Opracuj platformę wideo w 90 dni

Tej wiosny znaleźliśmy się w bardzo wesołych warunkach. W związku z pandemią stało się jasne, że nasze letnie konferencje trzeba przenieść do sieci. A żeby sprawnie przeprowadzić je online, gotowe rozwiązania programowe nie były dla nas odpowiednie, musieliśmy napisać własne. A mieliśmy na to trzy miesiące.

Nie ma wątpliwości, że to były ekscytujące trzy miesiące. Ale z zewnątrz nie jest to do końca oczywiste: czym jest platforma konferencyjna online? Z jakich części się składa? Dlatego na ostatniej z letnich konferencji DevOops zapytałem osoby odpowiedzialne za to zadanie:

  • Nikolay Molchanov – dyrektor techniczny Grupy JUG Ru;
  • Vladimir Krasilshchik jest pragmatycznym programistą Java pracującym na backendzie (jego raporty można było zobaczyć także na naszych konferencjach Java);
  • Za całą transmisję wideo odpowiada Artem Nikonov.

Swoją drogą, na jesienno-zimowych konferencjach będziemy korzystać z ulepszonej wersji tej samej platformy – więc wielu czytelników Habra nadal będzie jej użytkownikami.

Opracuj platformę wideo w 90 dni

Wielkie zdjęcie

— Jaki był skład zespołu?

Nikołaj Mołczanow: Mamy analityka, projektanta, testera, trzech frontendowców i backend. I oczywiście specjalista w kształcie litery T!

— Jak ogólnie wyglądał ten proces?

Nikolai: Do połowy marca nie mieliśmy w ogóle nic gotowego do udostępnienia online. A 15 marca cała internetowa karuzela zaczęła się kręcić. Założyliśmy kilka repozytoriów, zaplanowaliśmy, omówiliśmy podstawową architekturę i zrobiliśmy wszystko w trzy miesiące.

To oczywiście przeszło przez klasyczne etapy planowania, architektury, wyboru funkcji, głosowania na te funkcje, polityki dotyczącej tych funkcji, ich projektowania, rozwoju i testowania. W rezultacie 6 czerwca wdrożyliśmy wszystko do wersji produkcyjnej. TechTrain. Na wszystko było 90 dni.

— Czy udało nam się zrealizować to, co założyliśmy?

Nikolai: Skoro bierzemy teraz udział w konferencji DevOops online, to znaczy, że się udało. Osobiście postawiłem na najważniejsze: udostępnię klientom narzędzie, za pomocą którego będą mogli przeprowadzić konferencję online.

Wyzwanie było następujące: udostępnić nam narzędzie, za pomocą którego będziemy mogli transmitować nasze konferencje posiadaczom biletów.

Całe planowanie podzielono na kilka etapów, a wszystkie funkcje (około 30 globalnych) podzielono na 4 kategorie:

  • co na pewno zrobimy (nie możemy bez nich żyć),
  • co zrobimy w drugiej kolejności,
  • czego nigdy nie zrobimy,
  • i czego nigdy, przenigdy nie zrobimy.

Stworzyliśmy wszystkie funkcje z dwóch pierwszych kategorii.

— Wiem, że w sumie powstało 600 numerów JIRA. W trzy miesiące zrobiłeś 13 mikroserwisów i podejrzewam, że były one pisane nie tylko w Javie. Korzystałeś z różnych technologii, masz dwa klastry Kubernetes w trzech strefach dostępności i 5 strumieni RTMP w Amazon.

Przyjrzyjmy się teraz każdemu elementowi systemu z osobna.

Streaming

— Zacznijmy od tego, kiedy mamy już obraz wideo i jest on przesyłany do niektórych serwisów. Artem, powiedz nam, jak odbywa się ten streaming?

Artem Nikonow: Nasz ogólny schemat wygląda następująco: obraz z kamery -> nasza sterownia -> lokalny serwer RTMP -> Amazon -> odtwarzacz wideo. Więcej szczegółów o tym napisał na Habré w czerwcu.

Ogólnie rzecz biorąc, można to zrobić na dwa globalne sposoby: albo na sprzęcie, albo w oparciu o rozwiązania programowe. Wybraliśmy drogę programową, bo w przypadku głośników zdalnych jest łatwiej. Nie zawsze jest możliwe sprowadzenie sprzętu do mówcy z innego kraju, ale dostarczenie oprogramowania do mówcy wydaje się łatwiejsze i bardziej niezawodne.

Od strony sprzętowej mamy do dyspozycji określoną liczbę kamer (w naszych studiach i przy zdalnych głośnikach), pewną liczbę pilotów w studiu, które czasami trzeba naprawić tuż pod stołem w trakcie transmisji.

