Bom pessoal, nessa aula nós iremos falar sobre as Auto Scaling Policies. Essas policies, elas definem como o nosso cluster ou em quais condições o nosso cluster deve adicionar novas instâncias ou remover instâncias. Então nós podemos, por exemplo, definir um agendamento. Nós sabemos que na quarta-feira é o dia em que nós recebemos uma carga de trabalho maior no nosso cluster. Então, nós temos mais requisições, nós temos mais pessoas acessando a nossa aplicação por algum motivo na quarta-feira, porque na quarta-feira, por exemplo, nós temos sempre um desconto para um determinado produto. Está imaginando aí um webcommerce ou algo do tipo. Nesse caso, como nós conseguimos prever esse comportamento da utilização da nossa aplicação, nós podemos definir o agendamento em que na quarta-feira nós vamos aumentar o número de instâncias do nosso cluster para 20, por exemplo. Geralmente nós rodamos a nossa aplicação com 10 instâncias, mas na quarta-feira nós precisamos de 20 instâncias porque o número de acesso geralmente dobra. Então nós criamos o agendamento para que na quarta-feira o nosso cluster, em um determinado horário, tenha exatamente 20 instâncias. E isso vai acontecer de forma automática. E nós podemos fazer a mesma coisa também para diminuir o número de instâncias. Então, passou a quarta-feira ou na quarta-feira à noite mesmo, nós diminuímos o número de instâncias para 10 novamente. Então, nós temos essa flexibilidade que funciona muito bem quando a nossa carga de trabalho pode ser prevista, ela é estável, ela segue um padrão. Temos também um serviço que a AWS oferece que é o scaling preditivo. Então, nós não configuramos nenhuma regra. oferece, que é o scaling preditivo. Então, nós não configuramos nenhuma regra. A própria AWS vai entender os padrões, vai entender o comportamento da sua aplicação, como funciona a carga de trabalho naquele cluster através do tempo e baseado nessas informações históricas, ele mesmo vai fazer os ajustes na quantidade de instâncias. Então, ele vai prever a quantidade de instâncias necess Então, ele vai prever a quantidade de instâncias necessárias para atender aquela carga de trabalho específica. Isso funciona muito bem quando há um padrão, quando a nossa aplicação segue um padrão de consumo muito bem definido. Quando isso não é muito bem definido, quando há variações muito grandes, esse tipo de auto-scaling não é muito interessante, não funciona muito bem existem casos em que nós podemos customizar ainda mais onde nós não temos essa previsibilidade do nosso consumo então nós podemos definir regras de escalabilidade baseado em métricas e agora só para ficar claro alguns conceitos porque pode ser que eu fale sobre esses termos e você não entenda. Então, já para nós deixarmos isso claro, quando eu falar em Scale Out, eu estou falando em escalamento ou em escalabilidade horizontal. O Scale Out é quando nós adicionamos novas instâncias ao nosso cluster. As instâncias que já existem, elas permanecem trabalhando da mesma forma, porém nós vamos adicionar novas instâncias. Quando eu falo em scale in, ainda assim eu estou falando em escalabilidade horizontal, porém eu estou falando em diminuir o número de instâncias dentro daquele cluster. Existe uma outra forma de escalabilidade, que é a escalabilidade vertical. Nesse caso, a quantidade de instâncias permanece exatamente igual, porém eu aumento o capacity das minhas instâncias. Então eu aumento, por exemplo, o número de vcpus, aumento a memória, aumento o disco dessas instâncias. Beleza? Então só para ficar claro essa diferenciação e para dizer também que quando nós falamos aqui de escalabilidade nesses auto-scaling grupos, nós estamos falando de escalabilidade horizontal. Então, nós vamos aumentar o número de instâncias ou diminuir o número de instâncias. Então, dito isso, já tendo esse conceito bem claro, nós vamos aqui entender como nós podemos criar regras customizadas de escalabilidade horizontal baseado em métricas. Como eu já disse, temos ali a escalabilidade agendada e temos também a preditiva, mas para o nosso exemplo nós vamos falar das regras mais simples, onde nós definimos métricas que serão utilizadas como base para essas regras de escalabilidade. Primeiro, vamos dar uma olhada aqui no nosso cluster, no nosso grupo que nós criamos na aula anterior. Nós podemos observar aqui que existe uma aba Monitoring. Beleza? Aqui nós temos uma série de gráficos aqui que nós podemos dar uma olhada, mas eu gostaria de mostrar aqui para vocês o nosso EC2. Temos essa aba EC2, onde nós temos aqui uma série de métricas. A primeira delas, bastante interessante, é a utilização de CPUs. Então nós temos aqui como a utilização de CPU no nosso cluster está variando. Então isso aqui é no cluster todo, não é de uma máquina específica, mas é de todo o cluster. Nós temos aqui, por exemplo, leitura de disco, operações de leitura em bytes, em quantidade de operações, escrita e assim por diante. Temos também a quantidade de informações entrando, o network in e o network out, em bytes também, e essas informações podem realmente nos ajudar a definir as nossas regras de escalabilidade, porque se o nosso cluster, em média, ele já está chegando ali em 80% de utilização, já seria um bom sinal, um bom indicativo de que nós devemos aumentar a quantidade de instâncias, porque o nosso cluster já está trabalhando quase em capacidade máxima. Então nós temos todas essas métricas, nós podemos dar uma olhada nas métricas com mais detalhes aqui no CloudWatch. Então, se nós navegarmos aqui, nós teremos acesso ao CloudWatch. Nós temos aqui, por exemplo, o Explorer de métricas, onde nós podemos verificar quais as métricas que a AWS nos oferece. Aqui, no nosso caso, nós estamos trabalhando com o serviço de computação, com EC2, então nós podemos olhar aqui, por exemplo, em CPU Utilization, que é a métrica, inclusive, que nós já vamos utilizar. Aqui em From nós podemos filtrar quais são as máquinas que nós vamos considerar aqui nas nossas métricas, e nós podemos filtrar, por exemplo, por Auto Scaling Group Name. Então nós selecionamos aqui, e nós selecionamos o nosso Auto Scaling. Então ele vai olhar simplesmente para a utilização de CPU das máquinas que fazem parte desse Auto Scaling Group. E aqui nós temos, nós temos aqui, inclusive por nó, nós temos as nossas duas instâncias e temos as informações de utilização dessas duas instâncias. Nós temos funções de agregação, então nós podemos olhar para a média do consumo e aqui quando nós colocamos a média, ele já agrega o valor das duas instâncias que é inclusive o que nós precisamos, nós queremos olhar para o cluster como um todo e não simplesmente para uma única instância. Podemos ver também aqui valores mínimos, valores máximos, soma, então todas essas métricas disponíveis para o nosso cluster, elas podem ser utilizadas como regras, elas podem ser utilizadas como base para as nossas regras ou para as nossas policies de auto-scaling. No nosso caso, vamos utilizar CPU Utilization e vamos utilizar a média de utilização dentro desse cluster, dentro desse auto scaling group. Agora falando em números, eu penso que aqui para o nosso caso nós vamos considerar o seguinte, quando nós atingirmos ali 60% de utilização de CPU no nosso cluster, nós vamos aumentar a quantidade de instâncias em uma instância. Então nós vamos adicionar uma nova instância ao nosso Auto Scaling Group, claro, desde que esteja dentro daquele limite que nós definimos. Então se nós temos duas, nós vamos passar para três. Mas se aumentar mais ainda, não vai acontecer nada, por quê? Porque o nosso limite é três, de acordo com o que nós definimos lá no nosso Auto Scaling Group. Agora, quando nós chegarmos ali no percentual de 20% de utilização do nosso cluster, nós podemos tirar uma instância, nós podemos derrubar uma instância porque nós não estamos utilizando quase nada do capacity do nosso cluster. Então, nós tiramos aquela instância, no nosso caso se for 2, agora nós teremos uma única instância, mas nós não podemos diminuir mais do que isso, nós precisamos permanecer com pelo menos uma máquina dentro do nosso cluster. Esse é o nosso limite mínimo conforme foi definido lá no Auto Scaling Group. Então vamos lá, vamos partir aqui para a prática, já que nós entendemos como funciona na teoria. Então eu vou abrir aqui o arquivo main.tf do módulo do nosso cluster e primeiro eu vou criar a auto-scaling policy de scale-out, tá? Essa policy que ela incrementa uma máquina virtual sempre que nós atingimos um determinado limite de utilização de CPU. Vamos lá, primeiro nós teremos aqui o nosso recurso e o tipo desse recurso é a AWS auto-scaling policy eu vou chamar aqui scale-out E o tipo desse recurso é AWS Auto Scaling Policy, eu vou chamar aqui Scale Out Policy. Beleza? Nós vamos dar um nome para essa policy aqui, é arbitrário, tá? Eu vou escolher aqui como padrão o prefixo mais Scale Out, perfeito. Aqui nós vamos referenciar o nome do nosso auto-scaling group, nós precisamos ter essa referência, então basta nós referenciarmos aqui a AWS Auto-Scaling Group SG, ponto name. Além disso, nós temos um adjustment type, que eu vou copiar aqui, e aqui nós temos no nosso exemplo o adjustment type igual a change in capacity. O que significa isso daqui? Significa que nós vamos alterar o capacity do nosso cluster. Nós podemos também alterar em percentual. Então, nós podemos dizer que nós vamos aumentar o nosso cluster em 25%. Esse é outro tipo de adjustment type. E nós podemos também dar um valor exato. Então, nós podemos dizer que para essa policy, quando houver ali aquela métrica atingir determinado patamar, nós queremos exatamente 10 instâncias, independente do valor que tenha atualmente. Mas, no nosso caso, nós vamos simplesmente incrementar ou decrementar. E para isso, nós utilizamos o change incapacity. Perfeito? Aqui nós temos o scaling adjustment. Então, em quantas máquinas nós vamos aumentar ou decrementar o nosso cluster? No nosso caso, nós queremos aumentar em uma máquina. Então, essa policy sempre vai incrementar de uma em uma máquina. Nós poderemos colocar duas, três ou quatro. No nosso caso, nós vamos colocar uma. E aqui nós temos uma propriedade, um argumento muito importante, que é o CUDAL, que inclusive eu citei nas aulas anteriores, que define o seguinte, olha, após essa pólice ser acionada, após houver o trigger para essa pólice, o auto-scaling group vai esperar por alguns segundos até fazer um outro auto-scaling. Então, se nós colocarmos aqui, por exemplo, 60, se eu colocar aqui 60 segundos, quer dizer que na hora que nós aumentarmos o nosso cluster, nós adicionarmos uma nova máquina ao nosso cluster, a AWS vai esperar 60 segundos até adicionar uma outra máquina, caso seja necessário. Esses 60 segundos aqui é tempo suficiente para que a máquina ela de fato se inicialize e ela comece a trabalhar então após esses 60 segundos caso ainda haja necessidade de aumentar o capacete, então a AWS aumenta o capacete novamente, mas esses 60 segundos aqui seria o tempo de warm up conforme nós geralmente vemos ali na documentação ou o tempo de inicializaçãoup, conforme nós geralmente vemos ali na documentação, ou o tempo de inicialização, beleza? Aqui você pode colocar o valor desejado, mas é bom não colocar um valor muito pequeno, senão não vai dar tempo ali da sua máquina começar a trabalhar e de fato as métricas do seu cluster se alterarem para refletir aquela nova máquina no seu cluster, tá? Aqui no meu caso eu vou colocar 60, que inclusive é o valor baixo, tá? O valor default é 300. Beleza? E aqui, para a nossa policy, é só isso que nós precisamos, tá? Para esse recurso específico, mas você pode observar aqui que nós ainda não falamos, por exemplo, sobre as métricas, nós só definimos aqui a policy, mas não dizemos não falamos as métricas que nós vamos utilizar, é por isso que nós precisamos criar um alarme, então essas policies, o que faz a trigger da policy é um alarme do CloudWatch então nós faremos o seguinte nós teremos aqui um recurso, esse recurso será um AWS CloudWatch metric alarm e nós vamos chamar aqui de scale out alarm, nós vamos dar aqui uma descrição para este alarme então a alarm description vai ser igual a monitora, a utilização de CPU monitor, CPU utilization, aqui nós vamos colocar o alarm actions, no nosso caso quando nós tivermos este alarme, quando o estado deste alarme estiver como em alarm, nós iremos disparar o nosso auto-scaling, tá? E pra isso nós colocamos aqui alarm actions e referenciamos o ARM da nossa scale-out policy e poderíamos ter outras policies aqui também, tá? No nosso exemplo nós temos somente uma policy. Beleza, além dessa actions, nós vamos dar um nome para o nosso alarme, tá? Seguindo a mesma conversa que nós estamos seguindo até aqui, que é o prefix, scale out, alarme. Beleza? Aqui nós temos um comparador, tá? Que significa o seguinte, nós vamos disparar essa regra quando o valor, aqui no caso não é less than or equal, tá? É greater than. Greater than. Então, quando o valor da nossa métrica for igual, for maior ou igual ao nosso threshold. E qual que é esse threshold? Eu já vou colocar aqui, tá? O threshold vai ser, no nosso caso, a gente definiu 60%, né? Então, eu vou colocar aqui 60, tá? Seria o 60%, então esse alarme vai disparar quando a utilização da nossa CPU for maior ou igual a 60%, beleza. Mas agora nós precisamos informar qual que é a métrica, tá? E nós temos duas propriedades que nós precisamos informar para identificar a métrica, que são as seguintes, a namespace e o nome da métrica. Então, se nós voltarmos aqui na AWS, no console, nós temos aqui a nossa métrica, que é CPU Utilization, e temos aqui a nossa namespace, que no caso é EC2 Instance. Ele é a grupo aqui, mas o nome correto da métrica ou da namespace é a WS EC2. Inclusive, nós podemos pesquisar por aqui, deixa eu verificar se nós conseguimos aqui encontrar, tá? Nós temos aqui EC2, beleza? Essas daqui são as tags, temos aqui o nome da métrica CPU Utilization e a nossa namespace, deixa eu verificar aqui se nós Conseguimos encontrar Essa Namespace em algum lugar Eu acho que por aqui a gente não consegue Visualizar essa Namespace Assim Aqui nós conseguimos, então se nós Vermos aqui até Graphic Metrics Nós temos aqui os detalhes da métrica Nós temos a Namespace Que é WSC2 e temos aqui o nome da métrica que é CPU Utilization e nós temos uma tag que é Auto Scaling Group Name, Full Cycle, ASG. Então nós conseguimos refletir isso aqui na definição do nosso recurso, utilizando a namespace WSC2 e o nome da métrica. Além disso, nós precisamos passar uma estatística. Como nós vamos agrupar esses dados? Nós podemos agrupar a soma de todas as métricas, ou nós podemos colocar mínimo, máximo, ou então a média, que é o que nós precisamos. Nós queremos a média de todas as máquinas dentro daquele cluster. E agora, nós precisamos definir o que eu disse como tag, mas que na verdade é mais conhecido como dimension. Então, nós temos aqui as dimensões e as dimensões que nós vamos utilizar é auto-scaling loop name e aqui nós vamos referenciar o nome do nosso auto-scaling, que é exatamente o que nós fizemos aqui. Temos aqui as nossas dimensões e agora nós temos também outras duas propriedades, que é o evaluation period e o período. Então, essas duas propriedades são as seguintes, tá? São o período onde nós vamos agrupar essas métricas, então nós podemos colocar aqui como sendo 5 minutos, 1 minuto, 30 segundos, aqui para o nosso caso eu coloquei 30 segundos, e o evaluation period seria a quantidade de pontos, a quantidade de pontos que nós teremos aqui que será computado. Então, o que essa métrica quer dizer é o seguinte, esse alarme aqui vai disparar quando nós ultrapassarmos a média de utilização de CPU no nosso cluster acima de 60%, então quando for acima de 60% a utilização de CPU dentro do nosso cluster, a média de utilização, e isso acontecer pelo menos 3 vezes seguidas a cada 30 segundos. Então ele vai agrupar as métricas no período de 30 segundos e vai computar por três vezes e esse alarme só dispara se essa métrica estiver acima de 60% nas três vezes. Beleza? Então são vários números aqui, são várias formas de agrupar os dados, mas dê uma revisada, qualquer coisa volte aqui na aula, assista novamente que você vai entender aqui e olhando o gráfico fica muito mais claro, tá? Esse período aqui, os pontos, tudo isso fica muito mais claro quando nós olhamos no console. Dessa forma, nós já temos o nosso alarme, tá? Então, esse alarme aqui, ele vai disparar e ele vai iniciar a nossa policy de scale out, que vai adicionar, se possível possível uma VM dentro do nosso cluster. E agora para nós criarmos uma policy de scale in, é muito simples, basta nós duplicarmos aqui esse trecho de código eu vou alterar aqui de out para in, beleza e agora nós vamos mudar o capacity porém menos um, nós vamos decrementar a quantidade de instâncias dentro do nosso cluster, as demais propriedades permanecem iguais porém menos um. Nós vamos decrementar a quantidade de instâncias dentro do nosso cluster, as demais propriedades permanecem iguais, porém aqui nós vamos utilizar less than or equal, então nós vamos utilizar aqui menor do que ou igual a 20%. Então, se o nosso cluster está ali em menos de 20% de utilização de CPU, nós podemos remover uma máquina virtual deste cluster e as demais propriedades elas permanecem aqui exatamente iguais, tá? E eu acho que é isso, aparentemente nós não temos nada aqui que precisa ser alterado, agora nós vamos, claro, rodar aqui o nosso Terraform Plan, só para nós conferirmos se está tudo certo, nós temos aqui um recurso duplicado Deixa eu verificar aqui Ah sim, porque aqui eu não alterei de Out para In Eu preciso alterar para In também Beleza Scale Out, Scale Out Scale In, Scale In Salvando Vamos rodar aqui novamente Terraform Plan E aparentemente agora tá dando certo né tá dando um refresh aqui no state beleza e aqui agora nós temos as nossas policies sendo criadas tá vamos dar então terraforme apply auto approve e nós vamos esperar que essas policies sejam adicionadas na nossa conta. Beleza, dando um refresh aqui no state. Eu imagino que a criação dessas policies são rápidas, como já terminou, foi bem rápido. Agora nós vamos dar uma olhada aqui em automatic scaling nós temos dynamic scaling policies e aqui nós temos duas policies tá full cycle scale in e full cycle scale out e aqui nós temos definido tudo aquilo que nós colocamos todas as regras que nós colocamos nós podemos inclusive dar uma olhada aqui em edit nós podemos editar aqui nós temos o alarme que nós utilizamos, nós temos aqui que a ação é remover, remover uma das máquinas, um dos nossos Capacity Units. E beleza, aqui ele vai esperar 60 segundos antes de permitir ali uma nova Scaling Activity, uma nova atividade de escalabilidade. Ele espera 60 segundos para que a máquina se inicialize e que de fato o nosso cluster agora reflita a alteração, a quantidade de instâncias. Beleza, vamos dar um cancel aqui. E é isso, podemos também dar uma olhada aqui no Scale Out, mas não tem necessidade. Temos aqui as nossas Schedule Actions, que são aquelas policies que nós criamos de forma agendada. Então, todas as regras de escalabilidade estarão aqui. Se nós esperarmos alguns segundos, nós veremos que teremos aqui uma nova atividade, que vai ser a atividade de remoção de uma instância do nosso cluster, porque se nós olharmos em Monitoring, provavelmente nós estamos utilizando bem menos de 20% De uma instância do nosso cluster. Porque se nós olharmos em monitoring. Provavelmente nós estamos utilizando bem menos de 20% da nossa. De 20% do nosso CPU. Da nossa CPU. E aqui nós temos 0.20229. Então temos aí muita pouca utilização da nossa CPU. Já que nós não temos ali processos. Nós não temos o web server rodando e nada do tipo. Beleza? Então eu recomendo que você espere aí, que você pelo menos veja essa atividade de Scale In. Caso você queira ver também o Scale Out, você pode baixar. Eu creio que existe um package NPM que ele simplesmente roda um loop infinito, utilizando toda a CPU e dessa forma você vai conseguir enxergar esse scale out acontecendo. Só tome cuidado para não gastar muitos recursos, porque você pode ter uma surpresa ao final do mês quando vier a sua conta. Espero que você tenha gostado, então vejo você na nossa próxima aula.