Introducción

En mi artículo Amazon DevOps Guru para aplicaciones sin servidor: Parte 10 Detección de anomalías en Aurora Serverless v2, aprendimos que DevOps Guru pudo detectar anomalías con éxito con la base de datos PostgreSQL de Aurora (Serverless v2) en el caso de la función Lambda con Java 21 administrado. El tiempo de ejecución se conectó a través de JDBC. Escalamos nuestra base de datos solo de 0,5 a 1 ACU y creamos una carga muy alta en la base de datos al invocar la función Lambda para recuperar el producto por identificación varios cientos de veces simultáneamente durante varios minutos. Vimos que DevOps Guru señaló correctamente la mayor suma de conexiones de bases de datos y la carga constantemente alta de la base de datos (CPU). En este artículo, me gustaría determinar si DevOps Guru detectará la anomalía realizando el mismo experimento pero utilizando Data API para Aurora Serverless v2 con AWS SDK para Java en lugar de JDBC.

Detección de anomalías en Aurora Serverless v2 con API de datos

Veamos nuestra aplicación de muestra y usemos la plantilla SAM para crear infraestructura e implementar la aplicación descrita en la siguiente imagen:

La aplicación crea productos almacenados en la base de datos PostgreSQL de Aurora Serverless v2 y los recupera por identificación mediante Data API. La función Lambda relevante que usaremos para recuperar el producto por su ID es GetProductByIdViaAuroraServerlessV2DataApi y la implementación de su controlador es GetProductByIdViaAuroraServerlessV2DataApiHandler.

Como en el artículo anterior utilizamos la herramienta Hey para realizar la prueba de estrés como esta

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

En este ejemplo, invocamos el punto final de API Gateway con 300 contenedores simultáneos durante 15 minutos. Detrás del punto final prod/productsWithoutDataApi, se invocará la función Lambda GetProductByIdViaAuroraServerlessV2WithoutDataApi, que recuperará el producto por ID 1 de la base de datos PostgreSQL de Aurora Serverless v2.

