다른 언어로 작성된 멀티스레드 애플리케이션을 WebAssembly로 가져오는 방법을 알아봅니다.
WebAssembly 스레드 지원은 WebAssembly에 추가된 가장 중요한 성능 기능 중 하나입니다. 코드의 일부를 별도의 코어에서 병렬로 실행하거나 입력 데이터의 독립적인 부분에 동일한 코드를 실행하여 사용자가 보유한 코어 수만큼 확장하여 전체 실행 시간을 크게 줄일 수 있습니다.
이 도움말에서는 WebAssembly 스레드를 사용하여 C, C++, Rust와 같은 언어로 작성된 멀티스레드 애플리케이션을 웹에 가져오는 방법을 알아봅니다.
WebAssembly 스레드 작동 방식
WebAssembly 스레드는 별도의 기능이 아니라 WebAssembly 앱이 웹에서 기존 멀티스레딩 패러다임을 사용할 수 있도록 하는 여러 구성요소의 조합입니다.
웹 작업자
첫 번째 구성요소는 자바스크립트에서 즐겨 사용하는 일반적인 작업자입니다. WebAssembly 스레드는 new Worker 생성자를 사용하여 새로운 기본 스레드를 만듭니다. 각 스레드가 JavaScript 글루를 로드하면 기본 스레드가 Worker#postMessage 메서드를 사용하여 컴파일된 WebAssembly.Module뿐만 아니라 공유된 WebAssembly.Memory(아래 참조)를 이러한 다른 스레드와 공유합니다. 이렇게 하면 통신이 설정되고 이러한 모든 스레드가 JavaScript를 다시 거치지 않고 동일한 공유 메모리에서 동일한 WebAssembly 코드를 실행할 수 있습니다.
웹 작업자는 10년 이상 사용되어 왔으며 광범위하게 지원되며 특수 플래그가 필요하지 않습니다.
SharedArrayBuffer
WebAssembly 메모리는 JavaScript API에서 WebAssembly.Memory 객체로 표현됩니다. 기본적으로 WebAssembly.Memory는 단일 스레드만 액세스할 수 있는 원시 바이트 버퍼인 ArrayBuffer를 둘러싼 래퍼입니다.
> new WebAssembly.Memory({ initial:1, maximum:10 }).buffer
ArrayBuffer { … }
멀티스레딩을 지원하기 위해 WebAssembly.Memory도 공유 변형을 얻었습니다. JavaScript API를 통해 shared 플래그 또는 WebAssembly 바이너리 자체로 생성된 경우, 대신 SharedArrayBuffer를 둘러싼 래퍼가 됩니다. 이는 ArrayBuffer의 변형으로, 다른 스레드와 공유할 수 있고 한쪽에서 동시에 읽거나 수정할 수 있습니다.
> new WebAssembly.Memory({ initial:1, maximum:10, shared:true }).buffer
SharedArrayBuffer { … }
일반적으로 기본 스레드와 웹 작업자 간의 통신에 사용되는 postMessage와 달리 SharedArrayBuffer는 데이터를 복사하거나 이벤트 루프가 메시지를 보내고 받을 때까지 기다릴 필요도 없습니다.
대신 모든 변경사항이 거의 즉시 모든 스레드에 표시되므로 기존 동기화 프리미티브의 컴파일 타겟에 훨씬 더 적합합니다.
SharedArrayBuffer에는 복잡한 역사가 있습니다. 처음에는 2017년 중반에 여러 브라우저에서 제공되었지만, 스펙터 취약점이 발견되어 2018년 초에 사용 중지해야 했습니다. 특히 스펙터의 데이터 추출은 특정 코드의 실행 시간을 측정하는 타이밍 공격을 사용하기 때문입니다. 이러한 종류의 공격을 더 어렵게 만들기 위해 브라우저는 Date.now 및 performance.now와 같은 표준 타이밍 API의 정밀도를 낮췄습니다. 그러나 공유 메모리와 별도의 스레드에서 실행되는 간단한 카운터 루프를 함께 사용하는 것도 정밀도가 높은 타이밍을 얻을 수 있는 매우 안정적인 방법이며 런타임 성능을 크게 제한하지 않고는 완화하기가 훨씬 더 어렵습니다.
대신 Chrome 68 (2018년 중반)에서는 사이트 격리를 활용하여 SharedArrayBuffer를 다시 사용 설정했습니다. 사이트 격리는 서로 다른 웹사이트를 여러 프로세스에 배치하고 스펙터와 같은 부채널 공격을 훨씬 더 어렵게 만드는 기능입니다. 그러나 사이트 격리는 비용이 많이 드는 기능이며 메모리 용량이 낮은 휴대기기의 모든 사이트에서 기본적으로 사용 설정할 수 없었고 다른 공급업체에서 아직 구현하지도 않았으므로 이 완화 조치는 여전히 Chrome 데스크톱으로만 제한되었습니다.
2020년까지 Chrome과 Firefox 모두 사이트 격리를 구현하고 웹사이트에서 COOP 및 COEP 헤더를 사용하여 이 기능을 선택할 수 있는 표준 방법을 제공합니다. 수신 동의 메커니즘을 사용하면 사이트 격리를 모든 웹사이트에 사용 설정하는 데 비용이 너무 많이 드는 저전력 기기에서도 사이트 격리를 사용할 수 있습니다. 선택하려면 서버 구성의 기본 문서에 다음 헤더를 추가하세요.
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
선택하면 SharedArrayBuffer (SharedArrayBuffer에서 지원하는 WebAssembly.Memory 포함), 정확한 타이머, 메모리 측정, 보안상의 이유로 격리된 출처가 필요한 기타 API에 액세스할 수 있습니다. 자세한 내용은 COOP 및 COEP를 사용하여 웹사이트를 '교차 출처 분리'로 만들기를 참고하세요.
WebAssembly 원자적 구조
SharedArrayBuffer를 사용하면 각 스레드가 동일한 메모리에 읽고 쓸 수 있지만 올바른 통신을 위해서는 충돌하는 작업을 동시에 실행하지 않도록 해야 합니다. 예를 들어 한 스레드가 공유 주소에서 데이터 읽기를 시작하고 다른 스레드가 여기에 쓰기를 시작할 수 있으므로 이제 첫 번째 스레드는 손상된 결과를 얻게 됩니다. 이 버그 카테고리를 경합 상태라고 합니다. 경합 상태를 방지하려면 이러한 액세스를 동기화해야 합니다.
여기에서 원자적 작업이 사용됩니다.
WebAssembly 원자적 연산은 작은 데이터 셀(일반적으로 32비트 및 64비트 정수)을 '원자적으로' 읽고 쓸 수 있는 WebAssembly 명령 집합의 확장 프로그램입니다. 즉, 두 개의 스레드가 동시에 같은 셀을 읽거나 여기에 쓰지 않도록 보장하여 낮은 수준에서 이러한 충돌을 방지합니다. 또한 WebAssembly 원자적 연산에는 두 개의 명령 종류인 'wait'와 'notify'가 추가로 포함됩니다. 이 명령은 다른 스레드가 'notify'를 통해 절전 모드를 해제할 때까지 공유 메모리의 주어진 주소에서 한 스레드가 절전 모드 ('대기')를 하도록 허용합니다.
채널, 뮤텍스, 읽기-쓰기 잠금을 비롯한 모든 상위 수준의 동기화 프리미티브는 이러한 명령을 기반으로 빌드됩니다.
WebAssembly 스레드 사용 방법
기능 감지
WebAssembly 원자적 구조와 SharedArrayBuffer는 상대적으로 새로운 기능으로, WebAssembly가 지원되는 일부 브라우저에서는 아직 사용할 수 없습니다. 새로운 WebAssembly 기능을 지원하는 브라우저는 webassembly.org 로드맵에서 확인할 수 있습니다.
모든 사용자가 애플리케이션을 로드할 수 있도록 하려면 두 가지 Wasm 버전(멀티스레딩 지원 버전과 지원되지 않는 버전)을 빌드하여 점진적인 개선을 구현해야 합니다. 그런 다음 특성 감지 결과에 따라 지원되는 버전을 로드합니다. 런타임 시 WebAssembly 스레드 지원을 감지하려면 Wasm-feature-detect 라이브러리를 사용하고 다음과 같이 모듈을 로드합니다.
import { threads } from 'wasm-feature-detect';
const hasThreads = await threads();
const module = await (
hasThreads
? import('./module-with-threads.js')
: import('./module-without-threads.js')
);
// …now use `module` as you normally would
이제 WebAssembly 모듈의 멀티스레드 버전을 빌드하는 방법을 살펴보겠습니다.
C
C, 특히 Unix와 유사한 시스템에서 스레드를 사용하는 일반적인 방법은 pthread 라이브러리에서 제공되는 POSIX 스레드를 통해 사용하는 것입니다. Emscripten은 웹 작업자, 공유 메모리, 원자적 요소를 기반으로 빌드된 pthread 라이브러리의 API 호환 구현을 제공하므로 변경 없이 웹에서 동일한 코드를 사용할 수 있습니다.
예를 살펴보겠습니다.
example.c:
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
void *thread_callback(void *arg)
{
sleep(1);
printf("Inside the thread: %d\n", *(int *)arg);
return NULL;
}
int main()
{
puts("Before the thread");
pthread_t thread_id;
int arg = 42;
pthread_create(&thread_id, NULL, thread_callback, &arg);
pthread_join(thread_id, NULL);
puts("After the thread");
return 0;
}
여기서 pthread 라이브러리의 헤더는 pthread.h를 통해 포함됩니다. 스레드를 처리하기 위한 몇 가지 중요한 함수도 확인할 수 있습니다.
pthread_create는 백그라운드 스레드를 만듭니다. 스레드 핸들을 저장할 대상, 일부 스레드 생성 속성 (여기서는 아무것도 전달하지 않으므로 NULL), 새 스레드에서 실행될 콜백 (여기서 thread_callback), 기본 스레드에서 일부 데이터를 공유하려는 경우 콜백에 전달할 선택적 인수 포인터를 사용합니다. 이 예에서는 변수 arg의 포인터를 공유합니다.
pthread_join는 스레드가 실행을 완료하고 콜백에서 반환된 결과를 가져오기 위해 언제든지 나중에 호출할 수 있습니다. 이전에 할당된 스레드 핸들과 결과를 저장할 포인터를 허용합니다. 이 경우에는 결과가 없으므로 함수에서 NULL를 인수로 사용합니다.
Emscripten으로 스레드를 사용하여 코드를 컴파일하려면 다른 플랫폼에서 Clang 또는 GCC로 동일한 코드를 컴파일할 때처럼 emcc를 호출하고 -pthread 매개변수를 전달해야 합니다.
emcc -pthread example.c -o example.js
그러나 브라우저나 Node.js에서 실행하려고 하면 경고가 표시되고 프로그램이 중단됩니다.
Before the thread
Tried to spawn a new thread, but the thread pool is exhausted.
This might result in a deadlock unless some threads eventually exit or the code
explicitly breaks out to the event loop.
If you want to increase the pool size, use setting `-s PTHREAD_POOL_SIZE=...`.
If you want to throw an explicit error instead of the risk of deadlocking in those
cases, use setting `-s PTHREAD_POOL_SIZE_STRICT=2`.
[…hangs here…]
어떻게 되었을까요? 문제는 웹에서 시간이 많이 걸리는 대부분의 API가 비동기식이며 이벤트 루프를 사용하여 실행된다는 점입니다. 이러한 제한은 애플리케이션이 일반적으로 동기식 차단 방식으로 I/O를 실행하는 기존 환경과 비교하여 중요한 차이점입니다. 자세한 내용은 WebAssembly에서 비동기 웹 API 사용에 관한 블로그 게시물을 참고하세요.
이 경우 코드는 동기식으로 pthread_create를 호출하여 백그라운드 스레드를 만들고 백그라운드 스레드가 실행을 완료할 때까지 기다리는 pthread_join에 관한 또 다른 동기식 호출이 이어집니다. 그러나 이 코드가 Emscripten으로 컴파일될 때 백그라운드에서 사용되는 Web Worker는 비동기식입니다. 그러면 pthread_create는 다음 이벤트 루프 실행 시 새 작업자 스레드가 생성되도록 예약하기만 하고 pthread_join는 즉시 이벤트 루프를 차단하여 해당 worker를 기다리며, 이렇게 하면 이벤트가 생성되지 않습니다. 교착 상태의 일반적인 예입니다.
이 문제를 해결하는 한 가지 방법은 프로그램이 시작되기 전에 작업자 풀을 미리 만드는 것입니다. pthread_create가 호출되면 풀에서 즉시 사용 가능한 작업자를 가져와 백그라운드 스레드에서 제공된 콜백을 실행하고 작업자를 풀로 반환할 수 있습니다. 이 모든 작업은 동기식으로 실행할 수 있으므로 풀이 충분히 큰 한 교착 상태가 발생하지 않습니다.
바로 이것이 Emscripten에서 -s
PTHREAD_POOL_SIZE=... 옵션과 함께 사용할 수 있는 기능입니다. 이 API를 사용하면 스레드 수(고정된 숫자 또는 navigator.hardwareConcurrency과 같은 자바스크립트 표현식)를 지정하여 CPU의 코어 수만큼 스레드를 만들 수 있습니다. 후자의 옵션은 코드를 임의의 스레드 수로 확장할 수 있는 경우에 유용합니다.
위 예에서는 스레드가 하나만 생성되므로 모든 코어를 예약하는 대신 -s PTHREAD_POOL_SIZE=1를 사용하면 됩니다.
emcc -pthread -s PTHREAD_POOL_SIZE=1 example.c -o example.js
이번에는 성공적으로 실행됩니다.
Before the thread
Inside the thread: 42
After the thread
Pthread 0x701510 exited.
하지만 또 다른 문제가 있습니다. 코드 예에서 sleep(1)가 표시되나요? 스레드 콜백에서 실행됩니다. 즉, 기본 스레드 밖에서 실행되므로 괜찮습니다. 맞습니까? 그렇지 않습니다.
pthread_join가 호출되면 스레드 실행이 완료될 때까지 기다려야 합니다. 즉, 생성된 스레드가 장기 실행 작업(이 경우 1초 절전 모드)을 실행하는 경우 기본 스레드도 결과가 반환될 때까지 동일한 시간 동안 차단해야 합니다. 이 JS가 브라우저에서 실행되면 스레드 콜백이 반환될 때까지 UI 스레드를 1초 동안 차단합니다. 이로 인해 사용자 경험이 저하됩니다.
이에 대한 몇 가지 해결책은 다음과 같습니다.
pthread_detach-s PROXY_TO_PTHREAD- 커스텀 작업자 및 Comlink
pthread_detach
먼저 기본 스레드에서 일부 작업만 실행해야 하지만 결과를 기다릴 필요는 없다면 pthread_join 대신 pthread_detach를 사용하면 됩니다. 이렇게 하면 스레드 콜백이 백그라운드에서 실행됩니다. 이 옵션을 사용하는 경우 -s
PTHREAD_POOL_SIZE_STRICT=0로 경고를 사용 중지할 수 있습니다.
PROXY_TO_PTHREAD
둘째, 라이브러리가 아닌 C 애플리케이션을 컴파일하는 경우 -s
PROXY_TO_PTHREAD 옵션을 사용할 수 있습니다. 이 옵션은 애플리케이션 자체에서 생성된 중첩 스레드 외에도 기본 애플리케이션 코드를 별도의 스레드로 오프로드합니다. 이렇게 하면 UI를 정지하지 않고도 기본 코드를 언제든지 안전하게 차단할 수 있습니다.
또한 이 옵션을 사용할 때는 스레드 풀을 미리 만들 필요가 없습니다. 대신 Emscripten에서 기본 스레드를 활용하여 새 기본 작업자를 만든 다음 교착 상태 없이 pthread_join에서 도우미 스레드를 차단할 수 있습니다.
Comlink
셋째, 라이브러리에서 작업 중이며 여전히 차단해야 한다면 자체 Worker를 만들고 Emscripten에서 생성된 코드를 가져온 다음 Comlink를 사용하여 기본 스레드에 노출할 수 있습니다. 기본 스레드는 내보낸 메서드를 비동기 함수로 호출할 수 있으며 이렇게 하면 UI 차단도 방지됩니다.
위의 예와 같은 간단한 애플리케이션에서는 -s PROXY_TO_PTHREAD가 가장 적합한 옵션입니다.
emcc -pthread -s PROXY_TO_PTHREAD example.c -o example.js
C++
모든 동일한 주의사항과 로직은 C++에서도 동일한 방식으로 적용됩니다. 새로 얻게 되는 유일한 점은 이전에 논의한 pthread 라이브러리를 내부적으로 사용하는 std::thread 및 std::async와 같은 상위 수준 API에 액세스하는 것입니다.
따라서 위의 예는 다음과 같이 더 관용적인 C++로 다시 작성할 수 있습니다.
example.cpp:
#include <iostream>
#include <thread>
#include <chrono>
int main()
{
puts("Before the thread");
int arg = 42;
std::thread thread([&]() {
std::this_thread::sleep_for(std::chrono::seconds(1));
std::cout << "Inside the thread: " << arg << std::endl;
});
thread.join();
std::cout << "After the thread" << std::endl;
return 0;
}
유사한 매개변수로 컴파일되고 실행되면 C 예와 동일한 방식으로 작동합니다.
emcc -std=c++11 -pthread -s PROXY_TO_PTHREAD example.cpp -o example.js
Output:
Before the thread
Inside the thread: 42
Pthread 0xc06190 exited.
After the thread
Proxied main thread 0xa05c18 finished with return code 0. EXIT_RUNTIME=0 set, so
keeping main thread alive for asynchronous event operations.
Pthread 0xa05c18 exited.
Rust
Emscripten과 달리 Rust에는 특수한 엔드 투 엔드 웹 타겟이 없으며 대신 일반 WebAssembly 출력을 위한 일반적인 wasm32-unknown-unknown 타겟을 제공합니다.
Wasm을 웹 환경에서 사용할 목적인 경우 JavaScript API와의 모든 상호작용은 Wasm-bindgen 및 wasm-pack과 같은 외부 라이브러리 및 도구에서 수행됩니다. 즉, 표준 라이브러리는 웹 워커를 인식하지 못하며 std::thread와 같은 표준 API는 WebAssembly에 컴파일할 때 작동하지 않습니다.
다행히 생태계 대부분은 멀티스레딩을 처리하기 위해 상위 수준의 라이브러리에 의존합니다. 이 수준에서는 플랫폼의 모든 차이를 훨씬 쉽게 추상화할 수 있습니다.
특히 Rayon은 Rust에서 데이터 동시 로드에 가장 많이 사용됩니다. 이를 통해 일반 반복자에서 메서드 체인을 가져올 수 있으며 일반적으로 한 줄만 변경하면 순차적이지 않고 사용 가능한 모든 스레드에서 병렬로 실행되는 방식으로 변환할 수 있습니다. 예를 들면 다음과 같습니다.
pub fn sum_of_squares(numbers: &[i32]) -> i32 {
numbers
.iter()
.par_iter()
.map(|x| x * x)
.sum()
}
이 작은 변경으로 코드는 입력 데이터를 분할하고 병렬 스레드에서 x * x와 부분 합계를 계산한 후 이러한 부분 결과를 함께 더합니다.
std::thread가 작동하지 않는 플랫폼을 지원하기 위해 Rayon은 스레드 생성 및 종료를 위한 맞춤 로직을 정의할 수 있는 후크를 제공합니다.
Wasm-bindgen-rayon이 이러한 후크를 활용하여 WebAssembly 스레드를 웹 작업자로 생성합니다. 사용하려면 종속 항목으로 추가하고 docs에 설명된 구성 단계를 따라야 합니다. 위의 예시는 다음과 같이 표시됩니다.
pub use wasm_bindgen_rayon::init_thread_pool;
#[wasm_bindgen]
pub fn sum_of_squares(numbers: &[i32]) -> i32 {
numbers
.par_iter()
.map(|x| x * x)
.sum()
}
완료되면 생성된 JavaScript가 추가 initThreadPool 함수를 내보냅니다. 이 함수는 작업자 풀을 만들고 Rayon에서 실행하는 모든 멀티스레드 작업에 프로그램의 전체 기간 동안 재사용합니다.
이 풀 메커니즘은 앞에서 설명한 Emscripten의 -s PTHREAD_POOL_SIZE=... 옵션과 유사하며 교착 상태를 방지하려면 기본 코드보다 먼저 초기화해야 합니다.
import init, { initThreadPool, sum_of_squares } from './pkg/index.js';
// Regular wasm-bindgen initialization.
await init();
// Thread pool initialization with the given number of threads
// (pass `navigator.hardwareConcurrency` if you want to use all cores).
await initThreadPool(navigator.hardwareConcurrency);
// ...now you can invoke any exported functions as you normally would
console.log(sum_of_squares(new Int32Array([1, 2, 3]))); // 14
기본 스레드 차단에 관한 동일한 주의사항이 여기에도 적용됩니다. sum_of_squares 예도 다른 스레드의 부분 결과를 기다리도록 기본 스레드를 여전히 차단해야 합니다.
반복자의 복잡성과 사용 가능한 스레드 수에 따라 매우 짧은 대기 또는 긴 대기일 수 있지만 안전을 위해 브라우저 엔진은 기본 스레드 차단을 적극적으로 방지하며 이러한 코드는 오류를 발생시킵니다. 대신 작업자를 만들고 wasm-bindgen에서 생성된 코드를 가져온 다음 Comlink와 같은 라이브러리와 함께 API를 기본 스레드에 노출해야 합니다.
다음을 보여주는 엔드 투 엔드 데모는 wasm-bindgen-rayon 예를 확인하세요.
- 스레드의 특징 감지.
- 동일한 Rust 앱의 단일 및 멀티 스레드 버전 빌드
- Worker에서 wasm-bindgen이 생성한 JS+Wasm 로드.
- wasm-bindgen-rayon을 사용하여 스레드 풀을 초기화합니다.
- Comlink를 사용하여 기본 스레드에 Worker의 API를 노출합니다.
실제 사용 사례
Google은 클라이언트 측 이미지 압축을 위해 Squoosh.app의 WebAssembly 스레드를 적극적으로 사용하고 있습니다. 특히 AVIF(C++), JPEG-XL(C++), OxiPNG(Rust) 및 WebP v2(C++)와 같은 형식의 경우
Google 어스는 웹 버전에 WebAssembly 스레드를 사용하는 또 다른 유용한 서비스입니다.
FFMPEG.WASM은 널리 사용되는 FFmpeg 멀티미디어 도구 모음의 WebAssembly 버전으로, WebAssembly 스레드를 사용하여 브라우저에서 직접 동영상을 효율적으로 인코딩합니다.
이 밖에도 WebAssembly 스레드를 사용하는 흥미로운 예가 많이 있습니다. 데모를 확인하고 나만의 멀티스레드 애플리케이션과 라이브러리를 웹에 가져오는 것도 잊지 마세요.