Sygnały z tych urządzeń docierają do komputerów z kartami przechwytującymi, kartami wejścia/wyjścia i kartami dźwiękowymi. Tam sygnały są mieszane i łączone w układy:

Opracuj platformę wideo w 90 dni
Przykład układu dla 4 głośników

Opracuj platformę wideo w 90 dni
Przykład układu dla 4 głośników

Ponadto ciągłe nadawanie odbywa się za pomocą trzech komputerów: jest jedna maszyna główna i para działających. Pierwszy komputer zbiera pierwszy raport, drugi – przerwę, pierwszy – kolejny raport, drugi – kolejną przerwę i tak dalej. A główna maszyna miesza pierwszą z drugą.

Tworzy się to swego rodzaju trójkątem i jeśli któryś z tych węzłów ulegnie awarii, możemy szybko i bez utraty jakości kontynuować dostarczanie treści klientom. Mieliśmy taką sytuację. W pierwszym tygodniu konferencji naprawiliśmy jedną maszynę, włączyliśmy/wyłączyliśmy ją. Ludzie wydają się być zadowoleni z naszej odporności.

Następnie strumienie z komputerów trafiają na lokalny serwer, który ma dwa zadania: kierować strumienie RTMP i rejestrować kopie zapasowe. Mamy więc wiele punktów rejestracyjnych. Strumienie wideo są następnie przesyłane do części naszego systemu zbudowanej w oparciu o usługi Amazon SaaS. Używamy Media na żywo,S3, CloudFront.

Nikolai: Co się tam dzieje, zanim film dotrze do odbiorców? Trzeba to jakoś przeciąć, prawda?

Artem: Z naszej strony kompresujemy wideo i wysyłamy je do MediaLive. Tam uruchamiamy transkodery. Transkodują filmy w czasie rzeczywistym na kilka rozdzielczości, aby ludzie mogli je oglądać na swoich telefonach, za pośrednictwem słabego Internetu w kraju i tak dalej. Następnie strumienie te są cięte kawałki, tak działa protokół HLS. Wysyłamy do frontendu playlistę zawierającą wskaźniki do tych fragmentów.

— Czy używamy rozdzielczości 1080p?

Artem: Szerokość naszego wideo jest taka sama jak 1080p - 1920 pikseli, a wysokość jest nieco mniejsza, obraz jest bardziej wydłużony - są ku temu powody.

Gracz

— Artem opisał, w jaki sposób wideo trafia do strumieni, jest rozdzielane na różne playlisty dla różnych rozdzielczości ekranu, cięte na kawałki i trafia do odtwarzacza. Kolya, teraz powiedz mi, co to za odtwarzacz, jak zużywa strumień, dlaczego HLS?

Nikolai: Mamy odtwarzacz, który mogą oglądać wszyscy widzowie konferencji.

Opracuj platformę wideo w 90 dni

Zasadniczo jest to opakowanie wokół biblioteki hls.js, na którym napisano wielu innych graczy. Potrzebowaliśmy jednak bardzo konkretnej funkcjonalności: przewijania i oznaczania miejsca, w którym dana osoba się znajduje, jaki reportaż aktualnie ogląda. Potrzebowaliśmy także własnych układów, wszelkiego rodzaju logo i wszystkiego, co zostało z nami wbudowane. Dlatego postanowiliśmy napisać własną bibliotekę (opakowanie na HLS) i osadzić ją na stronie.

Jest to funkcjonalność root, więc została zaimplementowana prawie jako pierwsza. A potem wszystko wokół niego wyrosło.

Tak naprawdę, poprzez autoryzację, gracz otrzymuje od backendu playlistę z linkami do fragmentów skorelowanych z czasem i jakością, pobiera niezbędne i pokazuje je użytkownikowi, dokonując przy tym pewnej „magii”.

Opracuj platformę wideo w 90 dni
Przykład osi czasu

— W odtwarzaczu wbudowany jest przycisk umożliwiający wyświetlenie osi czasu wszystkich raportów...

Nikolai: Tak, od razu rozwiązaliśmy problem nawigacji użytkownika. W połowie kwietnia zdecydowaliśmy, że nie będziemy transmitować każdej z naszych konferencji na osobnym portalu, ale połączymy wszystko w jednym. Dzięki temu użytkownicy biletów Full Pass mogą swobodnie przełączać się pomiędzy różnymi konferencjami: zarówno transmisjami na żywo, jak i nagraniami poprzednich.

Aby ułatwić użytkownikom nawigację po bieżącym strumieniu i przełączanie między utworami, zdecydowaliśmy się stworzyć przycisk „Cała transmisja” i poziome karty raportów umożliwiające przełączanie między ścieżkami i raportami. Jest sterowanie klawiaturą.

— Czy były z tym jakieś problemy techniczne?

