Shard Balancingについて理解したい/Understanding shard rebalancing in Elasticsearch

第52回Elasticsearch勉強会 2023.2.28 #elasticsearchjp

https://www.meetup.com/ja-JP/tokyo-elastic-fantastics/events/291017943/

Transcript

1. Shard Balancingについて理解したい 第52回 Elasticsearch勉強会 Kazuma Arimura (@pakio) 2023/02/28
2. 2023 Kazuma Arimura (pakio) 株式会社メルカリ Software Engineer US@Tokyo ・検索エンジン周り運用 ・検索体験/ランキング改善 @pakio / @paki0o
3. 　　 Got stuff you don’t use? Sell or buy almost anything from home. メルカリは、世界的なマーケットプレイスを創ることを目指し、創業翌年から海外展開を推し進めています。 2014年9月にUS事業を開始し、現地の嗜好やマーケットの特徴に合わせたブランディングやUI・UXの改良、配送網 の構築等に取り組んでいます。巨大かつ多様性に富む人口基盤を有するUSでの成功が、メルカリのミッションを実 現する上で重要なマイルストーンであると認識しており、注力しています。 3 Your Marketplace US事業について Factbookより引用

4. 2023 Shard Balancingについて理解したい
5. 2023 運用上発生するShard周りの悩み
6. 2023 Shardがキレイに分散してくれない
7. 2023 2016/05 (v2.2.0 !!) 時点ですでにIssueが存在
8. 2023 仮定 • index1 : 検索、インデキシング共に活発なインデックス • index2 : 検索、インデキシング共にindex1の半分程度なインデックス • ノード数 : 5 • シャード数 : 3 • レプリカ数 : 1 • シャード当たりのサイズ : 10GB 理想的なシャード配置を思い浮かべてください
12. 2023 何故このような状況に？ 各ノードへの配置はあくまでも shard数ベー スであるため、Elasticsearchにとってはこれ も最適解の一種。
13. 2023 各ノードに配置されているshard数は高々3つで、配置を変えてもそれ以上は変わらない
14. 2023 これまでに提案されてきた回避策 index/cluster.routing.allocation.total_shards_per_node インデックス/クラスター単位の設定項目。 ノードあたりに配置するshard数を制限することが可能。 利点 • 運用者が想定した、納得行くバランスに強制できる 難点 • ノード数を減らした場合でも1ノード当たりのshard数が限定されているため、unassinged shardを引き起こす可能性がある • auto_expand_replicasとの併用が難しく、動的なスケーリングが不得意 • ILMとの相性に問題あり[1] [1] : https://github.com/elastic/elasticsearch/issues/17213#issuecomment-511954376
15. 2023 v8.6.0 #91603 Improving shard balancing
16. 2023 Improving shard balancing 変更点 • ノード当たりのshard数に加えて、以下のメトリクスが追加 ◦ Write load balance : 各シャード毎に対して予め計算されたIndexing Thread数によるスコア ◦ Disk usage balance : 各ノード毎のディスク使用量に対するスコア 何が改善されたか • Write load balance ◦ 書き込みが考慮されたことにより、hotなshardはより効率的に分散されるように ▪ warm/coldはこのスコアが0となる • Disk usage balance ◦ 制約の厳しいwater markより前にディスク効率的な分散がされるように
17. 2023 旧指標 (ノード上のshard数 - 平均shard数) * 0.45 + (ノード上のindex1のshard数 - 平均shard数) * 0.55 node1 : (3 - 2.4) * 0.45 + (2 - 1.2) * 0.55 = 0.71 node2 : (2 - 2.4) * 0.45 + (1 - 1.2) * 0.55 = -0.29 => 差分が1.0に対して閾値がちょうど 1.0で変化なし
18. 2023 新指標 (旧指標 + (shard当たりの書き込みスレッド数 ) * 10 + (ノードのディスク使用量 (byte)) * 10^-11) / 11 node1 : (0.71 + (10 * 2 + 5 * 1) * 10 + (10GB * 3) * 10^-11)/11 = 253.7/11 = 23.6 node2 : (-0.29 + (10 * 1 + 5 * 1) * 10 + (10GB * 2) * 10^-11) = 151.71/11 = 13.8 => 差分が約10あるため、rebalance条件に合致。その他の組み合わせも考慮され最適化される。
19. 2023 👍 • 書き込みの負荷がより効率的に分散されるようになった • ディスクの使用量も加味して分散されるため、より効率的にディスクを使い切れるように 🤔 • 検索のユースケースで必要とされるような、読み込み量、メモリ/CPU使用率に関しては大きな進歩は見られず ⇓ ロギングやモニタリングなど、大量のデータかつHot/Warm/Cold等データのTierがはっきりしたユースケースに最適化
20. 2023 Shard Allocation周りの改善 v8.6.0ではその他にも多くの改善が取り込まれた様子
21. 2023 まとめ • Elasticsearchでは以下の複数要素を加味しつつshardが分散され、書き込み負荷の偏りが防がれるようになった ◦ 各ノードに乗っているshard数 ◦ 各ノードに乗っている特定インデックスのshard数 ◦ ディスク使用状況 ◦ Shard毎の予測される書き込み負荷 • この恩恵を受けるには8.6以上に上げる必要があるので注意 • 一方で読み込み、計算リソースについては考慮されないので、 検索が多いユースケースではtotal_shards_per_node等を用いて事前に対策をする必要がある
22. 2023 Thanks!