Q58 — AWS SAA-C03 第4章

第 58/105 問 | ← 第4章

Q253. ある企業が Amazon RDS for MySQL のDBインスタンスを起動しました。このデータベースへの接続のほとんどはサーバーレスアプリケーションから発生しています。アプリケーションによるデータベースへのトラフィックは、ランダムな間隔で大きく変動します。高負荷時において、ユーザーはアプリケーションでデータベース接続拒否エラーが発生していると報告しています。 この問題を、最も少ない運用オーバーヘッドで解決するソリューションはどれですか？

• A. RDS Proxy にプロキシを作成し、ユーザーのアプリケーションが RDS Proxy を経由して DB インスタンスを利用するように設定する ✓
• B. ユーザーのアプリケーションと DB インスタンスの間に Amazon ElastiCache for Memcached を展開する
• C. DB インスタンスを I/O 処理能力が高い別のインスタンスタイプに移行し、ユーザーのアプリケーションが新しい DB インスタンスを利用するように設定する
• D. DB インスタンスに対して Multi-AZ を設定し、ユーザーのアプリケーションが DB インスタンス間で切り替えるように設定する

正解: A. RDS Proxy にプロキシを作成し、ユーザーのアプリケーションが RDS Proxy を経由して DB インスタンスを利用するように設定する

解説

接続拒否エラー（例：'Too many connections'）は、MySQL の最大接続数（max_connections）を超えた場合に発生します。サーバーレスアプリケーション（例：AWS Lambda）は短時間で多数の接続を確立・切断する傾向があり、接続の急増や接続リークにより、DB の接続数制限に達しやすくなります。RDS Proxy は、接続プール機能と自動接続再利用を提供し、アプリケーションからの接続要求を効率的に管理・調整することで、DB の接続数制限を超過することを防ぎます。これは、コード変更やアプリケーションの再設計を最小限に抑え、運用オーバーヘッドが極めて低いソリューションです。一方、ElastiCache for Memcached はキャッシュ用途であり、接続管理には対応しておらず、接続拒否エラーの根本原因を解決しません。インスタンスタイプの変更（C）や Multi-AZ 構成（D）は、可用性やパフォーマンス向上には寄与しても、接続数制限そのものを緩和するものではなく、また追加の構成・監視・障害対応などの運用負荷が発生します。したがって、最も少ない運用オーバーヘッドで問題を解決するのは選択肢 A です。