Чи можна оптимізувати моноліт для highload-систем та як це зробити? Розповідає Head of Engineering в FAVBET Tech

Коли кажуть про переваги мікросервісу, часто забувають згадати, що перехід на нього займає досить багато часу. До прикладу, у FAVBET Tech почали переходити на мікросервіс кілька років тому, але й досі мають 30% залишків моноліту.

Не зручно? Так. Але чи витримає їхній моноліт highload? Теж так. А чи є для його оптимізації якісь особливі підходи та чи варто за нього триматися, розповідає в партнерському тексті Head of Engineering в FAVBET Tech Максим Ільїн.

Моноліт VS мікросервіс для високонавантажених систем

Зазвичай високонавантажені продукти використовують мікросервісну архітектуру. За словами Максима Ільїна, це найправильніший шлях. Тільки так можна масштабувати певний функціонал (сервіс), а також ізолювати й виділяти необхідні ресурси для кожного сервісу окремо. 

Крім того, у мікросервісів:

• гнучкіші розгортання та релізи, що дозволяє оновлювати тільки необхідні частини продукту й не впливати на інші;
• гнучкіша розробка – кожним мікросервісом може займатись окрема команда, що не спричинить конфліктів функціоналу.

Натомість моноліт має наступні обмеження:

• Не можна масштабувати різні компоненти системи. Для монолітної архітектури можемо масштабувати систему в цілому, і це дуже дорого для інфраструктури.
• Функціонал не ізольований, що за певних обставин може впливати на весь проєкт у цілому, аж до непрацездатності продукту. Це стосується не тільки кодової бази проєкту, а й баз даних.
• Складні розгортання та релізи. Мінімальні зміни чи виправлення помилок програми можуть вимагати певного даунтайму всієї системи.

Але чи означає це, що для highload-проєктів у жодному випадку не можна використовувати моноліт? Не зовсім так.

Максим Ільїн:

«Використання монолітної архітектури на стадіях MVP чи для продуктів з невеликою кількістю залежностей – абсолютна норма. Коли замовник не впевнений в реалізації ідеї та потрібно протестувати її на ринку, з фінансового погляду не доцільно вкладати в це великі гроші. А монолітну архітектуру побудувати дешевше, аніж мікросервіс. Тож уже в міру зростання продукту відбувається перехід, і інколи якась частина так і лишається на моноліті».

У компанії FAVBET Tech перехід на мікросервісну архітектуру почали ще кілька років тому. Наразі тут мають приблизно 80% мікросервісів і 20% моноліту. І хоча найближчим роком у компанії планують повністю перейти на мікросервіс, Максим зазначає, що й у моноліта є свої переваги:

• Не потрібно використовувати транспорт між компонентами (мікросервісами) системи. Таким чином не витрачається час, щоб передати дані мережею з одного сервісу в інший.
• У випадку невеликих проєктів певні зручності є для розробки. Робота з кодовою базою виконується в одному репозиторії – там розробнику простіше орієнтуватися по всьому функціоналу системи.

Коли 100% час переходити на мікросервіс

У компанії FAVBET Tech було кілька тригерів, які призвели до рішення перейти на мікросервісну архітектуру.

---

Кейс FAVBET Tech №1

Популярні спортивні події мають велику кількість маркетів (варіанти ставок), та одночасно з великою кількістю користувачів на сайті призводить до великого навантаження платформи.  Оновлення даних в реальному часі для кожного окремого гравця в такому випадку стає викликом стійкості всієї системи.

Поки функціонал нотифікацій не був виділений в окремий мікросервіс, кожне навантаження на сайт під час популярних подій спричиняло проблеми для всієї платформи.. Виникали проблеми з обробкою запитів – аж до того, що платформа взагалі переставала працювати.

---

Кейс FAVBET Tech №2

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

---

Максим каже, що, відтоді як компанія почала переходити на мікросервіс, продуктивність системи збільшилась у рази. Це відстежують кількома способами: 

1. Внутрішні технічні метрики системи.
2. Кількість інцидентів на платформі за період часу.
3. Час витрачений на вирішення проблеми з боку команди розробки.
4. Фідбек від клієнтів.

Декілька років томи проблеми із платформою виникали доволі регулярно. На сьогоднішній день збої в роботі є радше виключенням із правил і трапляються дуже рідко. Тим не менш ми продовжуємо шукати шляхи вдосконалення і максимізації нашого Up time.

Як у FAVBET Tech працюють із залишками моноліту

Головне правило роботи з монолітом у контексті highload – не фокусуватися на його збереженні, а планувати перехід і впроваджувати ті самі методи оптимізації, що працюють і для мікросервісу.

Найефективніші з них:

• Якісне навантажувальне тестування: щоб знати максимальні можливості платформи.
• Скейлінг і даунскейлінг: збільшення і зменшення кількості серверів під потреби.
• Шардування: розподіл даних по декількох базах.

Читати також: Стабільні версії на бекапі, кастомні метрики і не тільки: найкращі практики для highload від FAVBET Tech

 

Унікальних практик для роботи з монолітом для його підготовки під високе навантаження не існує. Тому Максим радить дотримуватись балансу і підходити до питання завчасно — якщо є стратегічний план розвитку бізнесу і можна оцінити майбутні навантаження на продукт, варто заздалегідь планувати перехід на мікросервісну архітектуру та закладати час на вирішення технічного боргу. Це не швидкий процес зі своїми складнощами.

Максим Ільїн:

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

Висновки

Працювати з монолітом можна. Для цього типу архітектури у плані оптимізації під високе навантаження використовують ті самі практики. Утім, їх впровадження може бути складнішим та обходитися дорожче.

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

Більше про FAVBET Tech

 

Візуал: редакція highload.tech