Observabilidade na AWS – Parte III

Por Roberto Silva e Hamilton Oliveira, Arquitetos de Soluções da AWS Brasil

Introdução

Na parte II desta série sobre observabilidade exploramos o pilar de métrica, e nessa terceira e última parte abordaremos o pilar de rastreamento distribuído.

As funcionalidades de uma aplicação monolítica normalmente são expostas através de um único ponto de entrada, geralmente a porta 443(HTTPS). Em um cenário de microsserviços este comportamento é bem diferente, uma vez que uma mesma requisição pode implicar em chamadas de diversos microsserviços, cada um com o seu próprio ponto de entrada. Quando estes microsserviços estão distribuídos é muito mais complexo identificar a causa raiz em uma situação de latência, se comparado com uma aplicação monolítica.

O pilar que endereça este desafio no contexto de observabilidade é o rastreamento distribuído. Sua finalidade é permitir que identifiquemos o caminho percorrido por uma requisição até a resposta para o usuário, com visibilidade do tempo gasto em cada etapa. Neste blog post examinaremos como utilizar a plataforma da AWS para endereçar este desafio.

Pré-requisitos

Utilizaremos como exemplo a mesma aplicação da parte I e parte II.

O primeiro serviço que abordaremos é o AWS X-Ray que ajuda os desenvolvedores a analisar e depurar aplicações distribuídas, como no nosso cenário de microsserviços.

O AWS X-Ray nos permite entender o caminho percorrido por uma determinada requisição, bem como provê um mapa dos componentes da nossa aplicação.

Podemos utilizar o AWS X-Ray nos diferentes modelos de computação oferecidos pela AWS como o AWS Lambda, Amazon EKS, Amazon ECS, AWS Fargate e Amazon EC2.

Em uma aplicação baseada no Amazon EC2 o AWS X-Ray é executado como um daemon nas instâncias. Já quando executado em um ambiente de container, como o EKS, ECS ou o Fargate, este daemon é executado através de um container ou de um sidecar

Abaixo temos duas figuras que ilustram essas arquiteturas:

Outro componente importante nesta arquitetura é o SDK do AWS X-Ray, o qual é embarcado no código da nossa aplicação. O guia de implementação para cada linguagem suportada pode ser encontrado na documentação do AWS X-Ray.

Basicamente, uma vez que a aplicação esteja instrumentada, ela enviará os rastreamentos para o daemon/container/sidecar do AWS X-Ray que, por sua vez, enviará os rastreamentos para armazenamento no back-end do AWS X-Ray.

Como em nossa aplicação exemplo nossos microsserviços já foram devidamente instrumentados e os agentes já se encontram corretamente configurados, podemos focar na utilização do AWS X-Ray.

Mapa de serviços

Através do mapa de serviços podemos visualizar quais os componentes fazem parte da nossa aplicação e como eles interagem entre si.

Rastreamentos no AWS X-Ray

Para detalhar um componente específico no mapa de serviços basta clicar no mesmo e, a partir disso, o AWS X-Ray destaca quais componentes interagem com tal serviço, além do tempo gasto com cada interação.

Na figura abaixo observa-se que o serviço PetListAdoption interage com o PetSite, com um banco de dados e com o serviço PetSearch.

Outro ponto que podemos visualizar é a distribuição do tempo de resposta na ordem de 500 milissegundos para a maior parte das requisições e uma taxa de erro na ordem de 1%.

Através do botão Visualizar Rastreamento temos uma visão das URL(s) pelas quais o serviço PetListAdoption é acionado, o tempo de resposta e a quantidade de acionamentos.

Para correlacionar as requisições entre os diversos microsserviços basta selecionar um rastreamento específico através de seu ID na Lista de Rastreamento. Este ID tem um papel semelhante ao que vimos na parte referente a LOG.

Por meio do ID conseguimos identificar no AWS X-Ray quanto tempo levou cada etapa da requisição, e relacionar o tempo total desta requisição.

Escolhemos um dos rastreamentos que chegou através do nosso balanceador de carga, que no nosso exemplo demorou por volta de 2.2 segundos, para devolver uma resposta ao usuário.

Usando o ID do rastreamento foi possível identificar a requisição em sua totalidade, onde:

1º) O serviço PetSite recebeu a requisição do usuário e acionou o serviço PetListAdoption;

2º) O PetListAdoption consultou um banco de dados e acionou o serviço PetSearch;

