FastDoctor AWS Infrastructure

Appearance

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

チケット概要 ​

JIRA URL:

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

課題・制約事項 ​

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: 設計
    • [x] 構成の設計
    • [x] 設計のレビュー
    • [x] 技術的制約の確認: NLBでAuroraエンドポイント直接指定ができないことを確認
  • [ ] Phase 2: 代替案検討 (保留)
    • [ ] 各解決策の詳細検討
    • [ ] コスト・運用負荷の比較分析
    • [ ] 長期的な実装計画策定

完了条件 ​

  1. 技術的制約の確認: NLBでAuroraエンドポイント直接指定の制約確認完了
  2. 代替案検討: 複数の解決策の検討とメリット・デメリット分析完了
  3. 長期的な方針決定: 代替案の詳細検討と実装計画の策定
  4. 設計: 構成の設計とチームのレビュー完了

リスク・注意事項 ​

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

作業完了項目 ​

Phase 1: 設計・調査 ​

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

最終更新日 ​

2025-09-22