Edge Functions를 5배 빠르게: V8 isolate에서 Firecracker MicroVM으로

AI 요약

Netlify는 하루 약 10억 건의 Edge Functions를 처리합니다. 기존에는 요청이 외부 실행 서비스로 이동해 함수를 실행한 뒤 Netlify 네트워크로 돌아왔습니다. 새 구조에서는 자체 엣지 네트워크 안의 컴퓨트 노드에서 Firecracker MicroVM을 실행합니다. Netlify는 따뜻한(warm) 호출의 중앙값 지연 시간이 기존 25~40ms에서 약 5~6ms로 줄었고, p99 호출은 47.4% 빨라졌다고 밝혔습니다. 가용성은 99.998%이며 로그 전달 속도도 5배 빨라졌습니다. 새 지역에서 처음 실행할 때 이미지가 필요하면 평균 약 9ms가 더 걸립니다. 이런 콜드 호출은 전체 호출의 약 1.2%입니다.

요청을 VM까지 보내는 과정

요청은 클라이언트와 가까운 Netlify 엣지 노드에 도착합니다. 노드는 TLS 연결을 종료하고 배포에 설정된 Edge Functions 경로와 요청 경로를 비교합니다. 일치하는 경로가 있으면 요청과 함께 VM 사양을 컴퓨트 노드로 전달합니다. 사양에는 런타임, Netlify 플랫폼, 함수 코드 이미지와 CPU·메모리·연결 한도가 들어갑니다. 사양 해시와 사이트별 정보로 서비스 ID를 만들기 때문에 코드나 환경 변수가 다른 배포는 별도 서비스로 취급합니다.

컴퓨트 노드는 서비스 ID가 이미 있는지 확인합니다. 서비스가 없으면 필요한 이미지가 디스크에 있는지 살피고, 없는 이미지는 엣지 노드에서 받아 저장합니다. 해당 지역에서 실제 트래픽을 받는 함수 이미지에 한해 가져오는 방식입니다. 지역별 노드 선택에는 rendezvous hashing을 씁니다. 같은 서비스 요청을 같은 노드로 보내면 실행 중인 VM과 캐시를 재사용해 콜드 시작을 줄일 수 있습니다. 다만 특정 서비스에 트래픽이 몰리면 노드 하나가 과부하될 수 있으므로, 일정 임계치를 넘으면 여러 노드로 분산합니다.

MicroVM 시작과 재사용

함수마다 Firecracker MicroVM 하나를 실행합니다. Netlify 설명에 따르면 VM 생성에는 1ms 미만, 시작에는 p99 기준 약 2ms가 걸립니다. 전체 운영체제 대신 축소한 Linux 환경을 시작하기 때문입니다. 함수 파일은 압축하지 않은 EROFS 이미지로 마운트하고 메모리 매핑합니다. 따라서 번들 전체를 미리 읽지 않고 실제 사용하는 부분만 읽습니다.

VM이 시작되고 JavaScript 서버가 포트를 열면 Netlify는 VM 스냅샷을 만듭니다. 함수가 호출되지 않을 때는 VM을 계속 대기시키지 않고 0개까지 줄입니다. 다음 호출이 오면 스냅샷에서 새 VM을 시작합니다. 스냅샷도 메모리 매핑하므로 내용을 모두 메모리에 읽어 들이기 전에 실행을 시작할 수 있습니다. VM 부팅과 스냅샷 생성·복원, 스케일 투 제로(scale to zero)는 Unikraft 제품이 담당합니다.

운영과 배포

Netlify는 컴퓨트 노드에 로컬 DNS resolver를 두고, 부팅 시간과 첫 포트 개방까지 걸린 시간, 사용자 코드 시작 시간 같은 지표를 수집합니다. 신속한 재라우팅과 컴퓨트 노드 제외를 위한 circuit breaker도 둡니다. 컴퓨트 노드는 엣지 노드와 다른 이미지로 별도 구축합니다. 엣지 노드를 가볍게 유지하고 컴퓨트 노드의 인스턴스 유형과 확장 규모를 독립적으로 조정하기 위해서입니다.

컨트롤 플레인은 컴퓨트 노드 목록과 상태를 관리하고 엣지 노드는 목록을 주기적으로 확인합니다. 새 버전을 배포할 때는 기존 노드와 나란히 새 노드 집합을 띄워 기존 규모까지 확장합니다. 새 집합이 정상 상태가 된 뒤에야 트래픽을 넘깁니다. Netlify는 이번 변경이 기존 Edge Functions 사용 방식이나 가격을 바꾸지 않으며, 프로젝트를 옮길 필요도 없다고 밝혔습니다.

