Wasmtime 및 프로덕션 Edge Functions의 경우 Wasmer

이 영어 텍스트는 프랑스어 원본에서 자동으로 생성되었으며 아직 검토되지 않았습니다.

이 페이지는 자동으로 번역되었습니다. 영어 버전은 권위가 있습니다.

이 선택은 정면 선호가 아닙니다. 이 기사에서는 실제로 검증된 두 런타임(거버넌스, 컴파일러, WASI 표준, 보안 모델)을 비교한 다음 측정되지 않은 콜드 스타트 수치를 제공하지 않고 Aurabase가 프로덕션에서 실행하는 Wasmtime 구현, 연료 측정, 에포크 중단, 메모리 제한을 자세히 설명합니다.

필수사항

Wasmtime: Rust로 작성된 바이트코드 얼라이언스 프로젝트, Cranelift 프로덕션 컴파일러, LLVM 예외가 있는 Apache-2.0 라이센스.
Wasmer: Wasmer Inc.에서 개발한 런타임, 세 가지 상호 교환 가능한 컴파일러(Singlepass, Cranelift, LLVM), MIT 라이센스.
Aurabase는 wasmtime = { version = "43", features = ["async", "cranelift"] }를 aura-functions의 실제 생산 종속성으로 선언하고 Cargo.toml에서 확인되었습니다.
기본 WASM 모드는 기본적으로 64MB의 메모리 한도, 10억 단위의 연료 예산, 10초의 시간 제한을 적용하며 세 가지 모두 환경 변수에 따라 조정 가능합니다.
이 WASM 모드는 Aurabase Edge Functions(Deno 런타임)의 기본 모드와 공존합니다. 이는 기본 경로가 아닌 두 번째 실행 경로입니다.

맥락

두 개의 런타임, 동일한 WebAssembly 기반

WebAssembly는 오랫동안 브라우저의 런타임 형식을 지정해 왔습니다. 몇 년 동안 이는 서버 측이나 에지에서 샌드박스 코드를 실행하는 데에도 사용되었습니다. 즉, 한 번 컴파일된 바이트코드는 모든 호스트 시스템에 이식 가능하며 기본적으로 컨테이너나 완전한 가상 시스템 없이 격리됩니다. Wasmtime과 Wasmer는 둘 다 Rust로 작성되었으며 동일한 .wasm파일을 실행할 수 있는 브라우저에서 이 확장을 수행합니다.

Wasmtime은 Cranelift 컴파일러를 포함하여 WebAssembly 서버 생태계의 여러 구성 요소를 관리하는 조직인 Bytecode Alliance가 주최하는 프로젝트입니다. Wasmer는 런타임을 오픈 소스로 게시하는 동시에 관련 보완 서비스(에지 배포, 툴링)를 마케팅하는 회사인 Wasmer Inc.에서 개발했습니다. 두 가지 다른 거버넌스 모델, 둘 중 하나가 생성한 코드의 품질에 대한 판단이 없습니다.

이 기사의 나머지 부분에서는 검증 가능한 네 가지 필드, 라이선스 및 거버넌스, 사용 가능한 컴파일러, WASI 표준 및 구성 요소 모델, 보안 모델을 비교한 다음 지원 코드와 함께 Aurabase의 Rust 코어가 Edge Functions 엔진에서 Wasmtime을 실행하는 이유를 설명합니다.

거버넌스 및 라이선스

다중 공급업체 기반과 상업 출판사 비교

Wasmtime은 컴파일러 생태계에서 일반적으로 허용되는 라이센스인 LLVM 예외가 포함된 Apache-2.0 라이센스에 따라 릴리스됩니다. 거버넌스는 Bytecode Alliance 모델을 따릅니다. 여러 조직이 프로젝트에 기여하고 누구도 단독으로 소유하지 않습니다.

Wasmer는 MIT 라이선스에 따라 게시되며 문서상으로는 더욱 허용적이지만 기술적 방향은 여전히 단일 게시자인 Wasmer Inc에 집중되어 있습니다. 이는 그 자체로는 결함이 아닙니다. 많은 성공적인 오픈 소스 프로젝트가 이 모델을 따릅니다. 조직이 여러 엔터티에 걸쳐 분산 거버넌스를 중요하게 생각하는 경우 이는 단순히 다른 위험 프로필입니다.

컴파일러

백엔드 1개 대 3개: Cranelift, Singlepass, LLVM

Wasmtime은 Bytecode Alliance의 코드 생성기인 Cranelift를 통해 프로덕션 환경에서 컴파일됩니다. 상자에는 시작에 민감한 경우 Cranelift에 비해 컴파일 시간을 줄이도록 설계된 추가 컴파일러인 Winch도 문서화되어 있습니다.aura-functions의 Cargo.toml는 cranelift 기능만 활성화합니다. 이 컴파일러는 프로덕션에 로드된 각 WASM 모듈을 단독으로 처리합니다.

