웹사이트가 ALB 뒤의 4개 EC2 인스턴스에서 실행됩니다. ALB가 인스턴스를 비정상으로 표시하면 CloudWatch 경보가 ALARM 상태가 되고 운영자가 수동으로 대체 인스턴스를 추가합니다. 회사는 새로운 설계로 마이그레이션하는 동안 다운타임을 최소화하면서 실패한 EC2 인스턴스를 자동으로 교체하는 고가용성 솔루션을 원합니다. 솔루션스 아키텍트는 어떤 단계 시퀀스를 사용해야 할까요?

이 솔루션은 기존 ALB와 EC2 인스턴스를 유지하면서 Auto Scaling 그룹을 도입하여 다운타임을 최소화합니다. 먼저 웹 트래픽에 맞게 크기가 조정된 Auto Scaling 그룹과 새 시작 템플릿을 생성하여 인스턴스 자동 교체를 위한 기반을 마련합니다. 그런 다음 이 Auto Scaling 그룹을 기존 ALB에 연결하여 로드 밸런싱 기능을 활용합니다. 마지막으로 기존 EC2 인스턴스를 Auto Scaling 그룹에 추가하여 현재 운영 중인 인스턴스들을 관리 범위에 포함시키고, 향후 인스턴스 장애 발생 시 Auto Scaling 그룹이 자동으로 교체 인스턴스를 시작하도록 합니다. 다른 옵션들은 불필요한 다운타임을 유발하거나 비효율적입니다. 기존 ALB를 삭제하거나 새 ALB를 생성하는 것은 서비스 중단을 초래할 수 있으며, Auto Scaling 그룹이 최소 인스턴스를 시작할 때까지 기다리는 것은 초기 배포 시간을 지연시킵니다. 기존 인스턴스를 Auto Scaling 그룹에 추가하는 대신 ALB가 자동으로 등록하기를 기다리는 것은 제어력을 떨어뜨리고 예상치 못한 동작을 유발할 수 있습니다.