СУБД-кластер на Yadro Vegman S220 для высоконагруженного интернет-магазина

Интернет-магазин, входящий в топ-50 по обороту российского e-commerce с годовым GMV порядка 18 млрд рублей, столкнулся с системной деградацией СУБД в период пиковых распродаж. Базы данных PostgreSQL 14 работали на четырёх серверах 2019 года с дисками SAS HDD 7200 RPM в RAID 10. В Чёрную пятницу 2023 года p99-латентность REST API достигала 800–1200 мс при норме 150 мс; около 4% транзакций завершалась ошибкой таймаута gateway. Мониторинг показывал: узким местом является дисковый I/O — ожидания на pg_stat_bgwriter превышали 90% времени запроса. Потери от деградации — около 3% выручки пикового дня, или примерно 8 млн рублей. Команда приняла решение о полной замене платформы СУБД до следующего сезона.

Перевести продуктивный кластер PostgreSQL на новую аппаратную платформу с целевыми показателями: TPS не менее 30 000 транзакций/секунду, p99-латентность не более 20 мс при пиковой нагрузке. Решение должно работать на Astra Linux (требование ИБ-службы, субъект КИИ) и вписываться в аппаратный бюджет 5 млн рублей.

Компания относится к субъектам КИИ — обязательна сертифицированная операционная система. Репликация PostgreSQL должна обеспечивать RPO = 0 (без потери транзакций) для продуктивных баз при любом сценарии отказа. Существующие серверы 2019 года сохраняются и переводятся в dev/staging окружение. Срок окна миграции продуктива — не более 2 часов в ночное время пятницы.

Три сервера Yadro Vegman S220 G2 в конфигурации single-socket: один Intel Xeon Gold 6338N (32 ядра, 2.1–3.8 ГГц Turbo Boost) и 512 ГБ DDR4 ECC 3200 МГц. Выбор single-socket не случаен: PostgreSQL плохо масштабируется на NUMA-топологии dual-socket из-за конкуренции между сокетами за shared buffer. S220 полностью устраняет эту проблему при сохранении высокого числа ядер.

Каждый узел несёт шесть NVMe U.2 7.68 ТБ Micron 7450 PRO (750 000 IOPS random read, PCIe 4.0) для табличных пространств и два NVMe Samsung PM9A3 1.92 ТБ для WAL-журнала и системного раздела. Дисковый IOPS каждого узла — около 4.5 млн на чтение.

Кластер PostgreSQL управляется Patroni с двумя synchronous_standby: запись подтверждается только после применения WAL на оба standby — RPO = 0 гарантирован. Failover через etcd — автоматический за 12 секунд. Балансировка клиентских подключений — HAProxy + pgBouncer на отдельных легковесных VM, направляющих SELECT на standby-узлы.

• Вычисление: 3 × Yadro Vegman S220 G2 (1×Xeon Gold 6338N, 512 ГБ ECC), каждый с 6×NVMe 7.68 ТБ + 2×NVMe 1.92 ТБ WAL
• Сеть: 1 × Eltex ESR-100 25GbE 24×SFP28, 12 × DAC SFP28 3 м
• RAID загрузки: 3 × Broadcom SAS 9400-8i
• ИБП: 2 × Eaton 9SX 3000i rack Online

Партнёрский статус ВИСТЛАН с Yadro обеспечил прямые партнёрские цены на серверы Vegman S220 — экономия 19% от публичных рыночных цен, около 912 000 рублей. Диски Micron 7450 PRO (18 штук) закуплены в рамках квартального объёма поставок ВИСТЛАН по Micron-программе, что добавило дополнительные 7% скидки от дистрибьютора. Суммарная экономия на оборудование — порядка 1,1 млн рублей.

Дни 1–2: детальный профилинг текущей нагрузки PostgreSQL (pg_stat_statements, wait events, iostat, iotop), выбор финальной конфигурации NVMe-дисков. Дни 3–5: поставка серверов. Дни 6–7: развёртывание Astra Linux SE 1.7, PostgreSQL 16, Patroni 3.x, etcd, HAProxy, pgBouncer. День 8: нагрузочное тестирование в staging-среде (pgbench 100 клиентов × 10 потоков, 30 минут). День 9: ночное окно — pg_basebackup на два новых standby, переключение HAProxy, тест производительности под реальной нагрузкой; дежурство инженера ещё 8 часов после переключения.

После переключения TPS в Patroni-кластере вырос до 35 000 (прирост 338% к исходным 8 000 TPS). p99-латентность снизилась с 120 до 18 мс. Следующая Чёрная пятница прошла без единого таймаута при пиковой нагрузке 41 000 TPS. За 10 месяцев эксплуатации автоматический failover не потребовался ни разу. Сумма поставки — 4 800 000 рублей с НДС с учётом экономии 19%.

