Amazon Elasticsearch Service
開発者ガイド (API バージョン 2015-01-01)

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

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

ストレージ要件の計算

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

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

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

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

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

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

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

  2. Elasticsearch インデックス作成オーバーヘッド: ディスク上のインデックスのサイズは一定ではありませんが、多くの場合でソースデータよりも 10% 大きくなります。データのインデックスを作成したら、_cat/indices API と pri.store.size の値を使用して正確なオーバーヘッドを計算します。_cat/allocation API を使用すると、全体像を把握できて便利です。

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

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

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

    次の式では、オーバーヘッドが "最悪の場合" の予測を使用しています。これは、インスタンス当たりのストレージ容量が 100 GB 未満のドメインに対しては正確なもので、それよりも大きいインスタンスに対しては過剰割り当てとなります。

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

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

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

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

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

注記

最小ストレージ要件が 1 PB を超える場合は、「Amazon Elasticsearch Service におけるペタバイト規模」を参照してください。

シャード数の選択

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

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

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

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

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

注記

デフォルトでは、Elasticsearch のインデックスはプライマリシャード 5 つに分割されます。インデックスを作成する際には異なる設定を指定できます。

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

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

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

ヒント

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

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

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

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

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

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

  3. クラスターを構成したら、インデックスを追加できます。それから、実践的なデータセットと代表的なクライアントを使用したテストを実施して CloudWatch メトリクスを監視し、クラスターでのワークロード処理を確認します。

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

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

    容量不足のクラスターにおける不足量よりも、容量過多のクラスターにおける超過容量の方が簡単に測定できます。したがって、まずは想定するニーズよりも大規模なクラスターを用意し、テストを通じて、アクティビティが増加した期間中に安定したオペレーションが確保できる追加のリソースを備えた効果的なクラスターまでスケールダウンすることをお勧めします。

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