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

インスタンスタイプとテストの選択

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

一般的に、各インスタンスタイプのストレージ制限は、ライトワークロードに必要な CPUとメモリの量にマッピングされます。例えば、m6g.large.searchインスタンスの最大EBSボリュームサイズは 512 GiB、2 vCPU コア、8 GiB のメモリです。クラスターには多数のシャードがあり、高負荷の集計処理、頻繁なドキュメント更新、または大量のクエリ処理が発生している場合、それらのリソースではニーズを満たせない可能性があります。クラスターがこれらのカテゴリのいずれかに該当する場合は、ストレージ要件の 100 GiB ごとに 2 vCPU コアと 8 GiB のメモリに近い設定から開始してみてください。

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

ステップ 1: 初期見積もりを作成する

開始するには、スプリットブレイン状態 (通信が遅れて 2 つのマネージャーノードを持つクラスターになる場合) などの潜在的な OpenSearch問題を避けるため、最低 3 つのノードをお勧めします。専用マネージャーノードが 3 つある場合でも、レプリケーションには最低 2 つのデータノードをお勧めします。

ステップ 2: ノードごとのストレージ要件を計算する

ストレージ要件が 184 GiB で、推奨最小数である 3 つのノードがある場合、各ノードで必要とするストレージの容量は 184/3 = 61 GiB という計算になります。この例では、それぞれが 90-GiBEBSストレージボリュームを使用する 3 つのm6g.large.searchインスタンスを選択して、安全ネットと時間の経過とともに成長する余地があるようにすることができます。この設定は 6 vCPU コアと 24 GiB のメモリを提供するため、より軽量なワークロードに適しています。

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

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

ステップ 3: 代表的なテストを実行する

クラスターを設定したら、前に計算したシャードの数を使用してインデックスを追加し、リアルなデータセットを使用して代表的なクライアントテストを実行し、 CloudWatch メトリクスをモニタリングして、クラスターがワークロードをどのように処理するかを確認できます。

ステップ 4: 成功または反復する

パフォーマンスがニーズを満たし、テストが成功し、 CloudWatch メトリクスが正常であれば、クラスターはすぐに使用できます。リソースの異常な使用状況を検出する CloudWatch アラームを設定することを忘れないでください。

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

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

本番稼働用クラスターまたは複雑な状態のクラスターは、専用マネージャーノードの恩恵を受けるため、パフォーマンスとクラスターの信頼性が向上します。