Planejamento de capacidade para aplicativos do Service Fabric

Este documento ensina como estimar a quantidade de recursos (CPUs, RAM, armazenamento em disco) necessários para executar seus aplicativos do Azure Service Fabric. É comum que os requisitos de recursos mudem ao longo do tempo. Normalmente, você precisa de poucos recursos à medida que desenvolve/testa seu serviço e, em seguida, requer mais recursos à medida que entra em produção e seu aplicativo cresce em popularidade. Ao projetar seu aplicativo, pense nos requisitos de longo prazo e faça escolhas que permitam que seu serviço seja dimensionado para atender à alta demanda dos clientes.

Ao criar um cluster do Service Fabric, você decide quais tipos de máquinas virtuais (VMs) compõem o cluster. Cada VM vem com uma quantidade limitada de recursos na forma de CPUs (núcleos e velocidade), largura de banda de rede, RAM e armazenamento em disco. À medida que seu serviço cresce ao longo do tempo, você pode atualizar para VMs que oferecem mais recursos e/ou adicionar mais VMs ao cluster. Para fazer isso, você deve arquitetar seu serviço inicialmente para que ele possa aproveitar as novas VMs que são adicionadas dinamicamente ao cluster.

Alguns serviços gerenciam pouco ou nenhum dado nas próprias VMs. Portanto, o planejamento de capacidade para esses serviços deve se concentrar principalmente no desempenho, o que significa selecionar as CPUs (núcleos e velocidade) apropriadas das VMs. Além disso, você deve considerar a largura de banda da rede, incluindo a frequência com que as transferências de rede estão ocorrendo e a quantidade de dados que está sendo transferida. Se o serviço precisar ter um bom desempenho à medida que o uso do serviço aumentar, você poderá adicionar mais VMs ao cluster e balancear a carga das solicitações de rede em todas as VMs.

Para serviços que gerenciam grandes quantidades de dados nas VMs, o planejamento de capacidade deve se concentrar principalmente no tamanho. Assim, você deve considerar cuidadosamente a capacidade da RAM e do armazenamento em disco da VM. O sistema de gerenciamento de memória virtual no Windows faz com que o espaço em disco pareça RAM para o código do aplicativo. Além disso, o tempo de execução do Service Fabric fornece paginação inteligente mantendo apenas dados quentes na memória e movendo os dados frios para o disco. Assim, os aplicativos podem usar mais memória do que a fisicamente disponível na VM. Ter mais RAM simplesmente aumenta o desempenho, uma vez que a VM pode manter mais armazenamento em disco na RAM. A VM selecionada deve ter um disco grande o suficiente para armazenar os dados desejados na VM. Da mesma forma, a VM deve ter RAM suficiente para fornecer o desempenho desejado. Se os dados do seu serviço crescerem com o tempo, você poderá adicionar mais VMs ao cluster e particionar os dados em todas as VMs.

Determinar quantos nós você precisa

O particionamento do serviço permite dimensionar os dados do serviço. Para obter mais informações sobre particionamento, consulte Particionamento do Service Fabric. Cada partição deve caber dentro de uma única VM, mas várias partições (pequenas) podem ser colocadas em uma única VM. Assim, ter mais partições pequenas dá-lhe maior flexibilidade do que ter algumas partições maiores. A contrapartida é que ter muitas partições aumenta a sobrecarga do Service Fabric e você não pode executar operações transacionadas entre partições. Há também mais tráfego de rede potencial se o seu código de serviço frequentemente precisa acessar partes de dados que vivem em partições diferentes. Ao projetar seu serviço, você deve considerar cuidadosamente esses prós e contras para chegar a uma estratégia de particionamento eficaz.

