マイクロサービスエンジン(MSE)のマイクロサービスレジストリが提供する高可用性機能を使用することで、アプリケーションのリスク処理能力を大幅に向上させることができます。このトピックでは、実装範囲の観点から、マイクロサービスレジストリのインスタンス、サービスディスカバリ、および構成管理の高可用性機能を実装する方法について説明します。この例では、MSE のマイクロサービスレジストリ プロフェッショナル版を使用します。
推奨バージョン
spring-cloud-alibaba: 2.2.6.RELEASE 以降。dubbo: 2.7.12 以降。spring-boot: 2.3.x 以前。 2.4.x バージョンは互換性の問題があるため、使用しないことをお勧めします。
MSE レジストリの高可用性
[高可用性アーキテクチャ]
アプリケーションは常にダウンタイムなしで実行できるとは限りません。アプリケーションでより高い信頼性とデータセキュリティが必要な場合は、インスタンスに少なくとも 3 つのノードをデプロイすることをお勧めします。いずれかのノードがダウンした場合、そのノードのワークロードは数秒以内に他のノードに切り替えることができます。異常なノードはインスタンスから自動的に削除されます。
マイクロサービスレジストリ プロフェッショナル版は、Nacos 2.0 をベースに開発されています。 Nacos 2.0 アーキテクチャは、必要なインフラストラクチャリソースを少なく抑えながら、MSE インスタンスの高可用性を保証します。また、Nacos 2.0 アーキテクチャは、MSE インスタンスのディザスタリカバリ機能も強化します。詳細については、「共通インスタンスのタイプとエディションを選択する」をご参照ください。
[マルチゾーンデプロイメント]
各リージョンは複数のゾーンで構成されています。同じリージョンの異なるゾーンにデプロイされたアプリケーションは、3 ミリ秒未満のレイテンシで相互に通信できます。マルチゾーンデプロイメントでは、障害分離も可能です。たとえば、異なるゾーンにある複数の物理サーバーにインスタンスをデプロイできます。ゾーン A の物理サーバーがダウンした場合、その物理サーバーのワークロードは短時間で別のゾーンの物理サーバーに切り替えることができます。フェイルオーバープロセスはユーザーに対して透過的であり、アプリケーション側の変更を行う必要はありません。マルチゾーンデプロイメント用に複数のノードを構成すると、MSE はゾーン全体にインスタンスを自動的にデプロイします。
図 1. 3 ノードに基づくアクティブ - アクティブゾーン冗長アーキテクチャ
図 2. 階層型ディザスタリカバリ アーキテクチャ
サービスディスカバリの高可用性
サービスディスカバリには、[コンシューマー] と [プロバイダー] が含まれます。 [コンシューマー] は [空のリスト保護] 機能を提供し、[プロバイダー] は [ディザスタリカバリ] 機能を提供します。
コンシューマー
コンシューマーは、サービスレジストリ内のプロバイダーによって提供されるインスタンスリストをサブスクライブします。アプリケーションは常にダウンタイムなしで実行できるとは限りません。サービスレジストリが構成を更新したり、アップグレードまたはダウングレードを実行したり、ネットワークの切断や停電などの例外が発生したりすると、コンシューマーからのサブスクリプションが影響を受ける可能性があります。その結果、コンシューマーの可用性が影響を受けます。
例外によって発生するサブスクリプションエラーを処理するために、コンシューマーの空のリスト保護機能を有効にすることができます。
空のリスト保護を無効にすると、コンシューマーが空のインスタンスリストをサブスクライブしたときにビジネスが中断され、エラーが返されます。
空のリスト保護を有効にすると、コンシューマーによる空のインスタンスリストへのサブスクリプションは無視されます。これにより、ビジネスの高可用性が確保されます。
[空のリスト保護を有効にする]
nacos-java-client 1.4.1 以降のバージョンのみが空のリスト保護をサポートしています。空のリスト保護をサポートする Spring Cloud および Dubbo のバージョンについては、「推奨バージョン」をご参照ください。
Spring Cloud アプリケーション
Spring Cloud アプリケーションの構成に次の設定を追加します。
spring.cloud.nacos.discovery.namingPushEmptyProtection=trueDubbo アプリケーション
registry.url に次のパラメーターを追加します。
namingPushEmptyProtection=true
[永続キャッシング]
クライアントで空のリスト保護を有効にした後、アプリケーションをポッドにデプロイできます。ただし、キャッシュディレクトリに保存されているアプリケーションデータは、ポッドの再起動後に失われる可能性があります。この問題を解決するには、ボリュームを使用してキャッシュディレクトリを永続ストレージ用のポッドにマウントします。
キャッシュディレクトリは ${user.home}/nacos/naming/${namespaceId} です。
プロバイダー
プロバイダーは、トラフィックの急増によるサービスの中断を防ぐために、ディザスタリカバリ機能を提供します。
nacos-java-client 2.x バージョンを使用して登録されたプロバイダーは、ディザスタリカバリ機能をサポートしていません。
[ディザスタリカバリが無効になっている場合]
コンシューマーからのリクエスト数が急増すると、一部のプロバイダーノードが過負荷になり、サービスを提供できなくなる可能性があります。
サービスレジストリは異常なノードを削除し、リクエストを正常なノードに配信します。
正常なノードも過負荷になり、障害が発生する可能性があります。
その結果、すべてのプロバイダーノードがダウンし、ビジネスが中断されます。
[ディザスタリカバリが有効になっている場合]
コンシューマーからのリクエスト数が急増すると、一部のプロバイダーノードが過負荷になり、サービスを提供できなくなる可能性があります。
サービスレジストリは異常なノードを削除し、リクエストを正常なノードに配信します。
異常なノードの数がディザスタリカバリのしきい値に達すると、リクエストはすべての正常なノードに均等に配信されます。
ノードの半分がサービスを提供できます。
[ディザスタリカバリを有効にする]
[サポートされているインスタンスタイプ]
永続ストレージを使用するインスタンス:ディザスタリカバリがサポートされています。
永続ストレージを使用しないインスタンス:
nacos-java-client1.x:デフォルトでは、異常なノードは 30 秒間隔で削除されます。削除された異常なノードは、システムが異常なノードの数とディザスタリカバリのしきい値を照合する際に考慮されません。その結果、ディザスタリカバリ機能は期待どおりに機能しません。nacos-java-client2.x:ディザスタリカバリはサポートされていません。ノードへの永続的な接続が切断されると、システムはすぐにノードを削除します。その結果、ディザスタリカバリ機能は期待どおりに機能しません。
[CLI を使用してディザスタリカバリを有効にする]
特定のサービスのディザスタリカバリのしきい値を指定する
curl -X PUT "${nacos.address}/nacos/v1/ns/service?namespaceId=public&serviceName=my-provider&protectThreshold=0.6"${nacos.address}: サービスレジストリのエンドポイント。namespaceId: 名前空間の ID。デフォルト値:public。serviceName: Spring Cloud アプリケーションの名前または Dubbo アプリケーションの API 名。
ディザスタリカバリのしきい値を照会する
curl -X GET "${nacos.address}/nacos/v1/ns/service?namespaceId=public&serviceName=my-provider"返された結果
{"namespaceId":"public","groupName":"DEFAULT_GROUP","name":"my-provider","protectThreshold":0.7,"metadata":{},"selector":{"type":"none"},"clusters":[]}
[マイクロサービスガバナンスの高可用性]
マイクロサービスガバナンスを使用すると、さまざまな機能を実装できます。たとえば、アプリケーションを正常に起動またはシャットダウンしたり、外れ値インスタンスを削除したり、サービスダウングレードを構成したりできます。マイクロサービスガバナンスは、アプリケーションの高可用性の向上にも役立ちます。
構成管理の高可用性
構成管理の高可用性機能は、構成管理クライアントのキャッシュディレクトリとバックアップディレクトリ、およびレジストリの多次元スロットリング機能にあります。
デフォルトでは、構成管理機能によって提供される高可用性は、マイクロサービスレジストリ プロフェッショナル版で有効になっています。
[クライアント]
[キャッシュディレクトリ]: クライアントが構成センターとデータを交換するたびに、クライアントは最新の構成をローカルキャッシュディレクトリに保存します。サーバーが使用できない場合は、ローカルキャッシュディレクトリに保存されている構成が使用されます。
[バックアップディレクトリ]: サーバーが使用できない場合は、バックアップディレクトリに保存されている構成を手動で更新できます。その後、クライアントはバックアップディレクトリから構成をプルします。
[構成センター]
構成センターは、基盤となるリソースを管理および保守し、複数のメトリックに基づいてアプリケーションへのトラフィックを調整することで、アプリケーションの可用性を向上させます。これらのメトリックには、ノードごとの最大接続数とクライアント IP アドレスごとの最大接続数が含まれます。構成センターでは、構成セットを 1 秒あたりまたは 1 分あたりにパブリッシュできる回数を制限したり、特定の構成セットをパブリッシュするための 1 秒あたりまたは 1 分あたりのデータ転送を制限したりできます。これにより、トラフィックが急増した場合のサーバー障害のリスクが軽減されます。