{"id":87393,"date":"2020-07-08T01:42:02","date_gmt":"2020-07-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws"},"modified":"2020-07-08T01:42:02","modified_gmt":"2020-07-07T23:42:02","slug":"sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","title":{"rendered":"Cria\u00e7\u00e3o de uma API escal\u00e1vel em inst\u00e2ncias spot da AWS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1 a todos! Meu nome \u00e9 Kirill, sou o CTO da Adapty. A maior parte da nossa arquitetura est\u00e1 na AWS, e hoje vou falar sobre como reduzimos os custos com servidores em 3 vezes usando inst\u00e2ncias spot em nosso ambiente de produ\u00e7\u00e3o, bem como sobre como configurar a escalabilidade autom\u00e1tica. Primeiro, haver\u00e1 uma vis\u00e3o geral de como isso funciona, seguida de um guia detalhado de como implementar.<\/p>\n

<\/p>\n

O que s\u00e3o inst\u00e2ncias spot?<\/h2>\n

<\/p>\n

Spot<\/a><\/noindex> inst\u00e2ncias s\u00e3o servidores de outros usu\u00e1rios da AWS que est\u00e3o ociosos no momento, e eles os vendem com um grande desconto (a Amazon menciona at\u00e9 90%, mas com base na nossa experi\u00eancia \u00e9 cerca de 3x, variando de acordo com a regi\u00e3o, AZ e tipo de inst\u00e2ncia). A principal diferen\u00e7a em rela\u00e7\u00e3o \u00e0s inst\u00e2ncias normais \u00e9 que elas podem ser desligadas a qualquer momento. Por muito tempo, acreditamos que era aceit\u00e1vel us\u00e1-las para ambientes de desenvolvimento ou para tarefas que requerem c\u00e1lculos, salvando resultados intermedi\u00e1rios no S3 ou em um banco de dados, mas n\u00e3o para produ\u00e7\u00e3o. Existem solu\u00e7\u00f5es de terceiros que permitem usar spot em produ\u00e7\u00e3o, mas no nosso caso, elas t\u00eam muitas limita\u00e7\u00f5es, portanto n\u00e3o as implementamos. O m\u00e9todo descrito neste artigo funciona totalmente dentro das funcionalidades padr\u00e3o da AWS, sem scripts adicionais, cron jobs, etc.<\/p>\n

<\/a><\/noindex><\/p>\n

A seguir, apresento algumas capturas de tela que mostram a hist\u00f3ria dos pre\u00e7os das inst\u00e2ncias spot.<\/p>\n

<\/p>\n

m5.large na regi\u00e3o eu-west-1 (Irlanda). O pre\u00e7o \u00e9 predominantemente est\u00e1vel ao longo de 3 meses, atualmente com uma economia de 2.9x.<\/p>\n

<\/p>\n

\"Cria\u00e7\u00e3o<\/p>\n

<\/p>\n

m5.large na regi\u00e3o us-east-1 (N. Virginia). O pre\u00e7o varia constantemente ao longo de 3 meses, atualmente com uma economia de 2.3x a 2.8x dependendo da zona de disponibilidade.<\/p>\n

<\/p>\n

\"Cria\u00e7\u00e3o<\/p>\n

<\/p>\n

t3.small na regi\u00e3o us-east-1 (N. Virginia). O pre\u00e7o \u00e9 est\u00e1vel ao longo de 3 meses, atualmente com uma economia de 3.4x.<\/p>\n

<\/p>\n

\"Cria\u00e7\u00e3o<\/p>\n

<\/p>\n

Arquitetura do servi\u00e7o<\/h2>\n

<\/p>\n

A arquitetura b\u00e1sica do servi\u00e7o que iremos discutir neste artigo est\u00e1 representada no diagrama abaixo.<\/p>\n

<\/p>\n

\"Cria\u00e7\u00e3o<\/p>\n

<\/p>\n

Application Load Balancer \u2192 EC2 Target Group \u2192 Elastic Container Service<\/h3>\n

<\/p>\n

O Application Load Balancer (ALB) \u00e9 usado como balanceador, que direciona as requisi\u00e7\u00f5es para o EC2 Target Group (TG). O TG \u00e9 respons\u00e1vel por abrir portas nas inst\u00e2ncias para o ALB e vincul\u00e1-las \u00e0s portas dos cont\u00eaineres do Elastic Container Service (ECS). O ECS \u00e9 an\u00e1logo ao Kubernetes na AWS, que gerencia cont\u00eaineres Docker.<\/p>\n

<\/p>\n

Em uma inst\u00e2ncia, pode haver v\u00e1rios cont\u00eaineres em execu\u00e7\u00e3o com as mesmas portas, portanto, n\u00e3o podemos defini-las de forma fixa. O ECS informa ao TG que est\u00e1 iniciando uma nova tarefa (o que na terminologia do Kubernetes \u00e9 chamado de pod), e ele verifica as portas dispon\u00edveis na inst\u00e2ncia e designa uma delas para a tarefa a ser iniciada. Al\u00e9m disso, o TG verifica regularmente se a inst\u00e2ncia e a API nela est\u00e3o funcionando por meio de checagens de sa\u00fade e, se notar algum problema, para de redirecionar solicita\u00e7\u00f5es para l\u00e1.<\/p>\n

<\/p>\n

Grupos de Auto Scaling do EC2 + Provedores de Capacidade do ECS<\/h3>\n

<\/p>\n

O servi\u00e7o Grupos de Auto Scaling do EC2 (ASG) n\u00e3o est\u00e1 mostrado no diagrama acima. Pelo nome, pode-se entender que ele \u00e9 respons\u00e1vel pela escalabilidade das inst\u00e2ncias. At\u00e9 recentemente, a AWS n\u00e3o tinha um recurso integrado para gerenciar o n\u00famero de m\u00e1quinas em execu\u00e7\u00e3o a partir do ECS. O ECS permitia escalar o n\u00famero de tarefas, por exemplo, com base no uso de CPU, RAM ou no n\u00famero de solicita\u00e7\u00f5es. Mas se as tarefas ocupassem todas as inst\u00e2ncias dispon\u00edveis, novas m\u00e1quinas n\u00e3o seriam automaticamente iniciadas.<\/p>\n

<\/p>\n

Isso mudou com a introdu\u00e7\u00e3o dos Provedores de Capacidade do ECS (ECS CP). Agora, cada servi\u00e7o no ECS pode ser vinculado a um ASG, e se as tarefas n\u00e3o cabem nas inst\u00e2ncias em execu\u00e7\u00e3o, novas ser\u00e3o iniciadas (mas dentro dos limites estabelecidos do ASG). Isso tamb\u00e9m funciona ao contr\u00e1rio; se o ECS CP identificar inst\u00e2ncias ociosas sem tarefas, ele dar\u00e1 a ordem ao ASG para deslig\u00e1-las. O ECS CP tem a capacidade de especificar uma porcentagem de utiliza\u00e7\u00e3o alvo das inst\u00e2ncias, de modo que um certo n\u00famero de m\u00e1quinas esteja sempre dispon\u00edvel para uma r\u00e1pida escalabilidade das tarefas, falarei sobre isso um pouco mais tarde.<\/p>\n

<\/p>\n

Modelos de Lan\u00e7amento do EC2<\/h3>\n

<\/p>\n

O \u00faltimo servi\u00e7o que irei apresentar, antes de passar \u00e0 descri\u00e7\u00e3o detalhada da cria\u00e7\u00e3o desta infraestrutura, s\u00e3o os Modelos de Lan\u00e7amento do EC2. Ele permite criar um modelo pelo qual todas as m\u00e1quinas ser\u00e3o iniciadas, para n\u00e3o ter que repetir isso do zero a cada vez. Aqui voc\u00ea pode escolher o tipo de m\u00e1quina a ser iniciada, grupo de seguran\u00e7a, imagem de disco e muitos outros par\u00e2metros. Tamb\u00e9m \u00e9 poss\u00edvel especificar dados personalizados que ser\u00e3o carregados em todas as inst\u00e2ncias iniciadas. Nos dados personalizados, voc\u00ea pode executar scripts, por exemplo, pode editar o conte\u00fado do arquivo de configura\u00e7\u00e3o do agente do ECS<\/a><\/noindex>.<\/p>\n

<\/p>\n

Um dos par\u00e2metros de configura\u00e7\u00e3o mais importantes neste artigo \u00e9 ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Se este par\u00e2metro estiver ativado, assim que o ECS receber o sinal de que a inst\u00e2ncia spot est\u00e1 sendo removida, ele muda o status de todas as tarefas que est\u00e3o sendo executadas nela para Draining. Nenhuma nova tarefa ser\u00e1 designada para esta inst\u00e2ncia; se houver tarefas que desejam ser implantadas nela, elas ser\u00e3o canceladas. As solicita\u00e7\u00f5es do balanceador de carga tamb\u00e9m deixar\u00e3o de chegar. A notifica\u00e7\u00e3o de remo\u00e7\u00e3o da inst\u00e2ncia chega 2 minutos antes do evento real. Portanto, se seu servi\u00e7o n\u00e3o executar tarefas por mais de 2 minutos e n\u00e3o salvar nada no disco, voc\u00ea pode usar inst\u00e2ncias spot sem perda de dados.<\/p>\n

<\/p>\n

Quanto ao disco \u2014 a AWS recentemente tornou<\/a><\/noindex> poss\u00edvel o uso do Elastic File System (EFS) junto com o ECS, com esse esquema nem mesmo o disco \u00e9 um obst\u00e1culo, mas n\u00e3o tentamos isso, j\u00e1 que, em princ\u00edpio, n\u00e3o precisamos de um disco para armazenar estado. Por padr\u00e3o, ap\u00f3s receber SIGINT (enviado no momento em que a tarefa muda para o status Draining), todas as tarefas em execu\u00e7\u00e3o ser\u00e3o paradas em 30 segundos, mesmo que n\u00e3o tenham sido conclu\u00eddas; esse tempo pode ser alterado usando o par\u00e2metro ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>. O importante \u00e9 n\u00e3o definir mais que 2 minutos para m\u00e1quinas spot.<\/p>\n

<\/p>\n

Cria\u00e7\u00e3o de servi\u00e7o<\/h2>\n

<\/p>\n

Vamos passar diretamente \u00e0 cria\u00e7\u00e3o do servi\u00e7o descrito. No processo, descreverei alguns pontos adicionais \u00fateis que n\u00e3o foram mencionados acima. Em geral, esta \u00e9 uma instru\u00e7\u00e3o passo a passo, mas algumas situa\u00e7\u00f5es muito b\u00e1sicas ou, pelo contr\u00e1rio, muito espec\u00edficas n\u00e3o ser\u00e3o abordadas. Todas as a\u00e7\u00f5es s\u00e3o realizadas no console visual da AWS, mas podem ser reproduzidas programaticamente usando CloudFormation ou Terraform. Na Adapty usamos Terraform.<\/p>\n

<\/p>\n

Modelo de Inicializa\u00e7\u00e3o EC2<\/strong><\/h3>\n

<\/p>\n

Neste servi\u00e7o, \u00e9 criada uma configura\u00e7\u00e3o de m\u00e1quinas que ser\u00e3o utilizadas. A gest\u00e3o dos modelos \u00e9 feita na se\u00e7\u00e3o EC2 -> Instances -> Launch templates.<\/p>\n

<\/p>\n

Imagem de m\u00e1quina da Amazon (AMI)<\/strong> \u2014 especificamos a imagem do disco com a qual todas as inst\u00e2ncias ser\u00e3o iniciadas. Para o ECS, na maioria dos casos, deve-se usar a imagem otimizada da Amazon. Ela \u00e9 atualizada regularmente e cont\u00e9m tudo o que \u00e9 necess\u00e1rio para o funcionamento do ECS. Para saber o ID atual da imagem, vamos \u00e0 p\u00e1gina Amazon ECS-optimized AMIs<\/a><\/noindex>, escolhemos a regi\u00e3o utilizada e copiamos o ID da AMI para ela. Por exemplo, para a regi\u00e3o us-east-1, o ID atual no momento da reda\u00e7\u00e3o deste artigo \u00e9 ami-00c7c1cf5bdc913ed<\/em>. Este ID deve ser inserido no item Especificar um valor personalizado.<\/p>\n

<\/p>\n

Tipo de inst\u00e2ncia<\/strong> \u2014 indicamos o tipo de inst\u00e2ncia. Escolha aquele que melhor se adapta \u00e0 sua tarefa.<\/p>\n

<\/p>\n

Par de chaves (login)<\/strong> \u2014 indicamos o certificado que permite a conex\u00e3o com a inst\u00e2ncia via SSH, se necess\u00e1rio.<\/p>\n

<\/p>\n

Configura\u00e7\u00f5es de rede<\/strong> \u2014 indicamos os par\u00e2metros da rede. Plataforma de rede<\/strong> na maioria dos casos deve ser a Virtual Private Cloud (VPC). Grupos de seguran\u00e7a<\/strong> \u2014 grupos de seguran\u00e7a para suas inst\u00e2ncias. Como iremos usar um balanceador na frente das inst\u00e2ncias, recomendo indicar aqui um grupo que permita conex\u00f5es de entrada apenas do balanceador. Ou seja, voc\u00ea ter\u00e1 2 grupos de seguran\u00e7a, um para o balanceador, que permite conex\u00f5es de entrada (inbound) de qualquer lugar nas portas 80 (http) e 443 (https), e o segundo para as m\u00e1quinas, que permite conex\u00f5es de entrada em quaisquer portas do grupo do balanceador. Conex\u00f5es de sa\u00edda (outbound) em ambos os grupos devem ser liberadas via protocolo TCP em todas as portas para todos os endere\u00e7os. \u00c9 poss\u00edvel restringir as portas e endere\u00e7os para conex\u00f5es de sa\u00edda, mas isso requer monitoramento constante para garantir que voc\u00ea n\u00e3o esteja tentando acessar uma porta fechada.<\/p>\n

<\/p>\n

Armazenamento (volumes)<\/strong> \u2014 indicamos os par\u00e2metros dos discos para as m\u00e1quinas. O volume do disco n\u00e3o pode ser menor do que o especificado na AMI, para ECS Optimized \u2014 30 GiB.<\/p>\n

<\/p>\n

Detalhes avan\u00e7ados<\/strong> \u2014 indicamos par\u00e2metros adicionais.<\/p>\n

<\/p>\n

Op\u00e7\u00e3o de compra<\/strong> \u2014 se queremos comprar inst\u00e2ncias spot. Queremos, mas n\u00e3o marcaremos esta op\u00e7\u00e3o aqui, configuraremos isso no Auto Scaling Group, onde h\u00e1 mais op\u00e7\u00f5es.<\/p>\n

<\/p>\n

Perfil de inst\u00e2ncia IAM<\/strong> \u2014 indicamos a fun\u00e7\u00e3o com a qual as inst\u00e2ncias ser\u00e3o iniciadas. Para que as inst\u00e2ncias funcionem no ECS, elas precisam de permiss\u00f5es que normalmente est\u00e3o na fun\u00e7\u00e3o ecsInstanceRole<\/em>. Em alguns casos, ela pode ser criada; se n\u00e3o, veja aqui um guia<\/a><\/noindex> como fazer isso. Ap\u00f3s a cria\u00e7\u00e3o, indicamos isso no template.
\nEm seguida, existem muitos par\u00e2metros, na maioria das vezes, pode-se deixar os valores padr\u00e3o, mas cada um deles tem uma descri\u00e7\u00e3o clara. Eu sempre incluo os par\u00e2metros de inst\u00e2ncia EBS-optimized e T2\/T3 Unlimited, se forem utilizados burstable<\/a><\/noindex> inst\u00e2ncias.<\/p>\n

<\/p>\n

Dados do usu\u00e1rio<\/strong> \u2014 indicamos os dados do usu\u00e1rio. Iremos editar o arquivo \/etc\/ecs\/ecs.config<\/code>, que cont\u00e9m a configura\u00e7\u00e3o do agente ECS.
\nExemplo de como os dados do usu\u00e1rio podem parecer:<\/p>\n

<\/p>\n

#!\/bin\/bash\necho ECS_CLUSTER=DemoApiClusterProd >> \/etc\/ecs\/ecs.config\necho ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> \/etc\/ecs\/ecs.config\necho ECS_CONTAINER_STOP_TIMEOUT=1m >> \/etc\/ecs\/ecs.config\necho ECS_ENGINE_AUTH_TYPE=docker >> \/etc\/ecs\/ecs.config\necho "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> \/etc\/ecs\/ecs.config<\/code><\/pre>\n
<\/p>\n
ECS_CLUSTER=DemoApiClusterProd<\/code> \u2014 o par\u00e2metro indica que a inst\u00e2ncia pertence a um cluster com o nome especificado, ou seja, esse cluster poder\u00e1 alocar suas tarefas neste servidor. Ainda n\u00e3o criamos um cluster, mas ao cri\u00e1-lo, usaremos este nome.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 o par\u00e2metro indica que, ao receber um sinal de desligamento de uma inst\u00e2ncia spot, todas as tarefas nela devem ser transferidas para o estado Draining.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 o par\u00e2metro indica que, ap\u00f3s receber o sinal SIGINT, todas as tarefas t\u00eam 1 minuto antes de serem encerradas.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_TYPE=docker<\/code> \u2014 o par\u00e2metro indica que o esquema de autoriza\u00e7\u00e3o utilizado \u00e9 o docker.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 par\u00e2metros de conex\u00e3o para um registro de containers privado, onde suas imagens Docker s\u00e3o armazenadas. Se for p\u00fablico, n\u00e3o \u00e9 necess\u00e1rio especificar nada.<\/p>\n
<\/p>\n
Neste artigo, utilizarei uma imagem p\u00fablica do Docker Hub, portanto, n\u00e3o \u00e9 necess\u00e1rio especificar par\u00e2metros. ECS_ENGINE_AUTH_TYPE<\/code> e ECS_ENGINE_AUTH_DATA<\/code> n\u00e3o \u00e9 necess\u00e1rio.<\/p>\n
<\/p>\n
\u00c9 \u00fatil saber<\/strong>: \u00e9 recomend\u00e1vel atualizar regularmente a AMI, pois, em novas vers\u00f5es, as vers\u00f5es do Docker, Linux, agente ECS, etc., s\u00e3o atualizadas. Para n\u00e3o esquecer disso, voc\u00ea pode configurar notifica\u00e7\u00f5es<\/a><\/noindex> sobre o lan\u00e7amento de novas vers\u00f5es. Voc\u00ea pode receber notifica\u00e7\u00f5es por e-mail e atualizar manualmente, ou pode escrever uma fun\u00e7\u00e3o Lambda que criar\u00e1 automaticamente uma nova vers\u00e3o do Launch Template com a AMI atualizada.<\/p>\n
<\/p>\n
Grupo de Auto Scaling EC2<\/strong><\/h3>\n
<\/p>\n
O grupo de Auto Scaling \u00e9 respons\u00e1vel por iniciar e dimensionar inst\u00e2ncias. O gerenciamento dos grupos \u00e9 feito na se\u00e7\u00e3o EC2 -> Auto Scaling -> Grupos de Auto Scaling.<\/p>\n
<\/p>\n
Template de Lan\u00e7amento<\/strong> \u2014 selecionamos o template criado na etapa anterior. Mantemos a vers\u00e3o padr\u00e3o.<\/p>\n
<\/p>\n
Op\u00e7\u00f5es de compra e tipos de inst\u00e2ncia<\/strong> \u2014 especificamos os tipos de inst\u00e2ncias para o cluster. Aderir ao template de lan\u00e7amento usa o tipo de inst\u00e2ncia do Launch Template. Combinar op\u00e7\u00f5es de compra e tipos de inst\u00e2ncia permite configurar os tipos de inst\u00e2ncias de forma flex\u00edvel. Usaremos esta op\u00e7\u00e3o.<\/p>\n
<\/p>\n
Base On-Demand Opcional<\/strong> \u2014 o n\u00famero de inst\u00e2ncias normais, n\u00e3o spot, que sempre estar\u00e3o em funcionamento.<\/p>\n
<\/p>\n
Percentual On-Demand acima da base<\/strong> \u2014 a propor\u00e7\u00e3o percentual de inst\u00e2ncias normais para inst\u00e2ncias spot, 50-50 distribuir\u00e1 igualmente, 20-80 far\u00e1 com que, para cada inst\u00e2ncia normal, sejam levantadas 4 inst\u00e2ncias spot. Neste exemplo, indicarei 50-50, mas na realidade frequentemente utilizamos 20-80, em alguns casos 0-100.<\/p>\n
<\/p>\n
Tipos de inst\u00e2ncia<\/strong> \u2014 aqui voc\u00ea pode especificar tipos adicionais de inst\u00e2ncias que ser\u00e3o utilizadas no cluster. Nunca utilizamos isso, pois n\u00e3o entendo muito o sentido dessa hist\u00f3ria. Talvez esteja relacionado a limites em tipos espec\u00edficos de inst\u00e2ncias, mas eles s\u00e3o aumentados facilmente pelo suporte. Se voc\u00ea sabe como isso se aplica, ficarei feliz em ler nos coment\u00e1rios)<\/p>\n
<\/p>\n
\"Cria\u00e7\u00e3o<\/p>\n
<\/p>\n
Rede<\/strong> \u2014 configura\u00e7\u00f5es de rede, voc\u00ea escolhe o VPC e as sub-redes para as m\u00e1quinas; na maioria das vezes, \u00e9 melhor selecionar todas as sub-redes dispon\u00edveis.<\/p>\n
<\/p>\n
Balanceamento de carga<\/strong> \u2014 configura\u00e7\u00f5es do balanceador, mas faremos isso separadamente, aqui n\u00e3o alteramos nada. Verifica\u00e7\u00f5es de sa\u00fade<\/strong> tamb\u00e9m ser\u00e3o configuradas mais tarde.<\/p>\n
<\/p>\n
Tamanho do grupo<\/strong> \u2014 especificamos limites para o n\u00famero de m\u00e1quinas no cluster e o n\u00famero desejado de m\u00e1quinas na inicializa\u00e7\u00e3o. O n\u00famero de m\u00e1quinas no cluster nunca ser\u00e1 menor do que o m\u00ednimo especificado e maior do que o m\u00e1ximo, mesmo que as m\u00e9tricas sinalizem que a escalabilidade deve ocorrer.<\/p>\n
<\/p>\n
Pol\u00edticas de escalonamento<\/strong> \u2014 par\u00e2metros de escalonamento, mas iremos escalar com base nas tarefas ECS em execu\u00e7\u00e3o, ent\u00e3o configuraremos o escalonamento mais tarde.<\/p>\n
<\/p>\n
Prote\u00e7\u00e3o de escala de inst\u00e2ncias<\/strong> \u2014 prote\u00e7\u00e3o contra exclus\u00e3o de inst\u00e2ncias durante o escalonamento para baixo. Ativamos isso para que o ASG n\u00e3o remova a m\u00e1quina que est\u00e1 executando tarefas. Desativar a prote\u00e7\u00e3o para inst\u00e2ncias sem tarefas ser\u00e1 feito pelo ECS Capacity Provider.<\/p>\n
<\/p>\n
Adicionar tags<\/strong> \u2014 voc\u00ea pode especificar tags para inst\u00e2ncias (para isso, a op\u00e7\u00e3o Tag new instances deve estar marcada). Recomendo usar a tag Name, assim todas as inst\u00e2ncias que s\u00e3o iniciadas dentro do grupo ter\u00e3o o mesmo nome, facilitando a visualiza\u00e7\u00e3o no console.<\/p>\n
<\/p>\n
\"Cria\u00e7\u00e3o<\/p>\n
<\/p>\n
Ap\u00f3s criar o grupo, abra-o e acesse a se\u00e7\u00e3o Configura\u00e7\u00f5es Avan\u00e7adas, pois na fase de cria\u00e7\u00e3o nem todas as op\u00e7\u00f5es est\u00e3o vis\u00edveis no console.<\/p>\n
<\/p>\n
Pol\u00edticas de termina\u00e7\u00e3o<\/strong> \u2014 regras consideradas ao remover inst\u00e2ncias. Elas s\u00e3o aplicadas em ordem. Geralmente, usamos aquelas mostradas na imagem abaixo. Primeiro, removemos inst\u00e2ncias com o Launch Template mais antigo (por exemplo, se atualizarmos o AMI, uma nova vers\u00e3o ser\u00e1 criada, mas todas as inst\u00e2ncias j\u00e1 ter\u00e3o mudado para ela). Depois, escolhemos as inst\u00e2ncias que est\u00e3o mais pr\u00f3ximas do pr\u00f3ximo hor\u00e1rio de c\u00e1lculo fatur\u00e1vel. Em seguida, selecionamos as mais antigas pela data de lan\u00e7amento.<\/p>\n
<\/p>\n
\"Cria\u00e7\u00e3o<\/p>\n
<\/p>\n
\u00c9 \u00fatil saber<\/strong>: para atualizar todas as m\u00e1quinas no cluster, \u00e9 conveniente usar Atualiza\u00e7\u00e3o de inst\u00e2ncia<\/a><\/noindex>. Se voc\u00ea combinar isso com a fun\u00e7\u00e3o Lambda da etapa anterior, ter\u00e1 um sistema de atualiza\u00e7\u00e3o de inst\u00e2ncias completamente automatizado. Antes de atualizar todas as m\u00e1quinas, \u00e9 necess\u00e1rio desativar a prote\u00e7\u00e3o de escala de inst\u00e2ncia para todas as inst\u00e2ncias no grupo. N\u00e3o a configura\u00e7\u00e3o no grupo, mas sim a prote\u00e7\u00e3o das pr\u00f3prias m\u00e1quinas, isso \u00e9 feito na aba de gerenciamento de inst\u00e2ncias.<\/p>\n
<\/p>\n
Application Load Balancer e EC2 Target Group<\/h3>\n
<\/p>\n
O balanceador \u00e9 criado na se\u00e7\u00e3o EC2 \u2192 Load Balancing \u2192 Load Balancers. Usaremos o Application Load Balancer; uma compara\u00e7\u00e3o dos diferentes tipos de balanceadores pode ser lida na p\u00e1gina do servi\u00e7o<\/a><\/noindex>.<\/p>\n
<\/p>\n
Listeners<\/strong> \u2014 faz sentido criar as portas 80 e 443 e fazer o redirecionamento de 80 para 443 mais tarde, usando regras do balanceador.<\/p>\n
<\/p>\n
Availability Zones<\/strong> \u2014 na maioria dos casos, escolhemos todas as zonas de disponibilidade.<\/p>\n
<\/p>\n
Configure Security Settings<\/strong> \u2014 aqui \u00e9 indicado o certificado SSL para o balanceador, a op\u00e7\u00e3o mais conveniente \u00e9 criar um certificado<\/a><\/noindex> no ACM. As diferen\u00e7as Security Policy<\/strong> podem ser lidas em documenta\u00e7\u00e3o<\/a><\/noindex>, pode-se deixar o selecionado por padr\u00e3o ELBSecurityPolicy-2016-08<\/code>. Ap\u00f3s criar o balanceador, voc\u00ea ver\u00e1 seu DNS name<\/strong>, para o qual \u00e9 necess\u00e1rio configurar um CNAME para seu dom\u00ednio. Por exemplo, assim \u00e9 como aparece no Cloudflare.<\/p>\n
<\/p>\n
\"Cria\u00e7\u00e3o<\/p>\n
<\/p>\n
Security Group<\/strong> \u2014 criamos ou escolhemos um grupo de seguran\u00e7a para o balanceador; mais detalhes sobre isso foram escritos um pouco acima na se\u00e7\u00e3o EC2 Launch Template \u2192 Configura\u00e7\u00f5es de rede.<\/p>\n
<\/p>\n
Target group<\/strong> \u2014 criamos um grupo que \u00e9 respons\u00e1vel pelo roteamento de solicita\u00e7\u00f5es do balanceador para as m\u00e1quinas e verifica sua disponibilidade, para substitu\u00ed-las em caso de problemas. Target type<\/strong> deve ser Instance, Protocol<\/strong> e Porta<\/strong> qualquer um, se voc\u00ea estiver usando HTTPS para a comunica\u00e7\u00e3o entre o balanceador e as inst\u00e2ncias, ent\u00e3o dever\u00e1 carregar o certificado nelas. Neste exemplo, n\u00e3o faremos isso, apenas deixaremos a porta 80.<\/p>\n
<\/p>\n
Verifica\u00e7\u00f5es de sa\u00fade<\/strong> \u2014 par\u00e2metros de verifica\u00e7\u00e3o de integridade do servi\u00e7o. No servi\u00e7o real, isso deve ser uma solicita\u00e7\u00e3o separada, que implementa partes importantes da l\u00f3gica de neg\u00f3cios; neste exemplo, deixarei as configura\u00e7\u00f5es padr\u00e3o. Em seguida, pode-se escolher o intervalo de solicita\u00e7\u00f5es, o tempo de espera, c\u00f3digos de resposta bem-sucedidos, etc. No nosso exemplo, indicaremos c\u00f3digos de sucesso de 200-399, porque a imagem do Docker que ser\u00e1 utilizada retorna o c\u00f3digo 304.<\/p>\n
<\/p>\n
\"Cria\u00e7\u00e3o<\/p>\n
<\/p>\n
Register Targets<\/strong> \u2014 aqui s\u00e3o escolhidas as m\u00e1quinas para o grupo, mas neste caso isso ser\u00e1 gerenciado pelo ECS, portanto, apenas pulamos esta etapa.<\/p>\n
<\/p>\n
\u00c9 \u00fatil saber<\/strong>: no n\u00edvel do balanceador, voc\u00ea pode ativar logs que ser\u00e3o salvos no S3 em um determinado formato<\/a><\/noindex>. A partir da\u00ed, voc\u00ea pode export\u00e1-los para servi\u00e7os externos de an\u00e1lise ou fazer consultas SQL diretamente nos dados no S3 com o Athena<\/a><\/noindex>. Isso \u00e9 conveniente e funciona sem nenhum c\u00f3digo adicional. Tamb\u00e9m recomendo configurar a exclus\u00e3o de logs do bucket S3 ap\u00f3s um per\u00edodo de tempo definido.<\/p>\n
<\/p>\n
Defini\u00e7\u00e3o de Tarefa ECS<\/h3>\n
<\/p>\n
Nas etapas anteriores, criamos tudo o que est\u00e1 relacionado \u00e0 infraestrutura do servi\u00e7o, agora passamos para a descri\u00e7\u00e3o dos cont\u00eaineres que iremos executar. Isso \u00e9 feito na se\u00e7\u00e3o ECS \u2192 Defini\u00e7\u00f5es de Tarefa.<\/p>\n
<\/p>\n
Compatibilidade do tipo de inicializa\u00e7\u00e3o<\/strong> \u2014 escolhemos EC2.<\/p>\n
<\/p>\n
Fun\u00e7\u00e3o IAM de execu\u00e7\u00e3o da tarefa<\/strong> \u2014 selecionamos ecsTaskExecutionRole<\/code>. Com ela, os logs s\u00e3o escritos, o acesso a vari\u00e1veis secretas \u00e9 concedido, entre outros.<\/p>\n
<\/p>\n
Na se\u00e7\u00e3o Defini\u00e7\u00f5es de Cont\u00eainer, clique em Adicionar Cont\u00eainer.<\/p>\n
<\/p>\n
Imagem<\/strong> \u2014 o link para a imagem com o c\u00f3digo do projeto, neste exemplo, usarei uma imagem p\u00fablica do Docker Hub bitnami\/node-example:0.0.1<\/a><\/noindex>.<\/p>\n
<\/p>\n
Limites de Mem\u00f3ria<\/strong> \u2014 limites de mem\u00f3ria para o cont\u00eainer. Limite Rigoroso<\/strong> \u2014 limite rigoroso, se o cont\u00eainer ultrapassar o valor especificado, o comando docker kill ser\u00e1 executado, o cont\u00eainer morrer\u00e1 imediatamente. Limite Suave<\/strong> \u2014 limite suave, o cont\u00eainer pode ultrapassar o valor especificado, mas ao alocar tarefas para as m\u00e1quinas, esse par\u00e2metro ser\u00e1 considerado. Por exemplo, se a m\u00e1quina tem 4 GiB de mem\u00f3ria RAM e o limite suave do cont\u00eainer \u00e9 2048 MiB, ent\u00e3o no m\u00e1ximo 2 tarefas podem ser executadas nessa m\u00e1quina com esse cont\u00eainer. Na realidade, 4 GiB de RAM \u00e9 um pouco menos que 4096 MiB, isso pode ser verificado na aba Inst\u00e2ncias ECS no cluster. O limite suave n\u00e3o pode ser maior que o limite rigoroso. \u00c9 importante entender que se uma tarefa tiver v\u00e1rios cont\u00eaineres, seus limites s\u00e3o somados.<\/p>\n
<\/p>\n
Mapeamentos de Porta<\/strong> \u2014 em Porta do Host<\/strong> definimos 0, isso significa que a porta ser\u00e1 designada dinamicamente, ela ser\u00e1 monitorada pelo Target Group. Porta do Cont\u00eainer<\/strong> \u2014 a porta na qual seu aplicativo est\u00e1 executando, frequentemente definida no comando de execu\u00e7\u00e3o ou designada no c\u00f3digo do seu aplicativo, Dockerfile etc. Para o nosso exemplo, usaremos 3000, pois est\u00e1 especificado no Dockerfile<\/a><\/noindex> imagem utilizada.<\/p>\n
<\/p>\n
Verifica\u00e7\u00e3o de integridade<\/strong> \u2014 par\u00e2metros para verificar a operabilidade do cont\u00eainer, n\u00e3o confundir com a configura\u00e7\u00e3o no Target Group.<\/p>\n
<\/p>\n
Ambiente<\/strong> \u2014 configura\u00e7\u00f5es do ambiente. unidades de CPU<\/strong> \u2014 semelhante aos limites de mem\u00f3ria, mas sobre o processador. Cada n\u00facleo do processador representa 1024 unidades, ent\u00e3o se o servidor tiver um processador de dois n\u00facleos e o cont\u00eainer tiver um valor de 512, ser\u00e1 poss\u00edvel executar 4 tarefas com esse cont\u00eainer em um \u00fanico servidor. As unidades de CPU sempre correspondem ao n\u00famero de n\u00facleos, n\u00e3o pode haver um n\u00famero ligeiramente menor, como acontece com a mem\u00f3ria.<\/p>\n
<\/p>\n
Comando<\/strong> \u2014 comando para iniciar o servi\u00e7o dentro do cont\u00eainer, todos os par\u00e2metros s\u00e3o especificados por v\u00edrgula. Isso pode ser gunicorn, npm, etc. Se n\u00e3o for especificado, o valor da diretiva CMD do Dockerfile ser\u00e1 utilizado. Especificamos npm,start<\/code>.<\/p>\n
<\/p>\n
Vari\u00e1veis de ambiente<\/strong> \u2014 vari\u00e1veis de ambiente do cont\u00eainer. Podem ser tanto dados de texto simples, quanto vari\u00e1veis secretas do Secrets Manager<\/a><\/noindex> ou Parameter Store<\/a><\/noindex>.<\/p>\n
<\/p>\n
Armazenamento e Registro<\/strong> \u2014 aqui configuraremos o registro no CloudWatch Logs (servi\u00e7o de logs da AWS). Para isso, basta marcar a op\u00e7\u00e3o Auto-configure CloudWatch Logs. Ap\u00f3s criar a Task Definition, um grupo de logs ser\u00e1 criado automaticamente no CloudWatch. Por padr\u00e3o, os logs s\u00e3o armazenados indefinidamente, recomendo alterar o Retention period de Never Expire para o per\u00edodo desejado. Isso pode ser feito em CloudWatch Log groups, clicando no per\u00edodo atual e escolhendo um novo.<\/p>\n
<\/p>\n
\"Cria\u00e7\u00e3o<\/p>\n
<\/p>\n
ECS Cluster e ECS Capacity Provider<\/h3>\n
<\/p>\n
Vamos para a se\u00e7\u00e3o ECS \u2192 Clusters para criar um cluster. Como modelo, escolhemos EC2 Linux + Networking.<\/p>\n
<\/p>\n
Nome do cluster<\/strong> \u2014 \u00e9 muito importante, aqui fazemos o mesmo nome que est\u00e1 indicado no Launch Template na par\u00e1metro ECS_CLUSTER<\/code>, no nosso caso \u2014 DemoApiClusterProd<\/code>. Marque a op\u00e7\u00e3o Create an empty cluster. Opcionalmente, voc\u00ea pode habilitar o Container Insights para visualizar m\u00e9tricas dos servi\u00e7os no CloudWatch. Se tudo foi feito corretamente, na se\u00e7\u00e3o ECS Instances, voc\u00ea ver\u00e1 as m\u00e1quinas que foram criadas no Auto Scaling group.<\/p>\n
<\/p>\n
\"Cria\u00e7\u00e3o<\/p>\n
<\/p>\n
Vamos para a guia Capacity Providers<\/strong> e criamos um novo. Lembro que ele \u00e9 necess\u00e1rio para gerenciar a cria\u00e7\u00e3o e desligamento de m\u00e1quinas, dependendo do n\u00famero de tarefas ECS em execu\u00e7\u00e3o. \u00c9 importante notar que o provedor pode estar vinculado apenas a um \u00fanico grupo.<\/p>\n
<\/p>\n
Auto Scaling group<\/strong> \u2014 escolhemos o grupo criado anteriormente.<\/p>\n
<\/p>\n
Escalonamento gerenciado<\/strong> \u2014 habilitamos para que o provedor possa escalar o servi\u00e7o.<\/p>\n
<\/p>\n
Capacidade alvo %<\/strong> \u2014 qual porcentagem de carga das m\u00e1quinas precisamos para as tarefas. Se especificar 100%, todas as m\u00e1quinas estar\u00e3o sempre ocupadas com tarefas em execu\u00e7\u00e3o. Se especificar 50%, metade das m\u00e1quinas estar\u00e1 sempre livre. Nesse caso, se ocorrer um pico repentino na carga, novos t\u00e1xis ser\u00e3o imediata e automaticamente alocados nas m\u00e1quinas livres, sem necessidade de aguardar a implanta\u00e7\u00e3o de inst\u00e2ncias.<\/p>\n
<\/p>\n
Prote\u00e7\u00e3o de termina\u00e7\u00e3o gerenciada<\/strong> \u2014 ativamos, este par\u00e2metro permite que o provedor remova a prote\u00e7\u00e3o das inst\u00e2ncias contra a exclus\u00e3o. Isso acontece quando n\u00e3o h\u00e1 tarefas ativas na m\u00e1quina e permite a capacidade alvo %.<\/p>\n
<\/p>\n
Servi\u00e7o ECS e configura\u00e7\u00e3o de escalonamento<\/h3>\n
<\/p>\n
\u00daltima etapa :) Para criar um servi\u00e7o, \u00e9 necess\u00e1rio acessar o cluster criado anteriormente na aba Servi\u00e7os.<\/p>\n
<\/p>\n
Tipo de lan\u00e7amento<\/strong> \u2014 \u00e9 necess\u00e1rio clicar em Alternar para a estrat\u00e9gia de provedor de capacidade e escolher o provedor criado anteriormente.<\/p>\n
<\/p>\n
\"Cria\u00e7\u00e3o<\/p>\n
<\/p>\n
Defini\u00e7\u00e3o de tarefa<\/strong> \u2014 selecionamos a Defini\u00e7\u00e3o de Tarefa criada anteriormente e sua revis\u00e3o.<\/p>\n
<\/p>\n
Nome do servi\u00e7o<\/strong> \u2014 para n\u00e3o confundir, sempre indicamos o mesmo que a Defini\u00e7\u00e3o de Tarefa.<\/p>\n
<\/p>\n
Tipo de servi\u00e7o<\/strong> \u2014 sempre Replica.<\/p>\n
<\/p>\n
N\u00famero de tarefas<\/strong> \u2014 n\u00famero desejado de tarefas ativas no servi\u00e7o. Este par\u00e2metro \u00e9 gerenciado pelo escalonamento, mas ainda precisa ser especificado.<\/p>\n
<\/p>\n
Porcentagem m\u00ednima saud\u00e1vel<\/strong> e Porcentagem m\u00e1xima<\/strong> \u2014 determinam o comportamento das tarefas durante a implanta\u00e7\u00e3o. Os valores padr\u00e3o 100 e 200 indicam que no momento da implanta\u00e7\u00e3o, o n\u00famero de tarefas aumentar\u00e1 duas vezes, e depois retornar\u00e1 ao desejado. Se voc\u00ea tiver 1 tarefa, min=0 e max=100, ela ser\u00e1 encerrada durante a implanta\u00e7\u00e3o e, em seguida, uma nova ser\u00e1 iniciada, o que resultar\u00e1 em inatividade. Se tiver 1 tarefa, min=50 e max=150, a implanta\u00e7\u00e3o n\u00e3o acontecer\u00e1, pois n\u00e3o \u00e9 poss\u00edvel dividir 1 tarefa ao meio ou aumentar em 1,5 vezes.<\/p>\n
<\/p>\n
Tipo de implanta\u00e7\u00e3o<\/strong> \u2014 deixamos Atualiza\u00e7\u00e3o progressiva.<\/p>\n
<\/p>\n
Templates de aloca\u00e7\u00e3o<\/strong> \u2014 regras para aloca\u00e7\u00e3o de tarefas nas m\u00e1quinas. O padr\u00e3o \u00e9 AZ Balanced Spread \u2014 isso significa que cada nova tarefa ser\u00e1 colocada em uma nova inst\u00e2ncia at\u00e9 que as m\u00e1quinas sejam iniciadas em todas as zonas de disponibilidade. Normalmente, fazemos BinPack \u2014 CPU e Spread \u2014 AZ; com essa pol\u00edtica, as tarefas s\u00e3o alocadas o mais compactamente poss\u00edvel em uma m\u00e1quina em termos de CPU. Se for necess\u00e1rio criar uma nova m\u00e1quina, ela ser\u00e1 criada em uma nova zona de disponibilidade.<\/p>\n
<\/p>\n
\"Cria\u00e7\u00e3o<\/p>\n
<\/p>\n
Tipo de balanceador de carga<\/strong> \u2014 escolhemos Application Load Balancer.<\/p>\n
<\/p>\n
Fun\u00e7\u00e3o IAM do servi\u00e7o<\/strong> \u2014 escolhemos ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Nome do balanceador de carga<\/strong> \u2014 escolhemos o balanceador criado anteriormente.<\/p>\n
<\/p>\n
Per\u00edodo de gra\u00e7a da verifica\u00e7\u00e3o de sa\u00fade<\/strong> \u2014 pausa antes de realizar as verifica\u00e7\u00f5es de funcionalidade ap\u00f3s a implanta\u00e7\u00e3o de uma nova tarefa, costumamos definir 60 segundos.<\/p>\n
<\/p>\n
Container para balanceamento de carga<\/strong> \u2014 na op\u00e7\u00e3o Nome do grupo-alvo, selecionamos o grupo criado anteriormente e tudo ser\u00e1 preenchido automaticamente.<\/p>\n
<\/p>\n
\"Cria\u00e7\u00e3o<\/p>\n
<\/p>\n
Escalonamento Autom\u00e1tico de Servi\u00e7os<\/strong> \u2014 par\u00e2metros de escalonamento do servi\u00e7o. Selecionamos Configurar Escalonamento Autom\u00e1tico de Servi\u00e7os para ajustar a contagem desejada do seu servi\u00e7o. Definimos a quantidade m\u00ednima e m\u00e1xima de tarefas durante o escalonamento.<\/p>\n
<\/p>\n
Fun\u00e7\u00e3o IAM para Escalonamento Autom\u00e1tico de Servi\u00e7os<\/strong> \u2014 escolhemos AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Pol\u00edticas de escalonamento autom\u00e1tico de tarefas<\/strong> \u2014 regras para escalonamento. Existem 2 tipos:<\/p>\n
<\/p>\n
    \n
  1. Rastreamento de meta<\/strong> \u2014 rastreamento de m\u00e9tricas-alvo (uso de CPU\/RAM ou n\u00famero de solicita\u00e7\u00f5es por tarefa). Por exemplo, queremos que a carga m\u00e9dia do processador esteja em 85%; quando ela exceder, novas tarefas ser\u00e3o adicionadas at\u00e9 que atinja o valor alvo. Se a carga estiver abaixo, as tarefas ser\u00e3o removidas, a menos que a prote\u00e7\u00e3o contra escalonamento para baixo esteja ativada (Desativar escalonamento para baixo<\/strong>).<\/li>\n
  2. Escalonamento em etapas<\/strong> \u2014 rea\u00e7\u00e3o a um evento arbitr\u00e1rio. Aqui podemos configurar a rea\u00e7\u00e3o a qualquer evento (Alarme CloudWatch); quando ocorrer, podemos adicionar ou remover uma quantidade espec\u00edfica de tarefas ou indicar um n\u00famero exato de tarefas.<\/li>\n<\/ol>\n
    <\/p>\n
    O servi\u00e7o pode ter v\u00e1rias regras de escalonamento, o que pode ser \u00fatil, desde que n\u00e3o entrem em conflito uns com os outros.<\/p>\n
    <\/p>\n
    Conclus\u00e3o<\/h2>\n
    <\/p>\n
    Se voc\u00ea seguiu as instru\u00e7\u00f5es e usou a mesma imagem do Docker, seu servi\u00e7o deve retornar essa p\u00e1gina.<\/p>\n
    <\/p>\n
    \"Cria\u00e7\u00e3o<\/p>\n
    <\/p>\n
      \n
    1. Criamos um modelo pelo qual todas as m\u00e1quinas no servi\u00e7o s\u00e3o iniciadas. Tamb\u00e9m aprendemos a atualizar as m\u00e1quinas ao alterar o modelo.<\/li>\n
    2. Configuramos o tratamento do sinal de parada da inst\u00e2ncia spot, para que dentro de um minuto ap\u00f3s receb\u00ea-lo, todas as tarefas em execu\u00e7\u00e3o sejam removidas da m\u00e1quina, garantindo que nada seja perdido ou interrompido.<\/li>\n
    3. Subimos um balanceador para distribuir uniformemente a carga entre as m\u00e1quinas.<\/li>\n
    4. Criamos um servi\u00e7o que opera em inst\u00e2ncias spot, reduzindo assim os custos com m\u00e1quinas em cerca de 3 vezes.<\/li>\n
    5. Configuramos o escalonamento autom\u00e1tico em ambas as dire\u00e7\u00f5es para lidar com aumentos de carga, mas ao mesmo tempo n\u00e3o pagar por inatividade.<\/li>\n
    6. Usamos um Provedor de Capacidade para que o aplicativo gerencie a infraestrutura (m\u00e1quinas), e n\u00e3o o contr\u00e1rio.<\/li>\n
    7. Estamos indo muito bem.<\/li>\n<\/ol>\n
      <\/p>\n
      Se voc\u00ea tem picos de carga previs\u00edveis, por exemplo, ao fazer uma grande campanha de e-mail, pode configurar o escalonamento de acordo com um cronograma<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      Al\u00e9m disso, \u00e9 poss\u00edvel fazer escalonamento com base em dados de diferentes partes do seu sistema. Por exemplo, temos a funcionalidade de envio de ofertas promocionais individuais<\/a><\/noindex> para usu\u00e1rios do aplicativo m\u00f3vel. \u00c0s vezes, a campanha \u00e9 enviada para mais de 1 milh\u00e3o de pessoas. Ap\u00f3s tal envio, sempre h\u00e1 um grande aumento nas solicita\u00e7\u00f5es ao API, pois muitos usu\u00e1rios acessam o aplicativo ao mesmo tempo. Portanto, se percebemos que h\u00e1 uma quantidade significativamente maior de promo\u00e7\u00f5es programadas para envio do que o padr\u00e3o, podemos rapidamente iniciar v\u00e1rias m\u00e1quinas e tarefas adicionais para nos prepararmos para a carga.<\/p>\n
      <\/p>\n
      Ficarei feliz se voc\u00eas compartilharem casos interessantes de uso de inst\u00e2ncias spot e ECS ou alguma dica sobre escalonamento nos coment\u00e1rios.<\/p>\n
      <\/p>\n
      Em breve, publicaremos artigos sobre como processamos milhares de eventos anal\u00edticos por segundo em uma pilha predominantemente serverless (com custos) e sobre como \u00e9 feito o deploy de servi\u00e7os com GitLab CI e Terraform Cloud.<\/p>\n
      <\/p>\n
      Siga-nos, vai ser interessante!<\/p>\n
      Apenas usu\u00e1rios registrados podem participar da pesquisa. Entre<\/a><\/noindex>, por favor.<\/p>\n
      Voc\u00ea utiliza inst\u00e2ncias spot em produ\u00e7\u00e3o?<\/h2>\n