안녕하세요! 와탭랩스📊입니다.

‘포켓몬GO’라는 게임을 한 번쯤 들어 보셨을텐데요. ‘포켓몬스터’라는 만화를 현실 세계에 구현해 놓은 듯한 게임입니다. 이 게임은 2022년 국내 모바일 게임 MAU(월간 사용자 수) 1위를 기록할 정도로 큰 인기를 끌었지만, 출시 초기에는 예상치 못한 큰 난관을 겪었습니다.

미국, 호주, 뉴질랜드에서 서비스를 시작한 포켓몬GO는 출시 직후 예상을 50배 이상 초과하는 약 2억 명의 사용자가 몰리면서 서버가 불안정해졌고 결국 게임 접속과 플레이에 지장을 초래했습니다. 개발사인 나이언틱(Niantic)은 이러한 과부하 현상을 해결하기 위해 서버 증설, 안정화 작업을 통해 문제를 빠르게 해결해야 했습니다.

이처럼 신규 서비스 오픈 시 예상치 못한 장애와 마주하는 상황은 흔하게 발생합니다. 갑작스러운 부하나 애플리케이션의 리소스 사용 패턴 변화로 인해 장애가 발생할 수 있습니다. 올해 초 와탭의 고객인 A사 역시 신규 서비스 오픈 과정에서 OOM(Out of Memory) 문제를 겪었습니다. 메모리 부족으로 인해 약 1시간 가량 장애가 발생했고, 그동안 사용자는 서비스에 접근조차 할 수 없었죠.

A사가 겪은 OOM 문제는 무엇이었고, 이를 발견하여, 어떻게 해결했는지 이번 레터에서 살펴보고자 합니다. 또한, OOM 재발 방지를 위한 IT 운영 전략에 대해서도 소개해드립니다. 이번 레터가 신규 서비스 오픈 시 발생할 수 있는 장애를 최소화하는 데에 도움이 되길 바랍니다.

OOM은 크게 두 가지 원인으로 인해 발생합니다.

우선 예상보다 많은 리소스 소비로 인해 메모리 한계를 초과하는 경우입니다. 다음은 애플리케이션이 사용한 메모리를 반환하지 않아 점진적으로 소비량이 누적되는 메모리 누수의 경우입니다. A사의 경우 OOM의 주요 원인은 예상보다 많은 리소스 사용량이었습니다.

OOM이 발생하면 신속하게 원인을 파악하고 해결하는 것이 중요합니다. 다행히 A사는 OOM 발생 시 알림을 받도록 설정이 되어 있었습니다. 그래서 장애 감지 후 즉시 [Out Of Memory Killed 컨테이너] 메뉴를 통해 문제의 컨테이너를 추적했습니다.

이 기능을 사용하면 OOM이 발생한 컨테이너의 목록, 컨테이너 ID 및 이름, 설정된 메모리 제한, OOM 발생 직전 메모리 사용 추이 등을 한눈에 확인할 수 있습니다. 따라서 문제의 원인을 빠르게 분석할 수 있습니다.

정확한 OOM 원인 분석을 위해서는 컨테이너 종료 직전의 메모리 사용 패턴을 확인하는 것이 중요한데요. 당일 메모리 사용량 추이를 살펴본 결과 사용량이 지속적으로 증가하다가 제한값을 초과하면서 OOM이 발생했고, 이로 인해 컨테이너가 반복적으로 재시작되는 현상이 나타났습니다. 이런 경우에는 서비스 운영에 필요한 최소한의 리소스만큼 할당되지 않은 것이 아닌지 점검해야 합니다.

컨테이너 맵을 통해 전체 컨테이너의 상태를 확인해보니 문제 컨테이너의 메모리 사용량이 지속적으로 증가하고 있었습니다. 해당 컨테이너를 관리하는 Deployment의 매니페스트 정보를 확인해본 바 replicas 값이 1로 설정되어 단일 Pod로만 운영 중인 상태임을 확인했습니다.

한 개의 Pod만으로 서비스를 감당하기 어려울 것으로 판단하였고, 이에 replicas 수를 5개로 확장하여 이후 각 Pod 내 컨테이너의 메모리 사용량이 안정적으로 유지되는지 모니터링했습니다.

이러한 경우 다음과 같은 원인을 의심해 볼 수 있습니다.

• Heap 단편화: 큰 객체 할당이 실패하여 메모리 부족 현상이 발생하는 경우
• Xmx 설정 값이 너무 낮음: 힙 메모리 최대 크기(Xmx)가 제한되어 있어 충분한 메모리를 사용할 수 없는 경우
• Full GC로 인한 메모리 부족: Full GC가 자주 발생하면서 사용 가능한 힙 메모리가 줄어드는 경우
• 메모리 누수: GC가 불필요한 객체를 해제하지 못해 점진적으로 메모리가 소진되는 경우

이 중에서 가장 빠르게 확인할 수 있는 Xmx 설정을 먼저 점검해봤고, 현재 설정된 Xmx 값이 힙 사용량 대비 충분한 상태임을 확인했습니다.

컨테이너 자체에 문제가 있는지 확인하기 위해 다시 점검해봤습니다. 확인해본 결과 컨테이너의 메모리 제한 값, 실제 사용량, 제한값 대비 사용률 모두 낮은 상태로 컨테이너는 안정적으로 실행되고 있었습니다.

이어 컨테이너 메모리와 자바 애플리케이션 메모리와의 상관관계를 살펴보았습니다. 그리고 컨테이너에 할당된 최대 메모리에 비해 애플리케이션의 Xmx 값은 지나치게 낮게 설정되어 있는 것을 확인했습니다. 이로 인해 반복적으로 GC가 실행되면서 트랜잭션 응답 지연과 서비스 성능 저하가 발생한 것으로 추정되었습니다.

설정 값을 변경한 후 OOM은 더 이상 발생하지 않았습니다. 다만 메모리를 늘렸음에도 사용량이 지속적으로 증가하고, 특히 GC 실행 후에도 메모리 여유량이 충분히 회복되지 않는 현상이 반복된다면 메모리 누수를 의심해볼 필요가 있습니다. 메모리 누수는 단기 사용량 추이만으로는 파악하기 어렵기 때문에 중장기적으로 메모리 사용 추이를 모니터링해야 합니다.

사전 예방 조치를 했음에도 불구하고 OOM이 발생했다면 애플리케이션의 특성에 맞게 수평 확장(Horizontal Scaling) 또는 수직 확장(Vertical Scaling)하여 서비스 다운타임을 최소화해야 합니다.

쿠버네티스는 컨테이너 오케스트레이션 도우고써 Pod를 추가하거나 리소스 제한 설정 작업을 빠르게 수행할 수 있습니다. A사 역시 수평 확장을 통해 빠르게 서비스를 정상화할 수 있었습니다.

OOM을 해결한 후 힙 덤프(Heap Dump) 분석, GC 튜닝, 리소스 사용량 최적화 등을 수행함으로써 메모리 사용 패턴을 점검하고, OOM이 반복되지 않도록 근본적인 원인을 해결해야 합니다.

단순히 리소스를 늘리는 것에 그치지 않고 애플리케이션이 효율적으로 메모리를 활용할 수 있도록 구조를 최적화하는 것이 서비스 안정화를 위한 장기적인 해결책입니다.