헬스체크란 무엇인가
헬스체크는 서버나 애플리케이션이 정상적으로 동작하고 있는지를 주기적으로 확인하는 검사 절차입니다. 쿠버네티스, 로드밸런서, 오케스트레이션 도구 등은 이 헬스체크 결과를 바탕으로 트래픽을 보낼지, 컨테이너를 재시작할지, 서비스에서 제외할지를 판단합니다. 보통 /health나 /healthz 같은 엔드포인트를 만들어 HTTP 200 응답 여부로 상태를 확인하는 방식이 널리 쓰입니다.
Liveness Probe와 Readiness Probe의 차이
쿠버네티스를 예로 들면 헬스체크는 크게 Liveness(살아있는지)와 Readiness(준비되었는지)로 나뉩니다. 이 둘은 목적이 다르기 때문에 반드시 구분해서 이해해야 합니다.
- Liveness Probe: 프로세스가 죽었거나 무한 루프, 데드락 등으로 멈춰있는지 확인합니다. 실패하면 컨테이너를 강제로 재시작시킵니다.
- Readiness Probe: 프로세스는 살아있지만 아직 요청을 처리할 준비가 되지 않은 상태(예: DB 연결 대기, 캐시 워밍업)를 확인합니다. 실패하면 재시작하지 않고 단지 로드밸런서의 트래픽 대상에서 제외합니다.
비유하자면 식당의 주방을 떠올리면 쉽습니다. Liveness는 ‘주방에 불이 켜져 있고 직원이 쓰러지지 않았는가’를 확인하는 것이고, Readiness는 ‘지금 당장 주문을 받아도 되는 상태인가’를 확인하는 것입니다. 주방 불이 켜져 있어도(Liveness 정상) 아직 식재료 준비가 안 됐다면(Readiness 실패) 손님을 받지 않는 것과 같습니다.
실무에서 왜 중요한가
이 둘을 구분하지 않고 하나의 체크로 처리하면 문제가 생깁니다. 예를 들어 앱이 시작 직후 DB 커넥션을 맺는 데 10초가 걸리는 경우, Liveness만 있다면 그 사이 트래픽이 들어와 에러가 발생하거나, 반대로 정상 기동 중인데 재시작 루프에 빠질 수도 있습니다. Readiness를 별도로 두면 준비가 끝날 때까지 트래픽을 차단하면서도 프로세스 자체는 재시작하지 않아 불필요한 다운타임을 막을 수 있습니다.
결국 헬스체크는 단순한 ‘살아있음’ 확인을 넘어, 서비스의 안정성과 무중단 배포를 뒷받침하는 핵심 장치입니다. Liveness와 Readiness를 목적에 맞게 설계하는 것이 견고한 시스템 운영의 출발점입니다.