Как построить архитектуру «serverless + edge» для глобального приложения

Когда ваше приложение начинают использовать в разных точках мира, классическая схема с одним бэкендом в одном регионе начинает сыпаться. Задержки растут, пользователи в Азии ждут отклика дольше, чем в Европе, а вы не знаете, куда смотреть — добавлять серверы или менять архитектуру. Архитектура «serverless + edge» решает эту задачу не наращиванием железа, а за счёт правильного размещения вычислений ближе к пользователю.

Я расскажу, как подойти к такой архитектуре, какие компоненты за что отвечают, где подводные камни и как не превратить простой проект в неуправляемый зоопарк сервисов.

Что реально дают serverless и edge

Serverless — это когда вы деплоите код, а платформа сама решает, на каком сервере он крутится, и масштабирует его по запросам. Вы не арендуете виртуалку 24/7, а платите за фактические вычисления. Для глобального приложения это удобно, потому что не нужно вручную поднимать инфраструктуру в каждом регионе.

Edge — это следующий шаг. Вы не просто запускаете код в облаке, а запускаете его в точках, максимально близких к пользователю. Это не один дата-центр во Франкфурте, а десятки или сотни точек по всему миру. Запрос обрабатывается ближе, и время ответа падает кратно.

Вместе эти два подхода дают: низкую задержку по всему миру, автоматическое масштабирование и отсутствие головной боли с обслуживанием серверов. Но только если архитектура спроектирована правильно.

Из чего собирается такая архитектура

Глобальное приложение на serverless + edge обычно состоит из нескольких слоёв. Каждый слой решает свою задачу, и попытка запихнуть всё в один компонент — верный путь к хаосу.

1. Edge-слой: маршрутизация и быстрая логика

Это первый рубеж. Сюда попадает запрос пользователя, и здесь принимаются решения, которые не требуют тяжёлой обработки: редиректы, A/B-тесты, геолокация, проверка аутентификации, отдача кэшированного контента. Примеры платформ: Cloudflare Workers, Vercel Edge Functions, Fastly Compute.

Edge-функции работают быстро, но у них жёсткие ограничения: короткое время выполнения (часто единицы или десятки миллисекунд на CPU), ограниченный доступ к файловой системе, специфическая среда выполнения. Это не место для сложной бизнес-логики.

2. Serverless-бэкенд: основная логика

Тяжёлые операции — работа с базой данных, сложные вычисления, интеграции с внешними сервисами — отправляются в serverless-функции в региональных дата-центрах. AWS Lambda, Google Cloud Functions, Cloudflare Workers с более мощными лимитами, Deno Deploy — вариантов много.

Ключевой момент: serverless-функция должна быть максимально близко к данным, с которыми она работает. Если ваша база в Европе, а функция крутится в Японии, каждый запрос будет ходить туда-сюда через океан. Это сводит на нет весь смысл edge.

3. Распределённые данные

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

• Eventually consistent — данные синхронизируются с задержкой. Подходит для ленты новостий, каталогов, профилей. Примеры: Cloudflare D1, DynamoDB Global Tables, PlanetScale.
• Strongly consistent — все узлы видят одни и те же данные одновременно. Нужно для финансовых операций, бронирования. Примеры: Spanner, CockroachDB, Fauna.
• Edge-native кэши — данные хранятся прямо в edge-слое и обновляются по событию. Подходит для контента, который меняется редко. Примеры: Cloudflare KV, Upstash Redis.

4. Статика и ассеты

Всё, что можно закэшировать — CSS, JS, изображения, шрифты — должно жить в CDN. Это база, которую часто забывают оптимизировать, пока бэкенд уже распределён по миру. Современные платформы (Vercel, Cloudflare Pages) делают это автоматически, но если вы собираете всё сами — об этом нужно думать отдельно.

Как маршрутизировать запросы

Это центральный вопрос архитектуры. Пользователь в Токио должен попасть на edge-ноду в Азии, а его данные — считаться из ближайшей реплики базы. Есть несколько подходов:

