Monitore aplicativos baseados no Amazon SNS de ponta a ponta com o rastreamento ativo do AWS X-Ray

Este post foi escrito por Daniel Lorch, consultor sênior e David Mbonu, arquiteto sênior de soluções, e adaptado para Português por Daniel ABIB, arquiteto sênior de soluções para Entreprise.

O Amazon Simple Notification Service (Amazon SNS), que é um serviço de mensagens que fornece mensagens de alta performance, baseadas em push, entre sistemas distribuídos, microsserviços e aplicativos Serverless orientados por eventos, agora oferece suporte ao rastreamento ativo com o AWS X-Ray.

Com o rastreamento ativo do AWS X-Ray habilitado para SNS, você pode identificar gargalos e monitorar a integridade dos aplicativos orientados por eventos analisando os detalhes do segmento de tópicos do SNS, como metadados de recursos, falhas, erros e latência de entrega de mensagens para cada assinante.

Esta blog post analisa casos de uso comuns em que o rastreamento ativo do AWS X-Ray habilitado para SNS fornece uma visão consistente dos dados de rastreamento nos serviços da AWS em cenários do mundo real. Abordamos dois padrões de arquitetura que permitem que você obtenha visibilidade precisa do seu rastreamento de ponta a ponta: filas do SNS para o Amazon Simple Queue Service (Amazon SQS) e tópicos do SNS para streams do Amazon Kinesis Data Firehose.

Introdução ao exemplo de aplicativo Serverless

Para demonstrar o rastreamento ativo do AWS X-Ray para SNS, usaremos o aplicativo Serverless Wild Rydes, conforme mostrado na figura a seguir. O aplicativo usa uma arquitetura de microsserviços que implementa mensagens assíncronas para integrar sistemas independentes.

É assim que este exemplo de aplicativo Serverless funciona:

1. Um Amazon API Gateway recebe solicitações de viagem dos usuários.
2. Uma função do AWS Lambda processa solicitações de viagem.
3. Uma tabela do Amazon DynamoDB serve como um local de armazenamento para viagens.
4. Um tópico do SNS serve como uma forma de distribuição para solicitações de viagem.
5. As filas individuais do SQS e as funções do Lambda são configuradas para processar solicitações por meio de vários serviços de back-office (notificação ao cliente, contabilidade do cliente e outros).
6. Existe um filtro de mensagens SNS para a assinatura do serviço de viagens extraordinárias.
7. Um stream de entrega do Kinesis Data Firehose arquiva solicitações de viagem em um bucket do Amazon Simple Storage Service (Amazon S3).

Implantação do aplicativo Serverless de amostra

Pré-requisitos

• Interface de linha de comando da AWS (AWS CLI)
• CLI do modelo de aplicativo Serverless da AWS (AWS SAM)
• Git

Etapas de implantação usando o AWS SAM

O aplicativo de exemplo é fornecido utilizando uma infraestrutura como modelo de código através do AWS SAM

Esse exemplo implantará uma API sem autorização. Considere controlar e gerenciar o acesso às suas APIs.

1. Clone o repositório do GitHub:
   
2. Crie os artefatos:
   
3. Implante a solução de exemplo em sua conta da AWS:
   
   Confirme se submitrideCompletionFunction pode não ter autorização definida. Tudo bem? [Y/n]: com sim (YES).
4. Espere até que a pilha esteja com o status de CREATE_COMPLETE.

Consulte a documentação do exemplo no arquivo README.md para obter instruções detalhadas de implantação.

Testando o aplicativo

Depois que o aplicativo for implantado com sucesso, gere mensagens e valide se o tópico do SNS está publicando todas as mensagens:

1. Consulte o endpoint do API Gateway:
   
2. Armazene esse endpoint do API Gateway em uma variável de ambiente:
   
3. Envie solicitações para o endpoint executando o seguinte comando cinco ou mais vezes com cargas variáveis:

   curl -XPOST -i -H "Content-Type\:application/json" -d '{ "from": "Berlin", "to": "Frankfurt", "duration": 420, "distance": 600, "customer": "cmr", "fare": 256.50 }' $ENDPOINT

