Panorama general y perspectivas sobre la infraestructura hiperescalable de Meta

• La cultura de ingeniería de Meta enfatiza la ejecución rápida, la apertura tecnológica, la investigación en producción y la infraestructura compartida
• Para aumentar la productividad de los desarrolladores, adopta el despliegue continuo y permite que más desarrolladores escriban funciones serverless en lugar de código de servicio tradicional
• Para reducir los costos de hardware, aprovecha el codiseño de hardware y software a escala de centro de datos, y optimiza automáticamente la asignación de recursos entre centros de datos de todo el mundo en lugar de limitarse a clústeres individuales
• La estrategia de IA de Meta codiseña toda la pila, desde PyTorch hasta aceleradores de IA, redes y modelos de ML como Llama

# [Cultura de ingeniería]

Ejecución rápida (Move Fast)

• Meta mantiene una cultura de agilidad e iteración rápida que enfatiza el enfoque de “moverse rápido”
• Respalda firmemente el despliegue continuo (Continuous Deployment) para implementar el código más reciente en producción lo antes posible
• Los ingenieros de producto escriben funciones serverless sin estado usando lenguajes como PHP, Python y Erlang
• Pueden cambiar prioridades sin largos procesos de planificación y resuelven problemas inciertos mediante ejecución iterativa
• Este enfoque permite una rápida respuesta al mercado y lanzamientos de producto ágiles

Apertura tecnológica (Technology Openness)

• Apertura interna: usa un enfoque de monorepo para almacenar el código de todos los proyectos en un único repositorio
  • Facilita la búsqueda de código, la reutilización y la colaboración entre equipos
  • En la mayoría de los proyectos no existen restricciones estrictas de propiedad del código, por lo que los desarrolladores pueden contribuir libremente
• Apertura externa: comparte activamente proyectos de hardware y software de código abierto
  • Publica diseños de hardware a través de Open Compute Project
  • Mantiene diversos proyectos de software de código abierto como PyTorch, Llama, Presto, RocksDB y Cassandra
  • Comparte tecnologías de infraestructura mediante artículos de investigación

Investigación en producción (Research in Production)

• Meta realiza investigación en entornos operativos reales sin un laboratorio de sistemas dedicado
• Los equipos que desarrollan sistemas de producción redactan directamente artículos de investigación para resolver problemas reales y ofrecer soluciones validadas en entornos operativos a gran escala
• Este enfoque es práctico y cumple con los criterios clave de una investigación de sistemas exitosa

Infraestructura común (Common Infrastructure)

• En lugar de que cada equipo elija libremente su stack tecnológico, se priorizan la estandarización y la optimización global
• Hardware:
  • Todos los servidores se asignan desde un pool compartido de servidores
  • Para cargas de trabajo de cómputo no relacionadas con IA, se ofrece un único tipo de servidor (básicamente 1 CPU y 256 GB de DRAM) para reducir la complejidad de los tipos de servidor
• Software:
  • Antes se usaban varios almacenes clave-valor como Cassandra, HBase y ZippyDB, pero ahora se ha consolidado en ZippyDB
  • El despliegue de software, la gestión de configuración, el service mesh y las pruebas de rendimiento están unificados en herramientas comunes
• Preferencia por componentes reutilizables:
  • Se ha construido una cadena de reutilización de componentes compuesta por el sistema de archivos Tectonic → ZippyDB (almacenamiento de metadatos) → Shard Manager (gestión del sharding de datos) → ServiceRouter (descubrimiento de shards y enrutamiento de solicitudes) → Delos (almacén de datos de alta confiabilidad)
  • En lugar de sistemas monolíticos como HDFS, se usan componentes modulares y reutilizables para maximizar la escalabilidad

Caso de estudio cultural: desarrollo de la app Threads (Culture Case Study: The Threads App)

• El caso del desarrollo de la app Threads muestra claramente la cultura de ingeniería de Meta
• El trabajo técnico se completó en solo 5 meses, y tras un aviso previo de 2 días, el equipo de infraestructura terminó de preparar el despliegue en producción
• En la mayoría de las grandes empresas, incluso redactar un plan de proyecto en dos días sería difícil. Pero Meta montó un war room para resolver problemas en tiempo real y respondió con rapidez
• Como resultado, superó los 100 millones de usuarios en 5 días desde su lanzamiento, convirtiéndose en la app de crecimiento más rápido de la historia
• Threads pudo escalar rápidamente reutilizando infraestructura existente:
  • El backend en Python de Instagram
  • La infraestructura compartida de Meta (base de datos del grafo social, almacén clave-valor, plataforma serverless, plataforma de ML, gestión de configuración de apps móviles, etc.)
• Apertura interna: aprovechó el monorepo para reutilizar parte del código de Instagram y acelerar el desarrollo
• Apertura externa: apunta a la interoperabilidad con otras apps mediante ActivityPub
• Compartir la experiencia de desarrollo: difundió públicamente la experiencia de desarrollo y despliegue rápidos

# [Flujo de solicitud de usuario de extremo a extremo (End-to-End User Request Flow)]

• Para examinar en profundidad las tecnologías de infraestructura de Meta, se explica todo el proceso mediante el cual se procesa una solicitud de usuario
• Los productos de Meta están respaldados por una infraestructura de servicios compartidos, que incluye varios componentes clave

Enrutamiento de solicitudes (Request Routing)

• Mapeo dinámico de DNS (Dynamic DNS Mapping)
  • Cuando un usuario accede a facebook.com, el servidor DNS de Meta devuelve dinámicamente la dirección IP del PoP (Point of Presence) más cercano
  • Un PoP es un pequeño centro de datos de borde que distribuye la carga de red desde una ubicación cercana al usuario
  • El PoP mantiene conexiones TCP de larga duración con los centros de datos de Meta, lo que reduce el tiempo de establecimiento de conexión TCP y mejora el rendimiento de red
  • Hay cientos de PoP desplegados en todo el mundo, lo que proporciona a la mayoría de los usuarios baja latencia de red
• Caché de contenido estático (Static-Content Caching)
  • El contenido estático, como imágenes y videos, se almacena en caché en los PoP y puede entregarse directamente
  • Además, Meta opera una CDN (red de distribución de contenido) y colabora con los ISP (proveedores de servicios de internet) para construir sitios CDN
  • Si la solicitud del usuario es facebook.com/image.jpg, Meta la reescribe como CDN109.meta.com/image.jpg para entregar el contenido desde un sitio CDN cercano
  • Si ese contenido no está en la CDN, la solicitud se transmite por PoP → balanceador de carga del centro de datos → sistema de almacenamiento
• Enrutamiento de solicitudes de contenido dinámico (Dynamic-Content Request Routing)
  • Las solicitudes de contenido dinámico, como el feed de noticias, se reenvían desde el PoP al centro de datos
  • Una herramienta de ingeniería de tráfico selecciona el centro de datos óptimo considerando la capacidad del centro de datos y la latencia de red
  • El tráfico desde el PoP hasta el centro de datos se transporta a través de la WAN privada (red de área amplia) de Meta
  • El tráfico entre centros de datos es mucho mayor que el tráfico usuario-PoP, debido a la replicación de datos y a las interacciones entre microservicios

Topología de infraestructura (Infrastructure Topology)

• La infraestructura global de Meta está compuesta por componentes de infraestructura de múltiples capas
• Cada componente cumple una función específica y opera a la siguiente escala:
  • Región de centros de datos (Region): hay alrededor de 10 regiones de centros de datos en todo el mundo, y cada región puede operar hasta 1 millón de servidores
  • PoP (Point of Presence, centro de datos de borde): hay más de 100 PoP, y cada PoP normalmente incluye entre 100 y 1,000 servidores. Su función es procesar el tráfico cerca de los usuarios para reducir la latencia
  • Sitio CDN: hay más de 1,000 sitios CDN, que por lo general incluyen más de 10 servidores, y algunos sitios grandes operan más de 100 servidores. Almacenan en caché contenido estático (imágenes, videos, etc.) para entregarlo rápidamente
  • Centro de datos (Datacenter): en cada región de centros de datos hay varios centros de datos, y cada centro de datos puede operar alrededor de más de 100,000 servidores
  • MSB (Main Switchboard, tablero principal de distribución): dentro de un centro de datos puede haber hasta 12 MSB, y cada MSB se encarga de 10,000 a 20,000 servidores. Cumple la función de distribución eléctrica y actúa como un dominio principal de falla dentro del centro de datos. Si un MSB falla, hasta 20,000 servidores pueden quedar fuera de servicio
• Red de borde:
  • Los PoP se conectan con múltiples sistemas autónomos (AS) de Internet y usan BGP (Border Gateway Protocol) para seleccionar la mejor ruta
• Red del centro de datos:
  • Los servidores se conectan usando una topología Clos de 3 niveles
  • Está diseñada para evitar la congestión de red y ofrecer el máximo ancho de banda entre servidores
• Red regional:
  • Los centros de datos se conectan mediante fabric aggregators, lo que les permite comunicarse con la WAN
  • Usa una topología Fat-Tree para poder escalar de forma gradual