1. DNS-маршрутизация. DNS-сервер определяет регион пользователя и отвечает IP-адресом ближайшей ноды. Просто, но медленно — DNS-кэши могут удерживать неправильный маршрут минутами.
2. Anycast. Все edge-ноды анонсируют один и тот же IP-адрес, и маршрутизация на уровне сети направляет пакет к ближайшей точке. Используется в Cloudflare, Fastly. Работает быстро и надёжно.
3. Прокси-маршрутизация. Входящий запрос принимается в одной точке, анализируется и перенаправляется в нужный регион. Добавляет один прыжок, но даёт больше контроля.

На практике большинство edge-платформ используют anycast для edge-слоя и прокси-маршрутизацию для перехода к serverless-функциям. Вам не нужно это настраивать вручную — но понимать разницу важно, когда что-то работает не так, как ожидаете.

Сравнение платформ: что выбрать

Я собрал основные варианты, с которыми сталкивался на практике. Выбор зависит от того, что для вас критичнее: экосистема, простота или контроль.

Платформа	Edge-функции	Serverless-бэкенд	Распределённые данные	Для кого
Cloudflare	Workers (V8 isolates, ~0ms cold start)	Workers + Durable Objects	D1, KV, R2, Durable Objects	Универсальный вариант, хорошая цена, обширная сеть edge-нод
Vercel	Edge Middleware	Serverless Functions (AWS под капотом)	Не предоставляет сама — интегрируется с внешними БД	Проекты на Next.js, фронтенд-команды, быстрый старт
AWS	Lambda@Edge, CloudFront Functions	Lambda	DynamoDB Global Tables, Aurora Global	Команды, уже в экосистеме AWS, сложные интеграции
Fastly	Compute@Edge (WASM)	Нет классического serverless — только edge	Нет встроенной БД	Высокая производительность edge, медиастриминг, сложная логика на WASM

Сценарии: что подходит под вашу задачу

Если вы делаете фронтенд-приложение с лёгким бэкендом — начните с Vercel или Cloudflare Pages + Workers. Этого хватит для 80% проектов. Данные храните в совместимой облачной базе (Neon, PlanetScale, Supabase).

Если у вас сложная серверная логика и много интеграций — вероятно, вы уже в экосистеме AWS или GCP. Используйте Lambda@Edge или CloudFront Functions для edge-слоя, а основную логику оставьте в региональных Lambda. Не пытайтесь перенести всё на edge — там для этого слишком жёсткие лимиты.

Если вам нужна максимальная скорость и вы готовы писать на Rust/C — посмотрите на Fastly Compute. Он даёт самую быструю обработку на edge, но требует другого стека и подхода к разработке.

Если бюджет ограничен и команда маленькая — Cloudflare Workers с D1 или KV. У них щедрый бесплатный тариф, сеть нод огромная, и всё управляется из одного места. Минут на старт уйдёт меньше, чем на настройку AWS.

Частые ошибки, которые я видел

Ошибка 1: Запускать тяжёлую логику в edge-функции. Edge — это не мини-сервер. Если ваша функция выполняется дольше 50 мс, она должна работать в региональном serverless, а не на edge. Попытка сделать всё на edge приводит к таймаутам и непонятным багам.

Ошибка 2: Хранить состояние в edge-функции. Каждый запрос может попасть на другую ноду. Если вы сохранили что-то в памяти функции — следующий запрос этого не увидит. Состояние — только в базе данных или распределённом кэше.

Ошибка 3: Не думать о холодном старте. Serverless-функции «засыпают» без запросов и запускаются заново с задержкой. Для edge-функций это обычно быстро (единицы миллисекунд на V8 isolates), но для обычных Lambda может быть сотни миллисекунд. Если для вас это критично — используйте provisioned concurrency или платформы с V8 isolates.

