A Uber introduziu uma abordagem inovadora para resolver o problema de heterogeneidade em sua infraestrutura de computação. A solução, chamada Normalized Compute Units (NCUs), padroniza a alocação de CPU em frotas de servidores com características diferentes, implementada na plataforma Odin de orquestração de workloads stateful.
A plataforma Odin gerencia aproximadamente 5 milhões de núcleos de CPU distribuídos entre data centers on-premises e nuvem pública, incluindo múltiplas gerações de processadores x86 e arquitetura ARM. O desafio fundamental identificado pela Uber é que a performance de single-threaded varia por um fator próximo a 2x entre os cores mais rápidos e mais lentos, significando que a mesma carga de trabalho requer diferentes quantidades de núcleos físicos dependendo do servidor onde executa.
Este cenário cria dilemas operacionais críticos. Alocar recursos conforme o hardware mais lento desperdiça capacidade em máquinas mais rápidas. Por outro lado, alocar baseado em uso médio deixa workloads sub-provisionados quando migram para servidores mais lentos. Para workloads stateful, onde mover tráfego para outra máquina frequentemente não é possível, a subprovisionamento torna-se um problema de confiabilidade. Requisições precisam alcançar servidores específicos contendo dados ou shards particulares, impossibilitando o uso de load balancing simples como em sistemas stateless.
A solução separa a quantidade de performance computacional requerida de um workload dos núcleos físicos utilizados para fornecê-la. Odin atribui a cada tipo de servidor um fator de performance, usando uma geração antiga como baseline de 100. Servidores mais novos alcançam fatores próximos a 190. Estes fatores são inicialmente determinados durante qualificação de hardware e refinados posteriormente usando dados de workloads em produção.
O uso de CPU é convertido em unidades normalizadas usando estes fatores. Odin então determina quanto de capacidade computacional um workload requer e traduz essa necessidade em diferentes quantidades de núcleos físicos dependendo do servidor hospedador. Um workload em hardware mais rápido pode receber menos cores, enquanto o mesmo workload em hardware mais lento recebe mais cores, mantendo capacidade computacional comparável.
A Uber descobriu que fatores de performance diferem entre tecnologias. Medições para Kafka mostraram performance substancialmente diferente entre ARM, hardware on-premises antigo e sistemas x86 novos. A empresa atualiza fatores usando medições em produção em vez de confiar exclusivamente em benchmarks sintéticos.
Em topologias distribuídas, líderes consomem mais de 10x a CPU dos followers. Quando um líder migra de um servidor rápido para um mais lento, seu consumo de CPU aumenta substancialmente, potencialmente causando pressão de recursos mesmo que a carga de trabalho em si não tenha mudado.
A Uber implementou a abordagem em aproximadamente 1,4 milhões de núcleos de CPU em workloads Odin com auto-scaling. Para Kafka, a utilização de CPU inicialmente variava por cerca de oito pontos percentuais entre tipos de servidores, com hardware mais quente rodando a aproximadamente 50% maior utilização que hardware mais frio. Após introduzir alocação performance-aware, a diferença caiu para cerca de três pontos percentuais, com hardware mais quente apenas 10% acima do mais lento. A Uber também reduziu alocação total de CPU para Kafka em aproximadamente 8%, com grande parte da redução ocorrendo em hardware mais rápido onde as economias são potencialmente mais valiosas.
O modelo NCU difere da abstração de CPU usada por Kubernetes, onde requests de CPU são expressas como cores ou millicores. Kubernetes deliberadamente trata uma unidade de CPU como quantidade absoluta de tempo de CPU independente do tamanho da máquina subjacente. Esta abstração funciona bem para definições de workloads portáveis, mas não expressa inerentemente performance relativa de diferentes gerações de processadores. A abordagem da Uber aborda um problema diferente: tornar o recurso em si performance-aware, perguntando quanto de capacidade computacional uma alocação de CPU realmente representa.