4. Valide se as mensagens estão sendo passadas no aplicativo usando o mapa do serviço CloudWatch:
   

Consulte arquivo README.md para obter instruções detalhadas de teste.

O aplicativo de teste mostra vários casos de uso, descritos nas seções a seguir.

Cenário de distribuição de Amazon SNS para Amazon SQS

Um cenário comum de integração de aplicativos para SNS é o cenário Fanout. No cenário Fanout, uma mensagem publicada em um tópico do SNS é replicada e enviada para vários endpoints, como filas SQS. Isso permite o processamento assíncrono paralelo e é um padrão comum de integração de aplicativos usado em arquiteturas de aplicativos orientadas por eventos.

Quando um tópico do SNS se espalha para as filas do SQS, o padrão é chamado de encadeamento de filas de tópicos. Isso significa que você adiciona uma fila, no nosso caso uma fila SQS, entre o tópico do SNS e cada um dos serviços do assinante. Como as mensagens são armazenadas em buffer de forma persistente em uma fila do SQS, nenhuma mensagem é perdida se o processo do assinante apresentar problemas por várias horas ou dias ou sofrer exceções ou falhas.

Ao colocar uma fila SQS na frente de cada serviço de assinante, você pode aproveitar o fato de que uma fila pode atuar como um balanceador de carga de buffer. Como cada mensagem da fila é entregue a um dos potencialmente muitos processos do consumidor, os serviços do assinante podem ser facilmente expandidos e ampliados, e a carga de mensagens é distribuída pelos processos de consumo disponíveis. Em um evento em que, repentinamente, um grande número de mensagens chega, o número de processos do consumidor deve ser ampliado para lidar com a carga adicional. Isso leva tempo e você precisa esperar até que processos adicionais se tornem operacionais. Como as mensagens são armazenadas em buffer na fila, você não perde nenhuma mensagem no processo.

Para resumir, no cenário Fanout ou no padrão de encadeamento de filas de tópicos:

• O SNS replica e envia a mensagem para vários endpoints.
• O SQS separa os terminais de envio e recebimento.

Com o rastreamento ativo do AWS X-Ray ativado no tópico SNS, o mapa de serviços do CloudWatch nos mostra a arquitetura completa do aplicativo, da seguinte forma.

Antes da introdução do rastreamento ativo do AWS X-Ray no tópico SNS, o serviço AWS X-Ray não conseguia reconstruir o mapa completo do serviço e os nós do SQS estariam ausentes no diagrama

Para ver a integração sem o rastreamento ativo do AWS X-Ray ativado, abra template.yaml e navegue até o recurso RideCompletionTopic. Comente a propriedade TracingConfig: Ative, reimplante e teste a solução. O mapa do serviço deve então mostrar um diagrama incompleto em que o tópico SNS está vinculado diretamente às funções do Lambda do consumidor, omitindo os nós do SQS.

Para esse caso de uso, considerando o cenário Fanout, ao habilitar o rastreamento ativo do AWS X-Ray no tópico SNS fornece uma observabilidade completa dos rastreamentos disponíveis no aplicativo.

Streams de entrega do Amazon SNS para o Amazon Kinesis Data Firehose para arquivamento e análise de mensagens

O SNS é comumente usado com fluxos de entrega do Kinesis Data Firehose para casos de uso de arquivamento e análise de mensagens. Você pode usar tópicos do SNS com assinaturas do Kinesis Data Firehose para capturar, transformar, armazenar em buffer, compactar e carregar dados para o Amazon S3, Amazon Redshift, Amazon OpenSearch Service, endpoints HTTP e provedores de serviços terceirizados.

Implementaremos esse padrão da seguinte forma:

• Um tópico do SNS para replicar e enviar a mensagem para seus assinantes.
• Um stream de entrega do Kinesis Data Firehose para capturar e armazenar mensagens em buffer.
• Um bucket do S3 para receber mensagens enviadas para arquivamento.

Para demonstrar esse padrão, um consumidor adicional foi adicionado ao tópico do SNS. O mesmo padrão Fanout se aplica e o stream de entrega do Kinesis Data Firehose recebe mensagens do tópico do SNS junto com os consumidores existentes.

