datatech-jp Casual Talks #5_データ基盤の立ち位置を考えるのに チームトポロジーの概念を活用した話
Die SlideShare-Präsentation wird heruntergeladen.
×
Hier ansehen
Weitere Verwandte Inhalte
Ähnlich wie アドテクを支える基盤 〜10Tバイト/日のビッグデータを処理する〜 (20)
Weitere von MicroAd, Inc.(Engineer) (20)
Aktuellste (20)
アドテクを支える基盤 〜10Tバイト/日のビッグデータを処理する〜
- 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 ありがとうございました
