[K8s] 메모리 고갈로 인한 OOMKilled 테스팅

대규모 언어 모델을 포함한 AI 서빙 환경에서 가장 치명적인 위협은 CPU 부하가 아닌 메모리 고갈(OOM, Out Of Memory)이다. CPU 부하는 서비스의 지연을 초래하지만, 메모리 임계치 초과는 쿠버네티스 커널에 의한 컨테이너 즉시 사살로 이어지기 때문이다.

이번 실습에서는 의도적으로 메모리 부하를 일으켜 k8s의 Self-healing 메커니즘과 메모리 기반 HPA(Horizontal Pod Autoscaler)의 실제 동작 방식을 분석했다.

실험 환경 구축

• Infra: Minikube (Metrics Server 활성화)
• Monitoring: Prometheus & Grafana (w. Helm)
• App: Flask 기반의 'Mock-LLM' 서버 (요청 시마다 20MB씩 메모리 점유하는 로직 구현)

핵심 설정: Deployment & HPA

장애 상황을 정밀하게 관측하기 위해 메모리 임계치를 타이트하게 설정했다.

# Deployment 리소스 설정
resources:
  requests:
    memory: "100Mi"
  limits:
    memory: "300Mi" # 300MB 초과 시 즉시 종료(OOMKilled)

# HPA 설정 (v2)
metrics:
- type: Resource
  resource:
    name: memory
    target:
      type: Utilization
      averageUtilization: 60 # 메모리 사용량 60% 도달 시 스케일 아웃

장애 재현 및 관측

curl loop를 통해 부하 테스트를 진행해본 결과 급격한 메모리 점유가 유도했ㅇ르 때, 다음과 같은 시스템 변화가 포착되었다.

# kubectl get pods -w 관측 로그
mock-app-xxx   1/1   Running            1    (2s ago)   8m22s
mock-app-xxx   0/1   OOMKilled          1    (4m29s ago)   12m
mock-app-xxx   0/1   CrashLoopBackOff   1    (15s ago)     13m
mock-app-xxx   1/1   Running            2    (16s ago)     13m

재시작 후 연결 단절 문제

포드가 Running 상태로 복구되었음에도 불구, 로컬 터미널에서 connect 에러가 발생했다.

• 원인 분석: kubectl port-forward는 특정 프로세스와의 1:1 터널링이다. 프로세스가 OOM으로 종료되는 순간 이 터널은 파괴된다. 터미널에 출력된 Broken Pipe 에러가 이를 증명했습니다.
• 해결: 기존 포트 포워딩 세션을 종료하고 재성립함으로써 연결을 복구했습니다. 이는 인프라의 휘발성을 보여주는 전형적인 사례이다.

Engineering Insights

1. HPA와 OOM 사이의 골든 타임
   HPA가 메트릭을 수집하고 새 포드를 준비하는 속도보다 메모리가 차오르는 속도가 더 빠르면 오토스케일링이 작동하기 전에 서버가 먼저 죽는다는 것을 확인했습니다. 이를 방지하기 위해 실무에서는 Requests와 Limits 사이의 충분한 Buffer 설계가 필수적임을 알게되었다.
2. Running과 Ready의 엄격한 구분
   컨테이너가 다시 살아나도 내부 애플리케이션이 런타임을 준비하는 Warm-up 시간이 필요했다. 이를 위해 Readiness Probe를 설정하여, 서비스가 실제로 요청을 받을 준비가 되었을 때만 트래픽을 유입시키는 설계의 중요성을 이해했다.
3. Self-healing의 한계와 보완
   쿠버네티스가 포드를 살려내더라도 기존 네트워크 세션은 유실된다. 따라서 시스템 안정성을 위해서는 인프라의 복구뿐만 아니라, 클라이언트 레벨의 재시도 로직과 로드밸런서의 정밀한 헬스 체크가 병행되어야 함을 알게되었다.

결론

안정적인 인프라란 단순히 장애가 없는 상태가 아니라, 장애가 발생했을 때 시스템이 얼마나 예측 가능하게 반응하고 자동으로 복구되느냐에 달려 있다. 이번 실습을 통해 리소스 설계와 관측 가능성의 중요성을 다시 한번 확인할 수 있었습니다.