Clústeres autoadministrados: ECS + Fargate como alternativa a Kubernetes
Hace unos días atrás me tocó, como Solution Architect, diseñar una arquitectura para un cliente con un negocio muy dinámico y configurable, lo cual nos llevó a optar por microservicios. Debíamos separar conceptos y acomodarlos para que interactúen con otros servicios internos y externos.
Por características de este cliente, decidimos usar AWS; y como solemos hacer, usamos Kubernetes con EKS (Elastic Kubernetes Service). Pero, conversando sobre esta elección con Carlos (un gran amigo), me preguntó: “¿El cliente tiene gente que sepa cómo administrar Kubernetes?”. A lo que contesté: “Mmm…no”. Entonces, me advirtió: “Necesitás que la administración sea lo más automatizada posible, para que no tengas que estar vos manejando recursos para escalar, o subiendo y bajando Pods” (un Pod es la unidad básica de implementación y escalabilidad en EKS).
Esta fue la razón por la que, finalmente, decidimos cambiar EKS por ECS (Elastic Container Service) y Fargate. Y si esto es nuevo para vos, quedate que te cuento más.
¿Qué dice la documentación de AWS?
“La tecnología AWS Fargate se puede utilizar en Amazon ECS para ejecutar contenedores de Docker sin tener que administrar servidores y clústeres de instancias de Amazon EC2. Con Fargate, ya no tendrá que aprovisionar, configurar ni escalar clústeres de máquinas virtuales para ejecutar los contenedores. De esta manera, se elimina la necesidad de elegir tipos de servidores, decidir cuándo escalar los clústeres u optimizar conjuntos de clústeres.”1
La idea no es administrar recursos, ni máquinas virtuales, ni memoria, sino que AWS los administre en nuestro lugar.
Un ECS es un clúster que funciona como servicio y se utiliza como si fuera una API. Podemos saber todos los valores de uso (como memorias, procesos y más), pero sin que la persona usuaria tenga que administrarlo.
¿Pero, qué es un clúster?
Un clúster de Amazon Elastic Container Service (ECS) es un grupo de instancias de Amazon Elastic Compute Cloud (EC2) que se usa para ejecutar contenedores. Los clústeres proporcionan un ambiente para ejecutar tareas de contenedor que, a su vez, ejecutan contenedores individuales.
Cada clúster puede tener uno o varios grupos de tareas que, al mismo tiempo, pueden contener uno o varios contenedores. Y los contenedores se pueden escalar automáticamente dentro de un clúster mediante la configuración de reglas de escalabilidad automática.
Hay 2 tipos ECS:
1. El ECS con instancias es un clúster en el que se proveen las instancias, ya sea bajo demanda o spot.
2. El serverless (ECS Fargate), donde el clúster simula ser serverless (es decir, no tiene instancias), se define qué servicios se van a ejecutar y AWS, por detrás, se encarga de los procesos para resolver los servicios y ejecutarlos.
Como comenté antes, un clúster sirve para resolver tareas o servicios, y un clúster de ECS está desarrollado exclusivamente para orquestar contenedores de Docker.
Todas sus tareas y procesos terminan en contenedores de Docker. Y para definir estos contenedores, existe un objeto llamado container definition, en el que definiremos todos los parámetros y propiedades que necesita un Docker para funcionar.
Así mismo, se utilizará task definition, un template que sirve para saber dónde está esa imagen de Docker, cómo poder acceder a ella y ejecutarla, y si será del tipo EC2 o Fargate. Podríamos tener una colección de container definitions: por ejemplo, un servidor de .Net Core y otro de SQL Server estarán ejecutándose en el mismo entorno y compartiendo datos entre sí.
Luego existe el service, que es la puerta de entrada a la ejecución. En el service tendremos definidos los parámetros de cantidad de tasks que vamos a ejecutar, como así también el Load Balancer que usaremos y los límites, tanto de memoria como de procesador.
Fuente: www.serverless.com/blog/serverless-application-for-long-running-process-fargate-lambda
Cómo crear un ECS Fargate directamente desde la consola de AWS
Podemos crearlo desde Terraform o desde SDK siguiendo estos pasos:
1. Crear un clúster
Desde AWS Console ingresamos en Elastic Container Service y creamos un nuevo clúster.
Seleccionamos la VPC en la que correrá el clúster, o creamos una.
En la sección de infraestructura, seleccionamos el tipo de clúster (EC2 o Fargate) dependiendo de si queremos instancias o serverless. Recordá que, si seleccionamos Fargate, todos los servicios deben ser del mismo tipo.
Una vez creados, en la consola podremos ver el clúster y en qué estado está, y debemos esperar a que AWS cree y asigne los recursos del clúster.
2. Crear una task definition
Creado el clúster, tenemos que decirle qué imagen va a ejecutar, y para eso creamos nuestra task definition.
¿Qué es una task definition? Es un archivo JSON que especifica los detalles de una tarea de contenedor, como, por ejemplo, qué contenedores debe incluir, las configuraciones de recursos para esos contenedores y las reglas de red. Una task definition también puede especificar los volúmenes de datos para montar en el contenedor, variables de entorno y configuraciones de autenticación. Se utiliza la task definition para poder crear luego una task que se ejecutará en el clúster de ECS
¿Cómo creamos una task definition? Para crear una tarea de Fargate hay que:
- Seleccionar la opción “Task Definitions” en el menú de navegación.
- Seleccionar el botón “Create New Task Definition”.
- Seleccionar el botón “Fargate” como plataforma de ejecución.
- Seleccionar el botón “Next Step”.
- En la pestaña “Task Definition”, llenar los detalles necesarios como nombre, número de CPU y memoria requerida. Estos parámetros son los mínimos. Una vez creada la tarea, el Auto Scaling se encarga de administrar, agregar o quitar estos recursos.
- Seleccionar el botón “Add Container” para agregar un contenedor a la tarea.
- Llenar los detalles del contenedor como: nombre, imagen, puertos, etc.
- Seleccionar el botón “Create” para crear la tarea.
Una vez creada la tarea, podemos usar la opción “Run Task” para ejecutarla en un clúster de Fargate.
Hay que tener en cuenta que, para ejecutar una tarea en Fargate, es necesario contar con un servicio y una red configurada antes de crear la tarea.
Ya creada la tarea, esperamos a que ECS aprovisione los recursos y deje corriendo la tarea. En el clúster podemos ver el estado, tanto de los servicios como de las tareas.
3. Crear services
Para poder coordinar todo esto y mantener las instancias o las tasks corriendo, necesitamos un service. ¿De qué se trata?
Un servicio en Amazon Elastic Container Service (ECS) es una abstracción que se utiliza para manejar un grupo de contenedores idénticos que se ejecutan en un clúster. Un servicio se encarga de asegurar que un número específico de réplicas de un contenedor se estén ejecutando en todo momento, y también proporciona un mecanismo para escalar automáticamente los contenedores según la demanda.
Al crear un servicio en ECS, se especifica una task definition que describe qué contenedor se va a ejecutar, y se configura el número de réplicas deseado del contenedor. ECS se encarga de provisionar los recursos necesarios en el clúster y de lanzar las tareas que se corresponden con la task definition.
Un servicio también se puede vincular a una ruta de Amazon Elastic Load Balancing (ELB) o Application Load Balancer (ALB), lo que permite equilibrar la carga entre las tareas de contenedor. También puede usarse para automatizar la recuperación de tareas fallidas y el escalado automático de tareas en función de la demanda.
Podemos decir que es como la “puerta de ingreso” al clúster.
En primer lugar, creamos el service y seteamos el environment.
A continuación, generamos la configuración de deployment.
La configuración de deployment es una característica que permite controlar cómo se realizan las actualizaciones de un servicio. Especifica cómo se realizarán las transiciones entre diferentes versiones de una task definition, lo que permite a personas usuarias controlar el proceso de implementación de un servicio de forma precisa.
Al crear o actualizar un servicio, se puede especificar una configuración de implementación que incluye información como:
- El número máximo de tareas que se deben detener simultáneamente durante una actualización.
- El tiempo de espera máximo permitido para detener una tarea antes de forzar la finalización.
- El número máximo de tareas que se deben lanzar simultáneamente durante una actualización.
De esta manera, podemos controlar el proceso de implementación para asegurar una transición suave entre las diferentes versiones del servicio. Además, la configuración de implementación permite reducir el tiempo de inactividad y el riesgo de interrupciones durante la implementación.
Configurar el networking
El networking se usa, principalmente, para establecer conexiones entre contenedores.
Otra de las funciones importantes del networking en ECS es la posibilidad de conectar contenedores entre sí y con otros servicios dentro de un clúster. Esto se logra mediante el uso de Virtual Private Cloud (VPC) y las opciones de enrutamiento y seguridad de Amazon VPC.
Además, el servicio de Load Balancing en ECS puede usar un Elastic Load Balancer (ELB) para balancear la carga entre las tareas de un servicio y asegurar una distribución equitativa de la carga entrante. Esto permite escalar automáticamente los contenedores para manejar la demanda, y ofrecer una alta disponibilidad para los servicios.
También es posible controlar el tráfico de red entrante y saliente mediante el uso de Security Group y Network Access Control Lists (ACLs) de Amazon VPC, para limitar el acceso sólo a servicios específicos y proteger los contenedores y servicios contra ataques externos.
Una vez creados los servicios, ya podremos ver en la consola de AWS cómo se comportan los componentes que integran el clúster, y si todos los componentes están levantados y corriendo.
Cuando tenemos el clúster con sus respectivos services y task definition, podemos generar un Load Balancer para balancear la carga en la llamada a los services.
¿Qué es un load balancer? Un load balancer es un servicio que proporciona un equilibrio de carga automático para las aplicaciones. Permite distribuir automáticamente la carga entrante entre varios servidores o instancias, lo que aumenta la disponibilidad y escalabilidad de las aplicaciones.
AWS ofrece dos tipos de load balancer:
Application Load Balancer (ALB): es un equilibrador de carga de aplicaciones de nivel 7; es decir, se enfoca en el nivel de aplicación, con un enfoque en la distribución de carga en función de criterios como las URL o las cabeceras HTTP.
Network Load Balancer (NLB): es un equilibrador de carga de nivel 4, que se centra en la distribución de carga en función de criterios de protocolo de red, como direcciones IP y puertos.
Los load balancers pueden utilizarse para distribuir la carga entrante entre múltiples instancias de EC2, y también pueden ser utilizados para equilibrar la carga entre contenedores, ejecutándose en Amazon ECS o en un clúster de Kubernetes.
Además, un load balancer puede proporcionar funcionalidades como:
- SSL Offloading
- Health Checks
- Sticky Sessions
Con el load balancer se puede mejorar la disponibilidad y escalabilidad de las aplicaciones, distribuyendo automáticamente la carga entre varios servidores o instancias. Esto permite tener un único punto de acceso y, mediante los listener, poder enrutar tráfico.
Ahora, ¿qué es un listener? En un load balancer, los listeners son reglas que se configuran para controlar cómo se maneja el tráfico entrante hacia el load balancer. Cada listener está configurado con un protocolo de red y un puerto específicos, y se utiliza para escuchar y manejar las solicitudes entrantes en ese protocolo y puerto.
En el caso de Application Load Balancer (ALB), los listeners se enfocan en el nivel de aplicación, y pueden ser configurados con reglas basadas en URL o cabeceras HTTP para redirigir el tráfico entrante hacia diferentes grupos de tareas o servidores.
En el caso de Network Load Balancer (NLB), los listeners se enfocan en el nivel de red, y pueden ser configurados con reglas basadas en protocolos de red como TCP o UDP y el puerto correspondiente para redirigir el tráfico hacia diferentes grupos de tareas o servidores.
Por cada listener podemos configurar una o varias reglas, las cuales son utilizadas para determinar a qué grupo de tareas enviar el tráfico entrante. Estas reglas pueden basarse en diferentes criterios, como las URL o las cabeceras HTTP, o las direcciones IP y puertos.
Los listeners son esenciales en el funcionamiento de un Load Balancer, ya que son los encargados de escuchar y redirigir el tráfico entrante hacia los servidores o instancias correctas, permitiendo una distribución equitativa de la carga y mejorando la disponibilidad y escalabilidad de las aplicaciones.
La arquitectura del ECS Fargate utilizada en este ejemplo quedaría de la siguiente manera (el proyecto contempla un front end en React y un back end en Node.JS):
En una branch específica de un manejador de versiones está la configuración de deploy, la cual genera la imagen docker y la sube al ECR (Amazon Elastic Container Registry); desde ahí se van creando versiones nuevas de las task definition y se implementan para que el service pueda hacer uso de ellas.
Todo esto sin la intervención de personas usuarias: todos los clústeres tienen Auto Scaling!
El Auto Scaling en ECS se usa para escalar automáticamente los contenedores de un servicio en función de la demanda. Con Auto Scaling, los contenedores siempre estarán disponibles para manejar la carga y garantizar una alta disponibilidad para las aplicaciones.
Hay dos formas principales de configurar el Auto Scaling en ECS:
Escalado automático basado en CloudWatch: este tipo de escalado automático utiliza reglas de CloudWatch para aumentar o disminuir el número de tareas de un servicio en función de los metadatos de CloudWatch. Por ejemplo, se pueden crear reglas para escalar automáticamente las tareas en función de la CPU o el uso de la memoria.
Escalado automático basado en un planificador: en este caso, el escalado automático es un planificador para escalar automáticamente el número de tareas de un servicio en función de un calendario. Por ejemplo, se puede configurar un planificador para aumentar el número de tareas durante las horas pico, y disminuirlas durante las horas no pico.
Una vez configurado, el Auto Scaling automáticamente aumenta o disminuye el número de tareas en función de las reglas o planificador que se hayan configurado, asegurando que siempre haya suficientes tareas disponibles para manejar la carga y garantizar una alta disponibilidad para las aplicaciones.
En conclusión
Cuando es necesario un clúster para administrar servicios, APIs o un front end, y no se cuenta con los recursos, tiempo o el conocimiento para poder administrarlo, es conveniente optar por clústeres autoadministrados como ECS + Fargate, que ofrecen dinamismo y escalado tanto para agrandar como para achicar en función de la demanda, sin la intervención constante de un rol DevOps o SRE que esté monitoreando, subiendo y bajando instancias, o administrando los recursos del clúster. Para que toda esta magia ocurra, y podamos controlarla, tenemos que tener en cuenta que existe un auto scaling2 (Documentación AWS) que se encarga de agrandar o achicar el clúster de ECS de acuerdo a nuestros requerimientos.
Ahora me gustaría preguntarles: ¿qué les parecieron estas tecnologías serverless de AWS? Y si ya las probaron antes, ¿cómo les resultaron? Dejo abiertos los comentarios para leer sus opiniones. Cualquier duda que tengan, pueden escribirme a demian.sclausero@fluxit.com.ar o también dejar un comentario en esta nota, y en conjunto vamos a poder aprender más de este mundo infinito que nos da AWS. Desde ya, ¡gracias por leer el artículo!
Referencias
1 docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/AWS_Fargate.html
2 https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html
Fuentes
https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/application.html
