クラスターのノード台数について

Elastic In Your Native Tongue 日本語による質問・議論はこちら
1

お世話になっております。

クラスターのノード台数を増やすことによる、副作用などはあったりしますでしょうか。
もちろん各ノードのリソースによるところとは思いますが、例えば各ノード間の死活監視が増えることにより、
検索性能に影響が出るなど。。

基本的にノードを増やすこと自体は問題ない認識ではおりますが、
すでに既知の課題や問題などがあれば知っておきたいなと思った次第です。

漠然とした質問で恐縮ですが、もし知見がおありの方、経験された方などいらっしゃいましたら、
教えてください。。

利用しているVersionは1.7.5でシャード数は5で設定しております。
サーバーはAWSのEC2上に起動しており、r3.large(vCPU2/メモリ15.25GB)のインスタンスになります。

よろしくお願いします。

2

クラスターのノード台数を増やすことによる、副作用などはあったりしますでしょうか。

身も蓋もなくて恐縮なのですが、要件によるかと思います。
極端な話をすると、すぐに再投入できるクリティカルでないようなデータの保持のためにクラスタリンググループを組むと設計や運用、サーバの維持にコストがかかりすぎてしまうので、それなら１台でやって壊れたら再投入のほうが色々と楽かな、等。

個人的な感覚ですが、今回始めて導入を検討されるのであればテスト環境用に１台で運用されてみるのが良いかと思います。

Elasticsearchはクラスタリングを組みやすいのですが、
その反面、あまり細かい挙動を理解しなくても動いてしまいます。
私は過去にクラスタリングでざっくり運用していて負荷をかけすぎてクラスタリングの挙動をおかしくしてデータを壊してしまったことがあります。。。:innocent:
※多分このへんは本来設定で回避出来ると考えています。

ある程度こなれてきたら、クラスタリンググループを構築されたほうが良いかと思います。
ElasticsearchはJVMで動いており、オブジェクトポインタの効率の問題から巨大な一つのインスタンスで運用するよりも程々のスペックのインスタンスでクラスタリングを構成されることを推奨されているためです。

AWS上での構築例として、昨年の6月のタイミング(Elasticsearch2系)ではm3.2xlargeが一例として紹介されてます。

また、時間がないけど設計等の段階からなるべく無駄のないように進められたいのであればサポート契約されるのも一つの手かと思います。

ご参考まで。

3

@st1t さんの仰る通り要件次第ですが、何れにせよ1点気をつけたほうが良いのはshard数とnode数の整合性です。

(以下、nodeはdata nodeを意味します)

shard数5でreplicaが1の場合、1つのindexにつき合計10のshardが存在しますが、node数が5であれば1nodeあたり2shardを均等に配置することができます。
しかし同様の状況でnode数が7の場合、1shardだけ配置されたnodeと2shard配置されたnodeが混在することになります。

Elasticsearchの分散処理は基本的にshard単位で実行され、処理全体の所要時間は最も応答が遅いnodeに引きずられることになるため、上記の例ではnode数が5でも7でも1nodeあたり最大で2shardを保持している状況に変わりはないため、cluster全体でのパフォーマンスは対して変わらない可能性があります。

上記のような理由から、1node当たりのshard数が均等になるようなnode数(とshard数)を採用するのが無難だと思っています。具体的には(replicaを含む)1index当たりのshard数の倍数や約数ということになります。

副作用というより留意点といった感じですが参考になれば:wink:。

4

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.