Apache Pulsar で実現する大規模広告検索システム @PulsarMeetupJapan_20190905

Apache Pulsar で実現する 大規模広告検索システム 2019年9月4日 ヤフー株式会社 石田 遊也 Apache Pulsar Meetup Japan #3 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

アジェンダ • 自己紹介 • 広告検索システムの概要 • 広告検索システムにおけるPulsarの活用 • Pulsarの3つのポイント • 細かい話 • まとめ 2

自己紹介 • 石田遊也 • 2017年4月~ ヤフー株式会社 • 広告検索システムの開発運用 • 海辺や森の中で暮らしたい 3

広告検索とは？ ユーザと相性の良い広告を配信 • ユーザの情報がクエリで、広告が検索 結果となるイメージ ①広告情報を入稿 広告主 Y! ②クエリ（ユーザ情報） ③検索結果（広告） ユーザ 4

広告検索システムの概要 広告検索の問題設定についての詳細 • 広告配信のための高速疎ベクトル検索エ ンジンの開発@WebDBフォーラム2015 • https://www.slideshare.net/tec hblogyahoo/webdb2015- webdbf2015 5

広告検索システムとPulsar 1秒あたり平均 約130,000通 のメッセージを処理するなど活躍中 6

広告検索システムの概要図 広告主 DB/API PULSAR API AIモデル 配信制御 + openstack. Feeder PULSAR 検索エンジン リージョンA リージョンB PULSAR 検索エンジン 7

広告検索システムの概要図 広告主 DB/API PULSAR API AIモデル 配信制御 + openstack. Feeder PULSAR 検索エンジン リージョンA リージョンB PULSAR 検索エンジン API • 検索用データの受け口 • レスポンス速度が障害とならないよう、素早い応答が必須 • Web APIとFeederを別コンポーネントに分けて非同期処理 • DBにデータを書き、PulsarにProduceする 8

広告検索システムの概要図 広告主 DB/API PULSAR API AIモデル 配信制御 + openstack. Feeder PULSAR 検索エンジン リージョンA リージョンB PULSAR 検索エンジン Feeder • 1通知につき1回、検索用データ変換ロジックを実行 • パーティションドトピック + Failover • 冗長性確保のため、パーティション数+αのConsumerを用意 9

広告検索システムの概要図 広告主 DB/API PULSAR API AIモデル 検索エンジン • Feederで作った検索用データをindexに反映 • 3000台規模の検索エンジンのデータソースは Pulsarに一本化 • 外部DBへのクエリ発行無し • スケーラビリティはPulsarの性能に依存 • 本番運用以降事故なし • ジオレプリケーションも活用 + openstack. Feeder PULSAR 検索エンジン リージョンA リージョンB PULSAR 検索エンジン 10

なぜこのシステムにしたか？ (自前の) 検索エンジンならではの苦悩 11

検索エンジンの課題1 検索速度/負荷分散のための十分なマシン数 • 全リージョン合計で3000台に更新データ を送信 • 外部DBへのアクセスも負荷的に厳しい • 更新頻度を上げるのに問題が出る • AIの活用頻度↑↑ 12

検索エンジンの課題2 リソースは検索のみに使用したい • 更新頻度が増えるに連れ負荷が増える • 重複する更新用の処理はまとめたい • リソース増 ⇒アラート対応の確率増 13

検索エンジンの課題3 検索インデックスの管理が煩雑 • テーブル定義変更で ALTER TABLE みたいにはいかない • 新規クラスタの追加でインデックスの 再構築が必要 14

検索エンジンの課題 これらの課題をPulsarで解決 15

課題1をPulsarで解決 検索速度/負荷分散のための十分なマシン数 ⇒ Exclusive Subscriptionとジオレプリケーション で解決 • 1 Subscriptionあたり1 Consumerに限定できる • データの圧縮もPulsarで • LZ4, ZLIB, SNAPPY, ZSTD • メッセージスキーマ 16

課題2をPulsarで解決 リソースは検索のみに使用したい ⇒ PulsarのFailover Subscriptonでメッセージの順 序保証がされた前処理クラスタ（Feeder）を作成 • 各Consumerは同じSubscription • 検索エンジン内の更新処理をできる限りFeederへ • 1通知への操作がユニーク（重複なし）なため、DB へのデータ取得の負荷が上がりにくい 17

課題3をPulsarで解決 検索インデックスの管理が煩雑 ⇒ Pulsarのreset-cursorコマンドでConsumerの カーソルを過去の時間に巻き戻せるので、 indexの再 作成が容易 • 定期的に全index情報をFeederが更新 • 検索エンジンのdeploy→巻き戻しで完成 • Dispatch Throttling機能で流量制御も可能 18

これらのシステムを構築して思うこと ノウハウを抽象化すると、Pulsarは以下 の3つのケースで使うべき 19

3つのキーワード 非同期 一対多の通信 データストア 20

非同期 Producer（書き込み側） • Pulsarに書き込めばOKなのでロジック待ちがなく 高速 Consumer（読み込み側） • 大量のリクエストで性能劣化するようなことがない • Backlog数のチェックは必須 21

非同期 • 同期処理より複雑さは増す⚠ • リアルタイム性が利益に直結するケー スには向いていない⚠ • 広告のReal-Time Bidding • 証券取引 22

一対多の通信 中間の処理などの、ユニークな処理ならできるかぎり集約 • メッセージの処理順序を問わない処理 • Subscription: Shared (最速) • メッセージの処理順序が厳密な処理 • Subscription: Failover, Key_shared 最終の処理など、複数台にコピーを反映するならExclusiveを選択 • ブロードキャストのような一対多の通信 • Subscription: Exclusive (+ ジオレプリケーション) 23

データストア Cursorをreset（巻き戻し）できる $ pulsar-admin topics reset-cursor some-topic \ --subscription sub1 \ --time 60m • 下流のDBの再構築 • 性能調査、負荷試験 • Topic Compactionと併用すると高速 • > Allows for faster "rewind" through topic logs https://pulsar.apache.org/docs/en/concepts- topic-compaction/ 24

細かい話 その他細かい話 • 通知と実データは分けると吉 • マルチテナント 25

通知と実データは分けると吉 メッセージ自体にはデータを含めず、メ タデータ（primary keyなど）のみを送 り、データは別DB/APIで渡すパターン ① Producer DB/API ④ Consumer ② PULSAR ③ 26

通知と実データは分けると吉 • Consumer視点でデータ不整合が起きない • 巻き戻しても古い実データが来ない • Microservicesな外部APIの活用 • Pulsarの重複排除機能使用可能 27

マルチテナント ヤフー社内にPulsarのCommitter含む管理 チームが存在 • 一部テナントを間借りして利用 • 運用はプロにまかせる（超大事） • 我々にもKafkaを自前運用していた時 期があったが… 28

まとめ • Pulsarは3000台規模の Consumer/Subscriptionにも対応 • 非同期、一対多の通信、データストア のユースケースで使うと良い • 通知と実データは分けると吉 29