Gestión de cargas de trabajo de producción en bases de datos alojadas

Proporcionado por Servicios web de Amazon

AWS ofrece múltiples opciones para alojar sus bases de datos que atienden cargas de trabajo OLTP: aloje su propia base de datos administrada en Amazonas EC2 instancias o uso RDS de Amazon administrado por AWS. RDS administra la alta disponibilidad, las copias de seguridad automatizadas, las actualizaciones de la base de datos, los parches del sistema operativo, la seguridad y la réplica de lectura. RDS también ofrece la opción nativa de la nube Amazonas-Aurora motor de base de datos, que es compatible con MySQL y PostgreSQL. Aurora ofrece un mayor rendimiento en comparación con las bases de datos MySQL y PostgreSQL estándar.

Mientras ejecutaba cargas de trabajo de producción en bases de datos alojadas con Amazon RDS o Amazon EC2, es posible que haya encontrado las siguientes preguntas:

• ¿Cuáles son las mejores opciones de tipo de almacenamiento de base 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 para un rendimiento óptimo?
• Cómo solucionar problemas de rendimiento de almacenamiento mediante Amazon CloudWatch ?
• ¿Rendimiento operativo de Amazon RDS frente a Aurora?

En esta publicación, proporciono las mejores prácticas de almacenamiento para ejecutar 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 ensayo, las cargas de trabajo de producción requieren un rendimiento de E/S rápido y uniforme. Si bien las bases de datos relacionales se pueden usar para múltiples 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 y Aurora utilizan diferentes tipos de técnicas de almacenamiento, como se muestra a continuación:

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

Las mejores opciones de tipo de almacenamiento de base de datos

Amazon RDS proporciona tres tipos de almacenamiento :

• SSD de uso general (también conocido como Volúmenes gp2 )
• SSD de IOPS provisionadas (también conocido como io1 )
• Magnético

La capacidad de E/S de la instancia se basa en el tipo y tamaño de almacenamiento de la instancia. Si la instancia de base de datos está configurada con un volumen gp2, la capacidad de IOPS de referencia es 3 veces el almacenamiento de GiB. Si la instancia de base de datos ha asignado un volumen gp2 de 100 GiB, la capacidad de IOPS de referencia es 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 brindan una capacidad de ráfaga de hasta 3000 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 20 GiB–32 TiB, pero la IOPS de referencia máxima está limitada de 100 a 16 000 IOPS. Por lo tanto, un volumen gp2 de 5,34 TiB o más ofrece la misma línea de base: 16 000 IOPS.

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

Si encuentra que el patrón de uso de IOPS supera consistentemente más de 16,000, debe modificar la base de datos instancia y cambie 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 OLTP que requiera un rendimiento de E/S constante y baja latencia.

El tipo de almacenamiento magnético no se recomienda para cargas de trabajo de E/S intensivas porque el almacenamiento máximo es menor que el de gp2 o io1. La capacidad de IOPS también está limitada a un máximo de 1000 IOPS.

Problemas de rendimiento del almacenamiento

El uso del almacenamiento gp2 es ideal para una amplia variedad de cargas de trabajo de bases de datos. Para este tipo de almacenamiento, diseñe las cargas de trabajo de lectura y escritura de la base de datos de tal manera que la suma de LeerIOPS y EscribirIOPS valores 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, después de usar la capacidad de ráfaga, un valor alto constante de IOPS de lectura y escritura degrada el rendimiento de la instancia. Esta degradación se puede ver por el aumento WriteLatency o Latencia de lectura valores. Idealmente, el almacenamiento gp2 es bueno para una latencia de milisegundos de un solo dígito, pero el uso excesivo de IOPS puede causar una latencia de >10 ms.

Las siguientes imágenes muestran un aumento WriteLatency valores como WriteIOPS consume constantemente una capacidad de referencia de 300 IOPS en una instancia de base de datos de Amazon RDS. En este ejemplo, la instancia PostgreSQL de Amazon RDS está alojada en una instancia t2.small con un volumen gp2 de 100 GiB.

La imagen de arriba muestra que Write IOPS consume 300 IOPS de manera constante, que es el rendimiento de referencia.

La imagen de arriba muestra una 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 LeerIOPS los valores son para:

• Utilice una réplica de lectura de Amazon RDS.
• Usa una memoria RAM más alta.

Uso de una réplica de lectura de Amazon RDS

