なぜ Airflow から Dagster に乗り換えたのか
こんにちは！Scene Live bq事業本部のまっすーです。
2025年からデータサイエンティスト兼データエンジニアとして、Scene Liveに中途入社しました。
bqというサービスのLLMを用いた検証・研究をおこなったり、プロダクトに関するデータ収集から利活用までの『データ基盤』を作ったりしています。
▼bqに関する記事
はじめに
前回の記事で、bq 事業のデータ基盤を 1 ヶ月半でゼロから作った話を書きました。
おかげさまで多くの方に読んでいただき、嬉しい限りです。
そして、「実際に運用はどうなの？」という声が聞こえそうですので、今回は全 3 回に分けて基盤を育てる中でぶつかった課題と、それをどう乗り越えたかを書いていきます。
今回のテーマは、データ基盤の実行制御を司る、オーケストレーターの乗り換え。
Cloud Composer（Airflow）で動かしていた基盤を、Dagster に全面移行しました。
この記事では「なぜ乗り換えたのか」、その設計思想の話に絞ります。
この記事の前提（用語の整理）
うちのデータ基盤は Google Cloud 上で動いています。記事中によく出てくる用語を先に並べておきます。
Cloud Composer: Google Cloud のフルマネージド Airflow サービス。Airflow一式の運用を GCP が引き受けてくれる代わりに、固定料金が発生する
Cloud Run Jobs（以下 CRJ）: バッチ処理用のサーバーレス実行環境。実行時間だけ課金される
Cloud Run Service（以下 CRS）: 常駐 Web サービス用のサーバーレス実行環境。Web UI や常駐プロセスのホストに使う
BigQuery: Google Cloud のデータウェアハウス
dbt / dlt / リバース ETL ツール: 本記事の後半で説明します
「オーケストレーター」は聞き慣れない方もいると思うので軽く補足しておきます。
語源は orchestrate（オーケストレートする）という動詞で、これは元々「オーケストラ用に編曲する」という意味から「複数の要素を統括して調和させる」に意味が広がった単語です。
語源そのままで オーケストラの指揮者 のイメージで捉えてください。
データ基盤には「BigQuery にデータを取り込む」「dbt で加工する」「結果を SaaS に書き戻す」など、たくさんの “演奏者”（処理）がいます。
オーケストレーターは「いつ・どの順番で・誰を起こすか」を指揮する役割で、
どの処理をいつ動かすか（スケジュール）
どれが終わったら次に何を動かすか（依存関係）
失敗したらどう知らせるか（通知・リトライ）
をまとめて面倒みてくれる道具、と捉えてください。
結論
先にまとめると、乗り換えの理由は 3 つです。
Cloud Composer のフルマネージド料金が重かった
“タスクを並べる” Airflow より、“データ資産を宣言する” Dagster の方が、今のうちのデータ基盤に合っていた
dbt / dlt / リバース ETL とのネイティブ統合が強力だった
順番に説明します。
1. Cloud Composer の固定料金が重かった
Airflow を Cloud Composer で動かしていたのですが、 フルマネージドゆえの固定料金 がそれなりのサイズになっていました。
Composer は楽な反面、Airflow を支える GKE クラスタ・PostgreSQL・各種コンポーネント一式が常時起動した状態で課金されます。
うちの基盤は朝と夜にバッチがまとまって走る運用で、日中はほぼアイドル。
それでも月額は一定の高めの金額がかかり続けていました。
ここで補足しておきたいのが、 重いバッチ処理を CRJ にオフロードする設計自体は Airflow 時代からやっていた ということです。
dbt-core も Airflow 時代から CRJ で動かしていて、これは Dagster 移行後も変わっていません。
つまり 変わったのは、Airflow / Dagster 本体の動かし方 です。
Airflow 時代: フルマネージドの Composer に任せる（楽だが料金は固定で高め）
Dagster 移行後: 自前で CRS として動かす（運用は自己責任、料金は軽量 Service の常駐分のみ）
要するに「フルマネージドの楽さを手放す代わりに、固定料金を大幅に下げた」というのが本質です。
運用のお守りは増えますが、削減できる金額の方が大きかった、という判断ですね。
念のため、「実際にどれくらい変わったの？」という話も少しだけ。
具体的な金額は伏せますが、オーケストレーター本体にかけているインフラ費用は、移行前後で約 4 割削減できました。
Composer の固定料金がまるごとゼロになる代わりに、Dagster を Cloud Run と Cloud SQL で動かす分が新規発生する、というトレードオフです。
詳しい内訳と「もっと下がる見込み」の話は、第 3 回でまとめて書きます。
2. “タスクを並べる” Airflow から “データ資産を宣言する” Dagster へ
これが実は一番大きかった話です。
Airflow の世界観は「 タスクを並べる 」です。
データの extract → transform → load のような処理の順序を DAG（有向非巡回グラフ）として書きます。
これはシンプルで強力なんですが、基盤が大きくなると困ることが出てきました。
たとえば「この BigQuery テーブル、どの DAG のどのタスクが作ってるんだっけ？」という問いに、Airflow はすぐ答えられません。
DAG はあくまで 処理の流れ であって、 成果物（データ） そのものを表現していないからです。
Dagster はここを逆転させます。
中心にあるのは タスクではなく Asset（データ資産） 。
「このテーブルが存在すること」を宣言し、その依存関係を定義すると、Dagster が自動的に実行順序を決めてくれます。
うちの基盤は Bronze → Silver → Gold（生データ → 整形済 → 集計済の 3 階層）のメダリオンアーキテクチャで、テーブル数は 4 月末の時点で軽く 500 を超えます。
こうなると「タスクの流れ」より「テーブル同士の依存関係」で考えた方が圧倒的に自然でした。
3. dbt / dlt / リバース ETL がネイティブに統合できた
3 つ目は、具体的な道具の話です。
前回記事で書いた通り、うちの基盤は dbt（data build tool、データ変換）を使っています。dbt-core は OSS でデータ加工を記述でき、GitHub 等を用いた開発プロセスに組み込みやすいのが特徴です。
今回、Dagster への移行に合わせて、以前は Python のカスタムスクリプトで書いていたデータ取り込みを、dbt-core と似たような体験ができる OSS、dlt（data load tool、取り込み）に変更しました。
さらに直近では、プロダクトやビジネスサイドの周辺ツールへの「データ基盤からの書き戻し」（Reverse ETL）の需要が増えています。
こちらは dbt-core / dlt と似た体験で書ける OSS を入れました。
よって、dlt / dbt / リバース ETL ツールの 3 本柱で多くは動いています。
Airflow 時代はこれらの取り込み・書き戻しツールを入れておらず、データ取り込みは Python のカスタムスクリプト で書いていて、リバース ETL の仕組み自体がそもそも存在しませんでした（dbt-core だけは Airflow 時代から CRJ で動かしていました）。
dlt / リバース ETL をいつ・なぜ・どう入れたかの詳細は、第 3 回で詳しく書きます。
Dagster には dagster-dbt / dagster-dlt など、それぞれのツール用のネイティブ連携があり、dbt のモデル 1 つ 1 つ、dlt のソース 1 つ 1 つが、そのまま Dagster の Asset として現れます。
これが何を意味するかというと、 dbt の lineage graph がそのまま Dagster の UI 上で可視化され、どのテーブルがいつ・何秒で・なぜ失敗したかが一画面で分かる ということです。
なお、冒頭で書いた通り、dbt-core 自体を CRJ で動かす構成は Airflow 時代から変わっていません（Composer の Airflow ワーカーから CloudRunExecuteJobOperator で CRJ を起動していました）。
変わったのは 観測性 の方で、Airflow 時代は「dbt のエラー？ Composer のログと dbt-core が走る CRJ のログと BigQuery のログを行き来して…」となっていたものが、Dagster Pipes（Dagster 本体と CRJ をつないで、Job 内で起きたことを Asset の世界に持ち帰る仕組み）経由になったことで dbt の各モデルが Asset として可視化され、1 画面で完結するようになりました。
3つの理由のまとめ
ここまでの内容を表にまとめました。良いことばかり書いてもアレなので、 Dagster 側の弱み も並べておきます。
太字にした下 3 行が Dagster 側の弱みです。
特に 運用負担 は無視できなくて、Composer 時代は GCP が面倒を見てくれていた daemon プロセスや UI のホスティングを、Dagster では自分たちで CRS として動かす必要があります。
これは次回以降の「ハマった話」でかなり出てきます。
ただ、 情報量の少なさ と 学習コスト の 2 つに関しては、最近の AI コーディング環境でかなり緩和されました。
データ基盤のリポジトリでは Claude Code を日常的に使っていて、Dagster Labs が公式に提供している dagster-io/skills プラグイン（dagster-expert / dignified-python）を有効化しています。
Asset の書き方や @dbt_assets / @dlt_assets の組み合わせ方を AI が知っていてくれるので、英語ドキュメントを読み解くハードルがぐっと下がっています。
OSS の情報量で Airflow に及ばないところを、AI のサポートで埋める、という構図ですね。
それでも乗り換えた理由は、上の利得（オーケストレーター本体の料金・設計思想・連携・観測性）が、下3行のコストを上回ると判断したからです（しかも下3行は AI でだいぶ薄められる）。
乗り換えは楽だったのか
ここまで書いておいてなんですが、移行は全く楽ではありませんでした。
テーブル数 500 超を段階的に移さないと、止まったときに事業に大きな影響が出る（そして 3 日くらい止まりました…詳細と教訓は第 2 回に書きます）
Airflow 時代と同じ挙動を保証しないといけない（パリティ検証）
Dagster 特有のハマりどころ（daemon = スケジューラ常駐プロセスの重複起動、Pipes 連携、sensor = イベント駆動トリガの挙動…）に片っ端から刺さる
このあたりの 段階移行の戦略 と 実際にハマった話 は、次回以降で詳しく書きます。
おわりに
まとめると、Airflow → Dagster の乗り換えは「安くなる」「見通しが良くなる」「道具と相性が良い」の 3 点狙いでした。
実際、移行後はコスト・開発体験ともに大きく改善しています（具体的な改善内容は第 3 回で触れます）。
次回は「Dagster 移行、500 テーブル超を止めずに引っ越した話」というタイトルで、500 テーブル超を止めずに移行するための段階移行戦略を書きます。
連載目次
第 1 回: なぜ Airflow から Dagster に乗り換えたのか（本記事）
第 2 回: Dagster 移行、500 テーブル超を止めずに引っ越した話
第 3 回: Dagster の“ネイティブ統合”が効いた話（dlt / dbt + リバース ETL）
最後に
まだまだ発展途上のデータ基盤。これからも生成AI・LLMを使った改善を続けていきます！
データ基盤に興味がある方、LLMを活用した開発やデータ分析に興味がある方、ぜひお話ししましょう。
▼Scene Live 採用情報
▼bq事業のエンジニア採用
