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.4k
スタディサプリのデータ基盤を支える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
Javaで作る RAGを活用した Q&Aアプリケーション
recruitengineers
PRO
1
110
問題解決に役立つ数理工学
recruitengineers
PRO
11
2.8k
Curiosity & Persistence
recruitengineers
PRO
2
190
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
410
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
190
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
350
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
360
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
3
200
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
2
250
Other Decks in Technology
See All in Technology
Github Copilot エージェントモードで試してみた
ochtum
0
100
Agentic Workflowという選択肢を考える
tkikuchi1002
1
510
Node-RED × MCP 勉強会 vol.1
1ftseabass
PRO
0
140
Navigation3でViewModelにデータを渡す方法
mikanichinose
0
220
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
100
生成AI時代 文字コードを学ぶ意義を見出せるか?
hrsued
1
440
AIの最新技術&テーマをつまんで紹介&フリートークするシリーズ #1 量子機械学習の入門
tkhresk
0
140
TechLION vol.41~MySQLユーザ会のほうから来ました / techlion41_mysql
sakaik
0
180
Understanding_Thread_Tuning_for_Inference_Servers_of_Deep_Models.pdf
lycorptech_jp
PRO
0
120
Observability в PHP без боли. Олег Мифле, тимлид Altenar
lamodatech
0
350
PostgreSQL 18 cancel request key長の変更とRailsへの関連
yahonda
0
120
なぜ私はいま、ここにいるのか? #もがく中堅デザイナー #プロダクトデザイナー
bengo4com
0
440
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Producing Creativity
orderedlist
PRO
346
40k
Being A Developer After 40
akosma
90
590k
VelocityConf: Rendering Performance Case Studies
addyosmani
330
24k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Gamification - CAS2011
davidbonilla
81
5.3k
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 ご清聴ありがとうございました