Dimensionar recursos
Uma das vantagens mais importantes da cloud é a capacidade de dimensionar recursos num sistema a pedido. O aumento vertical (aprovisionar recursos maiores) ou horizontal (aprovisionar recursos adicionais) pode ajudar a reduzir a carga em recursos únicos ao diminuir a utilização como resultado de uma maior capacidade ou de uma distribuição mais ampla da carga de trabalho.
O dimensionamento pode ajudar a melhorar o desempenho ao aumentar o débito, uma vez que agora é possível processar 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, tal pode ajudar a melhorar a fiabilidade do sistema ao reduzir a utilização de recursos e afastar-se do ponto de rutura do recurso.
É 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, embora seja benéfico aumentar vertical ou horizontalmente, também é importante reconhecer quando reduzir horizontal ou verticalmente para poupar nos custos. Numa aplicação de escalão n, também essencial determinar a localização dos estrangulamentos, bem como o escalão a dimensionar, quer seja o escalão de dados ou de servidor.
O dimensionamento de recursos é facilitado pelo balanceamento de carga (abordado anteriormente), que ajuda a mascarar o aspeto do dimensionamento de um sistema ao ocultá-lo através de um ponto final consistente.
Estratégias de dimensionamento
Dimensionamento horizontal (aumentar ou reduzir horizontalmente)
O dimensionamento horizontal é uma estratégia que permite a adição de recursos ao sistema ou a remoção de recursos estranhos. Este tipo de dimensionamento é benéfico para o escalão do servidor quando a carga no sistema é imprevisível e varia de forma inconsistente. A variabilidade da carga torna essencial aprovisionar de forma eficiente a quantidade correta de recursos para processar a carga em qualquer altura.
O tempo de atividade de uma instância, o modelo de preços do fornecedor de serviços cloud e as potenciais perdas nas receitas provenientes da redução do QoS (Quality of Service) ao não efetuar o dimensionamento a tempo são alguns dos aspetos que fazem desta uma tarefa desafiante. Como exemplo, consideremos seguinte o padrão de carga:
Figura 6: Padrão de carga de solicitação de amostra
Imaginemos que estamos a utilizar o Amazon Web Services. Imaginemos que cada unidade de tempo é equivalente a três horas reais e que necessitamos de um servidor para processar 5 mil pedidos. Se verificar a carga durante as unidades de tempo 16 a 22, existe uma variação enorme na carga. Conseguimos detetar uma quebra na procura na unidade de tempo 16 e começar a reduzir o número de recursos alocados. Visto que vamos passar de cerca de 50 mil para quase zero pedidos no espaço de três horas, podemos poupar o custo de 10 instâncias que estariam disponíveis na unidade de tempo 16.
Agora, imaginemos que cada unidade de tempo é igual a 20 minutos reais. Nesse caso, se reduzir o tempo de atividade de todos os recursos na unidade de tempo 16 e aumentar o tempo de atividade dos novos recursos após 20 minutos, poderá aumentar os custos, uma vez que o AWS fatura cada instância de computação por hora.
Além dos aspetos mencionados acima, um fornecedor de serviços também terá de avaliar as perdas devido ao QoS reduzido durante a unidade de tempo 20, caso tenha capacidade para apenas 90 mil pedidos ao invés de 100 mil.
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 em comportamento humano, como a transmissão de filmes num serviço Web durante a noite), o dimensionamento pode ser preditivo para manter o QoS. No entanto, em muitas situações, o tráfego não pode ser previsto e os sistemas de dimensionamento têm de ser reativos com base em critérios diferentes, conforme os exemplos apresentados acima.
Dimensionamento vertical (aumentar ou reduzir verticalmente)
Existem determinados tipos de cargas para fornecedores de serviços que são mais previsíveis do que outros. Por exemplo, se souber através de padrões históricos que o número de pedidos será sempre entre 10 mil e 15 mil, pode presumir de forma de segura que um servidor com uma capacidade de 20 mil pedidos será suficiente para o fornecedor de serviços. Estas cargas podem aumentar no futuro. No entanto, desde que aumentem de forma consistente, o serviço pode ser movido para uma maior instância capaz de processar mais pedidos. Tal é mais adequado para pequenas aplicações com uma quantidade de tráfego baixa.
O desafio do dimensionamento vertical consiste sempre num ponto de mudança que pode ser visto como tempo de inatividade. Isto ocorre porque, para mover todas as operações da menor instância para uma instância maior, mesmo que o tempo de mudança seja de meros minutos, o desempenho do QoS será degradado durante esse período.
Além disso, a maioria dos fornecedores de serviços cloud oferece recursos que duplicam o poder de computação de um recurso. Por conseguinte, a granularidade do dimensionamento vertical não é tão boa como a do dimensionamento horizontal. Mesmo que a carga seja previsível e aumente continuamente com o crescimento da popularidade do serviço, muitos fornecedores de serviços escolhem o dimensionamento horizontal ao invés do dimensionamento vertical.
Considerações sobre o dimensionamento
Monitorização
A monitorização é um dos elementos mais importantes para um dimensionamento de recursos eficaz, pois permite-lhe ter métricas que podem ser utilizadas para saber que partes do sistema necessitam de dimensionamento e quando deverão ser dimensionadas. A monitorização permite analisar os padrões de tráfego ou a utilização de recursos para fazer uma avaliação informada sobre quando e quantos recursos dimensionar para maximizar o QoS e o lucro.
Existem vários aspetos dos recursos que são monitorizados para acionar o dimensionamento de recursos. A métrica mais comum é a utilização de recursos. Por exemplo, um serviço de monitorização pode acompanhar a utilização da CPU de cada nó de recurso e dimensionar os recursos se a utilização for excessiva ou demasiado baixa. Por exemplo, se a utilização de cada recurso for superior a 95%, é recomendável adicionar mais recursos, pois o sistema está sujeito a uma carga pesada. Normalmente, os fornecedores de serviços definem estes pontos de acionamento ao analisar o ponto de rutura dos nós de recurso, ao verificar quando começam a falhar e ao mapear o respetivo comportamento mediante vários níveis de carga. Embora, por motivos de custos, seja importante utilizar cada recurso ao máximo, é aconselhável deixar algum espaço para o sistema operativo permitir atividades de sobrecarga. Da mesma forma, se a utilização estiver significativamente abaixo de 50%, por exemplo, é possível que nem todos os nós de recurso sejam necessários e que alguns possam ser desaprovisionados.
Na prática, os fornecedores de serviços monitorizam geralmente uma combinação de várias métricas diferentes de um nó de recurso para avaliar quando dimensionar os recursos. Entre estas, incluem-se a utilização da CPU, os consumos de memória, o débito e a latência. O Azure fornece o Azure Monitor como serviço adicional capaz de monitorizar qualquer recurso do Azure e disponibilizar essas métricas.
Sem estado
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 do nó existente para a nova configuração do nó. Tenha em atenção que existem técnicas para implementar serviços com estado (por exemplo, manter uma cache na rede com o Memcached para que o contexto possa ser partilhado entre os servidores).
Decidir o que dimensionar
Consoante o tipo de serviço, diferentes recursos podem necessitar de dimensionamento com base na condição relevante. No escalão de serviço, consoante o tipo de aplicação, à medida que as cargas de trabalho aumentam, também aumenta a contenção de recursos para a CPU, memória, largura de banda ou todas. A monitorização do tráfego permite-nos identificar o recurso afetado e dimensioná-lo de forma adequada. Os fornecedores de serviços cloud não fornecem necessariamente granularidade de escalabilidade apenas para dimensionar a computação ou memória, mas fornecem diferentes tipos de instâncias de computação que atendem especificamente a cargas pesadas em termos de computação ou memória. Assim, por exemplo, para uma aplicação que tem cargas de trabalho intensivas em termos de memória, seria mais aconselhável aumentar verticalmente os recursos para instâncias com otimização de memória. Para aplicações que precisam de servir um grande número de pedidos que não são necessariamente pesados em termos de computação ou memória, aumentar horizontalmente várias instâncias de computação padrão pode ser uma melhor estratégia.
O aumento dos recursos de hardware pode nem sempre ser a melhor solução para aumentar o desempenho de um serviço. Aumentar a eficiência dos algoritmos utilizados pelo serviço pode também ajudar a reduzir a contenção de recursos e melhorar a utilização ao eliminar a necessidade de dimensionar recursos físicos.
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 E/S de leituras e escritas no disco rígido. As instâncias maiores permitem um desempenho de E/S mais elevado para leituras e escritas, o que pode melhorar os tempos de procura no disco rígido e, por sua vez, resultar numa grande melhoria da latência do serviço. Ter múltiplas instâncias de dados na camada de dados pode melhorar a fiabilidade e a disponibilidade da aplicação ao fornecer redundâncias de ativação pós-falha. A replicação de dados em múltiplas instâncias tem vantagens adicionais na redução da latência da rede se o cliente for servido por um datacenter fisicamente mais próximo. A fragmentação ou criação de partições dos dados em vários recursos é outra estratégia de dimensionamento horizontal de dados em que, em vez de simplesmente replicar os dados em várias instâncias, estes são particionados em várias partições e armazenados em vários servidores de dados.
O 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 chamado de teorema CAP, que declara que é muito difícil obter completamente as três propriedades num sistema de bases de dados distribuído, pelo que o sistema pode apresentar uma combinação de duas das propriedades. Ficará a saber mais sobre estratégias de dimensionamento de bases de dados e o teorema CAP em módulos posteriores.