Vamos supor que seu aplicativo tenha um único serviço com monitoração de estado que tenha um tamanho de armazenamento que você espera aumentar para DB_Size GB em um ano. Você está disposto a adicionar mais aplicativos (e partições) à medida que experimenta crescimento além desse ano. O fator de replicação (RF), que determina o número de réplicas do serviço, afeta o total de DB_Size. O DB_Size total em todas as réplicas é o Fator de Replicação multiplicado por DB_Size. Node_Size representa o espaço em disco/RAM por nó que você deseja usar para seu serviço. Para obter o melhor desempenho, o DB_Size deve caber na memória em todo o cluster, e um Node_Size que esteja ao redor da RAM da VM deve ser escolhido. Ao alocar um Node_Size maior que a capacidade da RAM, você está confiando na paginação fornecida pelo tempo de execução do Service Fabric. Assim, o seu desempenho pode não ser o ideal se todos os seus dados forem considerados quentes (desde então, os dados são paginados para dentro/para fora). No entanto, para muitos serviços em que apenas uma fração dos dados é quente, é mais rentável.

O número de nós necessários para o desempenho máximo pode ser calculado da seguinte forma:

Number of Nodes = (DB_Size * RF)/Node_Size

Conta para o crescimento

Você pode querer calcular o número de nós com base no DB_Size para o qual você espera que seu serviço cresça, além do DB_Size com o qual você começou. Em seguida, aumente o número de nós à medida que seu serviço cresce para que você não esteja provisionando demais o número de nós. Mas o número de partições deve ser baseado no número de nós que são necessários quando você está executando seu serviço no crescimento máximo.

É bom ter algumas máquinas extras disponíveis a qualquer momento para que você possa lidar com picos ou falhas inesperadas (por exemplo, se algumas VMs caírem). Embora a capacidade extra deva ser determinada usando os picos esperados, um ponto de partida é reservar algumas VMs extras (5-10% extras).

O precedente pressupõe um único serviço com monitoração de estado. Se você tiver mais de um serviço com monitoração de estado, será necessário adicionar os DB_Size associados aos outros serviços na equação. Como alternativa, você pode calcular o número de nós separadamente para cada serviço com monitoração de estado. Seu serviço pode ter réplicas ou partições que não estão equilibradas. Tenha em mente que as partições também podem ter mais dados do que outras. Para obter mais informações sobre particionamento, consulte o artigo sobre práticas recomendadas de particionamento. No entanto, a equação anterior é agnóstica de partição e réplica, porque o Service Fabric garante que as réplicas estejam espalhadas entre os nós de maneira otimizada.

Usar uma planilha para cálculo de custos

Agora vamos colocar alguns números reais na fórmula. Um exemplo de planilha mostra como planejar a capacidade de um aplicativo que contém três tipos de objetos de dados. Para cada objeto, aproximamos seu tamanho e quantos objetos esperamos ter. Também selecionamos quantas réplicas queremos de cada tipo de objeto. A planilha calcula a quantidade total de memória a ser armazenada no cluster.

Em seguida, inserimos um tamanho de VM e custo mensal. Com base no tamanho da VM, a planilha informa o número mínimo de partições que você deve usar para dividir seus dados para caber fisicamente nos nós. Você pode desejar um número maior de partições para acomodar as necessidades específicas de computação e tráfego de rede do seu aplicativo. A planilha mostra que o número de partições que estão gerenciando os objetos de perfil de usuário aumentou de uma para seis.

Agora, com base em todas essas informações, a planilha mostra que você pode obter fisicamente todos os dados com as partições e réplicas desejadas em um cluster de 26 nós. No entanto, esse cluster seria densamente compactado, portanto, você pode querer alguns nós adicionais para acomodar falhas e atualizações de nós. A planilha também mostra que ter mais de 57 nós não fornece nenhum valor adicional porque você teria nós vazios. Novamente, você pode querer ir acima de 57 nós de qualquer maneira para acomodar falhas e atualizações de nós. Você pode ajustar a planilha para corresponder às necessidades específicas do seu aplicativo.

Próximos passos

Confira os serviços do Partitioning Service Fabric para saber mais sobre como particionar seu serviço.