Як масштабувати архітектуру під зростання продукту: від MVP до highload

Масштабування архітектури продукту – від мінімально життєздатного (MVP) до highload-системи – це не лише технічно складно, а й вимагає балансування між швидкістю, стабільністю та гнучкістю. 

Для партнерського матеріалу CTO Favbet Tech Андрій Черниш ділиться практичним досвідом і з прикладами розповідає про еволюцію архітектури – від перших запусків до систем, що витримують десятки тисяч запитів на секунду (RPS). Він також ділиться підходами, які працюють краще та від яких варто відмовитися.

MVP треба розробляти з поглядом у майбутнє

Коли продукт росте – збільшується і кількість користувачів, запитів і складність бізнес-логіки. Як приклад я можу навести масштабування API Gateway компанії Favbet Tech. Цей компонент наразі є основною точкою входу в систему.

Наша система, як це трапляється у 99% випадків, починалась як моноліт. Коли навантаження почало зростати, а кількість клієнтів збільшувалась, ми вирішили перейти до сервісної архітектури. Одним з перших кроків стало відокремлення API Gateway. Його завдання – централізовано обробляти всі зовнішні запити, маршрутизувати їх до відповідних сервісів, виконувати базову валідацію, обмежувати кількість запитів, робити автентифікацію тощо.

Після запуску API Gateway почав брати на себе найбільше навантаження в системі – завдяки горизонтальному масштабуванню, легкому та швидкому старту, використанню мови та фреймворків для обробки запитів з мінімальними затримками. Тепер API Gateway витримує серйозне продакшн-навантаження і став ключовим інструментом для контролю над інфраструктурою в масштабованому середовищі.

Андрій Черниш

CTO Favbet Tech

Початкова архітектура майже завжди монолітна. Це дозволяє швидко перевірити гіпотези, скоротити витрати та запуститися раніше конкурентів. Проте навіть на цьому етапі продукт потрібно розробляти з розрахунком на потенційний ріст. Тому навіть MVP-версія API Gateway з самого початку була готова працювати з реальними користувачами та під великим навантаженням. В неї ми вже тоді заклали ключові функції, необхідні для стабільної роботи в продакшн-середовищі.

Ми ніколи не починаємо з ідеального рішення. MVP має бути простим і доставленим швидко – але з чітким розумінням, куди продукт може еволюціонувати.

Принципи, що допомогли створити MVP-версію API Gateway

При створенні MVP-версії API Gateway наша команда дотримувалась принципів свідомо обмеженої складності. Тому архітектуру MVP побудували наступним чином:

1. Модульність. Моноліт, але з чіткими логічними модулями.
2. Єдина база даних з логічним поділом. 
3. Проста інфраструктура, але з можливістю масштабування без надмірної складності. 
4. Базовий observability: логи, трейси та метрики.

Тому ще на старті продукт мав ключові функції, необхідні для стабільної роботи в продакшн-середовищі:

1. Роутинг запитів до потрібних сервісів. 
2. Базову автентифікацію.
3. Rate limiting, тобто обмеження кількості запитів для захисту системи. 
4. Базові інструменти моніторингу і метрик.

Це дозволило швидко запустити продукт, перевірити його життєздатність і зібрати зворотний зв’язок.

Як зрозуміти, що настав час масштабуватись

Наш API Gateway від початку був готовий до продакшену. Але тільки коли бізнес став вимагати більше – ми усвідомили, що вже не достатньо простого роутера.

MVP-версія API Gateway добре виконувала базові функції, проте зʼявилася системна потреба в гнучкості й розширенні контролю. Саме наступні фактори вказали на те, що необхідно перейти від MVP до повноцінного production-рішення:

1. Мікросервісів стало більше. Статична маршрутизація перестала бути ефективною. Потрібні були динамічна конфігурація, A/B тестування та feature flags. 
2. Різноманітність політик безпеки. API Gateway мав «розуміти» контекст кожного запиту. 
3. Запити від команд розробки. Потреба в throttling, версіонуванні, трейсингу, retry-логіці та fallbacks. 
4. Зросло навантаження. Моніторинг показав, що система потребує інструментів для передбачуваного масштабування.

Технічні та організаційні виклики при переході від MVP до highload

Труднощі – природна частина еволюції будь-якого продукту. При масштабуванні API Gateway ми стикнулись з низкою технічних та організаційних проблем:

1. Пошук балансу між швидкістю змін і стабільністю. З переходом до продакшену зʼявилась відповідальність за надійність та безперервність сервісу. 
2. Зростання навантаження і складності інфраструктури, оскільки кількість мікросервісів збільшувалась і це вимагало нових інструментів управління.
3. Моніторинг. На ранньому етапі було достатньо простого логування. Але з переходом у production виникла потреба у детальному моніторингу метрик та сповіщень про критичні події.
4. Процеси та взаємодія між командами. У MVP команда могла бути маленькою і самодостатньою. У продакшн-фазі з’явилось більше залежностей між командами та необхідність впровадження формальних процесів розробки.

