Технології та Інфраструктура → Хмарна архітектура та SLA

Хмарна архітектура та SLA

1) Навіщо SLA і як ними управляти

SLA (Service Level Agreement) - зовнішня обіцянка бізнесу/партнерам про доступність, швидкість і коректність сервісу.
SLO (Service Level Objective) - внутрішні цільові рівні для команд.
SLI (Service Level Indicator) - вимірювані метрики, на основі яких оцінюється SLO.

Для iGaming/фінтех характерні жорсткі вікна піків (турніри, лайв-ставки, звітні періоди, «зарплатні» дні), сильна залежність від PSP/KYC-провайдерів і географії. SLA повинні враховувати цю поведінку, а архітектура - забезпечувати гарантії не тільки середні, але і перцентильні.

2) Базова термінологія

Доступність (Availability) - частка успішних запитів за інтервал.
Латентність - P50/P95/P99 для ключових операцій.
Помилка - визначайте точно (5xx, таймаут, бізнес-помилка?).
RTO (Recovery Time Objective) - скільки часу допускається на відновлення.
RPO (Recovery Point Objective) - скільки даних можна втратити при аварії.
Error Budget - 1 − SLO, «запас» на зміни та інциденти.

3) Каркас хмарної архітектури під SLA

3. 1 Багатозонність (Multi-AZ)

Реплікація стану (БД, кеш, черги) на мінімум 2-3 AZ.
Холодні/теплі стендбай, автоматичний failover.
Локальні балансувальники (L4/L7) з health-чеками per-AZ.

3. 2 Мультирегіон

Актив-актив: низькі RTO/RPO, складніше консистентність і вартість.
Актив-пасив (hot/warm): дешевше, RTO більше, але простіше контроль даних.
Географічний роутинг (GeoDNS/Anycast), ізоляція «blast radius».

3. 3 Сховища та дані

Транзакційні БД: синхронна реплікація всередині регіону, асинхронна міжрегіональна.
Кеш: крос-регіональні репліки, режим «local reads + async warmup».
Об'єктне сховище: версіонування, лайф-цикли, cross-region replication.
Черги/стрімінг: дзеркальні кластери/мульти-регіональні потоки.

3. 4 Ізоляція контурів

Розділення критичних сервісів (payments/wallet) і «важких» аналітичних завдань.
Rate-limits/quotas між контурами, щоб звіти не «з'їдали» прод.

4) Патерни високої доступності

Bulkhead & Pool Isolation - ізоляція пулів з'єднань і ресурсів.
Circuit Breaker + Timeouts - захист від залежань зовнішніх інтеграцій.
Idempotency - повторюємо запити без подвійних списань.
Graceful Degradation - при деградації відключаємо нефундаментальні фічі (аватарки, розширені фільтри).
Backpressure - керуйте вхідним потоком, не допускайте черг «до горизонту».
Chaos/Failure Injection - планові «провали» для перевірки гіпотез надійності.

5) Стратегії DR (Disaster Recovery)

Вибір: платежі/гаманець - мінімум Hot Standby; контент/каталог - Warm; звіти - Backup & Restore з чіткими вікнами.

6) Про SLI/SLO: Як правильно міряти

6. 1 SLI за рівнями

Клієнтський SLI: end-to-end (включаючи шлюз і зовнішніх провайдерів).
Сервісний SLI: «чиста» латентність/помилки сервісу.
Бізнес-SLI: CR (registratsiya→depozit), T2W (time-to-wallet), PSP-decline rate.

6. 2 Приклади SLO

Доступність Core API: ≥ 99. 95% за 30 днів.
Латентність payout-ініціації: P95 ≤ 350 мс, P99 ≤ 700 мс.
Доставка вебхуків PSP: ≥ 99. 9% протягом 60 сек (з ретраями).
Data Freshness звітів: ≤ 10 хв лаг в 95% часу.

6. 3 Error Budget Policy

50% бюджету - на зміни (релізи/експерименти), 50% - на інциденти.
Згоряння бюджету → фриз фіч, тільки стабілізація.

7) Продуктивність і масштабування

HPA/VPA з SLO-орієнтованими сигналами (не тільки CPU, але і черги/латентність).
Предиктивний скейлінг на основі розкладів та історичних піків.
Warm pools/попередній прогрів з'єднань до БД/PSP перед турнірами.
Кешування і edge - зменшувати RTT, особливо для каталогів ігор і статичних асетів.

8) Мережевий шар і глобальний трафік

Anycast/GeoDNS для мінімізації латентності та локалізації аварій.
Failover-політики: health-проби регіону, пороги, «stickiness» з TTL.
mTLS/WAF/Rate Limit на краю, захист від бот-трафіку.
Egress-контроль до PSP/KYC по allow-list і SLA-aware ретраям.

