Visão geral e insights sobre a infraestrutura em hiperescala da Meta

• A cultura de engenharia da Meta enfatiza execução rápida, abertura tecnológica, pesquisa em ambiente de produção e infraestrutura compartilhada
• Para aumentar a produtividade dos desenvolvedores, adota implantação contínua e permite que mais desenvolvedores escrevam funções serverless em vez de código tradicional de serviços
• Para reduzir custos de hardware, usa co-design de hardware e software na escala de datacenter e otimiza automaticamente a alocação de recursos entre datacenters no mundo todo, sem limitar isso a clusters individuais
• A estratégia de IA da Meta faz co-design de toda a stack, do PyTorch a aceleradores de IA, redes e modelos de ML como o Llama

# [Cultura de engenharia]

Execução rápida (Move Fast)

• A Meta mantém uma cultura de agilidade e iteração rápida, enfatizando o "Move Fast"
• Dá forte apoio à implantação contínua (Continuous Deployment), colocando o código mais recente em produção o mais rápido possível
• Engenheiros de produto escrevem funções serverless stateless usando linguagens como PHP, Python e Erlang
• É possível mudar prioridades sem longos processos de planejamento, resolvendo problemas incertos por meio de execução iterativa
• Essa abordagem permite resposta rápida ao mercado e lançamentos ágeis de produtos

Abertura tecnológica (Technology Openness)

• Abertura interna: usa a abordagem de monorepo para armazenar o código de todos os projetos em um único repositório
  • Facilita busca de código, reutilização e colaboração entre equipes
  • Na maioria dos projetos, não há restrições rígidas de propriedade de código, permitindo que desenvolvedores contribuam livremente
• Abertura externa: compartilha ativamente projetos de hardware e software open source
  • Publica designs de hardware por meio do Open Compute Project
  • Mantém vários projetos de software open source, como PyTorch, Llama, Presto, RocksDB e Cassandra
  • Compartilha tecnologias de infraestrutura por meio de artigos de pesquisa

Pesquisa em produção (Research in Production)

• A Meta realiza pesquisa em ambiente operacional real sem um laboratório de sistemas dedicado
• As equipes que desenvolvem sistemas de produção escrevem diretamente artigos de pesquisa para resolver problemas reais e oferecer soluções validadas em ambientes operacionais de grande escala
• Essa abordagem é prática e atende aos critérios centrais de uma pesquisa de sistemas bem-sucedida

Infraestrutura comum (Common Infrastructure)

• Em vez de cada equipe escolher livremente sua stack tecnológica, a Meta prioriza padronização e otimização global
• Hardware:
  • Todos os servidores são alocados a partir de um pool compartilhado de servidores
  • Para workloads de computação não relacionados a IA, fornece um único tipo de servidor (basicamente 1 CPU e 256 GB de DRAM), reduzindo a complexidade dos tipos de servidor
• Software:
  • Antes usava diversos armazenamentos chave-valor, como Cassandra, HBase e ZippyDB, mas hoje foi consolidado em ZippyDB
  • Implantação de software, gerenciamento de configuração, service mesh e testes de desempenho são unificados em ferramentas comuns
• Preferência por componentes reutilizáveis:
  • Construiu uma cadeia de reutilização de componentes composta por Tectonic sistema de arquivos → ZippyDB (armazenamento de metadados) → Shard Manager (gerenciamento de sharding de dados) → ServiceRouter (descoberta de shards e roteamento de requisições) → Delos (armazenamento de dados de alta confiabilidade)
  • Em vez de sistemas monolíticos como o HDFS, usa componentes modulares e reutilizáveis para maximizar a escalabilidade

Estudo de caso cultural: desenvolvimento do app Threads (Culture Case Study: The Threads App)

• O caso de desenvolvimento do app Threads mostra bem a cultura de engenharia da Meta
• O trabalho técnico foi concluído em apenas 5 meses e, após um aviso prévio de 2 dias, a equipe de infraestrutura concluiu a preparação para a implantação em produção
• Na maioria das grandes empresas, é difícil até escrever um plano de projeto em dois dias. Já a Meta montou uma war room para resolver problemas em tempo real e respondeu rapidamente
• Como resultado, ultrapassou 100 milhões de usuários em 5 dias após o lançamento, tornando-se o app com crescimento mais rápido da história
• O Threads conseguiu escalar rapidamente reutilizando a infraestrutura existente:
  • Backend em Python do Instagram
  • Infraestrutura compartilhada da Meta (banco de dados de grafo social, armazenamento chave-valor, plataforma serverless, plataforma de ML, gerenciamento de configuração de apps móveis etc.)
