ALB 및 API Gateway 뒤의 EC2로 마이그레이션된 레거시 애플리케이션은 사용자 중단을 최소화하고 애플리케이션 변경을 최소화하면서 빠른 롤백을 허용하는 배포가 필요합니다. 어떤 접근 방식이 이러한 목표를 달성할까요?

정답은 새 버전을 별도의 병렬 환경으로 배포하고 API Gateway 카나리 배포를 사용하여 새 환경으로 트래픽의 작은 비율을 보내는 것입니다. 이 방법은 사용자 중단 없이 새로운 버전을 점진적으로 테스트하고, 문제가 발생하면 즉시 이전 버전으로 롤백할 수 있어 위험을 최소화합니다. API Gateway 카나리 배포는 트래픽을 세밀하게 제어하여 점진적인 전환을 가능하게 합니다. 오답인 "새 버전을 별도의 병렬 환경으로 배포하고 DNS 별칭 레코드를 새 환경을 가리키도록 전환합니다"는 DNS 전파 시간으로 인해 빠른 롤백이 어렵고, 전환 시 모든 사용자에게 영향을 미쳐 사용자 중단 위험이 큽니다. 오답인 "동일한 ALB 뒤에 업데이트된 앱을 위한 새 대상 그룹을 추가하고 API Gateway가 새 대상 그룹으로 트래픽을 단계적으로 라우팅하도록 구성합니다"는 API Gateway가 ALB의 특정 대상 그룹으로 직접 트래픽을 라우팅하는 기능이 없으므로 불가능합니다. API Gateway는 일반적으로 ALB 자체를 백엔드로 사용합니다. 오답인 "새 앱 버전을 위해 ALB 뒤에 새 대상 그룹을 추가하고 API Gateway가 ALB가 모든 트래픽을 해당 새 대상 그룹으로 전달하도록 구성합니다"는 모든 트래픽을 한 번에 전환하므로 문제가 발생할 경우 사용자 중단이 크고 빠른 롤백이 어렵습니다.