Escalado dinámico para aplicaciones estáticas de .NET Framework - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Escalado dinámico para aplicaciones estáticas de .NET Framework

Descripción general de

Una de las principales ventajas de usar la nube para las aplicaciones es la elasticidad, es decir, la capacidad de escalar o reducir horizontalmente los recursos de computación en función de la demanda. Esto le permite pagar solo por la capacidad de computación que necesita, en lugar de aprovisionarla para los picos de uso. El Cyber Monday, día en el que los minoristas que venden por Internet pueden lograr rápidamente mucho más tráfico de lo normal (por ejemplo, incrementos de miles por ciento en cuestión de minutos), es un buen ejemplo de elasticidad.

Si va a migrar aplicaciones web de .NET heredadas a la nube (por ejemplo, aplicaciones de ASP.NET Framework que funcionan en IIS), la capacidad de escalar rápidamente los conjuntos de servidores con equilibrio de carga puede resultar difícil o imposible debido a la naturaleza activa de la aplicación. Los datos de la sesión del usuario se almacenan en la memoria de la aplicación, normalmente mediante el estado de la sesión de ASP.NET o con variables estáticas que contienen datos de varias solicitudes que deben conservarse. La afinidad entre las sesiones de los usuarios se suele mantener mediante sesiones persistentes del equilibrador de carga.

Esto supone un desafío desde el punto de vista operativo. Cuando se requiere una mayor capacidad, debe aprovisionar y agregar servidores de forma intencionada. Este proceso puede ser lento. Dejar los nodos fuera de servicio, ya sea para aplicar parches o ante fallos inesperados, puede resultar problemático para la experiencia del usuario final, ya que todos los usuarios asociados a los nodos afectados pierden su estado. En el mejor de los casos, esto requeriría que los usuarios inicien sesión de nuevo.

Al centralizar el estado de la sesión de las aplicaciones de ASP.NET y aplicar reglas de escalado automático a las aplicaciones de ASP.NET heredadas, puede aprovechar la elasticidad de la nube y, potencialmente, aprovechar los ahorros de costos al poner en marcha las aplicaciones. Por ejemplo, ahorra costos gracias a la escalabilidad de los recursos de computación, pero también puede elegir entre los diferentes modelos de precios disponibles, como reducir el uso de instancias reservadas y adherirse a los precios de las instancias de spot de Amazon.

Dos técnicas habituales incluyen el uso de Amazon DynamoDB como proveedor de estado de sesión y el uso de ElastiCache Amazon (Redis OSS) como almacén de sesiones de ASP.NET.

En el siguiente diagrama, se muestra una arquitectura que utiliza DynamoDB como proveedor de estado de sesión.

DynamoDB como proveedor de estado de sesión

El siguiente diagrama muestra una arquitectura que utiliza ElastiCache (Redis OSS) como proveedor de estado de sesión.

ElastiCache (Redis OSS) como proveedor de estado de sesión

Impacto del costo

Para ver las ventajas de escalar una aplicación de producción, le recomendamos que modele la demanda real. En esta sección se hacen las siguientes suposiciones para modelar una aplicación de muestra:

  • Las instancias que se agregan y se eliminan de la rotación son idénticas y no se introduce ninguna variación en el tamaño de las instancias.

  • Siempre hay dos servidores activos como mínimo para mantener la alta disponibilidad de la aplicación.

  • La cantidad de servidores se amplía linealmente con el tráfico (es decir, el doble de tráfico requerirá el doble de procesamiento).

  • El tráfico se modela a lo largo de un mes en incrementos de 6 horas, con una variación intradía y un pico de tráfico anormal (por ejemplo, una venta promocional) en un día en el que el tráfico se multiplica por 10. El tráfico de fin de semana se modela en función de la utilización básica.

  • El tráfico nocturno se modela en función del uso básico, mientras que el tráfico de los días laborables se modela en función del cuádruple del uso.

  • Los precios de las instancias reservadas se basan en los precios del plan de un año, sin pagos iniciales. Los precios diurnos normales se basan en los precios bajo demanda, mientras que para la demanda puntual se utilizan los precios de las instancias de spot.

El siguiente diagrama ilustra cómo este modelo aprovecha la elasticidad de una aplicación .NET en lugar de aprovisionar para hacer frente a los picos de uso. Esto se traduce en un ahorro de aproximadamente el 68 %.

Gráfico de costos del escalado automático

Si utiliza DynamoDB como mecanismo de almacenamiento del estado de la sesión, utilice los siguientes parámetros:

Storage: 20GB Session Reads: 40 million Session Writes: 20 million Pricing Model: On demand

El costo mensual estimado de este servicio es de aproximadamente 35 USD al mes.

Si utiliza ElastiCache (Redis OSS) como mecanismo de almacenamiento del estado de la sesión, utilice los siguientes parámetros:

Number of Nodes: 3 Node size: cache.t4g.medium Pricing Model: 1y reserved

El costo mensual estimado de este servicio es de aproximadamente 91 USD al mes.

Recomendaciones de optimización de costos

El primer paso es implementar el estado de la sesión en una aplicación .NET heredada. Si lo utiliza ElastiCache como mecanismo de almacenamiento de estado, siga las instrucciones que aparecen en el blog de herramientas para AWS desarrolladores ElastiCache como almacén de sesiones de ASP.NET. Si utiliza DynamoDB, siga las instrucciones de ¿Qué es? de AWS SDK for .NET la documentación. SDK for .NET

Si la aplicación utiliza la InProcsesión para empezar, asegúrese de que todos los objetos que planea almacenar en la sesión se puedan serializar. Para ello, utilice el atributo SerializableAttribute para decorar las clases cuyas instancias se almacenarán en la sesión. Por ejemplo:

[Serializable()] public class TestSimpleObject { public string SessionProperty {get;set;} }

Además, la MachineKey de .NET debe ser la misma en todos los servidores en uso. Este suele ser el caso cuando las instancias se crean a partir de una imagen de máquina de Amazon (AMI) común. Por ejemplo:

<machineKey validationKey="some long hashed value" decryptionKey="another long hashed value" validation="SHA1"/>

Sin embargo, es importante asegurarse de que, si se cambia una imagen base, se configure con la misma imagen de máquina .NET (ya sea a nivel de IIS o de servidor). Para obtener más información, consulteSystemWebSectionGroup. MachineKey Propiedad en la documentación de Microsoft.

Por último, debe definir el mecanismo para agregar servidores a un grupo de escalado automático en respuesta a un evento de escalado. Existen muchas formas de hacerlo. Recomendamos los siguientes métodos para implementar sin problemas las aplicaciones.NET Framework en una EC2 instancia de un grupo de Auto Scaling:

Recursos adicionales