Wysokoobciążeniowy backend platformy streamingowej OTT
Rozproszony backend dla TV Smart od Vectry — telewizja na żywo, VOD i timeshift serwowane w całej UE, zbudowany jako niezależne mikroserwisy na GCP.
- Stack
- Laravel · Go · Python · MySQL · Redis · Kafka · GCP
- Skala
- dziesiątki tysięcy równoczesnych żądań odtworzenia
- Obciążenie
- TV na żywo · VOD · timeshift, w całej UE
Telewizja na żywo to najmniej wybaczające obciążenie w streamingu
Tytuł VOD może się zaciąć na sekundę i nikt tego nie zauważy; mecz piłki nożnej na żywo — nie. Gdy startuje wydarzenie, dziesiątki tysięcy widzów naciska play w tej samej minucie — i każdy z nich oczekuje, że strumień się autoryzuje, program się załaduje, a uprawnienia do pakietu (entitlements) rozstrzygną się bez odczuwalnego opóźnienia.
Backend musi przyjąć ten szczyt bez degradacji, a kilka minut później wrócić do poziomu bazowego. Architektura, która czuje się dobrze przy średnim ruchu, ale składa się w szczycie, jest architekturą złą — bo to właśnie szczyt jest momentem, który się liczy.
Niezależne mikroserwisy, właściwy język na każdej ścieżce
Backend rozłożyliśmy na niezależne serwisy — odtwarzanie i uprawnienia (entitlements), EPG, katalog VOD, nagrywanie (NPVR) i billing — każdy z własnymi danymi i skalowany osobno. Ścieżki krytyczne dla wydajności, czyli autoryzacja strumienia i rozstrzyganie manifestu, powstały w Go dla przepustowości i przewidywalnej latencji; Laravel i PHP obsługują logikę biznesową oraz panele administracyjne; Python napędza zadania przetwarzania danych i integracji.
Serwisy komunikują się przez REST przy wywołaniach synchronicznych i przez Kafkę we wszystkim, co asynchroniczne. Zdarzenia odtwarzania, zadania nagrywania, zmiany uprawnień i aktualizacje EPG płyną strumieniami zdarzeń, więc żaden serwis nie blokuje się w oczekiwaniu na inny — wolny konsument w dole nigdy nie zatrzymuje żądania play, które widz ma przed sobą.
Redis z przodu, MySQL osłonięty przed nagłym szczytem
Redis stoi przed najgorętszymi danymi — stanem sesji, oknami EPG, sprawdzaniem uprawnień — dzięki czemu decyzje o autoryzacji strumienia nie trafiają do MySQL w szczycie obciążenia. Wolne zapytania zostały sprofilowane i przebudowane, indeksy i pule połączeń dostrojone, a ruch odczytu oddzielony od zapisu. Load balancing rozkłada żądania na repliki serwisów, a warstwa cache przejmuje szczyt, więc serwisy źródłowe widzą ułamek surowego wolumenu.
Tryb awarii naiwnego rozwiązania to kaskada: autoryzacja przelatuje aż do bazy, baza się nasyca, timeouty cofają się do serwisów, a spowolnienie rozlewa się, aż cała ścieżka play degraduje się naraz — dokładnie w trakcie wydarzenia na żywo. Postawienie cache przed gorącą ścieżką i trzymanie odczytów z dala od ścieżki zapisu to właśnie to, co zamienia tę kaskadę w stabilną latencję w trakcie szczytu.
Produkcyjny backend w skali krajowej, nie prototyp
To działający backend platformy OTT operatora krajowego, pracujący w całej UE — a nie proof of concept, który działa w demie i wykłada się w boju. Obsługuje realnych abonentów, realny billing i realne wydarzenia na żywo, i został zbudowany tak, by utrzymać latencję na stałym poziomie dokładnie w chwili, gdy nadchodzi szczyt.
Inżynieria, która to umożliwia, nie jest specyficzna dla telewizji. Rozłożona architektura serwisów, właściwy język na każdej ścieżce, strumienie zdarzeń zamiast blokujących wywołań i warstwa cache osłaniająca bazę to te same narzędzia, których potrzebuje każdy system, gdy ruch przychodzi zrywami, a nie równym strumieniem.
Zobacz, jak wyglądałoby to w Twoich procesach.
30 minut · wskazujemy 3 najlepsze obszary do automatyzacji · bez zobowiązań