ALB
그동안 ALB(Application Load Balancer)의 상태 확인은 대상 그룹(Target Group)의 Target Health 화면과 일부 CloudWatch 지표에 의존해 왔습니다. 그러나 이 정보만으로는 "정확히 어떤 요청이 어떤 이유로 실패했는지" 파악하는 데 한계가 있었습니다. 타임아웃인지, 응답 코드 문제인지, 혹은 애플리케이션 내부 오류인지 명확히 구분하기 어려웠기 때문입니다. 결국 EC2나 애플리케이션 로그를 직접 확인하거나 AWS Support에 케이스를 생성해야 하는 번거로운 상황이 종종 발생했습니다.
다행히 Health Check Logs(상태 검사 로그) 기능이 추가되었습니다. 이제 각 타깃에 대해 어떤 프로토콜로 언제 상태 검사를 보냈고, 응답 시간은 얼마나 걸렸으며, 어떤 상태 코드와 실패 사유로 인해 비정상(Unhealthy)으로 판단되었는지를 한 줄의 로그로 바로 확인할 수 있게 되었습니다.
Health Check Logs는 기본적으로 비활성화된 선택 기능이므로 해당 ALB에서 직접 활성화해야 합니다. 절차는 크게 다음과 같습니다.
S3 버킷 준비
ALB에서 Health Check Logs 활성화
활성화 이후 ELB는 각 로드 밸런서 및 대상 그룹에 대해 지정된 간격으로 상태 검사 로그 파일을 설정한 버킷에 gzip 형식으로 업로드합니다. 로그 파일은 bucket[/prefix]/AWSLogs/계정ID/elasticloadbalancing/리전/연/월/일/health_check_log_...log.gz 경로와 이름으로 저장됩니다. 대상(Target) 수가 많거나 상태 검사 주기를 짧게 설정했다면 같은 5분 구간 내에도 여러 개의 로그 파일이 생성될 수 있습니다.
Health Check Logs의 각 로그 라인은 한 번의 상태 검사 결과를 의미하며, 공백으로 구분된 여러 필드로 구성됩니다. 주요 필드는 아래와 같습니다.
http, https, h2, grpc, lambda 등으로 어떤 프로토콜/타입으로 헬스 체크를 했는지 나타냅니다.IP:Port 형식의 EC2 또는 IP 타겟 주소, 혹은 Lambda 타깃인 경우 함수 ARN이 기록됩니다.PASS 실패 시 FAIL이 기록됩니다.ALB, 타겟 그룹 생성 절차는 생략하겠습니다.
S3 버킷의 퍼블릭 액세스를 차단한 상태에서 다음과 같이 버킷 정책을 지정합니다.
#기본 정책 예시
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "logdelivery.elasticloadbalancing.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::<bucket-name>/<prefix>/AWSLogs/<account-id>/*"
}
]
}필자는 별도의 접두사(Prefix)를 지정하지 않았으므로 아래와 같이 적용했습니다.
#Prefix를 지정하지 않은 예시
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "logdelivery.elasticloadbalancing.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::<bucket-name>/AWSLogs/*"
}
]
}
AWS 콘솔의 ALB [속성] 탭 내 [모니터링] 섹션에서 "상태 검사 로그"를 활성화하고 앞서 생성한 버킷을 지정합니다.
위 단계가 정상적으로 완료되면 S3 버킷에 ELBHealthCheckLogTestFile이라는 테스트 파일이 생성됩니다.
콘솔에서 다음과 같은 응답 코드를 확인한 상황을 가정해보겠습니다.
로그를 확인하면 다음과 같은 상세 정보를 볼 수 있습니다.
http 2025-12-12T01:44:51.876800Z 0.002303735 10.0.11.121:80 <tg-name> FAIL 403 ResponseCodeMismatch
http 2025-12-12T01:44:51.877287Z 0.002084793 10.0.12.248:80 <tg-name> FAIL 403 ResponseCodeMismatch
위 로그를 보면 상태 검사 프로토콜, 응답 시간, IP:Port, 응답 코드 등을 확인할 수 있습니다. 내용을 분석해 보면 응답 시간(latency)이 약 0.002초로 매우 짧다는 것을 알 수 있습니다. 이를 통해 네트워크 타임아웃 문제가 아니라 애플리케이션이나 웹 서버가 즉시 403 응답을 반환했음을 짐작할 수 있습니다.
상태 검사가 정상적으로 통과된 경우의 로그는 다음과 같습니다.
http 2025-12-12T04:34:52.837939Z 0.004288887 10.0.11.121:80 <tg-name>PASS 200 -
http 2025-12-12T04:34:52.838434Z 0.003962947 10.0.12.248:80 <tg-name> PASS 200 -2대 중 1대만 실패하는 경우에는 아래와 같이 로그가 기록됩니다.
http 2025-12-12T04:22:28.841953Z 0.002405452 10.0.12.248:80 <tg-name> PASS 200 -
http 2025-12-12T04:22:58.862174Z 0.002346755 10.0.11.121:80 <tg-name> FAIL 404 ResponseCodeMismatch이러한 상세 로그는 실제 운영 환경에서 더욱 빛을 발합니다. 예를 들어10대 중 2대만 실패하는 것과 같은 까다로운 부분 장애 상황에서도 문제의 인스턴스를 핀포인트로 식별할 수 있기 때문입니다.
정리하자면 Health Check Logs를 통해 실패 시점과 응답 코드, 에러 사유를 시계열로 추적함으로써 막연했던 원인 분석 과정을 데이터 기반의 명확한 디버깅 과정으로 개선할 수 있습니다.
