Enfoque sin servidor para el rápido desarrollo de un servicio de video en funcionamiento

Trabajo en outsourcing, donde el principio principal se puede describir con la frase "vende mucho, hazlo rápido". Cuanto más rápido lo hacemos, más ganamos. Y, es deseable que no todo funcione con muletas y mocos, sino con un nivel aceptable de calidad. Contaré sobre mi experiencia cuando en poco tiempo fue necesario desarrollar un servicio promocional.

Dado: cuenta raíz en AWS, sin restricciones en la elección de la pila de tecnología, un back-end y un mes para el desarrollo.

Objetivo: implementar un servicio promocional donde los usuarios suban de uno a cuatro videos que duran de uno a cuatro segundos, que luego se incrustan en la secuencia de video original. Es decir, reemplazamos fragmentos del video original (protector de pantalla de la serie) por otros personalizados. Función asesina: la capacidad de enviar su nombre, que en forma de hermoso texto superpone el fragmento de video correspondiente. Además, el usuario puede cargar un video de 4 a 30 segundos de duración, y en el lado del servicio se reducirá a 4 segundos.

Solución

Escribir su servicio de bicicletas en un período de tiempo tan ajustado es una idea. Además, para que el servicio pueda hacer frente a las cargas y a todos los que quieran recibir el codiciado video, se requerirá la infraestructura. Y preferiblemente no con una etiqueta de precio desde el avión. Por lo tanto, nos centramos inmediatamente en soluciones listas para usar con una personalización mínima.

La solución estándar para trabajar con video es FFmpeg, una utilidad de consola multiplataforma que, a través de argumentos, le permite cortar y superponer el sonido. Lo pequeño es escribir un contenedor y ponerlo en práctica. Estamos escribiendo un prototipo que une dos videos y ... comienza la diversión. La biblioteca en .NET Core 2 debería girar en cualquier máquina virtual, por lo que tomamos la instancia de AWS EC2 y todo funcionará


FFmpeg, aunque simplifica la tarea, pero para una solución que realmente funcione, necesita crear una instancia EC2, diseñar una infraestructura de red para ello, incluido el equilibrador de carga. La simple tarea de implementar desde cero es "un poco" complicada, y la infraestructura comienza a exigir dinero de inmediato: la cantidad del tiempo de ejecución se retira de la cuenta del cliente cada hora.

Nuestro servicio no involucra procesos de larga duración, no requiere una base de datos relacional grande y audaz, y se adapta perfectamente a la arquitectura de eventos con una cadena de llamadas de microservicio. La solución se sugiere a sí misma: podemos abandonar EC2 e implementar una aplicación verdadera sin servidor, como el Image Resizer estándar basado en AWS Lambda.

Por cierto, a pesar de la obvia aversión de los desarrolladores de AWS por .NET, admiten .NET Core 2.1 como tiempo de ejecución, lo que brinda una gama completa de oportunidades de desarrollo.

Y la guinda del pastel: AWS proporciona un servicio separado para trabajar con archivos de video: AWS Elemental MediaConvert.

La esencia del trabajo es increíblemente simple: tomamos el enlace S3 al video saliente, a través de la consola de AWS, .NET SDK o simplemente JSON escribimos lo que queremos hacer con el video y llamamos al servicio. Él mismo implementa las colas para procesar las solicitudes entrantes, descarga el resultado en S3 y, lo más importante, genera un evento CloudWatch para cada cambio de estado. Esto nos permite implementar disparadores lambda para completar el procesamiento de video.


La versión final de la arquitectura se ve así

Todo el backend se coloca en dos lambdas. Otro es para rotar videos verticales, ya que dicho trabajo no se puede hacer de una vez.

La superposición de texto se realizó renderizando una imagen transparente sobre la marcha de acuerdo con la resolución del video. La biblioteca SixLabors.ImageSharp es perfecta para este propósito, y los problemas de pérdida de memoria eluden con elegancia el ciclo de vida lambda.

El frente en forma de una aplicación SPA escrita en JS y compilada a través de pug se colocará en la cesta pública S3. Para descargar los videos en sí, no necesitamos ningún código de servidor, solo abra los puntos finales REST que nos ofrece S3. Lo único: no olvide configurar políticas y CORS.

Trampas

• AWS MediaConvert por alguna razón desconocida impone el sonido solo en cada videoclip individualmente, y necesitamos una canción ferviente de todo el protector de pantalla.
• Los videos verticales deben procesarse por separado. A AWS no le gustan las rayas negras y coloca los rodillos a 90 °.

Pista fácil

A pesar de la belleza de Stateless, debe realizar un seguimiento de lo que debe hacerse con el video: pegar o superponer el sonido en una secuencia de video ya terminada. Afortunadamente, MediaConvert admite la transferencia de metadatos a través de su trabajo, y siempre podemos aplicar un indicador simple como "isMasterSoundJob", analizando estos metadatos en cualquier etapa.

Sin servidor hace que NoOps funcione bien, un enfoque que asume la necesidad de un equipo separado responsable de la infraestructura del proyecto. Por lo tanto, era un asunto pequeño: implementamos la solución en AWS sin la participación de administradores de sistemas, que siempre tienen algo que hacer.
Y para acelerarlo todo, automatizamos la secuencia de comandos de implementación en AWS CloudFormation tanto como sea posible, lo que le permite implementar un botón directamente desde VS. Como resultado, un archivo con 200 líneas de código le permite implementar una solución lista para usar, aunque la sintaxis de CloudFormation puede ser muy desagradable.

Total

Sin servidor no es una panacea. Pero facilitará enormemente la vida en situaciones con tres límites: "recursos limitados - poco tiempo - poco dinero".

Características de las aplicaciones adecuadas para Serverless

• sin procesos de larga duración. Puerta de enlace API de límite rígido - 29 segundos, lambda de límite rígido - 15 minutos;
• descrito por la arquitectura dirigida por eventos;
• se descompone en componentes sueltos por tipo de SOA;
• no requiere mucho trabajo con su condición;
• escrito en .NET Core. Para trabajar con .NET Framework, aún necesitará al menos un Docker con el tiempo de ejecución adecuado.

Beneficios de un enfoque sin servidor

• reduce los costos de infraestructura;
• reduce el costo de entregar una solución;
• Escalabilidad automática
• desarrollo a la vanguardia del progreso tecnológico.

Desventajas, en un ejemplo concreto

• Seguimiento y registro distribuidos: parcialmente resueltos a través de AWS X-Ray y AWS CloudWatch;
• depuración inconveniente;
• Arranque en frío en ausencia de carga;
• La interfaz hostil de usuario de AWS es un problema universal :)