컨테이너 서비스 안정성을 위협하는 4가지 헬스 체크 오류와 해결법

컨테이너 오케스트레이션에서 자주 발생하는 헬스 체크 설정 오류를 알아보고, 서비스 불안정을 막을 수 있는 실용적인 해결책들을 초보자 눈높이에서 쉽게 설명해 드립니다.

안녕하세요! 열심히 개발한 서비스가 자꾸만 멈추거나, 원인 모를 재시작으로 개발자를 애태우는 경험, 혹시 해보셨나요? 분명 코드에는 문제가 없는데 말이죠. 이런 경우, 범인은 의외의 곳에 숨어있을 때가 많답니다. 바로 컨테이너 오케스트레이션 환경에서 설정하는 헬스 체크(Health Check)에 문제가 있는 경우인데요!

특히 쿠버네티스(Kubernetes) 같은 시스템을 사용하고 있다면, 이 헬스 체크 설정이 서비스의 안정성에 엄청난 영향을 미친다는 사실, 알고 계셨나요? 오늘은 초보 개발자분들이 자주 저지르는 헬스 체크 설정 오류들, 즉 안티패턴들을 알아보고, 어떻게 하면 우리 서비스를 더 튼튼하게 만들 수 있는지 쉽고 친근하게 이야기해볼게요.

📑 목차

• 헬스 체크, 우리 서비스의 '심장 박동'을 확인하는 방법
• 치명적인 헬스 체크 오류 1: 너무 짧은 타임아웃과 주기
• 문제 상황: 성급한 판단이 부르는 서비스 재시작
• 해결책: 컨테이너에게 충분한 시간을 주세요!
• 치명적인 헬스 체크 오류 2: Liveness와 Readiness의 혼동
• 문제 상황: 역할이 뒤바뀐 두 개의 프로브
• 해결책: 각자의 역할에 충실하게!
• 치명적인 헬스 체크 오류 3: 과도한 외부 의존성 확인
• 문제 상황: 하나의 문제로 서비스 전체가 흔들흔들
• 해결책: 헬스 체크는 가볍게, 의존성은 현명하게!
• 마무리하며: 헬스 체크, 똑똑하게 사용하면 든든한 아군!

Image by geraldoswald62 on Pixabay

헬스 체크, 우리 서비스의 '심장 박동'을 확인하는 방법

먼저, 헬스 체크가 뭔지부터 간단히 짚고 넘어갈까요? 컨테이너 오케스트레이션 시스템은 수많은 컨테이너들을 마치 오케스트라 지휘자처럼 관리하는데요. 이 컨테이너들이 잘 살아있는지, 맡은 역할을 제대로 수행할 준비가 되었는지 계속해서 확인해야 해요. 마치 의사가 환자의 심장 박동을 체크하듯이 말이죠.

이때 사용하는 것이 바로 헬스 체크예요. 크게 두 가지 종류가 있어요.

• Liveness Probe (라이브니스 프로브): "이 컨테이너가 정말 살아있나?"를 확인해요. 만약 컨테이너가 응답이 없거나, 심각한 오류로 죽어버렸다면, 오케스트레이션 시스템은 이 컨테이너를 '죽은' 것으로 판단하고 재시작시켜줍니다.
• Readiness Probe (레디니스 프로브): "이 컨테이너가 외부 트래픽을 받을 준비가 되었나?"를 확인해요. 컨테이너가 이제 막 시작해서 초기화 중이거나, 아직 데이터베이스에 연결이 안 된 상태라면, 시스템은 이 컨테이너로 트래픽을 보내지 않고 대기시켜줍니다. 준비가 완료되면 그때 트래픽을 보내주죠.

이 두 가지 헬스 체크가 제대로 작동해야 서비스가 안정적으로 운영될 수 있는데요. 문제는 이 설정을 잘못했을 때 발생합니다. 멀쩡한 컨테이너를 죽였다 살렸다 하거나, 트래픽을 제대로 처리하지 못하게 만들 수 있거든요. 그럼 어떤 오류들이 있는지 함께 살펴볼까요?

치명적인 헬스 체크 오류 1: 너무 짧은 타임아웃과 주기

첫 번째 흔한 실수는 헬스 체크의 '인내심'이 너무 부족한 경우예요. 컨테이너가 잠시 바쁘거나, 로딩 중인데 헬스 체크가 너무 급하게 '죽음'을 선고해버리는 거죠.

문제 상황: 성급한 판단이 부르는 서비스 재시작

여러분이 만든 웹 서비스 컨테이너가 시작하는 데 30초 정도 걸린다고 가정해볼게요. 이 컨테이너는 초기화 과정에서 설정 파일을 읽고, 필요한 데이터를 로딩하느라 시간이 좀 걸릴 수 있거든요. 그런데 헬스 체크를 5초마다 확인하고, 5초 안에 응답이 없으면 바로 실패로 간주하도록 설정했다고 해봅시다.

# 잘못된 설정 예시
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5 # 컨테이너 시작 후 5초 뒤부터 체크
  periodSeconds: 5     # 5초마다 체크
  timeoutSeconds: 5    # 응답 없으면 5초 뒤 타임아웃
  failureThreshold: 1  # 1번 실패하면 바로 재시작

이렇게 설정하면 어떻게 될까요? 컨테이너가 뜨기도 전에 헬스 체크가 계속 실패하고, 결국 오케스트레이션 시스템은 "얘 죽었네!"라고 판단해서 무한 재시작의 굴레에 빠지게 됩니다. 사용자는 계속 서비스 접속이 안 되거나, 느려지는 현상을 겪게 되겠죠.

해결책: 컨테이너에게 충분한 시간을 주세요!

이런 문제는 헬스 체크 설정에 충분한 여유 시간을 주는 것으로 해결할 수 있어요. 컨테이너가 안정적으로 시작하고, 잠시 느려지는 상황에도 유연하게 대처할 수 있도록 말이죠.

• initialDelaySeconds (초기 지연 시간): 컨테이너가 시작된 직후 바로 헬스 체크를 시작하지 않고, 어느 정도 시간이 지난 후에 시작하도록 설정합니다. 컨테이너가 완전히 준비될 시간을 벌어주는 거죠.
• periodSeconds (체크 주기): 헬스 체크를 너무 자주 하지 않도록 주기를 늘려줍니다. 예를 들어, 5초마다 체크하는 대신 10초나 15초마다 체크하도록요.
• timeoutSeconds (응답 대기 시간): 컨테이너가 응답할 때까지 기다려주는 시간을 늘려줍니다. 잠깐 느려진 상황에도 '죽음'으로 판단하지 않도록요.
• failureThreshold (실패 임계값): 한두 번 실패했다고 바로 재시작하지 않고, 몇 번 연속으로 실패했을 때 비로소 '죽음'으로 판단하도록 설정합니다. 예를 들어, 3번 연속 실패했을 때 재시작하도록 하는 거죠.

아래 표를 통해 잘못된 설정과 개선된 설정을 비교해볼게요.

설정 항목	잘못된 설정 (예시)	개선된 설정 (예시)	설명
initialDelaySeconds	5초	30초	컨테이너가 완전히 뜨는 시간을 고려하여 설정
periodSeconds	5초	10~15초	체크 주기를 늘려 시스템 부하 감소 및 일시적 지연 허용
timeoutSeconds	1초	3~5초	응답 대기 시간을 늘려 일시적인 네트워크 지연 등 대응
failureThreshold	1	3	연속 실패 횟수를 늘려 오작동으로 인한 불필요한 재시작 방지

이렇게 설정을 조정하면, 컨테이너가 좀 더 여유롭게 작업을 처리할 수 있고, 서비스가 불필요하게 재시작되는 일을 크게 줄일 수 있답니다.

Image by HeungSoon on Pixabay

치명적인 헬스 체크 오류 2: Liveness와 Readiness의 혼동

두 번째 실수는 Liveness Probe와 Readiness Probe의 역할을 혼동해서 사용하는 경우예요. 각자의 역할이 명확한데, 이를 섞어 쓰면 문제가 발생하죠.

문제 상황: 역할이 뒤바뀐 두 개의 프로브

어떤 개발자분들은 Liveness Probe에 데이터베이스 연결 확인이나 외부 API 호출 같은 복잡하고 시간이 오래 걸리는 로직을 넣곤 해요. 하지만 Liveness Probe는 컨테이너가 '살아있는지'만 확인하는 아주 기본적인 체크를 해야 하거든요.

만약 Liveness Probe가 외부 DB 연결을 확인하는데, DB 서버가 잠깐 문제가 생겼다고 가정해볼게요. 그러면 Liveness Probe는 계속 실패할 것이고, 시스템은 "컨테이너가 죽었다!"라고 판단해서 컨테이너를 재시작시킬 거예요. 하지만 컨테이너 자체는 아무 문제가 없고, 단지 DB 서버 문제일 뿐인데 말이죠. 이런 불필요한 재시작은 서비스 불안정으로 이어집니다.

반대로 Readiness Probe를 너무 단순하게, 예를 들어 항상 HTTP 200 OK만 반환하도록 설정하는 경우도 있어요. 컨테이너가 아직 초기화 중이거나, DB 연결이 안 된 상태인데도 "나 준비 완료!"라고 외치는 꼴이 됩니다. 그러면 트래픽이 이 준비 안 된 컨테이너로 몰려들고, 결국 사용자들은 오류를 경험하게 되겠죠.

해결책: 각자의 역할에 충실하게!

Liveness Probe와 Readiness Probe는 각자의 명확한 역할이 있어요. 이 역할을 지켜주는 것이 중요합니다.

Liveness Probe: '살아있음'만 확인하기

Liveness Probe는 컨테이너가 '살아있는지'만 확인해야 해요. 즉, 컨테이너 내부의 프로세스가 멈추지는 않았는지, 심각한 데드락 상태는 아닌지 등 컨테이너 자체의 건강 상태를 확인해야 합니다. 아주 가볍고 빠르게 응답할 수 있는 엔드포인트를 사용하는 것이 좋아요.

• 예시: 간단한 HTTP 200 OK 응답, 프로세스가 실행 중인지 확인 등.
• 피해야 할 것: 외부 데이터베이스 연결, 외부 API 호출 등 다른 서비스의 상태에 의존하는 체크.

# 올바른 Liveness Probe 예시 (간단한 HTTP 체크)
livenessProbe:
  httpGet:
    path: /healthz # 컨테이너 자체의 건강만 확인하는 가벼운 엔드포인트
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 3

Readiness Probe: '준비 완료'를 확인하고 트래픽 받기

Readiness Probe는 컨테이너가 외부 트래픽을 받을 준비가 되었는지를 확인해야 합니다. 여기에는 필요한 경우 외부 의존성(예: 데이터베이스 연결)이 잘 되어있는지도 포함될 수 있어요. 이 프로브가 실패하면, 시스템은 해당 컨테이너로 트래픽을 보내지 않고 대기시킵니다.

• 예시: 데이터베이스 연결 확인, 캐시 초기화 완료 여부, 필요한 외부 API 연결 확인 등.
• 중요: 이 프로브가 실패하면 트래픽이 가지 않으므로, 복구될 가능성이 있는 일시적인 문제라면 재시작보다는 기다리는 것이 좋습니다.

# 올바른 Readiness Probe 예시 (DB 연결 확인 등)
readinessProbe:
  httpGet:
    path: /ready # DB 연결 등 서비스가 트래픽을 받을 준비가 되었는지 확인
    port: 8080
  initialDelaySeconds: 20 # Liveness보다 좀 더 길게 설정할 수도 있어요
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

이렇게 Liveness와 Readiness의 역할을 명확히 구분하면, 서비스는 불필요하게 재시작되지 않고, 사용자들은 항상 준비된 컨테이너로부터 응답을 받을 수 있게 됩니다.

Image by Myriams-Fotos on Pixabay

치명적인 헬스 체크 오류 3: 과도한 외부 의존성 확인

세 번째 실수는 헬스 체크가 너무 많은 외부 의존성을 확인하려고 하는 경우예요. 특히 Liveness Probe에서 이런 실수를 많이 저지르곤 합니다.

문제 상황: 하나의 문제로 서비스 전체가 흔들흔들

여러분이 만든 서비스가 데이터베이스(DB)와 캐시 서버, 그리고 몇몇 외부 API를 사용한다고 가정해볼게요. 그런데 Liveness Probe가 이 모든 외부 시스템의 연결 상태를 확인하도록 설정했어요.

만약 데이터베이스 서버가 잠깐 문제가 생겨서 응답이 느려지거나 끊겼다고 생각해봅시다. 그러면 여러분 서비스의 Liveness Probe는 실패할 것이고, 시스템은 "컨테이너가 죽었다!"라고 판단해서 재시작을 명령합니다. 이 컨테이너가 재시작되는 동안, 다른 요청들은 이 컨테이너로 갈 수 없게 되고, 결국 서비스에 장애가 발생하겠죠. 심지어 DB가 복구되더라도, 이미 재시작된 컨테이너는 다시 초기화 과정을 거쳐야 하니, 서비스 복구 시간은 더 길어질 수 있어요.

이것은 마치 건물의 한 전기 콘센트가 고장 났다고 해서 건물 전체의 전원을 내려버리는 것과 같아요. 너무 과도한 조치죠.

