As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Suporte à escalabilidade dinâmica para aplicações .NET Framework estáticas

Visão geral do

Uma das principais vantagens de usar a nuvem para aplicações é a elasticidade, ou seja, a capacidade de aumentar ou reduzir horizontalmente a computação com base na demanda. Isso permite que você pague apenas pela capacidade computacional de que precisa, em vez de provisionar para o uso de pico. A Cyber Monday, em que os varejistas on-line podem obter rapidamente muito mais tráfego do que o normal (por exemplo, milhares de pontos percentuais em questão de minutos), é um bom exemplo de elasticidade.

Se você estiver trazendo aplicações web .NET legadas para a nuvem (por exemplo, aplicações ASP.NET Framework executadas no IIS), a capacidade de escalar rapidamente os parques de servidores com balanceamento de carga pode ser difícil ou impossível devido à natureza estável da aplicação. Os dados da sessão do usuário são armazenados na memória da aplicação, geralmente com o estado da sessão do ASP.NET ou variáveis estáticas que contêm dados de solicitações cruzadas que devem ser persistidos. A afinidade da sessão do usuário geralmente é mantida por meio de sessões persistentes do balanceador de carga.

Isso se prova um desafio operacional. Quando é necessário aumentar a capacidade, você deve provisionar e adicionar servidores intencionalmente. Isso pode ser um processo lento. Colocar os nós fora de serviço em caso de aplicação de patches ou falhas inesperadas pode ser problemático para a experiência do usuário final, perdendo o estado de todos os usuários associados aos nós afetados. Na melhor das hipóteses, os usuários precisarão fazer login novamente.

Ao centralizar o estado da sessão para aplicações ASP.NET e aplicar regras de escalonamento automático às aplicações ASP.NET legadas, você pode aproveitar a elasticidade da nuvem e, possivelmente, aproveitar a redução de custos ao executar aplicações. Por exemplo, você obtém reduções de custo por meio da escalabilidade computacional, mas também pode escolher entre os diferentes modelos de preços disponíveis, como reduzir o uso de instâncias reservadas e usar os preços das instâncias spot da Amazon.

Duas técnicas comuns incluem o uso do Amazon DynamoDB como provedor de estado de sessão e o uso do ElastiCache Amazon (Redis OSS) como armazenamento de sessões do ASP.NET.

O diagrama a seguir mostra uma arquitetura que usa o DynamoDB como provedor de estado de sessão.

O diagrama a seguir mostra uma arquitetura que usa ElastiCache (Redis OSS) como provedor de estado de sessão.

Impacto do custo

Para determinar as vantagens do dimensionamento para uma aplicação de produção, recomendamos que você modele a demanda real. Esta seção faz as seguintes suposições para modelar uma aplicação de exemplo:

O diagrama a seguir ilustra como esse modelo aproveita a elasticidade em uma aplicação .NET em vez do provisionamento para uso de pico. Isso resulta em uma economia de aproximadamente 68%.

Se você usa o DynamoDB como um mecanismo de armazenamento do estado da sessão, use os seguintes parâmetros:

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

O custo mensal estimado desse serviço é de aproximadamente USD 35,00 por mês.

Se você usa ElastiCache (Redis OSS) como um mecanismo de armazenamento do estado da sessão, use os seguintes parâmetros:

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

O custo mensal estimado desse serviço é de aproximadamente USD 91,00 por mês.

Recomendações de otimização de custos

A primeira etapa é implementar o estado da sessão em uma aplicação .NET legada. Se você estiver usando ElastiCache como seu mecanismo de armazenamento de estado, siga as orientações de ElastiCache como um repositório de sessões do ASP.NET no blog de ferramentas para AWS desenvolvedores. Se você estiver usando o DynamoDB, siga as orientações de O que é AWS SDK para .NET o na documentação. SDK para .NET

Se o aplicativo usar a InProcsessão para começar, certifique-se de que todos os objetos que você planeja armazenar na sessão possam ser serializados. Para fazer isso, use o atributo SerializableAttribute para marcar classes cujas instâncias serão armazenadas na sessão. Por exemplo:

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

Além disso, o .NET MachineKey deve ser o mesmo entre todos os servidores em uso. Normalmente é o caso quando instâncias são criadas de uma Imagem de máquina da Amazon (AMI) comum. Por exemplo:

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

No entanto, é importante garantir que, se uma imagem base for alterada, ela será configurada com a mesma imagem de máquina .NET (configurável no IIS ou no nível do servidor). Para obter mais informações, consulte SystemWebSectionGroup. MachineKey Propriedade na documentação da Microsoft.

Finalmente, você deve determinar o mecanismo para adicionar servidores a um grupo do Auto Scaling em resposta a um evento de escalabilidade. Existem diversas maneiras de realizar isso. Recomendamos os seguintes métodos para implantar facilmente aplicativos.NET Framework em uma EC2 instância em um grupo de Auto Scaling:

Recursos adicionais do