헬스체크를 개념 수준이 아니라 운영 신호로 다룰 수 있는지 본다. liveness/readiness 분리, 외부 의존성 포함 여부, 실패 임계치 결정 같은 운영 판단까지 짚는 사람과, 그저 "서버 살아 있나 확인하는 것" 수준에 머무는 사람을 가른다.
헬스체크는 인스턴스가 지금 트래픽을 받아도 되는지 주기적으로 판별하는 신호다. 보통 liveness(프로세스 생존), readiness(요청 처리 준비), startup(초기 기동 완료) 세 종류로 나눠서 각각 다른 동작과 연결한다. liveness가 깨지면 인스턴스를 재시작하고, readiness가 깨지면 트래픽만 끊는다. 핵심은 "살아 있음"이 아니라 "서비스 가능 상태"를 운영 정책과 맞춰 정의하는 일이다.
외부 API 장애로 readiness가 동시에 떨어져 더 큰 장애로 번진 경험이 있다면 의존성 포함 범위 결정 단서로 연결할 수 있다
롤링 배포 중 503이 새어 나갔던 경험을 startup probe·readiness 전파 지연과 엮어 풀 수 있다
헬스체크 임계치를 조정해 오탐 격리를 줄였던 경험은 SLO와 임계치 결정 사례로 가져갈 수 있다
Actuator·k8s probe로 헬스체크 엔드포인트를 직접 설계한 경험이 있다면 liveness/readiness 분리 기준을 자기 언어로 말할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.