Автомасштабирование интернет-магазина: пиковые нагрузки, стратегии масштабирования, контроль затрат и мониторинг
1. Как выглядят пики трафика у интернет-магазина
Кривая трафика интернет-магазина совсем не такая, как у B2C-приложений. У B2C пики случайны: вирусное видео или попадание в тренды — и трафик вырастает в 10 раз за 10 минут. У интернет-магазина пики почти всегда предсказуемы: реклама за неделю до отраслевой выставки, день запуска новинки, письма от зарубежных клиентов, которые открывают сайт в рабочие утренние часы Европы и США. Значит, круглосуточное автомасштабирование не нужно — достаточно добавить серверы перед известным событием.
Критерий простой: если время пиков за последние 3 месяца можно отметить в календаре — используйте плановое масштабирование. Если пики полностью случайны и превышают обычный уровень в 5 раз — добавьте реактивное масштабирование как страховку. В B2B-сегменте 90% случаев — это первый вариант. CDN со статическим кешем выдерживает 70% пикового трафика, см.Глобальное ускорение CDN.
| Тип пика | Закономерность | Масштаб | Рекомендуемая стратегия |
|---|---|---|---|
| Трафик с выставки | Известен за 2 недели | В 3–5 раз выше обычного | Плановое масштабирование за 2 часа |
| Запуск новинки | В день запуска | В 2–4 раза выше обычного | Плановое масштабирование за 1 час |
| Реклама | По плану рекламной кампании | В 5–10 раз выше обычного | Плановое + реактивное для надёжности |
| Колебания органического поиска | Пик в утренние часы по будням | В 1,5–2 раза выше обычного | Плановое по будням в определённые часы |
| Внезапная публикация в СМИ | Полностью случайный | Более чем в 10 раз выше обычного | Реактивное масштабирование как страховка |
2. Реактивное масштабирование: как настроить пороги, чтобы не было скачков
Самая частая проблема реактивного масштабирования — «дёрганье»: CPU только перевалил за 60% — добавляется инстанс, через 2 минуты трафик падает и инстанс убирается, через 3 минуты всё повторяется, за день десятки циклов. Решается это тремя параметрами: порог срабатывания, длительность и время ожидания. Для интернет-магазина рекомендуемые значения: масштабирование при CPU выше 60% в течение 3 минут, время ожидания при расширении 5 минут, при сокращении 15 минут.
Ещё один ключевой момент — ограничить максимальное число инстансов. Если не задать потолок, при наплыве краулеров или DDoS-атаке автмасштабирование будет наращивать инстансы, пока вы не получите счёт от облачного провайдера. Ставьте максимум 5 машин: всё, что выше, держат CDN и WAF, а не новые серверы. О том, как связать мониторинг, алерты и ограничение трафика, читайте Мониторинг сайта и оповещения.
| Параметр | Рекомендуемое значение | Что даёт | Что будет при ошибке |
|---|---|---|---|
| Порог масштабирования | CPU>60% в течение 3 минут | Чтобы не срабатывало на кратковременных пиках | Слишком низкий порог = частые скачки |
| Задержка перед масштабированием | 5 минут | Даёт время новой машине запуститься | Слишком короткая = повторное масштабирование |
| Порог снижения | CPU<30% в течение 10 минут | Чтобы не снижать сразу после спада трафика | Слишком короткий = подвисания у пользователей |
| Задержка перед снижением | 15 минут | Период наблюдения | Слишком короткий = метания туда-сюда |
| Минимальное число инстансов | 1 | Гарантия доступности | 0 = медленный холодный старт |
| Максимальное число инстансов | 5 (по бюджету) | Чтобы счёт не вышел из-под контроля | Без потолка = взрывной рост счёта |
三、定时扩缩：独立站最划算的策略
Накануне выставки вечером ставите cron, за 2 часа до начала масштабируете с 1 до 3 инстансов, а через 2 часа после окончания возвращаетесь к 1. Это дешевле реактивного масштабирования по двум причинам: новой машине от холодного старта до приёма трафика нужно 5 минут, а реактивное масштабирование запускается только после алерта по CPU — к моменту готовности машин пик уже наполовину прошёл. Плановое масштабирование готовит машины до пика, и пользователи не ждут.
一个可执行的排期：周一到周五早上8点（对应欧洲客户上班）扩到2台，下午5点缩回1台；展会日提前2小时扩到3台；周末保持1台。这套定时规则覆盖独立站80%的可预测峰值，月成本增量控制在300元以内。多语言站的流量时段差异见 Мультиязычный GEO.
| Временное окно | Часы работы клиентов | Число инстансов | Действие |
|---|---|---|---|
| Будни 08:00–17:00 (Пекин) | Утро в Европе | 2 | Расширение в 8:00, снижение в 17:00 |
| Будни 20:00–24:00 (Пекин) | Утро на восточном побережье США | 2 | Расширение в 20:00, снижение в полночь |
| Выходные круглосуточно | Низкий трафик | 1 | Держим минимум |
| День выставки, за 2 часа | Начало привлечения на выставке | 3 | Срабатывает по расписанию |
| День запуска новинки | Весь день запуска | 3 | Расширение за 1 час |
Четыре. Контроль затрат: как посчитать, окупается ли масштабирование
Модель затрат на автомасштабирование проста: оплата по часам, один VPS 4 ядра / 8 ГБ стоит около 0,5 юаня в час. Днём 3 инстанса, ночью 1 — это примерно 4 юаня в день, 120 юаней в месяц. Без масштабирования пришлось бы держать 3 инстанса постоянно, чтобы выдержать пик, — это лишние 600 юаней в месяц. Экономия от масштабирования — те самые 480 юаней.
Но есть контринтуитивная ловушка: новой машине нужно время на запуск, и если образ тянется медленно, а зависимости инициализируются долго, первые 10 минут машина простаивает. Уменьшите образ (см.Оптимизация Docker-образа) и запускайте скрипт прогрева заранее — это сократит холодный старт одной машины с 10 до 2 минут, и эта экономия тоже деньги.
| Подход | Месячная плата за инстансы | Трафик/CDN | Итого в месяц | Для чего подходит |
|---|---|---|---|---|
| Постоянно 3 инстанса без масштабирования | Около 1800 юаней | 200 юаней | 2000 юаней | Стабильный трафик |
| 1 постоянный + плановое расширение | около 700 ₽ | 200 юаней | 900 ₽ | Регулярные пики |
| 1 постоянный + реактивное расширение | около 600 ₽ | 200 юаней | 800 ₽ | Случайные пики |
| Плановое + реактивное | около 750 ₽ | 200 юаней | 950 ₽ | 独立站推荐 |
Пять: мониторинг — без него вы не узнаете, что автомасштабирование работает
После запуска автомасштабирования нужен дашборд мониторинга, иначе вы не узнаете, когда происходит масштабирование, почему и не превышен ли лимит. Ключевых метрик четыре: текущее число инстансов, число событий масштабирования, средняя загрузка CPU, доля ошибок на инстанс. Смотрите журнал событий раз в день, кривую затрат — раз в неделю.
Критерий: если реактивное масштабирование срабатывает больше 5 раз в неделю, значит плановые правила не покрывают реальный профиль трафика — добавьте эти события в расписание. Если не сработало ни разу за неделю, пороги реактивных правил можно ослабить или отключить, чтобы не просыпаться от алертов ночью. Полный список алертов мониторинга — в Мониторинг сайта и оповещения.
| Метрика | Нормальный диапазон | Тревожный сигнал | Действие |
|---|---|---|---|
| Текущее число инстансов | 1–3 | Долго держится на максимуме 5 | Проверьте, не бот ли это |
| События масштабирования в неделю | 2–5 | >10 или 0 | Настройте расписание или пороги |
| Средняя загрузка CPU | 30–50% | >70% постоянно | Увеличьте минимальное число инстансов |
| Доля ошибок на инстанс | <0.5% | >2% | Проверьте здоровье новых инстансов |
| Месячная плата за инстансы | ±20% от бюджета | Превышение бюджета на 30% | Проверьте максимальное число инстансов |
FAQ: частые вопросы
独立站真的需要自动扩缩容吗？
Какой порог CPU ставить?
Минимальное число инстансов — 1 или 2?
Как не дать парсерам раздуть число инстансов?
Сколько времени занимает запуск нового сервера и как его ускорить?
Можно ли использовать плановое и реактивное автомасштабирование одновременно?
В заключение
自动扩缩容不是越自动越好。对独立站这种流量曲线可预测的业务，把日历上已知的峰值提前2小时扩好，比任何智能算法都省钱、都可靠。反应式扩缩只是兜底，用来应对完全没预料到的突发流量。
Три шага к внедрению: первый — проанализировать кривую трафика за последние 3 месяца и отметить все известные пики; второй — записать эти пики в плановые задания: расширяться за 2 часа до и сужаться через 2 часа после; третий — добавить реактивное правило как подстраховку: срабатывает, когда CPU превышает 60% в течение 3 минут, максимум до 5 серверов. После этих трёх шагов месячные затраты вдвое меньше, чем при постоянных 3 серверах, а пользователи не замечают пиков. Сопутствующий мониторинг см.Мониторинг сайта и оповещения.
一句可以记住的话：独立站的峰值不是惊喜，是日历——把它写进定时任务，比等CPU告警再救场便宜十倍。