Kubernetes Probe로 상태 진단 완벽 가이드

쿠버네티스에서 파드의 건강 상태를 자동으로 진단하고 관리하는 Probe의 모든 것을 다룹니다. Liveness, Readiness, Startup Probe의 차이점과 실무 활용법을 초급자도 이해하기 쉽게 설명합니다.

---

목차

1. Probe의_필요성
2. Liveness_Probe
3. Readiness_Probe
4. Startup_Probe
5. HTTP_TCP_Exec_프로브_타입
6. 프로브_튜닝_베스트_프랙티스

---

1. Probe의 필요성

어느 날 김개발 씨가 운영 중인 서비스에서 이상한 일이 벌어졌습니다. 분명히 파드는 Running 상태인데, 사용자들은 서비스에 접속할 수 없다고 불만을 토로합니다.

어떻게 된 일일까요?

Probe는 쿠버네티스가 컨테이너의 건강 상태를 주기적으로 확인하는 진단 도구입니다. 마치 병원에서 정기 검진을 받는 것처럼, 컨테이너도 지속적인 상태 점검이 필요합니다.

Probe를 제대로 설정하면 장애 상황을 자동으로 감지하고 복구할 수 있습니다.

다음 코드를 살펴봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: my-app:1.0
    # Probe 없이 실행되는 기본 파드
    # 컨테이너가 죽어도 쿠버네티스는 모릅니다
    ports:
    - containerPort: 8080

김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 쿠버네티스를 도입했는데, 오늘 새벽에 긴급 호출을 받았습니다.

서비스가 먹통이라는 것이었습니다. 급하게 대시보드를 확인해보니 모든 파드가 Running 상태로 표시되어 있었습니다.

그런데 왜 서비스가 안 되는 걸까요? 김개발 씨는 혼란에 빠졌습니다.

선배 개발자 박시니어 씨가 다가와 상황을 살펴봅니다. "아, Probe 설정을 안 했군요.

컨테이너 안의 애플리케이션이 죽었는데 쿠버네티스가 모르는 거예요." 그렇다면 Probe란 정확히 무엇일까요? 쉽게 비유하자면, Probe는 마치 회사의 야간 경비원과 같습니다.

경비원은 정해진 시간마다 건물 곳곳을 순찰하며 이상이 없는지 확인합니다. 문이 열려 있거나 불이 꺼지지 않았다면 즉시 조치를 취합니다.

Probe도 마찬가지로 컨테이너를 주기적으로 점검하고, 문제가 발견되면 적절한 조치를 취합니다. Probe가 없던 시절에는 어땠을까요?

개발자들은 별도의 모니터링 시스템을 구축해야 했습니다. 서버가 죽었는지 확인하려면 직접 접속해보거나, 외부 헬스체크 도구를 사용해야 했습니다.

더 큰 문제는 장애를 감지해도 수동으로 재시작해야 했다는 점입니다. 바로 이런 문제를 해결하기 위해 쿠버네티스는 세 가지 Probe를 제공합니다.

Liveness Probe는 컨테이너가 살아있는지 확인합니다. 실패하면 컨테이너를 재시작합니다.

Readiness Probe는 트래픽을 받을 준비가 되었는지 확인합니다. 실패하면 서비스에서 제외합니다.

Startup Probe는 애플리케이션이 시작되었는지 확인합니다. 시작이 완료될 때까지 다른 Probe를 비활성화합니다.

위의 코드를 살펴보면, Probe가 전혀 설정되지 않은 기본 파드 정의를 볼 수 있습니다. 이 상태에서는 컨테이너 프로세스만 살아있으면 쿠버네티스는 정상이라고 판단합니다.

내부 애플리케이션이 데드락에 빠지거나 메모리 부족으로 응답하지 못해도 알 수 없습니다. 실제 현업에서 Probe는 필수입니다.

예를 들어 쇼핑몰 서비스의 결제 시스템을 운영한다고 가정해봅시다. 결제 서버가 응답하지 않으면 매출에 직접적인 타격이 옵니다.

Probe를 설정해두면 장애 상황에서 자동으로 복구되어 다운타임을 최소화할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 파드는 Running인데 서비스가 안 됐군요!" 이제 Probe를 하나씩 배워볼 차례입니다.

실전 팁

💡 - 모든 프로덕션 파드에는 반드시 Probe를 설정하세요

• Probe 실패 시 어떤 동작이 일어나는지 명확히 이해하고 설정하세요

