この記事では、Elasticsearchのサイズを設定するための基本的なアプローチを理解し、ログとメトリックをロードする際のクラスターベンチマークの比較を示します。そして、その違いはそこで顕著です。これがElasticsearchクラスターのサイズを決定し、「依存する」ことを解読するのに役立つことを願っています。

ある意味、この記事は、ハブレのサイジングに関する記事の続きです。しかし、実際の例がここに表示されたので、何らかの継続性が必要な場合は、その記事から始めて、ここに戻ってください。すべての詳細はカットの下にあります。

この記事は、ElasticブログのログとメトリックのElasticsearchクラスターのベンチマークとサイズ設定に基づいています。少し変更し、クラウドベースのElasticで例を削除しました。

Elasticsearchクラスターハードウェアリソース

Elasticsearchクラスターのパフォーマンスは、主にクラスターの使用方法とその下で実行されるもの（ハードウェアの意味で）に依存します。ハードウェアの特徴は次のとおりです。

ボールト

ベンダーは、可能な限りSSDを使用することを推奨しています。しかし、明らかに、これはどこにでも当てはまるとは限らないため、ホットウォームコールドアーキテクチャとインデックスライフサイクル管理（ILM）を利用できます。

Elasticsearchは冗長ストレージを必要としません（RAID 1/5/10なしで実行できます）。ログまたはメトリックストレージのシナリオには通常、フォールトトレランスを最小限に抑えるために少なくとも1つのレプリカがあります。

記憶

サーバー上のメモリは、

JVMヒープに分割されます。クラスタ、インデックス、セグメント、セグメント、およびドキュメントフィールドデータに関するメタデータを格納します。理想的には、これに使用可能なRAMの50％を割り当てる必要があります。

OSキャッシュ。Elasticsearchは、残りの使用可能なメモリを使用してデータをキャッシュします。これにより、全文検索、ドキュメント値の集計、および並べ替え中のディスク読み取りが防止され、パフォーマンスが大幅に向上します。また、RAMの内容をディスクにフラッシュしてから読み取ることを避けるために、スワップ（スワップファイル）を無効にすることを忘れないでください（これは遅いです！）。

CPU

Elasticsearchノードにはいわゆるものがあります。利用可能なコンピューティングリソースを使用するスレッドプールとスレッドキュー。CPUコアの数とパフォーマンスによって、Elasticsearchのデータ操作の平均速度とピークスループットが決まります。ほとんどの場合、これらは8〜16コアです。

通信網

ネットワークパフォーマンス-帯域幅とレイテンシーの両方が、Elasticsearchノード間の通信とElasticsearchクラスター間の通信に大きな影響を与える可能性があります。デフォルトでは、ノードの可用性チェックは毎秒実行され、ノードが30秒以内にpingを実行しない場合、ノードは使用不可としてマークされ、クラスターからシャットダウンされることに注意してください。

ストレージボリュームによるElasticsearchクラスターのサイズ設定

通常、ログとメトリックを保存するには大量のディスクスペースが必要になるため、このデータの量を使用して、Elasticsearchクラスターのサイズを最初に決定する価値があります。以下は、クラスターで管理する必要のあるデータ構造を理解するためのいくつかの質問です。

1日あたりどのくらいの生データ（GB）をインデックスに登録しますか？
データは何日保持しますか？
ホットゾーンには何日ありますか？
ウォームゾーンには何日ありますか？
レプリカはいくつ使用されますか？

5％または10％を上に置き、合計ディスク容量の15％が常に在庫に残るようにすることをお勧めします。それでは、このケースを数えてみましょう。

合計データサイズ（GB） = 1日あたりの生データ数（GB）*ストレージの日数*（レプリカの数+1）。

合計ストレージ（GB） =合計データ（GB）*（1 +0.15ストレージスペース+0.1追加ストレージ）。

データノードの総数= OKRVVERH（合計データサイズ（GB）/データノードあたりのメモリサイズ/メモリ：データ比）。大規模なインストールの場合は、もう1つのノードをストックしておくことをお勧めします。

Elasticは、次の比率のメモリを推奨しています。さまざまなタイプのノードのデータ：ホット→1：30（メモリ1ギガバイトあたり30 GBのディスク容量）、ウォーム→1：160、コールド→1：500）。OKRVVERKH-最も近い整数にサラウンドします。

小クラスター計算例

毎日約1GBのデータが到着し、9か月間保存する必要があると仮定します。

