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

# インスタンスタイプとテストの選択
<a name="bp-instances"></a>

ストレージ要件を計算して必要なシャード数を選択したら、ハードウェアに関する決定ができるようになります。ハードウェア要件はワークロードによって大きく異なるものの、基本的な推奨事項は提供されています。

各インスタンスタイプの[ストレージ制限](limits.md)は一般的に、軽度のワークロードで必要とされる CPU とメモリの量にマッピングされています。たとえば、`m6g.large.search` インスタンスが最大で 512 GiB の EBS ボリュームサイズ、vCPU x 2 コア、8 GiB のメモリを備えているとします。クラスターには多数のシャードがあり、高負荷の集計処理、頻繁なドキュメント更新、または大量のクエリ処理が発生している場合、それらのリソースではニーズを満たせない可能性があります。クラスターがこのようなカテゴリに分類される場合はまず、ストレージ要件の容量 100 GiB ごとに vCPU x 2 コア、メモリ 8 GiB に近い構成になるようにします。

**ヒント**  
各インスタンスタイプに割り当てられるハードウェアリソースの概要については、「[Amazon OpenSearch Service の料金表](https://aws.amazon.com/opensearch-service/pricing/)」を参照してください。

ただし、上記に記載されたリソースでも不十分になる場合があります。一部の OpenSearch ユーザーからは、要件を満たすためにこれらのリソースが重ねて必要になるという報告を受けています。ワークロードに適したハードウェアを見つけるには、知識に基づいた初期予測を作成し、代表的なワークロードでテストし、調整して、再度テストする必要があります。

## ステップ 1: 初期見積もりを作成する
<a name="initial-estimate"></a>

開始の際に、*スプリットブレイン*の状態 (コミュニケーションでの時間の経過により、クラスターが 2 つのマスターノードを持つようになる) などの潜在的な OpenSearch の問題を防ぐために、3 つ以上のノード数を選択することをお勧めします。[専用マスターノードが 3 つの場合は](managedomains-dedicatedmasternodes.md)、レプリケーション用のデータノードは少なくとも 2 つにすることをお勧めします。

## ステップ 2: ノードごとのストレージ要件を計算する
<a name="determine-storage"></a>

ストレージ要件が 184 GiB で、推奨最小数である 3 つのノードがある場合、各ノードで必要とするストレージの容量は 184/3 = 61 GiB という計算になります。この例では、3 つの `m6g.large.search` インスタンスを選択してそれぞれで 90 GiB の EBS ストレージボリュームを使用すれば、安全策として時間の経過に伴う拡張にも備えることができます。この構成では 6 つの vCPU コアと 24 GiB のメモリを利用でき、軽度のワークロードに適しています。

より大規模な例として、ストレージ要件が 14 TiB (14,336 GiB) で高い負荷が発生する状況を想定します。この場合、まずは 2 \* 144 = 288 の vCPU コアと 8 \* 144 = 1,152 GiB のメモリを使用したテストが考えられます。これらの数値は、約 18 `i3.4xlarge.search` インスタンスを使用する結果となります。高速なローカルストレージが必要ない場合、それぞれが 1 TiB の EBS ストレージボリュームを使用する 18 個の `r6g.4xlarge.search` インスタンスをテストすることもできます。

クラスターに数百テラバイトのデータが含まれる場合は、「[Amazon OpenSearch Service 用ペタバイトスケール](petabyte-scale.md)」を参照してください。

## ステップ 3: 代表的なテストを実行する
<a name="test-sizing"></a>

クラスターを設定したら、先ほど計算したシャードの数を使用して[インデックスを追加](indexing.md)し、実践的なデータセットを使用して代表的なクライアントテストを実行し、[CloudWatch メトリクスのモニタリング](managedomains-cloudwatchmetrics.md)によりクラスターでのワークロードの処理状況を確認できます。

## ステップ 4: 成功または反復する
<a name="test-iterate"></a>

パフォーマンスがニーズを満たすものであれば、テストは成功し、CloudWatch メトリクスは正常であり、クラスターは使用する準備ができたことになります。リソースの異常な使用状況を検出するために、必ず [CloudWatch アラームを設定](cloudwatch-alarms.md)してください。

パフォーマンスが許容できないものであれば、テストが失敗したか、または `CPUUtilization` か `JVMMemoryPressure` が高いことになります。別のインスタンスタイプを選択 (またはインスタンスを追加) して、テストを続行する必要があるかもしれません。インスタンスを追加すると、OpenSearch はクラスター全体にわたってシャードを自動的に再分散します。

過負荷クラスターの過剰容量は、負荷の低いクラスターの不足よりも簡単に測定できるため、必要以上に大きなクラスターから開始することをお勧めします。次に、追加のリソースを持つ効率的なクラスターにテストおよびスケールダウンして、アクティビティの増加期間中に安定した運用を確保します。

本番稼働用クラスター (1 つまたは複数) では複雑なステータスが発生しますが、[専用マスターノード](managedomains-dedicatedmasternodes.md)を活用することでパフォーマンスとクラスターの信頼性を向上させることができます。