Procesamiento de solicitudes (Request Processing)

• Procesamiento en línea (Online Processing)
  • Las solicitudes de los usuarios se distribuyen mediante balanceadores de carga hacia decenas de miles de funciones frontend serverless (FrontFaaS)
  • Las funciones frontend pueden llamar a varios servicios backend, y también pueden llamar a servicios de inferencia de ML (por ejemplo, recomendaciones de anuncios, recomendaciones de contenido del News Feed)
  • Durante la ejecución, las funciones frontend agregan eventos a una cola de eventos para que funciones serverless basadas en eventos (XFaaS) se ejecuten de manera asíncrona
  • La proporción de servidores entre funciones frontend y funciones basadas en eventos es de aproximadamente 5:1
• Procesamiento offline (Offline Processing)
  • El sistema de procesamiento offline complementa al sistema en línea y realiza análisis de datos y entrenamiento de machine learning
  • Las funciones frontend y los servicios backend almacenan diversos datos de logs en el data warehouse
    • Entrenamiento de ML: se usan los datos de logs para actualizar modelos de machine learning
    • Procesamiento de streams: se actualizan los temas más discutidos dentro del sitio y se almacenan en bases de datos y cachés
    • Análisis por lotes: se usan Spark y Presto para actualizar el sistema de recomendaciones de amigos
    • Ejecución de funciones serverless basadas en eventos: las actualizaciones de datos actúan como disparadores de eventos para ejecutar automáticamente funciones serverless

# [Mejora de la productividad de los desarrolladores (Boosting Developer Productivity)]

• La infraestructura compartida de Meta tiene como objetivo maximizar la productividad de los desarrolladores
• Para ello, aprovecha al máximo el despliegue continuo (Continuous Deployment) y las funciones serverless (Serverless Functions)

Despliegue continuo (Continuous Deployment)

• Meta está optimizada para desplegar rápidamente cambios de código y de configuración (Configuration)
• Las nuevas funciones y correcciones de errores se despliegan de inmediato, lo que permite retroalimentación rápida y mejoras iterativas
• Cambios de configuración (Configuration Changes)
  • La herramienta de gestión de configuración de Meta despliega en producción más de 100,000 cambios en tiempo real por día
  • La configuración se actualiza automáticamente en más de 10,000 servicios y millones de servidores
  • Se realizan automáticamente diversas tareas, como balanceo de carga, despliegue gradual de funciones, pruebas A/B y prevención de sobrecarga
  • Los cambios de configuración se revisan y se confirman en el repositorio de código igual que los cambios de código, y los cambios se propagan a todo el sistema en cuestión de segundos
• Cambios de código (Code Changes)
  • La herramienta de despliegue de Meta opera más de 30,000 pipelines de despliegue para gestionar actualizaciones de software
  • El 97% de los servicios adopta despliegues completamente automatizados, por lo que se actualizan sin intervención manual:
    • El 55% usa despliegue continuo completo (CD), por lo que los cambios de código se reflejan automáticamente en producción
    • El 42% se despliega automáticamente con un calendario fijo (diario o semanal)
  • Las funciones frontend serverless (FrontFaaS) se ejecutan en más de 500,000 servidores, y más de 10,000 desarrolladores realizan miles de commits de código cada día
  • Incluso en un entorno tan dinámico, todas las funciones serverless despliegan una nueva versión en producción cada 3 horas
• Actualizaciones de software de red e infraestructura
  • La WAN privada (Private WAN) de Meta mantiene múltiples planos de red en paralelo, lo que permite probar de forma independiente nuevos algoritmos de red
  • El software de switches de red también se actualiza con frecuencia, y al aprovechar la función "Warm Boot" del switch, es posible actualizar el software sin interrumpir el tráfico de red
  • Como el código y los cambios de configuración que se actualizan con frecuencia aumentan el riesgo de caídas del sitio, Meta invierte mucho en pruebas, despliegues graduales y health checks
    • Se llevó a cabo una campaña interna para aumentar la automatización de despliegues de código del 12% al 97%
    • Se realizan pruebas Canary automáticas para todos los cambios de configuración con el fin de garantizar la estabilidad

Funciones serverless (Serverless Functions)

• Las funciones serverless (o FaaS, Function-as-a-Service) son otro elemento clave para aumentar la productividad de los desarrolladores
• A diferencia de los servicios backend tradicionales, las funciones serverless no almacenan estado e implementan una interfaz de función simple
• Cada invocación de función se ejecuta de forma independiente y administra el estado mediante bases de datos externas o sistemas de caché
• Ventajas de las funciones serverless
  • Los desarrolladores solo necesitan escribir la lógica del producto sin administrar infraestructura
  • Se realizan automáticamente el despliegue del código y el escalado automático (Auto-Scaling) según las variaciones de carga
  • Evitan el desperdicio de hardware y los desarrolladores no necesitan asignar recursos en exceso
