Introdução

Em meu artigo Amazon DevOps Guru para aplicativos Serverless - Parte 10 Detecção de anomalias no Aurora Serverless v2, aprendemos que o DevOps Guru foi capaz de detectar anomalias com êxito com o banco de dados Aurora (Serverless v2) PostgreSQL no caso de função Lambda com Java 21 gerenciado o tempo de execução foi conectado a ele via JDBC. Escalamos nosso banco de dados apenas de 0,5 para 1 ACU e criamos uma carga muito alta no banco de dados invocando a função Lambda para recuperar o produto por ID várias centenas de vezes simultaneamente por vários minutos. Vimos que o DevOps Guru apontou corretamente para o aumento da soma de conexões de banco de dados e para a carga constantemente alta do banco de dados (CPU). Neste artigo, gostaria de descobrir se o DevOps Guru detectará a anomalia fazendo o mesmo experimento, mas usando a API de dados para Aurora Serverless v2 com AWS SDK para Java em vez de JDBC.

Detecção de anomalias no Aurora Serverless v2 com API de dados

Vamos dar uma olhada em nosso aplicativo de exemplo e usar o modelo SAM para criar infraestrutura e implantar o aplicativo descrito na imagem a seguir:

O aplicativo cria produtos armazenados no banco de dados Aurora Serverless v2 PostgreSQL e os recupera por ID usando a API de dados. A função Lambda relevante que usaremos para recuperar o produto por seu ID é GetProductByIdViaAuroraServerlessV2DataApi e sua implementação de manipulador é GetProductByIdViaAuroraServerlessV2DataApiHandler.

Como no artigo anterior, usamos a ferramenta hey para realizar o teste de estresse como este

hey -z 15m -c 300 -H "X-API-Key: XXXa6XXXX" https://XXX.execute-api.eu-central-1.amazonaws.com/prod/productsWithDataApi/1   

Neste exemplo, invocamos o endpoint do API Gateway com 300 contêineres simultâneos por 15 minutos. Por trás do endpoint prod/productsWithoutDataApi, a função Lambda GetProductByIdViaAuroraServerlessV2WithoutDataApi será invocada, recuperando o produto pelo id 1 do banco de dados Aurora Serverless v2 PostgreSQL.