• Abertura interna: usou o monorepo para reutilizar parte do código do Instagram e acelerar o desenvolvimento
• Abertura externa: usa o ActivityPub com o objetivo de interoperar com outros apps
• Compartilhamento da experiência de desenvolvimento: divulgou publicamente a experiência de desenvolvimento e implantação rápida

# [Fluxo de requisição de usuário de ponta a ponta (End-to-End User Request Flow)]

• Para examinar em profundidade as tecnologias de infraestrutura da Meta, o texto descreve todo o processo de tratamento de uma requisição de usuário
• Os produtos da Meta são sustentados por uma infraestrutura de serviços compartilhados, que inclui vários componentes centrais

Roteamento de requisições (Request Routing)

• Mapeamento dinâmico de DNS (Dynamic DNS Mapping)
  • Quando um usuário acessa facebook.com, o servidor DNS da Meta retorna dinamicamente o endereço IP do PoP (Point of Presence) mais próximo
  • O PoP é um pequeno datacenter de edge, que distribui a carga de rede em uma localização próxima ao usuário
  • O PoP mantém conexões TCP de longa duração com os datacenters da Meta, reduzindo o tempo de estabelecimento da conexão TCP e melhorando o desempenho da rede
  • Há centenas de PoPs distribuídos pelo mundo, oferecendo baixa latência de rede para a maioria dos usuários
• Cache de conteúdo estático (Static-Content Caching)
  • Conteúdos estáticos, como imagens e vídeos, podem ser armazenados em cache no PoP e servidos diretamente
  • Além disso, a Meta opera uma CDN (rede de entrega de conteúdo) e constrói sites de CDN em parceria com ISPs (provedores de internet)
  • Se a requisição do usuário for facebook.com/image.jpg, a Meta a reescreve como CDN109.meta.com/image.jpg para entregar o conteúdo a partir do site de CDN mais próximo
  • Se o conteúdo não estiver na CDN, a requisição é encaminhada por PoP → balanceador de carga do datacenter → sistema de armazenamento
• Roteamento de requisições de conteúdo dinâmico (Dynamic-Content Request Routing)
  • Requisições de conteúdo dinâmico, como o Feed de Notícias, são encaminhadas do PoP para um datacenter
  • Uma ferramenta de engenharia de tráfego escolhe o datacenter ideal considerando a capacidade do datacenter e a latência de rede
  • O tráfego do PoP até o datacenter é transmitido pela WAN privada (rede de longa distância) da Meta
  • O tráfego entre datacenters é muito maior do que o tráfego entre usuário e PoP, por causa da replicação de dados e das interações entre microsserviços

Topologia da infraestrutura (Infrastructure Topology)

• A infraestrutura global da Meta é composta por componentes de infraestrutura em várias camadas
• Cada componente desempenha um papel específico e opera na seguinte escala:
  • Região de datacenter (Region): há cerca de 10 regiões de datacenter no mundo, e cada região pode operar até 1 milhão de servidores
  • PoP (Point of Presence, datacenter de borda): há mais de 100 PoPs, e cada PoP normalmente inclui de 100 a 1.000 servidores. Eles processam o tráfego em locais próximos aos usuários para reduzir a latência
  • Site de CDN: há mais de 1.000 sites de CDN, que normalmente incluem mais de 10 servidores, e alguns sites maiores operam mais de 100 servidores. Eles armazenam em cache conteúdo estático (imagens, vídeos etc.) para entregá-lo rapidamente
  • Datacenter (Datacenter): em cada região de datacenter existem vários datacenters, e cada datacenter pode operar cerca de mais de 100 mil servidores
  • MSB (painel principal de distribuição, Main Switchboard): existem até 12 MSBs dentro de um datacenter, e cada MSB é responsável por 10 mil a 20 mil servidores. Ele cumpre a função de distribuição de energia e atua como um importante domínio de falha dentro do datacenter. Se um MSB falhar, até 20 mil servidores podem ficar fora do ar
• Rede de borda:
  • Os PoPs se conectam a vários sistemas autônomos (AS) da internet e usam BGP (Border Gateway Protocol) para selecionar a melhor rota
• Rede de datacenter:
  • Os servidores são conectados usando uma topologia Clos de 3 estágios
  • Ela é projetada para evitar congestionamento de rede e fornecer largura de banda máxima entre servidores
