한 회사에서 Application Load Balancer(ALB) 뒤에 있는 Auto Scaling 그룹의 EC2 인스턴스에서 애플리케이션을 실행합니다. 인스턴스는 시작 시 사용자 데이터 스크립트를 실행하여 S3 버킷에서 중요한 애플리케이션 콘텐츠를 다운로드합니다. 인스턴스가 시작되지만, 얼마 후 "An instance was taken out of service in response to an ELB system health check failure."라는 메시지와 함께 종료됩니다. Auto Scaling은 인스턴스를 반복적으로 시작하고 종료합니다. 최근 변경 사항은 S3 버킷에 많은 양의 중요한 콘텐츠를 추가한 것뿐입니다. 회사는 프로덕션 환경에서 사용자 데이터 스크립트를 수정하고 싶지 않습니다. 솔루션스 아키텍트는 프로덕션 환경이 성공적으로 배포되도록 무엇을 해야 할까요?

정답은 Auto Scaling 그룹 헬스 체크 유예 기간을 늘리는 것입니다. EC2 인스턴스가 시작될 때 사용자 데이터 스크립트가 S3 버킷에서 대량의 중요한 콘텐츠를 다운로드하는 데 시간이 오래 걸립니다. 이 과정이 완료되기 전에 ALB 헬스 체크가 시작되어 인스턴스가 준비되지 않은 것으로 판단하고 종료합니다. 헬스 체크 유예 기간을 늘리면 인스턴스가 시작되고 사용자 데이터 스크립트가 완료되어 애플리케이션이 정상적으로 실행될 시간을 충분히 확보할 수 있습니다. EC2 인스턴스 크기를 늘리는 것은 스크립트 실행 시간을 약간 단축할 수 있지만, 근본적인 문제(스크립트 실행 시간과 헬스 체크 간의 타이밍 불일치)를 해결하지 못할 수 있습니다. ALB 헬스 체크 타임아웃 값을 늘리는 것은 ALB가 응답을 기다리는 시간을 늘리지만, 인스턴스가 준비되지 않은 상태에서 헬스 체크가 시작되는 것을 막지는 못합니다. 헬스 체크 경로를 변경하는 것은 현재 문제와 관련이 없습니다.