Desarrollo en la nube
•
0 likes•366 views
Como abordar un proyecto web que tiene previsto un gran crecimiento sin temor a morir en el intento...
![Desarrollo en la nube Javier Nievas Muñoz CTO en Pynso | CTO en Hitsbook [email_address]](https://image.slidesharecdn.com/desarrolloenlanube-120126183146-phpapp02/85/Desarrollo-en-la-nube-1-320.jpg)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Desarrollo en la nube
Similar to Desarrollo en la nube (20)
Recently uploaded
Recently uploaded (13)
Desarrollo en la nube
- 1. Desarrollo en la nube Javier Nievas Muñoz CTO en Pynso | CTO en Hitsbook [email_address]
- 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. Bienvenidos TARGET Proyectos web con previsión de crecimiento en contenidos y visitas
- 4. Objetivo MISIÓN Conseguir que la plataforma web esté online el 99% del tiempo
- 5. Objetivo MISIÓN Conseguir que la plataforma web esté online el 99% del tiempo ¿Imposible?
- 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. Intro El problema Todo esto consume recursos del servidor: RAM + CPU + HDD + Red
- 14. Hosting Escalabilidad El gran problema...
- 16. Servidor Base de Datos
- 18. Procesamiento / Envío de emails
- 19. Generar HTML
- 20. Servidor
- 22. Muchas opciones de configuración que apenas se utilizan
- 24. Servidor Base de Datos
- 26. Procesamiento
- 27. Generar HTML
- 28. Servidor
- 30. Servidor Base de Datos
- 32. Procesamiento
- 33. Generar HTML
- 34. Servidor
- 36. Servidor Base de Datos
- 38. Procesamiento
- 39. Generar HTML
- 40. Servidor
- 42. Servidor Base de Datos
- 44. Procesamiento
- 45. Generar HTML
- 46. Servidor
- 48. Podríamos usar nginx, pero tampoco es buena idea...
- 49. Es una tarea secundaria ¿y si externalizamos este “marrón”?
- 51. Servidor Base de Datos
- 53. Procesamiento
- 54. Generar HTML
- 55. Servidor
- 58. Servidor Base de Datos
- 60. Procesamiento
- 61. Generar HTML
- 62. Servidor
- 64. Servidor Base de Datos
- 66. Procesamiento
- 67. Generar HTML
- 68. Servidor
- 70. Servidor Base de Datos
- 72. Procesamiento
- 73. Generar HTML
- 74. Servidor
- 76. Servidor Base de Datos
- 78. Procesamiento
- 79. Generar HTML
- 80. Servidor
- 82. Pagaremos realmente por el uso real que tenga nuestra plataforma
- 83. Y lo mejor, es que podemos conseguir que se regule y ajuste de forma automágica.
- 84. Por ejemplo: Amazon EC2
- 86. X servidores con procesos FastCGI/uWSGI sirviendo la plataforma
- 88. Servidores de aplicaciones (FastCGI/uWSGI)
- 89. Servidores de tareas (Celery Workers)
- 90. Granja de BBDD (Amazon RDS)
- 91. Servidores de caché de contenidos (memcached o Amazon Elasticache) Se supervisa gracias a Amazon CloudWatch Se “autoescala” gracias a Amazon Auto Scaling en base a parámetros de carga de los equipos configurables
- 93. Servidores de aplicaciones (FastCGI/uWSGI)
- 94. Servidores de tareas (Celery Workers)
- 95. Granja de BBDD (Amazon RDS)
- 96. Servidores de caché de contenidos (memcached) Se supervisa gracias a Amazon CloudWatch Se “autoescala” gracias a Amazon Auto Scaling en base a parámetros de carga de los equipos configurables
- 98. Amazon S3 + Cloudfront: Servir los Media
- 99. Amazon RDS: Granja de BBDD
- 100. Amazon SES: Envio de emails
- 101. Amazon Elasticache: Caché de contenidos (memcached)
- 102. Amazon CloudWatch + Amazon Auto Scaling: Para la magia
- 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
- 106. Scalable Internet Architectures (by Theo Schlossnagle)
- 107. The Art of Scalability (by Martin L.Abbott)
Editor's Notes
- Gracias por asistir Estamos en la WebRoom aunque realmente lo que vamos a ver en esta presentación al ser orientado a la web, nos va a servir tanto para plataformas PC como para móviles. Antes de comenzar querría tomaros un poco el pulso para ver qué cosas conoceis y qué cosas no, con la idea de adaptar un poco la presentación a vosotros. Repasar los términos por encima.
- El objetivo no son las webs corporativas, ni pequeños blogs (al menos en sus etapas iniciales), sino plataforma con base web cuya previsión de crecimiento a corto/medio plazo sea muy grande. La web de un pequeño comercio no va, al menos a priori, a recibir un número tal de visitas que llegue a provocar que deje de funcionar la web. Por lo que nos vamos a centrar en plataformas web grandes, por ejemplo, pongamos tuenti, blogger, twitter, flickr... pero suponiendo que nos encontramos en sus principios. De hecho el mejor ejemplo que puedo poneros es Hitsbook.
- ¿Porqué el 99% y no el 100%? Seamos realistas, la posibilidad de que haya cortes en los propios servicios que contratamos sumado a las actualizaciones y mejoras que introducimos en la aplicación hacen imposible plantearse como objetivo el 100%. Quizá hasta el 99% sea un poco utópico, pero sí debemos acercarnos todo lo posible.
- ¿Es imposible? Hay momentos en los que puede llegar a parecerlo, pero se puede conseguir. Es cuestión de conocer algunos trucos, seguir algunas guías, y tb, pq negarlo, cuestión de pasta :-)
- ¿Que es lo que hace que una plataforma pueda llegar a colapsarse? En realidad no es una única cosa, si lo fuera, tendríamos muy claro donde centrarnos. Todo lo contrario: son la suma de muchas cosas. Repasar el proceso completo desde que el navegador hace la petición hasta que el usuario vé la página resultante.
- Son muchas operaciones a realizar, que se ejecutan en un servidor, es decir, en un equipo con unos recursos finitos. Por ejemplo, la BBDD consume por una lado bastante memoria RAM en la que almacena los datos más consultados, y por otra parte, puede consumir bastante CPU si se le solicitan datos de múltiples tablas.
- Tradicionalmente los servidores se han clasificado en 3 categorías según la dedicación que recibíamos con respecto a sus recursos. Los más económicos, los compartidos, en los que contratamos un “trozo” de un servidor que vamos a compartir con otros muchos proyectos. Después tenemos los servidores virtuales, que básicamente se diferencian en que nos reservan unos mínimos que tendremos siempre a nuestra disposición. Y por otro lado tenemos los servidores dedicados. Enteramente a nuestra disposición. ¿Cómo escalamos con estos equipos?
- Pues, decir que son escalables no es del todo correcto... son equipos con unas limitaciones finitas. Si se trata de servidores virtuales suelen darnos opción a contratar algunos gigas extras de ram, o algunos cores/cpus extras. Con un límite, claro. ¿Cómo escalar con estos equipos? La única forma plausible es contratar más equipos.
- Echémosle un vistazo a la gráfica. La linea negra discontinua representa la estimación de la demanda. En rojo, vemos la demanda real. Que como puede verse, oscila alrededor de nuestra estimación, hay momentos en los que la demanda es baja y otros momentos “pico” en los que la demanada supera nuestras previsiones. ¿Cómo dimensionamos nuestros servidores? La linea discontinua representa la aproximación tradicional. Intentamos estar por encima de nuestra previsión. Pero puede pasarnos que haya momentos en los que los picos superen nuestra previsión... Y hacer un sobre-escalado para evitarlo tiene un coste que posiblemente no podamos abordar.
- Entonces, hemos visto que para preparar nuestra plataforma no basta con centrarnos en un único punto, debemos tener en cuenta todos los elementos que intervienen en el proceso. Veamos, interviene como hemos visto, el servidor web, el servidor de base de datos, las peticiones de elementos estáticos, el procesamiento de tareas y el envío de emails, la generación recurrente de html y el propio servidor donde nos alojamos. Hay algún elemento más, pero estos son los más importantes y en los que vamos a centrarnos en resolver. Vamos a ir viendolos uno por uno.
- Si yo os pregunto el nombre de un servidor web, o bien no conoceis ninguno, o si conoceis alguno, lo más probable es que sea Apache. Y es normal. Sin duda es el servidor web por excelencia, conocido de siempre, muy estable, muy seguro, fiable, muy configurable, hay muchos modulos que extienden y añaden funciones adicionales... lo tiene todo... pero claro... todo esa funcionalidad tiene un precio. Nosotros aquí vamos a proponer reemplazar esta pieza por Nginx. Nginx se ha utilizado típicamente como balanceador de carga y servidor proxy, pero cada día más gente está pasándose a Nginx utilizándolo directamente como servidor web. Veamos el porqué.
- Por una parte, si vemos esta gráfica en la que se compara el tiempo medio de respuesta por petición según el número de peticiones concurrentes va aumentando (y en este caso, estamos viendo un caso muy simple en el que se está sirviendo un fichero html simple), esto se debe a cómo están construidas ambas aplicaciones, mientras que apache tiene hebras o procesos que son las que atienden cada una de las peticiones, nginx aplica un enfoque muy distinto, y funciona basado en eventos. Gracias a ese enfoque consigue que el tiempo de respuesta se mantenga estable independientemente del número de peticiones. Pero eso no es lo mejor...
- Esto es lo que más sorprende. Fijaos en el consumo de recursos de un proceso y otro. Este es el gran motivo por el que utilizar nginx. No consume apenas memoria, y es capaz de gestionar miles de peticiones sin despeinarse. Eso sí, hay q tener en cuenta que con nginx estamos desligando el atender peticiones de la ejecución del código del servidor. Si necesitamos que nuestras páginas sean generadas dinámicamente (que raro sería lo contrario...) vamos a necesitar al menos otro proceso adicional que haga de intérprete ejecutor del código. Para ello podemos utilizar la interfaz FastCGI o uWSGI según la tecnología que utilicemos.
- Servir los ficheros estáticos es una tarea muy simple, no requiere ningún cálculo, si nos piden el fichero X hay que cogerlo y enviarlo. Si utilizamos Apache para realizar esta labor estaremos matando moscas a cañonazos. Esta labor se puede delegar a nginx, que es capaz de servir ficheros estáticos directamente. Pero... y si yo os dijera que existe un servicio que se puede contratar que permite alojar estos ficheros, y se encarga de replicarlo en multitud de servidores repartidos por el mundo y que de forma transparente para los usuarios y para nosotros se encarga de servir esos ficheros desde un servidor cercano al usuario, de forma que la velocidad con que se sirven estos ficheros es insuperable
- Servir los ficheros estáticos es una tarea muy simple, no requiere ningún cálculo, si nos piden el fichero X hay que cogerlo y enviarlo. Si utilizamos Apache para realizar esta labor estaremos matando moscas a cañonazos. Esta labor se puede delegar a nginx, que es capaz de servir ficheros estáticos directamente. Pero... y si yo os dijera que existe un servicio que se puede contratar que permite alojar estos ficheros, y se encarga de replicarlo en multitud de servidores repartidos por el mundo y que de forma transparente para los usuarios y para nosotros se encarga de servir esos ficheros desde un servidor cercano al usuario, de forma que la velocidad con que se sirven estos ficheros es insuperable
- Esas tareas no deben ejecutarse durante las peticiones de los usuarios, pues eso provocaría una saturación instantanea de la hebra que atendiera esa petición y lo que es más... pensad en YouTube, cuando subes un video en un formato X, youtube se encarga de procesarlo y convertirlo a otro formato, el FLV, ¿os imaginais que pasaría si de repente miles de usuarios subieran un video y tratásemos de procesarlos todos sobre la marcha? Pues como podeis sospechar, eso sobrecargaría la CPU y dejaría al servidor inservible, y por tanto, la página parecería caída. Este tipo de labores deben encolarse y procesarse por un número de limitado de “workers”, y si después de subir un video, te toca esperarte un rato... pues te esperas a que toque. Para esto existen los gestores de colas de tareas. Ahora mismo, el más extendido es Celery, que permite definir el numero de workers y se encarga de encolar las tareas, para luegor ir repartiendoselas a los workers. Lo mejor de este sistema, es que es muy facil de escalar, si necesitamos más capacidad de concurrencia, bastaría con añadir más workers (que pueden estar en otros equipos)
- Pensad en el Facebook / Tuenti o cualquier otro portal al que accedais frecuentemente. Existen multitud de zonas dentro de la página que se repiten a lo largo de la web, por ejemplo, un apartado de “ultimas noticias”, o “productos más vendidos”, o “ultimas entradas en twitter”... etc. Calcular esos elementos conlleva un coste computacional relativamente alto, pues implica lanzar una o más consultas a la base de datos para poder generar el html. Si ahora mismo, los productos más vendidos son A, B y C, dentro de un par de minutos, seguirán siéndolo, ¿verdad? Pues en lugar de calcularlo, lo que vamos a hacer es memorizar el html ya generado y durante un tiempo servirlo directamente, sin recalcularlo. Esto es, básicamente, lo que se conoce como caché de contenidos. Y es fundamental que lo apliquemos en nuestros proyectos. El rendimiento de las aplicaciones cambia drásticamente utilizando esta potente herramienta. Imaginaos, por ejemplo, un foro, con sus estadísticas en cada post, el numero de veces que se ha leido, el numero de respuestas que tiene, etc. y ahora, multiplicad eso por el numero de posts que hay un foro... si no fuera por la caché... ¿Quién gestiona esa caché? La aplicación más extendida para llevar a cabo esta labor es memcached.
- Hemos llegado al punto en que aparece ¡La nube! El famoso cloud en el que ahora parece que está todo. La nube está de moda! La cuestión ahora es... ¿Qué es la nube? ¿en qué se diferencia de un monton de servidores? Porque básicamente, la nube, es un conglomerado de servidores que podemos contratar para alojar nuestros proyectos... ¿y entonces?¿cuál es la novedad? ¿que tiene esto de nuevo? Imaginaos que soys unos informaticos frikis y gestionais un monton de servidores en los que dais alojamiento a clientes. Como buenos informáticos, somos flojos, muy flojos... y tendemos a automatizar las cosas todo lo posible, para trabajar lo mínimo... ¿verdad? Que sería lo más comodo? Tener un API, sencillica, que permita crear máquinas sobre la marcha, con las características que yo le pase como argumento, y que además, se le instale una imagen de disco concreta de forma automatica. Entonces fue cuando a alguien se le ocurrió la brillante idea de darle una vuelta más de tuerca y dar acceso a ese API a los usuarios. Pues, básicamente, eso es la nube, un API con la que podemos crear, borrar, hacer backups y de todo de maquinas completas, y todo así, en caliente.