Elasticsearch:ノード仕様とストレージ容量の評価

注意事項

本トピックで提供する評価方法は、実際のテスト結果とユーザーの経験に基づいています。ユーザーごとに、データ構造、クエリの複雑さ、データ量、パフォーマンス、データ変更に対する要件は異なります。本トピックは参考情報としてご利用ください。実データと業務シナリオに基づいて、Elasticsearch クラスターの仕様とストレージ容量を評価することを推奨します。

ストレージ容量の評価

Elasticsearch クラスターのストレージ容量は、次の要因によって決まります。

• ソースデータの容量。

• レプリカシャード数：各プライマリシャードには、少なくとも 1 つのレプリカシャードが必要です。

• インデックス作成のオーバーヘッド：ほとんどの場合、インデックス作成によってソースデータ量の 10% に相当するオーバーヘッドが追加されます。

  たとえば、例外分析に X-Pack が使用する監視インデックスでは、インデックス作成のオーバーヘッドが発生します。監視インデックスには次の種類があります。

  • .monitoring-es-6-*：この種類のインデックスは大量のストレージ容量を消費します。デフォルトでは、Elasticsearch は直近 7 日間に作成されたインデックスデータのみを保持します。

  • .monitoring-kibana-6-*：この種類のインデックスが消費するストレージ容量は、インデックス数に応じて増加します。デフォルトでは、Elasticsearch は直近 7 日間に作成されたインデックスデータのみを保持します。

  • .watcher-history-3-*：この種類のインデックスが消費するストレージ容量は少量です。不要になった場合は、手動でインデックスを削除できます。

• Elasticsearch クラスターの内部オーバーヘッド：セグメントマージやログ記録などの内部処理によってもオーバーヘッドが発生します。このオーバーヘッドとして、ストレージ容量の 20% を予約します。

  クラスターログが消費するストレージ容量は、Elasticsearch クラスターが受信するクエリ数とデータプッシュ数に応じて増加します。クラスターログには、実行ログ、アクセスログ、スローログが含まれます。デフォルトでは、Elasticsearch は直近 7 日間に生成されたログのみを保持します。この期間は変更できません。

• オペレーティングシステムが予約するストレージ容量：デフォルトでは、オペレーティングシステムは重要なプロセス、システムリカバリー、ディスクの断片化のためにストレージ容量の 5% を予約します。

• セキュリティしきい値のオーバーヘッド：Elasticsearch はセキュリティしきい値として、ストレージ容量の少なくとも 15% を予約します。

推奨ストレージ容量は、次の式で計算します。

クラスターの推奨ストレージ容量 = ソースデータの容量 × (1 + レプリカシャード数) × インデックス作成のオーバーヘッド/(1 - OSが予約するストレージ容量)/(1 - クラスター内部オーバーヘッド)/(1 - セキュリティしきい値のオーバーヘッド)
             = ソースデータの容量 × (1 + レプリカシャード数) × 1.7
             = ソースデータの容量 × 3.4

シャード設定のうち、上記の式の結果に影響するのはレプリカシャード数のみです。プライマリシャードを追加してもディスク使用量は増加しません。既存データがより多くのシャードに再分散されるだけで、総データ量は変わらないためです。一方、レプリカシャードを追加すると、各レプリカシャードがデータの完全なコピーを保持するため、レプリカ数に比例してディスク使用量が増加します。これは、式の係数 (1 + レプリカシャード数) に対応します。そのため、単一シャードが大きくなりすぎた場合は、レプリカシャードを追加するのではなく、プライマリシャード数を増やすことを推奨します。プライマリシャード数を増やすには、_split API を使用してインデックスを分割するか、データを再インデックスします。

ノード仕様とノード数の評価

データノード

• クラスターあたりの最大ノード数 = ノードあたりの vCPU 数 × 5。

• Elasticsearch クラスターの各ノードが格納できる最大データ容量は、業務シナリオによって異なります。

  • 一般的なシナリオ：ノードあたりの最大ストレージ容量 = ノードあたりのメモリサイズ (GiB) × 30。

  • データクエリの高速化や集計などのクエリシナリオ：ノードあたりの最大ストレージ容量 = ノードあたりのメモリサイズ (GiB) × 10。

  • ログデータの取り込みやオフライン分析などのログシナリオ：ノードあたりの最大ストレージ容量 = ノードあたりのメモリサイズ (GiB) × 50。

次の表に、ノード仕様別の最大ノード数とノードあたりの最大ストレージ容量を示します。

Elasticsearch クラスターの総ストレージ容量は、次の式で計算します：Elasticsearchクラスターの総ストレージ容量 = ノードあたりのストレージ容量 × ノード数。ノードあたりの最大ストレージ容量と最大ノード数に基づいて、各ノードの仕様を決定できます。

• データ容量が小さい一方でディスク I/O の負荷が高い場合は、ストレージ容量だけではなく I/O 性能に基づいて仕様を評価してください。典型例として、約 1,000 万件の短いドキュメントを含み、総容量が約 3 GB で、主に完全一致、前方一致、または集計でクエリされるインデックスが挙げられます。このケースでは、ストレージ容量がボトルネックではなく、vCPU とメモリの要件も中程度です。しかし、各クエリが多数のタームとセグメントに触れるため、ディスクに対するランダムリードが頻繁に発生します。そのため、達成可能なクエリレイテンシはディスク I/O によって決まります。次の 2 項目を併せて評価することを推奨します。

  • ノード仕様：vCPU とメモリの比率が 1:2 の仕様を選択し、各データノードに少なくとも 4 vCPU と 16 GiB のメモリを使用します。4 vCPU と 16 GiB のメモリを備えたノードは、クエリシナリオで最大 160 GiB のデータをサポートできるため、この規模のデータ容量に対して十分な余裕があります。これより低い仕様では、インデックス用のページキャッシュがほとんど確保できず、クラスターがより多くのデータをディスクから読み取るようになります。

  • ストレージ：クラスターを購入する場合、またはクラスターの構成をアップグレードする場合は、[Storage Type] を [Standard SSD] に設定します。Standard SSD は IOPS が高く応答時間も短いため、オンライン分析と検索に適しています。ノードが到達できる IOPS とスループットは、プライマリシャード数ではなく、ストレージタイプとノード仕様によって決まります。この規模のインデックスにプライマリシャードを追加しても、利用可能な I/O 性能は向上しません。

専用マスターノード

Elasticsearch クラスターに多数のデータノードが含まれる場合は、クラスターの安定性を確保するために専用マスターノードを有効化することを推奨します。

Elasticsearch クラスターの専用マスターノードの仕様は、次のガイダンスを参考に決定できます。

• デフォルト仕様：2 vCPU、8 GiB メモリ

• データノード数が 10 を超える場合の仕様：4 vCPU、16 GiB メモリ

• データノード数が 30 を超える場合の仕様：8 vCPU、32 GiB メモリ

• データノード数が 50 を超える場合の仕様：16 vCPU、64 GiB メモリ

クライアントノード

独立したクライアントノードは、集計クエリの結果に対して reduce 操作を実行します。この場合、reduce 段階で深刻なガベージコレクション (GC) が発生しても、データノードには影響しません。

クライアントノードを有効化する場合は、クライアントノードとデータノードを 1:5 の比率で構成し、クライアントノードには vCPU とメモリの比率が 1:4 または 1:8 の仕様を選択することを推奨します。クライアントノードは少なくとも 2 台購入する必要があります。たとえば、8 vCPU と 32 GiB メモリのデータノードを 10 台構成する場合は、8 vCPU と 32 GiB メモリのクライアントノードを 2 台構成することを推奨します。

シャードの評価

シャード数と各シャードのサイズは、Elasticsearch クラスターの安定性とパフォーマンスに影響します。Elasticsearch クラスター内のすべてのインデックスに対して、シャードを適切に計画する必要があります。これにより、多数のシャードがクラスターのパフォーマンスに影響することや、複雑な業務シナリオで負荷が不均一になることを防げます。たとえば、Elasticsearch クラスター内のインデックスに対するシャード計画が不適切な場合、ノードのディスク使用量に大きな差が生じたり、ノード間の CPU 負荷が不均一になったりする可能性があります。

Alibaba Cloud は、シャード計画のために次のガイドラインを提供しています。これらのガイドラインは参考情報としてご利用ください。

• 各シャードに格納するデータ容量

  • 各シャードに格納するデータ容量は 30 GiB 以下にすることを推奨します。特別なケースでは、各シャードに格納するデータ容量を 50 GiB 以下にできます。

  • ログ分析シナリオや、極めて大きなインデックスが必要なシナリオでは、各シャードに格納するデータ容量が 100 GiB を超えないようにしてください。

• シャード数

  • Elasticsearch クラスターにシャードを割り当てる前に、格納するデータ容量を評価することを推奨します。

    • 総データ容量が大きい場合は、Elasticsearch クラスターのワークロードを軽減するために書き込みデータ量を減らす必要があります。この場合は、各インデックスに複数のプライマリシャードを構成し、各プライマリシャードに 1 つのレプリカシャードを構成することを推奨します。

    • 総データ容量と書き込みデータ量の両方が小さい場合は、各インデックスに 1 つのプライマリシャードを構成し、各プライマリシャードに 1 つ以上のレプリカシャードを構成することを推奨します。

    説明

    • デフォルトでは、V7.X 以降の Elasticsearch クラスターは、各インデックスに 1 つのプライマリシャードと、各プライマリシャードに 1 つのレプリカシャードが構成されています。V7.X より前の Elasticsearch クラスターは、デフォルトで各インデックスに 5 つのプライマリシャードと、各プライマリシャードに 1 つのレプリカシャードが構成されています。

    • 格納するデータ容量が 30 GiB 未満の場合は、各インデックスに 1 つのプライマリシャードを構成し、プライマリシャードに複数のレプリカシャードを構成できます。これにより負荷分散を実現できます。たとえば、各インデックスのサイズが 20 GiB で、Elasticsearch クラスターに 5 台のデータノードがある場合、各インデックスに 1 つのプライマリシャードと、各プライマリシャードに 4 つのレプリカシャードを構成できます。

  • シャード数は、データノード数と同じ、またはデータノード数の整数倍にすることを推奨します。

  • 1 ノードあたり、1 つのインデックスに対するシャード数は最大 5 つにすることを推奨します。

  • 単一ノードあたりのシャード総数は、次のいずれかの式で計算することを推奨します。

    • 小規模仕様のクラスターの場合：データノードあたりのシャード数 = データノードのメモリサイズ × 30

    • 大規模仕様のクラスターの場合：データノードあたりのシャード数 = データノードのメモリサイズ × 50

    説明

    • シャード数を計算する際は、データ容量も考慮する必要があります。データ容量が 1 TiB 未満の場合は、小規模仕様のクラスター用の式でシャード数を計算することを推奨します。

    • デフォルトでは、Elasticsearch V7.X クラスターの単一ノードあたりの最大シャード数は 1,000 です。この最大数は変更しないことを推奨します。単一ノードあたりのシャード数を変更する場合は、クラスターを使用する前にノード数を増やすことができます。

    • 業務要件に基づいてシャードを構成することを推奨します。プライマリシャード数が多いほど、パフォーマンスのオーバーヘッドが増加します。Elasticsearch クラスター内の各インデックスに過剰なシャード数を構成すると、ファイルハンドルが枯渇する可能性があります。その結果、Elasticsearch クラスターで障害が発生する可能性があります。

