Prácticas recomendadas para trabajar con Amazon Aurora Serverless

Por Milan Matejka, Software Development Engineer en AWS

Amazon Aurora Serverless es una configuración de escalamiento automático bajo demanda para Amazon Aurora. Amazon Aurora Serverless v2, actualmente en versión preliminar, escala instantáneamente de cientos a cientos de miles de transacciones en una fracción de segundo. A medida que escala, ajusta la capacidad en incrementos finos para proporcionar la cantidad justa de recursos de base de datos y admite todas las formas de cargas de trabajo de bases de datos. Amazon Aurora Serverless v1 es una opción sencilla y rentable para cargas de trabajo poco frecuentes, intermitentes o impredecibles. Esta publicación de blog se centra en las prácticas recomendadas para trabajar con bases de datos Aurora Serverless v1.

Aurora Serverless es adecuada para cargas de trabajo que tienen ráfagas de solicitudes intermitentes, poco frecuentes o impredecibles. Algunos ejemplos son las bases de datos de desarrollo y pruebas que se utilizan con poca frecuencia, las aplicaciones de comercio electrónico que ocasionalmente ejecutan ventas flash o las aplicaciones nuevas para las que no se puede predecir la capacidad. Organizar la capacidad justa para estas cargas de trabajo puede ser mucho trabajo; pagar por ello en un estado estable puede no ser sensato.

Con Aurora Serverless, debe tener en cuenta algunas cosas, como la administración de conexiones y los inicios en frío. En esta publicación, describimos algunas de las prácticas recomendadas importantes para Aurora Serverless, como las herramientas de depuración operativa, la seguridad y la supervisión.

Gestión de conexiones

Un desafío clave para las aplicaciones serverless modernas es la administración de conexiones. Una aplicación se comunica con una base de datos mediante el establecimiento de conexiones. El establecimiento de una conexión de este tipo consume recursos informáticos y de memoria valiosos en el servidor de base de datos. Las aplicaciones serverless pueden abrir un gran número de conexiones de base de datos o abrir y cerrar conexiones con frecuencia. Esto puede tener un impacto negativo en la base de datos y provocar un rendimiento más lento. La capacidad asignada al clúster de base de datos Aurora Serverless aumenta y disminuye sin problemas en función de la carga (el uso de la CPU y el número de conexiones) generada por la aplicación. Si sigue las prácticas recomendadas para la administración de conexiones, puede escalar adecuadamente el clúster de base de datos, reducir los costos y mejorar el rendimiento. Tiene dos opciones con Aurora Serverless: administrar su propia agrupación de conexiones de aplicaciones o utilizar la API de datos de Amazon RDS.

Agrupación de conexiones de aplicaciones

La agrupación de conexiones (Connection pooling) es una buena solución para algunas aplicaciones, como programas de larga duración, aplicaciones que no necesitan escalar la capa de aplicación y aplicaciones con tráfico constante. La agrupación de conexiones reduce el número de veces que se abren nuevas conexiones con la base de datos. Cuando necesitas una nueva conexión, obtienes una conexión ya establecida del grupo. Cuando la aplicación cierra la conexión, la conexión se devuelve al grupo en lugar de cerrarse. La agrupación de conexiones puede mejorar el rendimiento y la escalabilidad de su aplicación porque reduce el número de veces que se crean nuevas conexiones y acelera el proceso de obtención de una conexión. También evita mantener innecesariamente el clúster de base de datos a mayor capacidad porque solo mantiene tantas conexiones como necesite. Por último, las conexiones del grupo se cierran automáticamente si no se utilizan durante un tiempo determinado.

Si la agrupación de conexiones se adapta a su caso de uso, asegúrese de seguir las prácticas recomendadas generales:

Garantizar tiempos de espera y comprobaciones de estado (health checks) adecuados
Recuperar una conexión del grupo tan tarde como sea posible y devolverla lo antes posible
Cierre siempre una conexión, incluso en caso de excepción

Conexión a un clúster de base de datos de Amazon Serverless

Es necesario realizar un DNS scan para la implementación personalizada de una conmutación por error de conexión (connection failover). Sin embargo, el parámetro mariadb:aurora evita el análisis DNS automático en busca de destinos de conmutación por error y al eliminar el análisis se provoca un retraso en el establecimiento de la conexión. Si utiliza la utilidad MariaDB Connector/J con un clúster Aurora Serverless, utilice el prefijo jdbc:mariadb:aurora// en la cadena de conexión.

