Руководство
Облачная платформа для стартапа: как подготовиться к росту нагрузки
Обновлено · 5 мин чтения
Стартапу на старте нужна платформа, где первый деплой занимает вечер, а уход не требует переписывать код: контейнер, переменные окружения и дамп базы. Горизонтальное масштабирование нужно позже, чем кажется. Первыми при росте нагрузки ломаются подключения к базе, память и скорость выкладки.
Мы делаем DADA Cloud. Масштабирование у неё только вертикальное, ниже написано, что это значит для растущего продукта и когда пора уходить.
Стадии роста
| Стадия | Как выглядит | Что нужно от платформы |
|---|---|---|
| Прототип | Один контейнер и одна база, пользователей единицы | Быстрый деплой, недорогой простой, переменные окружения |
| Первые клиенты | Один экземпляр справляется, но простой уже заметен | Откат релиза, бэкапы базы, логи, свой домен |
| Рост | CPU или память упираются в потолок экземпляра | Рост размера, пул подключений, мониторинг |
| Нагрузка | Одного экземпляра мало, сервисов несколько | Горизонтальное масштабирование, реплики базы, восстановление на момент времени |
Границы между стадиями определяют ваши метрики: загрузка CPU, память, число подключений к базе, время ответа. Число пользователей говорит об этом слабо.
Что ломается первым
Подключения к базе. Число соединений PostgreSQL ограничено, а каждый экземпляр приложения держит свой пул. Следите за произведением: число экземпляров на размер пула в каждом должно укладываться в предел базы. В DADA Cloud доступ к базе идёт через PgBouncer с пулами transaction и session, а у каждой базы есть предел подключений и таймаут запроса. Числа смотрите в консоли. Режим transaction в PgBouncer не поддерживает часть сессионных возможностей PostgreSQL, например LISTEN, поэтому проверьте настройки своей ORM по документации PgBouncer до нагрузки.
Память. Растущий кеш внутри процесса, утечки и тяжёлые запросы заканчиваются остановкой контейнера по памяти. Автомасштабирование DADA Cloud поднимает размер при 90% памяти, но проверяет это раз в 15 минут и не лечит утечку: если процесс заполняет память быстрее, поможет только исправление кода.
Скорость выкладки. Когда релиз выходит несколько раз в день, долгая сборка и отсутствие быстрого отката начинают тормозить команду. В DADA Cloud пуш в связанную ветку по умолчанию запускает сборку и деплой, а откат поднимает один из прежних образов без новой сборки. Окружений для каждого pull request у платформы нет.
База как единая точка отказа. У управляемого PostgreSQL в DADA Cloud нет реплик для чтения и восстановления на момент времени. Копии делаются не чаще раза в час, хранятся 14 дней, а восстановление идёт для одной базы из последнего дампа и перезаписывает её. Записи за последний час при аварии не гарантированы. Подробнее о возможностях базы в материале про облачные базы данных и на странице PostgreSQL.
Фоновые задачи. Запуска по расписанию в DADA Cloud нет, фоновый процесс работает непрерывно. Расписание придётся держать внутри приложения или во внешнем сервисе.
Какое масштабирование есть в DADA Cloud
Только вертикальное. Платформа проверяет приложения каждые 15 минут. Контейнерное приложение растёт, когда троттлинг CPU доходит до 0,25 или память до 90%. Между двумя изменениями одного приложения проходит 6 часов, а рост останавливается на 8 vCPU и 16 ГиБ. При низкой нагрузке размер уменьшается в сторону small.
Размер можно поменять и вручную через API. Три профиля задают запросы ресурсов: small 10m CPU и 128 МиБ, medium 100m и 256 МиБ, large 250m и 512 МиБ. Число реплик от 1 до 10 указывается при создании приложения. Автоматического горизонтального масштабирования нет, а возможность поменять число реплик позже мы не подтвердили.
Из этого следуют две практические вещи. Всплеск, который длится минуты, автомасштабирование не поймает. Для запланированных событий вроде рассылки или рекламной кампании поднимите размер заранее. Подробнее о механике в материале про масштабирование облачного приложения.
Когда уходить на контейнерные кластеры
Пора смотреть на другого поставщика, если выполняется хотя бы один пункт:
- приложению нужно больше 8 vCPU или 16 ГиБ памяти;
- нужны несколько реплик с автоматическим горизонтальным масштабированием;
- нужны реплики базы для чтения, восстановление на момент времени или движки MySQL, MongoDB, ClickHouse;
- нужны запуск по расписанию или отдельное окружение под каждый pull request.
Selectel и VK Cloud по страницам своих продуктов предлагают управляемые контейнерные кластеры и базы нескольких движков. У VK Cloud в Cloud Backup есть режим PITR для PostgreSQL, у Yandex Cloud управляемый PostgreSQL включает PITR по умолчанию. Цены считайте на калькуляторах самих поставщиков.
Как подготовить переезд заранее
Переезд дёшев, если приложение собирается из Dockerfile, хранит настройки в переменных окружения, не держит состояние в файловой системе контейнера и пишет логи в стандартный вывод. Эти правила собраны в методологии 12-factor app. Заранее прогоните пробный pg_dump и загрузку в чистую базу, пока данных мало. Полный порядок описан в материале про переход на другую платформу.
Частые вопросы
Когда добавлять реплики?
Когда один экземпляр не справляется даже на максимальном размере. До этого проще и дешевле увеличить размер, найти медленные запросы и добавить кеш. В DADA Cloud реплики задаются при создании приложения, автоматического добавления нет.
Хватит ли DADA Cloud на первых клиентов?
Для типичного веб-приложения, API или бота с PostgreSQL и Redis хватит. Ограничения те, что перечислены выше: рост только вертикальный, у базы нет реплик и восстановления на момент времени, расписания нет. Если ваш продукт упирается в них с первого дня, начинайте с другого поставщика.
Как пережить всплеск трафика?
Заранее поднимите размер приложения вручную, вынесите тяжёлые операции в фоновую очередь и закешируйте ответы, которые одинаковы для многих пользователей. Автомасштабирование с интервалом 15 минут и паузой 6 часов между изменениями для коротких пиков не подходит.
Что делать с базой при росте?
Начните с индексов и разбора медленных запросов: в консоли есть SQL только на чтение и обзор таблиц, а через MCP доступен explainDatabaseQuery. Затем проверьте предел подключений и размер пулов. Если нужны реплики или восстановление на момент времени, готовьте переезд базы к другому поставщику.
Нужен ли стартапу контейнерный кластер сразу?
Обычно нет: он добавляет работу по настройке и обслуживанию, которая на старте отнимает время у продукта. Он оправдан, когда сервисов много и есть человек, отвечающий за инфраструктуру.