Introdução a Sistemas Distribuídos
HandsON ­ Exemplo de utilização 
de SQS e SNS
Eduardo de Lucena Falcão
Queues are Everywhere
Notifications are Everywhere
Componentes AWS para Troca de
Mensagens
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.
Evite a Sobrecarga
● Eventualmente, seu serviço ficará sobrecarregado.
– Podemos tratar a sobrecarga sem escalar nossos
servidores, caso seja pertinente.
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.
Use Filas SQS
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.
SQS dá Suporte a Alta Vazão de
Mensagens
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.
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.
SQS como um Buffer
● Quanto o sistema voltar a seu funcionamento pleno, as
processará rapidamente.
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.
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;
Componentes AWS para Troca de
Mensagens
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.
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.
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.
Transparência na Entrega das
Mensagens
● Podemos entregar as mensagens por diferentes
protocolos, não precisamos no preocupar em como elas
serão entregues.
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.
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:
Comparação
Exemplo I - SQS
● Processamento de imagens
Exemplo II - SQS
● Processamento de PDFs com prioridade (Marvia)
– Arquitetura Inicial
Exemplo II - SQS
● Processamento de PDFs com prioridade (Marvia)
– Arquitetura Final com SQS: QoS - Quality of Service
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.
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.
Exemplo Prático
25/05/2013 30
Referências
● Amazon Web Services. http://aws.amazon.com/pt/
(Acesso: abril/2013).
● Baseado em “AWS Messaging: Amazon SQS and SNS”.
Acessado em 06/2013. Url:
http://java.dzone.com/articles/aws-messaging-amazon-s
qs-and
● Vliet, J., and Paganelli, F.; Programming Amazon EC2.
O'Reilly.
25/05/2013 31
Dúvidas
https://sites.google.com/site/introsistemasdistribuidos/
Eduardo de Lucena Falcão
eduardolfalcao@gmail.com
@dudufalcao

Aula 8 - Comunicação entre Componentes com SQS e SNS

  • 1.
    Introdução a SistemasDistribuídos HandsON ­ Exemplo de utilização  de SQS e SNS Eduardo de Lucena Falcão
  • 2.
  • 3.
  • 4.
    Componentes AWS paraTroca de Mensagens
  • 5.
    Quebrando nosso Sistemaem 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 comFilas 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.
  • 8.
  • 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.
  • 10.
    SQS dá Suportea Alta Vazão de Mensagens
  • 11.
    SQS dá Suportea 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 umBuffer ● 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 umBuffer ● Quanto o sistema voltar a seu funcionamento pleno, as processará rapidamente.
  • 14.
    SQS – PrincipaisCaracterí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çoGeral ● 100.000 mensagens de graça por mês para todos; ● $1,00 a cada 1.000.000 de requisições;
  • 16.
    Componentes AWS paraTroca de Mensagens
  • 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 Sobrecargacom 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 Entregadas Mensagens ● Podemos entregar as mensagens por diferentes protocolos, não precisamos no preocupar em como elas serão entregues.
  • 21.
    SNS – PrincipaisCaracterí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çoGeral ● 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:
  • 23.
  • 24.
    Exemplo I -SQS ● Processamento de imagens
  • 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.
  • 29.
  • 30.
    25/05/2013 30 Referências ● AmazonWeb Services. http://aws.amazon.com/pt/ (Acesso: abril/2013). ● Baseado em “AWS Messaging: Amazon SQS and SNS”. Acessado em 06/2013. Url: http://java.dzone.com/articles/aws-messaging-amazon-s qs-and ● Vliet, J., and Paganelli, F.; Programming Amazon EC2. O'Reilly.
  • 31.