Windows Azure: Elaboración de costos para Windows Azure

  • Artículo

El diseño de aplicaciones y soluciones para cloud computing y Windows Azure exige una forma totalmente diferente de considerar los costos operativos.

Maarten Balliauw

La computación en nube (cloud computing) y las plataformas como Windows Azure se facturan como “la segunda opción” en TI. Esto ciertamente parece ser verdad cuando se consideran las miles de ventajas que tiene la computación en nube.

La informática y el almacenamiento se transforman en una base a petición que puede usar en cualquier momento, pagando sólo lo que realmente usa. Sin embargo, esto también supone un problema. Si una aplicación de nube se diseña como una aplicación normal, es posible que la perspectiva de costos de esa aplicación no corresponda a lo esperado.

Métricas distintas

En la TI tradicional, una persona podría comprar un conjunto de hardware (infraestructura de red, servidores, etc.), configurarlo, realizar el proceso de configuración y conectarse a Internet. Es una inversión única, en la que un empleado realiza todo el proceso... así funciona.

Con la computación en nube, un modelo de costos reemplaza a ese modelo de inversión. Se paga por recursos, como la potencia del servidor y el almacenamiento según su uso real. Con una plataforma de nube como Windows Azure, puede esperar las siguientes mediciones para calcular su factura mensual:

  • El número de horas durante las cuales ha reservado una máquina virtual (VM), lo que significa que paga por una aplicación implementada, aunque no se encuentre en ejecución actualmente.
  • El número de las CPU de una VM.
  • El ancho de banda, medido por GB de entrada/salida.
  • La cantidad de almacenamiento utilizado en GB.
  • El número de las transacciones en almacenamiento.
  • El tamaño de la base de datos en SQL Azure.
  • El número de conexiones en AppFabric de la plataforma Windows Azure.

Puede encontrar todos los detalles sobre la fijación de precios en el sitio web de Windows Azure en microsoft.com/windowsazure/offers. Como puede ver en esta lista, hay muchos elementos que se deben considerar.

Limitación de máquinas virtuales

A continuación, presentamos cómo se realiza su división desde una perspectiva práctica. A pesar de que limitar la cantidad de máquinas virtuales que se tienen en ejecución es una buena manera de ahorrar costos, para los roles web tiene sentido contar, al menos, con dos máquinas virtuales para disponibilidad y equilibrio de carga. Use la API de diagnóstico de Windows Azure para medir el uso de la CPU, la cantidad de solicitudes HTTP y el uso de la memoria en estas instancias y trabaje con su aplicación a menor escala cuando sea adecuado.

Cada instancia de cualquier rol que se ejecute en Windows Azure de manera mensual duplica la cantidad de horas en la factura. Por ejemplo, tener tres instancias de rol en ejecución en promedio (a veces dos, a veces cuatro) será un 25% más barato que ejecutar cuatro instancias en todo momento casi sin carga de trabajo.

Para los roles de trabajador, también tiene sentido contar con al menos dos instancias de rol para realizar un procesamiento en segundo plano. Esto ayudará a garantizar que cuando una está inactiva debido a que se realizan actualizaciones o cuando se produce el reinicio de un rol, la aplicación sigue estando disponible. Si usa las herramientas disponibles para Windows Azure, puede configurar un rol de trabajador estándar para que realice sólo una tarea.

Si ejecuta un sitio web para el uso compartido de fotografías, por ejemplo, posiblemente desee tener un rol de trabajador para cambiar el tamaño de las imágenes y otro para enviar notificaciones de correo electrónico. Usar la regla de "al menos dos instancias" puede significar la ejecución de cuatro instancias de rol de trabajador, lo que generará una factura a la que se le puede cambiar el tamaño. Cambiar el tamaño de las imágenes y enviar correos electrónicos en realidad no requieren esa cantidad de potencia de la CPU, por lo que si sólo tiene dos roles de trabajador para hacer ambas tareas debería ser suficiente. Hay un ahorro del 50% en la factura mensual gracias a la ejecución de Windows Azure. Implementar un mecanismo de subprocesamiento en un rol de trabajador también es bastante simple, en el que cada subproceso realiza su parte del trabajo de manera dedicada.

