Global Databaseで実現する マルチリージョン自動切替とBlue/Greenデプロイ 株式会社 野村総合研究所 矢野 純平 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 

Jaws Days初参加、初登壇です！ よろしくお願いします！ ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 

矢野 純平 株式会社 野村総合研究所 金融基盤サービス部 書籍 ○ 要点整理から攻略する『AWS認定 高度なネットワーキング-専門知識』 ○ マルチクラウドデータベースの教科書 ○ マルチクラウドセキュリティの教科書（2025年夏 発売予定！） 自己紹介 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ ⚫ Global Databaseの利用を検討されている方、提案しようと考えている方 ⚫ Global Databaseは利用していたけど、2023/8にGAとなった マネージドフェイルオーバーはキャッチアップできていない方、これまでの フェイルオーバーとの違いやユースケースが今一つ分からなかった方 ⚫ マルチリージョン対応するかもしれない方、している方 ⚫ マルチリージョン自動切替を検討したい方、選択肢に持っておきたい方 ⚫ Global Databaseでも、Blue/Greenしたかった方 想定聴講者 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ ⚫ 書き込み可能なプライマリリージョン＋最大5つの読み取り専用セカンダリリージョン構成 ⚫ プライマリクラスター(Writer/Reader)、セカンダリクラスター(Reader/Reader)となる構成 ⚫ ストレージレベルでのレプリケーションのため、プライマリインスタンスへの影響は非常に軽微 Amazon Aurora Global Databaseとは ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 出典：https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ ● AWSのリージョン(大規模)障害時にRTO・RPOが最も短縮可能なAuroraのソリューション RTO・RPO ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 出典：https://pages.awscloud.com/rs/112-TZM-766/images/ORL-T4-Session.pdf 

Global Databaseの切り替え方式 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 

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 

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

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ スイッチオーバーの動作概要 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● スイッチオーバーはGlobalDatabase構成は維持したまま、プライマリクラスタの切替が行われる ● インスタンスに紐づくPerformance Insightsも過去の情報が保持される （後述しますが、２つのフェイルオーバーのうち、手動フェイルオーバーではPerformance Insightsの過去情報は元の利用しなくなるインスタンスに 紐づいて保持されますので注意が必要） 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ スイッチオーバーの通常時から切り戻しまでの動作概要 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● スイッチオーバーはGlobalDatabase構成は維持したまま、プライマリクラスタの切替が行われる ● 切り戻しは、再度スイッチオーバーを実施する 

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

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

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ 手動フェイルオーバーの通常時から切り戻しまでの動作概要 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● 手動フェイルオーバーでは、もとのAuroraインスタンスを再度Global Database構成に組み込むことはでき ない（ストレージ含め、要再構築） ● 再構築後、切り戻しは、スイッチオーバーを実施する 

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

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ マネージドフェイルオーバーの動作概要 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● 手動フェイルオーバーとの違いは、AWSが自動で元のプライマリクラスターを再構築してくれる点 （スナップショットも取ってくれる） ● 過去のPerformance Insights情報も保持したまま再構築される ● カスタマイズしているパラメータグループも再構築時に踏襲してくれる、手動フェイルオーバーと比較する とデメリットはない！（とAWSサポートからも回答受領） 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ マネージドフェイルオーバーの通常時から切り戻しまでの概要 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● AWS側での自動再構築後、切り戻しは、スイッチオーバーを実施する 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ 切り替え方式についてのまとめ ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ⚫ 障害時の切り替えは、マネージドフェイルオーバーの一択 

2023年8月から稼働している マルチリージョン自動切替 RTOは5分、RPOは0秒 ※まだ切り替わったことはありません ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ 自動切替方式 ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● 自動切替のトリガーは、DatadogのSyntheticsによる外形監視 ● 誤発動防止(東京リージョン障害時のみ切り替えたい)のため、3ロケーション×3経路、合計9つの 外形監視が全てNGとなった場合にのみ発動させる（DatadogのComposite Monitorで実装） ● Datadog→EventBridge→Lambda→ジョブツールの経路で自動切替を実行 ● 正常に切替処理を実行出来ると考えられる、大阪リージョンから自動切替は実行する 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ AZ障害で自動切替を発動させないためのタイマーチューニング ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● 自動切替トリガとなる外形監視タイマーは、監視間隔145秒、リトライ間隔47秒を採用 ● 1AZ障害時のDB切替最長時間となる120秒(AuroraのF/O)の間は自動切替を発動させない ● 外形監視のリトライ上限3回・EventBridgeのEventBus連携ラグ30-60秒(Datadog仕様) ⚫ 自動切替発動に至るまでの目標時間の3-6分(要件) 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ RPOゼロ秒を実現するためのポイント ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● ポイントは、プライマリDB(Writer)へのトランザクションが発生しない(残らない)ようにすること ● 東京リージョン（リソース・コントロールプレーン）に対する制御は機能しないことも想定 ①エンドユーザトラフィックの切替(DNS(Route53)切替)は先頭で実施(大阪のサービス閉塞画面へ) ②サービス閉塞＋システム閉塞(制御不可を考慮して一定時間経過時はスキップし後続処理へ) ③Network ACLでDBへの書込を制限(制御不可を考慮して一定時間経過時はスキップし後続処理へ) ・ステートフルなSecurity Groupではなく、ステートレスなNetwork ACLでの制御 ④DBへのトラフィック切替(Route53切替)実施 ⑤Global Databaseのフェイルオーバー 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ RPOゼロ秒を実現するためのポイント ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● 東京リージョン側のシステム閉塞やNetwork ACL閉塞で残トランザクションを終了させる ● 最終的にDBのRoute53レコードのDNS切替（TTL）を待つことで、RPOゼロ秒を実現 ※Route53のコントロールプレーンはus-east-1/us-west-2 で提供される 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ オンプレからの接続も自動切り替え ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● DNSが利用できず、かつNATしているオンプレからの接続もCiscoのIP SLA＋Object Tracking機能と 切り替えジョブの中で実施しているNACL制御を組み合わせて自動切り替えを実装 ● 通常時はNACLでDenyしている大阪Cluster Pro構成サーバのVIPへのアクセスを、切り替えジョブの中で Permitしている 

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レコードを利用して自前で実装していたため見送り 

Global Databaseでも Blue/Greenデプロイしたい ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 

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を 再構築することが可能） 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ Global DatabaseとBlue/Greenデプロイ機能の併用イメージ ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● 手動フェイルオーバー、Blue/Green構成への変更、再構築はプライマリクラスターへの影響はなし ● 影響は、Green環境への切り替え時の1分程度のサービス断のみ（確認除く） 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ どれだけ違う？Global Database構成でのVerup（Blue/Greenデプロイなし） ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● サービス閉塞後Verupしていると、打鍵確認含め、2時間程度はサービス閉塞が必要 ※打鍵確認時間などが長時間必要である場合は、さらにサービス閉塞時間が必要 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ どれだけ違う？Global Database構成でのVerup（Blue/Greenデプロイあり） ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a ● サービス閉塞後は、1分程度でGreen環境へ切り替えて、即時閉塞解除も可能 

Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ NRIではエンジニアを積極採用中です！ ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 

さいごに ● 本日ご紹介した内容は、以下の弊社ブログ（atlax blogs）でもご紹介しています。 その他のブログ記事などと合わせてご確認ください！ ○ https://atlaxblogs.nri.co.jp/entry/20240910 ● ありがとうございました！ Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ ハッシュタグ：#jawsdays2025 #jawsug #jawsdays2025_a 

No content