추상 위키백과/웹어셈블리 노트

이것은 웹어셈블리(이하 WASM), 웹어셈블리 시스템 인터페이스(이하 WASI), 현재 위키함수에 이러한 기술의 통합, 그리고 미래에 탐구할 수 있는 대체 디자인에 대한 일련의 생각에 대한 참고 사항 모음입니다.

WASM, WASI, 정의와 이유

WASM은 어셈블리와 유사한 언어입니다. C 및 Rust를 포함한 여러 프로그래밍 언어의 컴파일 대상으로 지원됩니다. WASM 코드는 대부분의 최신 브라우저에서 실행될 수 있습니다. WASM 런타임을 통해 독립형 애플리케이션으로 실행할 수도 있습니다. WASM 런타임은 여러 가지가 있습니다. 우리는 wasmtime를 시도했지만 지금은 wasmedge만 사용하고 있습니다.

WASI는 WASM이 운영 체제와 상호 작용할 수 있도록 해줍니다. WASM 자체는 파일 읽기/쓰기, 네트워크 연결 등의 일반적인 작업을 위한 일부 기능을 제공합니다. 이 기능은 기본적으로 구현되지는 않지만 OS의 해당 syscall에 명시적으로 연결되어야 합니다. WASI는 특정 시스템 콜에 대한 선택적 액세스를 제공하여 이를 수행합니다. wasmedge에는 대부분의 WASM 런타임과 마찬가지로 WASI 확장이 내장되어 있습니다.

위키함수 실행 프로그램은 현재 WASM 런타임에서 실행됩니다. Security 및 SRE와의 논의 후 추상 위키백과 팀은 임의 코드(이것은 실행자가 수행하도록 만들어진 것입니다) 실행과 관련된 일부 일반적인 공격 벡터를 해결하기 위한 빠르고 비교적 눈에 띄지 않는 방법으로 WASM 런타임을 사용하는 데 동의했습니다. 이것이 완벽한 솔루션은 아니지만 다른 솔루션을 사용하려면 잠재적으로 안전하지 않은 다른 팀(예: AW 평가자 서비스가 루트로 실행될 수 있도록 Blubber를 변경함)의 변경이나 평가자 서비스 자체(예: 실행자를 저렴하고 일시적인 서비스 대신 단일 장기 실행 서비스로 만들고, 비동기 호출을 조정하고, 재시도 논리를 구현하고, 실패 시 실행자 프로세스를 다시 시작하는 등의 변경 사항을 수행합니다.)에 대한 크고 문제가 있는 변경이 필요했을 것입니다. 따라서 WASM은 보안 및 인프라 제약을 준수하는 간단한 해결책으로 합의되었습니다.

현황

파이썬과 자바스크립트 모두 비슷한 패턴으로 결정했습니다. 우리는 소스로부터 각 프로그래밍 언어에 대한 인터프리터를 구축합니다. 인터프리터는 WASM 런타임(이 경우 wasmedge)을 사용하여 실행할 수 있는 .wasm 바이너리입니다. 성능상의 이유로 평가자 서비스 이미지를 구축할 때 해당 바이너리(wasmedge 사용)를 컴파일합니다.

이러한 프로그래밍 언어에 대한 WASM 런타임은 힙스터 구현에서 더 쉽게 찾을 수 있습니다. 따라서 파이썬의 경우 RustPython을 사용합니다(표준 인터프리터는 CPython입니다). 자바스크립트의 경우 (일반적인 V8 대신) QuickJS 엔진을 사용하여 자바스크립트를 구현하는 wasmedge-quickjs를 사용합니다.

미래를 위한 대안과 아이디어(자바스크립트)

quickjs-emscripten

quickjs-emscripten은 신뢰할 수 없는 코드 실행을 위해 특별히 제작되었습니다. 실행 모델은 표면적으로 TensorFlow의 계산 그래프와 유사합니다. QuickJS 인터프리터는 격리된 컨텍스트에서 실행됩니다. 데이터는 전방 선언을 통해 기본 JS 프로세스와 이 컨텍스트 간에 전달됩니다. 그러면 안전한 eval() 함수가 격리된 컨텍스트 내에서 해당 데이터에 대해 임의의 계산을 실행합니다. 그런 다음 반환된 값은 컨텍스트에서 "래핑 해제"되어 기본 프로세스에 표시됩니다.

여기에서 이 접근 방식을 사용하려는 과거 시도를 볼 수 있습니다. 불행하게도 이것은 지원이 거의 없는 상대적으로 모호한 라이브러리이며 WASM 런타임에는 우리가 원하는 보안 프로필이 없기 때문에(적어도 기본적으로는) 이 접근 방식을 포기했습니다.

Javy

Javy은 자바스크립트 코드를 WASM으로 변환하여 작동하며, 이는 wasmedge 또는 다른 WASM 런타임을 통해 실행될 수 있습니다. 따라서 이 접근 방식은 실행기 코드를 WASM으로 직접 변환할 수 있게 함으로써 잠재적으로 더 빨라질 수 있으며 eval() 문에서 커뮤니티 기여 코드만 "천천히" 실행되도록 남겨둡니다.

이 접근 방식은 모듈성 측면에서 약간의 어려움을 겪습니다. 각 모듈은 .wit 파일로 패키징될 것이라고 가정하지만 내보낼 수 있는 항목에는 큰 제한이 있습니다. 특히 모듈은 인수나 반환 값이 있는 함수를 내보낼 수 없습니다. 그러나 속도가 문제가 된다면 Javy를 다시 방문하는 것이 좋습니다. .wit 임포트가 그때까지 성숙되지 않았다면 rollupjs을 사용하여 모듈성 문제를 해결할 수 있습니다.

cloudflare/workerd

Cloudflare의 workerd은 위키함수에서 WASM을 채택하게 된 동기와 동일한 문제를 해결하기 위해 구축되었습니다. 이는 위키함수가 현재 구현하고 있는 것과 정확히 같은 자바스크립트용 서버 측 WASM 런타임입니다. 여기서 잠재적인 이점 중 하나는 workerd가 더 친숙한 V8 엔진을 사용한다는 것입니다(여기에 언급된 다른 솔루션은 QuickJS를 사용합니다). 하지만 workerd는 매우 무거워서 WASM에서 JS를 실행하려는 첫 번째 시도로 통합하려고 하기에는 너무 번거로워 보였습니다.

추가 리소스

QuickJS 사양 및 C API에 대한 이 요약은 매우 도움이 되었습니다.