Масштабирование SaaS-продукта: находим узкое место и растим платформу по ступеням

Профиль запросов

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

Нагрузочная модель по вашему профилю

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

Порядок исправлений

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

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

«Шумный сосед» — клиент, чья операция занимает общие ресурсы. Типичный случай: ночью запущен импорт на большой объём данных, и утром у всех остальных медленно открываются списки. Чинят это не мощностью, а правилами.

Лимиты по клиенту

• Обращения к API. Лимит по ключу и по тарифу с понятным ответом «подождите» и временем, через которое можно повторить. Без этого интеграция клиента с ошибкой в цикле выглядит для сервера как атака.
• Параллельные задачи. Каждому клиенту доступно ограниченное число одновременных тяжёлых задач, чтобы одна организация не заняла всех исполнителей.

Очередь с честным распределением

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

Расширить, перенести, сжать

Изменение делится на три релиза. Сначала добавляется новая структура рядом со старой, и приложение умеет работать с обеими. Затем данные переносятся порциями в фоне, с проверкой количества и сумм. Только после этого старая структура убирается. Каждый шаг можно откатить, пока не выполнен следующий.

Перенос крупного клиента в отдельную базу

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

Эта страница про рост уже работающего продукта: замеры, узкие места, миграции, нагрузка от крупных клиентов. Если платформы ещё нет, начинают с разработки SaaS-платформы, а для первой версии — с состава и ограничений, как в статье «Как разработать SaaS с нуля».

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

Порядок узких мест подробно разобран в статье «Как масштабировать SaaS и B2B-продукт».