Kubernetes에서 Node.js Liveness와 Readiness Probe 설계 가이드

개요

Kubernetes 환경에서 Liveness Probe와 Readiness Probe는 애플리케이션 상태를 주기적으로 점검해 자동 복구와 트래픽 차단을 수행하는 안전 장치 역할 수행 Node.js는 싱글 스레드 기반으로 이벤트 루프 차단이나 메모리 누수 상황이 치명적이라 두 프로브의 설계가 안정성에 직접적인 영향 미침

핵심 차이

Liveness Probe의 질문은 너 살아있니, 실패 시 컨테이너 재시작 수행
Readiness Probe의 질문은 일할 준비 됐니, 실패 시 서비스 엔드포인트에서 제외해 트래픽 차단 수행
본질적 차이는 실패 시 K8s가 취하는 액션이며 재시작과 트래픽 제어로 구분됨

Node.js 맥락

Liveness Probe 대상 상황
- 이벤트 루프 블로킹으로 요청 처리 불가 상태
- 무한 루프 또는 데드락과 유사한 좀비 상태로 PID는 있으나 응답 불능
- 메모리 누수로 OOM 임박하여 응답 지연 또는 멈춤에 가까운 상태
Readiness Probe 대상 상황
- 프로세스는 떠 있으나 초기화 작업 진행 중인 상태
- DB 연결 수립 중, 대용량 설정 로딩, 캐시 워밍업 등으로 실제 서비스 처리 불가 상태
유의점
- Liveness는 가벼운 체크로 한정, 외부 의존성까지 포함 시 불필요한 재시작 유발 위험
- Readiness는 실제 트래픽 처리 가능 여부를 반영해야 하며 의존성 준비 상태를 포함하는 편이 안전함

구현 스니펫

Node.js에서 Liveness는 최소한의 핑 수준으로, Readiness는 의존성 준비 여부를 반영하는 형태 권장

간단한 Express 핸들러 예시

let isReady = false

// Liveness
app.get('/health/live', (_req, res) => res.status(200).send('OK'))

// Readiness
app.get('/health/ready', (_req, res) => {
  if (isReady) return res.status(200).send('OK')
  return res.status(503).send('Not Ready')
})

준비 플래그는 DB 연결 완료 시점 등에서 true로 전환하는 방식 권장

Kubernetes 프로브 최소 설정 예시

livenessProbe:
  httpGet:
    path: /health/live
    port: 3000
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health/ready
    port: 3000
  initialDelaySeconds: 5
  periodSeconds: 10

앱 기동 시간이 긴 경우 startupProbe 사용 고려

startupProbe:
  httpGet:
    path: /health/live
    port: 3000
  periodSeconds: 5
  failureThreshold: 12

주의와 베스트 프랙티스

Liveness에 DB 체크 넣지 않기
- DB 일시 지연으로 Liveness 실패 시 컨테이너 재시작 폭주 발생 가능
- 재접속 과부하로 DB 상태 악화, 전체 장애로 확산되는 연쇄 실패 위험
Readiness에는 실제 서비스 처리 가능 상태를 반영
- DB 연결 불가, 핵심 캐시 미구축 시 503 반환으로 트래픽 유입 차단
초기 지연 대응
- initialDelaySeconds를 앱 기동 시간보다 여유 있게 설정 또는 startupProbe로 초기 부트 구간 명시
과한 작업 금지
- Liveness 핸들러에 무거운 로직, 외부 네트워크 호출, 파일 IO 등 포함 금지
- Readiness도 불필요한 비용 최소화, 필요한 의존성 상태만 점검
프로브 타이밍 파라미터 조정
- periodSeconds, timeoutSeconds, failureThreshold를 워크로드 특성에 맞춰 튜닝
- 일시적 네트워크 지연에 과민하지 않도록 실패 임계값 완충 적용
엔드포인트 분리
- /health/live와 /health/ready는 별도 라우트로 유지, 공용 미들웨어에서 불필요한 비용 유입 방지

운영 시 고려사항

배포 중 Readiness가 OK가 될 때까지 로드밸런서가 신규 파드로 트래픽을 라우팅하지 않음
- 롤링 업데이트 시 502와 같은 전이적 오류 방지에 효과적
장애 상황 가시화
- Liveness 재시작 이벤트와 Readiness 변화를 모니터링 지표로 수집하면 회귀나 성능 저하 조기 탐지에 유용
Node.js 특성 반영
- 이벤트 루프 블로킹은 Liveness로 조기 감지 가능
- 메모리 누수로 인한 GC 압박과 응답 지연은 Readiness 변동과 함께 관찰 시 원인 추적에 도움

요약

Liveness Probe는 죽었으면 살려내라, 실패 시 재시작 수행
Readiness Probe는 준비 안 됐으면 손님 받지 마라, 실패 시 트래픽 차단 수행
Node.js에서는 Liveness를 가볍게, Readiness로 의존성 준비 상태를 엄밀히 반영
초기 부트 지연 구간은 startupProbe로 구분해 재시작 루프 예방 권장

개요#

핵심 차이#

Node.js 맥락#

구현 스니펫#

주의와 베스트 프랙티스#

운영 시 고려사항#

요약#

참고자료#

개요

핵심 차이

Node.js 맥락

구현 스니펫

주의와 베스트 프랙티스

운영 시 고려사항

요약

참고자료