• La plataforma serverless de Meta
  • Entre los más de 10 mil desarrolladores de Meta, la cantidad de quienes escriben funciones serverless es 50% mayor que la de quienes escriben código de servicios tradicionales
  • El entorno de desarrollo serverless (IDE) de Meta permite acceder fácilmente a la base de datos del grafo social y a diversos sistemas backend, y ofrece pruebas de integración continua (CI) para permitir retroalimentación rápida
• La plataforma serverless de Meta: FrontFaaS y XFaaS
  • FrontFaaS: funciones serverless de frontend basadas en PHP, ejecutadas en más de 500 mil servidores
    • Mantiene siempre activo el runtime de PHP para procesar solicitudes de inmediato sin problemas de cold start
    • Cuando la carga del servidor es baja, libera automáticamente algunos servidores mediante autoescalado y los aprovecha para otras tareas
  • XFaaS: funciones serverless basadas en eventos que se ejecutan de manera asíncrona
    • Procesa tareas en segundo plano que no requieren respuesta inmediata
    • Para evitar trabajos de alta carga, aplica retraso de ejecución, balanceo de carga global y throttling basado en cuotas
• Innovación serverless de Meta
  • Desde finales de la década de 2000 usa el enfoque serverless como paradigma de desarrollo predeterminado
  • Diferencias frente a las plataformas serverless de nube pública:
    • La nube pública usa una máquina virtual por función para lograr un aislamiento fuerte
    • En cambio, Meta está diseñada para que múltiples funciones puedan ejecutarse simultáneamente dentro de un solo proceso de Linux, maximizando así la eficiencia del hardware

# [Reducción de costos de hardware (Reducing Hardware Costs)]

• La infraestructura compartida de Meta no solo cumple un papel importante para aumentar la productividad de los desarrolladores, sino también para la reducción de costos de hardware
• Para ello, usa una estrategia que aprovecha la optimización de software para maximizar la eficiencia del hardware

Operar todos los centros de datos globales como si fueran una sola computadora (All Global Datacenters as a Computer)

• En los entornos de nube tradicionales, los usuarios tenían que configurar directamente la cantidad de réplicas (replica) del servicio, las regiones de despliegue, etc.
• Este método de gestión manual provocaba problemas como desperdicio de recursos, desequilibrio de carga y falta de migración entre centros de datos
• Meta evolucionó su enfoque existente de operar "el centro de datos como una computadora" (DaaC, Datacenter as a Computer) para implementar Global-DaaC, que opera "los centros de datos de todo el mundo como una sola computadora"
• Características principales de Global-DaaC:
  • Si el usuario simplemente solicita un despliegue global, la infraestructura determina automáticamente la cantidad óptima de réplicas, las regiones de despliegue, el tipo de hardware y el enrutamiento del tráfico
  • Cambia la ubicación de los servicios según sea necesario y puede adaptarse a cambios en la oferta y en la carga
  • A diferencia de la nube pública, Meta opera todas las aplicaciones por cuenta propia, por lo que puede mover cargas de trabajo con mayor flexibilidad
• Método de implementación de Global-DaaC
  • Automatización de la asignación de recursos a nivel global, regional y de servidor individual:
    • Herramienta global de gestión de capacidad: utiliza trazado de RPC para analizar dependencias entre servicios y determina la distribución óptima de capacidad mediante programación entera mixta (MIP)
    • Herramienta regional de gestión de capacidad: asigna recursos de servidor por centro de datos para formar un clúster virtual (Virtual Cluster)
    • Herramienta de gestión de contenedores: coloca contenedores dentro del clúster virtual y los distribuye entre varios centros de datos para garantizar tolerancia a fallas (Fault Tolerance)
    • Técnicas de gestión del kernel: comparten y aíslan adecuadamente los recursos de memoria e I/O entre contenedores
• Casos de aplicación de Global-DaaC
  • Bases de datos y servicios con estado:
    • Cada contenedor aloja varios shards de datos para maximizar la eficiencia
    • Global Service Placer (GSP) determina la cantidad óptima de réplicas de shards y las regiones de ubicación
    • Con base en ello, el framework de sharding asigna los shards a los contenedores y los migra dinámicamente
  • Cargas de trabajo de machine learning (ML):
    • Las tareas de inferencia (Inference) de ML administran réplicas de modelos como si fueran shards de datos
    • El entrenamiento (Training) de ML requiere que los datos y las GPU estén ubicados en el mismo centro de datos
    • Recibe asignación global de capacidad de GPU y el scheduler de entrenamiento de ML realiza la replicación de datos y la colocación de GPU óptimas