Windows Azure ofrece cuatro tamaños de máquina virtual: pequeña, mediana, grande y muy grande. Las diferencias entre cada uno de los tamaños son el número de CPU disponibles, la cantidad de memoria y almacenamiento local disponibles y el rendimiento de E/S. Es mejor considerar el tamaño adecuado de la máquina virtual antes de realizar realmente la implementación en Windows Azure. No puede cambiarlo una vez que ejecuta la aplicación.

Cuando reciba su estado de cuenta mensual, observará que todas las horas de proceso se convierten en horas de instancias pequeñas cuando se presentan en la factura. Por ejemplo, una hora de una instancia de proceso mediana se presentará como dos horas de instancias de proceso pequeñas en la tarifa de instancia pequeña. Si tiene dos instancias medianas en ejecución, se le facturará por 720 horas x 2 x 2.

Considérelo cuando ajuste el tamaño de sus máquinas virtuales. Puede obtener casi la misma potencia de proceso si usa instancias pequeñas. Supongamos que tiene cuatro de estas instancias facturadas a 720 horas x 4. El precio es igual. Puede trabajar a una menor escala para tener dos instancias cuando sea adecuado, lo que significará 720 horas x 2. Si no necesita tener más CPU, más memoria o más almacenamiento, mantenga esas instancias pequeñas porque pueden escalarse de manera más pormenorizada que las instancias mayores.

La facturación por los servicios de Windows Azure comienza una vez que se implementa una aplicación y se produce independientemente de si las instancias de rol están activas o desactivadas. Puede ver esto claramente en el portal de Windows Azure. Aparece la imagen grande de un cuadro. Si el cuadro aparece de color gris, no hay problemas. Si el cuadro es azul, hay una factura pendiente.

Cuando implemente aplicaciones para almacenamiento provisional o para producción y las desactive después de usarlas, no olvide también anular la implementación. No desea pagar por alguna aplicación inactiva. También recuerde trabajar a menor escala cuando sea adecuado. Esto tiene un efecto directo sobre los costos operacionales mensuales.

Cuando se escala de manera vertical hacia arriba y hacia abajo, es mejor tener una instancia de rol en ejecución por al menos una hora, puesto que se paga por hora. Ponga en marcha varios subprocesos de trabajo en un rol de trabajador. De esa manera, un rol de trabajador puede realizar varias tareas en lugar de sólo una. Si no necesita más CPU, más memoria o más almacenamiento, mantenga las instancias pequeñas. Y, repito, asegúrese de anular la implementación de las aplicaciones cuando no las esté usando.

Ancho de banda, almacenamiento y transacciones

El ancho de banda y las transacciones son dos métricas complicadas. Actualmente, no hay una buena manera para medirlos, excepto si se mira la factura mensual. No existe una supervisión en tiempo real que pueda consultar y usar para adaptar su aplicación. De ambas métricas, la más simple de medir es el ancho de banda. Mientras menos cantidad de tráfico ponga en la conexión, menor será el costo. Tan simple como eso.

Las cosas se complican cuando implementa aplicaciones en varias regiones de Windows Azure. Supongamos que tiene un rol web que se ejecuta en la región “Norteamérica” y una cuenta de almacenamiento en la región “Europa Occidental". En esta situación, se facturará el ancho de banda para la comunicación entre el rol web y el almacenamiento.

Si el rol web y el almacenamiento estuviesen ubicados en la misma región (por ejemplo, ambos en “Norteamérica”) no habría factura por el ancho de banda para la comunicación entre el rol web y el almacenamiento. Tenga en cuenta que cuando se diseñan aplicaciones distribuidas geográficamente, es mejor mantener servicios acoplados dentro de la misma región de Windows Azure.

