Ola a todos! Chámome Kirill, son CTO de Adapty. A maior parte da nosa arquitectura está en AWS, e hoxe falarei de como reducimos os custos do servidor en 3 veces mediante o uso de instancias puntuales nun ambiente de produción, así como de como configurar o seu escalado automático. Primeiro haberá unha visión xeral de como funciona, e despois instrucións detalladas para comezar.
Que son as instancias Spot?
as instancias son servidores doutros usuarios de AWS que están actualmente inactivos e véndenas cun gran desconto (Amazon escribe ata o 90 %, segundo a nosa experiencia, ~3 veces, varía dependendo da rexión, AZ e tipo de instancia). A súa principal diferenza cos habituais é que poden apagarse en calquera momento. Por iso, durante moito tempo cremos que era normal utilizalos para ambientes virxes, ou para tarefas de cálculo de algo, con resultados intermedios gardados no S3 ou na base de datos, pero non para as vendas. Existen solucións de terceiros que permiten utilizar spots en produción, pero hai moitas muletas para o noso caso, polo que non as implementamos. O enfoque descrito no artigo funciona enteiramente dentro da funcionalidade estándar de AWS, sen scripts, coroas, etc. adicionais.
A continuación móstranse algunhas capturas de pantalla que mostran o historial de prezos dos casos puntuales.
m5.grande na rexión eu-west-1 (Irlanda). O prezo estivo na súa maioría estable durante 3 meses, polo que actualmente aforra 2.9 veces.
m5.grande na rexión us-east-1 (N. Virginia). O prezo cambia constantemente ao longo de 3 meses, polo que aforra actualmente de 2.3x a 2.8x dependendo da zona de dispoñibilidade.
t3.pequeno na rexión us-east-1 (N. Virginia). O prezo mantívose estable durante 3 meses, polo que actualmente aforra 3.4 veces.
Arquitectura do servizo
A arquitectura básica do servizo da que falaremos neste artigo móstrase no seguinte diagrama.
Balanceador de carga da aplicación → Grupo obxectivo EC2 → Servizo de contedores elásticos
O equilibrador de carga de aplicacións (ALB) úsase como equilibrador, que envía solicitudes ao grupo de destino (TG) de EC2. TG é responsable de abrir portos en instancias para ALB e conectalos a portos de contedores de Elastic Container Service (ECS). ECS é un análogo de Kubernetes en AWS, que xestiona os contedores Docker.
Unha instancia pode ter varios contedores en execución cos mesmos portos, polo que non podemos configuralos de forma fixa. ECS di a TG que está a lanzar unha nova tarefa (na terminoloxía de Kubernetes isto chámase pod), comproba se hai portos libres na instancia e asigna un deles á tarefa iniciada. TG tamén comproba regularmente se a instancia e a API están a traballar nela mediante a comprobación de saúde e, se observa algún problema, deixa de enviar solicitudes alí.
EC2 Auto Scaling Groups + ECS Capacity Providers
O diagrama anterior non mostra o servizo EC2 Auto Scaling Groups (ASG). Polo nome pódese entender que é responsable de escalar as instancias. Non obstante, ata hai pouco, AWS non tiña unha capacidade integrada para xestionar o número de máquinas en execución desde ECS. ECS permitiu escalar o número de tarefas, por exemplo, segundo o uso da CPU, a RAM ou o número de solicitudes. Pero se as tarefas ocupaban todas as instancias libres, entón as máquinas novas non se crearon automaticamente.
Isto cambiou coa chegada dos ECS Capacity Providers (ECS CP). Agora cada servizo en ECS pódese asociar a un ASG e, se as tarefas non se axustan ás instancias en execución, levantaranse outras novas (pero dentro dos límites establecidos de ASG). Isto tamén funciona na dirección oposta, se ECS CP ve instancias inactivas sen tarefas, entón dará o comando ASG para apagalas. ECS CP ten a capacidade de especificar unha porcentaxe de destino de carga de instancia, de xeito que un certo número de máquinas sempre estean libres para escalar rapidamente tarefas; falarei sobre isto un pouco máis tarde.
Modelos de lanzamento EC2
O último servizo do que vou falar antes de entrar en detalles sobre a creación desta infraestrutura é EC2 Launch Templates. Permite crear un modelo segundo o cal todas as máquinas comezarán, para non repetir isto desde cero cada vez. Aquí podes seleccionar o tipo de máquina para iniciar, o grupo de seguridade, a imaxe do disco e moitos outros parámetros. Tamén pode especificar os datos de usuario que se cargarán en todas as instancias iniciadas. Pode executar scripts en datos de usuario, por exemplo, pode editar o contido dun ficheiro .
Un dos parámetros de configuración máis importantes para este artigo é = verdade. Se este parámetro está activado, en canto ECS recibe un sinal de que se está eliminando unha instancia puntual, transfire todas as tarefas que traballan nel ao estado Esgotado. Non se asignarán tarefas novas a esta instancia; se hai tarefas que se queiran implementar neste momento, cancelaranse. Tamén deixan de chegar as solicitudes do equilibrador. A notificación da eliminación da instancia chega 2 minutos antes do evento real. Polo tanto, se o teu servizo non realiza tarefas de máis de 2 minutos e non garda nada no disco, podes usar instancias puntuales sen perder datos.
Respecto ao disco - AWS recentemente É posible utilizar o Elastic File System (EFS) xunto con ECS; con este esquema, nin sequera o disco é un obstáculo, pero non o intentamos, xa que en principio non necesitamos o disco para almacenar o estado. De forma predeterminada, despois de recibir SIGINT (enviado cando unha tarefa se transfire ao estado Esgotamento), todas as tarefas en execución pararanse despois de 30 segundos, aínda que aínda non se completasen; pode cambiar esta hora usando o parámetro . O principal é non configuralo durante máis de 2 minutos para máquinas de punto.
Creación dun servizo
Pasemos á creación do servizo descrito. No proceso, describirei ademais varios puntos útiles que non se mencionaron anteriormente. En xeral, esta é unha instrución paso a paso, pero non vou considerar algúns casos moi básicos ou, pola contra, moi específicos. Todas as accións realízanse na consola visual de AWS, pero pódense reproducir mediante programación mediante CloudFormation ou Terraform. En Adapty usamos Terraform.
Modelo de lanzamento EC2
Este servizo crea unha configuración de máquinas que se utilizarán. Os modelos xestionanse na sección EC2 -> Instancias -> Lanzamento de modelos.
Imaxe da máquina de Amazon (AMI) — especifique a imaxe de disco coa que se iniciarán todas as instancias. Para ECS, na maioría dos casos paga a pena usar a imaxe optimizada de Amazon. Actualízase regularmente e contén todo o necesario para que ECS funcione. Para coñecer o ID da imaxe actual, vai á páxina , seleccione a rexión que está a usar e copie o ID AMI para ela. Por exemplo, para a rexión us-east-1, o ID actual no momento da escritura é ami-00c7c1cf5bdc913ed. Este ID debe inserirse no elemento Especificar un valor personalizado.
Tipo de instancia - indicar o tipo de instancia. Elixe o que mellor se adapte á túa tarefa.
Par de claves (iniciar sesión) — especifique un certificado co que pode conectarse á instancia a través de SSH, se é necesario.
Configuración de rede — Especifique os parámetros da rede. Plataforma de redes na maioría dos casos debería haber unha Nube Privada Virtual (VPC). Grupos de seguridade — grupos de seguridade para as súas instancias. Dado que utilizaremos un equilibrador diante das instancias, recomendo especificar aquí un grupo que permita conexións entrantes só desde o equilibrador. É dicir, terá 2 grupos de seguridade, un para o equilibrador, que permite conexións entrantes desde calquera lugar dos portos 80 (http) e 443 (https), e o segundo para máquinas, que permite conexións entrantes en calquera porto do grupo equilibrador. . As conexións de saída de ambos os grupos deben abrirse mediante o protocolo TCP a todos os portos a todos os enderezos. Podes limitar os portos e enderezos para as conexións de saída, pero entón tes que supervisar constantemente que non estás tentando acceder a algo nun porto pechado.
Almacenamento (volumes) — Especifique os parámetros do disco para as máquinas. O tamaño do disco non pode ser inferior ao especificado na AMI; para ECS Optimized é de 30 GiB.
Detalles avanzados - especificar parámetros adicionais.
Opción de compra - se queremos comprar instancias spot. Queremos, pero non marcaremos esta caixa aquí; configurarémola no Grupo de Auto Scaling, hai máis opcións alí.
Perfil de instancia de IAM — indicar a función coa que se porán en marcha as instancias. Para que as instancias se executen en ECS, necesitan permisos, que normalmente se atopan no rol ecsInstanceRole. Nalgúns casos pódese crear, se non, aquí sobre como facelo. Despois da creación, indicámolo no modelo.
A continuación hai moitos parámetros, basicamente podes deixar os valores predeterminados en todas partes, pero cada un deles ten unha descrición clara. Sempre habilito a instancia optimizada para EBS e as opcións T2/T3 Unlimited se se usan instancias.
Datos do usuario - indicar os datos do usuario. Editaremos o ficheiro /etc/ecs/ecs.config, que contén a configuración do axente ECS.
Un exemplo de como poden ser os datos do 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 — o parámetro indica que a instancia pertence a un clúster co nome dado, é dicir, este clúster poderá colocar as súas tarefas neste servidor. Aínda non creamos un clúster, pero usaremos este nome ao crealo.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — o parámetro especifica que cando se recibe un sinal para desactivar unha instancia de spot, todas as tarefas sobre ela deben transferirse ao estado Drenaxe.
ECS_CONTAINER_STOP_TIMEOUT=1m - o parámetro especifica que despois de recibir un sinal SIGINT, todas as tarefas teñen 1 minuto antes de ser eliminadas.
ECS_ENGINE_AUTH_TYPE=docker — o parámetro indica que se utiliza o esquema Docker como mecanismo de autorización
ECS_ENGINE_AUTH_DATA=... — parámetros de conexión ao rexistro de contedores privados, onde se almacenan as imaxes de Docker. Se é público, non é necesario especificar nada.
Para os efectos deste artigo, usarei unha imaxe pública de Docker Hub, polo que especifique os parámetros ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA sen necesidade.
É bo saber: Recoméndase actualizar a AMI regularmente, xa que as novas versións actualizan versións de Docker, Linux, axente ECS, etc. Para non esquecer isto, pode sobre o lanzamento de novas versións. Podes recibir notificacións por correo electrónico e actualizar manualmente, ou podes escribir unha función Lambda que creará automaticamente unha nova versión de Launch Template cunha AMI actualizada.
EC2 Auto Scaling Group
Auto Scaling Group é o responsable de lanzar e escalar instancias. Os grupos xestionanse na sección EC2 -> Auto Scaling -> Auto Scaling Groups.
Modelo de lanzamento — seleccione o modelo creado no paso anterior. Deixamos a versión predeterminada.
Opcións de compra e tipos de instancias — Especifique os tipos de instancias para o clúster. Adherirse ao modelo de lanzamento usa o tipo de instancia do modelo de lanzamento. Combinar opcións de compra e tipos de instancias permítelle configurar de xeito flexible os tipos de instancias. Usarémolo.
Base opcional baixo demanda — o número de instancias regulares e non puntuales que sempre funcionarán.
Porcentaxe baixo demanda sobre a base — proporción porcentual de instancias regulares e puntuales, repartirase 50-50 por partes equitativas, 20-80 por cada instancia regular elevaranse 4 puntuais. Para os efectos deste exemplo, indicarei 50-50, pero en realidade a maioría das veces facemos 20-80, nalgúns casos 0-100.
Tipos de instancias — aquí pode especificar tipos adicionais de instancias que se usarán no clúster. Nunca o usamos porque non entendo moi ben o significado da historia. Quizais isto se deba aos límites de tipos específicos de instancias, pero poden aumentarse facilmente grazas ao soporte. Se coñeces a aplicación, estarei encantado de lela nos comentarios)
Rede — axustes de rede, seleccione VPC e subredes para máquinas, na maioría dos casos debe seleccionar todas as subredes dispoñibles.
Equilibrado de carga - configuración do equilibrador, pero farémolo por separado, non tocaremos nada aquí. Controles de saúde tamén se configurará máis tarde.
Tamaño do grupo — indicamos os límites no número de máquinas do clúster e o número de máquinas desexado ao inicio. O número de máquinas do clúster nunca será inferior ao mínimo especificado nin superior ao máximo, aínda que se produza o escalado segundo as métricas.
Políticas de escalado — parámetros de escala, pero escalaremos en función das tarefas ECS en execución, polo que configuraremos a escala máis tarde.
Protección de escala de instancia — protección das instancias contra a eliminación ao reducir a escala. Habilitamos para que ASG non elimine a máquina que ten tarefas en execución. ECS Capacity Provider desactivará a protección para as instancias que non teñan tarefas.
Engade etiquetas — pode especificar etiquetas para instancias (para iso, a caixa de verificación Etiquetar novas instancias debe estar marcada). Recomendo especificar a etiqueta Nome, entón todas as instancias que se lanzan dentro do grupo terán o mesmo nome, e é conveniente velas na consola.
Despois de crear o grupo, ábreo e vai á sección Configuracións avanzadas.Por que non todas as opcións son visibles na consola na fase de creación.
Políticas de terminación — regras que se teñen en conta ao eliminar instancias. Aplícanse en orde. Normalmente usamos os da imaxe de abaixo. En primeiro lugar, elimínanse as instancias co modelo de lanzamento máis antigo (por exemplo, se actualizamos a AMI, creamos unha nova versión, pero todas as instancias conseguiron cambiar a ela). A continuación, selecciónanse as instancias máis próximas á seguinte hora de facturación. E despois escóllense os máis antigos en función da data de lanzamento.
É bo saber: para actualizar todas as máquinas dun clúster, cómodo de usar . Se combinas isto coa función Lambda do paso anterior, terás un sistema de actualización de instancias totalmente automatizado. Antes de actualizar todas as máquinas, debes desactivar a protección de ampliación de instancias para todas as instancias do grupo. Non a configuración no grupo, senón a protección das propias máquinas, isto faise na pestana Xestión de instancias.
Balanceador de carga da aplicación e grupo obxectivo EC2
O equilibrador créase na sección EC2 → Load Balancing → Load Balancers. Usaremos Application Load Balancer; pódese ler unha comparación de diferentes tipos de equilibradores en .
Escoitadores - ten sentido facer os portos 80 e 443 e redirixir de 80 a 443 usando regras de balance máis tarde.
Zonas de dispoñibilidade — na maioría dos casos, seleccionamos zonas de accesibilidade para todos.
Configurar a configuración de seguranza — aquí indícase o certificado SSL para o equilibrador, a opción máis conveniente é en ACM. Sobre as diferenzas Política de seguridade pódese ler en , podes deixalo seleccionado por defecto ELBSecurityPolicy-2016-08. Despois de crear o equilibrador, verá Nome DNS, que precisas para configurar o CNAME para o teu dominio. Por exemplo, así se ve en Cloudflare.
Grupo de seguridade — cree ou seleccione un grupo de seguridade para o equilibrador, escribín máis sobre isto xusto arriba na sección Modelo de lanzamento de EC2 → Configuración de rede.
Grupo obxectivo — creamos un grupo que se encarga de dirixir as solicitudes do equilibrador ás máquinas e de comprobar a súa dispoñibilidade para substituílas en caso de problemas. Tipo de destino debe ser unha instancia, Protocolo и Porta calquera, se usa HTTPS para a comunicación entre o equilibrador e as instancias, entón cómpre cargarlles un certificado. Para os efectos deste exemplo, non o faremos, simplemente abandonaremos o porto 80.
Controles de saúde — Parámetros para comprobar a funcionalidade do servizo. Nun servizo real, esta debería ser unha solicitude separada que implemente partes importantes da lóxica empresarial; para os efectos deste exemplo, deixarei a configuración predeterminada. A continuación, pode seleccionar o intervalo de solicitude, o tempo de espera, os códigos de éxito, etc. No noso exemplo, indicaremos os códigos de éxito 200-399, porque a imaxe Docker que se utilizará devolve un código 304.
Rexistrar obxectivos — aquí se seleccionan os coches para o grupo, pero no noso caso será a ECS, polo que simplemente saltamos este paso.
É bo saber: no nivel do equilibrador pode habilitar rexistros que se gardan en S3 nun determinado momento . Desde alí pódense exportar a servizos de terceiros para realizar análises ou pode realizar consultas SQL directamente sobre os datos en S3 con . É cómodo e funciona sen ningún código adicional. Tamén recomendo configurar a eliminación de rexistros do bucket S3 despois dun período de tempo especificado.
Definición de tarefas ECS
Nos pasos anteriores creamos todo o relacionado coa infraestrutura do servizo; agora pasamos a describir os contedores que imos lanzar. Isto faise na sección ECS → Definicións de tarefas.
Compatibilidade do tipo de lanzamento - Seleccione EC2.
Función IAM de execución de tarefas - escoller ecsTaskExecutionRole. Ao utilizar, escríbense rexistros, dáse acceso a variables secretas, etc.
Na sección Definicións do contedor, faga clic en Engadir contedor.
Imaxe — ligazón á imaxe co código do proxecto; para este exemplo, usarei unha imaxe pública de Docker Hub .
Límites da memoria — límites de memoria para o recipiente. Límite duro — límite ríxido, se o contedor supera o valor especificado, executarase o comando docker kill, o contenedor morrerá inmediatamente. Límite suave — límite suave, o recipiente pode ir máis aló do valor especificado, pero este parámetro terase en conta ao colocar tarefas nas máquinas. Por exemplo, se unha máquina ten 4 GiB de RAM e o límite suave dun contedor é de 2048 MiB, esta máquina pode ter un máximo de 2 tarefas en execución con este contenedor. En realidade, 4 GiB de RAM son algo menos que 4096 MiB, isto pódese ver na pestana Instancias ECS do clúster. O límite suave non pode ser superior ao límite duro. É importante entender que se hai varios contedores nunha mesma tarefa, os seus límites resúmense.
Mapas de portos - dentro Porto anfitrión Indicamos 0, isto significa que o porto asignarase de forma dinámica e será supervisado polo Grupo Obxectivo. Porto de contedores — o porto no que se executa a súa aplicación adoita especificarse no comando de execución ou asignado no código da súa aplicación, Dockerfile, etc. Para o noso exemplo, usaremos 3000 porque está listado en a imaxe que se está a utilizar.
Control sanitario — parámetros de comprobación de estado do contenedor, que non deben confundirse co configurado no Grupo de destino.
ambiente - Configuración do entorno. unidades CPU - similar aos límites de memoria, só sobre o procesador. Cada núcleo de procesador é de 1024 unidades, polo que se o servidor ten un procesador de dobre núcleo e o contenedor está configurado en 512, pódense iniciar 4 tarefas con este contenedor nun servidor. As unidades CPU sempre corresponden ao número de núcleos; non pode haber un pouco menos deles, como é o caso da memoria.
Mando — un comando para iniciar un servizo dentro dun contedor, todos os parámetros especifícanse separados por comas. Pode ser gunicorn, npm, etc. Se non se especifica, empregarase o valor da directiva CMD do Dockerfile. Indicamos npm,start.
Variables de ambiente — Variables de ambiente do contedor. Estes poden ser datos de texto simples ou variables secretas de ou .
Almacenamento e rexistro — aquí configuraremos o rexistro en CloudWatch Logs (un servizo para rexistros de AWS). Para facelo, basta con activar a caixa de verificación Auto-configure CloudWatch Logs. Despois de crear a definición de tarefas, crearase automaticamente un grupo de rexistros en CloudWatch. De forma predeterminada, os rexistros almacénanse nel indefinidamente; recomendo cambiar o período de retención de Nunca caduca ao período necesario. Isto faise nos grupos de rexistro de CloudWatch, cómpre facer clic no período actual e seleccionar un novo.
Clúster ECS e provedor de capacidade ECS
Vaia á sección ECS → Clústeres para crear un clúster. Seleccionamos EC2 Linux + Networking como modelo.
Nome do clúster - moi importante, facemos aquí o mesmo nome que o especificado no parámetro Launch Template ECS_CLUSTER, no noso caso - DemoApiClusterProd. Marque a caixa de verificación Crear un clúster baleiro. Opcionalmente, pode habilitar Container Insights para ver as métricas dos servizos en CloudWatch. Se fixeches todo correctamente, na sección Instancias de ECS verás máquinas que se crearon no grupo Auto Scaling.
Vaia á pestana Provedores de capacidade e crear un novo. Permíteme recordarche que é necesario controlar a creación e apagado das máquinas dependendo do número de tarefas ECS en execución. É importante ter en conta que un provedor só se pode asignar a un grupo.
Grupo Auto Scaling — seleccione o grupo creado previamente.
Escalado xestionado — activalo para que o provedor poida escalar o servizo.
Capacidade obxectivo % — que porcentaxe de máquinas cargadas de tarefas necesitamos. Se especificas 100 %, todas as máquinas estarán sempre ocupadas coas tarefas en execución. Se especificas o 50 %, a metade dos coches estará sempre gratuíto. Neste caso, se hai un forte salto de carga, os novos taxis chegarán inmediatamente aos coches libres, sen ter que esperar a que se despreguen instancias.
Protección de terminación xestionada — habilitar, este parámetro permite ao provedor eliminar a protección das instancias contra a eliminación. Isto ocorre cando non hai tarefas activas na máquina e permite a capacidade de destino %.
Servizo ECS e configuración de escalado
Último paso :) Para crear un servizo, cómpre ir ao clúster creado previamente na pestana Servizos.
Tipo de lanzamento — cómpre facer clic en Cambiar á estratexia de provedor de capacidade e seleccionar os provedores creados previamente.
Definición de tarefas — seleccione a Definición de tarefa creada previamente e a súa revisión.
Nome do servizo — para evitar confusións, sempre indicamos o mesmo que Definición de tarefa.
Tipo de servizo - sempre Réplica.
Número de tarefas — o número desexado de tarefas activas no servizo. Este parámetro contrólase mediante a escala, pero aínda debe especificarse.
Porcentaxe mínima de saúde и Porcentaxe máxima — Determinar o comportamento das tarefas durante a implantación. Os valores predeterminados son 100 e 200, o que indica que no momento da implantación o número de tarefas aumentará varias veces e despois volverá ao valor desexado. Se tes 1 tarefa en execución, min=0 e max=100, durante a implantación eliminarase e, despois, crearase unha nova, é dicir, será o tempo de inactividade. Se se está a executar 1 tarefa, min=50, max=150, a implantación non se producirá en absoluto, porque 1 tarefa non se pode dividir á metade nin aumentar unha vez e media.
Tipo de implantación - deixa a actualización de Rolling.
Modelos de colocación — normas para colocar tarefas nas máquinas. O valor predeterminado é AZ Balanced Spread; isto significa que cada tarefa nova colocarase nunha nova instancia ata que suban as máquinas de todas as zonas de dispoñibilidade. Normalmente facemos BinPack - CPU e Spread - AZ; con esta política, as tarefas colócanse o máis densamente posible nunha máquina por CPU. Se é necesario crear unha nova máquina, créase nunha nova zona de dispoñibilidade.
Tipo de equilibrador de carga — seleccione Balanceador de carga de aplicacións.
Papel IAM do servizo - escoller ecsServiceRole.
Nome do equilibrador de carga — seleccione o equilibrador creado previamente.
Período de carencia do control de saúde — facer unha pausa antes de realizar comprobacións de saúde despois de lanzar unha nova tarefa, normalmente axustámola en 60 segundos.
Contador para balance de carga — no elemento Nome do grupo de destino, seleccione o grupo creado anteriormente e todo encherase automaticamente.
Servizo Auto Scaling - Parámetros de escalado do servizo. Seleccione Configurar a escala automática do servizo para axustar o reconto desexado do seu servizo. Establecemos o número mínimo e máximo de tarefas ao escalar.
Rol de IAM para Service Auto Scaling - escoller AWSServiceRoleForApplicationAutoScaling_ECSService.
Políticas de escalado automático de tarefas - Normas de escalado. Hai 2 tipos:
- Seguimento de obxectivos — seguimento das métricas de destino (uso de CPU/RAM ou número de solicitudes para cada tarefa). Por exemplo, queremos que a carga media do procesador sexa do 85%, cando sexa maior, engadiranse novas tarefas ata que alcance o valor obxectivo. Se a carga é menor, eliminaranse as tarefas, pola contra, a non ser que estea activada a protección contra a redución (Desactivar a escala).
- Escalado de pasos - Reacción ante un evento arbitrario. Aquí pode configurar unha reacción a calquera evento (Alarma CloudWatch), cando se produza, pode engadir ou eliminar o número especificado de tarefas ou especificar o número exacto de tarefas.
Un servizo pode ter varias regras de escala, isto pode ser útil, o principal é garantir que non entren en conflito entre si.
Conclusión
Se seguiches as instrucións e utilizaches a mesma imaxe de Docker, o teu servizo debería devolver unha páxina coma esta.
- Creamos un modelo segundo o cal se poñen en marcha todas as máquinas do servizo. Tamén aprendemos a actualizar as máquinas cando cambia o modelo.
- Configuramos o procesamento do sinal de parada da instancia puntual, polo que nun minuto despois de recibilo, todas as tarefas en execución son eliminadas da máquina, polo que non se perda nin se interrompe nada.
- Levantamos o equilibrador para distribuír a carga uniformemente entre as máquinas.
- Creamos un servizo que se executa en instancias puntuales, o que reduce os custos das máquinas unhas 3 veces.
- Configuramos a escala automática en ambas direccións para xestionar o aumento das cargas de traballo sen incorrer en custos de inactividade.
- Usamos Capacity Provider para que a aplicación xestione a infraestrutura (máquinas) e non ao revés.
- Somos xeniais.
Se tes picos de carga previsibles, por exemplo, estás anunciando nunha campaña de correo electrónico grande, podes configurar a escala mediante .
Tamén pode escalar en función dos datos de diferentes partes do seu sistema. Por exemplo, temos a funcionalidade usuarios da aplicación móbil. Ás veces, envíase unha campaña a máis de 1 millón de persoas. Despois desta distribución, sempre hai un gran aumento das solicitudes á API, xa que moitos usuarios inician sesión na aplicación ao mesmo tempo. Polo tanto, se vemos que hai moito máis indicadores estándar na cola para enviar notificacións push promocionais, podemos lanzar inmediatamente varias máquinas e tarefas adicionais para estar preparados para a carga.
Estarei feliz se me contas nos comentarios casos interesantes de uso de instancias puntuales e ECS ou algo sobre escalado.
En breve haberá artigos sobre como procesamos miles de eventos analíticos por segundo nunha pila predominantemente sen servidor (con diñeiro) e como funciona a implantación de servizos mediante GitLab CI e Terraform Cloud.
Subscríbete a nós, será interesante!
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Usas instancias puntuales na produción?
-
22,2%Si 6
-
66,7%No 18
-
11,1%Aprendín sobre eles cun artigo e penso utilizalos3
Votaron 27 usuarios. 5 usuarios abstivéronse.
Fonte: www.habr.com