Desempenho do RDS
Escolher a camada certa de monitoramento do RDS, ler DB load em sessões ativas médias e aplicar a alavanca de ajuste que corresponde ao gargalo, do RDS Proxy ao armazenamento e aos parâmetros.
Um banco de dados é o único componente deste domínio que consegue estar em sofrimento com todas as métricas de recurso normais. CPU tranquila, memória estável, latência de disco baixa, e ainda assim a aplicação dá timeout. Este tópico existe por causa dessa diferença: ele mostra onde a resposta mora quando os números que você tem dizem que está tudo bem.
O que este tópico cobre
- As 3 camadas de monitoramento do RDS diferenciadas por origem dos dados, granularidade e destino: métricas de instância do CloudWatch, Enhanced Monitoring e Performance Insights
- As métricas do CloudWatch que importam numa DB instance, com as 2 armadilhas clássicas:
DatabaseConnectionsnão é contagem de sessões, eBurstBalanceeEBSIOBalance%são baldes diferentes - Enhanced Monitoring: agent contra hypervisor, granularidade de 1 a 60 segundos, o log group
RDSOSMetricse a role do IAM que ele exige - DB load em sessões ativas médias, a linha de Max vCPU, e o diagnóstico fatiando por wait event, top SQL, host e usuário
- A transição do Performance Insights para o CloudWatch Database Insights, com os modos Standard e Advanced e as recomendações proativas
- Como alarmar em cada camada, incluindo a função de metric math
DB_PERF_INSIGHTS - Esgotamento de conexões: de onde vem
max_connections, como o RDS Proxy faz pool e multiplexing, e o session pinning que cancela o benefício em silêncio - As alavancas de ajuste restantes: classe de instância, tipos e limiares de armazenamento, parameter groups estáticos contra dinâmicos, Optimized Reads e Optimized Writes
Por que isso importa
A Task 1.3 do guia da SOA-C03 pede que você otimize o desempenho de bancos de dados, e as questões seguem quase sempre o mesmo formato: um sintoma, um conjunto de métricas e 4 correções plausíveis. Escolher certo depende de saber qual camada enxerga o quê. Métricas de recurso não conseguem ver uma sessão esperando um lock, o Enhanced Monitoring não aparece nas métricas do CloudWatch, e o DB load não te diz nada útil até você fatiar por wait event.
O mesmo raciocínio te protege de gastar dinheiro à toa no trabalho. Aumentar a instância quando as sessões estão esperando I/O, comprar IOPS quando a profundidade de fila está abaixo de 1, adicionar um proxy num workload que dá pin em toda sessão: cada um desses é uma fatura maior sem melhora nenhuma. As 2 lições aqui te dão a sequência de diagnóstico que separa esses casos antes de você mudar qualquer coisa.