앞으로 바꾸려는 제한

Netlify는 실제 파일 시스템을 갖춘 VM 환경이 npm 패키지 지원을 넓히는 데 도움이 된다고 설명합니다. 현재 베타 기능에는 네이티브 바이너리와 실행 중 파일 가져오기 관련 제약이 있습니다. 또 요청당 CPU 50ms, 메모리 512MB, 압축 코드 20MB라는 제한은 isolate 기반 실행 모델에서 정한 값이라며 재검토할 여지를 언급했습니다. 자체 네트워크에서 컴퓨트를 운영하면 네트워크 경로를 직접 제어해야 하는 기능도 검토할 수 있다고 덧붙였습니다.

Hacker News 반응

• @aaronvg — V8 isolate에서 MicroVM으로 바꾸면서 지연 시간이 어디서 생겼는지 설명했으면 좋겠습니다.
  • @vmg12 — V8 isolate는 훌륭한 샌드박스가 아니며, AI 시대에는 그대로 신뢰하지 않겠습니다. 아마 그래서 추가 샌드박스로 감싼 것 같습니다.
  • @binsquare — V8 isolate는 커널을 공유하지만 MicroVM은 별도 커널과 하이퍼바이저의 하드웨어 가상화를 이용합니다. V8 isolate가 나쁘다기보다는 서로 다른 용도에 맞는 도구라고 봅니다.
  • @phickey — 이름에 isolate가 들어가지만 V8 팀은 이를 보안 경계로 보지 않습니다.
• @nchmy — Cloudflare Workers도 V8 isolate를 쓰는데 Netlify가 말한 기존 25~40ms보다 훨씬 빠릅니다. 설명을 이해하기 어렵고 믿기 힘듭니다.
  • @phickey — 글에 따르면 예전에는 요청이 인터넷을 거쳐 외부에서 실행된 뒤 돌아왔습니다. Cloudflare Workers는 제가 알기로 처음부터 Cloudflare 네트워크 안에서 실행했습니다.
• @secondcoming — 밀리초 단위가 중요하다면 왜 JavaScript를 쓰나요?
  • @wmf — V8은 스크립트 시작 시간이 매우 빠르도록 최적화돼 있습니다.
• @nderjung — Unikraft에서 일하는 Alex입니다. MicroVM 쪽 이야기에 질문이 있으면 답하겠습니다. 저희 쪽 기술 글도 몇 편 있습니다.
• @torginus — AWS가 Lambda용 MicroVM을 만들었는데도 Lambda의 Node.js는 지연 시간과 처리량이 모두 느립니다. AWS도 비슷한 사용 사례가 많으니 이 기술을 활용할 수 있을 것 같습니다.
  • @tomnipotent — Firecracker는 AWS 기술이며 Lambda와 Fargate의 기반이 됐습니다. 그 위에 얹힌 기업용 기능들이 문제를 일으키는 것 같습니다.
  • @nderjung — 원래 AWS 기술이지만 Unikraft는 약 4년 전에 Firecracker를 포크했습니다. VM 안에서 제어하는 사용자 지정 hypercall과 POSIX 방식 fork 등 기능을 더했고, upstream의 수정 사항도 꾸준히 반영합니다.
• @CodesInChaos — VM을 스냅샷한 뒤 복원하면 난수 생성기 상태도 복제될 수 있습니다. UUID 생성기나 암호화에서 치명적인 문제가 생길 수 있어 걱정됩니다.
  • @ameliaquining — Firecracker에는 이 문제를 해결하는 기존 방식이 있습니다. Netlify도 그 방식을 쓰고 있다고 봅니다.
  • @tybit — 그렇게 하길 바라지만 잘못 처리된 사례도 있습니다. Fastly는 몇 년 전 WASM 스냅샷에 게스트 시드 값을 저장해 실행 중 난수 생성에 썼고, 취약점이 됐습니다.
• @yencabulator — 실행 자체는 이전보다 느려졌을 수도 있습니다. 네트워크 왕복만 없앤 것일 수 있는데, 설명이 오해를 부릅니다.
• @WatchDog — 다른 조건이 같다면 V8 isolate가 Firecracker보다 지연 시간이 낮아야 합니다. 글에서도 V8 지연의 원인이 외부 호스팅이었다고 설명합니다. Firecracker는 보안 모델이 더 낫습니다.

원문: Netlify / 번역·요약: Trawling