Llegamos a ustedes gracias a:



Reportajes y análisis

El loco mundo del desempeño en la nube

[11/09/2013] Antes de entrar en el mundo de la computación en la nube, hagamos una pausa para recordar los días locos de la década de 1970 cuando la ciencia de la cadena de montaje no era bien entendida, y los consumidores descubrieron que cada compra era una especie de juego de azar. Este fue quizá más notorio en los concesionarios de automóviles, donde la calidad de los autos nuevos era tan aleatoria que los compradores comenzaron a exigir conocer el día en que un automóvil salía de la línea de ensamblaje.
Se decía que los automóviles construidos los lunes eran un riesgo porque todo el mundo venía de la resaca del fin de semana, mientras que los ensamblados los viernes sufrían porque todo el mundo ya estaba pensando en el fin de semana. Los compradores más paranoicos examinaban el calendario para ver si el vehículo salió un día de semana en que un juego de la serie mundial hubiera nublado los cerebros de todos.
Incoherencias como esas han sido olvidadas en gran parte por los compradores de hoy en día, gracias a mejores pruebas, una mayor dedicación a la calidad, y un éxodo general de las fábricas lejos de donde las personas se quedan hasta muy tarde bebiendo o que ven demasiados deportes. En todo caso, las fábricas modernas escupen artículos idénticos con una consistencia que raya con lo aburrido. Cuando las películas modernas muestran una línea de ensamble, a menudo es un mecanismo sin carisma con duplicados perfectos.
Esos recuerdos de la década de 1970 volvieron a mí cuando empecé a ejecutar pruebas de referencia en los equipos de nube. Mientras que las computadoras normalmente se producen tan bien, con una perfección que hace que parezcan clones, empecé a descubrir que la metáfora clon puede no ser la mejor opción para las máquinas disponibles para alquiler en las nubes de computación. Las máquinas de nube no son todas iguales, producidas con precisión como las cajas que están en los pupitres. Son un poco como los automóviles de los años 70.
Comencé a aprender esto después de que varios ingenieros de las empresas de nube se quejaron sobre las pruebas de referencia en mi estudio de las nubes públicas. Las pruebas no fueron lo suficientemente sofisticadas, me dijeron.
Los resultados de mi benchmark a la nube nunca pretendieron ser una respuesta definitiva, solo un informe sobre lo que el usuario puede experimentar al caminar por la puerta virtual. Al igual que Consumer Reports, me inscribí en una máquina, cargué código Java, y escribí los resultados. Ya que el conjunto de benchmark o pruebas de DaCapo tiene ventajas tales como la independencia del procesador (Java) y una amplia colección de populares códigos de servidor (Jython, Tomcat), los resultados se esparcieron. La única solución, concluí, era probar el código que se va a ejecutar, porque esa es la única forma de averiguar qué máquinas de nube ofrecerán el mejor rendimiento para su mezcla particular de I/O, acceso al disco, y computación.
A un ingeniero no le gustó este enfoque. Él comenzó a hacer preguntas directas que eran sorprendentemente complejas. ¿Cuál fue la metodología precisa? ¿Qué sistema operativo se ejecutó en las pruebas? ¿Con qué frecuencia se ejecutaron las pruebas? ¿Las pruebas controlaban la hora del día?
¿La hora del día? Sí, dijo el ingeniero. Realmente quería saber si estábamos prestándole atención a cuándo se ejecutaban las pruebas. Sin duda, los sistemas operativos son una fuente obvia de las diferencias de rendimiento, y el uso de los últimos controladores y parches siempre tiene sentido. Pero él también quería saber la hora del día.
Esto era nuevo. Las CPU tienen relojes que hacen tictac de forma extremadamente rápida, pero van a trabajar la computación en la misma proporción por la mañana, tarde y noche. ¿Era realmente importante saber la hora? Sí, dijo. En otras palabras, las máquinas de nube pueden ser más como una línea de ensamblaje de Detroit de los 70s que un reloj suizo.
Camaros y Corvettes de nube
Para darme cuenta de lo variable que puede ser la nube, encendí instancias en EC2 de Amazon. Elegí Amazon porque es una de las empresas líderes de la industria con una de las nubes más sofisticadas, pero las conclusiones son probablemente iguales para cualquiera de las otras nubes - están todas jugando el mismo juego. Están construyendo un estante de computadoras súper rápidas y a la búsqueda de una forma inteligente de compartirlas con muchos usuarios. A pesar de que la literatura de las ventas hace que parezca que va a comprar otra computadora como la que está en su escritorio, por lo general es más parecido a comprarse un departamento en la playa.
En este punto, debo hacer una pausa y dejar a un lado estas alusiones a Detroit y a los bienes raíces. Un defensor con gracia de la nube diría que a veces se obtiene por lo que se paga, pero a menudo se tiene suerte. En un mal día, podría terminar compartiendo una CPU con 10 que tratan de hacerse ricos o ganarse monedas extra al fusionar el procesador; en un buen día, la CPU le dará muchos ciclos extra de forma gratuita. Podría terminar compartiendo una máquina con 10 abuelas que solo actualizan las páginas web con un nuevo ejemplar del boletín de la iglesia cada domingo. En otras palabras, el vaso de la CPU no solo está medio lleno, sino que el camarero le ofrecerá hasta los últimos restos de la botella.
Los resultados fueron sorprendentes. He comprado dos tipos de máquinas: la instancia Micro T1 de gama baja y la versión media llamada apropiadamente M1. Micro es una máquina de prueba con 613MB de RAM y una promesa de "hasta dos unidades Compute EC2 (para las explosiones periódicas cortas)". Medium viene con 3.75GB de RAM y promete un "núcleo virtual con dos unidades Compute EC2". Micro se cotiza a dos centavos de dólar por hora y Medium cuesta 12 centavos de dólar por hora. Ambos precios están en la lista de la instancia "a la carta" a disposición de cualquiera que ingrese por la puerta. Los precios más bajos están disponibles para aquellos que hacen un compromiso a largo plazo con una reserva.
En ambos casos, empecé con los 64 bits con los que viene precargada la máquina Amazon Linux personalizada de OpenJDK con 1.6.0_24. Después de actualizar todos los paquetes con Yum, descargué los puntos de referencia DaCapo y los ejecuté de inmediato.
Pruebas en instancias Micro
En total, ejecuté los benchmarks o puntos de referencia 36 veces en 10 máquinas diferentes (cinco Micro y cinco Medium). En general, los casos Micro fueron mucho más lentos que los Medium, pero en realidad las máquinas Micro corrieron más rápido varias veces. En general, esto sucedió poco después de que la máquina se iniciara, probablemente porque EC2 estaba permitiendo que la máquina "explote" más rápido y corriera libremente. Esta generosidad por lo general se desvanecía y la siguiente ejecución solía ser dramáticamente más lenta, a veces 10 veces más lenta -sí, 10 veces más lenta.
El rendimiento de las máquinas Micro varió dramáticamente. Hubo un caso que podía indexar archivos con Lucene en tres ejecuciones diferentes de 3.4, 4.0 y 4.1 segundos, era predecible como un reloj. Pero otro caso iniciado en 3.4 segundos, tomó 39 segundos para la segunda carrera y 34 segundos para la tercera. Otra instancia tuvo 14, 47 y 18 segundos para crear el mismo índice de Lucene con el mismo archivo. Los resultados de la máquina Micro estaban por todo el mapa.
En las pruebas DaCapo, el rendimiento de las instancias Micro T1 de Amazon era todo menos coherente. (Descargue un PDF con los resultados Micro T1).
 