Опыт ВИСТЛАН в СУБД-проектах с 2010 года, PostgreSQL DBA-экспертиза в инженерной команде, прямое партнёрство с Yadro и глубокое понимание специфики e-commerce нагрузок на PostgreSQL (включая профилирование планов запросов и тюнинг Patroni) определили выбор. Инженер ВИСТЛАН лично сопровождал ночное окно миграции и дежурил 12 часов после переключения продуктивной нагрузки.

Patroni 3.x сконфигурирован с параметром synchronous_mode: true и synchronous_node_count: 2 — это означает, что транзакция считается зафиксированной только после получения подтверждения от обоих standby-узлов. При такой конфигурации RPO = 0 гарантирован даже при одновременном отказе primary и немедленном переключении на standby — данные на standby всегда идентичны primary в момент отказа.

etcd-ансамбль из 3 узлов (два на новых серверах + один на существующей инфраструктуре) обеспечивает кворум для Patroni. При отказе двух из трёх узлов etcd кластер PostgreSQL переходит в read-only режим до восстановления кворума — это защита от split-brain. Параметр ttl (Time To Live для лидерства) установлен в 30 секунд, loop_wait = 10 секунд — failover занимает 12–25 секунд при отказе primary.

pgBouncer в режиме transaction pooling снижает число реальных соединений к PostgreSQL с 1 500 (максимум клиентских соединений в e-commerce) до 200 backend-соединений. Это критично: PostgreSQL деградирует при числе реальных соединений свыше 200–300 из-за overhead на управление памятью. HAProxy балансирует клиентские соединения между двумя standby для SELECT-запросов аналитики и направляет все DML-запросы на primary.

Для мониторинга PostgreSQL-кластера применён стек Prometheus + postgres_exporter + Grafana с дашбордами из открытых репозиториев, адаптированными под специфику e-commerce нагрузок. Алерты настроены на: lag репликации > 1 МБ (потенциальный RPO-риск), количество долгих транзакций > 10 (блокировки), размер TPS < 10 000 в рабочее время (деградация производительности). Инженер ВИСТЛАН передал все дашборды и runbook по реагированию на алерты.

При росте нагрузки свыше 50 000 TPS доступны два пути масштабирования без замены оборудования. Горизонтальное: добавление четвёртого узла Yadro Vegman S220 G2 (ещё один standby с read-реплика PostgreSQL) займёт 4–6 часов. TPS read-запросов масштабируется линейно с числом standby-узлов. Вертикальное: апгрейд RAM с 512 ГБ до 1 ТБ на каждом существующем узле (4 свободных DIMM-слота) увеличит доступный shared_buffers в 2 раза и снизит количество disk read запросов. ВИСТЛАН подготовил рекомендацию по порогам принятия решений: при достижении среднесуточного TPS > 40 000 в течение 14 дней подряд — инициировать расширение. Соответствующий Zabbix-триггер настроен и уведомит администраторов автоматически.

Настройка PostgreSQL 15 на трёхузловом кластере Patroni с Yadro Vegman S220 G2 (2× EPYC 9254, 512 ГБ DDR5) включала специфические оптимизации под NUMA-архитектуру AMD EPYC. Параметры postgresql.conf: max_connections = 1200 (с PgBouncer перед кластером), shared_buffers = 96GB (25% от 384 ГБ на вычислительные хосты), effective_cache_size = 288GB, huge_pages = on (THP отключён, статические hugepages 2 МБ выделены через /etc/sysctl.d/). Параметры ядра Linux (Astra Linux SE): numa_balancing=0 (балансировку NUMA выполняет PostgreSQL через pg_numa расширение), vm.dirty_ratio=5, vm.dirty_background_ratio=2 для снижения write amplification на NVMe. После применения оптимизаций медианная задержка SELECT-запроса OLTP снизилась на 22% по сравнению с базовой конфигурацией.

ВИСТЛАН передал заказчику полный архитектурный пакет: схему кластера Patroni (три узла Yadro Vegman S220 G2, etcd-кворум, HAProxy endpoint), матрицу ролей (primary/standby) и правила автоматического failover, описание конфигурации replication slots и wal_keep_size, инструкцию по ручному switchover без потери данных и инструкцию по расширению кластера четвёртым узлом. Документация актуализируется при каждом изменении конфигурации в рамках постгарантийного сопровождения.

Конфигурации, производители и цены носят ориентировочный характер и могут изменяться. Точные параметры согласовываются индивидуально при оформлении заказа.