Serverless lähenemine kiire video teenuse arendamiseks

Ma töötan outsourcena, kus peamine põhimõte on «müü palju, tee kiiresti». Mida kiiremini suudame teha, seda rohkem teenime. Ja soovitavalt peaks kõik toimima mitte kergelt, vaid vastuvõtlikul kvaliteeditasemel. Räägin oma kogemusest, mil tuli lühikese aja jooksul arendada promoteenus.

Antud: root-konto AWS-is, tehnolooge valides pole piiranguid, üks backend arendaja ja kuu arendamiseks.

Ülesanne: rakendada promoteenus, kus kasutajad saavad üles laadida ühe kuni neli videot, mille kestus on ühest nelja sekundini, mis seejärel integreeritakse originaalsesse videovoogu.

Lahendus

Oma teenuse kirjutamine selliste lühikeste tähtaegadega — pole just parim plaan. Lisaks peab teenus taluma koormust ja kõik soovijad saama oma soovitud video, seetõttu on vajalik infrastruktuur. Soovitavalt mitte liiga kallis. Seetõttu keskendume kohe valmislahendusele minimaalse kohandamisega.

Standardne lahendus videoga töötamiseks on FFmpeg, platvormidevaheline konsoolirakendus, mis võimaldab argumentide kaudu nii lõigata kui ka heli lisada. Jääb vaid kirjutada wrapper ja viia see ellu. Kirjutame prototüübi, mis toob kokku kaks videot, ja... algab kõige huvitavam osa. Raamatukogu .NET Core 2, peab töötama igas virtuaalmasinas, seega võtame AWS EC2 instantsi ja kõik töötab.

Peidetud tekstei, see ei tööta.
.
FFmpeg, kuigi lihtsustab ülesannet, vajab tõeliselt toimiva lahenduse jaoks EC2 instantsi loomist ja selle võrguinfrastruktuuri projekteerimist, sealhulgas koormuse jagajat. Lihtne ülesande juurutamine nullist on «veidi» keerulisem, ning infrastruktuur hakkab kohe nõudma raha — iga tund eemaldatakse klientide kontolt summa jooksutamise eest.

Meie teenus ei eelda pikaajalisi protsesse, ei vaja suurt ja mahukat relatsioonilist andmebaasi ning mahub suurepäraselt sündmuste arhitektuuri, kus on mikroteenuste kutsumise ahel. Lahendus tuleb iseenesest — saame loobuda EC2-st ja rakendada tõeliselt serverivaba rakendust, sarnast standardset Image Resizer AWS Lambda baasil.

Muide, kuigi AWS arendajatel on selge antipaatia .NETi vastu, toetavad nad .NET Core 2.1 jooksutajana, mis annab kõik arendamise võimalused.

Ja lõpetuseks — AWS pakub eraldi teenust videofailidega töötamiseks — AWS Elemental MediaConvert.

Töö olemus on uskumatult lihtne: võtame S3 lingi lähtevideole, kirjutame AWS Console'i, .NET SDK-s või lihtsalt JSON-is, mida soovime videoga teha, ja kutsume teenuse. See ise haldab sisendküsimuste töötlemiseks järjekordi, laadib tulemuse automaatselt S3 ja, mis kõige tähtsam, genereerib iga staatuse muutuse jaoks CloudWatch Event. See võimaldab meil rakendada lambdate trikke video töötlemise lõpetamiseks.

Nii näeb välja lõplik arhitektuuri variant.

Kogu backend on paigutatud kahte lambdasse. Veel üks on vertikaalsete videote pööramiseks, kuna sellist tööd ei saa teostada ühe käiguga.

Front-end SPA-rakenduse kujul, kirjutatud JS-is ja kompileeritud läbi pug, paneme avalikku S3 korvi. Videote üleslaadimiseks ei vaja me mingit serveripoolset koodi — piisab, kui avada S3 poolt pakutavad REST-lõpp-punktid. Ainus punkt — ärge unustage seadistada poliitikaid ja CORS-i.

Peidetud probleemid

• AWS MediaConvert, mingil tunmatu põhjusel, lisab heli ainult iga videolõigu peale eraldi, kuigi vajalik on lõbus laul, mis käivitub koos sissejuhatusega.
• Vertikaalid videod tuleb töödelda eraldi. AWS ei värava mustade ribade ja paneb videod 90°.

Lihtne mure.

Hoolimata kogu Statelessi ilust, on vajalik jälgida, mida video tegemiseks teha: kas liita või lisada heli juba valmis videopildile. Õnneks toetab MediaConvert metainformatsiooni edastamist oma Tööde kaudu, ja me saame alati rakendada lihtsa lipu, näiteks “isMasterSoundJob”, need metainformatsioonid eristades igal etapil.

Serverless võimaldab suurepäraselt töötada NoOps'i lähenemisviisiga — meetod, mis välistab eraldi meeskonna vajaduse, kes vastutab projekti infrastruktuuri eest. Nii et asi oli kerge — juurutame lahenduse AWS-is ilma süsteemiadminnide osaluseta, kellel alati on muud toimetused.
Ja et seda kõike kiirendada, maksimaalselt automatiseerime juurutamise AWS CloudFormation'i skripti kaudu, võimaldades juurutamist ühe nupuvajutusega otse VS-st. Lõpuks, 200 rea koodi fail võimaldab välja anda valmis lahenduse, kuigi CloudFormation'i süntaks võib harjumatus olukorras šokeerida.

Kokku

Serverless — ei ole paanitse. Kuid see lihtsustab elu olukordades, kus on kolm limiiti: «piiratud ressursid — lühike tähtaeg — vähe raha».

Rakenduste omadused, millele Serverless sobib.

• ilma Long-Running protsessidest. API Gateway'i karm piir on 29 sekundit, lambdade karm piir on 5 minutit;
• kirjeldatakse Event-Driven arhitektuuriga;
• jagatakse madala seotuse komponentideks, nagu SOA;
• ei nõua suurt tööd oma olekuga;
• kirjutatud .NET Core'is. .NET Framework'i jaoks on endiselt vajalik vähemalt Docker koos vastava jooksukeskkonnaga.

Serverless lähenemise eelised

• vähendab infrastruktuuri kulusid;
• vähendab lahenduse tarnimise kulusid;
• automaatne skaaleerimine;
• arendus tehnoloogia tipptasemel.

Puudused, konkreetse näite põhjal

• Jaotatud jälgimine ja logimine - osaliselt lahendatav AWS X-Ray ja AWS CloudWatch kaudu;
• ebamugav silumine;
• Cold Start ilma koormuseta;
• Kasutajale ebasõbralik AWS liides - universaalne probleem 🙂

Allikas: habr.com