Explorando App Mesh Parte 1: Conceptos, Demostración, Certificados y Observabilidad

Introducción

En las últimas semanas, nos hemos sumergido en el estudio de AWS App Mesh, profundizando en la documentación oficial de AWS y llevando a cabo diversas pruebas de concepto (PoCs). Por lo que es relevante compartir aspectos destacados y valiosos hallazgos sobre este servicio.

Antes de empezar proporcionaré contexto sobre nuestro proyecto, que se basa en una arquitectura de microservicios utilizando Amazon Elastic Container Service (AWS ECS) y ECS Service Connect para el descubrimiento de servicios y capa de red. En algunos casos de uso, necesitábamos ajustar el tiempo de espera a más de 15 segundos por solicitud y cifrar la comunicación entre microservicios. Debido a que ECS Service Connect no admitía estas características en ese momento, optamos por investigar AWS App Mesh. Es importante señalar que AWS anunció estas capacidades en ECS Service Connect después de que ya habíamos comenzado a implementar cambios en nuestro proyecto con AWS App Mesh. Aunque estas capacidades ahora están disponibles en ECS Service Connect a nivel de consola, hemos decidido continuar con AWS App Mesh al no estar disponibles en Terraform. Si quieres más información sobre estos anuncios, se pueden leer en los siguientes enlaces timeout y tls.

¿Qué es AWS App Mesh?

Es un servicio de AWS que funciona como una malla de servicios que simplifica la comunicación y supervisión de aplicaciones dentro de la malla. Su objetivo es proporcionar una capa de red a nivel de aplicación para aplicaciones desplegadas en diversas infraestructuras, como EKS, EC2 y ECS. Utiliza un proxy ligero (Envoy) para estandarizar la comunicación, ofreciendo visibilidad completa y alta disponibilidad. Aunque AWS App Mesh ofrece flexibilidad en la configuración de sus componentes, es crucial tener en cuenta que esta flexibilidad puede introducir complejidad en la implementación.

Componentes de AWS App Mesh

Este servicio tiene diversos componentes que nos ofrecen un marco robusto para controlar, observar y asegurar la comunicación entre servicios. Aquí hay un resumen:

• Mesh: Es una capa de red dedicada a gestionar la comunicación entre servicios, normalmente a través de una serie de proxies (envoy) implementados junto a la aplicación.
• Virtual Gateway: Este componente facilita el acceso de clientes externos a los servicios definidos dentro de la malla.
• Virtual Service: Es una abstracción de un servicio dentro de la malla, que es proveído por un nodo virtual o indirectamente por un enrutador virtual.
• Virtual Node: Es un puntero a la tarea o grupo de tareas en ECS o un deployment en EKS.
• Virtual Router y routers: Dirige el tráfico entre los nodos virtuales. Los routers definen cómo se dirige el tráfico entre los virtual nodes.
• Envoy Proxy: En AWS App Mesh, el Envoy Proxy es un componente esencial que opera como un contenedor junto a la aplicación. Su función principal es facilitar la comunicación segura y eficiente entre las aplicaciones dentro de la malla de servicios. Entre las funciones clave de Envoy se incluyen el enrutamiento, el descubrimiento de servicios, el balanceo de carga, la observabilidad y la seguridad.

El siguiente diagrama muestra los principales componentes de AWS App Mesh:

Integraciones

Es relevante resaltar que, a diferencia de ECS Service Connect, que se limita a trabajar exclusivamente con ECS, AWS App Mesh nos ofrece la capacidad de construir una malla de servicios que abarca aplicaciones desplegadas en Amazon ECS, EKS y Amazon EC2.

El diagrama siguiente ilustra una malla de servicios que incorpora los diversos tipos de infraestructura compatibles con AWS App Mesh.

Seguridad

En el ámbito de la seguridad, en AWS App Mesh, obtenemos la capacidad de cifrar la comunicación entre servicios dentro de la malla. Esto se logra a través de AWS Certificate Manager (ACM), certificados generados por el cliente, o aprovechando el componente de gestión de secretos de Envoy (SDS).

La siguiente imagen, muestra las opciones disponibles para habilitar el TLS Certificate en el listener del Virtual Node.

En nuestras pruebas, hemos centrado nuestra atención en la utilización de certificados almacenados en AWS ACM y en el sistema de archivos del proxy-envoy. A continuación, compartimos un cuadro comparativo que resume las conclusiones alcanzadas en nuestras pruebas.

En la siguiente imagen se muestra como configurar el listener del nodo virtual con un certificado almacenado en ACM. Si el certificado almacenado en ACM cumple los requisitos que se necesita AWS App Mesh, el certificado debería mostrarse en la lista desplegable. 
 

