Héctor Jaskolowski
Sysadmin
Colegio San Esteban
Bariloche
Sysadmin
Colegio San Esteban
Bariloche
viernes, 20 de noviembre de 2009
jueves, 15 de octubre de 2009
Consideraciones para entender hosting + Ancho de banda + disponibilidad
Subiéndome a la nube, capítulo uno
Este mes mi proveedor de housing me aplicó un 150% de aumento al costo del servicio. Aparte me aplicarán topes al consumo del ancho de banda. Al tener mis equipos en ese data center desde hace 8 años esperaba que un reajuste de tarifas no sería tan dramático nunca, pero yo soy muy ingenuo. Además el servicio cambiará para peor, aplicándose desde ahora topes en los consumos que antes no existían. Punto.Concidentemente, comencé hace un mes y días a estudiar cómo funciona a la estructura computacional de Amazon, conocida como Amazon Web Services (AWS). Digámosle "la nube".
Mi primer ejercicio fue tomar el servicio más sencillo de implementar. Surgió que lo más sencillo era implementar S3 (Simple Storage Service) como sistema de almacenamiento de los archivos estáticos de Grippo.com - http://static.grippo.com. Me tomó simplemente una hora mover todos los archivos estáticos a la plataforma S3. Luego ví que Amazon tiene una CDN ó Content Delivery Network, que es un sistema como Akamai, que acerca esos archivos estáticos a los cachés de los proveedores de internet de los millones de usuarios de Internet a nivel global, tecnología que todos los sitios gigantes de Internet están obligados a utilizar. Ahora se me hizo disponible también a mí. Otra hora más y pude conectar el nombre del host en mi propio dominio http://static.grippo.com, con la CDN de Amazon, a la que llaman con el bonito nombre de CloudFront. El origen de los datos de CloudFront es el repositorio S3 que ya había creado anteriormente. Asique, en dos horas, tuve todos mis archivos estáticos (imágenes, style sheets, scripts JS, iconos), en la nube de Amazon y servidos a través de su CDN bajo mi propio nombre de dominio. Esto lo hice al finalizar mayo.
¿Cuánto cuesta utilizar S3 con CloudFront? Calcular por adelantado es un poco complejo a primera vista. Ahora que hace más de un mes, el sistema tarifario de Amazon produce mucha satisfacción como cliente, cosa que no siento con mi proveedor de housing local. Amazon cobra por varios items por separado: cantidad de storage utilizado, bando de ancha utilizado y cantidad de requests servidos. Mis cálculos preliminares fueron que gastaría unos 60 dólares por mes. Pero tenía dudas. Ahora que cerró el mes de junio, puedo mostrarles con gran satisfacción la primera liquidación de un mes completo de S3 más CloudFront de Grippo.com en Amazon:
De esta imagen sólo presten atención a los títulos Amazon Simple Storage Service que totaliza USD 0,16, o sea 16 centavos de dólar, y Amazon CloudFront por USD 48,80.
Tengan en cuenta que para los costos que yo estoy acostumbrado a pagar en Buenos Aires, esos precios son muy inferiores. Tengan también en cuenta, que la tecnología que me ofrece Amazon, con mis datos guardados en forma redundante, monitoreado por un ejército de ingenieros y distribuidos en su CDN, no está al alcance de muchos hoy en día en todo el mundo. Para los chicatos, les cuento: con 96GB de data transfer, y 33 millones de requests.
Conclusión: mejor subirse a la nube que quedarse en la tierra.
Próximo capítulo: cómo subo el application server a la nube y cómo se hace load balancing en la nube. Ah! Les adelanto el costo por server equivalente a Pentium 4 Dual Core, con 1,7GB RAM y 160GB disco fijo: USD 40 mensual. Hasta la próxima
A principios de este mes, publiqué el capítulo uno, donde mostraba lo sencillo que fue migrar todos los elementos estáticos a S3 + CloudFront, el competitivo costo mensual y el upgrade que significa en tecnología pasar a servir imégenes, css, js y demás, desde una content delivery network, archivando los elementos en una plataforma indestructible, quasi-eterna y 100% disponible.
Ahora bien, una cosa son elementos estáticos, y otra cosa son páginas dinámicas. Hoy les voy a mostrar cómo va la migración de la aplicación y el tipo de setup redundante que es posible / mandatorio hacer.
Esta es la consola AWS de Amazon:
Versión para chicatos. En este dashboard vemos que ya tengo 2 running instances. Cada instancia es un server completo, con 1.7GB RAM, procesador Opteron de 2007, 160GB en disco. Uno de esos servers es solo para MySQL. El otro es un worker con Apache 2 + mod_perl 2. El plan es agregar un segundo servidor MySQL que haga replicación. Y agregar un segundo apache para atender los requests HTTP, balanceados con un ELB, ó Elastic Load Balancer en la jerga de Amazon. Cada una de las instancias (recuerden, cada instancia es un server), tiene montado por nfs un volumen externo, donde los datos importantes de la aplicación, incluyendo las databases MySQL, existen en un dispositivo redundante y externo a las instancias, llamado Elastic Block Store o EBS. Esto es importante porque si la instancia se corrompe, nunca se recuperarían los datos almacenados en su propio hard disk, los datos sensibles deben almacenarse fuera de la instancia.
En resumen:
- frente a los usuarios solo está el load balancer, que es un servicio que pinguea cada 30 segundos cada apache para ver si está vivo y balancea la carga entre tantas instancias como le pongamos.
- detrás del load balancer hay n cantidad de instancias, cada una corriendo apache + mod_perl, en mi caso con dos instancias puedo servir mucho mas de mis 3 millones de uniques mensuales
- cada aplicación realiza inserts, updates y deletes en un servidor master MySQL (que corre en su propia instancia) y todos los selects van al slave (que por supuesto corre en una instancia separada), en total hasta aca tenemos 4 instancias corriendo
- todos los datos (templates, logs, bases de datos), existen en una unidad de storage externo (EBS)
- en mi repositorio S3 tengo imágenes del setup particular del OS de cada rol de servidor. En mi caso uso Debian. A cada imagen la llaman AMI (Amazon Image) y contiene una imagen binaria que aplicada a una instancia nueva, instala no solo el OS sino todas las decenas de paquetes y configuraciones específicas que se necesitan para asignarlo un rol al server. Asi tengo un AMI para servidor MySQL master, otro para servidor MySQL slave, y otro para servidor Apache + mod_perl. En caso de necesitar más apaches, simplemente lanzo una nueva instancia (launch instance), y le aplico el AMI correspondiente a apache con mod_perl. Todo el proceso implica dos clicks y esperar como 90 segundos en total. Al finalizar ese procedimiento, tengo un nuevo apache que puedo agregar al load balancer y en minutos puede estar sirviendo mas requests.
De la misma manera, si se corrompe la instancia que corre alguno de los servidores MySQL, puedo en minutos tener otro con identico setup. Como las tablas de las bases de datos se montan en el volumen externo "indestructible", lo que puede ser una verdadera catástrofe, puede pasar inadvertido si se usan otras herramientas de las que voy a hablar en el futuro, que combinan un monitor con el API de AWS, y que permite automatizar el lanzamiento de instancias nuevas en caso de necesidad.
Como yo vengo de hacer todo con el destornillador en la mano, esa mejora la dejo para más adelante, aunque es inevitable caer en automatizar todo al punto de por ejemplo, mantener dos apaches de lunes a viernes, pero sabados y domingos cuando la demanda baja, mantener solo un apache y pagar menos.
Bueno, ¿cuanto cuesta todo esto? Como dije en la nota anterior, mi interés en compartir esto es que aún habiendo conocido AWS hace años, siempre me pregunté efectivamente cuán viable era para un sitio como grippo.com. Pues bien, es mucho más viable que mantenerlo en un datacenter de clase mundial en Buenos Aires, eso se los puedo asegurar, porque mientras esté en el datacenter de clase mundial, sea en Buenos Aires, Los Angeles, Londres o donde sea, siempre llega el momento fatídico del downtime, como me pasó hoy mismo, o llega el momento que con destornillador en la mano tenemos que cambiar una fuente que dijo basta, o agregar mas pizzas al horno (sevidores en el gabinete).
Si bien falta un día o dos para cerrar el mes de julio, con aproximadamente USD 100, estoy cubriendo toda la operacion de storage S3 (22 centavos) + CloudFront (mi propia CDN para 30 y pico millones de requests por 38 dólares) + EC2 (Elastic Computing Cloud, 60 dolares más). EC2 incluye el uso de dos instancias por el momento. Estoy a punto de lanzar dos instancias nuevas, así para finales de agosto puedo mostrar el costo total de infraestructura de grippo.com. El desglose de EC2 es muy pormenorizado:
Para chicatos. El primer item que figura con USD500, es para reservar una instancia. Si la instancia no está reservada, pago USD 0,10 por hora. Eso es lo mejor para instancias lanzadas por demanda, digamos una aplicacion que tiene mucho trafico de 9 a 17 de lunes a viernes, en esos momentos usamos instancias sin reserva y pagamos 0,10 por hora. En mi caso, necesito una base de 4 instancias para mi setup, puedo reservar 4 instancias a USD500 cada una por tres años, y durante esos tres años, pago USD 0,03 por hora, el costo de cada server en este caso es de menos de USD 500 anual! Sí leíste bien, anual. Si no es reservado, pagás algo más de USD 700 anual, claro en el caso de que lo estes usando todo el tiempo, que no sería el caso jamás, porque en ese caso lo convertirías a reservado.
Luego tengo USD 32 por mil y tantas horas de instancias a 0,03. Esas son las dos instancias que ya tengo corriendo, una con MySQL, la otra con Apache.
Luego viene el costo por bandwidth. Debo aclarar que tengo migrados sitios pequeños, que en su conjunto pueden tener 5 mil usuarios por día, como por ejemplo da.com.ar, grippo.co.il, grippo.es, horoscopo.grippo.com. Asique el bandwidth me cuesta centavos. El bandwidth que va a consumir el mes que viene puede llegar a 50GB mas o menos, la espectativa de costo de este item no superaría los USD 10.
Luego viene EBS, que es el storage externo, attacheable a las instancias. Es decir donde se guardan todos mis datos sensibles, incluyendo las bases de datos y de la que puedo programar un backup instantáneo que se realice cada hora si quiero, y que se almacene en mi repositorio S3. Sólo por esto conviene pasarse a AWS. Sólo por EBS y Snapshots.
Luego vienen las EIPs, elastics IP, que si las uso, no me las cobran. Sólo me cobrarían USD 2 mensual si las reservo pero no las asigno a ninguna instancia.
Luego viene CloudWatch que es un monitor que permite automatizar las respuestas a la demanda, que hablaremos en un futuro cercano.
Luego viene el load balancer, que cuesta 18USD mensual. Como en mi setup los apaches pueden responder a todas las aplicaciones, uso solo un load balancer, y pongo detras tantos apaches como sean necesarios de acuerdo a la demanda.
Espero que no sea muy confuso esta vez, hay muchos conceptos aqui adentro, cada uno voy a tratar de explicarlos por separado, pero lo central aquí es que grippo.com siendo uno de los 10 sitios nacionales con mayor tráfico y difícilmente llegue a superar los USD 200 mensuales en agosto, migrando el 100% de los servicios a Amazon.
Dicho de otra manera: cualquier start up podría reservar USD 100 mensuales y tener un setup indestructible y escalable al nivel de google, yahoo o amazon. Quizás era un tema que podía incidir mucho más en el presupuesto mensual, pero ya no.
Dicho de otra manera: qué se puede hacer con USD200 en un datacenter en Argentina?
Dicho de otra manera: cuál es el presupuesto de servidores más conectividad de los otros 10 sitios nacionales de mayor tráfico? Creo que cada uno se podría optimizar.
En cualquier caso, aclaro que no soy socio comercial de Amazon, simplemente su AWS es genial, y yo tardé como 4 años en comprobarlo
COMENTARIOS EN EL BLOG DE ORIGEN
comentarios
Suscribirse a:
Entradas (Atom)
Felicitaciones Jorge!!! Un post excelene, la verdad que no encontre mucha documentacion de AWS en español y sintetizado, me viene barbaro, vamos a empezar a probar. Un abrazo.
Que maravilla! Yo estoy usando Amazon para hospedar videos, y es excelente alternativa al server en el Datacenter!
Yo estoy usando S3 para servir los videos, cual es la diferencia entre usar eso o el CDN?
Saludos
Si pero el soporte ? por lo que veo te cobran y lindo si queres un soporte rapido ante eventuales emergencias. O no Jorge ?
Hola Dan, el CDN, que en Amazon se llama CloudFront, pone los contenidos que tenes en S3, más cerca de los usuarios, en cachés ubicados en los ISP de los usuarios. Un CDN muy conocido es Akamai. El setup de CloudFront en Amazon es muy sencillo:
1. Adherir al servicio
2. Especificar el bucket S3 de donde se van a servir archivos
3. Listo, si queres, por medio de un registro CNAME del archivo de zona de tu dominio, podes usar el CDN bajo tu propio dominio.
El costo es casi identico a usar solamente S3.
Hola Sebastián. muy buena pregunta. El soporte es de dos tipos: autoservicio, en cuyo caso vos sos tu propio soporte, o premium, cuyo costo está entre 100 y 400 dólares mensuales.
http://aws.amazon.com/premiumsupport/
Luego hay un nuevo tipo de proveedores de hosting, que te dan un servicio por sobre AWS, es decir subcontratando AWS y manejandolos ellos, unificando recursos, optimizando el soporte, donde hay cuentas desde USD 25 mensuales, con soporte incluido.
http://www.engineyard.com
La idea detras de empresas como esta es : "ocupate solo de tu negocio, nosotros nos ocupamos de lo que necesites de hosting, con soporte incluido"
Que tema este del Cloud Computing. Me sería mucho mas claro si tarifaran el bandwidth en mbps. Tengo unos proyectos personales que mueven mucho trafico (500.000 únicas diarias) y mi proveedor, que no es de Argentina, me factura con el método 95th percentile. (http://en.wikipedia.org/wiki/Burstable_billing). Estoy usando en los servidores de imágenes que son el 90% del consumo unos 70mbps. Me pregunto cuanto costará esto en números de AWS...
je, voy a tener que analizarlo para mis proyectos nuevos, hasta 5k visitas y 90Gb de trasnfer me bancan, ahora si llego a duplicar eso ya pinta para este tipo de servicios?
Hola Fabio. Con esta calculadora podés prever exactamente cuanto va a ser el costo de cualquier proyecto.
http://calculator.s3.amazonaws.com/calc5.html
Sin embargo, el costo no es la única variable.
Cristian, modestamente te digo, estas equivocado, la forma de facturarte de AWS es mejor. Con el "95th percentile billing method there is potential for paying for bandwidth that is not used". Con AWS, el modo de facturar es mucho más claro: pagas por lo que usás, no pagas por lo que no usás.
Deberías usar esta calculadora:
http://calculator.s3.amazonaws.com/calc5.html
Ingresar los datos que te pide: storage, data transfer in/out, y cantidad de requests, para saber con certeza cuanto deberías haber pagado en meses anteriores. Asi te das una idea de cuánto demás estás pagando ahora. Por favor, avisame como te fue en la comparación.
Qué opinión te merece el hosteo de los MySQL versus el uso de SimpleDB?
Qué tanto te complica el mantenimiento de estos máquinas para la BD, y qué tanto cuesta pasar todo a SimpleDB?
Hola Sebastián, no he tenido tiempo todavía de usar SimpleDB, nisiquiera de leer la documentación. Trabajé con BigTable en Google Application Server, y creo entender que esto es parecido. Es muy cómodo trabajar con SimpleDB porque no es SQL. No hay schemas que definir por anticipado. Cuando necesitas un tuple o columna nueva, la usas y alli estará. Todas las columnas se indexan, asique realizar queries contra SimpleDB siempre es eficiente. Por otra parte no hay problemas de escalabilidad, porque no hay límite practicamente en la cantidad de data que pueden almacenar. Pero como te dije no tengo experiencia directa con SimpleDB. El mantenimiento de la BD en Amazon se hace más flexible, en mi opinión. El hecho de poder montar un volumen externo, sobre el cual hacer snapshots (backup), mientras el volumen está montado y el SQL server está en servicio, es algo que en sí mismo es de un valor increíble. Decime si no es siempre complicado hacer backups de las tablas. Bueno en AWS es tan fácil como apretar un botón en el dashboard de EC2 o programar un cron job para que lo haga periódicamente utilizando el API. Todos los esquemas de redundancia documentados en MySQL, incluyendo por supuesto replicación en todas sus variantes, es muy sencillo, económicamente viable y tremendamente potente en AWS. La performance es algo que voy a experimentar en lo que queda de agosto, ya que como expliqué tengo sitios pequeños por el momento, y estoy por mover uno grande en estos días. Pero gente mucho más experimentada que yo lo viene usando desde hace años. Te recomiendo el blog de alestic.com para interiorizarte a fondo de MySQL sobre AWS. Son genios.
Muy buena la calculadora, la estuve utilizando y a simple vista no creo que sea conveniente para lo que hago. No dudo de los beneficios de la infraestructura pero económicamente no me es viable. Tomando como ejemplo 50mbps (siento el promedio 70 mas o menos) hice unos calculos y mi consumo mensual en el sistema de Amazon son 16200GB al mes. Usando la calculadora del link, solo de transferencia sin poner espacio en disco ni requests ya me da un total de $2500 dolares mensuales. Actualmente por un dual xeon con discos SAS estoy pagando u$s10 aprox cada 1mbps.
Cristian, el data transfer no es el resultado de explotar la tasa de tranferencia en el tiempo como vos lo calculaste. Es algo asi como la suma de los tamaños de todos los archivos transferidos en la línea. Pensalo asi, en tu casa está el agua corriente, las cañerías y la canilla. Contar con un caudal de agua X no hace que el consumo sea igual a mantener la canilla abierta todo el tiempo, no?
Te animaría a intentar nuevamente con la calculadora, con los datos correctos.
¿Podes decirnos cual es el costo mensual en dólares de tu server, sumando todos los conceptos?
Jorge, el calculo lo baje de 70mbps para hacerlo mas aproximado, por eso lo puse en 50mbps que es mas bajo que el promedio o 95th percentile consumido actualmente. Pensa que usando 10mbps sostenidos las 24 horas del día serian unos 3140gb al mes. En mi ejemplo multiplique esos 10mbps x 5 que es un numero del que no baja ni en la peor hora del día durante todo el mes.
Los request ni los puse por que me da panico, eso exactamente es cada acceso a un item alojado en el servidor? Por que cada html de las webs que te hablo tiene incrustadas unas 180 imagenes. Eso sumado a los css y demas objetos podrian ser unos 190 request por visita.
Actualmente pago unos u$150 al mes por el server de htmls/php/mysql en The Planet y en promedio u$500 por server de imagenes.
Jorge, el calculo lo baje de 70mbps para hacerlo mas aproximado, por eso lo puse en 50mbps que es mas bajo que el promedio o 95th percentile consumido actualmente. Pensa que usando 10mbps sostenidos las 24 horas del día serian unos 3140gb al mes. En mi ejemplo multiplique esos 10mbps x 5 que es un numero del que no baja ni en la peor hora del día durante todo el mes.
Los request ni los puse por que me da panico, eso exactamente es cada acceso a un item alojado en el servidor? Por que cada html de las webs que te hablo tiene incrustadas unas 180 imagenes. Eso sumado a los css y demas objetos podrian ser unos 190 request por visita.
Actualmente pago unos u$150 al mes por el server de htmls/php/mysql en The Planet y en promedio u$500 por server de imagenes.
Muchas gracias Cristian por tu valiosa participación.
Hola,
Muy bueno tu artículo, recién ahora entiendo en detalle el tema de "la nube". En general yo utilizo servidores dedicados en Argentina y USA, y en general administrados, ya que no somos especialistas en configuración de servidores, a este respecto una consulta:
Cuando haces referencia a las AMI (Amazon Image) ¿Amazon dispone de algunas configuraciones "listas para usar" o es necesario armar una propia?
Gracias desde ya!
Hola de nuevo,
Me contesto yo solo, veo que existen cientos de AMIs a disposición. Entonces la consulta sería:
¿Para alguien acostumbrado a usar servidores administrados, o con panel de control (cpanel, plesk o incluso webmin) es factible pasarse a Amazon si volverse loco?
Gracias!
No Nestor, definitivamente Amazon AWS es para alguien que tenga perfil de sysadmin, es decir que se sienta cómodo instalando base de datos, web servers, y demás. El valor de Amazon AWS no está por alli, aunque hay compañías como
http://www.engineyard.com
que ofrecen justamente lo que estás sugiriendo, operando sobre plataforma Amazon AWS. Ellos te dicen, despreocupate de la tecnología, ocupate de tus negocios, nosotros te cuidamos tus servers en Amazon.
Cristian, que yo sepa, en Theplanet podes obtener un server dedicado por unos 150 u$, con una interface de 100 mbps para tener picos de esa velocidad. Pero de ninguna manera se puede hacer la cuenta de que tener disponibles 100 mbps impliquen 30 teras de trafico en tus manos. Por eso tenes un limite de banda de 2 o 3 teras (o poquito mas por alguna promo). Sumado a que el consumo tipico de internet es mas bien una campana (que la marcan tus usuarios mas la estacionalidad de la conectividad de tu carrier) y no una recta, lo comun es que un web server (o una granja de ellos) con una interface de 10 mbps pueda servir como MAXIMO 1 (un) tera/mes. o si tenes 100 mbps, 10 teras.
Por ejemplo, uno de los 2 diarios mas grandes del pais tiene un trafico de 80 mbps en su pico, y te aseguro que no pagan 150 u$ por un server en theplanet.
Un terabyte en bruto transferido via amazon costaria si mal no hago las cuentas unos 170 u$. Nada mal. Corrijanme si me equivoco. Daniel.