Skalowalność platform OTT: obsłuż ponad 100 tys. widzów na żywo

Transmisja na żywo może działać bez zarzutu przy 10 000 widzów, a mimo to zawieść, gdy w ciągu kilku minut dołączy 100 000 osób.

Na tym właśnie polega prawdziwe wyzwanie, jakim jest skalowalność platform OTT.

Sport na żywo, pilne wiadomości, koncerty, premiery produktów, wydarzenia religijne i duże premiery rozrywkowe potrafią wywołać nagłe skoki ruchu, zupełnie inne niż zwykłe zapotrzebowanie na streaming. Platforma musi przyjmować, przetwarzać, autoryzować, dystrybuować i monitorować wideo, gdy tysiące widzów dołączają niemal jednocześnie.

Odpowiedzią nie jest po prostu dołożenie kolejnych serwerów. Skalowalna architektura OTT musi przenieść większość pracy związanej z dostarczaniem treści na brzeg sieci, chronić origin, obsługiwać streaming adaptacyjny i mieć wystarczającą redundancję, by przetrwać awarie.

Ten przewodnik wyjaśnia, czego wymaga przygotowanie platformy OTT na ponad 100 tys. jednoczesnych widzów oraz co firmy streamingowe powinny przetestować przed dużym wydarzeniem na żywo.

Widzowie jednoczesni to co innego niż widzowie łącznie.

Platforma może mieć miliony zarejestrowanych użytkowników, ale tylko niewielki ich odsetek ogląda w tym samym momencie. Podczas dużego wydarzenia tysiące użytkowników potrafią jednak pojawić się niemal równocześnie.

Wyobraź sobie na przykład platformę, która zwykle obsługuje 15 000 jednoczesnych widzów. Zaczyna się mecz o mistrzostwo i w ciągu kilku minut 100 000 użytkowników próbuje go obejrzeć.

To tworzy presję na kilku warstwach:

• Przyjmowanie sygnału wideo

• Kodowanie i transkodowanie

• Infrastruktura origin

• Dostarczanie przez CDN

• Uwierzytelnianie

• DRM

• API i bazy danych

• Żądania odtwarzacza

• Analityka

• Systemy płatności i uprawnień

Dlatego najważniejsza zasada jest prosta:

Nie pozwól, aby ruch generowany przez 100 000 widzów docierał do Twojego origin tak, jakby każdy widz był osobnym połączeniem wideo.

To CDN powinien przejąć większość obciążenia związanego z dostarczaniem treści. Sieci CDN dla wideo przybliżają treści do widzów i zmniejszają ruch, który musi wracać do origin.

Architekturę OTT o wysokiej współbieżności można traktować jak potok:

Źródło na żywo → Przyjęcie sygnału → Kodowanie → Pakowanie → Origin → CDN → Odtwarzacz

Każda warstwa odpowiada za co innego.

1. Niezawodne przyjęcie sygnału

Sygnał na żywo to punkt wyjścia. Jeśli zawiedzie wejście, żadna pojemność CDN nie uratuje transmisji.

Przy dużych wydarzeniach warto rozważyć redundantne ścieżki przyjmowania sygnału. Architektury referencyjne, takie jak rozwiązanie do streamingu na żywo firmy AWS, wykorzystują wejście podstawowe i zapasowe, aby zwiększyć odporność.

2. Kodowanie adaptacyjne

Pojedynczy strumień o wysokim bitrate nie sprawdzi się u każdego widza.

Enkoder powinien tworzyć kilka poziomów jakości, aby odtwarzacz mógł przełączać się między nimi zależnie od dostępnego pasma i wydajności urządzenia.

Na przykład:

Dokładną drabinkę bitrate należy dobrać do treści, urządzeń, kodeka i grupy odbiorców.

Vodlix obsługuje streaming adaptacyjny HLS i MPEG-DASH, co pozwala dostarczać wiele wariantów jakości na web, urządzenia mobilne i telewizory.

3. Dostarczanie w modelu CDN-first

CDN to jeden z najważniejszych elementów przy obsłudze skoku współbieżności.

Zamiast pozwalać, by każdy widz raz po raz pobierał segmenty wideo z origin, punkty brzegowe CDN mogą serwować treści z pamięci podręcznej bliżej użytkowników.

Referencyjna architektura streamingu na żywo od AWS umieszcza warstwę origin/pakowania za Amazon CloudFront, a to CDN odpowiada za dystrybucję strumienia do widzów.

