Чому лайв-контент вимагає потужних серверів і CDN

1) У чому «тяжкість» лайва в порівнянні з VOD

Фан-аут в реальному часі. Один вхідний потік → тисячі вихідних. Будь-яка просадка CPU/мережі миттєво б'є по всіх глядачах.

Жорсткі SLA по затримці. У лайві важлива не тільки «картинка», але і «сьогоднішнє повітря»: 0,5-2 с для WebRTC і 2-5 с для LL-HLS.

Постійний енкодинг/транскодинг. Потрібно тримати кілька бітрейт-сходів (ABR) і профілів під різні екрани/мережі.

Нестабільна мережа глядачів. Потрібні адаптивні бітрейти, перекадрування, перезбірка GOP і агресивні буфери при піках.

Неможливість «полагодити потім». У VOD можна перерендерити. У лайві помилка кадру - втрачений момент назавжди.

2) Сервери для енкодингу та транскодингу: CPU, GPU, пресети

Кодеки: H.264/AVC - золотий стандарт сумісності; HEVC/AV1 - економлять трафік, але важче для кодування і декодування на слабких пристроях.

Залізо:

CPU x264 (veryfast-faster) - стабільність, передбачуваність, але дорогий по ядрах.
GPU NVENC/AMF/Quick Sync - дешевий на потік, корисний для сходів ABR.
Налаштування низької затримки: короткий GOP (1-2 сек), обмежені B-frames, CBR/консервативний VBR, регулярні ключові кадри для швидких перемикань профілів.
Чому «потужні»: пара десятків одночасних 1080p60 профілів вже впирає сервер в CPU/GPU і пам'ять, особливо при багатолісничому ABR.

3) WebRTC, SFU и TURN: де потрібна «реальна» потужність

SFU (Selective Forwarding Unit). Не мікшує, а маршрутизує потоки → економить CPU, але вимагає широкого egress і грамотного фан-ауту.

TURN/ICE/STUN. При NAT/фаєрволах трафік йде через TURN - це повний relay, подвоює навантаження на uplink.

Backpressure і пріоритизація. При перевантаженні SFU повинен знижувати якість/частоту кадрів, інакше розірве сесію.

Чому CDN недостатньо. WebRTC погано кешується традиційним CDN - навантаження лягає на медіасерверний шар (SFU-кластери).

4) LL-HLS/DASH и CDN: Як масштабувати глядачів

Кешованість сегментів. На відміну від WebRTC, сегменти HLS/DASH кешуються на edge → різко знижується навантаження на origin.

Origin-shield і багаторівневий CDN. Edge → регіональні кеш-вузли → origin. Високий cache hit ratio критичний для економії egress/CPU.

ABR-сходи. 240p-1080p (іноді 1440p/2160p). Чим більше профілів - тим вище навантаження на транскодер і сховище.

Мульти-CDN. Anycast/DNS-steering, real-user measurements (RUM) і автоматичний фейловер за метриками часу завантаження/помилок.

5) Узгодженість часу і подій

Для інтерактивних лайв-сценаріїв (ставки, квізи, лайв-казино):

Жорстка синхронізація часу (NTP/chrony), позначки'video _ ts'в подіях і серверний «джерело істини».
Послідовність повідомлень (seq, ACK, ретрансміт, ідемпотентність).
Реплеї та запис (WORM-сховище) для розборів спірних моментів.

6) Приклад розрахунку ємності (консервативно)

Потік 1080p з бітрейтом ≈ 4 Мбіт/с.

Онлайна одночасно: 20 000 глядачів.

Сумарний egress: 4 × 20 000 = 80 000 Мбіт/с = 80 Гбіт/с.

При 80% cache-hit на edge трафік з origin ≈ 20%: 16 Гбіт/с

Для WebRTC (некешируемо) якщо один SFU-вузол стабільно тримає ~ 8 Гбіт/с egress, потрібно ≈ 10 SFU-нод + 2-3 в резерві.

💡 Висновок: навіть «помірний» лайв швидко впирається в мережевий egress і горизонтальне масштабування медіасерверів.

7) Зберігання записів і таймшифт

5 Мбіт/с → 0,625 МБ/с → ≈ 2,2 ГБ на годину на один профіль.

Для 6 профілів ABR і 10 столів/каналів: 2,2 × 6 × 10 = ≈ 132 ГБ/год.