Wasmer는 반대 경로를 택합니다. 즉, 상호 교환 가능한 3개의 백엔드입니다. 싱글패스는 덜 최적화된 기계어 코드를 사용하여 거의 즉시 단일 패스로 컴파일합니다. Cranelift는 균형 잡힌 절충안을 제공합니다. LLVM은 세 가지 중 가장 긴 컴파일 시간을 통해 가능한 최고의 실행 처리량을 목표로 합니다. 단일 런타임, 구성 중에 선택된 세 가지 손상 프로필.

표준

WASI 미리보기 2 및 구성요소 모델

WebAssembly 시스템 인터페이스인 WASI는 브라우저에 의존하지 않고 WASM 모듈에서 파일, 시계 및 네트워크에 대한 액세스를 표준화합니다. 최신 버전인 WASI Preview 2는 각 런타임에 특정한 바이너리 형식이 아닌 공유 유형 인터페이스를 사용하여 다양한 언어로 작성된 모듈을 구성하는 메커니즘인 구성 요소 모델을 기반으로 합니다. Wasmtime과 Wasmer는 각자의 속도에 맞춰 이 표준을 구현하기 위해 노력하고 있습니다.

Wasmer는 스레드나 보다 포괄적인 네트워크 소켓과 같이 공식 WASI 표준이 아직 다루지 않는 POSIX 기본 요소를 다루는 것을 목표로 하는 확장인 WASIX를 추가로 문서화합니다. 이는 WebAssembly 작업 그룹에서 지원하는 표준이 아니라 Wasmer 생태계에 특정한 확장입니다.

Aurabase WASM 모드가 사용하지 않는 것

wasm/mod.rs에서 검증된 Aurabase의 기본 wasm 모드는 현재 WASI Preview 2나 구성 요소 모델을 사용하지 않습니다. 이는 전체 표준이 아닌 게스트 모듈에 노출되는 4가지 기능인 자체 개발 최소 호스트 ABI입니다. Cargo.toml는 또한 wasmtime상자의 wasi 기능을 활성화하지 않습니다.

보안

메모리 격리 및 타이밍: 연료, 에포크, 제한

두 런타임 모두 명시적으로 가져온 함수 외부에서 호스트 시스템에 직접 액세스하지 않고 각 모듈을 자체 선형 메모리에 격리합니다. 이는 두 프로젝트 모두에 공통적인 WebAssembly 보안 모델의 기초입니다.

Wasmtime은 또한 기본 실행 영상 API인 fuel를 공개합니다. 각 명령은 미리 고정된 예산을 소비하고 이 예산이 소진되면 실행이 제대로 중지됩니다. 두 번째 API인 epoch중단을 사용하면 기다리는 동안 엔진을 차단하지 않고 시간 초과를 적용할 수 있습니다. Wasmer는 자신의 미터링 메커니즘과 인스턴스별 메모리 제한을 문서화합니다. 이 기사에서는 타사 저장소에서 이를 확인하지 않았으므로 그림별로 분류하지 않습니다.

이것이 바로 Aurabase의 aura-functions 서비스가 가능하게 하는 것이며, 실제 소스 코드와 함께 다음 섹션에 자세히 설명되어 있습니다.

Aurabase의 선택

선언된 기본 설정이 아닌 코드에서 Wasmtime을 확인했습니다.

aura-functions 서비스는 비활성화 주석이나 개발 종속성 구성 없이 wasmtime을 프로덕션 종속성으로 선언합니다. 저장소에 Cargo.toml 또는 .rs파일 중 어떤 파일도 Wasmer를 언급하지 않습니다.

Cargo.tomltoml

# WASM 런타임
wasmtime = { version = "43", features = ["async", "cranelift"] }

초기화 코드는 명시적으로 연료를 활성화하고 에포크별로 인터럽트한 다음 StoreLimits를 호출하여 메모리를 제한합니다.

wasm/mod.rsrust

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);
let engine = Engine::new(&cfg)?;

// 호출로:
let limits = StoreLimitsBuilder::new()
    .memory_size(self.max_memory_mb as usize * 1024 * 1024)
    .build();
store.set_fuel(self.max_fuel)?;
store.epoch_deadline_async_yield_and_update(1);

세 가지 제한은 모두 환경 변수별로 구성할 수 있으며 기본값은 config/mod.rs: WASM_MAX_MEMORY_MB(64), WASM_TIMEOUT_SECS(10), WASM_MAX_FUEL(10억 단위)에서 확인됩니다. 시간 제한은 백그라운드에서 트리거됩니다. tokio::spawn는 구성된 기간을 기다린 다음 기다리는 동안 현재 실행을 차단하지 않고 엔진 시대를 증가시킵니다.

게스트 모듈에 노출된 ABI는 의도적으로 최소한으로 유지됩니다. aura.log, aura.get_input, aura.set_output 및 aura.get_env는 linker.func_wrap를 통해 등록됩니다. 이는 구성 요소 모델도 아니고 WASI Preview 2도 아닙니다. 이는 HTTP 에지 기능을 실행하고 JSON 응답을 복구하는 단일 용도로 설계된 더 좁은 내부 계약입니다.

