Prácticas recomendadas de almacenamiento para cargas de trabajo de producción en Amazon RDS o Amazon EC2

• ¿Cuáles son las mejores opciones en términos de tipos de almacenamiento de bases de datos?
• ¿Cómo resolver los problemas de rendimiento del almacenamiento?
• ¿Cuáles son las opciones de configuración de RAID para las bases de datos alojadas en instancias EC2?
• ¿Cuáles son las modificaciones de la aplicación necesarias para un rendimiento óptimo?
• ¿Cómo solucionar problemas de rendimiento del almacenamiento con Amazon CloudWatch?
• ¿Rendimiento operativo de Amazon RDS frente a Aurora?

En esta publicación, proporciono las prácticas recomendadas de almacenamiento para operar cargas de trabajo de producción en bases de datos alojadas en instancias de Amazon RDS o EC2.

En comparación con los entornos de prueba, control de calidad, o desarrollo, las cargas de trabajo de producción requieren un rendimiento de E/S (I/O) rápido y constante. Si bien las bases de datos relacionales se pueden usar para varios propósitos, su caso de uso más común es alojar una carga de trabajo de procesamiento de transacciones en línea (OLTP). RDS, las bases de datos alojadas en EC2, RDS, y Aurora utilizan diferentes tipos de técnicas de almacenamiento, como se muestra a continuación:

• Las instancias de base de datos de Amazon RDS utilizan volúmenes de Amazon EBS para el almacenamiento.
• Las instancias de Aurora utilizan volúmenes de almacenamiento propietarios de AWS.
• Las instancias EC2 permiten una variedad de opciones de almacenamiento.

Las mejores opciones de tipo de almacenamiento de bases de datos

Amazon RDS provee tres tipos de almacenamiento:

• SSD de uso general (también conocido como volúmenes gp2)
• SSD de IOPS aprovisionado (también conocido como io1)
• Almacenamiento Magnético

La capacidad de E/S (I/O) de la instancia se basa en el tipo y el tamaño de almacenamiento de la instancia. Si la instancia de base de datos está configurada con un volumen gp2, la capacidad de IOPS básica triplica el almacenamiento en GiB. Si la instancia de base de datos ha asignado un volumen gp2 de 100 GiB, la capacidad de IOPS de referencia es de 300. Cuanto más almacenamiento aprovisione, mayor será la capacidad de IOPS.

Además de la capacidad de IOPS de referencia, los volúmenes gp2 también ofrecen una capacidad de ráfaga de hasta 3,000 IOPS durante períodos prolongados. La función de ráfaga está limitada a volúmenes iguales o inferiores a 1 TiB de almacenamiento. Las instancias de base de datos para MySQL, MariaDB, Oracle, y PostgreSQL se pueden configurar con entre 20 GB y 32 TiB, pero la cantidad máxima de IOPS de referencia está limitada de 100 a 16,000 IOPS. Por lo tanto, un volumen gp2 de 5.34 TiB o más ofrece la misma base de referencia: 16,000 IOPS

Si su carga de trabajo de producción requiere un OLTP elevado y un desempeño de alto rendimiento rápido y constante, debe configurar la instancia de base de datos con volúmenes io1. En comparación con los volúmenes gp2, que ofrecen una línea base máxima de 16,000 IOPS, los volúmenes io1 pueden ofrecer hasta 40,000 IOPS para las instancias de base de datos de MySQL, MariaDB, Oracle y PostgreSQL, y hasta 32,000 para las instancias de SQL Server.

Si observa que el patrón de uso de IOPS supera de forma constante más de 16,000, debe modificar la instancia de base de datos y cambiar el tipo de almacenamiento de gp2 a io1. Amazon RDS también ofrece almacenamiento magnético, pero no es adecuado para una carga de trabajo de OLTP que requiera un rendimiento de E/S (I/O) uniforme y una latencia baja.

El tipo de almacenamiento magnético no se recomienda para cargas de trabajo con un uso intensivo de E/S (I/O) porque el almacenamiento máximo es inferior al de gp2 o io1. La capacidad de IOPS también está limitada a un máximo de 1,000 IOPS.

Problemas de rendimiento del almacenamiento

El uso del almacenamiento gp2 es ideal para una amplia variedad de cargas de trabajo de base de datos. Para este tipo de almacenamiento, diseñe las cargas de trabajo de lectura y escritura de las bases de datos de forma que la suma de los valores de ReadIOPS y WriteIOPS no supere la capacidad de IOPS de referencia en ningún momento dado.

