Netflix adiciona isolamento de desempenho por tarefa ao Titus em instâncias EC2 dedicadas

A Netflix adicionou ao Titus um modo que executa cada tarefa em uma instância EC2 dedicada, dimensionada conforme seus requisitos. A mudança busca reduzir interferências entre cargas de trabalho confiáveis que compartilham recursos físicos. A equipe Compute/Platform continua responsável pelos hosts e por suas atualizações; para as equipes de aplicação, permanecem iguais a API e o fluxo de implantação.

Os primeiros usos incluem cargas stateful de streaming com alto throughput. Nesses casos, a interferência de uma tarefa vizinha pode levar a minutos de recuperação de checkpoints. Também estão entre os usuários iniciais Apache Flink gerenciado, conectores de dados de streaming, pipelines de telemetria e registro, além de alguns serviços GraphQL e de edge sensíveis à latência. A implantação ainda está em andamento.

O Titus lança milhões de containers por semana em dezenas de milhares de instâncias EC2 e, por padrão, funciona em um modelo multi-tenant. Segundo a Netflix, mecanismos como cgroups, seccomp, o controlador iocost e o traffic shaping não isolam por completo recursos de hardware compartilhados, entre eles o cache de último nível e a largura de banda de memória. O traffic shaper HTB também usa um lock global: um container que envia muitos pacotes pequenos pode consumir CPU do kernel e prejudicar os vizinhos.

A empresa relata que a pinagem preditiva de CPU e a detecção baseada em eBPF ajudaram a reduzir problemas, mas não eliminaram a diferença de desempenho. A conclusão foi que ajustes no kernel compartilhado estreitam essa diferença, sem fechá-la. O modo single-tenant foi concebido para isolamento de desempenho entre equipes internas confiáveis, não como defesa contra tenants hostis.

Imagem: InfoQ. A Netflix adicionou ao Titus um modo de execução em que cada tarefa ocupa sozinha uma instância EC2 dimensionada para ela.

A Netflix avaliou outras opções e aponta limitações específicas. Firecracker e Kata exigem bare metal ou virtualização aninhada; esta última não estava pronta nos tipos de instância usados pela empresa. Essas alternativas também implicariam uma camada de hypervisor e overhead de virtualização, além de não oferecerem suporte a GPU. Na avaliação da Netflix, gVisor acrescenta overhead em caminhos intensivos em I/O e tem sua manutenção conduzida principalmente por um único fornecedor. Já executar containers diretamente em EC2 transferiria para as equipes de aplicação a responsabilidade por atualizar os hosts e dimensionar a frota.

No Titus, a camada de federação coordena a alocação. Uma lista de permissões mantida pela equipe Compute/Platform determina quais tarefas podem usar o modo e quais famílias de instância estão disponíveis. O autoscaler lança a menor instância que atende às solicitações de CPU, memória e GPU. Afinidade negativa entre pods, uma classe de prioridade não preemptível e uma taint no nó impõem uma tarefa por nó. A Netflix desativa a desfragmentação para que a tarefa não seja realocada.

Para avaliar o isolamento, a empresa executa uma aplicação de referência sozinha e, depois, ao lado de um container de teste chamado “havoc”. A comparação considera o throughput mantido e a latência P99. A publicação não apresenta pontuações para esses testes.

O custo operacional mais evidente é o tempo de inicialização. Uma instância nova leva dezenas de segundos para iniciar, antes mesmo de começar o download da imagem do container. Pools aquecidos ajudam menos do que na frota compartilhada porque o dimensionamento ajustado produz muitos formatos de instância. Por isso, a Netflix mantém um pool pequeno para as inicializações mais sensíveis à latência e limita os tamanhos disponíveis. A empresa retirou instâncias metal desses pools. Também desativou a preempção do Kubernetes, removendo um gargalo que deixava nós recém-criados ociosos.

Como possíveis melhorias de longo prazo, a Netflix cita o download preguiçoso de imagens com stargz e SOCI e a restauração de checkpoints com CRIU. A eficiência também pode melhorar quando cargas sensíveis deixam os hosts compartilhados: isso remove regras de afinidade negativa e orçamentos de interrupção que mantinham esses hosts parcialmente vazios. Em sentido contrário, sidecars e serviços do sistema têm custos fixos. Segundo a empresa, eles podem consumir dezenas de por cento dos recursos de uma instância pequena, mas apenas alguns por cento das instâncias maiores. Além disso, os tamanhos discretos das instâncias EC2 deixam lacunas no encaixe de cargas em grandes hosts compartilhados; na experiência da Netflix, esse fator favoreceu o dimensionamento ajustado.

Enquanto avança com o modo dedicado, a Netflix trabalha em melhorias para a frota compartilhada: um mecanismo Expected Departure Time baseado em eBPF para substituir o HTB; particionamento de cache e largura de banda de memória com Intel RDT e AMD PQoS; NVIDIA MIG; e o controlador de I/O do cgroup v2. A meta de longo prazo é oferecer uma única Compute API que escolha entre posicionamento em EC2 ou Titus com base na intenção declarada.

A publicação compara a abordagem com outras opções de infraestrutura. O projeto de código aberto Instance-per-Pod Webhook, de Akihiro Suda, da NTT, usa um webhook de admissão do Kubernetes e o Cluster Autoscaler para criar uma instância dedicada, com taint, para cada pod. O AWS Fargate toma o pod como unidade de infraestrutura e dispensa os clientes de criar, corrigir ou escalar nós de trabalho. No GKE, os sole-tenant nodes são servidores físicos dedicados às VMs de um único projeto, enquanto o GKE Sandbox executa cada pod em uma microVM Kata. O Pod Sandboxing do Azure também usa Kata para fornecer a cada pod uma VM leve.

A distinção destacada pela Netflix é o objetivo: enquanto a maior parte das alternativas citadas se concentra em isolamento de segurança contra código não confiável, o Titus single-tenant procura limitar interferências de desempenho entre equipes internas. Para plataformas Kubernetes compartilhadas, a empresa recomenda o padrão de pools de nós dedicados com taints, afinidade negativa e repacking desativado. A recomendação é voltada a cargas grandes, duradouras, sensíveis a interrupções e dimensionadas perto do formato de um nó — não a serviços pequenos ou de tráfego variável. A lista de permissões, por sua vez, limita a adoção para evitar que o modo reduza a densidade multi-tenant.