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

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

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

3
⾃⼰紹介
• ⽯⽥遊也
• 2017年4⽉〜
ヤフー株式会社
• 広告検索システムの開発運⽤
• 海辺や森の中で暮らしたい

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

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

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

広告検索システムの概要図
7
リージョンA
リージョンB
$広告主
%AIモデル
配信制御
&
+
Feeder
DB/API
検索エンジン
"
💁
📱
💻
API
検索エンジン

8
リージョンA
リージョンB
$広告主
%AIモデル
配信制御
&
+
Feeder
DB/API
検索エンジン
"
💁
📱
💻
API
検索エンジン
API
• 検索⽤データの受け⼝
• レスポンス速度が障害とならないよう、素早い応答が必須
• Web APIとFeederを別コンポーネントに分けて⾮同期処理
• DBにデータを書き、PulsarにProduceする
👉

9
リージョンA
リージョンB
$広告主
%AIモデル
配信制御
&
+
Feeder
DB/API
検索エンジン
"
💁
📱
💻
API
検索エンジン
Feeder
• 1通知につき1回、検索⽤データ変換ロジックを実⾏
• パーティションドトピック + Failover
• 冗⻑性確保のため、パーティション数＋αのConsumerを⽤意
👈

10
リージョンA
リージョンB
$広告主
%AIモデル
配信制御
&
+
Feeder
DB/API
検索エンジン
"
💁
📱
💻
API
検索エンジン
検索エンジン
• Feederで作った検索⽤データをindexに反映
• 3000台規模の検索エンジンのデータソースは
Pulsarに⼀本化
• 外部DBへのクエリ発⾏無し
• スケーラビリティはPulsarの性能に依存
• 本番運⽤以降事故なし
• ジオレプリケーションも活⽤
👉
👉

なぜこのシステムにしたか︖
11
（⾃前の）検索エンジンならではの苦悩

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (11)

Featured

Featured (20)

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