2020/12/12 Devleopers Boost 2020登壇資料 Digdagを用いた大規模広告配信ログデータの加工と運用

1. Digdagを用いた
大規模広告配信ログデータの
加工と運用
株式会社マイクロアド
前西 鷹
Developers Boost 2020
#devboost

2. 自己紹介
● 前西 鷹 (Taka Maenishi)
株式会社マイクロアド
システム開発本部 アプリケーションエンジニア
○ 27歳、新卒3年目
○ 大規模なデータのバッチ処理開発を主に担当
○ 副: エンジニア広報
● 使用言語
○ ほとんどPython
● 関西出身
● Twitter
○ @taka_na_u
● 会社のTwitter: @microad_dev もよろしくお願いします。
2

3. もくじ
● 広告配信システムのログの概要
● ログの加工処理
● ワークフローエンジンDigdagの利用
● 保守・運用
● 課題
3

4. 4
広告配信システムのログ

5. 広告配信システムのログ
● 広告配信システムはRTB(入札)・インプレッション・
クリックなどのイベントに合わせてログを出力する。
○ ログの内容はそのイベントに関わるあらゆる情報
■ タイムスタンプ、SSP名(ID)、デバイス情報、ユーザ情報、入札額…
○ そのログ件数は合計すると毎日数百億件にも
5
SSP
(Supply-Side
Platform)
WEBページ
広告枠
入札
(RTB/Real-Time
Bidding)
要求広告をリクエスト
応札
広告が表示される：インプレッション
広告がクリックされる：クリック
DSP
(Demand-side
Platform)広告をレスポンス

6. ログの利用用途
マイクロアドでは、広告配信システムから出力される大量のログを
保持し、様々な用途に利用している。
例えば…
● 配信実績集計
● 監視
● 可視化
● 分析
● 機械学習
→ 生ログを加工し、それぞれの用途に合う使いやすい形にしたい。
6

7. 7
ログの加工処理

8. ログ基盤
● ログ基盤にはHadoopを利用。
● JSON形式の生ログをKafkaに蓄積し、FlumeでHadoopまで転送。
● 詳細: MicroAdのデータ基盤 - MicroAd Developers Blog
8

9. ログの圧縮処理
● Hadoopに送られた生ログに対して、長期保存のため、加工する前に
まずは圧縮処理をかけて容量を削減。
● 圧縮形式には、以下の理由からParquet形式を採用。
○ 列指向フォーマットで、大規模データの処理に適している。
○ カラム追加などのスキーマ変更が容易である。
○ データ分析に用いられるImpala等でサポートされている形式である。
● 圧縮処理は1時間ごとに行われ、タイムスタンプの情報をもとに
1時間ごとにパーティショニングして保持。
9

10. ログの加工処理
用途に合わせた加工や集計を行う。
例えば…
● 1時間毎の配信実績を集計したい。
○ RTB, インプレッション, クリックのそれぞれのログの紐付けを行い、
1つのテーブルに集約する。
● 分析や機械学習に利用するための前処理を行いたい。
○ レコード数の削減
○ カラム数の削減
○ 変換
10

11. データの転送処理
● 加工したデータを、用途に合わせて別のクラスタやデータストアに
転送したい場合も多々あり。
● 詳細: MicroAdのログ蓄積の流れ - MicroAd Developers Blog
11

12. 定期実行したい
● 絶え間なく生成され続けるログに対して、これらの一連の処理を
止めることなく実行し続けなければならない。
12

13. 13
ワークフローエンジンDigdagの利用

14. Digdagとは
● Treasure Data社が開発するOSSのワークフローエンジン。
● 特徴
○ ワークフローをYAMLで定義できる。
○ タスクをDockerコンテナ上で実行できる。
○ タスクをShell, Python, Rubyで記述可能。
○ session_timeという、バッチの処理対象時間を担保する概念がある。
■ システム時間によって処理対象が変わるなどといったことが無い。
■ リトライの時に特に便利。
○ retryやkillなどの処理がWeb UIからクリック一つで簡単に実行できる。
○ 自動リトライやアラートなどの機能も備わっている。
○ オペレータを自前で実装して追加できる。
14

