<p style="text-align: justify;">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.</p>
<div id="toc_container" class="toc_white no_bullets"><p class="toc_title">Sum&aacute;rio</p><ul class="toc_list"><li><a href="#Como-comecar"><span class="toc_number toc_depth_1">1</span> Como começar?</a></li><li><a href="#Atencao"><span class="toc_number toc_depth_1">2</span> Atenção!</a><ul><li><a href="#Volateis"><span class="toc_number toc_depth_2">2.1</span> Voláteis:</a></li><li><a href="#Nao-Volateis"><span class="toc_number toc_depth_2">2.2</span> Não Voláteis:</a></li></ul></li><li><a href="#Resolvido"><span class="toc_number toc_depth_1">3</span> Resolvido?</a><ul><li><a href="#A-solucao-para-esta-situacao-e-simples"><span class="toc_number toc_depth_2">3.1</span> A solução para esta situação é simples:</a><ul><li><ul><li><a href="#Por-Otavio-Fonseca"><span class="toc_number toc_depth_4">3.1.0.1</span> Por: Otávio Fonseca</a></li><li><a href="#Revisao-Jessica-Saliba"><span class="toc_number toc_depth_4">3.1.0.2</span> Revisão: Jéssica Saliba</a></li></ul></li></ul></li></ul></li></ul></div>
<h2 style="text-align: justify;"><span id="Como-comecar"><span style="color: #ff6600;">Como começar?</span></span></h2>
<p style="text-align: justify;">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, <strong>mas ele também pode se tornar um grande vilão para as aplicações</strong>. 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.</p>
<p style="text-align: justify;">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:</p>
<ol style="text-align: justify;">
<li>Um acesso é requisitado ao determinado dado.</li>
<li>Este primeiro acesso é feito ao banco de dados e o dado é armazenado no cache.</li>
<li>O dado é entregue ao requisitante.</li>
<li>Um segundo acesso é realizado ao mesmo dado, e é recuperado do cache.</li>
</ol>
<p style="text-align: justify;">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.</p>
<h2 style="text-align: justify;"><span id="Atencao"><span style="color: #ff6600;">Atenção!</span></span></h2>
<p style="text-align: justify;">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:</p>
<h3 style="text-align: justify;"><span id="Volateis"><span style="color: #ff6600;">Voláteis:</span></span></h3>
<ul style="text-align: justify;">
<li>Preço de produtos</li>
<li>Saldo de crédito em conta</li>
<li>Disponibilidade de produtos em estoque</li>
</ul>
<h3 style="text-align: justify;"><span id="Nao-Volateis"><span style="color: #ff6600;"><strong>Não Voláteis:</strong></span></span></h3>
<ul style="text-align: justify;">
<li>Endereços de fornecedores, clientes e filiais</li>
<li>Parâmetros diversos</li>
<li>Categorias de produtos</li>
</ul>
<p style="text-align: justify;">Em algumas arquiteturas pode ser utilizado um servidor exclusivo para cache. A Microsoft possui o<strong> <span style="color: #ff6600;">AppFabric</span></strong> que é uma solução de cache implementada no Windows Server que exerce o papel de servidor de Cache remoto.</p>
<h2 style="text-align: justify;"><span id="Resolvido"><span style="color: #ff6600;">Resolvido?</span></span></h2>
<p style="text-align: justify;">Calma&#8230; 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.</p>
<h3 style="text-align: justify;"><span id="A-solucao-para-esta-situacao-e-simples"><span style="color: #ff6600;"><strong>A solução para esta situação é simples:</strong></span></span></h3>
<p style="text-align: justify;">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.</p>
<p style="text-align: justify;">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.</p>
<p style="text-align: justify;">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.</p>
<h5 style="text-align: justify;"><span id="Por-Otavio-Fonseca">Por: Otávio Fonseca</span></h5>
<h5 style="text-align: justify;"><span id="Revisao-Jessica-Saliba">Revisão: Jéssica Saliba</span></h5>


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

One-stop shop em tecnologia

Confira outros artigos