• Rede regional:
  • Os datacenters são conectados por fabric aggregators, permitindo a comunicação com a WAN
  • Usa uma topologia Fat-Tree para possibilitar expansão gradual

Processamento de requisições (Request Processing)

• Processamento online (Online Processing)
  • As requisições dos usuários são distribuídas por load balancers para dezenas de milhares de funções serverless de frontend (FrontFaaS)
  • As funções de frontend podem chamar vários serviços de backend e também podem chamar serviços de inferência de ML (por exemplo, recomendação de anúncios, recomendação de conteúdo do feed de notícias)
  • Durante a execução, as funções de frontend adicionam eventos a uma fila de eventos, permitindo que funções serverless orientadas a eventos (XFaaS) sejam executadas de forma assíncrona
  • A proporção de servidores entre funções de frontend e funções orientadas a eventos é de cerca de 5:1
• Processamento offline (Offline Processing)
  • O sistema de processamento offline dá suporte ao sistema online, realizando análise de dados e treinamento de machine learning
  • As funções de frontend e os serviços de backend armazenam vários dados de log no data warehouse
    • Treinamento de ML: os dados de log são usados para atualizar modelos de machine learning
    • Processamento de streams: atualiza os tópicos mais discutidos no site e os armazena em bancos de dados e caches
    • Análise em lote: usa Spark e Presto para atualizar o sistema de recomendação de amigos
    • Execução de funções serverless orientadas a eventos: atualizações de dados atuam como gatilhos de eventos para executar automaticamente funções serverless

# [Aumentando a produtividade dos desenvolvedores (Boosting Developer Productivity)]

• A infraestrutura compartilhada da Meta tem como objetivo maximizar a produtividade dos desenvolvedores
• Para isso, ela faz uso extremo de deploy contínuo (Continuous Deployment) e funções serverless (Serverless Functions)

Deploy contínuo (Continuous Deployment)

• A Meta é otimizada para implantar rapidamente alterações de código e de configuração (Configuration)
• Novos recursos e correções de bugs são implantados imediatamente, permitindo feedback rápido e melhorias iterativas
• Alterações de configuração (Configuration Changes)
  • A ferramenta de gerenciamento de configuração da Meta implanta em produção mais de 100 mil alterações em tempo real por dia
  • As configurações são atualizadas automaticamente em mais de 10 mil serviços e milhões de servidores
  • Diversas tarefas, como balanceamento de carga, rollout de recursos, testes A/B e prevenção de sobrecarga, são executadas automaticamente
  • As alterações de configuração passam por revisão e são commitadas no repositório de código como alterações de código, e as mudanças são propagadas por todo o sistema em poucos segundos
• Alterações de código (Code Changes)
  • A ferramenta de deploy da Meta opera mais de 30 mil pipelines de deploy para gerenciar atualizações de software
  • 97% dos serviços adotam deploy totalmente automatizado, sendo atualizados sem intervenção manual:
    • 55% usam deploy contínuo completo (CD), em que alterações de código são refletidas automaticamente em produção
    • 42% são implantados automaticamente em cronogramas fixos (diários ou semanais)
  • As funções serverless de frontend (FrontFaaS) são executadas em mais de 500 mil servidores, e mais de 10 mil desenvolvedores fazem milhares de commits de código todos os dias
  • Mesmo nesse ambiente tão dinâmico, novas versões de todas as funções serverless são implantadas em produção a cada 3 horas
• Atualizações de software de rede e infraestrutura
  • A WAN privada (Private WAN) da Meta mantém vários planos de rede paralelos, permitindo testar novos algoritmos de rede de forma independente
  • O software dos switches de rede também é atualizado com frequência, e, usando o recurso "Warm Boot" dos switches, é possível atualizar o software sem interromper o tráfego de rede
  • Como código atualizado com frequência e alterações de configuração aumentam o risco de falhas no site, a Meta investe fortemente em testes, deploy gradual e health checks
    • Foi conduzida uma campanha interna para aumentar a automação de deploy de código de 12% para 97%
    • Testes automáticos de canary são realizados para todas as alterações de configuração, garantindo a estabilidade

Funções serverless (Serverless Functions)

• Funções serverless (ou FaaS, Function-as-a-Service) são outro elemento central para aumentar a produtividade dos desenvolvedores
• Diferentemente dos serviços de backend tradicionais, as funções serverless não armazenam estado e implementam uma interface de função simples
• Cada invocação de função é executada de forma independente, e o estado é gerenciado com o uso de bancos de dados externos ou sistemas de cache
• Vantagens das funções serverless
  • Os desenvolvedores precisam apenas escrever a lógica do produto, sem gerenciar infraestrutura
  • Implantação de código e escalonamento automático (auto-scaling) conforme a variação de carga são realizados automaticamente
  • Evita desperdício de hardware e elimina a necessidade de os desenvolvedores alocarem recursos em excesso