Nikolai: Posiadały pasek przewijania, na którym zaznaczano punkty początkowe poszczególnych raportów.

— Czy ostatecznie umieściłeś te znaczniki na pasku przewijania, zanim YouTube zrobił coś podobnego?

Artem: Mieli to wtedy w wersji beta. Wygląda na to, że jest to dość złożona funkcja, ponieważ w ciągu ostatniego roku częściowo testowano ją z użytkownikami. A teraz trafił do sprzedaży.

Nikolai: Ale tak naprawdę udało nam się go sprzedać szybciej. Szczerze mówiąc, za tą prostą funkcją kryje się ogromna ilość backendu, frontendu, obliczeń i matematyki wewnątrz odtwarzacza.

Interfejs użytkownika

— Zastanówmy się, w jaki sposób wyświetlana przez nas treść (karta mowy, głośniki, strona internetowa, harmonogram) trafia do interfejsu użytkownika?

Władimir Krasilszczik: Posiadamy kilka wewnętrznych systemów informatycznych. Istnieje system, w którym wpisywane są wszystkie raporty i wszyscy prelegenci. Istnieje proces, w wyniku którego mówca bierze udział w konferencji. Prelegent składa wniosek, system go przechwytuje, po czym następuje pewien potok, według którego tworzony jest raport.

Opracuj platformę wideo w 90 dni
Tak mówca widzi rurociąg

System ten jest naszym wewnętrznym rozwojem.

Następnie musisz zbudować harmonogram na podstawie poszczególnych raportów. Jak wiadomo, jest to problem NP-trudny, ale jakoś go rozwiązujemy. W tym celu uruchamiamy kolejny komponent, który generuje harmonogram i przesyła go do zewnętrznej usługi chmurowej Contentful. Tam wszystko wygląda jak tabela, w której są dni konferencji, w dniach przedziały czasowe, a w przedziałach sprawozdania, przerwy czy działania sponsorskie. Zatem treści, które widzimy, znajdują się w usłudze strony trzeciej. Zadaniem jest przekazanie tego na stronę.

Wydawać by się mogło, że strona to tylko strona z odtwarzaczem i nie ma tu nic skomplikowanego. Chyba, że ​​tak nie jest. Backend stojący za tą stroną przechodzi do Contentful, pobiera stamtąd harmonogram, generuje pewne obiekty i wysyła je do frontendu. Korzystając z połączenia websocket, które wykonuje każdy klient naszej platformy, przesyłamy mu aktualizację harmonogramu z backendu na frontend.

Prawdziwy przypadek: prelegent zmienił pracę już w trakcie konferencji. Musimy zmienić jego identyfikator firmy pracodawcy. Jak to się dzieje z backendu? Aktualizacja jest wysyłana do wszystkich klientów poprzez websocket, a następnie sam frontend ponownie rysuje oś czasu. Wszystko to dzieje się płynnie. Połączenie usługi w chmurze i kilku naszych komponentów daje nam możliwość wygenerowania całej tej treści i dostarczenia jej na pierwszy plan.

Nikolai: Warto tutaj wyjaśnić, że nasza strona nie jest klasyczną aplikacją SPA. Jest to zarówno renderowana strona internetowa oparta na układzie, jak i SPA. Google faktycznie postrzega tę witrynę jako wyrenderowany kod HTML. Jest to dobre dla SEO i dostarczania treści użytkownikowi. Nie czeka na załadowanie 1,5 megabajta kodu JavaScript, zanim zobaczy stronę, natychmiast widzi już wyrenderowaną stronę i czujesz to za każdym razem, gdy przełączasz raport. Wszystko dzieje się w pół sekundy, gdyż treść jest już gotowa i zamieszczona we właściwym miejscu.

— Narysujmy granicę pomiędzy powyższymi kwestiami, wymieniając technologie. Tyoma powiedział, że mamy 5 strumieni Amazon i tam dostarczamy obraz i dźwięk. Mamy tam skrypty bashowe, za ich pomocą uruchamiamy i konfigurujemy...

Artem: Dzieje się to poprzez API AWS, jest tam o wiele więcej dodatkowych usług technicznych. Podzieliliśmy się obowiązkami tak, abym ja dostarczał CloudFront, a programiści front-end i back-end czerpią to stamtąd. Posiadamy szereg własnych opraw upraszczających układ treści, które następnie wykonujemy w 4K itp. Ponieważ terminy były bardzo napięte, zrobiliśmy to prawie w całości na AWS.

— Następnie wszystko to trafia do odtwarzacza za pomocą systemu zaplecza. W naszym odtwarzaczu mamy TypeScript, React, Next.JS. A na backendzie mamy kilka usług w C#, Java, Spring Boot i Node.js. Wszystko to jest wdrażane za pomocą Kubernetes przy użyciu infrastruktury Yandex.Cloud.