Aurora Serverless cierra las conexiones que tienen más de 24 horas. Asegúrese de que el grupo de conexiones actualiza las conexiones con frecuencia.

API de datos

Debido a la naturaleza transitoria de las aplicaciones serverless, suele tener más conexiones que en las aplicaciones tradicionales. Como no hay un servidor persistente, no hay lugar para almacenar un identificador de conexión para reutilizarlo. La administración de conexiones para aplicaciones serverless puede resultar engorrosa.

La API de datos reduce el esfuerzo de administrar las conexiones de bases de datos o los grupos de conexiones. La API de datos no requiere una conexión persistente al clúster de base de datos. En su lugar, proporciona un punto final HTTP seguro, respaldado por un grupo de conexiones. La API de datos utiliza credenciales de base de datos almacenadas en AWS Secrets Manager para que no tenga que pasar credenciales en las llamadas a la API. Con la API de datos, puede evitar la complejidad y la sobrecarga que conlleva la administración de conexiones. En el siguiente diagrama se ilustra una arquitectura representativa de Aurora Serverless mediante la API de datos.

Para obtener más información sobre la API de datos, consulte Uso de la API de datos para Aurora Serverless.

Capacidad mínima

La capacidad de Aurora Serverless se mide en unidades de capacidad (ACU) de Aurora. Cada ACU incluye aproximadamente 2 GB de memoria, la CPU correspondiente y recursos de red. Como práctica recomendada, establezca la capacidad mínima adecuada en lugar de utilizar el valor predeterminado.

Aurora Serverless se amplía cuando se observan restricciones de capacidad en la CPU o en las conexiones. Sin embargo, encontrar un punto de escala puede llevar tiempo (consulte la sección Operaciones de bloqueo de escala). Pruebe su aplicación para determinar la capacidad mínima adecuada. Si observa que su aplicación necesita más recursos, establezca una capacidad mínima más alta. Si descubre que su clúster tiene dificultades para encontrar un punto de escalamiento, es posible que su capacidad mínima sea demasiado baja y que su base de datos esté demasiado ocupada para pausar las transacciones y escalar. En ese caso, aumente su capacidad mínima y vuelve a ejecutar la prueba.

Si hay un aumento repentino en las solicitudes, puede sobrecargar la base de datos. Es posible que Aurora Serverless no encuentre un punto de escalamiento y escale lo suficientemente rápido debido a la escasez de recursos. Esto es especialmente cierto cuando el clúster tiene una capacidad de 1 ACU, lo que corresponde a aproximadamente 2 GB de memoria. Normalmente, 1 ACU no es adecuada para cargas de trabajo de producción.

Minimizar el tiempo de pausa y reanudación

Puede optar por pausar el clúster de base de datos Aurora Serverless transcurrido un tiempo determinado sin actividad. Cuando se pausa el clúster de base de datos, no se produce actividad de computo ni de memoria y solo se cobra por el almacenamiento. Si se solicitan conexiones de base de datos cuando se pausa un clúster de base de datos Aurora Serverless, el clúster de base de datos reanuda automáticamente y da servicio a las solicitudes de conexión.

Algunas aplicaciones pueden requerir una reanudación rápida. La reanudación del clúster tarda unos segundos y, en algunos casos, puede durar más en función de variables como la ACU, el tamaño de almacenamiento y más. Para evitar un arranque en frío, considere deshabilitar la pausa automática y, como se explicó en la sección anterior, establezca la capacidad mínima adecuada.

Precalentamiento

Es posible que tenga casos de uso en los que sepa exactamente cuándo ampliar o reanudar el clúster, o casos prácticos en los que se espera un aumento brusco de la carga en un corto período de tiempo. En esos casos, escalar o despertar el clúster puede no ser lo suficientemente rápido. En su lugar, se puede precalentar el clúster. Puede reanudar el clúster estableciendo una nueva conexión a través de la API de datos o puede llamar a la API de Amazon RDS para modificar el clúster según sus necesidades. Para ejecutar un trabajo periódico, puede crear una regla de Amazon CloudWatch programada o utilizar Amazon EventBridge para llamar a AWS Lambda para que realice el trabajo. Para obtener instrucciones, consulte Tutorial: Programar funciones AWS Lambda con CloudWatch Events y Tutorial: Programar funciones AWS Lambda mediante EventBridge, respectivamente. Al reanudar un clúster, asegúrese de ejecutar la carga dentro del periodo de tiempo SecondsUtilAutoPause. El siguiente diagrama ilustra esta arquitectura.

