SpringIO 2012 Madrid-Escalabilidad con Grails

1,638
-1

Published on

Presentación hecha en el SpringIO 2012 en Madrid España. Donde se muestra un poco de la experiencia adquirida durante el desarrollo y puesta a producción de la plataforma de eCommerce mas grande de LatinoAmerica construida con Grails

Published in: Technology
3 Comments
3 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,638
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
34
Comments
3
Likes
3
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • SpringIO 2012 Madrid-Escalabilidad con Grails

    1. 1. De cero a 2M de usuariosGrails, 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.
    2. 2. Agenda• ¿Porque Groovy/Grails?• Negocio• Diseño inicial• Infraestructura• Problemas• El futuro
    3. 3. ¿Porque Groovy/Grails?
    4. 4. ¿Porque Groovy/Grails?• Aburrido de Java
    5. 5. ¿Porque Groovy/Grails?• Aburrido de Java• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow
    6. 6. ¿Porque Groovy/Grails?• Aburrido de Java• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow• JSF, Struts, Flex... <-- NO por favor
    7. 7. ¿Porque Groovy/Grails?• Aburrido de Java• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow• JSF, Struts, Flex... <-- NO por favor• Rails en 2004
    8. 8. ¿Porque Groovy/Grails?• Aburrido de Java• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow• JSF, Struts, Flex... <-- NO por favor• Rails en 2004• Groovy. Gran lenguaje.
    9. 9. ¿Porque Groovy/Grails?• Aburrido de Java• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow• JSF, Struts, Flex... <-- NO por favor• Rails en 2004• Groovy. Gran lenguaje. • Productividad
    10. 10. ¿Porque Groovy/Grails?• Aburrido de Java• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow• JSF, Struts, Flex... <-- NO por favor• Rails en 2004• Groovy. Gran lenguaje. • Productividad • Comunidad y ecosistema
    11. 11. ¿Porque Groovy/Grails?• Aburrido de Java• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow• JSF, Struts, Flex... <-- NO por favor• Rails en 2004• Groovy. Gran lenguaje. • Productividad • Comunidad y ecosistema• Grails 0.5-0.6 en 2007
    12. 12. ¿Porque Groovy/Grails?• Aburrido de Java• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow• JSF, Struts, Flex... <-- NO por favor• Rails en 2004• Groovy. Gran lenguaje. • Productividad • Comunidad y ecosistema• Grails 0.5-0.6 en 2007• Primer aplicación productiva en 2008, Grails 0.6
    13. 13. ¿Porque Groovy/Grails?• Aburrido de Java• Soy fanático de Hibernate, Spring y SpringMVC, WebFlow• JSF, Struts, Flex... <-- NO por favor• Rails en 2004• Groovy. Gran lenguaje. • Productividad • Comunidad y ecosistema• Grails 0.5-0.6 en 2007• Primer aplicación productiva en 2008, Grails 0.6• Me gusto tanto que hice screencast en Groovy.org.es
    14. 14. Negocio Una tienda en linea, con una ampliay creciente gama de servicios y productos
    15. 15. Negocio• Ventas en grupo• Cupones.• Viajes, electrodomésticos, etc• Campañas de email masivas.• Campañas de publicidad masivas.
    16. 16. Diseño inicialGrails, Terracotta, RabbitMQ & mySQL
    17. 17. Primera implementación• En 8 semanas se construye en Berlin las bases de la plataforma, con 4 desarrolladores• Salimos a producción en Septiembre 2010 en México y Argentina• En Octubre 2010 salimos en producción en Emiratos Arabes (Dubai)• En noviembre el equipo de desarrollo crece en México• El desarrollo continua para México con un equipo de 5 desarrolladores
    18. 18. Grails• Grails 1.3.4 • GORM • Servicios • Controllers y TagLibs • Jobs
    19. 19. GORM, lo bueno• Facilidad de crear modelos • Modelos ricos• Consultas • Criteria • DynamicFinders• Actualización del esquema de base de datos
    20. 20. 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)
    21. 21. Servicios, lo bueno• Lógica de negocio• Servicios que “escuchan” eventos-RabbitMQ• Extensivo uso de Dependency Inyection• Composición, agregación• Reglas de negocio flexibles
    22. 22. 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.
    23. 23. Controllers, lo bueno• Ridículamente simple• Generar JSON/XML es trivial• Reglas de mapeo, muy sencillo y flexible (URLMappings)• Totalmente desacoplado de la vista
    24. 24. Controllers, lo malo• Nada, IMHO lo perfecto de Grails
    25. 25. TagLibs, lo bueno• Súper simple crearlas :)• Apoyo de Dependency Injection para acceder a servicios, o a cualquier componente.• Condicionar la generación de contenido• Llenar plantillas (fragmentos de una página)
    26. 26. TagLibs, lo malo• Usarlas como scriptlets
    27. 27. 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
    28. 28. 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.
    29. 29. Escalabilidad y DisponibilidadVitales para estar en un negocio muy competitivo
    30. 30. Números•200k-300k visitas diarias•1.5M > pageviews diarias•Hasta 80K usuarios concurrentes•20K-50K usuarios nuevos al día•1000-3000 compras diarias
    31. 31. Terracotta• Cache distribuido• Evitamos accesos a la BD• Guardamos Objetos Java, HTML, JSON, XML • Entidades de Hibernate • Páginas completas • Fragmentos de páginas
    32. 32. Terracotta• Usamos EhCache como “fachada” • En desarrollo no usamos Terracotta • En producción y QA configurado • El código aplicativo no se ve modificado
    33. 33. 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
    34. 34. 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
    35. 35. RabbitMQ• Servicio de mensajería• Diferente a JMS, AMQP es un protocolo programable• Escrito en Erlang• Muy robusto, estable• Casi cero administración• Desarrollado por vmWare
    36. 36. RabbitMQ• Procesamiento asíncrono• Procesos muy tardados • Envío de email • Consultas pesadas (reportes financieros)• Integración con otras aplicaciones
    37. 37. 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.
    38. 38. 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.
    39. 39. 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.
    40. 40. 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.
    41. 41. mySQL• ¿que puedo decir?
    42. 42. mySQL• Tenemos instalada una versión “afinada” 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
    43. 43. MongoDB• Principalmente almacenamos documentos con la bitácora de cambios en algunos objetos del modelo.• Grails Audit Logging Plugin • Guarda un registro por cada cambio. No nos convencía este enfoque. La tabla de auditoria crecía demasiado (millones de registros en unas semanas) • Activando los handlers, los atributos alterados se serializan a JSON y se almacenan de manera asíncrona en MongoDB• Tenemos una aplicación con Grails 2.0 con el plugin de MongoDB• MongoDB instalado en otra maquina diferente
    44. 44. Redis• Excelente opción para usarlo como Cache• Redis puede almacenar ‘Estructuras de datos’• Provee soporte para operar sobre esas estructuras. • incr, incrBy, set• Lo usamos para guardar estadísticas. • Compras por producto, etc. • Redis se encarga de la concurrencia
    45. 45. ElasticSearch• Muy buena opción para busquedas ‘Full Text Search’• Plugin de Grails para usarlo
    46. 46. Infraestructura
    47. 47. Maquinas• 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
    48. 48. Características• 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
    49. 49. 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
    50. 50. Solucionar problemas• Necesitas métricas, indicadores• Medición• ¿Profiler?• ¿JMX?
    51. 51. JavaMelody• Analiza todas las peticiones a tu aplicación• Nos ayudo a detectar • Cuellos de botella • Queries ineficientes • Servicios mas usados• OpenSource, Apache 2.0• Activado en producción, penalización mínima, imperceptible.• Plugin para Grails
    52. 52. CompetitividadDatos de Alexa.com del día 21 de Octubre de 2011
    53. 53. “Empresa del Año del Comercio Electrónico y losNegocios por Internet en México”
    54. 54. ¿Como lo logramos?
    55. 55. Comunidad• La comunidad Groovy/Grails es fantastica.• Muchos plugins para Grails• Grails es un campo fértil para crear nuevos plugins• Es sencillo participar.• Hemos contribuido a varios plugins • Export • SpringSecurity • ReCaptcha • SpringSocial • Scala
    56. 56. Q&ATexto
    57. 57. Créditos fotos• http://flic.kr/p/e61Pt • http://flic.kr/p/2wGvZi• http://flic.kr/p/7cxoek • http://flic.kr/p/7jLN6x• http://flic.kr/p/5vSqgq • http://flic.kr/p/2VvzMw• http://flic.kr/p/6K9jb8 • http://flic.kr/p/9c7z9T• http://flic.kr/p/6h8UoU • http://flic.kr/p/J1NKm• http://flic.kr/p/24GsCj
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×