Масштабирование Битрикс в Kubernetes под пиковые нагрузки и распродажи

Соблазн понятен: вместо того чтобы возиться с кластером, просто арендовать сервер помощнее с запасом под распродажу. На бумаге это выглядит проще и дешевле, чем масштабирование Битрикс в Kubernetes. Но на практике вертикальный путь упирается в потолок, плохо переживает сбои и заставляет переплачивать за простаивающие мощности одиннадцать месяцев в году ради одного пикового. Ниже разбираем, в чём разница, какие проблемы решает масштабирование и как мы строим кластер так, чтобы он держал пик и при этом не разорял вас на ресурсах.

Почему один сервер упирается в потолок

Пока сайт живёт на одной машине, его производительность ограничена её ресурсами: ядрами процессора, объёмом памяти, скоростью диска и числом соединений с базой. До определённого момента можно докупать мощность — это вертикальное масштабирование. Но у него есть жёсткий потолок: самая мощная машина всё равно конечна, а её аренда растёт нелинейно. И главное — любой сбой этой машины кладёт сайт целиком. В распродажу, когда каждая минута простоя стоит дорого, это особенно болезненно: реклама ведёт людей на витрину, которая отдаёт ошибки.

Дополнительная ловушка вертикального пути в том, что узкое место часто не там, где кажется. Бизнес докупает процессор, а сайт всё равно тормозит, потому что упирается в базу или в кэш на диске. Без нагрузочного теста деньги уходят на мощности, которые не решают проблему. Поэтому мы всегда начинаем с диагностики, а не с покупки железа вслепую. О том, как мы разбираем подобные узкие места в эксплуатации, мы подробно рассказываем на странице оптимизации и ускорения BitrixVM.

Что меняет горизонтальное масштабирование

Kubernetes переводит сайт на горизонтальную модель: приложение работает как множество одинаковых подов, между которыми распределяется трафик. Под нагрузкой подов становится больше, при спаде — меньше. Падение одного пода не роняет витрину, потому что балансировщик перенаправляет запросы на живые. Автомасштабирование через HPA делает это без участия человека: вам не нужно ночью следить за графиками и вручную добавлять мощность в разгар распродажи.

Но просто запустить Битрикс в нескольких подах недостаточно. Появляются новые задачи: сессии нельзя держать на локальном диске, иначе пользователя будет выкидывать из корзины при переключении между подами. Кэш должен быть общим. База под умноженной нагрузкой быстро становится узким местом. Именно поэтому масштабируемая архитектура — это не только поды, но и кэш Redis, реплики базы и очереди. Контейнеризацию приложения, на которой всё это строится, мы разбираем на странице Docker для Битрикс в разработке и продакшене.

Где на самом деле узкое место под нагрузкой

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

Второе типовое узкое место — кэш и сессии. Когда они лежат на локальном диске, при нескольких подах начинается хаос: поды не видят данные друг друга. Вынос сессий и кэша Битрикс в общий Redis или memcached решает обе задачи сразу — снимает проблему сессий и разгружает базу, потому что горячие данные читаются из памяти, а не считаются заново. Третье — тяжёлые фоновые операции: письма, выгрузки, обмен с 1С, индексация. Они не должны заставлять покупателя ждать, поэтому уходят в очереди и обрабатываются отдельными воркерами.

Готовность к распродаже подтверждается тестом, а не словами

Главная ценность нашего подхода в том, что готовность к пику мы доказываем нагрузочным тестом до распродажи, а не проверяем на живых покупателях. Мы имитируем поток посетителей выше ожидаемого пика и смотрим, как ведёт себя кластер: срабатывает ли автомасштабирование, держит ли база и кэш, не растёт ли отклик, не появляются ли ошибки. Все слабые места исправляются заранее, в спокойной обстановке, а не в ночь чёрной пятницы под звонки от руководства. Это превращает распродажу из стресса в обычный рабочий день с повышенной нагрузкой.

Стресс-тест мы закладываем в каждый проект под распродажи и повторяем после серьёзных изменений. Кластер, который не проверен нагрузкой, считаем не готовым к пику, каким бы правильным ни выглядел на схеме. Запас по трафику закладываем с многократным резервом к ожидаемому пику, чтобы непредвиденная рекламная волна или вирусный всплеск не застали врасплох.

Когда кластер окупается, а когда хватит оптимизации

Мы не уговариваем всех подряд переходить в Kubernetes. Кластер оправдан, когда у вас выраженные пики, дорогой простой, большой каталог или сайт уже вырос из одного сервера. Если же нагрузка ровная и умеренная, а распродаж практически нет, иногда честнее и дешевле сначала оптимизировать текущую инфраструктуру: расшить узкие места базы, настроить кэш, ускорить код. На бесплатном аудите мы прогоняем нагрузочный тест и прямо говорим, что выгоднее в вашем случае — масштабирование в кластер или оптимизация на месте. Решение принимаем по цифрам нагрузки и цене простоя, а не по тому, что нам интереснее продать.

Как мы держим стоимость ресурсов под контролем

Распространённый страх — что кластер окажется дороже сервера. На пике ресурсов действительно нужно больше, но именно тогда они зарабатывают, удерживая заказы, которые иначе ушли бы из-за тормозов. Всё остальное время кластер сжимается. Для подов мы задаём requests и лимиты, чтобы они не съедали лишнего, настраиваем HPA на разумные пороги и подключаем автоскейл узлов, который сокращает кластер вне пиков. Дашборды показывают, куда уходят ресурсы, поэтому переплата за простаивающие мощности видна и устраняется. На дистанции с распродажами такой подход обычно выходит экономнее, чем держать мощную машину про запас круглосуточно.

