쿠버네티스에서 파드(Pod)가 OOMKilled 될 때마다 겪는 비효율적인 대응에 대한 질문

Ask a Question
, , ,
1

1. 질문 내용 (The Question)

쿠버네티스에서 파드(Pod)가 OOMKilled(메모리 초과로 인한 강제 종료)될 때마다 겪는 비효율적인 대응 방식에 대해 토로했습니다.

  • 현재 방식: 메트릭을 확인하고, 대충 새로운 리밋(Limit)을 추측하거나 2배로 늘린 뒤, 다시 문제가 생기지 않기를 기도함.
  • 핵심 질문: 이렇게 운영하는 것이 너무 주먹구구식 같은데, 매번 수동으로 수정하는 것 말고 실제로 프로덕션 환경에서 효율적으로 대처하는 좋은 방법이 있는가?

2. 주요 답변 및 해결책 (Top Answers & Solutions)

댓글에서는 크게 자동화 도구 활용, 애플리케이션 최적화, 운영 프로세스 개선의 세 가지 관점에서 조언이 쏟아졌습니다.

A. 도구 및 자동화 추천 (Tools & Automation)

가장 많은 추천을 받은 방법은 적절한 리소스 값을 찾아주는 도구를 사용하는 것입니다.

  • Goldilocks & VPA (Vertical Pod Autoscaler):
    • 가장 많이 언급된 솔루션입니다. VPA를 'Recommendation(추천) 모드’로 실행하여 한 달 정도 데이터를 수집한 뒤, 제안된 request/limit 값을 베이스라인으로 삼으라는 조언이 많았습니다. * Tortoise:
    • VPA와 HPA(Horizontal Pod Autoscaler)를 모두 활용해 리소스 최적화를 자동화해주는 도구로 추천되었습니다.
  • Continuous Profiling (지속적 프로파일링):
    • 단순히 리소스를 늘리는 대신, Grafana Alloy, Pyroscope, Parca 같은 도구를 사용해 메모리 사용량의 원인을 시각화(Flamegraph)하고 분석하라는 조언입니다. 어떤 코드가 메모리를 많이 쓰는지 파악할 수 있습니다. * KRR (Kubernetes Resource Recommender):
    • Robusta의 도구로, Prometheus 메트릭을 기반으로 파드의 적정 크기를 제안해 줍니다.

B. 근본 원인 해결: “앱을 고쳐라” (Fix the Application)

단순히 메모리를 늘려주는 것은 근본적인 해결책이 아니라는 지적도 많았습니다.

  • 메모리 누수(Memory Leak) 의심: 리밋을 계속 늘려도 OOM이 발생한다면 인프라 문제가 아니라 애플리케이션의 메모리 누수일 가능성이 큽니다.
  • 책임 소재: "인프라팀이 리소스를 늘려주기보다 개발팀이 코드를 고치게 해야 한다"는 강경한 의견들이 많은 공감을 얻었습니다.
  • 언어별 구체적 조언:
    • Go: API 호출 후 resp.Body.Close()를 호출하지 않아 누수가 발생하는 경우가 많음. GOMEMLIMIT 설정 확인 필요.
    • Node.js: 컨테이너 메모리 제한을 인식하지 못할 수 있으므로 힙(Heap) 사이즈를 명시적으로 설정해야 함.
    • Java: 구버전 JVM은 컨테이너 리소스를 인식 못 할 수 있음.

C. 프로세스 및 테스트 (Process & Testing)

  • 부하 테스트 (Load Testing): 배포 전 로컬이나 CI 환경에서 JMeter, k6 등으로 부하 테스트를 수행해 리소스 한계를 미리 파악해야 합니다.
  • 엄격한 PR 승인: 테스트 결과와 리소스 사용량을 리포트로 첨부해야 PR(Pull Request)을 승인해 주는 문화를 가진 회사의 사례가 공유되었습니다.

3. 주요 댓글 반응 및 토론 (Comments & Reactions)

기술적인 조언 외에도 개발자와 운영자 간의 갈등이나 냉소적인 유머가 섞인 반응들이 있었습니다.

  • “Node.js 혐오”: “Node 모듈들이 운다(cries in node modules)”, "백엔드에서 JS를 쓰는 게 문제다"라며 Node.js의 메모리 관리에 대한 불만이 다수 표출되었습니다.
  • 개발자 vs 운영자:
    • “개발자들은 가비지 컬렉션(GC)이 있으니 메모리 누수가 없다고 우긴다.”
    • “OOM은 좋은 것이다. 운영자 입장에서는 시스템 전체가 죽는 걸 막아주니까. 이제 개발자가 자기 똥(shit)을 치울 차례다.”
    • “개발자를 호출(Page)해라. 새벽에 깨우면 고친다.”
  • QoS 클래스 논쟁: Requests와 Limits를 동일하게 설정(Guaranteed QoS)하여 파드가 쫓겨나는(Eviction) 것을 방지하라는 조언과, 이에 대한 토론이 있었습니다.
  • 유머: “가장 좋은 방법? 그냥 2배로 늘리고 기도해라(Just double it and pray)”, “10분마다 파드를 재시작해라(농담 반 진담 반)” 같은 반응도 있었습니다.

요약

이 글의 결론은 **“무작정 메모리만 늘리지 말고(OOM Whac-A-Mole 하지 말고), VPA/Goldilocks 같은 도구로 적정값을 찾거나 프로파일링을 통해 앱의 메모리 누수를 고쳐라”**로 정리할 수 있습니다.

Bro분들의 생각은 어떠신지요?

[출처] Reddit - The heart of the internet

2 Likes
2

안녕하세요, 고생이 많으십니다. 저라면 B에 한 표를 던지겠습니다.

  • 먼저, 어떤 POD의, 어떤 컨테이너의, 어떤 앱이 얼마만큼의 양을 사용하는지 투명하게 볼 수 있도록 준비하고 (container_memory_working_set_bytes).
  • 특정 앱의 메모리 사용량이 계속 증가한다면, GOMEMLIMIT, XMX 설정 등을 확인하고 의도치 않게 사용량이 높다면 앱 내 코드나 설정에서 조치하는 것이 맞다고 생각합니다.
  • 물론, 의도한 처리량을 소화하기에 부족하다면 가용량을 늘려주는 것이 맞을 것 같습니다.

이 부분이 기본으로 선행되어야만, 나머지 사전/사후에 적용하면 좋을 법한 우아한 솔루션들이 조금 더 의미가 있을 것 같습니다.

도움이 되셨기를 바라며, 오늘도 좋은 하루 보내세요.:blush:

3 Likes