O stream de entrega do Kinesis Data Firehose armazena mensagens em buffer e está configurado para entregá-las a um bucket do S3 para fins de arquivamento. Opcionalmente, um filtro de mensagens SNS pode ser adicionado a essa assinatura para selecionar mensagens relevantes para arquivamento.

Com o rastreamento ativo do AWS X-Ray ativado no tópico SNS, o nó do Kinesis Data Firehose aparecerá no mapa do serviço CloudWatch como uma entidade separada, como pode ser visto na figura a seguir. É importante observar que o bucket do S3 não aparece no mapa do serviço CloudWatch, pois o Kinesis ainda não oferece suporte ao rastreamento ativo do AWS X-Ray no momento em que este post foi escrito no blog.

Antes da introdução do rastreamento ativo do AWS X-Ray no tópico SNS, o serviço AWS X-Ray não conseguia reconstruir o mapa de serviço completo e o nó Kinesis Data Firehose estaria ausente do diagrama. Para ver a integração sem o rastreamento ativo do AWS X-Ray ativado, abra template.yaml e navegue até o recurso RideCompletionTopic. Comente a propriedade TracingConfig: Ative, reimplante e teste a solução. O mapa do serviço deve então mostrar um diagrama incompleto em que o nó Kinesis Data Firehose está ausente.

Para esse caso de uso, considerando o cenário de arquivamento de dados com o Kinesis Delivery Firehose, habilitar o rastreamento ativo do AWS X-Ray no tópico SNS fornece visibilidade adicional no nó Kinesis Data Firehose no mapa do serviço CloudWatch.

Analise falhas, erros e latência de entrega de mensagens na página de detalhes do rastreamento do AWS X-Ray

A página de detalhes do rastreamento do AWS X-Ray fornece um cronograma com metadados de recursos, falhas, erros e latência de entrega de mensagens para cada segmento

Com o rastreamento ativo do AWS X-Ray ativado no SNS, segmentos adicionais para o tópico do SNS em si, mas também para os segmentos de consumidores posteriores (AWS: :SNS: :Topic, AWS: :SQS: :Queue e AWS: :KinesisFirehose) estão disponíveis, fornecendo falhas adicionais, erros e latência de entrega de mensagens para esses segmentos. Isso permite que você analise as latências em suas mensagens e em seus serviços de back-end. Por exemplo, quanto tempo uma mensagem fica em um tópico e quanto tempo levou para entregar a mensagem a cada uma das assinaturas do tópico.

Habilitando o rastreamento ativo do AWS X-Ray para SNS

O rastreamento ativo do AWS X-Ray não está habilitado por padrão nos tópicos do SNS e precisa ser ativado explicitamente.

O aplicativo de exemplo usado nesta postagem do blog demonstra como habilitar o rastreamento ativo usando o AWS SAM.

Você pode habilitar o rastreamento ativo do AWS X-Ray usando a API SNS SetTopicAttributes, o SNS Management Console ou via AWS CloudFormation. Consulte Rastreamento ativo no Amazon SNS no Guia do desenvolvedor do Amazon SNS para obter mais opções.

Limpeza

Para limpar os recursos fornecidos como parte deste exemplo Serverless, siga as instruções descritas no arquivo README.md.

Conclusão

O rastreamento ativo do AWS X-Ray para SNS permite visibilidade de ponta a ponta em cenários do mundo real envolvendo padrões como SNS para SQS e SNS para Amazon Kinesis.

Mas não é útil apenas para esses padrões. Com o rastreamento ativo do AWS X-Ray habilitado para SNS, você pode identificar gargalos e monitorar a integridade dos aplicativos orientados por eventos analisando os detalhes do segmento de tópicos e consumidores do SNS, como metadados de recursos, falhas, erros e latência de entrega de mensagens para cada assinante.

Habilite o rastreamento ativo do AWS X-Ray para SNS para obter visibilidade precisa do seu rastreamento de ponta a ponta.

Para obter mais recursos de aprendizado Serverless, visite Serverless Land.

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre os autores

Daniel Lorch

David Mbonu

Tradutor

Daniel Abib é Enterprise Solution Architect na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/