Oferta de instancias de base de datos de Amazon RDS para MySQL, MariaDB, Oracle y PostgreSQL RDS leer réplicas . Estas instancias son instancias de base de datos separadas sincronizadas con la instancia de base de datos de origen mediante la reproducción de registros transaccionales de la base de datos. Cualquier modificación de datos en la instancia de base de datos de origen se aplica en la réplica de lectura. Con una réplica de lectura, está reduciendo la carga en su instancia de base de datos de origen al enrutar consultas de lectura desde sus aplicaciones a la réplica de lectura. También está liberando capacidad de IOPS para actividad de escritura adicional en la instancia de base de datos de origen.

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

En las instancias de base de datos de Amazon RDS, puede monitorear el retraso de la réplica mediante la métrica de CloudWatch ReplicaLag . Si encuentra un retraso de réplica alto, también debe monitorear la actividad de escritura en la instancia de base de datos de origen. Esto se puede lograr monitoreando las métricas de CloudWatch EscribirIOPS y Rendimiento de escritura . Si la instancia de base de datos de origen es deficiente en IOPS (es decir, la carga de trabajo de escritura y lectura utiliza toda la capacidad de IOPS), la réplica también sigue retrasada.

Una de las razones detrás de las réplicas retrasadas es que en la mayoría de los motores de base de datos, la recuperación de réplicas de lectura implica procesos de un solo hilo. Eso significa que cuanto mayor sea la carga en una instancia maestra, la recuperación será exponencialmente más lenta en las réplicas de lectura. Cualquier actividad de escritura alta adicional en la instancia de base de datos de origen aumenta exponencialmente el retraso de la réplica de lectura. Aparte de las métricas de CloudWatch, con ReplicaLag también puede monitorear el retraso mediante consultas SQL.

En PostgreSQL, el retraso de la réplica de lectura se puede calcular mediante la siguiente consulta:

|_+_|

En MySQL, puede verificar el estado de la replicación con el siguiente comando:

|_+_|

Con una réplica de lectura de Amazon RDS, configure el cliente de tal manera que un cierto nivel de latencia o error de replicación encontrado en una réplica desencadene la prueba de conexión con otro punto de enlace de réplica.

Una buena manera de asegurarse de 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 latencia de lectura/escritura. El retraso de la replicación se puede encontrar con los comandos SQL, como se muestra en los ejemplos anteriores. También puede encontrar el estado actual de la réplica llamando al Interfaz de línea de comandos de AWS (AWS CLI) comando describe-db-instances. Si el estado actual de la réplica no es replicar, el cliente debe intentar conectarse a otra réplica.

Además del beneficio de distribuir transacciones de lectura, las réplicas de lectura también se pueden usar para fragmentar sus datos. Siguiendo la arquitectura de fragmentos sin compartir nada, puede crear réplicas de lectura correspondientes a cada uno de sus fragmentos y promocionarlos cuando decida convertirlos en fragmentos independientes.

Uso de RAM más alta

Las instancias de base de datos de Amazon RDS deben tener suficiente RAM para que su conjunto de trabajo completo resida en la memoria. Como las consultas de lectura pueden leer datos de la memoria, reduce la comunicación con los volúmenes de almacenamiento. Como tal, reduce el uso de LeerIOPS capacidad que se puede utilizar para fines de escritura.

No existe una forma sencilla de encontrar el tamaño de un conjunto de datos de trabajo. Mire las consultas de lectura y descubra cuántos datos están siendo afectados. Por ejemplo, si el tamaño de una base de datos es de 100 GiB y el conjunto de trabajo es de 20 GiB, debe utilizar un Instancia de base de datos de Amazon RDS con al menos 20 GiB de memoria. Eso le permite tener el conjunto de trabajo completo en la memoria.

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

Los volúmenes de EBS son volúmenes de almacenamiento a nivel de bloque que proporcionan almacenamiento de bloque 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 de EBS son ideales para bases de datos alojadas en instancias EC2. No se recomienda el uso de almacenamiento efímero de instancia EC2 para una base de datos.

Al utilizar volúmenes de almacenamiento de EBS con instancias EC2, puede configurar volúmenes con cualquier nivel de RAID. Por ejemplo, para un mayor rendimiento de E/S, puede optar por RAID 0, que puede unir varios volúmenes en bandas. RAID 1 se puede utilizar para la redundancia de datos porque refleja dos volúmenes juntos.

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

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