Pragnę też zaznaczyć, że gdy potrzebowałem zapoznać się z platformą, okazało się to proste: wszystkie repozytoria znajdują się na GitLabie, wszystko jest dobrze nazwane, napisane są testy, jest dokumentacja. Oznacza to, że nawet w trybie awaryjnym zajęli się takimi sprawami.

Ograniczenia biznesowe i analityka

— Wybraliśmy grupę 10 000 użytkowników w oparciu o wymagania biznesowe. Czas porozmawiać o ograniczeniach biznesowych, które mieliśmy. Musieliśmy zapewnić duże obciążenie pracą, zapewnić zgodność z prawem o ochronie danych osobowych. I co jeszcze?

Nikolai: Początkowo zaczęliśmy od wymagań wideo. Najważniejszą rzeczą jest rozproszona pamięć wideo na całym świecie, aby zapewnić szybką dostawę do klienta. Inne obejmują rozdzielczość 1080p, a także przewijanie do tyłu, czego wiele innych nie realizuje w trybie na żywo. Później dodaliśmy możliwość włączenia prędkości 2x, dzięki której można „nadrobić zaległości” na żywo i kontynuować oglądanie konferencji w czasie rzeczywistym. Po drodze pojawiła się funkcja oznaczania osi czasu. Dodatkowo musieliśmy być odporni na awarie i wytrzymać obciążenie 10 000 połączeń. Z punktu widzenia backendu jest to około 10 000 połączeń pomnożonych przez 8 żądań na każde odświeżenie strony. A to już 80 000 RPS/s. Całkiem sporo.

— Czy były jakieś inne wymagania dotyczące „wirtualnej wystawy” ze stoiskami partnerów online?

Nikolai: Tak, trzeba było to zrobić dość szybko i uniwersalnie. Do każdej konferencji mieliśmy maksymalnie 10 firm partnerskich i wszystkie musiały zostać ukończone w ciągu tygodnia lub dwóch. Ich treść różni się jednak nieco formatem. Ale stworzono pewien silnik szablonów, który składa te strony w locie, praktycznie bez dalszego udziału w rozwoju.

— Pojawiły się także wymagania dotyczące analityki widoków w czasie rzeczywistym i statystyk. Wiem, że używamy do tego Prometheusa, ale powiedz nam szerzej: jakie wymagania spełniamy w zakresie analityki i jak to jest realizowane?

Nikolai: Na początek mamy wymagania marketingowe dotyczące zbierania do testów A/B i zbierania informacji, aby zrozumieć, jak prawidłowo dostarczyć klientowi w przyszłości najlepszą treść. Istnieją również wymagania dotyczące niektórych analiz dotyczących działań partnerów i analiz, które widzisz (licznik odwiedzin). Wszystkie informacje gromadzone są w czasie rzeczywistym.

Możemy przekazać te informacje w formie zbiorczej nawet prelegentom: ile osób Cię oglądało w określonym momencie. Jednocześnie, aby zachować zgodność z ustawą federalną nr 152, Twoje konto osobiste i dane osobowe nie są w żaden sposób śledzone.

Platforma posiada już narzędzia marketingowe oraz nasze metryki umożliwiające pomiar aktywności użytkowników w czasie rzeczywistym (kto oglądał, która sekunda raportu) w celu budowania wykresów frekwencji na raportach. Na podstawie tych danych prowadzone są badania, które sprawią, że kolejne konferencje będą lepsze.

Oszustwo

— Czy posiadamy mechanizmy zwalczania nadużyć finansowych?

Nikolai: Ze względu na napięte z biznesowego punktu widzenia ramy czasowe, początkowo zadaniem nie było natychmiastowe blokowanie zbędnych połączeń. Jeśli dwóch użytkowników zalogowało się na to samo konto, mogliby przeglądać zawartość. Wiemy jednak, ile było jednoczesnych wyświetleń z jednego konta. Zablokowaliśmy także kilka szczególnie złośliwych osób naruszających zasady.

Vladimir: Trzeba przyznać, że jeden z zablokowanych użytkowników zrozumiał, dlaczego tak się stało. Przyszedł, przeprosił i obiecał kupić bilet.

— Aby to wszystko mogło się wydarzyć, musisz całkowicie prześledzić wszystkich użytkowników od wejścia do wyjścia i zawsze wiedzieć, co robią. Jak działa ten system?