Cuando usa la Red de entrega de contenidos (CDN) de Windows Azure, puede aprovechar otra medida interesante para la reducción de los costos. La CDN se mide de la misma manera que un almacenamiento de blob, es decir, por GB almacenado al mes. Una vez que inicia una solicitud a la CDN, ésta tomará el contenido original desde el almacenamiento de blob (incluido el consumo de ancho de banda, entonces facturado) y lo almacenará localmente en la caché.

Si define que los encabezados de expiración de la caché sean muy breves, consumirá más ancho de banda porque la caché de la CDN se actualizará con más frecuencia. Cuando la expiración de la caché está definida como muy larga, Windows Azure almacenará el contenido en la CDN durante más tiempo y facturará por GB almacenado al mes. Considere esto para cada aplicación a fin de poder determinar el mejor tiempo de expiración de la caché.

El Monitor de diagnóstico de Windows Azure también usa el almacenamiento de blob para los datos de diagnósticos, como contadores de rendimiento, registros de seguimiento, registros de eventos, etc. El monitor escribe estos datos en la aplicación siguiendo un intervalo especificado previamente. Escribir a cada minuto aumentará el recuento de transacciones en el almacenamiento, lo que genera costos adicionales. Si se define en un intervalo cada 15 minutos, se generarán menos transacciones de almacenamiento. Sin embargo, el inconveniente de esto es que los datos de diagnósticos siempre tendrán una antigüedad de al menos 15 minutos.

Además, el Monitor de diagnóstico de Windows Azure no limpia sus datos. Si usted no lo hace, es posible que se le facture por concepto de una cantidad de almacenamiento que sólo contenga datos de diagnósticos expirados y antiguos.

Las transacciones se facturan por 10.000. Puede parecer un número alto, pero pagará por ellas en realidad. Cada operación realizada en una cuenta de almacenamiento es una transacción. Crear un contenedor de blob, enumerar los contenidos de un contenedor de blob, almacenar datos en una tabla del almacenamiento de tablas, observar los mensajes de una cola; todas éstas son transacciones. Por ejemplo, cuando se realiza una operación como el almacenamiento de blob, primero compruebe si existe el contenedor de blob. Si no es así, es posible que tenga que crearlo y luego almacenar un blob. Ahí hay al menos dos transacciones, o posiblemente tres.

Ocurre lo mismo para el hospedaje de contenido estático en el almacenamiento de blob. Si el sitio web hospeda 40 imágenes pequeñas en una página, esto representa 40 transacciones. Esto puede aumentar rápidamente con aplicaciones con mucho tráfico. Simplemente al asegurarse de que existe un contenedor de blob al inicio de la aplicación y al omitir esa comprobación en cada operación subsiguiente, puede disminuir el número de transacciones casi en 50%. Haga esto y podrá disminuir la factura.

Los índices pueden ser caros

SQL Azure es un producto interesante. Puede tener una base de datos de 1 GB, 5 GB, 10 GB, 20 GB, 30 GB, 40 GB o 50 GB a un precio mensual muy bajo. Comenzar con una base de datos de SQL Azure de 5 GB es seguro y suficiente. Sin embargo, si sólo usa 2 GB de esa capacidad, no se trata realmente de un modelo de pago por uso, ¿no?.

En algunas situaciones, puede resultar más rentable distribuir sus datos en distintas bases de datos de SQL Azure en lugar de tener una base de datos de gran tamaño. Por ejemplo, podría tener una base de datos de 5 GB y una de 10 GB, en lugar de tener una base de datos de 20 GB con 5 GB de capacidad sin utilizar. Este tipo de almacenamiento estratégico afectará su factura si lo utiliza de manera inteligente, y si funciona con su tipo de datos.

Todos los objetos consumen almacenamiento. Los índices y las tablas pueden consumir gran parte de la capacidad de almacenamiento de la base de datos. Las tablas de gran tamaño pueden ocupar el 10% de una base de datos y algunos índices pueden consumir el 0,5% de una base de datos.