Para empeorar las cosas, las instancias Micro a veces no fallaban sino hasta el final. A veces aparecía un error 404 causado por una solicitud fallida a una página web en las simulaciones de los servicios Web (Tradesoap y Tradebeans). A veces los trabajos más grandes terminaban con un mensaje de error de una línea: "muerto". Las muertes, sin embargo, no eran previsibles. No hubo un punto de referencia que bloquee la máquina.
Bueno, hubo un caso en el que pude sentir que la falla era inminente. Una instancia era una máquina chancha definida, y su lentitud era evidente desde el principio. La prueba de Eclipse es uno de los puntos de referencia más exigentes de DaCapo. Las otras máquinas Micro terminaban entre 500 y 600 segundos, pero ésta empezó en más de 900 segundos y se puso peor. En la tercera ejecución, impulsaba 2.476 segundos, casi cinco veces más lenta que sus hermanas.
Esto no era necesariamente sorprendente. Esta máquina se puso en marcha el jueves después del almuerzo en la costa este, probablemente uno de los momentos en los que la mayor parte de América está despierta y navegando por la web. Algunas de las máquinas más rápidas se iniciaron a las 6:30 de la mañana en la costa este.
Si bien normalmente apagaba las máquinas después de finalizadas las pruebas, dejé a esta máquina lenta encendida para jugar un poco. No había nada mejor. Por la tarde, fallaba. Encontraba mensajes que avisaban que la máquina había perdido comunicación, dejando a mi escritorio quejándose de una "tubería rota". Muchas veces, no pudo acabar más que unas cuantas pruebas.
Para sonreír, desplegué las mismas pruebas en la misma máquina un par de días más tarde, el domingo por la mañana en la costa este. La primera prueba salió bien. La máquina se alimentaba con Avrora en 18 segundos, un tiempo comparable a los resultados a menudo reportados por las máquinas Medium. Pero después de ello, se ralentizó considerablemente, tomándole 3.120 segundos para terminar la prueba de Eclipse.
Pruebas en instancias Medium
Las máquinas Medium fueron mucho más consistentes. Ellas nunca dejaron de ejecutar un benchmark o punto de referencia y reportaron tiempos que no variaban tanto. Pero incluso estos números no estaban cerca de un reloj suizo. Una máquina Medium reportó tiempos de 16.7, 16.3 y 17.5 segundos para la prueba Avrora, mientras que otra informó tiempos de 14.9, 14.8, y 14.8. Sin embargo, otro equipo corrió en 13.3 segundos.
Algunas máquinas Medium se desempeñaron 10% más rápido que otras. La velocidad de las máquinas Medium fue consistente en la mayoría de los puntos de referencia y no parecía tan ligada a la hora del día.
El rendimiento de las máquinas Medium también sugiere que la memoria RAM puede ser tan importante como los núcleos de la CPU, pero solo si usted la necesita. Medium tiene aproximadamente seis veces más memoria RAM que Micro, cuesta -y no hay que sorprenderse- seis veces más. Pero en el benchmark o punto de referencia Avrora, la máquina Micro a menudo corrió más rápido o solo un par de veces más lento. En el punto de referencia Tomcat, nunca funcionó más rápido, pero de forma rutinaria terminó entre cuatro y seis veces más lento.
El desempeño en instancias Medium M1 de Amazon fue mucho más consistente. A diferencia de las Micros, las Mediums no dejaban de realizar una prueba de funcionamiento. (Descargue un PDF con los resultados de Medium M1).
 
