Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スタディサプリのデータ基盤を支えるETLとパイプラインの技術 / meetup_tanda
Search
Recruit
PRO
January 27, 2022
Technology
4
2.3k
スタディサプリのデータ基盤を支えるETLとパイプラインの技術 / meetup_tanda
2022/01/27_スタディサプリのデータ基盤を支える技術 2022 -RECRUIT TECH MEET UP #3-での、丹田の講演資料になります
Recruit
PRO
January 27, 2022
Tweet
Share
More Decks by Recruit
See All by Recruit
Curiosity & Persistence
recruitengineers
PRO
2
30
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
84
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
33
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
2
35
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
0
37
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
1
23
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
0
23
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
4
62
技術的ミスと深堀り
recruitengineers
PRO
3
47
Other Decks in Technology
See All in Technology
入門 PEAK Threat Hunting @SECCON
odorusatoshi
0
180
Amazon Q Developerの無料利用枠を使い倒してHello worldを表示させよう!
nrinetcom
PRO
2
120
Two Blades, One Journey: Engineering While Managing
ohbarye
4
2.6k
What's new in Go 1.24?
ciarana
1
120
AI Agent時代なのでAWSのLLMs.txtが欲しい!
watany
3
360
AI自体のOps 〜LLMアプリの運用、AWSサービスとOSSの使い分け〜
minorun365
PRO
9
970
User Story Mapping + Inclusive Team
kawaguti
PRO
0
180
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
2
530
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
570
IAMのマニアックな話2025
nrinetcom
PRO
6
1.4k
AWSではじめる Web APIテスト実践ガイド / A practical guide to testing Web APIs on AWS
yokawasa
8
770
プロダクト開発者目線での Entra ID 活用
sansantech
PRO
0
120
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Designing for Performance
lara
605
68k
Unsuck your backbone
ammeep
669
57k
Into the Great Unknown - MozCon
thekraken
35
1.6k
Documentation Writing (for coders)
carmenintech
68
4.6k
We Have a Design System, Now What?
morganepeng
51
7.4k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
Optimizing for Happiness
mojombo
377
70k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
Transcript
#Rtech スタディサプリのデータ基盤を支える データパイプラインの技術と運用 丹田 尋 スタディサプリのデータ基盤を支える技術 2022 ーRECRUIT TECH MEET
UP #3ー
#Rtech 2020年リクルート新卒入社。 データ基盤の開発・運用、移管プロジェクト などに携わり、現在は MLOps 周りも担 当。 MLを用いた顧客スコア算出・活用のプロ ジェクトにも参画。 丹田
尋
#Rtech Agenda | 01 02 03 04 データ基盤を支えるデータパイプラインの概要 パフォーマンス面での4つの工夫 データ基盤運用面での4つの工夫
まとめと今後の展望
#Rtech データ基盤を支える データパイプラインの概要 01
#Rtech スタディサプリのデータ基盤アーキテクチャ(簡略版) Kinesis + lambda + (S3) Serverside Log firebase
Analytics Client Log (Web / App) Cloud Storage BigQuery AWS GCP PostgreSQL / mongoDB / MySQL CRM SecureDB
#Rtech 全体の処理を Cloud Composer で制御 ➔ GCPが提供している Apache Airflow で構築された、フルマネージドのワークフ
ローオーケストレーションサービス ➔ DAG(有向非巡回グラフ)形式のパイプラインを Python で記述可能 ➔ Airflow のスケジューラーやワーカーが、 GKE 上で動作可能 ➔ 豊富なメトリクス画面がビルドイン Cloud Composer とは 実際の定常処理のDAG
#Rtech BigQuery導入で集計が高速化するも、効果は限定的 BigQuery 導入での効果 ➔ DWH を BigQuery へ移行することで、集計処理時間は飛躍的に高速化さ れた
◆ 例)「課金ログを元に学習者の会員ステータスを管理するテーブル」の 集計時間が 60min(hive) → 1min(BQ) に短縮 実際の状況 ➔ しかし、日次処理全体の処理時間や労力が激減はしなかった BigQuery導入後の実際の状況
#Rtech データ転送処理がボトルネックになっている ➔ 日次処理時間の大半が BashOperator で 占めており、BigQueryOperator は短い ➔ BashOperator
は、データ転送のタスクがほ とんど データ転送処理のパフォーマンスが改善できれ ば、全体の高速化が見込める BashOperator(27.3h) BigQueryOperator(2.8h) Composer での 日次処理時間の内訳 パフォーマンス面での課題
#Rtech データ定常処理を支える運用の負担が大きい 運用面での課題 運用面での課題 実際に直面した苦労・失敗 ① 利用者との期待値調整ができておらず、 運用者も努力目標が不明確 • 集計が遅延した時、どのレベルで誰に周知していいか悩んだ
② リソース管理 や CI/CD が不十分で、 障害発生のリスクがあった • オペミスにより本番環境に不要なファイルがデプロイされ定常 処理が止まる • 新たなインスタンスを立てたらモジュールがインストールされて おらず処理が止まった ③ 障害の検知に遅れることがあった • 定常処理のステータスが瞬時に把握できない • ディスク不足やネットワークのポートの枯渇などの把握に遅 れ、障害が発生 ④ 障害対応がスムーズに行かない • 障害復旧が職人芸化され、属人化している部分があった
#Rtech データの定常処理を効率化する パフォーマンス面・運用面での Tips を紹介します 今回のテーマ
#Rtech パフォーマンス面での4つの工夫 02
#Rtech 日次処理における処理の平準化 合計 実行時間 時間帯 ログ 取り込み マスター 取り込み 外部データ
取り込み BQ集計 外部データ 提供 ログ 取り込み ログ 取り込み 外部データ 取り込み ピークタイムをずらし、マシンへの 負荷の平準化 パフォーマンスチューニングの工夫① Composer で使われている GKE ノードへの負荷を抑えるため、リソースが空い ている時間を有効活用
#Rtech 合計 実行時間 時間帯 ログ 取り込み マスター 取り込み 外部データ 取り込み
BQ集計 外部データ 提供 ログ 取り込み peak_time normal_time idle_time 時間帯ごとにGKEノード数を設定(1日3段階) パフォーマンスチューニングの工夫② 1日の中で、Composer への負荷は濃淡があるためノード数を時間帯ごとに設定 Composer の GKE ノード数を負荷に合わせて調整 ※BashOperator から上記のコマンドを実行
#Rtech タスクの並列数を調整可能に パフォーマンスチューニングの工夫③ 個別のタスクの処理時間を測定し タスク並列数を調整 ↓このように、Airflow の Variablesで 4並列から直列に変更も可能 サーバーサイドログ取り込み処理の
Graph View
#Rtech Embulk を Cloud Run で実行 パフォーマンスチューニングの工夫④ ➔ 複数処理による同一リソースの食い合いをサーバーレス化で解決 ◆
処理の高速化 ➔ 必要な時に必要な分だけリソースを確保してくれる ◆ コスト面での大幅削減 ◆ スケーラビリティの拡充 Cloud Run
#Rtech 急激な負荷に迅速に対応した2つの事例 ➔ COVID-19 で一斉休校になり、 データ量が増大 ◆ 処理の平準化、リソースを負 荷に合わせて調整すること で対応
➔ 季節要因でログが急増 ◆ 並列数を減らして最大負荷 を下げる 冬休み 最終日 GW 最終日 ログ取り込み時間の推移
#Rtech データ基盤運用面での4つの工夫 03
#Rtech データ定常処理を支える運用の負担が大きい(再掲) 運用面での課題 運用面での課題 実際に直面した苦労・失敗 ① 利用者との期待値調整ができておらず、 運用者も努力目標が不明確 • 集計が遅延した時、どのレベルで誰に周知していいか悩んだ
② リソース管理 や CI/CD が不十分で、 障害発生のリスクがあった • オペミスにより本番環境に不要なファイルがデプロイされ定常 処理が止まる • 新たなインスタンスを立てたらモジュールがインストールされて おらず処理が止まった ③ 障害の検知に遅れることがあった • 定常処理のステータスが瞬時に把握できない • ディスク不足やネットワークのポートの枯渇などの把握に遅 れ、障害が発生 ④ 障害対応がスムーズに行かない • 障害復旧が職人芸化され、属人化している部分があった
#Rtech SLAを定め、モニタリングする データ基盤運用面の工夫① ➔ データのステークホルダーと協議し 主要データを何時までに提供する か合意し期待値調整をする ➔ 障害の条件を定義し、半年間のSLA をチームで決める
➔ 週次定例でチームメンバー全員で SLAの実績を確認 SLA (1) 10時時点で、Table Aが作成されていること (2) 12時時点で、spreadsheet吐き出しタスクが完了し ていること (3) 13時時点で、集計データの外部連携まで完了して いること
#Rtech CI/CDとインフラコード化を徹底し、障害を予防 ➔ CI/CDツールとして Cloud Build を導入 ◆ クエリチェック、パイプラインチェック、構文チェックを行う •
過去のしくじり:Python ファイルのエラーでDAGが壊れ定常処理 が走らない ◆ Composer , Cloud Run へのデプロイを自動で行う • 過去のしくじり:デプロイ先がファイルの変更箇所に応じて2箇所あ り、デプロイ忘れが発生 ➔ Terraform でのGCPコンポーネント管理 ◆ 構成の再現性を担保 データ基盤運用面の工夫②
#Rtech 監視項目を整理し、アラート設定をして障害を迅速に検知 データ基盤運用面の工夫③ ➔ Airflow の Operator の成功/失敗コールバックに Slack のPOST処理をか
ませる ➔ 重要なテーブルデータの整合性を検証するタスクを設け Slack 通知 ◆ 過去のしくじり • Operator は成功しているが、中身のデータが不整合だった ➔ DAGの重複依存関係や Composer でのエラーアラートを設定
#Rtech 障害対応をスムーズに データ基盤運用面の工夫④ ➔ ドキュメント化の徹底 ◆ エスカレ対応の条件 ◆ 対応方法・コツ ◆
対応の心構え ◆ 対応時のログを残す 誰でも同じ品質の対応ができる
#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構成のイメージ図
#Rtech 4つのポイントを仕組み化しPDCAをまわし属人化を解消 データ基盤運用面の工夫のまとめ ① SLA定義 & モニタリング整備 ② 障害の予防 ③
障害の検知 ④ 障害対応
#Rtech まとめと今後の展望 04
#Rtech データ処理のパフォーマンス面・運用面での改善を行った パフォーマンス面 運用面 ➔ 日次処理における処理の平準化 ➔ Composer のGKEノード数を負荷に合わせて 調整
➔ タスクの並列数を調整可能に ➔ Embulk を Cloud Run で実行 ➔ SLAを定め、モニタリングする ➔ CI/CDとインフラコード化を徹底し、障害を 予防 ➔ 監視項目を整理し、アラート設定をして障 害を迅速に通知 ➔ 障害をワンタッチで対応可能に まとめ
#Rtech 今後の展望 ➔ Composer の更なるロバスト化 ◆ 2系で導入された Autopilot によるオートスケーリングの実現 ➔
新データ基盤と MLOps 基盤の連携強化 ◆ データプロダクトごとに乱立している MLOps のシステム・運用を共通化 し、今回紹介したデータ基盤と連携強化 ◆ Vertex AI の活用を強化し、手軽にML開発できる仕組みを整備
#Rtech ご清聴ありがとうございました