ログエンジンの容量計画¶

Elasticsearch/OpenSearch を Guance のログ/トレースストレージバックエンドとして使用する前に、ストレージ容量とクラスタスペックを事前に評価してください。このドキュメントでは、コミュニティの情報と実際のテスト結果に基づいて、評価アルゴリズムを提供します。

Warning

Elasticsearch のオープンソースライセンス変更に伴い、OpenSearch を優先的に推奨します。
まずは小規模な Elasticsearch/OpenSearch で監視データの生成レートをテストし、そのテスト結果に基づいてクラスタ計画を立てることをお勧めします。

データ圧縮¶

以下は、Elasticsearch の圧縮アルゴリズムのテスト結果です。公式の esrally に付属するデータセット nyc_taxis（サイズ 74GB）を使用しています。

codec 設定	圧縮アルゴリズム	圧縮結果/GB	圧縮比
default	LZ4	35.5	0.48
best_compression	DEFLATE	26.4	0.36

以下は、OpenSearch の 2 つの圧縮アルゴリズムのテスト結果です。opensearch-benchmark に付属するデータセット eventdata（サイズ 15GB）を使用しています。

codec 設定	圧縮アルゴリズム	圧縮結果/GB	圧縮比
default	LZ4	5.1	0.34
best_compression	DEFLATE	3.7	0.25

ディスク容量の見積もり¶

以下の条件を想定します。

1 日あたり【1TB】の監視元データが生成される
圧縮比は【0.5】
各インデックスに【1】つのレプリカが存在する
監視データは直近【7】日間保持する

ここでは、Tencent Cloud Elasticsearch のストレージ計算式を参考にします。

パラメータ	参考値
データ膨張/インデックスオーバーヘッド	10%
内部タスクオーバーヘッド	20%
OS 予約	5%
セキュリティ予約	15%

Guance のデータ保持ポリシーに基づき、ここではセキュリティ予約を 30% に引き上げます。元の計算式は以下の通りです。

実効容量 = 元データ x 圧縮比 × (1 + レプリカ数) × (1 + データ膨張) / (1 - 内部タスクオーバーヘッド) / (1 - OS 予約) x (1 + 予約領域)

参考値を代入すると、以下のようになります。

実効容量 ~= 元データ x 圧縮比 x (1 + レプリカ数) × 1.89

直近 7 日間のデータを保持する場合、発生しうるピーク値は次のようになります。

7[日] x 1[TB] x 0.5 x (1 + 1) * 1.89 ~= 13[TB]

クラスタ計画¶

データノード¶

以下は Elasticsearch のクラスタ計画です。単一ノードのスペックが高いほど、サポート可能なクラスタ規模は大きくなります。

単一ノードスペック	クラスタノード数の上限	単一ノードのディスク上限
2C4GB	10	200GB
2C8GB	10	400GB
4C16GB	20	800GB
8C32GB	40	1.5TB
16C64GB	80	3TB

【4C16GB】のノードを採用する場合、上記の容量見積もり結果に基づくと、推奨されるクラスタデータノード数は以下のようになります。

13T / 800G ~= 16

【8C32GB】のノードを採用する場合、上記の容量見積もり結果に基づくと、推奨されるクラスタデータノード数は以下のようになります。

13T / 1.5T ~= 9

【16C64GB】のノードを採用する場合、上記の容量見積もり結果に基づくと、推奨されるクラスタデータノード数は以下のようになります。

13T / 3T ~= 5

コーディネーターノード¶

1:5 の比率で独立したコーディネーターノード（最低 2 台）を追加することを推奨します。CPU:メモリの比率は 1:4 または 1:8 とします。例えば、10 台の 8C32GB データノードに対しては、2 台の 8C32GB 独立コーディネーターノードを推奨します。マスターノードは 2n+1 の高可用性構成でデプロイし、クラスタのスプリットブレインを防止します。