Amazon OpenSearch Service のペタバイトスケール

このサイズのドメインは、ドメインあたり 80 インスタンスというデフォルトの制限を超えています。ドメインあたり最大 1000 インスタンスのサービス制限の引き上げをリクエストするには、 AWS サポートセンター でケースを開きます。

このサイズのドメインを作成する前に、Amazon OpenSearch Service の料金ページをチェックして、関連するコストが期待値と一致することを確認します。ホットウォームアーキテクチャがユースケースに合っているかどうかを確認するために UltraWarm Amazon OpenSearch Service の ストレージ を調べます。

i3 インスタンスタイプは、高速でローカルの不揮発性メモリエクスプレス (NVMe) ストレージを提供するように設計されています。このローカルストレージは Amazon Elastic Block Store と比較してパフォーマンス上の利点を提供する傾向があるため、 OpenSearch Service でこれらのインスタンスタイプを選択した場合、EBSボリュームはオプションではありません。EBS ストレージを使用する場合は、 などの別のインスタンスタイプを使用しますr6.12xlarge.search。

一般的な OpenSearch ガイドラインは、シャードあたり 50 GB を超えないようにすることです。大きなドメインに対応するために必要なシャードの数および i3.16xlarge.search インスタンスが利用可能なリソースが指定されている場合は、シャードのサイズは 100 GB をお勧めします。

たとえば、450 TB のソースデータがあり、レプリカを 1 つにする場合、最小ストレージ要件は 450 TB * 2 * 1.1/0.95 = 1.04 PB です。この計算の説明については、「ストレージ要件の計算」を参照してください。1.04 PB/15 TB = 70 インスタンスですが、時間と共に変動するデータ量を考慮して、ストレージセーフティネットを提供し、ノードの障害を処理するために、90 個以上の i3.16xlarge.search インスタンスを選択することができます。各インスタンスにより最小ストレージ要件に 20 GiB が追加されますが、このサイズのディスクでは、この 20 GiB はほぼ無視できます。

シャードの数の制御はトリッキーです。 OpenSearch ユーザーは多くの場合、インデックスを毎日ローテーションし、1～2 週間データを保持します。このような状況では、「アクティブ」なシャードと「非アクティブ」なシャードを区別すると便利な場合があります。アクティブなシャードとは、書き込みや読み取りがアクティブに行われているシャードです。非アクティブなシャードとは、いくつかの読み取りリクエストがあるものの大部分はアイドルな状態のサービスです。一般的には、アクティブなシャードの数を数千個未満に維持する必要があります。アクティブなシャードの数が 10,000 に近づくと、パフォーマンスと安定性に大きなリスクが出現します。

プライマリシャードの数は次の式を使用して計算します。450,000 GB * 1.1/(100 GB/シャード) = 4,950 シャード。レプリカを考慮してこの数を 2 倍にすると 9,900 シャードになり、すべてのシャードがアクティブの場合は大きな懸念事項になります。ただし、インデックスをローテーションして、任意の指定日にシャードの数の 1/7 または 1/14 (それぞれ 1,414 または 707 シャード) のみがアクティブな場合、クラスターはうまく機能します。この場合も、ドメインのサイズ決定と設定において最も重要なステップは、現実的なデータセットを使用して代表的なクライアントテストを実行することです。