Amazon Web Services ブログ
Amazon OpenSearch Service Multi-AZ with Standby が有効化されたドメインによる高可用性の実現: フェイルオーバーの詳細
この記事は、Achieve high availability in Amazon OpenSearch Multi-AZ with Standby enabled domains: A deep dive into failovers を翻訳したものです。
Amazon OpenSearch Service は最近、Multi-AZ with Standby を導入しました。これは重要なワークロードに対して、強化された可用性と一貫したパフォーマンスをビジネスに提供するために設計されたデプロイメントオプションです。この機能により、マネージドクラスターはゾーンのインフラストラクチャ障害に対する回復力を保ちながら、99.99% の可用性を実現できます。
この投稿では、Multi-AZ with Standby での検索とインデックスの仕組みと、その信頼性、シンプルさ、耐障害性をもたらす基盤メカニズムについて掘り下げます。
背景
Multi-AZ with Standby では、OpenSearch Service ドメインのインスタンスを 3 つのアベイラビリティーゾーンにまたがってデプロイします。そのうち 2 つのゾーンがアクティブ、1 つがスタンバイとして指定されます。この構成により、すべてのゾーンで同じキャパシティを維持することで、ゾーン障害が発生した場合でも一貫したパフォーマンスが確保されます。特に、このスタンバイゾーンは静的に安定した設計に従うため、障害時のキャパシティのプロビジョニングやデータ移動の必要がなくなります。
通常の運用中、アクティブゾーンは読み込みと書き込みのリクエストのためのコーディネータートラフィック、およびシャードクエリトラフィックを処理します。一方、スタンバイゾーンはレプリケーショントラフィックのみを受信します。 OpenSearch Service は、書き込みリクエストに同期レプリケーションプロトコルを利用します。 これにより、障害が発生した場合にスタンバイゾーンをアクティブな状態にすばやく昇格させることができます (フェイルオーバーまでの平均時間は 1 分以内)。これをゾーンフェイルオーバーと呼びます。 以前にアクティブだったゾーンはスタンバイモードに降格され、正常な状態を回復するためのリカバリ操作が開始されます。
検索トラフィックのルーティングとフェイルオーバーによる高可用性の保証
OpenSearch Service ドメインにおいて、コーディネータとは、特にインデックス作成と検索リクエストを扱う HTTP(S) リクエストを処理するすべてのノードです。Multi-AZ with Standby を有効化したドメインでは、アクティブゾーンのデータノードが検索リクエストのコーディネータとして機能します。
検索リクエストのクエリの段階では、コーディネータはクエリ対象のシャードを決定し、そのシャードコピーをホストしているデータノードにリクエストを送信します。クエリは各シャードでローカルに実行され、マッチしたドキュメントがコーディネータノードに返されます。シャードコピーを含むノードにリクエストを送信する責務を持つコーディネータノードは、プロセスを 2 つのステップで実行します。 まず、シャードコピーにトラフィックが均一に分散されるように、シャードコピーをクエリするためにノードを問い合わせる順序を定義するイテレータを作成します。 その後、リクエストが関連するノードに送信されます。
シャードコピーのクエリ対象ノードの順序付きリストを作成するために、コーディネータノードはさまざまなアルゴリズムを使用します。 これらのアルゴリズムには、ラウンドロビン選択、適応型レプリカ選択、優先度ベースのシャードルーティング、重み付きラウンドロビンが含まれます。
Multi-AZ with Standby の場合、シャードコピーの選択には重み付きラウンドロビンアルゴリズムが使用されます。このアプローチでは、アクティブゾーンには重み 1 が割り当てられ、スタンバイゾーンには重み 0 が割り当てられます。これにより、スタンバイアベイラビリティーゾーンのデータノードに読み取りトラフィックが送信されないことが保証されます。 重みはクラスター状態メタデータ内に JSON オブジェクトとして保存されます:
次のスクリーンショットに示すように、us-east-1b リージョンのゾーンステータスが StandBy となっており、このアベイラビリティーゾーン内のデータノードがスタンバイ状態であり、ロードバランサーからの検索やインデックス要求を受信していないことを示しています。
定常状態の運用を維持するために、スタンバイのアベイラビリティーゾーンは 30 分ごとにローテーションされ、すべてのネットワークパーツがアベイラビリティーゾーン全体でカバーされていることが保証されます。このプロアクティブなアプローチは、読み取りパスの可用性を検証し、潜在的な障害時のシステムの回復力をさらに強化します。次の図は、このアーキテクチャを示しています。
前の図では、Zone-C の重み付きラウンドロビンの重みが 0 に設定されています。これにより、スタンバイゾーンのデータノードがインデックス作成や検索トラフィックを受信しないことが保証されます。 コーディネータがシャードコピーのクエリをデータノードに対して行うとき、クエリを送信するノードの順序を決定するために、重み付きラウンドロビンの重みが使用されます。 スタンバイアベイラビリティーゾーンの重みが 0 であるため、コーディネータのリクエストは送信されません。
OpenSearch Service クラスターでは、次のスクリーンショットに示すように、アベイラビリティーゾーンのローテーションメトリクスを使用して、アクティブゾーンとスタンバイゾーンをいつでも確認できます。
ゾーン障害時には、スタンバイアベイラビリティーゾーンがシームレスにフェイルオープンモードに切り替わり、検索リクエストを処理します。 これは、アクティブなアベイラビリティーゾーンで正常なシャードコピーが利用できない場合、スタンバイを含むすべてのアベイラビリティーゾーンにシャードクエリのトラフィックがルーティングされることを意味します。 このフェイルオープンアプローチにより、障害時の検索リクエストが中断されることから保護され、サービスの連続性が確保されます。次の図は、このアーキテクチャを示しています。
前の図では、定常状態時に、シャードクエリのトラフィックは、アクティブなアベイラビリティゾーン (ゾーン A とゾーン B) のデータノードに送信されます。 ゾーン A のノード障害が発生すると、スタンバイのアベイラビリティゾーン (ゾーンC) がオープンになってシャードクエリのトラフィックを受け取るため、検索リクエストに影響はありません。 最終的に、ゾーン A が不健全と検出されると、読み込みフェイルオーバーがスタンバイをゾーン A に切り替えます。
フェイルオーバーが書き込み障害時に高可用性を確保する方法
OpenSearch Service のレプリケーションモデルは、プライマリバックアップモデルに従っており、ユーザーの書き込みリクエストを承認する前に、すべてのシャードコピーからの承認が必要となる同期的な性質を特徴としています。このレプリケーションモデルの顕著な短所の 1 つは、書き込みパスに何らかの障害が発生した場合の低速化に対する脆弱性です。これらのシステムは、アクティブなリーダーノードに依存して、障害や遅延を特定し、その情報をすべてのノードにブロードキャストします。これらの問題を検出するのにかかる時間 (平均検出時間) と、その後解決するのにかかる時間 (平均修復時間) が、システムが障害状態で動作する時間を大きく左右します。さらに、ゾーン間通信に影響を与えるネットワークイベントは、レプリケーションの同期的な性質のため、書き込みリクエストを大幅に阻害する可能性があります。
OpenSearch Service は、書き込みトラフィックをレプリケートし、メタデータの更新を調整するために、選出されたリーダーを通じて内部のノード間通信プロトコルを利用します。 したがって、ストレスを受けているゾーンをスタンバイにすることは、書き込み障害の問題に効果的に対処することにはなりません。
ゾーンの書き込みフェイルオーバー: ゾーン間レプリケーショントラフィックの遮断
Multi-AZ with Standby の場合、想定外のゾーン障害やネットワークイベントなどで発生する可能性のあるパフォーマンスの問題を軽減するために、ゾーン間の書き込みフェイルオーバーは効果的なアプローチです。このアプローチでは、影響を受けたゾーン内のノードをクラスターから正常に削除することで、ゾーン間の入出力トラフィックを効果的に遮断します。ゾーン間のレプリケーショントラフィックを遮断することで、ゾーン障害の影響を影響を受けたゾーン内に限定することができます。これにより、お客様により予測可能な体験を提供し、システムが信頼性高く稼働し続けることを確実にします。
グレースフルな書き込みフェイルオーバー
OpenSearch Service 内の書き込みフェイルオーバーのオーケストレーションは、選出されたリーダーノードによって、明確に定義されたメカニズムを通じて実行されます。 このメカニズムには、クラスター状態の公開のためのコンセンサスプロトコルが含まれており、すべてのノードが一致して、常に 1 つのゾーンのみを廃止対象として指定することに同意します。 重要なことに、影響を受けたゾーンに関連するメタデータは、障害の発生時に完全な再起動があったとしても、その永続性を確保するために、すべてのノード間でレプリケートされます。
さらに、リーダーノードは I/O フェンシングを始める前に、まず影響を受けるゾーン内のノードを 5 分間スタンバイ状態に置くことで、スムーズで正常な移行を保証します。この意図的なアプローチにより、影響を受けたゾーン内のノードに新しいコーディネータトラフィックやシャードクエリトラフィックが向けられるのを防ぎます。これにより、これらのノードは進行中のタスクを正常に完了し、サービスから外される前に未処理のリクエストを徐々に処理できるようになります。次の図は、このアーキテクチャを示しています。
リーダーノードの書き込みフェイルオーバーを実装するプロセスで、OpenSearch Serviceは次の主要なステップに従います。
- リーダーの譲位 – リーダーノードが書き込みフェイルオーバーがスケジュールされているゾーンに位置している場合、システムはリーダーノードが自発的にリーダーシップの役割から下りることを保証します。この譲位は管理された方法で実行され、プロセス全体が別の適格なノードに引き継がれ、必要なアクションを担当します。
- 廃止予定のリーダーの再選を防ぐ – 書き込みフェイルオーバーがマークされたゾーンからのリーダーの再選を防ぐために、適格なリーダーノードが書き込みフェイルオーバーアクションを開始すると、廃止予定のリーダーノードがさらなる選挙に参加しないようにする措置を講じます。これは、廃止予定のリーダーノードを投票設定から除外することによって実現され、クラスターの運用の重要なフェーズでの投票を効果的に防ぎます。
書き込みフェイルオーバーゾーンに関連するメタデータはクラスター状態内に保存されます。この情報は、分散された OpenSearch Service クラスター内のすべてのノードに次のように公開されます。
次のスクリーンショットは、ゾーンでネットワークの低速化が発生した際、書き込みフェイルオーバーが可用性の回復に役立つことを示しています。
ゾーン回復後の書き込みフェイルオーバー
ゾーンの再起動プロセスは、ゾーンの書き込みフェイルオーバー後のリカバリフェーズで重要な役割を果たします。 影響を受けたゾーンが復旧し、安定していると見なされた後、以前に廃止されたノードがクラスターに再参加します。 この再参加は通常、ゾーンが再起動されてから 2 分以内の時間枠で発生します。
これにより、ピアノードとの同期が可能になり、レプリカシャードのリカバリプロセスが開始されるため、クラスターは目的の状態に効果的に復元されます。
結論
OpenSearch Service は Multi-AZ with Standby の導入により、重要なワークロードの高可用性と一貫したパフォーマンスを実現するための強力なソリューションが企業に提供されます。このデプロイオプションを使用することで、企業はインフラストラクチャの回復力を強化し、クラスタの構成と管理を簡素化し、ベストプラクティスを適用できます。 重み付きラウンドロビンによるシャードコピー選択、プロアクティブなフェイルオーバーメカニズム、フェイルオープンなスタンバイアベイラビリティゾーンなどの機能により、OpenSearch Service の Multi-AZ with Standby は、要求の厳しいエンタープライズ環境において、信頼性が高く効率的な検索エクスペリエンスを実現します。
Multi-AZ with Standby の詳細については、Amazon OpenSearch Service Under the Hood: Multi-AZ with Standbyを参照してください。