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 (ENIsが割り当てられます。この配置により、VPCs に必要なプライベート IP アドレスの数を減らすことができ、ネットワーク効率が向上します。通常、専用コーディネーターノードはデータノード全体の約 10% を占めます。

要件と制限

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

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

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

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

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

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

で専用コーディネーターノードをプロビジョニングするには AWS Management Console

  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% を超える場合は、負荷を処理するためにより大きなコーディネーターノードまたは追加のコーディネーターノードが必要であることを示している可能性があります。

クラスターサイズ別のノードレコメンデーション

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

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

スモール (最大 50 ノード）

 3～5 ノード 汎用

中 (50～100 ノード）

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

ラージ (100 個以上のノード）

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