Read Original
#DevOps

EKS 컨테이너 메모리 스파이크 추적기

EKS 컨테이너 메모리 스파이크 추적기
01

Summary

EKS 이관 후 나타난 500MB 메모리 스파이크, 범인은 Java가 아니라 '로그 압축'이었습니다

ZGC 교체와 힙 튜닝도 소용없던 미스터리한 메모리 스파이크를 페이지 캐시 분석으로 완벽히 해결한 실전 디버깅기

원인 불명의 EKS 컨테이너 메모리 폭증 현상을 집요하게 추적하여 리눅스 페이지 캐시의 파일 압축 매커니즘과 컨테이너 메모리 집계 지표 간의 상관관계를 완벽히 파헤친 기술 아티클입니다. 단순 리소스 증설이 아닌 합리적인 데이터 기반 추론과 다차원적 분석을 통해 문제를 본질적으로 해결하는 테크 엔지니어링의 정수를 보여줍니다.

  • 01합산 메트릭 그래프에 가려진 개별 파드 고유의 메모리 스파이크 규칙성을 분리해 낸 정밀 분석 기법
  • 02Java 힙 영역 바깥의 네이티브 메모리 및 GC 교체 검토를 통한 다양한 메모리 누수 가설 무죄 입증
  • 03리눅스 OS의 페이지 캐시가 컨테이너 cgroups 메모리 집계에 포함되면서 발생한 알림 메커니즘 규명
  • 04로그 파일 gzip 압축 정책 비활성화 및 로컬 보관 기한 최적화를 통한 디스크와 메모리의 최적 타협점 도출

RECOMMENDATION

EKS 등 컨테이너 환경으로 이관한 백엔드 서비스의 메모리 관리 및 원인 불명의 자원 경고 현상으로 고민하고 있는 백엔드 엔지니어 및 DevOps 인프라 담당자에게 최적의 실무 해결법을 제시합니다.

The Problem

EC2에서 EKS로 서버 인프라를 이관한 이후, 특정 파드의 컨테이너 메모리가 약 500MB씩 규칙적으로 급증하여 90% 알림 임계치를 초과하는 현상이 발생했습니다. 애플리케이션 내의 에러 로그나 OOM 장애는 발생하지 않았지만, 비정기적으로 울리는 알림이 시스템의 안정적인 운영을 위협했습니다.

The Solution

모니터링 그래프의 규칙성이 개별 파드가 아닌 전체 파드의 수치 합산에 따른 착시임을 규명하고, 각 파드에서 500MB 크기의 로그 파일이 롤오버되어 gzip 압축될 때 메모리 스파이크가 발생함을 파악했습니다. 컨테이너 메모리 계산 방식에 리눅스 페이지 캐시(Page Cache)가 포함되는 특성을 분석하여, 로컬 로그 파일 압축 옵션을 비활성화하고 보관 기한 단축(1일) 및 총량 상한(totalSizeCap) 정책을 적용했습니다.

The Result

로그 압축을 끈 이후 파일 백업 및 압축 시 발생하던 500MB의 메모리 스파이크 현상이 완전히 사라졌으며, 보관 기간 단축과 상한선 조정을 통해 디스크 사용량을 안정적으로 유지하는 성과를 거두었습니다.

Trade-off

로컬 로그 파일의 gzip 압축을 비활성화하면서 디스크 원본 파일의 크기가 늘어나는 트레이드오프가 존재하나, 중앙 수집기가 로그를 정상적으로 즉시 실어 나르는 상태이므로 로컬 보관 주기를 1일로 대폭 축소하여 디스크 공간 부족 리스크를 효과적으로 상쇄했습니다.

03

Key Concepts

Concept · 01

페이지 캐시 (Page Cache)

리눅스 커널이 디스크 I/O 성능 향상을 위해 파일 데이터를 메모리에 미리 로드하고 유지하는 영역으로, 파일 읽기/쓰기 작업 시 자동으로 생성되는 메모리 영역입니다.

  • Logback 라이브러리가 500MB 크기의 로그 파일을 압축하기 위해 파일을 읽어 들이면서 이 페이지 캐시 영역에 대량의 메모리가 순식간에 할당되었습니다.
Concept · 02

컨테이너 메모리 메트릭 (cgroups)

쿠버네티스 파드가 사용하는 컨테이너의 제한 메모리를 측정할 때, 순수 프로세스 메모리(RSS) 뿐만 아니라 운영체제 수준의 페이지 캐시 영역까지 포함하여 계산하는 지표 방식입니다.

  • Java JVM 내부의 메모리 사용량은 일정했지만, 리눅스 페이지 캐시로 인한 점유가 컨테이너 메모리 사용률 지표를 75% 이상으로 끌어올렸습니다.
Concept · 03

로그백 롤오버 정책 (Logback Rollover Policy)

실시간으로 생성되는 로그 파일이 특정 한도 크기나 시간 주기를 초과할 때, 이를 다른 파일명으로 보관 처리하고 파일 스토리지를 정리하는 백엔드 로깅 솔루션의 작동 주기입니다.

  • 원래 EC2 시절에는 OS 데몬의 logrotate가 처리하던 로그 백업 및 gzip 압축 태스크를 JVM 내부 Logback의 500MB 크기 기준 압축 설정으로 통합하게 되면서 현상이 발현되었습니다.