Allá por Enero, escribía sobre la arquitectura de LMAX, una empresa que había desarrollado una aplicación para operar en mercados de derivados pero no sólo orientada a traders sino también al usuario final, y que presentaba unos números impresionantes. En InfoQ publicaron un video muy interesante donde los creadores de la arquitectura la explicaban en detalle.
Un amigo me ha pasado hoy este enlace, donde el mismísimo Martin Fowler ha hecho un análisis mucho más detallado sobre la arquitectura, complementado por notas que ha intercambiado por email con los autores. Si os interesa el tema de la escalabilidad y la computación de alto rendimiento entonces es un artículo que no os debéis perder.
Ayer apareció en todos los medios de comunicación, aunque yo me enteré por el grupo de escalabilidad en español (toma promo gratuita). Una compañía de Miami, LexisNexis ha anunciado que hará Open Source su tecnología de computación y análisis de datos HPCC Systems (High Performance Computing Cluster) a la que la prensa no ha dudado en tildar como el Hadoop Killer.
Aparentemente, según comentan en el artículo, se están leyendo cada vez más opiniones negativas de personas que se han dado cuenta que no es oro todo lo que reluce dentro del mundo de NoSQL. Algo que por otra parte, tampoco nos debería extrañar a nadie ya que hay muy pocas tecnologías que sean sólo ventajas.
Hace unos días trascendió que Twitter había terminado su proyecto de migración para su backend de búsqueda en tiempo real (search.twitter.com). El proyecto había comenzado en la primavera del 2010 y terminó en Abril del 2011 así que tenemos, tal y como señala Javier Murillo en su análisis, un año para un proyecto desarrollado por un equipo de quince ingenieros.
Twitter tenía dos problemas para querer cambiar la arquitectura de su sistema de búsqueda y que hasta el momento estaba basado en el modelo clásico de base de datos relacional. Uno era el que describen en el post de este mes, y es la escalabilidad. Con Rails estaban atados a un thread por búsqueda y eso hacía que desperdicien CPU y recursos mientras se está realizando la búsqueda. Algo realmente importante cuando tienes 12.000 búsquedas por segundo y mil millones de búsquedas diarias. Para eso decidieron migrar a una arquitectura asíncrona basada en Netty tal y como explica el artículo.
En el blog del departamento de ingeniería de FourSquare han publicado un post realmente interesante sobre como han construido su motor de recomendaciones de lugares.
Lo primero que comentan básicamente es la dificultad de este tipo de motores al tener gran cantidad de datos, en su caso 10 millones de locales, y necesitar por una parte computar la similitud de estos lugares, es decir agrupar los lugares en los que se come Sushi, o Churrasco, o donde se toca Jazz, y por otra parte ponderar estos resultados con las preferencias personales de los usuarios, es decir como los han puntuado o cuantas veces los han visitado y con que frecuencia, y las preferencias de sus amigos, es decir si tus amigos suelen ir a restaurantes Indios hay una gran posibilidad de que a ti también te interesen estos restaurantes.
Confieso que no he probado todavía Firefox 4. La verdad es que Chrome me ha dado todo lo que necesito. Pero hay algo que me ha gustado mucho de Firefox 4 sin haberlo probado, y es su página de visualización de descargas en tiempo real. Mozilla Glow. Realmente impresionante.
En un mapa del mundo se pueden ver en tiempo real todas las descargas que se están realizando de Firefox, y que no son pocas ya que en el momento de escribir estas líneas ya van 37 millones.
Desde el punto de vista técnico la utilidad de este tipo de visualizaciones es más bien nula, salvo el hecho de poder decirnos: "bien, hay gente descargando nuestro software". Desde el punto de vista de marketing el impacto es brutal. Hay que darse cuenta de que Firefox tampoco es un navegador tan popular (o era), y el efecto que tiene este gráfico en una persona de a pie es cercano al "Guau!!! ¿¿¿pero hay realmente tanta gente descargándose Firefox???". Esto no puede ser malo.
Tal y como os comentaba ayer, los últimos días había estado comentando con Marc y Miguel Ángel Pastor la posibilidad de crear un grupo sobre escalabilidad, Hadoop, NoSQL, computación distribuida, etc.
La cosa ha surgido así como de casualidad. Miguel se pone en contacto conmigo preguntándome por listas o grupos sobre el tema; por otra parte, conozco a Marc que me cuenta que le gustaría potenciar la comunidad Hadoop en España, y ya lo demás es el poner en práctica mis habilidades de liante para que entre ellos dos monten un grupo en Google para ver si arranca esta comunidad :)
La pasada semana este blog estuvo parado ya que estuve casi todos los días en Londres. Allí tuve la oportunidad de tomarme unas pintas con David Hernandez y Marc de Palol, ambos unos cracks que se encuentran viviendo y trabajando en la city.
El blog de David ya lo conocía. El que no conocía era el de Marc. Entre pinta y pinta estuvimos comentando como estaba la situación de los dos países, y muchos otros temas. Uno de ellos era como todos veíamos que Hadoop estaba dando fuerte y como se empezaba a usar más y más, también en España.
Siguiendo con el post anterior, sobre la presentación sobre LMAX en InfoQ, de mi resumen me restaba comentar los seis consejos que ellos daban para la creación de aplicaciones de alto rendimiento que fuesen capaces de gestionar un gran número de transacciones con una latencia muy baja.
Su máxima era: hoy en día con un único hilo puedes jugar con 3 billones de instrucciones por segundo. Con no hacer nada estúpido tendrás 10 mil transacciones por segundo sin problemas. ¿Pero cómo hacemos para no meternos en problemas? Aquí resumo sus consejos:
Hace poco más de un mes publicaron en InfoQ una presentación muy interesante sobre como crear aplicaciones capaces de procesar un gran número de transacciones con una latencia muy pequeña.
Los autores de la presentación fueron Martin Thompson y Michael Barker y trabajan en LMAX. Esta copañía desarrolla lo que se llama un Trading Exchange. Este tipo de compañías ofrecen la posibilidad de comprar activos financieros al usuario final (i.e. nosotros) ofreciendo un pool de proveedores (agencias de trading, bancos, etc.) que compiten entre sí para ofrecerle al usuario el mejor precio. La idea es que si por ejemplo quiero comprar EUR/USD el sistema me va a ofrecer siempre la mejor oferta de entre los varios proveedores existentes en el trading exchange.
Tal y como escribía hace unos días, la arquitectura de Netflix está basada en Amazon Web Services. La compañía, decidió a principios de año migrar su arquitectura a Amazon.
En el blog de Netflix, comparten cinco lecciones que han extraído de su experiencia al mover su arquitectura desde su propio data center a la nube:
En la línea de las notas de arquitectura que suelo publicar voy a escribir hoy un post con un resumen de notas que he ido sacando sobre un documento acerca de la arquitectura del chat de Facebook. Si os interesa el tema entonces os pueden interesar también las notas sobre la arquitectura de Facebook del año pasado. Empiezo.
En 2007 en Facebook se dan cuenta de que necesitan un Chat, seguir los mensajes entre muros es un infierno. El código surge en el 2007 de lo que en Facebook denominan un Hackathon, es decir quedarse los ingenieros durante toda una noche programando. No es hasta el 2008 cuando se manda el primer mensaje y lo lanzan oficialmente.
Adrian Cockcroft, Cloud Architect en Netflix ha compartido unas transparencias en Slideshare bastante interesantes sobre el servicio de streaming de video Netflix.
Las transparencias están orientadas tanto a desarrolladores como a ingenieros de sistemas. Las notas que se sacan son bastante interesantes y son bastante densas, de hecho entran en bastantes detalles según comenta su autor en su propio blog para atraer a ingenieros a su equipo, ya que están contratando. Y vaya si están contratando. En su web tienen unas 100 posiciones abiertas ahora mismo. Como siempre me pasa, este post iba a ser una simple referencia pero ha terminado en una recopilación de notas.
Hace unos meses, Tom Cook, Ingeniero de Sistemas de Facebook daba una charla en el evento Velocity 2010 de O'Reilly donde describía como es el día a día dentro del servicio de operaciones del gigante americano de las redes sociales.
La charla comienza con algunas estadísticas que le quitan el hipo a cualquiera:
- La gente pasa 16000 millones de minutos diarios en Facebook - Se comparten 6000 millones de piezas de contenido al mes - Se suben 3000 millones de fotos al mes - Hay un millón de implementaciones de Facebook Connect
A todo ello contribuye que 50 de los 100 sitios más visitados del mundo integren Facebook de algún modo, ayudando a llegar a los 400 millones de usuarios de este 2010. Para soportar esta carga de usuarios, Facebook tiene dos centros de datos. Uno en la costa Este y otro en la costa Oeste de Estados Unidos y están construyendo uno nuevo en Oregon. Todos sus servidores utilizan Linux y su distribución es CentOS.
Nada más comenzar la charla uno se da cuenta de que Facebook es un lugar donde la opinión de los ingenieros tiene realmente mucho peso, para bien o para mal. Está claro que no es trata de un lugar habitual. Algo que me ha sorprendido por ejemplo es que la propagación de parches y cambios a producción se hace con BitTorrent, moviendo ese código a más de diez mil servidores. Otro uso interesante de BitTorrent.
Pero hay cosas todavía más sorprendentes. Facebook está hecho en PHP. Sin embargo parece que el rendimiento llegó un punto en el que no era aceptable. Lejos de cambiar de plataforma, ya que a sus ingenieros les gusta PHP, crearon una herramienta interna para traducir el PHP a C++, compilándolo después con g++. El resultado fue un 50% de aumento en el rendimiento que podríamos trasladarlo, aunque no sea estríctamente así, a un 50% menos de servidores. Sea como sea, el crear un traducor de PHP a C++ no parece que sea el tipo de decisión recomendable para todas las compañías que quieran más rendimiento.
Otro modo que tienen de aumentar el rendimiento es utilizar cachés (Memcached) y una enorme cantidad de memoria RAM: más de 300Tb de datos en vivo en diferentes cachés. Utilizan MySQL en la base de datos. Sobre MySQL en Facebook ya puse unas notas hace un año en el post "Notas sobre la arquitectura de Facebook".
La principal conclusión que he extraido de esta charla es que Facebook es, sin ninguna duda, una de esas compañías dirigidas principalmente por el equipo de operaciones. Está claro el peso de este departamento en el proceso de desarrollo y producción. En mi experiencia, trabajar en este tipo de empresas puede llegar a ser un auténtico infierno en los casos en los que el equipo de producción esté demasiado aislado del equipo de desarrollo, en los casos en que los procesos de trabajo estén demasiado cargados de burocracia o en los casos en que el departamento de operaciones tenga excesivo celo en cuanto a la implantación de cambios y nuevas funcionaliades.
Facebook nuevamente es diferente. Tom Cook comenta en su charla como los ingenieros de operaciones se mezclan con los ingenieros de desarrollo para trabajar conjuntamente en los parches y funcionalidades. Asimismo, los desarrolladores adquieren plena autonomía y responsabilidad sobre sus actos, de modo que deben participar en todas las fases de despliegue y sentarse con el equipo de sistemas a la hora de pasar cambios a producción.
Una de las consecuencias de esto es que en Facebook han eliminado la capa de QA. Esto en mi opinión es un error, pero no cabe duda de que Facebook es un sitio diferente. Me imagino que todo el desarrollo de productos y parches estará dirigido por procesos controlados, pero desde luego la impresión que se extrae de la charla es que los ingenieros tienen poco más que barra libre para introducir cambios a su antojo sin el más mínimo control de calidad. Claro, uno después se explica como en funcionalidades que no son 'core' como puedan ser las aplicaciones Facebook, un día las cosas funcionan y otro no :-)
Pero entonces, ¿cómo suplen esta falta de control de Calidad? Con un gran énfasis en la monitorizacíon y la instrumentación. Todo lo que sucede en los servidores de Facebook está completamente controlado. Para ello disponen de herramientas internas o usan software Open Source como Ganglia, Nagios o CFEngine. Pueden controlar en cualquier instante el estado de cualquier servidor, rack, cluster o centro de datos. Además de resaltar la importancia de la monitorización y la instrumentación se hace relevante también el automatizar la reacción ante caidas de cualquiera de estos componentes, ya sea eliminando el nodo, reiniciándolo, etc.
Una cosa queda clara en la charla. En Facebook no se toman las operaciones a broma. Aunque nuevamente hay cosas muy desconcertantes en cuanto al control de calidad. En la charla muestran herramientas de comunicación interna que se utilizan para que todo el mundo en la compañía conozca el estado de los sistemas en cualquier momento independientemente de tu puesto en la compañía. Es algo sin duda fantástico. Pero asimismo cuando sucede un problema lo que se entiende de la charla es que lo resaltan en su portal interno de noticias y esperan a que ningún ingeniero introduzca código, ya que éstos tienen la capacidad de introducir cambios en cualquier momento. Esto no hace más que reafirmar en mi interior que Facebook no es una empresa tradicional, y que por el contrario ofrece ese sentimiento de funcionamiento bastante anárquico en ciertos aspectos.
Por último, os dejo el video por si interesa verlo vosotros mismos.
Con un dominio muy molón Yahoo acaba de lanzar hace nada S4. Se trata de una "Distributed Stream Computer Platform" o para que nos entendamos, una librería/plataforma para procesar grandes cantidades de datos que van llegando continuamente en tiempo real.
Hace nada acaban de publicar una entrada en su blog presentando el proyecto. Se trata de llevar la filosofía que MapReduce y Hadoop han popularizado para el procesado de trabajos en batch al procesado de datos que fluyen en tiempo real. Ellos ponen el ejemplo del análisis mediante técnicas de aprendizaje por computador de miles de búsquedas por segundo realizadas por millones de usuarios diariamente en el buscador de Yahoo.
Todo esto de manera que sea distribuido, es decir que haya múltiples nodos que se dividan el procesado de ese flujo de datos; que sea escalable, es decir que para soportar el procesado de más información sólo sea necesario introducir más máquinas; y que sea tolerante a fallos, es decir que si algún nodo se cae, haya otro que sea capaz de procesar esos datos.
La plataforma es Open Source, la han liberado bajo la licencia Apache y está desarrollada completamente en Java.
Poco os puedo explicar yo sobre eso, todavía estamos en la fase de escalar como negocio así que mucha escalación técnica aún no necesitamos. Pero por casualidad descubrí el otro día un video en vimeo muy recomendable donde gente de Doppler, exs de Twitter, Google, etc. explican como fue su proceso de escalabilidad que les han permitido llegar a donde han llegado.
En una de las empresas en las que trabajé en rlanda me pasó lo que probablemente fue ha sido el momento más rocambolesco de mi carrera. Y es que a veces los managers tienen una extraña concepción de lo que puede y no puede motivar a un equipo.
Os pongo en situación: Un banco pagando X dinero (mucho, mucho) al mes durante 24 meses y la aplicación no ha llegado a nada. Ya se sabe como son estas cosas. Grandes especificaciones que tardan meses en completarse y mientras tanto ni una línea de código, a vivir. Llega el momento y resulta que no llegamos a esos 50000 usuarios concurrentes que necesitamos. Hay que contratar personal extra. Ahí llego yo, con seis meses ya de retraso acumulado y sin rumbo claro. Pasan los meses y poco cambia. Por mucho que queramos hacer cosas todo está dirigido por especificaciones inamovibles e irrealistas. Proyecto abocado al fracaso.
Llega el momento del ultimatum. El banco lo quiere ya y necesitamos la aplicación en quince días. ¿Cómo podemos motivar al equipo? Pues a alguien se le ocurrió la siguiente idea tan fenomenal y que he bautizado como TVDD o TV-Driven Development:
Comprar una televisión de 42 pulgadas (doy fe de que se puede reusar posteriormente para apostar a las carreras de caballos).
Colocar la televisión en la entrada para que sea lo primero que ven los empleados al entrar en la oficina.
Mostrar lo más grande que se pueda la cuenta atrás para el día fatídico. 15,14,13,12,...
Preparar un PowerPoint cada día donde figuren las incidencias más críticas en JIRA y mostrarlo en grande como índice.
En sucesivas páginas del PowerPoint, relatar la incidencia y el responsable de arreglar esas incidencias.
Hacer saber a los empleados que esta medida es para que todos mantengamos el foco en el objetivo a conseguir en las próximas dos semanas y que nadie se dedique a otra cosa más que a solucionar sus incidencias.
Así que los "afortunados", y me incluyo porque a mi me tocó alguna, llegábamos por la mañana tan tranquilo y nos encontrabamos con un pantallón donde veías los días, y si "tenías suerte" tu nombre saldría en grande y tendrías tus minutos de gloria ya que alguien te habría asignado un marrón del que probablemente nunca habías oido hablar porque se había colado entre los cientos de documentos Word que los business analyst habían estado reenviando de aquí para allá.
Si alguno está interesado en aplicar esta metodología en su empresa, por favor que me avise primero para evitar acercarme a un kilómetro a la redonda :-) No os tengo que decir que la metodología falló estrepitósamente. En realidad nos lo tomamos bastante a guasa. Lamentablemente la cuenta atrás terminó en el número 7. El banco canceló el proyecto y hubo que despedir a la mitad de la plantilla.
El final es feliz ya que la empresa perdió mucha de la gente que no estaba favoreciendo al rumbo. De hecho, eramos !9 arquitectos! (para unos 50 desarrolladores) y nos quedamos en 3, lo que es un número mucho más razonable. Conseguimos que se cambiase la forma de trabajo a una metodología ágil y reconstruir el producto con iteraciones claras. La empresa por fin, tras unas semanas consiguió un producto que vender, y de hecho se consiguió vender a varios bancos mucho más pequeños. Han pasado varios años, muchos nos hemos ido y la empresa no está pasando los mejores momentos, pero es uno de los lugares donde más he aprendido sobre como transformar algo que está podrido desde su raíz incapaz de sacar algo a la luz en una empresa que realmente produce productos y vende software que funciona.
En definitiva, que si un proyecto está retrasado, seguramente ni el no tener una televisión de 42", ni el no tener una cuenta atrás, ni el no tener JIRAs amenazantes, ni el traer refuerzos de última hora van a hacer que el proyecto se salve. Profesionalidad y asumir el "mea culpa", reconocer que las cosas se están haciendo mal y cambiar completamente el chip.
En mi opinión, sólo con la honestidad se puede salir adelante en proyectos como este. No sé si alguno tenéis experiencias parecidas. Os animo a compartirlas
Bueno, primeramente Feliz 2010, que ya tocaba decirlo. Y seguidamente continuo con mi tradicional lista para los más curiosos de lo más visto en el blog en el 2010:
Spring Roo, ¿Competencia para Grails?, con detalles sobre el anuncio de Spring Roo. Creo que este post seguramente haya sido popular más por llegadas sobre Grails que sobre Roo.
Este año la actividad de posteo ha decrecido considerablemente debido a Jobsket y parece que el 2010 tiene la misma pinta así que intentaré ser un poco más selectivo con las publicaciones. Muchísimas gracias a todos por las 37000 visitas que ha tenido este blog este 2009, casi nada. Casi tanto como los más de 800 subscriptores al RSS. Cifras increibles para este pequeño espacio y que son un reto para este año. ¡A ver si soy capaz de mejorarlas!
Facebook, Digg y muchos otros utilizan una técnica denominada Sharding para escalar.
El Sharding es una técnica que consiste en particionar los datos de tu base de datos horizontalmente agrupándolos de algún modo que tenga sentido y que permita un direccionamiento más rápido. Una agrupación típica puede ser por id por ejemplo: "los usuarios del 1 al millón están en esta base de datos"; o por nombre "los usuarios cuyo nombre va de la A a la E" están en esta base de datos".
Típicamente estos shards, agrupaciones o segmentos estarán localizados en tablas en diferentes bases de datos y localizaciones físicas. El Sharding no tiene por qué estar basado únicamente en una tabla y una columna, puede ser a nivel de todas las tablas. Por ejemplo podríamos decir "todos los datos de usuarios cuyo perfil está en los Estados Unidos los redirigimos a la base de datos del servidor en Estados Unidos, y todos los de Asia van a la base de datos de Asia".
El Sharding como tal mejora la escalabilidad y el rendimiento al agrupar menos datos en tablas más pequeñas por lo que los accesos serán mucho más rápidos. En caso de tener múltiples servidores en múltiples localizaciones, el basar el Sharding en la localización geográfica permite también disminuir considerablemente la latencia.
¿Cuándo se necesita hacer Sharding? Principalmente cuando el volumen de datos comienza a ser inmanejable. A tablas más grandes, más lentos son los accesos. No es lo mismo acceder a una tabla de diez mil usuarios que a una tabla de diez millones de usuarios. También comentan en el blog del que hablaré en breve que es bueno hacer Sharding cuando el volumen de escrituras es demasiado grande para un único servidor. En bases de datos, escrituras=bloqueos, bloqueos=contención de recursos, contención de recursos=mala experiencia de usuario, a parte del problema con la sincronización con slaves.
Todo esto viene a cuento de que en el blog de rendimiento de MySQL nos advierten de por qué no deberíamos hacer Sharding prematuramente. El problema principal es que Sharding se ha convertido en una palabra de moda. A fin de cuentas, si Facebook lo hace, ¿por qué no lo voy a hacer yo? Pues porque yo no tengo 120 millones de usuarios activos, ¿quizás?
Mi opinión es que en general estoy de acuerdo con el no hacer Sharding desde el principio, pero sólo si este va a impactar en la estructura de la base de datos. Es decir, dividir los usuarios de la A-E, la F-M, ... etc. a bote pronto parece como una mala decisión, al menos sin saber si vamos a tener cien usuarios o cien mil.
Pero planificar para Sharding no siempre tiene por que ser una mala decisión. En Java por ejemplo hay herramientas que nos lo facilitan. En general, el particionar por aplicación o por país además no son decisiones demasiado relevantes y que no tienen porque impactar el desarrollo en sobremanera, al tiempo que en el futuro facilitan enormemente la escalabilidad del servicio. Eso sí, hay que tener claro que a mayor número de shards mayor mantenimiento. No es lo mismo actualizar un índice en una tabla que hacerlo en cinco, especialmente porque al hacerlo en cinco es más fácil el dejarse uno olvidado.
Hace unas semanas fue la Velocity 09 y en blip.tv están disponibles los videos. ¡Vaya montón de conferencias interesantes! El otro día estuve echándole un vistazo a la de Twiter de John Adams: "Fixing Twitter: Improving the Performance and Scalability of the World's Most Popular Micro-Blogging Site"
(perdón que me cargue el blog con este video, tengo que buscar una plantilla más moderna)
Como acostumbro, he tomado unas notas porque me gusta tenerlas por aquí de referencia.
Su equipo de operaciones está formado por 8 personas. Funcionan más como un equipo de arquitectos de sistemas que como un centro operacional a la usanza. Se encargan de controlar la escalabilidad, el rendimiento, la disponibilidad, la planificación de la capacidad, etc.
El mantenimiento de servidores está subcontratado con NTT America, así que ellos no tratan con los servidores físicos.
No utilizan clouds. Lo intentaron pero no es para ellos. Comentan que por ciertas razones, no les funcionó. Uno de los argumentos que esgrimen es que necesitan métricas e información muy exacta.
Crecer es doloroso. Hay un miedo institucionalizado a cualquier cambio. Así que ellos se rigen por un Mantra común. Buscar el punto más débil y solucionarlo. Después, proceder al siguiente punto más débil.
Un consejo. Instrumetar todo lo que podáis. Pero ojo con instrumentar demasiado, especialmente con MySQL o Memcache por ejemplo.
Utilizan herramientas como RRDTool, Ganglia o MRTG. Con el output de estas herramientas crean cuadros de mando. Ahora mismo tienen sobre 1200 métricas. Toda la compañía tiene acceso a los cuadros de mando. También agregan métricas de fuentes externas, por ejemplo de NTT America.
Para recoger los datos de error, utilizan Google Analytics!
Monitorizan todos los despliegues. Así pueden correlacionar los despliegues con las estadísticas del sitio web como puede ser la latencia. De esa forma detectan cambios hechos por desarrolladores que pueden tener un fuerte impacto.
Otro consejo, si no habéis empezado a gestionar vuestra configuración. Hacerlo ya. Vale la pena. Ellos controlan los cambios en los ficheros usando diff y SVN. Tienen hooks de pre-commit y post-commit. Para hacer un cambio siempre debe ir acompañado de un comentario que especifique quien ha aprobado ese cambio. Una vez entra en el SVN se manda un correo a una lista de revisores. Los revisores reciben en su email el diff y aprueban el cambio o no. Si todo el mundo lo aprueba, el cambio se aplica.
Para la comunicación utilizan Campfire. Muy contentos con el.
Para atacar los problemas en los diferentes subsistemas utilizan fichas con "planes de ataque". Estás fichas incluyen, el síntoma, cual es el cuello de botella, el vector de elementos afectados y la solución propuesta. Este es un ejemplo:
CPU, ahora consiguen más por menos. Pasaron de AMD a Intel Xeon y consiguieron un 30% de rendimiento más. Cambiando de dual y quad core a 8 cores consiguieron otro incremento del 40%.
Rails. Ok, ruby es lento, pero hay formas de contrarestar esto. Tuvieron muchos problemas y mucho análisis que hacer, pero casi siempre el problema era debido, no a ruby sino a otras razones. La caché y la invalidación de la caché es un problema gordo, pero es más de memcache. ActiveRecord sí que les fue un problema ya que genera queries que a veces pueden tener muy mal rendimiento, lo que hace que la base de datos vaya más lenta y que la latencia en las colas se incremente. Otros problemas fueron la corrupción de datos en Memcache y el lag en la replicación de datos.
El disco duro es la nueva cinta. La Web 2.0 no es posible sin enormes cantidades de memoria RAM. Los gráficos sociales ocupan mucha memoria. Facebook o Twitter, ambos tienen enormes pools de instancias de memcache.
Twitter es tiempo-real pero hacen muchísimo caching. Utilizan diferentes pools de memcache para diferentes subsistemas para así prevenir la evicción prematura de datos. Los TTL van de 20 a 60 segundos pero para los usuarios que no usan mucho twitter pueden ser mayores. La mayor parte de los timelines se pueden
cachear ya que no varían demasiado. La creación de una página genera de 100 a 300 peticiones de memcache. Han contribuido varias optimizaciones a la librería de memcache de rails. Por ejemplo, cambiaron el algoritmo hash de MD5 a FNV lo que les supuso un aumento del rendimiento de 200x 300x. Han contribuido al Open Source Cache-Money una cache read y write-through para Ruby.
Pero hay que tener cuidado. Cachear todo no es la mejor política. Ellos han tenido problemas de datos obsoletos, corrupción de las instancias de memcache, corrupción de los hash, etc.
Utilizan colas de mensajería para la comunicación entre los diferentes demonios. Empezaron a desarrollarlo con Erlang, y les gustó, pero necesitas programadores con experiencia en erlang :S Así que cambiaron a Scala. Crearon Kestrel una solución interna que funciona como memcache.
Otra de sus experiencias es lo que casi todas las webs de este tamaño comentan. Las bases de datos relacionales no son la panacea. Ellos se han saltado muchas normas porque la consistencia de los datos no resulta un gran problema para el tipo de aplicación que es Twitter.
Hacen mucho cacheo web. Especialmente en Twitter Search. Utilizan Varnish.
Muchos problemas con Mongrel al no ser multi-threaded, ya que tanto el tráfico interno como externo consume muchos recursos en forma de instancias de Mongrel. La solución para ellos ha sido mover muchas tareas fuera del ciclo de requests para hacer éste mucho más corto y ahorrar recursos. Muchos demonios externos.
Sobre MySQL, nada que no se haya contado. Que las bases de datos relacionales no son muy aptas para los grafos sociales. Problemas de replicación. Un buen sharding es muy importante. Matan cualquier query que esté durando demasiado tiempo. Lo utilizan como mecanismo de auto-defensa.
Y eso es más o menos todo. Quizás me haya pasado con las notas, pero me ha parecido una charla muy interesante.
Allá por Enero, escribía sobre la arquitectura de LMAX, una empresa que había desarrollado una aplicación para operar en mercados de derivados pero no sólo orientada a traders sino también al usuario final, y que presentaba unos números impresionantes. En InfoQ publicaron un video muy interesante donde los creadores de la arquitectura la explicaban en detalle. 