Un clúster = una base de datos

En el mundo de las bases de datos tradicionales, es común tener un clúster que contenga varias bases de datos. Ayuda a reducir el mantenimiento y los costes. Eso no es cierto para Aurora Serverless. AWS realiza el mantenimiento y las actualizaciones de forma automática. No hay límite para el número de bases de datos que se pueden tener en un clúster de Aurora Serverless, pero se recomienda agrupar únicamente esquemas o bases de datos que atienden casos de uso de aplicaciones similares. La división de bases de datos no relacionadas en clústeres independientes reduce el radio de explosión de posibles fallos o problemas de rendimiento, y las operaciones de escalamiento se pueden ejecutar de forma independiente en función de los patrones de tráfico únicos de la base de datos. A diferencia de otros motores de base de datos, la consolidación de varias bases de datos en un solo clúster no supone ningún beneficio en cuanto se establezca la configuración de capacidad adecuada. Dado que el costo principal de Aurora Serverless es por ACU (no por clúster ni por licencia), también puede ahorrar costos a largo plazo.

Operaciones de bloqueo de escalas

La capacidad asignada al clúster de base de datos Aurora Serverless se escala sin problemas. Sin embargo, el uso de consultas o transacciones de larga duración y tablas temporales o bloqueos de tabla puede retrasar la búsqueda de un punto de escala.

Consultas o transacciones de larga duración

Para las transacciones, se deben seguir las mejores prácticas estándar. Por ejemplo, mantenga sus transacciones simples, cortas y utilice un nivel de aislamiento adecuado. Para obtener más información, consulte Declaraciones Transaccionales y de Bloqueo y Optimizar la Gestión de Transacciones InnoDB.

La práctica más importante es evitar transacciones de larga duración. En general, para cualquier base de datos relacional, las transacciones de larga duración pueden provocar una degradación del rendimiento. Específicamente para Aurora Serverless, las transacciones de larga duración bloquean las operaciones de escalamiento a menos que se utilice el parámetro de escalamiento forzado. Incluso en este escenario, primero debe completar un rollback adecuado, lo que puede llevar mucho tiempo. Esto puede tener un impacto muy negativo en su aplicación. En cualquier caso, se debe recordar gestionar correctamente las excepciones de reversión a nivel de aplicación.

Para Aurora Serverless MySQL 5.6, la excepción tendrá el siguiente aspecto:

mysql> SELECT * FROM Customer;
ERROR 1105 (HY000): The last transaction was aborted due to an unknown error. Please retry.

Para Aurora Serverless MySQL 5.7, la excepción tendrá el siguiente aspecto:

mysql> SELECT * FROM Customer; ERROR 1105 (HY000): The last transaction was aborted due to Seamless Scaling. Please retry.

Si su sistema requiere transacciones de larga duración, reduzca primero el alcance de la transacción al mínimo accediendo a la menor cantidad de datos dentro del cuerpo de la transacción. Intenta dividir la transacción en subtransacciones más pequeñas y ejecútalas de forma independiente. Por ejemplo, si es posible, recupere los datos de las tablas por separado.

Una sola consulta de larga duración puede bloquear el escalamiento. Una sola consulta es implícitamente una transacción de estado único, por lo que siguen principios y prácticas recomendadas similares a los mencionados anteriormente para las transacciones de larga duración.

Por último, establezca tiempos de espera adecuados para las instrucciones y las transacciones. Para PostgreSQL 10, se puede usar statement_timeout e idle_in_transaction_session_timeout. Para MySQL 5.7, se puede usar max_execution_time.

Tablas temporales o bloqueo de tabla

Durante el diseño de la aplicación y la base de datos, recuerde que las tablas temporales y los bloqueos de tabla también bloquean las operaciones de escalamiento a menos que habilite el parámetro de escalamiento forzado. El tiempo de espera (timeout) potencial y el escalamiento forzado dan como resultado un rollback adecuado de las transacciones. Si utiliza cualquiera de ellos, tenga en cuenta el posible impacto en su aplicación.

Una tabla temporal es un tipo especial de tabla que permite almacenar un conjunto de resultados temporales que puede reutilizar varias veces. Aurora Serverless elimina la tabla temporal automáticamente cuando finaliza la sesión o finaliza la conexión. También puede soltar la tabla manualmente para quitar una tabla temporal de forma explícita cuando ya no la necesite. Si tienes que usar tablas temporales, intenta limitar su duración total. Crea una tabla temporal cuando la necesites y suéltala tan pronto como puedas en lugar de esperar a que se limpie automáticamente. En algunos casos de uso, una tabla temporal se crea internamente como parte de la instrucción. Los usuarios no tienen control sobre cuándo ocurre esto. La duración de estas tablas temporales es la duración de la propia consulta. Estos ejemplos pueden ser instrucciones UNION, vistas, tablas derivadas o CTE (common table expressions). Para obtener más información, consulte Uso de tablas temporales internas en MySQL.

Una regla similar también se aplica a los bloqueos de tabla. Los bloqueos de tabla suelen utilizarse para emular transacciones o para acelerar la actualización de tablas. Si la sesión finaliza, de forma normal o anormal, Aurora Serverless libera todos los bloqueos de forma implícita. La mejor opción es evitar los bloqueos de tabla. Si debe usarlos, mantenga el bloqueo durante el tiempo mínimo necesario.

Lógica de reintento

Numerosos componentes de una red, como servidores DNS, conmutadores, equilibradores de carga y otros, pueden generar errores en cualquier parte de la vida de una solicitud determinada. Otros errores incluyen la falta de disponibilidad temporal de un servicio o los tiempos de espera que se producen cuando un servicio está ocupado. Estos errores suelen ser autocorregidos. La técnica habitual para tratar estas respuestas de error es implementar reintentos en la aplicación cliente. Esta técnica aumenta la fiabilidad de la aplicación y reduce los costes operativos para el desarrollador. Al diseñar la aplicación, asegúrese de implementar la lógica de reintento en la capa de acceso a datos. Para obtener más información, consulte Retroceso exponencial (exponential backoff) y fluctuación (jitter) y Tiempos de espera, reintentos y retardo con fluctuación.

Cuando el escalamiento forzado está habilitado, el escalamiento se produce tan pronto como se alcanza el tiempo de espera, que es de 300 segundos de forma predeterminada. Este comportamiento puede provocar una interrupción de la base de datos de la aplicación. Si implementa la lógica de reintento, esto se gestiona y se vuelve a intentar en la capa de base de datos y no afecta al resto de la aplicación. De hecho, esto puede acelerar potencialmente el proceso de escalamiento y su aplicación puede ser más resistente.

Diferencia entre Aurora Serverless PostgreSQL y Aurora Serverless MySQL

Aurora PostgreSQL y Aurora MySQL son dos motores de base de datos diferentes, pero en términos de Aurora Serverless, tanto Aurora Serverless PostgreSQL como Aurora Serverless MySQL no presentan grandes diferencias. Existen ligeras diferencias en la disponibilidad de las configuraciones de ACU y, en consecuencia, en la configuración específica de memoria y computo del servidor. La diferencia más importante es que Aurora Serverless MySQL admite una configuración ACU mínima de 1 y Aurora Serverless PostgreSQL admite un mínimo de 2.

Acceso a Aurora Serverless

Aurora Serverless reside en la subred privada de Amazon Virtual Private Cloud (Amazon VPC). No puede dar una dirección IP pública a un clúster de base de datos Aurora Serverless; solo puede acceder a él estando dentro de una VPC basada en el servicio de Amazon VPC. Puede utilizar cualquier servicio, como Amazon Elastic Compute Cloud (Amazon EC2), AWS Lambda, Amazon Elastic Container Service (Amazon ECS) y más, si residen en la misma VPC.

Para el acceso de desarrolladores al clúster Aurora Serverless, tiene dos tipos de acceso: la API de datos o un túnel SSH a través de una caja de salto (jump box).

Acceso a la API de datos

Para las siguientes opciones, debe habilitar la API de datos para el clúster de base de datos Aurora Serverless.

