🔧
Data Engineering Study #28「データ基盤のCI/CD」レポート
公開
2025-03-04
文章量
約3716字
株式会社ヤードの代表で、Yardの開発者です。 データプロダクトの受託開発や技術顧問・アドバイザーもお受けしております。 #データ利活用 #DevOps #個人開発
目次
はじめに
講演① データ基盤のための Terraform Workflow を tfaction で構築しよう
Terraform×CIの難しさとtfaction誕生の背景
tfactionの特徴的機能
講演② 進化を加速させるデータ基盤CI/CDの実践
なぜデータ基盤こそCI/CDが必要なのか
コード×データ×コンピュートの三位一体
具体的な取り組み：DBTスリムCI
Q&A・全体を通じたポイント
Q.「中央集権的なデータチームから脱却して分散運用するのはいつがいい？」
Q.「データ基盤エンジニアの仕事は、分散運用したら無くなる？」
Q.「難しそうだけど、まずどう着手すればいい？」
全体を踏まえた感想──「データ基盤の失敗力」とCICDの未来
2025年2月27日、ForkwellとprimeNumberの共催による「Data Engineering Study #28」がオンラインで開催されました。
データ分析基盤に深く携わるエンジニアたちを招き、"データ基盤のCI/CD" をテーマに多角的な視点から学びを深める場となった本イベント。
発表や質疑応答を通じて、データ基盤特有の課題と、それを解消するための手法や実装例が数多く語られました。
以下では、本編の内容を振り返りつつ、全体を通じて見えてきた重要なポイントをまとめます。
はじめに
今回のイベントは、インフラやデータ基盤の勉強会を継続的に企画するForkwellが、データ活用基盤の総合支援サービス「TROCCO®️」を展開するprimeNumberとタッグを組んで実現したものです。
データ分析領域には、一般的なソフトウェア開発とは異なる固有の難しさがあり、特にCI/CDの設計では「単にコードをビルド＆デプロイする」以上の工夫が求められがち。
そこで、データ基盤の構築や運用にまつわる先進的な取り組みを知りたい──そんな声に応えるべく、多様な実践者が登壇し、具体的なノウハウを共有してくれました。
本稿では、登壇者による講演とQ&Aの様子をレポートし、データ基盤におけるCI/CDがどのように構築され、どんな課題を解決しているのかをひも解いていきます。
講演① データ基盤のための Terraform Workflow を tfaction で構築しよう
登壇者: フリー株式会社 SRE 鈴木 俊輔（seli07 / せりな / @szkdash）氏
Terraform×CIの難しさとtfaction誕生の背景
まず、データ基盤では多種多様なクラウドリソースを管理・設定する必要があります。Terraform自体はこれらリソースをIaC（Infrastructure as Code）で扱う際の強力なツールですが、大規模・複数チームで使いこなすとなると、単にterraform applyするだけでは済みません。
- モノレポ運用（複数のディレクトリ/サービスが1つのリポジトリに存在）
- 安全なプランファイル運用（Plan結果と違うリソースがApplyされないようにする）
- ドリフト検知（手動変更でリソースが崩れた際の検出）
- 複雑なワークフローの自動化（Linters/フォーマッタ/プラン結果の可視化…）
こうした高度な要件を満たすための一般的ソリューションがまだ少なく、各社が独自に作り込むことになりがちでした。そこで鈴木氏が開発・公開しているのが、tfactionというOSS。GitHub Actions上でTerraformの高度なワークフローを簡単に構築できるフレームワークです。
tfactionの特徴的機能
tfactionは以下のような多彩な機能を備え、「全社的にTerraform管理を浸透させたい」「変更が増え続けてCIを充実させたい」といった場面で威力を発揮します。
- モノレポサポート変更されたディレクトリのみ検知してCIを走らせる
- プランファイルを用いた安全なApplyプラン生成時とApply時のステート差分を防ぎ、安全性を高める
- ドリフトディテクション手動変更やApply失敗が放置されるのを防ぐ
- リンタ・自動修正
tf lintやフォーマットツール、ドキュメント生成などをPRコメントに可視化 - Apply失敗時の自動リカバリエラー時に関連PRを更新＆周知し、二次被害を抑える
「Terraformのワークフロー構築」は一見地味ですが、大規模・複数チームの開発現場では避けて通れない課題であり、このtfactionを取り入れれば「安全・ガバナンス向上」と「スピーディなデリバリー」が両立できる可能性があります。
講演② 進化を加速させるデータ基盤CI/CDの実践
登壇者: CARTA MARKETING FIRM VP of Data 近森 淳平（@pei0804）氏
なぜデータ基盤こそCI/CDが必要なのか
近森氏はまず「データ活用はとにかく失敗が多い」と強調。成功確率はどうしても低くなるので、結局「失敗をどれだけ効率良く繰り返せるか」が鍵になるといいます。
試行回数を増やすためには、コード変更→デプロイ→結果検証のサイクルを高速化しなくてはならず、CI/CDが必然的に重要となるわけです。
コード×データ×コンピュートの三位一体
一方、データ基盤では「コード」「データ」「コンピュート」の3要素が複雑に絡み合い、ソフトウェア開発のように単純にCI/CDを組めばOKではありません。
- コード（SQLやDBTロジック）が変更されれば、出力されるデータ品質が大きく変わる
- データが変化すれば、既存ロジックが崩れ、コンピュートリソース消費パターンも変化
- コンピュート（クラウドDWHや実行基盤）のリソース制限が、ロジックやデータ保持方針にも波及
これら3つの要素が相互に影響を与えるため、従来のソフトウェア開発におけるCI/CDナレッジだけでは対応しきれない難しさが生まれるのです。
具体的な取り組み：DBTスリムCI
CARTAマーケティングファームでは、DBTを使ったデータ変換でCI/CDを実装。膨大なデータをすべてテストするのは現実的でないため、「スリムCI」という割り切りを導入しています。
- 必要最小限のデータ（最新数行）でDBTモデルをビルドしてテスト
- リミットをかけたり、特定の日付範囲だけ抽出する工夫で、高速に動作可能
- 本番相当の大規模データまではチェックできないが、それは別の環境・仕組みで検証
- 事故が起きたときにすぐ戻せる仕組み
- 事前にスリムCIで「最低限動くこと」は保証し、もしデータ量が多い環境で問題が判明しても即リカバリできるようにしてある
こうしたアプローチで、「データオーナーがアイデアをすばやく実装→CIで最低限の安全を担保→本番で失敗しても早期に戻せる」というサイクルを実現。結果、ビジネスサイドの試行回数を増やし、スピーディなデータ活用を可能にしています。
Q&A・全体を通じたポイント
Q.「中央集権的なデータチームから脱却して分散運用するのはいつがいい？」
A.
- まずは、データ活用需要が爆発して「データ基盤チームがプルリク処理するだけでパンパン」になったタイミング
- そこで明らかにボトルネックが生まれ、ビジネス上のスピード低下を痛感しはじめる
- ただし、無闇に権限移譲すると事故るので、CI/CDでガードレールを敷きながら徐々に分散していく
Q.「データ基盤エンジニアの仕事は、分散運用したら無くなる？」
A.
- むしろ増える。従来はコード管理やリソース設定の窓口になりがちだったが、そこは自動化やOSSで解消可能
- 一方で「事業が求めるデータ」を創り出す課題は無限にある。全社的なデータ戦略の設計や、まだデータ化されていない領域の発掘など、やるべき仕事は尽きない
Q.「難しそうだけど、まずどう着手すればいい？」
A.
- リンター・フォーマッタなど、実装が容易かつメリットの大きいガードレールから始めるのが定石
- そこから、ドリフト検知やプランファイル管理のような高度機能を段階的に導入する
- 事故や失敗を“学ぶチャンス”と捉え、継続的に仕組みを進化させるのがポイント
全体を踏まえた感想──「データ基盤の失敗力」とCICDの未来
ソフトウェア開発では当たり前になったCI/CD。しかし「データ基盤 × CICD」は、単なるコードの自動テストやデプロイを超えて、三位一体の複雑さに対応する高度な仕掛けが必要になると感じさせられました。
とはいえ、最終ゴールは「データ活用でビジネス価値を生み出す」こと。失敗を効率化し、試行回数を増やすためにCI/CDを整える──という観点が特に印象的です。鈴木氏が開発するtfactionのようなOSSフレームワークがTerraformワークフローの高度化を促し、近森氏が示したDBTスリムCIなどの手法が大規模データならではの問題を巧みに解決している事例は、いずれも「事故を防ぎつつ、スピードを出す」という本質的な課題に応えるものでしょう。
データ基盤の時代は今後さらに進み、多種多様なチーム・ロールが触れる機会も増えるはずです。そんな中、「コード×データ×コンピュート」の三位一体を意識しながらCI/CDを組んでいくことは、もはや避けて通れない道となりそうです。
エンジニア個々が「どこまで責任を負うか」「どの部分をOSSや既存ツールに任せるか」を取り決め、最小限のコストで最大限の失敗を許容できる土壌を作り上げる。これこそがデータ基盤の未来を切り開くカギかもしれません。
本イベントを通じて、多くの参加者が「データ基盤のCICDはソフトウェア開発より一段難度が高いが、技術と仕組みづくり次第で十分実現可能」という確信を得られたのではないでしょうか。
ここから各社がどんなイノベーションを起こし、データ活用を加速させていくか、ますます注目が集まります。
