この記事は#GauDev Advent Calendar 2025の18日目です。
はじめに
社内で「AWS にある基幹データを GCP でほぼリアルタイムで分析したい」というケースがあったので、そのためのデータパイプラインの基礎をつくった話です。
結果として、いくつもの問題に直面しながら泥臭く構築することになりました。
本記事は、私が経験したことの一部を記録したものです。同じようなマルチクラウド構成を検討している方にとって、少しでも参考になれば幸いです。
結論
以下で記載する文章の最終的なサンプルは Terraform で組んでいるので、興味がある方はこちらを参考にしてください。
目的
今回の目的は、AWS 上で稼働している Aurora RDS (MySQL) のデータを、GCP の GCS もしくは BigQuery へ CDC（Change Data Capture） 形式で同期することです。
バッチ処理による夜間同期などではなく CDC を採用することで、分析データの鮮度を準リアルタイムに保つこと、を狙っています。
今回構成するパイプラインを応用すれば、ダウンタイムなしの Spanner への移行などの手段となりえます。
検討
目的を実現するためには AWS と GCP でそれぞれソリューションが考えられました。
- AWS DMS
- GCP Datastream
どちらを選ぶかの検討は、以下の前提状況があったので、あまり時間をかけませんでした。
- 私個人また会社としても AWS の知見はほぼなく、GCP に慣れている
- Datastream の接続設定がシンプルでわかりやすく、データの受取先になる GCS, BigQuery への設定も容易
ここはシンプルに考えて、GCP Datastream を主軸に CDC パイプラインを構築することで、目的は達成できるだろうと考えました。
課題としてつまづいたこと
いろんなつまづきポイントはありましたが、検討が大きく必要だったことを2点上げたいと思います。
AWS と GCP がつながらない
Datastream のドキュメントを読んでいると、データソースとの接続には大きく4つの手段があることがわかります。
- IP許可リスト
- フォワードSSHトンネル
- Private Service Connect
- VPCピアリング
ドキュメントを参考に、この中でセキュリティ要件と社内の事情も考慮して、許容できて、工数も比較的安くすむものは PSC (Private Service Connect) だと考えました。
しかし、なかなかうまく接続ができませんでした。ドキュメントを参考に、PSC の接続を試みましたが、うまくいかず、久々に悩んでいました。
結局、問題だったのはシンプルなことで、まず VPN で AWS と GCP のネットワークをつなぐ必要がありました。
これを理解するまで2,3日かかりました...。
時間がかかってしまった理由を考えると、以下の思い込みや自身の足りなさがありました。
- ネットワークの知識が浅い
そもそもネットワークに関する知識が浅かったので、勘所がありませんでした。
VPN をつながないといけないという発想も当初出てこなかったし、恥ずかしい限りです。
この機会に TCP/IP マスタリングから読み直したりして、徐々に解像度をあげていきました。
-
上記の公式ドキュメントで、VPCピアリングに関して
考慮事項：データベースと Google Cloudの間にプライベート ネットワーク接続（VPN、Interconnect など）が必要
と記載してある。
PSC にはこの考慮事項はかかれていなかったので、知識が足りない自分は逆説的に「VPN を設定しなくても接続できるのかも」と思い込んでいました。
- AI で調査しても、VPN の設定に言及されない
プロンプトが悪いと思いますが、何回か試しても、PSC 単体で AWS と GCP のマルチクラウド構成ができるような回答が返ってきてしまい、知識が浅い自分は間違った情報かどうかを判断するのに時間がかかりました。
回答を元に自分で調べても確証を得られるソースが出てこないので、より混乱に陥っていました。
これらの反省はしつつ、VPN の接続の検討を開始しました。
VPN について
VPN の接続設定でも AWS, GCP どちらを主軸に置くかによって選択肢が複数あります。
ここも検討は深くやり過ぎずに、以下の前提で考えて GCP の HA VPN (High Availability VPN) に決めました。
- AWS より GCP に慣れている
- CDC に関する設定がほぼ GCP のみで完結するため、見通しがいい
VPN の接続に関しては、基本的に以下のドキュメントに書かれている内容を行えば設定できました。ただし、ドキュメント通りにいかない部分もあったので、試す場合はエラーを確認しながら進めてください。
Aurora のバックフィル時の負荷
2つ目の問題として、Aurora の仕様上、ライターインスタンスでしか binlog が取得できないため、バックフィルをする時に、本番稼働しているDBへの負荷が懸念になりました。
この注意点はドキュメントにも書いてあります。
Amazon Aurora MySQL データベース用に CDC を構成する前に、既存の Aurora クラスタがあり、プライマリ データベース サーバーのライター エンドポイントに接続していることを確認してください。
初期ロードでは、テーブルのフルスキャンになるため、大きな負荷がかかることが予想できます。
他の記事のケースでは、この仕様のため実運用を諦めたものもありましたが、何か良い解決策がないかを練りました。
最終的に、3点の解決方法を検討しました。
- Aurora Blue/Green deployment を利用して、レプリカ（Green）を作成し、CDC は Green をターゲットとして行う
- Datastream のバックフィル同時実行数を下げる（デフォルト: 20）
- Datastream を開始した時点のデータから取り始め、それ以前のデータはスナップショットから再構築する
1 は本番環境に影響を与えずにできる、一番安全な方法だと考えます。しかし、本番相当のDBを2つ分稼働させるコスト面、レプリカを用意・破棄する運用コスト面、DBのタイプによる実施可否などの考慮は必要です。
2 は一番工数も低く妥当な案です。しかし、CDCするテーブルによってはフルスキャンを許せなかったりすると思うので、要件によるところがあります。
3 は負荷をかけずに、他の手段と組み合わせてすべてのデータのレプリケーションが実現できそうなので、一番良い方法だと感じます。ただ、2 で問題なく実現できるのであれば、3のための追加の工数をかけずに済みます。
弊社の場合は、データ全てではなく、特定のテーブルのみを対象としていたので、本番相当のデータで 2 の検証をまず行い、トランザクションの量も加味して問題がないと判断できたので、バックフィルの同時実行数を 5 にさげて実行することにしました。
より可用性をあげるために
本番で CDC を運用するには、接続の安定性や障害時の復旧能力など、他にも検討すべき事項が多数あります。以下は個人的に採用したほうがいいと思う事項を2つ上げます。
AWS Transit Gateway (TGW) の利用
GCP の HA VPN と AWS を接続する際、AWS 側のゲートウェイとして VGW (Virtual Private Gateway) と TGW (Transit Gateway) のどちらを使うかという選択肢があります。
当初は安価な VGW を検討していましたが、以下の理由から TGW を採用しました。
-
将来的な拡張性（柔軟性）
TGW はリージョンルーターとして機能するため、複数の VPC を集約して接続できます。将来的に対象の VPC が増えた場合でも、VPN 設定を変更することなくルーティングの設定のみで対応可能です。 -
可用性とスループットの向上
TGW は ECMP (Equal-Cost Multi-Path) ルーティング をサポートしています。 GCP の HA VPN は 99.99% の稼働率を提供するために複数のトンネル（インターフェース）を使用しますが、TGW 側で ECMP を有効にすることで、複数の VPN トンネルをアクティブ・アクティブな状態で使用できます。 これにより、片方のトンネルに障害が発生しても瞬時に別ルートへトラフィックを流せるため、通信断のリスクを最小限に抑えることができます。
ただし、VGW に比べて TGW は時間課金やデータ処理料金が別途発生するため、コスト試算は事前に行うことをおすすめします。
Aurora RDS の binlog は GTID ベースに
MySQL のレプリケーション設定において、標準的な binlog ファイル位置（File名 + Offset）ベースではなく、GTID (Global Transaction ID) を有効にすることを強く推奨します。
Aurora はクラスター構成のため、障害時にはプライマリインスタンスのフェイルオーバーが発生します。 ファイル位置ベースで管理している場合、フェイルオーバー後に新プライマリと旧プライマリで binlog ファイルの名前やオフセット位置が一致しないことが考えられ、Datastream が「どこからデータを読み取ればいいか」を見失い、レプリケーションが破損してしまいます。
一方、GTID はトランザクションごとに一意の ID が振られるため、サーバーが切り替わっても「この ID の次からデータをください」と指定することで、一貫性を保ったまま同期を再開できます。
Datastream のドキュメントでも GTID の利用は前提条件に近い形で記載されています。 （余談で、Google のドキュメントあるあるですが、英語でしか書いていない情報があったりするので、深堀りたいときは英語で探すのが良いです）
他の検討事項
本記事では接続と初期構築にフォーカスしましたが、以下の観点も詰め切る必要があります。
-
スキーマ変更（DDL）への追従戦略
Datastream はカラム追加などの一部の DDL には自動追従しますが、互換性のない変更（カラム削除や型変更など）が発生した場合、ストリームが停止したりデータ不整合が起きたりするリスクがあります。アプリ側のリリースフローとどう連携するかは重要な設計ポイントです。 -
AWS 側のデータ転送料（Egress Cost）
CDC は常にデータを転送し続けるため、GCP 側の料金だけでなく、AWS 側の「インターネット（またはVPN）へのデータ転出料」が従量課金で発生します。大量のデータを同期する場合、ここが隠れたコスト要因になるため、事前の試算が必須です。 -
監視体制の確立
マルチクラウド構成になるので、どのように監視体制を構築して、どんなアラートを設定するのかの検討が必要です。 -
セキュリティ要件（CMEKなど）
より高度なセキュリティ要件がある場合、顧客管理暗号鍵（CMEK）を用いたデータの暗号化や、VPC Service Controls の境界設定なども検討範囲に入ってきます。
などなど、検討しなければいけない事項はありますが、長くなってしまうので、この記事では割愛します 🙇
おわりに
今回、AWS と GCP という異なるクラウドベンダー間での CDC パイプラインを構築しましたが、振り返ってみると 「データの連携設定（Datastream）」そのものよりも、「データの通り道（Network）」の構築に最も頭を悩ませました。
便利なマネージドサービスが増えても、クラウドを跨ぐような要件では、TCP/IP やルーティング、VPN といった低レイヤーの知識が不可欠であることを痛感する良い機会となりました。
マルチクラウド構成は複雑になりがちですが、適切に設計すれば、それぞれのクラウドの「いいとこ取り」ができる強力な武器になります。 本記事が、みなさんのデータ基盤構築の一助となれば嬉しいです。
#GauDev Advent Calendar 2025、明日12月19日の担当はAndo Fumimasaさんです！
Gaudiy（ガウディ）グループ所属エンジニアの個人発信をまとめたPublicationです。 公式Tech Blog：techblog.gaudiy.com/
Discussion