Amazon Aurora Global Database のリージョン切り替え(スイッチオーバー)が速くなったらしいので実際に確認してみた
ウィスキー、シガー、パイプをこよなく愛する大栗です。
Amazon Aurora Global Database のクロスリージョン スイッチオーバーが速くなったというアナウンスがあったので、どのくらい変化があったのか実際に確認してみました。
Amazon Aurora reduces cross-Region Global Database Switchover time to typically under 30 seconds
Amazon Aurora Global Database のスイッチオーバー
Amazon Aurora の Global Database は低レイテンシでクロスリージョンのレプリケーションを行う機能です。Global Database のスイッチオーバーは、リージョン間でライターを入れ替える機能となります。プライマリ DB クラスターと異なるリージョンにあるセカンダリ DB クラスターを昇格して書き込みを可能にさせて事業継続を維持するための機能です。
リージョン間でライターを入れ替える機能は、スイッチオーバー(以前は「計画的なフェイルオーバー」と呼ばれていた)とフェイルオーバーがあります。スイッチオーバーは計画的に行うもので、セカンダリ DB クラスターとデータ同期を行うため RPO は 0(データ損失無し)で切り替えを行います。フェイルオーバーは計画外のシステム停止から回復するための機能で、通常 RPO は秒単位で発生(データ損失の可能性あり)します。
今回のアップデートでは計画的に実行するスイッチオーバーが通常30秒未満に短縮されています。
なお、先日セカンダリリージョンに指定できる数が 5 から 10 へ増加しています。
対象バージョン
以下の Aurora のバージョンでスイッチオーバーが高速になっています。
- Aurora MySQL
- 3.09 (compatible with MySQL 8.0.40) 以上のバージョン
- Aurora PostgreSQL
- PostgreSQL 17
- PostgreSQL 16 (versions 16.8 以上)
- PostgreSQL 15 (versions 15.12 以上)
- PostgreSQL 14 (versions 14.17 以上)
- PostgreSQL 13 (versions 13.20 以上)
試してみる
以下の環境でスイッチオーバーの切り替えを確認してみました。
- リージョン
- 東京
- 大阪
- インスタンス
- db.r6g.large
- クラスタ構成
- 両リージョンともに 1 台のインスタンス
- DB エンジン
- MySQL
- 計測対象バージョン
- 高速化前: Aurora MySQL (version 3.08.2, compatible with MySQL 8.0.39)
- 高速化後: Aurora MySQL (version 3.09.0, compatible with MySQL 8.0.40)
環境の注意点としては、切り替わった先のクラスターへもアクセスできるようにクロスリージョンで VPC ピアリングを設定して別リージョンのクラスタへの接続確認もしておくことです。
計測方法は、Aurora Global Database のグローバルエンドポイントに対して 0.5 秒ごとにアクセスして、アクセス先が切り替わり安定的に接続できるようになるまでの実質的なダウンタイムを 10 回計測しました。更新負荷は掛けていない状態です。
以下の形式でアクセス情報を記述した設定ファイルを作成します。
[client]
user = <USERNAME>
password = <PASSWORD>
以下のようなスクリプトを作成して、上記で作成した設定ファイルとグローバルエンドポイントを記載します。スクリプトを実行しつつスイッチオーバーを行い切り替え時間を計測します。
/usr/bin
while true
do
DATETIME=$(date "+%Y-%m-%d %T.%N")
(echo "select '${DATETIME}', now(3), @@hostname, @@server_id, @@innodb_read_only;" | mysql --defaults-extra-file=global-dbaccess.cnf -h <GLOBAL-ENDPOINT> -s) &
sleep 0.5
done
計測結果
高速化前: Aurora MySQL (version 3.08.2, compatible with MySQL 8.0.39)
高速化前は平均して 45.3 秒かかっています。最長で 56.9 秒、最短で 35.2 秒と 1 分は切っていますが 30 秒には届いていない状態です。
計測回数 | 切り替え時間 |
---|---|
1 回目 | 36.7 sec |
2 回目 | 37.8 sec |
3 回目 | 56.9 sec |
4 回目 | 53.4 sec |
5 回目 | 35.2 sec |
6 回目 | 48.9 sec |
7 回目 | 47.3 sec |
8 回目 | 52.4 sec |
9 回目 | 43.3 sec |
10 回目 | 41.3 sec |
平均時間 | 45.3 sec |
高速化後: Aurora MySQL (version 3.09.0, compatible with MySQL 8.0.40)
高速化後は平均して 17.3 秒かかっています。最長で 24.2 秒、最短で 9.6 秒と全て 30 秒未満となっています。
計測回数 | 切り替え時間 |
---|---|
1 回目 | 22.2 sec |
2 回目 | 24.2 sec |
3 回目 | 12.6 sec |
4 回目 | 14.2 sec |
5 回目 | 9.6 sec |
6 回目 | 17.2 sec |
7 回目 | 19.1 sec |
8 回目 | 14.2 sec |
9 回目 | 20.6 sec |
10 回目 | 18.7 sec |
平均時間 | 17.3 sec |
この様にスイッチオーバーの時間が大幅に短縮したことが分かりました。
さいごに
東京リージョンと大阪リージョンの間で間でどの程度切り替えに要するのか気になったので確認してみました。本番ワークロードでは更新量に応じて切り替え時間に差が発生すると思いますので、ご自身の環境では負荷を与えつつ切り替え状況を確認されると良いと思います。