ALB에 새로 등록한 대상은 헬스 체크에 한 번 성공하면 healthy로 판정됩니다. 이미 unhealthy가 된 대상은 HealthyThresholdCount에 설정된 횟수만큼 연속으로 성공해야 healthy로 복구됩니다. 따라서 같은 대상 그룹에서도 신규 등록과 장애 복구에 필요한 성공 횟수가 다릅니다.
같은 설정인데 정상 판정 횟수가 다른 이유
HealthyThresholdCount는 unhealthy 대상을 다시 정상으로 판단하는 데 필요한 연속 성공 횟수입니다. 신규 등록 대상의 최초 정상 판정에 이 값을 그대로 적용하면 상태 전환을 잘못 해석하게 됩니다.
| 대상의 상황 | 정상 판정에 필요한 성공 | 해석 |
|---|---|---|
| 신규 등록 후 최초 검사 | 1회 | HealthyThresholdCount만큼 기다리는 규칙이 아님 |
| unhealthy에서 복구 | HealthyThresholdCount만큼 연속 성공 | 한 번 성공한 것만으로 복구 완료를 판단할 수 없음 |
등록 또는 최초 검사가 진행 중이면 대상 상태는 initial로 표시될 수 있습니다. 반면 unhealthy는 헬스 체크에 응답하지 않았거나 검사에 실패한 상태이므로, 이후 정상 판정에는 복구 기준을 적용해야 합니다.
대상 상태와 설정을 대조하는 순서
- 헬스 체크가 수행될 전제를 확인합니다. 대상이 대상 그룹에 등록되어 있고, 해당 그룹이 리스너 규칙에 지정되어 있으며, 대상의 가용 영역이 ALB에서 활성화되어 있어야 합니다.
- 현재 상태와 이전 상태를 구분합니다. 새로 등록되어 initial 상태에서 검사 중인지, 이미 unhealthy로 판정된 뒤 복구 중인지 확인합니다. 현재 healthy라는 정보만으로는 어느 과정을 거쳤는지 알 수 없습니다.
- 대상 그룹의 HealthyThresholdCount를 확인합니다. 이 값을 unhealthy 복구에 필요한 연속 성공 횟수로 해석합니다.
- 성공의 조건을 확인합니다. HTTP 헬스 체크라면 지정된 프로토콜·포트·경로에 대한 응답이 제한 시간과 성공 코드 설정인 Matcher를 충족하는지 대조합니다. 별도 요청에서 응답을 받았다는 사실만으로 ALB 검사의 성공을 단정하지 않습니다.
상태가 예상과 다르면 이유 코드도 함께 확인합니다. 예를 들어 Elb.InitialHealthChecking은 최초 검사 진행을 뜻합니다. unused라면 성공 횟수를 기다리기 전에 대상 사용 조건부터 확인해야 합니다.
예제: HealthyThresholdCount가 3인 대상 그룹
다음은 동작을 설명하기 위한 가상 예제입니다. 두 대상 모두 등록·리스너 규칙·가용 영역 조건을 충족하며, HTTP 헬스 체크의 경로는 /health, Matcher는 200, HealthyThresholdCount는 3으로 설정했다고 가정합니다. 표의 성공은 ALB의 헬스 체크 조건을 충족했다는 뜻입니다.
| 대상 | 출발 상태 | 이후 검사 결과 | 기대하는 해석 |
|---|---|---|---|
| A | 신규 등록 후 initial | 성공 | 최초 1회 성공으로 healthy 판정 조건 충족 |
| B | unhealthy | 성공 → 성공 | 연속 성공 2회이므로 복구 조건 미충족 |
| B | 위 검사에 이어서 | 성공 | 연속 성공 3회로 healthy 복구 조건 충족 |
A가 한 번의 성공으로 정상 판정을 받아도 설정이 무시된 것은 아닙니다. B가 두 번 성공한 뒤에도 unhealthy라면 그것만으로 새로운 장애가 발생했다고 판단할 수 없습니다. 복구에 필요한 세 번째 연속 성공이 아직 남아 있기 때문입니다.
B의 결과가 성공 → 성공 → 실패 → 성공이라면 누적 성공은 세 번이지만 연속 성공은 마지막 한 번입니다. 이 결과로는 연속 3회라는 복구 조건을 충족하지 못합니다.
성공 횟수를 해석할 때의 한계
- 최초 검사 중이라는 조건을 확인해야 합니다. 새로 등록한 대상이라도 이미 unhealthy로 판정되었다면 이후에는 unhealthy 복구 기준으로 해석합니다.
- 횟수만으로 정확한 완료 시각을 계산하지 않습니다. HealthCheckIntervalSeconds는 검사 사이의 대략적인 간격입니다. 등록 시각에 간격과 횟수를 곱해 상태 전환 시각을 확정할 수는 없습니다.
- 서버의 전체 요청 수를 단일 연속 성공 횟수로 보지 않습니다. ALB의 각 노드가 대상을 검사하므로 여러 노드의 요청이 섞인 기록만으로 복구 조건 충족을 단정하지 않아야 합니다.
- 복구 기준을 높여도 최초 등록 기준은 달라지지 않습니다. HealthyThresholdCount를 높이면 복구에 더 많은 연속 성공을 요구하지만, 신규 대상에도 같은 횟수의 검증을 강제하는 효과는 없습니다.
상태를 확인할 때는 먼저 ‘최초 정상 판정인가, unhealthy 복구인가’를 기록하세요. 그다음 최초 판정에는 1회 성공을, 복구에는 설정된 연속 성공 횟수를 적용하면 대기 중인 상태를 더 정확히 해석할 수 있습니다.