헬스체크(Health Check)란?

 

매일메일 백엔드 질문을 참고해 개인적으로 학습한 내용을 정리하였습니다.
오류가 있다면 언제든 피드백 주시면 바로 반영하겠습니다..!

 

 

 

헬스체크란?

 

헬스체크(Health Check)는 현재 서버나 어플리케이션의 상태가 정상인지 파악하는 것을 의미함

 

=> API 엔드포인트를 호출하거나 특정 포트로 TCP 연결을 시도하는 방식을 사용할 수 있으며, Spring Actuator를 활용하여 헬스체크 기능을 사용할 수 있음

 

이런 헬스체크는 로드 밸런서나 오케스트레이션 도구(ECS, Kubernetes 등)가 서버 상태를 판단하고 트래픽을 효율적으로 분산하는 데에 핵심적인 역할을함

 

헬스체크가 왜 필요할까?

 

배포 상태 확인

 

 

새로운 버전을 배포한 직후, 어플리케이션이 정상적으로 기동되었는지 자동으로 확인할 수 있음

 

=> 헬스체크가 통과되어야만 실제 트래픽이 들어가기 때문에, 문제가 있는 서버에 요청이 가지 않도록 방지할 수 있음

 

 

장애 조기 감지 및 대응

 

예기치 않은 에러나 자원 고갈(CPU, 메모리 등)이 발생한 경우, 헬스체크 실패를 통해 서버가 비정상 상태임을 빠르게 탐지할 수 있음

 

=> 이로 인해 로드 밸런서가 해당 서버를 트래픽 분산 대상에서 제외하여 장애 확산을 막을 수 있음

 

자동화된 무중단 배포 (Docker, ECS, K8s 등)

 

많은 클라우드 환경에서 헬스체크를 기반으로 자동 롤링 업데이트와 무중단 배포를 제공함

 

=> 새 인스턴스 Healthy 상태가 되기 전까지는 트래픽을 넘기지 않기 때문에 사용자는 문제 없이 서비스를 이용할 수 있음

 

롤링 업데이트(Rolling Update)는 배포 전략 중 하나로, 전체 서비스를 한 번에 중단하지 않고 하나씩(또는 소수씩) 순차적으로 업데이트하는 방식임

=> 서버 여러 대 중에서 한 대씩 업데이트 하고, 문제가 없으면 다음 서버를 업데이트하는 방식으로 전체 서버를 한 번에 업데이트하는 방식과는 달리, 사용자는 서비스 중단을 거의 느끼지 못한다는 장점이 있음

 

헬스체크의 방식

 

HTTP 헬스체크

 

가장 일반적인 방식으로, 지정된 엔드포인트에 주기적으로 HTTP 요청을 보내고 응답 상태 코드를 확인함

 

GET /health
200 OK

 

TCP 헬스체크

 

특정 포트에 TCP 연결을 시도하여 서버가 수신 가능한 상태인지 확인함

 

=> HTTP 서버가 완전히 기동되지 않았더라도, 프로세스 레벨에서 동작 여부를 판단할 수 있음

 

예를 들어 Spring Boot 서버라면, 애플리케이션이 실행되면서 Bean 초기화, DB 연결, 설정 로딩 등이 완전히 끝나지 않았더라도 이미 포트(ex. 8080)를 열고 TCP 수신 대기(listen) 하고 있을 수 있음

이 시점에서는 HTTP 요청을 받더라도 에러를 뱉을 수 있지만, TCP 수준에서는 연결은 가능함

=> 즉, telnet <IP> <PORT>는 성공함
(프로세스는 살아 있음)

 

 

Spring Boot에서 헬스체크 구현하기

 

Spring Boot에서는 Spring Boot Actuator 라이브러리를 통해 헬스체크를 매우 간편하게 구현할 수 있음

 

// build.gradle
implementation 'org.springframework.boot:spring-boot-starter-actuator'

 

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: health, info

 

 

이렇게 설정을 하게되면 기본적으로 /actuator/health 엔드포인트가 생성되며

 

{
  "status": "UP"
}

 

위와 같은 JSON 응답을 제공함 
(추가로, DB, Redis, Kafka, S3 등의 의존성까지 포함한 복합 헬스체크도 가능함)

 

헬스체크 실패 시의 시나리오 예시

 

서버 A, B 두 대가 있고 로드 밸런서가 요청을 균등하게 분산하고 있는 환경이 있는데