Vladimir: Chciałbym porozmawiać o analityce i statystykach, które następnie analizujemy pod kątem powodzenia raportu lub możemy następnie udostępnić partnerom. Wszyscy klienci są połączeni za pośrednictwem połączenia internetowego z określonym klastrem zaplecza. Stoi tam Leszczyna. Każdy klient w każdym przedziale czasowym przesyła co robi i jaki utwór ogląda. Następnie informacje te są agregowane przy użyciu szybkich zadań Hazelcast i wysyłane z powrotem do każdego, kto ogląda te utwory. W rogu widzimy, ile osób jest teraz z nami.

Opracuj platformę wideo w 90 dni

Te same informacje są przechowywane w Mongo i trafia do naszego jeziora danych, z którego mamy możliwość zbudowania ciekawszego wykresu. Powstaje pytanie: ilu unikalnych użytkowników obejrzało ten raport? Idziemy do Postgres, są pingi wszystkich osób, które przyszły przez identyfikator tego raportu. Zebraliśmy, zagregowaliśmy unikalne i teraz możemy zrozumieć.

Nikolai: Ale jednocześnie otrzymujemy również dane w czasie rzeczywistym od Prometeusza. Jest przeciwny wszystkim usługom Kubernetes i samemu Kubernetesowi. Zbiera absolutnie wszystko, a dzięki Grafanie możemy budować dowolne wykresy w czasie rzeczywistym.

Vladimir: Z jednej strony pobieramy to w celu dalszego przetwarzania OLAP. A w przypadku OLTP aplikacja pobiera całość do Prometheusa, Grafany i wykresy nawet się zbiegają!

- Dzieje się tak, gdy wykresy są zbieżne.

Zmiany dynamiczne

— Powiedz nam, jak wprowadzane są dynamiczne zmiany: jeśli raport został odwołany 6 minut przed startem, jaki jest łańcuch działań? Który rurociąg działa?

Vladimir: Rurociąg jest bardzo warunkowy. Istnieje kilka możliwości. Po pierwsze, program do generowania harmonogramu zadziałał i zmienił harmonogram. Zmodyfikowany harmonogram zostanie przesłany do Contentful. Po czym backend rozumie, że w Contentful nastąpiły zmiany dla tej konferencji, bierze je i odbudowuje. Wszystko jest gromadzone i wysyłane poprzez websocket.

Druga możliwość, gdy wszystko dzieje się w zawrotnym tempie: redaktor ręcznie zmienia informacje w Contentful (link do Telegramu, prezentacja prelegenta itp.) i działa ta sama logika, co za pierwszym razem.

Nikolai: Wszystko dzieje się bez odświeżania strony. Wszelkie zmiany zachodzą dla klienta całkowicie bezproblemowo. To samo dotyczy raportów przełączania. Kiedy nadejdzie czas, raport i interfejs się zmienią.

Vladimir: Istnieją również ograniczenia czasowe dotyczące rozpoczęcia raportów na osi czasu. Na samym początku nie ma nic. A jeśli najedziesz myszką na czerwony pasek, to w pewnym momencie, dzięki reżyserowi transmisji, pojawią się odcięcia. Reżyser ustala prawidłowy początek transmisji, backend wychwytuje tę zmianę, oblicza czas rozpoczęcia i zakończenia prezentacji całego utworu zgodnie z harmonogramem konferencji, wysyła go do naszych klientów, a odtwarzacz losuje przerwy. Teraz użytkownik może łatwo przejść do początku i końca raportu. Był to rygorystyczny wymóg biznesowy, bardzo wygodny i użyteczny. Nie tracisz czasu na szukanie faktycznego czasu rozpoczęcia raportu. A kiedy zrobimy podgląd, będzie absolutnie cudownie.

Zastosowanie

— Chciałbym zapytać o rozmieszczenie. Na początku Kolya i zespół spędzili dużo czasu na skonfigurowaniu całej infrastruktury, w której wszystko się dla nas rozwija. Powiedz mi, z czego to wszystko jest zrobione?

Nikolai: Z technicznego punktu widzenia początkowo wymagaliśmy, aby produkt był jak najbardziej abstrakcyjny od dowolnego dostawcy. Przyjdź do AWS, aby tworzyć skrypty Terraform specjalnie z AWS, lub konkretnie z Yandex, lub z Azure itp. naprawdę nie pasowało. W pewnym momencie musieliśmy się gdzieś przenieść.

Przez pierwsze trzy tygodnie nieustannie szukaliśmy sposobu, aby zrobić to lepiej. W rezultacie doszliśmy do wniosku, że Kubernetes w tym przypadku jest dla nas wszystkim, ponieważ pozwala nam tworzyć automatycznie skalujące się usługi, autorollout i uzyskać prawie wszystkie usługi od razu po wyjęciu z pudełka. Naturalnie wszystkie usługi musiały zostać przeszkolone do współpracy z Kubernetesem, Dockerem, a zespół też musiał się tego nauczyć.

