Blueprint Técnico — Infraestrutura SaaS de Baixa Latência

Neste artigo, descrevo as dificuldades técnicas que aparecem no caminho de quem tenta resolver o problema de aplicações SaaS distribuídas de baixa latência. E como dá para contornar essas dificuldades, ao menos em parte.

Os critérios de sucesso são aplicações stateful, com a menor latência possível, compartilhadas por um grupo de usuários geograficamente próximos entre si. A aplicação precisa ser hospedada pelo provedor de SaaS, por dois motivos: validação dos cálculos pelo provedor e alta disponibilidade para todos os participantes.

Como você pode imaginar, esse problema vem sendo resolvido hoje de algumas formas: usando provedores de nuvem para computação em algumas áreas densamente povoadas, Content Delivery Networks para estender a conexão até localidades mais remotas e instalações on-premises em regiões que os provedores de nuvem não cobrem.

Ainda assim, conectar e gerenciar um sistema desses é uma operação complexa, que só as maiores empresas, como a Valve, topam encarar. Isso pode mudar em breve, e vou te mostrar como.

A limitação física para o público de aplicações de baixa latência são as redes. E, embora as CDNs sejam ótimas para fornecer conexões entre diversos provedores, os usuários ainda ficam muito por conta própria — vários saltos de tráfego somam latência e afastam o público de experiências de alta qualidade. Essa é uma limitação dura: em algumas regiões geográficas, só novos projetos de infraestrutura em terra e sob o mar resolvem. Tecnologias revolucionárias como o Starlink oferecem conectividade em áreas bem mais remotas, mas a latência ainda é proibitiva para aplicações de baixa latência.

Já a limitação branda é uma questão de execução — interconectar o tráfego entre diferentes provedores de nuvem, CDNs e hardware. Essa barreira já foi superada e a solução está prontamente disponível.

Para superar a limitação física de velocidade e conectividade da rede, vamos precisar provisionar a hospedagem das aplicações SaaS o mais perto possível dos usuários. Isso tem um custo e levanta a questão de como controlar uma infraestrutura desse tipo.

Uma solução genérica seria um cluster Kubernetes com nós distribuídos em várias localidades. Segundo estes benchmarks, os contêineres rodaram apenas 0,12% mais lentos do que processos nativos.

Para provisionar nós sob demanda, seria preciso operar uma solução de infraestrutura como o Terraform, para acionar as APIs dos provedores de nuvem (AWS, GCP, Azure), data centers que usam VMware e outros hypervisors. Boa parte do trabalho seria dedicada a manter essa solução em pé.

O avanço que os provedores de nuvem trouxeram, e que hoje a gente toma como garantido, é o modelo Pay-As-You-Go. Você começa a usar uma máquina virtual na AWS assim que cadastra o cartão de crédito. Sem amarras.

Mesmo assim, muitos data centers tradicionais ainda estão correndo atrás para provisionar seus ambientes online via ferramentas de nuvem privada. Um dos grandes obstáculos é o desempenho dessas máquinas e a medição do custo-benefício. De qualquer forma, rodar um piloto continua sendo a melhor maneira de obter um benchmark específico para o seu workload.