Около четырех лет назад мы анонсировали Cloudflare Workers — бессерверную платформу, работающую непосредственно на периферии.
На этой неделе мы будем говорить о многих способах, с помощью которых Cloudflare помогает ускорить работу приложений, уже существующих в вебе. Но если сегодня настал тот день, когда вы решите воплотить свою идею в жизнь, создание своего проекта на Cloudflare и развертывание его непосредственно в Интернете — это лучший способ гарантировать, что ваше приложение всегда будет быстрым для всех пользователей, независимо от их местоположения.
Прошло несколько лет с тех пор, как мы обсуждали Cloudflare Workers по сравнению с другими бессерверными платформами, поэтому мы решили, что пришло время для обновления. Хотя большая часть нашей работы над платформой Workers за последние несколько лет была направлена на то, чтобы сделать платформу более мощной: внедрить новые функции, API, хранилища, инструменты отладки и мониторинга, производительность не осталась без внимания.
Сегодня Workers работает на 30 % быстрее, чем три года назад на P90. И это на 210 % быстрее, чем Lambda@Edge, и на 298 % быстрее, чем Lambda.
Кроме того, мы устранили холодные запуски.
Как вы измеряете производительность бессерверных платформ?
В прошлом я проводил сотни тестов производительности между CDN, и формула проста: мы используем инструмент под названием Catchpoint, который отправляет запросы от узлов по всему миру к одному и тому же ресурсу и сообщает о времени, которое потребовалось для каждой локации для отправки ответа.
Измерение бессерверной производительности немного отличается: поскольку вы сравниваете производительность вычислений, а не статического ресурса, мы хотели убедиться, что все функции выполняют одну и ту же операцию.
В нашем блоге 2018 года о тестировании скорости каждая функция просто возвращала текущее время. Для целей данного теста «бессерверные» продукты, которые не соответствовали минимальным критериям способности выполнять эту задачу, были дисквалифицированы. Бессерверные продукты, использованные в этом раунде тестирования, выполняли одну и ту же функцию при одинаковой вычислительной сложности, чтобы обеспечить точные и достоверные результаты.
Также важно отметить, что именно мы измеряем. Причина, по которой производительность имеет значение, заключается в том, что она влияет на удобство реальных конечных клиентов. Неважно, каков источник сетевой задержки: DNS, перегрузка сети, холодные запуски и т. д. Клиенту все равно, каков источник, дня него важно то, что ему приходится тратить время на ожидание загрузки своего приложения.
Соответственно, важно измерять производительность с точки зрения удобства использования для конечных пользователей — «из конца в конец», поэтому мы используем глобальные эталонные тесты для измерения производительности.
Результат ниже показывает тесты, проведенные на 50 узлах по всему миру, в Северной Америке, Южной Америке, Европе, Азии и Океании.
Blue: Cloudflare WorkersRed: Lambda@EdgeGreen: Lambda
Как видно из результатов, независимо от того, в какой точке мира находятся пользователи, с точки зрения скорости Workers может гарантировать наилучшее удобство для клиентов.
В случае с Workers достижение максимальной производительности в глобальном масштабе не требует дополнительных усилий со стороны разработчиков. Разработчикам не нужно выполнять дополнительную балансировку нагрузки или настройку регионов. Каждое развертывание мгновенно запускается в обширной периферийной сети Cloudflare.
Даже если вы не стремитесь обращаться к глобальной аудитории, а ваша клиентская база удобно расположена на восточном побережье США, Workers может гарантировать максимально быстрый ответ на все запросы.
Выше приведены результаты только из Вашингтона, округ Колумбия, максимально приближенные к us-east-1. И снова без какой-либо оптимизации Workers работает на 34 % быстрее.
Почему?
От чего зависит производительность бессерверной платформы?
Помимо производительности самого кода, с точки зрения конечного пользователя, производительность бессерверного приложения по своей сути является функцией двух переменных: расстояния, на котором приложение выполняется от пользователя, и времени, которое требуется самой среде выполнения для развертывания. Осознание того, что удаленность от пользователя становится все более серьезным узким местом в производительности приложений, побуждает многих поставщиков бессерверных платформ все глубже и глубже внедрять периферийные решения. Запуск приложений на периферии, ближе к конечному пользователю, повышает производительность. По мере появления 5G эта тенденция будет только усиливаться.
Однако многие поставщики облачных услуг в бессерверном пространстве сталкиваются с серьезной проблемой при решении проблемы, конкурируя за более высокую производительность. А именно: устаревшая архитектура, которую они используют для создания своих предложений, плохо работает с присущими периферии ограничениями.
Поскольку цель бессерверной модели заключается в том, чтобы намеренно абстрагироваться от базовой архитектуры, не всем ясно, как традиционные поставщики облачных услуг, такие как AWS, создали бессерверные предложения, в частности, Lambda. Традиционные поставщики облачных услуг предоставляют бессерверные услуги, развертывая для вашего кода контейнеризованный процесс. Поставщик автоматически масштабирует все различные процессы в фоновом режиме. Каждый раз, когда запускается контейнер, вместе с ним запускается вся языковая среда выполнения, а не только ваш код.
Чтобы реализовать выполнение первого графика, измеряющего глобальную производительность, поставщики пытаются перейти от своей обширной централизованной архитектуры (несколько крупных центров обработки данных) к распределенному миру на основе периферии (большее количество небольших центров обработки данных по всему миру), чтобы сократить расстояние между приложениями и конечными пользователями. Но с таким их подходом связана проблема: чем меньше центры обработки данных, тем меньше машин и меньше памяти. Каждый раз, когда поставщики используют стратегию небольших, но многочисленных центров обработки данных, чтобы работать ближе к периферии, вероятность холодного запуска любого отдельного процесса возрастает.
Это фактически создает потолок производительности для бессерверных приложений в архитектурах на основе контейнеров. Если традиционные поставщики с небольшими центрами обработки данных переместят ваше приложение ближе к периферии (и к пользователям), у вас будет меньше серверов, меньше памяти, и более вероятно, что приложению потребуется холодный запуск. Чтобы снизить вероятность этого, они вернулись к более централизованной модели; но это означает, что ваши приложения будут работать в одном из нескольких крупных централизованных центров обработки данных. Эти более крупные централизованные центры обработки данных по определению почти всегда будут находиться дальше от ваших пользователей.
Вы можете увидеть это на графике выше, посмотрев на результаты тестов при запуске в Lambda@Edge — несмотря на меньшую близость к конечному пользователю, производительность p90 ниже, чем у Lambda, поскольку контейнерам приходится чаще разворачиваться.
Бессерверные архитектуры, построенные на основе контейнеров, могут перемещаться вверх и вниз по границе, но в конечном итоге они мало что могут сделать, чтобы сдвинуть эту переднюю кривую.
Благодаря чему Workers такой быстрый?
Workers был разработан с нуля для бессерверной модели, ориентированной на периферию. Поскольку Cloudflare начала с распределенной периферийной сети, вместо того чтобы пытаться переносить вычисления из крупных централизованных центров обработки данных в периферийные сети, работа в условиях этих ограничений побудила нас внедрять инновации.
В одной из наших предыдущих публикаций в блоге мы обсуждали, как это нововведение привело к новому сдвигу парадигмы : архитектура Workers построена на облегченных изолятах V8, которые могут быстро развертываться, без необходимости холодного запуска при каждом запросе.
Использование изолятов дает нам преимущество не только сразу после установки, но и по мере того, как V8 становится лучше, улучшается и наша платформа. Например, когда V8 анонсировала Liftoff, компилятор для WASM, все WASM Workers мгновенно стали работать быстрее.
Аналогичным образом, всякий раз, когда в сеть Cloudflare вносятся улучшения (например, когда мы добавляем новые центры обработки данных) или стек (например, поддержка новых, более быстрых протоколов, таких как HTTP/3), Workers немедленно получает от этого выгоду.
Кроме того, мы всегда стремимся улучшать саму платформу Workers, чтобы сделать ее еще быстрее. Например, в прошлом году мы выпустили усовершенствование, которое помогло нашим клиентам исключить холодный запуск.
Одним из ключевых преимуществ, которое помогает Workers выявлять и устранять пробелы в производительности, является масштаб, в котором он работает. Сегодня Workers служит для сотни тысяч разработчиков, от любителей до предприятий по всему миру, обслуживая миллионы запросов в секунду. Всякий раз, когда мы вносим улучшения для одного клиента, вся платформа становится быстрее.
Производительность, которая имеет значение
Конечная цель бессерверной модели — дать разработчикам возможность сосредоточиться на том, что у них получается лучше всего: на создании удобства для своих пользователей. Выбор бессерверной платформы, которая может предложить наилучшую производительность непосредственно после установки, означает, что у разработчиков станет на один повод для беспокойства меньше. Если вы тратите свое время на оптимизацию для холодных запусков, вы не тратите свое время на создание наилучшей функции для своих клиентов.
Точно так же, как разработчики хотят обеспечить максимальное удобство для своих пользователей, повышая производительность своего приложения, мы постоянно стремимся повысить удобство для разработчиков, использующих Workers.
Точно так же, как клиенты не хотят ждать медленного ответа, разработчики не хотят ждать медленных циклов развертывания.
И здесь платформа Workers снова на высоте.
Глобальное распространение любого развертывания на Cloudflare Workers занимает менее секунды, поэтому вам не нужно тратить время на ожидание развертывания вашего кода, и пользователи могут видеть изменения в кратчайшие сроки.
Разумеется, важно не только время развертывания, но и эффективность полного цикла разработки, поэтому мы всегда стремимся улучшить его на каждом этапе: от регистрации до отладки.
Но не верьте нам на слово!
Излишне говорить, что, как бы мы ни старались сохранять нейтралитет, мы всегда будем немного предвзятыми. К счастью, вам не нужно верить нам на слово.
Мы приглашаем вас зарегистрироваться и развернуть свой первый Worker сегодня — это займет всего несколько минут!