WASM vs 컨테이너 콜드 스타트: 런타임에서 말하는 내용

콜드 스타트는 애플리케이션 코드가 실행되기 전에 실행 환경을 초기화해야 하는 경우 요청에 의해 지불되는 추가 대기 시간을 나타냅니다. 클래식 엣지 또는 서버리스 기능에서 이는 한계적인 사례가 아닙니다. 두 트래픽 피크 사이에 인스턴스가 0개로 떨어지거나 지리적으로 분산된 수십 개의 엣지 노드에 실행을 분산하는 플랫폼은 첫 번째 배포 시뿐만 아니라 이 비용을 영구적으로 지불합니다.

이 주제는 Docker의 공동 창립자인 Solomon Hykes가 2019년 3월 Twitter에 게시한 "만약 WASM+WASI가 2008년에 존재했다면 Docker를 만들 필요가 없었을 것입니다. 그만큼 중요합니다. 서버의 WebAssembly는 컴퓨팅의 미래입니다."라는 문장이 발표된 이후 WASM 생태계에서 거의 상징적인 중요성을 갖게 되었습니다. 출처 그림.

Aurabase는 엣지 기능을 위한 두 가지 경로를 제공합니다. 하나는 Supabase 마이그레이션 가이드에 설명된 대로 Deno 런타임에서 코드를 실행하는 Studio 편집기이고, 다른 하나는 Rust로 작성되고 Wasmtime에서 WASM으로 컴파일된 함수에 대한 별도의 경로를 목표로 하는 aura functions deployCLI입니다. 아직 존재하지 않는 콜드 스타트 수치를 제공하지 않고 이 기사에서 조명하는 것이 바로 이 두 번째 경로입니다.

차이점은 절대적인 측면에서 더 빠른 런타임에서 발생하는 것이 아니라 쿼리와 애플리케이션 코드 사이의 더 짧은 단계 스택에서 발생합니다.

컨테이너를 시작하면 호스트 커널이 동원됩니다. 즉, 새 프로세스를 생성하고 이를 격리하는 cgroup 및 네임스페이스를 설정하고 이미지 레이어를 마운트한 다음 내부에서 애플리케이션 런타임을 시작합니다(예를 들어 Node.js 및 해당 V8 엔진 자체에는 초기화 비용이 있습니다). 각 단계에는 시스템 호출이 추가되고, 로컬에서 볼 수 없는 이미지의 경우 시작하기도 전에 네트워크 다운로드가 추가됩니다.

WebAssembly 모듈은 운영 체제 수준이 아닌 가상 머신 언어 수준에서 격리됩니다. 모듈을 인스턴스화한다는 것은 호스트 런타임의 이미 시작된 프로세스 내에서 선형 메모리를 할당하고 가져오기를 바인딩한 다음 진입점으로 점프하는 것을 의미합니다. 새로운 프로세스, 이미지 레이어, 기본 파일 시스템 마운트가 없습니다.

컴파일 모드를 선택하면 추가 변수가 추가됩니다. Wasmtime은 모듈이 로드될 때 Cranelift 백엔드를 통해 JIT로 컴파일하거나, 이미 네이티브 기계 코드로 변환된 .cwasm 파일을 생성하는 wasmtime compile를 사용하여 미리 컴파일할 수 있습니다. AOT(조기 컴파일)는 요청의 중요한 경로에서 컴파일 단계를 제거합니다. 이는 바로 콜드 스타트에 민감한 에지 아키텍처가 활성화해야 하는 레버입니다.

# Aurabase 저장소에서 실제 추출
# WASM 런타임
wasmtime = { version = "43", features = ["async", "cranelift"] }

이는 개발이 아닌 생산 종속성입니다. 이는 Wasmtime이 실제로 Aurabase 엣지 기능의 CLI 경로에서 실행된다는 것을 확인합니다. 그러나 날짜가 지정된 벤치마크가 게시되지 않는 한 이는 지연 시간 수치를 확인하지 않습니다.

이 분야에서 가장 강력한 소스는 마케팅 블로그 게시물이 아닌 업계 연구 논문입니다. AWS에서 개발하고 특히 Lambda 및 Fargate에 사용되는 경량 microVM 기술인 Firecracker는 Agache 등이 USENIX NSDI 2020 컨퍼런스에서 발표했습니다. "Firecracker: 서버리스 애플리케이션을 위한 경량 가상화" 기사에서.

이 문서에서는 동일한 물리적 시스템에서 수천 개의 microVM을 실행할 수 있는 기능과 함께 125ms 미만의 부팅 시간과 microVM당 5MiB 미만의 메모리 오버헤드에 대해 설명합니다. 이는 동료 검토를 거친 학술 간행물에서 가져온 날짜가 지난 수치(2020년)이며, 그 이후로 서버리스 격리에 관한 문헌에서 널리 인용되었습니다.

표준 Docker 컨테이너는 일반적으로 이미지 크기, 다운로드 필요성, 임베디드 애플리케이션 런타임의 부팅 시간에 따라 수백 밀리초에서 몇 초까지 더 높습니다. Firecracker와 달리 여기에는 보편적으로 인용되는 단일 수치가 없습니다. 결과는 합의를 달성하기 위해 단일 값에 대해 테스트된 이미지에 너무 많이 의존합니다.

