本番環境でのshardとreplica数について

[mukai]

システム本番環境でのシャード(shard)数とレプリカ(replica)数を決める必要があるのですが、参考になるドキュメントやベストプラクティスはありますか？

(1) サーバ構成
3ノード構成
※当システムの集約(Terms Aggregation)時は誤差が発生してはいけないので、shard数は1にした方が良い？。

Terms Aggregationで正確な結果を取得するには - Qiita

(2) 今回決めたい設定
"settings" : {
"number_of_shards" : ◯,
"number_of_replicas" : ◯
}

[r4-keisuke (Sunggyu Kei Rhie)]

はじめましてー

shard数はデータの容量等によって異なるので、利用される目的などによって設定する必要がありますね。
shard毎に行われる処理が結構あるので、あんまり分散してしまうと良くはなさそうですし。

replicaは演算の分散と万が一のときにためだと思うので、そこも目的次第って感じでしょうね。。。

Diskの容量が確保できて、3nodesであれば2replicasでの問題ないのではないかと思います。

あまり役に立つ回答じゃなくて申し訳ないですが、ご参考までに！

[mnozawa (Makoto Nozawa)]

terms aggregationの誤差はsizeおよびshard_sizeの設定により抑制/解消することができます。
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html#_shard_size_3

要するに全documentを集計対象に含めることができれば誤差はなくなります。
number_of_shards:1としてしまうと3ノードのうち1ノードでしか集計をできなくなるので誤差なく集計できるdocument数は逆に小さくなります。誤差を許さないのが重要な要件であれば、資源を無駄なく使うため、number_of_shards:3(もしくは3の倍数)とするのが良いと思います。

本番運用に載せるのであれば、number_of_replicasは1以上にするのが基本です。replicaが1あれば、1ノードの障害に耐えられます。dedicated master nodeを置かない場合、2ノードに障害が起きるとクラスタを保てなくなるため、耐障害性の観点からはnumber_of_replicasを2以上にする動機は小さいです。
replicaを増やすことでreadの性能が上がる場合もあるので、3以上のreplicaが無駄ということはありません。性能試験をしながら調整することになるかと思います。

shardとreplica、毎回悩みます。
結局は「ケースバイケース」で永遠のテーマ的なところありますね。

[st1t (Shota Ito)]

Shardの数に関してはこのブログが参考になるかなと思います

How many shards should I have in my Elasticsearch cluster? | Elastic

スケール全般に関してはこの辺りが良いかと思います。
https://www.elastic.co/guide/en/elasticsearch/guide/master/scale.html

[mukai]

沢山のアドバイスとリンクを教えて頂き、ありがとうございます。

shard数は3 (事前に実際に誤差なく集計できることを確認する)、replica数は1 (容量が余りそうなら増やす？)をベースに検討いたします。

How many shards should I have in my Elasticsearch cluster? | Elastic
How many shards should I have in my Elasticsearch cluster? | Elastic Blog

また、上記ブログの記載もとても参考になりました。
ブログに書かれていた下記の内容も参考にshard, replica数を検討させて頂きます。

1. 1shardサイズの上限は50GB。
2. 期間単位(年・月)でのindexの分割は大切。(shard, replica数の変更に容易に対応可。)
3. index数とmappingサイズのバランスが大切。
4. shardサイズは数GB～数十GB、時系列データのshardサイズは20GB～40GBが一般的。(小さすぎるshardはパフォーマンス低下につながる)
5. 小さすぎるshardは「Force Merge API」を使って、shard数を減らす。
6. 1ノードの最大shard数はメモリ量に比例する。メモリ1GB辺り最大20～25shard、16GB辺り最大320～400shardまで持てる。(shard数は余裕を持ったほうが、パフォーマンスは向上する。)
7. 本番データと複数クエリで実際に試して、適切な最大shardサイズを決めるのが良い。