Muy interesante la manera en la que los responsables de Taringa le abrieron las puertas a uno de los moderadoradors del sitio, el cual, ni lerdo ni perezoso se gastó el índice sacando fotos de las oficinas de uno de los emprendimientos argentinos mas exitosos en internet.
En el post (que se convirtió en uno de los más visitados) es posible ver unas muy bonitas y luminosas oficinas donde pasan sus días administradores, diseñadores, publicistas y programadores. Como casi toda “oficina 2.0″ todos están bastante cerca, lo que debe facilitar y mucho la comunicación de sus miembros, también hay mucho “multi-monitor”, algo que parece mejorar la productividad de los trabajadores web.
También tiene un metegol, de los buenos, y una Genesis (espero que con el Sonic 2).
Un estabilizador Atomlux modelo 1997 es responsable de la estabilidad eléctrica de la administración de T!
Una sala de reuniones donde habitualmente se deben discutir varios aspectos relacionados al sitio.
La verdad que muy buenas las oficinas de Taringa! (recomiendo ver todas las imágenes en el post de kuruzka) y salvo alguna visita de Sergio a PsicoFXP (donde no se vieron fotos de las oficinas en sì) no he visto muchos posts que muestren las “oficinas de las startups”, vamos a tratar de mover las influencias altabísticas a ver si podemos “meternos” en alguna otra oficina próximamente 
Taringa! está en boca de todos, y no es para menos, es uno de los sitios que más tráfico tiene en Argentina (con una gran expansión también en America Latina) y mantiene una empinada línea de crecimiento, superando en el tiempo a gigantes como Mercadolibre, Clarín y Fotolog.
Mucho se habla del contenido, de sus comienzos, de su fundador y de sus actuales dueños, pero poco se ha escrito sobre la infraestructura técnica de este gigante que a la fecha podría considerarse un ejemplo de proyecto web cuyo crecimiento se basa en una comunidad muy participativa y su expansión en el clásico boca en boca.
Alberto Nakayama es socio principal en el proyecto junto a Hernán y Matías Botbol y además es el encargado de la parte técnica del sitio. A través de la buena onda y predisposición de Matías pude contactarme con él y hacerle unas preguntas sobre el funcionamiento y el mantenimiento de un proyecto tan grande y en expansión como lo es Taringa!
¿Alberto, cómo es a grandes rasgos la estructura técnica de taringa?
Taringa! cuenta con
- 5 webservers de contenido dinámico
- 2 webservers de contenido estático
- 3 ram servers
- 2 servidores que funcionan como search engine.
- 11 servidores de bases de datos usando MySQL
Todos los servidores corren Gentoo Linux. Los webservers corren una versión ínfimamente modificada de lighttpd.
Para tener redundancia se implementó un simple sistema de comunicación interna usando netcat que comunica eventos, estado y carga. En base a esa información se quitan servidores de los pooles para evitar errores.
Para la comunicación entre webservers y DB se desarrolló un proxy que mantiene conexiones permanentes y nos permite ejecutar prepared statements.
¿Encontraste algún tipo de limitación en el software que utilizan (o que utilizaron) debido a la carga de usuarios?
La mayor limitación que encontré en el desarrollo de Taringa! fue la gran cantidad de consultas a la base de datos que genera la interacción con los usuarios, siempre teniendo en cuenta que desde siempre fuimos una empresa que necesitó optimizar recursos para poder subsistir y no contábamos con la posibilidad de adquirir grandes equipos de marcas conocidas. Al momento de hoy no encontré todavía una solución definitiva y es necesario mantenerse optimizando.
En el momento en que las partes, comunmente Apache, PHP y MySQL y/o equivalentes de otras marcas, no te entran más en un solo box, es necesario empezar a separar. Cuando se empieza a separar, inevitablemente se agrega un overhead, que es el tiempo de conexión entre las partes. Luego, en el momento de escalar, se siguen agregando más y más overheads porque cada parte al mismo tiempo está dividida/replicada/distribuida en diferentes particiones/equipos/redes/datacenters y hasta países/continentes en ciertos casos.
¿De cuanto ancho de banda disponen para soportar más de 2.500.000 pageviews por día? ¿Que tasas de transferencia están manejando?
Te corrijo una cosa: Diariamente Taringa no tiene >2.900.00 visitas sino pageviews. Pageviews tiene >13.000.000.
En este momento Taringa! al estar bastante optimizado utiliza aproximadamente 120M de ancho de banda en contenido dinámico y 50M de contenido estático (css, logos e iconitos).
Optimizamos los íconos para que los más utilizados se encuentren todos juntos dentro de una misma imagen, por ej http://i.t.net.ar/images/big1v8.gif. Al ser contenido estático utilizamos otro dominio para que no haya desperdicio de tráfico de cookies. De esta forma se ahorra tiempo de carga, y transferencia.
(Alberto Nakayama, Matias y Hernán Botbol en Newsweek)
¿Cuantas personas manejan el/los servers de Taringa?
Actualmente los servidores son administrados solamente por mí.
A propósito, estamos buscando Administrador. Si conocés alguno por favor hacele llegar nuestra búsqueda (http://taringa.net/busquedas/).
¿Que políticas de escalabilidad tienen hoy? ¿Que sucede cuando hay picos de transferencia?
En este momento llegamos a un nivel de escalabilidad que nos permite sumar equipos y agregarlos al sub-grupo que lo necesite, ya sea, web, ram, db, o search en solo una hora, y el nuevo servidor inmediatamente alivia la carga del resto de los servidores del mismo sub-grupo.
Actualmente estamos agregando un promedio de 2 equipos por mes. Generalmente el día que vamos al datacenter a conectar los servidores nuevos se envían los mails necesarios para adquirir otros 2.
Hoy en día podemos soportar el 99% de los picos, siendo ese 1% picos muy poco frecuentes que pueden llegar a requerir por pocos minutos el doble de hardware con el que contamos. En ese 1% utilizamos el queue y si es necesario, mostramos errores.
¿Cuales fueron los hechos que mas dañaron el uptime desde que manejan taringa?
En nuestro desarrollo, el uptime se vio dañado en muchas ocasiones debido a diferentes razones: Insuficiencia de hardware, cuellos de botella, errores humanos, inmadurez de escalabilidad, features poco optimizadas, “Single points of failure” y falta de redundancia y/o falla en los procesos, problemas de red, etc.
Uno puede leer varios libros sobre escalabilidad y high availability, pero cada caso es un mundo aparte, y esos libros son en general apuntados a compañías con high availability of dollars.
¿Como manejan los “problemas de seguridad” del sitio? ¿Tienen políticas de auditoría?
Tenemos auditorías regularmente, intentamos ser lo más cautos posibles, nos informamos, ponemos trampas, mostramos falsos errores, metemos sleeps, y bueno, todos esos truquitos.
Muchas gracias Alberto por tu tiempo y a Matías por tu predisposición.
0 comentarios:
Publicar un comentario