ALB 대상이 unhealthy라면 먼저 대상의 이유 코드를 확인하세요. Target.ResponseCodeMismatch는 응답은 받았지만 코드가 설정된 성공 코드와 일치하지 않은 경우이고, Target.Timeout은 요청이 제한 시간 안에 응답받지 못한 경우입니다. 전자는 실제 응답 코드와 성공 코드·경로를, 후자는 요청 대상의 프로토콜·포트와 응답 제한 시간을 우선 대조합니다.
unhealthy 상태만으로는 실패 원인을 알 수 없다
ALB는 대상 그룹의 헬스 체크 설정에 따라 등록된 대상에 주기적으로 요청합니다. unhealthy는 헬스 체크에 실패했다는 상태이며, 구체적인 실패 유형은 이유 코드와 설명으로 구분해야 합니다. 콘솔에서 대상의 상태 설명을 확인하거나 API가 반환하는 이유 코드와 설명을 확인할 수 있습니다.
| 이유 코드 | 확인된 사실 | 우선 점검할 항목 |
|---|---|---|
Target.ResponseCodeMismatch |
받은 응답 코드가 성공 코드 조건에 맞지 않음 | 설명에 표시된 코드, Matcher, 요청 경로 |
Target.Timeout |
요청 시간이 초과됨 | 프로토콜, 포트, 응답 여부와 제한 시간 |
이유 코드는 원인 분석의 출발점입니다. 코드 불일치만으로 애플리케이션 전체가 고장 났다고 단정할 수 없고, 타임아웃만으로 네트워크 문제인지 애플리케이션 지연인지 확정할 수도 없습니다.
성공 코드·경로·포트·제한 시간을 점검하는 순서
아래 절차는 HTTP/1.1 또는 HTTP/2 응답 코드를 사용하는 대상 그룹을 기준으로 합니다. 사전에 해당 대상 그룹과 대상 상태를 조회할 권한, 애플리케이션의 실제 수신 포트와 헬스 체크 경로에 대한 정보가 필요합니다. 응답 기록까지 대조하려면 관련 로그를 조회할 수 있어야 합니다.
-
대상과 설정을 함께 기록합니다. 대상 식별 정보, 이유 코드와 설명, 확인 시각을 적고 같은 대상 그룹의
HealthCheckProtocol,HealthCheckPort,HealthCheckPath,Matcher,HealthCheckTimeoutSeconds를 확인합니다. 서로 다른 대상 그룹의 설정을 섞어 비교하지 않도록 합니다. -
코드 불일치라면 설명에 나온 코드를 Matcher와 비교합니다. Matcher는 콘솔의 Success codes에 해당하며, HTTP/1.1과 HTTP/2에서는 기본값이
200입니다. 예를 들어 실제 응답이204이고 성공 코드가200뿐이면 불일치입니다. 응답 자체가 의도한 정상 동작인지 확인한 뒤 애플리케이션 응답 또는 성공 코드 설정을 조정합니다. -
헬스 체크 경로를 확인합니다. HTTP 헬스 체크는 GET 요청을 사용합니다. 브라우저에서 접속한 페이지가 아니라 설정된 경로가 GET 요청에 어떤 코드를 반환하는지 확인해야 합니다. 경로 기본값은
/이며, 애플리케이션이 준비한 점검 경로가 별도로 있다면 그 경로와 대조합니다. -
프로토콜과 포트를 확인합니다. 헬스 체크 프로토콜은 HTTP 또는 HTTPS이며, 포트 기본값은 각 대상이 ALB 트래픽을 받는 포트입니다. 별도 포트를 지정했다면 그 포트에서 해당 프로토콜과 경로를 처리하는지 확인합니다. 사용자 접속용 ALB 리스너 포트만 확인해서는 대상에 보내는 헬스 체크 조건을 알 수 없습니다.
-
타임아웃이라면 설정된 제한 시간과 응답 기록을 대조합니다.
HealthCheckTimeoutSeconds는 응답을 기다리는 시간입니다. 해당 요청이 대상에 도달한 기록이 있는지, 응답을 완료한 기록과 처리 시간은 어떤지 확인합니다. 기록이 없다는 사실만으로 요청이 도달하지 않았다고 확정하지 말고 로그 수집 범위도 확인합니다.
헬스 체크 간격인 HealthCheckIntervalSeconds는 응답 제한 시간과 별개입니다. 요청 간격을 늘리는 것은 한 요청의 응답 대기 시간을 늘리는 조치가 아닙니다.
같은 설정에서 404 응답과 무응답을 비교하는 예시
다음은 실제 실행 결과가 아닌 진단용 가정입니다. HTTP 헬스 체크를 사용하는 대상이 등록되어 있고, 대상 그룹이 리스너 규칙에 연결되어 있으며, 대상의 가용 영역이 ALB에서 활성화되어 있다고 가정합니다.
HealthCheckProtocol: HTTP
HealthCheckPort: 8080
HealthCheckPath: /health
Matcher: 200
HealthCheckTimeoutSeconds: 5| 가정한 관찰 | 예상 해석 | 다음 확인 |
|---|---|---|
| ALB가 제한 시간 안에 404를 받음 | 200과 다르므로 코드 불일치에 해당 | 8080 포트의 애플리케이션에 /health 경로가 있는지 확인 |
| ALB가 5초 안에 응답받지 못함 | 타임아웃에 해당 | 8080 포트의 HTTP 처리 여부와 요청·응답 기록 확인 |
| ALB가 제한 시간 안에 204를 받음 | 응답은 있지만 Matcher가 200이므로 코드 불일치 | 정상 응답 규약이 200인지 204인지 확인 |
예를 들어 애플리케이션의 의도한 점검 경로가 /ready이고 그 경로만 200을 반환한다면, 404를 성공 코드에 추가하기보다 헬스 체크 경로를 바로잡는 것이 적절합니다. 반대로 /health가 정상 상태에서 204를 반환하도록 설계되었다면 성공 코드를 204로 맞추는 선택을 검토할 수 있습니다.
타임아웃 사례에서는 Matcher를 바꿔도 응답을 받지 못하는 문제가 해결되지 않습니다. 먼저 프로토콜·포트가 맞는지 확인하고, 요청을 처리하는 데 시간이 걸린다면 그 이유와 허용 가능한 응답 시간을 확인해야 합니다.
설정 변경 뒤 확인할 한계와 흔한 실수
- 성공 코드 범위를 무작정 넓히면 잘못된 경로나 의도하지 않은 응답까지 정상으로 인정할 수 있습니다. HTTP/1.1과 HTTP/2의 Matcher는 200~499 안에서 여러 값이나 범위를 지정할 수 있지만, 애플리케이션의 정상 상태 의미에 맞춰 선택해야 합니다.
- 제한 시간을 늘리면 더 늦은 응답을 기다릴 수 있지만, 응답하지 않는 원인 자체가 해결되는 것은 아닙니다. 제한 시간 변경과 원인 수정을 구분하세요.
- 한 번 성공했다고 기존 unhealthy 대상이 즉시 healthy로 바뀐다고 기대하지 마세요. 복구 여부에는 설정된 연속 성공 횟수인
HealthyThresholdCount가 적용됩니다. - 직접 보낸 요청의 성공은 보조 증거입니다. ALB의 헬스 체크와 요청 조건이 다르면 같은 결과를 보장하지 않으므로 최종적으로 대상 상태와 이유 코드를 다시 확인해야 합니다.
- gRPC는 성공 코드와 경로 규칙이 다릅니다. 이 글의 HTTP 코드 예시를 그대로 적용하지 마세요.
실무에서는 이유 코드와 설정값을 한 묶음으로 남기고, 코드 불일치는 응답 규약을, 타임아웃은 응답 도달과 대기 시간을 따라 좁혀 가세요. 수정 후에는 연속 성공 조건을 충족해 대상 상태가 복구되는지까지 확인하면 됩니다.