Escalando além dos limites: por que você precisa do Azure Compute Fleet para cargas de trabalho massivas

By Mirko Peters · 2026-08-13

Bem-vindo de volta à nossa exploração contínua de arquiteturas avançadas de nuvem. No nosso episódio mais recente do podcast, Azure Compute Fleet – Simply Explained, abordamos um m…

Automatically translated with AI from the original post. Read the English original

Bem-vindo de volta à nossa exploração contínua de arquiteturas avançadas de nuvem. No nosso episódio de podcast mais recente, Azure Compute Fleet – Simply Explained, abordamos um desafio enorme que as empresas modernas enfrentam ao lidar com a infraestrutura de nuvem. Se você já tentou provisionar centenas ou milhares de máquinas virtuais de uma só vez para um job de processamento em lote exigente, uma simulação de computação de alto desempenho ou um pipeline de processamento de dados em grande escala, já conhece a frustração de bater de repente em limites de capacidade. Neste post, vamos aprofundar esses conceitos, explicando por que os métodos tradicionais ficam aquém e como o Azure Compute Fleet muda fundamentalmente a forma como você adquire e gerencia recursos computacionais massivos na nuvem.

O que é o Azure Compute Fleet?

O Azure Compute Fleet é um serviço gerenciado especializado, projetado especificamente para resolver problemas de capacidade em grande escala. Quando você precisa escalar uma carga de trabalho de zero até milhares de workers instantaneamente, os métodos de implantação padrão podem facilmente virar gargalo. Criar uma única máquina virtual é simples, mas pedir a uma região que entregue mil máquinas virtuais idênticas de um SKU exato é um desafio completamente diferente. O Azure Compute Fleet muda a pergunta fundamental que você faz à nuvem. Em vez de perguntar "Como eu obtenho mil VMs idênticas deste tamanho exato?", você pergunta "Como eu obtenho a capacidade computacional de que minha carga de trabalho precisa usando uma variedade de opções aceitáveis?" Ao descrever seus requisitos gerais de capacidade, os tamanhos de VM aceitáveis, as preferências regionais e sua tolerância entre preço sob demanda e preço Spot, mais barato, o Azure pode pesquisar de forma inteligente em vários pools de disponibilidade para garantir os recursos que sua aplicação exige.

Por que a flexibilidade importa

Para entender por que o Compute Fleet é tão poderoso, precisamos observar de perto como a capacidade de nuvem funciona. Um SKU de máquina virtual representa uma combinação específica de CPU, memória, arquitetura de armazenamento e família de processadores. Se seus scripts de automação solicitarem apenas um SKU específico, o Azure só pode procurar essa correspondência exata. Se essa família específica estiver com alta demanda na sua região de destino, sua implantação vai ficar parada em fila ou falhar por completo. O Compute Fleet introduz flexibilidade ao permitir que você especifique uma ampla gama de tamanhos de VM aceitáveis. Desde que sua carga de trabalho esteja projetada para executar com sucesso nessas diferentes configurações de hardware, o Azure pode distribuir seus workers dinamicamente. Em escala massiva, essa flexibilidade aumenta exponencialmente a probabilidade de você obter exatamente a quantidade de poder computacional agregado de que precisa, exatamente quando precisa.

Até 10.000 VMs em um único fleet

Gerenciar manualmente uma infraestrutura de grande escala é receita para o esgotamento operacional. Escrever scripts de orquestração personalizados para lidar com novas tentativas de implantação, tamanhos de VM de fallback e monitoramento em dezenas de configurações diferentes rapidamente se torna um pesadelo impossível de manter. O Compute Fleet foi projetado para eliminar essa sobrecarga operacional, oferecendo suporte a até 10.000 máquinas virtuais em uma única solicitação de fleet. Você define os parâmetros do fleet uma vez, e o Azure avalia o inventário disponível em todas as opções permitidas, identificando automaticamente a combinação ideal de recursos e provisionando os grupos de máquinas virtuais subjacentes necessários. Essa capacidade nativa permite que as equipes de engenharia se concentrem nas suas cargas de trabalho reais, em vez de gastar incontáveis horas solucionando erros de alocação de infraestrutura.