Configuración	Ventajas	Desventajas	caso de uso
RAID 0	Rendimiento de E/S superior en comparación con la tolerancia a fallas	La pérdida de un solo volumen provoca la pérdida completa de datos	Si la base de datos requiere un mayor rendimiento en comparación con la disponibilidad de datos y los datos son reproducibles
RAID 1	La tolerancia a fallas es superior en comparación con el rendimiento de E/S	Bajo rendimiento de escritura	Si los datos son críticos y la tolerancia a errores de la base de datos es más importante que el rendimiento de E/S

Modificaciones de la aplicación para un rendimiento óptimo

Si una instancia de base de datos se enfrenta a problemas de almacenamiento y tiene problemas como un tiempo de compromiso elevado y latencias elevadas, a veces los cambios en la aplicación pueden mitigar esta degradación. Puede modificar las aplicaciones para habilitar el retroceso exponencial o los reintentos de error.

El retroceso exponencial permite que las aplicaciones esperen progresivamente más entre reintentos para respuestas de error consecutivas. Mientras que algunos algoritmos usan un retraso incremental, la mayoría de los algoritmos de retroceso exponencial usan un retraso aleatorio. Aquí hay ejemplos para un algoritmo diferente:

Retraso aleatorio:

1. La aplicación inicia la solicitud.
2. Si la solicitud falla, espere rand(1000,3000) milisegundos e inicie la solicitud nuevamente.
3. Si la solicitud falla, espere rand(1000,3000) milisegundos e inicie la solicitud nuevamente.
4. Si la solicitud falla, espere rand(1000,3000) milisegundos e inicie la solicitud nuevamente.

Retraso incremental:

1. La aplicación inicia la solicitud.
2. Si la solicitud falla, espere 1 = 1000 milisegundos e inicie la solicitud nuevamente.
3. Si la solicitud falla, espere 2 = espere 1 + 1000 milisegundos e inicie la solicitud nuevamente.
4. Si la solicitud falla, espere 3 = espere 2 + 1000 milisegundos e inicie la solicitud nuevamente.

Utilice determinadas prácticas recomendadas para lograr una conmutación por error más rápida en instancias de Amazon RDS Multi-AZ y clústeres de Aurora. Habilite los parámetros keepalive de TCP y configúrelos agresivamente para asegurarse de que si su cliente ya no puede conectarse a la instancia de base de datos, todas las conexiones activas se cierren rápidamente. Esta modificación también permite que las aplicaciones reaccionen más rápido a la conmutación por error y se conecten rápidamente al nuevo punto final.

También puede reducir el tiempo de espera de almacenamiento en caché de DNS en el cliente. Las conexiones de lectura y escritura se establecen rápidamente en los puntos finales apropiados. Algunos de los parámetros de configuración de TCP del servidor también se pueden modificar. Estos cambios ayudan a una conmutación por error más rápida. Por ejemplo, en PostgreSQL, esto puede controlarse mediante tcp_keepalives_count, tcp_keepalives_idle y tcp_keepalives_interval. parámetros .

Solución de problemas de rendimiento del almacenamiento con CloudWatch

Supervisar el estado del almacenamiento de instancias de forma regular identifica la aparición temprana de un problema de rendimiento antes de que tenga un efecto grave en el rendimiento de la base de datos. Algunas de las métricas relacionadas con el almacenamiento de CloudWatch que debe monitorear regularmente se enumeran aquí.

operaciones de escritura

• EscribirIOPS: Medida a una tasa de recuentos por segundo, esta métrica de CloudWatch determina la cantidad promedio de operaciones de E/S de escritura en disco por segundo. Concéntrese en esta métrica si su instancia de 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 instancia que el volumen de almacenamiento de EBS maestro y adjunto. Este almacenamiento se sincroniza sincrónicamente con el almacenamiento de la instancia principal. Para la redundancia de datos, de forma predeterminada, los datos de cada volumen de EBS se copian en otro volumen de EBS secundario ubicado en la misma zona de disponibilidad. Esto significa que una transacción de escritura debe confirmarse en cuatro lugares antes de enviar un acuse de recibo al cliente. La actividad de escritura masiva por encima de las IOPS de las instancias y la capacidad de rendimiento empeoran el rendimiento general.
• Rendimiento de escritura: Esta métrica de CloudWatch representa la cantidad promedio de bytes escritos en el disco por segundo. Superar el rendimiento de la instancia o el límite de rendimiento del almacenamiento perjudica el rendimiento de la instancia. Sugiero monitorear la actividad de escritura y distribuir la carga de trabajo de escritura con un retraso adecuado para optimizar el rendimiento.
• Latencia de escritura: Esta es la cantidad promedio de tiempo que toma cada operación de E/S de disco. la mayor parte del tiempo WriteLatency los aumentos se deben al uso excesivo de los recursos de la instancia, como CPU, IOPS y rendimiento.

