Support de mise à l'échelle dynamique pour les applications statiques. NETApplications Framework

Présentation

L'un des principaux avantages de l'utilisation du cloud pour les applications est l'élasticité, c'est-à-dire la capacité de faire évoluer le calcul en fonction de la demande. Cela vous permet de payer uniquement pour la capacité de calcul dont vous avez besoin, plutôt que de la provisionner en cas de pic d'utilisation. Le Cyber Monday, au cours duquel les détaillants en ligne peuvent rapidement obtenir beaucoup plus de trafic que d'habitude (par exemple, des milliers de pour cent en quelques minutes), est un bon exemple d'élasticité.

Si vous apportez un héritage. NETapplications Web vers le cloud (par exemple,ASP. NETFramework (applications exécutées surIIS), il peut être difficile, voire impossible, de faire évoluer rapidement des batteries de serveurs à charge équilibrée en raison de la nature dynamique de l'application. Les données de session utilisateur sont stockées dans la mémoire de l'application, généralement avec ASP. NETétat de session ou variables statiques contenant des données de requêtes croisées qui doivent être conservées. L'affinité de session utilisateur est généralement maintenue par le biais de sessions permanentes de l'équilibreur de charge.

Cela s'avère difficile sur le plan opérationnel. Lorsqu'une capacité accrue est requise, vous devez intentionnellement provisionner et ajouter des serveurs. Ce processus peut être lent. La mise hors service des nœuds en cas d'application de correctifs ou de défaillances inattendues peut nuire à l'expérience de l'utilisateur final et entraîner une perte d'état pour tous les utilisateurs associés aux nœuds concernés. Dans le meilleur des cas, cela obligerait les utilisateurs à se reconnecter.

En centralisant l'état de session pourASP. NETapplications et application de règles de mise à l'échelle automatique aux anciennes ASP applications. NETapplications, vous pouvez tirer parti de l'élasticité du cloud et potentiellement réaliser des économies lors de l'exécution d'applications. Par exemple, vous pouvez obtenir des réductions de coûts grâce à l'évolutivité du calcul, mais vous pouvez également choisir parmi les différents modèles de tarification disponibles, tels que la réduction de l'utilisation des instances réservées et l'utilisation de la tarification des instances Amazon Spot.

Deux techniques courantes incluent l'utilisation d'Amazon DynamoDB en tant que fournisseur d'état de session et l'utilisation d' ElastiCache Amazon (OSSRedis) en tant que. ASP NETmagasin de sessions.

Le schéma suivant montre une architecture qui utilise DynamoDB comme fournisseur d'état de session.

Le schéma suivant montre une architecture qui utilise ElastiCache (RedisOSS) comme fournisseur d'état de session.

Impact sur les coûts

Pour déterminer les avantages de la mise à l'échelle pour une application de production, nous vous recommandons de modéliser votre demande réelle. Cette section repose sur les hypothèses suivantes pour modéliser un exemple d'application :

• Les instances ajoutées et supprimées de la rotation sont identiques et aucune variation de taille d'instance n'est introduite.

• Le taux d'utilisation des serveurs ne descend jamais en dessous de deux serveurs actifs afin de maintenir la haute disponibilité de l'application.

• Le nombre de serveurs évolue de façon linéaire en fonction du trafic (c'est-à-dire que deux fois plus de trafic nécessitera deux fois plus de calcul).

• Le trafic est modélisé au cours d'un mois par tranches de six heures, avec des variations au cours d'une journée et un pic de trafic anormal (par exemple, une vente promotionnelle) pour une journée où le trafic est multiplié par 10. Le trafic de fin de semaine est modélisé en fonction de l'utilisation de base.

• Le trafic nocturne est modélisé en fonction de l'utilisation de base, tandis que le trafic en semaine est modélisé selon un taux d'utilisation multiplié par 4.

• La tarification des instances réservées utilise une tarification d'un an, sans frais initiaux. La tarification diurne normale utilise la tarification à la demande, tandis que la demande en rafale utilise la tarification par instance Spot.

Le schéma suivant montre comment ce modèle tire parti de l'élasticité d'un. NETapplication plutôt que de le provisionner en cas de pic d'utilisation. Cela se traduit par des économies d'environ 68 %.

Si vous utilisez DynamoDB comme mécanisme de stockage de l'état de session, utilisez les paramètres suivants :

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

Le coût mensuel estimé de ce service est d'environ 35$ par mois.

Si vous utilisez ElastiCache (RedisOSS) comme mécanisme de stockage de l'état de session, utilisez les paramètres suivants :

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

Le coût mensuel estimé de ce service est d'environ 91$ par mois.

Recommandations d'optimisation des coûts

La première étape consiste à implémenter l'état de session dans un héritage. NETdemande. Si vous l'utilisez ElastiCache comme mécanisme de stockage d'état, suivez les instructions de la section Qu'est-ce que c'est AWS SDK for .NET dans la AWS SDK for .NET documentation. Si vous utilisez DynamoDB, suivez les instructions ElastiCache de en tant que. ASP NETStockage des sessions sur le AWS blog des outils de développement.

Si l'application utilise la InProcsession pour commencer, assurez-vous que tous les objets que vous prévoyez de stocker dans la session peuvent être sérialisés. Pour ce faire, utilisez l'SerializableAttributeattribut pour décorer les classes dont les instances seront stockées dans la session. Par exemple :

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

De plus, le. NETMachineKeydoit être identique sur tous les serveurs utilisés. C'est généralement le cas lorsque les instances sont créées à partir d'une Amazon Machine Image (AMI) commune. Par exemple :

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

Cependant, il est important de s'assurer que si une image de base est modifiée, elle est configurée de la même manière. NETimage de machine (configurable au niveau du serveur IIS ou au niveau du serveur). Pour plus d'informations, consultez SystemWebSectionGroup. MachineKey Propriété figurant dans la documentation Microsoft.

Enfin, vous devez déterminer le mécanisme d'ajout de serveurs à un groupe Auto Scaling en réponse à un événement de dimensionnement. Il existe plusieurs moyens d'y parvenir. Nous recommandons les méthodes suivantes pour un déploiement fluide. NETApplications de framework pour une EC2 instance d'un groupe Auto Scaling :

• Utilisez EC2Image Builder pour configurer un AMI fichier contenant le serveur et l'application entièrement configurés. Vous pouvez ensuite l'utiliser AMI pour configurer le modèle de lancement de votre groupe Auto Scaling.

• AWS CodeDeployÀ utiliser pour déployer votre application. CodeDeploy permet une intégration directe avec Amazon EC2 Auto Scaling. Cela fournit une alternative à la création d'une nouvelle version AMI pour chaque version de l'application.

Ressources supplémentaires

• Création d'images avec EC2 Image Builder (documentation EC2 Image Builder)

• Déploiement. NETApplications Web utilisées AWS CodeDeploy avec Visual Studio Team Services (blog sur AWS les outils de développement)