Amazon Aurora Serverless v2でフェイルオーバーにどのくらいかかるのか検証してみた
皆さんこんにちは。まると(@MaruDevG)です。
タイトルにも記載がある通り、Amazon Aurora Serverless v2でフェイルオーバーが発生する際、どのくらいの時間で切り替わるのか気になったので、実際に検証してみました。
AWS公式ドキュメントなどを確認しましたが、具体的な時間は保証されていないため、参考値としてご利用ください。
先に結論
おおよそ10〜30秒でフェイルオーバーが完了し、データベースに接続できるようになります。
また、RDS Proxyを間に入れる場合、10秒以内にフェイルオーバーが完了できました。
検証環境
- 東京リージョン
- Amazon Aurora PostgreSQL
- Serverless v2 (0.5 〜 2 ACU)
- マルチAZ配置(ライターインスタンス/リーダーインスタンス)
検証方法
AWSマネジメントコンソールより、「フェイルオーバー」を実行してライター/リーダーインスタンスを切り替えます。
また、検証用のプログラムは以下の流れを想定します。
- 1秒ごとにINSERTして接続、動作確認
- 初回の接続失敗時に時刻を記録
- 3回連続で接続が復旧した際、初回失敗時との時間の差分を計算し出力
上記の流れを以下のように実装しました。
<?php
$host = 'endpoint'; // エンドポイント
$port = '5432'; // ポート番号
$dbname = 'database'; // データベース名
$user = 'user'; // ユーザー名
$password = 'password'; // パスワード
$ssl_root_cert = '/path/to/ca/certificate'; // CA証明書のパス
$log_file = 'recovery_log.txt'; // ログファイルのパス
$last_failure_time = null;
$is_connected = false;
$consecutive_recoveries = 0;
$text_value = "Test";
while (true) {
try {
echo "Connecting...";
$dsn = "pgsql:host=$host;port=$port;dbname=$dbname;sslmode=require;sslrootcert=$ssl_root_cert";
$pdo = new PDO($dsn, $user, $password);
$sql = "INSERT INTO testTable (textTest) VALUES (:textValue)";
$stmt = $pdo->prepare($sql);
$stmt->bindParam(':textValue', $text_value, PDO::PARAM_STR);
$stmt->execute();
echo "OK\n";
if (!$is_connected) {
$is_connected = true;
}
if ($last_failure_time !== null && $is_connected) {
$consecutive_recoveries++;
}
// 3回連続で復旧後、終了
if ($consecutive_recoveries >= 3 && $is_connected) {
$recovery_time = time() - $last_failure_time;
$now_time = date('Y/m/d H:i');
file_put_contents($log_file, "復旧時間: $recovery_time 秒 ($now_time)\n", FILE_APPEND);
echo "復旧までの時間: $recovery_time 秒\n";
exit(0);
}
} catch (PDOException $e) {
echo "NG\n";
if ($is_connected) {
$is_connected = false;
$last_failure_time = time();
$consecutive_recoveries = 0; // 連続復旧カウントをリセット
}
} finally {
if (isset($pdo)) {
$pdo = null;
}
}
sleep(1);
}
?>
結果
本検証結果は日本時間2025/2/5 14:00 - 14:15に実施した結果です。
様々な時間帯でデータを取得中のため、データが増え次第本記事を更新していきます。
※一時的なネットワークトラブルによる外れ値の防止ため、復旧後3回連続で成功を条件にしていることから、3秒ほどの差分が発生する場合がございます。
回数 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 平均 |
---|---|---|---|---|---|---|---|---|---|---|---|
復旧までの時間 (秒) | 15 | 14 | 13 | 15 | 9 | 15 | 11 | 13 | 16 | 13 | 13.4 |
早い時間では9秒がありましたが、平均すると10秒台となりました。
RDS Proxyを使った場合は?
高速フェイルオーバーの手段としてRDS Proxyを間に入れる方法がございます。
試しにRDS Proxyを挟んだ場合も同様に計測してみました。
回数 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 平均 |
---|---|---|---|---|---|---|---|---|---|---|---|
復旧までの時間 (秒) | 4 | 3 | 4 | 4 | 4 | 4 | 3 | 4 | 3 | 3 | 3.6 |
平均3.6秒とかなり高速化しました。
読み込みの場合は読み取り専用インスタンスがあるため問題ないと思われますが、書き込みの場合、フェイルオーバー時に瞬間的にDBに接続ができなくなります。
そのため、リトライ手段は別途実装する方がより安全となります。
また、RDS Proxyは上記のように更に高速でフェイルオーバーを行えますが、RDS Proxy分の追加料金が発生します。
そのため、ユースケースによっては恩恵よりもコストの方が高くなる場合がございます。
まとめ
実際に検証を行ってみて、予想よりも早くフェイルオーバーできることがわかりました。
ただ、どうしても瞬断は発生するのでアプリケーション側などでリトライを行う仕組みを取り入れることで、より安心してシステムの構築・運用ができると思われます。
少しでもこの記事がお役に立てれば幸いです。