Para obtener un acceso sencillo y básico, puede utilizar el editor de consultas para Aurora Serverless en la consola de Amazon Relational Database Service (Amazon RDS). Los resultados de las consultas son visibles al instante en la consola. El editor de consultas es adecuado para verificar el contenido de la tabla o realizar algunas instrucciones SQL rápidas.

Es posible que prefiera utilizar la interfaz de línea de comandos de AWS (CLI de AWS) directamente, compatible con Aurora Serverless.

El código siguiente es un ejemplo para Linux, macOS o Unix:

aws rds-data execute-statement \
--resource-arn "arn:aws:rds:us-east-1:123456789012:cluster:my_db_cluster" \
--database "mydb" \
--secret-arn "arn:aws:secretsmanager:us-east-1:123456789012:secret:my_secret" \
--sql "SELECT * FROM Customer"

El código siguiente es un ejemplo para Windows:

aws rds-data execute-statement ^
--resource-arn "arn:aws:rds:us-east-1:123456789012:cluster:my_db_cluster" ^
--database "mydb" ^
--secret-arn "arn:aws:secretsmanager:us-east-1:123456789012:secret:my_secret" ^
--sql "SELECT * FROM Customer"

Del mismo modo, puede utilizar la API de datos para conectar y ejecutar fácilmente cualquier instrucción SQL en la base de datos con una sencilla función de Lambda. No es necesario que la función esté dentro de una VPC de Amazon personalizada ni tener controladores MySQL o PostgreSQL. Simplemente se ejecutan instrucciones SQL como una solicitud HTTP.

Acceso al túnel SSH

La otra opción es utilizar AWS Cloud9. AWS Cloud9 es un entorno de desarrollo integrado (IDE) basado en la nube que proporciona acceso a la terminal con solo un navegador. La principal ventaja es que no es necesario instalar ni mantener un IDE local. Para obtener instrucciones, consulte Configurar y conectarse a una base de datos MySQL serverless.

Puede que ya esté familiarizado con algunos IDE, como MySQL Workbench, HeidiSQL, pgAdmin o dBeaver. Puede seguir utilizándolos con una configuración similar a la de AWS Cloud9. Debido a que no se puede conectar directamente a su servidor a través de SSH, debe configurar una caja de salto. Esto es lo mismo que en la configuración de AWS Cloud9, que se realiza automáticamente. Para configurar una caja de salto, sigue los pasos siguientes:

Cree una instancia EC2 basada en Linux en la misma región y en la misma VPC que el clúster Aurora Serverless.
Asegúrese de que puede utilizar SSH en la instancia mediante el nombre de usuario y la clave privada (private key).
Habilite el acceso de red de clientes a su clúster
- Buscar los grupos de seguridad (security groups) de VPC de su clúster.
- Seleccione reglas de entrada (Inbound Rules).
- Añada una nueva regla con Sourcetomando el ID del grupo de seguridad de la instancia de EC2 y Type como una de las siguientes opciones:
  - MySQL/aurora (3306) para MySQL
  - PostgreSQL (5432) para PostgreSQL

Actualice su IDE:
- Para el nombre de host o la dirección IP del clúster, utilice el endpoint de base de datos de clúster Aurora Serverless.
- Para las credenciales del clúster, introduzca el nombre de usuario y la contraseña del clúster.
- Para puerto de clúster, introduzca lo siguiente:
  - 3306 para MySQL
  - 5432 para PostgreSQL
- Para host y puerto SSH, defina el nombre DNS público de la instancia EC2.
- En Nombre de usuario SSH, introduzca el nombre de usuario que utiliza para acceder a la instancia de EC2.
- Para SSH, establezca su clave privada (.pem).

Resiliencia

La resiliencia es una parte importante del diseño. Aurora Serverless ofrece funciones que ayudan a respaldar la resiliencia de sus datos.

Failover

Aurora separa la capacidad de cómputo del almacenamiento. El volumen de almacenamiento del clúster se distribuye en varias zonas de disponibilidad (Availability Zones). La durabilidad de los datos no se ve afectada incluso si las interrupciones afectan a la instancia de base de datos o a la zona de disponibilidad asociada.

Los clústeres de Aurora Serverless se supervisan para comprobar su disponibilidad y se reemplazan automáticamente cuando se detectan problemas; no es necesario que intervenga por su parte. Aurora Serverless administra el warmpool de los clústeres de base de datos creados previamente. A continuación, el proceso de reemplazo obtiene una nueva instancia de base de datos del servicio del warmpooling y reemplaza el host que no está en buen estado.

