CloudComposerによる大規模ETL 「制御と実行の分離」の実践

2025/11/04に開催された「Data Engineering Summit 前夜祭」の登壇資料です
https://findy-tools.connpass.com/event/373000/

Transcript

1. CloudComposerによる大規模ETL 
 「制御と実行の分離」の実践 
 レバレジーズ株式会社 
 于　原駿

2. 自己紹介

3. 自己紹介

4. datatech-jpというコミュニティで #みん強 イベントの企画運営とMCしてます
 自己紹介
 ⬇今月末SnowVillageと
 コラボイベント開催予定！

5. 会社紹介

6. 6 機密情報・転載禁止 © 2024 Leverages Co., Ltd. 会社概要 検討中 オフィス⽴地や社員数等最低限の情報 （最新の数値に更新する） デザイン調整する 社名 従業員数 代表者 資本⾦ 所在地‧拠点 グループ会社 レバレジーズ株式会社 Leverages Co.,Ltd. 2,838名（2024年4⽉現在） 岩槻 知秀 5,000万円 本社：東京都渋⾕区渋⾕2丁⽬24番12号 渋⾕スクランブルスクエア24F‧25F 国内拠点：27拠点 海外拠点：3拠点 レバテック株式会社  レバレジーズM&Aアドバイザリー株式会社 ATLIKE株式会社 レバレジーズメディカルケア株式会社 レバレジーズオフィスサポート株式会社 レバレジーズプランニングサポート株式会社 レバレジーズスタッフィング株式会社 員点動⼒（上海）⼈⼒資源有限公司 Leverages Career Mexico S.A. de C.V. Leverages Career Vietnam Co., Ltd. Leverages U.S.Inc. 会社について
7. 7 機密情報・転載禁止 © 2024 Leverages Co., Ltd. 10年後に ⼀兆円規模を ⽬指す 企業の安定性と成⻑性を担保する独⾃の経営戦略のもと、 創業以来、黒字経営を継続し、 2023年度は1,149億円を達成しました。 企業理念として「顧客の創造を通じて、関係者全員の幸福を追求し、 各個⼈の成⻑を促す」を掲げ、⼈の感情と向き合いながら 次の時代を創るグローバル企業を⽬指しています。 ベンチャーを牽引する成⻑で、 次代を創る企業へ 売上推移 会社について
8. 8 機密情報・転載禁止 © 2024 Leverages Co., Ltd. ポートフォリオ経営とは、業界やビジネスモデルなどにこだわらず、 分散投資をしていく経営形態のこと。 この経営形態のメリットは、予測困難な外部変化に会社全体で衝撃を 吸収しやすい点にあります。例えば、コロナ禍では海外事業などは打 撃を受けた⼀⽅で、IT事業や医療‧ヘルスケア事業は追い⾵を受け、 過去最⾼の売上を更新、黒字経営を継続しました。 経営のリスク分散を⾏うことで、未曾有の状況でも安定した成⻑を実 現しています。 ポートフォリオ経営による安定した 収益基盤で創業以来、黒字経営を継続 経営体制について 会社について
9. 9 © 2025 Leverages Co., Ltd. • データサイエンティスト：2名 • データアナリスト：4名 • データアーキテクト：6名 • AIコンサルタント：3名 • データエンジニア：5名 • AI/MLエンジニア：4名 • 先端技術研究員：2名 • (マネージャー：2名) レバレジーズのデータ関連職種 データ職種の正社員は28名が在籍 (2025年8月時点) 9 © 2025 Leverages Co., Ltd.
10. データ活用基盤 

11. 11 © 2025 Leverages Co., Ltd. • ELT：Fivetran • DWH：BigQuery • Transform：Dataform • BI：Tableau, Looker Studio • Metadata：Dataplex • Quality Check：Dataplex • Reverse ETL：trocco • Orchestration：Airflow データ活用基盤 - 全体概要アーキテクチャ
12. 12 © 2025 Leverages Co., Ltd. データ活用基盤 - 個別アーキテクチャ • 全社で50近くのサービスを展開していることもあり ブランド単位でまとめつつデータ活用基盤を分割 • データ活用基盤の数は10ほど • BigQueryを中心としつつ、事業売上や関係者数、 実装時期によって少しずつアーキテクチャが異なる • 異なるビジネスモデルや売上規模でも 設計が変わらないよう共通利用できる技術を選定
13. Composer移管 

