Aurora PostgreSQL → Datastream CDC IP変動問題 - 詳細調査・検証レポート

関連JIRA:

SRE-1687（初期調査・代替案検討）
SRE-1744（詳細調査・検証環境実装）

調査期間: 2025-09-05 〜 2026-02-12 検証実施日: 2026-02-13 ステータス: ✅ 検証完了（HAProxy方式で解決確認）

関連タスク: SRE-1687: 初期調査・代替案検討

1. 課題概要

発生している問題

AWS Aurora PostgreSQLのフェイルオーバーまたは再起動時にインスタンスのIPアドレスが変動し、GCE上のrinetdプロキシを介したGoogle Cloud Datastream CDCパイプラインが停止する。

根本原因: rinetdは起動時にのみDNS名前解決を行い、起動後のIP変動に追従できない
影響: BigQueryへのリアルタイムデータ連携が停止。手動でrinetd再起動が必要
発見日: 2025-09-05（rinetdの起動時のみ名前解決する挙動を検知できていなかった）

現在の構成

過去の経緯

日付	内容
2025-02-27	GCP公式ドキュメントの起動スクリプトがIP指定必須と判明。rinetd導入で対応
2025-09-05	フェイルオーバー時にDatastream停止を発見。rinetdが起動時のみ名前解決と判明
2025-09-22	NLBでAuroraエンドポイント直接指定不可を実機確認。5つの代替案を洗い出し
2026-02-10〜12	改めて各解決策を深掘り調査。コスト比較、trocco評価、HAProxy設定手順策定

2. 要件定義（オンライン事業部の要求事項）

要件項目	内容	優先度
データ転送時間SLO	3〜5分以内にBigQueryへ反映	🔴 必須
IaC化	Terraform管理必須（手動設定NG）	🔴 必須
フェイルオーバー時ダウンタイム	最小化（自動復旧）	🔴 必須
追加コスト	増加を回避したい	🟡 重要

3. 検討した解決策一覧

解決策の前提

各解決策はDatastreamの扱いが異なります：

解決策	Datastream	説明
①HAProxy置き換え	✅ 維持	既存のDatastream CDCパイプラインをそのまま使用。GCE上のプロキシソフトのみ変更
②NLB+Lambda	✅ 維持	既存のDatastream CDCパイプラインをそのまま使用。AWS側で固定IP提供
③trocco	❌ 廃止	Datastream全体をtrocco CDCに置き換え。VPN・GCE Proxy・GCP NLBも削減可能

解決策比較表

解決策	月額コスト（推定）	実装期間	ダウンタイム	IaC対応	レイテンシ	評価
①HAProxy置き換え	$0	1〜2日	5〜30秒	✅	数秒〜数十秒（実測値はステージング環境で確認予定）	⭐️⭐️⭐️ 推奨1位
②NLB+Lambda（AWS完結）	~$17〜20	3〜5日	5〜30秒	✅	数秒〜数十秒（実測値はステージング環境で確認予定）	⭐️⭐️ 推奨2位
③trocco Professional	¥50万〜80万+	2〜3週間	ゼロ（DNS対応）	❌ CDC非対応	5分以上（SLO超過リスク）	⭐️ 条件次第
❌RDS Proxy	~$43（推定）	-	-	-	-	❌ CDC非サポート

要件適合状況:

解決策	SLO（3〜5分）	IaC化	コスト	総合評価
①HAProxy	✅ 数秒〜数十秒（余裕）	✅ 対応	✅ $0	✅✅✅
②NLB+Lambda	✅ 数秒〜数十秒（余裕）	✅ 対応	🟡 +$17	✅✅
③trocco	❌ 5分以上（SLO超過リスク）	❌ CDC非対応	❌ +¥50万	❌

4. 各解決策の詳細評価

①HAProxy置き換え（GCEプロキシ改善）⭐️⭐️⭐️ 推奨1位

概要

項目	内容
月額コスト（推定）	追加 $0（既存GCEでrinetdをHAProxyに差し替えるだけ）
実装期間	2〜3日
フェイルオーバー時ダウンタイム	5〜30秒（DNS再解決5秒間隔）
Datastream設定変更	不要
既存インフラ変更	GCE内のプロキシソフトのみ。VPN・NLB・Datastream変更なし
IaC対応	✅ Terraform完全管理可能
レイテンシ	数秒〜数十秒（Datastream維持、実測値はステージング環境で確認予定）

