Quedas de servidor? Erros? Lentidão? Nunca mais! Veja como construir uma arquitetura “parruda” para sua aplicação

Por dti digital|
Atualizado: Jul 2023 |
Publicado: Out 2015

O mundo hoje está cada vez mais conectado à internet e a cada dia surgem novas aplicações mais complexas e “parrudas”. Isso faz com que cada vez mais necessitemos lidar com um grande volume de dados e de acessos de usuários. Estas duas variáveis acarretam diversos desafios para os desenvolvedores de software, pois é necessário garantir que todo este volume de dados esteja disponível o tempo inteiro e que o tempo de resposta seja o mais rápido possível. A velocidade de entrega dos dados é crucial, não só por uma questão mercadológica em que “tempo é dinheiro”, mas também, para o próprio conforto do usuário que não admite mais lentidão na hora de navegar.

Como começar?

Um grande volume de dados normalmente vem normalmente associado a um grande banco de dados relacional. O BD relacional fornece uma estrutura robusta e capaz de manter a integridade dos dados para operação da organização, mas ele também pode se tornar um grande vilão para as aplicações. O acesso a BD feito pela aplicação gera tempo e algumas consultas podem durar vários milissegundos (pode demorar ainda mais se este banco se encontrar em um servidor diferente).  Sabe o que isso significa? O cliente olhando para tela do computador com a ampulheta girando e esperando.

Já sabemos que o BD pode ser um vilão, mas os dados estão gravados nele, então não podemos simplesmente eliminá-lo. Porém, podemos “driblá-lo” utilizando estruturas de Cache na memória do servidor da aplicação. Uma estrutura de cache funciona basicamente da seguinte forma:

  1. Um acesso é requisitado ao determinado dado.
  2. Este primeiro acesso é feito ao banco de dados e o dado é armazenado no cache.
  3. O dado é entregue ao requisitante.
  4. Um segundo acesso é realizado ao mesmo dado, e é recuperado do cache.

O acesso à memória é muito mais rápido do que o acesso ao BD da aplicação. Com isso, economizamos tempo. É importante também definir um tempo de validade dos dados do cache, para evitar que eles fiquem defasados se armazenados por prazo maior que o devido, uma vez que as atualizações acontecem no BD. Quando este tempo expirar, um novo acesso ao banco deve ser feito.

Quer ver mais conteúdos como esse?

Atenção!

Um cuidado neste tipo de arquitetura que deve ser tomado é definir qual a volatilidade dos dados armazenados em cache (frequência em que os dados são atualizados no BD) e isto varia de acordo com cada aplicação. Desta forma podemos segmentar o cache de acordo com a volatilidade das informações, atribuindo um tempo maior para os dados menos voláteis e um tempo menor para os dados mais voláteis. Veja exemplos de cada categoria:

Voláteis:

  • Preço de produtos
  • Saldo de crédito em conta
  • Disponibilidade de produtos em estoque

Não Voláteis:

  • Endereços de fornecedores, clientes e filiais
  • Parâmetros diversos
  • Categorias de produtos

Em algumas arquiteturas pode ser utilizado um servidor exclusivo para cache. A Microsoft possui o AppFabric que é uma solução de cache implementada no Windows Server que exerce o papel de servidor de Cache remoto.

Resolvido?

Calma… até aqui conseguimos resolver o problema do tempo de resposta, mas ainda temos o problema da disponibilidade. Disponibilidade significa saber se a aplicação estará sempre (adivinha?) disponível (!) quando necessitar ser utilizada, e isto é crucial para a algumas aplicações. Vejamos um exemplo simples e prático: um site de compras em plena Black Friday possui apenas um servidor, que começa a diminuir o tempo de resposta devido ao alto volume de acessos, culminando em queda. Resultado disso: o site de compras fica fora do ar, diversos clientes ficam insatisfeitos e o site perde milhares em receita.

A solução para esta situação é simples:

replicação e balanceamento. Para ter uma garantia de disponibilidade, aplicação deve estar dispersa em no mínimo dois servidores, para que um sirva de contingência para o outro. Sobre  estes servidores deve existir um balanceador de carga que fará o papel de dividir as requisições de forma (adivinha de novo?) balanceada (!) entre cada um dos servidores. Desta forma, se ocorrer alguma falha em um servidor, automaticamente o balanceador irá destinar as requisições para o servidor que está funcional enquanto os analistas têm tempo para tornar operante novamente o servidor afetado.

Um erro grave e muito comum ao adotar este tipo de infraestrutura que algumas organizações cometem é colocar este conjunto de servidores operantes em um mesmo local físico, algumas vezes em um mesmo Storage Server ou Data Center. Isto acarreta um grande problema caso ocorra uma falha de energia elétrica que venha a afetar todo o DataCenter. Assim, o servidor principal e as réplicas ficam comprometidas em conjunto. O ideal é que a aplicação seja replicada em vários servidores em localidades diferentes para mitigar o risco de alguma falha mais grave de infraestrutura.

Com uma combinação de uma estrutura de cache com replicação e balanceamento, podemos construir uma aplicação com uma arquitetura “parruda” que irá fornecer baixo tempo de resposta em conjunto com alta disponibilidade. Assim, as organizações podem ficar tranquilas quanto à eficácia de suas aplicações.

Por: Otávio Fonseca
Revisão: Jéssica Saliba

Quer saber mais?

Desenvolvimento de Software

Confira outros artigos

Veja outros artigos de Desenvolvimento de Software