Tutorial

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

Published on December 3, 2014
Português
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:

##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:

##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

##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:

#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:

#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

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about us


About the authors


Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?
 
5 Comments


This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Boa noite. Otimo material e muito bem explicado… Aonde acho mais materias com a explicação mais a fundo sobre os assuntos.

Att., Fernando

Parabéns, excelente explicação.

Olá Mitchell,

Estou enfrentando muitos problemas de Proxy do Brasil para o DataServer dos Estados Unidos, por acaso a solução 3 ou 4 poderiam ser aplicadas com um servidor externo a Digital Ocean.

Estou usando Floating IP e seguido a minhas aplicações ficam fora do ar, mas quando vejo qual o problema é algum Proxy da Embratel para de localizar o Floating IP, mas consegue localizar o Public IP da Droplet.

traceroute to 159.203.. (159.203..), 64 hops max, 52 byte packets 1 192.168.0.1 (192.168.0.1) 215.404 ms 1.367 ms 1.314 ms 2 bd077701.virtua.com.br (189.7.119.1) 38.128 ms 36.018 ms 31.568 ms 3 bd077064.virtua.com.br (189.7.112.100) 10.869 ms 11.838 ms 12.980 ms 4 embratel-g0-0-0-3-uacc01.pae.embratel.net.br (200.213.139.37) 107.653 ms embratel-g0-0-0-8-uacc02.rjo.embratel.net.br (200.167.245.1) 33.927 ms embratel-g1-0-3-iacc05.pae.embratel.net.br (200.247.68.137) 35.125 ms 5 ebt-h0-9-0-0-tcore01.pae.embratel.net.br (200.244.213.27) 36.636 ms ebt-t0-3-1-2-udist02.pae.embratel.net.br (200.230.3.164) 34.795 ms 34.940 ms 6 ebt-bp1422-intl02.nyk.embratel.net.br (200.230.220.114) 144.453 ms ebt-t0-7-0-9-tcore01.pae.embratel.net.br (200.244.212.216) 37.562 ms ebt-t0-7-0-10-tcore01.pae.embratel.net.br (200.244.212.204) 40.647 ms 7 ebt-b1511-tcore01.ctamc.embratel.net.br (200.230.251.218) 158.782 ms * * 8 ebt-b1452-intl02.nyk.embratel.net.br (200.230.220.126) 139.229 ms 139.076 ms 137.392 ms 9 * * * 10 * * *

Alguma sugestão?

Gostaria de saber um pouco melhor como implementar a situação 3 para que faça uso também de um servidor que funcionaria como storage. Por exemplo, teria dois servidores cada um rodando a aplicação e teria que montar uma unidade para acessar e gravar dados.

Obrigado Fernando Pimenta pela tradução e Mitchell Anicas pelo post. Excelente Tutorial muito bem explicado com tudo que é preciso saber para ter um ambiente extremamente profissional, tanto para estudo como produção.

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Join the Tech Talk
Success! Thank you! Please check your email for further details.

Please complete your information!

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more
DigitalOcean Cloud Control Panel