• Plataforma serverless da Meta
  • Entre os mais de 10 mil desenvolvedores da Meta, o número dos que escrevem funções serverless é 50% maior do que o dos que escrevem código de serviços tradicionais
  • O ambiente de desenvolvimento serverless (IDE) da Meta dá suporte a acesso fácil ao banco de dados do grafo social e a diversos sistemas de backend, além de fornecer testes de integração contínua (CI), permitindo feedback rápido
• Plataforma serverless da Meta: FrontFaaS e XFaaS
  • FrontFaaS: funções serverless de frontend baseadas em PHP, executadas em mais de 500 mil servidores
    • Mantém o runtime de PHP sempre ativo, permitindo processar requisições imediatamente, sem problemas de cold start
    • Quando a carga do servidor é baixa, usa auto-scaling para liberar parte dos servidores e aproveitá-los em outras tarefas
  • XFaaS: funções serverless orientadas a eventos executadas de forma assíncrona
    • Processa tarefas em segundo plano que não exigem resposta imediata
    • Para evitar tarefas com carga alta, aplica atraso de execução, balanceamento global de carga e throttling baseado em cotas
• Inovação serverless da Meta
  • Desde o fim dos anos 2000, usa a abordagem serverless como paradigma padrão de desenvolvimento
  • Diferenças em relação às plataformas serverless de nuvem pública:
    • A nuvem pública usa uma máquina virtual por função para garantir isolamento forte
    • Em contrapartida, a Meta foi projetada para permitir que várias funções sejam executadas simultaneamente em um único processo Linux, maximizando a eficiência do hardware

# [Redução de custos de hardware (Reducing Hardware Costs)]

• A infraestrutura compartilhada da Meta não apenas aumenta a produtividade dos desenvolvedores, mas também desempenha um papel importante na redução de custos de hardware
• Para isso, ela usa uma estratégia de maximizar a eficiência do hardware por meio de otimizações de software

Operar todos os datacenters globais como um único computador (All Global Datacenters as a Computer)

• Em ambientes de nuvem tradicionais, os usuários precisavam configurar diretamente o número de réplicas (replicas) de serviço, regiões de implantação etc.
• Esse modelo de gerenciamento manual causava problemas como desperdício de recursos, desequilíbrio de carga e falta de migração entre datacenters
• A Meta evoluiu da abordagem existente de operar um datacenter como um computador (DaaC, Datacenter as a Computer) para implementar o Global-DaaC, que opera os datacenters do mundo inteiro como se fossem um único computador
• Principais características do Global-DaaC:
  • Se o usuário simplesmente fizer uma solicitação de implantação global, a infraestrutura determina automaticamente o número ideal de réplicas, as regiões de implantação, o tipo de hardware e o roteamento de tráfego
  • Altera a localização dos serviços conforme necessário e consegue se adaptar a mudanças de oferta e de carga
  • Diferentemente da nuvem pública, a Meta opera todas as aplicações por conta própria, o que permite mover workloads com mais flexibilidade
• Como o Global-DaaC é implementado
  • Automatiza a alocação de recursos nos níveis global, regional e de servidor individual:
    • Ferramenta global de gerenciamento de capacidade: analisa dependências entre serviços usando rastreamento de RPC e determina a alocação ideal de capacidade por meio de programação inteira mista (MIP)
    • Ferramenta regional de gerenciamento de capacidade: aloca recursos de servidor por datacenter para formar clusters virtuais (Virtual Cluster)
    • Ferramenta de gerenciamento de contêineres: posiciona contêineres dentro de clusters virtuais e os distribui entre vários datacenters para garantir tolerância a falhas (Fault Tolerance)
    • Técnicas de gerenciamento de kernel: compartilham e isolam adequadamente recursos de memória e I/O entre contêineres
• Casos de aplicação do Global-DaaC
  • Bancos de dados e serviços com armazenamento de estado:
    • Cada contêiner hospeda vários shards de dados para maximizar a eficiência
    • O Global Service Placer (GSP) determina o número ideal de réplicas de shard e as regiões de implantação
    • Com base nisso, o framework de sharding atribui shards aos contêineres e os migra dinamicamente
  • Workloads de machine learning (ML):
    • Tarefas de inferência (Inference) de ML gerenciam réplicas de modelos como shards de dados
    • O treinamento (Training) de ML exige que os dados e as GPUs estejam posicionados no mesmo datacenter
    • Recebe alocação global de capacidade de GPU, e o escalonador de treinamento de ML realiza a replicação de dados e o posicionamento ideal das GPUs

