Muita tinta é gasta no debate “monólitos versus microsserviços”, mas a verdadeira questão por trás desse debate é se a arquitetura de sistema distribuído vale o tempo do desenvolvedor e as despesas gerais. Ao pensar nas considerações operacionais reais de nossos sistemas, podemos obter algumas informações sobre se realmente precisamos de sistemas distribuídos para a maioria das coisas.
Estamos todos tão familiarizados com virtualização e abstrações entre nosso software e os servidores que o executam. Atualmente, a computação “sem servidor” está na moda, e até mesmo o “bare metal” é uma classe de máquina virtual. No entanto, cada pedaço de software é executado em um servidor. Como agora vivemos em um mundo de virtualização, a maioria desses servidores é muito maior e muito mais barata do que pensamos.
Conheça seu servidor
Esta é uma imagem de um servidor usado pelo Microsoft Azure com CPUs AMD. Começando da esquerda, a grande luminária de metal à esquerda (com os tubos de cobre) é um dissipador de calor, e as caixas de metal às quais os tubos de cobre são fixados são trocadores de calor em cada CPU. As CPUs são CPUs de servidor de terceira geração da AMD, cada uma com as seguintes especificações:
- 64 núcleos
- 128 fios
- ~2-2,5 GHz de clock
- Núcleos capazes de 4-6 instruções por ciclo de clock
- 256 MB de cache L3
No total, este servidor possui 128 núcleos com 256 threads simultâneos. Com todos os núcleos trabalhando juntos, este servidor é capaz de 4 TFLOPs de desempenho de computação de precisão dupla de pico. Esse servidor ficaria no topo da lista dos 500 melhores supercomputadores no início de 2000. Levaria até 2007 para esse servidor sair da lista dos 500 melhores. Cada núcleo de CPU é substancialmente mais poderoso do que um único núcleo de 10 anos atrás e possui um pipeline de computação muito mais amplo.
Acima e abaixo de cada CPU está a memória: 16 slots de RAM DDR4-3200 por soquete. Os DIMMs “econômicos” de maior capacidade hoje são de 64 GB. Preenchido de forma econômica, esse servidor pode conter 1 TB de memória. Preenchido com DIMMs especializados de alta capacidade (que geralmente são mais lentos que os DIMMs menores), esse servidor suporta até 8 TB de memória total. No DDR4-3200, com um total de 16 canais de memória, este servidor provavelmente terá cerca de 200 Gbps de taxa de transferência de memória em todos os seus núcleos.
Em termos de E/S, cada CPU oferece 64 pistas PCIe gen 4. Com um total de 128 pistas PCIe, este servidor é capaz de suportar 30 SSDs NVMe mais uma placa de rede. As configurações típicas que você pode comprar oferecem slots para cerca de 16 SSDs ou discos. A última coisa que eu queria destacar nesta foto está no canto superior direito, a placa de rede. Este servidor provavelmente está equipado com uma conexão de rede de 50-100 Gbps.
As capacidades de um servidor
Entre outras coisas. Atualmente, existem muitos benchmarks públicos e, se você souber como seu serviço se comporta, provavelmente poderá encontrar um benchmark semelhante.
O custo de um servidor
Em um grande provedor de hospedagem, o OVHCloud, você pode alugar um servidor HGR-HCI-6 com especificações semelhantes às acima, com 128 núcleos físicos (256 threads), 512 GB de memória e 50 Gbps de largura de banda por US$ 1.318/mês.
Mudando para a popular opção de orçamento, Hetzner, você pode alugar um servidor menor com 32 núcleos físicos e 128 GB de RAM por cerca de € 140,00/mês. Este é um servidor menor que o da OVHCloud (1/4 do tamanho), mas dá uma ideia do spread de preços entre provedores de hospedagem.
Na AWS, um dos maiores servidores que você pode alugar é o servidor m6a.metal. Ele oferece 50 Gbps de largura de banda de rede, 192 vCPUs (96 núcleos físicos) e 768 GB de memória e custa US$ 8,2944/hora na região leste dos EUA. Isso sai para US $ 6.055 / mês. O prêmio de nuvem é real!
Um servidor semelhante, com 128 núcleos físicos e 512 GB de memória (assim como NICs, SSDs e contratos de suporte apropriados), pode ser adquirido no site da Dell por cerca de US$ 40.000. No entanto, se você vai gastar tanto em um servidor, provavelmente deve conversar com um vendedor para ter certeza de que está fazendo o melhor negócio possível. Você também precisará pagar para hospedar esse servidor e conectá-lo a uma rede.
Em comparação, a compra de servidores leva cerca de 8 meses para atingir o equilíbrio em comparação com o uso de servidores em nuvem e 30 meses para obter o equilíbrio em comparação com o aluguel. É claro que comprar servidores tem muitas desvantagens, assim como alugar, então, daqui para frente, vamos pensar um pouco sobre o “prêmio de nuvem” e se você deveria estar disposto a pagá-lo (alerta de spoiler: a resposta é “sim , mas não tanto quanto as empresas de nuvem querem que você pague”).
Pensando na Nuvem
A “era da nuvem” começou para valer por volta de 2010. Na época, a CPU de última geração era uma CPU Intel Nehalem de 8 núcleos. O Hyperthreading tinha acabado de começar, então a CPU de 8 núcleos oferecia 16 threads. A aceleração de hardware estava prestes a chegar para a criptografia AES e os vetores tinham 128 bits de largura. As maiores CPUs tinham 24 MB de cache, e seu servidor poderia acomodar 256 GB de memória DDR3-1066. Se você quisesse armazenar dados, a Seagate tinha acabado de oferecer um disco rígido de 3 TB. Cada núcleo oferecia 4 FLOPs por ciclo, o que significa que seu servidor de 8 núcleos rodando a 2,5 GHz oferecia 80 GFLOPs incrivelmente rápidos.
O boom da computação distribuída veio nessa onda: se você quisesse fazer qualquer coisa que envolvesse a recuperação de dados, precisaria de muitos discos para obter a taxa de transferência de armazenamento desejada. Se você quisesse fazer grandes cálculos, geralmente precisaria de muitas CPUs. Isso significava que você precisava coordenar várias CPUs para fazer a maioria das coisas.
Desde o início, o tamanho dos servidores aumentou muito e os SSDs aumentaram o IOPS disponível por um fator de pelo menos 100, mas o tamanho das VMs e contêineres principais não aumentou muito, e ainda usamos unidades virtualizadas que executam mais como discos rígidos do que SSDs (embora essa lacuna esteja diminuindo).
Um servidor (mais um backup) geralmente é suficiente
Se você estiver fazendo algo que não seja streaming de vídeo e tiver menos de 10.000 QPS, um servidor geralmente funcionará bem para a maioria dos serviços da web. Para serviços realmente simples, um servidor pode chegar a um milhão de QPS ou mais. Muito poucos serviços da web recebem tanto tráfego – se você tiver um, você sabe disso. Mesmo se você estiver servindo vídeo, executar apenas um servidor para seu plano de controle é muito razoável. Um benchmark pode ajudá-lo a determinar onde você está. Como alternativa, você pode usar benchmarks comuns de aplicativos semelhantes ou tabelas de números de desempenho comuns para estimar o tamanho de uma máquina que você pode precisar.
Alto é melhor que largo
Quando você precisa de um cluster de computadores, se um servidor não for suficiente, usar menos servidores maiores geralmente será melhor do que usar uma grande frota de máquinas pequenas. Há uma sobrecarga diferente de zero para coordenar um cluster e essa sobrecarga é frequentemente O(n) em cada servidor. Para reduzir essa sobrecarga, geralmente você deve preferir usar alguns servidores grandes do que muitos servidores pequenos. No caso de coisas como computação sem servidor, onde você aloca pequenos contêineres de curta duração, essa sobrecarga é responsável por uma grande fração do custo de uso. No outro extremo, coordenar um cluster de um computador é trivial.
Grandes servidores e disponibilidade
A grande desvantagem de usar um único servidor grande é a disponibilidade. Seu servidor vai precisar de tempo de inatividade e vai quebrar. Executar um servidor primário e um de backup geralmente é suficiente, mantendo-os em datacenters diferentes. Uma configuração 2×2 deve apaziguar os verdadeiramente paranóicos: dois servidores em um datacenter primário (ou provedor de nuvem) e dois servidores em um datacenter de backup fornecerão muita redundância. Se você deseja uma terceira implantação de backup, geralmente pode torná-la menor do que a primária e a secundária.
No entanto, talvez você ainda precise se preocupar com falhas de hardware correlacionadas . Os discos rígidos (e agora os SSDs) são conhecidos por ocasionalmente terem falhas correlacionadas: se você vir um disco falhar, é muito mais provável que você veja uma segunda falha antes de fazer backup se seus discos forem do mesmo lote de fabricação. Serviços como o Backblaze superam isso usando muitos modelos diferentes de discos de vários fabricantes. Notícias de hackers aprenderam isso da maneira mais difícil recentemente, quando o servidor primário e de backup foram desativados ao mesmo tempo.
Se você estiver usando um provedor de hospedagem que aluga servidores pré-construídos, é prudente alugar dois tipos diferentes de servidores em cada um de seus datacenters primários e de backup. Isso deve evitar quase todos os modos de falha presentes em sistemas modernos.
Use a nuvem, mas não fique muito nublado
Uma combinação de disponibilidade e facilidade de uso é uma das grandes razões pelas quais eu (e a maioria dos outros engenheiros) gostamos de computadores em nuvem. Sim, você paga um prêmio significativo para alugar as máquinas, mas seu provedor de nuvem tem tanta experiência na construção de servidores que você nem vê a maioria das falhas e, para as outras falhas, você pode voltar a funcionar muito rapidamente alugando um nova máquina em seu conjunto quase ilimitado de computação. O trabalho deles é garantir que você não tenha tempo de inatividade e, embora nem sempre o façam perfeitamente, eles são muito bons nisso.
Os provedores de hospedagem que estão dispostos a alugar um servidor para você são uma alternativa mais barata aos provedores de nuvem, mas esses provedores às vezes podem ter baixa qualidade e alguns deles não entendem coisas como provisionamento de rede e falhas de hardware correlacionadas. Além disso, mudar de um servidor alugado para um maior é muito mais irritante do que redimensionar uma VM na nuvem. Os servidores em nuvem têm um preço premium por um bom motivo.
No entanto, quando você lida com nuvens, seus vendedores geralmente o empurram para uma arquitetura “nativa de nuvem”. São coisas como microsserviços em grupos de VMs de dimensionamento automático com legiões de balanceadores de carga entre eles e produtos de aprimoramento de bloqueio de fornecedor, como computação sem servidor e bancos de dados gerenciados de alta disponibilidade. Há uma boa razão para que os vendedores de nuvem sejam os que impulsionam a “arquitetura de nuvem” – é melhor para eles!
A sabedoria convencional é que o uso da arquitetura em nuvem é bom porque permite escalar sem esforço. Existem boas razões para usar a arquitetura nativa da nuvem, mas atender muitas pessoas não é uma delas: a maioria dos serviços pode atender milhões de pessoas ao mesmo tempo com um servidor e nunca lhe dará uma conta surpresa de cinco dígitos.
Por que devo pagar pelo pico de carga?
Uma crítica comum à abordagem de “um grande servidor” é que agora você precisa pagar pelo seu pico de uso em vez de pagar à medida que usa o que usa. Assim, a computação sem servidor ou frotas de VMs de microsserviço alinham mais de perto seus custos com seu lucro.
Infelizmente, como todos os seus serviços são executados em servidores (quer você goste ou não), alguém nessa cadeia de suprimentos está cobrando de você com base na carga de pico. Parte do “prêmio de nuvem” para balanceadores de carga, computação sem servidor e VMs pequenas se baseia em quanta capacidade extra seu provedor de nuvem precisa construir para lidar com a carga de pico. Você está pagando pela carga de pico de alguém de qualquer maneira!
Isso significa que, se sua carga de trabalho for excepcionalmente em rajadas – como uma simulação que precisa ser executada uma vez e depois desligar para sempre – você deve preferir soluções “nubladas”, mas se sua carga de trabalho não for tão rajada, muitas vezes você terá uma solução mais barata. sistema (e mais fácil construí-lo) se você optar por alguns servidores grandes. Se o uso do seu provedor de nuvem for mais intermitente do que o seu, você pagará esse prêmio sem nenhum benefício.
Esse prêmio também se aplica a VMs, não apenas a serviços em nuvem. No entanto, se você estiver executando uma VM na nuvem 24 horas por dia, 7 dias por semana, poderá evitar pagar o “prêmio de carga de pico” usando contratos de 1 ano ou negociando com um vendedor se for grande o suficiente.
Geralmente, quanto maior for a carga de trabalho, mais turva sua arquitetura deve ser.
Quanto custa estar nublado?
Ficar nublado é caro. Geralmente, eu anteciparia um prêmio de preço de 5 a 30 vezes dependendo do que você compra de uma empresa de nuvem e dependendo da linha de base. Não 5-30%, um fator entre 5 e 30.
Aqui está o preço do AWS lambda: US$ 0,20 por 1 milhão de solicitações + US$ 0,0000166667 por GB-segundo de RAM. Estou usando o preço de uma CPU x86 aqui para manter a paridade com a instância m6a.metal que vimos acima. Servidores ARM grandes e computação ARM sem servidor são mais baratos.
Supondo que seu servidor custe US$ 8,2944/hora e seja capaz de 1k QPS com 768 GB de RAM:
- 1k QPS são 60k consultas por minuto ou 3,6M consultas por hora
- Cada consulta aqui recebe 0,768 GB-segundos de RAM (amortizada)
- Substituir este servidor custaria cerca de US$ 46/hora usando computação sem servidor
O preço premium para computação sem servidor sobre a instância é um fator de 5,5. Se você puder manter esse servidor acima de 20% de utilização, usar o servidor será mais barato do que usar computação sem servidor. Isso é antes de qualquer forma de plano de economia que você possa aplicar a esse servidor – se você puder alugar esses grandes servidores no mercado spot ou se comparar com o preço que pode obter com um contrato de 1 ano, o preço premium é ainda maior.
Se você comparar com o preço de aluguel da OVHCloud para o mesmo servidor, o preço premium de comprar seu computador através do AWS lambda é um fator de 25
Se você está pensando em alugar um servidor de um provedor de hospedagem de baixo custo ou usar o AWS lambda, você deve preferir o provedor de hospedagem se puder manter o servidor operando com 5% da capacidade!
Além disso, observe que o número real de QPS não importa: se o servidor de US$ 8,2944/hora for capaz de 100 mil QPS, a consulta usará 100 vezes menos tempo de memória, o que significa que você chegará ao mesmo prêmio de 5,5x (ou 25x) . Obviamente, você deve dimensionar o tamanho do servidor para se adequar ao seu aplicativo.
Objeções comuns a um grande servidor
Se você propor o uso da abordagem de um grande servidor, muitas vezes receberá críticas de pessoas que se sentem mais à vontade com a nuvem, preferem estar na moda ou têm preocupações legítimas. Use seu julgamento quando pensar sobre isso, mas a maioria das pessoas subestima muito o quanto a “arquitetura em nuvem” realmente custa em comparação com a computação subjacente. Aqui estão algumas objeções comuns.
Mas se eu usar a Arquitetura de Nuvem, não preciso contratar administradores de sistema
Sim você faz. Eles agora são chamados de “Cloud Ops” e estão sob um gerente diferente. Além disso, sua capacidade de ler a documentação misteriosa que vem das empresas de nuvem e acompanhar os torrents correspondentes de atualizações e descontinuações os torna 5 vezes mais caros que os administradores de sistema.
Mas se eu usar a arquitetura de nuvem, não preciso fazer atualizações de segurança
Sim você faz. Você pode ter que fazer menos deles, mas os que você não precisa fazer são os mais fáceis de automatizar. Você ainda vai compartilhar a dor de auditar bibliotecas que você usa e garantir que todas as suas configurações sejam seguras.
Mas se eu usar a arquitetura de nuvem, não preciso me preocupar com a queda
As arquiteturas de “alta disponibilidade” que você obtém usando construções e microsserviços em nuvem praticamente compensam a fragilidade que adicionam devido à complexidade. Neste ponto, se você usa duas regiões de nuvem diferentes ou dois provedores de nuvem, geralmente pode presumir que isso é bom o suficiente para evitar que seu serviço caia. No entanto, os provedores de nuvem muitas vezes tiveram interrupções globais no passado e não há razão para supor que os datacenters em nuvem ficarão inativos com menos frequência do que seus servidores individuais.
Lembre-se de que estamos tentando evitar falhas correlacionadas . Os datacenters em nuvem têm muitas partes que podem falhar de maneiras correlacionadas. Os provedores de hospedagem têm muito menos dessas partes. Da mesma forma, serviços de nuvem complexos, como bancos de dados gerenciados, têm mais modos de falha do que os simples (VMs).
Mas posso desenvolver mais rapidamente se usar a arquitetura de nuvem
Então faça, e fique de olho na conta e pense quando vale a pena trocar. Este é provavelmente o argumento mais forte a favor do uso de construções nebulosas. No entanto, se você não pensar nisso à medida que cresce, provavelmente acabará queimando muito dinheiro em sua arquitetura nublada muito além da hora de mudar para algo mais chato.
Minha carga de trabalho é realmente estourada
Nuvem longe. Essa é uma ótima razão para usar coisas como computação sem servidor. Um dos grandes benefícios das construções de arquitetura em nuvem é que a escala diminui muito bem. Se sua carga de trabalho passar por longos períodos de ociosidade pontuados com grandes picos de atividade imprevisíveis, a arquitetura de nuvem provavelmente funcionará muito bem para você.
E os CDNs?
É impossível obter os benefícios de uma CDN, tanto em melhorias de latência quanto em economia de largura de banda, com um grande servidor. Isso também vale para outros sistemas que precisam ser distribuídos, como backups. Felizmente, CDNs e backups são mercados competitivos e relativamente baratos. Este é o tipo de coisa para comprar em vez de construir.
Uma nota sobre microsserviços e monólitos
Pensar em “um grande servidor” naturalmente se alinha com pensar em arquiteturas monolíticas. No entanto, você não precisa usar um monólito para usar um servidor. Você pode executar vários contêineres em um grande servidor, com um microsserviço por contêiner. No entanto, as arquiteturas de microsserviço em geral adicionam muita sobrecarga a um sistema para ganho duvidoso quando você está executando em um grande servidor.