해결책: 헬스 체크는 가볍게, 의존성은 현명하게!

헬스 체크는 최대한 가볍고, 자신(컨테이너)의 상태에만 집중해야 합니다. 외부 의존성 문제는 다른 방식으로 처리하는 것이 좋아요.

의존성 없는 Liveness Probe 설계

Liveness Probe는 컨테이너 자체가 비정상 상태(예: 메모리 누수로 인한 응답 불가, 데드락)가 되었을 때만 재시작하도록 유도해야 합니다. 즉, 컨테이너 내부의 아주 기본적인 기능만 확인하는 것이 좋습니다.

• 예시: 간단한 HTTP 200 응답 엔드포인트. 이 엔드포인트는 외부 의존성 없이, 그저 웹 서버 프로세스가 살아있고 기본적인 요청을 처리할 수 있는지만 확인해야 해요.
• 핵심: "내가 살아있고, 기본적인 숨은 쉬고 있는가?"만 묻는 거죠.

Readiness Probe에서의 현명한 의존성 관리

Readiness Probe에서는 필요한 경우 외부 의존성을 확인할 수 있습니다. 하지만 이 역시 신중해야 해요.

• 핵심 의존성만 확인: 서비스가 동작하는 데 필수적인 외부 의존성(예: 핵심 데이터베이스)만 확인하는 것이 좋습니다. 모든 외부 시스템을 다 확인할 필요는 없어요.
• 유연한 대처: 만약 Readiness Probe가 실패했다면, 오케스트레이션 시스템은 해당 컨테이너로 트래픽을 보내지 않습니다. 이 컨테이너가 복구될 때까지 기다리거나, 다른 건강한 컨테이너로 트래픽을 우회시키는 거죠. 이것이 Liveness Probe가 재시작시키는 것보다 훨씬 안전하고 유연한 방법입니다.

데이터베이스 연결이 잠깐 끊어졌다고 내 웹 서버를 죽여야 할까요? 아니면 DB가 복구될 때까지 기다려야 할까요? 대부분의 경우 후자가 더 나은 선택이겠죠. 이렇게 헬스 체크의 역할을 명확히 하고, 외부 의존성 체크는 최소화하여 현명하게 사용하면 서비스의 안정성을 크게 높일 수 있습니다.

마무리하며: 헬스 체크, 똑똑하게 사용하면 든든한 아군!

오늘은 컨테이너 오케스트레이션 환경에서 헬스 체크를 잘못 설정했을 때 발생할 수 있는 흔한 문제점들과 그 해결책들을 알아보았어요. 요약하자면, 헬스 체크는 우리 서비스를 지키는 중요한 방어막이지만, 잘못 사용하면 오히려 서비스의 안정성을 해칠 수 있는 '양날의 검'과 같다는 거죠.

핵심은 이 세 가지를 기억하는 거예요.

1. 충분한 시간 주기: 컨테이너의 시작 시간과 일시적인 부하를 고려하여 initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold를 넉넉하게 설정해주세요.
2. Liveness와 Readiness 구분: Liveness Probe는 '살아있음'만, Readiness Probe는 '트래픽 받을 준비 완료'를 확인하도록 각자의 역할에 충실하게 설정해야 합니다.
3. 외부 의존성 확인은 신중하게: Liveness Probe에서는 가급적 외부 의존성을 확인하지 않고, Readiness Probe에서도 꼭 필요한 핵심 의존성만 최소한으로 확인하는 것이 좋습니다.

이 기본적인 원칙들을 잘 지킨다면, 여러분의 서비스는 훨씬 더 튼튼하고 안정적으로 운영될 수 있을 거예요. 처음에는 어렵게 느껴질 수 있지만, 몇 번 적용해보면 금방 익숙해질 거랍니다!

혹시 여러분은 헬스 체크와 관련해서 어떤 실수를 해보셨거나, 자신만의 꿀팁이 있으신가요? 댓글로 자유롭게 공유해주세요! 여러분의 경험이 다른 분들에게 큰 도움이 될 거예요!

📌 함께 읽으면 좋은 글

• [클라우드 인프라] 쿠버네티스 영속 스토리지: StatefulSet과 CSI, 데이터베이스 및 메시지 큐 배포 모범 사례
• [클라우드 인프라] AWS 서비스 접근 보안 강화: PrivateLink vs VPC 엔드포인트, 현명한 도입 전략
• [개발 도구] 성능 프로파일링, 개발자가 흔히 저지르는 5가지 치명적인 실수와 해결책

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.