上記のガイドラインは単一インデックスに適用されます。クラスターに複数の業務インデックスが格納されている場合、インデックスごとにデータ容量と増加率が異なるため、すべてのインデックスに同一の値を適用するのではなく、インデックスごとにプライマリシャード数を個別に計画してください。各インデックスについて、次の手順を実行します。

1. インデックスを計画するための情報を収集します。GET _cat/indices?v&bytes=b コマンドを実行して各インデックスの現在のストレージサイズを取得し、日次増分と保持期間を見積もって、保持期間終了時点の想定データ容量を算出します。クラスター内のデータノード数、データノードあたりのメモリサイズ、インデックスで使用するレプリカシャード数を記録します。

2. シャードあたりのストレージサイズに基づいて、プライマリシャード数のベースラインを計算します。インデックスの想定データ容量を 30 GiB で割り、結果を切り上げます。特別なケースでは、除数として 50 GiB を使用できます。ログ分析シナリオや、極めて大きなインデックスが必要なシナリオでは、100 GiB を使用できます。インデックスの想定データ容量が 30 GiB 未満のままである場合は、インデックスのプライマリシャードを 1 つに維持し、代わりにレプリカシャードを追加して、インデックスへのクエリがノード間に分散されるようにします。

3. シャード数をデータノード数に合わせます。式 プライマリシャード数 × (1 + レプリカシャード数) で計算されるインデックスの総シャード数が、データノード数と同じ、またはデータノード数の整数倍になるようにベースライン値を調整します。将来の増加に備えて余地を確保できるため、切り捨てではなく切り上げを推奨します。

4. ノードあたりの上限値と照らし合わせて結果を検証します。各ノードは、同一インデックスのシャードを 5 つ以下にする必要があります。1 つのデータノード上のすべてのインデックスの総シャード数は、クラスター仕様に応じた式で計算される値を超えてはなりません。小規模仕様のクラスターの場合は「データノードのメモリサイズ × 30」、大規模仕様のクラスターの場合は「データノードのメモリサイズ × 50」です。V7.X のクラスターの場合は、単一ノードあたりのシャード数を 1,000 未満に維持してください。すべてのインデックスで計画したシャード数の合計がこれらの上限を超える場合は、データ容量が最も少ないインデックスのシャード数を減らす、時間で分割されているがほとんどクエリされないインデックスをマージする、またはデータノードを追加します。

例：あるインデックスが保持期間終了時点で 300 GiB のデータを格納する見込みで、クラスターに 6 台のデータノードがあり、インデックスが 1 つのレプリカシャードを使用しているとします。プライマリシャード数のベースラインは 300 GiB / 30 GiB = 10 です。総シャード数を 6 の整数倍にするため、プライマリシャード数を 12 に増やします。これにより、インデックスの総シャード数は 24 となり、各シャードには約 25 GiB のデータが格納され、各データノードにはこのインデックスのシャードが 4 つ格納されます。3 つのガイドラインをすべて満たしています。

すべてのインデックスに対する計算が完了したら、計画を適用します。プライマリシャード数はインデックス作成時にのみ指定できます。すでに存在し、シャードが大きすぎるインデックスの場合は、_split API を使用してインデックスを分割するか、データを再インデックスします。また、インデックステンプレートを使用して、後から作成されるインデックスに計画値を適用します。

計画の適用後も、ノード間でディスク使用量や CPU 使用率に大きな差がある場合は、1 つ以上の大きなインデックスのシャードが少数のノードに集中したままです。不均衡の原因となっているインデックスとノードを特定し、Unbalanced loads on a cluster に基づいてシャードを再分散できます。

シャードの評価の詳細については、「How to size your shards」をご参照ください。

関連ドキュメント

• リージョンやバージョンごとにサポートされるノード仕様を確認するには、または Elasticsearch クラスターを購入するには、購入ページをご参照ください。

• 異なる仕様および異なるバージョンの Elasticsearch クラスターに対するストレステスト結果を参照すると、ノード仕様ごとのパフォーマンスを確認できます。詳細については、「Performance」ディレクトリ内のトピックをご参照ください。

• Standard Edition と Kernel-enhanced Edition のクラスタータイプの違い、および各クラスターバージョンの機能変更については、「Version features」をご参照ください。

• 評価結果に基づき、既存の Elasticsearch クラスターのノード仕様、ノードあたりのストレージ容量、ノード数などを調整できます。操作方法と関連する注意事項については、「Upgrade cluster configuration」および「Downgrade a cluster」をご参照ください。

• インデックスのプライマリシャード数は、インデックス作成時にのみ指定できます。インデックス作成後は、この数を変更できません。インデックスの作成方法については、「Create an index」をご参照ください。

• 既存インデックスで、各シャードに格納されるデータ容量が推奨値を超える場合は、そのインデックスのデータを再インデックスすることを推奨します。詳細については、「Use the reindex API to migrate data between Alibaba Cloud Elasticsearch clusters」をご参照ください。

  説明

  データの再インデックスによりサービスの継続性を確保できますが、時間がかかります。

• Elasticsearch クラスターの負荷不均衡の解決方法については、「Unbalanced loads on a cluster」をご参照ください。

• ノード上でホットデータの分散が不均一になる問題の解決方法については、「Uneven distribution of hot data on nodes」をご参照ください。

• Auto Indexing 機能を有効化する場合は、インデックスライフサイクル管理 (ILM) 機能または Elasticsearch API スクリプトを使用して期限切れのインデックスを削除することを推奨します。ILM 機能の詳細については、「Manage Heartbeat data with ILM」をご参照ください。

• ヒープメモリを解放するために、小さなインデックスは適時削除することを推奨します。

インデックスのストレージサイズに差が生じる理由

ストレージサイズはインデックス間で大きく異なる場合があります。以下では、差が生じる一般的な理由とトラブルシューティング方法について説明します。

• アナライザ設定の違い：ngram アナライザはテキストを多数の小さな文字の組み合わせに分割するため、standard アナライザよりも大幅に多くのトークンを生成します。その結果、転置インデックスが大きくなります。たとえば、同一のドキュメントに対して、ngram アナライザを min_gram=1 および max_gram=4 で使用するインデックスは、standard アナライザを使用する同一インデックスの約 3.4 倍のサイズになる可能性があります。

• フィールドタイプとマッピング設定の違い：text フィールドは転置インデックスを構築しますが、keyword フィールドは構築しません。マッピング設定の違いはストレージ使用量に直接影響します。

• レプリカ数の違い：number_of_replicas パラメーターの値が大きいほど、総ストレージ消費量が増加します。

• 圧縮設定の違い：best_compression 設定では DEFLATE アルゴリズムが使用されます。このアルゴリズムは、default の LZ4 アルゴリズムよりも高い圧縮率を提供しますが、読み書き性能がわずかに低下します。

ストレージサイズの差を調査するには、次の手順を実行します。

• GET _cat/indices?v&bytes=b コマンドを実行して、各インデックスのストレージサイズを確認します。

• POST <index>/_disk_usage?run_expensive_tasks=true コマンドを実行して、フィールドレベルのストレージ分布を分析し、最も容量を消費しているフィールドを特定します。

よくある質問

クラスターに構成のアップグレードが必要かどうか、およびディスク I/O にリスクがあるかどうかを判断するにはどうすればよいですか？

次の順序でクラスターを評価します。リソースメトリクスから、クラスターが容量の上限に近いかどうかを判断できます。クラスタイベントから、ディスク I/O がすでにボトルネックになっているかどうかを判断できます。

手順1：リソースメトリクスが高い水準で推移しているかを確認する

