Amazon OpenSearch Service でのマルチ AZ ドメインの設定
サービス中断が発生した場合にデータの損失を防ぎ、Amazon OpenSearch Service クラスターのダウンタイムを最小限に抑えるため、同じリージョン内の 2 つまたは 3 つのアベイラビリティーゾーン間にノードを分散できます。これは、マルチ AZ と呼ばれる設定です。アベイラビリティーゾーンは、各 AWS リージョン内の独立した場所です。
実稼働ワークロードを実行するドメインの場合、次の設定をお勧めします。
-
OpenSearch Service により 3 つのアベイラビリティーゾーンをサポートするリージョンを選択します。
-
3 つのゾーン間にドメインをデプロイします。
-
専用マスターノードおよびデータノードに現行世代のインスタンスタイプを選択します。
-
3 つの専用マスターノードと少なくとも 3 つのデータノードを使用します。
-
クラスター内のインデックスごとに少なくとも 1 つのレプリカを作成します。
このセクションの残りの部分では、これらの推奨事項について説明し、そのコンテキストを示します。
シャード分散
マルチ AZ を有効にする場合は、クラスターの各インデックスに少なくとも 1 つのレプリカを作成する必要があります。レプリカがないと、OpenSearch Service はデータのコピーを他のアベイラビリティーゾーンに分散できないため、マルチ AZ の意味がほとんどなくなります。さいわい、すべてのインデックスのデフォルト設定で、レプリカの数は 1 つです。次の図に示すように、OpenSearch Service は、最善の方法でプライマリシャードとそれに対応するレプリカシャードを異なるゾーンに分散します。
シャードをアベイラビリティーゾーンごとに分散することに加えて、OpenSearch Service はノードごとにシャードを分散します。それでも、特定のドメイン設定ではシャード数が不均等にある場合があります。次のドメインを考えます。
-
データノード x 5
-
プライマリシャード x 5
-
レプリカ x 2
-
アベイラビリティーゾーン x 3
この状況では、次の図に示すように、OpenSearch Service はゾーン間でプライマリシャードとレプリカシャードを分散するために 1 つのノードをオーバーロードする必要があります。
個々のノードに負荷がかかってパフォーマンスが低下する可能性があるこのような状況を回避するため、インデックスあたりのレプリカが複数になる予定の場合は 3 の倍数のインスタンス数を選択することをお勧めします。
専用マスターノード分散
ドメインを設定するときに 2 つのアベイラビリティーゾーンを選択した場合でも、OpenSearch Service は 3 つのアベイラビリティーゾーン間に専用マスターノードを自動的に分散します。この分散により、ゾーンでサービス中断が発生した場合にクラスターのダウンタイムを防ぐことができます。推奨される 3 つの専用マスターノードを使用していて、1 つのアベイラビリティーゾーンがダウンした場合でも、クラスターには専用マスターノードのクォーラム (2) が残り、新しいマスターを選択できます。この設定は以下の図のようになります。
この自動分散にはいくつかの重要な例外があります。
-
3 つのアベイラビリティーゾーンで使用できない旧世代のインスタンスタイプを選択した場合、以下のシナリオが適用されます。
-
ドメインに 3 つのアベイラビリティーゾーンを選択した場合、OpenSearch Service はエラーをスローします。異なるインスタンスタイプを選択し、もう一度試します。
-
ドメインに 2 つのアベイラビリティーゾーンを選択した場合、OpenSearch Service は 2 つのゾーン間に専用マスターノードを分散します。
-
-
すべての AWS リージョンに 3 つのアベイラビリティーゾーンがあるわけではありません。それらのリージョンでは、2 つのゾーンのみを使用するようにドメインを設定できます (OpenSearch Service は 2 つのゾーン間にのみ専用マスターノードを分散できます)。
アベイラビリティーゾーンの中断
アベイラビリティーゾーンの中断が発生することはほとんどありませんが、起こり得ます。以下の表に、各種マルチ AZ 設定と中断時の動作を示します。
| リージョン内のアベイラビリティーゾーン数 | 選択したアベイラビリティーゾーンの数 | 専用マスターノードの数 | 1 つのアベイラビリティーゾーンで中断が発生した場合の動作 |
|---|---|---|---|
| 2 以上 | 2 | 0 |
ダウンタイム。クラスターのデータノードの半分が失われます。マスターを選択する前に残りのアベイラビリティーゾーンで少なくとも 1 つを置き換える必要があります。 |
| 2 | 2 | 3 |
ダウンタイムの可能性は五分五分です。OpenSearch Service は、2 つの専門マスターノードを 1 つのアベイラビリティーゾーンに、もう 1 つを他のアベイラビリティーゾーンに分散します。
|
| 3 以上 | 2 | 3 |
ダウンタイムはありません。OpenSearch Service は、専用マスターノードを 3 つのアベイラビリティーゾーン間で自動的に分散するため、残りの 2 つの専用マスターノードがマスターを選択できます。 |
| 3 以上 | 3 | 0 |
ダウンタイムはありません。データノードの約 3 分の 2 が引き続きマスターを選択できます。 |
| 3 以上 | 3 | 3 |
ダウンタイムはありません。残りの 2 つの専用マスターノードがマスターを選択できます。 |
原因に関係なくあらゆる設定において、ノードの障害が発生すると、欠落したノードを置き換えるために OpenSearch Service が自動的に新しいノードを設定する間、クラスターの残りのデータノードで非常に大きな負荷がかかる期間が発生する可能性があります。
たとえば、3 ゾーン設定でアベイラビリティーゾーンが中断した場合、3 分の 2 に相当するデータノードがクラスターへのリクエストを処理する必要があります。これらのリクエストを処理するとき、残りのノードはオンラインになる新しいノードにもシャードをレプリケートするため、さらにパフォーマンスに影響が及びます。ワークロードにとって可用性が重要な場合、クラスターにリソースを追加してこの問題を緩和することを検討してください。
OpenSearch Service はマルチ AZ ドメインを透過的に管理するため、アベイラビリティーゾーンの中断を手動でシミュレートすることはできません。