15. Digdagの利用
● Hadoopに転送されたデータに対して行う定期実行のバッチ処理を
Digdagで記述。
15

16. ワークフローの記述
ワークフローファイルはYAMLに似たフォーマットで、
宣言的に記述できる。
16
taskA
↓
taskB & taskC (並列で実行される)
↓
taskD
という順番で実行される。
左図の例だと…

17. Digdagバッチ CI/CDの構成
GitHub Enterprise上のバッチ管理リポジトリの変化に応じて、
Jenkinsがビルド・テスト・コードチェック・デプロイを
自動で行う仕組みを構築。
17

18. Digdagバッチの実行環境
Digdag + Docker + Pythonで実行環境を構築。
● 詳細:
Digdagバッチの基本設計とビルドの実例紹介 - MicroAd Developers Blog
18

19. 19
保守・運用

20. バッチは失敗する
● バッチは様々な要因で失敗する。
○ データの不整合、ネットワークエラー、高負荷…
● 少しインターバルを置いた自動リトライを設定。
● しかし、手作業が避けられない場面がどうしても発生する。
20
Web UIからワンクリックで
リトライが可能
RETRY FAILED:
ワークフローの途中で失敗していた
場合、失敗したところから再開。
RETRY ALL:
最初から全て再実行。

21. 処理失敗時のアラート
● バッチが失敗した場合、速やかにそれを検知できることが望ましい。
● アラートをSlackに即時通知する仕組みを導入。
● メンション付きでSlackに通知される
○ 担当チームへメンション
○ 対応の緊急度や注意点なども同時に通知
● 詳細: アラートメールのslack通知の話 - MicroAd Developers Blog
21

22. バッチの冪等性が重要
● バッチが再実行された場合にもデータの整合性を保つ必要がある。
○ データが重複して生成されたりしてはならない。
● 冪等性を確保することを強く意識。
○ 冪等性: 同じ操作を何度繰り返しても同じ結果が得られる性質のこと。
● 具体的には
○ INSERTであればINSERT OVERWRITE(上書き)にする。
○ 1レコードずつ挿入したい場合など、上書きでは実現できない場合は
DELETEしてからINSERTするようにする。
○ cpなどのコピーも必ず上書きするオプションをつける。
22

23. Digdagを導入してみて
● Digdagを導入して約2年ほど運用を続けている。
○ 従来のJenkinsやcrontab等のスケジュール実行方法に比べて、
メンテナンス性が向上し、大規模データに対する処理フローも安定稼働。
○ 障害発生時の即時通知のおかげで、可用性の高いシステムに。
○ 導入前と比較して、手動による運用コストが大幅削減。
● 現在マイクロアドでは、200以上ものDigdagバッチが稼働。
23

24. 24
課題

25. 課題
● 同時実行できるタスクの数に上限がある。
○ 設定値で増やすことはできるが、負荷とのトレードオフ。
○ 依存関係のあるバッチが止まってしまうと、後続処理が進まなくなる
ため、上限数にぶつかってしまう。
25

26. 26
まとめ

27. まとめ
● 広告配信ログを圧縮した後、様々な加工を施して保持している。
○ ログ基盤にはHadoopを採用。
○ 必要に応じて他のデータストアにも適宜転送。
● 圧縮や加工などのバッチ処理はDigdagを用いたワークフローで管理。
○ ワークフローをソースコードで管理できる。
○ メンテナンスが非常にしやすい。
○ JenkinsによるCI/CDによる開発フローを整備。
○ バッチ実行環境にはDocker + Pythonを採用。
● 運用における工夫
○ バッチが失敗したことを素早く検知できる仕組みを導入。
○ 再実行された場合にもデータに不整合が生じないように、冪等性を担保。
○ 手動による運用コストを最小限にするため試行錯誤している。
● 課題
○ 同時実行できるタスクの数に上限がある。
27

28. We Are Hiring!!
28
マイクロアドでは、広告配信システムを一緒に作りたい人を
募集しています！
https://recruit.microad.co.jp/
公式Twitterアカウント @microad_dev もよろしくお願いします。

29. 29
ご清聴ありがとうございました！