Как настроить масштабирование облачного приложения при росте нагрузки

Облачное приложение масштабируют двумя способами: дают одному экземпляру больше ресурсов (вертикально) или запускают больше экземпляров (горизонтально). На DADA Cloud работает первый способ: платформа проверяет нагрузку раз в 15 минут и увеличивает размер приложения до потолка 8 vCPU и 16 Gi, а профиль можно сменить вручную. Горизонтального автомасштабирования и запуска задач по расписанию (cron) на платформе нет, и ниже сказано, что с этим делать.

Шаг 1 - Найдите узкое место

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

Если упираетесь в процессор или память приложения, помогут больший размер или больше экземпляров. Если базу держит медленный запрос, лишние экземпляры только усилят давление на неё. На DADA Cloud метрики и логи доступны в консоли, а для медленных запросов есть план выполнения: MCP-инструмент explainDatabaseQuery и SQL-консоль только для чтения (SELECT, 5 секунд, до 1000 строк).

Шаг 2 - Сделайте приложение без состояния

Горизонтальный рост работает, когда любой экземпляр может обслужить любой запрос. Для этого сессии храните в базе или Redis, загруженные файлы пишите во внешнее объектное хранилище или на общий том, фоновую работу отдавайте отдельному процессу, а настройки читайте из переменных окружения. Принципы описаны в 12-factor: про процессы и про масштабирование через процессы.

На DADA Cloud постоянный том общий для всех экземпляров (RWX), его размер можно только увеличивать. Это подходит для файлов, но не заменяет базу данных: блокировки и очереди на файлах строить не стоит.

Шаг 3 - Защитите базу данных

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

Пул соединений. Каждый экземпляр держит свой пул, и сумма по всем экземплярам должна укладываться в лимит базы. Условный пример: 5 экземпляров по 10 соединений дают 50. Перед базой на DADA Cloud стоит PgBouncer с пулами в режимах transaction и session, а у каждой базы есть собственный лимит соединений и таймаут запроса. Актуальные значения смотрите в консоли. В режиме transaction pooling состояние сессии между запросами не сохраняется, помните об этом при настройке драйвера.

Кеш. Управляемый Redis создаётся инструментом createServiceCache или запросом к API, а REDIS_URL записывается в привязанное приложение. Это пользователь с ограниченными правами на общем экземпляре, ключи изолированы префиксом. Резервных копий у Redis нет, и инструмента запросов тоже, поэтому держите в нём только то, что можно пересобрать из базы.

Очереди. Тяжёлую работу (письма, отчёты, обработка файлов) выносите в фоновый процесс. У приложения на платформе есть признак worker: он запускает постоянный процесс. Очередь можно построить на списках Redis или на таблице в PostgreSQL. Задачи, которые нельзя потерять, храните в PostgreSQL: у него есть резервные копии, а у Redis нет.

Следите и за объёмом данных: при 80% квоты хранилища платформа предупреждает, при 100% база становится доступной только для чтения. Рост нагрузки обычно означает и рост данных. Подробнее о базах: облачные базы данных и страница баз.

Шаг 4 - Настройте вертикальное масштабирование на DADA Cloud

Автомасштабирование работает для контейнерных приложений по таким правилам:

• проверка идёт каждые 15 минут;
• размер растёт, когда показатель троттлинга CPU достигает 0,25 или память достигает 90%;
• между изменениями одного приложения проходит минимум 6 часов;
• потолок 8 vCPU и 16 Gi;
• когда запас больше не нужен, размер уменьшается в сторону малого профиля.

Ручное изменение профиля доступно в настройках приложения и запросом PATCH .../profile к API. Базовые профили заданы по запрашиваемым ресурсам:

Из правил следуют два практических вывода. Короткий всплеск на несколько минут автомасштабирование не поймает: проверка редкая. А после одного увеличения следующее возможно только через 6 часов. Если вы знаете о пике заранее (рассылка, запуск, акция), поднимите профиль вручную накануне. Учёт ресурсов идёт по запрошенным значениям, раз в час, так что больший профиль стоит дороже, пока вы его держите.

Реплики. При создании приложения из образа задаётся число реплик от 1 до 10. Отдельного способа менять его на ходу мы не подтверждали, поэтому закладывайте число с запасом и убедитесь, что приложение корректно работает в нескольких экземплярах (шаг 2).

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

Шаг 5 - Решите, когда переходить на контейнерные кластеры

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

• одному экземпляру нужно больше 8 vCPU или 16 Gi;
• нагрузка прыгает быстрее, чем раз в 15 минут и раз в 6 часов, и нужны реплики, которые добавляются по метрикам;
• нужны задачи по расписанию как отдельный ресурс;
• нужны реплики базы для чтения, другой движок (MySQL, MongoDB, ClickHouse) или выбор размера экземпляра: на DADA Cloud есть только управляемый PostgreSQL без этих настроек.

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

Частые вопросы

Есть ли на DADA Cloud горизонтальное автомасштабирование?

Нет. Платформа не добавляет реплики сама. Число реплик от 1 до 10 выбирается при создании приложения из образа, а растёт приложение за счёт вертикального автомасштабирования.

Как быстро автомасштабирование реагирует на нагрузку?

Проверка идёт раз в 15 минут, а после изменения размера следующее возможно не раньше чем через 6 часов. Для всплесков, которые вы можете предсказать, поднимайте профиль вручную заранее.

До какого размера вырастет приложение?

До 8 vCPU и 16 Gi. Если этого мало, нужно либо разбивать нагрузку на несколько приложений, либо переходить на платформу с кластерами.

Можно ли запускать задачи по расписанию?

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

Что делать, если не справляется база данных?

Начните с индексов и плана запроса, затем добавьте кеш в Redis и проверьте пул соединений. Размер экземпляра и диска на DADA Cloud выбрать нельзя, а реплик для чтения нет. Если упираетесь в это, базу можно перенести обычными pg_dump и psql.

Сколько стоит больший размер?

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

Источники

• The Twelve-Factor App: процессы
• The Twelve-Factor App: параллелизм
• Руководство по развёртыванию приложения