No mês de fevereiro abordamos sobre a mudança de uma hospedagem compartilhada para uma hospedagem cloud e quais fatores devem ser levados em conta para esta decisão. Agora vamos para um assunto mais avançado e focado no desempenho de consultas e escritas em banco de dados. A criação de cluster de banco de dados.
A arquitetura de cluster de banco de dados é formada pela redundância do seu banco de dados em 2 instâncias ou mais instâncias. Estas instâncias, então, são balanceadas de forma a dividir com eficiência a quantidade de requisições ao banco. Mas, vamos por partes. Neste artigo pretendemos mostrar como funciona esta arquitetura.
Tópicos
Camada de Aplicação
A camada de aplicação é a parte que terá contato com o usuário e ela deverá ser inteligente para disparar requisições de escrita e leitura para as instâncias responsáveis por cada ação.
No diagrama exemplificado acima temos uma estrutura mais simples, onde todo o cluster faz leitura e escrita (configuração master-master). Neste caso apenas a camada de load balancing será o suficiente para balancear a carga. Mas em um projeto de alto fluxo isto ainda pode gerar gargalos de requisição e assim é melhor dividir as responsabilidades ainda mais.
No exemplo abaixo podemos ver uma arquitetura que divide o banco de dados em 4 instâncias, sendo 2 responsáveis por leituras e 2 responsáveis por escrita.
Camada Load Balancer
A camada Load Balancer será responsável por receber a requisição da aplicação e balancear a carga de forma efetiva para seus respectivos bancos de dados. No caso do exemplo 1, a aplicação vai simplesmente mandar a requisição e o load balancer vai dividir cada requisição para cada instância de banco de dados sem nenhuma interferência da aplicação.
No exemplo 2, a camada de aplicação irá trabalhar em conjunto com 2 load balancer. Sendo, um dividindo as cargas com os bancos de leitura e o outro com os bancos de escrita.
Assim, a camada Load Balancer será responsável por nunca deixar uma instância de banco de dados sobrecarregada enquanto a outra estiver ociosa. Com isto, seus serviço mantém maior disponibilidade para um momento de alto fluxo de processos.
Aqui na Dialhost, por exemplo, você consegue fazer esta configuração do Load Balancer através do painel de controle do DialCloud +
Camada do cluster de banco de dados
Esta é a camada principal da arquitetura e se não for bem planejada tudo pode ir por água abaixo. A primeira coisa a se pensar é qual o nível de gargalo seu sistema se encontra hoje. Caso seja um gargalo geral de requisições porque seu banco de dados encontra-se todo em apenas uma instância o primeiro exemplo pode ser o suficiente para você. Mesmo tendo uma divisão mais básica onde todas as instâncias leem e escrevem, o fato de ter uma nova instância para dividir a carga de processos já irá equilibrar o uso de recursos.
Vale aqui, analisar o nível de complexidade do sistema em questão. Para um portal com muito conteúdo, como por exemplo globo.com, esta arquitetura do exemplo 1 pode ser ineficiente, dada a quantidade de dados que lidos e inseridos a todo momento.
Após escolher entre o exemplo 1 ou o exemplo 2 é necessário configurar todas as instâncias para que elas mantenham sincronismo de dados. Qualquer falha de sincronismo aqui pode acabar com a estabilidade do seu sistema. Isto porque, um dado inserido no banco da instância X não conseguirá ser lido na instância Z ou Y. A falta de sincronismo na verdade, é um dos grandes contras desta arquitetura.
Finalizando
O cluster de dados se bem montado otimiza bastante as requisições ao seu banco de dados. Mas, como podemos ver ele possui prós e contras em sua utilização.
Prós
- Melhora a performance de escrita no banco de dados, já que elas podem ser espalhadas em infinitos bancos de dados;
- Permite que seu sistema escalone em seu cloud sem limitações;
- Pode ser ainda mais otimizado, disponibilizando bancos somente para leitura e outros para escrita;
Contras
- A aplicação deve ser inteligente para saber balancear a carga entre as instâncias;
- Se a sincronização de dados for assíncrona, é possível que os dados estejam fora de sincronia por questões de segundos;
- Se o banco de dados master (central) falhar, é preciso arrumar-lo para que o cluster volte a funcionar;
