- A essência do debate não é monólito vs. microsserviços, mas sim se sistemas distribuídos valem o custo em overhead de desenvolvimento/operação
- Um servidor único moderno tem dezenas a centenas de núcleos, memória na casa dos TB e I/O de dezenas a centenas de Gbps, com folga de desempenho suficiente para suportar a maioria dos serviços web
- Benchmarks reais mostram que um único servidor pode entregar Nginx 500 mil RPS, PostgreSQL 70 mil IOPS, NoSQL 1 milhão de IOPS, codificação 4K a 75 FPS e outros níveis de processamento de alto desempenho
- A nuvem oferece mais conveniência e disponibilidade, mas o prêmio de custo é considerável, então é preciso avaliar a eficiência do investimento
- Apenas quando o padrão de uso é extremamente variável arquiteturas cloud-native e serverless trazem vantagem financeira
- Porém, o prêmio de custo de serverless/micro-VMs é alto e, se a carga de trabalho for contínua/previsível, escalabilidade vertical é mais econômica
- Disponibilidade pode ser resolvida em grande parte com redundância primário/secundário (ou 2×2) e combinações de hardware diferentes, e faz sentido adotar uma estratégia em que apenas CDN e backups sejam distribuídos
Visão geral: o valor de “um único servidor grande” em vez de um sistema distribuído
- O ponto central do debate “monolítico vs. microsserviços” é julgar se vale a pena gastar tempo e dinheiro de desenvolvedores para adotar sistemas distribuídos
- O software moderno roda sobre virtualização de servidores e várias camadas de abstração; mesmo “serverless” ou “bare metal” no fim das contas são construídos sobre recursos de servidores físicos
- Os servidores de hoje têm uma eficiência de custo por desempenho muito maior do que normalmente imaginamos
- Em comparação com o passado, as especificações de servidores evoluíram drasticamente em quantidade de núcleos, largura de banda de memória, pistas PCIe e armazenamento NVMe, e muitos serviços conseguem atingir o QPS desejado sem distribuição
O forte desempenho do hardware de servidor
- Um servidor de exemplo da Microsoft Azure usa 2 CPUs AMD de 3ª geração para servidores, totalizando 128 núcleos e 256 threads
- Um único servidor pode entregar algo em torno de 4 TFLOPs de capacidade computacional, superando supercomputadores do início dos anos 2000
- Com 16 slots de DDR4-3200 por soquete, há escalabilidade para até 8 TB de memória; mesmo em opções de compra mais práticas, 1 TB de RAM já é suportado
- São 128 pistas PCIe Gen4 no total, permitindo conectar até 30 SSDs NVMe e placas de rede de 50 a 100 Gbps para armazenamento e rede de alto desempenho
O que dá para fazer com um único servidor assim (citando benchmarks)
- É possível atingir 400–800 Gbps de transmissão de vídeo, NoSQL com 1 milhão de IOPS, PostgreSQL com 70 mil IOPS e Nginx com 500 mil RPS
- Em tarefas intensivas em CPU, memória e I/O, como compilar o kernel do Linux em 20 segundos ou codificar x264 4K a 75 FPS, o throughput também é alto
Comparação de custos de aluguel e compra de servidores
- OVHCloud: servidor com 128 núcleos / 512 GB de RAM pode ser alugado por cerca de US$ 1.318 por mês
- Hetzner: oferece servidor com 32 núcleos / 128 GB de RAM por €140 por mês, com variação de preço conforme o porte
- AWS m6a.metal: servidor com 96 núcleos físicos / 768 GB de RAM custa US$ 8,29 por hora, cerca de US$ 6.055 por mês, mostrando um grande prêmio de nuvem
- Comprando um servidor similar diretamente da Dell, o custo fica em torno de US$ 40.000, com retorno do investimento frente à nuvem em cerca de 8 meses
- Assumindo a mesma capacidade de processamento em serverless, estima-se um prêmio de custo de 5,5× em relação a instâncias e de 25× em relação a hospedagem barata
Por que sistemas distribuídos ganharam tanto destaque
- No passado (por volta de 2010), as limitações de CPU, memória e armazenamento exigiam combinar vários servidores para serviços de grande porte
- Mais recentemente, com grandes servidores únicos, SSDs NVMe e alta largura de banda de memória, o limite de processamento em um único nó subiu muito, mas VMs e contêineres ainda são projetados com base em recursos de servidores menores
Quando um único servidor grande é suficiente
- A maioria dos serviços web abaixo de 10k QPS cabe tranquilamente em uma única máquina, e serviços simples podem chegar à faixa de milhão de QPS
- Mesmo em streaming de vídeo, é realista manter o control plane em um único servidor, e benchmarks com tabelas de desempenho comuns permitem estimar o tamanho adequado do servidor
- Fora situações especiais, apenas uma configuração com servidor principal e servidor de backup já é suficiente para garantir disponibilidade
“Mais alto” em vez de “mais largo”: preferir poucos servidores grandes a muitos pequenos
- Mesmo quando um cluster é necessário, alguns servidores grandes têm menos overhead de coordenação (O(n)) do que muitos servidores pequenos
- Ou seja, no longo prazo, costuma ser mais eficiente reduzir o número de servidores e aumentar suas especificações
- Em modelos baseados em serverless e contêineres efêmeros, a proporção de overhead fica ainda maior
- A desvantagem é o ponto único de falha, mas isso pode ser bastante mitigado com uma configuração primário/secundário (em DCs diferentes)
- Para mais robustez, uma configuração 2×2 (2 servidores no DC principal + 2 no DC secundário) e lotes diferentes de hardware/fabricantes distintos ajudam a evitar falhas correlacionadas
- Em locação, diversificar os modelos de servidor reduz o risco de falhas em cascata em discos ou SSDs do mesmo lote
Vantagens e limites do uso de nuvem
- A nuvem se destaca em disponibilidade, velocidade de recuperação e conveniência operacional, e há valor em pagar esse custo premium
- É possível religar rapidamente sem indisponibilidade dentro do orçamento e aproveitar grandes pools de recursos gerenciados como uma grade
- Provedores de servidores alugados têm preços menores, mas podem ficar atrás em qualidade, rede e suporte premium
- Ainda assim, a venda de nuvem costuma incentivar VMs com autoscaling, serverless e bancos HA gerenciados, ou seja, arquiteturas dependentes do fornecedor, então é preciso tomar cuidado com custos e complexidade
- Lidar com tráfego em larga escala por si só não é o principal motivo para optar por cloud-native, e há muitos casos em que um único servidor grande consegue atender milhões de usuários simultâneos
Custo de pico e critério para cargas em burst
- Alguém sempre precisa provisionar capacidade para o pico, então no fim o custo do pico será cobrado em algum ponto da cadeia de suprimentos
- Para tarefas temporárias e em burst (ex.: uma grande simulação pontual), serverless/autoscaling é econômico, mas para cargas contínuas e previsíveis, manter um servidor grande fixo é mais eficiente em custo
- Com compromissos anuais, instâncias spot e negociação comercial, o custo das instâncias pode cair ainda mais, ampliando o prêmio em relação ao serverless
Avaliação quantitativa do “prêmio de nuvem”
- Computação serverless, como o AWS Lambda, pode ter um prêmio de custo de 5 a 30 vezes em comparação com um servidor equivalente
- Exemplo: se um servidor de US$ 8,2944/hora entrega 1k QPS e 768 GB de RAM, substituir a mesma capacidade por Lambda custaria cerca de US$ 46/hora, um prêmio de 5,5×
- Em comparação com aluguel na OVH, estima-se um prêmio de 25×, e com apenas 5% de utilização, hospedagem barata já pode ser mais econômica que serverless
- Com contratos de longo prazo e instâncias spot, essa diferença de prêmio pode aumentar ainda mais
- Mesmo que o QPS varie, ao converter por memória-tempo, o múltiplo de prêmio tende a ser parecido; o essencial é escalar o servidor de acordo com o tamanho da carga de trabalho
Objeções e mal-entendidos comuns
- “Na nuvem não é preciso equipe de operações”: na prática, só mudou o nome da função para Cloud Ops; ainda são necessárias habilidades de documentação, rastreamento de mudanças e resposta a deprecações, o que pode até aumentar o custo de pessoal
- “Na nuvem não precisa aplicar atualizações de segurança”: parte disso é terceirizada, mas só em áreas fáceis de automatizar; auditoria de bibliotecas e verificação de configuração continuam necessárias
- “A nuvem dá tranquilidade por ter alta disponibilidade”: o aumento da complexidade cria novas vulnerabilidades, e até redundância entre regiões ou provedores não elimina completamente falhas correlacionadas
- “Na nuvem o desenvolvimento é mais rápido”: a agilidade inicial é uma vantagem real, então vale usar, mas é preciso monitorar o ponto de inflexão de custo para fazer a migração na hora certa
- “Nosso tráfego é muito bursty”: nesse caso, serverless e autoscaling fazem sentido
- “E a CDN?”: redução de latência e de banda é um caso claro de distribuição que vale a pena comprar, e backups entram na mesma categoria
Monolítico vs. microsserviços e a estrutura do servidor
- Um “servidor grande” se associa naturalmente a uma arquitetura monolítica, mas também é possível montar microsserviços em vários contêineres dentro de uma única máquina
- Porém, o overhead de comunicação entre processos, deploy e observabilidade continua pesando mesmo em um único host, reduzindo bastante o ganho prático de desempenho diante da complexidade adicional
- Em fase inicial ou em escala pequena e média, monólitos ou poucos serviços tendem a ser melhores em termos de simplicidade operacional
Conclusão
- Na maioria dos casos, escolher escalabilidade vertical (um único servidor grande) é mais simples e econômico do que apostar em escalabilidade horizontal ou em uma arquitetura centrada em nuvem
- Combinando redundância primário/secundário, hardware heterogêneo e terceirização de CDN/backups, é possível obter confiabilidade prática e vantagem em custo total de propriedade (TCO) em ambientes de carga contínua
- Desde que haja uma estratégia sólida de redundância de hardware, a abordagem de “um único servidor grande” pode ser uma escolha muito adequada para serviços reais
Ainda não há comentários.