Mamy dwa klastry. Testowanie i produkcja. Są absolutnie identyczne pod względem sprzętu i ustawień. Infrastrukturę wdrażamy jako kod. Wszystkie usługi są automatycznie wdrażane w trzech środowiskach z gałęzi funkcji, gałęzi głównych, gałęzi testowych i GitLab przy użyciu automatycznego potoku. Jest to maksymalnie zintegrowane z GitLabem, maksymalnie zintegrowane z Elasticiem, Prometheusem.

Otrzymujemy możliwość szybkiego (dla backendu w ciągu 10 minut, dla frontendu w ciągu 5 minut) wdrożenia zmian w dowolnym środowisku wraz ze wszystkimi testami, integracjami, uruchomieniem testów funkcjonalnych, testów integracyjnych na środowisku, a także testów z testami obciążeniowymi na środowisko testowe w przybliżeniu to samo, co chcemy uzyskać na produkcji.

O testach

— Testujesz prawie wszystko, trudno uwierzyć, jak to wszystko napisałeś. Czy możesz nam opowiedzieć o testach backendu: ile wszystkiego obejmuje, jakie testy?

Vladimir: Napisano dwa rodzaje testów. Pierwszą z nich są testy komponentowe. Testy poziomu podnoszenia całego zastosowania sprężyny i podstawy Pojemniki testowe. Jest to test scenariuszy biznesowych najwyższego poziomu. Nie testuję funkcji. Testujemy tylko kilka dużych rzeczy. Przykładowo, bezpośrednio w teście emulowany jest proces logowania użytkownika, żądanie użytkownika o bilety do miejsca, w którym może się udać oraz żądanie dostępu do oglądania transmisji. Bardzo jasne scenariusze użytkownika.

Mniej więcej to samo implementuje się w tzw. testach integracyjnych, które faktycznie działają na środowisku. W rzeczywistości, kiedy wdrażane jest kolejne wdrożenie w środowisku produkcyjnym, w środowisku produkcyjnym działają również prawdziwe podstawowe scenariusze. To samo logowanie, prośba o bilety, prośba o dostęp do CloudFront, sprawdzanie, czy strumień rzeczywiście łączy się z moimi uprawnieniami, sprawdzanie interfejsu reżysera.

W tej chwili mam na pokładzie około 70 testów komponentowych i około 40 testów integracyjnych. Zasięg jest bardzo bliski 95%. To jest dla komponentów, mniej dla integracji, po prostu nie jest tak wiele potrzebne. Biorąc pod uwagę, że projekt obejmuje wszelkiego rodzaju generowanie kodu, jest to bardzo dobry wskaźnik. Nie było innego sposobu, aby zrobić to, co zrobiliśmy w trzy miesiące. Ponieważ gdybyśmy testowali ręcznie, przekazując funkcje naszej testerce, a ona znalazłaby błędy i zwróciła je nam w celu naprawy, wówczas podróż w obie strony w celu debugowania kodu byłaby bardzo długa i nie dotrzymalibyśmy żadnych terminów.

Nikolai: Konwencjonalnie, aby przeprowadzić regresję na całej platformie przy zmianie jakiejś funkcji, trzeba siedzieć i szperać wszędzie przez dwa dni.

Vladimir: Dlatego wielkim sukcesem jest to, że oceniając funkcję, mówię, że potrzebuję 4 dni na dwa proste pióra i 1 gniazdo internetowe, Kolya na to pozwala. Przyzwyczaił się już do tego, że te 4 dni obejmują 2 rodzaje testów i wtedy najprawdopodobniej się uda.

Nikolai: Mam też napisanych 140 testów: komponentowy + funkcjonalny, które robią to samo. Wszystkie te same scenariusze są testowane w środowisku produkcyjnym, testowym i produkcyjnym. Niedawno dodaliśmy także podstawowe testy funkcjonalne interfejsu użytkownika. W ten sposób pokrywamy najbardziej podstawową funkcjonalność, która może się rozpaść.

Vladimir: Oczywiście warto porozmawiać o testach obciążeniowych. Należało przetestować platformę pod obciążeniem zbliżonym do rzeczywistego, aby zrozumieć, jak wszystko się dzieje, co dzieje się z Rabbitem, co dzieje się z maszynami JVM, ile faktycznie potrzeba pamięci.

— Nie jestem pewien, czy testujemy coś po stronie strumienia, ale pamiętam, że podczas spotkań były problemy z transkoderami. Czy testowaliśmy strumienie?

Artem: Testowane iteracyjnie. Organizowanie spotkań. W trakcie organizacji spotkań sprzedano około 2300 biletów JIRA. To tylko ogólne rzeczy, które ludzie robili, aby się spotykać. Części platformy umieściliśmy na osobnej stronie poświęconej spotkaniom, którą prowadził Kirill Tołkaczow (talkkv).

