Как мы используем Yandex Cloud Functions для запуска проверок
Мы в Пингере запускаем тысячи проверок API, веб-сайтов и TCP-сервисов в минуту. Сегодня мы заглянем под капот — как у нас это все работает, как масштабируется и как мы решили использовать Cloud Functions от Яндекса (а потом и Serverless Containers).
Решение в лоб — серверы проверок
Наша идея запуска проверок из разных частей света не нова, но каждая компания подходит к реализации по-разному. Когда мы только начали, мы сделали решение «в лоб» — все проверки запускались с выделенных серверов или VPS. Мы долго выбирали между Pull/Push моделью, но так как наш бэкенд уже использовал Celery + Redis, то проверки решили делать на таком же функционале.
Вот как это выглядело:
Проверки помещаются в очередь через Celery Beat.
Серверы проверок забирают из очереди (или очередей) задачи и выполняют их.
Результаты помещаются в другую очередь.
Отдельная задача записывает результат в базу данных.
И казалось бы, такой подход дает практически безлимитные возможности для масштабирования. Можно добавлять новые серверы, увеличивать CPU/RAM на существующих и прочее.
Но тут появляются две проблемы:
Стоимость для небольшой компании. Мы небольшая компания. Оплачивать 20-30 серверов в месяц при небольшой нагрузке достаточно накладно. А их надо держать наготове, так как, кроме регулярных проверок, наши пользователи запускают on-demand проверки (например, в CI/CD пайплайнах). То есть просто выключить серверы или уменьшить их количество нельзя.
Качество сервиса. Когда вы предоставляете сервис мониторинга, пользователи рассчитывают на верные данные. Если сервер проверки сильно нагружен, то может быть такое, что он покажет задержку до веб-сайта в 2-3 раза больше реальной (а может и отвалится по таймауту).
Конечно же, мы попробовали придумать, как решить эту проблему — умное масштабирование, умные очереди (не отправлять задачи на уже загруженный сервер) и прочее. Но это сильно усложняло логику и приложение, добавляя ненужную сложность в архитектуру.
Бессерверные вычисления
Бессерверные решения замечательно решают проблему масштабирования. При нулевой загрузке ваш счет за облако будет почти нулевым, а при пиках система автоматически масштабируется. Вы можете использовать open-source решения вроде OpenFaaS, а можете взять готовые — Yandex Cloud Functions, AWS Lambda и другие. Так как мы делаем сервис в России, то решили довериться Яндексу.
Их Cloud Functions ничем не отличаются от западных аналогов, поддерживают популярные языки программирования и имеют множество нужных настроек.
Чтобы не изменять сильно наш стек, мы сделали следующее:
Проверки помещаются в очередь через Celery Beat.
Серверы проверок не выполняют проверки сами, а отправляют их в Cloud Functions.
Результаты помещаются в другую очередь.
Отдельная задача записывает результат в базу данных.
Эти минимальные изменения позволили нам сократить количество серверов проверок с 30 до 2 (после полного перехода на Cloud Functions). Единственная особенность Яндекса в том, что, кроме России и Казахстана, у них нет других регионов. Для покрытия по всему миру мы используем AWS и других провайдеров.
Конечно, следующая итерация предусматривает полный отказ от оставшихся серверов проверок. Один из вариантов — помещать проверки непосредственно в очередь сообщений (message queue), которая затем будет триггерить Cloud Functions. Однако это решение было бы слишком специфично для Яндекс.Облака, а нам требуется более глобальное решение, поддерживающее разных облачных провайдеров. Чтобы избежать вендор-лока (vendor lock-in), мы сейчас работаем над дополнительным компонентом, который позволит нам унифицировать процесс запуска функций, независимо от выбранного облака. Это даст нам возможность максимально гибко управлять инфраструктурой и обеспечивать покрытие во всех необходимых регионах мира.
Serverless Containers
Мы разрешаем нашим пользователям запускать их собственные Playwright-скрипты. Тут недостаточно взять пользовательский скрипт и запустить его в Cloud Function, и вот почему:
Сложность окружения: Playwright требует полноценного браузерного окружения (например, Chromium), которое должно быть установлено и настроено. Cloud Functions обычно предоставляют легковесные среды выполнения, не предназначенные для таких сложных зависимостей. Установка и запуск браузера внутри стандартной функции могут быть невозможны или крайне неэффективны.
Размер пакета: Образы браузеров и необходимые библиотеки для Playwright могут быть очень большими, превышая лимиты на размер развертываемого пакета для Cloud Functions.
Время холодного старта: Запуск браузера с нуля при каждом вызове функции приведет к значительному увеличению времени холодного старта, что критически важно для быстрых проверок.
Управление ресурсами: Playwright может потреблять много CPU и RAM, особенно при параллельном выполнении нескольких скриптов. Cloud Functions имеют ограничения по ресурсам и времени выполнения, которые могут быть недостаточными для сложных сценариев Playwright.
Взаимодействие с файловой системой и сетью: Скрипты Playwright могут требовать доступа к временным файлам, скриншотам или специфическим сетевым конфигурациям, что сложнее реализовать в изолированной и безгосударственной среде Cloud Functions.
Таким образом, мы решили использовать Serverless Containers. Мы создали собственный рантайм, который выполняет скрипт, а с помощью хуков обрабатывает некоторые пользовательские вызовы. Например, если пользователь делает скриншот, мы должны загрузить его в S3, но мы не можем дать пользователю прямые ключи от облака и доступ к ним. В Serverless Containers мы можем упаковать все необходимые зависимости (включая браузер) в один контейнер и гибко управлять его окружением и доступом к внешним сервисам.
Заключение
В целом, бессерверные вычисления отлично подходят для стартапов и дают возможность быстро масштабировать бизнес, минимизируя операционные расходы и позволяя сосредоточиться на разработке продукта, а не на управлении инфраструктурой. Они обеспечивают гибкость и отказоустойчивость, необходимые для современного высоконагруженного сервиса.
Мы не ограничиваемся только проверками! Pingera также предоставляет замечательные Статус Страницы, которые вы можете полностью адаптировать под свой бренд. Гибкая настройка позволит вам загрузить собственный логотип, изменить цветовую палитру и выбрать доменное имя.