翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon OpenSearch Service でのマルチ AZ ドメインの設定
サービス中断が発生した場合にデータの損失を防ぎ、Amazon OpenSearch Service クラスターのダウンタイムを最小限に抑えるため、同じリージョン内の 2 つまたは 3 つの*アベイラビリティーゾーン*間にノードを分散できます。これは、マルチ AZ と呼ばれる設定です。アベイラビリティーゾーンは、各 AWS リージョン内の独立した場所です。
プロダクションワークロードを実行するドメインでは、Multi-AZ with Standby デプロイのオプションが推奨されます。このオプションが次の構成を作成します。
+ ドメインが 3 つのゾーン間にデプロイされました。
+ 専用マスターノードおよびデータノードに、現行世代のインスタンスタイプを選択します。
+ 3 つの専用マスターノードと 3 つ (または 3 の倍数) のデータノード。
+ ドメイン内の各インデックスに 2 つ以上のレプリカ、または 3 の倍数のデータコピー (プライマリノードとレプリカの両方を含む)。
このセクションの残りの部分では、これらの構成とそのコンテキストについて説明します。
## Multi-AZ with Standby
Multi-AZ with Standby は、99.99% の可用性、プロダクションワークロードでの一貫したパフォーマンス、シンプルなドメイン設定と管理とを実現した、Amazon OpenSearch Service ドメインのデプロイオプションです。Multi-AZ with Standby を使用したドメインは、インフラストラクチャの障害に対して回復力があり、パフォーマンスや可用性に一切影響を与えません。このデプロイオプションは、指定されたデータノード数、マスターノード数、インスタンスタイプ、レプリカ数、ソフトウェア更新設定、Auto-Tune の有効化など、数多くのベストプラクティスを義務付けることでこの標準を達成しています。
**注記**
スタンバイ付きマルチ AZ は OpenSearch バージョン 1.3 以降で利用可能で、少なくとも 3 つのアベイラビリティーゾーンを持つリージョンが必要です。
Multi-AZ with Standby を使用すると、OpenSearch Service が 3 つのアベイラビリティーゾーンを横断してドメインを作成し、データの完全なコピーが各ゾーンに追加され、データは各ゾーンに均等に分散されます。ドメインは、これらのゾーンのいずれかの 1 つのノードをスタンバイとして予約します。このノードは、検索リクエストの処理を行いません。OpenSearch Service が基盤のインフラストラクチャで障害を検出すると、スタンバイノードが 1 分以内に自動的にアクティブ化します。ドメインは、引き続きインデックス作成と検索リクエストを処理し、その影響は、フェイルオーバーの実行に必要な時間に限られます。データやリソースの再配布は行われないため、クラスターのパフォーマンスには影響せず、可用性が下がるリスクもありません。Multi-AZ with Standby は、追加コストなしでご利用いただけます。
AWS マネジメントコンソールでスタンバイ付きのドメインを作成するには、2 つの方法があります。1 つ目では、**[簡易作成]** の作成方法を使用してドメインを作成します。OpenSearch Service は、次を含む、あらかじめ決められた設定を自動的に使用します。
+ 3 つのアベイラビリティーゾーン、1 つはスタンバイとして機能
+ 3 つの専用マスターノードとデータノード
+ Auto-Tune がドメインで有効になっている
+ データノード用の GP3 ストレージ
また、**[標準作成]** の作成方法を選択し、デプロイオプションとして **[スタンバイ状態のドメイン]** を選択することもできます。これにより、ドメインをカスタマイズしながら、引き続き 3 つのゾーンと 3 つのマスターノードなどスタンバイの主な機能を要求することができます。データノードの数は 3 の倍数 (アベイラビリティーゾーンの数) を選ぶことが推奨されます。
ドメインを作成したら、ドメインの詳細ページに移動し、**[クラスター設定]** タブで、アベイラビリティーゾーンに「スタンバイ状態の 3 つの AZ」と表示されていることを確認します。
既存のドメインを Multi-AZ with Standby へ移行する際に問題が生じた場合は、トラブルシューティングガイドの「[Multi-AZ with Standby に移行する際のエラー](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/handling-errors.html#troubleshooting-multi-az-standby)」を参照してください。
### 制限事項
Multi-AZ with Standby のドメインを設定するときは、次の制限を考慮します。
+ ノード上のシャードの合計数は 1000 を超えることはできず、クラスター上のシャードの合計数は 75000 を超えることはできず、1 つのシャードの容量は 65 GB を超えることはできません。
+ スタンバイ付きマルチ AZ は、`m5`、、`c5`、`r5`、`r6g`、`c6g`、`m6g`、`r6gd`、`r7gd`、、、および `r7g` `c7g` `m7g``i3`インスタンスタイプでのみ機能します。サポートされているインスタンスタイプの詳細については、「[サポートされるインスタンスタイプ](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/supported-instance-types.html)」を参照してください。
+ スタンバイではプロビジョンド IOPS SSD、汎用 SSD (GP3)、または instance-backed ストレージのみを使用できます。
+ スタンバイ付きマルチ AZ ドメインで [UltraWarm](ultrawarm.md) を有効にする場合、ウォームノードの数は、使用されるアベイラビリティーゾーンの数の倍数である必要があります。
## Multi-AZ without Standby
OpenSearch Service は、Multi-AZ without Standby もサポートしています。こちらの可用性は 99.9% です。ノードはアベイラビリティーゾーン全体に分散しており、可用性は、アベイラビリティーゾーンとデータコピーの数に依存します。スタンバイ付きの場合はドメインをベストプラクティスで設定する必要がありますが、スタンバイが付いていない場合は、アベイラビリティゾーン、ノード、レプリカの数を自分で選択できます。この方法は、スタンバイ付きのドメインを作成した場合に既存のワークフローが中断する可能性がない限り、推奨されません。
この方法を選択した場合でも、ノード、ディスク、シングル AZ での障害に対する回復力を維持するため、3 つのアベイラビリティーゾーンを選択することが引き続き推奨されます。障害が発生すると、クラスターは、可用性と冗長性を保つため他のリソースにデータを再分散します。このデータ移動によりクラスターでのリソースの使用量が増加し、パフォーマンスに影響する可能性があります。クラスターの容量が適切でないと可用性は低下します。これでは、マルチ AZ の目的が大きく損なわれかねません。
でスタンバイなしでドメインを設定する唯一の方法は AWS マネジメントコンソール 、**標準作成**方法を選択し、**スタンバイなしでドメイン**をデプロイオプションとして選択することです。
### シャード分散
スタンバイの付いていないマルチ AZ を有効にする場合は、クラスターの各インデックスに 1 つ以上のレプリカを作成します。レプリカがないと、OpenSearch Service はデータのコピーを他のアベイラビリティーゾーンに分散することができません。さいわい、すべてのインデックスのデフォルト設定で、レプリカの数は 1 つです。次の図に示すように、OpenSearch Service は、最善の方法でプライマリシャードとそれに対応するレプリカシャードを異なるゾーンに分散します。
シャードをアベイラビリティーゾーンごとに分散することに加えて、OpenSearch Service はノードごとにシャードを分散します。それでも、特定のドメイン設定ではシャード数が不均等にある場合があります。次のドメインを考えます。
+ データノード x 5
+ プライマリシャード x 5
+ レプリカ x 2
+ アベイラビリティーゾーン x 3
この状況では、次の図に示すように、OpenSearch Service はゾーン間でプライマリシャードとレプリカシャードを分散するために 1 つのノードをオーバーロードする必要があります。
こうした、個々のノードに負荷がかかってパフォーマンスが低下する状況を避けるため、Multi-AZ with Standby を選択するか、インデックスごとのレプリカ数を 2 つ以上にする場合は インスタンスの数を 3 の倍数にすることが推奨されます。
### 専用マスターノード分散
ドメインを設定するときに 2 つのアベイラビリティーゾーンを選択した場合でも、OpenSearch Service は 3 つのアベイラビリティーゾーン間に[専用マスターノード](managedomains-dedicatedmasternodes.md)を自動的に分散します。この分散により、ゾーンでサービス中断が発生した場合にクラスターのダウンタイムを防ぐことができます。推奨される 3 つの専用マスターノードを使用していて、1 つのアベイラビリティーゾーンがダウンした場合でも、クラスターには専用マスターノードのクォーラム (2) が残り、新しいマスターを選択できます。この設定は以下の図のようになります。
3 つのアベイラビリティーゾーンで使用できない旧世代のインスタンスタイプを選択した場合、以下のシナリオが適用されます。
+ ドメインに 3 つのアベイラビリティーゾーンを選択した場合、OpenSearch Service はエラーをスローします。異なるインスタンスタイプを選択し、もう一度試します。
+ ドメインに 2 つのアベイラビリティーゾーンを選択した場合、OpenSearch Service は 2 つのゾーン間に専用マスターノードを分散します。
## アベイラビリティーゾーンの中断
アベイラビリティーゾーンの中断が発生することはほとんどありませんが、起こり得ます。以下の表に、各種マルチ AZ 設定と中断時の動作を示します。表の最後の行は Multi-AZ with Standby に適用され、それ以外のすべての行は Multi-AZ without Standby にのみ適用される構成になっています。
| リージョン内のアベイラビリティーゾーン数 | 選択したアベイラビリティーゾーンの数 | 専用マスターノードの数 | 1 つのアベイラビリティーゾーンで中断が発生した場合の動作 |
| --- | --- | --- | --- |
| 2 以上 | 2 | 0 | ダウンタイム。クラスターのデータノードの半分が失われます。マスターを選択する前に残りのアベイラビリティーゾーンで少なくとも 1 つを置き換える必要があります。 |
| 2 | 2 | 3 | ダウンタイムの可能性は五分五分です。OpenSearch Service は、2 つの専門マスターノードを 1 つのアベイラビリティーゾーンに、もう 1 つを他のアベイラビリティーゾーンに分散します。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/managedomains-multiaz.html) |
| 3 以上 | 2 | 3 | ダウンタイムはありません。OpenSearch Service は、専用マスターノードを 3 つのアベイラビリティーゾーン間で自動的に分散するため、残りの 2 つの専用マスターノードがマスターを選択できます。 |
| 3 以上 | 3 | 0 | ダウンタイムはありません。データノードの約 3 分の 2 が引き続きマスターを選択できます。 |
| 3 以上 | 3 | 3 | ダウンタイムはありません。残りの 2 つの専用マスターノードがマスターを選択できます。 |
原因に関係なく*あらゆる*設定において、ノードの障害が発生すると、欠落したノードを置き換えるために OpenSearch Service が自動的に新しいノードを設定する間、クラスターの残りのデータノードで非常に大きな負荷がかかる期間が発生する可能性があります。
たとえば、3 ゾーン設定でアベイラビリティーゾーンが中断した場合、3 分の 2 に相当するデータノードがクラスターへのリクエストを処理する必要があります。これらのリクエストを処理するとき、残りのノードはオンラインになる新しいノードにもシャードをレプリケートするため、さらにパフォーマンスに影響が及びます。ワークロードにとって可用性が重要な場合、クラスターにリソースを追加してこの問題を緩和することを検討してください。
**注記**
OpenSearch Service はマルチ AZ ドメインを透過的に管理するため、アベイラビリティーゾーンの中断を手動でシミュレートすることはできません。