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

by Tech Leverages

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 

Slide 3

Slide 3 text

自己紹介 

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

会社紹介 

Slide 6

Slide 6 text

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. 会社について

Slide 7

Slide 7 text

7 機密情報・転載禁止 © 2024 Leverages Co., Ltd. 10年後に⼀兆円規模を⽬指す企業の安定性と成⻑性を担保する独⾃の経営戦略のもと、創業以来、黒字経営を継続し、 2023年度は1,149億円を達成しました。企業理念として「顧客の創造を通じて、関係者全員の幸福を追求し、各個⼈の成⻑を促す」を掲げ、⼈の感情と向き合いながら次の時代を創るグローバル企業を⽬指しています。ベンチャーを牽引する成⻑で、次代を創る企業へ売上推移会社について

Slide 8

Slide 8 text

8 機密情報・転載禁止 © 2024 Leverages Co., Ltd. ポートフォリオ経営とは、業界やビジネスモデルなどにこだわらず、分散投資をしていく経営形態のこと。この経営形態のメリットは、予測困難な外部変化に会社全体で衝撃を吸収しやすい点にあります。例えば、コロナ禍では海外事業などは打撃を受けた⼀⽅で、IT事業や医療‧ヘルスケア事業は追い⾵を受け、過去最⾼の売上を更新、黒字経営を継続しました。経営のリスク分散を⾏うことで、未曾有の状況でも安定した成⻑を実現しています。ポートフォリオ経営による安定した収益基盤で創業以来、黒字経営を継続経営体制について会社について

Slide 9

Slide 9 text

9 © 2025 Leverages Co., Ltd. ● データサイエンティスト：2名 ● データアナリスト：4名 ● データアーキテクト：6名 ● AIコンサルタント：3名 ● データエンジニア：5名 ● AI/MLエンジニア：4名 ● 先端技術研究員：2名 ● (マネージャー：2名) レバレジーズのデータ関連職種データ職種の正社員は28名が在籍 (2025年8月時点) 9 © 2025 Leverages Co., Ltd.

Slide 10

Slide 10 text

データ活用基盤  

Slide 11

Slide 11 text

11 © 2025 Leverages Co., Ltd. ● ELT：Fivetran ● DWH：BigQuery ● Transform：Dataform ● BI：Tableau, Looker Studio ● Metadata：Dataplex ● Quality Check：Dataplex ● Reverse ETL：trocco ● Orchestration：Airﬂow データ活用基盤 - 全体概要アーキテクチャ

Slide 12

Slide 12 text

12 © 2025 Leverages Co., Ltd. データ活用基盤 - 個別アーキテクチャ ● 全社で50近くのサービスを展開していることもありブランド単位でまとめつつデータ活用基盤を分割 ● データ活用基盤の数は10ほど ● BigQueryを中心としつつ、事業売上や関係者数、実装時期によって少しずつアーキテクチャが異なる ● 異なるビジネスモデルや売上規模でも設計が変わらないよう共通利用できる技術を選定

Slide 13

Slide 13 text

Composer移管  

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Composerの設計方針  

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

SalesForceの大規模データ連携  

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

意識したこと  

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

今後の課題  

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

さいごに 

Slide 36

Slide 36 text

Slide 37

Slide 37 text

37 機密情報・転載禁止 © 2025 Leverages Co., Ltd. ビジネスグロース DX 営業企画 SFA 開発 CRM/MA CJM スコアリング CS システム構築プロモーションプロダクト UI/UX SEO プロトタイプ Web 広告クリエイティブ TV CM 電⾞広告仮説設定レバレジーズはマーケティングやセールスといった全ての組織がインハウスで機能しており、データ戦略が事業運営上重要なハブとなる構造になっています。データ戦略の役割データ戦略 