К списку статей DevOps и Инфраструктура

Горизонтальное масштабирование: Настройка балансировщика HAProxy и репликации баз данных

Опубликовано: 25.09.2026 в 12:34

Когда один сервер больше не справляется: переход от вертикального к горизонтальному масштабированию

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

Архитектурные требования к stateless-приложениям

Чтобы запустить сайт параллельно на трех или четырех серверах, приложение обязано стать stateless — то есть не хранить уникальное состояние внутри локальной файловой системы конкретной ноды. Сессии пользователей выносятся в единый независимый кластер Redis, а все загружаемые медиафайлы (изображения, документы) сохраняются в общее сетевое S3-хранилище. Только после этого балансировщик сможет перенаправлять пользователя на любой случайный сервер без риска сбросить его авторизацию в личном кабинете.

Архитектурная карта распределения слоев HAProxy — 💡 Рис 1. Схема слоев HAProxy

Шаг 1: Конфигурация балансировщика HAProxy для распределения трафика

Устанавливаем HAProxy на выделенный фронтенд-сервер. В файле /etc/haproxy/haproxy.cfg настраиваем опрос веб-нод и проверку их здоровья (Health Checks) в реальном времени.

haproxy

frontend http_front
    bind *:80
    stats uri /haproxy?stats
    default_backend   laravel_nodes

backend laravel_nodes
    balance           roundrobin
    option            httpchk GET /health
    http-check        expect status 200
    cookie            SERVERID insert indirect nocache
    server            app01 192.168.1.11:80 check cookie app01
    server            app02 192.168.1.12:80 check cookie app02
    server            app03 192.168.1.13:80 check cookie app03

Шаг 2: Разделение потоков чтения и записи в Laravel

Для снижения нагрузки на основную СУБД мы переводим операции чтения (SELECT) на реплику (Slave), а операции изменения данных (INSERT/UPDATE) оставляем на основном сервере (Master). Laravel поддерживает это на уровне конфигурации ядра.

php

// config/database.php - Настройка раздельных хостов для Eloquent
'mysql' => [
    'read' => [
        'host' => [
            '192.168.1.22', // IP-адрес СУБД Реплики (Slave)
        ],
    ],
    'write' => [
        'host' => [
            '192.168.1.21', // IP-адрес основной СУБД (Master)
        ],
    ],
    'driver' => 'mysql',
    'database' => 'isitreal_prod',
    'username' => 'laravel_user',
    'password' => env('DB_PASSWORD'),
    // ... остальные параметры
],

Итоги и резюме

Результат масштабирования инфраструктуры

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

Была ли полезна статья?

Оценки помогают мне понимать, какие темы вам наиболее интересны.

Чтобы оценить, войдите или зарегистрируйтесь.