Przy wydarzeniu ze 100 000 widzów to rozróżnienie ma kluczowe znaczenie.

Serwery aplikacyjne powinny obsługiwać przede wszystkim logikę aplikacji. CDN powinien wziąć na siebie ciężar dostarczania wideo.

Jednym z największych błędów w streamingu na żywo jest projektowanie przy założeniu, że origin po prostu skaluje się wraz z liczbą widzów.

Wyobraź sobie 100 000 widzów pobierających ten sam segment na żywo. Jeśli żądania raz po raz docierają do origin, infrastruktura może szybko zostać przeciążona.

Właśnie dlatego tak duże znaczenie mają strategia cache'owania, origin shield i wydajne dostarczanie segmentów.

Streaming na żywo jest szczególnie wymagający, ponieważ manifesty stale się zmieniają, a segmenty pojawiają się bardzo często. Architekturę trzeba więc projektować wokół wzorca żądań charakterystycznego dla wideo na żywo, a nie traktować ją jak zwykły ruch webowy.

Przydatna zasada brzmi:

Skaluj warstwę dystrybucji, a nie tylko serwery aplikacyjne.

Cloudflare również zwraca uwagę, że sieci CDN dla wideo pomagają uniknąć przeciążenia origin i jednocześnie obniżają opóźnienia, serwując treści bliżej widzów.

Jeśli Twój normalny ruch to 20 000 jednoczesnych widzów, projektowanie infrastruktury dokładnie na 20 000 jest ryzykowne.

Liczy się Twoja spodziewana szczytowa współbieżność plus margines bezpieczeństwa.

Rozważ prosty model planowania:

Spodziewany szczyt = 100 000 widzów

Zamiast traktować 100 000 jako maksimum, które system ma jeszcze wytrzymać, zapewnij dodatkową pojemność na nieoczekiwany popyt i awarie infrastruktury.

Twój plan pojemności powinien uwzględniać:

• Szczytową liczbę jednoczesnych widzów

• Tempo przyrostu widowni

• Średni bitrate wideo

• Liczbę regionów CDN

• Długość segmentów

• Liczbę wariantów jakości

• Żądania uwierzytelniania

• Ruch API

• Ruch analityczny

• Żądania licencji DRM

• Spodziewany rozkład geograficzny ruchu

Zapotrzebowanie na pasmo również zmienia się drastycznie wraz z bitrate.

Na przykład przy średnim dostarczanym bitrate 5 Mb/s:

100 000 widzów × 5 Mb/s = 500 Gb/s

Dlatego próba przepchnięcia takiego ruchu bezpośrednio przez serwery aplikacyjne lub pojedynczy origin nie jest rozsądną architekturą.

Dostarczanie wideo to tylko część systemu.

Gdy rusza duże wydarzenie, widzowie mogą jednocześnie:

1. Otworzyć aplikację.

2. Zalogować się.

3. Sprawdzić swoją subskrypcję.

4. Poprosić o autoryzację odtwarzania.

5. Poprosić o licencje DRM.

6. Załadować strumień.

7. Wysłać zdarzenia analityczne.

Jeśli wszystkie te żądania trafią do tej samej usługi backendowej, aplikacja może paść nawet wtedy, gdy CDN działa bez zarzutu.

Rozdzielaj obciążenia tam, gdzie to możliwe.

Uwierzytelnianie, weryfikacja uprawnień, API, DRM, analityka i dostarczanie wideo nie powinny tworzyć jednego długiego łańcucha zależności.

W przypadku treści premium zabezpieczenia muszą działać także przy dużym ruchu. Vodlix udostępnia w ramach swojej platformy OTT funkcje bezpieczeństwa dla transmisji na żywo, kontrolę treści oraz obsługę DRM na wielu platformach.

Skalowalności nie da się potwierdzić, patrząc na obciążenie CPU serwerów po rozpoczęciu wydarzenia.

Potrzebujesz wglądu w czasie rzeczywistym w cały potok streamingowy.

Do ważnych metryk należą:

• Jednocześni widzowie

• Rozpoczęcia odtwarzania

• Czas startu

• Współczynnik buforowania

• Bitrate wideo

• Współczynnik trafień CDN

• Ruch do origin

• Wskaźniki błędów HTTP

• Opóźnienie uwierzytelniania

• Czas odpowiedzi DRM

• Błędy dostarczania segmentów

• Zdarzenia ponownego buforowania

• Wydajność w poszczególnych regionach

