翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon OpenSearch Service ドメインのサイジング
Amazon OpenSearch Service ドメインのサイズを決定するための完璧な方法はありません。ただし、ストレージのニーズ、サービス、および OpenSearch 自体を理解することから始めることで、ハードウェアのニーズに関する、情報に基づいた初期予測を行うことができます。ドメインのサイジングに取りかかる際の最も重要な検討材料として、そうした予測結果を代表的なワークロードを使用したテストに活用し、パフォーマンスを監視します。
**Topics**
+ [ストレージ要件の計算](bp-storage.md)
+ [シャード数の選択](bp-sharding.md)
+ [インスタンスタイプとテストの選択](bp-instances.md)
# ストレージ要件の計算
ほとんどの 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 \$1 2 \$1 1.1/0.95/0.8 = 191 GiB になります。この計算は、次のように定型化できます。
**ソースデータ \$1 (1 \$1 レプリカ数) \$1 (1 \$1 インデックス作成オーバーヘッド) / (1 - Linux 予約スペース) / (1 - OpenSearch Service のオーバーヘッド) = 必要な最小ストレージ**
あるいは、この簡素化されたバージョンを使用することもできます。
**ソースデータ \$1 (1 \$1 レプリカの数) \$1 1.45 = 必要な最小ストレージ**
ストレージ容量の不足は、クラスターが不安定になる最も一般的な原因の 1 つです。したがって、[インスタンスタイプ、インスタンス数、およびストレージボリュームを選択](bp-instances.md)するときは、数値をクロスチェックする必要があります。
ストレージに関するその他の考慮事項は次のとおりです。
+ 最小ストレージ要件が 1 PB を超える場合は、「[Amazon OpenSearch Service 用ペタバイトスケール](petabyte-scale.md)」を参照してください。
+ ローリングインデックスがあり、ホットウォームアーキテクチャを使用する場合は、「[Amazon OpenSearch Service の UltraWarm ストレージ](ultrawarm.md)」を参照してください。
# シャード数の選択
ストレージ要件を理解したら、インデックス作成の戦略を調査できます。OpenSearch Service のデフォルトでは、各インデックスは 5 つのプライマリシャードと 1 つのレプリカ (合計 10 個のシャード) に分割されます。この動作は、デフォルトで 1 つのプライマリシャードと 1 つのレプリカシャードに分割するオープンソースの OpenSearch とは異なります。既存のインデックスに対してプライマリシャードの数を簡単に変更することはできません。したがって、シャード数は最初のドキュメントでインデックスを作成する*前に*決定する必要があります。
シャード数を選択することの全体的な目標は、クラスター内のすべてのデータノード間でインデックスを均等に分散させることです。ただし、これらのシャードは大きすぎたり多すぎたりしてはいけません。一般的なガイドラインとして、検索レイテンシーが主要なパフォーマンス目標であるワークロードではシャードのサイズを 10～30 GiB、ログ分析などの書き込みが多いワークロードでは 30～50 GiB の範囲に維持することをお勧めします。
シャードが大きいと、OpenSearch の障害復旧が困難になる可能性があります。一方、各シャードはある程度の CPU とメモリを使用するため、小規模なシャードが多数ある場合には、パフォーマンスの問題やメモリ不足のエラーが発生する可能性があります。つまり、基盤となる OpenSearch Service のインスタンスで問題なく処理できるようにシャードは小さくする必要がありますが、小さすぎるとハードウェアに不必要な負荷をかけてしまうということです。
たとえば、66 GiB のデータがあるとします。その数値は今後も増加する予定がなく、各シャードのサイズは約 30 GiB を維持する必要があります。この場合、シャード数は約 3 つとなります (66 \$1 1.1/30 = 3)。この計算は、次のように定型化できます。
**(ソースデータ \$1 拡張の余地) \$1 (1 \$1 インデックス作成オーバーヘッド) / 必要なシャードサイズ = プライマリシャードの概数**
この式は、時間の経過に伴うデータ拡張にも対応できます。同じ 66 GiB のデータが来年は 4 倍になると想定される場合、シャード数はおよそ (66 \$1 198) \$1 1.1/30 = 10 となります。ただし、追加分の 198 GiB のデータは*現時点では*存在しません。将来に向けてのこのような準備として不必要な小さいシャードを作成し、現時点で CPU とメモリを大量に消費することがないようにしてください。この場合、シャード当たりのサイズは 66 \$1 1.1/10 シャード = 7.26 GiB となります。これは余分なリソースを消費する場合があり、推奨サイズ範囲を下回ります。中間をとったアプローチとしてシャード数を 6 つにすると、シャードのサイズは現時点で 12 GiB、将来的には 48 GiB となります。その後、シャードが 50 GiB を超えたときには、3 つのシャードを使用してデータのインデックスを再作成することもできます。
かなりまれな問題の場合、ノードあたりのシャード数を制限する必要があります。シャードのサイズを適切に設定した場合、通常はこの制限に達するかなり前にディスク容量が不足します。たとえば、`m6g.large.search` インスタンスの最大ディスクサイズは 512 GiB です。ディスク使用率が 80% 未満に維持されており、シャードのサイズを 20 GiB に設定した場合、約 20 個のシャードを収容できます。Elasticsearch 7. *以降*、および OpenSearch 2.15 までのすべてのバージョンには、1 ノードあたり *1,000* シャードの制限があります。ノードあたりの最大シャードを調整するには、`cluster.max_shards_per_node` 設定を設定してください。OpenSearch 2.17 以降では、OpenSearch Service は JVM ヒープメモリ 16 GB 当り 1,000 シャード、最大 1 ノード当り 4,000 シャードをサポートします。例については、「[Cluster settings](https://opensearch.org/docs/latest/opensearch/rest-api/cluster-settings/#request-body)」(クラスターの設定) を参照してください。シャード数の詳細については、「[シャード数のクォータ](limits.md#shard-count)」を参照してください。
シャードのサイズを適切に設定すると、ほとんどの場合この制限未満に維持できますが、Java ヒープの GiB ごとにシャードの数を検討することもできます。ノードごとに、Java ヒープの GiB あたりのシャード数を 25 以下にしてください。例えば、`m5.large.search` インスタンスに 4 GiB のヒープがあるとすると、各ノードのシャード数は 100 以下にすることになります。そのシャード数では、各シャードのサイズが約 5 GiB になり、推奨値をかなり下回ります。
# インスタンスタイプとテストの選択
ストレージ要件を計算して必要なシャード数を選択したら、ハードウェアに関する決定ができるようになります。ハードウェア要件はワークロードによって大きく異なるものの、基本的な推奨事項は提供されています。
各インスタンスタイプの[ストレージ制限](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: 初期見積もりを作成する
開始の際に、*スプリットブレイン*の状態 (コミュニケーションでの時間の経過により、クラスターが 2 つのマスターノードを持つようになる) などの潜在的な OpenSearch の問題を防ぐために、3 つ以上のノード数を選択することをお勧めします。[専用マスターノードが 3 つの場合は](managedomains-dedicatedmasternodes.md)、レプリケーション用のデータノードは少なくとも 2 つにすることをお勧めします。
## ステップ 2: ノードごとのストレージ要件を計算する
ストレージ要件が 184 GiB で、推奨最小数である 3 つのノードがある場合、各ノードで必要とするストレージの容量は 184/3 = 61 GiB という計算になります。この例では、3 つの `m6g.large.search` インスタンスを選択してそれぞれで 90 GiB の EBS ストレージボリュームを使用すれば、安全策として時間の経過に伴う拡張にも備えることができます。この構成では 6 つの vCPU コアと 24 GiB のメモリを利用でき、軽度のワークロードに適しています。
より大規模な例として、ストレージ要件が 14 TiB (14,336 GiB) で高い負荷が発生する状況を想定します。この場合、まずは 2 \$1 144 = 288 の vCPU コアと 8 \$1 144 = 1,152 GiB のメモリを使用したテストが考えられます。これらの数値は、約 18 `i3.4xlarge.search` インスタンスを使用する結果となります。高速なローカルストレージが必要ない場合、それぞれが 1 TiB の EBS ストレージボリュームを使用する 18 個の `r6g.4xlarge.search` インスタンスをテストすることもできます。
クラスターに数百テラバイトのデータが含まれる場合は、「[Amazon OpenSearch Service 用ペタバイトスケール](petabyte-scale.md)」を参照してください。
## ステップ 3: 代表的なテストを実行する
クラスターを設定したら、先ほど計算したシャードの数を使用して[インデックスを追加](indexing.md)し、実践的なデータセットを使用して代表的なクライアントテストを実行し、[CloudWatch メトリクスのモニタリング](managedomains-cloudwatchmetrics.md)によりクラスターでのワークロードの処理状況を確認できます。
## ステップ 4: 成功または反復する
パフォーマンスがニーズを満たすものであれば、テストは成功し、CloudWatch メトリクスは正常であり、クラスターは使用する準備ができたことになります。リソースの異常な使用状況を検出するために、必ず [CloudWatch アラームを設定](cloudwatch-alarms.md)してください。
パフォーマンスが許容できないものであれば、テストが失敗したか、または `CPUUtilization` か `JVMMemoryPressure` が高いことになります。別のインスタンスタイプを選択 (またはインスタンスを追加) して、テストを続行する必要があるかもしれません。インスタンスを追加すると、OpenSearch はクラスター全体にわたってシャードを自動的に再分散します。
過負荷クラスターの過剰容量は、負荷の低いクラスターの不足よりも簡単に測定できるため、必要以上に大きなクラスターから開始することをお勧めします。次に、追加のリソースを持つ効率的なクラスターにテストおよびスケールダウンして、アクティビティの増加期間中に安定した運用を確保します。
本番稼働用クラスター (1 つまたは複数) では複雑なステータスが発生しますが、[専用マスターノード](managedomains-dedicatedmasternodes.md)を活用することでパフォーマンスとクラスターの信頼性を向上させることができます。