Dimensionar recursos de computação
- 5 minutos
Uma das vantagens importantes da cloud é a capacidade de dimensionar recursos num sistema a pedido. Aumentar verticalmente (aprovisionar recursos maiores) ou aumentar horizontalmente (aprovisionar recursos adicionais) pode ajudar a reduzir a carga num sistema ao diminuir a utilização como resultado de uma maior capacidade ou distribuição mais ampla da carga de trabalho.
O dimensionamento pode ajudar a melhorar a capacidade de resposta (e o desempenho da perspetiva do utilizador) ao aumentar o débito, já que agora pode ser servido um maior número de pedidos. Isto também pode ajudar a diminuir a latência durante cargas de pico, uma vez que é colocado em fila de espera um número reduzido de pedidos durante as cargas de pico num único recurso. Além disso, o dimensionamento pode melhorar a fiabilidade do sistema ao reduzir a utilização de recursos e a impedi-la de se aproximar do ponto de rutura.
É importante observar que, embora a cloud nos permita aprovisionar facilmente recursos mais recentes ou melhores, o custo é sempre um fator oposto que tem de ser considerado. Assim, mesmo que seja benéfico aumentar vertical ou horizontalmente, também é importante reconhecer quando reduzir horizontal ou verticalmente para conservar os custos.
Dimensionamento horizontal (aumentar e reduzir horizontalmente)
O dimensionamento horizontal é uma estratégia em que são adicionados recursos adicionais ao sistema ou são removidos recursos estranhos do sistema ao longo do tempo. Este tipo de dimensionamento é benéfico para o escalão de servidor quando a carga no sistema flutua de forma inconsistente ou imprevisível. A natureza da carga de flutuação torna essencial aprovisionar a quantidade correta de recursos para processar a carga continuamente.
Algumas considerações que tornam esta tarefa desafiadora são:
- O tempo de criação de uma instância (por exemplo, uma máquina virtual)
- O modelo de preços do fornecedor de serviços cloud
- A perda potencial de receita devido à degradação do Quality of Service (QoS) ao não aumentar horizontalmente de forma antecipada.
Figura 5: Padrão de carga da amostra.
Por exemplo, considere o padrão de carga na Figura 5, acima.
Imagine que estamos a utilizar o Amazon Web Services, que cada unidade de tempo é equivalente a 1 hora do tempo real e que precisamos de um servidor para servir cinco mil pedidos. Os picos de procura são entre as unidades de tempo 6 e 8 e as unidades de tempo 14 e 16. Vamos utilizar o último como exemplo. Conseguimos detetar uma quebra na procura em relação à unidade de tempo 16 e começar a reduzir o número de recursos alocados. Como vamos de aproximadamente 90 mil pedidos para 10 mil no espaço de 3 horas, matematicamente, podemos economizar o custo de dez ou mais instâncias adicionais que teriam estado online na unidade de tempo 15.
A Figura 6 mostra um padrão de dimensionamento que ajusta a contagem de instâncias em tempo real para corresponder ao padrão de carga (as contagens de instâncias são mostradas a vermelho). Durante as horas de picos de procura, o número de instâncias é aumentado horizontalmente para 20 e 18, respetivamente, para fornecer os recursos necessários para processar o tráfego. Noutras ocasiões, a contagem de instâncias é reduzida (reduzida horizontalmente) para manter a utilização de recursos relativamente constante. Se presumirmos que cada instância custa 20 cêntimos por hora, o custo de manter 20 instâncias em execução durante 24 horas será de 96 dólares. Dimensionar a contagem de instâncias conforme mostrado reduz o custo para cerca de 42 dólares para uma poupança anual de mais de 15 mil dólares por ano. Trata-se de um montante significativo para quase todos os orçamentos de TI.
Figura 6: Ajuste de capacidade conforme a demanda.
O dimensionamento depende das características do tráfego e da carga subsequente gerada num serviço Web. Se o tráfego seguir um padrão previsível - por exemplo, com base no comportamento humano, como streaming de filmes de um serviço Web à noite - então o dimensionamento pode ser preditivo para manter a QoS. No entanto, em muitos casos, o tráfego não pode ser previsto e os sistemas de dimensionamento precisam ser reativos com base em critérios diferentes.
Vale a pena observar que o aumento e redução horizontais podem ser realizados com instâncias de contentor, bem como com instâncias de VM. As cargas de trabalho são tradicionalmente executadas na cloud em VMs, mas está a tornar-se cada vez mais comum executá-las em contentores. O dimensionamento é obtido com cargas de trabalho baseadas em VMs ao aumentar e diminuir a contagem de VMs. Da mesma forma, as cargas de trabalho baseadas em contentores podem ser dimensionadas ao variar o número de contentores. Como os contentores tendem a ser iniciados mais rapidamente do que as VMs, a elasticidade é ligeiramente maior, já que as novas instâncias de contentor podem ser colocadas online em menos tempo do que as instâncias de VM.
Dimensionamento vertical (aumentar e reduzir verticalmente)
O dimensionamento horizontal é uma forma de obter elasticidade, mas não é a única. Imagine que o tráfego para o seu site raramente excede 15 mil pedidos por unidade de tempo e aprovisiona uma única instância grande que consegue processar 20 mil pedidos, o suficiente para servir o tráfego normal razoavelmente bem e contar também com picos menores. Se a carga no site aumentar, pode acomodar razoavelmente o aumento de tráfego ao substituir a instância do servidor por uma que tenha o dobro de núcleos da CPU e o dobro da RAM. Isso é conhecido como ampliação.
O principal desafio no dimensionamento vertical é que, em geral, existe algum ponto de mudança que pode ser considerado como tempo de inatividade. Isto ocorre porque, para mover todas as operações da instância menor para uma instância maior, mesmo que o tempo de mudança seja de meros minutos, o desempenho do Quality of Service será degradado durante esse intervalo.
Outra limitação do dimensionamento vertical é a granularidade reduzida. Se tiver 10 instâncias de servidor online e precisar de aumentar temporariamente a capacidade em 10%, poderá aumentar horizontalmente de 10 para 11 instâncias e alcançar o resultado pretendido. No entanto, com o dimensionamento vertical, o tamanho de instância maior seguinte normalmente tem cerca do dobro da capacidade do anterior, o que seria o equivalente a dimensionar horizontalmente de 10 para 20 instâncias apenas para acomodar um aumento de 10% no tráfego. Isto é menos rentável do que dimensionar horizontalmente.
Uma consideração final a ser tida em conta em relação ao dimensionamento vertical é a disponibilidade. Se tiver uma instância grande que serve todos os clientes de um site e essa instância falhar, o site também ficará inativo. Por outro lado, se aprovisionar 10 instâncias pequenas para processar a mesma carga e uma delas falhar, os utilizadores podem observar uma pequena queda no desempenho, mas continuam a conseguir aceder ao site. Consequentemente, mesmo que a carga seja previsível e aumentada constantemente conforme a popularidade do serviço aumentar, muitos administradores de cloud optam por dimensionar horizontalmente em vez de verticalmente.
Dimensionar o escalão de servidor
Por vezes, a escalabilidade tem mais nuances do que simplesmente aprovisionar mais recursos (aumentar horizontalmente) ou recursos maiores (aumentar verticalmente). No escalão de servidor, uma maior procura pode aumentar a competição entre tipos específicos de recursos, como CPU, memória e largura de banda de rede. Os fornecedores de serviços cloud oferecem normalmente VMs otimizadas para cargas de trabalho de computação pesadas, cargas de trabalho com utilização intensiva da memória e cargas de trabalho com utilização intensiva da rede. Conhecer a sua carga de trabalho e escolher o tipo certo de VM é tão essencial quanto utilizar mais ou maiores VMs para resolver o problema. É melhor ter cinco VMs a processar cargas de trabalho de computação pesadas do que 10, mesmo que as VMs otimizadas para cargas de trabalho com utilização intensiva da CPU custem mais 20% relativamente às VMs mais genéricas.
O aumento dos recursos de hardware nem sempre é a melhor solução para aumentar o desempenho de um serviço. Aumentar a eficiência dos algoritmos utilizados pelo serviço também pode reduzir a contenção de recursos e melhorar a utilização ao eliminar a necessidade de dimensionar recursos físicos.
Uma consideração importante em termos de dimensionamento é a monitorização de estado (ou falta dela). Um design de serviço sem estado contribui para uma arquitetura dimensionável. Um serviço sem estado significa, essencialmente, que o pedido do cliente contém todas as informações necessárias para servir um pedido através do servidor. O servidor não armazena informações relacionadas com o cliente na instância nem armazena informações relacionadas com a sessão na instância do servidor.
Ter um serviço sem estado ajuda a alternar entre recursos, sem qualquer configuração necessária para manter o contexto (estado) da ligação do cliente para os pedidos subsequentes. Se o serviço tiver estado, o dimensionamento de recursos exigirá uma estratégia para transferir o contexto da configuração existente para a nova configuração. Tenha em atenção que existem técnicas para implementar serviços com estado, por exemplo, manter uma cache na rede para que o contexto possa ser partilhado entre os servidores.
Dimensionar a camada de dados
Em aplicações orientadas para dados, nas quais existe um grande número de leituras e escritas (ou ambas) numa base de dados ou sistema de armazenamento, o tempo de ida e volta para cada pedido é geralmente limitado pelos tempos de leitura e escrita no disco rígido. As instâncias maiores permitem um desempenho de E/S mais elevado, o que pode melhorar os tempos de procura no disco rígido e, por sua vez, reduzir a latência do serviço. Embora ter várias instâncias de dados na camada de dados possa melhorar a fiabilidade e a disponibilidade da aplicação ao fornecer redundâncias de ativação pós-falha, a replicação de dados entre várias instâncias tem vantagens adicionais ao reduzir a latência da rede se o cliente for servido por um datacenter fisicamente mais perto. Sharding, ou particionamento dos dados entre vários recursos, é outra estratégia horizontal de dimensionamento de dados em que, em vez de simplesmente replicar os dados em várias instâncias, os dados são particionados em segmentos e armazenados em vários servidores de dados.
Um desafio adicional em termos de dimensionamento da camada de dados é manter a consistência (uma operação de leitura em todas as réplicas é a mesma), a disponibilidade (leituras e escritas sempre bem-sucedidas) e a tolerância a partições (as propriedades garantidas no sistema são mantidas quando ocorrem falhas que impedem a comunicação entre os nós). Isto é muitas vezes referido como o teorema CAP, que afirma que em um sistema de banco de dados distribuído, é muito difícil obter todas as três propriedades completamente e, portanto, pode, no máximo, exibir uma combinação de duas das propriedades1º.
Referências
- Wikipédia. Teorema da PAC. https://en.wikipedia.org/wiki/CAP_theorem.