Как мы ведём проект

Старт — аудит нагрузки и нагрузочный тест текущего сайта. Мы снимаем профиль трафика, находим узкие места и понимаем, что именно держит сайт под пиком. Дальше проектируем архитектуру кластера под вашу нагрузку и бюджет: число подов, схему балансировки, реплики базы, кэш, очереди. Затем контейнеризируем Битрикс, пишем манифесты Kubernetes, настраиваем HPA, requests и лимиты. После поднимаем Redis, реплики и очереди и прогоняем стресс-тест выше распродажного трафика. Только убедившись, что кластер держит пик, выводим его в прод и берём на сопровождение.

Каждый этап заканчивается понятным результатом, а не абстрактным прогрессом. Состав работ и стоимость закрепляем до старта, доработки сверх ТЗ согласуем отдельно. По завершении передаём манифесты, доступы, мониторинг и документацию: кластер остаётся вашим, развивать его сможет как наша команда, так и ваш собственный DevOps. Если переход идёт с привычной BitrixVM, мы опираемся на наш опыт кластеризации и отказоустойчивости BitrixVM, чтобы переезд прошёл предсказуемо и без потери данных.

Возражения, которые мы слышим чаще всего

«Kubernetes — это слишком сложно для нашего сайта». Сложность прячется внутри кластера, а наружу выходит понятная схема: поды, балансировщик, кэш, база, очереди. Мы берём эксплуатацию на себя, отдаём документацию и при желании обучаем вашу команду. Вам не нужно становиться экспертом по Kubernetes, чтобы получить его преимущества — для этого и нужен подрядчик с опытом.

«Мы боимся простоя при переезде». Переезд готовим заранее, поднимаем кластер параллельно, проверяем его тестом и переключаем трафик в момент низкой нагрузки. Видимого простоя для посетителей практически нет, а на случай неожиданностей держим возможность быстрого отката на прежнюю инфраструктуру. Мы переводим сайт тогда, когда уверены, что новый кластер работает не хуже старого.

«А вдруг после запуска мы останемся одни с непонятным кластером». Не останетесь. Мы передаём манифесты и документацию, настраиваем мониторинг и алерты и предлагаем сопровождение с дежурством в распродажу. В пиковые дни DevOps на связи и держит кластер под контролем. При этом всё остаётся вашим: никаких закрытых конфигураций и привязки к нам.

Сценарии, под которые мы собираем кластер

Нагрузка бывает очень разной, и архитектура подстраивается под вашу модель, а не наоборот. Для классического интернет-магазина с распродажами ядром становится автомасштабирование витрины и каталога: посетительский трафик растёт волной, поэтому поды добавляются по HPA, а кэш и реплики держат каталог быстрым. Для маркетплейса с огромным числом товаров и продавцов на первый план выходит база: чтения в разы больше записей, реплик уже не хватает, и мы подключаем шардинг тяжёлых таблиц, чтобы снять потолок одного сервера базы. Для B2B-портала с плотным обменом с 1С критичны очереди: выгрузки и синхронизация не должны мешать покупателям, поэтому уходят в фон отдельным воркерам.

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

Чем масштабирование выгоднее альтернатив

У бизнеса под нагрузкой обычно три пути: держать один мощный сервер про запас, собрать ручной кластер на привычной BitrixVM или перейти в Kubernetes с автомасштабированием. Мощный сервер прост, но упирается в потолок, не переживает собственный сбой и заставляет переплачивать за простаивающие мощности вне пиков. Ручной кластер уже даёт резерв, но масштабируется руками: чтобы добавить ноду в разгар распродажи, нужен дежурный администратор и время, которого в пик нет. Оба варианта плохо контролируют стоимость, потому что резерв либо простаивает, либо докупается заранее наугад.

Kubernetes снимает эти ограничения. Поды добавляются за секунды по метрикам, упавший под заменяется автоматически, а узлы кластера сжимаются вне пиков, так что ресурсы оплачиваются по факту нагрузки. Готовность к пику подтверждается нагрузочным тестом, а не надеждой на запас. Вы получаете и горизонтальный масштаб без потолка, и отказоустойчивость, и предсказуемую стоимость в одном решении. Именно поэтому для проектов с выраженными распродажами и дорогим простоем кластер на дистанции оказывается и надёжнее, и экономнее ручных альтернатив.

Гарантии и сопровождение

Мы понимаем, что кластер становится фундаментом продаж, поэтому к надёжности относимся серьёзно. Состав и стоимость закрепляем в смете до старта, а доработки сверх ТЗ согласуем отдельно — вы всегда понимаете, за что платите. Перед запуском прогоняем ключевые сценарии под нагрузкой: пиковый трафик витрины, тяжёлые запросы к базе, обмен с 1С, поведение автомасштабирования при резком всплеске. После запуска даём гарантийный период, в течение которого устраняем замечания, и предлагаем сопровождение с мониторингом, алертами и дежурством в распродажу. Резервное копирование, контроль стоимости ресурсов и разграничение доступов закладываем с первого дня, чтобы кластер был не только быстрым, но и управляемым.

С чего начать

Начните с разговора и нагрузочного теста. Расскажите о вашем трафике, распродажах и текущей инфраструктуре — мы прогоним тест, покажем, где узкое место, и предложим архитектуру кластера под вашу нагрузку и бюджет. Аудит и оценка бесплатные, а по их итогам вы получите честную картину: что масштабировать в первую очередь, какой запас по трафику реально нужен и во сколько обойдётся готовность к пику. Обсудим ваш проект — и превратим распродажу из риска в обычный рабочий день с повышенной нагрузкой.