BPStudyでの講演資料です

1. The new
LINE Ads Platform
BPStudy
LINE Corp. Ad Platform 開発室
Tokuhiro Matsuno

2. Self introduction
 LINE 株式会社 Ad Platform 開発室 副室長
 Tokuhiro Matsuno
 広告関連の開発マネージャーを担当しています
 Perl5 の module をいろいろ書いたり、Perl6 のコミッターだったりしま
す。
 今回の話には出てきませんが、弊社では Perl エンジニアを採用してます。

3. What’s LINE Ads Platform?
 LINE の Timeline/News 等に広告配信可能
 LINE マンガなどのファミリーサービスにも配信

4. 歴史
 2016 年 LINE Ads Platform リリース
 2018 年夏 新システムリリース

5. 新システムを今夏リリースしました
 ログのリアルタイム集計
 広告インデキシングの高速化
 DSP のオンライン学習

6. LINE Ads Platform の仕組み

7. 1.Real Time Bidding –
Auction
2.Impression
3.Click
4.Conversion

8. DSP
Demand Side Platform
Media
SSP
Supply Side
Platform
1.Ad Request 2.Bid Request
Bid Bid
3. Ad List4. Ad List
ざっくりした RTB の仕組み

9. なるほどわからん。

10. 実際のところどう動くのか?
DSP MySQL
DB
LAP DSP CMS

11. DSP CMS から登録された広告をDSP配信
サーバーへ登録する
DSP MySQL
DB
登録されている広告リストを
ファイルとして配布する
DSP 配信サーバー
Go で書かれている

12. 一方そのころ。。

13. 広告表示したいんですけど。。
というHTTP Request
SSP
SSP = Supply Side Platform

14. SSP
LAP Guaranteed Ad DSP
LAP Performance Ads
DSP
3rd party DSP
並行して複数の DSP にリクエストを投げます
OpenRTB というプロトコルで一応標準化されている
DMP

15. SSP
LAP Guaranteed Ad DSP
LAP Performance Ads
DSP
3rd party DSP
• 入札価格
• 広告のタイトル
• 画像のURL
Imp発生時にコールしてほしいURL
• クリックしたときの遷移先URL
などなど。。
SSP 側は一番パフォーマンスの高い広告を選んでアプリ側に返却する

16. まとめると。。
SSP
LAP
Guaranteed Ad
DSP
LAP
Performance
Ads DSP
3rd party DSP
DSP MySQL
DB

17. 1.Real Time Bidding –
Auction
2.Impression
3.Click
4.Conversion

18. Impression
 広告が表示されたことを記録するということ

19. Impression 報告フロー
SSP
LAP
Performance
Ads DSP
DSP報告用URL
[DSP報告用URL,
SSP報告用URL]
DSP Tracker
SSP Tracker
Storage
Tracker からの登録時には Kafka を経由している

20. 1.Real Time Bidding –
Auction
2.Impression
3.Click
4.Conversion

21. Click 報告フロー
SSP
LAP
Performance
Ads DSP
DSP報告用URL
[DSP報告用URL]
DSP Redirector
Storage

22. 1.Real Time Bidding –
Auction
2.Impression
3.Click
4.Conversion

23. Conversion 報告フロー
広告主の成果発生
WebPage
<LINE Tag/>LINE Tag Server
Storage
JoinerStorage

24. Apps
Overview
Ad SDK
SSP DSP
Event
Tracker
Log
Storage
OpenRTB
本来であれば
DSPのCTRの推定とか、自動
入札の最適化とかのあたり
がホットですが、
今日はそのあたりの話はし
ません 。
そのあたりは 11/21 の LINE
DEVELOPER DAY で話がある
のでお越しください。

25. もっと複雑なアーキテクチャ図
Apps
Ad SDK
SSP
Performanc
e DSP
Event
Tracker
Log
Storage
Guarrantee
ed DSP
DMP
DPA
DSP CMS

26. コンポーネントは独立している
 Architecture はバラバラ
 それぞれのコンポーネントの Development Lead がアーキテクチャ等
は決定する
 揃えられる部分は揃える
 トラフィックが膨大なので、高速であることが必須
 コンパイル型言語必須
 突拍子もないものはダメ

27. システムの選択
 膨大なトラフィック
 膨大なログ
 データの保存
 ML
 Rust?

28. We’re using Private Cloud
 弊社はMessagingアプリなども運用しておりサーバー台数がめちゃん
こあるので、オンプレで運用しています
 OpenStack ベースで Private Cloud を運用
 IaaS
 PaaS
 DNS
 MySQL
 Kafka

29. Apps
ここからは個々のコンポーネントの開発の話
Ad SDK
SSP DSP
Event
Tracker
Log
Storage
OpenRTB

30. SSP
 Real time bidding している
 複数のDSPにパラレルでリクエストを投げて、結果を
オークションする
 Media のためのサーバー
 Written in Java 8 + Spring Boot 2 + Tomcat
LAP SSP
LAP DSP
External
DSP

31. DSP
 広告主の利益が最大化するように、最適な広告を配信する
 Real Time Bidding を実施する
 CTR Prediction/CVR Prediction
 自動単価調整
 広告に興味がありそうなユーザーに対して高値でビッドする
 Written in golang + net/http LAP SSP
LAP DSP
External
DSP

32. Event Tracker/Data Pipeline
 広告が「Impression=表示された」、「Clickされた」などのログを受信す
る。
 ログはすべて保存される。
 データの処理・Reporting を担当
 Java 8 + Spring Boot 1.5
 Spark Streaming
 Kafka
 ETL is using airflow

33. グローバルな開発体制のために
どんな技術を採用したのか

34. 開発の体制
 日本と韓国に開発と企画が別れています

35. Planner Developer
DSP CMS JP KR
DSP Serving KR KR
SSP CMS JP JP
SSP Serving JP JP
DMP JP JP
Guaranteed Ads KR KR
Data Pipeline KR KR

36. Why Kafka? → Distributed streaming system
Kafka
• Reliable/Distributed
• Buffering
• 再送処理が不要
• 1 producer, multiple consumer
• team 責任境界の明確化
DSP
DPA
SSP
Data
Pipeline
DMP

37. Binary Serialization
 Saving Storage
 Improve throughput
 AVRO/Protobuf を併用

39. どのようにコミュニケーションして
いるのか?

40. 英語?
 英語ももちろん使うが、日韓の機械翻訳も併用しています。
 System Specification の定義などは英語。

42. チャットで難しいときは?
 同時通訳を介したコミュニケーション
 Polycomのテレビ会議が全拠点に導入済み
 気軽に韓国に出張に行く
 フライト2時間ぐらいなので僕は月イチぐらいで行ってます
 Face to Face で話すと情報量がやっぱり多い!

43. Conclusion
 広告プラットフォームを1から作りました
 技術スタックは現場の判断で柔軟に選んでいます
 Global なチームで開発を進行しています

44. We’re hiring!
Let’s create great ad platform with
us.