Как масштабировать мобильный бэкенд и не переписать его целиком

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

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

Такой подход нормален. Ошибка начинается позже, когда вертикальное масштабирование превращается в единственный план развития.

Сначала найдите настоящее узкое место

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

До изменений в архитектуре нужно увидеть:

• время ответа основных методов API;
• загрузку процессора и оперативной памяти;
• количество запросов и ошибок;
• медленные обращения к базе данных;
• длительность фоновых задач;
• объём входящего и исходящего трафика.

Средние показатели часто скрывают проблему. Если API обычно отвечает за 100 мс, но у 5% пользователей запрос занимает три секунды, именно эти три секунды и будут отражаться в отзывах.

Отделите приложение от конкретного сервера

Масштабировать проще бэкенд, который не хранит важное состояние внутри одного процесса.

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

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

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

Добавляйте экземпляры приложения, а не бесконечно мощный сервер

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

Это решает сразу две задачи. Во-первых, увеличивается общая пропускная способность. Во-вторых, отказ одного экземпляра не обязан останавливать весь сервис.

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

Не масштабируйте базу данных вслепую

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

• отсутствующие индексы;
• запросы, которые загружают лишние поля;
• многократные обращения к базе внутри одного запроса API;
• отсутствие ограничения на размер выборки;
• длительные транзакции;
• частые отчёты по большим объёмам данных.

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

Уберите тяжёлую работу из пользовательского запроса

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

Такие операции лучше ставить в очередь и выполнять фоновыми обработчиками. API быстро принимает задачу и возвращает ответ, а приложение показывает её статус.

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

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

Не храните пользовательские файлы рядом с приложением

Изображения, документы и видеозаписи быстро занимают диск и мешают свободно добавлять новые экземпляры бэкенда.

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

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

Кеш должен ускорять систему, а не становиться новой базой

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

Но добавление кеша создаёт новый вопрос: когда информация в нём перестаёт быть актуальной?

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

Готовьте бэкенд к старым версиям приложения

С веб-сервисом сервер и клиент обычно обновляются одновременно. В мобильной разработке это не так: часть пользователей месяцами остаётся на старой версии.

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

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

Масштабируйте по фактам

Практичный порядок обычно выглядит так:

1. Настроить метрики и найти узкое место.
2. Оптимизировать код и запросы.
3. Вынести файлы и фоновые задачи.
4. Сделать экземпляры приложения независимыми.
5. Добавить балансировку и горизонтальное масштабирование.
6. Отдельно заняться базой данных.
7. Автоматизировать увеличение ресурсов только после появления понятных порогов.

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

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