Seleccionar página

Desde que llevo trabajando con AWS he visto como trabajar con EBS es un poco peculiar, acostumbrado al uso de los sistemas de almacenamiento tradicionales el uso del servicio de EBS en las instancias AWS ha sido un largo arduo camino de años. Al final después de experiencias de todo tipo como sufrir penalizaciones por BurstCredit en EBS o EFS he ido con mucha cautela, tanto en no superar los límites impuestos por AWS, como para entender las fluctuaciones de rendimiento que sufría con los EBS general purpose.

Aprovechando el estudio del rendimiento de una plataforma me puse manos a la obra a hacer unas pruebas empleando diferentes herramientas, la típica dd y fio con diferentes volúmenes e instancias. La idea era saber cómo se comportaba el rendimiento en diferentes tipos de operaciones. Comento la base de los test que se han realizado.

Partiendo de una instancia t2.medium se hizo pruebas con volúmenes GP2 de 20Gb (100IOPS), GP2 de 500Gb (1500IOPS), GP2 de 1000Gb (3000IOPS) e IO2 20Gb (1000IOPS). La operación que se lanzó para conseguir estas pruebas fueron

# Prueba escritura
fio –name fio_test_file –direct=1 –rw=randwrite –bs=4k –size=1G –numjobs=16 –time_based –runtime=180 –group_reporting
# Prueba de lectura
fio –name fio_test_file –direct=1 –rw=randread –bs=4k –size=1G –numjobs=16 –time_based –runtime=180 –group_reporting

Los resultados fueron los siguientes según los datos de Cloudwatch.

Instancia t2.medium con 20Gb GP2 (100IOPS)

ReadBandwith Kb/s WriteBandwith Kb/s ReadThroughput Op/s WriteThrougput Op/s Queue ReadLantency ms/op WriteLatency ms/op
446,97 7402,1 1727 1752,93 9 5,16 13,76

Instancia t2.medium con 500Gb GP2 (1500IOPS)

ReadBandwith Kb/s WriteBandwith Kb/s ReadThroughput Op/s WriteThrougput Op/s Queue ReadLantency ms/op WriteLatency ms/op
7310,94 62597,97 1827,61 489,04 30,37 5,06 62,11

Instancia t2.medium con 1000Gb GP2 (3000IOPS)

ReadBandwith Kb/s WriteBandwith Kb/s ReadThroughput Op/s WriteThrougput Op/s Queue ReadLantency ms/op WriteLatency ms/op
7011,96 59634,88 1752,99 2096,93 16,76 5,39 58,3

Instancia t2.medium con 20 IO (1000IOPS)

ReadBandwith Kb/s WriteBandwith Kb/s ReadThroughput Op/s WriteThrougput Op/s Queue ReadLantency ms/op WriteLatency ms/op
7121,28 4304,86 1823,23 1020,91 15,87 14,86 69,8

Después de estas pruebas vi que no había tanta diferencia entre el uso de un tipo de volumen GP2 a IO. Esto cumplía con lo que siempre había oído a soporte de AWS, webinars, ponencia en Summits, etc. Hay una clara dependencia entre el tipo de instancia empleada con el uso del servicio de EBS. Así que procedí a realizar los mismos tests con una instancia m4.large con EBS optimized. Los resultado son los siguientes:

Instancia m4.large con 20Gb GP2 (100IOPS)

ReadBandwith Kb/s WriteBandwith Kb/s ReadThroughput Op/s WriteThrougput Op/s Queue ReadLantency ms/op WriteLatency ms/op
7327,65 9503,77 1831,91 1729,65 9,42 5,14 5,28

Instancia m4.large con 500Gb GP2 (1500IOPS)

ReadBandwith Kb/s WriteBandwith Kb/s ReadThroughput Op/s WriteThrougput Op/s Queue ReadLantency ms/op WriteLatency ms/op
6957,01 28842,86 1739,25 1697,6 16,22 5,13 5,74

Instancia m4.large con 1000Gb GP2 (3000IOPS)

ReadBandwith Kb/s WriteBandwith Kb/s ReadThroughput Op/s WriteThrougput Op/s Queue ReadLantency ms/op WriteLatency ms/op
6779,6 19382,12 1694,6 1896,63 10,88 5,25 5,53

Instancia m4.large con 20 Gb IO 1000IOPS

ReadBandwith Kb/s WriteBandwith Kb/s ReadThroughput Op/s WriteThrougput Op/s Queue ReadLantency ms/op WriteLatency ms/op
4087,33 8838,13 1021,83 1027,33 16,19 15,63 15,8

Estos datos no eran muy aclaratorios, sin embargo veía durante las pruebas la volatilidad de la escritura en discos GP2, sin embargo el uso de volúmenes IO ofrecía más estabilidad independientemente del número de peticiones realizadas. Como apunte decir que no superé el Burst Credit en ningún caso. Sin embargo veía que GP2 unas veces me iba como un tiro y otras no. Esto me dejaba atónito. Lo que sí que me quedaba claro era que la instancia m4.large ofrecía mejores tiempos que la t2.medium. Había que lanzar un test que me lo dejara más claro. Por otro lado veía que la latencia en operaciones de escritura mejoraba drásticamente con el uso de volúmenes IO.

Así que lancé el típico comando dd para ver la capacidad de lectura y escritura con un solo hilo para cada caso. Durante las pruebas se midieron mediante iotop los mb/s de escritura y se obtuvieron estos resultados.

Read Write
20 Gb GP2 t2.medium No 100 6,2 Gb/s 86,3 Mb/s
500 Gb GP2 t2.medium No 1500 6,3 Gb/s 86 Mb/s
1000 Gb GP2 t2.medium No 3000 6,4 Gb/s 102 Mb/s
20 Gb IO t2.medium No 1000 6,4 Gb/s 86,2 Mb/s
20 Gb GP2 m4.large Yes 100 5,8 Gb/s 1.7 GB/s
500 Gb GP2 m4.large Yes 1500 5.8 GB/s 1.6 GB/s
1000 Gb GP2 m4.large Yes 3000 5.9 GB/s 1.7 GB/s
20 Gb IO m4.large Yes 1000 5.9 GB/s 1.6 GB/s

Aquí si que dejaba bien claro la diferencia ente instancias y la importancia, no sólo de elegir una buen volumen en el servicio de EBS sino también la instancia. Si tu aplicativo va a realizar operaciones de lectura no habría ningún problema en usar volúmenes GP2, sin embargo para muchas escrituras y constantes es altamente aconsejable usar una instancia EBS optimized y volúmenes IO.