Serverivaba lähenemine toimiva videoteenuse kiireks arendamiseks

Serverivaba lähenemine toimiva videoteenuse kiireks arendamiseks

Töötan allhanke alal, kus peamist põhimõtet saab kirjeldada väljendiga “müü palju, tee kiiresti”. Mida kiiremini me seda teeme, seda rohkem teenime. Ja on soovitav, et kõik ei töötaks karkudel ja tatt, vaid vastuvõetaval kvaliteeditasemel. Räägin teile oma kogemusest, kui oli vaja lühikese aja jooksul välja töötada reklaamiteenus.

Arvestades: juurkonto AWS-is, tehnoloogiapinu valikul pole piiranguid, üks taustaprogramm ja üks kuu arendamiseks.

Ülesanne: rakendama reklaamiteenust, kus kasutajad laadivad üles üks kuni neli videot, mis kestavad üks kuni neli sekundit, mis seejärel manustatakse algsesse videosarja.

otsus

Oma jalgrattateenuse kirjutamine nii lühikese ajaga ei ole hea mõte. Lisaks on selleks, et teenus koormusega toime tuleks ja kõik ihaldatud video kätte saaksid, vaja infrastruktuuri. Ja soovitavalt mitte lennuki hinnasildiga. Seetõttu keskendume koheselt minimaalse kohandamisega valmislahendustele.

Standardlahendus videoga töötamiseks on FFmpeg, platvormideülene konsooliutiliit, mis võimaldab argumentide kaudu heli kärpida ja üle dubleerida. Jääb üle vaid ümbris kirjutada ja see ellu lasta. Kirjutame prototüübi, mis liidab kaks videot kokku ja... lõbus algab. Teek põhineb .NET Core 2-l, see peaks töötama mis tahes virtuaalmasinas, nii et võtame AWS EC2 eksemplari ja kõik töötab

Varjatud tekstei, see ei tööta
.
Kuigi FFmpeg lihtsustab ülesannet, peate tõeliselt toimiva lahenduse jaoks looma EC2 eksemplari ja kavandama selle jaoks võrguinfrastruktuuri, sealhulgas koormuse tasakaalustaja. Lihtne nullist juurutamise ülesanne muutub "natuke" keerulisemaks ja infrastruktuur hakkab kohe raha nõudma - iga tund võetakse kliendikontolt käitusaja summa.

Meie teenus ei hõlma pikaajalisi protsesse, ei nõua suurt ja paksu relatsiooniandmebaasi ning sobib suurepäraselt sündmusepõhisesse arhitektuuri koos mikroteenusekõnede ahelaga. Lahendus soovitab ennast – saame loobuda EC2-st ja juurutada tõelise serverita rakenduse, nagu tavaline AWS Lambdal põhinev Image Resizer.

Muide, hoolimata AWS-i arendajate ilmsest vastumeelsusest .NET-i vastu, toetavad nad käituskeskkonnana .NET Core 2.1, mis pakub kõiki arendusvõimalusi.

Ja kirss tordil – AWS pakub videofailidega töötamiseks eraldi teenust – AWS Elemental MediaConvert.

Töö olemus on uskumatult lihtne: võtame S3 lingi väljuvale videole, kirjutame AWS-konsooli, .NET SDK või lihtsalt JSON-i kaudu, mida videoga teha tahame, ja helistame teenusesse. See ise rakendab sissetulevate päringute töötlemiseks järjekordi, laadib tulemuse ise S3-sse ja mis kõige tähtsam, genereerib iga olekumuudatuse jaoks CloudWatchi sündmuse. See võimaldab meil videotöötluse lõpuleviimiseks rakendada lambda-päästikuid.

Serverivaba lähenemine toimiva videoteenuse kiireks arendamiseks
Lõplik arhitektuur näeb välja selline:

Kogu tagaosa on paigutatud kahte lambdasse. Teine on vertikaalsete videote pööramiseks, kuna sellist tööd ei saa ühe käiguga teha.

Esikülje paneme JS-is kirjutatud ja mopsi kaudu koostatud SPA-rakenduse kujul avalikku S3 ämbrisse. Videote endi allalaadimiseks ei vaja me serverikoodi – peame lihtsalt avama REST-i lõpp-punktid, mida S3 meile pakub. Ainus asi on see, et ärge unustage poliitikaid ja CORS-i konfigureerida.

Lõksud

  • AWS MediaConvert rakendab teadmata põhjusel heli ainult igale videofragmendile eraldi, kuid vajame rõõmsat laulu kogu ekraanisäästjast.
  • Vertikaalseid videoid tuleb eraldi töödelda. AWS-ile ei meeldi mustad ribad ja see paneb rullid 90° nurga alla.

Lihtne liuväli

Vaatamata kogu Statelessi ilule, peate jälgima, mida videoga teha tuleb: liimida või lisada valmis videosarjale heli. Õnneks toetab MediaConvert metaandmete edastamist oma Jobsi kaudu ja me saame alati kasutada lihtsat lippu kujul „isMasterSoundJob”, analüüsides neid metaandmeid igal etapil.

Serverita võimaldab suurepäraselt töötada NoOpsiga – lähenemine, mis eeldab projekti infrastruktuuri eest vastutava eraldi meeskonna tarbetust. Seetõttu oli tegemist väikese asjaga – juurutasime lahenduse AWS-is ilma süsteemiadministraatorite osaluseta, kellel on nagunii alati midagi teha.
Ja kõige selle kiirendamiseks automatiseerime juurutusskripti nii palju kui võimalik AWS CloudFormationis, mis võimaldab juurutada ühe nupuga otse VS-ist. Selle tulemusel võimaldab 200 koodirida sisaldav fail valmis lahenduse välja rullida, kuigi CloudFormationi süntaks võib olla šokeeriv, kui te pole sellega harjunud.

Kogusummas

Serverita pole imerohi. Kuid see muudab elu palju lihtsamaks kolme piiranguga olukordades: "piiratud ressursid - lühiajaline - vähe raha."

Serverita jaoks sobivate rakenduste omadused

  • ilma pikaajaliste protsessideta. API Gateway kõva limiit on 29 sekundit, lambda kõva limiit on 5 minutit;
  • mida kirjeldab Event-Driven arhitektuur;
  • laguneb lõdvalt seotud komponentideks nagu SOA;
  • ei nõua teie seisundiga palju tööd;
  • kirjutatud .NET Core'is. NET Frameworkiga töötamiseks vajate siiski vähemalt Dockerit, millel on sobiv käitusaeg.

Serverita lähenemisviisi eelised

  • vähendab infrastruktuuri kulusid;
  • vähendab lahenduse kohaletoimetamise kulusid;
  • automaatne skaleeritavus;
  • areng tehnoloogilise progressi tipptasemel.

Puudused, konkreetse näitega

  • Hajutatud jälgimine ja logimine – osaliselt lahendatud AWS X-Ray ja AWS CloudWatchi kaudu;
  • ebamugav silumine;
  • Külmkäivitus, kui koormust pole;
  • AWS-i kasutajavaenulik liides on universaalne probleem :)

Allikas: www.habr.com

Lisa kommentaar