Rendimiento de RDS

Una base de datos administrada te esconde el sistema operativo, y eso deja fuera de juego los instintos habituales de diagnóstico. No puedes entrar y correr top. Las métricas de recursos dicen que la máquina está bien mientras la aplicación se cae por timeout. Este tema cubre el monitoreo que RDS te da en su lugar, y el conjunto chico de palancas que arreglan lo que ese monitoreo encuentra.

Dos lecciones. La primera te enseña a ver: las métricas de instancia de CloudWatch, Enhanced Monitoring y Performance Insights miran la base desde lugares distintos, y elegir la equivocada es la razón por la que un incidente real puede verse como un gráfico sano. La segunda te enseña a actuar: primero el agotamiento de conexiones y RDS Proxy, porque es la falla de RDS más común en cargas serverless y de alta concurrencia, y después los cambios de almacenamiento, de clase de instancia y de parámetros que cubren el resto.

Qué cubre este tema

• Las 3 capas de monitoreo y qué puede y qué no puede ver cada una: métricas del hipervisor, un agente en el sistema operativo y el motor de base de datos
• Las métricas de CloudWatch del namespace AWS/RDS sobre las que vale alarmar, incluidas las 2 métricas de burst balance que se confunden entre sí
• La granularidad de Enhanced Monitoring, su rol de IAM, y por qué sus datos aterrizan en CloudWatch Logs y no en métricas de CloudWatch
• La carga de la base en sesiones activas promedio, la línea de referencia Max vCPU, y cortar la carga por evento de espera, top SQL, host y usuario
• El paso de Performance Insights a CloudWatch Database Insights, y qué incluye cada modo, Standard y Advanced
• Connection pooling y multiplexing de RDS Proxy, el pinning de sesión y cómo detectarlo, los valores predeterminados del pool y el failover más rápido
• Palancas de ajuste más allá del proxy: límites de la clase de instancia, umbrales de gp3 y io2 Block Express, parameter groups, réplicas de lectura y las funciones RDS Optimized Reads y Optimized Writes

Por qué importa

Las bases de datos son donde los incidentes de CloudOps se vuelven caros, y las preguntas de RDS del examen lo reflejan. Rara vez preguntan qué hace un servicio. Te dan un síntoma (conexiones rechazadas mientras la CPU está en 30%, una consulta que se puso lenta después de una carga de datos, almacenamiento que se enlentece media hora después de arrancar un job nocturno) y preguntan qué métrica prueba la causa y qué cambio la arregla.

Acertar ahí depende de 2 discriminaciones más que de cualquier otra cosa: saber qué capa de monitoreo puede siquiera ver el problema que estás persiguiendo, y saber si la restricción son las conexiones, la CPU, el almacenamiento o el diseño de las consultas. Este tema construye las dos, y cierra el hilo de rendimiento que venía corriendo por cómputo y almacenamiento en los temas anteriores.