Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ

JAWS DAYS 2025
Track:A-7

国内金融系のミッションクリティカルシステムにおいて実装した、Global Databaseを利用したマルチリージョン構成、そのDR自動切り替えについて紹介します。

データの整合性を確保した迅速な切り替えが要件としてあり、RPOは0秒、RTOは5分を実現した事例となります。AWS外のオンプレシステムからの接続切り替えとの連動も含め、そのポイントについて紹介します。

なお、Global Databaseの切り替え方式については3種類ありますので、その違いとユースケースについて、また、Global Database構成では利用できないBlue/Greenデプロイ機能を併用するソリューションについても紹介します。

Junpei Yano

March 05, 2025
Tweet

Other Decks in Technology

Transcript

  1. 矢野 純平 株式会社 野村総合研究所 金融基盤サービス部 書籍 ◦ 要点整理から攻略する『AWS認定 高度なネットワーキング-専門知識』 ◦

    マルチクラウドデータベースの教科書 ◦ マルチクラウドセキュリティの教科書(2025年夏 発売予定!) 自己紹介 ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a
  2. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ ⚫ Global Databaseの利用を検討されている方、提案しようと考えている方 ⚫ Global Databaseは利用していたけど、2023/8にGAとなった マネージドフェイルオーバーはキャッチアップできていない方、これまでの フェイルオーバーとの違いやユースケースが今一つ分からなかった方

    ⚫ マルチリージョン対応するかもしれない方、している方 ⚫ マルチリージョン自動切替を検討したい方、選択肢に持っておきたい方 ⚫ Global Databaseでも、Blue/Greenしたかった方 想定聴講者 ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a
  3. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ Global Databaseの切り替え方式については、大きく分けて次の2種類の切り替え方式が あります。 • ①計画的に行うスイッチオーバー ▪ switchover-global-cluster •

    ②計画外(障害時)に行うフェイルオーバー (この中でも下記の2種類があります) ◦ ②-1:手動フェイルオーバー ▪ remove-from-global-cluster ※Global Database構成を廃止するタイミングでも利用します ◦ ②-2:マネージドフェイルオーバー(2023/8:GA) ▪ failover-global-cluster Global Databaseの切り替え方式 ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a
  4. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ ①計画的に行うスイッチオーバー ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a ⚫ スイッチオーバーは、以前は計画的なフェイルオーバーと呼ばれていた切替方式 ⚫ スイッチオーバーでは、GlobalDatabase構成は維持したまま、プライマリクラスターの切替が

    行われる ⚫ また、AWS側の制御により、完全に同期した後にフェイルオーバーが実施されるため、RPOは 0秒となる(一方、プライマリクラスターの書込停止制御が入るため、プライマリクラスターへ の操作が出来ないような障害時は、スイッチオーバー自体が稼働しないリスクあり) ⚫ スイッチオーバーは、正常な Global Databaseで使用するように設計されている ⚫ ユースケース ⚫ 定期的なDR訓練時のフェイルオーバー ⚫ テストフェーズにおけるフェイルオーバー ⚫ 計画的なアクティブなリージョン切り替え(ローテーション)など ⚫ 計画的なフェイルバック(切り戻し)
  5. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ スイッチオーバーの動作概要 ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a • スイッチオーバーはGlobalDatabase構成は維持したまま、プライマリクラスタの切替が行われる • インスタンスに紐づくPerformance

    Insightsも過去の情報が保持される (後述しますが、2つのフェイルオーバーのうち、手動フェイルオーバーではPerformance Insightsの過去情報は元の利用しなくなるインスタンスに 紐づいて保持されますので注意が必要)
  6. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ ②-1:手動フェイルオーバー ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a ⚫ セカンダリクラスターをGlobal Database構成から削除(デタッチ)することで、スタンド アロンのプライマリクラスターに昇格させる。Global

    Database構成は維持されない ⚫ Global Databaseの再構成は、手動で実施する必要がある ⚫ もとのプライマリクラスターについても、書き込み可能な状態で残る ⚫ プライマリクラスター側が障害、異常時でも稼働することが期待される動作 ⚫ ユースケース ⚫ 後述するマネージドフェイルオーバーが出た今となっては、Global Database構成を廃止したい ケースくらいでしか使わない ⚫ セカンダリクラスターやプライマリクラスターのAuroraを停止、削除したい ⚫ 停止や削除は、スタンドアロンクラスター(≠Global Database)であることが必須
  7. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ 手動フェイルオーバーの動作概要 ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a • 手動フェイルオーバーでは、Global Database構成が維持されずスタンドアロンクラスタになる •

    インスタンスに紐づくPerformance Insightsの情報はもとのインスタンスが保持している ※Performance Insightsの過去情報を残したい場合は、インスタンス自体を削除することなく残しておく必要がある ※Auroraは停止しないと利用料が発生。停止しても1週間で自動起動される。Event Bridge Schedulerなどを使って定期的に停止しましょう
  8. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ ②-2:マネージドフェイルオーバー ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a ⚫ セカンダリクラスターをGlobal Database構成から削除(デタッチ)し、スタンドアロンの プライマリクラスターに昇格させる

    ⚫ 元のプライマリリージョンが正常となったタイミングでセカンダリクラスター(インスタン ス、ストレージ)が自動で再構築されるため、Global Database構成が維持される(過去の Performance Insights情報を保持したクラスターが再構築される) ⚫ セカンダリクラスターの再構築の前に、もとのプライマリクラスターのストレージボリュー ムのスナップショットが作成される(切り替え時に欠落したデータ復旧への利用のため) ⚫ プライマリクラスター側が障害、異常時でも稼働することが期待される動作 ⚫ ユースケース ⚫ 真の地域災害やサービスレベルの全面的な停止が発生した場合(AWS公式ドキュメントの記載)
  9. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ マネージドフェイルオーバーの動作概要 ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a • 手動フェイルオーバーとの違いは、AWSが自動で元のプライマリクラスターを再構築してくれる点 (スナップショットも取ってくれる) •

    過去のPerformance Insights情報も保持したまま再構築される • カスタマイズしているパラメータグループも再構築時に踏襲してくれる、手動フェイルオーバーと比較する とデメリットはない!(とAWSサポートからも回答受領)
  10. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ 自動切替方式 ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a • 自動切替のトリガーは、DatadogのSyntheticsによる外形監視 • 誤発動防止(東京リージョン障害時のみ切り替えたい)のため、3ロケーション×3経路、合計9つの

    外形監視が全てNGとなった場合にのみ発動させる(DatadogのComposite Monitorで実装) • Datadog→EventBridge→Lambda→ジョブツールの経路で自動切替を実行 • 正常に切替処理を実行出来ると考えられる、大阪リージョンから自動切替は実行する
  11. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ RPOゼロ秒を実現するためのポイント ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a • ポイントは、プライマリDB(Writer)へのトランザクションが発生しない(残らない)ようにすること • 東京リージョン(リソース・コントロールプレーン)に対する制御は機能しないことも想定

    ①エンドユーザトラフィックの切替(DNS(Route53)切替)は先頭で実施(大阪のサービス閉塞画面へ) ②サービス閉塞+システム閉塞(制御不可を考慮して一定時間経過時はスキップし後続処理へ) ③Network ACLでDBへの書込を制限(制御不可を考慮して一定時間経過時はスキップし後続処理へ) ・ステートフルなSecurity Groupではなく、ステートレスなNetwork ACLでの制御 ④DBへのトラフィック切替(Route53切替)実施 ⑤Global Databaseのフェイルオーバー
  12. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ オンプレからの接続も自動切り替え ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a • DNSが利用できず、かつNATしているオンプレからの接続もCiscoのIP SLA+Object Tracking機能と

    切り替えジョブの中で実施しているNACL制御を組み合わせて自動切り替えを実装 • 通常時はNACLでDenyしている大阪Cluster Pro構成サーバのVIPへのアクセスを、切り替えジョブの中で Permitしている
  13. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ 自動切り替え実装後の変遷 ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a • EKS、ECS、Aurora MySQLを利用したワークロードも自動切り替えに追加で仲間入り(2024/4リリース) ◦

    Fargateの起動は、Seekable OCI(SOCI)を利用して時間短縮しRTOへの影響を軽減 • 手動フェイルオーバーからマネージドフェイルオーバーへの変更は2025/4リリース予定 • 以下の機能は採用を見送り ◦ Global Database for PostgreSQL 書き込み転送(2023/9/3:GA) ▪ MySQLのみ利用可能だった、セカンダリクラスターへの書き込みをプライマリクラスタのWriter に転送してくれる「書き込み転送」がPostgreSQLでも利用可能に ▪ 利用する場合、東京-大阪間のレイテンシーが発生するため、アプリケーションの挙動や整合性の 確保、性能要件を考慮する必要があることなどから見送り ◦ Global Database writer endpoint(2024/10/22:GA) ▪ Global DatabaseのWriterへの接続は、グローバルエンドポイントを設定していれば、切り替え不 要にできる機能。CNAMEレコードを利用して自前で実装していたため見送り
  14. Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ Global DatabaseでもBlue/Greenデプロイしたい ハッシュタグ:#jawsdays2025 #jawsug #jawsdays2025_a • Global Databaseでは、スタンドアロンのAuroraで利用できる機能が一部利用できません

    • (2025/3時点では)Blue/Greenデプロイもそんな機能のひとつですが・・ • 出来ます! ◦ Global DatabaseでもBlue/Greenできる選択肢を持っておきたいな、から考えました • どうやって? ①通常はGlobal Database構成(Blue/Greenなし)で運用しつつ、プライマリリージョン内での メンテナンス対応時は一時的に手動フェイルオーバーによりGlobal Database構成を解除する ことで、Blue/Green構成に変更 ②メンテナンスを実施したGreen環境への切り替え後に、再度Global Database構成とする (Green環境への切り替え後は、Blue/Green構成ではなくなっているため、Global Databaseを 再構築することが可能)