Pracuji v outsourcingu, kde hlavní princip lze popsat frází „prodávejte hodně, udělejte to rychle“. Čím rychleji to uděláme, tím více vyděláme. A je žádoucí, aby vše fungovalo ne o berlích a slinách, ale s přijatelnou úrovní kvality. Řeknu vám o své zkušenosti, kdy bylo nutné v krátké době vyvinout propagační službu.
Vzhledem k: root účet na AWS, žádná omezení na výběr technologického zásobníku, jeden backend a jeden měsíc na vývoj.
Úkol: implementovat propagační službu, kde uživatelé nahrávají jedno až čtyři videa v délce od jedné do čtyř sekund, která jsou poté vložena do původní série videí.
rozhodnutí
Napsat si vlastní cykloservis v tak krátké době není dobrý nápad. Kromě toho, aby se služba vyrovnala se zátěží a všichni dostali kýžené video, bude zapotřebí infrastruktura. A raději ne s cenovkou z letadla. Proto se okamžitě zaměřujeme na hotová řešení s minimálním přizpůsobením.
Standardním řešením pro práci s videem je FFmpeg, multiplatformní konzolová utilita, která pomocí argumentů umožňuje ořezat a předubovat zvuk. Vše, co zbývá udělat, je napsat obal a uvolnit jej do života. Píšeme prototyp, který spojí dvě videa dohromady a... zábava začíná. Knihovna je založena na .NET Core 2, měla by běžet na jakémkoli virtuálním počítači, takže vezmeme instanci AWS EC2 a vše bude fungovat
Skrytý textne, nebude to fungovat
.
Přestože FFmpeg zjednodušuje úlohu, pro skutečně fungující řešení je třeba vytvořit instanci EC2 a navrhnout pro ni síťovou infrastrukturu, včetně Load Balanceru. Jednoduchý úkol nasazení od nuly se „trochu“ zkomplikuje a infrastruktura začne okamžitě požadovat peníze – každou hodinu je z klientského účtu stažena částka za běh.
Naše služba nezahrnuje dlouhotrvající procesy, nevyžaduje velkou a tučnou relační databázi a dokonale zapadá do architektury založené na událostech s řetězcem volání mikroslužeb. Řešení se navrhuje samo – můžeme opustit EC2 a implementovat aplikaci bez serveru, jako je standardní Image Resizer založený na AWS Lambda.
Mimochodem, i přes zjevnou nechuť vývojářů AWS k .NET, podporují .NET Core 2.1 jako runtime, což poskytuje celou řadu vývojových příležitostí.
A třešnička na dortu – AWS poskytuje samostatnou službu pro práci s video soubory – AWS Elemental MediaConvert.
Podstata práce je neuvěřitelně jednoduchá: vezmeme S3 odkaz na odchozí video, napíšeme přes AWS Console, .NET SDK nebo jednoduše JSON, co chceme s videem udělat a zavoláme službu. Ta sama implementuje fronty pro zpracování příchozích požadavků, sama nahraje výsledek do S3 a hlavně vygeneruje CloudWatch Event pro každou změnu stavu. To nám umožňuje implementovat spouštěče lambda pro dokončení zpracování videa.
Takto vypadá finální architektura:
Celý backend je umístěn ve dvou lambdach. Další je pro otáčení vertikálních videí, protože takovou práci nelze provést v jednom průchodu.
Předek ve formě SPA aplikace napsané v JS a zkompilované přes pug umístíme do veřejného S3 kyblíku. Ke stažení samotných videí nepotřebujeme žádný kód serveru – stačí otevřít koncové body REST, které nám poskytuje S3. Jediná věc je nezapomenout nakonfigurovat zásady a CORS.
Úskalí
- AWS MediaConvert z nějakého neznámého důvodu aplikuje zvuk pouze na každý fragment videa zvlášť, ale potřebujeme veselou písničku z celého spořiče obrazovky.
- Vertikální videa je třeba zpracovat samostatně. AWS nemá rád černé pruhy a klade válečky na 90°.
Lehké kluziště
Navzdory všem krásám Stateless musíte mít přehled o tom, co je třeba s videem udělat: slepit nebo přidat zvuk do hotové videosekvence. Naštěstí MediaConvert podporuje předávání metadat prostřednictvím svých úloh a vždy můžeme použít jednoduchý příznak ve tvaru „isMasterSoundJob“, který tato metadata analyzuje v jakékoli fázi.
Serverless dokonale umožňuje práci s NoOps – přístup, který předpokládá zbytečnost samostatného týmu odpovědného za projektovou infrastrukturu. Šlo tedy o maličkost – řešení nasazujeme na AWS bez účasti systémových administrátorů, kteří mají stejně vždy co dělat.
A abychom to vše urychlili, na AWS CloudFormation maximálně automatizujeme skript nasazení, který umožňuje nasazení jedním tlačítkem přímo z VS. Výsledkem je, že soubor o 200 řádcích kódu vám umožňuje zavést hotové řešení, i když syntaxe CloudFormation může být šokující, pokud na ni nejste zvyklí.
Celkem
Serverless není všelék. Ale výrazně usnadní život v situacích se třemi limity: „omezené zdroje – krátkodobě – málo peněz“.
Charakteristika aplikací Vhodné pro bezserverové
- bez dlouhotrvajících procesů. Pevný limit API brány je 29 sekund, pevný limit lambda je 5 minut;
- popsaný Event-Driven architekturou;
- rozpadá se na volně spojené komponenty, jako je SOA;
- nevyžaduje mnoho práce s vaším stavem;
- napsané v .NET Core. Pro práci s .NET Framework budete stále potřebovat alespoň Docker s příslušným runtimem.
Výhody bezserverového přístupu
- snižuje náklady na infrastrukturu;
- snižuje náklady na dodání řešení;
- automatická škálovatelnost;
- vývoj na špici technologického pokroku.
Nevýhody, s konkrétním příkladem
- Distribuované trasování a protokolování – částečně řešeno pomocí AWS X-Ray a AWS CloudWatch;
- nepohodlné ladění;
- Studený start, když není zátěž;
- Uživatelsky nepřátelské rozhraní AWS je univerzální problém :)
Zdroj: www.habr.com