Recientemente un cliente empezó a experimentar lentitud en su aplicación. En parte motivado por el propio diseño de la misma: ausencia de caché tanto en frontend, como backend, base de datos monolítica, carga de trabajo de operativa y analítica en la misma RDS, etc.
El diseño de la RDS master empezó como una m5.xlarge y un volumen de 100 GB GP2. Los volúmenes GP2 dan un rendimiento base estable y predecible (en este caso 300 IOPS de ratio base, 3 IOPS por 100 GB = 300 IOPS) y un rendimiento de ráfaga de hasta 3000 IOPS y recargan su espacio de ráfaga durante los tiempos sin carga o cuando se ejecutan bajos niveles de I/O.
Los créditos de ráfaga (burst credits) se acumulan en un ratio de 3 por cada giga configurado por segundo, donde cada crédito será consumido por escritura o lectura. Cada volumen puede acumular hasta unos 5,4 millones de créditos que pueden ser consumidos hasta a 3.000 por segundo por volumen.
Las métricas necesarias (puede variar) para ver el comportamiento de nuestra RDS serán:
- Write IOPS
- Read IOPS
- Write Latency
- Read Latency
- Burst Balance
Una de las más importantes será la de Burst Balance si nuestro volumen es GP2. Esta métrica se añadió en 2016 y muestra en porcentaje el nivel de créditos y puedes monitorizar si se están vaciando o acumulando. Lo que puede dar una pista de que nuestro volumen GP2 puede necesitar más base de IOPS.
En caso de agotar los créditos, el volumen GP2 perderá la capacidad de utilizar créditos de ráfaga (bursts credits) y se mantendrá en su rendimiento base de 3 IOPS por GB.
En el caso del cliente se observa que no hay cuello de botella por utilización de CPU, MEMORIA LIBRE es correcta, pero hay altos picos de READ IOPS (2,05K) con picos altos de WRITE IOPS (1K). El BURST BALANCE llega a quedarse a 0 en algún momento pero en general se mantiene estable en el 50%, con lo que podemos concluir que no está consumiendo todos sus créditos. Aún así hay periodos de lentitud. Una gráfica que me ha llamado la atención es la relación entre BURST BALANCE Y DEPTH QUEUE DEPTH.
En este caso, el cliente es pequeño y no dispone de recursos con lo que, crear otro almacenamiento de tipo IO1 que es mucho más costoso no parece una solución coste-rendimiento efectiva. Coste aproximado
M5.XLARGE MultiAZ 100 GB GP2 (300 IOPS) = 578$
M5.XLARGE MultiAZ 100 GB IO1 1000 IOPS = 800 $
Se obtiene una diferencia de casi 222 $ lo cual no es, en este caso, una opción eficaz dado el coste. Aumentar a un cliente pequeño la factura unos 200$ de golpe merece una justificación. Y pueden haber otras opciones a estudiar como mover la parte de analítica a una RDS Read Replica M5.LARGE (single AZ) 100 GP2 para lectura (148$) o incluso inferior perfil solo para temas de lectura, reports, analítica, etc.
Links
- https://aws.amazon.com/blogs/database/how-to-use-cloudwatch-metrics-to-decide-between-general-purpose-or-provisioned-iops-for-your-rds-database/
- https://aws.amazon.com/blogs/aws/new-burst-balance-metric-for-ec2s-general-purpose-ssd-gp2-volumes/
- https://medium.com/@tdi/burst-balance-ebs-metric-in-aws-a3f3b90261dd
