한 회사의 API는 모니터링 장치로부터 실시간 데이터를 수신하여 Amazon RDS DB 인스턴스에 저장합니다. 수신되는 데이터 볼륨은 변동하며, 트래픽이 많을 때 데이터베이스가 쓰기 볼륨을 처리할 수 없어 API가 타임아웃됩니다. 솔루션스 아키텍트는 데이터베이스 연결을 최소화하고 트래픽이 많을 때 데이터 손실이 없도록 해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족할까요?

정답은 Amazon SQS 대기열을 사용하여 들어오는 데이터를 버퍼링하고, AWS Lambda 함수를 통해 RDS 데이터베이스에 비동기적으로 쓰는 것입니다. 이 솔루션은 API가 데이터베이스에 직접 연결하는 것을 최소화하여 데이터베이스 부하를 줄이고, SQS의 확장성을 활용하여 트래픽 급증 시 데이터 손실 없이 데이터를 안정적으로 수집할 수 있도록 합니다. Lambda는 대기열의 메시지를 처리하여 데이터베이스에 쓰기 작업을 수행하므로, 데이터베이스가 처리할 수 있는 속도로 데이터를 삽입할 수 있습니다. DB 인스턴스 크기를 늘리는 것은 일시적인 해결책일 수 있지만, 트래픽 급증 시 여전히 병목 현상이 발생할 수 있으며 비용 효율적이지 않을 수 있습니다. Multi-AZ는 고가용성을 위한 것이지 쓰기 성능 향상을 위한 것이 아니며, 모든 활성 RDS DB 인스턴스에 쓰도록 애플리케이션을 구성하는 것은 데이터 일관성 문제를 야기할 수 있습니다. Amazon SNS는 발행/구독 모델로, 메시지 버퍼링보다는 실시간 알림에 더 적합하며, SQS처럼 메시지를 안정적으로 보관하는 기능이 부족합니다.