Memory Leak Detection
일반적인 메모리 사용량은 톱니 모양입니다. 올라가다가 가비지 컬렉션이 메모리를 해제하면 다시 올라가는 식으로 반복됩니다. 누수는 다릅니다. 매 주기의 최저점이 계속 올라갑니다. Memory Leak Detection은 이 바닥, 즉 컨테이너별 시간당 최솟값 메모리를 지켜보다가, 바닥이 상승 추세인 워크로드를 찾아냅니다. 그래서 워크로드가 프로덕션에서 OOMKill을 맞기 전에 재시작을 예약하거나 코드를 고칠 수 있습니다.
Wave Diagnosis 아래의 Memory Leaks 화면에는 서로 다른 두 질문에 답하는 탭이 있습니다.
- Memory Leak Detection: 어떤 워크로드가 얼마나 빠르게, 얼마나 많이 누수되고 있는가.
- Possible OOM Risk: 누수 여부와 상관없이, 지금 memory limit에 가깝게 실행 중인 워크로드가 무엇인가.
두 탭 모두 우측 상단의 날짜 범위 선택기(기본값 최근 며칠)와 클러스터 선택기로 범위가 정해집니다.
무엇을 누수로 보는가
상승하는 바닥이 신호입니다. 여기에 더해 Wave는 각 감지 결과를 두 가지 패턴 중 하나로 분류하고, 콘솔에 배지로 표시합니다: Steady Growth와 Trend Based Growth입니다. 감지 결과마다 baseline 메모리, recent 메모리, increase %(및 시간당 increase %), confidence 점수를 기록해서, 빠르고 신뢰도 높은 급증과 느린 노이즈를 구분할 수 있게 합니다.
감지 패턴
Steady Growth
편차가 거의 없이 느리고 완만하게 올라가는 패턴입니다. 메모리가 계속 올라가고 거의 다시 내려오지 않습니다. 오래 실행되는 서비스의 느린 누수를 가리킵니다.
- 흔한 원인: 닫히지 않는 커넥션 풀, 제거(eviction) 정책이 없는 무한 캐시, 계속 쌓이는 이벤트 리스너, 해제되지 않는 파일 핸들이나 소켓.
- 예시: 하루에 약 50MB씩 누수되는 웹 서비스는 며칠간 바닥이 꾸준히 상승한 뒤 Steady Growth로 감지됩니다.
Trend Based Growth
통계적 추세 적합(trend fit)이 높은 신뢰도로 뒷받침하는 빠른 상승입니다. 곧 OOM에 도달할 공격적인 누수를 가리킵니다.
- 흔한 원인: 고루틴 누수(Go), 스레드 누수(Java), 종료 경로 없는 재귀, 무한정 쌓이는 큐나 버퍼.
- 예시: 24시간 동안 총 약 200MB를 소비하는 고루틴 누수가 있는 Go 서비스는 높은 신뢰도로 Trend Based Growth로 감지됩니다.
Memory Leak Detection 탭
상단의 발견 배너가 몇 개의 워크로드가 누수 중인지 알려줘서(예: "6 workload(s) detected"), 조치가 필요한지 한눈에 파악할 수 있습니다.
Triage 차트. 버블 차트가 누수 중인 모든 워크로드를 누수 속도(시간당 퍼센트, x축)와 절대 증가량(Mi, y축)으로 배치합니다. 모서리는 느리고 작음부터 빠르고 큼까지를 나타내며, 우측 상단에 있는 워크로드는 빠르고 크게 누수되고 있으므로 가장 먼저 조치해야 합니다.
Top Memory Leak Workloads. 아래 테이블은 각 워크로드를 Workload Name, Workload Type, Namespace, Detection Count, Increase %, Hourly Increase %, Confidence와 함께 나열하며, 가장 심각한 순서로 정렬됩니다. 행을 펼치면 다음을 볼 수 있습니다.
- 컨테이너별 바닥 차트: 시간당 최솟값을 나타내는 주황색 선(바닥이 올라가면 누수)과, 그 주위에 음영 처리된 시간당 최소/최대 범위.
- 감지 건별 테이블: Detected, Pod Name, Container Name, Detection Type(Steady Growth 또는 Trend Based Growth), Baseline Memory, Recent Memory, Increase %, Confidence.
Possible OOM Risk 탭
누수 감지가 추세를 알려준다면, OOM risk는 워크로드가 지금 얼마나 한계에 가까운지 알려줍니다. 이 탭은 누수 여부와 상관없이 memory limit에 근접한 워크로드를 표시합니다.
Triage 차트. 버블 차트가 워크로드를 메모리 사용률(limit 대비 퍼센트, x축)과 limit까지의 여유(Mi, 낮을수록 나쁨, y축)으로 배치합니다. 모서리의 음영 처리된 "위험하고 여유 없음, 먼저 조치" 구역은 100%에 가깝게 고정돼 더 내줄 여유가 없는 워크로드를 표시합니다.
Top OOM Risk Workloads. 테이블 헤더에는 현재 적용 중인 사용률 임계값(기본값 Utilization: 90%)이 표시됩니다. 컬럼은 Workload Name, Workload Type, Namespace, Detection Count, Latest Utilization, Memory Limit, Max OOM Risk(관측된 가장 작은 여유)입니다. 행을 펼치면 컨테이너별 사용률 카드(예: memory-eater가 100MiB limit 중 99.7MiB, 99.7%, 90% 임계값 대비)와 감지 건별 테이블(Detected, Pod Name, Container Name, Memory Limit, Avg Utilization, Threshold)을 볼 수 있습니다.
OOM Risk Settings. 무엇을 "위험"으로 볼지 결정하는 사용률 임계값은 기본값 **90%**이며, 테이블 위의 OOM Risk Settings 버튼으로 조정할 수 있습니다.
누수와 OOM risk는 서로 별개입니다
두 탭은 서로 다른 것을 측정하며, 워크로드가 한쪽에만 나타날 수 있습니다.
- OOM risk는 높지만 누수는 없음: 워크로드가 실제로 메모리가 더 필요한 상태입니다. limit을 올리거나 Smart Sizing으로 적정 사이징하세요.
- 누수는 있지만 아직 OOM risk는 없음: 바닥은 올라가고 있지만 아직 여유가 있습니다. 고칠 시간은 있지만, 시계는 돌아가고 있습니다.
같은 워크로드가 두 탭에 모두 나타나면 긴급 상황으로 취급하세요. 그 누수가 결국 OOMKill로 이어질 것이기 때문입니다.
활용 사례
선제적 재시작 예약
누수를 일찍 잡아내고, 증가 속도로부터 OOM까지 걸리는 시간을 추정한 뒤, 크래시가 나기 전에 유지보수 시간대(maintenance window)에 깔끔하게 재시작을 예약합니다. 메모리가 초기화되고 아무 사용자도 알아채지 못하니, 새벽 3시 알람이 계획된 변경으로 바뀝니다.
메모리 프로파일링과 코드 수정
감지 결과로 프로파일링 대상을 정합니다. 가장 자주 누수되는 워크로드를 찾고, 누수 시작 시점을 배포나 버전과 연결해 확인하고, 플래그된 컨테이너에 언어별 프로파일러(pprof, heapdump, VisualVM)를 돌리고, 근본 원인을 고친 뒤, 패턴이 더 이상 나타나지 않는지 확인합니다.
용량 계획과 limit 조정
limit을 건드리기 전에, 누수인지 아니면 정말 메모리가 더 필요한 것인지부터 구분하세요. 누수라면 누수된 메모리에 맞춰 limit을 올리지 말고 누수 자체를 고치세요. 누수가 없다면 워크로드가 정말로 더 많은 메모리를 필요로 하는 것이니, limit을 올리거나 Smart Sizing으로 적정 사이징하세요.
참고 사항
- Memory Leak Detection은 WA Metrics Agent가 수집한 최근 약 5일치의 컨테이너별 시간당 메모리 지표를 분석합니다.
- 두 탭 모두 먼저 요약 수치를 불러오고, 워크로드를 펼쳤을 때만 시계열 데이터를 가져옵니다. 그래서 대규모 클러스터에서도 화면이 빠르게 반응합니다.
- 누수 패턴은 Pod가 재시작되면 초기화됩니다. 재시작 직후 감지가 사라졌다면, 근본 코드가 고쳐지지 않은 이상 며칠 안에 다시 나타날 것으로 예상하세요.