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 - オペレーティングシステムによって予約されるストレージ容量)/(1 - クラスターの内部オーバーヘッド)/(1 - セキュリティしきい値のオーバーヘッド)
             = ソースデータの量 × (1 + レプリカシャード数) × 1.7
             = ソースデータの量 × 3.4

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

データノード

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

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

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

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

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

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

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

専用マスターノード

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

Elasticsearch クラスターの専用マスターノードの仕様を決定するには、次のガイドラインを参考にしてください：

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

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

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

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

クライアントノード

独立したクライアントノードを使用する場合、評価結果に対してリデュース操作を実行できます。この場合、リデュース段階で深刻なガベージコレクション (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 クラスターで障害が発生する可能性があります。

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

関連ドキュメント

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

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

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

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

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

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

  説明

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

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

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

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

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

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

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

• アナライザー設定の違い：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 コマンドを実行して、フィールドレベルのストレージ分布を分析し、最も多くの容量を消費しているフィールドを特定します。