O que o Compute Fleet não faz

Embora o Azure Compute Fleet seja uma grande mudança na forma de adquirir capacidade, é importante entender os seus limites. O Compute Fleet resolve o problema de capacidade; ele não define nem substitui toda a arquitetura da sua aplicação. Você continua totalmente responsável por fornecer as imagens de máquinas virtuais, as configurações de rede, os grupos de segurança e o software da aplicação de que cada worker precisa para executar. O Compute Fleet não sabe, por si só, se seus workers estão renderizando efeitos visuais cinematográficos, executando cálculos financeiros complexos, rodando testes de regressão automatizados ou analisando dados de telemetria científica brutos. Além disso, ele não substitui componentes centrais da arquitetura, como load balancers, filas de mensagens duráveis, a lógica da aplicação ou mecanismos de recuperação de desastres. Sua missão única e bem focada é adquirir e gerenciar grandes volumes de capacidade computacional quando existem várias configurações aceitáveis.

Escolhendo tamanhos de VM aceitáveis

Projetar uma implantação de fleet eficaz começa com uma decisão arquitetural crítica: determinar quais tamanhos de VM a sua aplicação realmente consegue usar. Em escala de fleet, sua principal preocupação não deve ser garantir um modelo específico de processador por preferência pessoal. Em vez disso, você precisa fazer uma auditoria completa dos requisitos do seu software. De quantos núcleos de CPU, quais limites de memória, quais métricas de desempenho de armazenamento local ou quais tipos de aceleradores a sua aplicação realmente depende? Se várias famílias de VM atendem a esses limites operacionais, permitir todas elas dá ao Azure um espaço de busca muito maior. No entanto, você deve validar com rigor cada tamanho que incluir. Nunca adicione uma família de VM à configuração do seu fleet apenas porque ela parece mais barata, se o seu software exigir conjuntos de instruções específicos, drivers especializados, configurações de armazenamento particulares ou recursos de hardware determinados.

Capacidade versus preço

Outra consideração importante de projeto é equilibrar a necessidade imediata de capacidade com a otimização de custos. Cargas de trabalho diferentes exigem estratégias de implantação completamente diferentes. Por exemplo, um cálculo noturno de risco financeiro pode ter uma janela de execução rígida e precisar terminar antes que os mercados globais abram na manhã seguinte. Nesse cenário específico, garantir capacidade imediatamente é muito mais crítico do que obter o menor preço possível por núcleo. Por outro lado, outras cargas de trabalho oferecem muita flexibilidade de agendamento. Testes em segundo plano, simulações de longo prazo, processamento de dados acumulados em backlog e ambientes temporários de desenvolvimento podem, muitas vezes, tolerar pequenos atrasos para obter a capacidade completa em troca de custos de infraestrutura bem menores. O Compute Fleet oferece às organizações a liberdade arquitetural de adaptar suas implantações a essas prioridades operacionais distintas.

Seleção de VM baseada em atributos

Para tornar a configuração ainda mais poderosa, o Azure oferece uma abordagem de seleção de VM baseada em atributos, que foi destacada em nossos materiais recentes do podcast como um recurso de prévia muito promissor. Em vez de obrigá-lo a listar manualmente dezenas de SKUs de VM exatas, esse recurso permite definir características gerais. Você pode especificar parâmetros como quantidade mínima e máxima de vCPUs, faixas de memória, requisitos de armazenamento NVMe local ou aceleradores de GPU especializados. Em seguida, o Azure identifica e utiliza dinamicamente os tamanhos de VM que correspondem exatamente a essas definições de atributos. Isso oferece uma preparação extraordinária para o futuro, à medida que a Microsoft lança gerações de VMs mais novas e eficientes na nuvem, embora suas aplicações ainda precisem passar por validação adequada em qualquer perfil de hardware recém-associado.

