Um sistema que atende bem dez mil usuários simultâneos raramente atende vinte mil só porque ganhou o dobro de máquinas. O tempo de resposta melhora um pouco, estaciona e, em certo ponto, piora mesmo com a frota crescendo. Essa curva está no centro de qualquer discussão séria sobre escalabilidade de sistemas. Jean Pierre Lessa e Santos Ferreira, CTO, observa que a origem do problema raramente é a quantidade de servidores.
Na raiz da confusão está uma conta que parece óbvia: se uma instância processa mil requisições por segundo, dez instâncias processariam dez mil. Ela só fecharia se cada instância fosse independente das demais, e nenhuma aplicação real é. Há um banco de dados no meio, um cache, uma fila de mensagens, um bloqueio de linha. Cada um deles é compartilhado. Recurso compartilhado tem fila.
O que é a contenção e como ela impacta o desempenho em sistemas distribuídos?
Jean Pierre Lessa e Santos Ferreira explica que duas instâncias precisam gravar no mesmo registro e uma delas espera. Esse tempo parado à espera de um recurso compartilhado tem nome em modelagem de desempenho: contenção. Ela aparece no pool de conexões esgotado, no bloqueio de tabela, em qualquer trecho de código que admite uma execução por vez. A contenção limita o ganho, mas mantém a curva subindo devagar. O retorno diminui, não se inverte.
O segundo custo é mais severo, porque cresce com o quadrado do número de nós. É a coerência, o atraso até que os dados fiquem consistentes entre partes distribuídas. Cada instância nova precisa saber o que as outras fizeram, e o número de conversas cresce mais rápido que o de máquinas.
O que faz uma requisição ficar presa a um servidor?
Um usuário faz login, o servidor guarda a sessão na própria memória e, a partir dali, todas as requisições dele precisam voltar para aquela máquina. É a afinidade de sessão, e ela desmonta o balanceamento por dentro: o tráfego de um cliente pesado não se distribui, fica concentrado onde nasceu. Chaves de criptografia geradas por máquina produzem o mesmo efeito. Arquivos gravados em disco local, também.
A regra é conhecida e pouco aplicada: qualquer instância precisa atender qualquer requisição. Na prática, é retirar o estado de dentro do processo e levá-lo para onde todas alcançam, seja num armazenamento de sessão externo, seja num token que viaja com o cliente. A correção é de arquitetura, não de infraestrutura, e por isso costuma ser adiada: exige mexer no código, não no contrato do provedor.
Como descobrir qual recurso não se replica?
Antes de aumentar a frota, convém medir o que acontece com a vazão a cada instância acrescentada. Se dobrar as máquinas, rendeu quarenta por cento a mais; o limite já apareceu, e ele está no recurso que continuou único. O especialista sugere começar pela lista do que não foi replicado: banco de dados primário, sistema de arquivos, fila, cache central, serviço de autenticação.
Esse mapeamento separa o gargalo real do sintoma. Painéis costumam mostrar processador ocioso nas máquinas de aplicação enquanto a espera se acumula no banco. Nesse cenário, subir mais instâncias piora a situação, porque cada uma abre novas conexões e disputa o mesmo pool. Aumentar a máquina do banco compra tempo; separar leitura de escrita, particionar dados ou reduzir as idas ao banco compra bem mais.
O limite que a fatura da nuvem não mostra
A nuvem tornou trivial adicionar capacidade e, com isso, tornou fácil confundir gasto com solução. Um sistema mal preparado escala em custo antes de escalar em vazão: a conta cresce em linha reta enquanto o desempenho desenha aquela curva que estaciona. A fatura não aponta a causa. Ela registra o consumo, nunca a contenção que o produziu.
Escalabilidade é mais uma característica do design do software do que um recurso da infraestrutura, sendo definida muito antes do primeiro aumento de tráfego. O local onde o estado reside, o nível de sincronização que o sistema demanda e as respostas que podem ser dadas sem recorrer à fonte única de verdade estabelecem o limite. Jean Pierre Lessa e Santos Ferreira define a virada como uma mudança na questão: ao invés de perguntar quantas máquinas estão faltando, questiona-se o que ainda depende de uma única máquina.