Redes entre los servicios de Amazon ECS en una VPC

Al utilizar las tareas de Amazon ECS en una VPC, puede dividir las aplicaciones monolíticas en partes independientes que se pueden implementar y escalar de forma independiente en un entorno seguro. Esta arquitectura se denomina arquitectura orientada a servicios (SOA) o microservicios. Sin embargo, puede resultar difícil asegurarse de que todas estas partes, tanto dentro como fuera de una VPC, puedan comunicarse entre sí. Existen varios enfoques para facilitar la comunicación, todos con diferentes ventajas y desventajas.

Uso de Service Connect

Recomendamos Amazon ECS Service Connect, que proporciona la configuración de Amazon ECS para la detección de servicios, la conectividad y la supervisión del tráfico. Con Service Connect, sus aplicaciones pueden usar nombres abreviados y puertos estándar para conectarse a los servicios de ECS del mismo clúster y a otros clústeres, incluso a todas las VPC del mismo Región de AWS. Para obtener más información, consulte Amazon ECS Service Connect en la Guía para desarrolladores de Amazon Elastic Container Service.

Cuando usa Service Connect, ECS administra todas las partes del descubrimiento de servicios: crea los nombres que se pueden descubrir, administra dinámicamente las entradas de cada tarea a medida que las tareas se inician y se detienen, y ejecuta un agente en cada tarea que está configurado para descubrir los nombres. La aplicación puede buscar los nombres mediante la funcionalidad estándar para los nombres de DNS y establecer conexiones. Si su aplicación ya lo hace, no tendrá que modificarla para usar Service Connect.

Los cambios solo se producen durante las implementaciones

Usted proporciona la configuración completa dentro de cada definición de servicio y tarea de ECS. ECS administra los cambios en esta configuración en cada implementación de servicio, para garantizar que todas las tareas de una implementación se comporten de la misma manera. Por ejemplo, un problema común con el DNS en la detección de servicios es el control de una migración. Si cambia un nombre de DNS para que apunte a las nuevas direcciones IP de reemplazo, es posible que pase el tiempo máximo de TTL antes de que todos los clientes comiencen a usar el nuevo servicio. Con Service Connect, la implementación del cliente actualiza la configuración sustituyendo las tareas del cliente. Puede configurar el disyuntor de implementación y otras configuraciones de implementación para que afecten a los cambios de Service Connect de la misma manera que cualquier otra implementación.

Uso de la detección de servicios

Otro enfoque de service-to-service comunicación es la comunicación directa mediante el descubrimiento de servicios. En este enfoque, puede utilizar la integración de descubrimiento de AWS Cloud Map servicios con Amazon ECS. Mediante la detección de servicios, Amazon ECS sincroniza la lista de tareas iniciadas AWS Cloud Map, que mantiene un nombre de host DNS que se resuelve en las direcciones IP internas de una o más tareas de ese servicio en particular. Otros servicios de Amazon VPC pueden usar este nombre de host DNS para enviar tráfico directamente a otro contenedor mediante su dirección IP interna. Para obtener más información, consulte Descubrimiento de servicios en la Guía para desarrolladores de Amazon Elastic Container Service.

En el diagrama anterior, hay tres servicios. serviceAtiene un contenedor y se comunica conserviceB, que tiene dos contenedores. serviceBtambién debe comunicarse conserviceC, que tiene un contenedor. Cada contenedor de estos tres servicios puede usar los nombres DNS internos AWS Cloud Map para buscar las direcciones IP internas de un contenedor del servicio descendente con el que necesita comunicarse.

Este enfoque de service-to-service comunicación proporciona una latencia baja. A primera vista, también es sencillo, ya que no hay componentes adicionales entre los contenedores. El tráfico viaja directamente de un contenedor al otro.

