
AWS AMI 기본 설정에 숨어있던 좀비 cgroup이 어떻게 대규모 ML 클러스터를 마비시켰는가
Pinterest 엔지니어들이 Ray ML 클러스터에서 발생한 미스터리한 네트워크 장애를 커널 레벨 프로파일링을 통해 해결한 여정을 담고 있습니다. 단순한 네트워크 오류처럼 보였던 문제가 사실은 수만 개의 좀비 메모리 cgroup으로 인한 CPU Starvation이었음을 밝혀내는 과정은 인프라 엔지니어에게 깊은 통찰을 제공합니다.
클라우드 벤더의 기본 이미지 설정을 맹신하지 마십시오. 원인 불명의 성능 저하가 발생한다면 평균 CPU 사용량에 속지 말고, 코어별 프로파일링과 커널 시스템 호출 지연 여부를 반드시 점검해야 합니다.
Pinterest의 Ray 기반 ML 학습 작업이 특정 가용 영역(us-east-1a)의 GPU 머신에서 네트워크 연결 유실 및 ENA 드라이버 리셋으로 인해 간헐적으로 중단되는 문제가 발생했습니다. 초기 조사 결과, 높은 시스템 CPU 사용량과 페이지 폴트가 관찰되었으나 일반적인 메모리 최적화 기법으로는 해결되지 않았습니다.
96개 vCPU 코어별로 mpstat와 시계열 perf 데이터를 수집하고 Flamescope로 시각화하여, 특정 코어에서 Kubelet이 mem_cgroup_nr_lru_pages 시스템 호출을 처리하며 100% 점유되는 현상을 발견했습니다. 원인은 AWS Deep Learning AMI에 기본 포함된 ecs-agent가 반복적으로 크래시되며 수만 개의 '좀비 메모리 cgroup'을 생성한 것이었으며, 해당 에이전트를 비활성화하여 문제를 해결했습니다.
네트워크 드라이버 리셋의 근본 원인인 CPU Starvation을 제거함으로써 25% 이상 하락했던 ML 학습 작업의 성공률을 정상화하고 고가의 GPU 리소스 낭비를 방지했습니다. 또한 클라우드 공급자의 기본 머신 이미지(AMI) 설정에 대한 검증 프로세스의 중요성을 확인했습니다.
Trade-off
근본 원인을 파악하기까지 약 3개월의 조사 기간이 소요되었으며, Huge pages 도입이나 jemalloc 적용 등 초기 가설에 기반한 시도들이 실제 문제 해결에는 직접적인 효과를 내지 못하는 리소스 낭비가 있었습니다. 시스템 안정성을 위해 불필요한 기본 서비스를 수동으로 관리해야 하는 운영 부담이 추가되었습니다.
AWS에서 사용하는 고성능 네트워크 인터페이스 드라이버로, CPU가 특정 시간(5초) 이상 응답하지 않으면 하드웨어 리셋을 트리거합니다.
컨테이너나 프로세스가 종료된 후에도 커널 메모리 참조가 남아있어 완전히 제거되지 않은 메모리 제어 그룹입니다.
Netflix에서 개발한 성능 분석 도구로, 일정 기간의 프로파일 데이터를 하위 시간 단위로 쪼개어 시각화함으로써 간헐적인 성능 튀는 현상을 추적하기에 적합합니다.




