翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon OpenSearch Service には、専用コーディネーターノードをプロビジョニングするオプションがあります。専用コーディネーターノードは、OpenSearch Dashboards の調整とホスティングの責任からデータノードを解放し、OpenSearch ドメインの回復性を向上させることができるデータノードのリソース使用率を向上させます。専用コーディネーターノードは、仮想プライベートクラウド (VPC) ドメインに必要なプライベート IP アドレスの予約を減らすのに役立ちます。専用コーディネーターノードはリソースの効率を高め、ワークロードの需要に応じてインデックス作成のスループットを最大 15% 向上させ、クエリパフォーマンスを 20% 向上させます。リソース効率の向上の詳細については、「専用コーディネーターノードによる OpenSearch Service クラスターの耐障害性とパフォーマンスの向上
コーディネーターノードロールの主な機能は、データを保持するデータノードにリクエストを送信し、各ノードの結果を単一のグローバル結果のセットに減らすことです。専用のコーディネーターノードがない場合、データノードは検索、データストレージ、インデックス作成の主要な責任とともに調整ロールを実行します。データノードには Kibana と OpenSearch Dashboards のホスティングが必要であり、リソース (メモリと CPU) の負担に直面する可能性があります。専用コーディネーターノードをプロビジョニングすることで、クラスターはデータノードから調整とダッシュボードホスティングの責任を軽減し、ドメインの耐障害性を向上させることができます。
OpenSearch のすべてのバージョンと Elasticsearch (オープンソース) バージョン 6.8 から 7.10 は、専用コーディネーターノードのプロビジョニングをサポートしています。専用コーディネーターノードプロビジョニングは、専用クラスターマネージャーが有効になっているドメインで使用できます。
OpenSearch VPC ドメインは、データノードではなく、専用コーディネーターノードに Elastic Network Interface (ENI) をアタッチします。専有コーディネーターノードは、通常、データノード全体の約 10% を占めます。その結果、VPC ドメイン用に予約されるプライベート IP アドレスの数が大幅に少なくなります。
ベストプラクティス
この章では、専用のコーディネーターノードをプロビジョニングするためのベストプラクティスと、多くのユースケースに適用される一般的なガイドラインについて説明します。各ワークロードは一意で、固有の特性があるため、すべてのユースケースに完全に適した一般的な推奨事項はありません。
-
ほとんどのユースケースでは、汎用インスタンスで十分です。
-
専用調整ノードとデータノードの場合、インスタンスファミリーは同じにしておきます。
-
ドメインの合計データノードの 5%～10% を専用コーディネーターノードとしてプロビジョニングします。例えば、ドメインに 90 R6g.large データノードがある場合、コーディネーターノードが R6g.large インスタンスタイプの 5～9 のいずれかを構成するように計画できます。
-
開始点として、専用コーディネーターノードのインスタンスサイズは、ドメインのデータノードと同じである必要があります。ただし、場合によっては、可用性を確保するために、カウント数の多い小さなインスタンスタイプを使用することをお勧めします。例えば、データノードのインスタンスサイズとして R6g.8xlarge を使用している場合は、1 つの M6g.8xlarge サイズではなく M6g.2xlarge サイズのインスタンスを 3 つ試して、可用性を向上させることができます。
-
ソースドメインは通常、調整タスクを実行しません。クロスリージョン検索を使用している場合は、送信先ドメインに専用コーディネーターノードをプロビジョニングします。
-
単一障害点を回避するには、少なくとも 2 つの専用コーディネーターノードをプロビジョニングします。
