Lavoro in outsourcing, dove il principio principale può essere descritto con la frase 'vendi molto, fai in fretta'. Più velocemente facciamo, più guadagniamo. Inoltre, è importante che tutto funzioni senza problemi e con un livello di qualità accettabile. Racconterò della mia esperienza quando, in un breve periodo, è stato necessario sviluppare un servizio promozionale.
Dati: un account root su AWS, senza vincoli nella scelta dello stack tecnologico, un backend developer e un mese per lo sviluppo.
Obiettivo: realizzare un servizio promozionale in cui gli utenti caricano da uno a quattro video, della durata di uno a quattro secondi, che vengono poi integrati nel video originale.
Soluzione
Scrivere il proprio servizio in tempi così ridotti è una pessima idea. Inoltre, affinché il servizio possa gestire i carichi e tutti coloro che desiderano ricevere il video, sarà necessaria un'infrastruttura. E sarebbe meglio che il costo non fosse eccessivo. Quindi ci orientiamo subito verso soluzioni pronte con una personalizzazione minima.
La soluzione standard per il lavoro con video è FFmpeg, un'utility da linea di comando multipiattaforma che consente di tagliare e sovrapporre audio tramite argomenti. Ora bisogna scrivere un wrapper e farlo funzionare. Creiamo un prototipo che unisce due video e… inizia la parte più interessante. La libreria è basata su .NET Core 2 e deve funzionare su qualsiasi virtual machine, quindi prendiamo un'istanza AWS EC2 e tutto funziona.
Testo nascostono, non funzionerà
.
FFmpeg, sebbene semplifichi il compito, richiede di creare un'istanza EC2, progettare l'infrastruttura di rete, inclusi i Load Balancer. Un semplice deployment da zero si complica un po', e l'infrastruttura inizia a richiedere denaro immediatamente — ogni ora si sottrae una somma dal conto del cliente per il runtime.
Il nostro servizio non prevede processi Long-Running, non ha bisogno di un grande e pesante database relazionale e si adatta perfettamente a un'architettura basata su eventi con una catena di chiamate di microservizi. La soluzione sembra ovvia: possiamo rinunciare a EC2 e realizzare un'applicazione true-serverless, simile a standard Image Resizer basata su AWS Lambda.
A proposito, nonostante l'evidente avversione degli sviluppatori AWS per .NET, supportano .NET Core 2.1 come runtime, il che offre un'ampia gamma di possibilità di sviluppo.
E la ciliegina sulla torta: AWS offre un servizio dedicato per lavorare con i file video — AWS Elemental MediaConvert.
Il funzionamento è incredibilmente semplice: prendiamo un link S3 al video originale, tramite la Console AWS, il .NET SDK o semplicemente JSON, specifichiamo cosa vogliamo fare con il video e chiamiamo il servizio. Gestisce autonomamente le code per l'elaborazione delle richieste in arrivo, carica il risultato su S3 e, cosa più importante, genera un evento CloudWatch per ogni cambio di stato. Questo ci consente di implementare trigger Lambda al termine dell'elaborazione video.
Circa così appare la variante finale dell'architettura.
Tutto il backend è ospitato in due Lambda. Un'altra sarà dedicata alla rotazione dei video verticali, poiché tale lavoro non può essere eseguito in un unico passaggio.
Il front-end sarà un'applicazione SPA, scritta in JS e compilata tramite pug, ospitata in un bucket S3 pubblico. Per caricare i video non abbiamo bisogno di alcun codice server; è sufficiente aprire i REST endpoint forniti da S3. L'unico punto importante è non dimenticarsi di configurare le politiche e il CORS.
Problemi inaspettati
- AWS MediaConvert, per qualche ragione sconosciuta, applica l'audio solo a ciascun segmento video separatamente, mentre noi abbiamo bisogno della stessa canzone dall'introduzione.
- I video verticali devono essere elaborati separatamente. AWS non ama le barre nere e ruota i video di 90°.
Facile come bere un bicchier d'acqua.
Nonostante tutta la bellezza dello Stateless, è necessario tenere traccia di cosa deve essere fatto con il video: unire o sovrapporre l'audio al video già pronto. Fortunatamente, MediaConvert supporta il passaggio di metadati tramite i propri Job, e possiamo sempre applicare una semplice flag del tipo 'isMasterSoundJob', eseguendo il parsing di questi metadati in qualsiasi fase.
Serverless consente di lavorare in NoOps — un approccio che implica la mancanza di un team dedicato alla gestione dell'infrastruttura del progetto. Quindi, ci siamo limitati a implementare la soluzione su AWS senza il coinvolgimento di amministratori di sistema, che hanno sempre cose di cui occuparsi.
E per accelerare tutto questo, automatizziamo al massimo il deployment con uno script su AWS CloudFormation, che consente il deployment con un clic direttamente da VS. In definitiva, un file di 200 righe di codice consente di far partire una soluzione pronta, anche se la sintassi di CloudFormation può sorprendere all'inizio.
Totale
Serverless non è una panacea. Ma renderà decisamente più facile la vita in situazioni con tre limiti: 'risorse limitate — breve termine — pochi soldi'.
Caratteristiche delle applicazioni adatte per Serverless.
- senza processi Long-Running. Limite hard dell'API Gateway — 29 secondi, limite hard della lambdas — 5 minuti;
- descritto dall'architettura Event-Driven;
- suddiviso in componenti debolmente accoppiati simili a SOA;
- non richiede un grande lavoro sul proprio stato;
- scritto in .NET Core. Per lavorare con .NET Framework sarà comunque necessario almeno Docker con il runtime appropriato.
Vantaggi dell'approccio Serverless
- riduce i costi per l'infrastruttura;
- riduce i costi per la distribuzione della soluzione;
- scalabilità automatica;
- sviluppo all'avanguardia del progresso tecnico.
Svantaggi, con un esempio specifico
- Tracciamento distribuito e registrazione — risolto parzialmente tramite AWS X-Ray e AWS CloudWatch;
- debugging scomodo;
- Cold Start in assenza di carico;
- Interfaccia ostile per l'utente di AWS — un problema universale 🙂
Fonte: habr.com
