프로덕션 Aurora MySQL 클러스터는 단일 라이터 노드이며 보고를 위해 쿼리가 많이 발생합니다. 클러스터는 높은 CPU 사용률과 최대 연결 도달로 인해 간헐적인 성능 문제를 겪고 있습니다. SysOps 관리자는 성능을 안정화해야 합니다. 이 요구 사항을 해결할 수 있는 솔루션은 무엇입요?

Aurora Replica를 생성하고 보고 쿼리를 읽기 전용 엔드포인트로 보내면 라이터 노드의 부하가 줄어들어 CPU 사용률과 연결 수가 감소합니다. Aurora Replica는 동일한 기본 스토리지 볼륨을 공유하므로 데이터 복제 오버헤드가 없습니다. Auto Scaling 정책을 사용하면 CPU 사용률에 따라 읽기 복제본을 자동으로 추가하거나 제거하여 성능을 안정화하고 비용을 최적화할 수 있습니다. 다른 가용 영역에 두 번째 클러스터를 프로비저닝하는 것은 별도의 데이터베이스를 생성하는 것이므로 데이터 동기화 및 관리 오버헤드가 발생합니다. Lambda 함수로 쿼리 결과를 캐시하는 것은 복잡하며, 모든 보고 쿼리가 Lambda를 호출하도록 변경해야 합니다. ElastiCache 클러스터를 배포하는 것은 캐싱 계층을 추가하는 것이지만, Aurora Replica가 더 직접적이고 효율적인 읽기 확장 솔루션입니다.