(정기적으로 /health 엔드포인트를 이용한 헬스체크 수행중)

 

서버 A에서 DB 연결 실패 또는 메모리 누수로 인한 GC 병목이 발생해서 /health 응답이 실패가된 상황임

 

그럼 로드 밸런서는 서버 A를 트래픽 대상에서 제외하고 모든 요청은 정상 서버인 B로 전달됨

=> 관리자 또는 모니터링 시스템이 A의 상태를 감지하고 자동 재시작 또는 알림을 발송하게됨

 

이렇게 되면

 

• 사용자에게 장애 서버의 오류 응답이 전달 X
  
  
• 자동 복구 또는 수동 점검까지 안전한 상태 유지 가능
  
  
• 클라이언트의 재시도로 인해 전체 트래픽이 증가하는 도미노 현상(장애) 방지

 

와 같은 장점이 있음

 

헬스체크 설계 시 주의사항

 

 

1. 너무 무거운 연산 금지

 

헬스체크는 자주 호출되므로, DB 쿼리 등은 간단하고 빠르게 수행되는 것으로 구성해야함

 

 

2. /healthz vs /readyz

 

Kubernetes에서는 liveness(살아있는지)와 readiness(요청을 받을 준비가 되었는지)를 분리해서 체크함

 

Spring Actuator에서 기본 /health는 모든 상태(DB, Redis 등 포함)를 다 확인함

그런데 서비스가 처음 시작될 때, DB 연결이 아직 안되어 있어서 /health에서 실패할 수 있기에 liveness와 readiness를 구분함

 

구분	의미	실패 시 행동	예시
liveness	앱이 살아있는가? (죽었는지 확인)	재시작함	OutOfMemory 등
readiness	요청 받을 준비가 됐는가?	트래픽 제외만	DB 연결 안 됨 등

 

 

앱은 살아있지만 아직 준비가 안 된 상황(DB 연결 지연 등)에서는 readiness만 실패하는게 맞고 만약 이걸 liveness에서 실패하게 하면, ECS나 K8s가 앱을 재시작해버리기에 문제가 커질 수 있음

 

=> 그래서 DB 등은 readiness에만 포함하고, liveness에서는 단순히 애플리케이션만 살아있는지만 확인하게 설계하는 게 좋음

 

management:
  endpoint:
    health:
      group:
        liveness:
          include: ping
        readiness:
          include: db, redis

/*
/actuator/health/liveness → 단순 “ping”만 확인 (항상 UP)
/actuator/health/readiness → DB, Redis 포함
*/

 

위와 같이 설정 후 Kubernetes/ECS에서 사용하는 liveness, readiness probe에 각각 매핑 가능하기도 하고

 

@Component("myApi")
public class MyApiHealthIndicator implements HealthIndicator {
    @Override
    public Health health() {
        boolean isApiHealthy = checkMyInternalApi(); // 내가 정의한 체크 로직
        return isApiHealthy ?
            Health.up().build() :
            Health.down().withDetail("error", "API connection failed").build();
    }
}

management:
  endpoint:
    health:
      group:
        readiness:
          include: db, redis, myApi
          
# myApi라는 이름으로 등록된 커스텀 health indicator는
# 기본 /actuator/health에 포함되고,
# 명시적으로 readiness에 포함시키려면 config에 include: myApi 추가

 

Spring Boot에서 커스텀 HealthIndicator를 정의하여 이를 분리 구현할 수 있음

 

 

 

3. 의존성 외부 시스템 포함 여부 결정

 

 

DB, Kafka, Redis 등과 연결 상태를 체크할지 여부는 서비스 특성에 따라 판단함

 

=> 초기 구동 시점에는 DB 연결이 지연될 수 있으므로, readiness에만 포함하는 방식도 고려해야함

 

• readiness에 포함해야 할 때
  
  
  • DB, Redis, Kafka가 없으면 서비스 요청을 처리할 수 없는 경우
    
    => 이 경우 readiness 실패 시 트래픽을 받지 않게 하는 게 맞음
    
    
    
• readiness에도 제외해야 할 때
  
  
  • 일부 비즈니스만 해당 시스템을 필요로 하고, 앱의 대부분은 동작 가능할 때
    (또는 초기 구동 시 DB가 늦게 준비되는데도 트래픽은 받아도 되는 경우)