9) Дані та консистентність

Вибір рівня узгодженості: строга (payments) vs eventual (каталог/рейтинги).
CQRS для розвантаження читання і вертикей критичних команд.
Outbox/Inbox для «рівно-одного разу» доставки подій.
Міграції без даунтайму: expand-migrate-contract, подвійний запис під час MAJOR-змін.

10) Спостережуваність (Observability) під SLA

Трейси крізь шлюз: кореляція'trace _ id'з партнером/регіоном/версією API.
SLO-дашборди з burn-rate, «погода» по регіонах і провайдерам.
Алерти за симптомами, а не за симптомами-проксі (не CPU, а Р99/помилки).
Synthetics: зовнішні перевірки з країн таргету (TR, BR, EU...).
Аудит та звітність: експорт SLI/SLO в партнерський портал.

11) Безпека та комплаєнс

Сегментація мереж і секрет-менеджмент (KMS/Vault).
Шифрування в польоті/спокої, токенізація PAN/PII.
Політики доступу за ролями для адмінок/операторок.
Логи незмінні (WORM) і ретеншн для аудиту.
Регуляторика: зберігання в регіоні, звіти, доказовість виконання SLA.

12) FinOps: SLA як драйвер вартості

Ставте ціни на девіації SLO: скільки коштує + 0. 01% доступності?
Профілюйте пікові вікна, не роздмухуйте постійну потужність.
Right-sizing і «spot де можна» для фонових завдань.
Квоти та бюджети на контури, не допускайте «безкоштовної» деградації.

13) Тестування надійності

GameDay/Chaos-сесії: вимкнення AZ/PSP, затримки в чергах, розриви BGP.
DR-дрилі: регулярний тренінг перемикання регіонів з цілями по RTO.
Load & Soak: тривалі прогонки з реальними профілями ставок/турнірів.
Replay-інцидентів: бібліотека відомих фейлів і скрипти відтворення.

14) Процесна сторона SLA

Каталог SLO: власник, формула, метрики, джерела, алерти.
Зміни через RFC/ADR: оцінка впливу на error budget.
Постмортеми: поліпшення архітектури та ранбуків, коригування SLO.
Комунікації з партнерами: розсилки, статус-сторінка, planned maintenance.

15) Приклади SLI/SLO/звітів

15. 1 Формули

SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек

15. 2 Приклад набору SLO для Core API

Доступність (30 днів): 99. 95%

P95 ендпоінта '/v2/payouts/create': ≤ 350 мс

Помилки 5xx (ковзне 1 год): < 0. 3%

Webhook delivery ≤ 60 сек (P99): ≥ 99. 9%

RPO для гаманця: ≤ 60 сек, RTO ≤ 5 хв

15. 3 Звіт SLA (вичавка)

Виконано: 99. 97% (SLO 99. 95%) +

Порушення: 2 епізоди по регіону BR через PSP-таймаути (сукупно 8 хв).
Заходи: доданий smart-routing за кодами відмови, збільшений warm pool з'єднань до PSP-B.

16) Чек-лист впровадження

1. Визначено критичні призначені для користувача шляхи та відповідні SLI.
2. SLO на 30/90 днів + error budget policy.
3. Багатозонність і план DR з цілями RTO/RPO, регулярні дрилі.
4. Synthetics з гео-таргету, дашборди per-region/per-PSP.
5. Патерни стійкості: circuit breaker, backpressure, idempotency.
6. Політика деградації і feature flags для відключаються фіч.
7. FinOps: бюджети по контурах, прогноз піків, warm pools.
8. Безпека: сегментація, шифрування, аудит.
9. Документація SLA для партнерів, процес комунікацій.
10. Ретроспективи та перегляд SLO кожні 1-2 квартали.

17) Анти-патерни

Обіцяти SLA без вимірюваних SLI і прозорої методики підрахунку.
Вважати доступність «на вході сервісу», ігноруючи шлюз/провайдерів.
Спиратися тільки на середню латентність, ігноруючи хвости P99.
DR «по паперу», відсутність реальних тренувань.
«Вічні» ресурси без лімітів: один звіт валить прод.
Змішувати прод і важку аналітику в одному кластері/БД.

18) Підсумок

Хмарна архітектура під SLA - це поєднання технічних патернів (multi-AZ/region, ізоляція, відмовостійкі дані), процесів (SLO, error budget, DR-дрилі) і економіки (FinOps). Дайте собі право на прогнозовані збої: тестуйте відмовостійкість, міряйте по перцентилях, обмежуйте «вибуховий радіус» і відкрито комунікуйте. Тоді обіцянки SLA стануть не маркетингом, а керованою інженерною практикою.