More Related Content
Similar to アドテクを支える技術 〜1日40億リクエストを捌くには〜 (20)
More from MicroAd, Inc.(Engineer) (18)
アドテクを支える技術 〜1日40億リクエストを捌くには〜
- 2. 自己紹介
● 名前: 大澤 昂太
● 職歴:
○ アドテクとかよく知らなかったものの、2016年新卒でマイクロアドに入社
○ SkyMagicという部署で小型ドローンの開発とドローンの集中制御ソフトの開発に参加
○ データエンジニア部署に移動してデータ基盤周りの開発に参加
○ 現在 DSP開発部署でチームリーダーをしています
■ 高速化周りの仕事が多いです
● 趣味
○ 基本家が好きで、本を読んだり映画を観ています
○ 外に出るとダイビング、操船、山登り等をすることが多いです
2
船酔い 筋肉痛 意外と寒い
- 5. ターゲティング広告
● インターネット広告の始まりは日本だと1996年頃
● 最初はHTMLに直接広告を埋め込んでいた
● 広告を管理するアドサーバの登場によって、広告枠に動的に広告が表示できるようになる
● アクセス情報、IP、時間帯等に応じて広告を出し分けられる (ターゲティング広告)
● 具体的には下記のターゲティングが可能 (マイクロアドで利用可能な機能のみ掲載)
○ デバイスターゲティング
○ プレースメントターゲティング
○ オーディエンスターゲティング
○ ロケーションターゲティング
○ タイムターゲティング
○ ・・・
5
Webページ
広告
Webページ
広告
Webサーバ
アドサーバ
Webサーバ
Cookie、IP、時間等を利用してユーザに
適切な広告を配信
予約しておいた広告を配信
アドサーバ以前 アドサーバ以降
- 6. DSP/SSPへの変遷
● 最初の頃、広告主はメディアや広告枠を選定して購入する必要があり手間がかかった(純広告)
● また、メディアは広告在庫が売れ残るリスクがあった
● そこで、複数メディアの広告枠をまとめて販売するアドネットワークが登場
● しかし広告主、メディア双方にとってデメリットがあった
○ 広告主: 掲載面を選べないので、出したくないメディアにも広告が出る
○ メディア: 適正な価格で取引できない
● そこで、オークションの機能を持ったアドエクスチェンジが登場
● アドエクスチェンジを構成するツールがDSP (Demand Side Platform), SSP (Supply Side Platform)
● だったが、RTBが主流になり、DSP/SSPが直接繋がるようになる
6
Webページ
広告
Webページ
広告
Webページ
広告
アドネットワーク 広告主
広告枠をまとめて購入
アドエクスチェンジ DSP
SSP
買いたい価格で買う
売りたい価格で売る
オークション方式で取引
SSP
DSP
RTB (Real Time Bidding)
DSP
DSP
SSP
SSP
SSPとDSP同士が相互に繋がる
アドネットワーク アドエクスチェンジ DSP/SSP
- 7. 広告の品質維持
昨今、インターネット広告の品質問題が注目されている
● ブランドセーフティ - 不適切なメディアへの配信による広告主のブランド毀損の懸念がある
● アドフラウド(広告詐欺) - ネット広告の仕組みを悪用して広告主からお金を引き出す問題
漫画村等の違法サイトが話題の時にこれらも問題になり広告を掲載していた広告代理店等が炎上した
7
アドベリフィケーションの重要性が増す
DSP DB
ブランドセーフティ
API
アドフラウドAPI
URL/IPで問い合わせ
アドベリ関連のソリューションを提供している会社例
DSPによるアドベリの活用
- 13. 増え続ける広告在庫
● DSPビジネスの拡大とともに扱う広告在庫は増大 ※広告在庫とは広告の表示可能回数のこと
● 1度のオークションで出来るだけ多くの広告在庫を入札候補にしたい
● 多くの広告在庫を扱える = より精度の高い広告を配信可能 = 高い広告効果
○ また、たくさん表示可能なため単純に売上が伸びる
● 一方で扱う広告の増大は処理負荷の増大に直結
● 少なくても業務は成り立つけどビジネスが拡大できない
13
多くの広告在庫を扱えることは業務が成立する十分条件
SSP DSP
入札要求
応札
化粧品関連のページから
リクエスト
うーん・・・とりあえず健
康関連? DSP 化粧品が最適!
(略)
入札要求
応札
DSP
(略)
入札要求
応札
(タイムアウト)
化粧品
関連
健康
関連
旅行
関連
広告在庫
健康
関連
旅行
関連
広告在庫
旅行
関連
健康
関連
化粧品
関連
広告在庫
・・・
お、おおすぎる!
処理が間に合わねぇ
広告在庫が少ないと・・・ 広告在庫が多いと 広告在庫が多過ぎると
処理が間に合わず機会損失が発生するのは
もったいない!
こうならないようにエンジニアが頑張る
- 19. Scala
● JVM言語(Javaの基盤に乗る言語)の1つ
● 静的型付け言語
○ 型推論・パターンマッチング
● Java製ライブラリと相互運用可能
● オブジェクト指向と関数型プログラミングの概念を持つ
● 充実したコレクションAPI
○ ループ処理ではなく述語関数によって表現
19
object Main extends App {
println("Hello world")
}
Seq(1,2,3,4,5)
.map(_ * 2)
.filter(_ > 5)
> Hello world
> Seq[Int] = List(6, 8, 10)
Hello worldの例 述語関数を使った例(for文を使わずにループ処理)
- 20. なぜScalaなのか
● 業務ロジックを安全に書ける
○ 言語がカバーできる業務ロジックの範囲が広く、誤ったロジックを書くと開発中に警告する
○ 関数型言語の特徴があり、バグが発生しやすいコードを避ける事が推奨されている
○ null関連のエラーを発生させない構造
■ 総じてランタイムエラーが発生しづらい
● 安心してデータベースを利用できる
○ データベース周りの活発なプロジェクトが多いJava言語の資産を使用できる
○ 変わったデータベースへもアクセスする手段が用意されている事も多い
● 生産性が高い
○ 関数型特有の癖があるものの、標準ライブラリが強力で複雑な事が短くコーディング出来る
● 実行速度が割と早い
○ Javaに近いくらいは速度を出すことが出来る
○ 上記3つのメリットを持ちながら実行速度が早い言語はそんなにない
20
- 23. アクターモデル
● アクターはメッセージ駆動の計算実体(スレッドに似ている)
○ アクターは非同期に実行される
● アクター同士(数千・数百万)が協調して1つのアプリケーションを構成する
● アトミックやロックを使わず、安全に並行並列処理が実装できる
○ アクターはメールボックス(メッセージキューみたいな)を持っていて、1度に1つ処理
● アクターはfire-and-forget(撃ちっぱなし)の性質によって、非同期処理を実現している
● スケーラビリティのためにアクター同士は疎結合になっている
○ 空間/位置: 位置透過性とも。同じノード、異なるノード等、どこにアクターがいても良い
○ 時間: アクターはタスクの完了について何も保証しないし、期待もしない
○ インターフェース: アクター同士は何も共有しない。インタフェースが正しいかとか関係ない
23
Actor
Actor
Actor
メッセージ送信
メッセージ送信
メッセージ送信
アクターシステム
メールボックス
(メッセージキュー)
アクターは非同期で動作するのでア
クターの数だけ並行並列に動作可
能
ロックとかアトミックな操作は一切不
要
メッセージを受信し
て何か処理
- 35. 広告の配信時間制御処理周りの改修
● 時間に応じてある広告の配信を開始したり取りやめたりする処理が存在する
● ここが重くなってきた事が調査でわかったので最適化をかける
● 時間制御するために時間が一致する広告が存在するか確認する処理が線形探索O(n)になっていた
● 二分探索木を導入してO(logn)になるように修正を行う事を検討した
● 二分探索木を導入するには事前に対象がソートされている必要がある
● 処理対象のデータを直接ソートしてしまうと、広告がこの処理に特化して並んでしまう
(他の制御で似たようなことが起きたときに、様々なデメリットが発生)
● 並び順情報を別で保持するインデックスという仕組みを作成してそこに対して二分探索を実施するよう
にした
● クラスの中にインデックスを隠す事で従来のユニットテストを再利用出来るようにした
35
広告在庫 開始時間インデックス
クライアント
クラス
従来どおり
アクセス
内部ではインデックスを利用した
アクセスにすり替わっている
広告在庫クラス 終了時間インデックス
広告
(時間内)
広告
(時間内)
広告
(時間外)
広告
(時間内)
有効な広告を探す
- 37. パフォーマンスに対するアプローチ まとめ
● スループット量の向上にはマルチスレッドが効く
○ 並列処理に強いScala
○ 高度な並列処理機能を持つAkkaフレームワーク
● 大量の広告在庫に対応するには計算をなるべく避ける
○ 広告在庫に応じて計算をなるべく増やさないようにする
○ 広告在庫自体の処理を高速化して底上げを図る
● レスポンス速度の向上には処理のボトルネック解消が必要
○ データベースへのアクセスを削減する
○ アルゴリズムの導入を検討する
37
今後も、まだまだ3つの軸の改善が必要