한 회사에서 API Gateway가 Lambda 함수와 통합된 HTTP API를 노출하는 중요한 애플리케이션을 운영하고 있습니다. 이 애플리케이션은 RDS for MySQL 인스턴스(2 vCPU, 64GB RAM)에 데이터를 저장합니다. 예측할 수 없는 피크 기간 동안 일부 API 호출이 HTTP 500 오류를 반환합니다. CloudWatch Logs에는 "too many connections"이 표시됩니다. 데이터베이스는 예정된 유지 관리 기간을 제외하고는 항상 가용해야 합니다. 회사는 연결 급증에 대해 애플리케이션을 어떻게 탄력적으로 만들 수 있을까요?

too many connections" 오류는 데이터베이스 연결 급증으로 인해 발생합니다. Amazon RDS Proxy는 서버리스 애플리케이션과 같이 연결 수가 많거나 자주 열고 닫는 애플리케이션의 데이터베이스 연결을 효율적으로 관리하고 풀링하여 이러한 문제를 해결합니다. Lambda 함수가 RDS Proxy에 연결하도록 업데이트하면, 프록시가 데이터베이스 연결을 유지하고 재사용하여 데이터베이스 부하를 줄이고 애플리케이션의 탄력성을 높일 수 있습니다. DB 인스턴스 vCPU를 줄이는 것은 성능을 저하시킬 수 있으며, maxconnections 설정만 늘리는 것은 근본적인 연결 관리 문제를 해결하지 못합니다. CloudWatch 경보로 DB 인스턴스 클래스를 변경하는 것은 연결 급증에 대한 즉각적인 해결책이 아니며, 인스턴스 변경에는 시간이 소요됩니다. EventBridge 규칙으로 maxconnections를 늘리는 것은 동적인 연결 관리에 적합하지 않으며, 데이터베이스에 과부하를 줄 수 있습니다.