Este enfoque es adecuado cuando se utiliza el modo de red awsvpc, en el que cada tarea tiene su propia dirección IP única. La mayoría de los programas solo admiten el uso de registros A de DNS, que se resuelven directamente en las direcciones IP. Cuando se utiliza el modo de red awsvpc, la dirección IP de cada tarea es un registro A. Sin embargo, si utiliza el modo de red bridge, es posible que varios contenedores compartan la misma dirección IP. Además, las asignaciones dinámicas de puertos hacen que a los contenedores se les asignen números de puerto de forma aleatoria en esa única dirección IP. En este punto, un registro A ya no es suficiente para la detección de servicios. También debe usar un registro SRV. Este tipo de registro puede hacer un seguimiento de las direcciones IP y los números de puerto, pero requiere que configure las aplicaciones de forma adecuada. Es posible que algunas aplicaciones prediseñadas que utilice no admitan registros SRV.

Otra ventaja del modo de red awsvpc es que tiene un grupo de seguridad único para cada servicio. Puede configurar este grupo de seguridad para permitir las conexiones entrantes únicamente desde los servicios ascendentes específicos que necesitan comunicarse con ese servicio.

La principal desventaja de la service-to-service comunicación directa mediante el descubrimiento de servicios es que se debe implementar una lógica adicional para volver a intentarlo y hacer frente a los fallos de conexión. Los registros DNS tienen un período time-to-live (TTL) que controla cuánto tiempo se almacenan en caché. El registro DNS tarda algún tiempo en actualizarse y la caché en caducar para que las aplicaciones puedan recoger la última versión del registro DNS. Por lo tanto, su aplicación podría terminar resolviendo el registro DNS para que apunte a otro contenedor que ya no está allí. Su aplicación debe gestionar los reintentos y tener una lógica para ignorar los backends defectuosos.

Uso de un balanceador de cargas interno

Otro enfoque de service-to-service comunicación consiste en utilizar un equilibrador de carga interno. Existe un balanceador de cargas interno completamente dentro de la VPC y solo los servicios que están dentro de la VPC pueden acceder a él.

El balanceador de carga mantiene una alta disponibilidad al implementar recursos redundantes en cada subred. Cuando un contenedor serviceA necesita comunicarse con un contenedor de origenserviceB, abre una conexión con el balanceador de cargas. A continuación, el balanceador de cargas abre una conexión a un contenedor desde. service B El balanceador de cargas sirve como un lugar centralizado para administrar todas las conexiones entre cada servicio.

Si un contenedor se serviceB detiene, el balanceador de cargas puede retirar ese contenedor del grupo. El balanceador de cargas también comprueba el estado de cada uno de los objetivos intermedios de su grupo y puede eliminar automáticamente los objetivos incorrectos del grupo hasta que vuelvan a estar en buen estado. Las aplicaciones ya no necesitan saber cuántos contenedores descendentes hay. Simplemente abren sus conexiones al balanceador de carga.

Este enfoque es ventajoso para todos los modos de red. El balanceador de carga puede realizar un seguimiento de las direcciones IP de las tareas cuando se usa el modo de awsvpc red, así como de las combinaciones más avanzadas de direcciones IP y puertos cuando se usa el modo de bridge red. Distribuye el tráfico de manera uniforme entre todas las combinaciones de direcciones IP y puertos, incluso si varios contenedores están realmente alojados en la misma instancia de Amazon EC2, solo que en puertos diferentes.

La única desventaja de este enfoque es el costo. Para tener una alta disponibilidad, el balanceador de cargas debe tener recursos en cada zona de disponibilidad. Esto supone un coste adicional debido a la sobrecarga que supone pagar por el balanceador de cargas y por la cantidad de tráfico que pasa por él.

Sin embargo, puedes reducir los gastos generales si varios servicios comparten un balanceador de carga. Esto es especialmente adecuado para los servicios REST que utilizan un Application Load Balancer. Puede crear reglas de enrutamiento basadas en rutas que dirijan el tráfico a diferentes servicios. Por ejemplo, /api/user/* podría enrutar a un contenedor que forma parte del user servicio, mientras que /api/order/* podría enrutarse al order servicio asociado. Con este enfoque, solo paga por un Application Load Balancer y dispone de una URL coherente para su API. Sin embargo, puedes dividir el tráfico en varios microservicios del backend.