Meta's Hyperscale Infrastructure: Overview and Insights
Обзор whitepaper Meta о гипермасштабной инфраструктуре: инженерная культура, E2E request flow, DevEx, cost optimization и архитектурные инсайты.
Практика чтения для этого источника ещё не опубликована
Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.
Открыть оригиналГотовый редакционный разбор
Он сохранён из прежней версии каталога и расположен после самостоятельной практики, чтобы не подменять чтение оригинала готовым пересказом.
Whitepaper
Meta's Hyperscale Infrastructure: Overview and Insights
CACM, январь 2025. Автор: Chunqiang Tang.
Whitepaper
Meta's Hyperscale Infrastructure: Overview and Insights
CACM, январь 2025. Автор: Chunqiang Tang.
Эта глава собрана по серии постов в tg-канале и даёт цельную картину whitepaper: как Meta проектирует инфраструктуру на масштабе в миллиарды пользователей, где соединяются инженерная культура, network/datacenter архитектура, developer productivity и экономическая эффективность платформы.
В тексте ниже используется имя компании Meta как технический контекст статьи; в РФ деятельность Meta Platforms Inc. признана экстремистской и запрещена.
Основа обзора
Серия постов [1/7]-[7/7]
Telegram-разборы, на которых построена эта глава.
Основа обзора
Серия постов [1/7]-[7/7]
Telegram-разборы, на которых построена эта глава.
Карта исходного материала
[1/7]
Общее содержание статьи
Контекст whitepaper и 6 тем: culture, flow, productivity, costs, scalability, future.
[2/7]
Engineering Culture
Move fast, openness, research in production, единая инфраструктура и стандарты.
[3/7]
End-to-End User Request Flow
PoP, CDN, региональные ЦОДы, private WAN, онлайн/офлайн контуры.
[4/7]
Boosting Developer Productivity
97% automated deployment, FaaS-парадигма и massive config-as-code.
[5/7]
Reducing Hardware Costs
Глобальный computer, co-design железа и софта, software-first reliability.
[6/7]
Designing Scalable Systems
Centralized control plane + distributed data plane, пример ServiceRouter.
[7/7]
Future Directions
AI-centric датацентры, специализированное железо, edge-рост и AI-ассистенты.
Engineering Culture
Move fast
Агрессивный CD и короткий цикл идеи -> production позволяют быстро менять приоритеты.
Кейс Threads: продукт за ~5 месяцев, инфраструктурная подготовка за 2 дня до запуска.
Открытость технологий
Монорепозиторий и низкий барьер на изменения между командами ускоряют переиспользование.
Внешне: Open Compute, PyTorch, RocksDB и другие открытые инициативы.
Research in production
Инновации рождаются в боевых задачах и публикуются после практической проверки.
Фокус смещается с лабораторной новизны на проверяемую инженерную ценность.
Единый стек и стандартизация
Унификация серверов, платформ и инструментов снижает организационную сложность.
Цель - глобальная оптимизация вместо локального «зоопарка» решений.
End-to-End User Request Flow
Edge first: PoP и CDN
Пользовательский трафик терминируется ближе к пользователю, а статика отдаётся с edge-кеша.
Meta использует PoP + CDN sites + кеши внутри сетей провайдеров.
Private WAN
Междатацентровый трафик идёт по собственной WAN, а не по публичному интернету.
Причина: очень высокий объём внутреннего cross-DC трафика.
Serverless frontend
Динамические запросы обрабатываются фронтенд-функциями с fanout во внутренние сервисы.
Онлайн-контур оптимизируется под latency и reliability.
Async + offline контур
Некритичные задачи уходят в очереди и event-driven функции, а data warehouse разделяет онлайн и офлайн.
Это декуплинг архитектуры и независимая оптимизация обоих контуров.
E2E инфраструктура: Users to CDN/PoP to Private WAN to Datacenter Regions
Users
CDN Site
Count: O(1,000)
Typically O(10), up to 100+ servers/site
PoP
Count: O(100)
Typically O(100), up to O(1,000) servers/PoP
Private WAN
Express Backbone
Datacenter Region
Count: O(10)
Up to 1,000,000 servers/region
Multiple datacenters/region
O(100,000) servers/datacenter
Up to 12 MSBs/datacenter
Typically 10K-20K servers/MSB
Datacenter Region
Count: O(10)
Up to 1,000,000 servers/region
Multiple datacenters/region
O(100,000) servers/datacenter
Up to 12 MSBs/datacenter
Typically 10K-20K servers/MSB
Users
CDN Site
Count: O(1,000)
Typically O(10), up to 100+ servers/site
PoP
Count: O(100)
Typically O(100), up to O(1,000) servers/PoP
Private WAN
Express Backbone
Datacenter Region
Count: O(10)
Up to 1,000,000 servers/region
Multiple datacenters/region
O(100,000) servers/datacenter
Up to 12 MSBs/datacenter
Typically 10K-20K servers/MSB
Datacenter Region
Count: O(10)
Up to 1,000,000 servers/region
Multiple datacenters/region
O(100,000) servers/datacenter
Up to 12 MSBs/datacenter
Typically 10K-20K servers/MSB
Flow пользовательского запроса
Step 1
DNS -> PoP
Подключение начинается на edge datacenter.
Step 2
PoP -> Private WAN
Динамический запрос отправляется во внутреннюю сеть.
Step 3
Regional frontend
Фронтенд-функция в регионе обрабатывает запрос.
Step 4
Backend fanout
Запросы к сервисам, кэшам и хранилищам.
Step 5
Response + async events
Ответ пользователю, события в очереди/warehouse.
`Static cache hit` завершает путь на edge-кэше. `Dynamic request` проходит через private WAN и региональные сервисы.
Диаграмма отражает структуру из whitepaper: трафик приходит через CDN/PoP, идёт по private WAN и обслуживается в региональных кластерах датацентров через fabric-слой.
Scale from Table 1
Region
Count: O(10)
Up to 1,000,000 servers/region
PoP
Count: O(100)
Typically O(100), up to O(1,000) servers/PoP
CDN site
Count: O(1,000)
Typically O(10), up to 100+ servers/site
Datacenter
Multiple datacenters/region
O(100,000) servers/datacenter
MSB
Up to 12 MSBs/datacenter
Typically 10K-20K servers/MSB
Figure 2. High-level architecture of software components in a datacenter region
Упрощённая схема. В реальности внутри Meta задействовано O(10,000) backend-сервисов со сложным call graph.
Real-time user-request processing
Load Balancer
Ingress routing
Frontend serverless functions
Request orchestration
Backend services
Business logic + fanout
Databases & caches
Low-latency state
Storage
Durable objects/files
ML inference
Online model scoring
Enqueue async events
Некритичные задачи уходят в event queue (например, email confirmations).
Offline processing
Data warehouse
Intermediate layer between online/offline
ML training
Model retraining pipelines
Stream processing
Near real-time analytics
Batch & interactive analytics
Historical and ad-hoc analysis
Event queue
Asynchronous buffering
Event-driven serverless functions
Background processing workers
Output
Feature updates, model updates, derived data for online serving.
Data logging
Real-time path continuously logs signals to the data warehouse.
Model update
Offline ML training pushes updated models into online ML inference.
Data update
Stream/batch analytics update online databases and caches.
Async processing
Frontend/backend enqueue events that are processed by event-driven functions.
Масштаб топологии (из обзора)
- Десятки регионов, в каждом регионе множество ЦОДов и сотни тысяч серверов в датацентре.
- Сотни PoP-узлов (обычно сотни/тысячи серверов на узел).
- Тысячи CDN sites (обычно десятки серверов, иногда сотни).
- Внутри ЦОДов используются MSB-секции питания, каждая на десятки тысяч серверов.
Boosting Developer Productivity
Continuous deployment на экстремальном масштабе
97% сервисов разворачиваются полностью автоматически, 55% деплоят каждую правку сразу.
Более 30k пайплайнов и частые релизы даже на сотнях тысяч серверов.
Config as code everywhere
Каждый день в production автоматически вносятся >100k конфигурационных изменений.
Единые review/CD-практики для кода и конфигов уменьшают операционный разрыв.
FaaS как основной режим разработки
Более 10k инженеров пишут serverless-функции: FrontFaaS для latency, XFaaS для throughput.
Реальный продуктовый код смещается к stateless + managed платформам.
Reducing Hardware Costs
All global datacenters as a computer
Глобальная инфраструктура работает как единый вычислитель с миграцией нагрузок без участия пользователя.
Подход уже применялся к БД, ML-системам и сервисам масштаба O(100,000) узлов.
Software-first reliability
Дешевле железо, выше требования к устойчивости программного стека.
Trade-off: больше сложности в софте в обмен на значимую экономию CAPEX/OPEX.
ServiceRouter и отказ от sidecar everywhere
Около 99% RPC маршрутизируются напрямую библиотекой, а не через proxy sidecar.
В обзоре подчёркнута экономия уровня 100k+ серверов.
In-house hardware design
Meta проектирует ЦОД, серверы, стойки и свитчи под собственные профили нагрузки.
Особый фокус - энергоэффективность и power constraints.
Пример дизайна
ServiceRouter (OSDI 2023)
Гибрид service mesh: централизованный control plane и распределённый data plane.
Пример дизайна
ServiceRouter (OSDI 2023)
Гибрид service mesh: централизованный control plane и распределённый data plane.
Designing Scalable Systems
Централизация vs децентрализация
Ключевая позиция paper: внутри управляемой DC-среды централизованный контроллер часто проще, стабильнее и даёт глобально более качественные решения, чем множество локальных агентов.
Гибридный паттерн
Лучший баланс часто достигается схемой centralized control plane + decentralized data plane: глобальная оптимизация без пропуска всего трафика через единый узел.
Figure: ServiceRouter's scalable service-mesh architecture
Централизованный control plane вычисляет routing-решения, а data distribution layer масштабно реплицирует RIB для data plane.
Data Warehouse
Service metrics, latency, traffic matrix
Independent Controllers
Control plane computes global routing policies
Routing Information Base (RIB)
• Service discovery info (service name, IP, port)
• Per-service routing config (e.g., RPC timeout)
• Cross-region routing data (latency and traffic matrix)
Data distribution layer (RIB replicas)
RIB Replica Set A
RIB Replica Set B
RIB Replica Set C
Massive replication of RIB enables horizontal scale-out for millions of routers/services.
Dedicated Load Balancer
Consumes routing state for high-throughput traffic steering
Service + Service Library
In-process router caches subset of the RIB
Server + Sidecar Proxy
Proxy caches small subset of the RIB
Telemetry flow to Data Warehouse
Future Directions
AI-центричная инфраструктура
Кластеры становятся более scale-up и ближе к модели суперкомпьютеров под AI training.
От PyTorch до cooling и networking - всё ко-дизайнится как единый стек.
Гетерогенное специализированное железо
Рост кастомных ускорителей (ASIC/NPUs) для AI, media, security и in-network processing.
Ключевой вызов - оркестрация и абстракции поверх разнородного hardware-пула.
Edge-расширение под low-latency сценарии
AR/VR, cloud gaming и IoT двигают инфраструктуру к сети более мелких edge-ЦОДов.
Ожидание: многоуровневая оркестрация «регион + микро-ЦОДы».
Новый слой DevEx через AI
AI-ассистенты и вертикально интегрированные платформы повышают output инженеров.
Роль разработчика смещается к управлению логикой, валидацией и governance.
Сводка 9 инсайтов из whitepaper
Insight 1: большая организация может сохранять move-fast культуру при общей инфраструктуре и монорепозитории.
Insight 2: глобальная инфраструктура Meta опирается на связку CDN + edge DC + main DC + private WAN.
Insight 3: data warehouse как промежуточный слой упрощает разрыв online/offline обработки.
Insight 4: continuous deployment возможен даже для O(10,000) сервисов на экстремальной скорости.
Insight 5: serverless-функции стали основным способом продуктовой разработки внутри Meta.
Insight 6: переход от datacenter-as-a-computer к all-global-datacenters-as-a-computer.
Insight 7: software-компенсация ограничений более дешёвого hardware оправдана экономикой масштаба.
Insight 8: собственный дизайн ЦОДов и железа снижает cost и power consumption.
Insight 9: в датацентре централизованный control plane часто проще и эффективнее децентрализованного.
Практический чеклист для архитекторов и платформенных команд
- Определите, где вам действительно нужна вариативность стека, а где выгоднее стандартизация.
- Разделите online и offline контуры через стабильный data-интерфейс (warehouse/lake/lakehouse).
- Доведите CD для кода и конфигов до единого процесса с быстрым rollback и canary-контролем.
- В сервис-меше оцените гибридную модель: centralized control plane + distributed data plane.
- Планируйте graceful degradation заранее, чтобы снижать peak-перепровижининг.
- Синхронизируйте roadmap платформы и hardware, если нагрузка или scale это оправдывают.
Куда копать дальше
Data platform
Как устроить надёжный и дешёвый online/offline bridge без потери скорости экспериментов.
AI infra
Переход к гетерогенным кластерам требует новых abstraction layers для scheduling и cost control.
DevEx platform
Продуктивность растёт, когда CI/CD, config pipelines, observability и AI-tools объединены в одну экосистему.
Связанные главы
Build Latency, Predictability, and Developer Productivity
Как инфраструктурные задержки и предсказуемость влияют на Developer Experience.
How We Use GenAI in SRE
Надёжность, эксплуатация и новые инженерные практики SRE.
Monarch: Google's Planet-Scale Time Series Database
Архитектурные компромиссы распределённой системы Google на гипермасштабе.
Главный практический вывод из всей серии: гипермасштабные компании не просто «покупают больше серверов», а перестраивают культуру, процессы и архитектурные границы так, чтобы скорость, надёжность и экономика усиливали друг друга, а не конкурировали.