5 configurações comuns de servidor para sua aplicação Web

###Introdução

Ao decidir qual arquitetura de servidor utilizar para seu ambiente, existem muitos fatores a considerar, tais como desempenho, escalabilidade, disponibilidade, confiabilidade, custo, e facilidade de gerenciamento.

Aqui está uma lista de configurações de servidor comumente utilizadas, com uma breve descrição de cada uma, incluindo prós e contras. Tenha em mente que todos os conceitos abordados aqui podem ser usados em várias combinações entre si, e que cada ambiente tem requisitos diferentes, assim não há uma configuração única, correta.

##1. Tudo em um único servidor

O ambiente inteiro reside em um único servidor. Para uma aplicação web típica, que incluiria um servidor web, servidor de aplicação, e um servidor de banco de dados. Uma variação comum desta configuração é a pilha LAMP, que significa Linux, Apache, MySQL, e PHP, em um único servidor.

Caso de Uso: Bom para a configuração rápida de uma aplicação, uma vez que é a configuração mais simples possível, mas oferece pouco em termos de escalabilidade e isolamento de componente.

###Prós:

• Simples

###Contras:

• Aplicação e banco de dados disputam os mesmos recursos de servidor (CPU, Memória, I/O, etc.) que, além de possível baixo desempenho, pode tornar difícil de determinar a origem (aplicação ou banco de dados) do baixo desempenho.

• Não é facilmente escalável horizontalmente

###Tutoriais Relacionados:

• How To Install LAMP On Ubuntu 14.04

##2. Servidor de banco de dados separado

O sistema gerenciador de banco de dados (SGBD) pode ser separado do resto do ambiente para eliminar a disputa de recurso entre a aplicação e a base de dados, e para aumentar a segurança removendo a base de dados da DMZ, ou internet pública.

Caso de Uso: Bom para configurar rapidamente uma aplicação, enquanto evita a aplicação e o banco de dados de disputarem os mesmos recursos de sistema.

###Prós:

• As camadas de aplicação e de banco de dados não competem pelos mesmos recursos de servidor (CPU, Memória, I/O, etc.)

• Você pode escalar verticalmente cada camada separadamente, adicionando mais recursos para qualquer servidor que necessita maior capacidade

• Dependendo da sua configuração, pode-se aumentar a segurança removendo seu banco de dados da DMZ

###Contras:

• Configuração um pouco mais complexa do que com um único servidor

• Problemas de desempenho podem surgir se a conexão de rede entre os dois servidores está com alta-latência (ou seja, os servidores estão distantes geograficamente um do outro), ou a largura de banda é muito baixa para a quantidade de dados a ser transferida.

###Tutoriais Relacionados:

• How To Set Up a Remote Database to Optimize Site Performance with MySQL
• How to Migrate A MySQL Database To A New Server On Ubuntu 14.04

##3. Balanceador de Carga (Proxy Reverso)

Balanceadores de carga podem ser adicionados a um ambiente de servidor para melhorar o desempenho e a confiabilidade distribuindo a carga por múltiplos servidores. Se um dos servidores que tem balanceamento de carga falhar, os outros servidores irão tratar o tráfego de entrada até que o servidor defeituoso volte a funcionar novamente. Ele pode ser usado também para servir múltiplas aplicações através do mesmo domínio e porta, utilizando um proxy reverso de camada 7 (camada de aplicação).

Exemplos de softwares capazes de balancear carga via proxy reverso: HAProxy, Nginx, e Varnish.

Caso de Uso: Útil em um ambiente que requer escalabilidade pela adição de mais servidores, também conhecido como escalabilidade horizontal.

###Prós:

• Habilita a escalabilidade horizontal, ou seja, a capacidade do ambiente pode ser escalada adicionando-se mais servidores a ele
• Pode proteger contra ataques DDOS limitando conexões de clientes a uma razoável quantidade e frequência

###Contras:

• O balanceador de carga pode se tornar um gargalo se ele não tiver recursos suficientes, ou se ele estiver mal configurado
• Pode apresentar complexidades que requerem consideração adicional, tais como onde executar terminação SSL e como lidar com aplicações que requerem sessões persistentes

###Tutoriais Relacionados

• An Introduction to HAProxy and Load Balancing Concepts
• How To Use HAProxy As A Layer 4 Load Balancer for WordPress Application Servers
• How To Use HAProxy As A Layer 7 Load Balancer For WordPress and Nginx

##4. Acelerador HTTP (Proxy Reverso com Cache)

Um acelerador HTTP, ou Proxy HTTP Reverso com Cache, pode ser usado para reduzir o tempo que ele leva para servir conteúdo para um usuário através de uma variedade de técnicas. A principal técnica empregada com um acelerador HTTP é fazer cache de respostas do servidor web ou do servidor de aplicação em memória, assim requisições futuras para o mesmo conteúdo podem ser servidas rapidamente, com menos interações desnecessárias com os servidores web e de aplicação.

Exemplos de softwares capazes para aceleração HTTP: Varnish, Squid, Nginx.