Co-design de hardware e software (Hardware and Software Co-Design)

• Aplicar co-design de hardware e software no nível de um único servidor é algo comum, mas a Meta expandiu isso para escala global e superou as limitações de hardware de baixo custo por meio de otimizações de software
• Tolerância a falhas de baixo custo (Low-Cost Fault Tolerance)
  • As nuvens públicas oferecem hardware com alta disponibilidade, mas a Meta adotou uma abordagem de superar falhas via software, o que permite usar hardware mais barato
  • Principais diferenças:
    • Os racks de servidores das nuvens públicas usam fonte de alimentação dupla e switches ToR (Top-of-Rack) duplos, enquanto a Meta usa fonte única e switch ToR único
    • As máquinas virtuais (VMs) das nuvens públicas usam armazenamento em bloco conectado à rede, permitindo migração ao vivo, enquanto os contêineres da Meta usam SSDs locais de baixo custo
  • Estratégias de mitigação de falhas baseadas em software:
    • Ferramentas de alocação de recursos: distribuem os contêineres dos serviços e os shards de dados entre diferentes domínios de falha dentro do datacenter
    • Protocolos cooperativos: permitem que a aplicação intervenha no gerenciamento do ciclo de vida dos contêineres, evitando que réplicas de shards de dados sejam interrompidas ao mesmo tempo
    • Garantia de durabilidade entre múltiplos datacenters: o sistema foi projetado para manter os serviços ativos mesmo se uma região inteira sair do ar, com testes práticos regulares para validar a confiabilidade
• Redução do custo de proxies de roteamento (Eliminating Routing Proxy Costs)
  • Service meshes tradicionais usam sidecar proxies para rotear requisições RPC, mas a Meta processa 99% das requisições RPC com roteamento direto cliente-servidor
  • Essa abordagem permite economizar cerca de 100 mil servidores de proxy
  • Há, porém, o desafio de compilar e distribuir a biblioteca de roteamento para mais de 10 mil serviços, algo que a Meta resolve com suas ferramentas de deploy de software e gerenciamento de configuração
• Armazenamento em camadas e uso de SSDs locais (Tiered Storage and Local SSDs)
  • A Meta segmenta o armazenamento de acordo com a frequência de acesso aos dados e os requisitos de latência para maximizar a eficiência de custos:
    • Dados quentes (Hot Data): armazenados em memória e SSD (ex.: banco de dados de grafo social)
    • Dados mornos (Warm Data): armazenados em sistema de arquivos distribuído baseado em HDD (ex.: vídeos, imagens e dados de log)
    • Dados frios (Cold Data): armazenados em servidores HDD de grande capacidade (ex.: vídeos antigos em alta resolução)
      • Mantidos em modo de baixo consumo para reduzir custos
  • Uso de SSDs locais:
    • Algumas cargas de trabalho têm melhor desempenho com SSD local do que com armazenamento remoto compartilhado
    • No entanto, existe o risco de baixa utilização dos SSDs devido à distribuição desigual de carga
    • A Meta usa seu framework comum de sharding para resolver o desequilíbrio e maximizar a eficiência dos SSDs

Design interno de hardware (In-House Hardware Design)

• A Meta projeta internamente datacenters, servidores, switches de rede e chips de IA para melhorar custo e eficiência energética
• Como a energia é o recurso mais limitado em um datacenter, a empresa opera ferramentas automatizadas para otimizar o consumo elétrico
• Co-design de hardware e software para reduzir custo e consumo de energia:
  • Otimização do uso de SRAM em chips de IA
  • Remoção de equipamentos de refrigeração por compressão nos datacenters
• A empresa também desenvolve internamente os switches de rede e o software, o que permite atualizações regulares, e compartilha a maior parte dos designs de hardware como open source por meio do Open Compute Project

# [Projetando sistemas escaláveis (Designing Scalable Systems)]

• Em infraestrutura em hiperescala, o projeto de sistemas escaláveis é um elemento central
• Sistemas distribuídos projetados para a internet (como BGP, BitTorrent e DHT) têm excelente escalabilidade, mas em ambientes de datacenter controladores centralizados podem oferecer maior escalabilidade e eficiência