La instancia de base de datos de un clúster de base de datos Aurora Serverless se crea en una única zona de disponibilidad. En el improbable caso de que una zona de disponibilidad completa deje de estar disponible, Aurora Serverless lanza una nueva instancia para su clúster en una de las otras zonas de disponibilidad. Nos referimos a esta capacidad como conmutación por error automática Multi-AZ (automatic Multi-AZ failover). Este mecanismo de conmutación por error tarda más en Aurora Serverless que en un clúster aprovisionado de Aurora. La conmutación por error de la zona de disponibilidad para Aurora Serverless se realiza como mejor esfuerzo porque depende de la demanda y la disponibilidad de capacidad en otras zonas de disponibilidad dentro de la región de AWS determinada. Por este motivo, Aurora Serverless no es compatible con el SLA de Aurora Multi-AZ.

Replicación

La replicación basada en binlog y la función de réplicas de Aurora son limitadas para los clústeres de base de datos Aurora Serverless. Si necesita estas funciones, considere la posibilidad de utilizar la versión aprovisionada de Aurora. Para obtener más información, consulte Limitaciones de Aurora Serverless.

Puede utilizar Aurora Serverless como destino de las replicaciones de datos de AWS Database Migration Service (AWS DMS). Para obtener más información, consulte Introducción a AWS Database Migration Service.

Seguridad

La seguridad en la nube de AWS es la máxima prioridad. En las secciones siguientes se muestra la configuración recomendada de Aurora Serverless para cumplir sus objetivos de seguridad y cumplimiento normativo. También aprenderá a utilizar otros servicios de AWS que le ayudan a supervisar y proteger sus recursos Aurora Serverless.

Parches y mantenimiento

Aurora Serverless realiza un mantenimiento periódico para que su clúster de base de datos cuente con las últimas funciones, correcciones y actualizaciones de seguridad. Aurora Serverless realiza el mantenimiento de forma no disruptiva siempre que sea posible. Sin embargo, puede interrumpir la carga de trabajo en algunos casos de uso. Para obtener más información, consulte Cómo funciona Aurora Serverless v1. Para evitar interrupciones, se recomienda que siga las mismas prácticas recomendadas que ya se mencionaron en la sección Operaciones de bloqueo de escala.

TLS/SSL

Para mejorar la seguridad, puede conectarse a los clústeres de Aurora Serverless mediante el protocolo Seguridad de la capa de transporte/capa de sockets seguros (TLS/SSL). Se recomienda el uso de SSL y es la primera opción para establecer una nueva conexión, pero no es obligatorio. Para asegurarse de que su sesión utiliza TLS, especifique el requisito en el lado del cliente con el parámetro --ssl-mode igual a VERIFY_CA o VERIFY_IDENTITY. Aurora Serverless admite el protocolo TLS versión 1.0, 1.1 y 1.2.

Instantáneas (Snapshots)

El volumen del clúster de un clúster de Aurora Serverless siempre está cifrado. Puedes elegir la clave de cifrado, pero no puedes desactivar el cifrado. Para copiar o compartir una instantánea de un clúster de Aurora Serverless, cifre la instantánea con su propia clave de AWS Key Management Service (AWS KMS).

Monitoreo

Aurora Serverless proporciona una variedad de métricas de CloudWatch que puede supervisar para determinar el estado y el rendimiento de su clúster de base de datos Aurora Serverless. Para acceder a las métricas de CloudWatch, puede utilizar herramientas como la consola de Amazon RDS, la CLI de AWS o la API de CloudWatch.

En un escenario de base de datos tradicional, es necesario supervisar varias métricas de infraestructura. Dado que Aurora Serverless es un servicio totalmente administrado, no es necesario supervisar el estado de la infraestructura subyacente. La administración de plataformas y aplicaciones y cualquier sistema operativo y configuración de red es responsabilidad de AWS, pero es importante recordar que los clientes son responsables de la administración del acceso, de su aplicación y del rendimiento. El modelo de responsabilidad compartida describe las responsabilidades entre AWS y el cliente.

Crear un plan de seguimiento adecuado es un tema difícil con muchas variables. Para obtener más información sobre cómo establecer los objetivos de supervisión adecuados, consulte Monitoreo de un clúster de base de datos de Amazon Aurora.

