AWS Builder Center
Servidores: onde vivem, como funcionam e por que dão tanto trabalho?

Servidores: onde vivem, como funcionam e por que dão tanto trabalho?

Antes de mergulhar no mundo serverless, vale entender por que esse tal de servidor chama tanta atenção. Neste artigo, vamos explorar o que é um servidor, como ele funciona, o que precisa pra se manter de pé e quais são os desafios que vêm junto. Esse é o primeiro de uma série sobre fundamentos de compute e serverless, então prepara o café e bora começar pelo básico.

Developer Advocate @ AWS
Se preferir consumir esse conteúdo em forma de vídeo, veja nosso canal do youtube:

O que é um servidor

Pra começo de conversa, um servidor é um computador de alto desempenho. São aqueles supercomputadores que parecem geladeiras, como os da imagem abaixo. Existem vários tipos de servidores especializados em diferentes tarefas. Eles podem armazenar, processar, gerenciar e transferir dados e arquivos, executar programas, enviar emails, disponibilizar conteúdo na internet, entre muitas outras funções.
Servidores
Podemos ainda ter servidores físicos ou virtuais. Chamamos de servidor físico aquele que a empresa dona do sistema também é dona da máquina que o executa. Ou seja, a empresa tem um datacenter, local onde armazena e mantém seu servidor, e executa código e armazena dados usando sua própria infraestrutura.
Agora você pode estar se perguntando: "e como assim servidor virtual? Os computadores não têm que existir em algum lugar?". Você está certíssimo! Acontece que uma pessoa não precisa de um supercomputador próprio para subir seu sistema, ela pode "pegar emprestado" o servidor de uma empresa que oferece esse serviço.
Esse servidor "emprestado" é o que chamamos de servidor virtual. A empresa dona do datacenter disponibiliza acesso aos seus servidores ou parte deles através da internet e desenvolvedores do mundo inteiro podem alugar seu uso.
Diagrama mostrando a diferença entre servidor físico acessado localmente e servidor virtual acessado pela nuvem
Essa oferta de serviços de computação sob demanda pela internet é justamente a definição de computação em nuvem. As empresas que oferecem esses serviços são as provedoras de nuvem como AWS, Azure, Google Cloud, ou parceiras que criam camadas de abstração sobre a nuvem como Cloudflare, Vercel, Netlify.

Para que serve um servidor

Basicamente, um servidor serve para servir... informações.
Trocadilhos e trava-línguas à parte, o nome "servidor" para as máquinas de execução de programas vem justamente desse papel que elas exercem: servir informações e funcionalidades para outras máquinas que pedem por elas, geralmente através de uma rede como a internet.
Podemos entender isso olhando para o modelo de comunicação cliente-servidor. Nele, temos o cliente que é uma máquina ou programa que pede por informações pela internet e o servidor que as oferece. Um exemplo clássico, é o acesso a sites. O seu navegador é um cliente que pede as informações de um site para o servidor onde ele está hospedado.
Chamamos isso também de modelo Request/Response. O cliente faz uma requisição, então o servidor recebe, processa e devolve a resposta.
Diagrama demonstrando cliente enviando request e servidor devolvendo response

Primeiros passos com seu servidor

Quando queremos usar servidores virtuais, precisamos especificar e reservar o pedacinho dele que vamos usar. Chamamos isso de instanciar ou criar uma instância. A instância é a unidade virtual que representa a porção do servidor reservado na nuvem para seu sistema.
Isso implica em algumas configurações que precisam ser feitas na hora de instanciar seu servidor:
  • Provisionar uma instância de servidor: você escolhe o tipo de máquina virtual que se encaixa no seu uso (instâncias mais focadas em processamento, em memória, em armazenamento, etc).
  • Selecionar CPU e memória: a CPU é o cérebro do servidor que processa as instruções, e a memória é onde os dados ficam acessíveis durante a execução. Quanto maior a demanda da sua aplicação, mais robusta precisa ser essa configuração (e mais caro fica).
  • Determinar o sistema operacional: você escolhe o sistema operacional que vai rodar na instância, como Linux ou Windows. Essa escolha impacta nas ferramentas que você terá disponíveis.
  • Configurar storage: define quanto espaço em disco sua instância vai ter para armazenar arquivos, logs e o que mais sua aplicação precisar.
  • Configurar network: aqui você define como sua instância se comunica com o mundo. Inclui regras de firewall, de qual rede privada ela faz parte e se ela é acessível publicamente pela internet ou só por outros recursos dentro da sua infraestrutura.