Descontinuação de controladores descentralizados (Deprecating Decentralized Controllers)

• A Meta escolheu migrar de controladores descentralizados existentes para controladores centralizados
• Como exceção, os switches de rede mantêm o BGP, mas são projetados para que um controlador central possa reconfigurar rotas em caso de congestionamento de tráfego ou falha de link
• Controladores centralizados permitem melhor balanceamento de carga e resposta mais rápida a falhas, sendo mais adequados para o ambiente de datacenter

Casos de transição de sistemas distribuídos existentes para modelos centralizados

• WAN privada (Private WAN)
  • Antes usava RSVP-TE (configuração de rotas descentralizada), mas foi convertida para um sistema baseado em controlador central
  • Calcula automaticamente os melhores caminhos de tráfego e pré-configura rotas de backup em caso de falha, permitindo recuperação rápida
• Armazenamento chave-valor (Key-Value Store)
  • Saiu de um modelo baseado em roteamento multihop com DHT (Distributed Hash Table) para um framework de sharding baseado em controlador central
  • O controlador central ajusta dinamicamente a realocação de shards para otimizar o balanceamento de carga
• Distribuição de grandes volumes de dados
  • Antes usava BitTorrent (download P2P distribuído), mas a Meta migrou para um sistema de distribuição centralizado chamado Owl
  • Ao decidir centralmente os caminhos de download dos dados, o sistema entrega velocidades muito mais altas
• Distribuição de pequenos metadados
  • No início, era usada uma estrutura de árvore distribuída em 3 camadas (baseada em Java), depois alterada para uma estrutura em árvore baseada em P2P por problemas de escalabilidade
  • No entanto, o desempenho instável de alguns nós degradava o desempenho geral, levando por fim a um retorno para uma arquitetura centralizada de servidores proxy de alto desempenho baseados em C++

Estudo de caso: service mesh escalável (Scalable Service Mesh)

A Meta opera um service mesh próprio chamado ServiceRouter,
por meio do qual comprovou a eficácia de uma arquitetura centralizada escalável.

• Problemas da arquitetura tradicional de service mesh
  • Um service mesh típico faz com que cada processo de serviço roteie requisições RPC por meio de um sidecar proxy L7
  • Porém, em ambiente de hiperescala, é ineficiente para um controlador central gerenciar diretamente milhões de sidecar proxies
  • Por isso, a Meta substituiu o modelo com sidecar proxy por uma estrutura em que o próprio serviço cuida do roteamento
• Arquitetura ServiceRouter da Meta
  • Os metadados de roteamento são gerados no controlador central, mas cada roteador L7 monta sua própria tabela de roteamento
  • A escalabilidade é garantida com um banco de dados baseado em Paxos (RIB, Routing Information Base)
    • Os controladores são shardados para distribuir a carga, e vários controladores podem calcular em paralelo tabelas de roteamento para serviços específicos
  • A camada de distribuição (Distribution Layer) usa milhares de réplicas de RIB para atender requisições de leitura de milhões de roteadores L7
  • No fim, cada roteador L7 pode ser configurado de forma independente, sem intervenção direta do controlador central
• Como o ServiceRouter garante escalabilidade
  1. Adoção de controladores stateless: o controlador não gerencia diretamente roteadores específicos, apenas mantém informações globais de roteamento
  2. Sharding dos controladores: vários controladores operam de forma independente e conseguem processar em paralelo as informações de roteamento de diferentes serviços
  3. Remoção de funções não essenciais: a gestão individual de roteadores L7 foi removida do controlador, e cada roteador passou a ser gerenciado por conta própria
• Resultados e lições
  • Uma arquitetura que combina controlador centralizado com data plane distribuído oferece a melhor escalabilidade
  • A remoção de sidecar proxies desnecessários otimiza custos operacionais e desempenho
  • Com sharding estratégico e design stateless, é possível gerenciar com eficiência o roteamento de milhões de serviços

# [Perspectivas futuras (Future Directions)]

• A infraestrutura em hiperescala da Meta é extremamente complexa, mas este documento fornece um resumo dos principais insights técnicos
• Por fim, compartilha perspectivas sobre as tendências futuras da infraestrutura em hiperescala

AI (inteligência artificial)

