FastDoctor AWS Infrastructure

Appearance

SRE-1687: Datastream連携のためにAuroraのエンドポイントをIPアドレスで固定化させる方法の検討 ​

チケット概要 ​

JIRA URL:

概要: AWS Aurora PostgreSQLのフェイルオーバーまたは再起動などインスタンスのIPアドレス変更時にGoogle Cloud Datastreamのダウンタイムが発生する問題を解決するため、Auroraの前段にNLBを導入し、IPを固定化させようと試みた。
しかし、NLBは名前解決したAuroraのエンドポイントのIPしか指定できないことが判明したため、再度、複数の技術的アプローチを分析し、最適な解決策を検討する。

関連ドキュメント ​

📊 詳細調査・検証レポート ​

SRE-1744: 詳細調査・検証レポート

  • HAProxy/trocco/NLB+Lambda等の詳細評価・コスト比較
  • HAProxy設定詳細
  • 検証環境での実装内容
  • 検証結果（2026-02-13実施・成功確認）
  • トラブルシューティングガイド
  • 参考リソース一覧

Note: 本番環境への展開手順作成と展開は別途対応予定

課題・制約事項 ​

Aurora フェイルオーバーや再起動時のDatastreamダウンタイム ​

  • 現状の問題: Aurora フェイルオーバーまたは再起動などインスタンスのIPアドレス変更時にDatastreamが停止する
  • 原因: 仕様によりGCE側の指定先はDBエンドポイントのIPアドレスの必要がある。 公式ドキュメント rinetdでエンドポイントの名前解決を導入していたが、起動時しか名前解決しない。
  • 影響: BigQueryへのリアルタイムデータ連携が停止

現在の構成の限界 ​

  • rinetdプロキシ: 起動時の名前解決のみ、動的IP変更に未対応
  • DNS依存: Auroraエンドポイントの名前解決に依存した接続
  • 手動復旧: フェイルオーバー後の手動介入が必要

検討アプローチ ​

Aurora前段でのIP固定化を実現するため、複数の技術的解決策を検討・評価し、実装コスト・運用負荷・技術的制約を総合的に分析する。

検討計画 ​

Phase 1: 技術調査・制約確認 ✅ ​

  1. 初期アプローチの検証

    • NLBを使用したIP固定化の技術検証
    • Auroraエンドポイント直接指定の可否確認
    • 技術的制約の洗い出し

  2. 代替案の洗い出し

    • 複数の解決策候補の特定
    • 各手法のメリット・デメリット分析

Phase 2: 解決策の詳細検討 (保留) ​

  1. 実装方法の詳細分析

    • 各解決策の技術的実装方法
    • コスト・運用負荷の定量化
    • リスク評価とリスク軽減策

  2. 最適解の選定

    • 総合評価による解決策の選定
    • 実装計画の策定

Phase 3: 実装・展開 (保留) ​

  1. 選定された解決策の実装

    • 開発・構築作業
    • テスト・検証

  2. 本番環境への展開

    • 段階的な移行
    • 監視・運用体制の確立

関連リソース ​

現在のリソース ​

  • AWS Aurora PostgreSQL: データソース
  • GCE with rinetd: 現在のプロキシ（起動時のみ名前解決）
  • Google Cloud Datastream: データ連携サービス

検討対象リソース ​

  • 代替プロキシ方式: GCE上でのIP変更検知・動的更新
  • AWS RDS Proxy: マネージドプロキシサービス
  • AWS ECS with Squid: カスタムプロキシサービス
  • trocco: サードパーティCDCサービス

作業記録・実装ログ ​

2025-09-05 ​

  • 作業内容: 問題分析と初期解決策検討
  • 実施者: SRE Team
  • 詳細:
    • Aurora フェイルオーバー時のDatastreamダウンタイム問題を特定
    • NLBによるIP固定化アプローチの検討開始
    • 初期実装計画とドキュメント作成

2025-09-22 ​

  • 作業内容: 技術的制約確認と代替案検討
  • 実施者: SRE Team
  • 詳細:
    • NLBでAuroraエンドポイント直接指定ができないことを実機で確認
    • 5つの代替解決策を洗い出し・分析
    • 各解決策のメリット・デメリット・実装コストを評価
    • 長期的課題として継続検討することを決定

課題・ブロッカー ​

GCP仕様によるDBエンドポイントのIP指定の制約 ​

  • 発見日: 2025-02-27
  • 詳細: 公式のGCEのポートフォワーディングの設定の起動スクリプトがあったが、IPアドレス指定でないと動かない。 当時のPR
  • 対処方針: 動的名前解決のためのrinetdの導入

Aurora フェイルオーバーや再起動時のDatastreamダウンタイム問題 ​

  • 発見日: 2025-09-05
  • 詳細: rinetdが起動時にしか名前解決せず(前回検証時に検知できず)、Aurora フェイルオーバーまたは再起動などインスタンスのIPアドレス変更時にDatastreamが停止する
  • 対処方針: Aurora前段にAWS Network Load Balancer (NLB)を配置し、固定IPアドレスでの接続を実現検討

NLBでAuroraエンドポイント直接指定の制約 ​

解決策の検討と結論 ​

検討した解決策 ​

1. GCEにミドルウェア・スクリプトでIP変更検知 ​

  • メリット: コストが低い
  • デメリット:
    • プログラムの作り込みが必要
    • ミドルウェアの新規の監視、運用などの検討事項が増える

