Olá a todos, e bem-vindos de volta.
Agora, no vídeo de hoje, vamos discutir sobre a arquitetura da escala baseada nas SKUs da Amazônia em
um panorama de alto nível.
Agora, em muitas das organizações, o número de duas instâncias da CE que estariam funcionando no ambiente
de produção se correlaciona diretamente com o número de mensagens que fazem parte do resgate.
Por exemplo, digamos que há dez mensagens na fila dos EUA, e como há duas CE duas instâncias que
estão executando cada CE duas instâncias cuidarão e processarão cinco mensagens e, após o processamento,
carregarão os artefatos para o balde S3.
Agora vamos dizer que amanhã há uma grande venda que está acontecendo e nos EUA, em vez de dez mensagens,
há 10.000 mensagens.
Agora, como há um grande número de mensagens na fila, há duas opções.
A primeira é manter apenas duas mensagens fáceis de serem processadas e o processamento de 10.000 mensagens levará muito
tempo.
Portanto, essa é a primeira opção.
A segunda opção é aumentar o número de duas instâncias da CE que estão funcionando no ambiente de
produção, digamos, de 2 para 20.
Assim, agora 20 são duas instâncias em execução, 10.000 mensagens serão processadas de forma muito mais rápida.
No entanto, o aumento do número de duas instâncias da CE também aumentará o custo.
Agora, após a conclusão da venda, o número de mensagens na fila foi reduzido de 10.000 de volta para
dez.
Portanto, agora o que você tem que fazer, você tem que terminar a CE extra.
Duas instâncias que estamos executando para reduzir o custo total.
Agora em ambiente de produção, você quer implementar tal tipo de arquitetura onde a CE duas instâncias
são lançadas e terminadas com base no número de mensagens na fila.
E, de fato, em muitas organizações você verá esse tipo de arquitetura sendo implementada.
Assim, numa visão geral de alto nível, vamos rapidamente analisar quais são as coisas que precisam ser feitas para
se conseguir este tipo de arquitetura.
Agora, se você estiver fazendo uso de um grupo de escalonamento automático, então em tais casos você pode configurá-lo para lançar
ou encerrar as duas instâncias fáceis com base no número de mensagens que fazem parte do resgate.
Agora, isto pode ser explicado com este diagrama onde você tem uma aplicação que está lendo o número de mensagens
que fazem parte da fila e que está armazenando os dados em um relógio de nuvens.
Agora, dependendo dos dados no relógio de nuvens, a escala automática ou lança um novo conjunto de instâncias ou encerra
o conjunto adicional de instâncias que estamos executando.
Agora a questão que se coloca é como esta aplicação específica sabe quantas mensagens há em salvamento?
E a resposta a isto é uma das seis colunas de atributos, número aproximado de mensagens.
Por isso, vamos em frente e rapidamente analisar o assunto.
Agora, para a demonstração de hoje, tenho um resgate e há duas mensagens que estão disponíveis.
Assim, se abrirmos o resgate, obtemos o URL da fila.
E com base nesta URL, você pode ir em frente e verificar quantas mensagens estão presentes.
Por isso, vamos em frente e rapidamente analisar o assunto.
Portanto, tenho um comando CLI que nos chama oito nós recebemos atributos, especificamos aqui a URL da fila e especificamos
aqui o nome do atributo e o nome do atributo é o número aproximado de mensagens.
Isto é muito semelhante ao que estávamos discutindo e a região é a AP Southeast.
Agora, se eu pressionar rapidamente enter aqui, você verá que o número de mensagens que está mostrando são duas e isto é
a mesma coisa que o aplicativo pode fazer e pode publicá-lo em um serviço central a partir do qual o autoescalonamento
lançará e encerrará as instâncias conforme necessário.
Portanto, este é um dos projetos de arquitetura que pode ser implementado caso você tenha um caso de uso em que queira
lançar e encerrar instâncias com base no número de mensagens.
Assim, com isto, o vídeo de hoje será concluído.