Codiseño de hardware y software (Hardware and Software Co-Design)

• Aplicar el codiseño de hardware y software (Co-Design) a nivel de un solo servidor es algo común, pero Meta lo extendió a escala global para superar mediante optimización de software las limitaciones del hardware de bajo costo
• Tolerancia a fallas de bajo costo (Low-Cost Fault Tolerance)
  • Las nubes públicas ofrecen hardware de alta disponibilidad, pero Meta adoptó un enfoque de superar las fallas mediante software para aprovechar hardware más barato
  • Diferencias principales:
    • Los racks de servidores de la nube pública usan fuentes de alimentación duales y switches ToR (Top-of-Rack) duales, mientras que Meta usa una sola fuente de alimentación y un solo switch ToR
    • Las máquinas virtuales (VM) de la nube pública usan almacenamiento en bloques conectado por red, lo que permite la migración en vivo, mientras que los contenedores de Meta usan SSD locales de bajo costo
  • Estrategia de mitigación de fallas basada en software:
    • Herramientas de asignación de recursos: distribuyen los contenedores de los servicios y los shards de datos en distintos dominios de falla dentro del datacenter
    • Protocolos cooperativos: permiten que las aplicaciones intervengan en la gestión del ciclo de vida de los contenedores, para evitar que las réplicas de shards de datos se interrumpan al mismo tiempo
    • Garantía de durabilidad entre múltiples datacenters: está diseñada para mantener el servicio incluso si una región completa queda fuera de servicio, y se realizan pruebas periódicas en condiciones reales para verificar la confiabilidad
• Reducción de costos de proxies de enrutamiento (Eliminating Routing Proxy Costs)
  • Los service mesh tradicionales usan proxies sidecar (Sidecar Proxy) para enrutar solicitudes RPC, pero Meta maneja el 99% de las solicitudes RPC con enrutamiento directo cliente-servidor
  • Con este método se pueden ahorrar alrededor de 100 mil servidores proxy
  • Aun así, existe el reto de compilar y desplegar la librería de enrutamiento en más de 10 mil servicios, pero Meta lo resuelve con sus herramientas de despliegue de software y gestión de configuración
• Almacenamiento por niveles y uso de SSD locales (Tiered Storage and Local SSDs)
  • Diferencia el almacenamiento según la frecuencia de acceso a los datos y los requisitos de latencia para maximizar la eficiencia de costos:
    • Datos calientes (Hot Data): se almacenan en memoria y SSD (ej.: base de datos del grafo social)
    • Datos templados (Warm Data): se almacenan en un sistema de archivos distribuido basado en HDD (ej.: videos, imágenes y datos de logs)
    • Datos fríos (Cold Data): se almacenan en servidores HDD de gran capacidad (ej.: videos antiguos en alta resolución)
      • Se mantienen en modo de bajo consumo para reducir costos
  • Uso de SSD locales:
    • Algunas cargas de trabajo ofrecen mejor rendimiento con SSD locales que con almacenamiento remoto compartido (Remote Storage)
    • Sin embargo, existe el riesgo de que la utilización de los SSD baje por una distribución de carga desequilibrada
    • Meta usa su framework común de sharding para resolver el desequilibrio y maximizar la eficiencia de los SSD

Diseño de hardware propio (In-House Hardware Design)

• Meta diseña internamente sus datacenters, servidores, switches de red y chips de IA para mejorar costos y eficiencia energética
• Como la energía es el recurso más limitado en los datacenters, opera herramientas automatizadas para optimizar el consumo eléctrico
• Reduce costos y consumo eléctrico mediante el codiseño de hardware y software:
  • Optimización del uso de SRAM en chips de IA
  • Eliminación de equipos de refrigeración por compresión en los datacenters
• También desarrolla internamente los switches de red y el software, lo que permite actualizaciones periódicas, y comparte en código abierto la mayoría de sus diseños de hardware a través de Open Compute Project

# [Diseño de sistemas escalables (Designing Scalable Systems)]

• En la infraestructura hiperescalable, el diseño de sistemas escalables es un elemento clave
• Los sistemas distribuidos diseñados para Internet (BGP, BitTorrent, DHT, etc.) tienen gran escalabilidad, pero en entornos de datacenter los controladores centralizados pueden ofrecer mayor escalabilidad y eficiencia

