はじめに
データ分析基盤において、スキーマ変更などを人手に依存せず検知する「Detection-based Ops（検知ベースの運用）」を目指し、Aurora MySQLからDatabricksへのCDC（Change Data Capture）連携を検証しました。
当初は、運用の手軽さを見込んでDatabricksのフルマネージドサービスである「Lakeflow Connect (LFC)」を基本方針として採用していました。
しかし、執筆時点（2026年3月）でLFCはまだ「Gated Public Preview（限定公開プレビュー）」の段階であり、実際の運用を想定した検証を進める中で、理想と現実のギャップが明らかになりました。
本記事では、その経緯とアーキテクチャ変更の判断について共有します。
直面した5つの課題（理想と現実）
LFCは非常に魅力的なサービスですが、私たちの環境・要件においては以下の3つの課題が表面化しました。
1. パフォーマンスのギャップ
システムとして目標とする連携速度は1〜2分でしたが、実測では7〜8分を要してしまい、要求されるパフォーマンスとの間に大きなギャップがありました。
2. DDL変更時のSCD Type 2履歴保持の複雑化
データソース側でカラム型の変更などのDDL操作が行われた際、SCD Type 2での履歴保持や運用管理が複雑になる懸念がありました。場合によっては蓄積データを全削除し、再流し込みが必要になるケースも想定されました。
3. 空間データ（GEOMETRY型）への非対応
業務上取り扱う必要のある空間データ（GEOMETRYなど）の型が、現在のLFCでは非対応であることが判明しました。
4. プレビュー機能特有の運用負荷とIaC（インフラコード化）の壁
現在のLFCは「Gated Public Preview（限定公開プレビュー）」の段階であり、本番稼働を見据えた際には手探りでのトラブルシューティングが多く発生しました。例えば、Aurora側のBinlog保持期間との兼ね合いで MYSQL_BINLOG_FILE_DELETED エラーに直面した際、パイプラインの状態をリセットして全データを再取り込みする「Full Refresh」を余儀なくされる運用上の脆さがありました。また、接続エラーの連続によってMySQL側でホストアクセスがブロックされ、手動で flush-hosts を実行して復旧させる手間も発生しています。さらに、これらLFCのパイプライン構築がTerraform（IaC）の管理スコープ外となっており、手作業による運用（トイル）が残ってしまう点も自動化を目指すインフラチームにとって大きな懸念でした。
5. 厳格なセキュリティ要件とネットワーク構成の摩擦
今回の基盤はPII（個人情報）を扱うため、インターネットへの露出を最小化すべく、AWS PrivateLink、VPC Lattice、NLBなどを組み合わせたセキュアな閉域網接続を標準としています。しかし、この複雑なプライベートネットワーク要件とマネージドサービスであるLFCの相性調整は難航しました。「Request failed private link validation」といったブラックボックス化されたネットワークエラーの切り分けに苦労したほか、IPアクセスリストやPrivate DNSの制約により正規のワークスペースアクセスがブロックされるなど、インフラ構築の摩擦が開発スピードを低下させる要因となっていました。
意思決定（アーキテクチャのピボット）
最新のマネージドサービスを利用すること自体を目的とするのではなく、事業に直結するインパクト（連携速度や運用継続性）を最優先に考えました。
上記の検証結果を受け、私たちはLFCへの固執を捨て、「Amazon DMS + Auto Loader」 の構成を最有力な代替案として検討し、切り替えを進める決断をしました。
新旧アーキテクチャの比較表
LFCで直面した課題が、DMS + Auto Loaderへの切り替えでどう解消されたかをまとめました。
| 評価軸 | Lakeflow Connect (Gated Public Preview) | Amazon DMS + Auto Loader (新構成) |
|---|---|---|
| 連携パフォーマンス | 7〜8分（テーブル数によるオーバーヘッド大） | 1〜2分（ニアリアルタイム連携が可能） |
| スキーマ変更への追従 | SCD2履歴保持が複雑。Full Refreshのリスクあり |
schemaEvolutionMode で新規カラム追加等に柔軟に追従
|
| データ型の対応 | 空間データ（GEOMETRY等）非対応 | キャスト等を含め柔軟に連携可能 |
| IaCと運用安定性 | Terraform未対応。手作業での復旧や構築が多い | 完全なTerraform化が可能。成熟した技術で運用が安定 |
| 閉域網・セキュリティ | PrivateLink等との組み合わせ・切り分けが難航 | AWSの標準的なVPCエンドポイントとルーティングで完結 |
新しいアーキテクチャ構成図
構成としては、AWS DMSを用いてAuroraのBinlogをキャプチャし、S3へニアリアルタイムに出力。それをDatabricksのAuto Loaderでストリーミング（またはマイクロバッチ）としてDelta Tableに取り込む形になります。
Auto Loaderの強み（スキーマ進化の吸収）
DMSとAuto Loaderを組み合わせる最大のメリットは、データソース側のDDL変更（カラム追加など）に強い点です。以下は実際のAuto Loader（PySpark）の実装イメージですが、cloudFiles.schemaEvolutionMode を活用することで、パイプラインを止めることなくスキーマの変更に追従できます。
# Auto Loaderを用いたS3からのCDCデータ取り込み例
df = (spark.readStream
.format("cloudFiles")
.option("cloudFiles.format", "parquet") # DMSからの出力フォーマットに合わせる
.option("cloudFiles.schemaLocation", "/mnt/schema_location/") # スキーマを推論・記憶するパス
.option("cloudFiles.inferColumnTypes", "true")
.option("cloudFiles.schemaEvolutionMode", "addNewColumns") # 💡新規カラムが追加されても自動で追従！
.load("s3://dms-landing-bucket/cdc-data/")
)
# Bronzeテーブルへの書き込み
(df.writeStream
.format("delta")
.option("checkpointLocation", "/mnt/checkpoint/")
.trigger(availableNow=True) # 💡コスト最適化のため、溜まった分だけ処理して停止（マイクロバッチ化）
.toTable("main.bronze.cdc_raw")
)
このように、マネージドサービス（LFC）でブラックボックス化されていた部分を、DMSとAuto Loaderの組み合わせに分解することで、「1〜2分という速度要件」 と 「DDL変更時の柔軟な対応」 の両方をクリアすることができました。
まとめと今後に向けて
新しい技術やマネージドサービスは魅力的ですが、自社のデータ特性や厳しいパフォーマンス・セキュリティ要件に合致するかを早期のPoCで見極めることが重要です。技術のメリット・デメリットを冷静に比較し、要件に合わせて柔軟にアーキテクチャをピボット（方針転換）する決断力こそが、堅牢なデータパイプライン構築の勘所となります。
なお、今回は採用を見送りましたが、Lakeflow Connectの「外部ソースからDatabricksまでをシームレスに統合する」というコンセプト自体は、データエンジニアリングの運用を劇的にシンプルにする素晴らしいポテンシャルを秘めています。
今後GA（一般公開）を迎え、Terraform対応の拡充や、閉域ネットワーク要件への柔軟性が増したタイミングで、改めて再評価したいと強く期待しています！
同じようにデータ連携方式で悩んでいる方の参考になれば幸いです!!