広告ログのリアルタイム集計とその活用 / Realtime Ad log aggregation and utilization

by wata

Slide 1

Slide 1 text

޿ࠂϩάͷϦΞϧλΠϜूܭͱ ͦͷ׆༻ 2017-07-26 Cookpad Tech Kitchen #9 wata

Slide 2

Slide 2 text

自己紹介 • 渡辺慎也 • マーケティングプロダクト開発部 • 広告配信基盤周りの整備、開発保守 • やりたいこと • Rails でアプリを書くよりコンテンツ配信に関わる、ミドルウェア、インフラ、プロトコルのアーキテクチャを考えることや、改善、安定運用

Slide 3

Slide 3 text

Agenda • サービス規模 • アーキテクチャ ‣ 以前 ‣ Lambda Architecture ‣ 変更後 • 活用方法について

Slide 4

Slide 4 text

サービス規模 • インスタンス • c3.xlarge, c4.xlarge で構成 • 5 〜 18 台（Auto Scaling） • ピーク時同時リクエスト数 • 2,000 req/s 以上 ※2017年7月現在

Slide 5

Slide 5 text

アーキテクチャ

Slide 6

Slide 6 text

アーキテクチャ HTML レンダリング時に JavaScript で広告配信サーバにリクエストを投げて表示する。配信サーバ impression log click log 302 redirect JSON Ajax

Slide 7

Slide 7 text

アーキテクチャ reverse proxy app mysql memcached fluentd queue Amazon   Redshift #SJDPMBHF 4USFBNJOH-PBE backup batch %8) Amazon  DynamoDB

Slide 8

Slide 8 text

アーキテクチャ reverse proxy app mysql memcached fluentd queue Amazon   Redshift #SJDPMBHF 4USFBNJOH-PBE backup batch %8) Amazon  DynamoDB ログデータがバッチ集計終わって mysql に入るまでに 1 時間ぐらいのラグがあった

Slide 9

Slide 9 text

もっと早くログが出ているか確認したい！

Slide 10

Slide 10 text

そこで

Slide 11

Slide 11 text

Lambda Architecture

Slide 12

Slide 12 text

Lambda Architecture 出典元：http://lambda-architecture.net/

Slide 13

Slide 13 text

Lambda Architecture 出典元：http://lambda-architecture.net/ 既存のバッチ処理集計がここにあたる

Slide 14

Slide 14 text

Lambda Architecture 出典元：http://lambda-architecture.net/ それに speed layer を追加

Slide 15

Slide 15 text

アーキテクチャ app mysql memcached fluentd queue Amazon   Redshift #SJDPMBHF 4USFBNJOH-PBE backup batch DWH Amazon  DynamoDB reverse proxy

Slide 16

Slide 16 text

アーキテクチャ app mysql memcached fluentd queue Amazon   Redshift #SJDPMBHF 4USFBNJOH-PBE backup batch DWH Amazon  DynamoDB reverse proxy ここに

Slide 17

Slide 17 text

アーキテクチャ app mysql memcached fluentd queue Amazon   Redshift #SJDPMBHF 4USFBNJOH-PBE backup batch DWH Amazon Kinesis Streams Lambda function Amazon  DynamoDB speed layer Amazon  DynamoDB reverse proxy

Slide 18

Slide 18 text

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

Kinesis Streams から Lambda で DynamoDB に書き込む

Slide 21

Slide 21 text

DynamoDB Streams で次の Lambda を起動させ 1 時間単位、1 日単位で集計（処理的には ADD）

Slide 22

Slide 22 text

日単位の集計は 1 時間単位で集計したデータを利用

Slide 23

Slide 23 text

950 executions/min 75 〜 125ms 225 executions/min 190 〜 425ms 2900 executions/min 0.2 〜 1.0s

Slide 24

Slide 24 text

活用方法について

Slide 25

Slide 25 text

活用方法について • 集計データの確認方法 ‣ batch layer の集計データは mysql を参照 ‣ speed layer の集計データは DynamoDB を参照 • 使い分け ‣ batch layer はレポーティング等の正式なデータとして利用 ‣ speed layer はあくまでも速報値や確認の為に利用

Slide 26

Slide 26 text

活用方法について • 異常検知（耐障害性） • ログの流量変化によって異常検知 • 配信制御 • 直近のデータを考慮して、高精度で制御 • 在庫予測 • 直近のデータを考慮して、予測値を最適化

Slide 27

Slide 27 text

異常検知（耐障害性） • layer で突き合わせをしてズレを検知 ‣ batch layer の集計と、speed layer の集計を突き合わせて、大きなズレがある場合は異常としてエンジニアに通知する • 冗長化 ‣ 別の集計方法（完全に別ではないが）をすることで、DynamoDB または Redshift が落ちていても完全にログ集計が止まることはない

Slide 28

Slide 28 text

配信制御 • インプレッションの出し方が単純にはいかない商品がある • 例えば 500 インプレッションを 1 週間で出す場合はなるべく平準化する必要がある

Slide 29

Slide 29 text

配信制御

Slide 30

Slide 30 text

配信制御これでは駄目で

Slide 31

Slide 31 text

配信制御

Slide 32

Slide 32 text

配信制御平準化する

Slide 33

Slide 33 text

配信制御 • 出しすぎてもいけないし、期間で平準化する必要がある

Slide 34

Slide 34 text

在庫予測 • 在庫が余った場合に、別の商品を掲出させたいことがある。 • その場合に人手で配信設定をせずとも直近のデータに基いて掲出量を変更する。

Slide 35

Slide 35 text

まとめ • batch layer だけでなく speed layer も導入、活用することで ‣ 掲出確認が迅速に行えるようになった ‣ 在庫の無駄を減らすことが出来る ‣ 2 layer で集計することで、異常検知可能

Slide 36

Slide 36 text

ຖ೔ͷྉཧΛָ͠Έʹ 5IBOLZPV