El reto de poder funcionar con un número de usuarios tan enorme se ha visto subrayado por una serie de dificultades sufridas por otras redes sociales. Twitter tuvo muchos problemas durante la etapa en que aumentó su capacidad y se hizo tristemente famosa por su “Ballena de Error”—la imagen que aparece cuando los servicios del sitio de microblogging no están disponibles.
Por el contrario, los esfuerzos de Facebook a la hora de aumentar de tamaño se han dado con una suavidad digna de elogio. El sitio soporta alrededor de mil millones de mensajes de chat cada día y, en las horas punta, sirve alrededor de 1,2 millones de fotos por segundo.
El vicepresidente de ingeniería de Facebook, Mike Schroepfer, aparecerá este miércoles en la conferencia EmTech@MIT de Technology Review en Cambridge, Massachusetts. Charló con la editora asistente Erica Naone acerca de cómo se ha enfrentado la compañía al flujo constante de nuevos usuarios y características.
Technology Review: ¿Cuál es la diferencia entre agrandar una red social y, por ejemplo, agrandar una página web de noticias?
Mike Schroepfer: Prácticamente cada una de las vistas en la página viene dada tras un registro de usuario, es una vista de página hecha a medida, y esto no suele ser así en la mayoría de las otras webs. Por tanto lo que ves en pantalla es muy distinto de lo que yo veo, y es también distinto de lo que ve tu hermana. Esto no sólo se aplica en la página de inicio, sino en todo lo que ves a lo largo del sitio. Tu visión del sitio está modificada por quién eres y quién está en tu gráfico social, y eso significa que tenemos que llevar a cabo muchos más procesos y cálculos para poder realizarlo.
TR: ¿Qué ocurre una vez que empiezo a realizar acciones en el sitio? Da la impresión de que eso complicaría las cosas aún más.
MS: Si eres amigo mio y te haces fan de la página de Green Day, por ejemplo, eso se va a mostrar en mi página de inicio, quizá en la sección de destacados, o quizá en el “flujo” general. Si algo así se muestra en mi página, también se mostrará que tres de mis otros amigos son fans. Sólo para mostrar la página de inicio tenemos que funcionar con un grupo de datos extremadamente complejo—que nosotros llamamos el gráfico—en tiempo real y servírselo al usuario en sólo unos segundos o, preferiblemente, en menos de un segundo. Cada día llevamos a cabo varios miles de millones de operaciones como esta.
TR: ¿Cómo se puede manejar todo eso? La mayoría de los sitios logran atender a un número elevado de usuarios mediante el uso del caché—que consiste en calcular una página una vez y almacenar los resultados para después mostrarla muchas veces más. No da la impresión de que algo así pudiese funcionar en este caso.
MS: La mejor arma en la mayoría de los problemas de ciencias informáticas es el caché. No obstante, y como ocurre con la página de inicio de Facebook, se están dando actualizaciones cada minuto o menos, entonces cada vez que cargo la página es una página nueva, o al menos posee nuevos contenidos. Esto hace que sea imposible usar el caché. Hacer cosas en tiempo real pone mucha presión en el sistema puesto que la viveza o frescura de los datos hace que sea necesario hacer peticiones y cálculos en tiempo real.
Hemos construido un par de sistemas de apoyo. Uno de ellos es una base de datos a medida y colocada en la memoria que hace un seguimiento de lo que ocurre en las redes de tus amigos y es capaz de devolver el núcleo de resultados de forma muy rápida, mucho más rápidamente que si hubiese que acceder a una base de datos, por ejemplo. Y después contamos con una arquitectura de sistema muy novedosa que nos permite fragmentar y dividir todos estos datos. Hay demasiados datos y se actualizan muy rápidamente como para colocarlos en una base de datos central. Esto no funcionaría. Por tanto tenemos que separarlos, dividirlos entre cientos de bases de datos, y después tenemos que acceder a esas bases de datos a alta velocidad.
TR: ¿Qué ocurre cuando se añaden nuevas características al sitio?
MS: Añadir o cambiar una característica al sitio puede afectar de forma bastante dramática al comportamiento del usuario, lo que tienen implicaciones también dramáticas en la arquitectura del sistema. Te daré un ejemplo muy simple. En febrero de este año añadimos la característica “Me gusta”. Es una forma de aprobar algo con un solo botón, para que el usuario pueda decir “Esto me gusta.” Hubo grandes debates inte os acerca de si la característica de “Me gusta” acabaría con los comentarios. Resultó ser algo adictivo; la cuota de comentarios se mantuvo igual y el “Me gusta” se hizo una de las acciones más comunes del sistema.
Esto suena muy trivial, pero uno de los retos a la hora de construir sistemas complejos y escalables es que siempre es más fácil leer datos de una base de datos que almacenarlos. Cada vez que hago clic en el botón “Me gusta”, tenemos que registrar esa acción permanentemente en algún lugar. Si construyésemos el sistema asumiendo que la mayoría del tiempo íbamos a estar leyendo datos, al cambiar las características del producto nos obligaríamos a dejar de asumir algo así. Creo que ponemos mucho esfuerzo en no asumir demasiadas cosas y estar listos para rediseñarlas al mismo tiempo que cambiamos el núcleo del producto. Esto es algo de gran importancia.
TR: ¿Y qué pasaría si se adjuntasen estas nuevas características a la arquitectura ya existente?
MS: Creo que una de las cosas más interesantes es que podemos encender y apagar las características. Pasar de cero usuarios a 300 millones de usuarios en una tarde para una característica totalmente nueva es una locura. Y nosotros somos capaces de hacer algo así puesto que, en general, toda la infraestructura está compartida. Puedes encender la característica y pasar del 1 por ciento de adopción al 100 por ciento en un día sin tener que percibir mucho tiempo de espera.
TR: Pero el problema no sólo reside en el cambio y en la complejidad—también está el problema del almacenamiento. Facebook trabaja con toneladas de fotos. ¿Ese sistema se construyó desde un principio para que pudiese hacerse más grande?
MS: Especialmente ahora—con las cámaras en los teléfonos y la integración directa a través de las aplicaciones de los smarphones—se suben y comparten muchísimas fotos en el sitio. La primera versión del almacenaje de fotos la construimos utilizando dispositivos normales de almacenaje para redes, con servidores web. Eso resultaba funcional, pero no lo suficientemente funcional, y también era muy caro. Hicimos algunos ajustes a ese sistema para mejorar el rendimiento y conseguimos que fuese cinco o seis veces más rápido que la versión original. Después pasamos a construir nuestro propio sistema de almacenaje llamado Haystack, y que está construido completamente utilizando hardware común y corriente. Consiste en un grupo de unidades estáticas y una caja Intel con una pila a medida encima que nos permite almacenar y servir las fotos usando directamente las distintas capas de almacenamiento. Esto es menos costoso y más rápido que los productos a la venta en el mercado. Hemos invertido muchísima energía en el almacenaje de fotos porque la escala de la que estamos hablando es simplemente impresionante.
TR: ¿Se tiene siempre la certeza de que se van a lograr implementar correctamente los cambios que se realizan en la arquitectura?
MS: Ha habido un par de casos en los que hemos iniciado proyectos que no estábamos seguros si podríamos llevar a cabo—hay uno del que no puedo hablar porque lo vamos a anunciar más tarde este año. Hay casos en los que vamos a intentar hacer algo que mucha otra gente ha intentado hacer antes, pero que nosotros pensamos que podemos hacer mejor. Creo que el valor y la predisposición para llevar a cabo la inversión es lo realmente importante en este caso, puesto que si no se dan esos dos factores ningún plan, por bueno que sea, te va a ayudar a llegar donde quieres llegar.