Si bien los microservicios están de moda, no son necesariamente la respuesta a todo. En una publicación de blog detalladaUn equipo de Prime Video, que está desarrollando un servicio para monitorear la calidad de las transmisiones de video vistas en vivo por los clientes, relata su viaje a contrapelo. De hecho, el equipo pasó de una arquitectura inicial altamente distribuida, basada en microservicios y sin servidores, a un enfoque más monolítico.

El servicio de análisis de calidad tiene tres componentes principales: conversores de medios, que transforman transmisiones de vídeo en imágenes y buffers de audio; detectores que analizan estos elementos en tiempo real para identificar defectos y finalmente una capa de orquestación. La herramienta inicial se desarrolló con componentes distribuidos, ejecutada en la plataforma sin servidor de AWS, Lambda, y orquestada con Step Functions. "Una buena opción para ir rápido", según Marcin Kolny, ingeniero senior de desarrollo de software en Prime Video y autor del artículo. Pero esta arquitectura demostró no ser adecuada cuando fue necesario ampliar y monitorear la calidad de miles de transmisiones en paralelo. “En teoría, este modelo permite que cada componente del servicio evolucione de forma independiente. Sin embargo, el uso de determinados componentes nos llevó a alcanzar un límite máximo de alrededor del 5 % de la carga prevista”, afirma el autor. La arquitectura planteaba dos problemas en particular: por un lado, la ampliación resultó muy costosa; por otro lado, el servicio encontró cuellos de botella.

El principal bloqueo estaba en la capa de orquestación: el servicio ejecuta muchas transiciones de estado por segundo, lo que rápidamente lleva a alcanzar el límite planificado para la cuenta de usuario. Además este servicio tiene un coste dependiendo del número de cambios de estadot. Otro problema fue cómo pasar imágenes de vídeo de un componente del servicio a otro. Para evitar tareas de conversión de video que requieren un alto rendimiento dentro del servicio principal, estas se delegaron a un microservicio separado, que almacenó temporalmente las imágenes resultantes en un depósito de S3. Pero esto provocó un gran número de llamadas al S3 desde el servicio principal, lo que supuso un coste económico.

De la escalabilidad horizontal a la vertical

Al notar que en este caso específico, un enfoque distribuido realmente no trajo los beneficios esperados, el equipo decidió revisar la arquitectura, agrupando todos los componentes en un solo proceso, pero manteniendo la misma división funcional (lo que permitió repetir un gran proceso). parte del código). De esta manera, ya no es necesario el uso de un depósito S3 para la preparación de imágenes. Además, ha cambiado la forma en que se gestiona el aumento de carga. Anteriormente, se hacía de forma horizontal, y la adición de detectores requería la creación de nuevos microservicios conectados a la capa de orquestación. A partir de ahora, se realizará de forma vertical: el equipo ha creado varios clones de su servicio, alojados en contenedores ECS en instancias EC2. Cuando se alcanza la capacidad máxima de una instancia, las solicitudes de los clientes se dirigen a otro clon, gracias a una capa de orquestación liviana. Otra ventaja es que puede beneficiarse de los planes de ahorro que ofrece AWS EC2.

Al rediseñar su arquitectura, el equipo redujo sus costos de infraestructura en un 90%. Los cambios también le permiten monitorear la calidad en todas las transmisiones de video, donde anteriormente se enfocaba en aquellas con mayor cantidad de espectadores, debido a los límites. De esta experiencia, Marcin Kolny concluye pragmáticamente: “Los microservicios y los componentes sin servidor son herramientas que funcionan a gran escala, pero la elección de utilizarlos en lugar de un monolito debe estudiarse caso por caso. »