¡Hola a todos! Me llamo Kirill, soy CTO en Adapty. Gran parte de nuestra arquitectura está en AWS, y hoy les contaré cómo hemos reducido los costos de servidores en 3 veces gracias al uso de instancias spot en el entorno de producción, así como cómo configurarlas para autoescalado. Primero haré una revisión de cómo funciona, y luego una guía detallada para el despliegue.
¿Qué son las instancias spot?
instancias spot son servidores de otros usuarios de AWS que están inactivos en este momento y los venden con un gran descuento (Amazon dice hasta un 90%, según nuestra experiencia es aproximadamente 3x, varía según la región, AZ y tipo de instancia). Su principal diferencia con las instancias normales es que pueden apagarse en cualquier momento. Por eso, durante mucho tiempo pensamos que era aceptable usarlas para entornos de desarrollo, o para tareas que requieren cálculos de algún tipo, guardando resultados intermedios en S3 o en una base de datos, pero no para producción. Existen soluciones de terceros que permiten usar instancias spot en producción, pero para nuestro caso tienen muchas limitaciones, así que no las implementamos. El enfoque descrito en este artículo funciona completamente dentro de las funcionalidades estándar de AWS, sin scripts adicionales, cron jobs, etc.
A continuación, proporcionaré algunas capturas de pantalla que muestran la historia de precios de las instancias spot.
m5.large en la región eu-west-1 (Irlanda). El precio ha sido mayormente estable durante 3 meses, actualmente el ahorro es de 2.9x.
m5.large en la región us-east-1 (Virginia del Norte). El precio cambia constantemente durante 3 meses, actualmente el ahorro está entre 2.3x y 2.8x dependiendo de la zona de disponibilidad.
t3.small en la región us-east-1 (Virginia del Norte). El precio ha sido estable durante 3 meses, actualmente el ahorro es de 3.4x.
Arquitectura del servicio
La arquitectura básica del servicio, del que hablaremos en este artículo, se muestra en el diagrama a continuación.
Application Load Balancer → EC2 Target Group → Elastic Container Service
Se utiliza un Application Load Balancer (ALB) como balanceador que envía solicitudes al EC2 Target Group (TG). TG se encarga de abrir los puertos en las instancias para el ALB y enlazarlos con los puertos de los contenedores del Elastic Container Service (ECS). ECS es análogo a Kubernetes en AWS, dedicado a la gestión de contenedores Docker.
En una instancia pueden haber varios contenedores en funcionamiento con los mismos puertos, por lo que no podemos asignarlos de manera fija. ECS informa al TG que está iniciando una nueva tarea (en la terminología de Kubernetes se llama pod), verifica los puertos libres en la instancia y asigna uno de ellos para la tarea que se está iniciando. Además, el TG verifica regularmente si la instancia y la API están operativas mediante un chequeo de salud, y si detecta algún problema, deja de enviar solicitudes a dicha instancia.
Grupos de Auto Scaling de EC2 + Proveedores de Capacidad de ECS
En el diagrama anterior no se muestra el servicio de Grupos de Auto Scaling de EC2 (ASG). Por el nombre se puede entender que es responsable de escalar instancias. Sin embargo, hasta hace poco, AWS no tenía la capacidad integrada de gestionar la cantidad de máquinas en funcionamiento desde ECS. ECS permitía escalar la cantidad de tareas, por ejemplo, en función del uso de CPU, RAM o el número de solicitudes. Pero si las tareas ocupaban todas las instancias libres, nuevas máquinas no se levantaban automáticamente.
Esto cambió con la llegada de los Proveedores de Capacidad de ECS (ECS CP). Ahora, cada servicio en ECS se puede vincular a un ASG, y si las tareas no caben en las instancias en funcionamiento, se levantarán nuevas (pero dentro de los límites establecidos del ASG). Esto también funciona al revés; si ECS CP ve instancias inactivas sin tareas, le ordenará al ASG que las apague. ECS CP tiene la capacidad de especificar un porcentaje objetivo de carga de las instancias para que un número determinado de máquinas siempre esté disponible para escalar rápidamente las tareas, hablaré de esto más adelante.
Plantillas de Lanzamiento de EC2
El último servicio del que hablaré, antes de pasar a la descripción detallada de la creación de esta infraestructura, son las Plantillas de Lanzamiento de EC2. Permiten crear una plantilla según la cual se iniciarán todas las máquinas, evitando tener que repetirlo cada vez desde cero. Aquí se puede elegir el tipo de máquina que se va a iniciar, el grupo de seguridad, la imagen de disco y muchos otros parámetros. También se pueden especificar datos de usuario que se cargarán en todas las instancias iniciadas. En los datos de usuario se pueden ejecutar scripts; por ejemplo, se puede editar el contenido del archivo .
Uno de los parámetros de configuración más importantes en el contexto de este artículo es =true. Si este parámetro está habilitado, tan pronto como ECS recibe la señal de que la instancia spot está siendo retirada, cambia el estado de todas las tareas que se están ejecutando en ella a Draining. No se asignarán nuevas tareas a esta instancia; si hay tareas que quieren ser desplegadas en ella, se cancelan. También dejarán de llegar solicitudes del balanceador. La notificación de eliminación de la instancia llega 2 minutos antes del evento real. Por lo tanto, si su servicio no realiza tareas que duren más de 2 minutos y no guarda nada en el disco, puede usar instancias spot sin pérdida de datos.
En cuanto al disco, AWS recientemente posible el uso de Elastic File System (EFS) junto con ECS, con este esquema ni siquiera el disco es un obstáculo, aunque no lo hemos probado, ya que en principio no necesitamos el disco para almacenar estado. Por defecto, después de recibir SIGINT (que se envía en el momento en que la tarea cambia a estado Draining), todas las tareas en funcionamiento se detendrán en 30 segundos, incluso si no han podido completarse; este tiempo puede ajustarse con el parámetro . Lo principal es no configurarlo más de 2 minutos para las máquinas spot.
Creación del servicio
Pasamos directamente a la creación del servicio descrito. En el proceso, describiré algunos puntos útiles adicionales que no se mencionaron anteriormente. En general, es una guía paso a paso, pero no consideraré casos muy básicos o, por el contrario, muy específicos. Todas las acciones se realizan en la consola visual de AWS, pero se pueden reproducir programáticamente utilizando CloudFormation o Terraform. En Adapty utilizamos Terraform.
Plantilla de lanzamiento de EC2
En este servicio se crea la configuración de las máquinas que se utilizarán. La gestión de las plantillas se lleva a cabo en la sección EC2 -> Instances -> Launch templates.
Amazon Machine Image (AMI) — especificamos la imagen de disco con la que se iniciarán todas las instancias. Para ECS, en la mayoría de los casos, se debe utilizar la imagen optimizada de Amazon. Se actualiza regularmente y contiene todo lo necesario para el funcionamiento de ECS. Para conocer el ID de imagen actual, accedemos a la página , seleccionamos la región utilizada y copiamos el AMI ID correspondiente. Por ejemplo, para la región us-east-1, el ID actual al momento de escribir este artículo es ami-00c7c1cf5bdc913ed. Este ID debe insertarse en el apartado Specify a custom value.
Tipo de instancia — especificamos el tipo de instancia. Elija el que mejor se adapte a sus necesidades.
Par de claves (inicio de sesión) — especificamos el certificado que se utilizará para conectarse a la instancia a través de SSH, si es necesario.
Configuración de red — especificamos los parámetros de la red. Plataforma de redes en la mayoría de los casos debe ser Virtual Private Cloud (VPC). Grupos de seguridad — grupos de seguridad para sus instancias. Dado que utilizaremos un balanceador antes de las instancias, le recomiendo especificar aquí un grupo que permita conexiones entrantes solo desde el balanceador. Es decir, tendrá 2 grupos de seguridad, uno para el balanceador que permite conexiones entrantes desde cualquier lugar a través de los puertos 80 (http) y 443 (https), y el segundo para las máquinas que permite conexiones entrantes a través de cualquier puerto del grupo del balanceador. Las conexiones salientes en ambos grupos deben ser abiertas a través del protocolo TCP en todos los puertos a todas las direcciones. Puede restringir los puertos y direcciones para las conexiones salientes, pero entonces debe monitorear constantemente que no intente acceder a ningún puerto cerrado.
Almacenamiento (volúmenes) — especificamos los parámetros de los discos para las máquinas. El tamaño del disco no puede ser menor que lo establecido en el AMI, para ECS Optimized — 30 GiB.
Detalles avanzados — especificamos parámetros adicionales.
Opción de compra — queremos comprar instancias de tipo spot. Queremos hacerlo, pero aquí no marcaremos esta casilla, lo configuraremos en el Grupo de Auto Scaling, donde hay más opciones.
Perfil de instancia IAM — especificamos el rol bajo el cual se lanzarán las instancias. Para que las instancias funcionen en ECS, necesitan permisos que generalmente se encuentran en el rol ecsInstanceRole. En algunos casos, puede ser creada. Si no, aquí hay información sobre cómo hacerlo. Después de crearla, la especificamos en la plantilla.
A continuación hay muchos parámetros, en su mayoría se pueden dejar los valores por defecto, pero cada uno de ellos tiene una descripción clara. Siempre incluyo los parámetros de instancia optimizada para EBS y T2/T3 Unlimited, si se utilizan instancias.
Datos del usuario — especificamos los datos del usuario. Editaremos el archivo /etc/ecs/ecs.config, donde se encuentra la configuración del agente ECS.
Ejemplo de cómo podría lucir los datos del usuario:
#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.configECS_CLUSTER=DemoApiClusterProd — el parámetro indica que la instancia pertenece a un clúster con el nombre especificado, es decir, este clúster podrá ejecutar sus tareas en este servidor. Aún no hemos creado un clúster, pero al crearlo usaremos este nombre.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — el parámetro indica que al recibir la señal para apagar la instancia de spot, todas las tareas en ella deben pasar al estado Draining.
ECS_CONTAINER_STOP_TIMEOUT=1m — el parámetro indica que tras recibir la señal SIGINT, todas las tareas tienen 1 minuto antes de ser terminadas.
ECS_ENGINE_AUTH_TYPE=docker — el parámetro indica que se utiliza el esquema de autorización de Docker como mecanismo de autorización.
ECS_ENGINE_AUTH_DATA=... — parámetros de conexión a un registro de contenedores privado, donde se almacenan tus imágenes de Docker. Si es público, no es necesario indicar nada.
En este artículo usaré una imagen pública de Docker Hub, así que no es necesario indicar parámetros. ECS_ENGINE_AUTH_TYPE y ECS_ENGINE_AUTH_DATA no es necesario.
Es bueno saber: se recomienda actualizar regularmente el AMI, ya que en las nuevas versiones se actualizan las versiones de Docker, Linux, el agente ECS, etc. Para no olvidar esto, puedes sobre el lanzamiento de nuevas versiones. Puedes recibir notificaciones por correo electrónico y actualizar manualmente, o puedes escribir una función Lambda que cree automáticamente una nueva versión del Launch Template con el AMI actualizado.
Grupo de escalado automático de EC2
El Grupo de Escalado Automático se encarga de iniciar y escalar instancias. La gestión de grupos se realiza en la sección EC2 -> Escalado automático -> Grupos de escalado automático.
Plantilla de lanzamiento — seleccionamos la plantilla que se creó en el paso anterior. Dejamos la versión predeterminada.
Opciones de compra y tipos de instancia — indicamos los tipos de instancias para el clúster. Adherirse a la plantilla de lanzamiento utiliza el tipo de instancia de la Plantilla de Lanzamiento. Combinar opciones de compra y tipos de instancia permite configurar los tipos de instancia de forma flexible. Lo usaremos.
Base de On-Demand opcional — la cantidad de instancias normales, no de spot, que siempre estarán funcionando.
Porcentaje de On-Demand sobre la base — la proporción porcentual de instancias normales y de spot, 50-50 distribuirá de manera uniforme, 20-80 significa que por cada instancia normal se lanzarán 4 de spot. En este ejemplo, indicaré 50-50, pero en realidad, a menudo hacemos 20-80, en algunos casos 0-100.
Tipos de instancia — aquí se pueden especificar tipos adicionales de instancias que se utilizarán en el clúster. Nunca lo hemos utilizado porque no entiendo muy bien el sentido de esta historia. Puede que se deba a los límites en tipos específicos de instancias, pero es fácil aumentarlos a través del soporte. Si conoces una aplicación, estaré encantado de leerla en los comentarios)
Red — configuraciones de la red, elige VPC y subredes para las máquinas, en la mayoría de los casos es mejor seleccionar todas las subredes disponibles.
Balanceo de carga — configuraciones del balanceador, pero esto lo haremos por separado, aquí no cambiamos nada. Comprobaciones de salud también se configurarán más tarde.
Tamaño del grupo — especificamos los límites en el número de máquinas en el clúster y la cantidad deseada de máquinas al inicio. El número de máquinas en el clúster nunca será menor que el mínimo especificado y mayor que el máximo, incluso si las métricas indican que debería producirse una escalabilidad.
Políticas de escalabilidad — parámetros de escalabilidad, pero escalaremos basándonos en las tareas de ECS en ejecución, así que configuraremos la escalabilidad más tarde.
Protección contra la reducción de instancias — protección de las instancias contra la eliminación al escalar hacia abajo. Activamos esto para que el ASG no elimine la máquina que tiene tareas en ejecución. Desactivar la protección para instancias sin tareas será proporcionado por el Proveedor de Capacidad ECS.
Añadir etiquetas — se pueden especificar etiquetas para las instancias (para esto debe estar marcada la opción Etiquetar nuevas instancias). Recomiendo especificar la etiqueta Nombre, así todas las instancias que se inician en el grupo tendrán el mismo nombre, lo que facilita su visualización en la consola.
Después de crear el grupo, ábrelo y ve a la sección de Configuraciones avanzadas, porque en la etapa de creación no se ven todas las opciones en la consola.
Políticas de terminación — reglas que se consideran al eliminar instancias. Se aplican en orden. Normalmente utilizamos las reglas como en la imagen de abajo. Primero se eliminan las instancias con el Launch Template más antiguo (por ejemplo, si hemos actualizado el AMI, se creó una nueva versión, pero todas las instancias lograron actualizarse a ella). Luego se seleccionan las instancias que están más cerca de la próxima hora de cálculo por facturación. Y después se eligen las más antiguas por fecha de lanzamiento.
Es bueno saberpara actualizar todas las máquinas en el clúster, es conveniente usar . Si combinamos esto con la función Lambda del paso anterior, tendremos un sistema de actualización de instancias completamente automatizado. Antes de actualizar todas las máquinas, es necesario desactivar la protección contra reducción de instancias para todas las instancias en el grupo. No la configuración en el grupo, sino la protección de las máquinas mismas, lo que se realiza en la pestaña de gestión de instancias.
Application Load Balancer y EC2 Target Group
El balanceador se crea en la sección EC2 → Load Balancing → Load Balancers. Usaremos Application Load Balancer; puedes leer sobre la comparación de diferentes tipos de balanceadores en .
Listeners — tiene sentido habilitar los puertos 80 y 443 y hacer un redireccionamiento del 80 al 443 posteriormente mediante reglas del balanceador.
Zonas de Disponibilidad — en la mayoría de los casos elegimos todas las zonas de disponibilidad.
Configurar Seguridad — aquí se especifica el certificado SSL para el balanceador, la opción más conveniente es en ACM. Sobre las diferencias Política de Seguridad puedes leer en , puedes dejar la seleccionada por defecto ELBSecurityPolicy-2016-08. Después de crear el balanceador, verás su nombre DNS, al que se debe configurar un CNAME para tu dominio. Por ejemplo, así se ve en Cloudflare.
Grupo de Seguridad — creamos o elegimos un grupo de seguridad para el balanceador, sobre esto ya se escribió un poco más arriba en la sección EC2 Launch Template → Configuración de red.
Grupo objetivo — creamos un grupo que se encarga de enrutar solicitudes del balanceador a las máquinas y verificar su disponibilidad, para reemplazarlas en caso de problemas. Tipo de objetivo debe ser Instance, Protocolo y Puerto cualquiera, si utilizas HTTPS para la comunicación entre el balanceador y las instancias, entonces debes cargar el certificado en ellas. En este ejemplo no lo haremos, simplemente dejaremos el puerto 80.
Comprobaciones de salud — parámetros para comprobar la funcionalidad del servicio. En el servicio real, esto debería ser una solicitud separada que implemente partes importantes de la lógica de negocio; en este ejemplo, dejaré la configuración por defecto. Luego puedes seleccionar el intervalo de solicitudes, el tiempo de espera, códigos de respuesta exitosos, etc. En nuestro ejemplo, indicaremos códigos de éxito de 200-399, porque la imagen de Docker que se utilizará devuelve el código 304.
Registrar Targets — aquí se eligen las máquinas para el grupo, pero en nuestro caso esto lo hará ECS, así que simplemente omitimos este paso.
Es bueno saber: a nivel del balanceador se pueden habilitar registros que se guardarán en S3 en un formato específico. . Desde allí se pueden exportar a servicios externos de análisis, o se pueden realizar consultas SQL directamente sobre los datos en S3 con . Esto es conveniente y funciona sin ningún código adicional. También recomiendo configurar la eliminación de registros del bucket S3 después de un período de tiempo determinado.
Definición de Tarea ECS
En los pasos anteriores creamos todo lo relacionado con la infraestructura del servicio, ahora pasamos a describir los contenedores que vamos a ejecutar. Esto se hace en la sección ECS → Definiciones de Tareas.
Compatibilidad de tipo de lanzamiento — seleccionamos EC2.
Rol IAM de ejecución de tareas — seleccionamos ecsTaskExecutionRole. Con él se escriben registros, se otorga acceso a variables secretas, etc.
En la sección Definiciones de Contenedor, hacemos clic en Añadir Contenedor.
Imagen — enlace a la imagen con el código del proyecto, en este caso utilizaré una imagen pública de Docker Hub .
Límites de Memoria — límites de memoria para el contenedor. Límite Duro — límite duro, si el contenedor supera el valor indicado, se ejecutará el comando docker kill, el contenedor morirá de inmediato. Límite Blando — límite blando, el contenedor puede superar el valor indicado, pero al colocar tareas en las máquinas se considerará este parámetro. Por ejemplo, si una máquina tiene 4 GiB de memoria RAM, y el límite blando del contenedor es de 2048 MiB, entonces se pueden ejecutar un máximo de 2 tareas con este contenedor en esa máquina. En realidad, 4 GiB de memoria RAM son un poco menos que 4096 MiB, esto se puede ver en la pestaña Instancias de ECS en el clúster. El límite blando no puede ser mayor que el límite duro. Es importante entender que si hay varios contenedores en una tarea, sus límites se suman.
Asignaciones de Puertos — en Puerto Host indicamos 0, esto significa que el puerto se asignará de manera dinámica, será rastreado por el Grupo de Destino. Puerto del Contenedor — el puerto en el que funciona tu aplicación, a menudo se establece en el comando de ejecución o en el código de tu aplicación, Dockerfile, etc. Para nuestro ejemplo, utilizamos 3000, porque está indicado en la imagen utilizada.
Chequeo de Salud — parámetros para verificar la operatividad del contenedor, no confundir con el que se configura en el Grupo de Destino.
Entorno — configuraciones del entorno. Unidades de CPU — similar to Memory limits, but for the processor. Each CPU core equals 1024 units, so if there's a dual-core processor on the server and the container has a value of 512 set, then up to 4 tasks can be run on that server with this container. CPU units always correspond to the number of cores; there cannot be slightly fewer than in the case of memory.
Comando — command to start a service within the container, with all parameters specified via commas. This can be gunicorn, npm, etc. If not specified, the CMD directive from Dockerfile will be used. We specify npm,start.
Variables de entorno — container environment variables. These can be plain text data or secret variables from the o .
Almacenamiento y Registros — here we will set up logging in CloudWatch Logs (the logging service from AWS). Simply check the Auto-configure CloudWatch Logs option. After creating the Task Definition, a log group will automatically be created in CloudWatch. By default, logs are stored indefinitely in it; I recommend changing the Retention period from Never Expire to the required duration. This is done in CloudWatch Log groups; you need to click on the current period and select a new one.
ECS Cluster y ECS Capacity Provider
We go to the ECS → Clusters section to create a cluster. As a template, we choose EC2 Linux + Networking.
Nombre del clúster — very important, we use the same name here as specified in the Launch Template under the parameter ECS_CLUSTER, in our case — DemoApiClusterProd. We check the Create an empty cluster option. Optionally, you can enable Container Insights to view service metrics in CloudWatch. If you’ve done everything correctly, you will see the machines created in the Auto Scaling group in the ECS Instances section.
We move to the Capacity Providers tab and create a new one. Reminder, this is needed to manage the creation and shutdown of machines depending on the number of running ECS tasks. It is important to note that the provider can only be tied to one group.
Auto Scaling group — we select the previously created group.
Escalado gestionado — we enable this so the provider can scale the service.
Capacidad objetivo % ¿Qué porcentaje de carga de las máquinas necesitamos para las tareas? Si se establece al 100%, todas las máquinas siempre estarán ocupadas con las tareas en ejecución. Si se establece al 50%, la mitad de las máquinas estarán siempre libres. En este caso, si hay un repentino aumento en la carga, los nuevos taxis se asignarán inmediatamente a las máquinas libres, sin necesidad de esperar a que se desplieguen las instancias.
Protección de terminación gestionada Si lo activamos, este parámetro permite al proveedor eliminar la protección de eliminación de las instancias. Esto ocurre cuando no hay tareas activas en la máquina y permite el porcentaje de capacidad objetivo.
Servicio ECS y configuración de escalado
Último paso :) Para crear un servicio, hay que acceder al clúster creado anteriormente en la pestaña Servicios.
Tipo de lanzamiento Hay que hacer clic en Cambiar a la estrategia del proveedor de capacidad y seleccionar el proveedor creado anteriormente.
Definición de tareas Seleccionamos la Definición de Tareas creada anteriormente y su revisión.
Nombre del servicio Para no confundirnos, siempre indicamos el mismo nombre que la Definición de Tareas.
Tipo de servicio Siempre Replica.
Número de tareas Número deseado de tareas activas en el servicio. Este parámetro se controla mediante el escalado, pero aún así debe especificarse.
Porcentaje mínimo saludable y Porcentaje máximo Determinan el comportamiento de las tareas durante el despliegue. Los valores por defecto son 100 y 200, lo que indica que en el momento del despliegue, el número de tareas se duplicará y luego regresará al deseado. Si tienes 1 tarea funcionando, min=0 y max=100, entonces durante el despliegue será eliminada y después se levantará una nueva, es decir, habrá inactividad. Si hay 1 tarea en funcionamiento, min=50 y max=150, entonces el despliegue no ocurrirá porque no se puede dividir una tarea en dos partes ni aumentarla en un 50%.
Tipo de despliegue Mantendremos la actualización continua.
Plantillas de colocación Reglas para la colocación de tareas en las máquinas. Por defecto está configurada como Distribución Balanceada por AZ, lo que significa que cada nueva tarea se colocará en una nueva instancia hasta que se levantan máquinas en todas las zonas de disponibilidad. Normalmente, hacemos BinPack para CPU y Spread para AZ; con esta política, las tareas se colocan de manera compacta en una máquina según el CPU. Si es necesaria una nueva máquina, se crea en una nueva zona de disponibilidad.
Tipo de balanceador de carga Seleccionamos el Balanceador de Carga de Aplicación.
Rol IAM del servicio Elegimos ecsServiceRole.
Nombre del balanceador de carga Seleccionamos el balanceador creado anteriormente.
Período de gracia para la verificación de salud Pausa antes de realizar las verificaciones de operatividad después de la implementación de una nueva tarea; normalmente establecemos 60 segundos.
Contenedor a equilibrar En el campo Nombre del grupo objetivo, seleccionamos el grupo creado anteriormente, y todo se llenará automáticamente.
Escalado automático del servicio Parámetros de escalado del servicio. Seleccionamos Configurar escalado automático del servicio para ajustar la cantidad deseada de su servicio. Establecemos el número mínimo y máximo de tareas al escalar.
Rol de IAM para el escalado automático del servicio Elegimos AWSServiceRoleForApplicationAutoScaling_ECSService.
Políticas de escalado automático de tareas Reglas para el escalado. Hay 2 tipos:
- Seguimiento de objetivos Seguimiento de una métrica objetivo (uso de CPU/RAM o número de solicitudes por tarea). Por ejemplo, queremos que la carga promedio del procesador sea del 85%; cuando supere este valor, se añadirán nuevas tareas hasta alcanzar el valor objetivo. Si la carga es inferior, las tareas se eliminarán, a menos que esté habilitada la protección contra escalado hacia abajo (Deshabilitar escalado hacia abajo).
- Escalado por pasos Reacción a un evento arbitrario. Aquí se puede configurar la reacción a cualquier evento (alarma de CloudWatch); cuando ocurra, se puede añadir o eliminar la cantidad especificada de tareas, o indicar un número exacto de tareas.
El servicio puede tener varias reglas de escalado, lo cual puede ser útil; lo principal es asegurarse de que no entren en conflicto entre sí.
Conclusión
Si seguiste las instrucciones y utilizaste la misma imagen de Docker, tu servicio debería devolver esta página.
- Hemos creado una plantilla a partir de la cual se lanzan todas las máquinas en el servicio. También hemos aprendido a actualizar las máquinas al modificar la plantilla.
- Hemos configurado el manejo de la señal de detención de la instancia spot, por lo que, dentro de un minuto, después de recibirla, todas las tareas en ejecución se eliminarán de la máquina, así nada se pierde ni se interrumpe.
- Hemos levantado un balanceador para distribuir la carga equitativamente entre las máquinas.
- Hemos creado un servicio que funciona en instancias spot, lo que reduce los costos de las máquinas aproximadamente en 3 veces.
- Hemos configurado el escalado automático en ambas direcciones para manejar el aumento de cargas, pero al mismo tiempo no pagar por inactividad.
- Estamos utilizando un Proveedor de Capacidad para que la aplicación gestione la infraestructura (máquinas), y no al revés.
- Hicimos bien.
Si tienes picos de carga predecibles, como cuando publicitas en un gran envío de correos electrónicos, puedes configurar el escalado según .
También se puede realizar escalado basado en datos de diferentes partes de su sistema. Por ejemplo, tenemos funcionalidad a los usuarios de la aplicación móvil. A veces, la campaña se envía a más de 1 millón de personas. Después de tal envío, siempre se observa un gran aumento en las solicitudes a la API, ya que muchos usuarios acceden a la aplicación al mismo tiempo. Así que, si vemos que en la cola para el envío de promociones push hay un aumento significativo en comparación con las métricas estándar, podemos iniciar varias máquinas y tareas adicionales de inmediato para estar listos para la carga.
Estaré encantado si comparten en los comentarios casos interesantes de uso de instancias spot y ECS o algo sobre escalado.
Pronto habrá artículos sobre cómo procesamos miles de eventos analíticos por segundo en una pila principalmente sin servidor (con dinero) y cómo está organizado el despliegue de servicios utilizando GitLab CI y Terraform Cloud.
¡Síguenos, será interesante!
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Utilizan instancias spot en producción?
22,2%Sí6
66,7%No18
11,1%Me enteré de ellos a través de un artículo, planeo usarlos3
Votaron 27 usuarios. 5 usuarios se abstuvieron.
Fuente: habr.com