Ошибка 4: Одна база данных для всех регионов. Если все ваши serverless-функции читают и пишут в одну базу в одном регионе, пользователи на другом конце света будут ждать каждый запрос. Реплицируйте данные или используйте глобальную базу.

Ошибка 5: Игнорировать стоимость исходящего трафика. В облаках входящий трафик бесплатный, а исходящий — платный. Когда вы распределяете архитектуру по миру, объём межрегионального трафика растёт. Считайте заранее, сколько будет стоить передача данных между регионами.

Как лучше сделать: пошаговый план

Вот последовательность, которая работает на практике:

1. Определите, где живут ваши пользователи. Если 80% в одной стране — глобальная архитектура может быть избыточной. Начните с одного региона и edge-кэширования.
2. Разделите запросы на «быстрые» и «тяжёлые». Быстрые (редиректы, кэш, проверка токена) — на edge. Тяжёлые (работа с БД, бизнес-логика) — в региональный serverless.
3. Выберите платформу под ваш стек. Если команда знает Next.js — Vercel. Если нужен максимальный контроль и не пугает сложность — AWS. Если хотите простоту и быстрый старт — Cloudflare.
4. Спроектируйте данные. Решите, какую модель консистентности вы можете принять, и выберите базу данных, которая поддерживает региональную репликацию из коробки.
5. Настройте мониторинг с первого дня. Распределённая система без наблюдаемости — чёрный ящик. Вам нужно видеть: время ответа по регионам, процент ошибок, стоимость на регион.
6. Тестируйте из разных точек мира. Локальный тест ничего не покажет. Используйте инструменты вроде Vercel Analytics, Cloudflare Analytics, или просто запускайте нагрузочные тесты из разных регионов.

Наблюдаемость — это не опция

В распределённой архитектуре без мониторинга вы летите вслепую. Вам нужно отслеживать минимум три вещи:

• Latency по регионам (p50, p95, p99). Если p95 в Азии — 500 мс, а в Европе — 80 мс, у вас проблема с размещением данных или функций.
• Error rate по регионам. Ошибки только в одном региона — признак проблемы с конкретной репликой базы или edge-нодой.
• Стоимость по компонентам. Serverless может неожиданно дорого обойтись, если где-то возникнет бесконечный цикл или неоптимальный запрос к базе.

Большинство платформ дают базовую аналитику из коробки. Для продвинутого мониторинга подключайте OpenTelemetry — это стандарт, который работает с любой платформой.

Когда serverless + edge — не лучший выбор

Бывает, что эта архитектура не подходит. Не нужно гнаться за модой, если:

• Ваше приложение используется только в одном регионе. Один дата-центр и CDN дешевле и проще.
• У вас длительные вычисления (обработка видео, генерация отчётов). Serverless с таймаутом в 30 секунд или даже 15 минут — не панацея для таких задач.
• У вас стабильная высокая нагрузка 24/7. В этом случае выделенный сервер или Kubernetes могут быть дешевле, чем постоянная работа serverless-функций.
• Ваша команда не готова к новому стеку. Переход на serverless + edge требует другого мышления. Если команда не знакома с этим, сначала попробуйте на небольшом проекте.

Итог: с чего начать

Архитектура «serverless + edge» — это не серебряная пуля, а мощный инструмент для глобальных приложений. Главные принципы:

• Edge — для быстрых решений и маршрутизации, а не для всей логики.
• Serverless-функции должны быть рядом с данными, с которыми работают.
• Данные нужно реплицировать между регионами — иначе архитектура не имеет смысла.
• Начните с малого: один регион, edge-кэш, одна serverless-функция. Расширяйте по мере необходимости.
• Считайте стоимость до запуска, особенно межрегиональный трафик.

Если вы строите приложение, которое должно работать быстро в любой точке мира — начните с Cloudflare Workers или Vercel Edge для фронта, подключите распределённую базу данных, и постепенно усложняйте архитектуру только там, где это действительно нужно. Не пытайтесь сделать всё идеально с первого дня — лучше запуститься быстро и улучшать по мере роста.