이 wasm 모드는 전역 토글이 아닌 기능별 선택입니다. Aurabase 아키텍처 개요에서는 별도의 서비스에서 JavaScript/TypeScript를 실행하는 다른 경로인 기본 deno모드에 대해 자세히 설명합니다. 둘 다 동일한 aura-functions서비스에 공존합니다.

검증된 목표와 제품 목표

What is checked here is the actual Wasmtime implementation and its default resource limits. No cold start figures are stated: see our dedicated analysis of the WebAssembly cold start for what is measurable, and what is not yet.

개요

Wasmtime과 Wasmer가 나란히

거버넌스	Bytecode Alliance, 다중 조직	Wasmer Inc., 상업 출판사
라이센스	LLVM 예외가 있는 Apache-2.0	MIT
구현 언어	녹	녹
컴파일러	Cranelift(윈치 옵션, Aurabase에서는 활성화되지 않음)	싱글패스, Cranelift, LLVM 선택
WASI 표준	WASI 미리보기 2 + 구성요소 모델	WASI Preview 2 + WASIX(WASmer 전용 확장 프로그램)
런닝 영상	연료 + 에포크별 인터럽트(검증된 네이티브 API)	Wasmer와 관련된 메커니즘(여기에서는 확인되지 않음)
Aurabase에서 사용	예, Aura-Functions, 버전 43 고정됨	아니요, 종속성 없음, 직접 또는 전이적

출처: Aurabase 저장소의 Cargo.toml 및 wasm/mod.rs, 2026년 8월 24일에 직접 확인됨. 일반적인 Wasmtime 및 Wasmer 특성은 각 프로젝트의 공개 문서에서 가져왔습니다. 이 표에는 타사 벤치마크 수치가 다시 게시되지 않습니다.

결정

누가 무엇을 선택해야 하는가

기존 종속성 없이 새 에지 런타임을 시작합니다. 다중 공급업체 기반이 지원하는 Wasmtime은 프로젝트의 미래를 단일 게시자에게 의존하는 위험을 줄여줍니다.

콜드 스타트가 매우 빈번하고 단기간 발생합니다. Wasmer의 Singlepass 백엔드는 덜 최적화된 기계어 코드를 사용하여 거의 즉각적인 컴파일로 이러한 요구에 직접적으로 응답합니다.

현재 표준 WASI 이상의 POSIX 기본 요소가 필요합니다. Wasmer 확장인 WASIX는 WASI Preview 2만으로는 아직 다루지 않는 스레드 및 확장 소켓을 다룹니다.

타사 미들웨어 없이 기본 영상 및 시간 제한 API를 원합니다. Wasmtime은 fuel 및 epoch를 상자에 직접 노출합니다. 이는 aura-functions가 Aurabase에서 지원하는 것과 정확히 같습니다.

자주 묻는 질문

자주 묻는 질문

Wasmtime이 Wasmer보다 빠른가요?+

여기에는 비교 성능 수치가 자발적으로 명시되지 않습니다. 두 런타임은 컴파일 속도와 실행 속도 간의 뚜렷한 절충점에 응답하는 서로 다른 컴파일러(Wasmtime의 경우 Cranelift, Wasmer의 경우 Singlepass, Cranelift 또는 LLVM 선택)를 노출합니다. 암호화 및 소스 처리를 위한 WebAssembly 콜드 스타트에 대한 전용 분석을 확인하세요.

동일한 프로젝트에서 Wasmtime과 Wasmer를 사용할 수 있나요?+

기술적으로 그렇습니다. 둘 다 동일한 .wasm 형식을 사용하기 때문입니다. 그러나 이는 통합 표면적, 두 개의 호스트 API, 두 개의 구성 모델을 두 배로 늘리며 대부분의 팀에 대한 순 이익은 없습니다. Aurabase는 aura-function 서비스의 Cargo.toml에서 확인된 하나만 배송합니다.

모든 Aurabase Edge Functions는 Wasmtime에서 실행됩니까?+

아니요. Aurabase Edge Functions의 기본 모드는 별도의 Deno 서비스를 통해 JavaScript/TypeScript를 실행합니다. Wasmtime으로 구동되는 Wasm 모드는 기본 경로가 아닌 기능별로 선택되는 두 번째 실행 경로입니다.

WebAssembly 구성 요소 모델은 실제로 무엇을 제공합니까?+

구성 요소 모델은 런타임에 특정한 바이너리 형식에 의존하지 않고 공유 유형 인터페이스를 사용하여 다양한 언어로 작성된 WASM 모듈의 구성을 표준화합니다. Aurabase의 기본 WASM 모드는 현재 이를 사용하지 않습니다. 이는 구성 요소 모델이 아닌 자체 제작 최소 호스트 ABI입니다.