Docker운영과 디버깅

healthcheck와 container readiness

컨테이너가 단순히 떠 있는 상태와 실제로 요청을 받을 준비가 된 상태가 왜 다른지, healthcheck를 어떤 기준으로 설계하는지 정리합니다.

마지막 수정 2026년 3월 22일

기본 패턴

dockerfile
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

설명

  • 컨테이너가 실행 중(running)이라고 해서 서비스가 정상 응답 중이라는 뜻은 아닙니다. 프로세스는 떠 있지만, DB 연결이 안 됐거나 초기화가 끝나지 않았을 수 있습니다.
  • HEALTHCHECK는 컨테이너 안에서 주기적으로 검사 명령을 실행해, 준비 상태와 이상 상태를 더 정확히 표현하게 해 줍니다.
  • 이 기능은 운영 관점에서 특히 중요합니다. 배포 직후 readiness 확인, 문제 컨테이너 식별, Compose나 오케스트레이션 환경에서 의존 서비스 타이밍 제어에 도움이 됩니다.
  • 좋은 healthcheck는 "가벼우면서도 실제 서비스 가능 여부를 잘 반영"해야 합니다. 너무 무거우면 검사 자체가 부담이 되고, 너무 단순하면 의미가 없습니다.
  • 결국 healthcheck는 관측성의 일부입니다. 단순히 프로세스 생존이 아니라, 애플리케이션이 사용할 만한 상태인지 드러내는 장치로 이해하는 편이 좋습니다.

빠른 정리

상태의미
running프로세스가 떠 있음
healthy검사 기준을 만족
unhealthy검사 실패 누적
핵심 질문지금 요청을 받아도 되는가

주의할 점

healthcheck를 단순 포트 열림 검사만으로 끝내면, 실제 앱이 준비되지 않았는데도 정상으로 보일 수 있습니다. 서비스 특성에 맞는 최소한의 readiness 기준을 같이 생각해야 합니다.

참고 링크

2 sources