Szczerze mówiąc nie było większych problemów. Dosłownie kilka razy złapaliśmy błędy w buforowaniu w CloudFront, rozwiązaliśmy to dość szybko - po prostu ponownie skonfigurowaliśmy zasady. Znacznie więcej błędów było u ludzi, w systemach transmisji strumieniowej na stronie.

Podczas konferencji musiałem napisać do kilku kolejnych eksporterów, aby opisać więcej sprzętu i usług. W niektórych miejscach musiałem sam robić rowery ze względu na metryki. Świat sprzętu AV (audio-wideo) nie jest zbyt różowy - masz pewnego rodzaju „API” sprzętu, na który po prostu nie masz wpływu. I wcale nie jest tak, że będziesz w stanie uzyskać potrzebne informacje. Dostawcy sprzętu są naprawdę powolni i prawie niemożliwe jest uzyskanie od nich tego, czego chcesz. W sumie jest ponad 100 sztuk sprzętu, nie oddają tego, czego potrzebujesz, a do tego piszesz dziwnych i zbędnych eksporterów, dzięki którym możesz przynajmniej w jakiś sposób zdebugować system.

Sprzęt

— Pamiętam, jak przed rozpoczęciem konferencji częściowo zakupiliśmy dodatkowy sprzęt.

Artem: Zakupiliśmy komputery, laptopy i akumulatory. W tej chwili bez prądu możemy żyć 40 minut. W czerwcu w Petersburgu były silne burze - więc mieliśmy taki blackout. Jednocześnie kilku dostawców przychodzi do nas z łączami optycznymi z różnych punktów. To tak naprawdę 40 minut przestoju budynku, podczas którego będziemy mieć włączone światła, dźwięk, kamery itp. Działające.

— Podobną historię mamy z Internetem. W biurze, w którym mieszczą się nasze studia, rozciągnęliśmy między piętrami zaciętą sieć.

Artem: Mamy 20 Gbit światłowodu pomiędzy piętrami. Dalej na piętrach gdzieś jest optyka, gdzieś nie ma optyki, ale i tak kanałów jest mniej niż gigabitowych – puszczamy na nich wideo pomiędzy utworami konferencji. Ogólnie rzecz biorąc, bardzo wygodnie jest pracować na własnej infrastrukturze, rzadko można to zrobić na konferencjach offline w witrynach.

— Zanim zacząłem pracować w Grupie JUG Ru, widziałem, jak podczas konferencji offline organizowano w ciągu nocy pomieszczenia sprzętowe, na których znajdował się duży monitor ze wszystkimi wskaźnikami, które buduje się w Grafanie. Teraz znajduje się tu także sala centrali, w której siedzi zespół programistów, który podczas konferencji naprawia niektóre błędy i rozwija funkcje. Jednocześnie istnieje system monitorowania wyświetlany na dużym ekranie. Artem, Kola i inni siedzą i pilnują, żeby to wszystko nie upadło i działało pięknie.

Ciekawostki i problemy

— Dobrze mówiłeś o tym, że mamy streaming z Amazonem, jest odtwarzacz z siecią, wszystko jest napisane w różnych językach programowania, zapewniona jest odporność na błędy i inne wymagania biznesowe, w tym konto osobiste obsługiwane dla osób prawnych i indywidualnych osób i możemy zintegrować się z kimś za pomocą OAuth 2.0, istnieje ochrona przed oszustwami, blokowanie użytkowników. Możemy wprowadzać zmiany dynamicznie, ponieważ zrobiliśmy to dobrze i wszystko zostało przetestowane.

Ciekawi mnie, jakie dziwactwa wiązały się z rozpoczęciem czegoś. Czy zdarzyły się jakieś dziwne sytuacje, gdy tworzyłeś backend, frontend, wyszło coś szalonego i nie rozumiałeś, co z tym zrobić?

Vladimir: Wydaje mi się, że działo się to tylko przez ostatnie trzy miesiące. Codziennie. Jak widać, wszystkie moje włosy zostały wyrwane.

Opracuj platformę wideo w 90 dni
Władimir Krasilshchik po 3 miesiącach, kiedy wyszła jakaś gra i nikt nie rozumiał, co z nią zrobić

Codziennie było coś takiego, kiedy był taki moment, kiedy bierzesz to i wyrywasz sobie włosy z głowy, albo uświadamiasz sobie, że nie ma nikogo innego i tylko ty możesz to zrobić. Naszym pierwszym dużym wydarzeniem był TechTrain. 6 czerwca o 2 w nocy nie uruchomiliśmy jeszcze środowiska produkcyjnego, Kolya je wdrażało. A konto osobiste nie sprawdziło się jako serwer autoryzacyjny wykorzystujący OAuth2.0. Przekształciliśmy go w dostawcę OAuth2.0, aby połączyć z nim platformę. Pracowałem bez przerwy chyba 18 godzin, patrzyłem na komputer i nic nie widziałem, nie rozumiałem dlaczego nie działa, a Kolya zdalnie przeglądał mój kod, szukał błędu w konfiguracji Springa , znalazłem i LC zadziałało, a także w produkcji.

