Pristop brez strežnika za hiter razvoj delujoče video storitve

Pristop brez strežnika za hiter razvoj delujoče video storitve

Delam v zunanjem izvajanju, kjer je glavno načelo mogoče opisati s frazo »prodaj veliko, naredi to hitro«. Hitreje kot to storimo, več bomo zaslužili. In zaželeno je, da vse deluje ne na berglah in smrklji, ampak na sprejemljivi ravni kakovosti. Povedal vam bom svojo izkušnjo, ko je bilo treba v kratkem času razviti promocijsko storitev.

Glede na: root račun na AWS, brez omejitev glede izbire tehnološkega sklada, en backend in en mesec za razvoj.

Naloga: izvajati promocijsko storitev, kjer uporabniki naložijo od enega do štiri videoposnetke v trajanju od ene do štirih sekund, ki so nato vdelani v izvirno video serijo.

odločitev

Napisati lasten kolesarski servis v tako kratkem času ni dobra ideja. Poleg tega bo potrebna infrastruktura, da bo storitev obvladala obremenitev in da bodo vsi prejeli želeni video. In po možnosti ne s ceno iz letala. Zato se takoj osredotočimo na že pripravljene rešitve z minimalnimi prilagoditvami.

Standardna rešitev za delo z videom je FFmpeg, konzolni pripomoček za več platform, ki vam prek argumentov omogoča rezanje in presnemavanje zvoka. Vse kar morate storiti je, da napišete ovoj in ga sprostite v življenje. Napišemo prototip, ki združi dva videoposnetka in ... zabava se začne. Knjižnica temelji na .NET Core 2, izvajati bi se morala na katerem koli virtualnem stroju, zato vzamemo primerek AWS EC2 in vse bo delovalo

Skrito besedilone, ne bo šlo
.
Čeprav FFmpeg poenostavi nalogo, morate za resnično delujočo rešitev ustvariti primerek EC2 in zanj oblikovati omrežno infrastrukturo, vključno z izravnalnikom obremenitve. Preprosta naloga uvajanja iz nič postane "malo" bolj zapletena in infrastruktura začne takoj zahtevati denar - vsako uro se znesek za čas izvajanja dvigne z računa stranke.

Naša storitev ne vključuje dolgotrajnih procesov, ne zahteva velike in debele relacijske baze podatkov in se popolnoma prilega arhitekturi, ki temelji na dogodkih, z verigo klicev mikrostoritev. Rešitev se kaže sama od sebe – lahko opustimo EC2 in implementiramo resnično brezstrežniško aplikacijo, kot je standardni Image Resizer, ki temelji na AWS Lambda.

Mimogrede, kljub očitnemu nenaklonjenosti razvijalcev AWS do .NET podpirajo .NET Core 2.1 kot runtime, ki ponuja celotno paleto razvojnih priložnosti.

In češnja na torti - AWS ponuja ločeno storitev za delo z video datotekami - AWS Elemental MediaConvert.

Bistvo dela je neverjetno preprosto: vzamemo povezavo S3 do odhodnega videa, prek konzole AWS, .NET SDK ali preprosto JSON napišemo, kaj želimo narediti z videom in pokličemo storitev. Sam implementira čakalne vrste za obdelavo dohodnih zahtevkov, sam naloži rezultat v S3 in, kar je najpomembnejše, ustvari CloudWatch Event za vsako spremembo statusa. To nam omogoča implementacijo lambda sprožilcev za dokončanje video obdelave.

Pristop brez strežnika za hiter razvoj delujoče video storitve
Tako izgleda končna arhitektura:

Celotno zaledje je nameščeno v dveh lambdah. Druga je za vrtenje navpičnih videov, saj takega dela ni mogoče opraviti v enem prehodu.

Prednjo stran bomo postavili v obliki aplikacije SPA, napisane v JS in prevedene prek pug v javno vedro S3. Za prenos samih videoposnetkov ne potrebujemo nobene strežniške kode - samo odpreti moramo končne točke REST, ki nam jih ponuja S3. Edina stvar je, da ne pozabite konfigurirati pravilnikov in CORS.

Pasti

  • AWS MediaConvert iz neznanega razloga uporablja samo zvok za vsak video del posebej, vendar potrebujemo veselo pesem iz celotnega ohranjevalnika zaslona.
  • Navpične videoposnetke je treba obdelati ločeno. AWS ne mara črnih črt in postavi valje na 90°.

Enostavno drsališče

Kljub vsej lepoti Statelessa morate spremljati, kaj je treba storiti z videom: prilepiti ali dodati zvok končnemu video zaporedju. Na srečo MediaConvert podpira posredovanje metapodatkov prek svojih opravil in vedno lahko uporabimo preprosto zastavico v obliki »isMasterSoundJob«, ki te metapodatke razčlenimo na kateri koli stopnji.

Brez strežnika odlično omogoča delo z NoOps - pristopom, ki predvideva nepotrebnost ločene ekipe, odgovorne za infrastrukturo projekta. Zato je šlo za malenkost - rešitev namestimo na AWS brez sodelovanja sistemskih skrbnikov, ki imajo tako ali tako vedno kaj početi.
Da bi vse to pospešili, v AWS CloudFormation čim bolj avtomatiziramo skript za uvajanje, kar vam omogoča uvajanje z enim gumbom neposredno iz VS. Posledično vam datoteka z 200 vrsticami kode omogoča, da uvedete že pripravljeno rešitev, čeprav je sintaksa CloudFormation lahko šokantna, če je niste vajeni.

Skupno

Brez strežnika ni zdravilo. Toda življenje bo veliko lažje v situacijah s tremi omejitvami: "omejeni viri - kratkoročno - malo denarja."

Značilnosti aplikacij, primernih za brezstrežniško uporabo

  • brez dolgotrajnih procesov. Trda omejitev API Gateway je 29 sekund, lambda trda omejitev je 5 minut;
  • opisano z arhitekturo, ki temelji na dogodkih;
  • razpade na ohlapno povezane komponente, kot je SOA;
  • ne zahteva veliko dela z vašim stanjem;
  • napisan v .NET Core. Za delo z ogrodjem .NET Framework boste še vedno potrebovali vsaj Docker z ustreznim izvajalnim okoljem.

Prednosti brezstrežniškega pristopa

  • zmanjša stroške infrastrukture;
  • zmanjša stroške dostave rešitve;
  • samodejna razširljivost;
  • razvoj na samem vrhu tehnološkega napredka.

Slabosti, s konkretnim primerom

  • Porazdeljeno sledenje in beleženje – delno rešeno z AWS X-Ray in AWS CloudWatch;
  • neprijetno odpravljanje napak;
  • Hladni zagon, ko ni obremenitve;
  • Uporabniku sovražen vmesnik AWS je univerzalna težava :)

Vir: www.habr.com

Dodaj komentar