Веб-кластер и масштабирование 1С-Битрикс

В обычный день магазин на 1С-Битрикс живёт спокойно на одном сервере. Но приходит распродажа, рассылка или сезон — трафик вырастает в разы, база захлёбывается от запросов на чтение каталога, время ответа ползёт вверх, а на пике сайт и вовсе отдаёт «502». Дальше два пути: бесконечно наращивать один сервер, пока это возможно, или разнести нагрузку на несколько машин — построить веб-кластер. В 1С-Битрикс за это отвечает штатный модуль cluster, который умеет реплицировать базу, балансировать веб-серверы и выносить сессии с кэшем в общее хранилище.

Ниже — практический разбор веб-кластера для highload-магазина: как устроена его архитектура, как работает репликация master-slave, куда девать сессии и кэш, чем горизонтальное масштабирование отличается от вертикального и что проверить перед запуском. Это выжимка из наших проектов по разработке и поддержке высоконагруженных сайтов на 1С-Битрикс — без теории ради теории, только то, что реально влияет на устойчивость под нагрузкой.

Зачем магазину веб-кластер и когда он нужен

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

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

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

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

Архитектура веб-кластера 1С-Битрикс

Чтобы принимать решения осознанно, полезно держать в голове полную схему кластера. Веб-кластер 1С-Битрикс — это не один компонент, а слоёная инфраструктура, где каждый уровень масштабируется отдельно.

• Балансировщик нагрузки. Точка входа, которая распределяет запросы покупателей между веб-нодами. Обычно это nginx, HAProxy или облачный балансировщик провайдера.
• Веб-ноды. Несколько одинаковых серверов с кодом сайта, PHP и веб-сервером. Именно их число наращивают при росте нагрузки — это горизонтальное масштабирование.
• Кластер базы данных. Мастер, принимающий запись, и одна или несколько реплик (слейвов) для чтения. Модуль кластера маршрутизирует запросы между ними.
• Хранилище сессий. Общее для всех нод — Redis или memcached, чтобы авторизация и корзина не «терялись» при переключении нод.
• Кэш-хранилище. Внешний кэш (Redis/memcached), общий для всех веб-нод, вместо локального файлового кэша на каждой машине.
• Хранилище файлов. Общая папка /upload и медиа: сетевое хранилище, синхронизация или CDN, чтобы загруженные файлы были видны всем нодам.

Запрос покупателя проходит по этим слоям сверху вниз: браузер обращается к балансировщику, тот выбирает свободную веб-ноду, нода читает сессию из общего хранилища, берёт данные из кэша или из реплики базы, а изменяющие операции (оформление заказа) отправляет на мастер. Понимание этой цепочки сразу подсказывает, где искать узкое место: медленный отклик каталога — смотрим реплики и кэш, «слетающая» авторизация — смотрим хранилище сессий, невидимые на части нод картинки — смотрим синхронизацию файлов.

Модуль «Веб-кластер»: из чего он собран

В 1С-Битрикс за кластеризацию отвечает штатный модуль «Веб-кластер» (cluster), доступный в старших редакциях. Он не заменяет системного администратора и не настраивает серверы за вас, но берёт на себя главное — делает так, чтобы прикладной код работал в распределённой среде без переписывания. Модуль объединяет несколько подсистем.

• Вертикальный шардинг и репликация БД. Управление мастером и репликами, маршрутизация запросов на чтение и запись, контроль состояния реплик через административный интерфейс.
• Веб-кластер сессий. Хранение пользовательских сессий во внешнем хранилище (база или memcached/Redis), общем для всех веб-нод.
• Мемкэш-серверы. Пул серверов memcached (или Redis) для кэша данных, общий для нод, с распределением ключей.
• Синхронизация кэша и файлов. Инструменты, помогающие держать кэш и загруженные файлы согласованными между нодами.

Ключевая идея модуля — прозрачность для приложения. Разработчик по-прежнему пишет обычные запросы через API D7 и старое ядро, а модуль сам решает, отправить SELECT на реплику или на мастер, взять кэш локально или из общего пула. Это снимает с прикладного слоя львиную долю сложности распределённых систем и позволяет масштабировать типовой магазин, не переписывая бизнес-логику.

