Kontratazioan lan egiten dut, non printzipio nagusia "asko saldu, egin azkar" esaldiarekin deskriba daitekeen. Zenbat eta azkarrago egin, orduan eta gehiago irabaziko dugu. Eta, desiragarria da dena ez makuluetan eta mokoetan funtzionatzea, baizik eta kalitate maila onargarrian. Denbora laburrean promozio-zerbitzu bat garatzea beharrezkoa izan zenean nire esperientzia kontatuko dizuet.
Emana: root kontua AWS-n, teknologia pila aukeratzeko murrizketarik, backend bat eta garapenerako hilabete bat.
Helburua: sustapen-zerbitzu bat ezarri, non erabiltzaileek segundu batetik lau irauten duten bideo batetik lau kargatzen dituzten, ondoren jatorrizko bideo seriean txertatuko direnak.
Erabaki
Zure bizikleta-zerbitzua hain denbora laburrean idaztea ez da ideia ona. Horrez gain, zerbitzuak zamari aurre egiteko eta bideo preziatua denek jaso dezaten, azpiegiturak beharko dira. Eta hobe ez hegazkinaren prezioarekin. Hori dela eta, berehala prestatutako soluzioetara bideratzen gara pertsonalizazio minimoarekin.
Bideoarekin lan egiteko irtenbide estandarra FFmpeg da, argumentuen bidez audioa moztu eta gainkobratzeko aukera ematen duen plataforma anitzeko kontsolaren erabilgarritasuna. Bilgarri bat idatzi eta bizitzara askatzea baino ez da falta. Bi bideo elkartzen dituen prototipo bat idazten dugu, eta... dibertsioa hasten da. Liburutegia .NET Core 2-n oinarritzen da, edozein makina birtualetan exekutatu beharko litzateke, beraz, AWS EC2 instantzia bat hartuko dugu eta dena funtzionatuko du
Ezkutuko testuaez, ez du funtzionatuko
.
FFmpeg-ek zeregina errazten badu ere, benetan funtzionatzen duen konponbide baterako EC2 instantzia bat sortu eta sare-azpiegitura bat diseinatu behar duzu horretarako, Load Balancer bat barne. Hutsetik zabaltzeko zeregin sinplea "pixka bat" zailagoa bihurtzen da, eta azpiegitura berehala dirua eskatzen hasten da - orduro exekuzio-denborarako zenbatekoa bezeroaren kontutik ateratzen da.
Gure zerbitzuak ez ditu Iraupen Luzeko prozesurik inplikatzen, ez du datu-base erlazional handi eta lodirik behar eta ezin hobeto egokitzen da ekitaldietan oinarritutako arkitektura batean, mikrozerbitzuen deien kate batekin. Irtenbideak berak iradokitzen du: EC2 alde batera utzi eta benetako zerbitzaririk gabeko aplikazio bat inplementatu dezakegu, AWS Lambda-n oinarritutako Image Resizer estandarra bezala.
Bide batez, AWS garatzaileei .NET-ri begi-bistakoa ez zaien arren, .NET Core 2.1 onartzen dute exekuzio-denbora gisa, garapen-aukera osoa eskaintzen duena.
Eta pastelaren gerezia - AWS-k zerbitzu berezi bat eskaintzen du bideo-fitxategiekin lan egiteko - AWS Elemental MediaConvert.
Lanaren funtsa izugarri sinplea da: irteerako bideorako S3 esteka bat hartzen dugu, AWS Console, .NET SDK edo, besterik gabe, JSON bidez bideoarekin egin nahi duguna idatzi eta zerbitzura deitzen dugu. Berak, sarrerako eskaerak prozesatzeko ilarak ezartzen ditu, emaitza S3ra kargatzen du eta, batez ere, CloudWatch Gertaera bat sortzen du egoera aldaketa bakoitzeko. Horri esker, lambda abiarazleak inplementatu ditzakegu bideoaren prozesamendua amaitzeko.
Hau da azken arkitekturaren itxura:
Backend osoa bi lambdatan dago. Beste bat bideo bertikalak biratzeko da, lan hori ezin baita pase bakarrean egin.
Aurrealdea JS-n idatzitako eta pug bidez konpilatutako SPA aplikazio baten moduan jarriko dugu S3 ontzi publiko batean. Bideoak beraiek deskargatzeko, ez dugu zerbitzari-koderik behar - S3-k eskaintzen dizkigun REST puntuak ireki besterik ez dugu behar. Gauza bakarra da ez ahaztu politikak eta CORS konfiguratzea.
Pitfalls
- AWS MediaConvert-ek, arrazoi ezezagun batengatik, bideo zati bakoitzari bakarrik aplikatzen dio soinua bereizita, baina pantaila-babesle osoko abesti alai bat behar dugu.
- Bideo bertikalak bereiz prozesatu behar dira. AWS-i ez zaizkio barra beltzak gustatzen eta arrabolak 90°-ra jartzen ditu.
Patinaje pista erraza
Stateless-en edertasun guztia gorabehera, bideoarekin egin beharrekoaren jarraipena egin behar duzu: amaitutako bideo-sekuentziari itsatsi edo audioa gehitu. Zorionez, MediaConvert-ek metadatuak bere Lanbideetatik pasatzea onartzen du, eta "isMasterSoundJob" formako bandera soil bat erabil dezakegu beti, metadatu horiek edozein unetan aztertuz.
Zerbitzaririk gabe ezin hobeto NoOps-ekin lan egitea ahalbidetzen du - proiektuaren azpiegituraz arduratzen den talde bereizi baten beharrik eza suposatzen duen ikuspegia. Hori dela eta, kontu txikia zen: sistema-administratzaileen parte-hartzerik gabe sistema-administratzaileen parte-hartzerik gabe zabaltzen dugu soluzioa, hala ere beti baitute zer egiteko.
Eta hori guztia bizkortzeko, inplementazio-scripta ahalik eta gehien automatizatzen dugu AWS CloudFormation-en, VS-tik zuzenean botoi batekin zabaltzeko aukera ematen duena. Ondorioz, 200 kode lerroko fitxategi batek prest egindako irtenbide bat zabaltzeko aukera ematen du, nahiz eta CloudFormation sintaxia harrigarria izan daitekeen ohituta ez bazaude.
Guztira
Zerbitzaririk gabekoa ez da panazea. Baina bizitza askoz erraztuko du hiru muga dituzten egoeretan: “baliabide mugatuak —epe laburrekoak— diru gutxi”.
Zerbitzaririk gabekoentzako egokiak diren aplikazioen ezaugarriak
- Ibilbide Luzeko prozesurik gabe. API Gateway muga gogorra 29 segundokoa da, lambda muga gogorra 5 minutukoa;
- Gertaerak bultzatutako arkitekturak deskribatzen du;
- SOA bezalako osagai solteetan apurtzen da;
- ez du lan handirik behar zure egoerarekin;
- .NET Core-n idatzita. .NET Framework-ekin lan egiteko, gutxienez Docker beharko duzu exekuzio-denbora egokia duen.
Zerbitzaririk gabeko ikuspegiaren abantailak
- azpiegituren kostuak murrizten ditu;
- irtenbidea emateko kostua murrizten du;
- eskalagarritasun automatikoa;
- garapena aurrerapen teknologikoaren abangoardian.
Desabantailak, adibide zehatz batekin
- Banatutako trazadura eta erregistroa - partzialki AWS X-Ray eta AWS CloudWatch bidez konpondu da;
- arazketa deserosoa;
- Cold Start kargarik ez dagoenean;
- AWS erabiltzaileen aurkako interfazea arazo unibertsala da :)
Iturria: www.habr.com