Q3 — AWS SAA-C03 第10章

第 3/100 問 | ← 第10章

Q603. ソリューションアーキテクトがアプリケーションの耐障害性をレビューしています。その際、データベース管理者がスケーリング演習の一環として、アプリケーションの Amazon Aurora PostgreSQL データベースの Writer インスタンスのフェイルオーバーを実行したことに気づきました。このフェイルオーバーにより、アプリケーションに 3 分間のダウンタイムが発生しました。 運用オーバーヘッドを最小限に抑えつつ、スケーリング演習時のダウンタイムを短縮するには、どのソリューションが最も適していますか？

• A. クラスター内に追加の Aurora PostgreSQL 読み取り専用レプリカを作成し、フェイルオーバー時の負荷を処理できるようにします。
• B. 同一 AWS リージョン内にセカンダリの Aurora PostgreSQL クラスターをセットアップします。フェイルオーバー時に、アプリケーションを更新してセカンダリクラスターの Writer エンドポイントを使用するようにします。
• C. フェイルオーバー時の負荷を処理するために、Amazon ElastiCache for Memcached クラスターを作成します。
• D. データベースに対して Amazon RDS Proxy をセットアップし、アプリケーションを更新してプロキシエンドポイントを使用するようにします。 ✓

正解: D. データベースに対して Amazon RDS Proxy をセットアップし、アプリケーションを更新してプロキシエンドポイントを使用するようにします。

解説

Amazon RDS Proxy は、データベース接続のプールと管理を自動化し、フェイルオーバー時の再接続処理を透過的かつ迅速に実行します。Aurora の Writer インスタンスのフェイルオーバー時、RDS Proxy はクライアント側の再接続ロジックを必要とせず、新しい Writer インスタンスへの接続を自動的に再試行・ルーティングします。これにより、アプリケーションのダウンタイムを数秒以内に短縮でき、追加のインフラ構成（例：セカンダリクラスター）やアプリケーション側の複雑なロジック変更（例：エンドポイント切り替え）を必要としないため、運用オーバーヘッドが最小限です。一方、選択肢 A は読み取り負荷の分散には有効ですが、Writer のフェイルオーバーによる書き込み不可状態を解消しません。選択肢 B は手動または自動でのエンドポイント切り替えが必要で、アプリケーションの変更と運用負荷が増大します。選択肢 C はキャッシュ層であり、データベースの可用性やフェイルオーバー自体を改善しません。