各選択肢の解説

A. Amazon RDS Proxyを使用して、DBクラスターのプロキシを作成し、プロキシの読み取り専用エンドポイントを構成します。Lambda関数を更新して、プロキシのエンドポイントに接続します。

• 解説: RDS Proxyは、データベース接続の管理を効率化するサービスです。特にLambdaなどのアプリケーションが頻繁に接続・切断を行う場合、接続プールを活用して効率的にリソースを管理します。RDS Proxyを使用することで、Lambda関数が直接データベースに接続する回数を減らし、接続の制限を避けることができます。これにより、アプリケーションの信頼性が向上します。

• 最適解: 高トラフィックの期間中でも接続数の管理が効率化され、接続の過負荷問題を解消できます。

B. DBクラスターのパラメータグループでmax_connections設定を増加させます。すべてのインスタンスを再起動します。Lambda関数を更新して、DBクラスターのエンドポイントに接続します。

• 解説: max_connectionsの設定を増加させることで、接続数の制限を緩和できますが、この方法はスケーラビリティの根本的な解決にはなりません。特に、Lambda関数が短期間に多くの接続を開いて閉じることが原因である場合、接続数を増やすだけでは、接続管理の負荷が軽減されるわけではありません。

• 不適切: 根本的な解決にはなりませんし、接続数の増加はコストを引き上げる可能性もあります。

C. DBクラスターでインスタンスのスケーリングを構成し、DatabaseConnectionsメトリックがmax_connections設定に近づいたときにスケーリングが発生するようにします。Lambda関数を更新して、Auroraリーダーエンドポイントに接続します。

• 解説: インスタンススケーリングを使用しても、接続数を超えた場合にリーダーエンドポイントに接続して読み取り専用の操作を行うことは一時的な解決策になります。しかし、根本的な問題は接続の管理です。スケーリングがトラフィックの急激な変動に追いつかないこともあります。

• 部分的解決: スケーリングの設定によりトラフィック負荷に対応することはできますが、接続プールを使用した効率的な接続管理には及びません。

D. Amazon RDS Proxyを使用して、DBクラスターのプロキシを作成し、プロキシのAurora Data APIの読み取り専用エンドポイントを構成します。Lambda関数を更新して、プロキシのエンドポイントに接続します。

• 解説: Aurora Data APIはAurora Serverlessに関連しているもので、通常のAuroraインスタンスには適用されません。したがって、このオプションはAurora PostgreSQLには適用できません。

• 不適切: Aurora Data APIはAurora Serverless向けであり、通常のAuroraインスタンスには使用できません。

結論