ある EC サイトが AWS Lambda 関数（ピーク時の同時実行数最大 500）を使用して Amazon Aurora MySQL に接続する注文処理システムを運用しています。セール期間中のピーク時に「too many connections」エラーが頻発し、注文処理が失敗しています。Aurora インスタンスの最大接続数の上限に達していることが原因と特定されています。アプリケーションコードの変更を最小限にとどめながら、この問題を最も効果的に解決する方法はどれですか。
Amazon RDS Proxy は、Lambda などのサーバーレス環境とデータベースの間に接続プールを提供するマネージドサービスです。Lambda 関数は実行のたびに短命な接続を大量に生成するため、データベースの接続数上限を超えやすくなります。RDS Proxy はこれらの接続をプールして再利用することで、Aurora が受け付ける実際の接続数を大幅に削減します。接続先エンドポイントを RDS Proxy のエンドポイントに変更するだけで利用でき、アプリケーションロジックの変更は最小限に抑えられます。 選択肢Aの Aurora スケールアップは max_connections の上限を引き上げられますが、Lambda の同時実行数がさらに増加するサーバーレス環境では根本的な解決にならず、コストも増加します。 選択肢Cの Lambda の予約済み同時実行数の制限は接続数を抑制できますが、ピーク時の処理能力を意図的に制限するためスループットが低下し、注文処理の遅延や失敗が増加するビジネス上のリスクがあります。 選択肢Dの Aurora リードレプリカの追加は読み取りクエリの負荷分散には有効ですが、注文の書き込み処理はプライマリに集中し続けるため、接続数過多の根本原因を解決しません。