「アドテクを支える基盤 〜10Tバイト/日のビッグデータを処理する〜」 【23卒/24卒】オンライン勉強会：「アドテクを支える技術 〜1日40億リクエストを捌くには〜」 https://microad.connpass.com/event/255303/ #MicroadDevs

1. マイクロアドのデータ基盤
アドテクを支える基盤
〜10Tバイト/日のビッグデータを処理する〜
株式会社マイクロアド
根本 優太
2022/08/22 (月)
オンライン勉強会

2. 自己紹介
● 根本 優太（ねもと ゆうた）
● システム開発本部 プロダクト開発グループ ユニット4
○ ビッグデータを処理するバッチ開発をしてます
● 2021年新卒入社/社会人2年目（東京勤務）
● 略歴
○ 会津大学 コンピュータ理工学部 コンピュータ理工学科 卒業
○ 会津大学大学院 コンピュータ理工学研究科 ソフトウェア工学専攻 修了
■ web開発と検索システムの研究をしていました
● その他
○ 今年から乗馬をはじめました

3. 目次
● 広告システムでできるビッグデータとは
● データ基盤の概要
● Hadoop（分散処理）
● 処理フロー（バッチ処理）
● 保守・運用

4. 4
広告システムでできる
ビッグデータとは

5. 広告配信のログ
などのイベントに合わせて
広告配信システムがログを出力する
RTB（広告の入札)
インプレッション（広告の表示）
クリック

6. 広告配信のログ
SSP
(Supply-Side
Platform)
WEBページ
・・・・・・
・・・・・
・・・・・・
********
・・・・・
・・・・・・
・・・・・
・・・・・・
・・・・・・
・・・・・
・・・・・・
広告枠
入札要求
(RTB/Real-Time
Bidding)
広告を
リクエスト
応札
DSP
(Demand-Side
Platform)
広告を
レスポンス
広告が表示された！
広告がクリックされた！
RTBログ

7. 広告配信のログ
SSP
(Supply-Side
Platform)
WEBページ
・・・・・・
・・・・・
・・・・・・
********
・・・・・
・・・・・・
・・・・・
・・・・・・
・・・・・・
・・・・・
・・・・・・
広告枠
入札要求
(RTB/Real-Time
Bidding)
広告を
リクエスト
応札
DSP
(Demand-Side
Platform)
広告が表示された！
広告がクリックされた！
インプレッション
ログ
広告を
レスポンス

8. 広告配信のログ
SSP
(Supply-Side
Platform)
WEBページ
・・・・・・
・・・・・
・・・・・・
********
・・・・・
・・・・・・
・・・・・
・・・・・・
・・・・・・
・・・・・
・・・・・・
広告枠
入札要求
(RTB/Real-Time
Bidding)
広告を
リクエスト
応札
DSP
(Demand-Side
Platform)
広告が表示された！
広告がクリックされた！
クリック
ログ
広告を
レスポンス

9. 広告配信ログの具体例：RTBログ
入札が1回発生するごとにこんなRTBログが生成される
2022年03月現在、RTBログの件数は約50億件/日
{“time”: “2022-05-17 10:00:00”, “rtb_id”: 1, “device_id”:
“xxx”, “tagid”: “yyy”, “site_id”: “zzz”, “bid_price”: 0.1,
“ad_id”: 2, … }
※項目を抜粋・一部改変しています

10. 広告配信ログって何に使うの？
例えば…
配信実績集計
監視
可視化 分析
機械学習

11. 広告配信ログって何に使うの？
RTBログ インプレッションログ クリックログ
入札戦略の分析 配信実績の集計 配信実績の集計
請求 請求
など など など

12. 広告配信ログのデータ量
RTBログ インプレッションログ クリックログ
入札戦略の分析 配信実績の集計 配信実績の集計
請求 請求
など など など
約50億件/日 約1.3億件/日 約38万件/日
データ量は増え続けるけど... サービスは止められない
一定時間で処理を終える 必要がある

13. 13
データ基盤の概要

14. データ基盤の基本構成
ログ基盤にはHadoopを利用

15. データ基盤の基本構成
Apache Kafka: 分散メッセージキュー
Flumeに引き渡す
ログを一時的に蓄積

16. データ基盤の基本構成
Apache Flume: ログデータを収集・集約・移動する分散ソフトウェア

17. データ基盤の基本構成

18. 18
Hadoop（分散処理）

19. Hadoopとは
ポイント
● 複数のサーバを用いてクラスタを構成している
● 複数のサーバのリソースを同時に使って短時間で
大規模データを処理することが可能
大規模データを複数台のサーバで分散処理するための基盤となるミドルウェア
Hadoopクラスタ
ログ
ログ
ログ
ログ
ログ
サーバ1
ログ ログ
ログ
ログ
サーバ3
サーバ2

20. Hadoopの構成
Hadoopは多くの機能を提供している
● データストレージのHDFS
○ 複数サーバに分散して
大量のデータが保持できる
● リソース管理のYARN
○ 大量の処理を効率よくさばく
● 分散処理エンジンのMapReduce
○ 大量のデータを一気に加工できる

21. HDFSとは
HDFS(Hadoop Distributed File System)
Hadoopの分散ファイルシステム
ファイルを一定サイズに分割し、複製しつつ複数サーバで分散して保存する
この特徴により、以下のメリットが得られる
● 耐障害性
○ 一部のサーバが壊れても稼働し続けられる
● 高スループット
○ 単位時間あたりに処理できるデータ量が多い

22. YARNとは
YARN (Yet Another Resource Negotiator)
Hadoopクラスタで実行するアプリケーションのリソース管理をする
以下のような処理が含まれる
● 利用可能な計算リソースの管理
○ リソースの利用状況把握と制御(メモリ・CPU使用率など)
● 処理のスケジューリング
○ どのサーバのリソースを用いて処理を行うか決定
○ リソースを確保して、後述するMapReduceのジョブを割り当てる

23. MapReduceとは
MapReduce
複数サーバに分散されたデータを並列処理するためのアプリケーションフレームワーク
特定のテキストから単語の出現数を調査する処理例
Map処理
● 入力値をKey-Valueの形式に変換
○ 「I like dogs.」→(“I”: 1, “like”: 1, “dogs”: 1)
Reduce処理
● Keyごとに出現回数を集計して出力
○ (“I”: 2, “like”: 2)、(“dogs”: 1, “cats”: 2)

24. 24
処理フロー（バッチ処理）

25. マイクロアドのシステム
配信
バッチ
処理
機械
学習
サービスの提供 最適化
ログ 分析用
データ
分析
請求用
データ

26. バッチ処理フロー
ログ
変換
集計
処理
データ
転送
保守
運用

27. バッチ処理フロー
ログ
変換
集計
処理
データ
転送
保守
運用
大量のデータに素早くアクセスするため
Parquet
というフォーマットに変換して保存する処理
（パーケイ）

28. バッチ処理フロー
ログ
変換
集計
処理
データ
転送
保守
運用
配信システムからはJSONなどの形式でログが発生
データ量が多いので素早くアクセスしやすい
フォーマットに変換する必要がある
● データアクセスの速さ
● 大規模データの処理に適している
● 開発で扱うフレームワークとの親和性が高い
などの理由から
というフォーマットにデータを変換して保存
Parquet

29. バッチ処理フロー
ログ
変換
集計
処理
データ
転送
保守
運用
集められたログのデータを
分析用
請求用
に扱いやすい形に加工する処理

30. バッチ処理フロー
ログ
変換
集計
処理
データ
転送
保守
運用
分析用
請求用
配信最適化のための予測分析で
機械学習や分析チームに利用される
広告主への請求のため
請求担当者に利用される
1時間, 1日などの間隔で、Hiveクエリで
扱いやすいデータに加工を行っている

31. バッチ処理フロー
ログ
変換
集計
処理
データ
転送
保守
運用
集計したデータを
データ分析
請求処理
それぞれの役割で扱いやすい
DBに転送する処理

32. バッチ処理フロー
ログ
変換
集計
処理
データ
転送
保守
運用
Hadoopで集計したデータを
Redis
MySQL
などのDBやストレージに転送している
Google Cloud Storage
Webレポートで参照されるデータの蓄積
高速な参照が必要なデータを保存
請求用のデータの蓄積