La capacidad de ráfaga puede estar disponible durante un período de tiempo prolongado. Sin embargo, una vez utilizada la capacidad de ráfaga, un valor elevado y constante de IOPS de lectura y escritura degrada el rendimiento de la instancia. Esta degradación se puede ver en el aumento de los valores de WriteLatency o ReadLatency. Lo ideal es que el almacenamiento gp2 sea adecuado para una latencia de milisegundos de un solo dígito, pero el uso excesivo de IOPS puede provocar una latencia de más de 10 ms.

En las siguientes imágenes se muestran valores de latencia de escritura elevados mientras que el nivel de WriteIOPS consume de forma constante una capacidad de referencia de 300 IOPS en una instancia de base de datos de Amazon RDS. En este ejemplo, la instancia de PostgreSQL en Amazon RDS está alojada en una instancia t2.small con un volumen gp2 de 100 GiB.

La imagen de arriba muestra los IOPS de escritura que consumen 300 IOPS de manera constante, que es el rendimiento básico del volumen.

La imagen de arriba muestra un aumento de la latencia de escritura de hasta 25 milisegundos debido al uso excesivo de IOPS

Como práctica recomendada, asegúrese de que su carga de trabajo no supere la capacidad de IOPS de la instancia. Algunas de las formas de reducir los valores de ReadIOPS (IOPS de lectura) son las siguientes:

• Utilice una réplica de lectura de Amazon RDS.
• Utilice más Memoria RAM.

Utilizando una réplica de lectura de Amazon RDS

Las instancias de base de datos de Amazon RDS para MySQL, MariaDB, Oracle, SQL Server, y PostgreSQL ofrecen réplicas de lectura de RDS. Estas instancias son instancias de base de datos independientes que se sincronizan con la instancia de base de datos de origen mediante la reproducción de los registros transaccionales de la base de datos. Cualquier modificación de datos en la instancia de base de datos de origen se aplica a la réplica de lectura. Con una réplica de lectura, se reduce la carga en la instancia de base de datos de origen al enrutar las sentencias SQL de lectura desde sus aplicaciones a la réplica de lectura. Al mismo tiempo se está liberando capacidad de IOPS para realizar actividades de escritura adicionales en la instancia de base de datos de origen.

Con las réplicas de lectura es importante monitorear el retraso de la replicación (replication lag). Por lo general, un retraso de replicación (replication lag) elevado se debe a una actividad de escritura elevada en la instancia de base de datos de origen.

En las instancias de base de datos de Amazon RDS puede supervisar el retraso de la réplica mediante la métrica ReplicaLag de CloudWatch. Si detecta un retraso de réplica elevado, también debe supervisar la actividad de escritura en la instancia de base de datos de origen. Esto se puede lograr mediante la supervisión de las métricas WriteIOPS y WriteThroughput de CloudWatch. Si la instancia de base de datos de origen presenta deficiencias de IOPS (es decir, la carga de trabajo de escritura y lectura utiliza toda la capacidad de IOPS), la réplica también seguirá retrasándose.

Una de las razones que explican el retraso de las réplicas es que, en la mayoría de los motores de base de datos, la aplicación de cambios en réplicas de lectura implica procesos single-threaded. Esto significa que cuanto mayor sea la carga en una instancia maestra, la aplicación de cambios en las réplicas de lectura será exponencialmente más lenta. Cualquier actividad adicional de escritura intensa en la instancia de base de datos de origen aumenta exponencialmente el retraso de la réplica de lectura. Además de las métricas de CloudWatch, con ReplicaLag también puede supervisar el retraso mediante consultas SQL.

En PostgreSQL, el retraso en la réplica de lectura puede ser calculado con la siguiente consulta:

postgres=> select client_addr, state, sent_lsn, write_lsn,
postgres->     flush_lsn, replay_lsn from pg_stat_replication;
 client_addr |   state   |  sent_lsn  | write_lsn  | flush_lsn  | replay_lsn
-------------+-----------+------------+------------+------------+------------
 10.3.1.167  | streaming | 0/510008D0 | 0/510008D0 | 0/510008D0 | 0/510008D0
(1 row)

