Rust/WASM Edge Functions 대 Cloudflare 및 Vercel Edge

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

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

그러나 Aurabase의 Rust 코어에 설명된 대로 Aurabase의 기본 모드는 Deno(V8 Isolates도 마찬가지)로 유지됩니다. "Rust의 Edge Functions"는 플랫폼에 따라 세 가지 다른 현실, 즉 Cloudflare 측의 커뮤니티 SDK, Vercel 측의 공식 경로 없음, Aurabase 측의 자체 CLI가 있는 기본 실행 모드를 다룹니다. 이 비교에서는 검증된 것과 플랫폼 목표로 남아 있는 것을 혼합하지 않고 세 가지 아키텍처를 자세히 설명합니다.

필수사항

Aurabase는 deno(V8 Isolates, 전용 서비스, 기본 모드)와 wasm(Rust 컴파일, Wasmtime을 통해 기본적으로 실행)라는 두 가지 Edge Functions 런타임을 제공합니다.
Cloudflare Workers는 V8 격리에서 실행되며 특히 workers-rs커뮤니티 SDK를 통해 WebAssembly도 실행할 수 있습니다. Aurabase의 wasm 모드와 같은 전용 네이티브 Rust 런타임이 아닙니다.
Vercel Edge Functions는 V8 격리에 대한 Node.js API의 하위 집합인 Edge Runtime을 사용합니다. Rust에서 함수 자체를 작성하는 공식 SDK나 CLI가 없습니다.
Aurabase의 wasm 모드는 Wasmtime 연료 CPU 예산, 전용 메모리 제한 및 에포크당 시간 제한을 사용하여 각 실행을 격리하지만 현재 게스트 모듈에 대한 나가는 네트워크 액세스를 노출하지 않습니다.
동일한 목표를 위한 세 가지 다른 아키텍처: 전체 컨테이너 비용 없이 빠르게 시작하고 각 실행을 격리합니다.

맥락

V8 격리 및 WASM 모듈: 두 가지 샌드박싱 메커니즘

V8 격리는 동일한 V8 엔진 내의 경량 JavaScript 실행 컨텍스트입니다. 새로운 시스템 프로세스도 없고 시작할 새로운 커널도 없습니다. 이는 Cloudflare가 Workers를 위해 처음 공개했으며 Vercel이 Edge Runtime에 재사용하는 메커니즘입니다. 목표는 양쪽 모두 동일합니다. 즉, 각 요청에 대한 컨테이너 또는 VM 비용을 피하는 것입니다.

A WebAssembly module meets the same need through a different mechanism. The WASM bytecode runs in a bounded linear memory, defined by the specification itself. The guest module cannot address outside this area, regardless of the source language (Rust, C, Go…) that produced the binary. It is this model that Wasmtime applies in the wasm mode of Aurabase, detailed below. For startup measurements between the two mechanics, see our file on WebAssembly cold start benchmarks.

WASM 런타임

Aurabase wasm 모드가 프로덕션에서 실행되는 것

각 Aurabase 기능은 "wasm" 또는 "deno"가치가 있는 runtime 필드를 전달합니다. 호출 엔진은 이에 따라 실행 경로를 선택합니다.

runtime/dispatch.rsrust

// 런타임에 따른 디스패치: WASM(wasmtime) 또는 Deno(Edge-runtime을 통해 V8 격리)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // aura-edge-runtime에 대한 프록시 — V8 Isolates(supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

샌드박스는 세 가지 Wasmtime 메커니즘을 결합하여 사용합니다. "연료"로 계산되는 CPU 예산: 각 WASM 명령이 이를 소비합니다. 에포크 증분으로 적용되는 시간 초과: 전용 스레드는 구성된 지연 후에 Wasmtime 시계를 증가시켜 현재 실행을 중단합니다. StoreLimits를 통해 설정된 메모리 제한. 엔진이 인스턴스화될 때 세 개의 터미널이 구성됩니다.

runtime/wasm.rsrust

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);

// StoreLimits로 제한된 메모리, 초기 연료 = max_fuel,
// timeout = timeout_secs 이후 에포크 증분(전용 스레드)

컴파일된 모듈은 code_hash에 의해 캐시됩니다. 배포된 동일한 바이너리는 호출할 때마다 다시 컴파일되지 않습니다. 그럼에도 불구하고 각 호출은 새로운 Store 및 인스턴스를 인스턴스화합니다. 한 호출에서 다음 호출로 상태가 누출되지 않습니다. 게스트 모듈에 노출된 표면적은 의도적으로 최소화되어 총 5개의 호스트 기능인 aura.log, aura.get_input, aura.set_output, aura.get_env 및 AssemblyScript 호환성을 위한 스텁 env.abort입니다. 현재로서는 나가는 네트워크 호출을 노출하는 호스트 기능이 없습니다.

