1. 문제 상황
- 증상
- ECS 배포 과정에서 테스크(Task)가 헬스 체크를 통과하지 못해 “Unhealthy”로 표시되고, 자동으로 중단됨.
- 구체적으로는 로드 밸런서(ALB)가 사용하는 타겟 그룹(Target Group)에서 실패 로그(“Task failed ELB health checks in …”)가 발생하고, ECS 콘솔의 Service/Stack에서는 “Deployment Circuit Breaker”가 발동되어 배포가 실패 상태로 남아 있음.
- 하지만…
- 직접
:8080포트를 이용해 웹 브라우저로 접속하면 애플리케이션이 정상 작동한다! - 즉, ECS 관점에서는 ‘실패’ 상태인데, 실제 서비스 접근은 가능한 아이러니한 상황.
- 직접
2. 원인 분석
(1) 포트 설정 불일치
- ECS 태스크 정의에서는 8080 포트로 컨테이너가 기동 중인데,
- ALB의 Health Check는 기본적으로 HTTP 80 포트로 요청을 보냄.
- 서로 다른 포트를 사용하니, ALB에서는 헬스 체크 결과를 “Unhealthy”로 판단하고 태스크를 중단시키려 함.
(2) 보안 그룹/네트워크 설정 문제
- ALB → ECS(Fargate) 컨테이너로의 인바운드 트래픽이 차단되어도 헬스 체크에 실패.
- 특정 포트(예: 8080)가 미리 열려있지 않으면 ALB가 헬스 체크를 제대로 수행하지 못함.
(3) Deployment Circuit Breaker 발동
- ECS에서는 새 태스크가 헬스 체크 시간을 초과해도 Healthy로 전환되지 않으면 자동으로 롤백(배포 취소)하려고 시도.
- 롤백 중 추가 오류가 발생하면, 클라우드포메이션 스택 또는 ECS 서비스가 “FAILED” 상태가 되기도 함.
3. 왜 서비스는 접속 가능한가?
- 실제로는 컨테이너 자체가 잘 기동되어 있기 때문. ALB의 헬스 체크는 실패했어도, 컨테이너는 여전히 애플리케이션을 구동 중.
- 로드밸런서를 통하지 않고 직접
<LB DNS>:8080으로 접근하면 트래픽이 컨테이너 포트와 맞아 떨어져 정상 응답을 받을 수 있음. - 다만, “Unhealthy”로 표시된 태스크를 ECS가 향후 중지시키거나 스케일링 정책에 의해 재시작할 가능성이 있으므로, 장기 운영을 위해서는 정상 헬스 체크가 가능하도록 설정하는 것이 좋다.
4. 해결 방안
- Target Group 설정 변경
- Health Check Port를 8080으로 맞추고, Health Check Path(
/,/health등)에서도 정상 응답이 오도록 설정. - “다음 강의”로 넘어가시는 분들은, 이후 시간을 내어 ALB 리스너/타겟 그룹을 컨테이너 포트(8080)와 일치.
- Health Check Port를 8080으로 맞추고, Health Check Path(
- 보안 그룹 확인
- ALB → ECS 포트(8080) 간 트래픽이 허용되어 있는지 확인(인바운드 규칙).
- Health Check Grace Period 연장
- 애플리케이션이 초기 구동 시간이 걸린다면, 헬스 체크 그레이스 기간을 넉넉히(예: 60초 이상) 설정.
- 컨테이너 내부 로그 확인
- 실제로 8080 포트가 떠 있는지, Spring Boot나 Tomcat에 별다른 예외가 없는지 CloudWatch 로그에서 확인.
5. 마무리
- 이번 오류는 ECS와 ALB의 포트 불일치가 가장 큰 원인.
- 현재는 실패 로그가 뜨지만, 컨테이너가 뜨기만 하면 직접 포트로 연결시 정상 이용 가능하므로 “대충 수습”이 된 상태.
-> 네트워크 공부를 하고, 나중에 다시 정리 및 healh check 해결해 보고.일단은 진도는 빼자....
Dreamer