---

2. Liveness Probe

김개발 씨가 배포한 서비스에서 간헐적으로 응답이 멈추는 현상이 발생했습니다. 로그를 확인해보니 애플리케이션이 데드락 상태에 빠진 것이었습니다.

컨테이너는 살아있지만 아무 일도 하지 못하는 상황, 어떻게 해결할 수 있을까요?

Liveness Probe는 컨테이너가 정상적으로 동작하는지 확인하는 생존 검사입니다. 마치 심장 박동을 확인하는 것처럼, 애플리케이션이 살아서 제대로 응답하는지 주기적으로 점검합니다.

검사에 실패하면 쿠버네티스가 컨테이너를 자동으로 재시작합니다.

다음 코드를 살펴봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: my-app:1.0
    # Liveness Probe 설정
    livenessProbe:
      httpGet:
        path: /health      # 헬스체크 엔드포인트
        port: 8080
      initialDelaySeconds: 15  # 시작 후 15초 대기
      periodSeconds: 10        # 10초마다 검사
      failureThreshold: 3      # 3번 실패시 재시작

김개발 씨는 며칠 전 배포한 서비스에서 이상한 패턴을 발견했습니다. 서비스가 잘 돌아가다가 갑자기 응답이 멈춥니다.

그리고 아무리 기다려도 복구되지 않습니다. 수동으로 파드를 재시작하면 다시 정상화되었습니다.

박시니어 씨가 코드를 살펴보더니 원인을 찾았습니다. "여기 동시성 처리 부분에서 데드락이 발생할 수 있어요.

근데 더 중요한 건, Liveness Probe를 설정했어야 해요." 그렇다면 Liveness Probe란 정확히 무엇일까요? 쉽게 비유하자면, Liveness Probe는 마치 병원의 생체 모니터와 같습니다.

환자의 심장 박동을 지속적으로 확인하다가, 비정상적인 상태가 감지되면 즉시 의료진에게 알립니다. Liveness Probe도 마찬가지로 애플리케이션의 심장 박동을 확인하고, 멈추면 재시작이라는 응급 조치를 취합니다.

Liveness Probe가 없으면 어떤 일이 벌어질까요? 애플리케이션이 데드락에 빠지거나 무한 루프에 걸려도 쿠버네티스는 알지 못합니다.

컨테이너 프로세스 자체는 살아있기 때문입니다. 사용자 입장에서는 서비스가 완전히 멈춘 것처럼 보이지만, 시스템은 모든 것이 정상이라고 판단합니다.

Liveness Probe를 설정하면 이 문제가 해결됩니다. 위의 코드에서 initialDelaySeconds는 컨테이너 시작 후 첫 검사까지 대기하는 시간입니다.

애플리케이션이 완전히 초기화되기 전에 검사하면 실패할 수 있으므로, 적절한 대기 시간을 설정해야 합니다. periodSeconds는 검사 주기입니다.

10초로 설정하면 10초마다 헬스체크 엔드포인트를 호출합니다. 너무 짧으면 불필요한 부하가 생기고, 너무 길면 장애 감지가 늦어집니다.

failureThreshold는 재시작 전 허용할 실패 횟수입니다. 네트워크 일시적 문제로 한두 번 실패할 수 있으므로, 보통 3회 정도로 설정합니다.

3번 연속 실패하면 쿠버네티스가 컨테이너를 재시작합니다. 실무에서 주의할 점이 있습니다.

헬스체크 엔드포인트는 가볍게 유지해야 합니다. 데이터베이스 조회나 외부 API 호출을 포함하면 안 됩니다.

외부 의존성 문제로 헬스체크가 실패하면 정상적인 컨테이너가 불필요하게 재시작될 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Liveness Probe를 설정한 후, 데드락이 발생해도 쿠버네티스가 자동으로 컨테이너를 재시작합니다. 물론 근본적인 버그는 수정해야 하지만, 적어도 서비스가 완전히 멈추는 상황은 방지할 수 있게 되었습니다.

실전 팁

💡 - 헬스체크 엔드포인트는 외부 의존성 없이 가볍게 구현하세요

• initialDelaySeconds는 애플리케이션 시작 시간보다 길게 설정하세요
• 너무 공격적인 설정은 불필요한 재시작을 유발할 수 있습니다

---

3. Readiness Probe

김개발 씨가 새 버전을 배포했는데, 사용자들이 간헐적으로 에러 페이지를 보게 되었습니다. 새 파드가 시작되자마자 트래픽을 받았는데, 아직 데이터베이스 연결이 완료되지 않은 상태였습니다.

어떻게 하면 준비된 파드에만 트래픽을 보낼 수 있을까요?

Readiness Probe는 컨테이너가 트래픽을 받을 준비가 되었는지 확인하는 검사입니다. 마치 식당이 오픈 준비를 마쳐야 손님을 받는 것처럼, 애플리케이션도 완전히 준비되어야 요청을 처리할 수 있습니다.

검사에 실패하면 서비스 엔드포인트에서 해당 파드를 제외합니다.

다음 코드를 살펴봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: my-app:1.0
    # Readiness Probe 설정
    readinessProbe:
      httpGet:
        path: /ready       # 준비 상태 확인 엔드포인트
        port: 8080
      initialDelaySeconds: 5   # 시작 후 5초 대기
      periodSeconds: 5         # 5초마다 검사
      successThreshold: 1      # 1번 성공시 준비 완료
      failureThreshold: 3      # 3번 실패시 트래픽 제외

김개발 씨의 회사에서는 무중단 배포를 하고 있습니다. 새 버전을 배포하면 새 파드가 생성되고, 기존 파드는 종료됩니다.

그런데 문제가 있었습니다. 새 파드가 시작되자마자 트래픽이 들어왔는데, 아직 애플리케이션이 준비되지 않은 상태였습니다.

박시니어 씨가 설명했습니다. "Liveness Probe만 설정하면 안 돼요.

Readiness Probe도 필요해요. 둘은 목적이 달라요." 그렇다면 Readiness Probe란 정확히 무엇일까요?

쉽게 비유하자면, Readiness Probe는 마치 식당의 오픈 사인과 같습니다. 요리사가 출근하고 재료 준비가 끝나야 Open 사인을 켭니다.

아직 준비 중이면 Closed 상태를 유지합니다. Readiness Probe도 마찬가지로 애플리케이션이 완전히 준비되어야 트래픽을 받기 시작합니다.

Liveness Probe와 Readiness Probe의 차이는 무엇일까요? Liveness Probe가 실패하면 컨테이너가 재시작됩니다.

반면 Readiness Probe가 실패하면 서비스에서 제외만 됩니다. 컨테이너는 계속 실행되면서 준비가 완료되기를 기다립니다.

이 차이가 매우 중요합니다. 예를 들어 데이터베이스 연결이 일시적으로 끊겼다고 가정해봅시다.

Liveness Probe에 DB 연결 확인을 넣으면 컨테이너가 재시작됩니다. 하지만 재시작해도 DB가 복구되지 않으면 또 재시작합니다.

무한 재시작 루프에 빠질 수 있습니다. 반면 Readiness Probe에 DB 연결 확인을 넣으면 어떻게 될까요?

트래픽에서만 제외되고 컨테이너는 계속 실행됩니다. DB가 복구되면 자동으로 다시 트래픽을 받기 시작합니다.

위의 코드에서 successThreshold는 준비 완료로 판단하는 연속 성공 횟수입니다. 보통 1로 설정합니다.

한 번 성공하면 바로 트래픽을 받기 시작합니다. 실무에서 Readiness Probe의 /ready 엔드포인트는 /health보다 더 많은 것을 확인해야 합니다.

데이터베이스 연결, 캐시 연결, 필수 설정 로드 여부 등을 확인합니다. 이 모든 것이 준비되어야 진정한 의미에서 서비스할 준비가 된 것입니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. Readiness Probe를 설정한 후에는 새 파드가 완전히 준비될 때까지 트래픽을 받지 않습니다.

사용자들은 더 이상 에러 페이지를 보지 않게 되었습니다.

실전 팁

💡 - Readiness Probe에는 외부 의존성 확인을 포함해도 됩니다

• Liveness Probe보다 더 엄격한 조건을 설정하세요
• 트래픽 급증 시 일시적으로 준비 상태가 아닐 수 있음을 고려하세요

---

4. Startup Probe

김개발 씨가 레거시 Java 애플리케이션을 쿠버네티스로 이전했습니다. 그런데 이 애플리케이션은 시작하는 데 2분이나 걸립니다.

Liveness Probe가 계속 실패해서 파드가 무한 재시작됩니다. 시작이 오래 걸리는 애플리케이션은 어떻게 처리해야 할까요?

Startup Probe는 애플리케이션이 시작되었는지 확인하는 검사입니다. 마치 컴퓨터 부팅이 완료될 때까지 기다리는 것처럼, 시작이 오래 걸리는 애플리케이션을 위한 특별한 Probe입니다.

Startup Probe가 성공할 때까지 다른 Probe들은 비활성화됩니다.

다음 코드를 살펴봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: legacy-app
spec:
  containers:
  - name: app
    image: legacy-java-app:1.0
    # Startup Probe - 시작 완료 확인
    startupProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 10    # 10초 후 시작
      periodSeconds: 10          # 10초마다 검사
      failureThreshold: 30       # 최대 300초(5분) 대기
    # Liveness Probe - Startup 성공 후 활성화
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      periodSeconds: 10

김개발 씨의 회사에는 오래된 Java 애플리케이션이 있었습니다. Spring Boot로 만들어졌는데, 온갖 라이브러리와 설정을 로드하느라 시작하는 데 2분 이상 걸렸습니다.

모던한 마이크로서비스라면 몇 초면 시작되겠지만, 레거시 모놀리식 애플리케이션은 그렇지 않았습니다. 쿠버네티스로 이전했더니 문제가 생겼습니다.

Liveness Probe의 initialDelaySeconds를 30초로 설정했는데, 애플리케이션은 아직 시작 중이었습니다. 헬스체크가 실패하고, 파드가 재시작되고, 또 시작 중에 실패하고...

무한 루프였습니다. "initialDelaySeconds를 3분으로 늘리면 되지 않나요?" 김개발 씨가 물었습니다.

박시니어 씨가 고개를 저었습니다. "그러면 정상 운영 중에 문제가 생겨도 3분 동안 감지를 못 해요.

Startup Probe를 써야 해요." 그렇다면 Startup Probe란 정확히 무엇일까요? 쉽게 비유하자면, Startup Probe는 마치 컴퓨터의 부팅 화면과 같습니다.

윈도우가 부팅되는 동안에는 프로그램을 실행할 수 없습니다. 부팅이 완료되어야 바탕화면이 나타나고, 그때부터 정상적인 사용이 가능합니다.

Startup Probe도 마찬가지로 애플리케이션 부팅이 완료될 때까지 기다립니다. Startup Probe의 핵심은 다른 Probe들을 비활성화한다는 점입니다.

Startup Probe가 성공하기 전까지 Liveness Probe와 Readiness Probe는 실행되지 않습니다. 이렇게 하면 시작이 오래 걸려도 불필요한 재시작이 발생하지 않습니다.

Startup Probe가 성공하면 그때부터 다른 Probe들이 활성화됩니다. 위의 코드에서 failureThreshold가 30이고 periodSeconds가 10이므로, 최대 300초(5분) 동안 시작을 기다립니다.

5분 안에 시작되지 않으면 그때 비로소 실패로 간주하고 재시작합니다. Startup Probe가 성공한 후에는 Liveness Probe가 활성화됩니다.

이때는 initialDelaySeconds가 없어도 됩니다. 왜냐하면 이미 애플리케이션이 시작되었다는 것이 확인되었기 때문입니다.

실무에서 Startup Probe는 레거시 애플리케이션뿐만 아니라, 대용량 데이터를 초기 로딩하는 서비스에도 유용합니다. 캐시 워밍업이나 ML 모델 로딩 같은 작업이 오래 걸릴 때 활용할 수 있습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. Startup Probe를 설정한 후, 레거시 애플리케이션이 안정적으로 시작됩니다.

시작이 완료되면 Liveness Probe가 활성화되어 정상적인 상태 감시가 이루어집니다.

실전 팁

💡 - 시작 시간이 일정하지 않다면 failureThreshold를 넉넉하게 설정하세요

• Startup Probe 성공 후 Liveness Probe가 바로 활성화되므로 설정에 주의하세요
• 모든 애플리케이션에 Startup Probe가 필요한 것은 아닙니다

---

5. HTTP TCP Exec 프로브 타입

김개발 씨가 새로운 서비스를 배포하려고 합니다. 그런데 이 서비스는 HTTP API가 아니라 TCP 소켓으로 통신합니다.

HTTP 헬스체크를 할 수 없는데, 어떻게 Probe를 설정해야 할까요?

쿠버네티스는 세 가지 프로브 타입을 제공합니다. HTTP GET 요청을 보내는 httpGet, TCP 연결을 시도하는 tcpSocket, 컨테이너 내부에서 명령을 실행하는 exec입니다.

서비스 특성에 맞는 타입을 선택해야 합니다.

다음 코드를 살펴봅시다.

# HTTP Probe - REST API 서비스용
livenessProbe:
  httpGet:
    path: /health
    port: 8080
    httpHeaders:
    - name: X-Custom-Header
      value: probe-check

# TCP Probe - 데이터베이스, 메시지 큐 등
livenessProbe:
  tcpSocket:
    port: 5432    # PostgreSQL 포트

# Exec Probe - 커스텀 스크립트 실행
livenessProbe:
  exec:
    command:
    - /bin/sh
    - -c
    - redis-cli ping | grep PONG

김개발 씨의 회사에서는 다양한 서비스가 운영되고 있습니다. REST API 서버도 있고, PostgreSQL 데이터베이스도 있고, Redis 캐시 서버도 있습니다.

각각의 특성이 다르기 때문에 헬스체크 방식도 달라야 합니다. 박시니어 씨가 설명을 시작했습니다.

"프로브 타입은 세 가지가 있어요. 서비스 특성에 맞게 선택하면 돼요." 첫 번째는 httpGet입니다.

이것은 가장 흔히 사용되는 타입입니다. 지정된 경로로 HTTP GET 요청을 보내고, 응답 코드가 200~399 사이면 성공으로 간주합니다.

REST API 서버, 웹 애플리케이션 등에 적합합니다. 필요하다면 커스텀 헤더를 추가할 수도 있습니다.

두 번째는 tcpSocket입니다. 이것은 지정된 포트로 TCP 연결을 시도합니다.

연결이 성공하면 성공으로 간주합니다. HTTP 프로토콜을 사용하지 않는 서비스에 적합합니다.

데이터베이스, 메시지 큐, 캐시 서버 등이 대표적입니다. tcpSocket의 장점은 단순함입니다.

포트만 열려있으면 성공입니다. 하지만 단점도 있습니다.

포트가 열려있다고 해서 서비스가 정상인 것은 아닙니다. 프로세스는 살아있는데 내부적으로 문제가 있을 수 있습니다.

세 번째는 exec입니다. 이것은 컨테이너 내부에서 지정된 명령을 실행합니다.

종료 코드가 0이면 성공으로 간주합니다. 가장 유연한 방식입니다.

원하는 어떤 검사든 스크립트로 작성할 수 있습니다. 위의 코드에서 Redis 예시를 보면, redis-cli ping 명령을 실행하고 결과에 PONG이 포함되어 있는지 확인합니다.

이렇게 하면 단순히 포트가 열려있는지가 아니라, Redis가 실제로 응답하는지 확인할 수 있습니다. 하지만 exec 타입은 주의가 필요합니다.

명령 실행에 리소스가 소모됩니다. 복잡한 스크립트는 CPU와 메모리를 사용합니다.

또한 명령이 오래 걸리면 타임아웃될 수 있습니다. 어떤 타입을 선택해야 할까요?

일반적인 가이드라인이 있습니다. HTTP API가 있다면 httpGet을 사용하세요.

가장 신뢰할 수 있고 많은 정보를 확인할 수 있습니다. HTTP가 없다면 tcpSocket을 사용하세요.

단순하고 가볍습니다. 특별한 검사 로직이 필요하다면 exec를 사용하세요.

유연하지만 리소스에 주의해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

TCP 소켓 서비스에는 tcpSocket 프로브를 설정했고, Redis에는 exec 프로브로 실제 ping 응답을 확인하도록 했습니다. 각 서비스의 특성에 맞는 헬스체크가 가능해졌습니다.

실전 팁

💡 - HTTP API가 있다면 httpGet을 우선적으로 사용하세요

• exec 프로브의 명령은 가볍고 빠르게 유지하세요
• tcpSocket은 연결 가능 여부만 확인하므로 한계가 있음을 인지하세요

---

6. 프로브 튜닝 베스트 프랙티스

김개발 씨가 Probe 설정을 마쳤습니다. 그런데 운영 중에 이상한 일이 벌어졌습니다.

트래픽이 몰릴 때마다 파드가 재시작됩니다. 분명히 서비스는 정상인데 Probe가 타임아웃된 것입니다.

Probe 설정을 어떻게 최적화해야 할까요?

Probe 튜닝은 안정적인 서비스 운영의 핵심입니다. 너무 민감하면 불필요한 재시작이 발생하고, 너무 느슨하면 장애 감지가 늦어집니다.

initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold 값을 서비스 특성에 맞게 조정해야 합니다.

다음 코드를 살펴봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: production-app
spec:
  containers:
  - name: app
    image: my-app:1.0
    # 운영 환경 최적화된 Probe 설정
    startupProbe:
      httpGet:
        path: /health
        port: 8080
      periodSeconds: 5
      failureThreshold: 60      # 최대 5분 대기
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      periodSeconds: 15         # 너무 자주 검사하지 않음
      timeoutSeconds: 5         # 5초 타임아웃
      failureThreshold: 3       # 3번 연속 실패시 재시작
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      periodSeconds: 5          # 트래픽 제어는 빠르게
      failureThreshold: 2       # 2번 실패시 트래픽 제외

김개발 씨는 Probe를 설정하고 뿌듯했습니다. 그런데 다음 날 블랙프라이데이 세일이 시작되었습니다.

트래픽이 평소의 10배로 늘어났습니다. 갑자기 알람이 울리기 시작했습니다.

파드들이 계속 재시작되고 있었습니다. 박시니어 씨가 원인을 분석했습니다.

"Probe 설정이 너무 공격적이에요. timeoutSeconds가 1초인데, 트래픽이 몰리니까 응답이 1초를 넘는 거예요." 그렇다면 Probe를 어떻게 튜닝해야 할까요?

첫 번째 원칙은 timeoutSeconds를 충분히 주는 것입니다. 기본값은 1초인데, 이것은 대부분의 경우 너무 짧습니다.

트래픽이 몰리거나 서버가 바쁠 때 헬스체크 응답도 느려질 수 있습니다. 최소 3~5초는 주는 것이 좋습니다.

두 번째 원칙은 periodSeconds를 적절히 설정하는 것입니다. 너무 자주 검사하면 서버에 부하가 됩니다.

특히 exec 타입은 매번 프로세스를 생성하므로 리소스가 소모됩니다. Liveness Probe는 10~30초 주기가 적당합니다.

Readiness Probe는 트래픽 제어 목적이므로 5~10초로 더 짧게 설정할 수 있습니다. 세 번째 원칙은 failureThreshold를 신중히 결정하는 것입니다.

이 값은 재시작까지의 총 시간을 결정합니다. periodSeconds * failureThreshold가 장애 감지 최대 시간입니다.

예를 들어 periodSeconds가 10이고 failureThreshold가 3이면, 최대 30초 후에 재시작됩니다. 네 번째 원칙은 헬스체크 엔드포인트를 가볍게 유지하는 것입니다.

/health 엔드포인트에서 데이터베이스 쿼리를 실행하거나 외부 API를 호출하면 안 됩니다. 서버가 바쁠 때 헬스체크도 느려져서 불필요한 재시작이 발생합니다.

메모리 내 상태만 확인하는 것이 이상적입니다. 다섯 번째 원칙은 Liveness와 Readiness를 구분하는 것입니다.

Liveness는 재시작 여부를 결정하므로 보수적으로 설정합니다. 정말로 죽었을 때만 재시작해야 합니다.

Readiness는 트래픽 제어이므로 더 민감하게 설정해도 됩니다. 일시적인 과부하 상황에서 트래픽을 줄이는 것은 좋은 전략입니다.

위의 코드에서 이런 원칙들이 적용되어 있습니다. Startup Probe는 최대 5분 동안 시작을 기다립니다.

Liveness Probe는 15초 주기로 여유롭게 검사하고, 5초 타임아웃을 줍니다. Readiness Probe는 5초 주기로 빠르게 검사하여 트래픽을 민첩하게 제어합니다.

실무에서 중요한 점이 하나 더 있습니다. Probe 설정은 모니터링과 함께 가야 합니다.

Probe 실패 횟수, 재시작 횟수를 모니터링하고, 비정상적으로 많다면 설정을 재검토해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Probe 설정을 튜닝한 후, 트래픽이 몰려도 불필요한 재시작이 발생하지 않습니다. 서비스는 안정적으로 운영되고, 진짜 장애 상황에서만 자동 복구가 이루어집니다.

실전 팁

💡 - timeoutSeconds는 최소 3초 이상으로 설정하세요

• 헬스체크 엔드포인트는 외부 의존성 없이 가볍게 구현하세요
• 프로덕션 배포 전에 부하 테스트로 Probe 설정을 검증하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!