Pracuję w outsourcingu, gdzie główną zasadę można opisać zwrotem „sprzedaj dużo, zrób to szybko”. Im szybciej to zrobimy, tym więcej zarobimy. Pożądane jest, aby wszystko działało nie na kulach i smarkach, ale z akceptowalnym poziomem jakości. Opowiem Ci o moim doświadczeniu, gdy w krótkim czasie konieczne było opracowanie usługi promocyjnej.
Biorąc pod uwagę: konto root na AWS, brak ograniczeń w wyborze stosu technologicznego, jeden backend i jeden miesiąc na rozwój.
Zadanie: wdrożyć usługę promocyjną, w ramach której użytkownicy przesyłają od jednego do czterech filmów trwających od jednej do czterech sekund, które następnie są osadzane w oryginalnej serii filmów.
decyzja
Pisanie własnego serwisu rowerowego w tak krótkim czasie nie jest dobrym pomysłem. Ponadto, aby usługa poradziła sobie z obciążeniem i aby każdy mógł otrzymać upragniony film, wymagana będzie infrastruktura. I najlepiej nie z ceną z samolotu. Dlatego od razu stawiamy na gotowe rozwiązania przy minimalnym dostosowaniu.
Standardowym rozwiązaniem do pracy z wideo jest FFmpeg, wieloplatformowe narzędzie konsolowe, które poprzez argumenty umożliwia wycinanie i dogrywanie dźwięku. Pozostało tylko napisać opakowanie i puścić go w życie. Piszemy prototyp, który łączy ze sobą dwa filmy i... zaczyna się zabawa. Biblioteka oparta jest na .NET Core 2, powinna działać na dowolnej maszynie wirtualnej, więc bierzemy instancję AWS EC2 i wszystko będzie działać
Ukryty tekstnie, to nie zadziała
.
Chociaż FFmpeg upraszcza zadanie, aby naprawdę działające rozwiązanie wymagało utworzenia instancji EC2 i zaprojektowania dla niej infrastruktury sieciowej, w tym modułu równoważenia obciążenia. Proste zadanie wdrożenia od zera staje się „trochę” bardziej skomplikowane, a infrastruktura natychmiast zaczyna żądać pieniędzy – co godzinę z konta klienta pobierana jest kwota za czas działania.
Nasza usługa nie obejmuje długotrwałych procesów, nie wymaga dużej i rozbudowanej relacyjnej bazy danych oraz doskonale wpisuje się w architekturę opartą na zdarzeniach z łańcuchem wywołań mikrousług. Rozwiązanie podsuwa się samo - możemy porzucić EC2 i wdrożyć aplikację typu true-serverless, jak standardowy Image Resizer oparty na AWS Lambda.
Nawiasem mówiąc, pomimo oczywistej niechęci programistów AWS do .NET, wspierają oni .NET Core 2.1 jako środowisko uruchomieniowe, co zapewnia pełen zakres możliwości programistycznych.
I wisienka na torcie – AWS udostępnia osobną usługę do pracy z plikami wideo – AWS Elemental MediaConvert.
Istota pracy jest niesamowicie prosta: bierzemy link S3 do wychodzącego wideo, piszemy poprzez AWS Console, .NET SDK lub po prostu JSON, co chcemy zrobić z wideo i dzwonimy do serwisu. Sam implementuje kolejki do przetwarzania przychodzących żądań, sam przesyła wynik do S3 i co najważniejsze, dla każdej zmiany statusu generuje zdarzenie CloudWatch. Dzięki temu możemy zaimplementować wyzwalacze lambda w celu zakończenia przetwarzania wideo.
Tak wygląda ostateczna architektura:
Cały backend mieści się w dwóch lambdach. Innym jest obracanie filmów w pionie, ponieważ takiej pracy nie da się wykonać w jednym przejściu.
Front umieścimy w postaci aplikacji SPA napisanej w JS i skompilowanej poprzez pug w publicznym Bucket S3. Aby pobrać same filmy, nie potrzebujemy żadnego kodu serwera - wystarczy, że otworzymy punkty końcowe REST, które udostępnia nam S3. Jedyną rzeczą jest nie zapomnij skonfigurować zasad i CORS.
Pułapki
- AWS MediaConvert z niewiadomego powodu stosuje dźwięk tylko do każdego fragmentu wideo z osobna, ale potrzebujemy wesołej piosenki z całego wygaszacza ekranu.
- Filmy pionowe wymagają osobnej obróbki. AWS nie lubi czarnych pasków i ustawia rolki pod kątem 90°.
Łatwe lodowisko
Pomimo całego piękna Stateless, musisz śledzić, co należy zrobić z wideo: przykleić lub dodać dźwięk do gotowej sekwencji wideo. Na szczęście MediaConvert obsługuje przekazywanie metadanych przez swoje Jobs i zawsze możemy użyć prostej flagi w postaci „isMasterSoundJob”, analizując te metadane na dowolnym etapie.
Serverless doskonale pozwala na pracę z NoOps – podejście zakładające zbędność osobnego zespołu odpowiedzialnego za infrastrukturę projektu. Była to zatem drobnostka – rozwiązanie wdrażamy na AWS bez udziału administratorów systemu, którzy i tak zawsze mają coś do zrobienia.
Aby to wszystko przyspieszyć, maksymalnie automatyzujemy skrypt wdrażania na AWS CloudFormation, co pozwala na wdrożenie jednym przyciskiem bezpośrednio z VS. W rezultacie plik zawierający 200 linii kodu pozwala na wdrożenie gotowego rozwiązania, choć składnia CloudFormation może szokować, jeśli nie jesteś do niej przyzwyczajony.
Razem
Bezserwerowy nie jest panaceum. Ale znacznie ułatwi życie w sytuacjach, w których obowiązują trzy ograniczenia: „ograniczone zasoby – krótkoterminowo – mało pieniędzy”.
Charakterystyka aplikacji odpowiednich dla wersji bezserwerowych
- bez długotrwałych procesów. Twardy limit API Gateway to 29 sekund, twardy limit lambda to 5 minut;
- opisany przez architekturę sterowaną zdarzeniami;
- rozkłada się na luźno powiązane komponenty, takie jak SOA;
- nie wymaga wiele pracy w związku z twoją chorobą;
- napisany w .NET Core. Do pracy z .NET Framework nadal będziesz potrzebować przynajmniej Dockera z odpowiednim środowiskiem wykonawczym.
Korzyści z podejścia bezserwerowego
- zmniejsza koszty infrastruktury;
- zmniejsza koszt dostarczenia rozwiązania;
- automatyczna skalowalność;
- rozwój w czołówce postępu technologicznego.
Wady na konkretnym przykładzie
- Rozproszone śledzenie i rejestrowanie - częściowo rozwiązane za pomocą AWS X-Ray i AWS CloudWatch;
- niewygodne debugowanie;
- Zimny start, gdy nie ma obciążenia;
- Interfejs AWS wrogi użytkownikowi to problem uniwersalny :)
Źródło: www.habr.com