검증된 목표와 제품 목표

wasm 모드는 이제 검증, 데이터 변환, 채점, 분석 등 순수 계산에 적합합니다. 타사 API(결제, 이메일, 외부 서비스)를 호출해야 하는 기능은 여전히 deno모드를 거쳐야 합니다. 이는 Aurabase의 기본 모드이며 기존 Deno 코드를 마이그레이션하는 데 권장되는 모드입니다.

배포 측에서 CLI는 보내기 전에 크레이트를 로컬로 컴파일합니다. aura functions new는 크레이트 cdylib을 스캐폴드하고, aura functions deploy는 이를 컴파일한 다음 보냅니다.

terminalbash

# 스캐폴딩: aurabase/functions/<name>/ 생성(Cargo.toml crate-type = cdylib)
aura functions new my-fn

# 화물 빌드 --target wasm32-unknown-unknown --release 후 업로드
# POST /v1/functions/:project_id { 런타임: "wasm", 코드: <base64의 wasm> }
aura functions deploy my-fn

클라우드플레어

Cloudflare Workers: WebAssembly를 추가하여 V8을 격리합니다.

Cloudflare 작업자는 기본적으로 Cloudflare의 글로벌 네트워크에 분산된 V8 격리에서 JavaScript 및 TypeScript를 실행합니다. WebAssembly는 플랫폼 시작부터 일류 시민이었습니다. .wasm 모듈은 다른 모듈과 마찬가지로 작업자로 직접 가져올 수 있습니다.

전체를 Rust로 Worker를 작성하기 위해 가장 많이 사용되는 경로는 코드를 wasm32-unknown-unknown로 컴파일하고 Workers 런타임에서 실행하는 커뮤니티 SDK workers-rs입니다. Aurabase의 wasm 모드와의 차이점은 사용 가능한 표면적입니다. 이 SDK를 통해 Rust로 작성된 작업자는 전체 작업자 환경에서 실행되므로 fetch 또는 기타 플랫폼 바인딩을 호출할 수 있습니다. Aurabase의 wasm 모드는 의도적으로 줄어든 호스트 표면에서 시작됩니다(이전 섹션).

베르셀

Vercel Edge Functions: Node.js 하위 집합, 공식 Rust 경로 없음

Vercel의 Edge Runtime은 또한 전체 Node.js 환경이 아닌 표준 웹 API(fetch, Request/Response, crypto.subtle…)의 하위 집합을 사용하여 V8 격리에서 코드를 실행합니다. 네이티브 노드 모듈과 임의의 컴파일 툴체인은 거기에 없습니다.

WebAssembly 개체는 이 하위 집합의 일부입니다. .wasm 바이너리를 로드하고 JavaScript 또는 TypeScript 함수에서 직접 인스턴스화하는 것을 방해하는 것은 없습니다. 그러나 우리가 아는 바로는 Vercel은 Cloudflare 측의 workers-rs 또는 Aurabase 측의 aura functions deploy와 달리 Rust에서 Edge Function을 직접 작성하기 위한 공식 SDK 또는 CLI를 게시하지 않습니다. 경로는 여전히 가능하지만 전용 도구 없이 완전히 수동입니다.

보안

샌드박스: WASM 선형 메모리와 V8 격리 비교

V8 격리는 동일한 엔진 프로세스 내에서 전용 힙과 자체 컨텍스트에 의해 실행되는 코드를 분리합니다. 이는 Cloudflare 및 Vercel에서 초당 수백만 건의 요청 규모로 입증된 메커니즘이지만 단일 JavaScript 엔진 내에서는 소프트웨어 격리 메커니즘으로 남아 있습니다.

WASM 모델은 다르게 분리됩니다. 각 인스턴스는 실행하는 엔진과 관계없이 바이너리 형식 자체를 구성하여 외부에 액세스할 수 없는 연속 버퍼인 자체 선형 메모리를 갖습니다. Aurabase 런타임에서 게스트 모듈(aura.log, aura.get_env…)이 제공하는 포인터를 조작하는 각 호스트 함수는 메모리 액세스 전에 명시적으로 경계를 다시 검증합니다. 이는 악성 또는 버그가 있는 모듈에 대한 추가 심층 방어입니다.

개요

세 가지 아키텍처를 나란히

	아우라베이스(wasm)	Cloudflare 작업자	Vercel 엣지 기능
