Alibaba Cloud ES のインスタンスタイプと容量の選択方法 - Elasticsearch

購入または構成変更の前に、Alibaba Cloud Elasticsearch (ES) クラスターのストレージ容量、ノード仕様、およびシャードレイアウトを計画します。

クイックリファレンス: プライマリシャードあたり1つのレプリカがある場合、合計ストレージとしてソースデータ量の約 3.4倍 をプロビジョニングします。例えば、100 GiB のソースデータには、約 340 GiB のクラスターストレージが必要です。

このドキュメントの評価方法は、実際のテスト結果と運用経験に基づいています。実際の要件は、データ構造、クエリの複雑さ、データ量、データの変更、およびパフォーマンス目標によって異なる場合があります。構成を確定する前に、代表的なワークロードで見積もりを検証してください。

ストレージ容量の計算式

プライマリシャードあたり1つのレプリカシャードがデフォルトの場合、合計クラスターストレージはソースデータ量の約 3.4倍 です。この乗数には、以下のオーバーヘッド要因が含まれます。

要因	オーバーヘッド	説明
レプリカシャード	2倍 (レプリカ1個の場合)	各プライマリシャードには少なくとも1つのレプリカシャードがあります
インデックス作成のオーバーヘッド	通常10%	ソースデータ以外のインデックス構造によって消費される領域
内部オーバーヘッド	20%予約済み	セグメントマージ、ログ記録、その他の内部操作
OS予約済み領域	5%予約済み	重要なプロセス、システムリカバリ、ディスクフラグメント
セキュリティしきい値	少なくとも15%予約済み	Elasticsearch によって維持される最小空き領域

簡易計算式:

Cluster storage = Source data x (1 + Number of replicas) x 1.7
                = Source data x 3.4  (when replicas = 1)

完全な計算式:

Cluster storage = Source data
                  x (1 + Number of replicas)
                  x Indexing overhead factor
                  / (1 - OS reserved)
                  / (1 - Internal overhead)
                  / (1 - Security threshold)

                = Source data x (1 + Number of replicas) x 1.1 / 0.95 / 0.80 / 0.85
                = Source data x (1 + Number of replicas) x 1.7

重要

3.4倍の乗数は、レプリカが1つであることを前提としています。実際のレプリカ数に合わせて計算式を調整してください。

例: 200 GiBのソースデータ

シナリオ: 200 GiB のソースデータ、プライマリシャードあたり1つのレプリカシャード。

Cluster storage = 200 GiB x (1 + 1) x 1.7
                = 200 x 2 x 1.7
                = 680 GiB

計算式に含まれないストレージ消費

計算式に含まれる要因以外にも、以下の項目がストレージを消費します。

X-Packモニタリングインデックス -- 例外分析に使用されます。
- .monitoring-es-6-*: 大量のストレージを消費します。デフォルトでは過去7日間保持されます。
- .monitoring-kibana-6-*: インデックス数に応じて増加します。デフォルトでは過去7日間保持されます。
- .watcher-history-3-*: 最小限のストレージを消費します。不要になった場合は手動で削除してください。
クラスターログ -- 実行ログ、アクセスログ、スローログが含まれます。デフォルトでは過去7日間保持されます。この保持期間は変更できません。ログ量は、クラスターが受信するクエリとデータプッシュの数に応じて増加します。

ノード仕様とノード数

データノード

データノードあたりの最大スケールを決定する2つのルールを次に示します。

クラスターあたりの最大ノード数 = ノードあたりのvCPU x 5
ノードあたりの最大ストレージ = ノードあたりのメモリ (GiB) x シナリオ固有の乗数

シナリオ	乗数	一般的な用途
汎用	メモリ x 30	読み取り/書き込み混合ワークロード
クエリ	メモリ x 10	高速化、集約
ログ記録	メモリ x 50	ログインポート、オフライン分析

次の表は、各仕様の最大ノード数とノードあたりの最大ストレージを示しています。

仕様	最大ノード数	汎用	クエリ	ログ記録
2 vCPUs, 4 GiB	10	120 GiB	40 GiB	200 GiB
2 vCPUs, 8 GiB	10	240 GiB	80 GiB	400 GiB
4 vCPUs, 16 GiB	20	480 GiB	160 GiB	800 GiB
8 vCPUs, 32 GiB	40	960 GiB	320 GiB	1.5 TiB
16 vCPUs, 64 GiB	80	1.9 TiB	640 GiB	3 TiB

合計クラスターストレージ = ノードあたりのストレージ x ノード数

ターゲット仕様のノードあたりの最大ストレージと最大ノード数に基づいて、ノード仕様を選択します。

データノードの数は、合計シャード数に影響します。ノード仕様を確定する前に、以下のシャード評価を完了してください。
集約負荷の高いクエリの場合は、vCPU対メモリ比が1:2の仕様を選択し、クライアントノードを有効にしてください。

例: 2 TiBのログデータ

シナリオ: 2 TiB のログデータ、ログ記録のユースケース、レプリカ1つ。

必要なストレージを計算します: 2 TiB x 3.4 = 6.8 TiB
ノード仕様を選択します: 8 vCPU、32 GiB (ログ記録の最大値: ノードあたり 1.5 TiB)
ノード数を計算します: 6.8 TiB / 1.5 TiB = 約 5 ノード (切り上げ)
ノード制限を確認します: 5 ノード < 40 最大ノード。有効です。

専用マスターノード

