ECS 강제 재배포 후 메모리 사용률 급증 — JVM Committed Heap과 OS 메모리 관계

문제 정의

ECS 자동 플랫폼 업데이트 대비로 12:00~13:00 사이에 ECS 서비스 강제 재배포를 진행했습니다. 재배포 후 특정 서비스의 메모리 사용률이 눈에 띄게 상승하였고, 코드 변경 없이 계단식으로 계속 올라가는 패턴이 관찰되었습니다.

JVM 메모리 상태 비교

재배포 전후의 JVM 메트릭을 비교했습니다.

재배포 전 (Uptime: 1.7주)

1.7주간 운영되면서 JVM이 이미 committed heap을 78%까지 확보한 상태였지만, 실제 사용(used)은 27% 수준으로 안정적이었습니다.

재배포 후 (Uptime: 2시간)

재배포 직후 2시간 만에 Heap Used가 이미 38%로, 재배포 전(27%)보다 높았습니다. Committed는 48%로 아직 낮지만, 워크로드를 처리하면서 빠르게 증가하는 중이었습니다.

원인 분석

원인 1 — JVM Committed Heap 확장과 OS 메모리 인식

핵심은 JVM의 committed heap과 OS가 인식하는 메모리 사용량의 차이입니다.

• JVM은 워크로드를 처리하면서 committed heap을 계속 늘려감
• OS 관점에서는 커밋 = 사용: JVM이 힙을 커밋하는 순간, OS는 그만큼을 이미 사용 중으로 인식 (실제 객체가 비어 있어도)
• CloudWatch의 mem_used_percent가 즉시 상승해 보이는 이유

재배포로 JVM이 새로 시작되면서, 초기화 과정에서 캐시/커넥션 풀/클래스 로딩 등이 한꺼번에 발생하여 committed heap이 빠르게 확장된 것입니다.

재배포 전: Used 27% / Committed 79% (1.7주에 걸쳐 서서히 확장)
재배포 후: Used 38% / Committed 48% (2시간 만에 빠르게 확장 중)
         → 시간이 지나면 Committed가 계속 올라가면서 OS 메모리도 함께 상승

원인 2 — ECS 플랫폼 업데이트 영향

ECS 플랫폼 버전 업데이트에 따른 내부 기능 변동(에이전트, 런타임 등)이 적용되면서 기존 대비 메모리 사용 패턴이 달라졌을 가능성도 있습니다.

핵심 포인트

CloudWatch에서 보이는 mem_used_percent는 JVM의 Heap Used가 아니라 OS가 인식하는 전체 프로세스 메모리(≈ Committed + Non-Heap + Native)를 반영합니다. 따라서 JVM 내부적으로는 여유가 있어도 OS 지표는 높게 나타날 수 있습니다.

마무리

"코드 변경 없이 재배포만 했는데 메모리가 올라간다"는 현상은, JVM이 새로 시작되면서 committed heap을 빠르게 확장하는 과정에서 OS 메모리 사용률이 함께 상승하는 정상적인 동작이었습니다.

ECS + JVM 환경에서 메모리를 모니터링할 때는 OS 레벨 지표(mem_used_percent)와 JVM 레벨 지표(Heap Used/Committed)를 함께 보는 것이 중요합니다.