Apache Pulsarにおける負荷分散

公開 Apache Pulsarにおける負荷分散 ヤフー株式会社 システム統括本部クラウドプラットフォーム本部 坂本 雅宏 © Yahoo Japan

公開 ⾃⼰紹介 坂本 雅宏 経歴︓ • 2013/04 ヤフー⼊社 • 2013/07~ ユーザの属性情報を扱うシステムを担当 • 2015/10~ 社内向けのWebAPI実⾏環境を担当 • 2016/04~ メッセージキュー「Pulsar」を担当 OSS化に関わる Apache Pulsar PMC member © Yahoo Japan 2

公開 今回のアジェンダ 1. 背景 2. トピックの所有権とバンドル 3. バンドルの動的再割り当て 4. 負荷分散に関する最近の動向 © Yahoo Japan 3

公開 今回のアジェンダ 1. 背景 2. トピックの所有権とバンドル 3. バンドルの動的再割り当て 4. 負荷分散に関する最近の動向 © Yahoo Japan 4

公開 1. 背景 マルチテナント • Pulsarの⼤きな特徴の1つ • 単⼀のシステムを複数の利⽤者が共⽤する形態 • 多種多様なサービスを持つヤフーにとっては利点が多い • • • リードタイムが短くて済む • システム運⽤を専⾨部署に集約できる • 運⽤コストを削減できる 要件 • ⽔平⽅向にスケーラブルでなければならない • 複数のサーバ間で均等に分散されるのが望ましい • ノイジーネイバー問題を回避したい どのように負荷分散を⾏っているのか︖ © Yahoo Japan ショッピング オークション ニュース 検索 天気・災害 知恵袋 ファイナンス トラベル メール 5

公開 1. 背景 今回のスコープ 今回はBrokerにおける負荷分散の仕組みにフォーカス Producer Broker Metadata Store Metadata Store Metadata Store Consumer Configuration Configuration Configuration Store Store Store Broker Producer Broker Consumer Bookie © Yahoo Japan Bookie Bookie Bookie 6

公開 今回のアジェンダ 1. 背景 2. トピックの所有権とバンドル 3. バンドルの動的再割り当て 4. 負荷分散に関する最近の動向 © Yahoo Japan 7

公開 2. トピックの所有権とバンドル Brokerによるトピックの所有権について • Pulsarでは原則としてあるトピックはただ1つのBrokerのみが担当 • そうでなければ順序保証の実現が難しい • 実際にはトピック単体ではなくバンドルという単位で担当が割り当てられる • Pulsarにおけるトピックは次のような階層構造を持つ persistent://shopping/production/cart テナント ∋ ネームスペース ∋ バンドル ∋ トピック エンドユーザが存在を意識する事はない © Yahoo Japan 8

公開 2. トピックの所有権とバンドル バンドルとは • 同じネームスペースのトピックを複数まとめたもの • トピックの所有権はバンドル単位で決定される • 8桁の16進数値のレンジで表現される • 負荷に応じて分割される（⼀度分割されると元に戻る事はない） 0x00000000_0xffffffff 0x00000000_0x7fffffff persistent://public/default/topic1 persistent://public/default/topic1 分割 0x7fffffff_0xffffffff persistent://public/default/topic2 persistent://public/default/topic2 © Yahoo Japan 9

公開 2. トピックの所有権とバンドル どのようにしてバンドルの所有権は決まるのか︖ Broker B (Leader) Broker A Client Broker C LookupTopic (authoritative=false) LookupTopicResponse (authoritative=false, LookupType=Redirect) Leaderにリダイレクト LookupTopic (authoritative=false) 所有権を与えるべき Brokerにリダイレクト LookupTopicResponse (authoritative=true, LookupType=Redirect) LookupTopic (authoritative=true) 所有権を獲得 LookupTopicResponse (authoritative=true, LookupType=Connect) © Yahoo Japan 10

公開 2. トピックの所有権とバンドル 所有権を与えるべきBrokerとは︖ • 基本的には最も低負荷なBrokerが選択される • 具体的なアルゴリズムはLoad Managerの実装によって異なる • Noop Load Manager • Simple Load Manager • Modular Load Manager (default as of v3.0.0) • Extensible Load Manager (since v3.0.0) • 管理者はどのLoad Manager実装を採⽤するか設定可能 • 今回は現在ヤフーで使⽤しているModular Load Managerのアルゴリズムを説明 © Yahoo Japan 11

公開 2. トピックの所有権とバンドル Modular Load Manager • クラスタ内のBrokerのリストから候補を絞り込んでいく 1. 担当しているトピックの数が閾値（変更可能）を超えるBrokerを除外 2. 担当している同じネームスペースのバンドルの数が最少でないBrokerを除外 3. Leaderとは異なるLoad Managerの実装を使⽤しているBrokerを除外 • • 残った候補の中からバンドル割り当てのストラテジ（選択可能）に基づいて1つの Brokerを選出 LeastLongTermMessageRate メッセージレートが低いものを選出 LeastResourceUsageWithWeight リソース使⽤率が低いものを選出 RoundRobinBrokerSelector ラウンドロビン 選出されたBrokerのリソース使⽤率が閾値（変更可能）を超えている場合、1~3 の除外を⾏わずにストラテジに基づいた選出をやり直す © Yahoo Japan 12

公開 今回のアジェンダ 1. 背景 2. トピックの所有権とバンドル 3. バンドルの動的再割り当て 4. 負荷分散に関する最近の動向 © Yahoo Japan 13

公開 3. バンドルの動的再割り当て ⼀度決まったバンドルの割り当てがずっと適切とは限らない • あるトピックのトラフィックが増減するかもしれない • あるバンドルに所属するトピックが増減するかもしれない • クラスタ内のBrokerの数が増減するかもしれない バンドルは動的に分割・再配置される © Yahoo Japan 14

公開 3. バンドルの動的再割り当て バンドルの⾃動分割 • あるクラスタにおけるバンドル分割の決定権はLeaderが持つ • 定期的に下記のいずれかの値が閾値（設定可能）を超えているバンドルを抽出 • • • トピックの数 • クライアントの数 • メッセージレート • スループット ネームスペースのバンドル数が最⼤値（設定可能）未満ならバンドルを⼆分割 • トピックがどちらのバンドルに所属するかはトピック名のハッシュ値から決まる • 必ずしもトピック数やトラフィックが均等になるとは限らない 分割後のバンドルは⼀時的に所有権が外され（アンロード）、クライアントが再 接続する事によって再割り当てされる © Yahoo Japan 15

公開 3. バンドルの動的再割り当て バンドルの⾃動アンロード • バンドルの分割時以外にもアンロードは動的に⾏われる • Leaderがクラスタ内に⾼負荷なBrokerがいないかを定期的にチェック • 負荷削減のストラテジ（選択可能）に基づいて⾼負荷なBrokerを抽出し アンロードを実⾏ • OverloadShedder • ThresholdShedder (default as of v3.0.0) • UniformLoadShedder © Yahoo Japan 16

公開 3. バンドルの動的再割り当て OverloadShedder リソース使⽤率が閾値を超えたらアンロードを実⾏ Leader Broker Unload loadBalancerBrokerOverloadedThresholdPercentage: 85% CPU: 89% Direct Memory: 33% Bandwidth In: 59% Bandwidth Out: 81% CPU: 19% Direct Memory: 11% Bandwidth In: 40% Bandwidth Out: 64% Direct Memory: 1% Bandwidth In: 1% Bandwidth Out: 1% Broker 1 Broker 2 Broker 3 © Yahoo Japan CPU: 3% 17

公開 3. バンドルの動的再割り当て ThresholdShedder 全Brokerのリソース使⽤率の平均値＋閾値を超えたらアンロードを実⾏ Leader Broker loadBalancerBrokerThresholdShedderPercentage: 10% (89 + 64 + 3) / 3 + 10 = 62% ※実際には過去の履歴や重みが考慮されるためもっと複雑 Unload CPU: 89% Direct Memory: 33% Bandwidth In: 59% Bandwidth Out: 81% CPU: 19% Direct Memory: 11% Bandwidth In: 40% Bandwidth Out: 64% Direct Memory: 1% Bandwidth In: 1% Bandwidth Out: 1% Broker 1 Broker 2 Broker 3 © Yahoo Japan CPU: 3% 18

公開 3. バンドルの動的再割り当て UniformLoadShedder 最も⾼負荷なBrokerと最も低負荷なBrokerの差が閾値を超えたらアンロードを実⾏ Leader Broker loadBalancerMsgRateDifferenceShedderThreshold: 50% loadBalancerMsgThroughputMultiplierDifferenceShedderThreshold: 4x 100 * (9680 - 98) / 98 = 9777% 284 / 2 = 142 Unload Rate: 9680 msg/s Throughput: 284 MiB/s Rate: 512 msg/s Throughput: 12 MiB/s Throughput: 2 MiB/s Broker 1 Broker 2 Broker 3 © Yahoo Japan Rate: 98 msg/s 19

公開 今回のアジェンダ 1. 背景 2. トピックの所有権とバンドル 3. バンドルの動的再割り当て 4. 負荷分散に関する最近の動向 © Yahoo Japan 20

公開 4. 負荷分散に関する最近の動向 従来の負荷分散メカニズムの抱える課題 • ZooKeeperに負荷やバンドルのデータを保存・共有している • • バンドルの割り当て・分割・アンロードをLeader Brokerのみが実⾏している • • Pulsarクラスタが巨⼤になってくるとスケーラビリティに⽀障をきたす Leader Brokerがボトルネックとなり得る アンロードが起きると再割り当てが完了するまでトピックは利⽤不能になる • 利⽤不能時間をなるべく短縮したい © Yahoo Japan 21

公開 4. 負荷分散に関する最近の動向 New Pulsar Broker Load Balancer • 負荷分散メカニズムを刷新するプロジェクト • 従来のメカニズムと選択可能にする • Extensible Load Manager • 負荷データをZooKeeperではなくTableViewに保存・共有 • バンドルの割り当て・分割を各Brokerに委任 • 事前にバンドルの再割り当てを⾏ってからクライアントの接続を閉じる • v3.0.0から利⽤可能 • 将来的にはデフォルト実装とする事も予定している © Yahoo Japan 22

公開 まとめ • Pulsarではトピックを担当するBrokerが負荷に応じて動的に変更される • 管理者が負荷分散のストラテジや閾値を⾃由に設定可能 • 最近新たな実装であるExtensible Load Managerが追加された © Yahoo Japan 23

公開 © Yahoo Japan