AWS ECS Health Check - 반드시 알아야 할 기본 사항
서문
AWS ECS를 사용할 때 가장 중요한 것은 기본적인 사항을 제대로 이해하는 것입니다. 특히 Health Check 설정은 안정적인 서비스 운영을 위한 핵심 요소입니다. 단순히 메트릭상 CPU와 Memory 사용률이 낮다는 이유로 리소스를 조정하면 예상치 못한 문제가 발생할 수 있습니다.
실제 사례를 보면, Health Check에 대한 이해 없이 리소스 최적화만 진행한 결과 배포가 정상적으로 이루어지지 않고 지속적인 롤백이 발생하는 문제가 있었습니다. ECS Service Events에서 Health checks failed with these codes: [503]라는 메시지와 함께 새로운 Task들이 계속 실패했습니다.
이런 문제를 방지하기 위해서는 AWS ECS Health Check의 기본 원리를 반드시 이해해야 합니다.
AWS ECS Health Check의 3계층 구조
ECS에는 3가지 레벨의 Health Check가 있습니다:
1. Container Health Check (Task Definition)
- 목적: Container 내부 애플리케이션 상태 확인
- 실패 시: Container 재시작
- 설정 위치: Task Definition
"healthCheck": {
"command": ["CMD-SHELL", "curl -f http://localhost:8080/actuator/health || exit 1"],
"interval": 30,
"timeout": 5,
"retries": 3,
"startPeriod": 60
}2. Target Group Health Check (ALB)
- 목적: 외부 트래픽 라우팅 결정
- 실패 시: 트래픽 차단
- 설정 위치: Application Load Balancer Target Group
Health Check Path: /actuator/health
Healthy Threshold: 2 (연속 2번 성공)
Unhealthy Threshold: 2 (연속 2번 실패)
Interval: 30초3. Health Check Grace Period (ECS Service)
- 목적: Task 강제 종료 방지
- 역할: 지정된 시간 동안 Health Check 실패를 허용
- 설정 위치: ECS Service
health_check_grace_period_seconds = 300 # 5분왜 Health Check 설정이 중요한가?
문제 상황 재현
Health Check 설정이 잘못되면 다음과 같은 상황이 발생할 수 있습니다:
12:57 - Task 시작
12:58 - Target Group에 등록
13:00 - Health Check 실패 (503 에러)
13:00 - Task 강제 종료
13:02 - 배포 실패, 롤백 수행근본 원인
리소스가 부족하면 Spring Boot 애플리케이션이 다음과 같은 문제에 직면합니다:
- 메모리 부족: JVM이 충분한 힙 메모리를 확보하지 못함
- 초기화 시간 증가: 리소스 제약으로 애플리케이션 부팅 시간 증가
- Health Check Endpoint 응답 불가:
/actuator/health가 503 에러 반환
올바른 Health Check 설정 방법
1. Container Health Check 설정
container_definitions = {
app = {
healthCheck = {
command = ["CMD-SHELL", "curl -f http://localhost:8080/actuator/health || exit 1"]
interval = 30
retries = 3
startPeriod = 120 # Spring Boot 초기화 시간 고려
timeout = 10
}
}
}2. Target Group Health Check 설정
resource "aws_lb_target_group" "app" {
health_check {
enabled = true
healthy_threshold = 2
unhealthy_threshold = 2
timeout = 5
interval = 30
path = "/actuator/health"
port = "traffic-port"
protocol = "HTTP"
matcher = "200"
}
}3. ECS Service Grace Period 설정
resource "aws_ecs_service" "app" {
health_check_grace_period_seconds = 300
load_balancer {
target_group_arn = aws_lb_target_group.app.arn
container_name = "app"
container_port = 8080
}
}Health Check 동작 원리
정상 배포 시나리오
새 Task 시작 → Grace Period 내에서 Health Check 진행
→ Target Group Health Check 통과 → 트래픽 라우팅 시작
→ 이전 Task Connection Draining → 이전 Task 종료실패 시나리오
새 Task 시작 → Health Check 실패 (503 에러)
→ Grace Period 초과 → Task 강제 종료
→ 배포 실패 → 이전 버전으로 롤백모니터링 및 트러블슈팅
ECS Service Events 확인
aws ecs describe-services \
--cluster your-cluster \
--services your-service \
--query 'services[0].events[0:20].{timestamp:createdAt,message:message}'주요 에러 메시지들
Health checks failed with these codes: [503]- 애플리케이션 응답 불가deployment failed: tasks failed to start- Task 시작 실패rolling back to deployment- 자동 롤백 수행
결론
AWS ECS를 사용할 때는 반드시 Health Check의 기본 사항을 숙지해야 합니다. 3계층의 Health Check가 유기적으로 연동되어 서비스의 안정성을 보장하는 원리를 이해하고 적용해야 합니다.
단순히 메트릭만 보고 리소스를 최적화하는 것은 위험합니다. 애플리케이션의 특성을 고려한 Health Check 설정을 통해 안전한 배포 전략을 수립해야 합니다.
핵심 포인트:
- Container Health Check로 애플리케이션 내부 상태 모니터링
- Target Group Health Check로 트래픽 라우팅 제어
- Health Check Grace Period로 안전한 배포 보장
- ECS Service Events로 배포 상태 실시간 모니터링
ECS를 효과적으로 활용하기 위해서는 이러한 기본 사항을 반드시 숙지하고 적용해야 합니다. 이는 안정적인 서비스 운영의 기반이 됩니다.