En MySQL, puede chequear el estatus de la replicación con el siguiente comando:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: localhost
                  Master_User: repl
                  Master_Port: 13040
                Connect_Retry: 60
              Master_Log_File: master-bin.000004
          Read_Master_Log_Pos: 1447
               Relay_Log_File: slave-relay-bin.000004
                Relay_Log_Pos: 1208
        Relay_Master_Log_File: master-bin.000077
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
… … …

Con una réplica de lectura de Amazon RDS, configure el cliente de forma que un determinado nivel de latencia o error de replicación detectado en una réplica provoque que se intente conectar con otra réplica utilizando un endpoint diferente para establecer conectividad.

Una buena forma de garantizar que su aplicación pueda encontrar la réplica más saludable es llamar a las métricas de CloudWatch para encontrar los valores actuales de ReplicaLag y de latencia de lectura/escritura. El retraso en la replicación se puede encontrar con comandos SQL, como se muestra en los ejemplos anteriores. También puede encontrar el estado actual de la réplica llamando al comando describe-db-instances en la Interfaz de línea de comandos de AWS (AWS CLI). Si el estado actual de la réplica es distinto a «replicating», el cliente debería intentar conectarse a otra réplica.

Además del beneficio de distribuir las transacciones de lectura, las réplicas de lectura también se pueden utilizar para particionar horizontalmente los datos (sharding). Siguiendo la arquitectura de «no compartir nada», puede crear réplicas de lectura correspondientes a cada una de sus particiones horizontales (shards) y promoverlas cuando decida convertirlas en particiones horizontales independientes.

Utilizando Más Memoria RAM

Las instancias de base de datos de Amazon RDS deben tener suficiente RAM para que todo el conjunto de datos de trabajo (working data set) de la base de datos resida en memoria. Como las consultas de lectura pueden leer datos de la memoria, reducen la comunicación con los volúmenes de almacenamiento. En consecuencia, se reduce el uso de la capacidad de ReadIOPS que se puede utilizar para operaciones de escritura.

No existe una forma sencilla de encontrar el tamaño del conjunto de datos de trabajo (working data set) para una base de datos. Observe las consultas de lectura y averigüe cuántos datos están siendo leídos. Por ejemplo, si el tamaño de una base de datos es de 100 GiB y el conjunto de datos de trabajo (working data set) es de 20 GiB, debe utilizar una instancia de base de datos de Amazon RDS con al menos 20 GiB de memoria. Esto le permite tener todo el conjunto de datos de trabajo en memoria.

Opciones de configuración de RAID para bases de datos alojadas en instancias EC2

Los volúmenes EBS son volúmenes de almacenamiento a nivel de bloque que proporcionan almacenamiento en bloques persistente. Estos volúmenes son volúmenes de almacenamiento de alta disponibilidad y se pueden adjuntar a una instancia EC2 en la misma zona de disponibilidad. Los volúmenes EBS son ideales para bases de datos alojadas en instancias EC2. No se recomienda utilizar el almacenamiento efímero de instancias de EC2 para una base de datos.

Al usar los volúmenes de almacenamiento EBS con las instancias EC2, puede configurar volúmenes con cualquier nivel de RAID. Por ejemplo, para obtener un mayor rendimiento de E/S (I/O), puede optar por RAID 0, que permite agrupar varios volúmenes acumulando capacidad y IOPS. El RAID 1 se puede usar para la redundancia de datos porque replica los bloques de datos entre los dos volúmenes asociados.

Independientemente de la configuración de RAID, los datos del volumen EBS se replican en servidores secundarios para evitar cualquier pérdida de datos. No se recomiendan RAID 5 y RAID 6 en bases de datos alojadas en instancias EC2 porque el rendimiento de E/S (I/O) no es tan bueno como el de RAID 0 o RAID 1.

La siguiente tabla muestra las ventajas y desventajas de usar estas dos configuraciones diferentes de RAID y sugiere posibles casos de uso.

Modificaciones a nivel de la aplicación para un rendimiento óptimo

Si una instancia de base de datos tiene problemas de almacenamiento y tiene problemas como un tiempo de confirmación (commit) elevado y latencias elevadas, a veces cambios en la aplicación pueden mitigar esta degradación. Puede modificar las aplicaciones para permitir el retraso exponencial o una lógica de reintentos.

El retraso exponencial permite que las aplicaciones esperen cada vez más tiempo entre reintentos para obtener respuestas de error consecutivas. Si bien algunos algoritmos utilizan un retraso incremental, la mayoría de los algoritmos de retraso exponencial utilizan un retraso aleatorio. Estos son algunos ejemplos de los algoritmos mencionados anteriormente:

Demora aleatoria:

1. Aplicación inicia solicitud.
2. Si la solicitud falla, espera rand(1,000, 3,000) milisegundos y reintenta la solicitud.
3. Si la solicitud falla, espera rand(1,000, 3,000) milisegundos y reintenta la solicitud de nuevo.
4. Si la solicitud falla, espera rand(1,000, 3,000) milisegundos y reintenta la solicitud de nuevo.

Demora incremental:

1. Aplicación inicia solicitud.
2. Si la solicitud falla, Espera 1 = 1,000 milisegundos y reintenta la solicitud de nuevo.
3. Si la solicitud falla, Espera 2 = Espera 1 + 1,000 milisegundos y reintenta la solicitud de nuevo.
4. Si la solicitud falla, Espera 3 = Espera 2 + 1,000 milisegundos y reintenta la solicitud de nuevo.

Utilice ciertas prácticas recomendadas para lograr un failover más rápido en las instancias Multi-AZ de Amazon RDS y en los clústeres de Aurora. Habilite los parámetros “keepalive” de TCP y configúrelos de forma agresiva para garantizar que, si su cliente ya no puede conectarse a la instancia de base de datos, las conexiones activas se cierren rápidamente. Esta modificación también permite que las aplicaciones reaccionen más rápidamente al failover y se conecten rápidamente al nuevo endpoint.

También puede reducir el tiempo de espera del caché de DNS en el cliente. Las conexiones de lectura y escritura se establecen rápidamente en los endpoints adecuados. Adicionalmente, se pueden modificar algunos de los parámetros de configuración de TCP del servidor. Estos cambios ayudan a acelerar el tiempo de failover. Por ejemplo, en PostgreSQL, esto se puede controlar mediante los parámetros tcp_keepalives_count, tcp_keepalives_idle y tcp_keepalives_interval.

Resolviendo problemas de rendimiento del almacenamiento con CloudWatch

La supervisión periódica del estado del almacenamiento de instancias permite identificar la aparición temprana de un problema de rendimiento antes de que tenga un efecto grave en el desempeño de la base de datos. A continuación, se enumeran algunas de las métricas de CloudWatch relacionadas con el almacenamiento que se deberían supervisar con regularidad.

Operaciones de Escritura

• WriteIOPS: Esta métrica de CloudWatch mide el número promedio de operaciones de escritura en disco por segundo. Céntrese en esta métrica si la instancia de su base de datos está configurada con una configuración Multi-AZ. Con Multi-AZ, se crea una instancia secundaria en otra zona de disponibilidad con la misma configuración de instancias que el volumen de almacenamiento EBS asociado al servidor principal. Este almacenamiento se sincroniza de forma síncrona con el almacenamiento de instancias principal. Para garantizar la redundancia de datos, los datos de cada volumen EBS principal se copian a otro volumen EBS secundario ubicado en la misma zona de disponibilidad. Esto significa que una transacción de escritura tiene que confirmarse en cuatro puntos antes de enviar un acuse de recibo al cliente. Una actividad de escritura masiva por encima de la capacidad de throughput y IOPS de las instancias empeora el rendimiento general.
• WriteThroughput: Esta métrica de CloudWatch representa la cantidad promedio de bytes escritos en disco por segundo. Superar la capacidad de throughput de la instancia o el límite de throughput del almacenamiento perjudica al rendimiento de la instancia. Sugiero supervisar la actividad de escritura y distribuir la carga de trabajo de escritura con un retraso adecuado para optimizar el rendimiento.
• WriteLatency: Esta es la cantidad promedio de tiempo empleado por operación de escritura de disco. La mayoría de las veces, los aumentos en WriteLatency se deben al uso excesivo de los recursos de la instancia, como CPU, IOPS, y throughput.

Operaciones de Lectura

• ReadIOPS: Esta métrica de CloudWatch mide el número promedio de operaciones de lectura de disco por segundo. El aumento del valor de ReadIOPS indica que la carga de trabajo de lectura es elevada o que la instancia requiere más memoria libre.
• ReadThroughput: Esta métrica representa el número promedio de bytes leídos del disco por segundo. Superar los límites de la instancia EC2 y del volumen EBS puede aumentar la latencia.
• ReadLatency: Esta es la cantidad promedio de tiempo empleado por operación de lectura de disco. Si tiene un valor elevado para esta métrica, observe la carga de trabajo de lectura y asegúrese de que no está haciendo un uso excesivo de los recursos de la instancia.