• As cargas de trabalho de AI tornaram-se atualmente as cargas de trabalho com maior peso nos datacenters
• Espera-se que, antes de 2030, mais da metade do consumo de energia dos datacenters seja usada por cargas de trabalho de AI
• A AI tem grande potencial para transformar fundamentalmente a estrutura da infraestrutura existente devido a redes de alto desempenho e alto consumo de recursos
• No passado, a infraestrutura em hiperescala evoluiu no modelo de scale-out (implantação em massa de servidores de baixo custo), mas
  os clusters de AI do futuro provavelmente migrarão para um modelo de scale-up (estrutura de supercomputador)
  • Exemplo: uso de redes Ethernet baseadas em RDMA (Remote Direct Memory Access), otimizadas para treinamento de machine learning (ML) em larga escala
• A Meta está conduzindo um co-design full-stack que abrange PyTorch → modelos de ML → chips de AI → rede → datacenter → servidores → armazenamento → energia e resfriamento

Hardware específico por domínio (Domain-Specific Hardware)

• Nos anos 2000, o hardware se tornou cada vez mais padronizado, mas
  daqui para frente, a tendência é de aumento de diversos hardwares especializados para treinamento/inferência de AI, virtualização, codificação de vídeo, criptografia, compressão, memória em camadas e mais
• Empresas de hiperescala conseguem projetar e implantar hardware personalizado de forma econômica por meio de produção em massa
• No entanto, esse aumento na diversidade de hardware tende a ampliar a complexidade da stack de software e trazer desafios para gerenciar ambientes heterogêneos

Datacenters de borda (Edge Datacenters)

• Com o aumento das aplicações de metaverso (Metaverse) e Internet das Coisas (IoT), espera-se a expansão dos datacenters de borda
• Cloud gaming executa a renderização gráfica não no dispositivo do usuário, mas em servidores com GPU em datacenters de borda, e
  uma baixa latência de rede, inferior a 25 ms, é essencial
• Com o aumento de aplicações em que a resposta em tempo real é importante, há grande possibilidade de crescimento significativo no número e na escala dos datacenters de borda
• Para operá-los com eficiência, será necessário expandir o Global-DaaC (conceito de operar datacenters no mundo todo como se fossem um único computador) e otimizá-lo para que os desenvolvedores não precisem se preocupar com a gestão de uma infraestrutura complexa

Aumento da produtividade dos desenvolvedores (Developer Productivity)

• Nos últimos 20 anos, ferramentas de automação melhoraram muito a produtividade dos administradores de sistemas, fazendo com que a proporção de servidores por administrador aumentasse drasticamente
• No entanto, o desenvolvimento de software ainda é intensivo em mão de obra e tem avançado lentamente em produtividade
• Daqui para frente, a produtividade dos desenvolvedores deve aumentar rapidamente por causa de dois fatores:
  1. Avanços em ferramentas de geração e depuração de código com AI
  2. Surgimento de paradigmas de programação serverless totalmente integrados e específicos por domínio
• O FrontFaaS da Meta é um exemplo desse modelo de programação serverless, e
  espera-se que surjam novos paradigmas de programação otimizados para setores específicos no futuro (por exemplo, finanças e saúde)

Conclusão

• A inovação em infraestrutura centrada em AI avançará rapidamente na próxima década
• Empresas de hiperescala devem contribuir para que toda a comunidade avance mais rapidamente ao compartilhar seus insights

[secret3056]

Aquele PoP é BGP4 ou anycast de TCP, e não existe jeito de uma pessoa física usar isso, né..? snif snif

[pribess]

Não entendi muito bem o que exatamente significa a descrição de que o PoP é BGP4 ou TCP anycast, mas se a pergunta é se operam um AS próprio, então sim.
Normalmente, serviços multi-region mais comuns usam mais balanceamento baseado em geolocalização junto com anycast DNS.
Sim, no momento não há. Se você precisa de um PoP multi-region, então terá que usar outro provedor.

[GN⁺]

Comentários do Hacker News

• Após o desenvolvimento do Threads, a equipe de infraestrutura recebeu apenas dois dias de aviso para se preparar para o lançamento. A maioria das grandes organizações leva mais de dois dias só para elaborar um plano de projeto envolvendo dezenas de equipes interdependentes. Na Meta, porém, montaram rapidamente salas de guerra em locais distribuídos para que as equipes de infraestrutura e produto resolvessem problemas em tempo real. O app alcançou 100 milhões de usuários em apenas 5 dias após o lançamento, tornando-se o aplicativo com crescimento mais rápido da história

• É impressionante manter a capacidade de lançar produtos rapidamente. Isso exige muito esforço para evitar o aumento da burocracia e impedir que o jurídico ou outros departamentos criem etapas de aprovação. Ou então é preciso ter a capacidade de concluir tudo rapidamente por meio de salas de guerra

