ストレージ要件の計算

ほとんどの OpenSearch ワークロードは、次の 2 つのカテゴリに大別できます。

• 長期存続インデックス: データを 1 つまたは複数の OpenSearch インデックスとして処理し、ソースデータの変更に伴ってそれらのインデックスを定期的に更新するコードを記述した場合。一般的な例としては、ウェブサイト、ドキュメント、e コマースの検索などがあります。

• ローリングインデックス: データは継続的に一時的なインデックスに受け渡され、インデックス作成時間や保持期間が指定されます (例: 2 週間保持される一連の日次のインデックス)。代表的な例は、ログ分析、時系列処理、クリックストリーム分析などです。

長期存続インデックスのワークロードの場合、使用されるストレージ容量はディスク上のソースデータを調べることで簡単に判断できます。データのソースが複数ある場合は、すべてのソースを単純に合計します。

ローリングインデックスについては、一般的な期間内に生成されるデータ量に保持期間を掛けます。たとえば、1 時間あたり 200 MiB のログデータが生成されるとすると、1 日で 4.7 GiB になります。この場合、保持期間が 2 週間であれば、いずれかの時点でデータは 66 GiB に達します。

ただし、ソースデータのサイズはストレージ要件の 1 つの要素に過ぎません。次の点についても考慮する必要があります。

• レプリカの数: 各レプリカはプライマリシャードの完全なコピーであり、インデックスのストアサイズはプライマリシャードとレプリカシャードによって取られたサイズを示します。デフォルトでは、各 OpenSearch インデックスに対してレプリカが 1 つ作成されます。データ損失を防ぐため、少なくとも 1 つは作成することをお勧めします。レプリカによって、検索パフォーマンスを改善することもできます。読み込みが多いワークロードが発生する場合は、より多くのレプリカがあるとよいでしょう。PUT /my-index/_settings を使用して、インデックスの number_of_replicas 設定を更新します。

• OpenSearch インデックス作成のオーバーヘッド: ディスク上のインデックスのサイズは一定ではありません。多くの場合、ソースデータとインデックスの合計サイズはソースの 110% で、インデックスはソースデータの 10% までです。データのインデックスを作成したら、_cat/indices?v API と pri.store.size 値を使用して正確なオーバーヘッドを計算できます。_cat/allocation?v も有用な要約を提供します。

• オペレーティングシステムの予約スペース: デフォルトでは、Linux は、重要なプロセス、システム復元、そしてディスクの断片化問題に対する保護目的で、root ユーザー用にファイルシステムの 5% を予約します。

• OpenSearch Service のオーバーヘッド: OpenSearch Service は、セグメントマージ、ログ、およびその他の内部オペレーション用として、インスタンスごとにストレージ容量の 20% (最大 20 GiB) を予約します。

  この 20 GiB の上限があるため、予約容量の合計はドメインに存在するインスタンスの数によって大きく異なります。たとえば、ドメインに 3 つの m6g.xlarge.search インスタンスがあり、それぞれのストレージ容量が 500 GiB であるとすると、合計は 1.46 TiB になります。この場合、予約される容量はわずか 60 GiB です。ドメインに 10 の m3.medium.search インスタンスがあり、それぞれのストレージ容量が 100 GiB の場合は、合計で 0.98 TiB になります。最初のドメインの方が 50% 大きいですが、後者の予約容量は合計 200 GiB です。

  次の式では、オーバーヘッドの「ワーストケース」の見積もりを適用します。この見積もりには、ノード障害やアベイラビリティーゾーンの停止による影響を最小限に抑えるのに役立つ追加の空き容量が含まれています。

つまり、任意の時点で 66 GiB のデータが存在し、レプリカを 1 つ必要とする場合、最小ストレージ要件は 66 * 2 * 1.1/0.95/0.8 = 191 GiB になります。この計算は、次のように定型化できます。

ソースデータ * (1 + レプリカ数) * (1 + インデックス作成オーバーヘッド) / (1 - Linux 予約スペース) / (1 - OpenSearch Service のオーバーヘッド) = 必要な最小ストレージ

あるいは、この簡素化されたバージョンを使用することもできます。

ソースデータ * (1 + レプリカの数) * 1.45 = 必要な最小ストレージ

ストレージ容量の不足は、クラスターが不安定になる最も一般的な原因の 1 つです。したがって、インスタンスタイプ、インスタンス数、およびストレージボリュームを選択するときは、数値をクロスチェックする必要があります。

ストレージに関するその他の考慮事項は次のとおりです。

• 最小ストレージ要件が 1 PB を超える場合は、「Amazon OpenSearch Service のペタバイトスケール」を参照してください。

• ローリングインデックスがあり、ホットウォームアーキテクチャを使用する場合は、「UltraWarm Amazon OpenSearch Service の ストレージ」を参照してください。