Trabajo en subcontratación, donde el principio fundamental se puede describir con la frase "vende mucho, hazlo rápido". Cuanto más rápido lo hagamos, más ganaremos. Y es deseable que todo funcione no con muletas y mocos, sino con un nivel de calidad aceptable. Les contaré mi experiencia cuando fue necesario desarrollar un servicio promocional en un corto período de tiempo.
mayo: cuenta raíz en AWS, sin restricciones en la elección de la pila de tecnología, un backend y un mes para el desarrollo.
Problema: implementar un servicio promocional donde los usuarios suben de uno a cuatro videos de una duración de uno a cuatro segundos, que luego se integran en la serie de videos original.
Solución
Crear tu propio servicio de bicicletas en tan poco tiempo no es una buena idea. Además, para que el servicio pueda hacer frente a la carga y que todos puedan recibir el codiciado vídeo, se necesitará infraestructura. Y preferiblemente no con el precio del 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 vídeo es FFmpeg, una utilidad de consola multiplataforma que, a través de argumentos, permite cortar y sobregrabar audio. Todo lo que queda por hacer es escribir un envoltorio y darle vida. Escribimos un prototipo que une dos videos y... comienza la diversión. La biblioteca está basada en .NET Core 2, debería ejecutarse en cualquier máquina virtual, por lo que tomamos una instancia de AWS EC2 y todo funcionará
Texto ocultono, no funcionará
.
Aunque FFmpeg simplifica la tarea, para una solución que realmente funcione es necesario crear una instancia EC2 y diseñar una infraestructura de red para ella, incluido un equilibrador de carga. La simple tarea de implementar desde cero se vuelve "un poco" más complicada y la infraestructura comienza a exigir dinero de inmediato: cada hora se retira de la cuenta del cliente el monto del tiempo de ejecución.
Nuestro servicio no implica procesos de larga duración, no requiere una base de datos relacional grande y pesada y encaja perfectamente en una arquitectura basada en eventos con una cadena de llamadas de microservicios. La solución se sugiere por sí sola: podemos abandonar EC2 e implementar una aplicación verdaderamente sin servidor, como el Image Resizer estándar basado en AWS Lambda.
Por cierto, a pesar del evidente disgusto de los desarrolladores de AWS por .NET, admiten .NET Core 2.1 como tiempo de ejecución, lo que proporciona una gama completa de oportunidades de desarrollo.
Y la guinda del pastel: AWS ofrece un servicio independiente para trabajar con archivos de vídeo: AWS Elemental MediaConvert.
La esencia del trabajo es increíblemente simple: tomamos un enlace S3 al video saliente, escribimos a través de la consola AWS, .NET SDK o simplemente JSON lo que queremos hacer con el video y llamamos al servicio. Él mismo implementa colas para procesar solicitudes entrantes, carga el resultado en el propio S3 y, lo más importante, genera un evento CloudWatch para cada cambio de estado. Esto nos permite implementar activadores lambda para completar el procesamiento de video.
Así es como se ve la arquitectura final:
Todo el backend está alojado en dos lambdas. Otro es para rotar vídeos verticales, ya que dicho trabajo no se puede realizar en una sola pasada.
Colocaremos el frente en forma de una aplicación SPA escrita en JS y compilada mediante pug en un depósito público de S3. Para descargar los videos, no necesitamos ningún código de servidor; solo necesitamos abrir los puntos finales REST que nos proporciona S3. Lo único es que no olvides configurar políticas y CORS.
Trampas
- AWS MediaConvert, por alguna razón desconocida, solo aplica sonido a cada fragmento de video por separado, pero necesitamos una canción alegre de todo el protector de pantalla.
- Los vídeos verticales deben procesarse por separado. A AWS no le gustan las barras negras y coloca los rodillos a 90°.
pista de patinaje fácil
A pesar de toda la belleza de Stateless, debes realizar un seguimiento de lo que se debe hacer con el video: pegar o agregar audio a la secuencia de video terminada. Afortunadamente, MediaConvert admite el paso de metadatos a través de sus trabajos, y siempre podemos usar un indicador simple del formato "isMasterSoundJob" para analizar estos metadatos en cualquier etapa.
Serverless permite trabajar perfectamente con NoOps, un enfoque que asume la innecesaria necesidad de un equipo separado responsable de la infraestructura del proyecto. Por lo tanto, fue un asunto menor: implementamos la solución en AWS sin la participación de los administradores del sistema, quienes de todos modos siempre tienen algo que hacer.
Y para acelerar todo esto, automatizamos el script de implementación tanto como sea posible en AWS CloudFormation, lo que le permite implementar con un botón directamente desde VS. Como resultado, un archivo de 200 líneas de código le permite implementar una solución ya preparada, aunque la sintaxis de CloudFormation puede resultar impactante si no está acostumbrado a ella.
En total
La tecnología sin servidor no es una panacea. Pero hará la vida mucho más fácil en situaciones con tres límites: “recursos limitados, corto plazo, poco dinero”.
Características de las aplicaciones aptas para Serverless
- sin procesos de larga duración. El límite estricto de API Gateway es de 29 segundos, el límite estricto de lambda es de 5 minutos;
- descrito por la arquitectura basada en eventos;
- se descompone en componentes débilmente acoplados como SOA;
- no requiere mucho trabajo con su condición;
- escrito en .NET Core. Para trabajar con .NET Framework, necesitará al menos Docker con el tiempo de ejecución adecuado.
Beneficios del enfoque sin servidor
- reduce los costos de infraestructura;
- reduce el costo de entregar la solución;
- escalabilidad automática;
- desarrollo a la vanguardia del progreso tecnológico.
Desventajas, con un ejemplo específico.
- Seguimiento y registro distribuidos: parcialmente resuelto a través de AWS X-Ray y AWS CloudWatch;
- depuración inconveniente;
- Arranque en frío cuando no hay carga;
- La interfaz hostil al usuario de AWS es un problema universal :)
Fuente: habr.com