Desarrollo en la nube

521 views

Published on

Como abordar un proyecto web que tiene previsto un gran crecimiento sin temor a morir en el intento...

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Desarrollo en la nube

  1. 1. Desarrollo en la nube Javier Nievas Muñoz CTO en Pynso | CTO en Hitsbook [email_address]
  2. 2. Bienvenidos Antes de empezar... ...algunos “keywords” Nube. Web 2.0. Servidor Web. Servidor de Base de datos. Caché. Aplicaciones Web. Hosting. Uptime. Amazon AWS.
  3. 3. Bienvenidos TARGET Proyectos web con previsión de crecimiento en contenidos y visitas
  4. 4. Objetivo MISIÓN Conseguir que la plataforma web esté online el 99% del tiempo
  5. 5. Objetivo MISIÓN Conseguir que la plataforma web esté online el 99% del tiempo ¿Imposible?
  6. 6. Intro Petición GET/POST Consulta(s) BBDD Generar HTML Servir HTML Servir Media (Imgs, CSS, JS...) Procesos largos Streaming Envío de emails Módulos recurrentes El problema Para entender el problema debemos considerar todos los elementos que intervienen a la hora de servir una página dentro de una aplicación web.
  7. 7. Intro El problema Todo esto consume recursos del servidor: RAM + CPU + HDD + Red
  8. 8. Hosting Servidor compartido Desde 10€/mes Poca capacidad Recursos limitados y compartidos Servidor virtual VPS Desde 30€/mes Capacidad configurable Recursos compartidos pero con reserva de unos mínimos Servidor dedicado Desde 100€/mes Capacidad fija Recursos 100% disponibles Servidor Los recursos de los servidores son finitos y, por tanto, tienen una capacidad limitada. Las opciones habituales que nos hemos encontrado a la hora de contratar un servidor han sido: <ul><li>Servidor compartido
  9. 9. Servidor virtual (VPS)
  10. 10. Servidor dedicado </li></ul>
  11. 11. Hosting Servidor compartido Desde 10€/mes Poca capacidad Recursos limitados y compartidos Servidor virtual VPS Desde 30€/mes Capacidad configurable Recursos compartidos pero con reserva de unos mínimos Servidor dedicado Desde 100€/mes Capacidad fija Recursos 100% disponibles ¡NO SON ESCALABLES! Servidor Los recursos de los servidores son finitos y, por tanto, tienen una capacidad limitada. Las opciones habituales que nos hemos encontrado a la hora de contratar un servidor han sido: <ul><li>Servidor compartido
  12. 12. Servidor virtual (VPS)
  13. 13. Servidor dedicado </li></ul>
  14. 14. Hosting Escalabilidad El gran problema...
  15. 15. Soluciones Hay muchos problemas... … que hay que resolver individualmente para conseguir una plataforma realmente preparada. <ul><li>Servidor web
  16. 16. Servidor Base de Datos
  17. 17. Servir ficheros estáticos
  18. 18. Procesamiento / Envío de emails
  19. 19. Generar HTML
  20. 20. Servidor </li></ul>
  21. 21. Soluciones Servidor Web Típicamente se ha utilizado Apache. <ul><li>Consume mucha memoria
  22. 22. Muchas opciones de configuración que apenas se utilizan
  23. 23. NGINX + FastCGI / uWSGI </li></ul><ul><li>Servidor web
  24. 24. Servidor Base de Datos
  25. 25. Servir ficheros estáticos
  26. 26. Procesamiento
  27. 27. Generar HTML
  28. 28. Servidor </li></ul>
  29. 29. Soluciones Servidor Web <ul><li>Servidor web
  30. 30. Servidor Base de Datos
  31. 31. Servir ficheros estáticos
  32. 32. Procesamiento
  33. 33. Generar HTML
  34. 34. Servidor </li></ul>
  35. 35. Soluciones Servidor Web <ul><li>Servidor web
  36. 36. Servidor Base de Datos
  37. 37. Servir ficheros estáticos
  38. 38. Procesamiento
  39. 39. Generar HTML
  40. 40. Servidor </li></ul>
  41. 41. Soluciones Servidor BBDD Habitualmente se utiliza MySQL y PostGres. Ambos sistemas de BBDD están diseñados para poder escalar. Solución típica : utilizar varios equipos con versiones de sólo lectura de la base de datos, y que todos escriban en una sola, que se encarga de replicarse en la demás. Otras opciones: <ul><ul><li>Cambiar de concepto, y pasarse a otro tipo de BBDD, las no relacionales / NoSQL. Ejemplos: MongoDB, SimpleDB, CouchDB </li></ul></ul><ul><li>Servidor web
  42. 42. Servidor Base de Datos
  43. 43. Servir ficheros estáticos
  44. 44. Procesamiento
  45. 45. Generar HTML
  46. 46. Servidor </li></ul>
  47. 47. Soluciones Servir MEDIA NO utilizar Apache!!! <ul><li>Es matar moscas a cañonazos!
  48. 48. Podríamos usar nginx, pero tampoco es buena idea...
  49. 49. Es una tarea secundaria ¿y si externalizamos este “marrón”?
  50. 50. Utilizar un CDN (p.e. Amazon S3) </li></ul><ul><li>Servidor web
  51. 51. Servidor Base de Datos
  52. 52. Servir ficheros estáticos
  53. 53. Procesamiento
  54. 54. Generar HTML
  55. 55. Servidor </li></ul>
  56. 56. Soluciones Procesamiento Las tareas que requieran un tiempo de procesamiento elevado no pueden ejecutarse en “tiempo de petición”, deben delegarse y ejecutarse en background. <ul><li>Utilizar un gestor de colas de tareas puede ser una idea excelente
  57. 57. Por ejemplo: Celery + Redis </li></ul><ul><li>Servidor web
  58. 58. Servidor Base de Datos
  59. 59. Servir ficheros estáticos
  60. 60. Procesamiento
  61. 61. Generar HTML
  62. 62. Servidor </li></ul>
  63. 63. Soluciones Generar HTML Más del 90% del HTML que se genera visita tras visita es igual al que se ha generado la última vez. ¿Por qué regenerar toda esa información cuando podemos evitarnos esos cálculos simplemente guardando el HTML resultado? <ul><li>Utiliza la caché! -> memcached </li></ul><ul><li>Servidor web
  64. 64. Servidor Base de Datos
  65. 65. Servir ficheros estáticos
  66. 66. Procesamiento
  67. 67. Generar HTML
  68. 68. Servidor </li></ul>
  69. 69. Soluciones Servidor Si el servidor se te queda pequeño... amplíalo. Si se te vuelve a quedar pequeño... vuelve a ampliarlo. Si vuelve a quedarse pequeño... vuelve a ampliarlo. Y si se queda pequeño otra vez.. amplíalo más <ul><li>Servidor web
  70. 70. Servidor Base de Datos
  71. 71. Servir ficheros estáticos
  72. 72. Procesamiento
  73. 73. Generar HTML
  74. 74. Servidor </li></ul>
  75. 75. Soluciones Servidor ¿y si ya no puedes ampliarlo más? -> Contrata otro servidor y reparte las tareas entre ambos. ¿y si se queda pequeño con ese otro? -> Contrata otro más! ¿y si resulta que ahora ya me sobran 2 porque hoy no hay apenas visitas? Erm... ¿me fastidio? <ul><li>Servidor web
  76. 76. Servidor Base de Datos
  77. 77. Servir ficheros estáticos
  78. 78. Procesamiento
  79. 79. Generar HTML
  80. 80. Servidor </li></ul>
  81. 81. Soluciones La nube al rescate! La nube/cloud es el lugar ideal donde alojar este tipo de proyectos. Nos proporciona una plataforma ideal donde servir nuestros proyectos con capacidad para escalarlos “ilimitadamente”. <ul><li>Podemos disponer de tantas máquinas como necesitemos, en el momento en el que las necesitemos.
  82. 82. Pagaremos realmente por el uso real que tenga nuestra plataforma
  83. 83. Y lo mejor, es que podemos conseguir que se regule y ajuste de forma automágica.
  84. 84. Por ejemplo: Amazon EC2 </li></ul>
  85. 85. Soluciones La nube al rescate! En la “nube” podremos disponer de equipos que podemos arrancar bajo demanda montando sobre ellos imágenes de disco previamente preparadas. ¿Qué nos permite esto? Si tenemos poca carga: <ul><li>1 servidor con el Nginx frontal y algunos procesos FastCGI/uWSGI </li></ul>Si tenemos más carga: <ul><li>1 servidor con el nginx frontal
  86. 86. X servidores con procesos FastCGI/uWSGI sirviendo la plataforma </li></ul>
  87. 87. Soluciones La nube al rescate! Arquitectura hiperflexible: <ul><li>Servidores frontales con un autobalanceador
  88. 88. Servidores de aplicaciones (FastCGI/uWSGI)
  89. 89. Servidores de tareas (Celery Workers)
  90. 90. Granja de BBDD (Amazon RDS)
  91. 91. Servidores de caché de contenidos (memcached o Amazon Elasticache) </li></ul>Se supervisa gracias a Amazon CloudWatch Se “autoescala” gracias a Amazon Auto Scaling en base a parámetros de carga de los equipos configurables
  92. 92. Soluciones La nube al rescate! Arquitectura hiperflexible: <ul><li>Servidores frontales con un autobalanceador e IP elástica
  93. 93. Servidores de aplicaciones (FastCGI/uWSGI)
  94. 94. Servidores de tareas (Celery Workers)
  95. 95. Granja de BBDD (Amazon RDS)
  96. 96. Servidores de caché de contenidos (memcached) </li></ul>Se supervisa gracias a Amazon CloudWatch Se “autoescala” gracias a Amazon Auto Scaling en base a parámetros de carga de los equipos configurables
  97. 97. La receta Ingredientes <ul><li>Amazon EC2: Todos los servidores que necesites
  98. 98. Amazon S3 + Cloudfront: Servir los Media
  99. 99. Amazon RDS: Granja de BBDD
  100. 100. Amazon SES: Envio de emails
  101. 101. Amazon Elasticache: Caché de contenidos (memcached)
  102. 102. Amazon CloudWatch + Amazon Auto Scaling: Para la magia
  103. 103. ¿Todo con Amazon? En realidad hay más alternativas, pero Amazon ha sido pionero y por ello tienen más experiencia y mejor abanico de herramientas </li></ul>
  104. 104. Referencias Mira qué hacen los demás... ...que lo mismo aprendes algo ;-) <ul><li>Muchos portales de los “grandes” tienen blogs en los que cuentan sus “batallas” contra los picos de visitas. Leelos. Empápate. </li><ul><ul><ul><li>Por ejempo, el proyecto Disqus o Tuenti
  105. 105. http://www.kitchensoap.com/ (trabajó en Flickr) </li></ul></ul></ul><li>Hay muchos libros interesantes al respecto: </li><ul><ul><ul><li>Building Scalable Web Sites (by Cal Henderson)
  106. 106. Scalable Internet Architectures (by Theo Schlossnagle)
  107. 107. The Art of Scalability (by Martin L.Abbott) </li></ul></ul></ul></ul>
  108. 108. Dudas Aprovecha la ocasión... ...y no te quedes con la duda <ul><li>PREGUNTAD! :-) </li></ul>

×