Shard Balancingについて理解したい 第52回 Elasticsearch勉強会 Kazuma Arimura (@pakio) 2023/02/28 

2023 Kazuma Arimura (pakio) 株式会社メルカリ Software Engineer US@Tokyo ・検索エンジン周り運用 ・検索体験/ランキング改善 @pakio / @paki0o 

　　 Got stuff you don’t use? Sell or buy almost anything from home. メルカリは、世界的なマーケットプレイスを創ることを目指し、創業翌年から海外展開を推し進めています。 2014年9月にUS事業を開始し、現地の嗜好やマーケットの特徴に合わせたブランディングやUI・UXの改良、配送網 の構築等に取り組んでいます。巨大かつ多様性に富む人口基盤を有するUSでの成功が、メルカリのミッションを実 現する上で重要なマイルストーンであると認識しており、注力しています。 3 Your Marketplace US事業について Factbookより引用
 

2023 Shard Balancingについて理解したい 

2023 運用上発生するShard周りの悩み 

2023 Shardがキレイに分散してくれない 

2023 2016/05 (v2.2.0 !!) 時点ですでにIssueが存在 

2023 仮定 ● index1 : 検索、インデキシング共に活発なインデックス ● index2 : 検索、インデキシング共にindex1の半分程度なインデックス ● ノード数 : 5 ● シャード数 : 3 ● レプリカ数 : 1 ● シャード当たりのサイズ : 10GB 理想的なシャード配置を思い浮かべてください 

2023 

2023 

2023 

2023 何故このような状況に？ 各ノードへの配置はあくまでも shard数ベー スであるため、Elasticsearchにとってはこれ も最適解の一種。 

2023 各ノードに配置されているshard数は高々3つで、配置を変えてもそれ以上は変わらない 

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 

2023 v8.6.0 #91603 Improving shard balancing 

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より前にディスク効率的な分散がされるように 

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で変化なし 

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条件に合致。その他の組み合わせも考慮され最適化される。 

2023 👍 ● 書き込みの負荷がより効率的に分散されるようになった ● ディスクの使用量も加味して分散されるため、より効率的にディスクを使い切れるように 🤔 ● 検索のユースケースで必要とされるような、読み込み量、メモリ/CPU使用率に関しては大きな進歩は見られず ⇓ ロギングやモニタリングなど、大量のデータかつHot/Warm/Cold等データのTierがはっきりしたユースケースに最適化 

2023 Shard Allocation周りの改善 v8.6.0ではその他にも多くの改善が取り込まれた様子 

2023 まとめ ● Elasticsearchでは以下の複数要素を加味しつつshardが分散され、書き込み負荷の偏りが防がれるようになった ○ 各ノードに乗っているshard数 ○ 各ノードに乗っている特定インデックスのshard数 ○ ディスク使用状況 ○ Shard毎の予測される書き込み負荷 ● この恩恵を受けるには8.6以上に上げる必要があるので注意 ● 一方で読み込み、計算リソースについては考慮されないので、 検索が多いユースケースではtotal_shards_per_node等を用いて事前に対策をする必要がある 

2023 Thanks!