Eliminación de controladores descentralizados (Deprecating Decentralized Controllers)

• Meta eligió avanzar en la transición de controladores descentralizados a controladores centralizados
• Como excepción, los switches de red mantienen BGP, pero están diseñados para que un controlador central pueda reconfigurar rutas cuando haya congestión de tráfico o fallas de enlace
• Los controladores centralizados permiten mejor balanceo de carga y respuesta más rápida ante fallas, por lo que son más adecuados para entornos de datacenter

Casos de transición de sistemas distribuidos existentes a sistemas centralizados

• WAN privada (Private WAN)
  • Antes usaba RSVP-TE (configuración de rutas distribuida), pero se cambió a un sistema basado en controlador central
  • Calcula automáticamente la mejor ruta de tráfico y preconfigura rutas de respaldo cuando ocurre una falla, lo que permite una recuperación rápida
• Almacén de clave-valor (Key-Value Store)
  • Pasó de usar enrutamiento multihop basado en DHT (tabla hash distribuida) a un framework de sharding basado en controlador central
  • El controlador central ajusta dinámicamente la reasignación de shards para optimizar el balanceo de carga
• Distribución de datos a gran escala
  • Antes usaba BitTorrent (descarga P2P distribuida), pero cambió a Owl, el sistema de distribución centralizado de Meta
  • Determina centralmente las rutas de descarga de datos para ofrecer velocidades de descarga mucho más rápidas
• Distribución de metadatos de pequeño tamaño
  • Al principio se usó una estructura de árbol distribuido de 3 niveles (basada en Java), pero se cambió a una estructura de árbol basada en P2P por problemas de escalabilidad
  • Sin embargo, como el rendimiento inestable de algunos nodos degradaba el rendimiento total, finalmente se volvió a una arquitectura de servidores proxy centralizados de alto rendimiento basada en C++

Caso de estudio: service mesh escalable (Scalable Service Mesh)

Meta opera su propio service mesh llamado ServiceRouter,
y con este sistema demuestra la efectividad de una arquitectura centralizada escalable.

• Problemas de la arquitectura tradicional de service mesh
  • Un service mesh típico hace que cada proceso de servicio enrute solicitudes RPC a través de un proxy sidecar L7 (Sidecar Proxy)
  • Pero en un entorno hiperescalable es ineficiente que un controlador central administre directamente millones de proxies sidecar
  • Meta reemplazó el enfoque de proxy sidecar por una estructura en la que el propio servicio maneja el enrutamiento
• Arquitectura de ServiceRouter de Meta
  • Los metadatos de enrutamiento se generan en el controlador central, pero cada router L7 construye por su cuenta sus tablas de enrutamiento
  • Usa una base de datos basada en Paxos (RIB, Routing Information Base) para asegurar escalabilidad
    • Shardear los controladores permite distribuir la carga, y varios controladores pueden calcular en paralelo las tablas de enrutamiento de un servicio específico
  • La capa de distribución (Distribution Layer) aprovecha miles de réplicas de RIB para atender solicitudes de lectura desde millones de routers L7
  • Al final, cada router L7 puede configurarse de forma independiente sin intervención directa del controlador central
• Cómo ServiceRouter logra escalabilidad
  1. Adopción de controladores sin estado (Stateless): el controlador no administra directamente routers específicos, sino que simplemente mantiene información global de enrutamiento
  2. Sharding de controladores: varios controladores operan de forma independiente y pueden procesar en paralelo la información de enrutamiento de distintos servicios
  3. Eliminación de funciones no esenciales: se quitó del controlador la gestión de routers L7 individuales y se diseñó para que cada router se administre por sí mismo
• Resultados y lecciones
  • Una arquitectura que combina controladores centralizados y un data plane distribuido ofrece la escalabilidad óptima
  • Eliminar proxies sidecar innecesarios optimiza tanto los costos operativos como el rendimiento
  • Con un diseño estratégico de sharding y controladores sin estado, es posible gestionar eficazmente el enrutamiento de millones de servicios

# [Perspectivas futuras (Future Directions)]

• La infraestructura hiperescalable de Meta es muy compleja, pero este documento ofrece un resumen de los principales insights técnicos
• Por último, comparte una perspectiva sobre las tendencias futuras de la infraestructura hiperescalable

AI (Inteligencia Artificial)

• Las cargas de trabajo de AI se han convertido en la actualidad en las cargas de trabajo más grandes dentro de los centros de datos
• Se espera que antes de 2030 más de la mitad del consumo eléctrico de los centros de datos se destine a cargas de trabajo de AI
• AI tiene un gran potencial de transformar de raíz las estructuras de infraestructura existentes debido a sus redes de alto rendimiento y alto consumo de recursos
• En el pasado, la infraestructura hiperescalable ha evolucionado con un enfoque de scale-out (despliegue masivo de servidores de bajo costo), pero
  es muy probable que los clústeres de AI del futuro cambien hacia un enfoque de scale-up (arquitectura de supercomputadora)
  • Ejemplo: optimización para entrenamiento de machine learning (ML) a gran escala mediante el uso de redes Ethernet basadas en RDMA (Remote Direct Memory Access)
• Meta está llevando a cabo un co-diseño full-stack que abarca desde PyTorch → modelos de ML → chips de AI → red → centro de datos → servidor → almacenamiento → energía y enfriamiento

Hardware específico por dominio (Domain-Specific Hardware)

• En los años 2000, el hardware se fue estandarizando cada vez más, pero
  de cara al futuro, se prevé un aumento de hardware especializado para entrenamiento/inferencia de AI, virtualización, codificación de video, cifrado, compresión, memoria jerárquica y más
• Las empresas hiperescalables pueden diseñar y desplegar hardware personalizado de forma económicamente viable gracias a la producción a gran escala
• Sin embargo, este aumento en la diversidad de hardware hará crecer la complejidad del stack de software y generará desafíos para gestionar entornos heterogéneos

Centros de datos edge (Edge Datacenters)

• Debido al crecimiento de las aplicaciones del metaverso (Metaverse) y del Internet de las cosas (IoT), se espera una expansión de los centros de datos edge
• El cloud gaming realiza el renderizado gráfico en servidores GPU de centros de datos edge, no en el dispositivo del usuario, y
  requiere de forma indispensable una latencia de red baja, de 25 ms o menos
• A medida que aumenten las aplicaciones donde la respuesta en tiempo real es crítica, es muy probable que la cantidad y la escala de los centros de datos edge crezcan de manera importante
• Para operarlos de forma eficaz, será necesario ampliar Global-DaaC (el concepto de operar centros de datos de todo el mundo como si fueran una sola computadora) y optimizarlo para que los desarrolladores no tengan que preocuparse por la gestión compleja de la infraestructura

Mejora de la productividad de los desarrolladores (Developer Productivity)

• Durante los últimos 20 años, las herramientas de automatización han mejorado enormemente la productividad de los administradores de sistemas, haciendo que aumente drásticamente la proporción de servidores a cargo de cada administrador
• Sin embargo, el desarrollo de software sigue siendo intensivo en mano de obra y su mejora de productividad ha sido relativamente lenta
• De cara al futuro, se espera un fuerte aumento en la productividad de los desarrolladores debido a dos factores:
  1. Desarrollo de herramientas de generación y depuración de código basadas en AI
  2. Aparición de paradigmas de programación serverless completamente integrados y específicos por dominio
• FrontFaaS de Meta es un ejemplo de este enfoque de programación serverless, y
  se espera que en el futuro surjan nuevos paradigmas de programación optimizados para industrias específicas (por ejemplo, finanzas, salud, etc.)

Conclusión

• La innovación en infraestructura centrada en AI avanzará rápidamente durante la próxima década
• Las empresas hiperescalables deben contribuir a que toda la comunidad avance más rápido compartiendo sus insights

[secret3056]

Ese PoP sería BGP4 o anycast de TCP, y supongo que no habría forma de que una persona común lo use, ¿verdad..? T_T

[pribess]

No entiendo bien a qué se refiere exactamente la afirmación de que el PoP es BGP4 o TCP anycast, pero si la pregunta es si operan su propio AS, entonces sí.
Normalmente, los servicios multi-región más comunes usan más bien DNS anycast junto con balanceo basado en geolocalización.
No, por ahora no existe; si necesita un PoP multi-región, puede usar otro proveedor.

[GN⁺]

Comentarios en Hacker News

• Después de desarrollar Threads, el equipo de infraestructura recibió solo dos días de aviso para prepararse para el lanzamiento. A la mayoría de las organizaciones grandes les toma más de dos días solo elaborar un plan de proyecto que involucre a decenas de equipos interdependientes. Sin embargo, en Meta montaron rápidamente salas de guerra en sitios distribuidos para que los equipos de infraestructura y producto resolvieran problemas en tiempo real. La app alcanzó 100 millones de usuarios en solo 5 días tras su lanzamiento y se convirtió en la app de crecimiento más rápido de la historia