Коли система переходить з умовно стабільного навантаження до highload-режиму (тисячі RPS, мільйони подій на добу), основне завдання архітектора – виявити та усунути «вузькі місця», зберігши при цьому керованість і стабільність всієї системи. Масштабування сервісу було не радикальним. Ми еволюційно перебудували архітектуру та зосередилися на тому, щоб усунути ці «вузькі місця» та одночасно зберегти керованість системи. 

Основні зміни включали такі етапи:

1. Поділити моноліт на менші, незалежні сервіси, які масштабуються окремо. 
2. Перейти на асинхронну обробку даних у фоновому режимі з використанням Kafka та RabbitMQ. 
3. Впровадити Grafana Stack для детального моніторингу.
4. Зробити автоматичне горизонтальне масштабування на основі метрик за допомогою Kubernetes.
5. Налаштувати декомпозицію бази даних і впровадити розподілений кеш (DragonflyDB), щоб знизити навантаження на основні сховища.
6. Перейти на gRPC замість REST для взаємодії між сервісами.
7. Винести авторизацію в окремий сервіс з підтримкою RBAC та OPA.

А оскільки масштабування – це не лише технології, а й люди, то в процесі ми адаптували і структуру команд:

• Перейшли від універсальних до кросфункціональних команд, які відповідають за свій окремий домен.
• Створили окрему DevOps/SRE-команду для управління інфраструктурою.
• Впровадили внутрішній портал для розробників.
• Провели перекваліфікацію та реструктуризацію для співробітників, для яких було складно адаптуватись до зростання навантаження.
• Залучили нових спеціалістів із потрібною експертизою.

Помилки та важливі уроки

Масштабування будь-якої системи – це завжди серія гіпотез. Деякі з них не справджуються, і це нормально. Ми також приймали рішення, які не дали очікуваного ефекту. Наведу у приклад найяскравіший етап:

Тому тут я можу дати такі поради:

1. Не ускладнюйте передчасно. Починайте з простого, але закладайте модульність ще на етапі архітектури.
2. Інвестуйте в observability: це ваші очі та вуха в системі. 
3. Автоматизуйте все, що можливо: CI/CD, autoscaling, моніторинг. Штучний інтелект (ШІ) допоможе суттєво підняти рівень автоматизації.
4. Тестуйте під навантаженням: регулярні load- і spike-тести допоможуть виявити слабкі місця ще до появи серйозних проблем. 
5. Масштабуйте людей і процеси: архітектура росте разом із командами.

Highload-тестування та важливі метрики: наш гайд

У Favbet Tech ми практикуємо кілька сценаріїв highload-тестування з використанням, зокрема JMeter і Grafana k6:

• Load testing: поступове зростання навантаження для визначення меж продуктивності. 
• Spike testing: різке збільшення трафіку для перевірки реакції системи. 
• Stress testing: перевантаження системи для оцінки graceful degradation. 
• Soak testing: тривала робота під високим навантаженням для виявлення витоків пам’яті, з’єднань чи інших проблем.

Тестування ми проводимо кожні кілька тижнів навіть якщо немає великих змін. Наприклад, під час spike-тестування виявили проблему з вичерпанням підключень до бази даних через те, що не було пулу підключень до бази даних. Це призводило до каскадних помилок. Ми додали пул підключень, оптимізували кеш і впровадили circuit breakers.

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

1. Сервісні метрики

• Latency (P50, P95, P99). Якщо P99 > 1s – сигнал проблеми, навіть якщо P95 «нормальний». 
• Throughput (RPS) для оцінки реального навантаження на компоненти. 
• Error rate (4xx, 5xx). Наприклад, сплеск 5xx часто служить сигналом потенційних збоїв. Метрики CPU/memory/open connections дозволять вчасно визначити потребу в масштабуванні – як вгору, так і вниз.

2. Інфраструктурні метрики

• Pod restarts у Kubernetes сигналізує про можливу нестабільність. 
• Queue length і lags у message-брокерах. 
• DB connection usage і query latency. 

3. Бізнес-метрики

• Request success rate – відсоток успішно оброблених запитів за певний інтервал часу.
• Кількість реєстрацій та логінів. 
• Conversion flow health показує, чи доходить користувач до ключової дії (оплата, реєстрація тощо). 

4. Метрики інцидентів

• Alert rate. 
• MTTR (Mean Time To Recovery). 
• Deployment failure rate.

Масштабування від MVP до highload – логічний процес росту продукту, який вимагає тонкого балансування між швидкістю, стабільністю та гнучкістю.

Андрій Черниш

CTO Favbet Tech

Досвід з API Gateway показав, що простота на старті, поступові й лише необхідні зміни, інвестиції в observability і правильна організація команд дозволяють створити систему, яка витримає тисячі RPS і не втрачає стабільність.