Dimensionar recursos de computação
Uma das vantagens importantes da nuvem é a capacidade de dimensionar recursos em um sistema sob demanda. Escalar verticalmente (provisionar recursos maiores) ou horizontalmente (provisionar recursos adicionais) pode ajudar a reduzir a carga em um sistema, diminuindo a utilização como resultado da maior capacidade ou da distribuição mais ampla da carga de trabalho.
O dimensionamento pode ajudar a melhorar a capacidade de resposta (e o desempenho percebido, da perspectiva do usuário) aumentando a taxa de transferência, já que um número maior de solicitações agora pode ser atendido. Isso também pode ajudar a diminuir a latência durante cargas de pico, uma vez que há um número menor de solicitações sendo enfileiradas em um único recurso durante cargas de pico. Além disso, o dimensionamento pode aprimorar a confiabilidade do sistema, reduzindo a utilização de recursos e evitando que ela se aproximar do ponto de interrupção.
É importante observar que, embora a nuvem nos permita provisionar facilmente recursos mais recentes ou melhores, o custo é sempre um fator de contraposição que precisa ser considerado. Portanto, mesmo que seja benéfico escalar verticalmente ou horizontalmente, também é importante reconhecer quando reduzir verticalmente ou horizontalmente para conservar os custos.
Dimensionamento horizontal (escalonamento e redução horizontais)
O dimensionamento horizontal é uma estratégia na qual recursos adicionais são adicionados ao sistema ou recursos desnecessários são removidos do sistema ao longo do tempo. Esse tipo de dimensionamento é benéfico para a camada de servidor quando a carga no sistema flutua de maneira inconsistente ou imprevisível. A natureza da carga de flutuação torna essencial o provisionamento da quantidade correta de recursos para lidar com a carga em todos os momentos.
Algumas considerações que tornam isso uma tarefa desafiadora são:
- o tempo para colocação de uma instância em funcionamento (por exemplo, uma máquina virtual);
- o modelo de preços do provedor de serviços de nuvem;
- a perda potencial na receita em contraposição à degradação da QoS (Qualidade de Serviço) devido a não dimensionar horizontalmente no devido tempo.
Figura 5: Padrão de carga de exemplo.
Como exemplo, considere o padrão de carga na Figura 5 acima.
Suponha que estamos usando o Amazon Web Services, que cada unidade de tempo é equivalente a uma hora de tempo real e que exigimos que um servidor atenda a 5.000 solicitações. Há picos de demanda entre as unidades de tempo 6 e 8 e as unidades de tempo 14 e 16. Vamos usar esse último caso como exemplo. Podemos detectar uma queda na demanda em um horário próximo à unidade de tempo 16 e começar a reduzir o número de recursos alocados. Como passamos de aproximadamente 90.000 solicitações para 10.000 no espaço de 3 horas, matematicamente, podemos economizar o custo de uma dúzia de instâncias adicionais ou mais, que teriam ficado 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, com as contagens de instâncias mostradas em vermelho. Durante os horários com picos de demanda, o número de instâncias é dimensionado para 20 e 18, respectivamente, para fornecer os recursos necessários para lidar com o tráfego. Em outros momentos, a contagem de instâncias é reduzida (dimensionada horizontalmente) para manter a utilização de recursos relativamente constante. Se presumirmos que cada instância custa 20 centavos de dólar por hora, o custo de manter 20 instâncias em execução por 24 horas será de 96 dólares. Dimensionar a contagem de instâncias conforme mostrado reduz o custo para cerca de 42 dólares, totalizando uma economia anual de mais de 15.000 dólares. É um valor substancial para praticamente qualquer orçamento de TI.
Figura 6: Escalonamento e redução horizontais de acordo com a demanda.
O dimensionamento depende das características do tráfego e da respectiva carga inútil subsequente gerada em um serviço Web. Se o tráfego seguir um padrão previsível (por exemplo, com base no comportamento humano, como assistir a filmes por streaming em um serviço Web à noite), a escala poderá ser predictive para manter a QoS. No entanto, em muitas instâncias, não é possível prever o tráfego e os sistemas de dimensionamento precisam ser reativos com base em critérios diferentes.
Vale a pena observar que o escalonamento e a redução horizontais podem ser realizados com instâncias de contêiner, bem como com instâncias de VM. As cargas de trabalho tradicionalmente são executadas na nuvem em VMs, mas está se tornando cada vez mais comum para que elas sejam executadas em contêineres. O dimensionamento é obtido com cargas de trabalho baseadas em VM, aumentando e diminuindo a contagem de VMs. Da mesma maneira, as cargas de trabalho baseadas em contêiner podem ser dimensionadas pela variação do número de contêineres. Como os contêineres tendem a ser iniciados mais rapidamente do que as VMs, a elasticidade é ligeiramente maior, já que novas instâncias de contêiner podem ser colocadas online em menos tempo do que as instâncias de VM.
Dimensionamento vertical (escalonamento e redução verticais)
O dimensionamento horizontal é um modo de se obter elasticidade, mas não é o único. Suponha que o tráfego para seu site raramente exceda 15.000 solicitações por unidade de tempo e que você provisiona uma única instância grande que pode lidar com 20.000 delas. É suficiente para atender muito bem ao tráfego normal, com alguma margem para picos pequenos. Se a carga no site aumentar, você poderá acomodar razoavelmente o aumento no tráfego substituindo a instância do servidor por uma que tenha duas vezes mais núcleos de CPU e duas vezes mais RAM. Isso é conhecido como escalonamento vertical.
O principal desafio no dimensionamento vertical é que, em geral, há algum tempo usado para a mudança que pode ser considerado como tempo de inatividade. Isso ocorre porque, para mover todas as operações da instância menor para uma instância maior, mesmo se o tempo usado para a mudança for de apenas alguns minutos, a Qualidade de Serviço se degradará durante esse intervalo.
Outra limitação do dimensionamento vertical é a granularidade reduzida. Se tiver dez instâncias de servidor online e precisar aumentar a capacidade temporariamente em 10%, você poderá escalar horizontalmente de dez instâncias para 11 e obter o resultado desejado. Com o dimensionamento vertical, no entanto, o próximo tamanho de instância maior normalmente tem cerca de duas vezes a capacidade do anterior, o que seria equivalente a dimensionar horizontalmente de dez instâncias para 20, apenas para acomodar um aumento de meros 10% no tráfego. Isso é menos econômico do que dimensionar horizontalmente.
Uma consideração final a ser levada em conta em relação ao dimensionamento vertical é a disponibilidade. Se você tiver uma instância grande que atenda a todos os clientes de um site e essa instância falhar, o site também ficará inativo. Por outro lado, se você provisionar dez instâncias pequenas para lidar com a mesma carga e uma delas ficar inativa, os usuários poderão observar uma pequena queda no desempenho, mas eles ainda poderão acessar o site. Consequentemente, mesmo que a carga seja previsível e aumentada constantemente conforme a popularidade do serviço aumentar, muitos administradores de nuvem optam por dimensionar horizontalmente em vez de verticalmente.
Dimensionar a o nível do servidor
Às vezes, a escalabilidade é mais cheia de nuances do que simplesmente provisionar mais recursos (escalonamento horizontal) ou provisionar recursos maiores (escalonamento vertical). No nível do servidor, uma demanda maior pode aumentar a competição por tipos específicos de recursos, como CPU, memória e largura de banda de rede. Os provedores de serviço de nuvem normalmente oferecem VMs otimizadas para cargas de trabalho pesadas de computação, cargas de trabalho com uso intensivo de memória e cargas de trabalho com uso intensivo de rede. Conhecer sua carga de trabalho e escolher o tipo certo de VM é tão essencial quanto a utilização de mais VMs ou de VMs mais poderosas para resolver o problema. É melhor ter cinco VMs lidando com cargas de trabalho de computação pesada do que dez, mesmo se as VMs otimizadas para cargas de trabalho com uso intensivo de CPU custarem 20% a mais do que as VMs 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 usados pelo serviço também pode reduzir a contenção de recursos e aprimorar a utilização, eliminando a necessidade de dimensionamento dos recursos físicos.
Uma consideração importante quando se trata de dimensionamento é a monitoração de estado (ou a falta dela). Um design de serviço sem estado é adequado para uma arquitetura escalonável. Um serviço sem estado significa, essencialmente, que a solicitação do cliente contém todas as informações necessárias para atender a uma solicitação pelo servidor. O servidor não armazena nenhuma informação relacionada ao cliente na instância e armazena quaisquer eventuais informações relacionada à sessão na instância do servidor.
Ter um serviço sem estado ajuda a alternar entre recursos, sem necessidade de nenhuma configuração para manter o contexto (estado) da conexão do cliente para solicitações subsequentes. Se o serviço for com estado, o dimensionamento de recursos exigirá uma estratégia para transferir o contexto da configuração existente para a nova configuração. Observe que há técnicas para implementar serviços com estado. Um exemplo é a manutenção de um cache de rede para que o contexto possa ser compartilhado entre servidores.
Dimensionar a camada de dados
Em aplicativos orientados a dados, nos quais há um grande número de leituras ou gravações (às vezes, as duas coisas) em um banco de dados ou sistema de armazenamento, o tempo de ida e volta para cada solicitação é geralmente limitado por tempos de leitura e de gravação do disco rígido. Instâncias maiores permitem um desempenho de E/S maior, o que pode melhorar os tempos de busca no disco rígido e, por sua vez, reduzir a latência do serviço. Embora a existência de várias instâncias de dados na camada de dados possa melhorar a confiabilidade e a disponibilidade do aplicativo, fornecendo redundâncias de failover, a replicação de dados entre várias instâncias tem vantagens adicionais, pois reduzirá a latência de rede se o cliente for atendido por um datacenter fisicamente mais próximo dele. A fragmentação ou o particionamento dos dados em vários recursos é outra estratégia horizontal de dimensionamento de dados na qual, 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 quando se trata de dimensionar a camada de dados é a manutenção da consistência (que uma operação de leitura em todas as réplicas seja a mesma), a disponibilidade (que leituras e gravações sempre sejam bem sucedidas) e a tolerância à partição (as propriedades garantidas no sistema serem mantidas quando as falhas impedirem a comunicação entre os nós). Isso é muitas vezes chamado de teorema do CAP, que declara que, em um sistema de banco de dados distribuído, é muito difícil obter todas as três propriedades integralmente e, portanto, é viável obter, no máximo, uma combinação de duas dessas propriedades1.
Referências
- Wikipedia. Teorema do CAP. https://en.wikipedia.org/wiki/CAP_theorem.