インスタンス詳細ページで [Cluster Monitoring] をクリックし、[Basic Monitoring] タブを表示します。時間範囲を 1 日に設定し、次に 7 日に設定して、[Node CPU Utilization(%)]、[Node Disk Utilization(%)]、[Node HeapMemory Utilization(%)]、[Node load_1m] を確認します。業務時間中にメトリクスが 80% を超える状態が継続している場合、または load_1m がノードあたりの vCPU 数に近い、もしくはそれ以上で推移している場合、クラスターは容量の上限付近で稼働しています。この場合、重大なアラートがトリガーされていなくても、書き込みとクエリのパフォーマンス、およびクラスターの安定性に影響が出る可能性があるため、クラスター構成のアップグレードを検討する必要があります。同じタブにあるクラスターのステータスと書き込み/クエリの QPS メトリクスにより、負荷がトラフィック増加によるものか、クエリパターンの変化によるものかを確認できます。

[Basic Monitoring] では、クラスターのステータス、クラスターインデックス QPS、クラスタークエリ QPS、ノード CPU 使用率、ノードのディスク使用量、ノードのヒープメモリ使用率、ノード load_1m の 7 つのメトリクスを提供します。IOPS のチャートやディスクスループットのチャートは個別に提供されないため、監視チャートでディスクが I/O 上限に達しているかどうかを判断しないでください。

手順2：クラスタイベントに基づいてディスク I/O のリスクを特定する

左側のメニューで [イベントセンター] をクリックし、時間範囲、インスタンス ID、イベント重大度でイベントをフィルタします。次のイベントは、現在のストレージ構成の I/O 性能がボトルネックになっていることを示します：[disk I/O performance bottleneck]、[high disk I/O utilization]、[disk throughput throttling]。このようなイベントが繰り返し発生する場合、またはクエリレイテンシの増加やリクエスト拒否を伴う場合、CPU 使用率とヒープメモリ使用率が正常であっても、クラスターには I/O ボトルネックのリスクがあります。イベントがクラスターが読み取り専用状態に入ったことを示している場合は、書き込みがすでにブロックされているため、直ちに対処してください。これらのイベントがトリガーされる IOPS とスループットの上限は、クラスターのストレージタイプとノード仕様によって決まります。

手順3：短期的に負荷を軽減する

• クエリを最適化する：クエリの時間範囲を狭める、大規模インデックスに対するワイルドカードや高カーディナリティの集計クエリを避ける、小さいインデックスやクエリされなくなったインデックスを削除またはマージしてヒープメモリを解放する。

• 高い読み取りスループットを必要としないインデックスでは、レプリカシャード数を減らす：各レプリカシャードはデータの完全なコピーを保持するため、レプリカシャードを 1 つ削除すると、ディスク使用量と書き込みオーバーヘッドの両方を削減できます。

• 本トピックの「シャードの評価」セクションのガイドラインに基づいてシャード分布を改善する：プライマリシャード数はインデックス作成時にのみ指定できます。すでに存在するインデックスについては、稼働中のインデックスのプライマリシャード数を変更できることを期待するのではなく、_split API を使用してインデックスを分割するか、データを再インデックスしてください。

手順4：長期的な増加に備えてクラスターをスケールする

上記の最適化後もメトリクスが高い水準で推移する場合、またはデータ量が増加し続ける場合は、クラスター構成をアップグレードしてください。Upgrade cluster configuration に基づき、ノード仕様の増強、データノードの追加、ノードあたりのストレージ容量の拡張を行い、本トピックの「ノード仕様とノード数の評価」セクションに基づいてターゲット仕様を再評価します。vCPU やメモリではなくディスク I/O がボトルネックである場合は、アップグレード計画時により高い IOPS を提供するストレージタイプを評価してください。クラスターが開発者仕様を使用している場合は、アップグレード中にサービスが中断されること、およびアップグレード後に開発者仕様へダウングレードできないことに注意してください。