Тонкости масштабирования данных, в частности работу с большими справочниками и highload-блоками под нагрузкой, мы отдельно разбирали в материале про highload-блоки в 1С-Битрикс — в кластере они особенно чувствительны к тому, откуда читаются данные и как кэшируются.

Репликация базы данных: master-slave

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

Как это работает. Есть один мастер — сервер, принимающий все изменяющие операции: оформление заказов, изменение остатков, обмен с 1С, редактирование контента. Мастер пишет журнал изменений (бинлог), который в реальном времени применяется на слейвах — репликах. Реплики держат актуальную копию данных и обслуживают запросы на чтение. Модуль веб-кластера анализирует каждый запрос: SELECT без изменения данных отправляет на одну из реплик, а INSERT/UPDATE/DELETE — на мастер.

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

• Чтение масштабируется добавлением реплик. Не хватает мощности на выборки каталога — добавляете ещё одну реплику, и нагрузка чтения делится между ними.
• Запись не масштабируется репликами. Мастер один, и все изменения идут через него. Если узкое место в записи (например, лавина заказов), реплики не помогут — нужны другие приёмы: оптимизация транзакций, шардинг, отложенная обработка.
• Есть задержка репликации (lag). Данные попадают на реплику не мгновенно. В норме это доли секунды, но под нагрузкой lag растёт, и свежезаписанное на мастере может ещё не появиться на слейве.
• Критичное чтение — с мастера. Сразу после записи (показать пользователю только что оформленный заказ) читать нужно с мастера, иначе из-за lag данные могут не найтись. Битрикс умеет помечать такие места.

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

Балансировка нагрузки веб-серверов

Если репликация масштабирует базу, то балансировщик масштабирует уровень приложения — веб-серверы, где выполняется PHP и собираются страницы. Балансировщик стоит перед нодами и распределяет входящие запросы так, чтобы ни одна машина не была перегружена, а отказ узла не ронял сайт.

Основные стратегии распределения:

• Round-robin. Запросы раздаются нодам по кругу. Просто и равномерно, если ноды одинаковой мощности, а запросы примерно равнозатратны.
• Least connections. Новый запрос уходит на ноду с наименьшим числом активных соединений. Лучше подходит, когда запросы разной тяжести.
• По весу (weighted). Более мощным нодам достаётся больше трафика. Удобно, если в кластере машины разной конфигурации.
• Sticky sessions (привязка). Пользователя закрепляют за одной нодой на всю сессию. В Битрикс-кластере это не нужно, если сессии вынесены в общее хранилище — и лучше не использовать, чтобы не мешать равномерности.

Отдельная важная функция балансировщика — health-check, проверка живости нод. Балансировщик периодически опрашивает каждую ноду по служебному URL и, если та не отвечает, выводит её из ротации: трафик перестаёт на неё идти, покупатели этого не замечают. Когда нода восстанавливается, её возвращают в пул. Именно health-check превращает набор серверов в отказоустойчивую систему.

На практике балансировщиком часто выступает nginx или HAProxy на отдельной машине, либо облачный балансировщик хостинг-провайдера. Сам балансировщик тоже не должен быть единой точкой отказа — в серьёзных внедрениях его резервируют (два балансировщика с плавающим IP). Требования к инфраструктуре и веб-окружению под такую схему мы подробно разбирали в статье про хостинг и инфраструктуру для 1С-Битрикс.

Сессии в кластере: общее хранилище

Как только веб-нод становится больше одной, штатные файловые сессии PHP превращаются в проблему. Сессия по умолчанию лежит файлом на диске той ноды, где пользователь авторизовался. Балансировщик при следующем запросе может отправить его на другую ноду — а там этого файла нет. Результат: покупателя «разлогинивает», корзина обнуляется, форма оформления теряет данные. Для магазина это прямые потери конверсии.

Решение — вынести сессии в единое хранилище, доступное всем нодам. Варианты по популярности:

• Redis. Предпочтительный вариант: быстрый, умеет TTL и вытеснение, переживает перезапуск при настройке персистентности. Обрабатывает большое число одновременных сессий с низкой задержкой.
• Memcached. Тоже быстрый и простой, но чисто in-memory: при перезапуске сервиса сессии теряются, и все активные пользователи разлогиниваются. Приемлемо, но менее надёжно, чем Redis.
• База данных. Модуль веб-кластера умеет хранить сессии в отдельной таблице. Надёжно и переживает перезапуски, но создаёт дополнительную нагрузку записи на базу — на highload это спорный выбор.