Si divide el costo mensual de la suscripción a SQL Azure por el tamaño de la base de datos, tendrá el costo por unidad de almacenamiento. Considere los objetos de su base de datos. Si el índice X cuesta 50 centavos al mes y en realidad no representa una gran mejora en el rendimiento, simplemente deséchelo. Cincuenta centavos de dólar no es demasiado, pero si elimina algunas tablas y algunos índices, pueden sumarse. Puede encontrar un ejemplo interesante sobre esto en la publicación del blog del equipo de SQL Azure titulada "El costo real de los índices” (blogs.msdn.com/b/sqlazure/archive/2010/08/19/10051969.aspx).

Existe un movimiento fuerte dentro del desarrollo de aplicaciones respecto de no seguir usando procedimientos de almacenamiento en una base de datos. En su lugar, la tendencia se inclina a usar mapeadores relacionales de objetos y a realizar gran cantidad de cálculos en los datos según la lógica de la aplicación.

No hay nada de malo en eso, pero sí se pone interesante cuando se considera Windows Azure y SQL Azure. Realizar cálculos de datos en la aplicación puede requerir instancias adicionales de roles web o de roles de trabajador. Si traslada estos cálculos a SQL Azure, ahorra en una instancia de rol en esta situación. Como SQL Azure se mide según el almacenamiento y no según el uso de la CPU, en realidad obtiene ciclos de CPU gratuitos en la base de datos.

Impacto para los desarrolladores

El desarrollador que escribe el código puede tener un impacto directo en los costos. Por ejemplo, cuando construye un sitio web de ASP.NET que Windows Azure hospedará, puede distribuir en todas las instancias de rol mediante el proveedor de estado de sesión con copia de seguridad del almacenamiento de Windows Azure. Este proveedor almacena los datos de la sesión en el servicio de tablas de Windows Azure donde se mide la cantidad de almacenamiento usada, la cantidad de ancho de banda usada y el número de transacciones para realizar la facturación Observe el siguiente fragmento de código que se usa para determinar el idioma del usuario en cada solicitud:

if (Session["culture"].ToString() == "en-US") {
  // .. set to English ...
}
if (Session["culture"].ToString() == "nl-BE") {
  // .. set to Dutch ...
}

¿No hay nada incorrecto ahí? Técnicamente no, pero podría optimizarlo en un 50% si se considera una perspectiva de costos:

string culture = Session["culture"].ToString();
if (culture == "en-US") {
  // .. set to English ...
}
if (culture == "nl-BE") {
  // .. set to Dutch ...
}

Ambos fragmentos de código hacen exactamente lo mismo. El primer fragmento de código lee dos veces los datos de la sesión, mientras que el segundo los lee sólo una vez. Esto representa una ganancia del 50% del costo en ancho de banda y en recuento de transacciones. Esto también sucede con las colas. Leer un mensaje a la vez 20 veces será más caro que leer 20 mensajes a la vez.

Como puede ver, la computación nube presenta distintos ahorros y detalles para la fijación de precios en lo que respecta a hospedar una aplicación. A pesar de que la computación nube puede ser una amplia mejora en lo que se relaciona con los costos de las operaciones frente a un centro de datos tradicional, es necesario poner atención a ciertas consideraciones en la arquitectura de la aplicación cuando se diseña para la nube.

Maarten Balliauw

Maarten Balliauw* es consultor técnico en tecnologías web de RealDolmen, una de las empresas de ICT más grandes de Bélgica. Sus intereses incluyen ASP.NET MVC, PHP y Windows Azure. Es MVP de Microsoft en ASP.NET y ha publicado varios artículos sobre PHP y .NET como MSDN Magazine, Bélgica y Arquitecto de PHP. Balliauw con frecuencia se desempeña como orador en diversos eventos nacionales e internacionales. Puede visitar su blog en blog.maartenballiauw.be.*

 

Contenido relacionado