Nikolai: I na godzinę przed premierą TechTrain miało miejsce wydanie.

Ustawiono tu wiele gwiazd. Mieliśmy ogromne szczęście, bo mieliśmy super zespół, a wszystkich zainspirował pomysł zrobienia tego online. Przez te trzy miesiące napędzał nas fakt, że „zrobiliśmy YouTube”. Nie pozwoliłam sobie wyrwać sobie włosów, ale powiedziałam wszystkim, że wszystko się ułoży, bo tak naprawdę wszystko zostało już dawno obliczone.

O wydajności

— Czy możesz mi powiedzieć, ile osób było na stronie na jednym ścieżce? Czy były jakieś problemy z wydajnością?

Nikolai: Jak już powiedzieliśmy, nie było problemów z wydajnością. Maksymalna liczba osób, które uczestniczyły w jednym raporcie wyniosła 1300 osób, dotyczy to Heisenbuga.

— Czy były jakieś problemy z oglądaniem lokalnym? A czy można prosić o opis techniczny ze schematami jak to wszystko działa?

Nikolai: Później napiszemy o tym artykuł.

Możesz nawet debugować strumienie lokalnie. Gdy zaczęły się konferencje, stało się to jeszcze łatwiejsze, bo pojawiły się streamy produkcyjne, które możemy oglądać cały czas.

Vladimir: Z tego co wiem, front-end developerzy pracowali lokalnie z makietami, a potem, bo czas na rollowanie do front-endu też jest krótki (5 minut), to nie ma problemów ze sprawdzeniem co się dzieje z certyfikatami.

— Wszystko jest testowane i debugowane, nawet lokalnie. Oznacza to, że napiszemy artykuł ze wszystkimi funkcjami technicznymi, pokażemy, opowiemy wszystko za pomocą diagramów, jak to było.

Vladimir: Możesz to wziąć i powtórzyć.

- Za 3 miesiące.

Łączny

— Wszystko opisane razem brzmi fajnie, zważywszy, że zrobił to mały zespół w trzy miesiące.

Nikolai: Duży zespół by tego nie zrobił. Ale niewielka grupa ludzi, którzy komunikują się ze sobą dość blisko i dobrze i potrafią dojść do porozumienia, mogłaby to zrobić. Nie ma w nich żadnych sprzeczności, architektura została wymyślona w dwa dni, została sfinalizowana i właściwie nie uległa zmianie. Istnieje bardzo rygorystyczne ułatwianie przychodzących wymagań biznesowych w zakresie gromadzenia żądań funkcji i zmian.

— Co było na Twojej liście dalszych zadań, gdy letnie konferencje już się odbyły?

Nikolai: Na przykład kredyty. Pnące się linie na filmie, w niektórych miejscach filmu pojawiają się wyskakujące okienka, w zależności od wyświetlanej treści. Na przykład, mówca chce zadać pytanie słuchaczom, a na ekranie pojawia się głos, który na podstawie wyników głosowania trafia do samego mówcy. Jakiś rodzaj aktywności społecznościowej w postaci polubień, serduszek, ocen raportu już w trakcie samej prezentacji, tak aby można było wypełnić opinię w odpowiednim momencie, nie rozpraszając się później formularzami opinii. Początkowo tak.

A także dodanie do całej platformy, poza streamingiem i konferencją, także stanu pokonferencyjnego. Są to playlisty (w tym te utworzone przez użytkowników), ewentualnie treści z innych poprzednich konferencji, zintegrowane, oznaczone, dostępne dla użytkownika, a także dostępne do wglądu na naszej stronie internetowej (live.jugru.org).

— Chłopaki, bardzo dziękuję za odpowiedzi!

Jeżeli wśród czytelników są tacy, którzy byli na naszych letnich konferencjach, prosimy o podzielenie się wrażeniami z odtwarzacza i transmisji. Co było dla Ciebie wygodne, co Cię irytowało, co chciałbyś zobaczyć w przyszłości?

Jeśli jesteś zainteresowany platformą i chcesz zobaczyć ją „w bitwie”, użyjemy jej ponownie na naszej konferencje jesienno-zimowe. Jest ich cała gama, więc prawie na pewno znajdziesz taki, który będzie dla Ciebie odpowiedni.

Źródło: www.habr.com

Dodaj komentarz