Caso de Uso: Útil em ambientes com aplicações web dinâmicas de conteúdo pesado, ou com muitos arquivos comumente acessados.

###Prós:

• Aumento do desempenho do site reduzindo a carga de CPU no servidor web, através de cache e compressão, aumentando assim a capacidade do usuário.
• Pode ser usado como balanceador de carga de proxy reverso
• Alguns softwares de cache podem proteger contra ataques DDOS

###Contras:

• Requer ajustes para obtenção de seu melhor desempenho
• Se a taxa de cache-hit é baixa, pode reduzir o desempenho

###Tutoriais Relacionados:

• How To Install Wordpress, Nginx, PHP, and Varnish on Ubuntu 12.04
• How To Configure a Clustered Web Server with Varnish and Nginx
• How To Configure Varnish for Drupal with Apache on Debian and Ubuntu

#5. Replicação de Banco de Dados Mestre-Escravo

Uma forma de melhorar o desempenho de um sistema de banco de dados que executa muitas leituras em comparação com as gravações, como um CMS, é a replicação de banco de dados mestre-escravo. A replicação mestre-escravo requer um nodo mestre e um ou mais nodos escravos. Nesta configuração, todas as atualizações são enviadas ao nodo mestre e as leituras podem ser distribuídas entre todos os outros nodos.

Caso de Uso: Bom para aumentar o desempenho de leitura para a camada de banco de dados de uma aplicação.

Aqui está um exemplo de uma configuração mestre-escravo, com um único nodo escravo:

###Pros:

• Melhora o desempenho de leitura de banco de dados distribuindo as leituras pelo escravos
• Pode melhorar o desempenho de gravação utilizando o mestre exclusivamente para atualizações (ele não consome tempo para servir requisições de leitura)

###Contras:

• A aplicação que acessa o banco de dados deve ter um mecanismo para determinar para qual nodo de banco de dados ele deve enviar atualizações e requisições de leitura
• Atualizações nos escravos são assíncronas, então existe uma chance de que seu conteúdo esteja desatualizado
• Se o mestre falhar, nenhuma atualização poderá ser executada no banco de dados até que seu conteúdo seja corrigido
• Não existe um failover embutido em caso de falha no nodo mestre

###Tutoriais Relacionados:

• How To Optimize WordPress Performance With MySQL Replication On Ubuntu 14.04
• How To Set Up Master Slave Replication in MySQL

#Exemplo: Combinando Conceitos

É possível fazer balanceamento de carga dos servidores de cache, adicionalmente aos servidores de aplicação, e usar replicação de banco de dados em um só ambiente. O propósito de combinar estas técnicas é colher os benefícios de cada uma sem introduzir muitos problemas e complexidade. Aqui está um exemplo de como um ambiente de servidor deve se parecer:

Suponhamos que o balanceador de carga está configurado para reconhecer requisições estáticas (como imagens, css, javascript, etc.) e enviar estas requisições diretamente aos servidores de cache, e enviar outras requisições para os servidores de aplicação.

Aqui está uma descrição do que aconteceria quando um usuário envia um pedido de conteúdo dinâmico:

1. O usuário requisita conteúdo dinâmico de http://example.com/ (balanceador de carga)
2. O balanceador de carga envia a requisição para o servidor de aplicação
3. O servidor de aplicação lê do banco de dados e retorna o conteúdo requisitado para o balanceador de carga
4. O balanceador de carga retorna o dado requisitado para o usuário

Se o usuário requisitar conteúdo estático:

1. O balanceador de carga verifica o servidor de cache para ver se o conteúdo requisitado está em cache (cache-hit) ou não (cache-miss)
2. Para cache-hit: retorna o conteúdo requisitado para o balanceador de carga e pula para o passo 7. Para cache-miss: o servidor de cache encaminha a requisição para o servidor de aplicação, através do balanceador de carga
3. O balanceador de carga encaminha a requisição através do servidor de aplicação
4. O servidor de aplicação lê do banco de dados e então retorna o conteúdo requisitado para o balanceador de carga
5. O balanceador de carga encaminha a resposta para o servidor de cache
6. O servidor de cache faz cache do conteúdo e o retorna para o balanceador de carga
7. O balanceador de carga retorna o dado requisitado para o usuário

Este ambiente tem ainda dois pontos únicos de falha (balanceador de carga e servidor de banco de dados mestre), mas ele fornece todos os outros benefícios de confiabilidade e desempenho que descrevemos em cada seção acima.

##Conclusão

Agora que você está familiarizado com algumas configurações básicas de servidor, você deve ter uma boa ideia de que tipo de configuração você gostaria de usar para a sua própria aplicação. Se você estiver trabalhando para melhorar seu próprio ambiente, lembre-se que um processo iterativo é melhor para evitar a introdução de muitas complexidades muito rapidamente.

Deixe-nos saber de quaisquer configurações você recomenda ou gostaria de aprender mais sobre, nos comentários abaixo!

Por Mitchell Anicas