Configuramos en nuestra [plantilla SAM]((https://github.com/Vadym79/AWSLambdaJavaAuroraServerlessV2DataApi/blob/master/template.yaml) el clúster de base de datos Aurora para escalar desde una capacidad mínima de 0,5 a una capacidad máxima de 1 ACU (que es tamaño de base de datos muy pequeño) en caso de aumentar la carga con el fin de ahorrar costos.

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

La base de datos Aurora (Serverless v2) administra el número máximo de conexiones de base de datos disponibles proporcionalmente al tamaño de la base de datos (en nuestro caso, la configuración de ACU) también con Data API para Aurora Serverless v2 (que es una gran diferencia con la v1, que se convertirá en sin soporte a finales del año 2024, donde había una cuota estricta de 1000 conexiones de bases de datos por segundo). Para obtener más información, lea la documentación sobre Conexiones máximas para Aurora Serverless v2. Por lo tanto, con el mayor número de invocaciones, esperamos alcanzar pronto el número máximo de conexiones de base de datos disponibles y una alta carga de base de datos (CPU), por lo que la base de datos no podrá responder a las nuevas solicitudes de la función Lambda para recuperar el producto por id (entonces Lambda también se encontrará). Con eso provocaremos la anomalía y nos gustaría saber si DevOps Guru podrá detectarla. Y fue capaz, más o menos... Se generó la siguiente información:

Y se han identificado las siguientes métricas anómalas agregadas:

En comparación con las métricas anómalas agregadas identificadas en caso de usar JDBC en lugar de Data API descritas en mi artículo Amazon DevOps Guru para aplicaciones sin servidor - Parte 10 Detección de anomalías en Aurora Serverless v2, desordenamos por completo las métricas anómalas de la base de datos de Aurora: conexión de la base de datos La suma y la base de datos (CPU) se cargan, pero veo correctamente el error en Lambda que se ejecutó en el tiempo definido de 15 segundos porque la base de datos no pudo. responder.

.

Entonces, ¿cuál es la diferencia? Exploremos los dos incidentes que reproducimos en el clúster PostgreSQL de Aurora Serverless v2 con JDBC (API sin datos) y API de datos:

En términos de utilización/escalamiento de ACU, ambos tienen el mismo aspecto:

En términos de otras métricas de bases de datos como: utilización de CPU, carga de DB de conexión de base de datos (CPU), existen grandes diferencias:

• La utilización de la CPU tiene el mismo aspecto para los casos de JDBC (API sin datos) y API de datos. Pero DevOps Guru parece no considerar esta métrica, ya que no la vimos ni siquiera en el experimento JDBC
• DBLoad(CPU), que es muy bajo para el uso de la API de datos. Parece que para Dat API hay algún Load Balancer frente a la base de datos Aurora Serverless v2 que monitorea el uso de la conexión y protege la base de datos contra sobrecargas.
• La métrica de conexión de base de datos no se muestra (o se muestra como 0) para el uso de la API de datos. La razón de esto es que no administramos la conexión de la base de datos para la API de datos, se hace en el otro lado por nosotros. Por supuesto, todavía juegan un papel importante que aprendimos en Conexiones máximas para Aurora Serverless v2, pero esta métrica parece estar expuesta al exterior en CloudWatch Metrics e incluso DevOps Guru no tiene ningún acceso a los números reales.

Con eso y una DBLoad (CPU) muy baja, no se ha generado información de DevOps Guru para el clúster Aurora Serverless v2 con uso de API de datos en comparación con el caso de uso de JDBC.

Hice el segundo experimento conectándome directamente al clúster Aurora Serverless v2 y escribí el script para crear la prueba de carga escribiendo el script que recupera el producto por identificación cientos de veces usando la forma estándar (API sin datos). Similar a lo que hicimos con la herramienta hey, pero accediendo a la base de datos directamente en lugar de invocar Api Gateway. Después de cargar la base de datos, comencé el mismo experimento con la herramienta hey como se describe anteriormente y quería ver qué pasaba. Se generó la misma información, pero esta vez con las siguientes métricas anómalas:

Ahora vemos al menos una métrica anómala de suma de conexión de base de datos Aurora Serverless v2 adicional, pero aún faltan métricas DBLoad(CPU).

Las anomalías gráficas se ven así:

Por supuesto, el experimento no fue limpio, ya que hice 2 pruebas de carga una tras otra y parcialmente en paralelo: la primera conectándose a la base de datos directamente sin el uso de API Gateway y la segunda usando Data API. Esto confirmó mi suposición inicial de que las métricas de suma de conexiones de bases de datos son un criterio muy importante para generar información de DevOps Guru para Aurora Serverless v2 (y para RDS en general) y no se exponen en general en caso de usar Data API.
Ya me comuniqué con el equipo de Devops Guru y compartí con ellos mis conocimientos con la expectativa de que mejoren el servicio. O, en primer lugar, exponer la conexión de la base de datos como métrica de CloudWatch se solucionará para el uso de Aurora Serverless v2 con API de datos.

Conclusión

En este artículo, aprendí que DevOps Guru podía detectar anomalías con éxito con la base de datos PostgreSQL Aurora (Serverless v2) en el caso de la función Lambda con el tiempo de ejecución administrado de Java 21 conectado a través de Data API, pero solo podía mostrar las métricas anómalas relacionadas con la función Lambda. se agotó el tiempo de espera porque la base de datos no respondió. La razón principal de esto parece ser que la conexión de la base de datos como métrica de CloudWatch no está expuesta (o siempre se muestra como 0) en caso de utilizar Aurora Serverless v2 con Data API. Las métricas de la base de datos de Aurora Serverless v2 (suma de conexiones de la base de datos) solo se mostraron durante el segundo experimento artificial.