AWS RDS aprovisionó IOPS realmente vale la pena?


Según lo entiendo, las IOPS aprovisionadas de RDS son bastante caras en comparación con la tasa de E/S estándar.

En la región de Tokio, la tasa de P-IOPS es 0.15 GB/GB, 0.12./IOP para el despliegue estándar. (El doble del precio para el despliegue Multi-AZ...)

Para P-IOPS, el almacenamiento mínimo requerido es 100GB, IOP es 1000. Por lo tanto, el costo inicial para P-IOPS es de 135 excluding excluyendo el precio de la instancia.

Para mi caso, usar P-IOPS cuesta aproximadamente 100 veces más que usar la tasa de E/S estándar.

Esto puede ser una pregunta muy subjetiva, pero por favor dé alguna opinión.

En la base de datos más optimizada para RDS P-IOPS, ¿el rendimiento valdría el precio?

O

El sitio de AWS ofrece algunas ideas sobre cómo P-IOPS puede beneficiar el rendimiento. ¿Hay algún punto de referencia real?

RESPUESTA PROPIA

Además de la respuesta que escribió zeroSkillz, investigué un poco más. Sin embargo, tenga en cuenta que no soy un experto en la lectura de puntos de referencia de bases de datos. Además, el punto de referencia y la respuesta se basaron en EBS.

De acuerdo con un artículo escrito por "Rodrigo Campos", el rendimiento en realidad mejora significativamente.

De 1000 IOPS a 2000 IOPS, el rendimiento de lectura/escritura(incluida la lectura/escritura aleatoria) se duplica. Por lo que dijo zeroSkillz, el bloque EBS estándar proporciona alrededor de 100 IOPS. Imagine la mejora en el rendimiento cuando 100 IOPS sube a 1000 IOPS(que es el IOPS mínimo para P-IOPS despliegue).

Conclusión

Según el índice de referencia, el rendimiento/precio parece razonable. Para situaciones críticas de rendimiento, supongo que algunas personas o empresas deben elegir P-IOPS incluso cuando se les cobra 100 veces más.

Sin embargo, si fuera un consultor financiero en una pequeña o mediana empresa, solo escalaría(como en CPU, memoria) en mis instancias de RDS gradualmente hasta que el rendimiento/precio coincida con P-IOPS.

Author: Jee Seok Yoon, 2013-09-13

2 answers

Ok. Esta es una mala pregunta porque no menciona el tamaño del almacenamiento asignado o cualquier otro detalle de la configuración. Usamos RDS y tiene sus ventajas y desventajas. Primero: no puede usar un dispositivo de almacenamiento efímero con RDS. Ni siquiera puede acceder al dispositivo de almacenamiento directamente cuando utiliza el servicio RDS.

Dicho esto, se supone que el medio de almacenamiento para RDS se basa en una variante de EBS de amazon. El rendimiento para IOPS estándar depende del tamaño del volumen y hay muchas fuentes que indican que por encima de 100 GB de almacenamiento que comienzan a" raya " volúmenes EBS. Esto proporciona un mejor acceso promedio a los datos de caso tanto en lectura como escritura.

Actualmente ejecutamos alrededor de 300 GB de asignación de almacenamiento y podemos obtener 2k write IOP y 1k IOP aproximadamente el 85% del tiempo durante un período de tiempo de varias horas. Usamos datadog para registrar esto para que podamos ver realmente. Hemos visto ráfagas de IOPs de escritura de hasta 4k, pero nada sostenido como eso.

El síntoma principal que vemos de una el lado de la aplicación es la contención de bloqueo si el IOPS para la escritura no es suficiente. El número y la frecuencia que obtiene de estos en los registros de su aplicación le dará síntomas para agotar los IOPS de RDS estándar. También puede utilizar un servicio como datadog para supervisar las IOPS.

El problema con las IOPS aprovisionadas es que asumen volúmenes de escritura / lectura en estado estacionario para ser rentables. Este casi nunca es un caso de uso realista y es la razón por la que Amazon comenzó a reparar los servicios en la nube. La única garantía que obtiene con P-IOPS es que obtendrá una capacidad de rendimiento máximo reservada. Si no lo usas, aún pagas por él.

Si está de acuerdo con ejecutar réplicas, recomendamos ejecutar una réplica de solo lectura como una instancia QUE NO SEA RDS y colocarla en una instancia EC2 normal. Puede obtener mejores IOPS de lectura a un precio mucho más barato administrando la réplica usted mismo. Incluso configuramos réplicas fuera de AWS usando stunnel y colocamos unidades SSD como el dispositivo de bloque principal y nos volvemos ridículos velocidades de lectura para nuestros sistemas de informes, literalmente 100 veces más rápidas que las que obtenemos de RDS.

Espero que esto ayude a dar algunos detalles del mundo real. En resumen, en mi opinión, a menos que deba garantizar un cierto nivel de capacidad de rendimiento (o su aplicación fallará) de forma constante (o en cualquier punto dado), hay mejores alternativas a las IOPS aprovisionadas, incluida la división de lectura y escritura con memcache de réplicas de lectura, etc.

 25
Author: Ross,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-03-17 12:36:02

Por lo tanto, acabo de salir de una llamada con un ingeniero de sistemas de Amazon, y tenía algunas ideas interesantes relacionadas con esta pregunta. (IE. este es el conocimiento de la segunda mano.)

Los bloques EBS estándar pueden manejar bien el tráfico explosivo, pero eventualmente se reducirán a aproximadamente 100 iops. Había varias alternativas que este ingeniero sugirió.

  1. Algunos clientes usan múltiples bloques pequeños de EBS y los rayan. Esto mejorará las IOPS y será el más rentable. No necesitas preocuparse por la duplicación porque EBS se refleja detrás de las escenas.

  2. Algunos clientes utilizan el almacenamiento efímero en la instancia EC2. (o instancia RDS) y tienen varios esclavos para "garantizar" la durabilidad. El almacenamiento efímero es almacenamiento local y mucho más rápido que EBS. Incluso puede usar instancias EC2 aprovisionadas con SSD.

  3. Algunos clientes configurarán el maestro para usar IOPS aprovisionadas o almacenamiento efímero SSD, y luego usarán almacenamiento EBS estándar para los esclavos. Previsto el rendimiento es bueno, pero el rendimiento de conmutación por error se degrada (pero sigue disponible)

De todos modos, si decides usar cualquiera de estas estrategias, volvería a verificar con amazon para asegurarme de que no he olvidado ningún paso importante. Como dije antes, este es el conocimiento de la segunda mano.

 29
Author: zeroSkillz,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-10-08 19:30:41