[AWS] ALB Health Check Logs 구성 방법

Application Load Balancer (ALB)에 새로운 기능인 Health Check Logs 가 정식으로 추가되었습니다. 이 기능을 이용하면 Target에 대한 헬스체크 결과를 S3에 자동 저장할 수 있어, 서비스 장애나 불안정 원인을 파악하기가 훨씬 쉬워집니다.

왜 ALB Health Check Logs인가

기존에는 ALB가 Target (예: EC2, IP, Lambda) 상태를 체크해 비정상(Target Unhealthy)을 감지해도, 왜 비정상이 되었는지 진단하기가 쉽지 않았습니다. 애플리케이션 로그가 없거나, Auto-Scaling으로 인스턴스가 사라진 경우는 원인 파악이 더욱 어려웠습니다.

 

Health Check Logs를 사용하면 다음과 같은 장점이 있습니다.

• 헬스 체크 시점의 상태 (예: PASS / FAIL) 기록
• 실패 시점의 상세 사유 (HTTP 응답 코드, 타임아웃, 연결 실패 등) 기록
• 언제, 어느 대상(Target IP/Port)이 문제를 일으켰는지 정확하게 추적 가능
• 시간 경과에 따른 헬스체크 성공/실패 패턴 분석 가능 → 간헐적 장애 대응에 유리
• 로드밸런서 단에서 로그를 남기므로, 대상 인스턴스 로그가 사라졌더라도 원인 추적 가능

이로 인해 운영팀의 MTTR(Mean Time To Resolution)을 크게 줄일 수 있는 기반을 마련할 수 있습니다.

설정 절차

ALB Health Check Logs는 기본적으로 비활성화되어 있으며, 설정을 통해 활성화해야 합니다. 공식 문서에 따르면 콘솔, CLI, CloudFormation 모두 지원됩니다.

1. S3 버킷 준비

• Health Check 로그를 저장할 S3 버킷을 생성하거나 기존 버킷을 사용 가능
• 버킷 정책(Bucket Policy)을 통해 ALB (log delivery) 권한 부여 필요
• 만약 기존 버킷을 사용한다면, 기존 정책에 AWS 로그 전송 권한을 추가해야 합니다.

예시 정책 (JSON):

{
  "Effect": "Allow",
  "Principal": { "Service": "logdelivery.elasticloadbalancing.amazonaws.com" },
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::your-log-bucket/health-check-logs/*"
}

 

2. ALB에서 Health Check Logs 활성화

콘솔

1. EC2 콘솔 → Load Balancers → 대상 ALB 선택
2. Attributes 탭 → Edit
3. “Health Check logs” 항목에서 Enabled = true, S3 버킷 및 (선택적) prefix 지정
4. 저장 후, 로그 전달이 시작됩니다.

AWS CLI 예시

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <alb-arn> \
  --attributes Key=health_check_logs.s3.enabled,Value=true \
               Key=health_check_logs.s3.bucket,Value=<your-bucket-name> \
               Key=health_check_logs.s3.prefix,Value=<optional-prefix>

 

prefix를 지정할 경우, prefix에 "AWSLogs" 문자열이 포함되지 않도록 주의해야 합니다.

3. 로그 확인 및 사용

• 로그는 기본적으로 5분 간격으로 로드 밸런서 노드별로 S3에 .log.gz 형식으로 기록됩니다.
• 로그 기록 주기가 짧고, 대상이 많거나 헬스체크 주기가 짧다면 동일 기간에 여러 로그가 생성될 수 있습니다.
• 로그 파일은 S3 수명주기 규칙(Lifecycle rules)을 사용해 보관/삭제 정책을 설정하는 것이 좋습니다.
• 로그 파일 이름 예시:

s3://your-bucket/prefix/AWSLogs/123456789012/elasticloadbalancing/ap-northeast-1/2025/11/22/health_check_log_123456789012_elasticloadbalancing_apploadbalancer-1_20251122T1535Z_172.31.0.10_<random>.log.gz

 

 

운영 팁 및 주의점

1. 장애 진단 & MTTR 단축

• 이전엔 “왜 Unhealthy가 됐을까?”를 찾기 위해 대상 인스턴스 로그, 애플리케이션 로그, 접근 로그, CloudWatch 메트릭을 복합적으로 분석해야 했지만, Health Check Logs만으로 실패 원인을 거의 즉시 파악할 수 있습니다. 예를 들어 HTTP 502, 타임아웃, 연결 실패 등 원인 코드가 로그에 남습니다.
• 이를 통해 반복되는 헬스체크 실패 패턴을 그래프로 시계열로 분석하거나, 특정 시간대/대상에 문제가 집중되는지 확인할 수 있습니다.

2. 접근 로그 / 연결 로그 / 헬스체크 로그의 조합

• 기존 ALB Access Logs, Connection Logs, Request Tracing, CloudTrail 로그 등과 함께 사용하면, 요청 → 라우팅 → 타겟 헬스 상태 → 응답 흐름 전체를 추적할 수 있습니다.
• 예: 특정 요청 경로에서만 타겟이 Unhealthy 처리된다면, Access Log + Health Check Log + 애플리케이션 로그를 함께 확인해보면 원인 규명에 유리합니다.

3. 비용 & 보안 고려

• Health Check Logs 기능 자체에는 추가 비용이 없습니다. 다만 로그 저장을 위한 S3 스토리지 요금이 발생합니다.
• S3 버킷 정책은 올바르게 설정해야 하며, 잘못된 설정으로 인해 로그가 쓰이지 않거나, 엉뚱한 계정에 노출되지 않도록 주의해야 합니다.
• 로그가 많아지면 저장 공간이 빠르게 늘 수 있으므로, S3 수명주기 정책을 미리 설계할 것을 권장합니다.

마무리

ALB Health Check Logs 기능은 ALB를 사용한 서비스에서 헬스체크 실패의 원인을 빠르고 명확하게 파악하고자 할 때 매우 유용한 도구입니다. 설정도 복잡하지 않고, S3 버킷 하나 준비하면 바로 적용할 수 있어서, 운영팀 입장에서는 도입 부담이 크지 않습니다.

• S3 버킷 + 권한 설정 → ALB Attributes에서 활성화 → 로그 수집 시작
• Access / Connection / Health Check 로그를 함께 활용해 요청 → 라우팅 → 상태 흐름 전체 가시화
• 장애 원인 분석, 재현 불가 장애 조사, 패턴 분석, MTTR 단축에 활용