Aurora Global Database によるクロスリージョン移行の検証
はじめに
最近の AWS のアップデートも中々素晴らしいものが多いですね。
今回は Aurora Global Database の記事ですが、皆さんご存知でしたでしょうか。実はこの仕組みのデータ同期、 binlog は使っていないのです。
さて、記事内容にお進みください。
背景
AWS Auroraを利用したシステムにおいて、リージョン間の移行が必要になるケースは少なくありません。例えば、以下のような理由が考えられます
- レイテンシの改善: ユーザーに近いリージョンへの移行による応答速度の向上
- コンプライアンス要件: データの保存場所に関する規制への対応
- コスト最適化: リージョン間の料金差を利用したコスト削減
- 災害対策: リージョン障害時の可用性向上
今回の検証では、バージニア(us-east-1)で運用中のAuroraを東京(ap-northeast-1)リージョンに移行する という具体的なシナリオを想定し、Aurora Global Databaseの動作を検証しました。
Aurora Global Databaseは、複数のAWSリージョンにまたがるAuroraクラスターを管理し、クロスリージョンレプリケーションと高速なフェイルオーバーを提供する機能です。この機能を活用することで、ダウンタイムを最小限に抑えながらリージョン間の移行が可能になると考えられます。
概要
検証目的
本検証では、Aurora Global Databaseを使用したクロスリージョン移行の実用性を確認するため、以下の4つの観点から検証を実施しました
-
Global Database化による既存エンドポイントの変更有無
- 既存のアプリケーションへの影響を最小限に抑えるため、エンドポイントが変更されないことを確認
-
Switchover（計画的切り替え）の所要時間
- メンテナンスウィンドウの計画に必要な、計画的切り替えの所要時間を測定
-
Failover（障害時切り替え）の所要時間
- 障害発生時の切り替え時間を測定し、RTO（Recovery Time Objective）の評価
-
双方向の切り替えが可能かどうか
- 移行後の切り戻しや、将来的なリージョン間の切り替えが可能かを確認
検証環境
| 項目 | バージニア(us-east-1) | 東京(ap-northeast-1) |
|---|---|---|
| クラスター名 | virginia-aurora-cluster | tokyo-aurora-cluster |
| エンジン | Aurora MySQL 8.0.mysql_aurora.3.10.0 | 同左 |
| インスタンスクラス | db.r5.large | db.r5.large |
| Writer | 1台 | - (Switchover後に昇格) |
| Reader | 1台 | 1台 |
Global Database識別子: test-global-db
内容
1. エンドポイント変更有無の検証結果
結論: 既存クラスターのエンドポイントは変更されない
検証の結果、以下の重要な事実が確認されました
| タイミング | バージニア Writer | バージニア Reader |
|---|---|---|
| Global Database化前 | virginia-aurora-cluster.cluster-c8qvptyrfqw8.us-east-1.rds.amazonaws.com |
virginia-aurora-cluster.cluster-ro-c8qvptyrfqw8.us-east-1.rds.amazonaws.com |
| Global Database化後 | 変更なし | 変更なし |
| Switchover後 | 変更なし （ただしセカンダリに降格） | 変更なし |
| Failover後（切り戻し） | 変更なし （プライマリに復帰） | 変更なし |
重要な発見事項
- 既存クラスターのエンドポイントは、Global Database化やSwitchover/Failoverを経ても一切変更されない
- 各リージョンのクラスターは独自のエンドポイントを保持し続ける
- アプリケーションの接続先変更は、Switchover後に東京のエンドポイントへ切り替える必要がある
Global Databaseでは、各リージョンのクラスターがそれぞれ独自のエンドポイントを保持しています。Globalエンドポイント（test-global-db.global-...global.rds.amazonaws.com）は現在のプライマリクラスターを指しますが、読み取り専用 であり、書き込みには使用できません。
エンドポイント一覧
| リージョン | 種類 | エンドポイント |
|---|---|---|
| バージニア | Writer | virginia-aurora-cluster.cluster-c8qvptyrfqw8.us-east-1.rds.amazonaws.com |
| バージニア | Reader | virginia-aurora-cluster.cluster-ro-c8qvptyrfqw8.us-east-1.rds.amazonaws.com |
| 東京 | Writer | tokyo-aurora-cluster.cluster-c0344g8vvdm3.ap-northeast-1.rds.amazonaws.com |
| 東京 | Reader | tokyo-aurora-cluster.cluster-ro-c0344g8vvdm3.ap-northeast-1.rds.amazonaws.com |
| Global | 参照用 | test-global-db.global-gc5dww26jsoh.global.rds.amazonaws.com |
2. クロスリージョン切り替え時間の検証結果
Switchover（計画的切り替え）: バージニア → 東京
| 項目 | 結果 |
|---|---|
| 開始時刻 | 2025-11-28 15:49:06 |
| 完了時刻 | 2025-11-28 15:50:29 |
| 所要時間 | 約83秒（1分23秒） |
| データ損失 | なし（RPO = 0） |
| トポロジー | 維持（バージニアは自動的にセカンダリに降格） |
Failover（障害時切り替え）: 東京 → バージニア
| 項目 | 結果 |
|---|---|
| 開始時刻 | 2025-11-28 15:51:18 |
| 完了時刻 | 2025-11-28 15:52:36 |
| 所要時間 | 約78秒（1分18秒） |
| データ損失 | 検証環境ではなし |
| トポロジー | 維持（東京は自動的にセカンダリに降格） |
まとめ
| 操作 | 所要時間 | AWS公式想定値 | 評価 |
|---|---|---|---|
| Switchover | 約83秒 | 数分程度 | 想定内 |
| Failover | 約78秒 | 通常1分以内 | 想定内（若干超過） |
両方の切り替え操作とも、AWS公式の想定値内で完了しました。特にSwitchoverは約1分20秒で完了し、メンテナンスウィンドウの計画において十分に実用的な時間であることが確認されました。
3. クロスリージョンレプリケーションラグの検証結果
CloudWatchメトリクス AuroraGlobalDBReplicationLag より取得した計測結果
| 項目 | 値 |
|---|---|
| 平均 | 約125〜140ミリ秒 |
| 最小 | 約70ミリ秒 |
| 最大 | 約230〜324ミリ秒 |
詳細データ（10分間のサンプル）
| 時刻 (UTC) | 平均 (ms) | 最小 (ms) | 最大 (ms) |
|---|---|---|---|
| 07:50:00 | 129.3 | 70 | 230 |
| 07:51:00 | 133.5 | 70 | 235 |
| 07:52:00 | 135.3 | 70 | 230 |
| 07:53:00 | 129.6 | 70 | 243 |
| 07:54:00 | 136.1 | 70 | 318 |
| 07:55:00 | 127.1 | 70 | 230 |
| 07:56:00 | 141.3 | 70 | 294 |
| 07:57:00 | 124.5 | 71 | 232 |
| 07:58:00 | 130.6 | 71 | 244 |
| 07:59:00 | 138.1 | 70 | 324 |
結論
- AWS公式ドキュメントでは「通常1秒未満」と記載
- 実測値は約70〜320ミリ秒（平均130ミリ秒） で、1秒よりもかなり短い
- バージニア〜東京間（約11,000km）でも非常に高速なレプリケーションが実現
この結果は、クロスリージョンレプリケーションによるデータ整合性が非常に高いレベルで維持されることを示しています。
4. 双方向切り替えの検証結果
結論: 双方向の切り替えが問題なく可能
| 切り替え | 結果 |
|---|---|
| バージニア → 東京（Switchover） | 成功 |
| 東京 → バージニア（Failover） | 成功 |
- Switchover後、バージニアは自動的にセカンダリとしてGlobal Databaseに残る
- Failover後、東京は自動的にセカンダリとしてGlobal Databaseに残る
- トポロジーは常に維持され、手動での再構築は不要
この検証により、移行後の切り戻しや、将来的なリージョン間の切り替えが柔軟に行えることが確認されました。
5. 実装時の注意事項
5.1 アプリケーションの接続先変更
Global Databaseでは、書き込みはプライマリリージョンでのみ可能 です。セカンダリリージョンは読み取り専用のため、Switchover時にはアプリケーションの接続先を変更する必要があります。
推奨される対応方法:
-
Route 53 + ヘルスチェック
- CNAMEレコードでアプリ用のエンドポイントを作成
- Switchover時にDNSを切り替え
- TTLを短くしておくことで、DNS切り替え後の反映が早くなる
- アプリケーションは常に同じホスト名に接続するため、コード変更不要
-
Write Forwarding機能
- セカンダリリージョンへの書き込みリクエストを自動的にプライマリに転送
- ただし往復で約260ミリ秒以上の遅延が追加 される
- 書き込み頻度が低い場合や、Switchover直後の一時的な措置として有効
| 方式 | 書き込み遅延 | Switchover時の対応 |
|---|---|---|
| プライマリ直接接続 | なし | 接続先変更が必要 |
| Write Forwarding | +260ms以上 | 不要 |
5.2 暗号化されたクラスターの場合
- クロスリージョンレプリカ作成時は
--kms-key-idの明示的な指定が必要 - 各リージョンで個別のKMSキーを使用する
5.3 パラメータグループの制約
最重要: lower_case_table_names
Aurora MySQL 3.xでは、このパラメータはクラスター作成時に永久に設定 され、後から変更できません。Global Databaseでは、プライマリとセカンダリで同一値が必須 です。
統一が推奨されるパラメータ:
-
time_zone: タイムゾーン設定 -
character_set_server: サーバー文字セット -
collation_server: サーバー照合順序
カスタムパラメータグループを使用している場合、東京リージョンにも同じ設定のカスタムパラメータグループを作成 する必要があります。パラメータグループはリージョン固有のリソースのため、クロスリージョンでは共有できません。
5.4 クラスター作成時間
- セカンダリクラスター作成: 約6分
- インスタンス作成: 約4分
移行計画を立てる際は、これらの時間も考慮する必要があります。
終わりに
検証結果の総括
Aurora Global Databaseを使用したバージニアから東京への移行は、以下の点で実用的であることが確認されました
- 既存エンドポイントの維持: Global Database化してもエンドポイントは変更されないため、既存アプリケーションへの即座の影響はない
- 高速な切り替え: Switchover/Failoverともに約1分20秒で完了し、メンテナンスウィンドウの計画が容易
- 双方向切り替え: 問題なく双方向の切り替えが可能で、移行後の柔軟性が高い
- トポロジーの自動維持: 切り替え後も自動的にGlobal Database構成が維持され、手動での再構築が不要
- 低レプリケーションラグ: バージニア〜東京間で平均130ミリ秒（最大でも約320ミリ秒）と、非常に高速なレプリケーションが実現
推奨される移行手順
- バージニアの既存クラスターをGlobal Database化（ダウンタイムなし）
- 東京にセカンダリクラスター・インスタンスを作成（約10分）
- レプリケーション同期を確認（CloudWatchメトリクスで監視）
- 計画停止時間を設けてSwitchover実行（約1分30秒）
- アプリケーションの接続先を東京エンドポイントに変更（Route 53でDNS切り替え推奨）
- 動作確認後、本番運用開始
一言
もしこの記事が気に入って頂けたらここでのいいね＆フォローとX( @___nix___ )でのフォローもお願い致します。
Discussion