3º) O serviço PetSearch utilizou uma tabela do Amazon DynamoDB e um bucket no Amazon S3.

O serviço PetListAdoption consulta informação dos pets em um banco de dados e depois aciona o serviço PetSearch múltiplas vezes, uma para cada um dos pets.

Analisando as requisições processadas pelo PetSearch podemos constatar que o maior tempo está relacionado com o acesso ao bucket, ou seja, através do PetSearch é possível identificar o ponto mais lento em toda cadeia de acionamento.

Visão Analítica do X-ray

O AWS X-Ray conta com uma visão analítica na qual é possível identificar problemas de performance rapidamente. Basicamente faremos uma consulta das requisições com tempo de resposta superior a 2.5 segundos do serviço PetSite.

Após aplicação do filtro é disponibilizada imediatamente a causa raiz da latência, sem a necessidade de analisar um rastreamento em específico.

Integrando logs, métricas e rastreamento.

O CloudWatch ServiceLens integra o Amazon com o AWS X-Ray com o objetivo de entregar uma visão fim-a-fim da aplicação, facilitando assim a análise em caso de um eventual problema e/ou a necessidade de depuração.

Através do botão Visualizar painel estão disponíveis diversas métricas como latência, solicitações e falhas.

Além das métricas citadas acima, há também uma seção de mapa de serviços/componentes, onde é possível visualizar como os mesmos interagem entre si.

Por fim, temos os logs gerados pelo serviço. No exemplo abaixo o mesmo se refere a função lambda que temos implementada em nossa aplicação.

Pesquisando rastreamento no Amazon CloudWatch ServiceLens

Além das métricas, logs e mapa dos serviços/componentes, o Amazon CloudWatch ServiceLens permite executar consultas de rastreamentos.

No exemplo abaixo faremos uma consulta de rastreamento aplicando um filtro com PetType, (igual a puppy). Este filtro foi implementado através do recurso de

No exemplo, ao aplicar o filtro no Amazon CloudWatch ServiceLens, pode-se ver que 1.000 rastreamentos atenderam ao critério, sendo que o tempo médio de reposta para estas requisições está na ordem de 560 milissegundos.

Com base no filtro definido no Amazon CloudWatch ServiceLens, é possível também visualizar a lista de rastreamentos e classificá-las conforme os critérios desejados.

Ao selecionar um dos rastreamentos listados o Amazon CloudWatch ServiceLens apresenta – em um só lugar – uma visão integrada e detalhada da requisição onde é possível visualizar o mapa do serviço/componentes.

A partir desta visão, também se tem acesso a um resumo do rastreamento que contém um histograma com a distribuição do tempo de resposta dos rastreamentos por segmento.

Nos detalhes do segmento estão apresentadas informações adicionais do segmento e permite identificar inclusive erros, quando aplicável.

Finalmente, na seção Logs é possível verificar dados pormenorizados por meio dos campos de log de sistema do Amazon CloudWatch que informa desde o identificador do grupo de logs até o log de evento em sua forma bruta, não interpretada.

Limpeza

Durante esta série foram provisionados diversos recursos em nossas contas. Para evitar que custos desnecessários sejam gerados, recomendamos seguir o passo a passo para removê-los.

Conclusão

Nesta série de blog posts abordamos desafios recorrentes, que nos deparamos em um ambiente de microsserviços em um contexto de observabilidade.

Demonstramos comos os pilares de log, métricas e rastreamento distribuído podem ser endereçados de forma prática na AWS, através de serviços como o Amazon CloudWatch, AWS X-Ray e o Amazon CloudWatch ServiceLens os quais a AWS é responsável pela disponibilidade e resiliência, liberando assim o tempo dos times para atividades mais estratégicas ao seu negócio.

Acesso ao workshop

https://observability.workshop.aws/

Sobre os Autores

Roberto Fernandes da Silva é arquiteto de soluções na AWS com mais de 14 anos no mercado de tecnologia. Atualmente seu foco esta no suporte a clientes do segmento enterprise em suas jornadas de nuvem bem como em ferramentas de gerenciamento.

Hamilton Oliveira é arquiteto de soluções na AWS com experiência de mais de 20 anos no desenvolvimento, suporte e arquitetura de soluções de gestão empresarial. Desde 2010, tem atuado junto às empresas do setor financeiro com a missão de ajudá-las a alcançar os benefícios resultantes da adoção de nuvem.

Agradecimento aos revisores:

Erik Miyashita e Thiago Paulino: Arquitetos de Solução da AWS.