Масштабирование архитектуры продукта — от минимально жизнеспособного (MVP) до highload-системы — это не только технически сложно, но и требует балансирования между скоростью, стабильностью и гибкостью.
Для партнерского материала CTO Favbet Tech Андрей Черныш делится практическим опытом и на примерах рассказывает об эволюции архитектуры — от первых запусков до систем, выдерживающих десятки тысяч запросов в секунду (RPS). Он также делится подходами, которые работают лучше, и от которых стоит отказаться.
Содержание
MVP нужно разрабатывать с взглядом в будущее
Когда продукт растет — увеличивается и количество пользователей, запросов и сложность бизнес-логики. В качестве примера я могу привести масштабирование API Gateway компании Favbet Tech. Этот компонент сейчас является основной точкой входа в систему.
Наша система, как это случается в 99% случаев, начиналась как монолит. Когда нагрузка начала расти, а количество клиентов увеличиваться, мы решили перейти к сервисной архитектуре. Одним из первых шагов стало выделение API Gateway. Его задача — централизованно обрабатывать все внешние запросы, маршрутизировать их к соответствующим сервисам, выполнять базовую валидацию, ограничивать количество запросов, делать аутентификацию и т. д.
После запуска API Gateway начал брать на себя наибольшую нагрузку в системе — благодаря горизонтальному масштабированию, легкому и быстрому старту, использованию языка и фреймворков для обработки запросов с минимальными задержками. Теперь API Gateway выдерживает серьезную продакшн-нагрузку и стал ключевым инструментом для контроля над инфраструктурой в масштабируемой среде.
Начальная архитектура почти всегда монолитная. Это позволяет быстро проверить гипотезы, сократить расходы и запуститься раньше конкурентов. Однако даже на этом этапе продукт нужно разрабатывать с расчетом на потенциальный рост. Поэтому даже MVP-версия API Gateway с самого начала была готова работать с реальными пользователями и под большой нагрузкой. В нее мы уже тогда заложили ключевые функции, необходимые для стабильной работы в продакшн-среде.
Мы никогда не начинаем с идеального решения. MVP должно быть простым и доставленным быстро — но с четким пониманием, куда продукт может эволюционировать.
Принципы, которые помогли создать MVP-версию API Gateway
При создании MVP-версии API Gateway наша команда придерживалась принципов сознательно ограниченной сложности. Поэтому архитектуру MVP построили следующим образом:
- Модульность. Монолит, но с четкими логическими модулями.
- Единая база данных с логическим разделением.
- Простая инфраструктура, но с возможностью масштабирования без чрезмерной сложности.
- Базовый observability: логи, трейсы и метрики.
Поэтому уже на старте продукт имел ключевые функции, необходимые для стабильной работы в продакшн-среде:
- Роутинг запросов к нужным сервисам.
- Базовая аутентификация.
- Rate limiting, то есть ограничение количества запросов для защиты системы.
- Базовые инструменты мониторинга и метрик.
Это позволило быстро запустить продукт, проверить его жизнеспособность и собрать обратную связь.
Как понять, что пришло время масштабироваться
Наш API Gateway с самого начала был готов к продакшену. Но только когда бизнес стал требовать большего — мы осознали, что простого роутера уже недостаточно.
MVP-версия API Gateway хорошо выполняла базовые функции, однако появилась системная потребность в гибкости и расширении контроля. Именно следующие факторы указали на то, что необходимо перейти от MVP к полноценному production-решению:
- Микросервисов стало больше. Статическая маршрутизация перестала быть эффективной. Требовались динамическая конфигурация, A/B-тестирование и feature flags.
- Разнообразие политик безопасности. API Gateway должен был «понимать» контекст каждого запроса.
- Запросы от команд разработки. Появилась потребность в throttling, версионировании, трейсинге, retry-логике и fallbacks.
- Возросла нагрузка. Мониторинг показал, что система нуждается в инструментах для предсказуемого масштабирования.
Технические и организационные вызовы при переходе от MVP к highload
Трудности – естественная часть эволюции любого продукта. При масштабировании API Gateway мы столкнулись с рядом технических и организационных проблем:
- Поиск баланса между скоростью изменений и стабильностью. С переходом в продакшн появилась ответственность за надежность и бесперебойность сервиса.
- Рост нагрузки и сложности инфраструктуры, так как количество микросервисов увеличивалось и это требовало новых инструментов управления.
- Мониторинг. На раннем этапе было достаточно простого логирования. Но с переходом в production возникла потребность в детальном мониторинге метрик и уведомлениях о критических событиях.
- Процессы и взаимодействие между командами. В MVP команда могла быть маленькой и самодостаточной. В продакшн-фазе появилось больше зависимостей между командами и необходимость внедрения формальных процессов разработки.
Когда система переходит с условно стабильной нагрузки в highload-режим (тысячи RPS, миллионы событий в сутки), основная задача архитектора – выявить и устранить «узкие места», сохранив при этом управляемость и стабильность всей системы. Масштабирование сервиса было не радикальным. Мы эволюционно перестроили архитектуру и сосредоточились на том, чтобы устранить эти «узкие места» и одновременно сохранить управляемость системы.
Основные изменения включали такие этапы:
- Разделить монолит на меньшие, независимые сервисы, которые масштабируются отдельно.
- Перейти на асинхронную обработку данных в фоновом режиме с использованием Kafka и RabbitMQ.
- Внедрить Grafana Stack для детального мониторинга.
- Сделать автоматическое горизонтальное масштабирование на основе метрик с помощью Kubernetes.
- Настроить декомпозицию базы данных и внедрить распределенный кеш (DragonflyDB), чтобы снизить нагрузку на основные хранилища.
- Перейти на gRPC вместо REST для взаимодействия между сервисами.
- Вынести авторизацию в отдельный сервис с поддержкой RBAC и OPA.
А поскольку масштабирование – это не только технологии, но и люди, то в процессе мы адаптировали и структуру команд:
- Перешли от универсальных к кроссфункциональным командам, которые отвечают за свой отдельный домен.
- Создали отдельную DevOps/SRE-команду для управления инфраструктурой.
- Внедрили внутренний портал для разработчиков.
- Провели переквалификацию и реструктуризацию для сотрудников, которым было сложно адаптироваться к росту нагрузки.
- Привлекли новых специалистов с нужной экспертизой.
Ошибки и важные уроки
Масштабирование любой системы – это всегда серия гипотез. Некоторые из них не оправдываются, и это нормально. Мы также принимали решения, которые не дали ожидаемого эффекта. Приведу в пример самый яркий этап:
В системе был один из условных монолитов, который не имел большой нагрузки и не требовал существенных изменений и частых обновлений. Мы начали агрессивно разбивать его на части, на микросервисы, да ещё и несколькими командами. Это создало избыточную сложность в CI/CD, синхронизации релизов, коммуникации между сервисами и увеличило стоимость инфраструктуры и её поддержки. Вывод, который мы сделали: архитектура должна расти вместе с бизнесом, а не опережать темпы его развития. Микросервисы – это не про «моду». Они должны быть только там, где действительно болит.
Поэтому здесь я могу дать такие советы:
- Не усложняйте преждевременно. Начинайте с простого, но закладывайте модульность еще на этапе архитектуры.
- Инвестируйте в observability: это ваши глаза и уши в системе.
- Автоматизируйте всё, что возможно: CI/CD, autoscaling, мониторинг. Искусственный интеллект (ИИ) поможет существенно повысить уровень автоматизации.
- Тестируйте под нагрузкой: регулярные load- и spike-тесты помогут выявить слабые места ещё до появления серьёзных проблем.
- Масштабируйте людей и процессы: архитектура растёт вместе с командами.
Highload-тестирование и важные метрики: наш гайд
В Favbet Tech мы практикуем несколько сценариев highload-тестирования с использованием, в частности, JMeter и Grafana k6:
- Load testing: постепенное увеличение нагрузки для определения пределов производительности.
- Spike testing: резкое увеличение трафика для проверки реакции системы.
- Stress testing: перегрузка системы для оценки graceful degradation.
- Soak testing: длительная работа под высокой нагрузкой для выявления утечек памяти, соединений или других проблем.
Тестирование мы проводим каждые несколько недель, даже если нет больших изменений. Например, во время spike-тестирования мы выявили проблему с исчерпанием подключений к базе данных из-за отсутствия пула соединений. Это приводило к каскадным ошибкам. Мы добавили пул подключений, оптимизировали кэш и внедрили circuit breakers.
Также мы постоянно мониторим критически важные метрики на четырёх уровнях. Вместе они позволяют видеть состояние системы и реагировать на аномалии ещё до того, как они повлияют на пользователей.
- Сервисные метрики
- Latency (P50, P95, P99). Если P99 > 1s – сигнал проблемы, даже если P95 «нормальный».
- Throughput (RPS) для оценки реальной нагрузки на компоненты.
- Error rate (4xx, 5xx). Например, всплеск 5xx часто служит сигналом потенциальных сбоев. Метрики CPU/memory/open connections позволяют вовремя определить потребность в масштабировании – как вверх, так и вниз.
- Инфраструктурные метрики
- Pod restarts в Kubernetes сигнализирует о возможной нестабильности.
- Queue length и lags в message-брокерах.
- DB connection usage и query latency.
- Бизнес-метрики
- Request success rate – процент успешно обработанных запросов за определённый интервал времени.
- Количество регистраций и логинов.
- Conversion flow health показывает, доходит ли пользователь до ключевого действия (оплата, регистрация и т. д.).
- Метрики инцидентов
- Alert rate.
- MTTR (Mean Time To Recovery).
- Deployment failure rate.
Масштабирование от MVP до highload – логический процесс роста продукта, который требует тонкого балансирования между скоростью, стабильностью и гибкостью.
Опыт с API Gateway показал, что простота на старте, постепенные и только необходимые изменения, инвестиции в observability и правильная организация команд позволяют создать систему, которая выдержит тысячи RPS и не потеряет стабильность.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: