De cero a 1.7 M de usuarios

Grails, opción real para sitios web de alta carga y escalabilidad.Una experiencia al crear la más grande

plataforma de eCommerce con Grails en Latinoamérica.

Agenda

• Negocio

• Diseño inicial

• Infraestructura

• Problemas

• El futuro

NegocioUna tienda en linea, con una amplia

y creciente gama de servicios y productos

Negocio

• Ventas en grupo

• Cupones.

• Pero no solo cupones...

• Campañas de email masivas.

• Campañas de publicidad masivas.

Diseño inicialGrails, Terracotta, RabbitMQ & mySQL

Grails

• Grails 1.3.4

• GORM

• Servicios

• Controllers y TagLibs

• Jobs

GORM, lo bueno• Facilidad de crear modelos

• Modelos ricos

• Consultas

• Criteria

• DynamicFinders

• Actualización del esquema de base de datos

GORM, lo malo• No es posible probar DynamicFinder y Criteria de forma

unitaria

• Pruebas integrales, a veces toma mucho tiempo

• Es sencillo cometer errores debido a la facilidad

• Olvidar crear indices

• Iterar grandes colecciones

• Dejar que Grails nombre relaciones (tablas o campos)

Servicios, lo bueno

• Lógica de negocio

• Servicios que “escuchan” eventos

• Extensivo uso de Dependency Inyection

• Composición, agregación

• Reglas de negocio flexibles

Servicios, lo malo• Abusar de Dependency Inyection

• Referencias circulares

• No es tema de Grails exclusivamente, con Spring se presenta también.

• Duplicar nombres de Servicios, en diferentes paquetes

• Olvidar quitar la administración transaccional cuando no es necesaria.

Controllers, lo bueno

• Ridículamente simple

• Generar JSON/XML es trivial

• Reglas de mapeo, muy sencillo y flexible (URLMappings)

• Totalmente desacoplado de la vista

Controllers, lo malo

• Nada

TagLibs, lo bueno

• Estúpidamente simple crearlas :)

• Apoyo de Dependency Inyection para acceder a servicios, o a cualquier componente.

• Condicionar la generación de contenido

• Llenar plantillas (fragmentos de una página)

TagLibs, lo malo

• Usarlas como scriptlets

Grails, en general

• Permite que un desarrollador Java, explote su conocimiento.

• Aumenta la productividad debido a el uso de “Convención sobre Configuración”

• Incrementa brutalmente la facilidad de convertir requerimientos de negocio en código ejecutable

Grails

• En mi humilde opinión, la mejor opción para desarrollo web en Java, de cualquier tamaño o requerimiento

• Disclaimer: Es solo mi experiencia personal, no puedo garantizar el mal uso de Grails. También puedo equivocarme. Es mi punto de vista como desarrollador.

Negocio

• En Agosto de 2010 @dvd2k5 me dijo:

• Hey domix; en un año tendremos un millón de usuarios

• @domix

• :O

Escalabilidad y Disponibilidad

Vitales para estar en un negocio muy competitivo

Terracotta• Cache distribuido

• Evitamos accesos a la BD

• Guardamos Objetos Java y HTML

• Entidades de Hibernate

• Páginas completas

• Fragmentos de páginas

Terracotta

• Usamos EhCache como “fachada”

• En desarrollo no usamos Terracotta

• En producción y QA configurado

• El código aplicativo no se ve modificado

Terracotta• IMHO, es una de las mejores piezas de software

jamas escritas en Java

• Robusto, Estable

• Confiable, Ligero

• Casi cero administración

• Configuración muy sencilla

• Uptime de meses en producción

Terracotta

• Lo usamos para clusterizar sesiones HTTP, pero no quedo productivo

• No quería cargar con mas trabajo a Terracotta

• Evitar tener un solo punto de falla

• También lo usamos muy poco tiempo para clusterizar Jobs con Quartz

RabbitMQ• Servicio de mensajería

• Diferente a JMS

• Escrito en Erlang

• Muy robusto, estable

• Casi cero administración

• Desarrollado por vmWare

RabbitMQ

• Procesamiento asíncrono

• Procesos muy tardados

• Envío de email

• Consultas pesadas (reportes financieros)

• Integración con otras aplicaciones

RabbitMQ, lo malo

• No hay muchas herramientas de administración/monitoreo

• Las que hay son poco “amistosas”

• Cuando falla, falla muy duro

• Los logs de error son como Hebreo antiguo o mas bien como lenguaje Orco.

RabbitMQ, lo malo

• No hay muchas herramientas de administración/monitoreo

• Las que hay son poco “amistosas”

• Cuando falla, falla muy duro

• Los logs de error son como Hebreo antiguo o mas bien como lenguaje Orco.

RabbitMQ, nada malo• Antes he usado varios servicios de

mensajería

• Todos ellos basados en Java

• RabbitMQ ha sido al que he visto que se le ha puesto una carga muy grande, sin necesidad de afinar la configuración.

• IMHO. La mejor opción.

RabbitMQ, nada malo• Antes he usado varios servicios de

mensajería

• Todos ellos basados en Java

• RabbitMQ ha sido al que he visto que se le ha puesto una carga muy grande, sin necesidad de afinar la configuración.

• IMHO. La mejor opción.

mySQL

• ¿que puedo decir?

mySQL• Tenemos instalada una versión “tuneada” por

RackSpace

• Una palabra para describirla: Impresionante

• He vivido engañado por muchos años.

• Un pequeño comportandose como nunca he visto un grande.

• Nuestro mySQL ha soportado +15 millones de queries en un día

Infraestructura2 versiones

Cajas Versión 1• 2 WebServers

• 1 Tomcat 6 con AJP = cluster de 2 Tomcats

• Apache HTTPD con mod_proxy

• 1 DBServer

• 1 Firewall físico

• 1 LoadBalancer físico

• Rackspace Londres

Cajas Versión 2• 4 WebServers

• 2 Tomcat 6 con AJP = cluster de 8 Tomcats

• Apache HTTPD con mod_proxy

• 1 DBServer

• 1 Firewall físico

• 1 LoadBalancer físico

Fierros Versión 2• Dual Quad Core Xeon 2.26 HGZ

• 24 GB de RAM

• 300 GB SAS X 3

• RedHat Enterprise Linux 5.6

• En Hospedaje dedicado en Rackspace Chicago

Problemas

• Quartz Jobs clusterizados

• Ahora corren en una instancia propia

• Indices faltantes en la base de datos

• Consultas muy mal escritas

• Mala configuración del log

Solucionar problemas

• Necesitas métricas, indicadores

• Medición

• ¿Profiler?

• ¿JMX?

Competitividad

Datos de Alexa.com del día 21 de Octubre de 2011

¿Como lo logramos?

Negocio

• En Septiembre de 2011 @dvd2k5 me dijo:

• Hey domix; en un año tendremos 5 millones de usuarios

• @domix

• :O

Estrategia actual y futura

• Hacer la webapp actual lo mas estática posible

• Modularizar la aplicación en un conjunto de servicios

• Usar mensajería para comunicarlos

• Usar Scala como lenguaje complementario a Groovy

• Akka para procesamiento asíncrono

• MongoDB como almacén secundario

• Redis como cache recundario

Estrategia actual y futura

• Convirtiendo los servicios en un API Rest

• clickOnero móvil iOS este año

• clickOnero móvil Android próximo año

• Facebook App próximo año

• Apertura del API próximo año

El equipo

¿Preguntas?

Créditos fotos• http://flic.kr/p/e61Pt

• http://flic.kr/p/7cxoek

• http://flic.kr/p/5vSqgq

• http://flic.kr/p/6K9jb8

• http://flic.kr/p/6h8UoU

• http://flic.kr/p/24GsCj

• http://flic.kr/p/2wGvZi

• http://flic.kr/p/7jLN6x

• http://flic.kr/p/2VvzMw

• http://flic.kr/p/9c7z9T

• http://flic.kr/p/J1NKm