Серверная инфраструктура для крупного интернет-магазина

Интернет-магазин электроники в Москве с каталогом из 120 000 SKU и собственным складом работал на едином выделенном сервере, купленном три года назад. В обычные рабочие дни сайт справлялся с нагрузкой: 500–800 одновременных сессий, время загрузки страницы — 1,2 секунды. Но каждая распродажа превращалась в операционную катастрофу. В «чёрную пятницу» предыдущего года сервер ушёл в swap через 40 минут после открытия скидок: время отклика выросло до 8 секунд, Яндекс.Метрика зафиксировала отказ 78% сессий, конверсия упала до нуля. По оценке аналитиков, за один день распродажи компания недополучила 4,2 млн руб. выручки.

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

Создать отказоустойчивый кластер, способный выдержать пиковую нагрузку 10 000+ RPS без деградации и с временем отклика не более 1 секунды. Серверы должны вписаться в имеющуюся стойку 42U в арендованном ЦОД. Бюджет — до 5,5 млн руб., срок — 10 рабочих дней: следующая крупная распродажа через три недели. Оплата — по счёту с НДС.

ЦОД предоставлял только электропитание и охлаждение — никакой поддержки «железа». Компания работала на монолитном PHP-приложении (Laravel), где хранение пользовательских сессий и файлов приложения требовало shared-хранилища: иначе при балансировке нагрузки между узлами пользователи теряли корзину и авторизацию. Shared NVMe-СХД была обязательным элементом архитектуры.

Пять однопроцессорных серверов 1U с 256 ГБ RAM — при равномерной балансировке каждый обрабатывал до 2 500 RPS, итого 12 500 RPS с запасом. Каждый сервер оснащён локальным NVMe 7,68 ТБ для кеша OPcache, Redis и Nginx tmp: операции с локальным кешем выполнялись без обращения к shared-СХД. Shared NVMe-СХД 2U на 30 ТБ нетто хранила файловую систему приложения, медиабиблиотеку товаров и сессии в Redis Cluster. 10/25GbE-коммутатор объединял все узлы и СХД по выделенным 25GbE линкам; к сети ЦОД — через аплинки 10GbE с балансировщиком.

• Вычисление: 5× сервер 1U, Intel Xeon Gold, 256 ГБ RAM DDR5 ECC
• Локальный кеш: 5× NVMe SSD 7,68 ТБ PCIe Gen4, 5× HBA PCIe pass-through
• Shared хранение: all-flash NVMe СХД 2U, 30 ТБ нетто, двойной контроллер
• Сеть: 10/25GbE-коммутатор 48× SFP28, аплинки 2× 100GbE
• Питание: ИБП 10 кВА онлайн, 2× управляемых PDU 32А

День 1: заявка, уточнение архитектуры — проверка, что PHP-приложение поддерживает монтирование по NFS. День 2–3: счёт и оплата. День 4–7: комплектация, тест latency СХД под нагрузкой fio, сборка стека на стенде. День 8: доставка курьером в Москву с подъёмом в стойку ЦОД. Серверы и СХД доставлены на 8-й день — за 5 дней до распродажи.

В следующую «чёрную пятницу» кластер выдержал пик 12 200 RPS. Среднее время отклика в пиковый час — 0,4 секунды. Конверсия вернулась к нормальным показателям; выручка за день превысила прошлогоднюю на 31%. Один из пяти серверов был искусственно выключен во время нагрузочного теста — оставшиеся четыре приняли трафик без снижения производительности. Итоговая стоимость поставки — 5 100 000 руб. с НДС.

Сжатые сроки и специфика shared NVMe-СХД под PHP-приложение — редкое сочетание. ВИСТЛАН предложил готовую спецификацию через 2 часа после звонка и подтвердил наличие всех позиций на складе; конкурент сообщил о сроке 3–4 недели только на СХД.

IT-команда магазина развернула Kubernetes-кластер из пяти узлов с использованием RKE2. Shared NVMe-СХД подключена по NFS v4.1 с включённым pNFS для параллельного чтения с разных контроллеров СХД. Redis Cluster для хранения сессий размещён на локальных NVMe каждого узла с репликацией 1:1 между парами серверов — это исключало потерю сессии при падении любого одного узла. Nginx Ingress Controller настроен на балансировку по методу least_conn, что равномернее распределяло нагрузку при разной длительности обработки запросов к каталогу.

Особого внимания потребовала медиабиблиотека: каталог содержал 420 000 изображений товаров общим объёмом 2,3 ТБ. При прямом обращении к shared-СХД за изображениями latency составляла 8–12 мс — недостаточно для быстрой отдачи страниц. Решение: Varnish Cache на каждом из пяти узлов кешировал изображения на локальном NVMe. После «прогрева» кеша за первые 2 часа работы 95% запросов к изображениям обслуживались с локального NVMe за 0,4–0,8 мс.

Нагрузочный тест перед «чёрной пятницей» показал: кластер стабильно выдерживает 14 000 RPS без деградации в течение 30 минут непрерывной нагрузки. Это дало запас 40% над пиковой нагрузкой прошлого года (10 000 RPS). Команда приняла решение не масштабировать кластер до следующей распродажи.

После «чёрной пятницы» аналитики провели разбор: пиковая нагрузка составила 12 200 RPS в 11:17 — через 17 минут после открытия скидок. Конверсия в этот момент составила 3,8% — на уровне обычных рабочих дней. Время до первого байта TTFB в пиковый момент — 0,38 секунды. Выручка за сутки превысила прошлогоднюю на 31%. Кластер продолжил работу без перебоев на все последующие распродажи квартала.

После «чёрной пятницы» кластер успешно отработал «киберпонедельник», новогодние распродажи в декабре и февральские акции. Ни на одном из этих событий не было ни одного инцидента с производительностью. Аналитики отметили закономерность: после перехода на быструю инфраструктуру средняя глубина просмотра каталога выросла с 4,2 до 6,8 страниц за сессию — пользователи стали больше смотреть товаров, потому что страницы загружались мгновенно. Это дало дополнительный рост конверсии на 0,4 процентных пункта сверх эффекта от устранения тормозов. Технический директор планирует добавить шестой узел кластера в следующем году под рост ассортимента до 200 000 SKU и расширение интеграции с маркетплейсами.

Оговорка: кейс носит иллюстративный характер. Производительность зависит от архитектуры приложения и настройки ПО.