Recientemente leí cuatro artículos interesantes que ponen en perspectiva los modelos actuales usados en cloud computing de software como un servicio (SaaS) e infraestructura como un servicio (IaaS o Utility Computing). Pienso que la historia de sus parientes lejanos (industria de tiempo compartido de los 70s) es imprescindible para tener una mejor visión del mercado actual de cloud computing.

Los artículos recomendados son (en orden cronológico de publicación):

1. Martin Campbell-Kelly and Daniel D. Garcia-Swartz. Economic perspectives on the history of the computer time-sharing industry, 1965-1985. IEEE Annals of the History of Computing, 30(1):16–36, January 2008.
2. Martin C. Kelly. [historical reflections] the rise, fall, and resurrection of software as a service. Commun. ACM, 52(5):28–30, May 2009.
3. Erik Brynjolfsson, Paul Hofmann, and John Jordan. Cloud computing and electricity: beyond the utility model. Commun. ACM, 53(5):32–34, 2010.
4. Dave Durkee. Why cloud computing will never be free. Commun. ACM, 53(5):62–69, 2010.

El 10 y 11 de junio asistí al ACM Symposium on Cloud Computing 2010 (ACM SOCC 2010) , que se llevó a cabo en Indianapolis, IN. Las presentaciones y charlas, tanto académicas como de la industria, estuvieron muy interesantes. Recomiendo ver on-line el vídeo del keynote talk a cargo de Jeffrey Dean de Google: Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google.

Esta entrada es la primera de varias que publicaré durante los próximos meses, resumiendo papers importantes relacionados al tema de cloud computing.

Eucalyptus es un proyecto open-source que permite levantar clústeres bajo demanda, con nodos virtualizados (Xen). A más de ser un proyecto de código abierto, tiene la gran ventaja de implementar el API de los AWS (EC2 y S3), de tal manera que es compatible con las herramientas desarrolladas para esa plataforma.

El paper no entra en muchos detalles, pero sí menciona las principales decisiones de diseño y componentes del mismo.

Como parte de ESPOLciencia, el 20 de enero tuvimos una vídeo-conferencia titulada «The State of the AWS Cloud» a cargo de Jinesh Varia, un Evangelist de los AWS. La conferencia tuvo una excelente acogida, entre estudiantes, profesionales e investigadores. Si bien algunos estudiantes de la FIEC ya estaban familiarizados con estos servicios al haberlos utilizado en mi materia de graduación, para otros el concer sobre estos fue algo nuevo.

Para los que les pareció interesante la charla, recomiendo leer el whitepaper «Architecting for the Cloud: Best Practices», el cual proporciona ejemplos y casos de mejores prácticas en el uso de los AWS.

Como hubo interés de investigadores y profesores de usar los AWS, pongo a disposición también el enlace de los fondos del programa AWS in Education.

Según el MIT Review, un grupo de investigadores de la Universidad de California, Berkeley está trababajdo en un proyecto llamado BOOM que facilitará la creación de programas que corran en las nubes. La meta del proyecto BOOM (Berkeley Orders Of Magnitude) es facilitar la construcción de sistemas distribuidos que sean mucho más escalables, usando mucho menos código. La idea es que el desarrollador se pueda preocupar del flujo de datos del sistema, y no de las complejidades del sistema distribuido como tal.

Las «nuevas» técnicas de BOOM están basadas en técnicas de bases de datos originalmente desarrolladas en los 80s; específicamente, en un lenguaje llamado Datalog. Para ser precisos, el ambiente de desarrollo de alto nivel de BOOM se llama Bloom, y está basado en el lenguaje Dedalus. Los creadores de Dedalus lo han descrito como Datalog en tiempo y espacio; es una adaptación de Datalog que permite expresar sistemas distribuidos como un conjunto de invariantes lógicas. A su vez, Datalog es un lenguaje de consultas y reglas para bases de datos que se deriva de Prolog.

El libro The Fourth Paradigm (disponible en-línea) parece ser muy interesante y busca motivar una nueva oleada de investigación basada en procesamiento masivo de datos. A través de varios ensayos, se argumenta que los nuevos avances tecnológicos se basarán en descubrimientos posibles gracias al desarrollo actual de técnicas computacionales avanzadas que permiten a los investigadores manipular y explorar datasets masivos.

