Olá pessoal,

Espero que todos estejam bem durante a pandemia.

O objetivo deste post e da próxima série de posts é falar sobre um recurso particularmente interessante: AutoScaling.

Este post não trata sobre banco de dados. E sim sobre recursos da Cloud Oracle (OCI).

Quando pensamos em servidores de aplicação ou websites, é importante citar que nem sempre os websites são hospedados em apenas 1 servidor. Esta regra também é válida para servidores de aplicações.

A pergunta é porque não é hospedado em apenas 1 servidor?

Ora, sempre discutimos aqui no Blog sobre alta-disponibilidade, se está hospedado em apenas 1 servidor, significa que se você perder este servidor por algum motivo, seu website/aplicação ficará indisponível.

Por este motivo é muito comum que websites/aplicações sejam hospedados em mais de um servidor. Desta forma, basta garantir que todos os servidores possuam a mesma versão de código implementada (deployada) e que se tenha um endpoint (ponto de acesso) único, o que costuma acontecer deixando estes servidores atrás de um Load Balancer.

Bom, se pensarmos em ambientes On-Premises, ainda temos um grande desafio: capacidade computacional.

Num ambiente On-Premises, a empresa precisa ter um DataCenter (que pode ser local ou alugado) para armazenar seus servidores, infraestrutura elétrica, infraestrutura de redes (switches, cabeamento, etc), infraestrutura de servidores (físicos e/ou virtuais), etc. Portanto, mesmo que uma empresa possua uma “farm” de servidores (mais de um servidor), a capacidade da aplicação será limitada à capacidade computacional do parque instalado. Ou seja, se o cliente possuir 20 VM’s em 2 servidores físicos, e supondo que estes servidores físicos estejam utilizando o máximo da sua capacidade computacional, e, seja necessário aumentar a farm, a empresa obrigatoriamente precisará adicionar um servidor físico no seu ambiente. Isso significa instalação física de servidor no rack, energização do servidor, cabeamento de rede até o servidor, instalação lógica (Sistema Operacional) no servidor, configuração, etc, até que o servidor esteja pronto para receber novas VMs. Neste momento tem-se um outro problema: se eu alocar apenas 1 VM no servidor físico novo, terei uma capacidade computacional subutilizada (e já paga).

Ou seja, a computação on-premises pode ser desafiadora ao se dimensionar o Workload da empresa, pois caso o parque computacional seja muito grande, corre-se o risco de ter subutilização de máquinas. Caso o sizing não seja preciso, poderá haver superutilização, deixando o ambiente em risco caso precise ser expandido.

Além disso, quando se fala de expandir a capacidade computacional, vamos imaginar por exemplo, um aumento súbito de Workload. Algumas perguntas precisam ser feitas:

  • O scaling será automático?
  • O scaling pode ser agendado?
  • Quão rápido é para fazer o scaling-out (aumento) na farm on-premises caso o workload aumente?
  • Quão rápido é para fazer o scaling-in (diminuição) na farm on-premises caso o workload diminua?
  • O scaling terá a capacidade de incluir/remover os servidores do Load Balancer?

Para muitas destas perguntas a resposta é utilizar soluções DevOps ou algo associado com Kubernetes ou Docker. Mas, caso a solução seja VMs, as perguntas acima devem ser feitas. Com certeza haverá outras.

No Oracle Cloud Infrastructure há uma solução de scaling bem interessante, que é automática, pode ser agendada (pensando em momentos onde se saberá que haverá aumento de Workload – Black Friday por exemplo). Também pode ser automática caso haja aumento de CPU ou memória. O mesmo acontece quando há diminuição de workload. No OCI, o scaling também permite a inclusão/remoção de servidores nos Load Balancers.

Portanto, essa série de posts tratará sobre esse tema, demonstrando na teoria e prática como implementar uma solução de autoscaling.

Espero que seja útil.

Um abraço

Vinicius