技術部データ基盤チームの@zaimyです。
ペパボの社内データ基盤「Bigfoot」では、2020年にDigdagから移設して以来約5年間にわたりCloud Composer（Managed Apache Airflow）をワークフローエンジンとして運用してきましたが、2026年1Qをもって別構成に移行しました。本記事では、Cloud Composerから3つのマネージドサービスへ移行した経緯と、その効果について紹介します。
Cloud Composerで動いていた3つのワークロード
データ基盤ではCloud Composer上で主に以下の3つのワークロードを動かしていました。
- dbtによるデータ変換（Cosmos経由でAirflow DAG上で実行）
- 事業DBからBigQueryへの同期
- dbt以外のデータ変換や機械学習パイプラインなどその他のオーケストレーション
なぜ撤退したのか
3つの課題が重なったため、2026年1Qでの撤退を決定しました。
1. Agentic AI readyになるためにdbtを身軽にしたい
技術部の方針「Agent Ready」に基づき、AIエージェント前提の技術基盤づくりを進めるにあたって、dbtでSSoTなデータマートを作った上でAgentic AIによる分析を実現したいと考えています。そのためにdbtをより身軽に使いたいのですが、Airflow上でdbtを実行する構成はオーバーヘッドが大きく、AIを用いた開発運用においてフィードバックループが遅い状態でした。
2. コストの膨張
Cloud Composer 2からCloud Composer 3への移行や、使用量の増加により、月額コストが数十万円に膨張していました。
3. 運用負荷の高さ
AirflowはPythonで作り込めるがゆえに、5年間の運用を経てコードベースが複雑になっていました。さらにCloud Composer/Airflowのバージョンアップ対応が必要であったり、Cloud Composerはリソース量をプリセットから選ぶ形でフルマネージドとも言えなかったりと、マネージド度合いを高めたいという課題がありました。
なお、Cloud Composerのバージョンアップにまつわる運用課題については、以前「社内データ基盤のワークフローエンジンをBlue-green deploymentで無停止バージョンアップする」で紹介しています。
移行先コンポーネントの紹介
Cloud Composerが担っていた3つのワークロードを、それぞれ専用のマネージドサービスに分離しました。
dbt Cloud
dbtの実行基盤をAirflow + Cosmosからdbt Cloudに移行しました。
| メリット | デメリット | |
|---|---|---|
| 開発体験 | CI実行時間が劇的に短縮（後述）。dbtに特化したIDE・ドキュメント生成・リネージが標準で使える | 開発者シート数に上限あり |
| 運用 | バージョン管理・デプロイがSaaS側で完結。Airflowの運用が不要に | 障害時の対応手段が限定的 |
| 拡張性 | Webhookで後続処理をトリガー可能（Eventarc連携） | - |
BigQuery Data Transfer Service (DTS)
事業DBの同期をDTSに移行しました。元はAmazon RDSのAmazon S3へのDBスナップショットデータのエクスポートをAirflow DAGから実行し、さらにBigQueryのLOADジョブをAirflow DAGから発行してロードする構成でしたが、移行後はMySQLやPostgreSQLなどのコネクタを使ってRDSから直接BigQueryにデータ転送します。
| メリット | デメリット | |
|---|---|---|
| コスト | Google公式コネクタを使うことで現時点で転送コストなし | RDSがプライベートVPC内のためCloud VPNが必要 |
| 運用 | フルマネージド。スケジュール実行・モニタリングが組み込み | 細かいカスタマイズが難しい |
| 信頼性 | ジョブ品質をGoogleに任せられる | 1ジョブにテーブルを詰め込みすぎるとレコード欠損が生じるケースがある。運用面からもジョブ分散が有用 |
Cloud Workflows
MLパイプラインやデータ変換のオーケストレーションをAirflow DAGからCloud Workflowsに移行しました。 また、dbt Cloudとの連携のため、dbt modelのビルド完了をトリガーにEventarcを介してCloud Workflowsを起動する仕組みも構築しました。
| メリット | デメリット | |
|---|---|---|
| コスト | 従量課金で月額数百円程度。無料枠も大きい | - |
| 開発体験 | YAMLベースでシンプル。Terraform統合でCI/CDが容易 | Airflowと比べ柔軟性が低い |
| 運用 | サーバーレス。ワークロードごとに独立。Cloud Logging/Monitoringに統合 | Airflow UIのような統合的な実行管理画面はない |
コスト比較
構成変更前後の月額コストを比較すると、約84%の削減となりました。
開発効率比較
開発効率の比較としてdbt modelの開発を例に、構成変更前後のCI実行時間を比較しました。
| 指標 | Cloud Composer（n=622） | dbt Cloud（n=476） | 改善 |
|---|---|---|---|
| 中央値 | 約17分 | 約30秒 | 34倍高速化 |
| 平均値 | 約42分 | 約2.5分 | 17倍高速化 |
CIの高速化により、dbt modelの変更に対するフィードバックループが劇的に短縮されました。これはAgentic AIがdbt modelを自律的に変更する際にも重要な基盤です。
運用面の比較
| 観点 | Cloud Composer | 移行後 |
|---|---|---|
| バージョンアップ | Cloud Composer/Airflowの大型アップグレード対応が必要（Cloud Composer 2→3でコスト増） | マネージドサービスで自動。EOL対応が不要 |
| 障害時の影響範囲 | 全DAGが1環境に依存。障害で全ワークロード停止 | ワークロードごとに独立。障害の影響を局所化 |
| スケーリング | 環境サイズの変更が必要（Worker 2台〜を常時確保するためコスト負荷もあり） | サーバーレスで自動スケール |
| デプロイ | 時間がかかる（GCS同期→パース待ち） | 個別に高速にデプロイ可能 |
| 可観測性 | Airflow UIで一元管理 | Cloud Logging/Monitoringに統合 |
| アラート・障害対応 | Airflowのpost hookでSlack通知 + GitHub Issueを作成 | Cloud MonitoringとCloud FunctionsでSlack通知 + GitHub Issueを作成 |
エラーレート比較
Cloud Monitoringのメトリクスから、本番環境のDAG/Workflow実行の失敗率を比較しました。
| Cloud Composer（1〜3月） | Cloud Workflows（4月） | |
|---|---|---|
| 成功 | 32,494 | 1,849 |
| 失敗 | 286 | 15 |
| 合計 | 32,780 | 1,864 |
| エラーレート | 0.87% | 0.80% |
期間の違いによりサンプル数の差はありますが、移行後の安定性が改善傾向であることを確認できます。
まとめ
Cloud Composerをdbt Cloud / BigQuery Data Transfer Service / Cloud Workflowsの3つのマネージドサービスに分離することで、以下の効果を得ました。
- コスト: 月額コスト約84%削減
- 開発効率: CI中央値17分→30秒（34倍高速化）
- 運用: サーバーレス化によりEOL対応・スケーリング・障害影響範囲が改善
「マネージドなAirflow」という一枚岩のアーキテクチャから、ワークロードの特性に合った専用サービスに分離するアプローチは、同様の構成で運用コストに課題を感じている方の参考になれば幸いです。
