Amazon OpenSearch Service の専用コーディネーターノード - Amazon OpenSearch Service
専用コーディネーターノードを使用すべきシチュエーションアーキテクチャと動作要件と制限専用コーディネーターノードのプロビジョニングベストプラクティス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon OpenSearch Service の専用コーディネーターノード

Amazon OpenSearch Service の専用コーディネーターノードは、データノードから調整タスクをオフロードする特殊なノードです。これらのタスクには、検索リクエストの管理や OpenSearch Dashboards のホスティングなどが含まれます。これらの機能を分離することで、専用コーディネーターノードはデータノードの負荷を軽減し、データノードがデータストレージ、インデックス作成、検索オペレーションに集中できるようにします。これにより、クラスター全体のパフォーマンスとリソース使用率が向上します。

さらに、専用コーディネーターノードは、VPC 設定に必要なプライベート IP アドレスの数を減らすため、より効率的なネットワーク管理につながります。この設定により、ワークロードの特性によっては、インデックス作成スループットが最大 15%、クエリパフォーマンスが 20% 向上します。

専用コーディネーターノードを使用すべきシチュエーション

専用コーディネーターノードは、以下のシナリオで最も有益です。

  • 大規模なクラスター – 大量のデータや複雑なクエリがある環境では、調整タスクを専用ノードにオフロードすることで、クラスターのパフォーマンスを向上させることができます。

  • 頻繁なクエリ – 頻繁な検索クエリや集計を含むワークロード、特に複雑な日付ヒストグラムや複数の集計を含むワークロードでは、クエリ処理の高速化により大きなメリットが得られます。

  • ダッシュボードの高負荷使用 – OpenSearch Dashboards はリソースを大量に消費するツールです。この責任を専用コーディネーターノードにオフロードすることで、データノードへの負担が軽減されます。

アーキテクチャと動作

OpenSearch クラスターでは、専用コーディネーターノードが 2 つの主要な責任を処理します。

  • リクエスト処理 – これらのノードは検索リクエストを受信し、関連するデータが保存されている適切なデータノードに転送します。その後、複数のデータノードからの結果を 1 つのグローバル結果セットに統合してクライアントに返します。

  • ダッシュボードホスティング – コーディネーターノードは OpenSearch Dashboards を管理します。これにより、OpenSearch Dashboards をホストし、関連するトラフィックを処理するという追加の負担からデータノードを解放できます。

VPC ドメインでは、専用コーディネーターノードには、データノードではなく Elastic Network Interface (ENI) が割り当てられます。この配置により、VPC に必要なプライベート IP アドレスの数を減らすことができ、ネットワーク効率が向上します。通常、専用コーディネーターノードは、データノード全体の約 10% を占めます。

要件と制限

専用コーディネーターノードには、次の要件と制限があります。

  • 専有コーディネーターノードは、すべての OpenSearch バージョンと Elasticsearch バージョン 6.8 から 7.10 でサポートされています。

  • 専用コーディネーターノードを有効にするには、ドメインで専用マスターノードが有効になっている必要があります。詳細については、「Amazon OpenSearch Service の専用マスターノード」を参照してください。

  • 専用コーディネーターノードをプロビジョニングすると、追加コストが発生する可能性があります。ただし、リソース効率の向上とパフォーマンスの向上により、特に大規模または複雑なクラスターにおける投資は正当化されるでしょう。

専用コーディネーターノードのプロビジョニング

既存のドメインに専用コーディネーターノードをプロビジョニングするには、次の手順を実行します。コーディネーターノードをプロビジョニングする前に、ドメインで専用マスターノードが有効になっていることを確認してください。

で専用コーディネーターノードをプロビジョニングするには AWS マネジメントコンソール

  1. https://console.aws.amazon.com/aos/home で Amazon OpenSearch Service コンソールにサインインします。

  2. [ドメイン] を選択し、変更するドメインを選択します。

  3. [クラスターの設定] セクションで、[編集] を選択します。

  4. [専用コーディネーターノードを有効にする] を選択します。

  5. プロビジョニングするコーディネーターノードのインスタンスタイプと数を選択します。

  6. [Save changes] (変更の保存) をクリックします。ドメインが更新されるまでに数分かかる場合があります。

