Skoro już cię przekonałem dlaczego warto używać chmury oraz dlaczego to może być AWS następnym logicznym krokiem jest przedstawienie jakiegoś przykładowego rozwiązania bazującego na chmurze AWS. Dziś na warsztat weźmiemy rozwiązanie streamingowe, które pozwoli ci pobić Netflixa 😉

 

Domena

Dla uproszczenia dziedziny problemu, przyjmijmy, że chcielibyśmy mniej więcej odzwierciedlić podstawowe funkcjonalności Netflixa (oczywiście zrobimy to lepiej!), czyli dostarczyć rozwiązanie pozwalające na oglądanie wideo na życzenie oraz platformę, która owe wideo serwuje. 
Użytkownik w dzisiejszych czasach jest bardzo wybredny. Mając do czynienia z rozwiązaniami typu HBO Go czy Netfix musimy dostarczyć serwis, która będzie:

Niezawodny

Powiedzmy sobie szczerze ile razy nie działał ci Netflix z ich winy?

Szybki

Jeżeli użytkownik będzie musiał czekać na buforowanie wideo zbyt długo to pójdzie tam gdzie nie musi czekać. To nic osobistego.

Relatywnie tani

Oczywiście możemy kupić najlepsze dostępne serwery, bazy danych itd, ale kiedy przyjdzie nam obsługiwać ruch tysięcy użytkowników to rachunki szybko poszybują na poziomy takie, że szybko zrezygnujemy z naszych ambitnych planów.

Skalowalny

Użytkownika mało obchodzi to, że akurat dziś ruch na naszych serwerach jest 2-3 czy 10 razy większy niż zwykle. To się zdarza, naszym zadaniem jest na to się przygotować.

Ogólna architektura

Pomijając zbędne szczegóły architektura takiego przekrojowego rozwiązania może wyglądać następująco:

Omówmy sobie po kolei wszystkie komponenty

Warstwa API Gateway

Odpowiada za odbiór żądań ze strony urządzeń. Jak mówi nazwa to interfejs do naszego systemu. Wszelkiego rodzaju przeglądarki, smartfony czy też TV będą komunikować się właśnie przez tą warstwę. Tutaj załatwimy sprawę cache-owania żądań, kontroli dostępu i przekierujemy żądania do warstwy serwerów aplikacyjnych.

Warstwa serwerów aplikacyjnych

Tutaj umieścimy obliczenia i całą logikę odpowiedzialną za obsługę żądań. Główny kod odpowiedzialny za synchroniczne przetwarzanie zapytań tak by dostarczyć użytkownikowi odpowiednie „ekrany” i ich zawartość. Od strony infrastruktury, logika odpalana jest oczywiście na serwerach czy też ich klastrach. Częściowo mogą być to lambdy przy podejściu bardziej serverless. Zwłaszcza na początku gdy dopiero rozpatrujemy różne możliwości jest to kuszące rozwiązanie. Mamy tu także wykorzystanie kolejek zadań, cache, baz danych, oraz oczywiście innych mikroserwisów czy to naszych, czy też zewnętrznych rozwiązań – SAAS.

Warstwa zadań asynchronicznych.

Wszystkie zapytania, które nie należą do naszej aplikacji bezpośrednio, ale też muszą się zadziać. Jeżeli chcesz zrobić system chociaż w niewielkim stopniu podobny do Netflixa, czy też go pobić, trzeba sobie uświadomić sobie ogrom pracy jaka jest wykonywana „pod spodem”, czyli po prostu na backendzie.

Co musimy przygotować dla użytkowników?

• Wideo w odpowiednim formacie. Każde urządzenia to inne wymagania odnośnie formatu czy też rozmiaru. Nie mówiąc o tym, że musimy serwować różne pliki w zależności od szybkości łącza użytkownika.
• Rekomendacje. Kiedyś to może byłby fajny dodatek, teraz to wymóg by prezentować rekomendacje dla użytkowników, jeżeli trafimy w gusta, +5 punktów dla nas!
• Newslettery. Byle nie za dużo spamu.
• Bieżąca obsługa. Reset hasła, usunięcie konta itd

Przestrzeń chmurowa (cloud storage) i CDN

Forma przechowywania danych wideo to jedno z bardziej krytycznych zadań. Trzeba pamiętać o tym, że danych tych będzie bardzo dużo (pamiętasz, że mamy wiele kopii tych samych filmów?) Potencjalne koszty będą tutaj silnie skorelowane właśnie z rozmiarem danych. Z drugiej strony nie możemy sobie pozwolić by dostęp do nich był wolny, inaczej użytkownik szybko wybierze konkurencję. Innymi słowy potrzebujemy hybrydy przestrzeni chmurowej i CDNa. Przestrzeń chmurowa to po prostu serwer plików, a CDN, czyli Content Delivery Network lix-a to rozproszona sieć buforująca często używane zasoby poprzez ich kopiowanie na odpowiednie serwery będące blisko użytkownika końcowego. Będąc w Polsce, możemy szybciej streamować film, jeżeli znajduje się od na serwerze we Wrocławiu, niż gdy znajduje się w Los Angeles, prawda?

Uczenie maszynowe

