Интернет-магазин бытовой техники в Алматы полгода работает с серверным GTM. В обычные дни сервер никто не замечает, до месячного лимита далеко. В пятницу в 20:00 магазин запускает распродажу с рассылкой в WhatsApp, и владелец спрашивает, выдержит ли сервер. Месячный лимит на этот вопрос не отвечает. Ответ зависит от того, сколько запросов придёт в первую минуту и что делает хостинг, когда их больше, чем он готов принять. Цифры в уроке условные.
Тот же минутный итог, разный пик
| Сценарий | Запросы | Средняя нагрузка на отрезке |
|---|---|---|
| Первая минута после рассылки | Около 6 000 | 100 в секунду |
| Если все пришли за первые десять секунд | Около 6 000 | 600 в секунду |
По месячному лимиту не понять, выдержит ли сервер первые секунды распродажи.
Переведите пик в запросы в секунду
Месячный объём нужен, чтобы выбрать тариф, а мощность сервера считают в запросах в секунду. Визиты в запросы переводят по расчёту из инфраструктуры sGTM. Здесь важен следующий шаг: найти самую плотную минуту.
Прошлогоднюю распродажу магазин проводил ещё без сервера, но выгрузка GA4 в BigQuery сохранила время каждого события. Если сгруппировать события по минутам и прибавить 30%, как Stape советует для грубой оценки запросов, видно, что в первую минуту после рассылки пришло около 6 000 запросов. Это в среднем 100 в секунду. Но ссылку открывают не равномерно. Если все 6 000 пришли за первые десять секунд, на этом отрезке нагрузка доходит до 600 в секунду. Минутный итог тот же, а нагрузка в шесть раз выше.
У Google есть ориентир для Cloud Run: от 2 до 10 экземпляров обрабатывают от 35 до 350 запросов в секунду, и Google сам оговаривает, что цифра зависит от числа тегов и того, что они делают (руководство по Cloud Run). По этой оценке на 100 запросов в секунду нужно три-четыре экземпляра, а 600 в секунду не уложатся и в десять. Для своего контейнера цифру получают нагрузочной проверкой, о ней в конце урока.
Что делает хостинг, когда запросов больше, чем он готов принять
Здесь варианты расходятся сильнее всего.
Cloud Run. Экземпляры добавляются по мере роста нагрузки, но не больше, чем задано в --max-instances. Когда экземпляров не хватает, Cloud Run отвечает ошибкой 429 с текстом «no available instance». Google называет три причины: резкий рост трафика, долгий запуск контейнера и долгая обработка запроса (ошибки Cloud Run). Такой запрос контейнер не обработал, и событий из него получатели не увидят.
Поэтому --min-instances поднимают заранее, до рассылки: новым экземплярам нужно время на запуск, а пик длится секунды. --max-instances ставят с запасом над расчётным пиком. Это граница худшего случая по оплате, лишних экземпляров Cloud Run сам не запустит. Сколько экземпляров держать постоянно, Google пишет по-разному: в руководстве по Cloud Run не меньше двух, в обзоре серверного тегирования не меньше трёх. Там же сказано, что сервер, созданный автоматической настройкой, ограничен по ресурсам и годится только для тестов с небольшим трафиком.
Stape. Тариф ограничивает запросы в месяц, а что бывает при превышении лимита, описано вместе с инфраструктурой sGTM. О пределе запросов в секунду на странице лимитов Stape ничего нет, поэтому перед распродажей спросите у поддержки, какой пик выдержит ваш тариф, и сохраните ответ.
AWS и свой сервер. Масштабирование здесь настраивает сторона клиента. В архитектуре, которую AWS публикует для sGTM, сервер тегов и отдельный preview-сервис работают в Amazon ECS за балансировщиком Application Load Balancer, а адреса ведёт Route 53 (sGTM на AWS). Сколько копий сервера держать и когда добавлять новые, решает админ. Google советует ставить серверы не больше чем с 1 vCPU и собирать их в кластер (ручная настройка), так что пик закрывают числом машин, а не размером одной. На единственном VPS масштабирования нет: пик упирается в его процессор.
Потолок расходов в Google Cloud. Если он настроен, в день распродажи счёт дойдёт до него быстрее обычного, и Cloud Run встанет на паузу. Бюджеты и потолок расходов настраивают по тому же уроку об инфраструктуре sGTM.
Сравните GCP, AWS и Stape на своей задаче
| Google Cloud Run | AWS | Stape | |
|---|---|---|---|
| Откуда берётся сервер | GTM создаёт сервер автоматически, а для рабочего трафика ему добавляют экземпляры по руководству Google | Вы разворачиваете образ в ECS по архитектуре AWS | Вы вставляете строку конфигурации контейнера в панели Stape |
| Как настроить пик | --min-instances и --max-instances | Масштабирование сервиса в ECS | Тариф и автоматический переход на следующий |
| Логи и метрики | Cloud Logging, по умолчанию каждый запрос | Метрики в CloudWatch | Логи входящих и исходящих запросов в панели Stape |
| Кто ведёт сервер | Вы или админ клиента | Админ клиента, который знает AWS | Stape, а вы ведёте контейнер |
Выбирайте вариант, который команда клиента сможет вести, когда вы закончите проект. Если у клиента уже есть админ, который работает с AWS, развёртывание там понятнее, чем новый аккаунт Google Cloud. Если админа нет, Stape снимает с вас заботу о сервере. Схема событий и доставка в любом случае остаются за тем, кто настраивает трекинг: хостинг не знает, что purchase должен уходить после оплаты.
Расходы, которых нет на странице тарифа
Цены собраны в статье о том, во сколько обходится server-side GTM. Строки сметы, которые легко пропустить (логи, preview-сервер, исходящий трафик, бюджет без потолка), перечислены в смете из инфраструктуры sGTM. Для распродажи к ним добавляются две.
Логи Stape. Они есть только на платных тарифах и хранятся по-разному: на Pro и Pro+ последние три дня, на Business и выше десять дней, а выгрузка логов доступна с Enterprise (логи Stape). Если пятничный сбой начнут разбирать через неделю, на Pro логов за пятницу уже не будет. Либо разбирайте в выходные, либо заранее решите, нужен ли на месяц распродажи тариф с более долгим хранением.
Месяц с пиком. Поднятый на день распродажи --min-instances стоит денег, пока вы его не опустите. Поэтому смет две: на обычный месяц и на месяц с распродажей.
Сервер жив - ещё не значит, что события доходят
Проверка /healthy говорит только о том, что сервер отвечает. Настраивают её вместе с инфраструктурой sGTM, а здесь важно, чего она не покажет.
В пятницу с 20:00 до 21:00 магазин принял 120 заказов на 5 760 000 ₸, средний чек 48 000 ₸. В GA4 за этот час 96 покупок, а /healthy весь вечер отвечал ok. Разница в 24 заказа - это 1 152 000 ₸ выручки, которой нет в отчётах GA4. Но сначала сравните её с обычными днями. Часть покупок GA4 не видит никогда: кто-то отказывается от аналитических cookies, у кого-то стоит блокировщик. Сколько их обычно, покажет неделя без распродаж, когда сервер точно справлялся: в обычный час заказов слишком мало, чтобы считать долю. Если и тогда GA4 недосчитывается каждого пятого заказа, 24 из 120 - обычный разрыв, и на сервер указывает только то, что сверх него.
Если разрыв больше обычного, посмотрите, хватало ли серверу экземпляров. Метрика числа запросов Cloud Run тут не поможет: запросы, отклонённые на пределе экземпляров, она не учитывает (метрики Cloud Run). Для ошибки 429 Google советует смотреть метрику Container instance count на вкладке Metrics сервиса: если в час распродажи она упиралась в --max-instances, часть запросов сервер не принял.
Поэтому доставку контролируют отдельно от живости сервера: коды ответа получателей в логах исходящих запросов и почасовая сверка заказов в CRM с покупками в GA4 и рекламных кабинетах. Такой контроль строят по правилам мониторинга S2S.
Репетиция перед распродажей
За неделю до большой кампании пройдите по списку:
Выполнено 0 из 7
Упражнение: записка владельцу перед кампанией
Возьмите свой проект или клиента с серверным контейнером и ближайшую кампанию, которая даст всплеск трафика. Напишите владельцу одну страницу: какой пик ждёте в запросах в секунду и откуда эта цифра, на чём работает сервер и что он сделает, если пик окажется выше, сколько будет стоить месяц с кампанией по сравнению с обычным, кто дежурит в день запуска и как вы поймёте, что покупки доходят.
Хорошая записка опирается на цифры: пик посчитан по прошлым данным, рядом указан ориентир Google или ответ поддержки провайдера, а для перегрузки назван исход, например ответы 429 на Cloud Run или пауза у Stape. Если раздел о мощности уместился в одну фразу «тариф вмещает 2 млн запросов в месяц», вернитесь к первому разделу урока. 2 млн в месяц - это в среднем 46 запросов в минуту, и про пятницу 20:00 эта цифра ничего не говорит. С последним разделом то же самое: «следим за сервером» не ответ, а «каждый час сверяем заказы в CRM с покупками в GA4, обычный разрыв 20%, отвечает Айгерим» - ответ.
Видео: пример управляемого хостинга
Видео на английском, от самого Stape: как создать серверный контейнер и разместить его у них.