Configuramos em nosso [modelo SAM]((https://github.com/Vadym79/AWSLambdaJavaAuroraServerlessV2DataApi/blob/master/template.yaml) cluster de banco de dados Aurora para escalar da capacidade mínima de 0,5 para a capacidade máxima de 1 ACU (que é tamanho de banco de dados muito pequeno) no caso de aumento de carga para fins de redução de custos.

AuroraServerlessV2Cluster: Digite: 'AWS::RDS::DBCluster' ... Configuração de escalonamento V2 sem servidor: Capacidade mínima: 0,5 Capacidade máxima: 1

  AuroraServerlessV2Cluster:
    Type: 'AWS::RDS::DBCluster'
...
      ServerlessV2ScalingConfiguration:
        MinCapacity: 0.5
        MaxCapacity: 1

O banco de dados Aurora (Serverless v2) gerencia o número máximo de conexões de banco de dados disponíveis proporcionalmente ao tamanho do banco de dados (em nosso caso, a configuração ACU) também com Data API para Aurora Serverless v2 (que é uma grande diferença para v1, que se tornará sem suporte no final do ano de 2024, onde havia uma cota rígida de 1.000 conexões de banco de dados por segundo). Para obter mais informações, leia a documentação sobre Conexões máximas para Aurora Serverless v2. Portanto, com o aumento do número de invocações, esperamos atingir em breve o número máximo de conexões de banco de dados disponíveis e alta carga de banco de dados (CPU), para que o banco de dados não seja capaz de responder às novas solicitações de função do Lambda para recuperar o produto por id (o Lambda também será executado). Com isso iremos provocar a anomalia e gostaríamos de saber se o DevOps Guru será capaz de detectá-la. E foi capaz, mais ou menos... O seguinte insight foi gerado:

E as seguintes métricas anômalas agregadas foram identificadas:

Comparando com as métricas anômalas agregadas identificadas no caso de uso de JDBC em vez da API de dados descritas em meu artigo Amazon DevOps Guru para aplicativos Serverless - Parte 10 Detecção de anomalias no Aurora Serverless v2, desconsideramos completamente as métricas anômalas do banco de dados Aurora: conexão com o banco de dados soma e carregamento do banco de dados (CPU), mas vê corretamente o erro no Lambda que atingiu o tempo definido de 15 segundos porque o banco de dados não pôde responder.

.

Então, qual é a diferença? Vamos explorar os dois incidentes que reproduzimos no cluster Aurora Serverless v2 PostgreSQL com JDBC (Non Data API) e Data API:

Em termos de utilização/escala da ACU, ambos parecem iguais:

Em termos de outras métricas de banco de dados como: Utilização de CPU, DatabaseConnection DBLoad(CPU), existem grandes diferenças:

A utilização da CPU parece a mesma para casos de JDBC (API não de dados) e API de dados. Mas o DevOps Guru parece não considerar essa métrica, pois não a vimos nem mesmo para o experimento JDBC
DBLoad(CPU) que é muito baixo para uso da API de dados. Parece que para a API Dat existe algum Load Balancer na frente do banco de dados Aurora Serverless v2 que monitora o uso da conexão e protege o banco de dados contra sobrecarga.
• A métrica DatabaseConnection não é mostrada (ou mostrada como 0) para uso da API de dados. A razão para isso é que não gerenciamos a conexão do banco de dados para a API de dados, isso é feito do outro lado para nós. É claro que eles ainda desempenham um papel importante que aprendemos em Conexões máximas para Aurora Serverless v2, mas essa métrica parece estar exposta externamente nas métricas do CloudWatch e mesmo o DevOps Guru não tem acesso aos números reais.
Com isso e DBLoad(CPU) muito baixo, nenhum insight do DevOps Guru para o cluster Aurora Serverless v2 com uso de API de dados foi gerado em comparação com o caso de uso JDBC.

Fiz o segundo experimento conectando-me diretamente ao cluster Aurora Serverless v2 e escrevi o script para criar o teste de carga escrevendo o script que busca o produto por ID várias centenas de vezes usando a maneira padrão (API sem dados). Semelhante ao que fizemos com a ferramenta hey, mas acessando o banco de dados diretamente em vez de invocar o Api Gateway. Depois de colocar o banco de dados sob carga, iniciei o mesmo experimento com a ferramenta hey conforme descrito acima e queria ver o que aconteceria. O mesmo insight foi gerado, mas desta vez com as seguintes métricas anômalas:

Agora vemos pelo menos uma métrica anômala de soma de conexão de banco de dados Aurora Serverless v2 adicional, mas as métricas DBLoad (CPU) ainda estão faltando.

As anomalias gráficas têm esta aparência:

É claro que o experimento não foi limpo, pois fiz 2 testes de carga um após o outro e parcialmente em paralelo: o primeiro conectando-se ao banco de dados diretamente sem uso do API Gateway e o segundo usando Data API. Isso confirmou minha suposição inicial de que as métricas de soma de conexão do banco de dados são um critério muito importante para gerar insights do DevOps Guru para Aurora Serverless v2 (e para RDS em geral) e não são expostas em geral no caso de uso da API de dados.

Já entrei em contato com a equipe Devops Guru e compartilhei com eles meus insights com a expectativa de que irão melhorar o serviço. Ou, antes de mais nada, a exposição da conexão do banco de dados como uma métrica do CloudWatch será corrigida para o uso do Aurora Serverless v2 com API de dados.

Conclusão

Neste artigo aprendi que o DevOps Guru pode detectar anomalias com sucesso com o banco de dados PostgreSQL Aurora (Serverless v2) no caso da função Lambda com tempo de execução gerenciado Java 21 conectado a ele via API de dados, mas só pode mostrar as métricas anômalas relacionadas à função Lambda sendo excedido porque o banco de dados não respondeu. A principal razão para isso parece ser que a conexão com o banco de dados como uma métrica do CloudWatch não é exposta (ou sempre exibida como 0) no caso de uso do Aurora Serverless v2 com API de dados. As métricas do banco de dados Aurora Serverless v2 (soma de conexões do banco de dados) só foram mostradas durante o segundo experimento artificial.