多数のデータノードを持つクラスターでは、クラスターの安定性を維持するために専用マスターノードを有効にしてください。データノード数に基づいて仕様を選択します。

データノード数	専用マスターノード仕様
デフォルト	2 vCPUs, 8 GiB
10以上	4 vCPUs, 16 GiB
30以上	8 vCPUs, 32 GiB
50以上	16 vCPUs, 64 GiB

クラスターに多数のインデックスとシャードがある場合、またはデータが頻繁に変更される場合は、専用マスターノードにより高い仕様を選択してください。

クライアントノード

クライアントノード (Elasticsearch のコーディネーティングノード) は、分散クエリのリデュースフェーズを処理します。専用クライアントノードは、ガベージコレクション (GC) の影響をデータノードから分離します。

ガイドライン	値
クライアントノード対データノード比	1:5
クライアントノードのvCPU対メモリ比	1:4 または 1:8
最小クライアントノード数	2

例: 各 8 vCPU、32 GiB のデータノードが10個ある場合、各 8 vCPU、32 GiB のクライアントノードを2個構成します。

シャードの評価

シャードは Elasticsearch インデックスの基本的なストレージ単位であり、プライマリシャードとレプリカシャードに分類されます。詳細については、「シャードとレプリカシャード」をご参照ください。

適切なシャード計画は、パフォーマンスの低下、ディスク使用率の不均一、ノード間のCPU負荷の不均衡を防ぎます。インデックスあたりのデータ量、予想されるデータ増加、ノード仕様、および一時的なインデックスが定期的な削除またはマージを必要とするかどうかに基づいてシャードを計画します。

シャードサイズのガイドライン

シナリオ	最大シャードサイズ
汎用ワークロード	30 GiB (特殊な場合は最大 50 GiB)
ログ分析または非常に大きなインデックス	100 GiB

インデックスあたりのシャード数

データ量に基づいてシャード数を決定します。

大容量データ、高い書き込みスループット: プライマリシャードあたり1つのレプリカを持つ、インデックスあたり複数のプライマリシャードを構成します。
小容量データ、低い書き込みスループット: インデックスあたり1つのプライマリシャードと、1つ以上のレプリカシャードを構成します。

デフォルトのシャード構成はバージョンによって異なります。
V7.X以降: インデックスあたり1つのプライマリシャード、1つのレプリカシャード
V7.X以前: インデックスあたり5つのプライマリシャード、1つのレプリカシャード

小さなインデックスでの負荷分散: インデックスあたりのデータ量が 30 GiB 未満の場合、複数のレプリカを持つ1つのプライマリシャードを使用して、ノード全体に負荷を分散します。例えば、5ノードクラスター上の 20 GiB のインデックスは、1つのプライマリシャードと4つのレプリカシャードを使用できます。

シャード分散のガイドライン

合計シャード数をデータノード数と等しくするか、その整数倍にしてください。
単一ノードあたりのインデックスあたりの最大シャード数は5つにしてください。

ノードあたりの合計シャード数

単一のデータノードが保持できる最大シャード数を計算します。

クラスターサイズ	計算式
小規模な仕様 (またはデータ量 < 1 TiB)	ノードあたりのシャード数 = メモリ (GiB) x 30
大規模な仕様	ノードあたりのシャード数 = メモリ (GiB) x 50

V7.X クラスターにおけるノードあたりのデフォルトの最大シャード数は 1,000 です。この制限を変更しないでください。より多くのシャードが必要な場合は、代わりにノードを追加してください。
過剰なシャードはパフォーマンスオーバーヘッドを増加させ、ファイルハンドルを使い果たし、クラスター障害につながる可能性があります。実際のビジネス要件に基づいてシャードを構成してください。

詳細については、「How to size your shards」をご参照ください。

サイジングとメンテナンスのベストプラクティス

見積もりから開始し、反復します。 このドキュメントの計算式は、初期のサイジング見積もりを提供します。代表的なワークロードで検証し、必要に応じて調整してください。
古いインデックスを削除します。 自動インデックス作成が有効になっている場合、インデックスライフサイクル管理 (ILM) または Elasticsearch APIスクリプトを使用して古いインデックスを削除します。詳細については、「ILM を使用した Heartbeat インデックスの管理」をご参照ください。
ヒープメモリを解放します。 小さいまたは未使用のインデックスを速やかに削除して、ヒープメモリを解放してください。
シャードの健全性を監視します。 既存のインデックスのシャードあたりのデータ量が推奨制限を超えている場合、データを再インデックスします。詳細については、「reindex API を使用したデータ移行」をご参照ください。データの再インデックスはサービスの継続性を維持しますが、時間のかかる作業です。

参考

購入ページ: リージョンと Elasticsearch バージョンごとのサポートされているノード仕様を表示します。
パフォーマンス: 異なる仕様とバージョンのクラスターのストレステスト結果。
バージョン機能: Standard Edition と Kernel-enhanced Edition の違い、およびバージョン間の機能変更。
クラスター構成のアップグレード: ノード仕様、ストレージ、ノード数を調整します。
クラスター構成のダウングレード: クラスター構成を削減します。
インデックスの作成: プライマリシャードの数は、インデックス作成時にのみ設定でき、後で変更することはできません。
クラスターの負荷の不均衡: 負荷の不均衡をトラブルシューティングします。
ノード上のホットデータの不均一な分散: ホットデータ分散の問題を解決します。