VMs sob demanda

Construir um fleet robusto significa entender os papéis distintos dos diferentes modelos de compra. As máquinas virtuais sob demanda formam a base estável e sólida do seu fleet. Ao solicitar uma VM sob demanda, você paga a tarifa padrão e previsível, e o Azure garante que não vai retomar esse recurso simplesmente porque a demanda de outro cliente aumentou. Isso torna a capacidade sob demanda ideal para o mínimo absoluto de computação de base que sua carga de trabalho precisa para continuar operando o tempo todo. Componentes críticos de infraestrutura, como coordenadores de jobs, listeners de filas de mensagens e workers primários de base, quase sempre devem usar capacidade sob demanda para garantir supervisão ininterrupta.

VMs Spot

No outro extremo do espectro de compra, encontramos as máquinas virtuais Spot. As VMs Spot permitem que você aproveite a capacidade de computação ociosa do Azure com descontos expressivos, muitas vezes economizando até noventa por cento em comparação com o preço padrão sob demanda. O preço que se paga por essas economias incríveis é o risco de interrupção. O Azure se reserva o direito de recuperar a capacidade Spot com pouco aviso sempre que a demanda regional exigir esses recursos físicos de volta. Isso torna as VMs Spot excepcionalmente atraentes para cargas de trabalho tolerantes a falhas, nas quais os workers podem desaparecer no meio de uma tarefa sem causar falhas catastróficas, desde que sua arquitetura seja construída para tentar novamente, com segurança, as operações interrompidas.

Combinando capacidade Spot e sob demanda

Você não precisa escolher entre uma estratégia puramente sob demanda e uma abordagem exclusivamente baseada em Spot. Na verdade, as arquiteturas mais resilientes combinam os dois modelos de compra em uma única frota coesa. Ao usar VMs sob demanda para o seu plano de controle persistente e para os workers fundamentais, você garante um throughput mínimo previsível. Ao mesmo tempo, você pode preencher a frota com VMs Spot para lidar com grandes escalas de computação por uma fração do custo habitual. Se o Azure recuperar parte dos seus workers Spot durante um momento de escassez de capacidade, os workers sob demanda continuam processando sem interrupção, alcançando um excelente equilíbrio econômico entre economia financeira e estabilidade operacional.

Projete para a interrupção

Embora o Azure Compute Fleet gerencie com elegância a alocação de capacidade subjacente e envie notificações antecipadas sobre interrupções de Spot, ele não consegue proteger, por mágica, os dados da aplicação armazenados exclusivamente na memória de um worker individual. Para aproveitar de verdade o poder de uma frota, sua carga de trabalho precisa ser projetada desde o início para lidar com o encerramento de workers. Por exemplo, considere um pipeline distribuído de renderização de vídeo. Se um projeto for dividido em tarefas individuais de renderização de quadros, e uma VM Spot for recuperada pelo Azure enquanto processa o quadro 412, essa tarefa específica deve voltar automaticamente para a sua fila de mensagens central, para que outro worker disponível possa pegá-la. Esse mesmo padrão arquitetural se aplica igualmente bem a simulações científicas, builds de software automatizados, testes de integração contínua e análises de dados em grande escala.

Mantenha o estado fora do worker

Para sobreviver em um ambiente de frota dinâmico, sua aplicação deve seguir uma regra de ouro: mantenha o estado totalmente fora do worker. Não dependa do armazenamento temporário em disco local para dados persistentes críticos. Em vez disso, use soluções de armazenamento durável, como o Azure Blob Storage, bancos de dados relacionais gerenciados ou armazenamentos NoSQL distribuídos, para manter a fonte da verdade. Use filas duráveis para distribuir tarefas pela frota e garanta que os workers gravem checkpoints regulares em operações de longa duração. Projete suas tarefas para serem idempotentes, o que significa que elas podem ser executadas várias vezes sem criar registros duplicados ou saídas corrompidas. Quando uma VM Spot desaparece inesperadamente, você deve perder apenas a pequena fração de trabalho que estava em andamento, em vez de horas de processamento irrecuperável.