Operaciones de lectura

• Lectura de IOPS: Medida a una tasa de recuentos por segundo, esta métrica de CloudWatch determina la cantidad promedio de operaciones de E/S de lectura de disco por segundo. El mayor valor de LeerIOPS sugiere que la carga de trabajo de lectura es alta o que la instancia requiere más memoria libre.
• Rendimiento de lectura: Esta métrica representa la cantidad promedio de bytes leídos del disco por segundo. Superar los límites de la instancia y de EBS puede aumentar la latencia.
• Latencia de lectura: Esta es la cantidad promedio de tiempo que toma cada operación de E/S de disco. Si tiene un valor alto para esta métrica, mire la carga de trabajo de lectura y asegúrese de que no esté abusando de los recursos de la instancia.

Otras métricas

Junto con las métricas mencionadas anteriormente, también debe monitorear las siguientes métricas de CloudWatch:

• Profundidad de cola de disco representa el número de E/S pendientes (solicitudes de lectura/escritura) que esperan acceder al disco. Por lo general, esto es el resultado de una gran carga de trabajo.
• Espacio de almacenamiento gratuito determina la cantidad de espacio de almacenamiento disponible. Como práctica recomendada, debe establecer Alertas de CloudWatch para que pueda recibir notificaciones de SNS tan pronto como el almacenamiento gratuito de la instancia esté por debajo de un valor de umbral, como el 15 %.

Rendimiento operativo de Amazon RDS frente a Aurora

Como se mencionó anteriormente, las instancias de base de datos de Amazon RDS y las instancias EC2 tienen una dependencia de IOPS 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 IOPS y un mayor rendimiento, puede planear migrar a Aurora, que es una solución rentable, de alto rendimiento y de alta disponibilidad adecuada para cargas de trabajo de alto rendimiento. Actualmente, Aurora ofrece motores compatibles con MySQL y PostgreSQL.

Al usar Aurora, asegúrese de que técnicamente no haya límite de IOPS, pero el rendimiento podría estar limitado al subyacente instancia de aurora límite. Para un mejor rendimiento, opte por una clase de instancia de Aurora más alta.

Aurora es más adecuada para aplicaciones que requieren poca o ninguna latencia para cualquier IOPS determinado. Está diseñado para manejar una alta velocidad de datos proporcionando un mayor rendimiento en comparación con los motores tradicionales de MySQL y PostgreSQL. Al ser una base de datos de almacenamiento en fila, es ideal para cargas de trabajo OLTP de alto volumen y alta concurrencia.

Otro caso de uso de Aurora es el procesamiento analítico de transacciones híbridas (HTAP). Aurora admite hasta 15 réplicas. Cada una de estas réplicas se ejecuta entre 15 y 20 milisegundos desde la instancia de escritura. Con el agregado recientemente Función de consulta paralela de Amazon Aurora , el procesamiento de consultas se transfiere más tarde 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 cómputo.

Conclusión

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

• Asignación de cargas de trabajo de lectura a una réplica de lectura.
• Comprensión de la capacidad de IOPS y su dependencia del tamaño y tipo de almacenamiento.
• Cambiar la arquitectura de la aplicación.
• Examen de las opciones de RAID.
• Monitoreo de métricas de CloudWatch.

También aprendió sobre Aurora y cómo su almacenamiento patentado funciona de manera diferente a los volúmenes de EBS. Todo este conocimiento lo ayuda a ejecutar una carga de trabajo de producción sin problemas y sin problemas en las bases de datos de AWS. También puede ver los detalles de cómo Aurora maneja la velocidad y la disponibilidad de la base de datos usando la capa de almacenamiento en esta publicación del blog de la base de datos: Presentamos el motor de almacenamiento de Aurora.

esconder