Symfony y 3 millones de usuarios, nuestro dia a dia

7,688 views

Published on

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.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,688
On SlideShare
0
From Embeds
0
Number of Embeds
5,352
Actions
Shares
0
Downloads
202
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • \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

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

    ×