Upgrade to Pro — share decks privately, control downloads, hide ads and more …

スタディサプリのデータ基盤を支えるETLとパイプラインの技術 / meetup_tanda

Recruit
PRO
January 27, 2022

スタディサプリのデータ基盤を支えるETLとパイプラインの技術 / meetup_tanda

2022/01/27_スタディサプリのデータ基盤を支える技術 2022 -RECRUIT TECH MEET UP #3-での、丹田の講演資料になります

Recruit
PRO

January 27, 2022
Tweet

More Decks by Recruit

Other Decks in Technology

Transcript

  1. #Rtech
    スタディサプリのデータ基盤を支える
    データパイプラインの技術と運用
    丹田 尋
    スタディサプリのデータ基盤を支える技術 2022 ーRECRUIT TECH MEET UP #3ー

    View Slide

  2. #Rtech
    2020年リクルート新卒入社。
    データ基盤の開発・運用、移管プロジェクト
    などに携わり、現在は MLOps 周りも担
    当。
    MLを用いた顧客スコア算出・活用のプロ
    ジェクトにも参画。
    丹田 尋

    View Slide

  3. #Rtech
    Agenda | 01
    02
    03
    04
    データ基盤を支えるデータパイプラインの概要
    パフォーマンス面での4つの工夫
    データ基盤運用面での4つの工夫
    まとめと今後の展望

    View Slide

  4. #Rtech
    データ基盤を支える
    データパイプラインの概要
    01

    View Slide

  5. #Rtech
    スタディサプリのデータ基盤アーキテクチャ(簡略版)
    Kinesis + lambda + (S3)
    Serverside Log
    firebase Analytics
    Client Log (Web / App)
    Cloud Storage BigQuery
    AWS
    GCP
    PostgreSQL / mongoDB / MySQL CRM
    SecureDB

    View Slide

  6. #Rtech
    全体の処理を Cloud Composer で制御
    ➔ GCPが提供している Apache Airflow で構築された、フルマネージドのワークフ
    ローオーケストレーションサービス
    ➔ DAG(有向非巡回グラフ)形式のパイプラインを Python で記述可能
    ➔ Airflow のスケジューラーやワーカーが、
    GKE 上で動作可能
    ➔ 豊富なメトリクス画面がビルドイン
    Cloud Composer とは
    実際の定常処理のDAG

    View Slide

  7. #Rtech
    BigQuery導入で集計が高速化するも、効果は限定的
    BigQuery 導入での効果
    ➔ DWH を BigQuery へ移行することで、集計処理時間は飛躍的に高速化さ
    れた
    ◆ 例)「課金ログを元に学習者の会員ステータスを管理するテーブル」の
    集計時間が 60min(hive) → 1min(BQ) に短縮
    実際の状況
    ➔ しかし、日次処理全体の処理時間や労力が激減はしなかった
    BigQuery導入後の実際の状況

    View Slide

  8. #Rtech
    データ転送処理がボトルネックになっている
    ➔ 日次処理時間の大半が BashOperator で
    占めており、BigQueryOperator は短い
    ➔ BashOperator は、データ転送のタスクがほ
    とんど
    データ転送処理のパフォーマンスが改善できれ
    ば、全体の高速化が見込める
    BashOperator(27.3h)
    BigQueryOperator(2.8h)
    Composer での
    日次処理時間の内訳
    パフォーマンス面での課題

    View Slide

  9. #Rtech
    データ定常処理を支える運用の負担が大きい
    運用面での課題
    運用面での課題 実際に直面した苦労・失敗

    利用者との期待値調整ができておらず、
    運用者も努力目標が不明確
    ● 集計が遅延した時、どのレベルで誰に周知していいか悩んだ

    リソース管理 や CI/CD が不十分で、
    障害発生のリスクがあった
    ● オペミスにより本番環境に不要なファイルがデプロイされ定常
    処理が止まる
    ● 新たなインスタンスを立てたらモジュールがインストールされて
    おらず処理が止まった
    ③ 障害の検知に遅れることがあった
    ● 定常処理のステータスが瞬時に把握できない
    ● ディスク不足やネットワークのポートの枯渇などの把握に遅
    れ、障害が発生
    ④ 障害対応がスムーズに行かない ● 障害復旧が職人芸化され、属人化している部分があった

    View Slide

  10. #Rtech
    データの定常処理を効率化する
    パフォーマンス面・運用面での
    Tips を紹介します
    今回のテーマ

    View Slide

  11. #Rtech
    パフォーマンス面での4つの工夫
    02

    View Slide

  12. #Rtech
    日次処理における処理の平準化
    合計
    実行時間
    時間帯
    ログ
    取り込み
    マスター
    取り込み 外部データ
    取り込み
    BQ集計 外部データ
    提供
    ログ
    取り込み
    ログ
    取り込み
    外部データ
    取り込み
    ピークタイムをずらし、マシンへの 負荷の平準化
    パフォーマンスチューニングの工夫①
    Composer で使われている GKE ノードへの負荷を抑えるため、リソースが空い
    ている時間を有効活用

    View Slide

  13. #Rtech
    合計
    実行時間
    時間帯
    ログ
    取り込み
    マスター
    取り込み 外部データ
    取り込み
    BQ集計 外部データ
    提供
    ログ
    取り込み
    peak_time normal_time idle_time
    時間帯ごとにGKEノード数を設定(1日3段階)
    パフォーマンスチューニングの工夫②
    1日の中で、Composer への負荷は濃淡があるためノード数を時間帯ごとに設定
    Composer の GKE ノード数を負荷に合わせて調整
    ※BashOperator から上記のコマンドを実行

    View Slide

  14. #Rtech
    タスクの並列数を調整可能に
    パフォーマンスチューニングの工夫③
    個別のタスクの処理時間を測定し タスク並列数を調整
    ↓このように、Airflow の Variablesで
    4並列から直列に変更も可能
    サーバーサイドログ取り込み処理の Graph View

    View Slide

  15. #Rtech
    Embulk を Cloud Run で実行
    パフォーマンスチューニングの工夫④
    ➔ 複数処理による同一リソースの食い合いをサーバーレス化で解決
    ◆ 処理の高速化
    ➔ 必要な時に必要な分だけリソースを確保してくれる
    ◆ コスト面での大幅削減
    ◆ スケーラビリティの拡充
    Cloud Run

    View Slide

  16. #Rtech
    急激な負荷に迅速に対応した2つの事例
    ➔ COVID-19 で一斉休校になり、
    データ量が増大
    ◆ 処理の平準化、リソースを負
    荷に合わせて調整すること
    で対応
    ➔ 季節要因でログが急増
    ◆ 並列数を減らして最大負荷
    を下げる
    冬休み
    最終日
    GW
    最終日
    ログ取り込み時間の推移

    View Slide

  17. #Rtech
    データ基盤運用面での4つの工夫
    03

    View Slide

  18. #Rtech
    データ定常処理を支える運用の負担が大きい(再掲)
    運用面での課題
    運用面での課題 実際に直面した苦労・失敗

    利用者との期待値調整ができておらず、
    運用者も努力目標が不明確
    ● 集計が遅延した時、どのレベルで誰に周知していいか悩んだ

    リソース管理 や CI/CD が不十分で、
    障害発生のリスクがあった
    ● オペミスにより本番環境に不要なファイルがデプロイされ定常
    処理が止まる
    ● 新たなインスタンスを立てたらモジュールがインストールされて
    おらず処理が止まった
    ③ 障害の検知に遅れることがあった
    ● 定常処理のステータスが瞬時に把握できない
    ● ディスク不足やネットワークのポートの枯渇などの把握に遅
    れ、障害が発生
    ④ 障害対応がスムーズに行かない ● 障害復旧が職人芸化され、属人化している部分があった

    View Slide

  19. #Rtech
    SLAを定め、モニタリングする
    データ基盤運用面の工夫①
    ➔ データのステークホルダーと協議し
    主要データを何時までに提供する
    か合意し期待値調整をする
    ➔ 障害の条件を定義し、半年間のSLA
    をチームで決める
    ➔ 週次定例でチームメンバー全員で
    SLAの実績を確認
    SLA
    (1) 10時時点で、Table Aが作成されていること
    (2)
    12時時点で、spreadsheet吐き出しタスクが完了し
    ていること
    (3)
    13時時点で、集計データの外部連携まで完了して
    いること

    View Slide

  20. #Rtech
    CI/CDとインフラコード化を徹底し、障害を予防
    ➔ CI/CDツールとして Cloud Build を導入
    ◆ クエリチェック、パイプラインチェック、構文チェックを行う
    ● 過去のしくじり:Python ファイルのエラーでDAGが壊れ定常処理
    が走らない
    ◆ Composer , Cloud Run へのデプロイを自動で行う
    ● 過去のしくじり:デプロイ先がファイルの変更箇所に応じて2箇所あ
    り、デプロイ忘れが発生
    ➔ Terraform でのGCPコンポーネント管理
    ◆ 構成の再現性を担保
    データ基盤運用面の工夫②

    View Slide

  21. #Rtech
    監視項目を整理し、アラート設定をして障害を迅速に検知
    データ基盤運用面の工夫③
    ➔ Airflow の Operator の成功/失敗コールバックに Slack のPOST処理をか
    ませる
    ➔ 重要なテーブルデータの整合性を検証するタスクを設け Slack 通知
    ◆ 過去のしくじり
    ● Operator は成功しているが、中身のデータが不整合だった
    ➔ DAGの重複依存関係や Composer でのエラーアラートを設定

    View Slide

  22. #Rtech
    障害対応をスムーズに
    データ基盤運用面の工夫④
    ➔ ドキュメント化の徹底
    ◆ エスカレ対応の条件
    ◆ 対応方法・コツ
    ◆ 対応の心構え
    ◆ 対応時のログを残す
    誰でも同じ品質の対応ができる

    View Slide

  23. #Rtech
    スケジュールを集約しワンタッチで障害対応が可能に 
    データ基盤運用面の工夫④
    AM3:00 AM6:00 AM9:00
    旧方式
    新方式
    タスク的な依存関係はあるが、
    データ提供の時間にズレがあるた
    め、十分時間をあけて個別にスケ
    ジュールさせていた。
    上流のタスクに障害があると、全て
    のタスクを時間を置いてそれぞれ
    実行する必要があった。
    特定の時間まで後続のタスクを進
    ませない wait タスクを挟みスケ
    ジュールを1つに集約。
    1つのタスクを再実行すれば自動で
    後続も順次実行され障害対応コス
    トが下がった。
    task A
    task A
    wait B
    wait C
    task B
    task C
    task B
    task C
    新旧方式のDAG構成のイメージ図

    View Slide

  24. #Rtech
    4つのポイントを仕組み化しPDCAをまわし属人化を解消
    データ基盤運用面の工夫のまとめ

    SLA定義
    &
    モニタリング整備

    障害の予防

    障害の検知

    障害対応

    View Slide

  25. #Rtech
    まとめと今後の展望
    04

    View Slide

  26. #Rtech
    データ処理のパフォーマンス面・運用面での改善を行った
    パフォーマンス面 運用面
    ➔ 日次処理における処理の平準化
    ➔ Composer のGKEノード数を負荷に合わせて
    調整
    ➔ タスクの並列数を調整可能に
    ➔ Embulk を Cloud Run で実行
    ➔ SLAを定め、モニタリングする
    ➔ CI/CDとインフラコード化を徹底し、障害を
    予防
    ➔ 監視項目を整理し、アラート設定をして障
    害を迅速に通知
    ➔ 障害をワンタッチで対応可能に
    まとめ

    View Slide

  27. #Rtech
    今後の展望
    ➔ Composer の更なるロバスト化
    ◆ 2系で導入された Autopilot によるオートスケーリングの実現
    ➔ 新データ基盤と MLOps 基盤の連携強化
    ◆ データプロダクトごとに乱立している MLOps のシステム・運用を共通化
    し、今回紹介したデータ基盤と連携強化
    ◆ Vertex AI の活用を強化し、手軽にML開発できる仕組みを整備

    View Slide

  28. #Rtech
    ご清聴ありがとうございました

    View Slide