MicroVM 복원 지연의 숨은 주범: ARP Stall 현상과 예방 설계

MicroVM 기반의 인프라는 수많은 AI 에이전트나 FaaS를 즉각적으로 구동하기 위해 스냅샷 복원(Snapshot Restore) 기술을 적극적으로 활용한다. 하지만 스냅샷 기술을 적용했음에도 불구하고 복원 과정에서 간헐적으로 1초 이상의 설명하기 어려운 지연이 발생하곤 한다. 엔지니어들은 종종 이 지연의 원인을 스토리지 디스크의 I/O 병목이나 호스트의 페이지 캐시(Page Cache) 미스 현상으로 오인하곤 한다. 하지만 네트워크 패킷 수준에서 시스템을 프로파일링해 보면 진짜 주범은 디스크나 메모리가 아닌 L2/L3 네트워크 스택의 'ARP Resolution Stall' 현상인 경우가 많다. 본 문서에서는 ARP Stall이 무엇이며 이를 스마트하게 우회하는 네트워크 아키텍처 설계 방안을 다룬다.

가짜 병목에 속지 마라: 캐시 미스의 착각

스냅샷 복원 시 콜드 복원(처음 복원하는 경우)과 웜 복원(이미 캐시된 상태에서의 복원) 사이에 극심한 속도 차이가 발생하면 대부분의 시스템 엔지니어는 이를 메모리 워킹 셋(Working Set)이 호스트의 페이지 캐시에 적재되지 않아 발생하는 지연으로 가설을 세운다. 이러한 가설에 기반하여 복원 전 디스크 데이터를 미리 메모리에 적재하는 madvise(MADV_WILLNEED) 등의 사전 읽기(Read-ahead) 최적화를 시도할 수 있다. 하지만 실측 데이터에 따르면 이러한 캐시 예열 작업이 실질적인 복원 속도 향상에 미치는 영향은 거의 없다. 전체 지연 시간의 80% 이상을 차지하는 진짜 병목은 프로세스나 디스크 I/O가 아닌 호스트가 게스트 VM과 첫 통신을 시도하는 순간 발생하는 네트워크 대기(Stall)에 숨어 있기 때문이다.

ARP Stall 현상의 기술적 원리

ARP Stall 현상은 게스트 OS가 스냅샷에서 깨어나 새로운 네트워크 인터페이스를 설정하는 과정과 호스트 커널의 주소 결정 프로토콜(ARP) 메커니즘이 엇갈리면서 발생한다. 스냅샷에서 복원된 게스트 OS는 IP 주소를 새롭게 할당받더라도(ip addr add) 자신이 해당 IP와 MAC 주소를 소유하고 있음을 네트워크에 자발적으로 알리는 Gratuitous ARP를 브로드캐스트하지 않는 경우가 빈번하다. 이런 경우 게스트의 상태를 확인하기 위해 호스트 데몬이 첫 번째 프로브 패킷을 보내려고 하면 호스트의 라우팅 테이블에는 타겟 IP에 대한 MAC 주소 정보가 존재하지 않게 된다. 따라서 호스트 커널은 ARP Request를 발송하고 응답을 기다리게 되는데 이 과정에서 불필요하게 약 1초에 달하는 커널 ARP 재시도 타임아웃(Kernel ARP retry)을 온전히 소모하게 된다. 결과적으로 게스트 VM은 이미 복원되어 연산을 수행할 준비를 마쳤음에도 불구하고 호스트는 L2 계층의 주소를 찾지 못해 약 1초간 통신을 강제로 중단하는 어처구니없는 상황이 발생하게 되는 것이다.

실측 데이터로 보는 ARP Stall의 심각성

MicroVM 환경에서 통신을 시작하기 전 대기 시간을 프로파일링해 보면 ARP Stall의 심각성을 명확히 알 수 있다. 스냅샷 복원 직후 ARP Stall 현상이 발생할 경우 호스트가 게스트 VM과 통신을 확립하기까지 소요되는 대기 시간은 약 870ms에 달한다. 부팅이나 메모리 복원 자체가 밀리초 단위로 끝나는 MicroVM 환경에서 870ms의 네트워크 대기 시간은 전체 응답성의 대부분을 갉아먹는 절대적인 지연 요소이다. 대규모 AI 에이전트 인프라에서는 초당 수백 개의 VM이 스폰되고 소멸한다. 각 VM마다 1초에 가까운 네트워크 지연이 중첩되면 오케스트레이터의 동기화 로직에 심각한 과부하를 유발하게 된다.

ARP Priming을 이용한 스마트한 해결 방안

ARP Stall 문제를 해결하기 위해 게스트 OS 내부의 커널을 뜯어고치거나 별도의 스크립트를 주입하여 억지로 Gratuitous ARP를 발생시키는 것은 유연하지 못한 접근이다. 현대적인 인프라 아키텍처에서는 이를 호스트 측의 선제적 네트워크 프로비저닝 방법(ARP Priming)으로 해결하는 것이 권장된다. 호스트 데몬(또는 오케스트레이터)은 VM을 복원하면서 게스트에게 할당될 IP와 MAC 주소를 이미 알고 있다. 따라서 호스트가 게스트로 상태 확인 프로브를 보내기 직전에 호스트 커널의 이웃 테이블(Neighbor Table)에 해당 IP-MAC 매핑 정보를 명시적으로 등록한다. 이렇게 하면 호스트 시스템은 이미 목적지의 MAC 주소를 알고 있으므로 시간 낭비가 심한 ARP Request 브로드캐스트와 커널 타임아웃 대기 과정 없이 즉각적으로 패킷을 전송할 수 있다. 실제로 ARP Priming 설계를 아키텍처에 반영한 후 성능을 측정해 보면 기존에 약 870ms를 소모하던 네트워크 통신 대기 시간이 단 약 1.8ms로 단축되는 것을 확인할 수 있었다. 요약하자면 호스트 측에서 게스트의 네트워크 상태를 사전에 주입하는 스마트한 네트워크 아키텍처 설계를 통해 우리는 MicroVM 기반 AI 에이전트 실행 인프라의 스냅샷 복원 즉시성에 저해가 되는 약 1초 안팎의 지연을 완벽하게 제거할 수 있다.