• Es impresionante que mantengan la capacidad de lanzar productos tan rápido. Hace falta mucho esfuerzo para evitar que aumente la burocracia y que el equipo legal u otras áreas creen puertas de aprobación. O bien hace falta la capacidad de usar salas de guerra para sacar el trabajo rápidamente

• Cuando estaba en FB, experimenté de primera mano lo potente que era la infraestructura. Los ingenieros de producto construían proyectos de gran escala en cuestión de días. Trabajé como líder técnico en varios equipos, y algunos de los equipos mencionados aquí son HBase y ZippyDB

• Qué bueno que ZippyDB se mencione públicamente por primera vez. También es genial que se hable de mejoras en la eficiencia de los desarrolladores. Cada día se hacen push a 10,000 servicios o se integran todos los commits

• Después de irme de FB, no pude encontrar nada parecido. Por eso, en mi startup estoy construyendo la infraestructura que necesitaba. Batteries Included

• Me da pena ver tanto cinismo y tantas reacciones negativas en estos comentarios. A mucha gente no le gusta Meta, pero el artículo en sí me parece asombroso. No sabía cuán amplia y compleja es la infraestructura que sostiene el mundo digital moderno. Leer este artículo y ver esa escala es impresionante

• La empresa puede ser mala en muchos sentidos, pero todo lo que aparece en el artículo me parece asombroso

• No soy ingeniero como ustedes, así que tal vez este artículo para ustedes sea noticia vieja, pero yo no podía evitar decir "wow"

• Si les mostraran este artículo a los escritores de ciencia ficción del pasado, creo que ellos también se maravillarían

• Asombroso. Toda esta tecnología increíble e impresionante y los mejores ingenieros del mundo se usan solo para poner más anuncios frente a los ojos de la gente. Suspiro

• Es interesante describir el frontend web en PHP como una arquitectura "serverless" o de "funciones como servicio". Parece una cuestión de perspectiva. Es un servicio con una sola base de código donde se despliegan muchos endpoints. Desde la perspectiva del responsable de mantener un endpoint, puede ser "serverless", pero como en toda abstracción, hay fugas

• En entornos de centros de datos, prefiero los controladores centralizados por su simplicidad y por la capacidad de tomar decisiones de alta calidad. En muchos casos, un enfoque híbrido que combine un plano de control centralizado con un plano de datos distribuido es lo más óptimo

• Este enfoque parece ser uno de los diseños más óptimos para redes definidas por software (service mesh) y almacenamiento (operación de bases de datos) en organizaciones con grandes cantidades de servidores. Sorprende que el networking IP siga un modelo parecido sin depender principalmente de BGP

• Esperaría que usen caché local para reducir la carga de los routers L7 y mejorar la latencia de las consultas a la base de datos. Los clientes pueden invalidar la caché y volver a consultar al service mesh después de un tiempo de espera razonable

• La combinación de funciones serverless desarrolladas rápidamente con despliegue continuo, donde cualquiera puede editar toda la base de código, suena como una pesadilla distópica. La cantidad de logging necesaria para depurar y encontrar bugs debe ser extrema

• Usar Erlang para escribir funciones serverless parece evitar todas las grandes ventajas que puede ofrecer BEAM

• Los ingenieros de producto escriben su código principalmente como funciones serverless sin estado en PHP, Python y Erlang. Eso tiene ventajas en simplicidad, productividad y velocidad de iteración

• Para aumentar la productividad de los desarrolladores, Meta adoptó universalmente el despliegue continuo y permite que más desarrolladores escriban funciones serverless en lugar de código de servicio tradicional

• Para cargas de cómputo no relacionadas con IA, ofrecen solo un tipo de servidor, con un solo CPU y la misma cantidad de DRAM (antes 64 GB, ahora 256 GB). Me pregunto si esto es común en toda la industria o solo en Meta

• Cuando una imagen no está en caché en CDN109 y un usuario la solicita, CDN109 reenvía la solicitud a un PoP cercano. El PoP envía la solicitud al balanceador de carga de la región del centro de datos, y el balanceador obtiene la imagen del sistema de almacenamiento

• Al solicitar una imagen de 1 MB, ¿no sería más rápido servir esa imagen de 1 MB con una latencia de 100 ms en una conexión lenta que pasar por múltiples viajes de ida y vuelta con una latencia cada vez mayor?

• Asumiendo que la solicitud pasa por el sistema de Meta, al final llega al mismo centro de datos y asumiendo que no existe tecnología FTL

• La comparación explícita con los hyperscalers es especialmente interesante. Me pregunto si se están preparando para lanzar su propia nube pública. Ojalá alguien de Meta comentara al respecto