MSE マイクロサービスレジストリの高可用性機能は、耐障害性の高いアプリケーションの構築に役立ちます。これらのベストプラクティスは、インスタンスの高可用性、サービスディスカバリの高可用性、設定管理の高可用性という観点から分類されています。本トピックでは、MSE マイクロサービスレジストリの Professional Edition を例として使用します。
推奨バージョン
spring-cloud-alibaba：2.2.6.RELEASE 以降。Dubbo：2.7.12 以降。spring-boot：2.3.x 以前。互換性の問題があるため、2.4.x バージョンの使用は推奨されません。
マイクロサービスレジストリインスタンスの高可用性
[高可用性アーキテクチャ]
可用性が 100% のサービスは存在しません。高い信頼性とデータセキュリティを確保するために、インスタンスを少なくとも 3 つのノードでデプロイすることを推奨します。あるノードで障害が発生した場合、トラフィックは数秒以内に他のノードに再ルーティングされ、障害が発生したノードはクラスターから自動的に削除されます。
マイクロサービスレジストリの Professional Edition は、Nacos 2.0 アーキテクチャをベースに構築されています。この設計はディザスタリカバリ機能を強化し、高可用性を実現するための基盤インフラへの依存を軽減します。詳細については、「インスタンスエディションの選択」をご参照ください。
[マルチゾーンデプロイ]
各 MSE リージョンには複数のゾーンが含まれています。同一リージョン内の異なるゾーンにあるアプリケーションは、フォールトアイソレーションのメリットを享受しながら、低いネットワークレイテンシー (3 ms 未満) を実現します。マルチゾーンインスタンスは、物理サーバーを異なるゾーンにまたがってデプロイします。ゾーン A で障害が発生した場合、トラフィックは迅速にゾーン B にリダイレクトされます。このプロセスはシームレスであり、アプリケーションコードを変更する必要はありません。ノード数を設定するだけで、MSE が自動的に複数のゾーンにまたがるデプロイを処理します。
図1. MSE 3 ノードアクティブ/アクティブアーキテクチャ
図2. 多層ディザスタリカバリ アーキテクチャ
サービスディスカバリの高可用性
サービスディスカバリでは、[コンシューマー] と [プロバイダー] で高可用性機能が異なります。[コンシューマー] は [Push-through protection] を、[プロバイダー] は [ディザスタリカバリ] をサポートします。
コンシューマー
コンシューマーは、レジストリからプロバイダーインスタンスのリストをサブスクライブします。レジストリでスケーリングやアップグレードなどの変更が行われたり、ゾーン全体のネットワーク停止や停電などの予期せぬイベントが発生したりすると、サブスクリプションが失敗し、コンシューマーの可用性に影響を与える可能性があります。
コンシューマー側で空のリスト保護を設定することで、障害発生時に空のインスタンスリストを受信することを防ぎます。
空のリスト保護がない場合：コンシューマーが空のリストを受信すると、サービスは中断され、エラーが報告されます。
空のリスト保護がある場合：コンシューマーが空のリストを受信すると、保護メカニズムが作動して更新を破棄し、サービスの可用性を維持します。
[設定]
この機能は、nacos-java-client 1.4.1 以降でのみサポートされています。互換性のある Spring Cloud および Dubbo のバージョンについては、「推奨バージョン」をご参照ください。
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：サポートされていません。永続的な接続が失われるとインスタンスは直ちにオフラインになるため、ディザスタリカバリポリシーはトリガーされません。
[コマンドラインによる設定]
特定サービスのしきい値の更新
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 アプリケーションのインターフェイス名。
しきい値設定の照会
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":[]}
[マイクロサービスガバナンスの高可用性設定]
グレースフルスタートアップ、グレースフルシャットダウン、外れ値インスタンスの除去、サービスディグレーデーションといったマイクロサービスガバナンス機能を使用することで、アプリケーションの可用性をさらに向上させることができます。
設定管理の高可用性
設定管理の高可用性は、主にクライアント側のキャッシュとバックアップディレクトリ、および設定センターの多層スロットリング機能という 2 つの側面によって実現されます。
以下の設定管理に関する高可用性機能は、マイクロサービスレジストリの Professional Edition でデフォルトで有効になっています。対応は不要です。
[Client]
[キャッシュディレクトリ]：クライアントが設定センターからデータを取得するたびに、最新の設定をローカルのキャッシュディレクトリに保存します。サーバーが利用できなくなった場合、クライアントはこのローカルキャッシュにフォールバックします。
[バックアップディレクトリ]：サーバーが利用できない場合は、ローカルのバックアップディレクトリ内のファイルを手動で更新できます。クライアントはこのディレクトリからの読み込みを優先し、サーバーからプッシュされた設定更新をシミュレートします。
[Configuration Center]
インフラストラクチャレベルでの高可用性に加えて、設定センターサービスは安定性を高めるために多次元のレート制限を実装しています。これには、ノードあたりの最大接続数やクライアント IP あたりの接続数制限が含まれます。また、1 秒あたりおよび 1 分あたりの設定発行に対するレート制限も含まれ、個別の設定に対するきめ細かなスロットリングも提供します。これらの措置は、異常なトラフィックによって引き起こされるサーバーのダウンタイムのリスクを軽減します。