14. Composer移管とは 
 2024年以前の世界
 • GCEに全て載せたのでSPoFになってる
 • スケジューラーの乱立
 ◦ digdagとCloudScheduler
 • ワーカーの乱立
 ◦ EmbulkとCloudFunctions
 • 無駄なコスト
 ◦ 夜間バッチに合わせた
 クソデカスペック

15. Composer移管とは 
 2024年以降の世界
 • ELTはFivetranに集約
 • その他はCloudComposerに集約
 ◦ スケジューラー
 ◦ SaaSからのELT処理
 ◦ 管理系の細かいワーカー
 • スケールする＆運用工数の削減を
 実現させる
 • 必要な時だけリソースを使う構成

16. • TerraformでIaC、GithubActionsでCICDを組んだ
 • 全事業のdigdag,embulkのETL実装をほぼ全てComposerへ移管完了
 Composer移管とは 

17. Composerの設計方針 

18. Composerの設計方針 
 • 制御の役割をCloudComposer に特化
 ◦ いつ、何を、どの環境で実行するか？の制御に集中
 • 具体のETL処理は外部 に委譲
 ◦ 基本的にCloudRunJobsに実行させる
 ◦ 高負荷な処理はCloudBatchに実行させる
 ◦ 一部軽量データ処理やメタデータの操作は、jobsを使わず CloudComposerのDAG内で完結

19. SalesForceの大規模データ連携 

20. SalesForceの大規模データ連携 
 
 
 本日はCloudComposer移管で、一番大変だった
 SalesForce → BigQueryのデータ処理の話をするよ！

21. SalesForceの大規模データ連携 
 2024年以前の世界でやっていたこと
 • 基本的にほぼ全てのオブジェクト、全カラムをBigQueryに連携
 • この処理を安定稼働させるため 、GCEのスペックを盛々に...!

22. SalesForceの大規模データ連携 
 一旦移行時にやったこと
 • Embulk実装(python)をそのままCloudRunJobsに移植
 • クソでかいjobsの最高性能(32GB)を持ってしてもメモリ不足
 • オブジェクト多すぎてComposer自体落ちる
 • データ連携多い、てかきつい

23. 悩みその①　連携対象のオブジェクトが多すぎる 
 • DAGやtaskの分割粒度を決める必要 がある
 ◦ 1オブジェクト1DAGは絶対違う
 ◦ 100オブジェクトを並列taskで処理させるのもの変
 • 短期間で捌くためのリソース調整が難しい 
 ◦ 同時実行並列数を増やすとComposerのリソースを増やす必要があり、夜 間のSalesForce連携のためだけにリソース増やすことになる

24. 悩みその②　オブジェクトがクソデカすぎる 
 • 一旦一番でかいオブジェクトをCloudRunjobsで実行した
 ◦ APIの仕様上ストリームでBigQueryに入れると長時間になるため、select allで取り込みBigQueryにinsertする方針
 ◦ 一番スペックが高い(32GB)を持ってしても、メモリ不足に...
 • 営業やマーケ等現場メンバーの多数がBigQueryでデータを見ている
 ◦ 各オブジェクトごとにカラムの要不要をヒアリングするのは現実的じゃない
 ◦ 困った困った

25. 意識したこと 

26. 移管時にやって意識したこと 
 • 連携対象のオブジェクトが多すぎる悩み
 ◦ そもそも一切使わないオブジェクトを連携しない
 ◦ 結果的に500オブジェクトから50オブジェクトに減らせた
 ◦ カラムは全て取り込む。SELECT * FROM オブジェクトは継続
 • オブジェクトがクソデカすぎる悩み
 ◦ DAG、CloudRunJobs、CloudBatchの三段階構成で突破

27. 連携対象のオブジェクトが多すぎる悩み 
 • カラムの利用有無を各オブジェクトごと見るのはしんどい
 • じゃオブジェクトの利用有無なら洗い出し頑張れそう
 • BigQueryのジョブ履歴やdwh/datamartを一通り洗い出し、利用していないも のは一旦連携対象から外す
 • 50オブジェクトに収まったので、めちゃめちゃ難易度が下がりました

