¡Hola a todos! Mi nombre es Kirill, soy CTO en Adapty. La mayor parte de nuestra arquitectura está en AWS y hoy hablaré sobre cómo redujimos los costos del servidor 3 veces mediante el uso de instancias puntuales en un entorno de producción, así como sobre cómo configurar su escalado automático. Primero habrá una descripción general de cómo funciona y luego instrucciones detalladas para comenzar.
¿Qué son las instancias puntuales?
Las instancias son servidores de otros usuarios de AWS que actualmente están inactivos y los venden con un gran descuento (Amazon escribe hasta el 90%, en nuestra experiencia ~3 veces, varía según la región, AZ y el tipo de instancia). Su principal diferencia con los habituales es que pueden apagarse en cualquier momento. Por eso, durante mucho tiempo creímos que lo normal era utilizarlos para entornos vírgenes, o para tareas de cálculo de algo, con resultados intermedios guardados en S3 o en la base de datos, pero no para ventas. Existen soluciones de terceros que permiten utilizar spots en producción, pero en nuestro caso hay muchos apoyos, por lo que no los implementamos. El enfoque descrito en el artículo funciona completamente dentro de la funcionalidad estándar de AWS, sin scripts, coronas, etc.
A continuación se muestran algunas capturas de pantalla que muestran el historial de precios de las instancias spot.
m5.large en la región eu-west-1 (Irlanda). El precio se ha mantenido prácticamente estable durante 3 meses y actualmente ahorra 2.9 veces.
m5.large en la región us-east-1 (norte de Virginia). El precio cambia constantemente durante 3 meses, ahorrando actualmente de 2.3x a 2.8x según la zona de disponibilidad.
t3.small en la región us-east-1 (norte de Virginia). El precio se ha mantenido estable durante 3 meses y actualmente ahorra 3.4 veces.
Arquitectura de servicio
La arquitectura básica del servicio del que hablaremos en este artículo se muestra en el siguiente diagrama.
Balanceador de carga de aplicaciones → Grupo objetivo EC2 → Servicio de contenedor elástico
El balanceador de carga de aplicaciones (ALB) se utiliza como balanceador, que envía solicitudes al grupo objetivo (TG) de EC2. TG es responsable de abrir puertos en instancias para ALB y conectarlos a puertos de contenedores de Elastic Container Service (ECS). ECS es un análogo de Kubernetes en AWS, que administra contenedores Docker.
Una instancia puede tener varios contenedores en ejecución con los mismos puertos, por lo que no podemos configurarlos de forma fija. ECS le dice a TG que está lanzando una nueva tarea (en la terminología de Kubernetes, esto se llama pod), busca puertos libres en la instancia y asigna uno de ellos a la tarea iniciada. TG también verifica periódicamente si la instancia y la API están funcionando mediante una verificación de estado y, si detecta algún problema, deja de enviar solicitudes allí.
Grupos de Auto Scaling de EC2 + Proveedores de capacidad de ECS
El diagrama anterior no muestra el servicio EC2 Auto Scaling Groups (ASG). Por el nombre se puede entender que es responsable de escalar instancias. Sin embargo, hasta hace poco, AWS no tenía una capacidad integrada para administrar la cantidad de máquinas en ejecución desde ECS. ECS hizo posible escalar la cantidad de tareas, por ejemplo, según el uso de CPU, RAM o la cantidad de solicitudes. Pero si las tareas ocupaban todas las instancias libres, entonces no se creaban automáticamente nuevas máquinas.
Esto ha cambiado con la llegada de los proveedores de capacidad de ECS (ECS CP). Ahora cada servicio en ECS se puede asociar con un ASG, y si las tareas no caben en las instancias en ejecución, se generarán otras nuevas (pero dentro de los límites de ASG establecidos). Esto también funciona en la dirección opuesta: si ECS CP ve instancias inactivas sin tareas, dará el comando ASG para cerrarlas. ECS CP tiene la capacidad de especificar un porcentaje objetivo de carga de instancia, de modo que una cierta cantidad de máquinas estén siempre libres para tareas de escalamiento rápido; hablaré de esto un poco más adelante.
Plantillas de lanzamiento de EC2
El último servicio del que hablaré antes de entrar en detalles sobre la creación de esta infraestructura son las plantillas de lanzamiento de EC2. Le permite crear una plantilla según la cual se iniciarán todas las máquinas, para no repetir esto desde cero cada vez. Aquí puede seleccionar el tipo de máquina a iniciar, grupo de seguridad, imagen de disco y muchos otros parámetros. También puede especificar los datos del usuario que se cargarán en todas las instancias lanzadas. Puede ejecutar scripts en datos de usuario, por ejemplo, puede editar el contenido de un archivo .
Uno de los parámetros de configuración más importantes para este artículo es = cierto. Si este parámetro está habilitado, tan pronto como ECS reciba una señal de que se está eliminando una instancia puntual, transfiere todas las tareas que trabajan en ella al estado de Drenaje. No se asignarán nuevas tareas a esta instancia; si hay tareas que quieran implementarse en ella ahora mismo, se cancelarán. Las solicitudes del equilibrador también dejan de llegar. La notificación de eliminación de instancia llega 2 minutos antes del evento real. Por lo tanto, si su servicio no realiza tareas de más de 2 minutos y no guarda nada en el disco, puede utilizar instancias puntuales sin perder datos.
Respecto al disco: AWS recientemente Es posible utilizar Elastic File System (EFS) junto con ECS, con este esquema ni siquiera el disco es un obstáculo, pero no lo intentamos, ya que en principio no necesitamos el disco para almacenar el estado. De forma predeterminada, después de recibir SIGINT (enviado cuando una tarea se transfiere al estado Drenaje), todas las tareas en ejecución se detendrán después de 30 segundos, incluso si aún no se han completado; puede cambiar este tiempo usando el parámetro . Lo principal es no configurarlo por más de 2 minutos para máquinas puntuales.
Creando un servicio
Pasemos a crear el servicio descrito. En el proceso, describiré además varios puntos útiles que no se mencionaron anteriormente. En general, esta es una instrucción paso a paso, pero no consideraré algunos 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 mediante programación mediante CloudFormation o Terraform. En Adapty utilizamos Terraform.
Plantilla de lanzamiento EC2
Este servicio crea una configuración de las máquinas que se utilizarán. Las plantillas se administran en la sección EC2 -> Instancias -> Plantillas de lanzamiento.
Imagen de máquina de Amazon (AMI) — especifique la imagen de disco con la que se lanzarán todas las instancias. Para ECS, en la mayoría de los casos vale la pena utilizar la imagen optimizada de Amazon. Se actualiza periódicamente y contiene todo lo necesario para que ECS funcione. Para conocer el ID de la imagen actual, vaya a la página , seleccione la región que está utilizando y copie el ID de AMI 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 elemento Especificar un valor personalizado.
Tipo de instancia — indicar el tipo de instancia. Elige el que mejor se adapte a tu tarea.
Par de claves (inicio de sesión) — especifique un certificado con el que pueda conectarse a la instancia a través de SSH, si es necesario.
Configuración de red — especificar los parámetros de la red. Plataforma de networking en la mayoría de los casos debería existir una Nube Privada Virtual (VPC). Grupos de seguridad — grupos de seguridad para sus instancias. Dado que usaremos un equilibrador delante de las instancias, recomiendo especificar aquí un grupo que permita conexiones entrantes solo desde el equilibrador. Es decir, tendrá 2 grupos de seguridad, uno para el balanceador, que permite conexiones entrantes desde cualquier lugar en los puertos 80 (http) y 443 (https), y el segundo para máquinas, que permite conexiones entrantes en cualquier puerto del grupo balanceador. . Las conexiones salientes en ambos grupos deben abrirse utilizando el protocolo TCP a todos los puertos a todas las direcciones. Puede limitar los puertos y direcciones para las conexiones salientes, pero luego debe controlar constantemente que no esté intentando acceder a algo en un puerto cerrado.
Almacenamiento (volúmenes) — especifique los parámetros del disco para las máquinas. El tamaño del disco no puede ser menor que el especificado en la AMI; para ECS Optimized es 30 GiB.
Detalles avanzados — especificar parámetros adicionales.
Opción de compra – si queremos comprar instancias al contado. Queremos, pero no marcaremos esta casilla aquí; lo configuraremos en el Grupo de Auto Scaling, hay más opciones allí.
Perfil de instancia de IAM — indicar el rol con el que se lanzarán las instancias. Para que las instancias se ejecuten en ECS, necesitan permisos, que generalmente se encuentran en el rol ecsInstanceRole. En algunos casos se puede crear, si no, entonces aquí sobre cómo hacer esto. Tras la creación, lo indicamos en la plantilla.
A continuación hay muchos parámetros, básicamente puedes dejar valores predeterminados en todas partes, pero cada uno de ellos tiene una descripción clara. Siempre habilito la instancia optimizada para EBS y las opciones ilimitadas T2/T3 si se usan instancias.
Tiempo de utilización — indicar datos del usuario. Editaremos el archivo /etc/ecs/ecs.config, que contiene la configuración del agente ECS.
Un ejemplo de cómo se verían 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 dado, es decir, este clúster podrá colocar sus tareas en este servidor. Aún no hemos creado un clúster, pero usaremos este nombre al crearlo.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — el parámetro especifica que cuando se recibe una señal para desactivar una instancia puntual, todas las tareas en ella deben transferirse al estado Drenaje.
ECS_CONTAINER_STOP_TIMEOUT=1m - el parámetro especifica que después de recibir una señal SIGINT, todas las tareas tienen 1 minuto antes de ser eliminadas.
ECS_ENGINE_AUTH_TYPE=docker — el parámetro indica que el esquema Docker se utiliza como mecanismo de autorización
ECS_ENGINE_AUTH_DATA=... — parámetros de conexión al registro de contenedores privado, donde se almacenan sus imágenes de Docker. Si es público, entonces no es necesario especificar nada.
Para los propósitos de este artículo, usaré una imagen pública de Docker Hub, así que especifique los parámetros. ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA no necesito
Lo que conviene saber: Se recomienda actualizar la AMI periódicamente, porque las nuevas versiones actualizan las versiones de Docker, Linux, agente ECS, etc. Para no olvidarse de esto, puede sobre el lanzamiento de nuevas versiones. Puede recibir notificaciones por correo electrónico y actualizarlas manualmente, o puede escribir una función Lambda que creará automáticamente una nueva versión de Launch Template con una AMI actualizada.
Grupo de escalado automático EC2
Auto Scaling Group es responsable de lanzar y escalar instancias. Los grupos se administran en la sección EC2 -> Auto Scaling -> Grupos de Auto Scaling.
Plantilla de lanzamiento — seleccione la plantilla creada en el paso anterior. Dejamos la versión por defecto.
Opciones de compra y tipos de instancias — especifique 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 instancias le permite configurar tipos de instancias de manera flexible. Lo usaremos.
Base bajo demanda opcional — la cantidad de instancias regulares, no puntuales, que siempre funcionarán.
Porcentaje bajo demanda por encima de la base — proporción porcentual de instancias regulares y puntuales, 50-50 se distribuirán equitativamente, 20-80 por cada instancia regular se aumentarán 4 puntuales. Para los propósitos de este ejemplo, indicaré 50-50, pero en realidad lo más frecuente es que sea 20-80, en algunos casos 0-100.
Tipos de instancia — aquí puede especificar tipos adicionales de instancias que se utilizarán en el clúster. Nunca lo usamos porque realmente no entiendo el significado de la historia. Quizás esto se deba a los límites de tipos específicos de instancias, pero se pueden aumentar fácilmente mediante soporte. Si conoces la aplicación, estaré encantado de leerla en los comentarios)
Nuestra red — configuración de red, seleccione VPC y subredes para máquinas; en la mayoría de los casos, debe seleccionar todas las subredes disponibles.
Balanceo de carga - configuración del balanceador, pero lo haremos por separado, no tocaremos nada aquí. Controles de salud También se configurará más adelante.
Tamaño del grupo — indicamos los límites en el número de máquinas en el clúster y el número deseado de máquinas al inicio. La cantidad de máquinas en el clúster nunca será menor que el mínimo especificado ni mayor que el máximo, incluso si el escalado debe ocurrir de acuerdo con las métricas.
Políticas de escala — parámetros de escala, pero escalaremos en función de las tareas de ECS en ejecución, por lo que configuraremos la escala más adelante.
Protección de escalamiento horizontal de instancias — protección de instancias contra la eliminación cuando se reduce. Lo habilitamos para que ASG no borre la máquina que tiene tareas en ejecución. El proveedor de capacidad de ECS desactivará la protección para instancias que no tengan tareas.
Agregar etiquetas — puede especificar etiquetas para instancias (para esto, la casilla Etiquetar nuevas instancias debe estar marcada). Recomiendo especificar la etiqueta Nombre, entonces todas las instancias que se lancen dentro del grupo tendrán el mismo nombre y es conveniente verlas en la consola.
Después de crear el grupo, ábrelo y ve a la sección Configuraciones avanzadas. ¿Por qué no todas las opciones están visibles en la consola en la etapa de creación?
Políticas de terminación — reglas que se tienen en cuenta al eliminar instancias. Se aplican en orden. Normalmente utilizamos los de la imagen de abajo. Primero, se eliminan las instancias con la plantilla de inicio más antigua (por ejemplo, si actualizamos la AMI, creamos una nueva versión, pero todas las instancias lograron cambiar a ella). Luego se seleccionan las instancias más cercanas a la siguiente hora de facturación. Y luego se seleccionan los más antiguos según la fecha de lanzamiento.
Lo que conviene saber: para actualizar todas las máquinas en un clúster, cómodo de usar . Si combina esto con la función Lambda del paso anterior, tendrá un sistema de actualización de instancias totalmente automatizado. Antes de actualizar todas las máquinas, debe deshabilitar la protección escalable de instancias para todas las instancias del grupo. No la configuración en el grupo, sino la protección de las propias máquinas, esto se hace en la pestaña Administración de instancias.
Balanceador de carga de aplicaciones y grupo objetivo de EC2
El equilibrador se crea en la sección EC2 → Equilibrio de carga → Equilibradores de carga. Usaremos Application Load Balancer; se puede leer una comparación de diferentes tipos de balanceadores en .
Oyentes - Tiene sentido crear los puertos 80 y 443 y redirigir del 80 al 443 utilizando reglas de equilibrado más adelante.
Zonas de disponibilidad — en la mayoría de los casos, seleccionamos zonas de accesibilidad para todos.
Configurar ajustes de seguridad — aquí se indica el certificado SSL para el equilibrador, la opción más conveniente es en ACM. Sobre las diferencias Política de Seguridad se puede leer en , puedes dejarlo seleccionado por defecto ELBSecurityPolicy-2016-08. Después de crear el balanceador, lo verás. Nombre DNS, que necesitas para configurar el CNAME para tu dominio. Por ejemplo, así es como se ve en Cloudflare.
Grupo de seguridad — cree o seleccione un grupo de seguridad para el equilibrador. Escribí más sobre esto justo arriba en la sección Plantilla de inicio EC2 → Configuración de red.
Grupo objetivo — creamos un grupo que se encarga de enrutar las solicitudes del equilibrador a las máquinas y verificar su disponibilidad para reemplazarlas en caso de problemas. Tipo de objetivo debe ser una instancia, Protocolo и Puerto cualquiera, si usa HTTPS para la comunicación entre el balanceador y las instancias, entonces debe cargarles un certificado. Para los propósitos de este ejemplo, no haremos esto, simplemente dejaremos el puerto 80.
Controles de salud — parámetros para comprobar la funcionalidad del servicio. En un servicio real, esta debería ser una solicitud independiente que implemente partes importantes de la lógica empresarial; para los fines de este ejemplo, dejaré la configuración predeterminada. A continuación, puede seleccionar el intervalo de solicitud, el tiempo de espera, los códigos de éxito, etc. En nuestro ejemplo, indicaremos los códigos de éxito 200-399, porque la imagen de Docker que se utilizará devuelve un código 304.
Registrar objetivos — aquí se seleccionan los autos para el grupo, pero en nuestro caso esto lo hará ECS, así que simplemente nos saltamos este paso.
Lo que conviene saber: en el nivel del balanceador puede habilitar los registros que se guardarán en S3 en un determinado . Desde allí, se pueden exportar a servicios de terceros para análisis, o puede realizar consultas SQL directamente sobre los datos en S3 con . Es conveniente y funciona sin ningún código adicional. También recomiendo configurar la eliminación de registros del depósito S3 después de un período de tiempo específico.
Definición de tarea de ECS
En los pasos anteriores creamos todo lo relacionado con la infraestructura del servicio, ahora pasamos a describir los contenedores que lanzaremos. Esto se hace en la sección ECS → Definiciones de tareas.
Compatibilidad del tipo de lanzamiento - seleccione EC2.
Función de IAM de ejecución de tareas - elegir ecsTaskExecutionRole. Al usarlo, se escriben registros, se proporciona acceso a variables secretas, etc.
En la sección Definiciones de contenedor, haga clic en Agregar contenedor.
Imagen — enlace a la imagen con el código del proyecto; para este ejemplo usaré una imagen pública de Docker Hub .
Límites de memoria — límites de memoria para el contenedor. Límite estricto — límite estricto, si el contenedor va más allá del valor especificado, se ejecutará el comando docker kill y el contenedor morirá inmediatamente. Límite suave — límite suave, el contenedor puede ir más allá del valor especificado, pero este parámetro se tendrá en cuenta al asignar tareas a las máquinas. Por ejemplo, si una máquina tiene 4 GiB de RAM y el límite flexible de un contenedor es 2048 MiB, entonces esta máquina puede tener un máximo de 2 tareas en ejecución con este contenedor. En realidad, 4 GiB de RAM es un poco menos que 4096 MiB, esto se puede ver en la pestaña Instancias ECS en el clúster. El límite flexible no puede ser mayor que el límite estricto. Es importante comprender que si hay varios contenedores en una tarea, sus límites se suman.
Mapeos de puertos - en Puerto host Indicamos 0, esto significa que el puerto será asignado dinámicamente y será monitoreado por el Grupo Objetivo. Puerto de contenedores — el puerto en el que se ejecuta su aplicación a menudo se especifica en el comando de ejecución o se asigna en el código de su aplicación, Dockerfile, etc. Para nuestro ejemplo usaremos 3000 porque aparece en la imagen que se está utilizando.
Chequeo — parámetros de verificación del estado del contenedor, que no deben confundirse con el configurado en el grupo objetivo.
Entorno - configuración del entorno. Unidades de CPU - similar a los límites de memoria, sólo sobre el procesador. Cada núcleo de procesador tiene 1024 unidades, por lo que si el servidor tiene un procesador de doble núcleo y el contenedor está configurado en 512, entonces se pueden ejecutar 4 tareas con este contenedor en un servidor. Las unidades de CPU siempre corresponden al número de núcleos, no puede haber un poco menos, como ocurre con la memoria.
Comando — un comando para iniciar un servicio dentro de un contenedor, todos los parámetros se especifican separados por comas. Podría ser gunicorn, npm, etc. Si no se especifica, se utilizará el valor de la directiva CMD del Dockerfile. indicamos npm,start.
Variables de entorno - variables de entorno del contenedor. Pueden ser datos de texto simples o variables secretas de o .
Almacenamiento y registro — aquí configuraremos el inicio de sesión en CloudWatch Logs (un servicio para registros de AWS). Para hacer esto, simplemente habilite la casilla de verificación Configurar automáticamente CloudWatch Logs. Después de crear la definición de tarea, se creará automáticamente un grupo de registros en CloudWatch. De forma predeterminada, los registros se almacenan en él indefinidamente; recomiendo cambiar el período de retención de Nunca caducar al período requerido. Esto se hace en los grupos de CloudWatch Log; debe hacer clic en el período actual y seleccionar uno nuevo.
Clúster ECS y proveedor de capacidad ECS
Vaya a la sección ECS → Clústeres para crear un clúster. Seleccionamos EC2 Linux + Networking como plantilla.
Nombre del clúster - muy importante, aquí ponemos el mismo nombre especificado en el parámetro Plantilla de inicio ECS_CLUSTER, en nuestro caso - DemoApiClusterProd. Marque la casilla Crear un clúster vacío. Opcionalmente, puede habilitar Container Insights para ver métricas de servicios en CloudWatch. Si hizo todo correctamente, en la sección Instancias ECS verá las máquinas que se crearon en el grupo de Auto Scaling.
ir a la pestaña Proveedores de capacidad y crear uno nuevo. Permítanme recordarles que es necesario controlar la creación y el apagado de máquinas según la cantidad de tareas ECS en ejecución. Es importante tener en cuenta que un proveedor sólo puede ser asignado a un grupo.
Grupo de Auto Scaling — seleccione el grupo creado anteriormente.
Escalamiento administrado — habilitarlo para que el proveedor pueda escalar el servicio.
% de capacidad objetivo — ¿Qué porcentaje de máquinas cargadas de tareas necesitamos? Si especifica 100%, todas las máquinas siempre estarán ocupadas ejecutando tareas. Si especifica el 50%, la mitad de los coches siempre serán gratuitos. En este caso, si hay un aumento brusco en la carga, los nuevos taxis llegarán inmediatamente a los coches libres, sin tener que esperar a que se desplieguen las instancias.
Protección de terminación gestionada — habilitar, este parámetro permite al proveedor eliminar la protección de instancias contra la eliminación. Esto sucede cuando no hay tareas activas en la máquina y permite el % de capacidad objetivo.
Servicio ECS y configuración de escalado
Último paso :) Para crear un servicio, debe ir al clúster creado anteriormente en la pestaña Servicios.
Tipo de lanzamiento — debe hacer clic en Cambiar a estrategia de proveedor de capacidad y seleccionar los proveedores creados anteriormente.
Definición de tarea — seleccione la Definición de tarea creada anteriormente y su revisión.
Nombre del servicio — Para evitar confusiones, siempre indicamos lo mismo que Definición de tarea.
Tipo de servicio - siempre Réplica.
Número de tareas — el número deseado de tareas activas en el servicio. Este parámetro está controlado por escala, pero aún debe especificarse.
Porcentaje mínimo saludable и Porcentaje máximo — determinar el comportamiento de las tareas durante el despliegue. Los valores predeterminados son 100 y 200, lo que indica que en el momento de la implementación el número de tareas aumentará varias veces y luego volverá al valor deseado. Si tiene 1 tarea en ejecución, min = 0 y max = 100, durante la implementación se eliminará y luego se generará una nueva, es decir, habrá tiempo de inactividad. Si se está ejecutando 1 tarea, min=50, max=150, entonces la implementación no se realizará en absoluto, porque 1 tarea no se puede dividir por la mitad ni aumentar una vez y media.
Tipo de implementación - salir de Actualización continua.
Plantillas de ubicación — reglas para asignar tareas a las máquinas. El valor predeterminado es Distribución equilibrada AZ: esto significa que cada nueva tarea se colocará en una nueva instancia hasta que aumenten las máquinas en todas las zonas de disponibilidad. Generalmente usamos BinPack - CPU y Spread - AZ; con esta política, las tareas se ubican lo más densamente posible en una máquina por CPU. Si es necesario crear una nueva máquina, se crea en una nueva zona de disponibilidad.
Tipo de equilibrador de carga — seleccione Equilibrador de carga de aplicaciones.
Rol de IAM de servicio - elegir ecsServiceRole.
Nombre del balanceador de carga — seleccione el equilibrador creado anteriormente.
Período de gracia del control de salud — hacer una pausa antes de realizar comprobaciones de estado después de implementar una nueva tarea; normalmente la configuramos en 60 segundos.
Contenedor para equilibrar la carga — en el elemento Nombre del grupo objetivo, seleccione el grupo creado anteriormente y todo se completará automáticamente.
Servicio de Auto Scaling — parámetros de escalamiento del servicio. Seleccione Configurar Service Auto Scaling para ajustar el recuento deseado de su servicio. Establecemos el número mínimo y máximo de tareas al escalar.
Rol de IAM para Service Auto Scaling - elegir AWSServiceRoleForApplicationAutoScaling_ECSService.
Políticas automáticas de escalado de tareas — reglas para escalar. Hay 2 tipos:
- Seguimiento de objetivos — seguimiento de métricas objetivo (uso de CPU/RAM o número de solicitudes para cada tarea). Por ejemplo, queremos que la carga promedio del procesador sea del 85%, cuando sea mayor, se agregarán nuevas tareas hasta alcanzar el valor objetivo. Si la carga es menor, las tareas se eliminarán; por el contrario, a menos que esté habilitada la protección contra la reducción (Desactivar escalado horizontal).
- Escalado de pasos - reacción ante un evento arbitrario. Aquí puede configurar una reacción a cualquier evento (Alarma CloudWatch), cuando ocurre, puede agregar o eliminar la cantidad especificada de tareas, o especificar la cantidad exacta de tareas.
Un servicio puede tener varias reglas de escala, esto puede resultar útil, lo principal es asegurarse de que no entren en conflicto entre sí.
Conclusión
Si siguió las instrucciones y utilizó la misma imagen de Docker, su servicio debería devolver una página como esta.
- Hemos creado una plantilla según la cual se lanzan todas las máquinas del servicio. También aprendimos cómo actualizar las máquinas cuando cambia la plantilla.
- Hemos configurado el procesamiento de la señal de parada de la instancia puntual, de modo que un minuto después de recibirla, todas las tareas en ejecución se eliminan de la máquina, por lo que no se pierde ni se interrumpe nada.
- Levantamos el equilibrador para distribuir la carga uniformemente entre las máquinas.
- Hemos creado un servicio que se ejecuta en instancias puntuales, lo que reduce los costos de la máquina aproximadamente 3 veces.
- Hemos configurado el escalado automático en ambas direcciones para manejar mayores cargas de trabajo sin incurrir en costos de tiempo de inactividad.
- Usamos Capacity Provider para que la aplicación gestione la infraestructura (máquinas) y no al revés.
- Estuvieron estupendos.
Si tiene picos predecibles en la carga, por ejemplo, si está anunciando en una gran campaña de correo electrónico, puede configurar el escalado mediante .
También puede escalar en función de datos de diferentes partes de su sistema. Por ejemplo, tenemos la funcionalidad. usuarios de la aplicación móvil. A veces, se envía una campaña a más de 1 millón de personas. Después de tal distribución, siempre hay un gran aumento en las solicitudes a la API, ya que muchos usuarios inician sesión en la aplicación al mismo tiempo. Entonces, si vemos que hay muchos más indicadores estándar en la cola para enviar notificaciones push promocionales, podemos iniciar inmediatamente varias máquinas y tareas adicionales para estar listos para la carga.
Estaré encantado de que me cuentes en los comentarios casos interesantes sobre el uso de instancias puntuales y ECS o algo sobre escalado.
Pronto habrá artículos sobre cómo procesamos miles de eventos analíticos por segundo en una pila predominantemente sin servidor (con dinero) y cómo funciona la implementación de servicios utilizando GitLab CI y Terraform Cloud.
Suscríbete a nosotros, ¡será interesante!
Solo los usuarios registrados pueden participar en la encuesta. por favor
¿Utiliza instancias puntuales en producción?
-
22,2%Sí6
-
66,7%No18
-
11,1%Aprendí sobre ellos en un artículo y planeo usarlos3
27 usuarios votaron. 5 usuarios se abstuvieron.
Fuente: habr.com