WASM a zimne uruchomienie kontenera: co mówią środowiska wykonawcze

Zimny ​​start odnosi się do dodatkowego opóźnienia wymaganego przez żądanie, gdy środowisko wykonawcze musi zostać zainicjowane przed uruchomieniem kodu aplikacji. W przypadku klasycznej funkcji brzegowej lub funkcji bezserwerowej nie jest to przypadek marginalny: platforma, która ogranicza liczbę wystąpień pomiędzy dwoma szczytami ruchu lub rozdziela swoje wykonanie na dziesiątki geograficznie rozproszonych węzłów brzegowych, płaci ten koszt trwale, a nie tylko przy pierwszym wdrożeniu.

Temat nabrał niemal symbolicznego znaczenia w ekosystemie WASM od czasu, gdy w marcu 2019 roku na Twitterze pojawiło się zdanie Solomona Hykesa, współzałożyciela Dockera: „Gdyby WASM+WASI istniało w 2008 roku, nie musielibyśmy tworzyć Dockera. Takie to ważne. WebAssembly na serwerze to przyszłość informatyki. » To opinia uznanego praktyka, a nie pomiar. Wyjaśnia, dlaczego temat fascynuje, nie zastępuje figury źródłowej.

Aurabase oferuje dwie ścieżki dla swoich funkcji brzegowych: edytor Studio, który uruchamia kod w środowisku wykonawczym Deno, jak udokumentowaliśmy w naszym przewodniku migracji Supabaseoraz aura functions deployCLI, którego celem jest osobna ścieżka dla funkcji napisanych w Rust i skompilowanych do WASM w Wasmtime. To właśnie tę drugą ścieżkę niniejszy artykuł rzuca światło na tę drugą ścieżkę, nie podając jej jednak danych na temat zimnego startu, które jeszcze nie istnieją.

Różnica nie wynika z szybszego czasu działania w wartościach bezwzględnych: wynika z krótszego stosu kroków między zapytaniem a kodem aplikacji.

Uruchomienie kontenera mobilizuje jądro hosta: utworzenie nowego procesu, skonfigurowanie grup c i przestrzeni nazw, które go izolują, zamontowanie warstw obrazu, a następnie uruchomienie wewnątrz środowiska wykonawczego aplikacji (na przykład Node.js i jego silnik V8 mają koszt inicjalizacji). Każdy krok dodaje wywołania systemowe, a w przypadku obrazu nigdy nie widzianego lokalnie, pobieranie sieciowe jeszcze przed jego rozpoczęciem.

Moduł WebAssembly jest izolowany na poziomie języka maszyny wirtualnej, a nie na poziomie systemu operacyjnego. Utworzenie instancji modułu oznacza przydzielenie jego pamięci liniowej, powiązanie importów, a następnie przejście do punktu wejścia, a wszystko to w ramach już rozpoczętego procesu środowiska wykonawczego hosta. Żadnych nowych procesów, żadnych warstw obrazu, żadnych domyślnych montowań systemu plików.

Wybór trybu kompilacji dodaje dodatkową zmienną. Wasmtime kompiluje się do JIT poprzez backend Cranelift podczas ładowania modułu lub może go wcześniej skompilować za pomocą wasmtime compile, co powoduje utworzenie pliku .cwasm już przekształconego w natywny kod maszynowy. Wczesna kompilacja (AOT) usuwa etap kompilacji ze ścieżki krytycznej żądania: jest to dokładnie dźwignia, którą musi aktywować architektura brzegowa wrażliwa na zimny start.

# Rzeczywisty ekstrakt z repozytorium Aurabase
# Środowisko wykonawcze WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

Jest to zależność produkcyjna, a nie programistyczna: potwierdza, że ​​Wasmtime faktycznie działa na ścieżce CLI funkcji brzegowych Aurabase. Nie potwierdza jednak żadnych danych dotyczących opóźnień, co pozostaje prawdą, dopóki nie zostanie opublikowany żaden datowany test porównawczy.

W tym obszarze najsilniejszym źródłem jest artykuł z badań branżowych, a nie wpis na blogu marketingowym. Firecracker, lekka technologia microVM opracowana przez AWS i wykorzystywana zwłaszcza w Lambda i Fargate, została zaprezentowana na konferencji USENIX NSDI 2020 przez Agache i in. w artykule „Firecracker: lekka wirtualizacja dla aplikacji bezserwerowych”.

W tym artykule udokumentowano czas rozruchu krótszy niż 125 ms i obciążenie pamięci mniejsze niż 5 MiB na mikroVM, z możliwością uruchomienia tysięcy mikroVM na tej samej maszynie fizycznej. To dane datowane (2020 r.) pochodzące z recenzowanej publikacji akademickiej i od tego czasu szeroko cytowane w literaturze na temat izolacji bezserwerowej.

Standardowy kontener Dockera jest na ogół dłuższy: od kilkuset milisekund do kilku sekund w zależności od rozmiaru obrazu, konieczności jego pobrania i czasu uruchamiania wbudowanej aplikacji. W przeciwieństwie do Firecrackera nie ma tu jednej powszechnie cytowanej liczby: wynik w zbyt dużym stopniu zależy od testowanego obrazu pod kątem jednej wartości, aby osiągnąć konsensus.

