Planejar onde usar o RDS Proxy

Você pode determinar quais de suas instâncias de banco de dados, clusters e aplicações podem se beneficiar mais com o uso do RDS Proxy. Para fazer isso, considere estes fatores:

• Qualquer instância de banco de dados que encontrar erros de “conexões em excesso” é uma boa candidata para associação a um proxy. Isso geralmente é caracterizado por um alto valor da métrica ConnectionAttempts do CloudWatch. O proxy permite que as aplicações abram muitas conexões de cliente enquanto gerencia um número menor de conexões de longa duração para a instância de banco de dados.

• Para instâncias de bancos de dados que usam classes de instância menores da AWS, como T2 ou T3, o uso de um proxy pode ajudar a evitar condições de falta de memória. Isso também pode ajudar a reduzir a sobrecarga da CPU para estabelecer conexões. Essas condições podem ocorrer ao lidar com um grande número de conexões.

• É possível monitorar certas métricas do Amazon CloudWatch para determinar se uma instância de banco de dados está se aproximando de certos tipos de limite. Esses limites são para o número de conexões e para a memória associada ao gerenciamento de conexão. Você também pode monitorar certas métricas do CloudWatch para determinar se uma instância de banco de dados está lidando com muitas conexões de curta duração. A abertura e o fechamento dessas conexões podem aplicar um sobrecarga de performance a seu banco de dados. Para obter informações sobre as métricas a serem monitoradas, consulte Monitorar métricas do proxy do RDS com o Amazon CloudWatch.

• As funções do AWS Lambda também podem ser boas candidatas para o uso de um proxy. Essas funções fazem conexões curtas frequentes com o banco de dados que se beneficiam do grupo de conexões oferecido pelo RDS Proxy. É possível aproveitar qualquer autenticação do IAM que você já tenha para funções do Lambda, em vez de gerenciar credenciais de banco de dados em seu código de aplicação do Lambda.

• Essas aplicações que geralmente abrem e encerram um grande número de conexões de banco de dados e não têm mecanismos internos de agrupamento de conexões são ideais para usar um proxy.

• As aplicações que mantêm um grande número de conexões abertas por longos períodos geralmente são boas candidatas para o uso de um proxy. As aplicações em setores como software como serviço (SaaS) ou comércio eletrônico geralmente minimizam a latência de solicitações de banco de dados deixando as conexões abertas. Com o RDS Proxy, uma aplicação pode manter mais conexões abertas do que quando se conecta diretamente à instância de banco de dados.

• Talvez você não tenha adotado a autenticação do IAM e do Secrets Manager devido à complexidade da configuração dessa autenticação para todas as instâncias de banco de dados. Nesse caso, você pode manter os métodos de autenticação existentes implantados e delegar a autenticação para um proxy. O proxy pode aplicar as políticas de autenticação para conexões de cliente para aplicações específicas. É possível aproveitar qualquer autenticação do IAM que você já tenha para funções do Lambda, em vez de gerenciar credenciais de banco de dados em seu código de aplicação do Lambda.

• O RDS Proxy pode ajudar a tornar as aplicações mais resilientes e transparentes às falhas do banco de dados. Ele ignora os caches do Sistema de Nomes de Domínio (DNS) para reduzir os tempos de failover em até 66% para bancos de dados multi-AZ do Amazon RDS. O RDS Proxy também direciona automaticamente o tráfego para uma nova instância de banco de dados, preservando as conexões da aplicação. Isso torna os failovers mais transparentes para as aplicações.