Технически хранилище сессий подключается на уровне PHP через session.save_handler и session.save_path (например, указывающие на Redis), либо через настройки модуля веб-кластера. После этого любая нода видит одну и ту же сессию, и переключение между нодами становится незаметным для пользователя. Отдельно стоит следить за временем жизни сессий и объёмом хранилища: на большом магазине активных сессий бывают сотни тысяч, и Redis под них нужно правильно размерить.

Кэш в кластере: Redis и memcached

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

Правильное решение — общий кэш во внешнем хранилище. Все ноды читают и пишут в один Redis (или пул memcached), поэтому кэш согласован: что закэшировала одна нода, сразу доступно остальным, а сброс тега инвалидирует данные для всего кластера. Это снимает рассинхрон и разгружает диски нод.

Различайте уровни кэша, которые выносятся в кластере:

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

Загруженные файлы и синхронизация /upload

Незаметная на старте, но болезненная в кластере проблема — загруженные файлы. Картинки товаров, документы, пользовательские загрузки Битрикс кладёт в папку /upload. На одном сервере всё очевидно. В кластере же файл, загруженный через ноду 1, физически лежит только на её диске — и покупатель, попавший на ноду 2, увидит битую картинку.

Способы сделать файлы общими для всех нод:

• Сетевое хранилище. Общая папка /upload монтируется всем нодам по сети (NFS, GlusterFS, облачное файловое хранилище). Просто концептуально, но само хранилище становится точкой отказа и требует резервирования.
• Синхронизация. Файлы реплицируются между нодами (например, через lsyncd или средства модуля кластера). Работает, но есть задержка синхронизации — свежий файл появляется на других нодах не мгновенно.
• Объектное хранилище / CDN. Файлы отдаются из внешнего хранилища (S3-совместимое) или через CDN, а ноды работают только со ссылками. Масштабируется лучше всего и снимает нагрузку отдачи статики с веб-нод.

Для highload-магазина оптимальна связка «объектное хранилище плюс CDN»: статика (картинки каталога) уходит с веб-нод на CDN, а сами ноды занимаются только генерацией динамики. Это одновременно решает проблему общего доступа к файлам и разгружает кластер от раздачи тяжёлых изображений.

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

Веб-кластер — это форма горизонтального масштабирования, но выбирать между «горизонталью» и «вертикалью» нужно осознанно. Это два разных ответа на рост нагрузки, у каждого своя область применения.

Вертикальное масштабирование (scale up) — наращивание ресурсов одного сервера: добавить ядер, памяти, поставить NVMe вместо SATA, ускорить сеть. Плюсы: не меняется архитектура, не нужны общие сессии и репликация, минимум рисков. Минусы: есть жёсткий потолок железа, стоимость топовых конфигураций растёт нелинейно, и остаётся единая точка отказа — сервер один.

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

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

Настройка веб-кластера пошагово

Ниже — принципиальная последовательность внедрения кластера. Конкретные команды зависят от СУБД, ОС и хостинга, но порядок шагов универсален.

1. Оптимизируйте одиночный сервер. Прежде чем городить кластер, включите кэш, проверьте индексы, разберитесь с тяжёлыми запросами и монитором производительности. Часто этого хватает, и кластер откладывается.
2. Настройте репликацию базы. Поднимите реплику (slave), настройте бинлог и репликацию на уровне СУБД, дождитесь синхронизации данных и убедитесь, что lag минимален.
3. Подключите реплику в модуле веб-кластера. В админке добавьте slave-соединение, чтобы Битрикс начал маршрутизировать SELECT на реплику, а запись оставлял на мастере.
4. Вынесите сессии в общее хранилище. Настройте Redis для сессий и укажите его в php.ini или модуле кластера, чтобы сессии стали общими для нод.
5. Вынесите кэш в Redis/memcached. Подключите пул кэша, переключите тип кэша на внешний, проверьте согласованную инвалидацию по тегам.
6. Разверните вторую веб-ноду. Клонируйте окружение, подключите код (общий репозиторий/деплой), общий /upload и то же хранилище сессий и кэша.
7. Поставьте балансировщик. Настройте nginx/HAProxy, распределение запросов и health-check, отключите sticky sessions.
8. Нагрузочное тестирование. Прогоните нагрузку, близкую к пиковой, посмотрите на распределение по нодам, lag репликации, hit rate кэша и поведение при выводе ноды.

