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

注意事項

本トピックで提供される評価方法は、実際のテスト結果とユーザーエクスペリエンスに基づいています。データ構造、クエリの複雑さ、データ量、パフォーマンス、データの変更に関する要件はユーザーによって異なる場合があります。本トピックは参考情報としてのみ提供されます。実際のデータとビジネスシナリオに基づいて、お使いの ES クラスターの仕様とストレージ容量を評価することを推奨します。

ストレージ容量の評価

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

• ソースデータの量。

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

• インデックス作成のオーバーヘッド：ほとんどの場合、インデックス作成のオーバーヘッドはソースデータの 10% 増しになります。

  例えば、X-Pack が例外分析に使用するモニタリングインデックスは、インデックス作成のオーバーヘッドを生成します。モニタリングインデックスには以下のタイプが含まれます。

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

  • .monitoring-kibana-6-*：このタイプのインデックスが消費するストレージ容量は、インデックスの数とともに増加します。デフォルトでは、ES は過去 7 日間に作成されたインデックスデータのみを保持します。

  • .watcher-history-3-*：このタイプのインデックスは、少量のストレージ容量しか消費しません。このようなインデックスが不要になった場合は、手動で削除できます。

• ES クラスターの内部オーバーヘッド：セグメントマージやロギングなどの内部操作は、インデックス作成のオーバーヘッドを生成します。このようなオーバーヘッドのために、ストレージ容量の 20% が予約されます。

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

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

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

推奨されるストレージ容量は、次の式を使用して計算されます。

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

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

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

データノード

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

• ES クラスターの各ノードが保存できるデータの最大量は、ビジネスシナリオによって異なります。

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

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

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

次の表は、さまざまなノード仕様に対する最大ノード数とノードあたりの最大ストレージ容量を示しています。

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

• データ量が少なく、ディスク 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 のデータをサポートし、この規模のデータ量に対して十分な余裕があります。これより低い仕様では、インデックス用のページキャッシュがほとんどなくなり、クラスターはディスクからより多くのデータを読み取ることになります。

  • ストレージ：クラスターの購入時または構成のアップグレード時に、[ストレージタイプ] を [標準 SSD] に設定します。標準 SSD は高い IOPS と短い応答時間を提供し、オンライン分析と検索に適しています。ノードで達成可能な IOPS とスループットは、ストレージタイプとノード仕様によって決まり、プライマリシャードの数には依存しません。このサイズのインデックスにプライマリシャードを追加しても、利用可能な I/O 能力は増加しません。

専用マスターノード

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

ES クラスターの専用マスターノードの仕様は、以下の指針を参考に決定できます。

• デフォルト仕様：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 台構成することを推奨します。

シャードの評価

シャードの数と各シャードのサイズは、ES クラスターの安定性とパフォーマンスに影響します。ES クラスター内のすべてのインデックスに対して、シャードを適切に計画する必要があります。これにより、多数のシャードがクラスターのパフォーマンスに影響を与えたり、複雑なビジネスシナリオで負荷の不均衡を引き起こしたりするのを防ぐことができます。例えば、ES クラスター内のインデックスのシャード計画が不適切な場合、ノードのディスク使用量に大幅な差異が生じたり、ノード間で CPU 負荷の不均衡が発生したりすることがあります。

Alibaba Cloud は、シャードを計画するための以下のガイドラインを提供しています。これらのガイドラインは参考情報です。

• 各シャードに保存されるデータの量

  • 各シャードには 30 GiB 以下のデータを保存することを推奨します。特別な場合には、各シャードに 50 GiB 以下のデータを保存できます。

  • ログ分析シナリオや非常に大きなインデックスが必要なシナリオでは、各シャードが 100 GiB 以下のデータを保存するようにしてください。

• シャードの数

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

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

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

    説明

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

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

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

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

  • 単一ノード上のすべてのインデックスのシャード総数は、次のいずれかの式を使用して計算することを推奨します。

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

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

    説明

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

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

    • ビジネス要件に基づいてシャードを構成することを推奨します。プライマリシャードが多いほど、パフォーマンスのオーバーヘッドが大きくなります。ES クラスターの各インデックスに過度に多くのシャードを構成すると、ファイルハンドルが枯渇する可能性があります。その結果、ES クラスターに障害が発生する可能性があります。

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

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 つ以上の大きなインデックスのシャードが少数のノードに集中したままになっています。「クラスター上の負荷の不均衡」に基づいて、不均衡の原因となっているインデックスとノードを特定し、シャードを再分散させることができます。

シャードの評価の詳細については、「シャードのサイジング方法」をご参照ください。

関連ドキュメント

• さまざまなリージョンとバージョンでサポートされているノード仕様について、または ES クラスターを購入するには、購入ページをご参照ください。

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

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

• 評価結果に基づいて、既存の ES クラスターのノード仕様、ノードのストレージ容量、ノード数などの項目を調整できます。操作方法と関連する注意事項については、「クラスター構成のアップグレード」と「クラスターのダウングレード」をご参照ください。

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

• 既存のインデックスの各シャードに保存されているデータ量が推奨量を超える場合は、そのインデックスのデータを再インデックスすることを推奨します。詳細については、「reindex API を使用した Alibaba Cloud Elasticsearch クラスター間のデータ移行」をご参照ください。

  説明

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

• ES クラスター上の負荷の不均衡を解決する方法については、「クラスター上の負荷の不均衡」をご参照ください。

• ノード上のホットデータの不均等な分布を解決する方法については、「ノード上のホットデータの不均等な分布」をご参照ください。

• 自動インデックス作成機能を有効にする場合は、インデックスライフサイクル管理 (ILM) 機能または ES API スクリプトを使用して、古いインデックスを削除することを推奨します。ILM 機能の詳細については、「ILM を使用した Heartbeat データの管理」をご参照ください。

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

インデックスのストレージ使用量に差異が生じる原因

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

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

• フィールドタイプとマッピング設定の違い：text フィールドタイプは、フィールド値を複数のトークンにトークン化することで転置インデックスを構築します。keyword フィールドタイプはトークン化を行わず、代わりにフィールド値全体を転置インデックス内の単一のタームとしてインデックスし、完全一致 (term クエリ)、ソート、集計をサポートします。異なるマッピング構成は、ストレージ消費量に直接影響します。

• レプリカ数の違い：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：リソースメトリクスが高いレベルで推移しているか確認する

インスタンス詳細ページで [クラスター監視] をクリックし、[基本監視] タブを表示します。時間範囲を 1 日、次に 7 日に設定し、[ノード CPU 使用率 (%)]、[ノードディスク使用率 (%)]、[ノードヒープメモリ使用率 (%)]、および [ノード load_1m] を確認します。営業時間中にメトリクスが 80% を超えたままである場合、または load_1m がノードあたりの vCPU 数に近いかそれを超えるままである場合、クラスターは容量の限界近くで実行されています。この場合、重大なアラートがトリガーされていなくても、書き込みとクエリのパフォーマンスおよびクラスターの安定性が影響を受ける可能性があり、クラスターの構成をアップグレードすることを検討する必要があります。同じタブのクラスターの状態と書き込みおよびクエリの QPS メトリクスは、負荷がトラフィックの増加によるものか、クエリパターンの変更によるものかを確認するのに役立ちます。

[基本監視] は、クラスターの状態、クラスターインデックス 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：長期的な成長に備えてクラスターを拡張する

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