퍼블릭 소매 웹 애플리케이션은 여러 AZ에 걸쳐 EC2 인스턴스 앞에 Application Load Balancer(ALB)를 사용하고 Amazon RDS MySQL Multi-AZ 백엔드를 사용합니다. 대상 그룹 상태 확인은 HTTP를 사용하며 제품 카탈로그 페이지를 가리킵니다. Auto Scaling은 ALB 상태 확인을 기반으로 웹 플릿을 유지 관리합니다. 최근 앱에 장애가 발생했습니다. Auto Scaling은 인스턴스를 반복적으로 교체했지만 웹 서버 지표는 정상으로 보였습니다. 조사 결과 데이터베이스에 과부하가 걸려 쿼리가 매우 느린 것으로 나타났습니다. 다음 두 가지 변경 사항을 함께 적용하면 문제를 해결하고 향후 성장을 위한 전체 애플리케이션 가용성 및 기능 모니터링을 개선할 수 있습니다. (두 가지 선택)

첫 번째 정답은 ALB 상태 확인을 정적 페이지로 변경하고 Route 53 상태 확인을 통해 전체 애플리케이션 기능을 모니터링하는 것입니다. 현재 ALB 상태 확인은 제품 카탈로그 페이지를 사용하므로 데이터베이스 과부하 시 웹 서버가 정상으로 보여도 비정상으로 판단하여 Auto Scaling이 불필요하게 인스턴스를 교체하는 문제를 발생시켰습니다. 정적 페이지로 변경하면 웹 서버 자체의 가용성을 정확히 판단하고, Route 53 상태 확인으로 애플리케이션의 엔드투엔드 기능을 모니터링하여 데이터베이스 문제와 같은 실제 장애를 감지할 수 있습니다. 두 번째 정답은 Amazon ElastiCache 클러스터를 배포하여 데이터베이스 부하를 줄이는 것입니다. 데이터베이스 과부하가 문제의 원인이었으므로, ElastiCache를 통해 자주 액세스하는 데이터를 캐싱하면 RDS MySQL 데이터베이스의 쿼리 부하를 크게 줄여 성능을 향상시키고 과부하를 방지할 수 있습니다. 오답인 RDS 읽기 복제본은 읽기 부하 분산에는