を使用して専用コーディネーターノードをプロビジョニングするには AWS CLI、update-domain-config コマンドを使用します。次の例では、ドメインに 3 つの r6g.large.search コーディネーターノードをプロビジョニングします。

aws opensearch update-domain-config \
  --domain-name my-opensearch-domain \
  --cluster-config InstanceCount=3,InstanceType=r6g.large.search,DedicatedCoordinatorCount=3,ZoneAwarenessEnabled=true,DedicatedCoordinatorEnabled=true

このコマンドは、専用コーディネーターノードを有効にし、コーディネーターノードのインスタンスタイプと数を設定し、ゾーン認識を有効にて可用性を高めます。

ベストプラクティス

専用コーディネーターノードを使用する場合は、次のベストプラクティスを考慮してください。

  • ほとんどのユースケースについては汎用インスタンスを使用してください。コストとパフォーマンスのバランスの取れたアプローチを提供します。メモリ最適化インスタンスは、複雑な集約や大規模な検索など、大量のメモリリソースを必要とするワークロードに最適です。

  • 開始点として、データノードの 5%～10% を専用コーディネーターノードとしてプロビジョニングすることをお勧めします。例えば、ドメインに特定のインスタンスタイプのデータノードが 90 個ある場合は、同じインスタンスタイプのコーディネーターノードを 5～9 個プロビジョニングすることを検討してください。

    注記

    使用可能なインスタンスタイプは、リージョンごとに異なります。コーディネーターノードのインスタンスタイプを選択するときは、選択したインスタンスタイプが対象リージョンで使用可能かどうかを確認します。ドメインを作成または変更するときに、OpenSearch Service コンソールで利用可能なインスタンスタイプを確認できます。

  • 単一障害点のリスクを最小限に抑えるには、少なくとも 2 つの専用コーディネーターノードをプロビジョニングします。これにより、1 つのノードに障害が発生しても、クラスターは引き続き動作を継続できます。

  • クロスリージョン検索を使用している場合は、ターゲットドメインに専用のコーディネーターノードをプロビジョニングしてください。ソースドメインは通常、調整タスクを処理しません。

  • インデックス作成が多い環境では、最適なパフォーマンスを得るために、データノードのインスタンスサイズに一致する CPU 最適化インスタンスを検討してください。

  • メモリを大量に消費するワークロードでは、メモリ需要の増加を管理するために、専用コーディネーターノードに少し大きめのインスタンスタイプを使用します。

  • CoordinatorCPUUtilization Amazon CloudWatch メトリクスを追跡してください。一貫して 80% を超えている場合は、負荷を処理するためにより大きなコーディネーターノードまたは追加のコーディネーターノードが必要であることを示している可能性があります。

  • データノードに合わせて専用コーディネーターノードのサイズを設定しましょう。例えば、4xlarge データノードを使用する場合は、4xlarge 汎用コーディネーターノードから始めます。

  • 個々のリクエストまたはレスポンスで非常に高いメモリ (GB 単位) が必要でない限り、コーディネーターノードのインスタンス数を減らす代わりに、小さいインスタンスを複数使用します。例えば、6 つの 8xlarge 汎用インスタンスよりは 12 個の 4xl インスタンスを選択しましょう。

クラスターサイズ別のノードの推奨事項

クラスターサイズに基づいて専用コーディネーターノードをプロビジョニングするための出発点として、次のガイドラインを参照ください。ワークロードの特性とパフォーマンスメトリクスに基づいて、ノードの数とタイプを調整します。

クラスターサイズ 推奨コーディネーターノード インスタンスタイプ

小規模 (最大 50 ノード)

 3～5 ノード 汎用

中規模 (50～100 ノード)

 5～9 ノード メモリ最適化

大規模 (100 ノード以上)

 10～15 ノード メモリ最適化