Ik werk in de outsourcing, waar het hoofdprincipe kan worden omschreven met de zinsnede “verkoop veel, doe het snel.” Hoe sneller we het doen, hoe meer we zullen verdienen. En het is wenselijk dat alles niet op krukken en snot werkt, maar met een acceptabel kwaliteitsniveau. Ik zal u vertellen over mijn ervaring toen het nodig was om in korte tijd een promotiedienst te ontwikkelen.
gegeven: root-account op AWS, geen beperkingen op de keuze van de technologiestack, één backend en één maand voor ontwikkeling.
doelstelling: een promotiedienst implementeren waarbij gebruikers één tot vier video's van één tot vier seconden uploaden, die vervolgens worden ingebed in de originele videoserie.
beslissing
In zo'n korte tijd een eigen fietsservice schrijven is geen goed idee. Om ervoor te zorgen dat de dienst de belasting aankan en iedereen de felbegeerde video kan ontvangen, is er bovendien infrastructuur nodig. En liefst niet met het prijskaartje uit het vliegtuig. Daarom focussen wij direct op kant-en-klare oplossingen met minimaal maatwerk.
De standaardoplossing voor het werken met video is FFmpeg, een platformonafhankelijk consolehulpprogramma waarmee je via argumenten audio kunt knippen en overdubben. Het enige dat u nog hoeft te doen, is een verpakking schrijven en deze tot leven brengen. We schrijven een prototype dat twee video's aan elkaar plakt, en... het plezier begint. De bibliotheek is gebaseerd op .NET Core 2 en zou op elke virtuele machine moeten draaien, dus we nemen een AWS EC2-instantie en alles zal werken
Verborgen tekstnee, het zal niet werken
.
Hoewel FFmpeg de taak vereenvoudigt, moet je voor een echt werkende oplossing een EC2-instantie maken en daarvoor een netwerkinfrastructuur ontwerpen, inclusief een Load Balancer. De eenvoudige taak om helemaal opnieuw te implementeren wordt “een beetje” ingewikkelder en de infrastructuur begint onmiddellijk geld te eisen - elk uur wordt het bedrag voor runtime van de klantaccount afgeschreven.
Onze dienstverlening omvat geen langlopende processen, vereist geen grote en dikke relationele database en past perfect in een event-gebaseerde architectuur met een keten van microservice-aanroepen. De oplossing doet zich voor: we kunnen EC2 verlaten en een echte serverloze applicatie implementeren, zoals de standaard Image Resizer gebaseerd op AWS Lambda.
Trouwens, ondanks de duidelijke afkeer van AWS-ontwikkelaars voor .NET, ondersteunen ze .NET Core 2.1 als runtime, wat een volledig scala aan ontwikkelingsmogelijkheden biedt.
En als kers op de taart biedt AWS een aparte dienst voor het werken met videobestanden: AWS Elemental MediaConvert.
De essentie van het werk is ongelooflijk eenvoudig: we nemen een S3-link naar de uitgaande video, schrijven via AWS Console, .NET SDK of gewoon JSON wat we met de video willen doen en bellen de service. Het implementeert zelf wachtrijen voor het verwerken van inkomende verzoeken, uploadt het resultaat zelf naar S3 en, belangrijker nog, genereert een CloudWatch Event voor elke statuswijziging. Hierdoor kunnen we lambda-triggers implementeren om de videoverwerking te voltooien.
Zo ziet de uiteindelijke architectuur eruit:
De gehele backend is ondergebracht in twee lambda's. Een andere is voor het roteren van verticale video's, aangezien dergelijk werk niet in één keer kan worden gedaan.
We plaatsen de voorkant in de vorm van een SPA-applicatie geschreven in JS en samengesteld via pug in een openbare S3-bucket. Om de video's zelf te downloaden, hebben we geen servercode nodig. We hoeven alleen maar de REST-eindpunten te openen die S3 ons biedt. Het enige is dat u niet vergeet beleid en CORS te configureren.
Valkuilen
- AWS MediaConvert past om onbekende reden alleen geluid toe op elk videofragment afzonderlijk, maar we hebben een vrolijk liedje nodig van de hele screensaver.
- Verticale video's moeten afzonderlijk worden verwerkt. AWS houdt niet van zwarte balken en zet de rollen op 90°.
Gemakkelijke ijsbaan
Ondanks al het moois van Stateless moet je bijhouden wat er met de video moet gebeuren: lijm of voeg audio toe aan de voltooide videosequentie. Gelukkig ondersteunt MediaConvert het doorgeven van metadata via zijn Jobs, en we kunnen altijd een eenvoudige vlag van de vorm “isMasterSoundJob” gebruiken, waarmee we deze metadata in elk stadium kunnen parseren.
Serverless maakt het werken met NoOps perfect mogelijk - een aanpak die uitgaat van de onnodigheid van een apart team dat verantwoordelijk is voor de projectinfrastructuur. Daarom was het een kleine zaak: we implementeren de oplossing op AWS zonder de deelname van systeembeheerders, die toch altijd iets te doen hebben.
En om dit allemaal te versnellen automatiseren we het deployment script zoveel mogelijk op AWS CloudFormation, waardoor je met één knop direct vanuit VS kunt implementeren. Met een bestand van 200 regels code kun je daardoor een kant-en-klare oplossing uitrollen, al kan de syntaxis van CloudFormation schokkend zijn als je er niet aan gewend bent.
In totaal
Serverloos is geen wondermiddel. Maar het zal het leven veel gemakkelijker maken in situaties met drie beperkingen: “beperkte middelen – korte termijn – weinig geld.”
Kenmerken van applicaties geschikt voor serverless
- zonder langlopende processen. De harde limiet van API Gateway is 29 seconden, de harde limiet van Lambda is 5 minuten;
- beschreven door Event-Driven-architectuur;
- valt uiteen in losjes gekoppelde componenten zoals SOA;
- vereist niet veel werk met uw toestand;
- geschreven in .NET Core. Om met het .NET Framework te werken heb je nog steeds minimaal Docker met de juiste runtime nodig.
Voordelen van de serverloze aanpak
- verlaagt de infrastructuurkosten;
- verlaagt de kosten voor het leveren van de oplossing;
- automatische schaalbaarheid;
- ontwikkeling die zich op het snijvlak van de technologische vooruitgang bevindt.
Nadelen, met een specifiek voorbeeld
- Gedistribueerde tracering en logboekregistratie - gedeeltelijk opgelost via AWS X-Ray en AWS CloudWatch;
- lastig debuggen;
- Koude start wanneer er geen belasting is;
- AWS-gebruikersvijandige interface is een universeel probleem :)
Bron: www.habr.com