Потрібні «холодні» шари зберігання + життєві цикли (tiering/TTL).

8) Типові вузькі місця

CPU/GPU транскодерів. Піки підключень → зростання «решейпів» і перезбірки GOP.

Мережа SFU і TURN. SNI-блокування, NAT-симетрик → повний relay і раптовий шпиль навантаження.

Дискова підсистема origin. Висока QPS по дрібних сегментах, особливо при LL-HLS.

Пам'ять і сокети. Тисячі WebSocket/DTLS-сесій на ядро вимагають тюнінгу ядра/epoll і лімітів FD.

GC/RT паузи. На JVM/Node медіашлюзах - налаштування GC та ізоляція «гарячих» шляхів.

9) Безпека та захист контенту

TLS-термінація на edge, HSTS, сучасний набір шифрів.

Підписані URL/токени, короткий TTL, гео/реф-обмеження.

DRM/LL-token для захищених стрічок.

Анти-скрейпінг/анти-рестрим. Водяні знаки, поведінкові сигнали, непублічні маніфести.

10) Спостережуваність і SLO

Відеометрії: e2e-затримка, фриз-рейт, пропуски кадрів, відсоток зниження профілю ABR, відмови декодера.

Мережа: throughput за точками присутності, перепідключення WebRTC, помилки ICE/TURN, RTT/джиттер.

Сервер: завантаження CPU/GPU, температура, ulimit, кількість відкритих сокетів, p95/p99 по API.

Продукт: конект-рейт, утримання, середня тривалість сесії, complaint-rate.

SLO-приклади: 99,5% сегментів доставляються <1,5 с; 95-й перцентиль затримки WebRTC ≤ 2,5 с; drop-frame < 1%.

11) Оптимізація вартості без втрати якості

Гібрид кодування: базові профілі на GPU, «красиві» профілі для преміум - на x264 CPU.

Content-aware encoding. Динамічні бітрейти по сценах (статичні/динамічні епізоди).

Мульти-CDN з ціновим роутингом. Перемикання за сукупною метрикою якості/вартості.

Зменшення числа профілів. Якщо аудиторія - мобільна, 720p часто «тримає удар».

Edge-origin-shield. Підвищуємо cache-hit, знижуємо вихідний трафік з origin.

12) Чек-лист для запуску лайва «на потужностях»

Інфраструктура

Кластер транскодерів (CPU + GPU) з автоскейлом і гарячим резервом.
SFU-кластер для WebRTC + TURN-пул з білими IP і моніторингом relay-частки.
Origin-shield і як мінімум 2 незалежних CDN.
Сховище з політиками TTL/архівом (WORM) для записів/реплеїв.

Низька затримка

GOP ≤ 2 c, ключові кадри за розкладом, CBR/low-latency пресети.
ABR-сходи оптимізовані під мобільний сегмент.
Реал-тайм синхронізація часу, позначки'video _ ts'в подіях.

Надійність

Мультизонність, фейловер потоків, автоматичний дегрейд якості замість дропу.
Тести на 1,5 × планового навантаження і «шторм» перепідключень.
Повна спостережуваність: метрики, логи, трасування, алерти.

Безпека

Підписані URL, короткий TTL, гео-обмеження, DRM при необхідності.
TLS на edge, ротація сертифікатів, захист від хотлінка/рестрімів.
Мінімізація PII, сегрегація мереж, аудит доступу.

13) Рецепт архітектури за роллю контенту

Інтерактив (ставки/вікторини/лайв-казино): WebRTC + SFU, ультра-низька затримка, паралельний LL-HLS як «зоровий» фід.

Трансляції мас-аудиторії: LL-HLS/DASH + агресивний CDN, ABR-оптимізація, запис і таймшифт.

Гібрид: первинка в WebRTC, дзеркалювання в LL-HLS для реплеїв і відкладеного перегляду.

Лайв-контент - це не просто «відео в інтернеті». Це керована в реальному часі фабрика потоків, де медіасервери, енкодери, SFU, CDN і сховища працюють синхронно і під піковими навантаженнями. Потужні сервери потрібні, щоб тримати енкодинг і фан-аут без втрати кадрів; CDN - щоб доставити мільйонам сегменти швидко і дешево. У зв'язці вони дають те, чого чекають глядачі та інтерактивні сценарії: стабільну картинку, низьку затримку і масштаб, а бізнес - передбачувану собівартість і SLA.