Otras Métricas

Además de las métricas mencionadas anteriormente, también debe supervisar las siguientes métricas de CloudWatch:

• DiskQueueDepth: representa el número de solicitudes de E/S (solicitudes de lectura/escritura) pendientes que esperan acceder al disco. Por lo general, un número elevado es el resultado de una gran carga de trabajo.
• FreeStorageSpace: determina la cantidad de espacio de almacenamiento disponible. Como práctica recomendada, debería configurar alertas de CloudWatch para recibir notificaciones vía SNS en cuanto el almacenamiento libre de la instancia esté por debajo de un valor límite, por ejemplo, el 15%.

Desempeño Operacional de Amazon RDS vs. Aurora

Como se mencionó anteriormente, las instancias de base de datos de Amazon RDS y las instancias EC2 dependen de los IOPS disponibles en los volúmenes de almacenamiento. Los tipos de almacenamiento gp2 e io1 tienen sus propios límites de IOPS.

Si su carga de trabajo requiere un mayor rendimiento de almacenamiento en términos de IOPS y throughput, puede planear migrar a Aurora, que es una solución de bajo costo, de alta disponibilidad y rendimiento, adecuada para cargas de trabajo exigentes en términos de almacenamiento. Actualmente, Aurora ofrece dos configuraciones compatibles con MySQL y PostgreSQL.

Al usar Aurora, asegúrese de que aunque técnicamente no hay ningún límite de IOPS, el throughput podría limitarse debido al límite en términos de throughput que tienen las instancias de Aurora subyacentes. Para obtener un mejor rendimiento, opte por un tipo de instancia de Aurora superior.

Aurora es ideal para aplicaciones que necesitan poca o ninguna latencia para cualquier nivel de requerimientos en IOPS. Está diseñado para gestionar una alta velocidad de datos y ofrecer un throughput superior en comparación con los motores MySQL y PostgreSQL tradicionales. Al ser una base de datos relacional tradicional (“row-store”), es ideal para cargas de trabajo OLTP de gran volumen y alta concurrencia.

Otro caso de uso de Aurora es el procesamiento analítico de transacciones híbridas (HTAP). Aurora soporta hasta 15 réplicas. Cada una de estas réplicas se actualiza entre 15 y 20 milisegundos después de la instancia de escritura. Con la función Amazon Aurora Parallel Query añadida recientemente, el procesamiento de consultas se envía al almacenamiento de Aurora. La consulta utiliza potencialmente miles de nodos de almacenamiento en un clúster de Aurora para procesar, refinar y agregar datos antes de enviarlos al nodo de procesamiento.

Conclusión

En esta publicación, aprendió sobre las prácticas recomendadas de almacenamiento para ejecutar una carga de trabajo de producción en una instancia de base de datos de Amazon RDS y en bases de datos alojadas en instancias EC2. Estas prácticas incluían lo siguiente:

• Asignar cargas de trabajo de lectura a réplicas de lectura.
• Comprender la capacidad de IOPS y su dependencia del tamaño y tipo de almacenamiento.
• Cambiar la arquitectura de la aplicación.
• Examinar opciones de configuración de RAID.
• Monitorear métricas de CloudWatch.

También aprendió sobre Aurora y cómo su almacenamiento propietario tiene un rendimiento diferente al de los volúmenes EBS. Todo este conocimiento le ayuda a ejecutar una carga de trabajo de producción sin problemas en las bases de datos de AWS. También puede ver los detalles de cómo Aurora gestiona la velocidad y la disponibilidad de la base de datos mediante la capa de almacenamiento en esta entrada de blog sobre bases de datos: Presentamos el motor de almacenamiento Aurora.

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

About the Author

Vivek Singh es un Especialista de Bases de Datos Senior en Amazon Web Services enfocado en RDS/Aurora PostgreSQL. Él trabaja con clientes corporativos proveyendo asistencia técnica con PostgreSQL.

Traductor

Camilo Leon es un Arquitecto de Soluciones Principal especializado en bases de datos en Amazon Web Services radicado en San Francisco. Camilo Trabaja con clientes de AWS para proporcionar orientación y asistencia técnica en servicios de bases de datos relacionales, ayudándoles a mejorar el valor de sus soluciones cuando utilizan AWS.