TL;DR: O Azure Container Registry (ACR) mantém desempenho previsível em multi-tenancy não por sorte, mas por uma prática ativa: stamps são rebalanceados proativamente quando um deles fica sobrecarregado, movendo registries entre eles de forma transparente. Para workloads excepcionais, oferece isolamento adicional. Tudo isso é operado manualmente hoje, mas a equipe está automatizando. A métrica chave é hot-node P95 CPU, que capta o nó mais quente sem ruído de picos isolados.
Introdução
Duas das perguntas mais frequentes que recebemos de times rodando cargas de trabalho com containers em escala no Azure Container Registry (ACR) são:
- “Como o ACR mantém a performance do meu registry previsível quando estou compartilhando infraestrutura com milhares de outros tenants?” – Serviços cloud são inerentemente multi-tenant. O que o ACR realmente faz para evitar que minha workload dispute recursos com os vizinhos?
- “O que acontece quando a carga de um tenant cresce o suficiente para afetar a infraestrutura compartilhada?” – Existe uma intervenção ativa, ou o sistema simplesmente absorve o impacto?
Neste artigo, esclarecemos como o ACR opera sua frota multi-tenant: a arquitetura de stamps que sustenta a infraestrutura do ACR em cada região do Azure, a prática de rebalancear proativamente registries entre stamps quando um stamp fica quente, e as opções adicionais de isolamento de stamp disponíveis para cargas excepcionais. Rodar multi-tenancy bem em escala não é passivo – é uma prática operacional ativa, e os clientes se beneficiam dela todos os dias sem nunca perceber.
Principais Conclusões
- Um registry do ACR pode ser geo-replicado: um registry pode ter geo-replicas (leitura e escrita) em várias regiões do Azure. Cada geo-replica é servida por um ACR stamp – unidades de deployment independentes que formam a infraestrutura regional, compostas por pools de computação baseadas em VMSS e uma pool de contas de storage. Stamps são simultaneamente um pool de capacidade, um fault domain e um update domain.
- Quando um stamp fica quente, o ACR rebalanceia proativamente movendo registries para outro stamp menos utilizado na mesma região. O endpoint do registry não muda; a migração é transparente para o cliente.
- Para cargas excepcionais onde o rebalanceamento sozinho apenas transferiria o problema, o ACR pode oferecer isolamento adicional de stamp – colocando registries em stamps com menos co-tenants, proporcionando melhor isolamento de tráfego, separação de fault domain e independência de update domain. Isso também melhora estruturalmente os stamps que o tenant costumava compartilhar com todos.
- A engenharia do ACR usa uma combinação de sinais reativos (outages, erros sustentados, throttling, baixo throughput) e sinais proativos (telemetria operacional) para decidir quando rebalancear stamps. O Hot-node P95 CPU, discutido neste artigo, é um dos sinais proativos – para cada bin de 1 minuto, pega-se o CPU médio do nó mais quente e depois o percentil ao longo dos bins. A média da pool esconde hotspots; o máximo de uma amostra é muito ruidoso.
- Tudo isso é atualmente manual. As decisões de rebalanceamento, migrações e provisionamento de isolamento são conduzidas por operadores. Estamos investindo ativamente em padronizar e automatizar a prática – rebalanceamento automático de stamps e gerenciamento de ciclo de vida estão no roadmap.
Background
O que é um stamp?
Um stamp é a unidade de deployment do ACR dentro de uma região. Em alto nível, o ACR possui os seguintes componentes em uma região para servir operações do plano de dados:
- Pools de computação baseadas em VMSS. Virtual Machine Scale Sets são o primitivo do Azure para rodar um grupo gerenciado de VMs idênticas que escalam juntas. Cada stamp tem uma pool de VMs que cuidam de autenticação, operações de manifesto, resolução de tags e metadados do registry – a camada de coordenação de um pull de container – mais uma pool separada de VMs rodando o componente dataproxy, que fica entre clientes e storage. Em pulls via private endpoint, quando um cliente puxa uma layer, o dataproxy busca do storage (ou de seu cache local) e faz streaming dos bytes de volta; é efetivamente um private endpoint e um cache de streaming combinados.
- Uma pool de contas de storage. Cada região do ACR tem seu próprio conjunto de contas de Azure Storage que armazenam os dados reais de blob (layers) e conteúdo de manifesto para as geo-replicas. As contas de storage são multi-tenant dentro de um stamp e região – blobs de múltiplos registries podem cair no mesmo grupo de contas, com controles rigorosos de isolamento e autorização.
Cada região do ACR normalmente contém múltiplos stamps servindo registries de vários tenants. Para registries geo-replicados, uma geo-replica em uma região está vinculada a exatamente um stamp subjacente. O endpoint global do registry geo-replicado (<registry>.azurecr.io), endpoints regionais das geo-replicas e endpoints dedicados de dados são resolvidos via DNS – apoiados pelo próprio perfil do Traffic Manager do ACR – para um stamp específico que atende aquela geo-replica.
O ponto conceitual chave: um stamp é simultaneamente um pool de capacidade (autoscale opera sobre ele), um fault domain (incidentes no stamp afetam todos os seus tenants) e um update domain (rollouts progridem através dos update domains dentro do stamp). Quando movemos um registry entre stamps na mesma região, estamos movendo-o entre todos esses três ao mesmo tempo – e as URLs de endpoint do cliente não mudam. Da perspectiva do cliente, a migração é totalmente transparente: não há mudanças de endpoint, nem atualizações de DNS a fazer, nenhuma ação necessária. O registry continua funcionando exatamente como antes, e o cliente não precisa saber ou se importar que o stamp mudou.
Por que multi-tenancy em escala é uma prática ativa
A visão ingênua é: provisione capacidade suficiente, autoscale resolve o resto. Isso funciona em estado estável. Não funciona quando a carga de um tenant cresce o suficiente para influenciar sistematicamente o comportamento de um stamp, quando o formato do tráfego é tão bursty que as médias subestimam os picos, ou quando o raio de explosão de um único grande tenant fica desconfortavelmente concentrado em um stamp compartilhado.
Nenhum desses problemas é resolvido por um autoscaler passivo. Eles exigem uma decisão operacional: este registry seria melhor servido naquele stamp. A engenharia do ACR faz isso continuamente – desde o rebalanceamento de rotina até o fornecimento de isolamento adicional para cargas excepcionais.
Como Fazemos: Rebalanceamento de Stamps
Rebalanceamento de stamps – uma prática recorrente
Vários sinais podem disparar uma decisão de rebalanceamento de stamp – sinais reativos como erros sustentados, outages, throttling que os clientes observam ou que observamos em nossa própria telemetria, baixo throughput em um stamp, ou sinais proativos como o hot-node P95 CPU (descrito abaixo) ultrapassando um limiar. O trabalho de rebalanceamento mais recente usou hot-node P95 como gatilho proativo; outras decisões foram orientadas pelos sinais reativos listados. Quando qualquer um desses dispara, a engenharia do ACR identifica os registries que mais contribuem para o problema e escolhe um ou mais para mover para um stamp menos utilizado na mesma região.
O mecanismo é direto: iniciamos ações operacionais elevadas, o control plane re-liga o campo home_stamp do registry, o roteamento DNS segue, as requisições em andamento no stamp de origem drenam em 30–60 segundos, e o novo tráfego chega ao stamp de destino. O cutover leva minutos. O endpoint do registry não muda. A maioria dos clientes nunca sabe que aconteceu; os que tiveram seu registry movido geralmente veem latência melhor depois.
Rebalancear para um stamp existente mais frio é uma prática recorrente que resolve a maioria das pressões multi-tenant. Para cargas excepcionais onde rebalancear para outro stamp compartilhado apenas transferiria o problema, o ACR pode fornecer isolamento adicional de stamp – colocando registries em stamps com menos co-tenants, dando ao tenant melhor isolamento de tráfego, separação de fault domain e independência de update domain, enquanto também melhora estruturalmente os stamps que aquele tenant costumava compartilhar.
Rebalanceamento em diferentes escalas
O ACR aplica rebalanceamento em um espectro de cenários, desde mover um punhado de registries para um stamp mais frio até fornecer isolamento adicional de stamp para cargas excepcionais. O critério de decisão é o tamanho da carga em relação à frota compartilhada – se mover um tenant para outro stamp compartilhado apenas transferiria o problema de stamp quente para o destino, o isolamento adicional é a resposta correta. Para todos os outros, rebalancear para um stamp existente é suficiente. Ambos são manuais hoje; tanto o provisionamento de stamps quanto os mecanismos de rebalanceamento descritos estão no roadmap do ACR para serem automatizados com menos envolvimento de operadores.
Hot-node P95: um dos sinais que usamos proativamente
As decisões de rebalanceamento são guiadas por uma combinação de sinais reativos e proativos. Sinais reativos – outages, taxas de erro sustentadas, throttling frequente, baixo throughput relatado por clientes ou observado em nossa telemetria – são os gatilhos óbvios. Mas esperar por eles significa esperar por um problema visível ao cliente. Sinais proativos nos permitem intervir antes que isso aconteça.
Hot-node P95 CPU, destacado neste artigo, é um dos sinais proativos que usamos, e foi o sinal primário para o trabalho de rebalanceamento mais recente descrito no exemplo abaixo. A escolha da métrica de CPU importa. Três candidatos:
- Pool-average CPU. Média de todos os nós na pool. Esconde hotspots por nó – uma pool com 6% de CPU média ainda pode ter um nó a 99%.
- Single-sample Max CPU. A amostra de 1 minuto mais alta. Capta picos, mas é dominada por ruído de bins únicos que não representam carga sustentada.
- Hot-node P95 CPU. Para cada bin de 1 minuto, pegue o CPU médio do nó mais quente. Depois, tire o percentil ao longo dos bins em uma janela de pico de 12 horas. Isso é “quão quente está o pior nó, na maior parte do tempo”.
O Hot-node P95 capta carga sustentada por nó sem ser ruidoso, e rastreia o comportamento visível ao cliente mais de perto do que qualquer alternativa.
Um exemplo concreto de um redimensionamento regional recente: em um pool dataproxy de um stamp compartilhado, o Max CPU chegou a 96% – alarmante se lido isoladamente. Mas o hot-node P95 era de 43%, significando que na maior parte do tempo até o nó mais quente estava confortavelmente carregado; os 96% foram um pico único de 1 minuto. Usar Max como sinal operacional teria disparado uma intervenção desnecessária. Usar pool-average teria perdido hotspots reais em outros lugares. O hot-node P95 é o ponto operacional correto para este sinal específico – e é uma entrada entre várias que alimentam a decisão mais ampla de rebalanceamento.
Um Exemplo Recente: Rebalanceamento de Grandes Cargas de IA para Isolamento Adicional
Recentemente concluímos o rebalanceamento de registries pertencentes a uma das maiores cargas de IA da região, fornecendo isolamento adicional para lidar com a escala de seu tráfego. A carga do cliente havia crescido a ponto de sua presença nos stamps compartilhados estar influenciando sistematicamente o comportamento dos stamps – variabilidade que afetava a latência de pull do próprio cliente e a variabilidade que afetava todos os outros tenants nos mesmos stamps.
O cliente tinha 40 registries alocados em dois stamps compartilhados na região, com uma distribuição de tráfego severamente long-tailed: os quatro principais registries carregavam 96,7% do tráfego do cliente. Quando tanta carga está concentrada em quatro registries, a migração não pode prosseguir como um único lote. Movemos em fases, do menor para o maior, com janelas de observação entre as fases:
- Primeiro os registries ociosos e de pouco tráfego – cerca de trinta registries de baixo tráfego, usados para validar as ferramentas de cutover contra o stamp de destino.
- Depois os registries de tráfego médio – em sub-lotes com 24 horas de observação entre eles.
- Os quatro principais, um de cada vez – cada um individualmente com 48 horas de observação entre os cutovers. Ordem: do menor para o maior, para que cada cutover fosse uma verificação de sanidade com carga crescente.
O efeito cumulativo nos stamps compartilhados que o cliente ocupava anteriormente:
| Stamp + pool | Mudança no Hot-Node P95 CPU | Mudança no Max CPU |
|---|---|---|
| Stamp A – pool registry | -7% | flat |
| Stamp A – pool dataproxy | -34% | 96% → 64% |
| Stamp B – pool registry | -33% | -3 pontos percentuais |
| Stamp B – pool dataproxy | -44% | -5 pontos percentuais |
O dataproxy do Stamp A é o destaque. O nó mais quente passou de 96% (pico breve) para 64% (máximo), com o hot-node P95 sustentado caindo de 43% para 28,5%. Todos os outros tenants alocados no Stamp A – a maioria sem saber que esse rebalanceamento aconteceu – agora rodam em uma pool estruturalmente mais saudável, com mais headroom, menor latência de cauda sob carga e menor risco de incidentes de CPU durante picos de tráfego. O Stamp B viu alívio semelhante.
Após o rebalanceamento, redimensionamos os stamps compartilhados para baixo – reduzindo o número mínimo de instâncias VMSS em cada um para corresponder ao novo nível de tráfego. O hot-node P95 foi o sinal primário que orientou esse trabalho de redimensionamento, o mesmo sinal proativo que motivou o rebalanceamento inicial: quando o tráfego quente sai de um stamp compartilhado, o redimensionamento de capacidade segue.
Conclusões
O ACR executa essa prática recorrente de rebalanceamento de stamps por um motivo: oferecer aos clientes mais performance garantida – throughput de pull mais alto e previsível, latência de cauda mais baixa, melhor isolamento de falhas e atualizações – seja por meio de rebalanceamento de rotina ou isolamento adicional para cargas excepcionais. Cada tenant nos stamps rebalanceados ganha mais headroom, comportamento mais previsível sob carga e um raio de explosão menor para qualquer incidente ou rollout.
Três coisas acontecem continuamente em qualquer região do ACR para tornar isso real: registries são rebalanceados entre stamps à medida que os padrões de carga mudam, cargas excepcionais recebem isolamento adicional de stamp quando nenhum stamp compartilhado pode absorvê-las de forma sustentável, e stamps são continuamente redimensionados quando a carga entra ou sai.
Todos os três são operados manualmente hoje, todos os três estão sendo investidos para automação, e todos os três são guiados por uma combinação de sinais reativos (outages, erros, throttling) e sinais proativos (hot-node P95 CPU é um deles).
A tese é direta: multi-tenancy em escala na nuvem não é uma propriedade passiva da arquitetura. É uma prática operacional ativa que existe para oferecer aos clientes performance garantida e comportamento previsível. Os clientes que mais se beneficiam dela são geralmente aqueles que nunca percebem que ela está acontecendo.
Perguntas Frequentes
-
O que é um stamp no ACR?
É a unidade de deployment do ACR dentro de uma região: um conjunto de VMs (com autoscaling via VMSS) e uma pool de contas de storage. Cada stamp serve múltiplos registries de vários tenants. Ele funciona simultaneamente como pool de capacidade, fault domain e update domain. -
Como o rebalanceamento de stamps afeta a latência das minhas pulls?
Quando um stamp fica sobrecarregado, o ACR move seu registry para outro stamp na mesma região. A migração é transparente – o endpoint não muda, e o cutover leva minutos. Após a migração, a latência tende a melhorar, pois o novo stamp tem mais headroom. -
O que é hot-node P95 e por que é usado?
É a métrica que capta, a cada minuto, o CPU médio do nó mais quente da pool e depois tira o percentil 95 ao longo de uma janela de 12 horas. Ela equilibra sensibilidade e ruído: ao contrário da média da pool (que esconde hotspots) ou do pico máximo (muito ruidoso), o hot-node P95 mostra a carga sustentada do pior nó. -
O rebalanceamento ajuda apenas o tenant que foi movido?
Não. Quando um workload grande é removido de um stamp compartilhado, todos os outros tenants que continuam naquele stamp se beneficiam – o pool fica mais saudável, com mais headroom, menor latência de cauda e menor risco de incidentes de CPU. -
Esse processo de rebalanceamento é automático hoje?
Não. Atualmente, as decisões de rebalanceamento, migrações e provisionamento de isolamento são feitas manualmente por operadores. A equipe do ACR está investindo em automatizar essas práticas, e o rebalanceamento automático de stamps está no roadmap.
Artigo originalmente publicado por (autor não identificado) em Azure Updates - Latest from Azure Charts.
