Abordagem sem servidor para o rápido desenvolvimento de um serviço de vídeo em funcionamento

Eu trabalho em terceirização, onde o princípio principal pode ser descrito com a frase "vender muito, faça rápido". Quanto mais rápido fazemos, mais ganhamos. E, é desejável que tudo não funcione com muletas e ranho, mas com um nível aceitável de qualidade. Contarei minha experiência quando, em pouco tempo, foi necessário desenvolver um serviço promocional.

Fornecido: conta root na AWS, sem restrições na escolha da pilha de tecnologia, um back-end e um mês para desenvolvimento.

Objetivo: implementar um serviço promocional no qual os usuários enviam de um a quatro vídeos com duração de um a quatro segundos, que são incorporados à sequência de vídeos original. Ou seja, substituímos fragmentos do vídeo original (protetor de tela em série) por personalizados. Recurso assassino - a capacidade de enviar seu nome, que na forma de texto bonito sobrepõe o fragmento de vídeo correspondente. Além disso, o usuário pode fazer upload de um vídeo de 4 a 30 segundos e, no lado do serviço, ele será aparado para 4 segundos.

Solução

Escrever o seu serviço de bicicleta em um prazo tão curto é uma ideia. Além disso, para que o serviço possa lidar com as cargas e com todos que desejam receber o vídeo cobiçado, será necessária a infraestrutura. E de preferência não com um preço do avião. Portanto, focamos imediatamente em soluções prontas com personalização mínima.

A solução padrão para trabalhar com vídeo é o FFmpeg, um utilitário de console de plataforma cruzada que, através de argumentos, permite cortar e sobrepor sons. O pequeno é escrever um invólucro e colocá-lo em prática. Estamos escrevendo um protótipo que reúne dois vídeos e ... a diversão começa. A biblioteca do .NET Core 2 deve girar em qualquer máquina virtual, portanto, pegamos a instância do AWS EC2 e tudo funcionará


O FFmpeg, embora simplifique a tarefa, mas para uma solução realmente funcional, você precisa criar uma instância do EC2, crie uma infraestrutura de rede para ela, incluindo o Load Balancer. A tarefa simples de implantar do zero é "um pouco" complicada e a infraestrutura começa a exigir dinheiro imediatamente - o valor do tempo de execução é retirado da conta do cliente a cada hora.

Nosso serviço não envolve processos de execução longa, não requer um banco de dados relacional grande e arrojado e se encaixa perfeitamente na arquitetura do evento com uma cadeia de chamadas de microsserviço. A solução se sugere - podemos abandonar o EC2 e implementar um aplicativo sem servidor de verdade, como o Image Resizer padrão baseado no AWS Lambda.

A propósito, apesar da óbvia aversão dos desenvolvedores da AWS para .NET, eles oferecem suporte ao .NET Core 2.1 como um 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 o link S3 para o vídeo enviado, por meio do AWS Console, .NET SDK ou apenas JSON, escrevemos o que queremos fazer com o vídeo e chamamos o serviço. Ele próprio implementa as filas para processar solicitações recebidas, descarrega o resultado no S3 e, o mais importante, gera um Evento CloudWatch para cada alteração de status. Isso nos permite implementar gatilhos lambda para concluir o processamento de vídeo.


A versão final da arquitetura se parece com isso

Todo o back-end é colocado em duas lambdas. Outra é a rotação de vídeos verticais, pois esse trabalho não pode ser realizado de uma só vez.

A sobreposição de texto foi feita renderizando uma imagem transparente rapidamente, de acordo com a resolução do vídeo. A biblioteca SixLabors.ImageSharp é perfeita para essa finalidade, e os problemas de vazamento de memória ignoram elegantemente o ciclo de vida do lambda.

A frente na forma de um aplicativo SPA escrito em JS e compilado via pug será colocado na cesta S3 pública. Para baixar os vídeos, não precisamos de nenhum código de servidor - basta abrir os pontos de extremidade REST que o S3 nos oferece. A única coisa - não se esqueça de configurar políticas e CORS.

Armadilhas

• O AWS MediaConvert, por algum motivo desconhecido, impõe som apenas a cada videoclipe individualmente, e precisamos de uma música fervorosa de todo o protetor de tela.
• vídeos verticais precisam ser processados ​​separadamente. A AWS não gosta de listras pretas e coloca os roletes a 90 °.

Pista fácil

Apesar da beleza do Stateless, você precisa acompanhar o que precisa ser feito com o vídeo: cola ou sobreposição de som em uma sequência de vídeos já concluída. Felizmente, o MediaConvert suporta a transferência de metadados por meio do Job, e sempre podemos aplicar um sinalizador simples como "isMasterSoundJob", analisando esses metadados a qualquer momento.

Sem servidor faz o NoOps funcionar bem - uma abordagem que assume a necessidade de uma equipe separada responsável pela infraestrutura do projeto. Portanto, era uma questão pequena: implantamos a solução na AWS sem a participação de administradores de sistema, que sempre têm algo a fazer.
E, para acelerar tudo, automatizamos o script de implantação no AWS CloudFormation o máximo possível, permitindo implantar um botão diretamente do VS. Como resultado, um arquivo com 200 linhas de código permite implementar uma solução pronta, embora a sintaxe do CloudFormation possa ser chocante por hábito.

Total

Sem servidor não é uma panacéia. Mas isso facilitará muito a vida em situações com três limites: "recursos limitados - pouco tempo - pouco dinheiro".

Características dos aplicativos adequados para Serverless

• sem processos de longa execução. Gateway de API de limite rígido - 29 segundos, lambda de limite rígido - 15 minutos;
• descrito pela arquitetura orientada a eventos;
• decompõe-se em componentes fracamente acoplados por tipo de SOA;
• não requer muito trabalho com sua condição;
• escrito no .NET Core. Para trabalhar com o .NET Framework, você ainda precisará de pelo menos um Docker com o tempo de execução apropriado.

Benefícios de uma abordagem sem servidor

• reduz custos de infraestrutura;
• reduz o custo de entrega de uma solução;
• Escalabilidade automática
• desenvolvimento na vanguarda do progresso tecnológico.

Desvantagens, em um exemplo concreto

• Rastreamento e registro distribuídos - resolvidos parcialmente pelo AWS X-Ray e AWS CloudWatch;
• depuração inconveniente;
• Partida a frio na ausência de carga;
• A interface hostil do usuário da AWS é um problema universal :)