Netflix의 컨테이너 스케일링 병목, 현대 CPU에서 드러난 mount lock 문제

Netflix는 새 컨테이너 런타임으로 전환한 뒤, r5.metal 같은 일부 노드에서 컨테이너 시작이 수십 초씩 지연되거나 아예 멈추는 현상을 겪었다. 원인은 단순한 이미지 크기보다도, 50+ layer 이미지를 가진 컨테이너를 한꺼번에 띄울 때 발생하는 mount/umount 폭증이었다.

문제의 핵심은 containerd가 사용자 namespace 환경에서 각 레이어마다 open_tree(), mount_setattr(), **move_mount()**를 수행해 idmap bind mount를 만들고, overlayfs rootfs를 구성한 뒤 이를 다시 정리한다는 점이었다. 컨테이너 100개, 레이어 50개라는 조건에서는 시작 경로에서만 총 20,200회의 mount 작업이 발생하며, 이 모든 작업이 커널 VFS의 전역 mount lock을 두드리면서 락 경합이 폭발했다.

이 현상은 구형 런타임과의 차이에서도 설명됐다. 이전 방식은 모든 컨테이너가 하나의 호스트 user range를 공유하고 untar 시점에 UID를 미리 변환했지만, 새 런타임은 컨테이너마다 고유한 host user range를 부여하고 커널 idmap 기능으로 소유권을 효율적으로 매핑한다. 보안성은 좋아졌지만, 그 대가로 mount 경로의 동시성 비용이 커졌다.

벤치마크에서는 r5.metal이 고동시성에서 가장 먼저 실패했고, m7i.metal-24xl과 m7a.24xlarge는 훨씬 안정적으로 버텼다. 저동시성에서는 비슷했지만, 동시성이 올라갈수록 7세대 인스턴스가 더 낮은 launch time과 더 높은 성공률을 보였고, 특히 m7a가 가장 일관된 스케일링을 보여줬다.

perf와 커스텀 마이크로벤치마크로 확인한 핫패스는 Linux VFS의 path lookup, 특히 path_init() 안에서 seqlock을 기다리며 pause를 반복하는 스핀 루프였다. Intel Topdown Microarchitecture Analysis(TMA) 에서는 **95.5%**의 pipeline slot이 contested accesses에 묶였고, **57%**는 false sharing으로 나타나면서 cache line bouncing과 락 경합이 주범임이 드러났다.

하드웨어 관점에서는 두 가지가 특히 중요했다. NUMA가 있는 듀얼소켓 r5.metal에서는 전역 락 접근 시 원격 메모리 홉이 추가돼 지연이 더 커졌고, hyperthreading이 켜진 m7i.metal-24xl에서는 공유 실행 자원을 두 스레드가 경쟁해 락 경합이 악화됐다. 실제로 hyperthreading을 끄면 컨테이너 launch latency가 20~30% 개선됐다.

결국 이 문제는 단순히 containerd 최적화의 문제가 아니라, 전역 락 + 현대 CPU 아키텍처 + NUMA + hyperthreading이 함께 만들어낸 병목이었다. Netflix는 컨테이너 스케일링의 병목을 소프트웨어 레이어가 아니라 하드웨어와 커널 경계에서 찾아야 한다는 점을 확인했다.