Compute Fleet vs. Virtual Machine Scale Sets

Uma pergunta comum que engenheiros fazem ao explorar essa tecnologia é como o Compute Fleet se compara ao Azure Virtual Machine Scale Sets (VMSS). Os dois serviços gerenciam grupos de máquinas virtuais, mas foram criados para resolver problemas fundamentalmente diferentes. Os Virtual Machine Scale Sets normalmente começam com uma camada de aplicação específica. Você implanta um aplicativo web, uma API de microsserviços ou uma aplicação corporativa de linha de negócio atrás de um balanceador de carga, e o VMSS aumenta ou reduz o número de instâncias idênticas com base no tráfego de rede de entrada ou em limites de CPU. O Compute Fleet, por outro lado, parte de uma premissa completamente diferente: como posso adquirir rapidamente um grande pool de capacidade de computação flexível para processar uma montanha de trabalho distribuído?

Quando usar Virtual Machine Scale Sets

Os Virtual Machine Scale Sets continuam sendo o padrão-ouro para camadas de aplicação contínuas e de longa duração, em que as instâncias desempenham funções uniformes e precisam responder dinamicamente ao tráfego de usuários. Os casos de uso ideais incluem aplicações web voltadas ao cliente, APIs públicas, lojas virtuais de e-commerce e servidores de aplicação de back-end atrás de um Azure LoadBalancer ou Application Gateway. Nesses ambientes, os principais direcionadores de design são manter a integridade contínua da aplicação, rotear o tráfego ativo dos clientes sem interrupções e gerenciar atualizações graduais (rolling) do sistema operacional em instâncias idênticas.

Quando usar o Compute Fleet

Por outro lado, o Compute Fleet se destaca quando seu principal desafio é obter grandes volumes de poder computacional bruto para tarefas assíncronas, em lote ou independentes. Cenários típicos incluem clusters de computação de alto desempenho, processamento financeiro em lote, simulações de modelagem molecular, pipelines de ingestão de dados em grande escala, suítes de testes automatizados, fazendas de renderização de mídia e pools temporários de workers. Nessas arquiteturas, um worker pega uma unidade discreta de trabalho, processa, grava a saída final no armazenamento persistente e passa imediatamente para a próxima tarefa. Se um worker desaparecer, o sistema simplesmente atribui essa unidade de trabalho a outro nó disponível.

Você pode usar os dois

A melhor parte da arquitetura moderna em nuvem é que você não precisa escolher apenas uma ferramenta. O Azure Compute Fleet e os Virtual Machine Scale Sets não são mutuamente exclusivos; eles podem trabalhar em harmonia dentro do mesmo ecossistema corporativo. Por exemplo, uma aplicação corporativa sofisticada pode usar um Virtual Machine Scale Set para sustentar sua camada de front-end web e de API de alta disponibilidade, garantindo experiências de usuário impecáveis. Ao mesmo tempo, essa mesma aplicação pode iniciar um Azure Compute Fleet em segundo plano para lidar com cargas pesadas de data warehousing noturno, geração de relatórios em lote ou simulações complexas. Ao escolher a ferramenta certa para cada camada específica, você constrói uma arquitetura que é ao mesmo tempo muito responsiva para os usuários e econômica em escala.

Para se aprofundar ainda mais nessas arquiteturas e ouvir dicas práticas de implementação, não deixe de ouvir o episódio completo do nosso podcast complementar: Azure Compute Fleet – Simply Explained. Não se esqueça de apoiar nosso programa e fique atento a mais análises aprofundadas sobre engenharia de nuvem!

Torne-se um apoiador deste podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.