Серверный кластер для образовательной платформы дистанционного обучения

EdTech-компания в Воронеже разрабатывала и продавала онлайн-курсы по корпоративному обучению: финансы, управление проектами, soft skills. Платформа работала на монолитном приложении (PHP/Laravel) на арендованном VDS с 32 виртуальными CPU и 128 ГБ RAM. После подписания контрактов с тремя крупными корпоративными клиентами одновременная аудитория выросла с 200 до 800 студентов. Видеолекции начали буферизоваться: пользователи писали в поддержку о зависаниях по 10–15 секунд.

Мониторинг показал: сервер уходил в iowait при одновременном чтении видеофайлов несколькими студентами. VDS-провайдер делил физические диски между десятками виртуальных машин, и при пиковой нагрузке IOPS «заканчивались». Вертикальное масштабирование VDS стоило бы 260 000 руб./мес. дополнительно — без гарантии решения проблемы. CTO принял решение перейти на собственное оборудование.

Перенести платформу на собственные bare-metal серверы, обеспечить комфортный стриминг для 3 000+ одновременных студентов и разместить видеобиблиотеку 120 ТБ локально. Снизить ежемесячные облачные расходы. Бюджет — 4,5 млн руб. с НДС, срок поставки — 2 недели: следующий массовый старт курса через 3 недели. Оплата — по счёту с НДС.

Платформа работала на Docker/Kubernetes: требовались bare-metal узлы с достаточным RAM для контейнерных нагрузок — минимум 128 ГБ на узел. Видеохранилище должно подключаться по NFS или S3-совместимому протоколу — это ограничение архитектуры приложения. Серверное помещение — арендованный сегмент ЦОД в Воронеже: клиент оплачивал стойко-место, электричество и кондиционирование.

Четыре сервера 1U с 128 ГБ RAM — узлы Kubernetes-кластера. При равномерной балансировке каждый обрабатывал до 800 одновременных сессий; суммарно кластер мог обслуживать 3 200+ студентов с запасом 30%. Локальный NVMe 3,84 ТБ на каждом узле служил кешем контейнерных слоёв и OPcache — операции с локальным кешем выполнялись без обращения к NAS. Видеохранилище — высокоскоростной NAS 4U с 48 дисками SATA 16 ТБ (RAID 6, около 620 ТБ нетто) и 4 SSD SAS горячего уровня для 500 наиболее просматриваемых курсов. NAS подключён по 25GbE с LACP-агрегированием: агрегированная полоса 100 Гбит/с — достаточно для 8 000+ одновременных HLS-потоков.

• Вычисление: 4× сервер 1U, Intel Xeon Gold, 128 ГБ RAM DDR5 ECC
• Локальный кеш: 4× NVMe SSD 3,84 ТБ PCIe Gen4 (по одному на сервер)
• Видеохранилище: NAS 4U; 48× HDD SATA 16 ТБ RAID 6; 4× SSD SAS 3,84 ТБ горячий уровень
• Сеть: 25GbE-коммутатор 24× SFP28; 2× аплинк 100GbE к ЦОД-коммутатору
• Питание: ИБП 6000 ВА онлайн

День 1–2: согласование конфигурации Kubernetes-узлов и NAS, проверка NFS-совместимости. День 3–4: выставление счёта, оплата. День 5–9: комплектация, тест агрегирования NAS под нагрузкой 50 одновременных потоков на стенде — измеренная скорость 23 ГБ/с. День 10–11: упаковка, доставка в ЦОД Воронежа. Принято на 11-й день.

В первый пиковый день — сессионная неделя с 3 200 одновременными студентами — ни одного случая буферизации видео. Задержка до первого кадра — 0,9 секунды. Ежемесячные облачные расходы снизились с 520 000 до 68 000 руб. — сохранились только внешние сервисы мониторинга и SMS-шлюз. Видеохранилище 120 ТБ заполнено на 19% — достаточно места для нескольких лет роста. Итоговая стоимость поставки — 4 200 000 руб. с НДС.

CTO компании сравнил три предложения. ВИСТЛАН выиграл по наличию и скорости: все позиции на складе, отгрузка подтверждена в день заявки. Проведённый стресс-тест NAS с одновременными потоками на стенде до отгрузки дал уверенность в результате под реальную нагрузку.

IT-команда EdTech-компании развернула RKE2-кластер из четырёх узлов за два дня после получения оборудования. NAS подключён как NFS PersistentVolume в Kubernetes: StorageClass с provisioner hostpath для видеофайлов и NFS CSI Driver для данных приложения. Видеобиблиотека смонтирована как ReadWriteMany volume — все узлы могут одновременно читать видеофайлы без блокировок. HLS-сегментация видео выполнялась предварительно при загрузке курса: каждый видеофайл нарезался на 10-секундные TS-сегменты и манифест m3u8. Это перенесло нагрузку трансформации с момента просмотра на момент загрузки курса администратором.

Горизонтальный Pod Autoscaler настроен на метрику custom CPU utilization: при утилизации выше 70% Kubernetes добавлял реплики PHP-воркеров. При нагрузке 3 200 студентов кластер поднял 68 реплик воркера против базовых 20 — масштабирование произошло автоматически за 2 минуты. После спада нагрузки реплики масштабировались обратно в течение 10 минут.

Метрики во время сессионной недели: среднее потребление CPU по кластеру — 61%, RAM — 74%, I/O NAS — 18 ГБ/с в пике (при теоретическом максимуме 25 ГБ/с агрегирования). Запас по всем ресурсам — около 30%, что полностью соответствует целевому показателю надёжности.

После успешного сезона CTO принял стратегическое решение: вся новая функциональность платформы разрабатывается с учётом on-premise кластера как основной инфраструктуры. Облако остаётся только для сервисов, где собственная инфраструктура экономически невыгодна: CDN для студентов за пределами Воронежской области, SMS-шлюз, сервис видеоконференций для live-сессий. Ежегодная экономия на облаке — 5,4 млн руб. — будет реинвестирована в разработку новых курсов. Следующий шаг — расширение кластера до 6 узлов под новые направления обучения.

По итогам первого года работы на собственном кластере CFO EdTech-компании составила полный расчёт TCO. Капитальные вложения: 4 200 000 руб. (серверы и NAS). Операционные расходы в год: 816 000 руб. (стойко-место в ЦОД, электричество, мониторинг). Итого за первый год: 5 016 000 руб. Альтернатива (облако): 520 000 руб./мес. × 12 = 6 240 000 руб. — и это без роста нагрузки. Экономия за первый год: 1 224 000 руб. В последующие годы без капитальных вложений: 6 240 000 − 816 000 = 5 424 000 руб. ежегодной экономии. Компания подала заявку на включение в региональную программу поддержки EdTech: собственная IT-инфраструктура стала одним из критериев оценки зрелости компании при отборе участников программы.

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