Tutaj umieszczamy cokolwiek, byle by móc powiedzieć, że „robimy machine learning” i ściągnąć zainteresowanie inwestorów i klientów 😛 A tak na prawdę to skoro chcemy serwować naszym użytkownikom wspomniane wcześniej rekomendacje to dobrze jest móc to robić w oparciu nie o sztywne reguły, a właśnie modele wykorzystujące uczenie maszynowe. Dzięki temu będziemy mogli analizować podobieństwo między różnymi użytkownikami oraz podobieństwo miedzy filmami i na tej podstawie decydować czym dana osoba może być zainteresowana. To wszystko powinno przełożyć na trafniejsze rekomendacje i wzrost zainteresowania naszym rozwiązaniem.

Hurtownia danych

Raporty, analiza danych, musisz trzymać rękę na pulsie. Hurtownia to miejsce gdzie dane te są zorganizowane w przystępnej formie.

AWS

Przestwawię teraz przykładową implementację powyższych komponentów w AWSie. Od razu zaznaczam, że pewne kwestie zostały pominięte dla prostoty diagramu, przykładowo logowanie czy monitoring. Jeżeli chodzi o dobór konkretnych rozwiązań to też mamy do wyboru wielorakie rozwiązania na rynku. Nic nie stoi na przeszkodzie by część z nich było poza AWS, jednak formuła tego artykułu jest taka, że tylko do tej chmury zawęzimy nasz wybór. Dobra, koniec gadania:

Wersja w lepszej rozdzielczości: tutaj

Omówię teraz po krótce kluczowe decyzje.

Warstwa API Gateway

Jak wcześnieś zauważyliśmy, chcemy odpowiednio zopytmalizować wrażenia użytkowników różnych platform. Stąd też podejście typu backend for frontend, czyli warstwa API Gateway posiada wyspecjalizowane dedykowane AWS API Gatewaye w zależności od platformy klienckiej.

Warstwa serwerów aplikacyjnych

Sercem rozwiązania są klastry ECS, czyli Elastic Cloud Server. Tak, konteneryzacja zawitała i do nas! Żądania przychodzą od strony load balancer-a. Do tego SQS do kolejkowania zadań. Jako baza danych może posłużyć nam DynamoDB o ile dobrze czujemy się w środowisku baz NoSQL. Zaletą DynamoDB jest łatwa skalowalność, która jest dla nas niemalże przeźroczysta. Alternatywnie możemy posłużyć się RDS Aurorą.

 Warstwa zadań asynchronicznych

Preview(opens in a new tab)

Od strony infrastruktury wygląda to podobnie jak w przypadku warstwy serwerów aplikacyjnych. Różnicą będzie dużo większe wykorzystanie kolejek SQS, potencjalnie także topic-ów SNS to komunikacji zorientowanej na wiadomości, której będzie tutaj dużo.

Jedno z kluczowych zadań do wykonania w tej warstwie to transcoding wideo, który może wyglądać następująco:

Na wejściu mamy nieskompresowany plik wideo, wrzucony być może przez samego autora filmu. Na wyjściu mamy plik dostosowany przez nas process do odpowiedniego urządzenia końcowego.

Przestrzeń chmurowa (cloud storage) i CDN

Troche już w punkcie poprzednim zostało opowiedziane przy okazji omawiania transcodingu. S3+CloudFront załatwiają sprawę. 

Alternatywne rozwiązania – AWS Media Services

Pewną alternatywą dla nas mogą być AWS Media Services

Z naszej perspektywy użyteczne mogło by być zwłaszcza AWS Elemental MediaConvert, które zapewnia właśnie usługę transcodingu. Dużym plusem jest to, że płacimy tutaj za użycie, czyli tak jak w infrastrukturze powyżej, gdzie brudną robotę wykonują za nas EC2-ki. Myślę, że AWS Elemental MediaConvert możemy rozważyć jako element naszego MVP a docelowo możemy kierować się jednak ku ECS/EC2 gdyż pozwoli nam to na większą elastyczność rozwiązania i zoptymalizowanie kosztów. Zasadniczo reguła kciuka mówi nam, że im bardziej wysokopoziomowe rozwiązanie, tak jak w przypadku AWS Elemental MediaConvert, cena rośnie w sposób adekwatny.

Podsumowanie i dalsze kroki

Tak jak pisałem wyżej. Poza zaprezentowanymi rozwiązaniami pozostaje do doprecyzowania zostaje wiele kwestii pobocznych. Przykładowo do logowania możemy użyć serwisu Cloud Watch. To właśnie Cloud Watcha użyjemy także do monitorowania naszych zasobów oraz podnoszenia odpowiednich alarmów gdy przykładowo będziemy mieli do czynienia z jakimś problemem. Nie chcemy przecież by tak błache rzeczy jak np. brak pamięci na serwerze, błęd w logice serwisu czy tego typu sprawy zaprzepaściły nasz cały wysiłek i popsuły wizerunek pogromcy Netflixa.

Do przesyłu danych może przydać się Kinesis streams. Autentykacja użytkowników może przebiegać w Cognito. Potrzebujemy też dobrego cache-a, Amazon ElastiCache, poratuje. A no i nie obędzie się bez kontroli tego co który serwis może robić a czego nie może zrobić. Tu do gry wkracza IAM. Na tym chyba poprzestanę 🙂

Z pewnością tego typu przekrojowa architektura może nieco odstraszać, aczkolwiek pozwala sobie jednak zdać sprawę jak skomplikowane tworzenie systemów może być gdy nie mamy do dyspozycji tych gotowych serwisów i chcielibyśmy implementować skalowalny system przy pomocy softwareu instalowanego na naszych maszynach.