仕組み

HAProxy 1.6以降のresolversディレクティブを使い、バックグラウンドで定期的にAuroraエンドポイントのDNSを再解決する。hold valid 5s設定により、TTLに関係なく5秒ごとに強制再解決。フェイルオーバーでIPが変わっても自動追従する。

メリット

✅ 追加コスト実質ゼロ（既存GCE内でソフト差し替えのみ）
✅ IaC完全対応（Terraform + 起動スクリプトで管理）
✅ 実装が簡単（設定ファイル変更とサービス再起動のみ）
✅ 既存構成への影響最小（VPN、NLB、Datastream設定変更不要）
✅ Datastreamの低レイテンシ維持（数秒〜数十秒、3〜5分SLOを余裕で達成）
✅ 自動復旧（フェイルオーバー後、手動介入不要）

デメリット

🟡 フェイルオーバー時に5〜30秒程度のダウンタイム発生（DNS再解決の待ち時間）
- ただし、3〜5分のSLO要件から十分に許容できる範囲
🟡 GCE内でHAProxyの運用・監視が必要（既存rinetdと同程度）
- HAProxy監視項目の定義・アラート設定は別タスクで対応予定: SRE-1679

設定ファイル

📄 HAProxy設定ファイル例（/etc/haproxy/haproxy.cfg）を表示

cfg

global
    log /dev/log local0
    log /dev/log local1 notice
    maxconn 256
    nbthread 1
    stats socket /run/haproxy/admin.sock mode 660 level admin

resolvers awsdns
    nameserver dns1 169.254.169.254:53
    resolve_retries 3
    timeout resolve 5s
    timeout retry   5s
    hold valid     5s
    hold other     5s
    hold refused   5s
    hold timeout   5s
    hold obsolete  5s

defaults
    log     global
    mode    tcp
    option  tcplog
    option  dontlognull
    timeout connect 10s
    timeout client  3600s
    timeout server  3600s
    retries 3

frontend pg_front
    bind *:5432
    default_backend pg_aurora

backend pg_aurora
    server aurora1 <Auroraクラスタエンドポイント>:5432 resolvers awsdns resolve-prefer ipv4 init-addr none check inter 5s

設定のポイント:

hold valid 5s: TTLに関係なく5秒ごとにDNS再解決を強制
init-addr none: 起動時にDNS解決できなくてもHAProxy自体は起動する
timeout client/server 3600s: CDCの長時間接続に対応（切れる場合は86400sに延長）
mode tcp: PostgreSQLワイヤプロトコルをL4でそのまま通す
nameserver 169.254.169.254: AWS VPC DNSリゾルバ（GCEのメタデータサーバー経由で到達）

ログ管理

rsyslog設定 (/etc/rsyslog.d/49-haproxy.conf):

# HAProxyログを専用ファイルに出力
local0.* /var/log/haproxy.log
& stop

logrotate設定 (/etc/logrotate.d/haproxy):