33. バッチ処理フロー
ログ
変換
集計
処理
データ
転送
保守
運用
不要になったデータの削除
エラー発生の検知・対応
など

34. 34
保守・運用

35. バッチ処理は必ず成功するとは限らない
バッチは様々な要因で失敗する可能性がある
● データ不整合
● ネットワークエラー
● 高負荷
● リソース不足

36. バッチ処理は必ず成功するとは限らない
一時的な問題によるエラーの場合
何度か実行してみると成功する
→少しインターバルを置いた自動リトライを設定することで自動的に解
決
一時的な問題によるエラーではない場合
何度実行しても失敗する
→何らかの対応が必要になる

37. バッチ処理が失敗したときの対応
自動リトライを設定しても成功しなかったら
問題の検知
・まずは、問題に気づく必要がある
・監視・アラートの仕組みが必要（アラートメール、slack通知）
調査・対応
・様々なパターンの問題が発生する
・ドキュメントなど、関連する情報があると対応がしやすい（スプレッドシート）
問題が解消された後、エラーになったバッチを再実行する
・バッチを再実行しやすい仕組みが必要
・バッチを再実行しても問題が発生しないバッチの作りが大事（冪等性）
※バッチの特性や、その時の状況によっては再実行しない場合もあります。

38. バッチ処理失敗時のアラート通知のしくみ
● バッチから送信されたアラートメールをslackに通知
● 担当チームにメンションを付けて気づきやすくする
● スプレッドシートから、対応の緊急度、注意点や
仕様のリンクなど、様々な情報を読み込んで通知する
アラートメールを受信
バッチから
アラートメール送信
・アラートメールをチェック
・スプレッドシートから情報を取得
・情報を付加して slackに転送

39. バッチの再実行と冪等性
バッチが再実行された場合にも、データの整合性を保つ必要がある
・データが重複して生成されたりしてはならない
NG例1）
レコードが重複して登録され、件数が2倍になる
NG例2）
登録されないはずのデータがある（1回目の実行で登録されたものがそのまま残っている）
冪等性を確保することを強く意識
・冪等性：同じ操作を何度繰り返しても、同じ結果が得られる性質

40. バッチ処理失敗以外の異常を検知する
バッチ処理が失敗していなくても、異常が発生しつつある状況を検知する
早い段階での対応が可能になる→信頼性・可用性の向上
例）
バッチ処理の遅延
・何らかの理由で通常より時間がかかっている
集計結果の不整合
・データの異常、不具合、など、何らかの理由で数字が合わない
実行中のバッチ数
・どこかで失敗して後続のバッチが待ち状態になっている
停止中のバッチの有無
・運用作業でバッチを停止して、再開するの忘れることがある
inputデータの消化率
・何らかの理由で処理が停止／処理速度が落ちる

41. 41
まとめ

42. まとめ
● 広告配信システムから出力される大量のログデータを、Hadoopで構
成されたログ基盤で蓄積
● Hadoopは、分散処理するための基盤となるミドルウェアで、短時間
で大量のデータを処理可能
● 蓄積されたデータはバッチ処理で集計・加工・転送などが施され、請
求や分析などに利用している
● 安定稼働（信頼性・可用性）が求められるバッチ処理では、
冪等性（同じ操作を何度繰り返しても、同じ結果が得られる性質）
が重要

43. 以下で情報発信をしています！
43
43
Twitter
@microad_dev
技術ブログ
developers.microad.co.jp

44. 参考
● MicroAdのデータ基盤 - MicroAd Developers Blog
● CDH (Hadoop) 入門 - MicroAd Developers Blog
● マイクロアドのログ蓄積の流れ - MicroAd Developers Blog
● Digdagを用いた大規模広告配信ログデータの加工と運用
(2020/12/12 Developers Boost 2020登壇資料)

45. We Are Hiring!!
45
マイクロアドでは、大規模広告配信ログデータの処理システム
を一緒に開発したい人を募集しています！
https://recruit.microad.co.jp/

46. 46
質疑応答

47. 47
ありがとうございました