TROCCO の転送ジョブ・ワークフローを Terraform で IaC 化する
株式会社メドレー / 山邉哲生
EM / データエンジニア / 従業員規模: 1,001〜5,000名
アーキテクチャ
.png?disposition=inline)
アーキテクチャの意図・工夫
全体像としては、AWS 上のプロダクト基盤や kintone などの外部システムからのデータを TROCCO で BigQuery に集約し、dbt で加工した上で、再び TROCCO を経由して kintone / Metabase / スプレッドシートなどの業務ツールへ配信する、という構成を取っています。BigQuery を中心としたデータ基盤が全体のハブとなり、その入口と出口の両方を TROCCO が担う形です。
データ組織が管掌する領域で既に Terraform 管理を行っていたのは、図の下部にある社内向けデータポータルでした。今回新たに、BigQuery への入口となる TROCCO と、BigQuery からの出口となる TROCCO の双方を Terraform 配下に加え、データポータルと合わせて「データに関わる処理と環境を統一的に管理できる」状態に近づけています。
Terraform は責務単位で分割し、独立したモジュールとして扱える構成にしています。また、プロダクト側のスキーマ情報から tf ファイルを生成する一連のフローを Claude Code の Skills として定義することで、チーム内で同じ型に沿って作業を進められるようにしている点も工夫の一つです。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
メドレーでは ETL ツールの一つとして TROCCO を活用していますが、連携対象のテーブルや連携先が増えるにつれて、だんだんと GUI での運用コストが上がっている状態でした。
具体的には、
- カラムの型変換や連携処理の命名などのポリシーが設定した人や時期によってバラバラになる。また途中でポリシー変更をすると全部開き直して一つ一つ修正を適用しないといけない。
- 転送ジョブが増えるとワークフローの設定画面が重くなったり、どのノードがどのジョブかの視認性が著しく低くなる。また依存関係を管理するのが難しい。
- 新規プロダクトが立ち上がった時、数十のテーブル連携を一気に立ち上げる必要があるが一つ一つスキーマ定義をチェックして設定していかなくてはいけない。
- 転送元が抽出用の SQL とセットの場合、転送設定とともに SQL もコード管理対象としたいが GUI 上でしか確認できず、テストと反映が手作業になる。
といった課題がありました。
どのような状態を目指していたか
これらの課題はいずれも GUI 運用に起因するものであり、TROCCO の転送ジョブ・ワークフロー・スケジュール、さらには抽出 SQL までを含めて、すべてコードとして Git 管理下に置く(= IaC : Infrastructure as Code)ことで一挙に解消できると考えていました。
ポリシーをコード上で共通化・テンプレート化し、ワークフローや依存関係も宣言的に定義。また新規プロダクト立ち上げ時にはアプリケーションのスキーマ定義を起点に転送設定を一気通貫で生成・反映できる、そんな状態をゴールとしていました。
選定理由
決め手になったのは、ちょうど以下の3点が揃ったタイミングだったことです。
1. Terraform Provider for TROCCO のサポート拡充
近年 Terraform Provider for TROCCO の開発 が活発に行われ、転送ジョブ・ワークフロー・スケジュールといった主要リソースをコードで宣言できるようになりました。Provider がなければ TROCCO の IaC 化は成立しないため、これが大前提となります。
2. データ組織内での Terraform 運用実績
私たちのデータ組織では、別途運用しているデータポータル(社内向けデータ活用アプリケーション)のインフラ構成管理に Terraform を採用しており、運用ノウハウが蓄積されていました。TROCCO も同じツールチェーンに乗せられれば、「データに関わる処理と環境を統一的に管理できる」状態が実現でき、既存の型を流用することで導入コストを最小限に抑えられます。
3. 生成 AI による IaC 化の支援
インフラをコードで宣言する IaC は生成 AI との相性が良く、GUI で設定されていた既存リソースを再現するための tf ファイルの構成パターンの解析も可能です。結果として新規の類似連携設定はテーブル定義から直接生成できるようになるなど、一連の生成フロー整備に必要なコストを大きく下げられる見通しが立ちました。
導入の成果
改善したかった課題はどれくらい解決されたか
TROCCO の各種設定を Terraform 配下に置くことで、GUI からの手修正のほとんどをコード経由に寄せられました。導入前に挙げた課題は、いずれも大きく改善しました。
どのような成果が得られたか
- TROCCO 上の設定がほぼすべてコード管理可能になり、変更内容のレビュー・記録が容易になった
- terraform plan による事前差分確認で、本番反映前に意図しない変更を検知できるようになった
- アプリケーション側のスキーマ定義を起点に、テーブル連携からワークフロー組み込みまでを一気通貫で記述できるようになり、新規プロダクト立ち上げ時のリードタイムが大きく短縮された
- 抽出 SQL も転送設定と同じリポジトリでバージョン管理されるようになった
- 生成 AI を組み合わせた設定フローを整備したことで、既存 GUI 資産、並びに新規転送設定のコード化コストを大きく下げられた
導入時の苦労・悩み
TROCCO は長らく GUI 前提で運用してきたため、既存設定から tf ファイルを起こすまでの流れを確立するのが最初の山場でした。どの粒度でコード化し、terraform import とどう突き合わせて差分を潰すか、という型ができるまでに試行錯誤が必要でした。
ここで効いたのが、決め手の3点目にも挙げた生成 AI の活用です。TROCCO の API でリソースを列挙し、スキーマを AI に渡して tf ファイルを自動生成、terraform import → plan で差分を確認する、という流れを Claude Code の Skills として定義しました。一度型を作ってしまえば以降は同じフローに乗せるだけで進められ、既存ジョブのコード化を現実的な工数で回せるようになっています。
導入に向けた社内への説明
上長・チームへの説明
すでに一定の運用実績がある中で、GUI ベースでの運用負荷はチーム内でも共通の見解だったため特に大きな議論はありませんでした。
活用方法
データ組織のメンバーが、TROCCO の転送ジョブ・ワークフロー・抽出 SQL の追加・変更依頼などに対応する際に利用しています。新規プロダクトのデータ連携立ち上げや既存連携の変更は tf ファイルの作成を起点に進めています。
よく使う機能
- Terraform Provider for TROCCO : TROCCO 関連の設定変更を Terraform で行うための Provider です
- terraform import : GUI で構築済みの既存ジョブをコード化するために利用しています。一括置き換えのリスクを取らずに、既存資産を少しずつ IaC 配下へ移行できる点が重宝しています。
- terraform plan / apply : 変更内容を本番反映前に可視化するために利用しています。意図しない差分がないかをレビュー時点で確認でき、事故防止のガードレールとして機能しています。
- Remote State(S3 + DynamoDB) : State と Lock をチーム共通のリモートに集約するために利用しています。複数人で同じリソースを触る際の競合を防ぎ、変更履歴を一元管理できる状態を維持しています。
ツールの良い点
- 宣言的な記述と terraform plan による事前差分確認により、変更内容がコード上でもレビュー時点でも明確になる
- Provider エコシステムが非常に広く、AWS や GCP といったクラウドだけでなく TROCCO のような SaaS まで扱える
- terraform import によって既存リソースを段階的にコード化でき、GUI 前提で運用してきた資産も無理なく IaC 配下へ移行できる
- HCL はシンプルかつ記述量が少なく、生成 AI との相性も良いため、既存リソースから tf ファイルを自動生成するフローを組みやすい
ツールの課題点
- HCL 独自の記法・関数に一定の学習コストがあり、初見のメンバーがキャッチアップするまでに時間がかかる
- GUI 前提で運用されてきたサービスを後から IaC 化する場合、既存設定の取り込みフローを確立するまでに一定の試行錯誤が必要になる
- 運用によっては IaC 化後も GUI 操作による変更が引き続き発生することがあり、コードと実態のドリフト(乖離)が発生しやすい
ツールを検討されている方へ
最初から全リソースを一気に IaC 化しようとせず、まずは1つのユースケースから始め、terraform import で既存資産を段階的に取り込むアプローチがおすすめです。TROCCO のように GUI 前提で運用されてきたサービスは、既存設定から tf ファイルを起こすフローを確立するのが最初の山場なので、ここは生成 AI との組み合わせが非常に効きます。コード化を AI に任せられる土台を早めに整えておくと、移行作業やその後の新規追加作業は同じ型に乗せるだけで進められます。
また、IaC 化後も GUI からの変更が発生しうるサービスについては、ドリフト前提で運用を設計しておくと安心です。定期的に plan を流して差分を検知する仕組みや、GUI 変更を原則禁止するといった運用ルールを、導入初期から決めておくのが良いかもしれません。
今後の展望
現在は TROCCO のジョブ・ワークフロー・抽出 SQL を Terraform 配下に置く第一段階がようやく軌道に乗ってきた状況です。今後はこれをベースに、アプリケーション側のスキーマ変更を検知して tf ファイルの更新 PR を生成し、terraform plan まで自動で流して人間によるレビュー後に apply、といった一連のフローを生成 AI エージェントに任せられる状態を目指しています。あわせて、ドリフト検知の定期実行も整備していきたいです。
また、Terraform Provider for TROCCO は現在も活発に開発が進められているため、新しくサポートされるリソース・転送先に追従しながら、データ連携領域の IaC カバレッジをさらに広げていきたいと考えています。
株式会社メドレー / 山邉哲生
EM / データエンジニア / 従業員規模: 1,001〜5,000名
よく見られているレビュー
株式会社メドレー / 山邉哲生
EM / データエンジニア / 従業員規模: 1,001〜5,000名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


