ある企業が AWS 上で Amazon Aurora MySQL を使ったアプリケーションを運用しています。Aurora フェイルオーバー後にアプリケーションが新しいプライマリエンドポイントへの接続を確立するのに数分かかり、その間サービスが停止するという問題があります。現在のアプリケーションはドライバーレベルでのフェイルオーバーサポートがなく、接続文字列に Aurora クラスターエンドポイントをハードコードしています。最小限のアプリケーション変更でフェイルオーバー時間を最小化するには、どの方法が適切ですか？
- A. アプリケーションに Aurora フェイルオーバーを検知する再試行ロジックを実装し、新しいエンドポイントに自動で接続する
- B. Amazon RDS Proxy を Aurora クラスターの前段に設置し、アプリケーションの接続文字列を RDS Proxy エンドポイントに変更する。RDS Proxy はフェイルオーバーを内部的に処理し、アプリケーションへの接続を維持するため、フェイルオーバー時のサービス停止時間が大幅に短縮される
- C. Aurora のフェイルオーバー優先度を高いレプリカに設定し、フェイルオーバー時間を短縮する
- D. Route 53 のヘルスチェックと DNS フェイルオーバーを設定し、Aurora フェイルオーバー時に DNS を新しいエンドポイントに向ける
解答と解説を見る
正解: B
RDS Proxy は Aurora のフェイルオーバーをプロキシ層で処理します。フェイルオーバー時にアプリケーションは RDS Proxy エンドポイントへの接続を維持したまま、Proxy が内部的に新しいプライマリへの接続を確立します。アプリケーション側の変更は接続文字列をクラスターエンドポイントから RDS Proxy エンドポイントに変更するだけで、フェイルオーバー時間を数秒程度に短縮できます。 C: フェイルオーバー優先度の設定はどのレプリカが新プライマリになるかに影響しますが、フェイルオーバー後のアプリケーション接続時間の問題を解決しません。 D: Aurora クラスターエンドポイントは既にフェイルオーバー後の新プライマリを指すよう DNS が更新されますが、DNS の TTL（通常 5 秒）と接続プールの古い接続が問題です。Route 53 ヘルスチェックを追加しても根本的な接続プールの問題は残ります。 A: アプリケーションへの再試行ロジック追加は有効ですが、既存ドライバーのフェイルオーバーサポートがない場合は実装が複雑になります。「最小限のアプリケーション変更」という要件に対して RDS Proxy の方が少ない変更で対応できます。
📚 関連サービスの解説: Amazon RDS ・ Amazon Aurora