En la actualidad, Amazon RDS Performance Insights solo está disponible para su uso con algunos motores de base de datos. Para obtener más información, consulte Supervisión con Performance Insights en Amazon RDS.

Logs y auditoría

Puede hacer que Aurora publique algunos o todos los logs de la base de datos en CloudWatch. Puede realizar análisis en tiempo real de los datos de los logs, auditar la actividad de la base de datos y utilizar CloudWatch para crear alarmas y ver métricas. También puede almacenar sus logs en un almacenamiento muy duradero.

Para seleccionar los logs que desea publicar, habilite los parámetros de configuración en el grupo de parámetros del clúster de base de datos (DB cluster parameter group) asociado al clúster Serverless. Los clústeres serverless no requieren que especifique qué tipos de registro se van a cargar en CloudWatch, como los clústeres aprovisionados. Los clústeres serverless cargan automáticamente todos los logs disponibles. Al deshabilitar un parámetro de configuración de registro, se detiene la publicación del registro en CloudWatch. También puede eliminar los logs de CloudWatch si ya no los necesita.

Después de habilitar los eventos de registro de Aurora Serverless, puede supervisar los sucesos en CloudWatch Logs. Se crea automáticamente un nuevo grupo de logs para el clúster de base de datos de Aurora con el siguiente prefijo, en el que my_db_cluster representa el nombre del clúster de base de datos y log_type representa el tipo de registro:

/aws/rds/cluster/my_db_cluster/log_type

Aurora Serverless PostgreSQL utiliza un único tipo de registro denominado error.

En el caso de Aurora Serverless MySQL, el registro se controla con los siguientes parámetros:

slow_query_log — Crea un registro de consultas lento
long_query_time — Impide que las consultas de ejecución rápida se registren en el registro de consultas lentas
general_log — Crea el registro general
log_queries_not_using_indexes — Registra todas las consultas que no utilizan un índice en el registro de consultas lentas
server_audit_logging: habilita o deshabilita la auditoría avanzada y
server_audit_events especifica qué sucesos de auditoría se van a registrar

Para obtener más información, consulte Publicación de logs de Amazon Aurora MySQL en Amazon CloudWatch Logs y Uso de auditorías avanzadas con un clúster de base de datos Amazon Aurora MySQL.

En el caso de Aurora Serverless PostgreSQL, el registro se controla con los siguientes parámetros:

log_statement — Controla qué instrucciones SQL se registran
log_min_duration_statement — Establece el límite en milisegundos de una sentencia que se va a registrar
log_connections — Registra todos los detalles de conexión del cliente nuevo; está habilitado de forma predeterminada y no se puede modificar
log_disconnections — Registra todas las desconexiones del cliente; está habilitado de forma predeterminada y no se puede modificar
log_temp_files — Controla el registro de nombres y tamaños de archivos temporales
log_lock_waits — Registra las sesiones que están bloqueadas en un estado bloqueado
log_autovacuum_min_duration — Registra información de las ejecuciones de autovacuum y autoanalyzer (debe habilitar force_autovacuum_logging_level)
force_admin_logging_level — Captura las actividades del usuario rdsadmin

Para obtener más información, consulte Trabajando con logs de RDS y Aurora PostgreSQL: Parte 1 y Trabajando con logs de RDS y Aurora PostgreSQL: Parte 2.

Conclusión

En esta publicación se analizan las prácticas recomendadas para Aurora Serverless, que deberían ayudarle a diseñar su arquitectura y crear aplicaciones más robustas, seguras y escalables. Para empezar a utilizar Aurora Serverless hoy mismo, consulte Creación de aplicaciones serverless con Amazon Aurora Serverless.

Para obtener más información sobre Aurora Serverless, consulte lo siguiente:

Este artículo fue traducido del Blog de AWS en Inglés.

Sobre el autor

Milan Matejka se incorporó a Amazon en 2017. Es ingeniero de desarrollo de software en Amazon Web Services. Milán tiene un máster en Análisis Matemático.

Sobre el traductor

Iván González es arquitecto de soluciones en AWS México.

Sobre los revisores

Rodrigo Cabrera es Arquitecto de Soluciones de AWS.

Servio Reyes es Arquitecto de Soluciones de AWS.

Blog de Amazon Web Services (AWS)