3年かけてオンプレETLを廃止した話

この記事は、Money Forward Engineer Advent Calendar 2025 12月8日の投稿です

はじめに

この記事では、オンプレミス上の ETL 基盤 Digdag/Embulkシステム（Digdag + Embulk） を、約 3 年かけて廃止した話を書きます。

• 開始：2022 年夏ごろ
• 最後のサーバ停止：2025年6月ごろ
• 並行タスクも多かったので、ゆるやかに続いた長期プロジェクトでした。

当時のシステム構成と Digdag/Embulkシステム の役割

ざっくりした構成はこんな感じでした。

• 各プロダクトの DB（MySQL など）
• オンプレ環境の Digdag/Embulkシステム（Digdag / Embulk）
• 分析基盤としての BigQuery（カジュアル基盤）、セキュア基盤 など

今回廃止したのは、オンプレ上の Digdag / Embulk です。

Digdag/Embulkシステム とは？

プロダクトのDBからBigQuery（カジュアル基盤）へ、日次でデータ転送する仕組み

• 技術スタック：
  • Embulk：データ転送・Transform・暗号化/復号（プラグイン）
  • Digdag：Embulk ジョブのオーケストレーション
• 全盛期は 1 日あたり 300 テーブル弱 を転送

Digdag/Embulkシステム が抱えていた主な課題

1. 日次バッチが 1 日で終わらない（突き抜け）

• ジョブ数・データ量の増加で、日次 ETL が 24 時間に収まらない
• 遅延が連鎖し、レポート・後続バッチに影響

2. オンプレとクラウドの接続がつらい

• プロダクトや DB が増えるたび、オンプレと AWS をつなぐ調整が発生
• ネットワーク・セキュリティ・監視など、毎回手間が大きい

3. オンプレなのでスケールアウトが重い

• リソース追加にリードタイムがかかる
• ピークだけスケールさせる、などの柔軟な運用が難しい
• 結果として「人力でなんとかする」運用に寄りがち

プロジェクトのゴールと方針

ゴール

• Digdag/Embulkシステム 上のジョブをすべて停止し、インスタンスを削除すること。
• 日次 300 弱のテーブル転送をすべて別の仕組みに移行

最終的にオンプレサーバをシャットダウン

技術的な方針

• Embulk + Digdag の日次 ETL を、AWS DMS / RDS Snapshot + Airflow ベースに置き換える。
• データ吸い上げ：AWS DMS / RDS Snapshot → S3
• セキュアな処理：復号基盤（別システム）にて別途実装
• オーケストレーション：Airflow で BigQuery（カジュアル基盤）に流す

Digdag/Embulkシステム の機能をどう置き換えたか

1. 単純な ETL 処理

• Before：Embulk で MySQL → BigQuery への日次コピー
• After：プロダクト側から新パイプラインを開通
• AWS DMS / RDS Snapshot → S3 → Airflow 経由で BigQuery へ
• クラウド内で完結することで、ネットワークとスケールの問題を軽減しました。

2. 暗号化 / 復号（Embulk Plugin）

• Before：Embulk プラグインでカラム暗号化 / 復号
• After：復号基盤（別システム）上に暗号化 / 復号処理を実装
• 暗号鍵管理やアクセス制御をセキュア基盤に寄せることで、セキュリティ要件への対応を一箇所に集約しました。

3. Transform 処理（Embulk の filter/formatter）

• Before：Embulk の Transform 機能で型変換・カラム追加など
• After：BigQuery 上に Transform 用の SQL を用意
• Airflow から実行するパイプラインとして管理
• 変換ロジックを SQL に寄せることで、レビュー・変更がやりやすくなりました。

4. 利用者テーブルの切り替え

• Digdag/Embulkシステム 由来テーブルを使っているダッシュボード・バッチが多数存在
• 対応方針：監査ログから「誰がどのテーブルを使っているか」を可視化
• 対象ユーザーに新テーブルを案内し、切り替えを依頼
• 必要に応じてクエリ書き換えをサポート
• 技術的な移行と「利用者の移行」を分けて進めたのがポイントでした。

タイムライン

• 2022 年 6 月ごろ：新しいパイプラインが動き始める
• 2022〜2024 年：機能ごとの移行、新旧パイプラインの並走、利用者切り替え
• 2025 年 4〜6 月ごろ：最後のジョブ停止・サーバシャットダウン → Digdag/Embulkシステム 完全停止

がっつり 3 年フルでやっていたわけではありませんが、「長く続いた撤退戦」という感覚でした。

苦労ポイント

1. 最初に「何を担っているか」をちゃんと分解する

Digdag/Embulkシステム は単なるコピー装置ではなく、

• ETL
• 暗号化/復号
• 各種 Transform
• 利用者ごとのカスタム要件

などを一手に引き受けていました。
これを最初に棚卸しし、「どの役割をどの基盤に移すか」を決めておいたのは、後半の迷走防止に効きました。
また、全量を最初に洗い出したのも良かったです。おかげで明確なゴールとマイルストーン設定をすることができました。

2. 技術移行と利用者移行は別物

新テーブルを作るだけでは終わらず、

• 監査ログで利用状況を把握
• 廃止ポリシーと期限の明示
• ダッシュボード・バッチ修正の支援

など、「人の側の移行」にもしっかり時間を使う必要がありました。

3. 撤退の最後がしんどい

• オーナー不明のジョブ
• いつのまにか誰かが依存しているテーブル

など、最後に残る「よく分からないもの」を潰し切らないとサーバは消せません。
ここはもう、ひとつずつ現物確認しながら地道にやりました。

さいごに

地味な仕事でしたが、アドカレの形で供養できて良かったです。