/var/log/haproxy.log {
    daily
    rotate 7
    missingok
    notifempty
    compress
    delaycompress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

②NLB＋Lambda自動更新（AWS側完結）⭐️⭐️ 推奨2位

概要

NLBのElastic IPで固定IP提供し、Auroraフェイルオーバー時にLambdaが自動的にターゲットを更新する方式。2つのアプローチが存在する。

パターンA：Lambda直接登録（シンプル版）

項目	内容
月額コスト（推定）	~$18（NLB + Lambda）
実装期間	2〜3日
構成要素	NLB、Lambda、EventBridge

仕組み:

フロー:

EventBridge: Auroraフェイルオーバーイベント検知
Lambda: クラスタエンドポイントをDNS名前解決してWriter Instance IPを取得
Lambda: NLBターゲットグループにAurora IPを直接登録・更新

メリット:

✅ EC2不要でシンプル
✅ コスト最小（NLB + Lambdaのみ）

デメリット/懸念点:

⚠️ Aurora直接接続の安定性: NLBのヘルスチェックがAuroraに直接行われるため、予期しない挙動の可能性
⚠️ 接続プーリング不可: EC2プロキシがないため、接続管理が限定的
⚠️ 実績不足: AWS公式ブログで推奨されていない構成

パターンB：EC2プロキシ経由（AWS公式推奨）

項目	内容
月額コスト（推定）	~$17〜20（NLB + EC2 t3.nano×2 + Lambda）
実装期間	3〜5日
構成要素	NLB、EC2（RDS Router）、Lambda、EventBridge

AWS公式ブログ: https://aws.amazon.com/blogs/database/how-to-use-amazon-rds-and-amazon-aurora-with-a-static-ip-address/

仕組み:

フロー:

EventBridge: Auroraフェイルオーバーイベント検知
Lambda: クラスタエンドポイントをDNS名前解決してWriter Instance IPを取得
Lambda: EC2上のiptables DNATルールを更新（転送先IPをAurora新IPに変更）
NLBのターゲットはEC2で固定（変更不要）

メリット:

✅ AWS公式ブログ推奨パターン（信頼性高い）
✅ ヘルスチェック安定性: EC2がプロキシとして機能、NLBヘルスチェックはEC2に対して実施
✅ 接続管理の柔軟性: EC2でiptables制御、接続の追跡・管理が可能
✅ IaC完全対応（Terraform管理可能）

デメリット:

🟡 追加コスト: +$17〜20/月（NLB、EC2、Lambda）
🟡 複雑度: リソース（EventBridge、Lambda、EC2、iptables設定）が多く管理コストが高い
🟡 NLBアイドルタイムアウト350秒のため、PostgreSQL keepaliveを350秒以内に設定必要
🟡 EC2管理負荷: パッチ適用、監視、冗長化（最低2台推奨）

③trocco Professional（代替CDCサービス）⭐️ 条件次第

概要

項目	内容
月額コスト（推定）	¥50万〜80万+
実装期間	2〜3週間
フェイルオーバー時ダウンタイム	ゼロ（DNS名前解決対応）
IaC対応	❌ CDC設定はTerraform管理不可（APIなし、GUI手動のみ）
レイテンシ	5分以上（最小実行間隔5分＋データ転送時間）

仕組み

trocco SaaSがAuroraクラスタエンドポイント（DNS）経由で接続するため、IP変動問題を本質的に回避。

Note: 本検討では、セキュリティ要件と閉域接続の観点から AWS PrivateLink接続を推奨構成 として評価した。

メリット

✅ IP変動問題の根本解決（DNS名前解決対応）
✅ VPN削減の可能性（PrivateLink or Self-Hosted Runner利用時）
✅ CDC以外のETL機能も利用可能（データ基盤統合）

デメリット

❌ IaC要件を満たさない：CDC設定がTerraform管理不可（API非対応、GUI手動のみ）
- TROCCO APIのエンドポイント一覧にCDC関連のAPIが存在しない
- Terraform ProviderはAPIの上に構築されているため、CDCの設定はGUI手動管理が必須
❌ SLO要件を満たせない：最小実行間隔5分＋データ転送時間を考慮すると、3〜5分SLOを超過する
- troccoのCDC最小実行間隔は5分固定
- 実際のデータ転送時間を加えると5分以上かかるため、SLO（3〜5分）を超過
- Datastreamは数秒〜数十秒のレイテンシ（実測値はステージング環境で確認予定）でSLOを余裕で満たすのに対し、troccoはSLO超過
❌ コスト大幅増：現構成の約10〜17倍（+¥50万〜80万/月）
🟡 年間契約・一括払い（柔軟性低い）
🟡 CDC機能はProfessional限定（下位プランでは利用不可）

コスト詳細

trocco Professional + PrivateLink構成（推定）:

コンポーネント	月額（推定）
trocco Professionalプラン	¥45万〜60万+（要問合せ）
PrivateLinkオプション	¥10万〜20万（要問合せ）
AWS NLB（PrivateLink用）	~$18（≒¥2,700）
CDC追加料金（レコード数ベース）	要問合せ
合計（最小見積）	¥50万〜80万+/月

現構成（Datastream）（推定）:

月額 ~$310（≒¥47,000）

コスト差: troccoは現構成の約10〜17倍

troccoの3つの接続パターン（参考）

本検討では AWS PrivateLink接続を推奨構成 として評価した。参考として他のパターンも記載する。

AWS PrivateLink接続（最もセキュア、本検討の前提）
- 削除可能: VPN全体、GCE Proxy、GCP側NLB、Datastream
- 新規必要: AWS側NLB（PrivateLink用）
Self-Hosted Runner（閉域完結・VPN不要）
- 削除可能: VPN全体、GCE Proxy、GCP側NLB、Datastream、PrivateLink用NLBも不要
- 新規必要: ECS Fargate（Runner用コンテナ）
SSHトンネル経由（最小構成）
- 削除可能: VPN全体、GCE Proxy、GCP側NLB、Datastream
- 新規必要: 踏み台EC2（既存流用可）

❌RDS Proxy（却下）

CDC用途には使用不可。

PostgreSQLのストリーミングレプリケーションモードを明示的にサポートしていない
AWS DMSドキュメントでも「RDS Proxy for PostgreSQLをCDCソースとして使用することはサポートしていない」と記載
仮にCDC非対応を無視しても、RDS Proxyエンドポイント自体がDNSベースでIP変動の可能性あり

5. 採用案の決定理由

結論：HAProxy置き換え（①案）を採用

決定理由:

評価軸	HAProxy	NLB+Lambda	trocco	判定
データ転送SLO（3〜5分）	✅ 数秒〜数十秒（余裕で達成）	✅ 数秒〜数十秒（余裕で達成）	❌ 5分以上（SLO超過）	HAProxy ✅
IaC化（マスト要件）	✅ 完全対応	✅ 完全対応	❌ CDC非対応	HAProxy ✅
追加コスト	✅ $0	🟡 +$17	❌ +¥50万	HAProxy ✅
実装期間	✅ 1〜2日	🟡 3〜5日	🟡 2〜3週間	HAProxy ✅
既存インフラ影響	✅ 最小	🟡 中程度	🟡 大きい	HAProxy ✅

総合評価: HAProxyが全ての要件を最も高いレベルで満たす。

各案が選ばれるケース

案	選択条件
HAProxy	現在の要件に最適。追加コスト不要、IaC完全対応、SLO余裕達成、実装短期
NLB+Lambda	AWS側で完結させたい場合。追加コスト$17が許容できる場合
trocco	VPN廃止によるインフラ簡素化に月額¥50万以上の価値を見出す場合。ただしIaC要件（マスト）を満たさず、SLO要件（3〜5分）も超過するため推奨しない

6. 採用案（HAProxy）の実装方法

実装例（Terraform + 起動スクリプト）

📄 Terraformコード例を表示

hcl

resource "google_compute_region_instance_template" "online_karte" {
  name         = "${var.service_online_karte}-${var.env}-gce-template"
  machine_type = var.machine_type

  # HAProxy起動スクリプトを外部ファイルから読み込み
  metadata_startup_script = templatefile("${path.module}/scripts/haproxy-startup.sh", {
    db_endpoint = local.db_endpoint_online_karte
  })

  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  network_interface {
    subnetwork = google_compute_subnetwork.private.id
  }

  tags = [
    "${var.service_online_karte}-allow-lb-postgres-datastream"
  ]
}

📄 起動スクリプト例を表示

bash

#!/bin/bash
set -e

DB_ENDPOINT="${db_endpoint}"
CONF_FILE="/etc/haproxy/haproxy.cfg"
LOG_FILE="/var/log/haproxy-setup.log"

# ログに記録
exec > >(tee -a $LOG_FILE) 2>&1
echo "$(date): Starting HAProxy setup"

# HAProxyとツールのインストール
apt-get update -y
apt-get install -y haproxy socat logrotate

# rsyslog設定（HAProxyログを専用ファイルに分離）
cat > /etc/rsyslog.d/49-haproxy.conf << 'RSYSLOG_EOF'
# HAProxyログを専用ファイルに出力
local0.* /var/log/haproxy.log
& stop
RSYSLOG_EOF

systemctl restart rsyslog

# logrotate設定（HAProxyログのローテーション）
cat > /etc/logrotate.d/haproxy << 'LOGROTATE_EOF'
/var/log/haproxy.log {
    daily
    rotate 7
    missingok
    notifempty
    compress
    delaycompress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
LOGROTATE_EOF

# HAProxy設定ファイルを作成
cat > "$CONF_FILE" << 'HAPROXY_EOF'
global
    log /dev/log local0
    log /dev/log local1 notice
    maxconn 256
    nbthread 1
    stats socket /run/haproxy/admin.sock mode 660 level admin

resolvers awsdns
    nameserver dns1 169.254.169.254:53
    resolve_retries 3
    timeout resolve 5s
    timeout retry   5s
    hold valid     5s
    hold other     5s
    hold refused   5s
    hold timeout   5s
    hold obsolete  5s

defaults
    log     global
    mode    tcp
    option  tcplog
    option  dontlognull
    timeout connect 10s
    timeout client  3600s
    timeout server  3600s
    retries 3

frontend pg_front
    bind *:5432
    default_backend pg_aurora

backend pg_aurora
    server aurora1 DB_ENDPOINT_PLACEHOLDER:5432 resolvers awsdns resolve-prefer ipv4 init-addr none check inter 5s
HAPROXY_EOF

# DB_ENDPOINTを置換
sed -i "s/DB_ENDPOINT_PLACEHOLDER/$DB_ENDPOINT/g" "$CONF_FILE"

# HAProxy起動
systemctl restart haproxy
systemctl enable haproxy

echo "$(date): HAProxy setup completed"
echo "Configuration:"
cat $CONF_FILE

7. 検証方法と結果

検証環境

環境: gcp/services/fd-datastream/sre-dev
AWSデータベース: online-karte-service/infra-dev Aurora PostgreSQL
GCPプロジェクト: fdt-sre-dev
VPN: AWS VGW ↔ GCP HA VPN（BGP ASN: AWS 64514, GCP 65011）
CIDR: 10.101.0.0/24 (private), 10.101.1.0/24 (datastream)

検証手順

1. Datastream CDC起動確認

bash

# GCP Cloud ConsoleでDatastreamのステータスを確認
# ステータスが「実行中」であることを確認
# BigQueryテーブルにデータが継続的に反映されていることを確認

2. フェイルオーバー実行とCDC継続確認（重要）

目的: Datastream稼働中にAuroraフェイルオーバーを実行し、新しいWriterインスタンスに対してデータがCDC経由で継続転送されることを確認

確認ポイント:

Datastreamが稼働中の状態でフェイルオーバーを実行
フェイルオーバー後、HAProxyが新しいWriter InstanceのIPを自動検知（約5秒）
新しいWriterインスタンスに対してINSERTしたデータがBigQueryに継続転送される
Datastreamのステータスがエラーにならず「実行中」のまま維持される

3. 長時間安定性確認

検証環境（infra-dev）: 1〜2時間放置してCDCが途切れないことを確認

ステージング環境: 24〜48時間放置してCDCが途切れないことを確認予定（本番展開前の最終確認）

検証結果（2026-02-13実施）

✅ 成功: Aurora PostgreSQLフェイルオーバー時にDatastream CDCパイプラインが中断せず継続稼働

検証実施内容

Datastream稼働中の状態でフェイルオーバーを実行
- Datastreamステータス: 実行中
- BigQueryへのCDC転送が正常に動作していることを事前確認
Auroraクラスタのフェイルオーバーを実行
- aws rds failover-db-clusterコマンドで手動フェイルオーバー
- 旧Writer → 新Writerへの切り替え（約30秒〜1分）
HAProxyの自動IP追従を確認
- フェイルオーバー実行後、約5秒でHAProxyが新しいAurora Writer InstanceのIPを検知
- DNS再解決により自動的に新しいIPへ接続切り替え
新しいWriterインスタンスに対してデータをINSERT
- フェイルオーバー完了後、Auroraクラスタエンドポイント経由でテストデータをINSERT
- 新しいWriterインスタンスでデータが正常に書き込まれることを確認
BigQueryでのデータ継続転送を確認
- フェイルオーバー後にINSERTしたデータがBigQueryに正常に反映されることを確認
- Datastreamのステータスがエラーにならず「実行中」のまま維持
- データの遅延・欠損なし
長時間安定性確認（検証環境）
- フェイルオーバー後、1〜2時間放置してCDCが途切れないことを確認
- Datastreamステータスが「実行中」のまま維持され、継続的にBigQueryへデータ転送
- HAProxyのログにエラーなし、DNS再解決が正常に動作

観測された動作

✅ Datastream接続が維持され、データ転送が継続
✅ BigQueryへのデータ反映に遅延・欠損なし
✅ 手動介入不要で自動復旧
✅ Datastreamステータスは「実行中」のまま（エラー発生するが即座に復旧する）

技術的メカニズム

PostgreSQL Keepalive（60秒間隔）により、HAProxyとAurora間のTCP接続が維持される
HAProxyが5秒ごとにDNS再解決を実行し、Aurora IPの変更を検知
新しいIPへの接続切り替えが自動的に行われる
DatastreamからはHAProxy経由で透過的にAuroraに接続されているため、IP変更を意識しない
新しいWriterインスタンスに対する書き込みもCDC経由でBigQueryに継続転送される

コスト影響（推定）:

追加コスト: $0
既存GCEインスタンス上でrinetdをHAProxyに置き換えるのみ
インフラ構成変更なし（VPN、NLB、Datastream全て既存のまま）

8. 次のアクション

✅ 完了した作業

[x] HAProxy設定調査・設計（2026-02-10〜12）
[x] 検証環境実装（infra-dev、2026-02-13）
[x] フェイルオーバーテスト（2026-02-13、成功確認）
[x] Datastream継続稼働確認（BigQueryへのCDCパイプライン中断なし）

📋 今後のアクション（別途対応予定）

1. 本番環境展開準備

[ ] ステージング環境への展開手順作成
[ ] 本番環境へのローリングアップデート手順作成
[ ] ロールバック手順の策定

2. 運用ドキュメント整備（🔴 重要度: 高）

[ ] GCE(HAProxy)監視項目の定義
- CPU/メモリ使用率の閾値設定
- HAProxyプロセス死活監視
- DNS解決失敗率の監視
- バックエンド接続エラー率の監視
[ ] アラート設定（Datadog等）
- 関連タスク: SRE-1679
[ ] インシデント対応フロー作成
- HAProxy障害時のエスカレーション手順
- フェイルオーバー検知時の確認手順
- Datastream停止時の復旧手順

3. 本番環境への段階的展開

[ ] ステージング環境でのフェイルオーバーテスト
[ ] ステージング環境での長時間安定性確認（24〜48時間）
[ ] レイテンシ実測値の取得（ステージング環境）
[ ] 本番環境へのローリング適用（1台ずつ）
[ ] 長期安定性監視（1週間〜1ヶ月）

4. 本番運用準備（🟡 重要度: 中）

[ ] 既知の制限事項のドキュメント化
- フェイルオーバー時の5〜30秒ダウンタイム
- HAProxyのDNS再解決間隔（5秒）の技術的制約
- GCE再起動時の影響範囲と対処方法
[ ] パフォーマンス測定（ステージング環境）
- 通常時のデータ転送レイテンシ実測
- フェイルオーバー時のダウンタイム実測
- HAProxyのリソース使用量測定
[ ] 運用上の制約・注意事項の文書化
- GCEインスタンステンプレート変更時の影響
- HAProxy設定変更時のダウンタイム有無
- Terraform apply時の影響範囲

5. セキュリティ・DR対策（🟢 重要度: 低）

[ ] セキュリティ考慮事項の整理
- HAProxyのログに含まれる情報の確認
- ログ保存期間とアクセス制御の確認
- 脆弱性管理（HAProxyパッケージの定期更新）
[ ] ディザスタリカバリ手順
- GCEインスタンス障害時の復旧手順
- HAProxy設定誤りの検知とロールバック
- VPN障害時の影響範囲と対処

9. 参考リソース

リソース	URL
HAProxy DNS resolution	https://www.haproxy.com/documentation/haproxy-configuration-tutorials/proxying-essentials/dns-resolution/
AWS公式ブログ（RDS/Aurora静的IP）	https://aws.amazon.com/blogs/database/how-to-use-amazon-rds-and-amazon-aurora-with-a-static-ip-address/
GCP Datastream リバースプロキシ設定	https://cloud.google.com/datastream/docs/private-connectivity?hl=ja#set-up-reverse-proxy
Datastream料金	https://cloud.google.com/datastream/pricing?hl=ja
trocco料金プラン	https://primenumber.com/trocco/pricing
trocco CDC PostgreSQL ドキュメント	https://documents.trocco.io/docs/cdc-data-source-postgresql
trocco Terraform Provider	https://registry.terraform.io/providers/trocco-io/trocco/latest
trocco APIリファレンス	https://documents.trocco.io/trocco-api/apidocs
AWS PrivateLink料金	https://aws.amazon.com/jp/privatelink/pricing/
AWS RDS Proxy CDC制約（DMSドキュメント）	https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html

Aurora PostgreSQL → Datastream CDC IP変動問題 - 詳細調査・検証レポート ​

1. 課題概要 ​

発生している問題 ​

現在の構成 ​

過去の経緯 ​

2. 要件定義（オンライン事業部の要求事項） ​

3. 検討した解決策一覧 ​

解決策の前提 ​

解決策比較表 ​

4. 各解決策の詳細評価 ​

①HAProxy置き換え（GCEプロキシ改善）⭐️⭐️⭐️ 推奨1位 ​

概要 ​

仕組み ​

メリット ​

デメリット ​

設定ファイル ​

ログ管理 ​

②NLB＋Lambda自動更新（AWS側完結）⭐️⭐️ 推奨2位 ​

概要 ​

パターンA：Lambda直接登録（シンプル版） ​

パターンB：EC2プロキシ経由（AWS公式推奨） ​

③trocco Professional（代替CDCサービス）⭐️ 条件次第 ​

概要 ​

仕組み ​

メリット ​

デメリット ​

コスト詳細 ​

troccoの3つの接続パターン（参考） ​

❌RDS Proxy（却下） ​

5. 採用案の決定理由 ​

結論：HAProxy置き換え（①案）を採用 ​

各案が選ばれるケース ​

6. 採用案（HAProxy）の実装方法 ​

実装例（Terraform + 起動スクリプト） ​

7. 検証方法と結果 ​

検証環境 ​

検証手順 ​

1. Datastream CDC起動確認 ​

2. フェイルオーバー実行とCDC継続確認（重要） ​

3. 長時間安定性確認 ​

検証結果（2026-02-13実施） ​

検証実施内容 ​

観測された動作 ​

技術的メカニズム ​

8. 次のアクション ​

✅ 完了した作業 ​

📋 今後のアクション（別途対応予定） ​

1. 本番環境展開準備 ​

2. 運用ドキュメント整備（🔴 重要度: 高） ​

3. 本番環境への段階的展開 ​

4. 本番運用準備（🟡 重要度: 中） ​

5. セキュリティ・DR対策（🟢 重要度: 低） ​

9. 参考リソース ​

Aurora PostgreSQL → Datastream CDC IP変動問題 - 詳細調査・検証レポート

1. 課題概要

発生している問題

現在の構成

過去の経緯

2. 要件定義（オンライン事業部の要求事項）

3. 検討した解決策一覧

解決策の前提

解決策比較表

4. 各解決策の詳細評価

①HAProxy置き換え（GCEプロキシ改善）⭐️⭐️⭐️ 推奨1位

概要

仕組み

メリット

デメリット

設定ファイル

ログ管理

②NLB＋Lambda自動更新（AWS側完結）⭐️⭐️ 推奨2位

概要

パターンA：Lambda直接登録（シンプル版）

パターンB：EC2プロキシ経由（AWS公式推奨）

③trocco Professional（代替CDCサービス）⭐️ 条件次第

概要

仕組み

メリット

デメリット

コスト詳細

troccoの3つの接続パターン（参考）

❌RDS Proxy（却下）

5. 採用案の決定理由

結論：HAProxy置き換え（①案）を採用

各案が選ばれるケース

6. 採用案（HAProxy）の実装方法

実装例（Terraform + 起動スクリプト）

7. 検証方法と結果

検証環境

検証手順

1. Datastream CDC起動確認

2. フェイルオーバー実行とCDC継続確認（重要）

3. 長時間安定性確認

検証結果（2026-02-13実施）

検証実施内容

観測された動作

技術的メカニズム

8. 次のアクション

✅ 完了した作業

📋 今後のアクション（別途対応予定）

1. 本番環境展開準備

2. 運用ドキュメント整備（🔴 重要度: 高）

3. 本番環境への段階的展開

4. 本番運用準備（🟡 重要度: 中）

5. セキュリティ・DR対策（🟢 重要度: 低）

9. 参考リソース