Bom pessoal, como eu citei na aula anterior, nosso cluster ainda é muito simples, ele não é dinâmico. Então imagina que nós estamos ali criando um cluster de duas instâncias, somente com duas instâncias, e essas instâncias elas estão sendo utilizadas como um web server. O nosso cluster é um cluster de web server. Imagina agora que nós começamos a receber várias requisições. Então tem muita gente acessandoando o nosso site ao mesmo tempo e as nossas instâncias já não estão mais conseguindo atender a todos esses requests. O que vai acontecer é que alguns desses requests serão perdidos, agora passando um valor diferente de quantidade de instâncias. Mas é claro que isso não é uma solução legal, não é uma solução interessante. O que eu proponho aqui agora é nós refatorarmos o nosso projeto para utilizar o EC2 Auto Scaling. Como o próprio nome sugere, nós conseguimos criar ali um grupo de instâncias que elas são escaladas de forma automática pela AWS de acordo com as regras que nós definimos. Então nós temos um diagrama aqui que exemplifica isso. Nós temos um Auto Scaling Group. Então um Auto Scaling Group nada mais é do que uma coleção de instâncias que são gerenciadas ali juntas pela AWS. E nesse Auto Scaling Group nós definimos que nós queremos seis máquinas virtuais. Nós queremos um cluster com seis máquinas virtuais. Porém, nós definimos também que o valor mínimo de instâncias é 4 e o valor máximo de instâncias é 12. O que isso significa? Significa que de acordo com as regras que nós definimos para auto-scaling, com as nossas auto-scaling policies, este auto-scaling group pode diminuir para uma quantidade de 4 instâncias automaticamente, caso não haja muita demanda, caso não haja uma carga de trabalho tão intensa, porém, caso a carga de trabalho comece a aumentar de forma automática, nós podemos aqui aumentar a quantidade de instâncias até o valor de 12, tá? Porém, nunca mais do que 12 e nós nunca podemos diminuir também para menos do que 4, beleza? O exemplo que eu citei aqui foi em relação à carga de trabalho, mas existem outras formas também de definir auto-scaling, como por exemplo o scheduled, o auto-scaling agendado. Então, em um determinado horário que nós sabemos que nós teremos um pico de utilização, nós podemos aumentar a quantidade de instâncias do nosso cluster para 12, por exemplo, porque nós sabemos que 12 instâncias são capazes de atender aquela quantidade de demanda naquele horário específico. E depois que passou aquele horário de pico, nós podemos diminuir o número de instâncias dentro do cluster. Então, existem várias formas de nós criarmos policies para atender a nossa demanda e deixar o nosso cluster muito mais eficiente. Dessa forma, nós economizamos e nós estamos sempre também atendendo as nossas requisições. Beleza? Então, a ideia agora é nós transformarmos o nosso módulo em um módulo que crie um auto-scaling group e que nos permita passar ali regras de auto-scaling ou auto-scaling policies. Portanto, eu modifiquei aqui o nosso diagrama, nós tínhamos essa solução bem simples, onde nós tínhamos um Elastic IP que apontava para a nossa instância, e agora nós teremos, ao invés de uma instância, nós teremos um cluster, nós teremos várias instâncias, que aqui está sendo representado por um auto-scaling group, e agora para nós fazermos o roteamento das requisições, nós vamos utilizar um application mode balancer. Então, algo que um auto-scaling group resolve para nós também é essa questão de roteamento. Agora que nós temos várias instâncias, não faz sentido nós termos somente um Elastic IP e atribuirmos a uma instância específica. Agora nós estamos trabalhando com várias instâncias que num determinado momento podem ser quatro instâncias dentro de um cluster e em outro momento pode ser seis. Então como nós gerenciamos os IPs desse cluster? Agora já não faz mais sentido nós gerenciarmos esses recursos, esses Elastic IPs de forma manual e depois criarmos ali um load balancer utilizando esses IPs. Não, nós podemos utilizar ou criar um grupo e podemos fazer com que um application load balancer faça a distribuição do tráfego da web para esse cluster específico. da web para esse cluster específico. Está utilizando, por exemplo, um algoritmo de round robin, onde cada uma das instâncias receberão um request intercalado. Dessa forma, nós garantimos que todas essas instâncias vão trabalhar ali mais ou menos com a mesma quantidade de recursos ou de requisições sendo atendidas simultaneamente. Beleza? Então, essa daqui é a nossa nova proposta. Nós vamos atualizar o nosso projeto Terraform para agora refletir esse diagrama, essa solução. Espero que você esteja animado. Vejo você na nossa próxima aula.