실행 모델	기본 WASM 모듈, Wasmtime	V8 + WASM을 옵션 모듈로 분리	V8, Node.js 하위 집합 격리
전경의 녹	예, 전용 모드 + CLI	커뮤니티 SDK(workers-rs)를 통해	아니요, 공식 경로가 없습니다.
모듈을 종료하는 네트워크 액세스	아니요, 코드에서 확인되었습니다(네트워크 호스트 기능 없음).	예, 전체 Workers 환경을 통해	예, 표준 가져오기 API
CPU 예산	연료 Wasmtime, 구성 가능	요청당 CPU 시간 제한(Cloudflare 문서)	소환 당 지속 시간 제한 (doc. Vercel)
전용 Rust 배포	Aura 기능 배포(로컬 화물 빌드)	랭글러 + 노동자 -RS	공식적으로 동등한 도구가 없습니다.

Aurabase 런타임 사양. Cloudflare 및 Vercel 열은 각 플랫폼의 문서화된 공개 아키텍처에서 설명됩니다(V8, WebAssembly를 빌드 대상으로 격리).

결정

기능에 따라 선택할 런타임

네트워크 호출 없는 순수 계산: 스키마 검증, 데이터 변환, 점수 매기기, 경량 이미지 생성. Aurabase의 wasm 모드는 엄격한 메모리 샌드박스, 명시적인 CPU 예산 및 외부 서비스에 대한 의존 없이 직접적으로 적합합니다.

타사 API(결제, 이메일, 발신 웹훅)를 호출하는 함수입니다. Aurabase의 deno 모드는 기존 Cloudflare Worker 또는 Vercel Edge Function이 기본적으로 fetch를 사용하는 것과 같은 방식으로 오늘날에도 기본 선택으로 남아 있습니다.

팀은 이미 Cloudflare 생태계(KV, 내구성 개체, R2)에 투자했습니다. Workers를 유지하는 것이 합리적입니다. workers-rs를 사용하면 플랫폼을 변경하지 않고도 Rust를 점진적으로 도입할 수 있습니다.

Need a native Rust runtime managed end-to-end, with a dedicated CLI and the same language as the rest of the backend. This is the angle that documents in our Wasmtime vs Wasmer comparison, on the choice of the WebAssembly engine itself.

자주 묻는 질문

자주 묻는 질문

Rust에서 Aurabase Edge Functions를 작성할 수 있습니까?+

예, wasm 모드를 통해 가능합니다. CLI에는 Rust 상자(상자 유형 cdylib)를 새로운 기반으로 하는 기능이 있습니다. aura 함수 배포 명령은 이를 화물 빌드 --target wasm32-unknown-unknown --release를 사용하여 로컬로 컴파일한 다음 바이너리를 aura-functions 서비스로 전송합니다. 이 서비스는 기본적으로 Wasmtime 런타임으로 실행합니다. 이는 기본 모드가 아닙니다. 기본적으로 Aurabase Edge Function은 JavaScript/TypeScript(Deno 런타임, V8 Isolates)에서 실행됩니다.

Cloudflare Workers를 사용하면 실제로 Rust로 함수를 작성할 수 있나요?+

예, 하지만 간접적으로: Cloudflare Workers는 기본적으로 V8 격리에서 JavaScript/TypeScript를 실행합니다. Worker-rs 커뮤니티 SDK를 사용하면 Rust의 전체 Worker를 WebAssembly로 컴파일할 수 있지만 이는 가장 공식적으로 문서화된 경로는 아닙니다. WASM은 JS 모델을 완전히 대체하는 대신 작업자를 보완합니다.

Vercel Edge Functions는 기본적으로 WebAssembly 또는 Rust를 지원합니까?+

Vercel Edge Runtime은 WebAssembly 객체를 포함한 표준 웹 API를 노출하므로 JavaScript/TypeScript 함수에서 .wasm 모듈을 수동으로 로드하고 인스턴스화할 수 있습니다. 그러나 우리가 아는 바로는 Vercel은 Cloudflare 측의 Workers-RS나 Aurabase 측에 배포되는 aura 함수와 달리 Rust에서 직접 Edge 함수를 작성하기 위한 공식 SDK나 CLI를 게시하지 않습니다.

Aurabase wasm 모드는 타사 API(결제, 이메일 등)를 호출할 수 있나요?+

현재는 아닙니다. 게스트 WASM 모듈에 노출되는 호스트 기능은 로그, 입력 요청 읽기, 출력 응답 쓰기, 환경 변수 읽기입니다. 외부 API(네트워크 가져오기)를 호출해야 하는 함수의 경우 Deno 런타임(기본값)이 권장 경로입니다.