Symfony y 3 millones de usuarios, nuestro dia a dia
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Symfony y 3 millones de usuarios, nuestro dia a dia

on

  • 7,645 views

Ofertix.com ha crecido hasta convertirse en un proyecto que actualmente da servicio a una base de datos de casi 3 millones de usuarios con un equipo de menos de 10 personas y menos de 20 servidores. ...

Ofertix.com ha crecido hasta convertirse en un proyecto que actualmente da servicio a una base de datos de casi 3 millones de usuarios con un equipo de menos de 10 personas y menos de 20 servidores. Durante esta sesión expondremos técnicas implementadas en el proyecto, en el proyecto, su arquitectura y el sistema de deploy de código.

Statistics

Views

Total Views
7,645
Views on SlideShare
2,269
Embed Views
5,376

Actions

Likes
4
Downloads
195
Comments
0

8 Embeds 5,376

http://www.symfony.es 5306
http://symfony.es 50
http://www.linkedin.com 12
http://twitter.com 2
http://translate.googleusercontent.com 2
https://www.linkedin.com 2
http://www.slideshare.net 1
https://twitter.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Aquí explicar que és Ofertix.\nI rápidament com funciona.\nExplicar que és com obrir petites botigues cada dia (microsites). (s’enllaçarà amb q podem invalidar caches a nivell de microsite)\n
  • \n
  • \n
  • \n
  • \n
  • Servidor web = NGINX\nGranja PHP = php-fpm\nLogística té molt de pes al projecte. Pantalles molt complexes amb Sencha.\nSCM = Supply Chain Management\n
  • \n
  • \n
  • Nos permite dominar nuestras herramientas y sistemas. Pocas dependencias.\nAdemás nuestros programadores son más polivalentes.\n
  • \n
  • Vendemos en internet si la web no va, no comemos.\nTenemos los mínimos proveedores externos. Ellos no están tan comprometidos con nuestro negocio como nosotros.\n
  • \n
  • No tiramos código, lo evolucionamos.\nNos pensamos muy bien las cosas antes de decidir que debemos desarrollar algo.\n
  • \n
  • Cheap Off The Shelf\nTecnologías simples y genéricas.\nPodríamos utilizar powermta, o una aplicación de datawarehouse o un framework propio hecho de oro...\nEsto no mola del todo pq hacemos pocos desarrollos que podamos publicar para que otros los usen.\n\n
  • \n
  • \n
  • \n
  • \n
  • teniamos la idea de aumentar el equipo de programadores\ny evolucionar el código\ny no queríamos reinventar la rueda\n\n\n
  • \n
  • desarrollo en paralelo a la operación de ofertix1. \nNo paramos de vender.\nHemos evolucionado ese desarrollo durante 2 años y pico\n
  • \n
  • \n
  • \n
  • Ponemos eventos en las partes susceptibles de ser ampliadas. Sobretodo para notificaciones o acciones a realizar cuando pasa alguna cosa.\n
  • Para generar documentación.\nProcesos de preparación de elementos de la web (pej fotografías)\n\n
  • \n
  • No tenemos problemas de rendimiento por código mal escrito (si acaso por malas ideas). Pero si que podemos tener problemas de “rendimiento” en el desarrollo si quien tiene que tocar tu código no lo entiende.\n
  • \n
  • \n
  • \n
  • \n
  • Putada si tenemos que reiniciar, pero eso no ha pasado nunca. Lo meteremos en Redis, algún día.\n
  • \n
  • \n
  • Memcached va a morir.. Nuestro futuro es redis. Estamos en ello.\n
  • \n
  • \n
  • \n
  • \n
  • Datos de clientes, ofertas exclusivas, etc..\n
  • DKIM es una firma digital asimétrica aplicada a cada correo para validar que el remitente es quien dice ser.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Aprofitem la CPU que de nit no fem servir firmant amb el cluster de PHP\nEls nostres servidors SMTP fan de buffer. Així no tenim el procés parat. Un servidor SMTP serà sempre millor client SMTP que nosaltres.\n
  • \n
  • \n
  • \n
  • Per a evitar bloquejar les taules amb consultes llargues. Sí un select també bloqueja.\n
  • con algunos ajustes en referencia a la transaccionalidad\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Cada uno se como su ...erda.\n
  • \n
  • Procurem que la gent faci les seves hores i no més. Cal estar descansats.\nOdiem l’stress.\n
  • MTTR = Mean Time To Recovery (o Resolve)\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Parlem de netejar cachés, APC, etc?\n\n
  • Parlem de netejar cachés, APC, etc?\n\n
  • Parlem de netejar cachés, APC, etc?\n\n
  • Parlem de netejar cachés, APC, etc?\n\n
  • Parlem de netejar cachés, APC, etc?\n\n
  • Parlem de netejar cachés, APC, etc?\n\n
  • \n
  • \n
  • \n
  • \n
  • Parla d’etsy\n
  • \n
  • Preguntar quantes persones pensen que som?\n
  • Explicar que confiem amb les persones i la seva responsabilitat\nQue busquem el balanç entre lo personal i lo professional\nQue la gent quan porta moltes hores currant fa fallos\nQue intentem mantenir el Focus. \nMultidisciplinar\n
  • he comptat uns 12 servidors per ofx\n
  • \n
  • \n
  • \n

