WASM против холодного запуска контейнера: что говорят среды выполнения

Холодный старт означает дополнительную задержку, оплачиваемую запросом, когда среда выполнения должна инициализироваться перед запуском кода приложения. Для классической периферийной или бессерверной функции это далеко не маргинальный случай: платформа, которая снижает количество экземпляров до нуля между двумя пиками трафика или распределяет выполнение по десяткам географически разбросанных периферийных узлов, платит эти затраты постоянно, а не только при первом развертывании.

Эта тема приобрела почти символическое значение в экосистеме WASM после того, как Соломон Хайкс, соучредитель Docker, опубликовал в Твиттере в марте 2019 года предложение: "Если бы WASM+WASI существовало в 2008 году, нам не нужно было бы создавать Docker. Вот насколько это важно. WebAssembly на сервере — это будущее вычислений". Это мнение признанного практика, а не измерение. Оно объясняет, почему эта тема завораживает, но не заменяет исходную фигурку.

Aurabase предлагает два пути для своих пограничных функций: редактор Studio, который запускает код в среде выполнения Deno, как описано в нашем руководстве по миграции Supabase, и CLI aura functions deploy, который предназначен для отдельного пути для функций, написанных на Rust и скомпилированных в WASM на Wasmtime. Именно на этот второй путь и проливает свет данная статья, не приводя при этом цифру холодного старта, которой пока не существует.

Разница заключается не в более быстром времени выполнения в абсолютном выражении, а в более коротком стеке шагов между запросом и кодом приложения.

Запуск контейнера мобилизует ядро ​​хоста: создание нового процесса, настройка контрольных групп и пространств имен, которые изолируют его, монтирование слоев образа, а затем запуск среды выполнения приложения внутри (например, Node.js и его движок V8 сами требуют затрат на инициализацию). На каждом этапе добавляются системные вызовы и, для изображения, которое никогда не просматривалось локально, загрузка по сети еще до ее начала.

Модуль WebAssembly изолирован на уровне языка виртуальной машины, а не на уровне операционной системы. Создание экземпляра модуля означает выделение его линейной памяти, привязку его импорта, а затем переход к его точке входа, и все это в рамках уже запущенного процесса среды выполнения хоста. Никаких новых процессов, слоев образа и монтирования файловой системы по умолчанию.

Выбор режима компиляции добавляет дополнительную переменную. Wasmtime компилирует в JIT через свой бэкэнд Cranelift при загрузке модуля или может предварительно скомпилировать его с помощью wasmtime compile, который создает файл .cwasm, уже преобразованный в собственный машинный код. Ранняя компиляция (AOT) удаляет этап компиляции из критического пути запроса: это именно тот рычаг, который должна активировать пограничная архитектура, чувствительная к холодному старту.

# Актуальная выдержка из репозитория Aurabase.
# Среда выполнения WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

Это производственная зависимость, а не разработка: она подтверждает, что Wasmtime действительно работает по пути CLI пограничных функций Aurabase. Однако он не подтверждает никаких показателей задержки, что остается верным до тех пор, пока не публикуется датированный тест.

В этой области самым сильным источником является отраслевое исследование, а не сообщение в маркетинговом блоге. Firecracker, облегченная технология microVM, разработанная AWS и используемая, в частности, для Lambda и Fargate, была представлена ​​на конференции USENIX NSDI 2020 Agache et al. в статье «Firecracker: облегченная виртуализация для бессерверных приложений».

В этом документе документировано время загрузки менее 125 мс и затраты памяти менее 5 МБ на микроВМ с возможностью запуска тысяч микроВМ на одной физической машине. Это датированная цифра (2020 г.), полученная из рецензируемой академической публикации и с тех пор широко цитируемая в литературе по бессерверной изоляции.

У стандартного Docker-контейнера оно обычно выше: от нескольких сотен миллисекунд до нескольких секунд в зависимости от размера образа, необходимости его загрузки и времени загрузки среды выполнения встроенного приложения. В отличие от Firecracker здесь не упоминается ни одна цифра, которая была бы универсально указана: результат слишком сильно зависит от изображения, проверенного на одно значение, чтобы достичь консенсуса.

