Configurando sua aplicação: Como escolher a melhor configuração de servidor?

Introdução

A tecnologia e a internet tornaram-se presenças centrais em nossas vidas diárias, acadêmicas e profissionais. É por isso que o grande número de sites e aplicativos que existem simultaneamente não é uma surpresa. Se você é uma empresa, deseja ter uma plataforma web associada. Um aplicativo permite que você comercialize e entregue seus serviços aos seus clientes-alvo com facilidade.

Independentemente do motivo pelo qual você está criando um aplicativo web, você precisa determinar como construí-lo. Existem muitas opções à sua disposição quando se trata de escolher a melhor configuração de servidor. A arquitetura de servidor pela qual você optar determinará como você executa e gerencia tudo em seu ambiente. É por isso que a decisão deve ser tomada após uma consideração cuidadosa.

Como Escolher a Configuração de Servidor Correta

Então, como você decide qual arquitetura é a 'correta' para o seu aplicativo? Para fazer isso, primeiro você precisa pensar sobre quais são os requisitos para o seu aplicativo web. Deve haver certos recursos que você precisa incorporar para que ele funcione de maneira eficiente para o seu caso de uso específico. For exemplo, talvez você esteja buscando um aplicativo que seja fácil de dimensionar. Ou, talvez você precise que seu aplicativo funcione perfeitamente tanto em navegadores quanto em dispositivos móveis. Ao mesmo tempo, seu orçamento também pode ser sua principal preocupação.

Independentemente de quais sejam seus requisitos, você deve saber que pode criar uma solução personalizada para o seu aplicativo. Neste tutorial, exploraremos os vários tipos de servidores que muitas pessoas comumente usam para seus aplicativos web. Falaremos sobre os vários casos de uso e quando uma determinada configuração é melhor para ser usada. Para ajudá-lo a decidir se ela é adequada para você, também apresentaremos alguns prós e contras de cada arquitetura de servidor.

1. Tudo em um Único Servidor

Como o nome sugere, você carrega todo o ambiente em um único servidor. O ambiente incluiria seu servidor web, seu servidor de aplicação, bem como o servidor de banco de dados. Por exemplo, ele funciona na configuração de pilha Linux, Apache, MySQL, e PHP (LAMP). Você pode acompanhar nossos tutoriais sobre como instalar a pilha LAMP em um servidor Ubuntu e como instalar a pilha LAMP no CentOS.

Quando Usar:

Este tipo de arranjo funciona melhor se você estiver com pouco tempo. É simples e rápido de configurar. É por isso que funciona para aplicativos web simplistas.

Benefícios:

• Simples e fácil de entender e implementar.
• Leva pouco tempo para ser configurado em sua totalidade.

Desvantagens:

• Não permite escalabilidade horizontal.
• Oferece muito pouco em termos de isolamento de componentes.
• O aplicativo e o banco de dados estão essencialmente competindo pelos mesmos recursos, pois estão em um único servidor.
• Como resultado, você pode experimentar um desempenho ruim.

2. Servidor de Banco de Dados Separado

O principal problema ao usar um único servidor é a competição por recursos limitados. Esta configuração visa resolver esse problema. Aqui, o sistema de gerenciamento de banco de dados, ou SGBD, é mantido separado do servidor de aplicação. O servidor de banco de dados está em uma rede privada e possui seus próprios recursos. Isso resulta em melhor desempenho e maior segurança.

Quando Usar:

Novamente, se você deseja implantar uma configuração rápida, esta é bastante simples de configurar. É a solução ideal se você estiver preocupado com o banco de dados e o aplicativo competindo pelos mesmos recursos.

Benefícios:

• Recursos de sistema dedicados e separados para o aplicativo e o banco de dados, incluindo CPU, memória, E/S, etc.
• Mais potencial de escalabilidade em qualquer uma das camadas de aplicativo e banco de dados.
• Você pode adicionar e remover recursos conforme necessário.
• Se você remover o banco de dados da internet pública, também poderá aumentar sua segurança.

Desvantagens:

• Um pouco mais complexo do que uma configuração de servidor único.
• Uma conexão de rede com baixa largura de banda ou alta latência entre os dois servidores pode causar problemas de desempenho.

3. Proxy Reverso ou Balanceador de Carga

É aqui que os balanceadores de carga entram em cena. Os balanceadores de carga são normalmente usados em ambientes de servidor para melhorar o desempenho e a confiabilidade. Eles fazem isso 'balanceando a carga'; ou seja, distribuindo a carga de trabalho por uma matriz de servidores.

Quando usar:

Os balanceadores de carga são extremamente úteis para quando você precisa realizar escala horizontal. Escala horizontal basicamente significa adicionar mais servidores ao ambiente. Você também pode usar um proxy reverso de camada de aplicação para servir várias aplicações de uma só vez usando um único domínio e porta. HAProxy, Nginx, e Varnish são exemplos de software que permitem o balanceamento de carga por proxy reverso.

Benefícios:

• Caso um servidor na linha falhe, os outros servidores compensam sua função balanceando a carga de trabalho.
• Permite realizar escala horizontal para aumentar ou diminuir a capacidade do ambiente.
• Também limita as conexões de clientes, o que oferece proteção contra ataques DDoS.

Desvantagens:

• Caso os recursos do sistema não sejam suficientes, o balanceador de carga pode limitar o desempenho da sua aplicação.
• A configuração adequada é necessária para garantir o desempenho correto.
• Significativamente mais complexo do que configurações de servidor único ou servidores separados.
• Você precisa levar em consideração fatores como terminação SSL e aplicações que exigem sticky sessions.
• O principal ponto de preocupação ao usar balanceadores de carga é que eles são um ponto único de falha. Isso significa que, se o balanceador de carga falhar, todo o seu serviço ficará fora do ar.

4. Acelerador HTTP ou Proxy Reverso de Cache

Esta é uma configuração que você pode usar para aumentar a velocidade com que entrega conteúdo a um usuário da sua aplicação. Ela emprega várias técnicas para reduzir esse tempo. A mais importante delas é armazenar em cache a resposta do servidor de aplicação. O acelerador salva o conteúdo em sua memória quando um usuário o solicita pela primeira vez. Portanto, quando futuras solicitações semelhantes chegarem, ele servirá o conteúdo rapidamente sem interagir com o servidor de aplicação. O Nginx, o Varnish e o Squid são capazes de aceleração HTTP.

Quando usar:

Como é de se esperar, essa configuração é mais adequada para arquivos e conteúdos que os usuários solicitam com muita frequência. Ela também funciona muito bem para aplicações web dinâmicas com muito conteúdo.

Benefícios:

• O cache e a compressão aumentam significativamente a velocidade da aplicação e do processamento de solicitações.
• A diminuição da carga na CPU também melhora o desempenho do site.
• Você também pode usar isso como um balanceador de carga de proxy reverso.

Desvantagens:

• Você precisa ajustá-lo bem para extrair seu melhor desempenho.
• Você pode experimentar um desempenho ruim caso a taxa de acertos do cache seja baixa.

5. Replicação de Banco de Dados Primário-Réplica

Uma configuração de replicação de banco de dados primário-réplica é normalmente muito útil para sistemas que realizam mais leituras do que gravações. Por exemplo, sistemas de gerenciamento de conteúdo podem realmente se beneficiar de tal arquitetura. Você precisa de um nó primário e de um ou mais nós de réplica para a replicação. Ela distribui as leituras por todos os nós. As atualizações vão apenas para o nó primário.

Quando usar:

Como mencionamos, uma configuração de banco de dados baseada em replicação ajuda a melhorar o desempenho de leitura de um sistema. Você pode usá-la para aplicações como CMS.

Benefícios:

• Melhora o desempenho de leitura do banco de dados, pois o distribui entre as réplicas.
• Se você usar o nó primário apenas para atualizações, também poderá melhorar o desempenho de gravação.

Desvantagens:

• Qualquer aplicação que tente acessar o banco de dados deve ser capaz de decidir para qual nó enviar as atualizações e as solicitações de leitura.
• Caso a réplica primária falhe, as atualizações param. Você precisa resolver o problema para permitir que as atualizações continuem.
• Não há mecanismo de failover para acomodar uma possível falha do nó primário.

Usando as Configurações de Servidor em Combinação

Felizmente, também é possível combinar várias técnicas para obter o resultado desejado. Isso significa que você pode balancear a carga dos servidores de aplicação com os servidores de cache em um único ambiente e replicar o banco de dados. Fazer isso permite que você aproveite a funcionalidade de ambos os servidores. No entanto, isso não torna a configuração mais complicada ou problemática.

Exemplo:

Tentaremos entender esse ambiente com um exemplo:

Em tal ambiente, o balanceador de carga enviará requisições estáticas para os servidores de cache. Conteúdo estático inclui itens como CSS, imagens e Javascript, entre outros. Em vez disso, ele direcionará qualquer outro tipo de requisição de conteúdo para os servidores de aplicação.

Digamos que um usuário esteja solicitando algum conteúdo estático do ambiente. Aqui está o que aconteceria:

• O balanceador de carga primeiro determinará se o conteúdo é cache-hit ou cache-miss. O conteúdo cache-hit está presente no cache, enquanto o conteúdo cache-miss não está lá. Ele faz isso verificando com o cache-backend.
• Caso seja cache-hit, o balanceador de carga envia o conteúdo para o usuário.
• Caso seja cache-miss, o servidor de cache encaminha a requisição para o backend da aplicação.
• O app-backend encontrará e enviará o conteúdo a partir do banco de dados.
• O cache-backend recebe o conteúdo do balanceador de carga. Ele também armazena esse conteúdo em cache antes de devolvê-lo ao balanceador de carga.
• Este último, então, encaminha a resposta para o usuário.

Por outro lado, aqui está o que acontecerá se o usuário solicitar conteúdo dinâmico:

• A requisição virá do usuário para o balanceador de carga.
• Esta requisição chega ao app-backend.
• O app-backend localiza o conteúdo solicitado e o retorna para o balanceador de carga.
• O usuário recebe o conteúdo.

Um dos principais benefícios de um ambiente combinado como esse é que ele é mais confiável. Não apenas isso, mas também possui capacidades de desempenho superiores. No entanto, ainda existem dois pontos únicos de falha: o balanceador de carga e o servidor de banco de dados primário.

Conclusão

Você pode usar cada configuração de servidor por si só em seu ambiente. Por outro lado, você também pode combinar algumas delas para criar uma solução personalizada. Não existe uma resposta 'correta'. Tudo depende da funcionalidade que você deseja extrair da arquitetura.

Ter um conhecimento de nível fundamental sobre como funciona cada configuração de servidor ajudará você a tomar a decisão para sua própria aplicação. A melhor coisa a fazer é começar pequeno e simples. Você pode continuar aumentando a complexidade da sua configuração à medida que ganha experiência.

Boa computação!