Amazon OpenSearch Service の専用マスターノード

Amazon OpenSearch Service では、クラスターの安定性を向上するために専用マスターノードを使用します。専用マスターノードではクラスター管理タスクを実行しますが、データは保持せず、データのアップロードリクエストにも応答しません。このように、クラスター管理タスクをオフロードすると、ドメインの安定性が向上します。他のすべてのノードタイプと同様に、専用マスターノードごとに時間料金を支払います。

専用マスターノードで実行するクラスター管理タスクは次のとおりです。

• クラスター内のすべてのノードを追跡します。

• クラスター内のインデックスの数を追跡します。

• 各インデックスに属するシャード数を追跡します。

• クラスター内のノードのルーティング情報を保持します。

• クラスター内のインデックス作成やノードの作成/削除など、状態が変化したときにクラスターの状態を更新します。

• クラスターの状態に施された変更を、クラスター内のすべてのノードにわたって複製します。

• クラスター内のデータノードの可用性をモニタリングするハートビートシグナル (定期的なシグナル) を送信することで、すべてのクラスターノードの状態をモニタリングします。

次の図は、10 のインスタンスを持つ OpenSearch Service ドメインを表しています。インスタンスのうち 7 つはデータノードで、3 つは専用マスターノードです。アクティブになっているのは、専用マスターノードの 1 つだけです。2 つの灰色の専用マスターノードは、アクティブな専用マスターノードに障害が発生した場合のバックアップとして待機します。すべてのデータアップロードリクエストは、7 つのデータノードにより保存され、すべてのクラスター管理タスクは、アクティブな専用マスターノードにオフロードされます。

専用マスターノードの数の選択

スタンバイが有効のマルチ AZ を使用することを推奨します。これにより、本番稼働用の各 OpenSearch Service ドメインに 3 つの専用マスターノードが追加されます。スタンバイなしのマルチ AZ 、またはシングル AZ でデプロイする場合でも、3 つの専用マスターノードを推奨します。偶数の専用マスターノードを選択しないでください。専用マスターノードの数を選択するときは、次の点を考慮してください。

• 障害発生時にバックアップがないため、専用マスターノードの 1 つが OpenSearch Service によって明示的に禁止されています。1 つの専用マスターノードのみを持つドメインを作成しようとすると、検証例外が表示されます。

• 2 つの専用マスターノードがある場合、クラスターには、障害が発生した場合に新しいマスターノードを選択するために必要なノードのクォーラムがありません。

  クォーラムは、専用マスターノードの数/2 + 1 (直近の整数まで切り捨て) です。ここでは 2/2 + 1 = 2 となります。専用マスターノード 1 つが失敗し、バックアップは 1 つのみであれば、クラスターにはクォーラムがなく、新しいマスターを選択できません。

• 推奨される専用マスターノード数は 3 つです。マスターノードが失敗したときに 2 つのバックアップノードが使用でき、必要なクォーラム (2) で新しいマスターを選択できます。

• 専用マスターノードを 4 つにすると 3 つより良くなるわけではなく、複数のアベイラビリティーゾーンを使用した場合、問題が発生する可能性があります。

  • マスターノード 1 つが失敗した場合、クォーラム (3) で新しいマスターを選択します。2 つのノードが失敗したした場合、そのクォーラムは失われ、専用マスターノードが 3 つの場合と同じ状況になります。

  • 3 つのアベイラビリティーゾーン (AZ) 設定では、2 つの AZ に 1 つの専用マスターノードがあり、1 つの AZ に 2 つの専用マスターノードがあります。その AZ で中断が発生した場合、残りの 2 つの AZ には、新しいマスターを選択するために必要なクォーラム (3) がありません。

• 5 つの専用マスターノードは 3 つと同様に機能し、クォーラムを維持しながら 2 つのノードを失うことができます。ただし、一度にアクティブになる専用マスターノードは 1 つしかないため、この設定では 4 つのアイドルノードに対して料金を支払うことになります。多くのお客様は、このレベルのフェイルオーバーは過剰だと考えています。

クラスターに偶数のマスター対象ノードがある場合、OpenSearch および Elasticsearch バージョン 7.x 以降では 1 つのノードが無視されるため、投票設定は常に奇数になります。この場合、基本的に専用マスターノード 4 つは 3 つ (2 つは 1 つ) に相当します。

注記

新しいマスターノードを選択するために必要なクォーラムがクラスターにない場合は、クラスターへの書き込みおよび読み取りリクエストの両方が失敗します。この動作は OpenSearch のデフォルトとは異なります。

専用マスターノードのインスタンスタイプの選択

OpenSearch Service ドメインとインスタンスのクォータ

専用マスターノードでは検索およびクエリリクエストを処理しませんが、そのサイズは、管理可能なインスタンスサイズや、インスタンス数、インデックス数、シャード数と大きな相関があります。本番稼働用クラスターでは、最低でも専用マスターノードに以下のインスタンスタイプをお勧めします。

これらの推奨事項は一般的なワークロードに基づいており、お客様の要件によって異なります。多数のシャードまたはフィールドのマッピングがあるクラスターは、大きなインスタンスタイプからメリットを得ることができます。詳細については、「Amazon OpenSearch Service の推奨 CloudWatch アラーム」を参照して、より大きなインスタンスタイプを使用する必要があるかどうかを判断してください。

RAM	Elasticsearch および OpenSearch Service 1.x から 2.15 の最大ノードサポート	Elasticsearch および OpenSearch Service 2.15 以降の最大シャードサポート	Elasticsearch および OpenSearch Service 1.x から 2.15 の最大ノードサポート	Elasticsearch および OpenSearch Service 2.17 以降の最大シャードサポート
2 GB	該当しない	該当しない	10	1K
4 GB	該当しない	該当しない	10	5K
8 GB	10	10K	30	15K
16 GB	30	30K	60	30K
32 GB	75	40K	120	60K
64 GB	125	75K	240	120K
128 GB	200	75K	480	240K
256 GB	該当しない	該当しない	1002	500K