Vodlix oferuje analitykę i raportowanie w czasie rzeczywistym do monitorowania wydajności wideo i zachowań widowni. Coraz częściej AI w streamingu pomaga platformom wzbogacać treści i poprawiać dostępność na dużą skalę.

Celem jest wykrycie pogorszenia jakości zanim zaczną je zgłaszać widzowie.

Jeśli spodziewasz się 100 000 jednoczesnych widzów, nie rób z transmisji na żywo swojego pierwszego testu skalowalności.

Testuj przed startem.

Sensowna progresja testów może wyglądać tak:

Test powinien symulować znacznie więcej niż samo odtwarzanie wideo.

Przetestuj fale logowań, żądania API, autoryzację odtwarzania, żądania manifestów, dostarczanie przez CDN, DRM, analitykę oraz powrót do działania po awarii komponentów.

Najcenniejszy test to często ten, który ujawnia wąskie gardło, o którego istnieniu nie miałeś pojęcia.

Praktyczna lista kontrolna przed wydarzeniem powinna obejmować:

1. Potwierdź szczytową współbieżność.
Oszacuj spodziewaną widownię na podstawie wcześniejszych wydarzeń, rejestracji, zasięgu marketingowego i historycznego ruchu.

2. Zweryfikuj pojemność CDN.
Upewnij się, że Twoja architektura dostarczania udźwignie spodziewany rozkład geograficzny i zapotrzebowanie na pasmo.

3. Przetestuj origin.
Zadbaj o to, aby infrastruktura origin była chroniona przed nagłymi falami żądań.

4. Przetestuj uwierzytelnianie i DRM.
Skalowalny potok wideo jest bezużyteczny, jeśli użytkownicy nie mogą uzyskać autoryzacji odtwarzania.

5. Przetestuj wiele profili bitrate.
Sprawdź, czy widzowie mogą zmieniać jakość bez przerywania odtwarzania.

6. Przeprowadź realistyczny test obciążeniowy.
Testuj powyżej spodziewanego szczytu, zamiast zatrzymywać się na docelowej liczbie.

7. Ustaw monitoring i alerty.
Wiedz dokładnie, która metryka uruchamia eskalację.

8. Przygotuj plan awaryjny.
Krytyczne transmisje powinny mieć redundancję przyjmowania sygnału, przetwarzania i dostarczania wszędzie tam, gdzie jest to wykonalne.

Zbudowanie całej tej infrastruktury samodzielnie może wymagać rozległych kompetencji w obszarze inżynierii, chmury, CDN, bezpieczeństwa, monitoringu i utrzymania.

Firmom streamingowym, które chcą wystartować bez budowania całego stosu OTT od zera, Vodlix daje gotową do wdrożenia platformę OTT obejmującą streaming na żywo, VOD, nadawanie telewizyjne, integrację z CDN, streaming adaptacyjny, analitykę, monetyzację i dystrybucję wieloplatformową. Vodlix to w pełni platforma OTT w modelu white label, więc możesz wystartować i rosnąć pod własną marką.

Infrastruktura streamingu na żywo Vodlix opiera się na najlepszych sieciach CDN i została zaprojektowana z myślą o skalowalnym dostarczaniu transmisji. Platforma obsługuje także HLS i MPEG-DASH, streaming adaptacyjny, analitykę w czasie rzeczywistym oraz treści na żywo w przeglądarce, na urządzeniach mobilnych i w aplikacjach telewizyjnych.

Dla firm przygotowujących się do dużych wydarzeń na żywo oznacza to, że uwagę można przenieść z budowania każdego elementu infrastruktury osobno na zarządzanie treścią, widownią, monetyzacją i doświadczeniem oglądania.

Obsługa ponad 100 000 jednoczesnych widzów nie polega na znalezieniu jednego serwera wystarczająco mocnego dla 100 000 osób.

To problem architektoniczny.

Skalowalna platforma OTT oddziela dostarczanie wideo od obciążeń aplikacyjnych, wykorzystuje infrastrukturę CDN do dystrybucji treści, chroni origin, obsługuje streaming adaptacyjny, utrzymuje skalowalne uwierzytelnianie i DRM, monitoruje doświadczenie widza w czasie rzeczywistym oraz testuje warunki szczytowe przed wydarzeniem.

Co najważniejsze, skalowalność należy zaprojektować zanim nadejdzie skok ruchu.

Jeśli Twoja firma planuje duże wydarzenia na żywo, projektowanie pod przeciętną widownię nie wystarczy. Buduj z myślą o chwili, w której wszyscy naraz wciskają Odtwórz.