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

Cookpad Tech Kitchen #9 https://cookpad.connpass.com/event/60831/

Transcript

1. ޿ࠂϩάͷϦΞϧλΠϜूܭͱ
   ͦͷ׆༻ 2017-07-26 Cookpad Tech Kitchen #9 wata
2. 自己紹介 • 渡辺 慎也 • マーケティングプロダクト開発部 • 広告配信基盤周りの整備、開発保守 • やりたいこと • Rails でアプリを書くよりコンテンツ配信に関わ る、ミドルウェア、インフラ、プロトコルのアー キテクチャを考えることや、改善、安定運用
3. Agenda • サービス規模 • アーキテクチャ ‣ 以前 ‣ Lambda Architecture ‣ 変更後 • 活用方法について
4. サービス規模 • インスタンス • c3.xlarge, c4.xlarge で構成 • 5 〜 18 台（Auto Scaling） • ピーク時同時リクエスト数 • 2,000 req/s 以上 ※2017年7月現在
5. アーキテクチャ
6. アーキテクチャ HTML レンダリング時に JavaScript で広告配信サーバに リクエストを投げて表示する。 配信 サーバ impression log click log 302 redirect JSON Ajax
7. アーキテクチャ reverse proxy app mysql memcached fluentd queue Amazon 
 Redshift #SJDPMBHF
   4USFBNJOH
   -PBE backup batch %8) Amazon
 DynamoDB
8. アーキテクチャ reverse proxy app mysql memcached fluentd queue Amazon 
 Redshift #SJDPMBHF
   4USFBNJOH
   -PBE backup batch %8) Amazon
 DynamoDB ログデータがバッチ集計終わって mysql に入るまでに 1 時間ぐらいのラグがあった
9. もっと早くログが出ているか 確認したい！
10. そこで
11. Lambda Architecture
12. Lambda Architecture 出典元：http://lambda-architecture.net/
13. Lambda Architecture 出典元：http://lambda-architecture.net/ 既存のバッチ処理集計がここにあたる
14. Lambda Architecture 出典元：http://lambda-architecture.net/ それに speed layer を追加
15. アーキテクチャ app mysql memcached fluentd queue Amazon 
 Redshift #SJDPMBHF
    4USFBNJOH
    -PBE backup batch DWH Amazon
 DynamoDB reverse proxy
16. アーキテクチャ app mysql memcached fluentd queue Amazon 
 Redshift #SJDPMBHF
    4USFBNJOH
    -PBE backup batch DWH Amazon
 DynamoDB reverse proxy ここに
17. アーキテクチャ 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
18. アーキテクチャ 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 speed layer を追加
20. Kinesis Streams から Lambda で DynamoDB に書き込む
21. DynamoDB Streams で 次の Lambda を起動させ 1 時間単位、1 日単位で集計 （処理的には ADD）
22. 日単位の集計は 1 時間単位で集計した データを利用
23. 950 executions/min 75 〜 125ms 225 executions/min 190 〜 425ms 2900 executions/min 0.2 〜 1.0s
24. 活用方法について
25. 活用方法について • 集計データの確認方法 ‣ batch layer の集計データは mysql を参照 ‣ speed layer の集計データは DynamoDB を参照 • 使い分け ‣ batch layer はレポーティング等の正式なデータと して利用 ‣ speed layer はあくまでも速報値や確認の為に利用
26. 活用方法について • 異常検知（耐障害性） • ログの流量変化によって異常検知 • 配信制御 • 直近のデータを考慮して、高精度で制御 • 在庫予測 • 直近のデータを考慮して、予測値を最適化
27. 異常検知（耐障害性） • layer で突き合わせをしてズレを検知 ‣ batch layer の集計と、speed layer の集計を突 き合わせて、大きなズレがある場合は異常とし てエンジニアに通知する • 冗長化 ‣ 別の集計方法（完全に別ではないが）をするこ とで、DynamoDB または Redshift が落ちてい ても完全にログ集計が止まることはない
28. 配信制御 • インプレッションの出し方が単純には いかない商品がある • 例えば 500 インプレッションを 1 週 間で出す場合はなるべく平準化する必 要がある
29. 配信制御            
30. 配信制御             これでは駄目で
31. 配信制御            
32. 配信制御             平準化する
33. 配信制御 • 出しすぎてもいけないし、期間で平準 化する必要がある
34. 在庫予測 • 在庫が余った場合に、別の商品を掲出 させたいことがある。 • その場合に人手で配信設定をせずとも 直近のデータに基いて掲出量を変更す る。
35. まとめ • batch layer だけでなく speed layer も導入、活用することで ‣ 掲出確認が迅速に行えるようになった ‣ 在庫の無駄を減らすことが出来る ‣ 2 layer で集計することで、異常検知可 能
36. ຖ೔ͷྉཧΛָ͠Έʹ 5IBOL
    ZPV