Si elegimos la alternativa Local file hosting, antes de configurar el listener, necesitamos crear una imagen personalizada del envoy-proxy que incluya los certificados propios en el sistema de archivos. Esto se puede lograr añadiendo los certificados en un AWS Secret Manager y utilizando un script de arranque para leerlos al iniciar el contenedor y almacenarlos en el sistema de archivos local del contenedor. Es fundamental señalar que con esta opción asumimos la responsabilidad total de la gestión de certificados, incluyendo la rotación y renovación, entre otras tareas.

Observabilidad

Logs

En App Mesh, puedes configurar logs en nodos y puertas virtuales (/dev/stdout) para ver información clave que incluye:

• Detalles de la solicitud - Método HTTP, URL, encabezados, etc.
• Detalles de la respuesta: código de estado, tiempo de respuesta, encabezados, etc.
• Métricas del nodo virtual: recuento de solicitudes, recuento de errores, percentiles del tiempo de respuesta, etc.

Para enviar estos registros a CloudWatch, se requiere configurar el controlador awslog en los contenedores donde se ejecuta el envoy-proxy. Más información en este enlace.

El siguiente fragmento de código muestra la configuración del controlador awslog:

{
"name": "envoy",
"image": "XXXXXXXXXXXXXXXX.dkr.ecr.eu-central-1.amazonaws.com/aws-appmesh-envoy:v1.22.2.0-prod",
...
"user": "1337",
"logConfiguration": {
	"logDriver": "awslogs",
	"options": {
		"awslogs-group": "/aws/ecs/app/pxxx-local-ms-python-service-proxy",
		"awslogs-region": "eu-central-1",
		"awslogs-stream-prefix": "ecs"
	}
},

Seguimiento de trazas

AWS X-Ray se integra con AWS App Mesh para gestionar las trazas de las aplicaciones que se encuentran dentro de la malla. App Mesh proporciona una versión del envoy-proxy, que puede configurar para enviar datos de rastreo al demonio de X-Ray (Se ejecuta en un contenedor de la misma tarea o pod). El daemon de AWS X-Ray es una aplicación que monitorea el tráfico en el puerto UDP 2000, recoge datos crudos de segmentos y los envía a la API de AWS X-Ray. Este daemon trabaja en conjunto con los SDK de AWS X Ray y debe estar activo para que los datos enviados por los SDK lleguen al servicio X-Ray.

Para habilitar el envío de trazas a X-Ray, es necesario agregar un contenedor adicional que se ejecute junto a la aplicación para realizar esta función (sidecar).

La configuración del contenedor X-Ray se presenta de la siguiente manera:

{
	"name": "xray",
	"image": "amazon/aws-xray-daemon",
	"cpu": 0,
	"portMappings": [
		{
			"containerPort": 2000,
			"hostPort": 2000,
			"protocol": "udp"
		}
	],
	"essential": false,
	"environment": [],
	"mountPoints": [],
	"volumesFrom": [],
	"healthCheck": {
		"command": [
			"CMD-SHELL",
			"timeout 1 /bin/bash -c \"</dev/udp/localhost/2000\""
		],
		"interval": 10,
		"timeout": 5,
		"retries": 3,
		"startPeriod": 10
	}
}

Una vez configurado el contenedor dentro de la definición de la tarea, al actualizar el servicio en AWS ECS, podemos observar el contenedor de X-Ray que acabamos de agregar. Ver la siguiente imagen:

Y en la siguiente imagen, se visualiza el mapa de servicios que construye X-Ray, para una llamada interna entre microservicios.

Comparativas con otras soluciones

Explorar y comprender las diferencias entre las soluciones de gestión de mallas de servicios es esencial para tomar decisiones informadas en arquitecturas de microservicios. En esta comparativa, analizaremos AWS App Mesh junto con otras herramientas como Service Discovery y Service Connect:

Conclusiones

Tanto ECS Service Connect como AWS App Mesh desempeñan un papel crucial al establecer una capa de red para nuestros servicios mediante la inclusión de un sidecar en las tareas. Ambas soluciones proporcionan beneficios sustanciales en términos de control de tráfico, monitoreo, observabilidad y tolerancia a fallos. En ambos casos, los costos se limitan a los recursos consumidos por el sidecar, lo que resulta eficiente en términos de gastos.

En nuestro escenario específico, la elección de AWS App Mesh ha demostrado ser especialmente valiosa. Esta plataforma nos ha permitido personalizar los tiempos de espera por solicitud y configurar el cifrado de las comunicaciones entre microservicios dentro de la malla. Estas capacidades adicionales han fortalecido la seguridad y la flexibilidad en nuestra arquitectura de microservicios, contribuyendo significativamente a la mejora de nuestro entorno operativo.

Referencias

• Documentación de AWS: https://docs.aws.amazon.com/es_es/app-mesh/latest/userguide/what-is-app-...
• Workshop de App Mesh https://www.appmeshworkshop.com/introduction/
• Ejemplo de AppMesh https://github.com/aws/aws-app-mesh-examples