合計データ（GB） = 1 GB x（9か月x 30日）x 2 = 540 GB

合計ストレージ（GB） = 540 GB x（1 + 0.15 + 0.1）= 675GB

データノードの合計数= 675 GB / 8 GB RAM / 30 = 3ノード。

大規模なクラスターの計算例

1日あたり100GBを取得し、このデータをホットゾーンで30日間、ウォームゾーンで12か月間保存します。ノードごとに64GBのメモリがあり、そのうち30 GBがJVMヒープに割り当てられ、残りはOSキャッシュに割り当てられます。メモリの推奨比率：ホットゾーンのデータは暖かいゾーンのため、午前1時30分である- 1：160

あなたが一日と30日のためにこのデータを保存する必要性につき100ギガバイトを取得する場合、我々が得る：だから、

の合計額をホットゾーンのデータ（GB） =（100 GBx30日* 2）= 6000 GB

合計ホットゾーンストレージ（GB） = 6000 GB x（1 + 0.15 + 0.1） = 7500GB

合計ホットゾーンデータノード= OKRVUPH（ 7500/64/30）+ 1 = 5ノード

ウォームゾーンの合計データ（GB）=（100 GBx365日* 2）= 73,000 GB

ウォームゾーンの合計ストレージ（GB） = 73,000 GB x（1 + 0.15 + 0.1）= 91,250GB

ウォームゾーンのデータノードの合計数= OKRVVERKH（91 250 / 64/160）+ 1 = 10ノット

したがって、ホットゾーンで5ノット、ウォームフルーツで10ノットが得られました。コールドゾーンの場合も同様の計算ですが、メモリ比率：データはすでに1：500になっています。

パフォーマンステスト

クラスターのサイズが決定されたら、数学が実際に機能することを確認する必要があります。

このテストでは、Elasticsearchのエンジニアが使用するのと同じツールであるRallyを使用します。展開と実行が簡単で、完全にカスタマイズできるため、複数のシナリオ（トラック）をテストできます。

結果の分析を容易にするために、テストはインデックス作成と検索クエリの2つのセクションに分かれています。テストでは、Metricbeatトラックと Webサーバーログのデータを使用します。

インデックス作成

テストは次の質問に答えます。

クラスターのインデックス作成の最大スループットはどれくらいですか？
1日にどのくらいのデータをインデックスに登録できますか？
クラスターは適切なサイズよりも大きいですか、それとも小さいですか？

このテストでは、ノードごとに次の構成を持つ3ノードクラスターを使用します。

8 vCPU;
HDD;
32GB / 16ヒープ。

インデックステスト＃1テストに

使用されるデータセットは、次の特性を持つMetricbeatデータです。

1,079,600ドキュメント;
データ量：1.2 GB;
平均ドキュメントサイズ：1.17KB。

次に、最適なパケットサイズと最適なスレッド数を決定するためのいくつかのテストがあります。

それはすべて、最適なパッケージサイズを見つけるために1つのRallyクライアントから始まります。最初に100個のドキュメントがロードされ、その後の起動でその数が2倍になります。その結果、12,000ドキュメントの最適なバッチサイズ（約13.7 MB）になります。パケットサイズがさらに大きくなると、パフォーマンスが低下し始めます。

次に、同様の方法を使用すると、16が1秒あたり62,000のインデックス付きイベントを達成するための最適なクライアント数です。

合計すると、クラスターはパフォーマンスを犠牲にすることなく、1秒あたり最大62,000のイベントを処理できます。この数を増やすには、新しいノードを追加する必要があります。

以下は、12,000イベントのパケットを使用した同じテストですが、比較のために、帯域幅データは1ノード、2ノード、および3ノードについて示されています。

テスト環境の場合、最大インデックススループットは次のようになります。

1つのノードと1つのシャードを使用して、1秒あたり22,000のイベントにインデックスが付けられました。
2つのノードと2つのシャードを使用して、1秒あたり43,000のイベントにインデックスが付けられました。
3つのノードと3つのシャードを使用して、1秒あたり62,000のイベントにインデックスが付けられました。

追加のインデックス要求はキューに入れられ、いっぱいになると、ノードはインデックス要求を拒否することで応答します。

データセットはクラスターのパフォーマンスに影響を与えるため、独自のデータを使用してRallyトラックを実行することが重要であることに注意してください。

インデックス作成テスト＃2

次のステップでは、次の構成のHTTPサーバーログデータトラックが使用されます。