Trabalho com terceirização, onde o princípio fundamental pode ser descrito pela frase “venda muito, faça rápido”. Quanto mais rápido fizermos isso, mais ganharemos. E é desejável que tudo funcione não com muletas e ranho, mas com um nível de qualidade aceitável. Contarei a vocês minha experiência quando foi necessário desenvolver um serviço promocional em um curto espaço de tempo.
Dado: conta root na AWS, sem restrições na escolha da pilha de tecnologia, um back-end e um mês para desenvolvimento.
Tarefa: implementar um serviço promocional onde os usuários enviam de um a quatro vídeos com duração de um a quatro segundos, que são então incorporados à série de vídeos original.
Solução
Escrever seu próprio serviço de bicicletas em tão pouco tempo não é uma boa ideia. Além disso, para que o serviço dê conta da carga e todos recebam o cobiçado vídeo, será necessária infraestrutura. E de preferência não com a etiqueta do preço do avião. Portanto, focamos imediatamente em soluções prontas com o mínimo de customização.
A solução padrão para trabalhar com vídeo é o FFmpeg, um utilitário de console multiplataforma que, por meio de argumentos, permite cortar e fazer overdub de áudio. Tudo o que resta fazer é escrever um invólucro e lançá-lo à vida. Escrevemos um protótipo que une dois vídeos e... a diversão começa. A biblioteca é baseada em .NET Core 2, deve rodar em qualquer máquina virtual, então pegamos uma instância AWS EC2 e tudo funcionará
Texto ocultonão, não vai funcionar
.
Embora o FFmpeg simplifique a tarefa, para uma solução realmente funcional você precisa criar uma instância EC2 e projetar uma infraestrutura de rede para ela, incluindo um Load Balancer. A simples tarefa de implantar do zero torna-se “um pouco” mais complicada, e a infraestrutura começa a exigir dinheiro imediatamente – a cada hora o valor do tempo de execução é retirado da conta do cliente.
Nosso serviço não envolve processos de longa duração, não requer um banco de dados relacional grande e denso e se encaixa perfeitamente em uma arquitetura baseada em eventos com uma cadeia de chamadas de microsserviços. A solução surge por si mesma - podemos abandonar o EC2 e implementar um aplicativo verdadeiramente sem servidor, como o Image Resizer padrão baseado no AWS Lambda.
A propósito, apesar da óbvia antipatia dos desenvolvedores da AWS pelo .NET, eles suportam o .NET Core 2.1 como tempo de execução, o que oferece uma gama completa de oportunidades de desenvolvimento.
E a cereja do bolo - a AWS fornece um serviço separado para trabalhar com arquivos de vídeo - AWS Elemental MediaConvert.
A essência do trabalho é incrivelmente simples: pegamos um link S3 para o vídeo de saída, escrevemos através do Console AWS, .NET SDK ou simplesmente JSON o que queremos fazer com o vídeo e chamamos o serviço. Ele próprio implementa filas para processar solicitações recebidas, carrega o resultado no próprio S3 e, o mais importante, gera um evento CloudWatch para cada mudança de status. Isso nos permite implementar gatilhos lambda para concluir o processamento de vídeo.
Esta é a aparência da arquitetura final:
Todo o back-end está alojado em dois lambdas. Outra é para girar vídeos verticais, já que tal trabalho não pode ser feito de uma só vez.
Colocaremos o front na forma de uma aplicação SPA escrita em JS e compilada via pug em um bucket S3 público. Para baixar os vídeos, não precisamos de nenhum código de servidor - só precisamos abrir os endpoints REST que o S3 nos fornece. A única coisa é não se esquecer de configurar políticas e CORS.
Armadilhas
- O AWS MediaConvert, por algum motivo desconhecido, aplica som apenas a cada fragmento de vídeo separadamente, mas precisamos de uma música alegre de todo o protetor de tela.
- Vídeos verticais precisam ser processados separadamente. AWS não gosta de barras pretas e coloca os rolos em 90°.
Pista de patinação fácil
Apesar de toda a beleza do Stateless, você precisa acompanhar o que precisa ser feito com o vídeo: colar ou adicionar áudio à sequência de vídeo finalizada. Felizmente, o MediaConvert suporta a passagem de metadados por meio de seus trabalhos, e sempre podemos usar um sinalizador simples no formato “isMasterSoundJob”, analisando esses metadados em qualquer estágio.
Serverless permite perfeitamente trabalhar com NoOps - uma abordagem que pressupõe a inutilidade de uma equipe separada responsável pela infraestrutura do projeto. Portanto, foi uma questão pequena - implantamos a solução na AWS sem a participação de administradores de sistema, que sempre têm algo para fazer de qualquer maneira.
E para agilizar tudo isso, automatizamos ao máximo o script de implantação no AWS CloudFormation, que permite implantar com um botão diretamente do VS. Como resultado, um arquivo de 200 linhas de código permite implementar uma solução pronta, embora a sintaxe do CloudFormation possa ser chocante se você não estiver acostumado com ela.
No total
Sem servidor não é uma panacéia. Mas tornará a vida muito mais fácil em situações com três limites: “recursos limitados – curto prazo – pouco dinheiro”.
Características de aplicativos adequados para serverless
- sem processos de longa duração. O limite rígido do API Gateway é de 29 segundos, o limite rígido do lambda é de 5 minutos;
- descrito pela arquitetura orientada a eventos;
- se divide em componentes fracamente acoplados, como SOA;
- não requer muito trabalho com sua condição;
- escrito em .NET Core. Para trabalhar com o .NET Framework, você ainda precisará de pelo menos o Docker com o tempo de execução apropriado.
Benefícios da abordagem sem servidor
- reduz custos de infraestrutura;
- reduz o custo de entrega da solução;
- escalabilidade automática;
- desenvolvimento na vanguarda do progresso tecnológico.
Desvantagens, com um exemplo específico
- Rastreamento e registro distribuídos - parcialmente resolvidos por meio do AWS X-Ray e do AWS CloudWatch;
- depuração inconveniente;
- Cold Start quando não há carga;
- A interface hostil ao usuário da AWS é um problema universal :)
Fonte: habr.com