5. Quebrando nosso Sistema em
Componentes
● Se encaixa bem em sistemas que tenham componentes
no estilo produtor-consumidor.
– Pode ser um ou vários componentes produtores, e um
ou vários componentes consumidores.
6. Evite a Sobrecarga
● Eventualmente, seu serviço ficará sobrecarregado.
– Podemos tratar a sobrecarga sem escalar nossos
servidores, caso seja pertinente.
7. Evite Sobrecarga com Filas SQS
● Modifique seu produtor para enviar mensagens para as
filas SQS;
● Evite falhas: processe apenas o que conseguir naquele
momento; posteriormente, em momentos de baixa
demanda, processe o restante das mensagens.
9. Use Filas SQS
● As filas SQS armazenam suas mensagens de maneira duradoura até que você
as processe. Quando as mensagens são lidas elas não são automaticamente
removidas, mas são configuradas como invisível, para que nenhum outro
componente a processe repetidamente.
– A invisibilidade é definida por um visibility timeout que por padrão tem valor
30 segundos.
● Uma vez processadas as mensagens, você deve removê-la explicitamente da
fila SQS. Caso contrário, a mensagem tornar-se-á disponível novamente na fila
para que outros componentes a processem.
11. SQS dá Suporte a Alta Vazão de
Mensagens
● É possível ter vários “produtores” escrevendo na fila em um mesmo momento.
O SQS irá fazer de tudo para manter a ordem delas, mas a natureza distribuída
torna impossível garanti-la 100%.
– Se for extremamente necessário, adicione um identificador à sua
mensagem.
– A ordem aproximada é suficiente na maioria dos casos.
● É possível ter vários “consumidores”. A leitura de uma mensagem pelos
consumidores é atômica.
– Estratégias de para evitar dead lock são utilizadas pela SQS para prevenir
múltiplos consumidores de ler uma mesma mensagem.
12. SQS como um Buffer
● E se o serviço “cair” temporariamente, ou tiver de ser
reiniciado?
– Não tem problema. A fila pode absorver essas
mensagens, funcionando como um Buffer.
13. SQS como um Buffer
● Quanto o sistema voltar a seu funcionamento pleno, as
processará rapidamente.
14. SQS – Principais Características
● Provê alta durabilidade;
● Mantém as mensagens até as
deletarmos explicitamente;
● Se não consumidas as
mensagens são armazenadas por
4 dias (padrão), mas podem ser
armazenadas por até 14 dias;
● É possível utilizar alertas do
Amazon CloudWatch para
monitorar quantidade de
mensagens, taxa de mensagens
em um dado tempo, etc.
15. SQS - Preço Geral
● 100.000 mensagens de graça
por mês para todos;
● $1,00 a cada 1.000.000 de
requisições;
17. Introdução ao SNS
● Se encaixa bem em sistemas que tenham componentes
no estilo produtor-consumidor.
– A ideia é que um produtor envie mensagens idênticas
a vários serviços.
18. Evite a Sobrecarga
● Eventualmente, o produtor que produzir conteúdo
popular para vários serviços ficará sobrecarregado
quando precisar entregar essas mensagens a eles.
19. Evite a Sobrecarga com Tópicos
SNS
● Tópicos SNS desacoplam os produtores dos serviços que
consomem suas mensagens.
● Tópicos SNS permitem você enviar mensagens idênticas a vários
serviços em paralelo.
– Produtores publicam as mensagens nos tópicos SNS uma única
vez, e o SNS é encarregado de distribuir uma cópia idêntica
desta mensagem para os serviços inscritos naquele tópico.
20. Transparência na Entrega das
Mensagens
● Podemos entregar as mensagens por diferentes
protocolos, não precisamos no preocupar em como elas
serão entregues.
21. SNS – Principais Características
● Quantidade de inscritos ilimitadas: envie
mensagens para quantos subscribers
desejar;
● Suporte transparente a vários
protocolos: Amazon SQS, HTTP, e-mail,
SMS;
● Políticas de envio customizáveis
segundo sua aplicação (tentativas, taxa
de mensagens em dado tempo);
● É possível utilizar alertas do Amazon
CloudWatch para monitorar quantidade
de mensagens, taxa de mensagens em
um dado tempo, etc.
22. SNS - Preço Geral
● Preço para adicionar mensagens ao
Tópicos SNS:
– 100.000 mensagens de graça por mês
para todos;
– $0,60 a cada 1.000.000 de mensagens
adicionadas ao SNS;
● Preço de entrega das mensagens aos
inscritos no Tópico SNS:
25. Exemplo II - SQS
● Processamento de PDFs com prioridade (Marvia)
– Arquitetura Inicial
26. Exemplo II - SQS
● Processamento de PDFs com prioridade (Marvia)
– Arquitetura Final com SQS: QoS - Quality of Service
27. Exemplo II - SNS
● Monitoramento do status do processamento do PDF (Marvia)
● Uma das partes básicas que está faltando no Marvia é a
notificação ao cliente de quando o seu PDF estará pronto.
Vamos olhar novamente o gráfico do slide anterior. É possível
perceber que todo o ciclo, desde o pedido do cliente para a
criação do PDF, passando pelas SQS até o processamento do
mesmo pelas instâncias ocorre bem. Mas não existe um meio do
cliente saber o momento exato de que seu PDF está pronto. Um
meio seria criar tópicos SNS para cada clientes, e assim que o
PDF estiver pronto, enviamos uma notificação para o mesmo via
e-mail ou outro protocolo.
28. Exemplo III – SNS + SQS
●
Padrão de arquitetura “fanout”
●
Ao usar este padrão podemos
construir sistemas que tirem
vantagem de processamento
paralelo assíncrono.
● Por exemplo, seria possível
publicar uma mensagem a um
tópico SNS cada vez que
tivermos um novo upload de
imagem. Processos
independentes receberão de
maneira automática essa
mensagem e executarão suas
atividades de forma paralela.