28. オブジェクトがクソデカすぎる悩み 
 • DAGの分け方をETLに必要なスペック単位 で切ってみた
 ◦ small: CloudComposerのみで完結
 ◦ medium: CloudRunJobsで捌く(体感、数100MB以上)
 ◦ large: Jobsで捌けない特大オブジェクトをCloudBatchで実行。必要スペッ クはCloudComposer側で定義

29. オブジェクトがクソデカすぎる悩み 
 • DAGはsmall/medium/largeの3種類あるが、実装差分無し 
 ◦ ComposerのDAG自身が実行する
 ◦ Dockerfile化したものを、CloudRunJobsで実行する
 ◦ Dockerfile化したものを、CloudBatchをその場で作成し実行
 ◦ 実行環境をCloudComposerが切り替えているだけ

30. Composerの設計方針（まさにこれ！） 
 • 制御の役割をCloudComposer に特化
 ◦ いつ、何を、どの環境で実行するか？の制御に集中
 • 具体のETL処理は外部 に委譲
 ◦ 基本的にCloudRunJobsに実行させる
 ◦ 高負荷な処理はCloudBatchに実行させる
 ◦ 一部軽量データ処理やメタデータの操作は、jobsを使わず CloudComposerのDAG内で完結

31. 全体像
 small_dag
 medium_dag
 large_dag
 オブジェクト一 覧
 オブジェクト一 覧
 オブジェクト一 覧
 DAG内のtask実行
 CloudrunJobsで実行 
 CloudBatchで実行
 同じソースコードで
 実行環境だけ分離
 スケジューラ
 の役割
 オブジェクトごとにJobs を実行依頼
 オブジェクトごとに Batchを実行依頼
 オブジェクトごとに
 taskを実行

32. 今後の課題 

33. 今後の課題 
 • 先週起きた事件です！！
 • CloudBatch側がメモリ不足により連携失敗していることが発覚！
 • 知らぬ間に一番でかいSalesForceのオブジェクトのカラムが200個ぐらい増 え、データ連携に3時間→6時間かかってた
 • 最終的にメモリ不足でBatch側が失敗していた
 

34. 今後の課題 
 • CloudBatch側がメモリ不足により連携失敗していることが発覚！
 ◦ Batchもモニタリングちゃんとやろう
 ◦ 一部実装がイケてなかったので、DeferrableOperatorsとTriggers の仕組 みを使ってBatchの処理を非同期にinvokeするようにした
 • 知らぬ間に一番でかいSalesForceのオブジェクトのカラムが200個ぐらい増 え、データ連携に3時間→6時間かかってた
 ◦ クソデカオブジェクトだけは、カラムの要不要を判断しよう
 ◦ ※どちらかというと絶対使わないカラムを指定する

35. さいごに

36. 36 © 2025 Leverages Co., Ltd. We Are Hiring! • まずはカジュアル面談からどうぞ！ • 3年で2倍にスケールする環境で、データを使った変革を起こしましょう！ • 募集職種 ◦ データサイエンティスト ◦ データアナリスト ◦ データアーキテクト ◦ データエンジニア ◦ 機械学習エンジニア ◦ 機械学習研究員
37. 37 機密情報・転載禁止 © 2025 Leverages Co., Ltd. ビジネス グロース DX 営業 企画 SFA 開発 CRM/MA CJM スコア リング CS システム 構築 プロ モーション プロダクト UI/UX SEO プロト タイプ Web 広告 クリエイ ティブ TV CM 電⾞ 広告 仮説 設定 レバレジーズはマーケティングやセールスといった全ての組織がインハウスで機能しており、 データ戦略が事業運営上重要なハブとなる構造になっています。 データ戦略の役割 データ戦略

38. 38 © 2025 Leverages Co., Ltd. レバレジーズ テックブログ https://tech.leverages.jp/ データ戦略ブログ（週1更新） https://analytics.leverages.jp/ 全社の情報発信媒体(melev) https://melev.leverages.jp/ 情報発信しています！
39. ありがとうございました