Práticas recomendadas para ajuste de escala das políticas de design

Combinar políticas do ajuste de escala

Muitos clientes optam por combinar diferentes tipos de políticas de ajuste de escala em uma única frota para aumentar a potência e a flexibilidade do Ajuste de escala automático no AppStream 2.0. Por exemplo, você pode configurar uma política de ajuste de escala programada para aumentar o mínimo da frota às 6h, antes que os usuários comecem a trabalhar, e para diminuir o mínimo da frota às 16h, antes que os usuários parem de trabalhar. É possível combinar essa política de ajuste de escala programada com políticas de rastreamento de metas ou escalabilidade por etapas para manter um nível específico de utilização e aumentar, ou reduzir, a escala durante o dia para lidar com picos de uso. A combinação da escalabilidade programada e da escalabilidade de rastreamento de destino pode ajudar a reduzir o impacto de um aumento acentuado nos níveis de utilização, quando a capacidade é necessária imediatamente.

Evitar a rotatividade do ajuste de escala

Considere se a sua frota pode sofrer um alto grau de rotatividade devido ao seu caso de uso. A rotatividade ocorre quando um grande número de usuários inicia e encerra sessões em um curto período de tempo. Isso pode ocorrer quando muitos usuários acessam simultaneamente um aplicativo em sua frota por apenas alguns minutos antes da assinatura.

Nessas situações, o tamanho da frota pode ficar muito abaixo da capacidade desejada, pois as instâncias são encerradas quando os usuários encerram as sessões. As políticas de ajuste da escala por etapas podem não adicionar instâncias com rapidez suficiente para compensar a rotatividade e, como resultado, sua frota fica presa a um determinado tamanho.

Você pode identificar a rotatividade examinando as métricas do CloudWatch para a frota. Períodos de tempo em que sua frota tem capacidade pendente diferente de zero sem alteração (ou com muito pouca alteração) na capacidade desejada indicam que é provável ocorrer uma alta rotatividade. Com o objetivo de considerar situações de alta rotatividade, use políticas de ajuste de escala para acompanhamento de metas e escolha uma meta de utilização para que (100 - porcentagem de utilização alvo) seja maior do que a taxa de rotatividade em um período de 15 minutos. Por exemplo, se 10% da sua frota for encerrada em um período de 15 minutos devido à rotatividade de usuários, defina uma meta de utilização da capacidade de 90% ou menos para compensar a alta rotatividade.

Entender a taxa máxima de provisionamento

Os clientes que gerenciam frotas do AppStream 2.0 para um grande número de usuários devem considerar os limites de taxa de provisionamento. Esse limite afetará a rapidez com que as instâncias podem ser adicionadas a uma frota ou a todas de uma Conta da AWS.

Há dois limites a serem considerados:

• Para uma única frota, o AppStream 2.0 provisiona a uma taxa máxima de 20 instâncias por minuto.

• Para uma única Conta da AWS, o AppStream 2.0 provisiona a uma taxa de 60 instâncias por minuto (com um pico de 100 instâncias por minuto).

Se mais de três frotas forem ampliadas em paralelo, o limite da taxa de provisionamento da conta será compartilhado entre elas (por exemplo, seis frotas com escalabilidade paralela poderiam provisionar até 10 instâncias por minuto). Além disso, considere o tempo necessário para que uma determinada instância de streaming conclua o provisionamento em resposta a um evento de ajuste da escala. Para frotas não associadas a um domínio do Active Directory, isso normalmente demora 15 minutos. Para frotas unidas a um domínio do Active Directory, isso pode demorar até 25 minutos.

Por exemplo, considere estes cenários:

• Se quiser ajustar a escala de uma única frota de 0 a 1.000 instâncias, serão necessários 50 minutos (1.000 instâncias/20 instâncias por minuto) para que o provisionamento seja concluído e, em seguida, mais 15 a 25 minutos para que todas as instâncias estejam disponíveis para os usuários finais, um total de 65 a 75 minutos.

• Se quiser ajustar a escala simultaneamente de três frotas de 0 a 333 instâncias (um total de 999 instâncias na Conta da AWS), serão necessários aproximadamente 17 minutos (999/60 instâncias por minuto) para que todas as frotas concluam o provisionamento e, em seguida, mais 15 minutos para que elas fiquem disponíveis para os usuários finais, totalizando 32 a 42 minutos.

Utilizar várias zonas de disponibilidade

Escolha várias AZs na região para a implantação da sua frota. Ao selecionar várias AZs para a frota, você aumenta a probabilidade dela ser capaz de adicionar instâncias em resposta a um evento de escalabilidade. A métrica PendingCapacity do CloudWatch é um ponto de partida para avaliar a otimização do design na AZ da frota em grandes implantações. Um valor alto e sustentado de PendingCapacity pode indicar a necessidade de ampliar a escala horizontal (entre AZs). Para obter mais informações, consulte Monitoramento dos recursos do Amazon AppStream 2.0.

Por exemplo, se o ajuste de escala automático tentar provisionar instâncias para aumentar o tamanho da frota e a AZ selecionada não tiver capacidade suficiente, o ajuste de escala automático adicionará instâncias nas outras AZs especificadas para sua frota. Para obter mais informações sobre as zonas de disponibilidade e o projeto do AppStream 2.0, consulte Zonas de disponibilidade neste documento.

Monitorar métricas de erro de capacidade insuficiente

“Erro de capacidade insuficiente” é uma métrica do CloudWatch para frotas do AppStream 2.0. Esta métrica especifica o número de solicitações de sessão rejeitadas por falta de capacidade.

Ao fazer alterações em suas políticas de ajuste da escala, é útil criar um alerta do CloudWatch para notificar você quando ocorrerem erros de capacidade insuficiente. Assim, é possível ajustar rapidamente as políticas de escalabilidade e otimizar a disponibilidade para os usuários. O guia de administração fornece etapas detalhadas para monitorar seus recursos do AppStream 2.0.