無限ノック › SOA 練習問題一覧 › 問題SOA 信頼性とビジネス継続性
あるWebアプリケーションはAurora MySQLクラスターに接続しており、EC2 Auto Scalingにより接続数が急増した際にデータベース接続エラーが頻発しています。また、Multi-AZフェイルオーバー発生時にアプリケーションの再接続に30秒以上かかる問題もあります。アプリケーションコードの変更を最小限に抑えつつ、両方の問題を解決する最適なソリューションはどれですか?
A Auroraのリードレプリカを追加してリード負荷を分散し、アプリケーション層でコネクションプーリングライブラリを実装する
リードレプリカの追加はリード負荷分散には有効ですが、接続数のプール管理やフェイルオーバー時の再接続遅延は解消しません。アプリケーション層のコネクションプール実装はコード変更が必要で要件に反します。
B RDS Proxy をAuroraクラスターの前段に配置してデータベース接続をプール管理し、フェイルオーバー時の接続維持を実現する
✓ 正解
RDS Proxy はフルマネージドのデータベースプロキシで、多数の接続を少数のDB接続にプールし接続数超過エラーを防ぎます。フェイルオーバー時もProxyが接続を維持し再接続時間を最大66%短縮、変更はエンドポイント切替のみで両要件を満たします。
C Aurora Serverless v2 に移行してデータベース側でキャパシティを自動スケーリングさせる
Aurora Serverless v2はACU(Aurora Capacity Units)の自動スケーリングでキャパシティを調整しますが、接続数を削減するコネクションプール機能はなく、接続集中問題やフェイルオーバー時の再接続遅延を直接解決しません。
D ElastiCache for Redis をキャッシュレイヤーとして追加し、Auroraへのクエリ数を削減する
ElastiCache for RedisはクエリキャッシュによりAuroraへの読み取り負荷を削減できますが、データベース接続数の直接制御やフェイルオーバー時の再接続遅延問題は解決しません。
解説 RDS Proxy はフルマネージドのデータベースプロキシであり、多数のアプリケーション接続を少数のデータベース接続にプールすることで接続数超過エラーを防ぎます。フェイルオーバー時はProxyがデータベース接続を維持し続けるため、アプリケーション側の再接続時間を最大66%短縮できます。アプリケーションの変更はエンドポイントをProxy用に切り替えるのみです。
選択肢Aのリードレプリカの追加はリード負荷分散には有効ですが、接続数のプール管理やフェイルオーバー時の再接続遅延は解消しません。
選択肢Cの Aurora Serverless v2はACU(Aurora Capacity Units:データベースの処理能力単位)の自動スケーリングでキャパシティを調整しますが、アプリケーション接続数を削減するコネクションプール機能はなく、多数のEC2インスタンスからの接続集中問題やフェイルオーバー時の再接続遅延を直接解決しません。
選択肢Dの ElastiCacheはクエリキャッシュによりAuroraへの負荷を削減できますが、接続数の直接制御やフェイルオーバー問題は解決しません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →