Arquitecturas escalables en Google

[spanish]

Un compañero de trabajo me manda tres interesantes artículos de la web High Scalability, que no conocía aún y que ya he añadido a mi lista de RSSs en Google Reader. :) Los artículos tratan sobre las decisiones de diseño y arquitectura de computadores/redes tomadas en YouTube, Google y GTalk, para hacer frente a la altísima cantidad de visitas y datos que deben servir por segundo, comentando también más o menos la estructura actual y la evolución de la infraestructura de cada uno de ellos:

Algunas conclusiones a extraer de éstos artículos:

  • No intentar arreglarlo todo con una única arquitectura o una única herramienta. Dividir el problema en subproblemas, ver en cada caso si el límite es CPU, ancho de banda, IO y optimizarlo. Especializar servidores para cada caso y coordinar el trabajo de cada parte.
  • Cachear contenido siempre que sea posible. Pregenerar contenido siempre que sea posible. Utilizar las directivas HTTP para el control de caché. Usar squid como proxy inverso para aliviar a los servidores de aplicaciones.
  • Plantearse externalizar algún servicio, el hosting de imágenes o videos que puedan suponer más ancho de banda del que actualmente tenemos. Aunque sea como solución de compromiso mientras se contrata más ancho de banda. Lo importante es ofrecer el servicio en condiciones.
  • Simplicidad, dentro de lo que cabe. Permitirá hacer cambios y evoluciones sin cagarla demasiado.
  • Clusters basados en PCs normales. Maximizan la relación potencia/precio. Tener montado un sistema de redundancia para que una caída no afecte al servicio, y un sistema de instalación sencillo para poder añadir/sustituir equipos sin calentarse mucho la cabeza. Y empezar a planificar los problemas de alimentación y aire acondicionado. ;)
  • La programación hoy en día se basa en librerías y frameworks. No reinventar la rueda. Usar un framework común, propio o no, de forma que los programadores no tengan que hacer una y otra vez las mismas cosas y una actualización beneficie a todos nuestros productos de golpe.
  • Pensar en la arquitectura desde el principio. Estoy tristemente acostumbrado a que los desarrolladores no se preocupen de lo que hay por debajo de su código, ni si éste va a provocar problemas de red, disco, CPU, etc. Google enfoca todos los problemas desde la arquitectura necesaria para dar el servicio, y luego programa alrededor de ésa arquitectura. Es lo que diferencia a Google del resto.

[/spanish]

[english]

A coworker has sent me three interesting articles from High Scalability, a site I still didn’t knew but which I’ve already added to my Google Reader list. :) The articles talk about the design and computer/network architecture decisions taken at YouTube, Google and GTalk in order to handle the big load their services face. They also comment the current architecture in each site and their evolution over time:

Some lessons to learn from these articles:

  • Don’t try to fix everything with one single architecture or tool. Divide the problem, see if each sub-problem is CPU-, bandwidth- or IO-bound, and optimize it. Specialize server for each task and coordinate their work.
  • Cache content whenever possible. Pre-generate content whenever possible. Make good use of HTTP’s cache-control directives. Use squid as a reverse proxy to leverage your application servers’ load.
  • Think about externalizing some things, like hosting images or videos off-site. These elements may need more bandwidth that you currently have, and moving them off-site can be a good idea, even if it’s just a temporary measure while you manage to get more bandwidth. The service must run at all times.
  • Simplicity. Will let you make changes and evolve your architecture without screwing up.
  • Commodity-PC based clusters. They maximize the power/price ratio. Have a redundancy system in place so that when one node goes down or needs maintainence, the system keeps working without it. Have a system to easily install/change a node, also without affecting the service. And start planning the power and cooling problems ahead. ;)
  • Programming today is much about libraries and frameworks. Don’t reinvent the wheel. Use a common framework in all your developments, homegrown or not. This way novel programmers will be able to start writting code faster, will be able to switch projects easily, won’t have to code the same things over and over again, and a system upgrade will benefit all your applications.
  • Think about the architecture you’ll need from the start. I’m sadly used to developers not caring about what their code runs on, or if their code will lead to CPU, IO or bandwidth problems. Google seems to face every new development looking at the architecture they’ll need to handle the service, and then develop the code arount that architecture. This is what settles Google appart from the rest.

[/english]

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.