Amazon OpenSearch Service ドメインのサイズ設定 - Amazon OpenSearch サービス
ストレージ要件の計算シャード数の選択インスタンスタイプとテストの選択

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

Amazon OpenSearch Service ドメインのサイズ設定

Amazon OpenSearch Service ドメインのサイジングには完全な方法はありません。ただし、ストレージのニーズ、サービス、および OpenSearch それ自体を理解することから始めることで、ハードウェアのニーズを教育的に推定できます。ドメインのサイジングに取りかかる際の最も重要な検討材料として、そうした予測結果を代表的なワークロードを使用したテストに活用し、パフォーマンスを監視します。

ストレージ要件の計算

ほとんどの 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 サービスオーバーヘッド: OpenSearch サービスは、セグメントマージ、ログ、その他の内部オペレーションのために、各インスタンスのストレージ領域の 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 サービスオーバーヘッド) = 最小ストレージ要件

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

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

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

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

シャード数の選択

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

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

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

たとえば、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 になり、推奨値をかなり下回ります。

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

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

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

ヒント

各インスタンスタイプに割り当てられるハードウェアリソースの概要については、「Amazon OpenSearch サービスの料金」を参照してください。

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

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

開始するには、スプリットブレイン状態 (通信の時間が経過するとクラスターに 2 つのマスターノードが発生する) などの潜在的な OpenSearch問題を避けるため、少なくとも 3 つのノードを使用することをお勧めします。専用マスターノードが 3 つの場合は、レプリケーション用のデータノードは少なくとも 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 * 144 = 288 の vCPU コアと 8 * 144 = 1,152 GiB のメモリを使用したテストが考えられます。これらの数値は、約 18 i3.4xlarge.search インスタンスを使用する結果となります。高速なローカルストレージが必要ない場合、それぞれが 1 TiB の EBS ストレージボリュームを使用する 18 個の r6g.4xlarge.search インスタンスをテストすることもできます。

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

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

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

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

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

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

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

本番稼働用クラスター (1 つまたは複数) では複雑なステータスが発生しますが、専用マスターノードを活用することでパフォーマンスとクラスターの信頼性を向上させることができます。