Один день в году: платформа под пиковой нагрузкой

Крупная образовательная компания раз в год проводит общероссийский урок финансовой грамотности одновременно в большом количестве школ. Сразу после урока ученики и учителя заполняют анкеты на платформе — и именно они являются главным результатом мероприятия.

Задача решается один раз в год и не оставляет права на ошибку

Как было

Годом ранее задача решалась связкой из балансировщика и десяти постоянно работающих виртуальных машин. Мощность закупалась «с запасом» и простаивала несколько дней до мероприятия, а нагрузка на базу данных в час пик всё равно была существенной.

Что мешало

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

Что делали

Отказались от наращивания мощности «на всякий случай»

Предложили изменить саму архитектуру так, чтобы она умела расширяться и сжиматься по фактическому спросу. Запас, купленный заранее, простаивает весь год и всё равно не даёт гарантий в час пик.

Облегчили фронтенд

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

Разделили монолит на самостоятельные сервисы

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

Задали границы автомасштабирования с многократным запасом

Диапазон до восьми рабочих нод и отдельный кластер базы данных с двумя репликами. Дальше система должна была распорядиться этим запасом сама.

Отработали поведение под реальной волной нагрузки

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

Как итог

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

Что изменилось

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

Доля успешных ответов — 100%: за пиковые часы платформа отдала порядка семидесяти семи тысяч положительных ответов, ошибки исчисляются десятками и находятся на уровне статистической погрешности

Новая конфигурация показала более устойчивую производительность при заметно меньшем потреблении ресурсов, чем прежние десять постоянно работающих машин

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

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

Мониторинг кластера выявил, что движок сайта удерживает оперативную память даже в отсутствие пользовательской активности; передали заказчику как приоритетную задачу по дальнейшей оптимизации кода

Подготовка к пиковой нагрузке был вопросом архитектуры, а не закупки мощностей. Для заказчика ценность измеряется не в процентах утилизации кластера, а в том, что ни один учитель и ни один ученик, потративший время на анкету, не увидел в ответ ошибку.