AmazonAmazon DevOps Engineer Professional DOP-C02 Certification·KO·업데이트됨 4 Aug 2026
리프트 앤 시프트(lift-and-shift) 마이그레이션 후 단일 Auto Scaling 그룹에 각 EC2 인스턴스가 웹, 데이터베이스 및 Redis 캐시 구성 요소를 실행하게 되었고, 이로 인해 가변적인 응답 시간과 과부하된 인스턴스가 발생했습니다. 회사는 가용성과 성능을 개선하기 위해 구성 요소를 분리하고자 합니다. 어떤 아키텍처 변경이 이 요구 사항을 충족할까요?
정답 선택
옵션을 탭하여 정답을 확인하세요.
정답: 웹 애플리케이션용 Application Load Balancer 및 Auto Scaling 그룹을 생성합니다. 데이터베이스를 Multi-AZ가 있는 Amazon Aurora 데이터베이스로 마이그레이션합니다. 캐시용 Amazon ElastiCache (Redis OSS) 클러스터를 생성합니다..
이것이 정답인 이유
이 아키텍처 변경은 각 구성 요소를 분리하여 가용성과 성능을 향상시킵니다. 웹 애플리케이션용 Application Load Balancer(ALB)는 HTTP/HTTPS 트래픽을 효율적으로 분산하고, Auto Scaling 그룹은 웹 계층의 탄력성을 제공합니다. Multi-AZ Amazon Aurora 데이터베이스는 고가용성과 확장성을 보장하며, Redis 캐시를 위한 Amazon ElastiCache (Redis OSS) 클러스터는 전용 캐싱 솔루션을 제공하여 데이터베이스 부하를 줄이고 응답 시간을 개선합니다.
다른 옵션들은 다음과 같은 이유로 최적의 솔루션이 아닙니다.
Network Load Balancer(NLB)는 웹 애플리케이션에 필요한 고급 라우팅 기능을 제공하지 않습니다.
Redis 캐시용 ALB 또는 NLB를 생성하는 것은 ElastiCache와 같은 전용 캐싱 서비스가 있을 때 불필요하고 비효율적입니다.
Redis 캐시용 단일 가용 영역에 NLB 및 Auto Scaling 그룹을 생성하는 것은 고가용성 요구 사항을 충족하지 못합니다.