한 회사에서 프라이머리 DB 인스턴스와 5개의 읽기 복제본으로 구성된 RDS for MySQL에 웹 앱을 호스팅하고 있습니다. 복제본은 프라이머리보다 1초 이상 지연되지 않아야 합니다. 데이터베이스는 예약된 저장 프로시저를 실행하며, 피크 로드 시 복제본의 지연이 더 심해집니다. 솔루션스 아키텍트는 애플리케이션 코드 변경 및 지속적인 운영 오버헤드를 최소화하면서 복제 지연을 최대한 줄여야 합니다. 다음 중 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

정답은 Amazon Aurora MySQL로 마이그레이션하는 것입니다. Aurora는 MySQL과 호환되며, 공유 스토리지 아키텍처를 사용하여 읽기 복제본의 복제 지연을 최소화합니다. Aurora Replicas는 프라이머리 인스턴스와 동일한 스토리지 볼륨을 공유하므로 복제 지연이 일반적으로 100ms 미만으로 매우 낮습니다. Aurora Auto Scaling은 필요에 따라 읽기 복제본을 자동으로 조정하여 성능을 유지합니다. 저장 프로시저를 Aurora MySQL 네이티브 함수로 교체하는 것은 애플리케이션 코드 변경을 최소화하면서 기능을 유지하는 방법입니다. 오답인 ElastiCache는 캐싱을 통해 읽기 성능을 향상시키지만, 복제 지연 자체를 해결하지 못하며 애플리케이션 코드 변경이 필요합니다. EC2 인스턴스로 마이그레이션하는 것은 관리 오버헤드를 증가시키고, 복제 지연 문제를 근본적으로 해결하기 어렵습니다. DynamoDB는 NoSQL 데이터베이스이므로 관계형 데이터베이스인 MySQL과는 호환되지 않아 상당한 애플리케이션 재설계가 필요합니다.