2. NLBでインスタンスIP指定 + Lambda監視・変更 ​

  • デメリット:
    • プログラムの作り込みが必要
    • 新規の監視、運用などの検討事項が増える
    • 運用・メンテが必要になる
    • 管理リソースが増える

3. troccoに乗り換え ​

  • メリット:
    • 開発面: 比較的容易でスピーディに実現できる
    • 運用面: これまでの運用の知見が活かせる、比較的コストが低い
  • デメリット:
    • 開発面: 手動での設定になる
    • 運用面: IaC化できないため元々の課題を解決できない、テーブル追加時の手動設定が必要、ポーリング最速1分でリアルタイム性が低い
  • 参考: trocco CDCジョブ定義

4. AWS RDS Proxy導入 ​

  • メリット: マネージドで対応できる
  • デメリット:
    • 新規の設計、運用などの検討事項が増える
    • RDS ProxyのエンドポイントIPアドレスが変わる可能性がゼロではない

5. AWS側にSquid構築でIP固定化 ​

  • デメリット:
    • ECSでの新規サービス構築が必要
    • 監視、運用などの検討事項が増える
    • 管理リソースが増える

結論 ​

いずれもデメリットがあり、長期的な課題として検討する。

進捗状況 ​

  • [x] Phase 1: 設計・調査（2025-09-05 〜 2025-09-22）

    • [x] 構成の設計
    • [x] 設計のレビュー
    • [x] 技術的制約の確認: NLBでAuroraエンドポイント直接指定ができないことを確認
    • [x] 5つの代替解決策の洗い出し

  • [x] Phase 2: 詳細調査・評価（2026-02-10 〜 2026-02-12）

    • [x] HAProxy詳細調査（動的DNS解決機能の技術調査・設定手順策定）
    • [x] trocco詳細評価（CDC機能はProfessional限定、Terraform管理不可等）
    • [x] NLB+Lambda評価（AWS公式ブログパターン）
    • [x] コスト比較分析（現構成、HAProxy、troccoの詳細比較）
    • [x] 包括的調査レポート作成 → 詳細レポート

  • [x] Phase 3: 検証環境実装・検証（2026-02-13）

    • [x] HAProxy実装（GCE起動スクリプトをrinetd→HAProxyに変更、ログローテーション含む）
    • [x] Terraform化（起動スクリプトを別ファイルに分離、templatefile関数で管理）
    • [x] フェイルオーバーテスト（Aurora PostgreSQL フェイルオーバー実行・検証成功）
    • [x] Datastream継続稼働確認（BigQueryへのCDCパイプラインが中断せず継続）

完了条件 ​

  1. ✅ 技術的制約の確認: NLBでAuroraエンドポイント直接指定の制約確認完了
  2. ✅ 代替案検討: 複数の解決策の検討とメリット・デメリット分析完了
  3. ✅ 解決策の選定: HAProxy動的DNS解決方式の採用決定
  4. ✅ 検証環境での実装: infra-dev環境にてHAProxy設定実装完了
  5. ✅ フェイルオーバーテスト: Aurora PostgreSQLフェイルオーバー時のDatastream継続稼働確認完了

リスク・注意事項 ​

  1. 代替案の複雑性: 各解決策にそれぞれ運用負荷やコストの課題がある
  2. 長期課題化: 即座に実装可能な最適解が存在しない状況

作業完了項目 ​

Phase 1: 設計・調査（2025-09-05 〜 2025-09-22） ​

  1. 構成の設計: NLBを追加した構成の設計完了
  2. 技術的制約の確認: NLBでのAuroraエンドポイント直接指定不可を確認
  3. 代替案検討: 5つの解決策の洗い出し完了
  4. 実装方針決定: 長期的課題として継続検討することを決定

Phase 2: 詳細調査・評価（2026-02-10 〜 2026-02-12） ​

  1. HAProxy詳細調査: 動的DNS解決機能の技術調査・設定手順策定完了
  2. trocco詳細評価: プラン・料金・制約の詳細調査完了（CDC機能はProfessional限定、Terraform管理不可等）
  3. NLB+Lambda評価: AWS公式ブログパターンの調査完了
  4. コスト比較分析: 現構成、HAProxy、troccoの詳細コスト比較完了
  5. 包括的調査レポート作成: 全代替案を網羅した詳細レポート作成完了 → 詳細レポート

Phase 3: 検証環境実装・検証（2026-02-13） ​

  1. HAProxy実装: GCE起動スクリプトをrinetdからHAProxyに変更（ログローテーション含む）
  2. Terraform化: 起動スクリプトを別ファイルに分離、templatefile関数で管理
  3. フェイルオーバーテスト: Aurora PostgreSQLフェイルオーバー実行・検証成功
  4. Datastream継続稼働確認: BigQueryへのCDCパイプラインが中断せず継続稼働することを確認

実装ファイル:

  • gcp/services/fd-datastream/sre-dev/instance_template.tf（検証環境で使用、現在は削除済み）
  • gcp/services/fd-datastream/sre-dev/scripts/haproxy-startup.sh（検証環境で使用、現在は削除済み）

今後のアクション ​

本番環境への展開手順作成と展開は別途対応予定：

  1. ステージング環境への展開手順作成
  2. 本番環境への展開手順作成（ローリングアップデート）
  3. 運用ドキュメント・監視設定の更新

最終更新日 ​

2026-02-13