article

WebAssembly 기술 동향

📊 4.82K (4.017K/210KW) ⏱ 8 mins

WebAssembly (WASM)

웹어셈블리(WebAssembly 또는 Wasm)는 다양한 프로그래밍 언어와 많은 실행 환경 사이의 중간 계층으로, 30여 가지 이상의 언어로 작성된 코드를 .wasm 파일로 컴파일한 다음 브라우저나 다른 실행 환경에서 실행할 수 있다. 원래 웹에서 코드 실행 속도를 높이기 위해 개발되었지만 이제는 브라우저 이외의 다양한 환경에서도 실행할 수 있다.

WebAssembly는 발표된 시점에 비해 널리 사용되지 않았는데, 우선 언어 간 상호 호환성, 부족한 개발자 경험이 문제가 있었다. 또한 WebAssembly라는 이름 자체가 웹이나 어셈블리에 국한되지 않는데, Web이란 키워드를 쓰면서 잘못된 인상을 주었다.

이에 ’19년 모질라, 레드햇, 인텔, Fastly. 등의 회사들이 커뮤니티를 (Bytecode Alliance) 구축하였고, 브라우저를 벗어난 웹어셈블리 런타임에 대한 표준과 도구를 개발을 시작하였다. 현재 WASI (WebAssembly System Interface)를 구현한 WASM 런타임을 제공하고 있다.

특징

  • 이식성 (Portable) - 한번 빌드하면 여러 플랫폼에서 활용가능
  • 범용성 (Universal) - 많은 언어가 WASM으로 컴파일 가능
  • 빠른 시작 시간 - Docker보다 10~100x 빠른 시작시간
  • 안전성 (Secure) - 메모리 샌드박싱, 기능 제한
  • 성능 - 네이티브에 가까운 성능 (1.5배 느림), JavaScript 보다는 항상 빠름

적용 예

웹어셈블리의 적용 범위는 컨테이너화, 플러그인 시스템, 서버리스 컴퓨팅 플랫폼 등 기술 영역에서의 활발한 활용된다. 또한, 보안 측면에서도 샌드박스화된 외부 라이브러리의 안전한 실행, 제한된 권한 시스템, 그리고 라이브러리 격리 능력 등이 포함된다.

WASI (WebAssembly System Interface)

WASI(WebAssembly System Interface)는 웹 어셈블리 애플리케이션이 호스트 시스템과 상호 작용할 수 있도록 하는 표준 인터페이스이다. 이를 통해 웹 어셈블리 애플리케이션은 파일 시스템, 네트워킹 등의 시스템 리소스에 접근하도록 되었다.

WASI가 등장하기 이전에는 Emscripten이 사용되었으며 자체적으로 JavaScript layer와 WASM layer로 구성해 브라우저와 통신해서 시스템 기능을 사용하였다. de-facto 표준으로 다뤄지나 속도나, Private API 사용등의 문제가 있다. (https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/)

WASI 사용 모듈과 Node.js 모듈 비교

  • Portability: WASM 모듈은 Write one time, Use everywhere이 고려되었다. Node.js Native 모듈이 환경마다 node-gyp를 통해 빌들을 수행하는 것에 비해 한번 빌드된 형태로 그대로 배포가 가능하다.

  • Security: Capability-based security 전략을 사용한다. "권한이 프로그램 단위가 아니라 모듈 단위"로 이루어지고, 모듈 단위로 전파될 때 권한에 대한 수정도 가능하다. Node.js에서도 Permission 모델이 구축되고 있지만, 런타임 단위의 보안을 제공하고 모듈 단위의 제어는 불가하다. (관련된 Node.js 해킹사례: electron-native-notify NPM 모듈의 ZipSlip)

Capability-based security 전략에서 각각의 개체(사용자, 프로세스, 모듈 등)는 자신이 필요로 하는 특정한 능력을 가지고 있어야만 특정 능력을 수행할 수 있다. 예를 들어, 파일에 액세스해야 하는 함수를 호출하는 경우, 해당 함수는 파일에 대한 적절한 권한이 부여된 능력을 가진 객체에게만 실행되도록 할 수 있다. 이를 통해 권한이 필요한 동작을 수행하는 데 필요한 최소한의 권한만 부여할 수 있게 되며, 보안을 강화할 수 있다.

3rd party NPM 모듈 Vulnerability를 보장할 수 없기 때문에 Node.js 런타임은 실제 Production 에서 사용되기기 어렵다. 이에 비해 WASM 모듈은 WASI 인터페이스가 Sandboxing을 고려하여 설계되어있다.

표준화

현재 WASI의 모든 API는 Proposal 단계 (Phase 2) 이다. 아직 실험적 상태에고 인터페이스가 변경이 가능함을 의미한다. 자세한 현황은 https://github.com/WebAssembly/WASI/blob/main/Proposals.md 를 참조할 수 있다.

WASM Runtime 현황

브라우저 외부에서 WASM을 사용할 수 있는 Runtime은 다음과 같다.

Containerization

서버 어플리케이션 배포에 용이한 Docker에 비해 WASM은 콜드 스타트 ​​시간이 10~100배 빠르며 메모리 사용량이 적고 뛰어난 보안 모델을 채용하고 있다. 컨테이너가 아닌 WASM 모듈이 연산 및 배포의 최소 단위가 될 가능성이 높으나, 한번에 Docker를 완전히 대체하지는 않고 기존 오케스트레이션 시스템에 통합되는 형태로 진행될 것이라 예측된다.

이러한 흐름과 별개의 Containerization 기술은 아래와 같다.

Lightweight Virtualization

Lightweight Virtualization은 전통적인 가상화 기술과는 다르게 더 가벼운 방식으로 가상화를 구현하는 기술을 말한다. 더 적은 오버헤드와 빠른 부팅 시간을 제공하면서도 격리와 보안을 유지한다. AWS Firecracker가 이러한 Lightweight Virtualization 기술의 한 예로, 멀티 테넌시 환경에서 안전하게 컨테이너를 실행하도록 되어있다. KVM(Kernel-based Virtual Machine)을 기반으로 하며, 커널 기능을 최소화하여 경량화된 가상화를 제공한다.

JavaScript Container

JavaScript Container는 Node.js의 한계와 함께 등장한 새로운 개념으로, 브라우저 API 디자인 개념을 공유함으로써 웹 개발자들이 JavaScript 런타임을 사용할 때 배워야 할 개념을 줄일 수 있는 장점을 갖는다. 또, 메모리 사용량보다는 인스턴스 사용 시간이 중요한 Serverless 환경에서 빠른 재구동 시간을 제공하여 비용을 절감할 수 있다. 기존의 Microservice 아키텍처를 더 작은 단위의 컴포넌트로 분리하는 새로운 애플리케이션 아키텍처 구축이 가능하다. (Linux Container를 대체하는 것이 아니라 고성능 및 경량을 요구하는 일부 분야에서 광범위한 애플리케이션 적용 예상)

References

Share