Symfony y 3 millones de usuarios, nuestro dia a dia Presentation Transcript

  • 1. Symfony y 3 millonesde usuarios, nuestro día a día Jordi Llonch <jordi.llonch@ofertix.com>
  • 2. Me presentoJordi Llonchjordi.llonch@ofertix.comjordillonch
  • 3. ¿Qué veremos?
  • 4. ¿Código?
  • 5. ¿Código? NO
  • 6. ¿Técnicas?
  • 7. ¿Técnicas?ALGUNAS
  • 8. ¿Filosofía?
  • 9. ¿Filosofía?SUPONGO QUE SI
  • 10. ¿Lo más interesante?
  • 11. ¿Lo más interesante? Vuestras preguntas
  • 12. ¿Bueno, pero qué?
  • 13. El proyecto
  • 14. Vendemos productos yservicios a precios interesantes por internet
  • 15. Cada día abrimos 2-6 pequeñas tiendas durante 3-4 días
  • 16. Nuestros usuarios entran de golpe (cuando ven nuestro email)
  • 17. Algunos números• 5M visitas únicas mensuales.• 100M páginas servidas/mes.• 90M de correos enviados cada mes• 50k pedidos al mes
  • 18. Sólo contamos con nuestros recursos
  • 19. Alcance
  • 20. sistemas frontal backoffice mailing SO BBDD SEO CRM programaciónred serv. web caché tickets generación masiva granja PHP monitorización SCM envío masivo SMTP SAN producción campañas firmabackup NoSQL Marketing gestión de Cachés la lista de correo monitorización mini cloud privado VPNs
  • 21. Alcance x 2
  • 22. Principios IT
  • 23. Minimizar lastecnologías que usamos
  • 24. Somos los únicosresponsables de IT
  • 25. Intentamos tener clarodónde queremos llegarpero sabemos que hoy no llegamos
  • 26. COTS
  • 27. COTSNos mola lo estándar
  • 28. Nuestro equipo de I+D
  • 29. Nuestro código
  • 30. ¡es symfony!
  • 31. ¿porqué?
  • 32. estandarización
  • 33. productividad
  • 34. lo escribimos desde 0 en 6 meses
  • 35. 2 programadores
  • 36. A tener en cuenta
  • 37. clases doctrine modelo != clases lógica negocio
  • 38. Eventos (decoupling)
  • 39. Colas (procesos largos)
  • 40. Encapsula lo que va a cambiar ylo que necesites probar
  • 41. Escribe código para los otros compañeros no para el compilador
  • 42. Arquitectura
  • 43. Servidores web y granja de renderización PHP
  • 44. INTERNET FRONTALES CONTENIDO ESTATICORENDERIZADORES PHP BASE DE DATOS Caché SMTP Workers de procesos
  • 45. Sesiones
  • 46. memcached
  • 47. Cache
  • 48. Cacheamos: • Partes de la web que pueden ser estáticas (por ej. proceso de compra) • Información relativa a negocio muy usada pero que no es necesario que esté actualizada • assets (css, js, imágenes...)
  • 49. memcached redis
  • 50. Invalidación de caché• del proceso de compra (invalida la app)• de asset (invalida nuestro script deployer)
  • 51. Envío de mail
  • 52. Requisitos
  • 53. Cada noche envía3 millones de emails
  • 54. Todos personalizados
  • 55. Firmados con DKIM
  • 56. ¿cómo?
  • 57. Lo hacemos en 2 pasos (decoupling)
  • 58. 1r paso
  • 59. Seleccionamos todos los destinatarios y generamos el contenido
  • 60. Seleccionamos todos los destinatarios y generamos el contenido Tardamos 1 hora
  • 61. 2º paso
  • 62. entregar el correo
  • 63. ¿cómo?
  • 64. • Varios procesos concurrentes cogen packs de emails y los entregan a los servidores SMTP• Los servidores SMTP los entregan a los destinos• Firmamos con DKIM utilizando el clúster de renderización PHP
  • 65. Entregamos en 3 horas
  • 66. Entregamos en 3 horas Si Hotmail nos deja...
  • 67. Data warehouse
  • 68. Necesitamos medirpara tomar decisiones
  • 69. recolección de datosdesde la BBDD réplica
  • 70. Cargamos los datos en un copo de nieveen un MySQL dedicado
  • 71. Los años pasan yse nos piden cosas nuevas...
  • 72. ergo
  • 73. La base de datos evoluciona y el código también
  • 74. doctrine migrations
  • 75. En el99% de las migracionesañadimos campos
  • 76. si la tabla es pequeña < 300 Mb ó < 300k registros
  • 77. ejecutamos migración y actualizamos código
  • 78. si la tabla es grande
  • 79. ejecutamos migración a las 4:00h
  • 80. lo hemos hecho 4 veces
  • 81. y la gente compra a esas horas...
  • 82. Vale, y con el código?
  • 83. Cada programador esresponsable de su código
  • 84. Deployamos 5 o 6 veces al día
  • 85. A veces fallamos ytenemos que correr
  • 86. por eso tenemos un MTTR muy bajo
  • 87. ¿Cómo?
  • 88. DeployerAl rescate!
  • 89. Desarrollo en Sf2 :)
  • 90. Ideas basadas en capistrano
  • 91. Requisitos
  • 92. • Adaptar configuraciones para producción
  • 93. • Adaptar configuraciones para producción• Verificaciones del código y configuración
  • 94. • Adaptar configuraciones para producción• Verificaciones del código y configuración• Deploy en 8 servidores simultáneamente
  • 95. • Adaptar configuraciones para producción• Verificaciones del código y configuración• Deploy en 8 servidores simultáneamente• 4 tipos de deploy
  • 96. • Adaptar configuraciones para producción• Verificaciones del código y configuración• Deploy en 8 servidores simultáneamente• 4 tipos de deploy• Migraciones de la base de datos
  • 97. • Adaptar configuraciones para producción• Verificaciones del código y configuración• Deploy en 8 servidores simultáneamente• 4 tipos de deploy• Migraciones de la base de datos• Rollback
  • 98. ¿cómo?
  • 99. script preparación de código
  • 100. subimos código vía git
  • 101. aplicación de deploy• download• code2production• migrate• rollback• status
  • 102. mi gato poniendo código en producción
  • 103. Organización
  • 104. Equipo humano
  • 105. • 1 responsable de IT• 5 programadores PHP• 1 programador .NET y android• 1 project leader• 1 administrador de sistemas
  • 106. ratios• 1 programador / 600 k usuarios• 1 administrador de sistemas para cada 3M de usuarios ;)• 1 servidor para cada 250 k usuarios
  • 107. FIN Autores:Joan Valduvieco Jordi Llonch
  • 108. ¿Quién se apunta?
  • 109. Gracias