Amazon ES ドメインのサイジング - Amazon Elasticsearch Service

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

Amazon ES ドメインのサイジング

Amazon ES ドメインを確実にサイジングする方法として絶対的なものはありませんが、ストレージ要件やサービス、Elasticsearch の内容を理解することで、ハードウェアに対するニーズを正しい知識に基づいて予測できます。ドメインのサイジングに取りかかる際の最も重要な検討材料として、そうした予測結果を代表的なワークロードを使用したテストに活用し、パフォーマンスを監視します。

ストレージ要件の計算

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

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

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

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

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

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

  1. レプリカの数: 各レプリカはインデックスのフルコピーであり、同量のディスク容量が必要です。デフォルトでは、各 Elasticsearch インデックスに対してレプリカが 1 つ作成されます。データ損失を防ぐため、少なくとも 1 つは作成することをお勧めします。レプリカによって、検索パフォーマンスを改善することもできます。読み込みが多いワークロードが発生する場合は、より多くのレプリカがあるとよいでしょう。

  2. Elasticsearch インデックス作成オーバーヘッド: ディスク上のインデックスのサイズはさまざまですが、多くの場合、ソースデータよりも 10% 大きくなります。データのインデックスを作成したら、_cat/indices?v API と pri.store.size の値を使用して正確なオーバーヘッドを計算します。_cat/allocation?v は便利な概要も提供します。

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

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

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

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

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

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

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

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

ストレージの容量不足は、クラスターが不安定になる最も一般的な原因の 1 つです。インスタンスタイプ、インスタンスの数、ストレージボリュームを選択するときは、それらの数を照合して確認するようにしてください。

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

シャード数の選択

ストレージ要件を理解したら、インデックス作成の戦略を調査できます。各 Elasticsearch インデックスは、いくつかのシャードに分割されます。既存のインデックスに対してプライマリシャードの数を簡単に変更することはできません。したがって、シャード数は最初のドキュメントでインデックスを作成する前に決定する必要があります。

シャード数を選択する最終的なねらいは、クラスター内のすべてのデータノード間でインデックスを均等に分散させることです。ただし、これらのシャードは大きすぎたり多すぎたりしてはいけません。シャードのサイズは 10 – 50 GiB にすると良いようです。 シャードが大きいと、Elasticsearch が障害から復旧することが困難になる可能性があります。ただし、各シャードがある程度の CPU とメモリを使用するため、小規模なシャードが多数ある場合には、パフォーマンスの問題やメモリ不足のエラーが発生する可能性があります。つまり、基盤となる Amazon ES インスタンスで問題なく処理できるようにシャードは小さくする必要がありますが、小さすぎるとハードウェアに不必要な負荷をかけてしまうということです。

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

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

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

かなりまれな問題の場合、ノードあたりのシャード数を制限する必要があります。シャードのサイズを適切に設定した場合、通常はこの制限に達するかなり前にディスク容量が不足します。たとえば、m5.large.elasticsearch インスタンスの最大ディスクサイズは 512 GiB です。 ディスク使用率が 80% 未満に維持されており、シャードのサイズを 20 GiB に設定した場合、約 20 個のシャードを収容できます。Elasticsearch 7.x 以降には、ノードあたり 1,000 個というシャードの制限があり、cluster.max_shards_per_node 設定を使用して調整できます。

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

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

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

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

ヒント

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

ただし、上記に記載されたリソースでも不十分になる場合があります。一部の Elasticsearch ユーザーからは、要件を満たすためにこれらのリソースが重ねて必要になるという報告を受けています。ワークロードに最適なハードウェアを特定するには、知識に基づく初期予測、代表的なワークロードを使用したテスト、調整、そして再テストが必要になります。

  1. まず、スプレッドブレインなどの潜在的な Elasticsearch の問題を防ぐため、ノード数は 3 つ以上を選択することをお勧めします。専用マスターノードが 3 つの場合は、レプリケーション用のデータノードは少なくとも 2 つにすることをお勧めします。

  2. ストレージ要件が 184 で、推奨最小数である 3 つのノードがある場合、各ノードで必要とするストレージの容量は 184/3 = 61 GiB という計算になります。GiBこの例では、3 つの m5.large.elasticsearch インスタンスを選択してそれぞれで 90 個の GiB EBS ストレージボリュームを使用すれば、安全策として時間の経過に伴う拡張にも備えることができます。この構成では 6 つの vCPU コアと 24 個の GiB のメモリを利用でき、軽度のワークロードに適しています。

    より大規模な例として、ストレージ要件が 14 TiB (14,336 GiB) で高い負荷が発生する状況を想定します。この場合、まずは 2 * 144 = 288 の vCPU コアと 8 * 144 = 1,152 GiB のメモリを使用したテストが考えられます。これらの数値は、約 18 i3.4xlarge.elasticsearch インスタンスを使用する結果となります。高速なローカルストレージが必要ない場合、それぞれが 1 つの r5.4xlarge.elasticsearch EBS ストレージボリュームを使用する 18 個の TiB インスタンスをテストすることもできます。

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

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

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

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

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

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