En otros casos, Micro simplemente se derritió. En la prueba de Eclipse, Micro se desempeñó a alrededor de cinco veces más lento que la media, pero a menudo era de ocho a 10 veces más lento. Una vez en la prueba de Eclipse y varias veces en otras pruebas, Micro fracasó por completo. La falta de memoria RAM hizo que la máquina quede inestable. (Tenga en cuenta que estas fallas no incluyen las decenas de fracasos de limón, que se estrelló mucho más veces que las otras instancias Micro he probado).
Medium M1 dio cifras coherentes en algunas pruebas DaCapo (como Avrora, arriba), pero no tan consistentes en otras (como la prueba de Eclipse, más adelante).
Aunque son básicos, estos experimentos muestran que el rendimiento de envasado en la nube es mucho más complicado que con máquinas independientes. No todas las máquinas se comportarán de la misma manera. El efecto de otros usuarios en el hardware y la red, puede y va a distorsionar cualquier medición.
La Medium M1 dio cifras coherentes sobre algunas pruebas DaCapo (como Avrora, arriba), pero no tan consistentes en otras (como la prueba de Elipse, más adelante).
Entre la espada y la pared
Para empeorar las cosas, las empresas de nube están en una extraña situación. Si tienen ciclos guardados, sería una vergüenza que los desperdicien. Sin embargo, si se las dan, los clientes podrían acostumbrarse a un mejor rendimiento. Nadie se da cuenta cuando las máquinas se ejecutan más rápido, pero todos comienzan a enojarse si las máquinas van más lento.
Tales expectativas hacen que a las empresas les resulte más difícil desplegar el hardware más nuevo. Si aparecen nuevos chips que son 10% más rápidos, los bastidores se ejecutarán 10% más rápido. Todo el mundo será feliz hasta que se queden con una instancia en los bastidores más antiguos.
Los usuarios de la nube tienen que ajustar sus expectativas, o al menos relajar las barras de error en torno a las expectativas. La nube no ofrece un rendimiento con la misma precisión que el hardware dedicado que tiene en su escritorio. No es necesariamente una buena idea exigirlo, porque la única solución de la empresa en la nube para una demanda de precisión es eliminar cualquier tipo explosión conjunta. Ellos tendrían que limitar el rendimiento al denominador común más bajo.
En otras palabras, los años 70 no han sido los mejores años para la consistencia de Detroit, pero aun así produjeron grandes vehículos. El Camaro, Mustang, Trans-Am y Corvette a menudo funcionaron bastante bien. Las líneas de montaje no eran perfectas, pero no daba problemas en la mayor parte del tiempo -hasta que se produjo un limón. Al igual que los propietarios de esos viejos automóviles, los conductores de máquinas de nube deberían mantener una estrecha vigilancia sobre el desempeño.
Peter Wayner, InfoWorld (EE.UU.)