Por si no lo conoces, Karmacracy es un acortador de URLs desarrollado en Bilbao por Jordi Martí natural de Donosti (pero los de Bilbao nacen donde les da la gana) y Alex Dolara natural a secas.
Como todo servicio en Internet, Karmacracy cuenta con una infraestructura tecnológica que lo sustenta y lo hace posible, infraestructura que vamos a conocer en las siguientes líneas.
El proyecto lleva en marcha en fase beta desde mayo del 2010 y este próximo día diecinueve de marzo va a abandonar ese estado para dar paso a una nueva versión estable donde se incorporarán bastantes mejoras y features al servicio.
Uno de los principales objetivos de Karmacracy es que el sistema sea rápido lo cual ha planteado algunos retos a nivel técnico y presenta otros que deberán ser resueltos en el futuro.
Lo que se ve, el frontend
El frontend de Karmacracy está programado en PHP 5 sin hacer uso de frameworks ni herramientas de terceros. Implementa un sistema de templates propio así como una infraestructura de desarrollo basada en el patrón de diseño MVC que han diseñado ellos mismos.
El servicio requiere de un tiempo de respuesta lo más corto posible y utilizando frameworks de terceros se te escapa un poco el control de las manos.
En todo caso para futuros productos dependientes del servicio el equipo de desarrollo ha decidido hacer uso de Symfony puesto que la optimización necesaria para esos nuevos productos no es tan fuerte.
Arquitectura de sistemas detrás del frontend
El frontend está alojado en Amazon EC2. El equipo de Karmacracy nombra sus máquinas virtuales con nombres de robots a los que les tienen especial cariño o aprecio, así nos encontramos con workers llamados NONO1 … NONON (Nono es el robot de Telémaco en Ulises XXXI).
Hay un balanceador ELB de Amazon que divide las peticiones entre varios de estos “NONOS“ que ejecutan Apache y PHP5. El sistema aumenta o disminuye la cantidad de NONOs en función de la carga máxima prevista.
Para el Widget se pone a trabajar a RODNEY (de la película Robots) que se encarga de servir las páginas del Widget de Karmacracy. Al igual que los NONOs ejecuta Apache y PHP5.
RODNEY hace uso exhaustivo de memcache y es independiente de la web de Karmacracy y del acortador de URLs.
Lo que no se ve, el backend
Karmacracy hace uso del servicio Amazon RDS para bases de datos MySQL. La funcionalidad ofrecida por RDS con respecto al coste es muy ventajosa, los que estén familiarizados con el servicio ya saben que no es necesario preocuparse ni por el mantenimiento ni por los backups.
La posibilidad de restaurar un backup para desarrollo en pocos minutos permitiendo hacer pruebas sobre datos reales sin molestar a los usuarios es utilizada con regularidad por el equipo de desarrollo de Karmacracy en su quehacer diario.
La arquitectura de bases de datos del servicio cuenta con una configuración de replicación de datos master -> esclavos para aumentar la seguridad de los datos.
También hacen uso de forma complementaria de una base de datos no relacional MongoDB pensando también en la posible escalabilidad que ofrecen las bases de datos NoSQL.
El mecanismo de conteo de kclicks generados en el acortador, que es la parte más crítica del mismo ha sufrido algunos cambios durante el año y medio que lleva en marcha el servicio.
Al principio, durante el prototipo, cada click se almacenaba en la base de datos lo cual generaba problemas , obvios, en momentos de saturación por lo que decidieron implementar una cola memcache que no estaba falta de problemas puesto que si el servidor se reiniciaba, la cola se perdía.
Al final decidieron que cada click generara un pequeño archivo en un árbol de cache en el sistema de ficheros (que nunca se cae claro) y un demonio los va insertando en la base de datos.
No tengo muy claro como afectará esto último al rendimiento cuando el sistema tenga una masa crítica de usuarios establecidos puesto que no es lo más óptimo. Yo habría optado por hacer un servicio intermedio que siempre esté residente en memoria y se encargue de ello.
Cada click y enlace acortado que se genera provoca una sucesión de eventos encargados de recalcular y cachear determinada información que al final acaba afectando los rankings que se pueden ver en la web, o incluso en la entrega de un premio virtual, una nut.
Estos eventos se dividen en procesos individuales de trabajo que son enviados a diferentes nodos workers que se encargan de procesarlos y ejecutarlos, más tarde hablaremos más de ellos.
Por último y para mejorar la transparencia del servicio, el proceso redirector, el que te envía de un kclick a la URL original, esta optimizado y es independiente de la base de datos y gestores de cache, de forma que si alguno de ellos cae, siempre habrá algo que lo reemplace a modo de fallback.
¿Y qué hay de la escalabilidad?
Obviamente, MySQL tiene límites de escalabilidad horizontal y más en un servicio de acortador de URLs donde los accesos deben ser extremadamente habituales. Por ello el equipo de desarrollo de Karmacracy ha empezado a trabajar en paralelo en una arquitectura de sistemas donde MySQL es reemplazado por MongoDB.
Si cada click genera un INSERT en la base datos es fácil imaginarse el número de registros que tienen aunque yo me hubiera decantado por otras soluciones antes de dar el salto a MongoDB como por ejemplo, MySQL Cluster.
En Karmacracy optaron por MongoDB debido en parte a la curva de aprendizaje que es muy suave y que está en un estado bastante maduro y tiene una base de usuarios y comunidad bien asentada.
Para los procesos que son enviados a los workers, optaron por utilizar Gearman. El equipo de desarrollo ha generado un framework de gestión de procesos que puede invocar proceso offline en base a eventos ocurridos en la web o en otros procesos.
La programación de un proceso es completamente independiente y no interfiere con el resto de procesos o sistemas. Así es posible desarrollar pequeños trozos de código, llamémosle snippets que pueden ser testeados de forma independiente y ser puestos en producción de forma ágil.
De esta manera generan pequeños demonios que cachean enlaces (o que invalidan dicha caché), procesos que insertan clicks, procesos de sincronización entre MySQL y MongoDB, procesos de cálculos y estadísticas, premios, etc.
Aunque parece ser que German no anda exento de bugs, el equipo de desarrollo de Karmacracy ha conseguido lidiar con ello y mantenerlo completamente estable en producción no sin añadir unos hacks para mejorar su estabilidad y funcionamiento.
¿Con qué herramientas se ha construido toda esta historia?
Para diseño, se usa Mac, con Sublime. Los desarrolladores usan Ubuntu, y utilizan Eclipse. Usan control de versiones basado en SVN, aunque están haciendo pruebas con Git.
Utilizan un motor propio de plantillas que permite que un diseñador entre a modificarlas directamente y eso facilita la tarea.
Conclusión
En Karmaracy hacen uso exhaustivo de herramientas de código abierto y software libre y de servicios en la nube de Amazon para crear un sistema de acortador de URLs que, al menos a mi, me parece bastante diferente a lo que hay en el mercado.
Quizás yo no hubiera elegido PHP para un sistema tan crítico y me hubiera decantado por Python o Java y una solución NoSQL desde el primer momento o bien un MySQL Cluster en lugar de una arquitectura de replicación master-slave que no ofrece escalabilidad.
Lo que está claro es que la gente detrás del proyecto se divierte creando el producto y que en España no es habitual ver empresas que se arman de valor y se echan a la calle a presentar un producto en lugar de ofrecer “recursos de consultoría“ que es la salida fácil.
También cabe destacar como el servicio no se parece en nada a YOURLS otro servicio de recorte de URLs programado en PHP y creo que bastante de andar por casa comparado con lo que acabo de explicar.
Sin más cierro el post deseándoles mucha suerte y éxito desde Genbeta Dev al proyecto y sus impulsores.
Sitio web | Karmacracy
Más en Genbeta Dev | La tecnología que hay detrás de Instagram, Las tecnologías que usa el hype del momento, pinterest
