Radim u outsourcingu, gdje se glavni princip može opisati frazom „prodaj puno, uradi to brzo“. Što brže to uradimo, više ćemo zaraditi. I poželjno je da sve radi ne na štakama i šmrkama, već na prihvatljivom nivou kvalitete. Ispričat ću vam svoje iskustvo kada je bilo potrebno razviti promotivnu uslugu u kratkom vremenskom periodu.
S obzirom: root nalog na AWS-u, bez ograničenja u izboru tehnološkog steka, jedan backend i jedan mjesec za razvoj.
Zadatak: implementirati promotivnu uslugu gdje korisnici postavljaju od jednog do četiri videa u trajanju od jedne do četiri sekunde, koji se zatim ugrađuju u originalni video seriju.
odluka
Pisanje vlastitog servisa za bicikle u tako kratkom vremenu nije dobra ideja. Osim toga, da bi usluga mogla da se nosi sa opterećenjem i da bi svi dobili željeni video, bit će potrebna infrastruktura. I po mogućnosti ne sa cijenom iz aviona. Stoga se odmah fokusiramo na gotova rješenja s minimalnim prilagođavanjem.
Standardno rješenje za rad sa videom je FFmpeg, višeplatformski konzolni uslužni program koji vam, kroz argumente, omogućava da izrežete i presnimavate audio. Sve što je preostalo je da napišete omot i pustite ga u život. Pišemo prototip koji spaja dva videa i... zabava počinje. Biblioteka je bazirana na .NET Core 2, trebalo bi da radi na bilo kojoj virtuelnoj mašini, tako da uzimamo AWS EC2 instancu i sve će raditi
Skriveni tekstne, neće raditi
.
Iako FFmpeg pojednostavljuje zadatak, za stvarno funkcionalno rješenje morate kreirati EC2 instancu i dizajnirati mrežnu infrastrukturu za nju, uključujući Load Balancer. Jednostavan zadatak implementacije od nule postaje "malo" složeniji, a infrastruktura odmah počinje tražiti novac - svaki sat se iznos za vrijeme rada povlači sa klijentskog računa.
Naša usluga ne uključuje dugotrajne procese, ne zahtijeva veliku i masnu relacionu bazu podataka i savršeno se uklapa u arhitekturu zasnovanu na događajima sa lancem poziva mikroservisa. Rješenje se nameće samo od sebe - možemo napustiti EC2 i implementirati aplikaciju istinski bez servera, kao što je standardni Image Resizer baziran na AWS Lambda.
Usput, uprkos očiglednoj nesklonosti AWS programera prema .NET-u, oni podržavaju .NET Core 2.1 kao runtime, što pruža čitav niz razvojnih mogućnosti.
I trešnja na torti - AWS pruža zasebnu uslugu za rad sa video datotekama - AWS Elemental MediaConvert.
Suština posla je neverovatno jednostavna: uzimamo S3 link na odlazni video, pišemo preko AWS konzole, .NET SDK ili jednostavno JSON šta želimo da uradimo sa videom i pozivamo servis. On sam implementira redove za obradu dolaznih zahtjeva, učitava rezultat u sam S3 i, što je najvažnije, generiše CloudWatch događaj za svaku promjenu statusa. Ovo nam omogućava da implementiramo lambda okidače za završetak video obrade.
Ovako izgleda konačna arhitektura:
Cijeli backend je smješten u dvije lambda. Drugi je za rotiranje vertikalnih videa, jer se takav posao ne može obaviti u jednom prolazu.
Prednji dio ćemo postaviti u obliku SPA aplikacije napisane na JS-u i kompajlirane putem pug-a u javnu S3 kantu. Da preuzmemo same video zapise, ne treba nam nikakav serverski kod - samo trebamo otvoriti REST krajnje tačke koje nam S3 pruža. Jedina stvar je da ne zaboravite konfigurirati politike i CORS.
zamke
- AWS MediaConvert iz nepoznatog razloga samo primjenjuje zvuk na svaki video fragment posebno, ali nam je potrebna vesela pjesma iz cijelog screensavera.
- Vertikalne video zapise treba obraditi zasebno. AWS ne voli crne trake i postavlja valjke na 90°.
Lako klizalište
Unatoč svoj ljepoti Stateless-a, morate pratiti ono što treba učiniti sa videom: zalijepiti ili dodati audio u gotovu video sekvencu. Srećom, MediaConvert podržava prosljeđivanje metapodataka kroz svoje poslove i uvijek možemo koristiti jednostavnu zastavicu u obliku “isMasterSoundJob”, analizirajući ove metapodatke u bilo kojoj fazi.
Serverless savršeno omogućava rad sa NoOps - pristupom koji pretpostavlja nepotrebnost posebnog tima odgovornog za infrastrukturu projekta. Dakle, bila je mala stvar - rešenje postavljamo na AWS bez učešća sistem administratora, koji ionako uvek imaju šta da rade.
A da bismo sve ovo ubrzali, automatizovali smo skriptu za implementaciju na AWS CloudFormation što je više moguće, omogućavajući vam da implementirate jednim dugmetom direktno iz VS. Kao rezultat toga, datoteka od 200 linija koda vam omogućava da izbacite gotovo rješenje, iako CloudFormation sintaksa može biti šokantna ako niste navikli na nju.
Ukupno
Bez servera nije panaceja. Ali to će znatno olakšati život u situacijama s tri ograničenja: „ograničeni resursi – kratkoročno – malo novca”.
Karakteristike aplikacija pogodnih za servere
- bez dugotrajnih procesa. Hard limit API Gateway-a je 29 sekundi, lambda hard limit je 5 minuta;
- opisano Event-Driven arhitekturom;
- razlaže se na labavo povezane komponente kao što je SOA;
- ne zahtijeva puno rada s vašim stanjem;
- napisano u .NET Core. Da biste radili sa .NET Frameworkom, i dalje će vam trebati barem Docker s odgovarajućim runtime-om.
Prednosti pristupa bez servera
- smanjuje troškove infrastrukture;
- smanjuje troškove isporuke rješenja;
- automatska skalabilnost;
- razvoj na vrhuncu tehnološkog napretka.
Nedostaci, sa konkretnim primjerom
- Distribuirano praćenje i evidentiranje - djelimično riješeno putem AWS X-Ray i AWS CloudWatch;
- nezgodno otklanjanje grešaka;
- Hladni start kada nema opterećenja;
- AWS korisnički neprijateljski interfejs je univerzalni problem :)
izvor: www.habr.com