Você tem um servidor, e agora?

A gente sabe que quando coloca um filho no mundo, precisa cuidar. Com servidores, não é diferente. Existem alguns cuidados de manutenção que precisamos ter com os servidores para garantir que nossa aplicação continuará saudável.

Aplicação de patches

Aplicação de patches é o processo de instalar atualizações de software para corrigir vulnerabilidades de segurança, bugs de desempenho ou adicionar novas funcionalidades. Pense como aquela atualização do seu celular que você sempre adia até o aparelho começar a reclamar, só que num servidor as consequências de adiar podem ser bem mais sérias como vulnerabilidades expostas, sistema fora do ar, dados em risco... enfim, não recomendo deixar para amanhã.
Quando você usa um servidor físico, a responsabilidade de aplicar patches é toda sua. Isso vale para o sistema operacional, ferramentas instaladas e qualquer biblioteca que sua aplicação dependa. É preciso planejar janelas de manutenção, testar as atualizações em ambientes de desenvolvimento antes de aplicar em produção e garantir que nada vai quebrar no processo.
Já em servidores virtuais, parte desse trabalho é dividida com a provedora de nuvem. A AWS, por exemplo, cuida dos patches da infraestrutura física. Mas a partir do sistema operacional da sua instância pra cima, a responsabilidade volta a ser sua. Algumas provedoras oferecem serviços que automatizam esse processo, mas mesmo assim você precisa configurar e supervisionar.

Monitoramento

Imagine que você tem um sistema rodando em servidores na nuvem. É claro que você vai se preocupar em saber se seu sistema está saudável e respondendo como esperado. Para isso, é recomendado criar métricas de desempenho da aplicação como taxas de resposta com erro, resultados inesperados, volume de chamadas, etc. Você pode ainda criar alarmes em cima dessas métricas que te avisem quando algo parece estar saindo do esperado e precisa ser investigado.
Mas para além de todas essas preocupações a nível da aplicação, quando você trabalha com servidores ainda deve se atentar à saúde do próprio servidor. Precisamos lembrar que no final do dia, o servidor é uma máquina. E máquinas falham.
Algumas métricas importantes para monitorar a saúde de um servidor são:
  • Uso de CPU: indica o quanto do processamento da máquina está sendo usado. Se está sempre perto de 100%, é sinal de que sua aplicação precisa de mais capacidade ou que tem algum processo consumindo mais do que deveria.
  • Uso de memória: parecido com a CPU, mas para a memória RAM. Memória cheia pode levar a lentidões ou até travamentos.
  • Uso de disco: se o disco encher, sua aplicação simplesmente para de funcionar.
  • Tráfego de rede: quanto dado entra e sai do servidor. Picos inesperados podem indicar uso legítimo (boa notícia) ou ataques (má notícia).
  • Latência (Tempo de resposta): o quão rápido o servidor responde a requisições. Valores muito altos podem indicar uma experiência muito demorada para quem espera a resposta.
  • Disponibilidade (uptime): o servidor está de pé e respondendo? Parece básico, mas é a primeira coisa que qualquer alarme decente precisa cobrir.
Provedoras de nuvem oferecem ferramentas para acompanhar essas métricas automaticamente. Com elas, você consegue criar dashboards, alarmes e até automações que reagem a problemas sem precisar acordar você de madrugada.