Kevin Weil de Twitter (a quien mencioné en mi entrada anterior) acaba de publicar en el blog de Cloudera un tutorial sobre como usar archivos con compresión LZO. La compresión LZO resulta más adecuada que los algoritmos gzip y bz2 para el procesamiento masivo de datos con Hadoop. Gzip no puede ser usado en Hadoop porque un bloque (chunk) independiente de un gran archivo no puede descomprimirse sin conocer la información de los bloques anteriores; es decir, no se puede trabajar en paralelo con pedazos de archivos grandes. Bz2 sí puede ser usado en Hadoop, pero tiene la desventaja de ser muy lento, lo cual hace que una gran parte de lo que se gana en reducir E/S al usar compresión, se pierde debido a la sobrecarga de CPU requerida para las operaciones de descompresión. LZO tiene la ventaja de poder descomprimirse en paralelo y de manera muy rápida, lo que lo hace ideal para Hadoop.

En los gráficos que ilustran las implementaciones MapReduce podemos ver una «barrera» entre la fase Map y la Reduce. Una «barrera» es un mecanismo de sincronización entre procesos que espera a que todos los procesos de un lado de la barrera terminen antes que empiecen los procesos del otro lado. En este caso, eso significa que la fase Map debe terminar antes que empiece la fase Reduce. Este comportamiento parece no verse plasmado en Hadoop, en donde podemos ver que la fase Reduce empieza antes que terminen los Maps. Por ejemplo:

09/11/14 10:58:50 INFO mapred.JobClient: map 79% reduce 18%
09/11/14 10:58:54 INFO mapred.JobClient: map 79% reduce 19%
09/11/14 10:58:55 INFO mapred.JobClient: map 80% reduce 19%
09/11/14 10:58:58 INFO mapred.JobClient: map 80% reduce 20%
09/11/14 10:59:00 INFO mapred.JobClient: map 81% reduce 20%
09/11/14 10:59:04 INFO mapred.JobClient: map 82% reduce 20%
09/11/14 10:59:05 INFO mapred.JobClient: map 82% reduce 21%
09/11/14 10:59:08 INFO mapred.JobClient: map 82% reduce 22%

Recientemente, en un thread en la lista common-user de Hadoop se justificó muy bien este comportamiento.

David Howell dijo: «The first 2/3 of the reduce phase (as reported by the progress meters) are all about getting the map results from the map tasktracker to the reduce tasktracker and sorting them. The real reduce happens in the last third, and that part won’t start until all of the maps are done. »

Kevin Weil (líder del equipo de Analytics de Twitter) dijo: «The first third of the reduce phase is really the shuffle, where map outputs get sent to and collected at their respective refucers. You’ll see this transfer happening, and the «reduce» creeping up towards 33%, towards the end of your map phase.  The 33% mark is where the real barrier is.»

Lo que quiere decir que la fase Reduce no empieza realmente hasta que termina la fase Map. Ese porcentaje de «Reduce» que se ve avanzando en paralelo con los Maps, en realidad es la llamada fase de «Shuffle and Sort» que copia y ordena los valores intermedios generados por los Mappers antes de que puedan ser procesados por los Reducers.

En clase algunos tuvieron problemas con el plug-in de Hadoop para Eclipse. Este problema se debe a que el mantenimiento del plug-in ha sido descontinuado. Leí en un e-mail (y respuestas) enviado a la lista common-user de Hadoop y se puede solucionar el problema re-compilando el plug-in. Pero al parecer una mejor alternativa sería trabajar con el Karmasphere Studio for Hadoop basado en Netbeans.

Un estudio reciente publicado por una profesora de la Universidad de Toronto y gente de Google ha encontrado que los errores en memoria DRAM (memoria principal) son mucho  más comúnes de lo que se pensaba anteriormente. Esto tiene implicaciones importantes en los sistemas actuales, sobre todo para data centers implementados con componentes de bajo costo (los cuales vienen sin mecanismos de corrección de errores para la RAM).

A continuación, listo las conclusiones finales de la investigación:

1. We found the incidence of memory errors and the range of error rates across different DIMMs to be much higher than previously reported.
2. Memory errors are strongly correlated.
3. The incidence of CEs increases with age, while the incidence of UEs decreases with age (due to re-placements).
4. There is no evidence that newer genera-tion DIMMs have worse error behavior.
5. Within the range of temperatures our production systems experience in the field, temperature hasa surprisingly low effect on memory errors.
6. Error rates are strongly correlated withutilization.
7. Error rates are unlikely to be dominatedby soft errors.