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 つのレプリカシャードを構成できます。

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

  • ノードのインデックスには最大 5 つのシャードを構成することをお勧めします。

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

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

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

    説明

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

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

    • ビジネス要件に基づいてシャードを構成することをお勧めします。プライマリシャードが多いほど、パフォーマンスのオーバーヘッドが増加します。Elasticsearch クラスターの各インデックスに過度に多数のシャードを構成すると、ファイルハンドルが使い果たされる可能性があります。その結果、Elasticsearch クラスターで障害が発生する可能性があります。

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

参照資料

• Elasticsearch の 購入ページ で、Elasticsearch クラスターを購入したり、さまざまなリージョンと Elasticsearch バージョンでサポートされているノードの仕様を表示したりできます。

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

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

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

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

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

  説明

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

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

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

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

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