Trzy źródła, trzy różne statusy: dostawca historyczny, projekt objęty nadzorem fundacji i artykuł badawczy.

Szybko uruchomiono Compute@Edge w 2019 r. na Lucet, własnym kompilatorze i środowisku wykonawczym WASM do wstępnej kompilacji. W momencie wprowadzenia na rynek firma udokumentowała czasy tworzenia WASM poniżej milisekundy, co stanowi rząd wielkości, który wywarł trwały wpływ na dyskurs dotyczący zimnego rozruchu WASM w branży. W 2021 roku firma Fastly zaprzestała autonomicznego rozwoju Lucet i przekierowała swoje wysiłki w stronę Wasmtime, którego zaplecze kompilacji Cranelift odziedziczyło część tych optymalizacji: jest to jeden z powodów, dla których Wasmtime pozostaje dziś punktem odniesienia dla tego typu ładunków.

WasmEdge, środowisko wykonawcze WASM zarządzane przez CNCF (pierwotnie SSVM, wspierane przez Second State), twierdzi w swojej oficjalnej dokumentacji znacznie mniejsze zużycie pamięci podczas uruchamiania i zajmowania pamięci niż równoważny kontener Docker, z wyraźnym pozycjonowaniem na obciążeniach brzegowych i IoT. Są to dane opublikowane przez samego wydawcę projektu i należy je czytać jako oświadczenie dotyczące produktu, a nie niezależny audyt.

Jeśli chodzi o badania akademickie, Faasm (Shillaker & Pietzuch, USENIX ATC 2020, również dostępny w wersji przed publikacją) buduje stanową platformę bezserwerową opartą na izolacji WebAssembly (za pośrednictwem WAVM, a nie Wasmtime) właśnie dlatego, że umożliwia ona utworzenie instancji funkcji przy znacznie niższym koszcie niż izolacja przez kontener lub maszynę wirtualną. Artykuł nie dotyczy konkretnie Wasmtime, ale zapewnia niezależną akademicką walidację argumentu strukturalnego przedstawionego w poprzedniej sekcji.

Porównanie tych trzech środowisk wykonawczych tylko z nazwy ukrywa prawdziwą zmienną: wybrany backend kompilacji, który radykalnie zmienia równowagę pomiędzy szybkością uruchamiania a wydajnością wykonywania.

Singlepass, najszybszy backend kompilacji firmy Wasmer, istnieje właśnie dlatego, że jego zespół zidentyfikował zimny start jako odrębną oś wydajności wykonywania w stanie ustalonym: moduł skompilowany w Singlepass uruchamia się szybciej, ale działa wolniej podczas szczytowego obciążenia niż ten sam moduł skompilowany w LLVM. To przyjęty kompromis, a nie ukryta wada.

Tych pięć wierszy nie jest odczytywanych jako pojedyncza klasyfikacja: pochodzą one z różnych metodologii, dat i generacji środowiska wykonawczego. Aby uzyskać bardziej dogłębną metodologiczną krytykę wiarygodności tego typu testu porównawczego WASM, nasz artykuł na temat ograniczeń testów porównawczych WebAssembly idzie dalej niż obecne porównanie, które pozostaje skupione na tym, co konkretnie twierdzi każde źródło.

Korzyści z zimnego startu WASM dotyczą w największym stopniu obciążeń najbardziej wrażliwych na opóźnienie pierwszego żądania, a nie wszystkich obciążeń w równym stopniu.

Ma to szczególne znaczenie w przypadku bardzo nieregularnego ruchu brzegowego (serii, po których następują cisze), izolacji na żądanie, a nie na kontener współdzielony pomiędzy kilkoma żądaniami, oraz na infrastrukturze, która w rzeczywistości ogranicza się do zera wystąpień między dwoma szczytami, zamiast stale utrzymywać gorącą pulę. Przy stabilnym i przewidywalnym obciążeniu, gdzie instancje i tak pozostają gorące, przerwa w zimnym rozruchu strukturalnie ma mniejsze znaczenie.

WebAssembly utrzymuje również ograniczenia różniące się od zimnego startu: dostęp do systemu plików lub sieci odbywa się przez WASI, interfejs wciąż ewoluuje w zależności od środowisk wykonawczych i ich wersji, a moduł skompilowany tak, aby uruchamiał się szybko (na przykład Singlepass po stronie Wasmer) niekoniecznie jest najszybszy po ustanowieniu przy dużym obciążeniu. Wydajność zimnego startu i szczytowa wydajność to dwie odrębne osie, rzadko optymalne jednocześnie w tym samym profilu kompilacji.

Aby ocenić wybór architektury brzegowej na podstawie tego kryterium, Aurabase zadał trzy konkretne pytania dowolnemu dostawcy: jaki dokładnie czas wykonania jest używany, jakie zaplecze kompilacji (JIT czy AOT) oraz czy zaawansowane parametry zimnego startu zostały zmierzone przez niezależną stronę trzecią, czy tylko przez samego wydawcę środowiska wykonawczego.

Aby zapoznać się z warstwą bazy danych dotyczącą tego samego problemu, zobacz nasz artykuł na temat zimnego startu Postgres bezserwerowego.