本番相当の検証環境に、別AZのwriterと昇格可能なreaderを持つAurora PostgreSQLクラスタがある。アプリはRDS Proxyを使わず、クラスタエンドポイントへ接続している。
承認された切り替え試験で、アプリの再接続と書き込み再開までの時間を測定したい。DB切り替えの完了だけで復旧を判定しない。
この試験で実施すべき対応を2つ選べ。
計画的なwriter切り替えで再接続と書き込み再開を測定し、DB接続数・RDSイベントとアプリの失敗記録を突き合わせる。
詳細解説
実際にwriterを切り替え、既存接続の失敗・再接続・書き込み成功を観測する。クラスタエンドポイントの接続先更新とアプリが利用可能になる時点を区別できる。
エンドポイントの更新は既存TCP接続を新writerへ移さない。失敗した接続を破棄し、DNSキャッシュ・タイムアウト・再試行設定も含めて新規接続と書き込み成功を確認する。
readerの再起動はwriterの昇格を実際に起こす試験の代わりにならない。writerを切り替える目的にはFailoverDBClusterを使い、役割変更と接続回復を確認する。
DatabaseConnectionsはDBへのクライアントネットワーク接続数であり、アプリのエラー率ではない。アプリ側の測定値とイベントを合わせ、接続数だけでは分からない失敗と復旧を確認する。
DBの利用可能状態だけでは、アプリの接続プールが更新され、書き込みが成功することを確認できない。利用者が受ける影響を別に測定する必要がある。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
検証環境でFailoverDBClusterを実行し、役割変更・アプリの再接続・書き込み成功とDB接続数を時系列で記録する。
参考にした公式資料
確認できる内容
新writerへの接続と書き込み成功が確認でき、切り替え開始からアプリ復旧までの時間と失敗要求を記録できる。
理解のポイント
- Aurora failover
- DatabaseConnections
- 接続再試行
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
writer切り替えとアプリ復旧を分ける
この構成ではFailoverDBClusterにより昇格可能なreaderを新writerにする。役割変更後はクラスタエンドポイントから新しい接続を確立し、実際の書き込み成功まで測定する。既存TCP接続は自動で移らないため、接続プール・DNSキャッシュ・タイムアウト・再試行も検証対象にする。
DB接続数をアプリのエラー率と混同しない
AWS/RDSのDatabaseConnectionsは各DBインスタンスのクライアントネットワーク接続数。DBInstanceIdentifierで対象を分け、RDSイベントと時刻を合わせる。アプリのエラー率・失敗要求・再試行・書き込み成功はアプリ側で測定し、必要ならカスタムメトリクスとして発行する。接続数だけで復旧成功を判定しない。
試験結果の適用範囲を定める
別AZのreaderを準備し、承認された検証環境と負荷で試験する。切り替え開始・接続失敗・書き込み再開を記録し、目標と比較する。計画的な切り替えで得た時間は、その構成と試験条件での結果であり、あらゆる実障害で同じ復旧時間やSLA達成を保証しない。