シャード数の選択

ストレージ要件を理解したら、インデックス作成の戦略を調査できます。 OpenSearch Service では、デフォルトで、各インデックスは 5 つのプライマリシャードと 1 つのレプリカ (合計 10 個のシャード) に分割されます。この動作は OpenSearch、デフォルトで 1 つのプライマリシャードと 1 つのレプリカシャードであるオープンソース とは異なります。既存のインデックスに対してプライマリシャードの数を簡単に変更することはできません。したがって、シャード数は最初のドキュメントでインデックスを作成する前に決定する必要があります。

シャード数を選択することの全体的な目標は、クラスター内のすべてのデータノード間でインデックスを均等に分散させることです。ただし、これらのシャードは大きすぎたり多すぎたりしてはいけません。一般的なガイドラインとして、検索レイテンシーが主要なパフォーマンス目標であるワークロードではシャードのサイズを 10～30 GiB、ログ分析などの書き込みが多いワークロードでは 30～50 GiB の範囲に維持することをお勧めします。

シャードが大きいと、障害から復旧 OpenSearch するのが難しくなりますが、各シャードはある程度の CPUとメモリを使用するため、シャードが多すぎるとパフォーマンスの問題やメモリ不足エラーが発生する可能性があります。つまり、シャードは、基盤となる OpenSearch Service インスタンスが処理できるほど小さくする必要がありますが、ハードウェアに不要な負担をかけるほど小さくはなりません。

たとえば、66 GiB のデータがあるとします。その数値は今後も増加する予定がなく、各シャードのサイズは約 30 GiB を維持する必要があります。この場合、シャード数は約 3 つとなります (66 * 1.1/30 = 3)。この計算は、次のように定型化できます。

(ソースデータ + 拡張の余地) * (1 + インデックス作成オーバーヘッド) / 必要なシャードサイズ = プライマリシャードの概数

この式は、時間の経過に伴うデータ拡張にも対応できます。同じ 66 GiB のデータが来年は 4 倍になると想定される場合、シャード数はおよそ (66 + 198) * 1.1/30 = 10 となります。ただし、追加分の 198 GiB のデータは現時点では存在しません。この将来の準備により、現在大量の CPUとメモリを消費する不要な小さなシャードが発生しないことを確認してください。この場合、シャード当たりのサイズは 66 * 1.1/10 シャード = 7.26 GiB となります。これは余分なリソースを消費する場合があり、推奨サイズ範囲を下回ります。6 つのシャードのアプローチをより多く middle-of-the-road検討すると、現在は 12-GiB シャード、将来は 48-GiB シャードになります。その後、シャードが 50 GiB を超えたときには、3 つのシャードを使用してデータのインデックスを再作成することもできます。

かなりまれな問題の場合、ノードあたりのシャード数を制限する必要があります。シャードのサイズを適切に設定した場合、通常はこの制限に達するかなり前にディスク容量が不足します。たとえば、m6g.large.search インスタンスの最大ディスクサイズは 512 GiB です。ディスク使用率が 80% 未満に維持されており、シャードのサイズを 20 GiB に設定した場合、約 20 個のシャードを収容できます。Elasticsearch 7.x 以降、および のすべてのバージョンでは OpenSearch、ノードあたり 1,000 シャードに制限があります。ノードあたりの最大シャードを調整するには、cluster.max_shards_per_node 設定を設定してください。例については、「Cluster settings」(クラスターの設定) を参照してください。

シャードのサイズを適切に設定すると、ほとんどの場合この制限未満に維持できますが、Java ヒープの GiB ごとにシャードの数を検討することもできます。ノードごとに、Java ヒープの GiB あたりのシャード数を 25 以下にしてください。例えば、m5.large.search インスタンスに 4 GiB のヒープがあるとすると、各ノードのシャード数は 100 以下にすることになります。そのシャード数では、各シャードのサイズが約 5 GiB になり、推奨値をかなり下回ります。