Ніч піку
22:07. Прем’єра серіалу. Кнопка «Play» — і крива трафіку злітає. За хвилину — ще ×8. Система живе на кеші. У черзі — тисячі запитів. Першими стогнуть сесії та пошук. Через три хвилини доїдає ліміти API платежів. Якщо нема плану, усе лягає каскадом.
Картина схожа у ставках на топ‑матч. Кожна секунда — гроші. Затримка у 300 мс — і ставка вже не та. Без ідемпотентних подій і жорстких лімітів хаос росте. У соціальному лайві інша пастка: тисячі мікро‑подій (лайки, подарунки) душать бекенд метриками високої кардинальності.
Цей текст — для CTO, CPO, SRE та архітекторів, які готують платформи розваг до піку. Будуть реальні патерни, антипатерни, цифри, таблиця, і 90‑денний план.
Що тепер означає «високонавантажена розвага»
Профіль трафіку не рівний. Він «б’є хвилями». Є короткий бурст ×10–×20 на 10–20 хв. Є плато на 2–3 години. Є довга «коса» фонового трафіку. Користувачі приходять з усього світу. Кеш рятує, але не вічно. Балансер має бачити гео і здоров’я сервісів.
Цілі прості на словах, жорсткі на ділі: P95 до 150–250 мс у регіоні, P99 до 400–600 мс; 99.9–99.99% доступності; чіткий бюджет помилок. Це класика підходу SRE і роботи зі SLO — докладно описано у книзі Google про SRE: підхід SRE та SLO.
Сучасна платформа — це CDN/edge, глобальний балансер, мультірегіон, Kubernetes з автоскейлом, події (Kafka), кілька шарів кешу, фінансові сервіси з точною послідовністю. Поради по внутрішній інженерії добре зібрані у AWS Builders Library.
Три кейси, де все вирішують мілісекунди
1) Відеострімінг під прем’єру
Бурст трафіку — ×10–×20 за хвилини. Рятує CDN. Прогрівати edge до старту. Відео йде адаптивно (ABR). Вміст кешується близько до глядача. Початковий маніфест і ключі DRM — у гарячому кеші. Бекенд бачить тільки auth і нетипові запити.
Перед стартом — «суха репетиція» з синтетичним трафіком. Якщо P95 росте — збільшуємо warm‑pool нод, готуємо rate‑limits на API. Досвід гігантів добре описує Netflix TechBlog. Ключ: менше стани на бекенді, більше на клієнті та в edge.
2) Гемблінг/беттінг під великий матч
Критично мало затримки в оновленні коефіцієнтів. Події з полів ідуть у Kafka. Прайсинг — окремо. Ставка — транзакція з ідемпотентним ключем. Схема «exactly‑once» для грошей. Будь‑який повтор — не має подвоювати виплату. Антиботи фільтрують спайки, WAF ріже «пилососи». Сесії тримати не липкими; стан — у Redis або подіях.
Тут маркетинг іде хвилями. Юзери одночасно шукають, де грати. Часто вони відкривають огляди та порівняння. Саме в такі хвилини корисно мати прогріті промо‑сторінки і ввімкнений тротлінг на «важкі» блоки. Якщо ви даєте довідку про ліцензії та ліміти гри, дайте її поруч. Для прикладу, огляди й освітні матеріали є на ebgt.info (азартні ігри — 21+, грайте відповідально). Це не про заклик, а про прозору інформацію для дорослих користувачів.
3) Соціальний геймінг і лайв‑івенти
Тут болить не одне велике відео, а тисячі дрібних подій: подарунки, реакції, чати. Вони створюють шквал запитів до бекенду та баз моніторингу. Краще збирати їх у черги та батчити. На edge можна ставити «кімнату очікування» для великих прем’єр — як у Cloudflare Waiting Room. Так ви тримаєте досвід стабільним під час бурсту.
Швидкий вибір архітектури під пік
Немає однієї схеми «на всі випадки». Нижче — карта, яка допоможе зорієнтуватись за 5 хвилин. Перед читанням перевірте ваші граничні SLO і ліміти провайдерів.
| Стрімінг прем’єри | ×10–×20 на 10–20 хв; глобально | 150–250 мс / 400–600 мс | CDN/edge, глобальний LB, K8s | Статус у клієнті; мінімум стану | HPA + warm‑pool; rate limits | TTL 60–120 с; прогрів; маніфести в кеші | Error budget, saturation, 5xx | Холодний кеш; API‑квоти DRM | GDPR, антиботи, WAF | CDN offload, reserved інстанси |
| Лайв‑беттінг | ×5–×12 під час матчу; регіонально | 80–150 мс / 250–400 мс | Kafka, Redis, мультірегіон | Event‑sourcing; ідемпотентність | Karpenter/HPA; жорсткий тротлінг | Короткий TTL; інвалідація за подією | P50/P95 латентність, queue lag | Дубль ставок; ліміти платіжних API | PCI DSS, KYC/AML, WAF | Кеш коефіцієнтів, storage class |
| Лайв‑івент/соціальний | ×3–×8 бурсти; спалахи дрібних подій | 120–200 мс / 350–500 мс | Edge фільтри, черги, LB | Агрегація, батчинг | Backpressure; квоти на події | Кеш API‑відповідей 30–60 с | Cardinality метрик, RPS | High‑cardinality; DDoS шар | GDPR, SOC 2 | Cloud‑сейвінг плани, CDN |
Щоб автоскейл не «запізнювався», перегляньте HPA в Kubernetes. Для потоків грошей корисні «exactly‑once» підходи у Kafka — дивіться розбір від Confluent: як Kafka робить exactly‑once.
Антипатерни, що ламають пік
- Один регіон на все. Будь‑яка аварія — і ви в офлайні. Рішення: active‑active у щонайменше двох регіонах, глобальний балансер. База — з реплікацією, а читання — ближче до юзера. Базові патерни балансування тут: що таке load balancing.
- Приховані квоти провайдера. RPS, конекшени, IP‑репутація. Вони «б’ють» у найгірший момент. Майте табличку з усіма лімітами й контакти підтримки.
- Висококардинальні метрики. Коли лейбли вибухають, моніторинг сам стає проблемою. Чим менше унікальних тегів — тим краще. Пояснення від Datadog: ризики high‑cardinality.
- Sticky‑сесії без шардінгу стану. Один под — і трафік «прилипає». Краще зберігати стан поза подом (Redis/події) і дозволити вільне балансування.
Коробочка інженера: що справді працює
- Edge і CDN. Прогріти гарячі маршрути. Статичні й напівдинамічні блоки — на edge. Керуйте TTL і варіантами кешу. Гарне джерело практик — блог Akamai: продуктивність і edge.
- Глобальний балансер + мультірегіон active‑active. Тримайте стійкість до збою регіону й латентність ближче до юзера. Приклад реалізації від Cloudflare: Cloudflare Load Balancing.
- Подійна шина. Kafka для потоків ставок, подій глядачів, нотифікацій. Ідемпотентні ключі, дедуплікація, отруйні черги — це must. Офіційні гіди тут: документація Apache Kafka.
- Кеш‑шари. Redis як гарячий кеш, короткі TTL, інвалідація за подією. Продумані ключі: версія, локаль, user tier. Практики від спільноти Redis: як будувати кеш.
- Автоскейл з теплим резервом. Мін/макс для HPA, warm‑pool для нод, Karpenter для швидкого підйому. Backpressure і rate‑limits як запобіжник лавини.
- Спостережуваність. RED/GOLDEN сигнали, трейсинг, профайлінг. eBPF дає глибокий погляд без великого оверхеду — див. гайд від Grafana Labs: що таке eBPF.
- IаC і швидкі розгортання. Terraform як стандарт, окремі стеки для регіонів. Один клік — і у вас ще один регіон. Документація: Terraform docs.
- Edge‑обчислення для легких правил. Прості фільтри й перепис URL на edge, щоб не вантажити бек. Див. також Fastly Compute@Edge.
- CDN прогрітий; гарячі маніфести в кеші.
- HPA має мін/макс; warm‑pool увімкнено.
- Rate‑limits і квоти API перевірені.
- WAF/бот‑політики оновлені.
- Дашборди P95/P99, saturation, queue lag — на екрані.
- Черги подій мають запас на X хвилин.
Безпека і відповідність: не лише галочки
Автоматизовані загрози ростуть у пік. Скрейпери, боти, карт‑тестинг. Почніть із WAF і керування ботами. Список типових атак — у OWASP Automated Threats. Далі — сегментація, принцип найменших прав, секрети у менеджері секретів.
Комплаєнс — це стримувач хаосу. PCI DSS 4.0 для карткових даних: офіційні матеріали PCI. Для персональних даних — GDPR. Для довіри партнерів — SOC 2 та ISO 27001. Для хмари — матриця контролів CSA CCM.
Для гемблінгу діють KYC/AML і вікові обмеження. Будьте чіткі: 21+ в Україні. Додайте блок «відповідальна гра». Якщо на довідковій сторінці є перелік ліцензій і політик, посилайтеся на нього поруч із промо. Прикладом може бути нейтральна довідка на ebgt.info (без агресивних закликів).
Вартість без міфів: короткий FinOps
80% економії дає просте: більше кешу на edge, правильний storage class, підбір типів інстансів. CDN offload інколи знімає 40–70% трафіку з бекенду. Те, що не потрібно в реальному часі, відправляйте у черги.
Бюджет має слухати SLO. Якщо SLO по P95 — 200 мс, не варто платити за 100 мс, якщо це не дає бізнес‑вигоди. Вимірюйте вартість на запит, на хвилину відео, на ставку. Культура й інструменти — на FinOps Foundation.
Обережно з «знижками». Reserved/Savings плани — лише для стабільних сервісів. Для піків — спот/авто підйом і падіння. Логи та метрики — з ретенцією за класами.
Дорожня карта на 90 днів
Дні 0–30: побачити вузькі місця
- Аудит SLO і бюджетів помилок. Випишіть «де болить». Звірте ліміти API та квоти постачальників.
- Політика кешу: TTL, прогрів, інвалідація. Пронумеруйте гарячі маршрути.
- Rate‑limits і backpressure. Додайте захист на рівні edge і бекенду.
Дні 31–60: включити масштаб
- Пілот мультірегіону з глобальним балансером. Перевірка фейловеру.
- Критичні потоки переводимо на події. Ідемпотентність, ключі, дедуплікація.
- HPA/Karpenter з warm‑pool. Тест бурстів у нічний час.
Дні 61–90: зробити стійким
- Chaos‑ігри: вимкніть регіон, ланку мережі, брокер подій. Міряйте P95/P99.
- Тюнінг трейсингу, метрик, алертів. Приберіть висококардинальні теги.
- Закрийте комплаєнс‑прогалини. Оновіть політики, навчіть команду. На додачу — перегляньте референс‑каркаси: Google Cloud Architecture Framework та Azure Well‑Architected.
FAQ: п’ять коротких відповідей
Чим HPA відрізняється від Karpenter? HPA масштабує поди за метриками. Karpenter — ноди під ваші поди. Разом вони швидше ловлять бурст.
Active‑active чи active‑passive? Для критичних піків — active‑active. Дорожче, але швидше. Для другорядних сервісів — active‑passive з чітким RTO/RPO.
Як планувати пік + DDoS? Edge‑фільтри, WAF, бот‑менеджмент, квоти. Залишайте запас у CDN і балансері. Прогрівайте кеш до старту.
Що робити з холодним стартом функцій? Тримайте «теплі» екземпляри на пікових маршрутах. Критичну логіку — у довгоживучих сервісах, не у функціях.
Моніторинг з’їв бюджет? Зменшити кардинальність, обрізати ретенцію, зберігати сирі логи в холодному сховищі, робити семплінг трейсів.
Міні‑постмортем: як ми «врятували» реліз
Було: бекенд витримував до 15 тис. RPS, P99 — 900 мс у бурсті. Каса впиралась у 1 000 req/s на под, HPA розганявся запізно, кеш на edge — холодний.
Що зробили за тиждень: прогріли CDN, TTL маніфестів — 120 с, ввели warm‑pool на 20% кластера, додали ключі ідемпотентності, в Kafka поставили батчі. У платіжного провайдера підняли квоти на 3 години. Вимкнули 5 висококардинальних лейблів.
Стало: той самий бурст — P95 170 мс, P99 430 мс. Каса — без черг. 5xx — мінус 72%. Вартість на запит — мінус 28% завдяки CDN offload.
Польові нотатки наостанок
- Тестуйте піки у нічний час із синтетикою. Тільки так видно реальні квоти.
- Вимірюйте все, але бережіть метрики від «кардинальності заради кардинальності».
- Документація має жити. Оновлюйте «плейбуки піку» перед кожною великою подією.
- Не штовхайте всі запити у бекенд. Edge і кеш — перша лінія оборони.
- Гроші люблять ідемпотентність. Ставка має бути або одна, або нуль.
Автор: Інженер з хмари та SRE. 8+ років у стрімінгу, гемблінгу, соціальних івентах. Сертифікації: AWS, GCP, Kubernetes.
Оновлено: 05/2026
У тексті є посилання на сторонні ресурси: Netflix TechBlog, AWS Builders Library, книга SRE та інші. Партнерські/афілійовані — позначені як nofollow/sponsored. Для азартних ігор діє правило 21+, грайте відповідально.
