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

# Amazon OpenSearch Service の専用コーディネーターノード
<a name="Dedicated-coordinator-nodes"></a>

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

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

## 専用コーディネーターノードを使用すべきシチュエーション
<a name="dedicated-coordinator-nodes-uses"></a>

専用コーディネーターノードは、以下のシナリオで最も有益です。
+ **大規模なクラスター** – 大量のデータや複雑なクエリがある環境では、調整タスクを専用ノードにオフロードすることで、クラスターのパフォーマンスを向上させることができます。
+ **頻繁なクエリ** – 頻繁な検索クエリや集計を含むワークロード、特に複雑な日付ヒストグラムや複数の集計を含むワークロードでは、クエリ処理の高速化により大きなメリットが得られます。
+ **ダッシュボードの高負荷使用** – OpenSearch Dashboards はリソースを大量に消費するツールです。この責任を専用コーディネーターノードにオフロードすることで、データノードへの負担が軽減されます。

## アーキテクチャと動作
<a name="dedicated-coordinator-nodes-architecture"></a>

OpenSearch クラスターでは、専用コーディネーターノードが 2 つの主要な責任を処理します。
+ **リクエスト処理** – これらのノードは検索リクエストを受信し、関連するデータが保存されている適切なデータノードに転送します。その後、複数のデータノードからの結果を 1 つのグローバル結果セットに統合してクライアントに返します。
+ **ダッシュボードホスティング** – コーディネーターノードは OpenSearch Dashboards を管理します。これにより、OpenSearch Dashboards をホストし、関連するトラフィックを処理するという追加の負担からデータノードを解放できます。

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

## 要件と制限
<a name="dedicated-coordinator-nodes-requirements"></a>

専用コーディネーターノードには、次の要件と制限があります。
+ 専有コーディネーターノードは、すべての OpenSearch バージョンと Elasticsearch バージョン 6.8 から 7.10 でサポートされています。
+ 専用コーディネーターノードを有効にするには、ドメインで専用マスターノードが有効になっている必要があります。詳細については、「[Amazon OpenSearch Service の専用マスターノード](managedomains-dedicatedmasternodes.md)」を参照してください。
+ 専用コーディネーターノードをプロビジョニングすると、追加コストが発生する可能性があります。ただし、リソース効率の向上とパフォーマンスの向上により、特に大規模または複雑なクラスターにおける投資は正当化されるでしょう。

## 専用コーディネーターノードのプロビジョニング
<a name="dedicated-coordinator-nodes-provisioning"></a>

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

### コンソール
<a name="dedicated-coordinator-nodes-provisioning-console"></a>

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

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

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

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

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

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

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

### AWS CLI
<a name="dedicated-coordinator-nodes-provisioning-cli"></a>

を使用して専用コーディネーターノードをプロビジョニングするには AWS CLI、[update-domain-config](https://docs.aws.amazon.com/cli/latest/reference/opensearch/update-domain-config.html) コマンドを使用します。次の例では、ドメインに 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
```

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

## ベストプラクティス
<a name="best-practices-dedicated-coordinator-nodes"></a>

専用コーディネーターノードを使用する場合は、次のベストプラクティスを考慮してください。
+ ほとんどのユースケースについては汎用インスタンスを使用してください。コストとパフォーマンスのバランスの取れたアプローチを提供します。メモリ最適化インスタンスは、複雑な集約や大規模な検索など、大量のメモリリソースを必要とするワークロードに最適です。
+ 開始点として、データノードの 5%～10% を専用コーディネーターノードとしてプロビジョニングすることをお勧めします。例えば、ドメインに特定のインスタンスタイプのデータノードが 90 個ある場合は、同じインスタンスタイプのコーディネーターノードを 5～9 個プロビジョニングすることを検討してください。
**注記**  
使用可能なインスタンスタイプは、リージョンごとに異なります。コーディネーターノードのインスタンスタイプを選択するときは、選択したインスタンスタイプが対象リージョンで使用可能かどうかを確認します。ドメインを作成または変更するときに、OpenSearch Service コンソールで利用可能なインスタンスタイプを確認できます。
+ 単一障害点のリスクを最小限に抑えるには、少なくとも 2 つの専用コーディネーターノードをプロビジョニングします。これにより、1 つのノードに障害が発生しても、クラスターは引き続き動作を継続できます。
+ クロスリージョン検索を使用している場合は、ターゲットドメインに専用のコーディネーターノードをプロビジョニングしてください。ソースドメインは通常、調整タスクを処理しません。
+ インデックス作成が多い環境では、最適なパフォーマンスを得るために、データノードのインスタンスサイズに一致する CPU 最適化インスタンスを検討してください。
+ メモリを大量に消費するワークロードでは、メモリ需要の増加を管理するために、専用コーディネーターノードに少し大きめのインスタンスタイプを使用します。
+ `CoordinatorCPUUtilization` Amazon CloudWatch メトリクスを追跡してください。一貫して 80% を超えている場合は、負荷を処理するためにより大きなコーディネーターノードまたは追加のコーディネーターノードが必要であることを示している可能性があります。
+ データノードに合わせて専用コーディネーターノードのサイズを設定しましょう。例えば、4xlarge データノードを使用する場合は、4xlarge 汎用コーディネーターノードから始めます。
+ 個々のリクエストまたはレスポンスで非常に高いメモリ (GB 単位) が必要でない限り、コーディネーターノードのインスタンス数を減らす代わりに、小さいインスタンスを複数使用します。例えば、6 つの 8xlarge 汎用インスタンスよりは 12 個の 4xl インスタンスを選択しましょう。

### クラスターサイズ別のノードの推奨事項
<a name="dedicated-coordinator-nodes-recs"></a>

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


| クラスターサイズ | 推奨コーディネーターノード | インスタンスタイプ | 
| --- | --- | --- | 
| 小規模 (最大 50 ノード) | 3～5 ノード | 汎用 | 
| 中規模 (50～100 ノード) | 5～9 ノード | メモリ最適化 | 
| 大規模 (100 ノード以上) | 10～15 ノード | メモリ最適化 |