Construindo e otimizando um ambiente de alta disponibilidade

Eventualmente uma aplicação ou sistema pode se tornar crítico a ponto de “nunca” poder parar. As razões pelas quais esses sistemas devem estar sempre disponíveis são as mais diversas, mas em geral pode-se dizer que há questões financeiras e/ou de segurança que podem ser impactadas por eventos de indisponibilidade.

Ao pesquisarmos na internet encontramos inúmeros casos internacionais reportando queda de ações de determinadas empresas devido à indisponibilidade dos sistemas das mesmas. Mas não precisamos ir tão longe para pesquisar por falhas em serviços de grandes corporações. Há alguns anos, mais precisamente em 2009, o sistema de pagamentos de uma grande rede brasileira de cartões de débito e crédito ficou algumas horas fora do ar nas vésperas do Natal, o que fez com que muitos consumidores optassem por utilizar cartões que eram aceitos pela máquina da empresa concorrente, que, coincidentemente ou não, bateu o recorde do volume de transações.

Garantir a disponibilidade de um sistema não é uma tarefa trivial, pois deve-se levar em conta aspectos que vão muito além de componentes de software, como redundância de partes elétricas e outros componentes de infraestrutura como links, firewalls, roteadores e assim por diante.

As primeiras tentativas de criar sistemas redundantes em Java eram extremamente complexas e confusas e em geral eram “amarradas” a servidores de aplicação e ao uso das primeiras encarnações dos EJBs, que apresentavam um modelo de publicação complicado e um modelo de desenvolvimento improdutivo.

Hoje temos à nossa disposição dezenas de frameworks que oferecem, além de alta disponibilidade, outros benefícios como escalabilidade e desempenho. Independentemente de qual framework seja adotado, em geral há características comuns que são inseridas quando se quer prover um ambiente de alta disponibilidade através da adição de servidores em redundância: a complexidade aumenta e há um overhead intrínseco que é introduzido por soluções que utilizam a rede como meio de comunicação.

Neste artigo vamos explorar alguns conceitos de infraestrutura envolvidos para construir um ambiente tolerante a falhas, porém focando principalmente no ponto de vista do Software, de forma a instruir o leitor em boas práticas na criação de aplicações que ofereçam alta disponibilidade, avaliando como podemos configurar alguns componentes em particular de maneira otimizada, minimizando o overhead ocasionado pela adição de mais servidores e frameworks de replicação de dados.

Nas próximas seções vamos mostrar como configurar o Apache para atuar como balanceador de carga bem como o Hazelcast, que atuará como solução de replicação da Sessão HTTP, porém primeiramente vamos discutir alguns dos principais conceitos envolvidos na construção desse tipo de ambiente.

Pontos únicos de falha, tolerância a falhas e alta disponibilidade

A grosso modo, podemos dizer que um componente possui tolerância a falhas (FT-Fault Tolerance) se o mesmo puder continuar a oferecer seu serviço, mesmo de forma degradada, quando parte de seus subcomponentes encontrarem-se em falha. Para lidar com esse tipo de cenário, ou seja, prover FT a um componente, normalmente empregam-se técnicas de redundância, as quais, por sua vez, consistem em prover e configurar partes sobressalentes para os subcomponentes que fazem parte de um equipamento ou serviço.

Como sabemos, criar um ambiente com FT não é uma tarefa trivial e tende a se tornar cada vez mais complexa à medida que novos componentes ou serviços são introduzidos na arquitetura de um sistema. Com o objetivo de lidar com esse problema foi criada uma metodologia ...