• Quando eu estava no FB, vivi na prática o quão poderosa era a infraestrutura. Engenheiros de produto construíam projetos enormes em poucos dias. Trabalhei como líder técnico de várias equipes, e algumas das mencionadas aqui incluem as equipes do HBase e do ZippyDB

• É legal ver o ZippyDB sendo mencionado publicamente pela primeira vez. Também é muito legal que a melhoria na eficiência dos desenvolvedores tenha sido mencionada. Todos os dias, 10.000 serviços são enviados ou todos os commits são realizados

• Depois de sair do FB, não consegui encontrar nada parecido. Então estou construindo, numa startup, a infraestrutura de que eu precisava. Batteries Included

• É uma pena ver tanto cinismo e tantas reações negativas nestes comentários. Muita gente odeia a Meta, mas o artigo em si me causou admiração. Eu não fazia ideia de quão ampla e complexa é a infraestrutura que sustenta o mundo digital moderno. Ler este artigo e ver essa escala é impressionante

• A empresa pode ser ruim em vários aspectos, mas tudo o que aparece no artigo é impressionante para mim

• Não sou engenheiro como vocês, então este artigo pode ser notícia velha para vocês, mas eu não consegui deixar de dizer "uau"

• Se mostrassem este artigo a escritores de ficção científica do passado, acho que eles também ficariam admirados

• Impressionante. Toda essa tecnologia incrível e impressionante, e alguns dos melhores engenheiros do mundo, sendo usados apenas para colocar mais anúncios na frente dos olhos das pessoas. Suspiro

• É interessante descrever o frontend web em PHP como uma arquitetura "serverless" ou "função como serviço". Parece uma questão de perspectiva. É um serviço com uma base de código única com muitos endpoints implantados. Do ponto de vista de quem mantém os endpoints, pode ser "serverless", mas, como toda abstração, há vazamentos

• Em ambientes de datacenter, prefiro controladores centralizados por causa da simplicidade e da capacidade de tomar decisões de alta qualidade. Em muitos casos, uma abordagem híbrida que combina um plano de controle centralizado com um plano de dados distribuído é a mais ideal

• Essa abordagem parece ser um dos projetos mais ideais para redes definidas por software (service mesh) e armazenamento (operações de banco de dados) em organizações com um grande número de servidores em larga escala. É surpreendente que a rede IP siga o mesmo modelo sem depender principalmente de BGP

• Eu esperaria que usassem cache local para reduzir a carga nos roteadores L7 e melhorar a latência das consultas ao banco de dados. O cliente pode invalidar o cache e consultar novamente o service mesh após um timeout razoável

• Funções serverless desenvolvidas rapidamente combinadas com implantação contínua, em que qualquer pessoa pode editar toda a base de código, soam como um pesadelo distópico. A quantidade de logging necessária para depurar e encontrar bugs é extrema

• Usar Erlang para escrever funções serverless parece evitar todas as grandes vantagens que o BEAM pode oferecer

• Os engenheiros de produto escrevem código principalmente em PHP, Python e Erlang como funções serverless sem estado. Isso traz vantagens em simplicidade, produtividade e velocidade de iteração

• Para aumentar a produtividade dos desenvolvedores, a Meta adotou implantação contínua de forma universal e permite que mais desenvolvedores escrevam funções serverless em vez de código de serviço tradicional

• Para cargas de computação não relacionadas a IA, eles oferecem apenas um único tipo de servidor, equipado com um único CPU e a mesma quantidade de DRAM (antes 64 GB, agora 256 GB). Fico curioso se isso é comum em toda a indústria ou apenas na Meta

• Quando a imagem não está em cache no CDN109 e um usuário a solicita, o CDN109 encaminha a requisição para um PoP próximo. O PoP encaminha a requisição para o load balancer da região do datacenter, e o load balancer busca a imagem no sistema de armazenamento

• Ao solicitar uma imagem de 1 MB, não seria mais rápido, numa conexão lenta, entregar essa imagem de 1 MB com 100 ms de latência do que passar por várias idas e voltas com latência crescente?

• Assumindo que a requisição passe pelos sistemas da Meta e que, no fim, vá para o mesmo datacenter, e assumindo que não exista tecnologia FTL

• A comparação explícita com hyperscalers é particularmente interessante. Fico me perguntando se isso é uma preparação para lançar sua própria nuvem pública. Espero que alguém da Meta dê sua opinião