Три источника, три разных статуса: исторический поставщик, проект под управлением фонда и исследовательская работа.

В 2019 году быстро запустил Compute@Edge на Lucet, собственном компиляторе и среде выполнения WASM для предварительной компиляции. При этом запуске компания зафиксировала время создания экземпляра WASM менее миллисекунды, что оказало длительное влияние на дискуссию о холодном запуске WASM в отрасли. В 2021 году Fastly прекратила автономную разработку Lucet и перенаправила свои усилия на Wasmtime, чей бэкэнд компиляции Cranelift унаследовал часть этих оптимизаций: это одна из причин, почему Wasmtime сегодня остается эталоном для этого типа нагрузки.

WasmEdge, среда выполнения WASM под управлением CNCF (первоначально SSVM, поддерживаемая Second State), заявляет в своей официальной документации о значительно меньшем объеме запуска и занимаемой памяти, чем эквивалентный контейнер Docker, с явным позиционированием на периферии и нагрузками IoT. Это цифра, опубликованная самим издателем проекта, и ее следует читать как таковую: претензию к продукту, а не независимый аудит.

Что касается академических исследований, Faasm (Shillaker & Pietzuch, USENIX ATC 2020, также доступен в предварительной публикации) создает бессерверную платформу с отслеживанием состояния, опирающуюся на изоляцию WebAssembly (через WAVM, а не Wasmtime) именно потому, что она позволяет создавать экземпляры функций с гораздо меньшими затратами, чем изоляция с помощью контейнера или виртуальной машины. В статье не говорится конкретно о Wasmtime, но она обеспечивает независимое академическое подтверждение структурных аргументов, изложенных в предыдущем разделе.

Сравнение этих трех сред выполнения только по названию скрывает реальную переменную: выбранный бэкэнд компиляции, который радикально меняет баланс между скоростью запуска и производительностью выполнения.

Singlepass, самый быстрый бэкэнд компиляции Wasmer, существует именно потому, что его команда определила холодный запуск как отдельную ось производительности стабильного выполнения: модуль, скомпилированный в Singlepass, запускается быстрее, но работает медленнее во время пиковой нагрузки, чем тот же модуль, скомпилированный в LLVM. Это принятый компромисс, а не скрытый недостаток.

Эти пять строк не читаются как единая классификация: они взяты из разных методологий, дат и поколений времени выполнения. Для более глубокой методологической критики надежности этого типа тестов WASM наша статья об ограничениях тестов WebAssembly идет дальше настоящего сравнения, которое по-прежнему сосредоточено на том, что конкретно утверждает каждый источник.

Преимущество холодного запуска WASM больше всего зависит от нагрузок, наиболее чувствительных к задержке первого запроса, а не на всех нагрузках в равной степени.

Это особенно влияет на очень нерегулярный пограничный трафик (всплески, сопровождаемые молчанием), изоляцию для каждого запроса, а не для каждого контейнера, совместно используемого несколькими запросами, а также для инфраструктуры, которая фактически сводит количество экземпляров к нулю между двумя пиками вместо того, чтобы постоянно поддерживать горячий пул. При стабильной и предсказуемой нагрузке, когда экземпляры все равно остаются горячими, структурный разрыв при холодном запуске имеет меньшее значение.

WebAssembly также поддерживает ограничения, отличные от холодного запуска: доступ к файловой системе или сети осуществляется через WASI, интерфейс все еще развивается в зависимости от сред выполнения и их версий, а модуль, скомпилированный для быстрого запуска (например, Singlepass на стороне Wasmer), не обязательно является самым быстрым после установки под большой нагрузкой. Холодный старт и пиковая производительность остаются двумя разными осями, которые редко оптимальны одновременно в одном профиле компиляции.

Чтобы оценить выбор периферийной архитектуры по этому критерию, Aurabase включила три конкретных вопроса, которые следует задать любому поставщику: какая именно среда выполнения используется, какой бэкэнд компиляции (JIT или AOT) и измеряется ли показатель расширенного холодного запуска независимой третьей стороной или только самим издателем среды выполнения.

Информацию об этой же проблеме на уровне базы данных см. в нашей статье о холодном запуске бессерверного Postgres.