Как это выглядит в админке 1С-Битрикс

Управление кластером живёт в разделе «Настройки → Веб-кластер». Там видно состояние узлов, реплик и хранилищ. Схематично панель состояния группы серверов выглядит так:

Один сервер против кластера — наглядно

Мониторинг и метрики кластера

Кластер без мониторинга — чёрный ящик, который однажды молча деградирует. Чтобы управлять устойчивостью, за узлами нужно следить по метрикам. Ключевые ориентиры:

Отдельно держите на виду встроенный монитор производительности Битрикс и панель разработчика: они показывают число и время SQL-запросов, эффективность кэша и «тяжёлые» страницы. Если под нагрузкой резко растёт lag репликации или падает hit rate кэша — это первые сигналы, что кластер нужно расширять или пересматривать конфигурацию, не дожидаясь отказа.

Отказоустойчивость и деплой без простоя

Один из главных бонусов кластера — возможность обслуживать и обновлять инфраструктуру, не роняя магазин. Разберём два сценария, ради которых кластер часто и строят.

Отказ ноды. Если веб-нода умирает, health-check балансировщика это замечает и выводит её из ротации за секунды. Покупатели, чьи запросы шли на неё, автоматически обслуживаются оставшимися нодами — при общих сессиях они даже не теряют авторизацию. Ключевой момент: кластер должен иметь запас мощности, чтобы оставшиеся ноды выдержали перераспределённую нагрузку. Планировать кластер «впритык» без резерва — значит рисковать эффектом домино, когда падение одной ноды перегружает остальные.

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

Отдельная тема — отказ мастера базы. Реплики спасают чтение, но запись идёт только через мастер, поэтому его падение критично. В серьёзных внедрениях настраивают автоматическое или ручное повышение реплики до мастера (failover) и резервируют сам мастер. Это уже уровень зрелой отказоустойчивой архитектуры, к которому приходят по мере роста требований к доступности.

Частые ошибки при построении кластера

• Строят кластер вместо оптимизации — добавляют серверы, не разобравшись, что тормозит из-за отсутствия кэша или кривых запросов. Нагрузка просто размазывается.
• Оставляют файловые сессии при нескольких нодах — пользователей «разлогинивает» и обнуляет корзину при переключении между нодами.
• Держат локальный файловый кэш на каждой ноде — кэш рассинхронизируется, инвалидация тегов не доходит до соседей.
• Забывают про общий /upload — загруженные картинки видны только на одной ноде, у части покупателей битые изображения.
• Читают критичные данные с реплики сразу после записи — из-за задержки репликации только что оформленный заказ «не находится».
• Включают sticky sessions поверх общего хранилища сессий — мешают равномерной балансировке и усложняют вывод нод на обслуживание.
• Планируют кластер «впритык» без запаса мощности — отказ одной ноды перегружает остальные и роняет весь кластер.
• Не мониторят lag репликации и hit rate кэша — деградация копится незаметно и вскрывается только в пик под нагрузкой.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность кластера перед боевым запуском:

1. Одиночный сервер оптимизирован. Кэш включён, индексы на месте, тяжёлые запросы разобраны, монитор производительности зелёный — кластер строится на здоровой базе.
2. Репликация настроена. Слейв синхронизирован с мастером, lag минимален, чтение маршрутизируется на реплики, критичное чтение — с мастера.
3. Сессии в общем хранилище. Redis для сессий подключён, файловые сессии отключены, переключение между нодами незаметно для пользователя.
4. Кэш вынесен и согласован. Внешний кэш общий для нод, инвалидация по тегам работает на весь кластер, сессии и кэш разнесены по политике вытеснения.
5. Файлы общие. Папка /upload доступна всем нодам (сеть/синхронизация/объектное хранилище), статика по возможности на CDN.
6. Балансировщик и health-check. Запросы распределяются равномерно, отказавшие ноды выводятся автоматически, sticky sessions отключены.
7. Есть запас мощности. Кластер выдерживает выход из строя ноды без перегрузки остальных, деплой выполняется по нодам без простоя.
8. Мониторинг настроен. Отслеживаются lag репликации, загрузка нод, hit rate кэша, соединения к БД и статус health-check.

Вывод

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