세 가지 소스, 세 가지 다른 상태: 역사적 공급업체, 재단 거버넌스에 따른 프로젝트, 연구 논문.

자체 사전 컴파일 WASM 컴파일러 및 런타임인 Lucet에서 2019년에 Compute@Edge를 빠르게 출시했습니다. 이번 출시에서 회사는 WASM 인스턴스화 시간을 밀리초 미만으로 기록했는데, 이는 업계의 WASM 콜드 스타트 담론에 지속적인 영향을 미쳤습니다. 2021년에 Fastly는 Lucet의 자율 개발을 중단하고 그 노력을 Wasmtime으로 방향을 바꾸었습니다. Wasmtime의 Cranelift 컴파일 백엔드는 이러한 최적화의 일부를 상속받았습니다. 이것이 오늘날 Wasmtime이 이러한 유형의 로드에 대한 참조로 남아 있는 이유 중 하나입니다.

CNCF 거버넌스(원래 SSVM, Second State에서 지원됨)에 따른 WASM 런타임인 WasmEdge는 공식 문서에서 엣지 및 IoT 로드에 대한 명시적인 위치 지정을 통해 동등한 Docker 컨테이너보다 시작 및 메모리 공간이 훨씬 낮다고 주장합니다. 이는 프로젝트 게시자 자체가 게시한 수치로, 독립적인 감사가 아닌 제품 주장으로 읽혀집니다.

학술 연구 측면에서 Faasm(Shillaker & Pietzuch, USENIX ATC 2020, 사전 출판으로도 이용 가능)은 WebAssembly 격리(Wasmtime이 아닌 WAVM을 통해)를 기반으로 하는 상태 저장 서버리스 플랫폼을 구축합니다. 이는 컨테이너나 VM에 의한 격리보다 훨씬 저렴한 비용으로 기능을 인스턴스화할 수 있기 때문입니다. 이 논문은 특별히 Wasmtime에 관한 것이 아니지만 이전 섹션의 구조적 주장에 대한 독립적인 학문적 검증을 제공합니다.

이 세 가지 런타임을 이름만으로 비교하면 실제 변수가 숨겨집니다. 즉, 선택된 컴파일 백엔드는 시작 속도와 실행 성능 간의 균형을 근본적으로 변경합니다.

Wasmer의 가장 빠른 컴파일 백엔드인 Singlepass는 팀이 콜드 스타트를 안정적인 상태 실행 성능의 고유한 축으로 식별했기 때문에 존재합니다. Singlepass에서 컴파일된 모듈은 더 빠르게 시작되지만 최대 로드 중에는 LLVM에서 컴파일된 동일한 모듈보다 느리게 실행됩니다. 이는 숨겨진 결함이 아니라 허용된 타협입니다.

These five lines do not read as a single classification: they come from different methodologies, dates and runtime generations. For a more in-depth methodological critique of the reliability of this type of WASM benchmark, our article on the limits of WebAssembly benchmarks goes further than the present comparison, which remains focused on what each source concretely asserts.

WASM의 콜드 스타트 이점은 모든 로드가 동일하게 적용되는 것이 아니라 첫 번째 요청의 대기 시간에 가장 민감한 로드에서 가장 중요합니다.

이는 특히 매우 불규칙한 엣지 트래픽(버스트 후 침묵), 여러 요청 간에 공유되는 컨테이너별이 아닌 요청별 격리, 핫 풀을 영구적으로 유지하는 대신 실제로 두 피크 사이의 인스턴스가 0개로 내려가는 인프라에 중점을 둡니다. 어쨌든 인스턴스가 뜨거운 상태로 유지되는 안정적이고 예측 가능한 로드에서는 콜드 스타트 ​​간격이 구조적으로 덜 중요합니다.

WebAssembly는 또한 콜드 스타트와는 다른 제약 조건을 유지합니다. 파일 시스템이나 네트워크에 대한 액세스는 WASI를 통해 이루어지며, 인터페이스는 런타임과 해당 버전에 따라 계속 진화하고, 빠르게 시작하도록 컴파일된 모듈(예를 들어 Wasmer 측의 싱글 패스)은 과부하 상태에서 일단 설정되면 반드시 가장 빠른 것은 아닙니다. 콜드 스타트와 최대 실행 성능은 서로 다른 두 축으로 유지되며 동일한 컴파일 프로필에서 동시에 최적이 되는 경우는 거의 없습니다.

이 기준에 따라 엣지 아키텍처 선택을 평가하기 위해 Aurabase는 공급업체에 물어볼 세 가지 구체적인 질문을 포함했습니다. 사용되는 정확한 런타임, 어떤 컴파일 백엔드(JIT 또는 AOT), 고급 콜드 스타트 수치가 독립적인 제3자 또는 런타임 게시자 자체에 의해 측정되었는지 여부입니다.

For the database layer of this same problem, see our article on the serverless Postgres cold start.