Escalabilidade

As métricas que mencionamos nos ajudam na tarefa crítica de determinar quando nosso sistema precisa ser escalado, ou seja, quando a quantidade ou potência dos servidores reservados para o sistema não está dando conta de responder ao volume de requisições recebidas.
Diagrama mostrando um volume de requests baixo e apenas um servidor respondendo com sucesso e do outro lado um volume de requests alto e o servidor não conseguindo responder
Nesses casos, podemos escalar os sistemas verticalmente ou horizontalmente. Escalabilidade vertical (também chamada de "scale up") significa aumentar a capacidade de uma máquina existente, ou seja, trocar pra uma instância com mais CPU, mais memória ou mais disco. É como se você comprasse uma geladeira maior pra caber mais coisa. Funciona bem até certo ponto, mas tem um limite físico. Em algum momento, a maior máquina disponível ainda não vai ser suficiente.
Já a escalabilidade horizontal (ou "scale out") significa adicionar mais máquinas trabalhando em paralelo. Em vez de uma geladeira maior, você compra mais geladeiras. Esse modelo costuma escalar muito mais e é o padrão em sistemas modernos na nuvem, mas exige que sua aplicação seja preparada para rodar em várias instâncias ao mesmo tempo (o que adiciona complexidade).
Diagrama mostrando a diferença entre escalonamento vertical com servidor mais potente e escalonamento horizontal com mais servidores
A boa notícia é que o escalonamento pode ser configurado de forma automática nas provedoras de nuvem, no que chamamos de auto scaling. Mas mesmo automatizado, você precisa definir os critérios para escalar. Por exemplo: "adicione mais uma instância quando o uso médio de CPU passar de 70% por mais de 5 minutos" ou "remova uma instância quando o tráfego cair abaixo de X requisições por segundo". E não basta configurar e esquecer, é importante monitorar se essa configuração está reagindo bem aos seus picos reais de tráfego e ajustar quando necessário.
Quando temos várias instâncias rodando em paralelo, surge uma nova pergunta: como decidir qual instância vai atender cada requisição? É aí que entra o balanceamento de carga (ou load balancing). Um load balancer é um componente que fica entre seus clientes e seus servidores, recebendo todas as requisições e distribuindo entre as instâncias disponíveis de forma inteligente.
Além de distribuir o trabalho, o load balancer também faz health checks nas instâncias, ou seja, verifica periodicamente se cada uma está saudável. Se uma instância falhar, ele para de mandar tráfego pra ela e direciona tudo para as que estão funcionando, melhorando a resiliência do sistema todo.

O desafio de ter servidores

Como já diriam os filmes clássicos de Hollywood, com grandes processamentos de informação, vêm grandes responsabilidades (não é assim a frase?).
Vimos que para um único servidor já temos os trabalhos de:
  • Provisionar a instância e escolher o tipo certo de máquina
  • Configurar CPU, memória, sistema operacional, armazenamento e rede
  • Aplicar patches de segurança e atualizações
  • Monitorar métricas de saúde da máquina e da aplicação
  • Definir e ajustar critérios de auto scaling
  • Configurar e manter load balancers para distribuir o tráfego
Imagina então fazer isso para vários servidores ao mesmo tempo. É preciso ter muita atenção e conhecimentos variados.

Próximos passos

E se eu te dissesse que existe uma alternativa na computação em nuvem que permite que você rode seus programas sem ter que se preocupar com a manutenção dos servidores?
Essa mágica se chama serverless e vamos falar sobre ela nas próximas semanas...
Até lá, que tal ver esses conceitos que discutimos na prática? Minha recomendação é criar uma conta Free Tier na AWS  e sair brincando. Juro que você não vai ser cobrado a não ser que explicitamente escolha mudar de plano. Experimente criar uma instância no EC2 e conheça de pertinho tudo que vimos por aqui!
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article