Meta के hyperscale infrastructure का अवलोकन और insights

(cacm.acm.org)

22 पॉइंट द्वारा GN⁺ 2025-02-12 | 3 टिप्पणियां | WhatsApp पर शेयर करें

Meta की engineering culture तेज execution, technology openness, production environment में research, और shared infrastructure पर ज़ोर देती है
डेवलपर productivity बढ़ाने के लिए continuous deployment अपनाया गया है, और अधिक डेवलपर्स पारंपरिक service code की जगह serverless functions लिख सकें, यह सक्षम किया गया है
hardware cost घटाने के लिए data center scale पर hardware-software co-design का उपयोग किया जाता है, और resources का allocation अलग-अलग cluster तक सीमित रखने के बजाय दुनिया भर के data centers के बीच अपने-आप optimize किया जाता है
Meta की AI strategy में PyTorch से लेकर AI accelerators, network, और Llama जैसे ML models तक पूरे stack का co-design शामिल है

# [Engineering Culture]

तेज execution (Move Fast)

Meta agility और fast iteration पर ज़ोर देने वाली "तेज execution" culture को बनाए रखता है
यह नवीनतम code को जितनी जल्दी हो सके production में deploy करने वाले continuous deployment का मज़बूती से समर्थन करता है
product engineers PHP, Python, Erlang जैसी भाषाओं का उपयोग करके stateless serverless functions लिखते हैं
लंबी planning process के बिना भी priorities बदली जा सकती हैं, और iterative execution के ज़रिए अनिश्चित समस्याओं को हल किया जाता है
यह तरीका तेज़ market response और products को जल्दी launch करने में सक्षम बनाता है

Technology Openness

आंतरिक openness: monorepo approach का उपयोग करके सभी projects का code एक ही repository में रखा जाता है
- इससे code search, reuse, और teams के बीच collaboration आसान हो जाता है
- अधिकांश projects में कड़ी code ownership restrictions नहीं होतीं, इसलिए डेवलपर्स स्वतंत्र रूप से योगदान दे सकते हैं
बाहरी openness: open source hardware और software projects को सक्रिय रूप से साझा किया जाता है
- Open Compute Project के माध्यम से hardware designs सार्वजनिक किए जाते हैं
- PyTorch, Llama, Presto, RocksDB, Cassandra जैसे विभिन्न open source software projects संचालित किए जाते हैं
- research papers के माध्यम से infrastructure technologies साझा की जाती हैं

Production में Research

Meta समर्पित systems research lab के बिना वास्तविक operating environment में research करता है
production systems विकसित करने वाली teams स्वयं research papers लिखती हैं, ताकि वास्तविक समस्याओं को हल किया जा सके और बड़े पैमाने के operating environment में validated solutions दिए जा सकें
यह approach व्यावहारिक है और सफल systems research के मुख्य मानकों को पूरा करती है

Common Infrastructure

अलग-अलग teams को स्वतंत्र रूप से tech stack चुनने देने के बजाय, standardization और global optimization को प्राथमिकता दी जाती है
Hardware:
- सभी servers shared server pool से allocate किए जाते हैं
- non-AI computing workloads के लिए एक ही server type (मूल रूप से 1 CPU, 256GB DRAM) दिया जाता है, जिससे server types की complexity कम होती है
Software:
- पहले Cassandra, HBase, ZippyDB जैसे कई key-value stores उपयोग किए जाते थे, लेकिन अब ZippyDB में consolidate कर दिए गए हैं
- software deployment, configuration management, service mesh, performance testing आदि को common tools में integrate किया गया है
reusable components को प्राथमिकता:
- Tectonic file system → ZippyDB (metadata storage) → Shard Manager (data sharding management) → ServiceRouter (shard lookup और request routing) → Delos (high-reliability data store) से बनी component reuse chain तैयार की गई है
- HDFS जैसे monolithic systems के बजाय modular reusable components का उपयोग करके scalability को अधिकतम किया जाता है

Culture Case Study: Threads App Development

Threads app development case Meta की engineering culture को अच्छी तरह दिखाता है
केवल 5 महीनों में technical work पूरा किया गया, और 2 दिन पहले advance notice मिलने के बाद infrastructure team ने production deployment की तैयारी पूरी कर ली
अधिकांश बड़ी कंपनियों में दो दिनों में project plan लिखना भी मुश्किल होता है। लेकिन Meta ने real-time problem solving के लिए war room बनाया और तेज़ प्रतिक्रिया दी
नतीजतन, launch के 5 दिनों के भीतर 10 करोड़ users पार, और यह इतिहास का सबसे तेज़ी से बढ़ने वाला app बन गया
Threads मौजूदा infrastructure का reuse करके तेज़ी से scale कर सका:
- Instagram का Python backend
- Meta का shared infrastructure (social graph database, key-value store, serverless platform, ML platform, mobile app configuration management आदि)
आंतरिक openness: monorepo का उपयोग करके Instagram code के कुछ हिस्सों को reuse किया गया, जिससे development speed बढ़ी
बाहरी openness: ActivityPub का उपयोग करके दूसरे apps के साथ interoperability का लक्ष्य रखा गया
development experience sharing: तेज़ development और deployment के अनुभव को सार्वजनिक रूप से साझा किया गया

# [End-to-End User Request Flow]

Meta की infrastructure technologies को गहराई से देखने के लिए, user request के process होने की पूरी प्रक्रिया समझाई गई है
Meta के products को shared service infrastructure support करता है, जिसमें कई core components शामिल हैं

Request Routing

Dynamic DNS Mapping
- जब user facebook.com पर जाता है, तो Meta का DNS server dynamically सबसे नज़दीकी PoP (Point of Presence) का IP address लौटाता है
- PoP छोटे edge data centers होते हैं, जो user के करीब रहकर network load को distribute करते हैं
- PoP, Meta के data centers के साथ long-lived TCP connections बनाए रखते हैं, जिससे TCP connection setup time कम होता है और network performance बेहतर होती है
- दुनिया भर में सैकड़ों PoP तैनात हैं, इसलिए अधिकांश users को कम network latency मिलती है
Static-Content Caching
- images, videos जैसी static content को PoP पर cache किया जाता है और वहीं से सीधे serve किया जा सकता है
- इसके अलावा, Meta CDN (content delivery network) भी चलाता है और ISP (internet service provider) के साथ मिलकर CDN sites बनाता है
- अगर user की request facebook.com/image.jpg है, तो Meta इसे CDN109.meta.com/image.jpg में rewrite करके नज़दीकी CDN site से content serve करता है
- अगर CDN में वह content उपलब्ध नहीं है, तो request PoP → data center load balancer → storage system तक भेजी जाती है
Dynamic-Content Request Routing
- News Feed जैसी dynamic content requests को PoP से data center तक forward किया जाता है
- traffic engineering tools data center capacity और network latency को ध्यान में रखकर सबसे उपयुक्त data center चुनते हैं
- PoP से data center तक का traffic Meta के private WAN (wide area network) के जरिए transmit होता है
- data centers के बीच का traffic user-PoP traffic से कहीं अधिक होता है, क्योंकि इसमें data replication और microservices के बीच interactions शामिल होते हैं

इन्फ्रास्ट्रक्चर टोपोलॉजी (Infrastructure Topology)

Meta का global infrastructure इन्फ्रास्ट्रक्चर components की कई layers से मिलकर बना है
हर component एक खास भूमिका निभाता है, और इन्हें निम्नलिखित scale पर चलाया जाता है:
- डेटासेंटर region (Region): दुनिया भर में लगभग 10 डेटासेंटर region हैं, और हर region में अधिकतम 10 लाख servers चलाए जा सकते हैं
- PoP(Point of Presence, edge डेटासेंटर): 100 से अधिक PoP हैं, और हर PoP में आमतौर पर 100~1,000 servers होते हैं। ये users के करीब traffic process करके latency कम करते हैं
- CDN site: 1,000 से अधिक CDN sites हैं, जिनमें आमतौर पर 10 से अधिक servers होते हैं, और कुछ बड़े sites में 100 से अधिक servers चलते हैं। ये static content (image, video आदि) को cache करके तेज़ी से उपलब्ध कराते हैं
- डेटासेंटर (Datacenter): हर डेटासेंटर region में कई डेटासेंटर होते हैं, और हर डेटासेंटर में लगभग 1 लाख से अधिक servers चलाए जा सकते हैं
- MSB(मेन स्विचबोर्ड, Main Switchboard): एक डेटासेंटर के भीतर अधिकतम 12 MSB हो सकते हैं, और हर MSB 10,000~20,000 servers को संभालता है। यह power distribution का काम करता है और डेटासेंटर के भीतर एक प्रमुख failure domain की तरह काम करता है। यदि MSB fail हो जाए, तो अधिकतम 20,000 servers down हो सकते हैं
edge network:
- PoP कई internet autonomous systems (AS) से जुड़े होते हैं, और BGP(Border Gateway Protocol) का उपयोग करके सबसे बेहतर route चुना जाता है
डेटासेंटर network:
- servers 3-tier Clos topology का उपयोग करके जुड़े होते हैं
- इसे network congestion रोकने और servers के बीच अधिकतम bandwidth देने के लिए design किया गया है
regional network:
- डेटासेंटर fabric aggregators से जुड़े होते हैं, जिससे वे WAN के साथ communicate कर सकें
- Fat-Tree topology का उपयोग किया जाता है ताकि इसे क्रमिक रूप से scale किया जा सके

request processing

online processing
- user requests को load balancer के ज़रिए दसियों हज़ार serverless frontend functions (FrontFaaS) में distribute किया जाता है
- frontend functions कई backend services को call कर सकते हैं, और ML inference services (जैसे ad recommendation, News Feed content recommendation) को भी call कर सकते हैं
- execution के दौरान frontend functions event queue में events जोड़ते हैं, ताकि event-driven serverless functions (XFaaS) asynchronous तरीके से चल सकें
- frontend functions और event-driven functions का server ratio लगभग 5:1 रखा जाता है
offline processing
- offline processing system online system को support करता है, और data analysis तथा machine learning training करता है
- frontend functions और backend services विभिन्न log data को data warehouse में store करते हैं
  - ML training: log data का उपयोग करके machine learning models को update किया जाता है
  - stream processing: site में सबसे ज़्यादा चर्चा वाले topics को update करके database और cache में store किया जाता है
  - batch analysis: Spark और Presto का उपयोग करके friend recommendation system को update किया जाता है
  - event-driven serverless function execution: data updates event trigger की तरह काम करते हैं, जिससे serverless functions अपने-आप चल जाते हैं

# [डेवलपर productivity बढ़ाना (Boosting Developer Productivity)]

Meta का shared infrastructure डेवलपर productivity को अधिकतम करने पर केंद्रित है
इसके लिए यह continuous deployment और serverless functions का चरम स्तर तक उपयोग कर रहा है

continuous deployment

Meta को code और configuration changes को तेज़ी से deploy करने के लिए optimize किया गया है
नए features और bug fixes को तुरंत deploy किया जा सकता है, जिससे तेज़ feedback और iterative improvement संभव होता है
configuration changes
- Meta का configuration management tool हर दिन 1 लाख से अधिक real-time changes को production में deploy करता है
- 10,000 से अधिक services और लाखों servers में configuration अपने-आप update हो जाता है
- load balancing, feature rollout, A/B testing, overload prevention जैसे कई काम अपने-आप किए जाते हैं
- configuration changes को code changes की तरह review करके code repository में commit किया जाता है, और ये changes कुछ ही seconds में पूरे system में propagate हो जाते हैं
code changes
- Meta का deployment tool 30,000 से अधिक deployment pipelines चलाकर software updates को manage करता है
- 97% services ने fully automated deployment अपनाया है, इसलिए updates बिना manual intervention के किए जाते हैं:
  - 55% full continuous deployment (CD) का उपयोग करती हैं, जिसमें code changes अपने-आप production में लागू हो जाते हैं
  - 42% एक तय schedule (daily या weekly) पर automatically deploy की जाती हैं
- frontend serverless functions (FrontFaaS) 5 लाख से अधिक servers पर चलते हैं, और 10,000 से अधिक developers हर दिन हज़ारों code commits करते हैं
- इतने dynamic environment में भी सभी serverless functions का नया version हर 3 घंटे में production में deploy कर दिया जाता है
network और infrastructure software updates
- Meta का private WAN कई parallel network planes बनाए रखता है, जिससे नए network algorithms को independent तरीके से test किया जा सकता है
- network switch software भी बार-बार update किया जाता है, और switch की "Warm Boot" feature का उपयोग करके network traffic रोके बिना software update किया जा सकता है
- बार-बार होने वाले code और configuration updates site outage का जोखिम बढ़ाते हैं, इसलिए Meta testing, staged rollout, और health checks में काफ़ी निवेश करता है
  - code deployment automation को 12% से 97% तक बढ़ाने के लिए internal campaign चलाया गया
  - सभी configuration changes के लिए automated Canary tests किए जाते हैं ताकि stability सुनिश्चित की जा सके

Serverless functions

Serverless functions (या FaaS, Function-as-a-Service) डेवलपर productivity बढ़ाने वाला एक और प्रमुख तत्व हैं
पारंपरिक backend services के विपरीत, serverless functions state store नहीं करते और एक simple function interface implement करते हैं
हर function call स्वतंत्र रूप से चलता है, और state को manage करने के लिए external database या cache system का उपयोग करता है
Serverless functions के फायदे
- डेवलपर्स को infrastructure manage किए बिना केवल product logic लिखना होता है
- code deployment और load में बदलाव के अनुसार auto-scaling अपने-आप होता है
- hardware waste को रोकता है, और डेवलपर्स को जरूरत से ज़्यादा resources allocate नहीं करने पड़ते
Meta का serverless platform
- Meta के 10,000 से अधिक developers में, serverless functions लिखने वाले developers की संख्या पारंपरिक service code लिखने वालों से 50% अधिक है
- Meta का serverless development environment (IDE) social graph database और कई backend systems तक आसान access देता है, और continuous integration testing (CI) उपलब्ध कराकर तेज़ feedback संभव बनाता है
Meta का serverless platform: FrontFaaS और XFaaS
- FrontFaaS: PHP-आधारित frontend serverless functions, जो 5 लाख से अधिक servers पर चलते हैं
  - हमेशा PHP runtime को चालू रखता है, इसलिए cold start की समस्या के बिना requests को तुरंत process किया जा सकता है
  - जब server load कम होता है, तो auto-scaling के ज़रिए कुछ servers को मुक्त कर दूसरे कामों में इस्तेमाल किया जाता है
- XFaaS: asynchronously चलने वाले event-based serverless functions
  - यह background tasks को process करता है जिन्हें तत्काल response की ज़रूरत नहीं होती
  - उच्च load वाले tasks से बचने के लिए execution को delay करना, global load balancing, और quota-based throttling लागू की जाती है
Meta का serverless innovation
- 2000 के दशक के उत्तरार्ध से serverless approach को default development paradigm के रूप में इस्तेमाल किया जा रहा है
- public cloud के serverless platforms से अंतर:
  - public cloud मजबूत isolation के लिए हर function के लिए एक virtual machine का उपयोग करता है
  - इसके विपरीत, Meta एक Linux process में कई functions को एक साथ चलने देने के लिए design करता है, ताकि hardware efficiency अधिकतम हो

# [हार्डवेयर लागत में कमी (Reducing Hardware Costs)]

Meta का shared infrastructure सिर्फ developer productivity बढ़ाने में ही नहीं, बल्कि hardware costs कम करने में भी अहम भूमिका निभाता है
इसके लिए software optimization का उपयोग करके hardware efficiency को अधिकतम करने की strategy अपनाई जाती है

सभी global datacenters को एक कंप्यूटर की तरह चलाना (All Global Datacenters as a Computer)

पारंपरिक cloud environments में users को खुद service replicas की संख्या, deployment regions आदि सेट करने पड़ते थे
इस तरह की manual management से resource waste, load imbalance, और datacenters के बीच migration की कमी जैसी समस्याएँ पैदा होती थीं
Meta ने "datacenter को एक computer की तरह चलाने" वाले मौजूदा approach (DaaC, Datacenter as a Computer) को आगे बढ़ाकर, "दुनिया भर के datacenters को एक computer की तरह चलाने" वाला Global-DaaC लागू किया
Global-DaaC की मुख्य विशेषताएँ:
- user सिर्फ global deployment request देता है, और infrastructure अपने-आप replicas की optimal संख्या, deployment region, hardware type, और traffic routing तय करता है
- ज़रूरत पड़ने पर services की location बदली जा सकती है, और supply तथा load में बदलाव के अनुसार अनुकूलन संभव है
- public cloud के विपरीत, Meta सभी applications को खुद operate करता है, इसलिए workloads को अधिक लचीले ढंग से move किया जा सकता है
Global-DaaC का implementation
- global, regional, और individual server स्तर पर resource allocation को automate करना:
  - global capacity management tools: RPC tracing का उपयोग करके services के बीच dependencies का विश्लेषण करते हैं, और mixed integer programming (MIP) के माध्यम से optimal capacity allocation तय करते हैं
  - regional capacity management tools: datacenter-वार server resources allocate करके virtual clusters बनाते हैं
  - container management tools: virtual cluster के भीतर containers को place करते हैं, और कई datacenters में distribute करके fault tolerance सुनिश्चित करते हैं
  - kernel management techniques: containers के बीच memory और I/O resources को उचित रूप से share और isolate करती हैं
Global-DaaC के उपयोग के उदाहरण
- database और stateful services:
  - हर container कई data shards host करता है ताकि efficiency अधिकतम हो
  - Global Service Placer(GSP) shards के replicas की optimal संख्या और placement region तय करता है
  - sharding framework इसी आधार पर shards को containers में allocate करता है और dynamically migrate करता है
- machine learning (ML) workloads:
  - ML inference tasks model replicas को data shards की तरह manage करते हैं
  - ML training में data और GPU का एक ही datacenter में placed होना ज़रूरी है
  - global GPU capacity allocation मिलने के बाद, ML training scheduler optimal data replication और GPU placement को execute करता है

हार्डवेयर-सॉफ्टवेयर को-डिज़ाइन (Hardware and Software Co-Design)

सिंगल सर्वर स्तर पर हार्डवेयर-सॉफ्टवेयर को-डिज़ाइन (Co-Design) लागू करना आम है, लेकिन Meta ने इसे वैश्विक स्तर तक विस्तार दिया और कम-लागत हार्डवेयर की सीमाओं को सॉफ्टवेयर ऑप्टिमाइज़ेशन के जरिए पार किया
कम-लागत fault tolerance (Low-Cost Fault Tolerance)
- पब्लिक क्लाउड उच्च उपलब्धता वाला हार्डवेयर प्रदान करते हैं, लेकिन Meta ने सॉफ्टवेयर के जरिए failures को संभालने का तरीका अपनाकर और सस्ता हार्डवेयर इस्तेमाल किया
- मुख्य अंतर:
  - पब्लिक क्लाउड के server rack में dual power supply और dual ToR (Top-of-Rack) switch का उपयोग होता है, जबकि Meta single power और single ToR switch का उपयोग करता है
  - पब्लिक क्लाउड के virtual machine (VM) network-connected block storage का उपयोग करते हैं, जिससे live migration संभव होती है, जबकि Meta के containers कम-लागत local SSD का उपयोग करते हैं
- सॉफ्टवेयर-आधारित failure recovery रणनीतियाँ:
  - resource allocation tools: services के containers और data shards को डेटासेंटर के भीतर अलग-अलग failure domains में वितरित करते हैं
  - cooperative protocols: applications को container lifecycle management में हस्तक्षेप करने देते हैं, ताकि data shard replicas एक साथ बंद न हों
  - multi-datacenter durability assurance: पूरे region के बंद हो जाने पर भी service चालू रहे, इस तरह डिज़ाइन किया गया है, और विश्वसनीयता की पुष्टि के लिए नियमित रूप से वास्तविक परीक्षण किए जाते हैं
रूटिंग proxy लागत में कमी (Eliminating Routing Proxy Costs)
- पारंपरिक service mesh sidecar proxy का उपयोग करके RPC requests को route करता है, लेकिन Meta 99% RPC requests को सीधे client-server routing से संभालता है
- इस तरीके से लगभग 1 लाख proxy servers की बचत की जा सकती है
- हालांकि, routing library को 10,000 से अधिक services में compile और deploy करना एक चुनौती है, लेकिन Meta ने इसे software deployment और configuration management tools के जरिए हल किया
tiered storage और local SSD का उपयोग (Tiered Storage and Local SSDs)
- data access frequency और latency requirements के अनुसार storage को विभाजित करके लागत दक्षता को अधिकतम किया जाता है:
  - hot data: memory और SSD में स्टोर (उदा.: social graph database)
  - warm data: HDD-आधारित distributed file system में स्टोर (उदा.: video, image, log data)
  - cold data: बड़े HDD servers में स्टोर (उदा.: पुराने high-resolution videos)
    - low-power mode में रखकर लागत कम की जाती है
- local SSD का उपयोग:
  - कुछ workloads में shared remote storage की तुलना में local SSD बेहतर performance देता है
  - लेकिन, असंतुलित load distribution के कारण SSD utilization कम होने का जोखिम रहता है
  - Meta के common sharding framework का उपयोग करके इस असंतुलन को हल किया जाता है और SSD efficiency को अधिकतम किया जाता है

इन-हाउस हार्डवेयर डिज़ाइन (In-House Hardware Design)

Meta लागत और power efficiency के लिए datacenter, server, network switch और AI chips खुद डिज़ाइन करता है
power datacenter का सबसे सीमित resource है, इसलिए power usage को optimize करने वाले automation tools चलाए जाते हैं
हार्डवेयर-सॉफ्टवेयर को-डिज़ाइन के जरिए लागत और बिजली की खपत में कमी:
- AI chips में SRAM usage optimization
- datacenter में compression cooling equipment को हटाना
network switches और software भी खुद विकसित किए जाते हैं, जिससे नियमित updates संभव होते हैं, और अधिकांश hardware designs को Open Compute Project के जरिए open source के रूप में साझा किया जाता है

# [स्केलेबल सिस्टम्स डिज़ाइन करना (Designing Scalable Systems)]

hyperscale infrastructure में स्केलेबल सिस्टम डिज़ाइन एक मुख्य तत्व है
इंटरनेट वातावरण के लिए डिज़ाइन किए गए distributed systems (BGP, BitTorrent, DHT आदि) बेहद scalable हैं, लेकिन datacenter वातावरण में centralized controller अधिक scalability और efficiency दे सकता है

decentralized controllers को समाप्त करना (Deprecating Decentralized Controllers)

Meta ने मौजूदा decentralized controllers से centralized controllers की ओर बदलाव का रास्ता चुना
अपवाद के रूप में network switch BGP को बनाए रखते हैं, लेकिन traffic congestion या link failure होने पर centralized controller routes को फिर से सेट कर सके, इस तरह डिज़ाइन किया गया है
centralized controller बेहतर load balancing और तेज failure response संभव बनाते हैं, और datacenter वातावरण में अधिक उपयुक्त हैं

मौजूदा decentralized systems को centralized में बदलने के उदाहरण

private WAN
- पहले RSVP-TE (decentralized path setup) का उपयोग होता था, लेकिन अब centralized controller-आधारित system में बदला गया
- optimal traffic paths अपने आप calculate किए जाते हैं, और failure होने पर backup paths पहले से सेट रहते हैं, जिससे तेज recovery संभव होती है
key-value store
- पहले के DHT (distributed hash table)-आधारित multi-hop routing से बदलकर centralized controller-आधारित sharding framework अपनाया गया
- centralized controller shard rebalancing को dynamic तरीके से समायोजित कर load balance optimize करता है
बड़े पैमाने पर data distribution
- पहले BitTorrent (decentralized P2P download) का उपयोग होता था, लेकिन इसे Meta के Owl नामक centralized distribution system से बदल दिया गया
- data download paths को केंद्र से तय करके बहुत तेज download speed दी जाती है
छोटे metadata का वितरण
- शुरुआत में 3-tier decentralized tree structure (Java-आधारित) का उपयोग हुआ, लेकिन scalability समस्या के कारण इसे P2P-आधारित tree structure में बदला गया
- लेकिन कुछ nodes के अस्थिर performance ने पूरे system performance को गिराया, इसलिए अंततः high-performance C++-आधारित centralized proxy server architecture पर वापस लौटा गया

केस स्टडी: स्केलेबल service mesh (Scalable Service Mesh)

Meta ServiceRouter नाम का अपना service mesh चलाता है,
और इस system के जरिए स्केलेबल centralized architecture की प्रभावशीलता साबित करता है।

मौजूदा service mesh architecture की समस्याएँ
- सामान्य service mesh में हर service process L7 sidecar proxy के जरिए RPC requests को route करता है
- लेकिन hyperscale वातावरण में centralized controller के लिए लाखों sidecar proxies को सीधे manage करना अक्षम है
- Meta ने sidecar proxy मॉडल के बजाय ऐसा ढाँचा अपनाया जिसमें service खुद routing संभालती है
Meta का ServiceRouter architecture
- routing metadata centralized controller में generate होता है, लेकिन हर L7 router अपनी routing table खुद बनाता है
- Paxos-आधारित database (RIB, Routing Information Base) का उपयोग करके scalability सुनिश्चित की जाती है
  - controller sharding के जरिए load वितरित किया जाता है, और किसी विशेष service की routing table को कई controllers समानांतर रूप से calculate कर सकते हैं
- distribution layer हजारों RIB replicas का उपयोग करके लाखों L7 routers की read requests को संभालती है
- अंततः, हर L7 router centralized controller के सीधे हस्तक्षेप के बिना स्वतंत्र रूप से configure हो सकता है
ServiceRouter की scalability सुनिश्चित करने के तरीके
1. stateless controllers को अपनाना: controller किसी specific router को सीधे manage नहीं करता, बल्कि केवल global routing information बनाए रखता है
2. controller sharding: कई controllers एक-दूसरे से स्वतंत्र रूप से चलते हैं और अलग-अलग services की routing information को parallel में process कर सकते हैं
3. गैर-ज़रूरी features को हटाना: individual L7 router management function को controller से हटाकर ऐसा डिज़ाइन किया गया कि हर router खुद को manage करे
परिणाम और सीख
- centralized controller और decentralized data plane को जोड़ने वाला architecture सबसे बेहतर scalability देता है
- अनावश्यक sidecar proxies को हटाकर operational cost और performance को optimize किया गया
- रणनीतिक sharding और stateless design के जरिए लाखों service routes को प्रभावी ढंग से manage किया जा सकता है

# [भविष्य की दिशा (Future Directions)]

Meta का hyperscale infrastructure बेहद जटिल है, लेकिन इस दस्तावेज़ में मुख्य तकनीकी insights का सार दिया गया है
अंत में, hyperscale infrastructure के future trends पर दृष्टिकोण साझा किया गया है

AI (कृत्रिम बुद्धिमत्ता)

AI workloads अब डेटा सेंटर में सबसे बड़ा हिस्सा रखने वाले workloads बन चुके हैं
अनुमान है कि 2030 से पहले डेटा सेंटर की बिजली खपत का आधे से अधिक हिस्सा AI workloads पर इस्तेमाल होगा
AI में high-performance network और ऊँचे resource consumption के कारण मौजूदा infrastructure architecture को बुनियादी रूप से बदल देने की बड़ी संभावना है
पहले hyperscale infrastructure scale-out तरीके (कम लागत वाले सर्वरों की बड़े पैमाने पर तैनाती) से विकसित हुआ था, लेकिन
भविष्य के AI clusters के scale-up तरीके (supercomputer architecture) की ओर बदलने की संभावना अधिक है
- उदाहरण: RDMA(Remote Direct Memory Access) आधारित Ethernet network का उपयोग करके बड़े पैमाने की machine learning (ML) training के लिए optimization
Meta PyTorch → ML model → AI chip → network → data center → server → storage → power और cooling तक शामिल full-stack co-design पर काम कर रहा है

Domain-Specific Hardware

2000 के दशक में hardware लगातार अधिक standardized हुआ, लेकिन
आगे AI training/inference, virtualization, video encoding, encryption, compression, hierarchical memory आदि के लिए विभिन्न specialized hardware बढ़ने की संभावना है
hyperscale कंपनियाँ बड़े पैमाने पर उत्पादन के जरिए custom hardware को आर्थिक रूप से design और deploy कर सकती हैं
लेकिन, hardware diversity बढ़ने से software stack की complexity भी बढ़ेगी, और heterogeneous environments को manage करना एक चुनौती बनेगा

Edge Datacenters

Metaverse और Internet of Things (IoT) applications में वृद्धि के कारण edge datacenters के विस्तार की संभावना है
Cloud Gaming में graphics rendering उपयोगकर्ता के device पर नहीं बल्कि edge datacenter के GPU servers पर की जाती है, और
25ms से कम low network latency अनिवार्य है
real-time responsiveness महत्वपूर्ण होने वाले applications के बढ़ने से edge datacenters की संख्या और scale दोनों में बड़ी वृद्धि हो सकती है
इसे प्रभावी ढंग से चलाने के लिए, Global-DaaC (दुनिया भर के data centers को एक कंप्यूटर की तरह चलाने की अवधारणा) का विस्तार कर developers को जटिल infrastructure management की चिंता से मुक्त करने के लिए optimization की आवश्यकता है

Developer Productivity में सुधार

पिछले 20 वर्षों में automation tools ने system administrators की productivity को काफी बढ़ाया है, जिससे प्रति server एक administrator द्वारा संभाले जाने वाले servers का अनुपात तेज़ी से बढ़ा है
लेकिन, software development अब भी श्रम-प्रधान है और productivity improvement अपेक्षाकृत धीमा है
आगे चलकर दो कारणों से developer productivity में तेज़ बढ़ोतरी होने की संभावना है:
1. AI आधारित code generation और debugging tools का विकास
2. domain-specific, fully integrated serverless programming paradigm का आगमन
Meta का FrontFaaS इस तरह की serverless programming का एक उदाहरण है, और
भविष्य में विशेष उद्योगों (जैसे finance, healthcare आदि) के लिए optimized नए programming paradigms आने की संभावना है

निष्कर्ष

AI-केंद्रित infrastructure innovation अगले 10 वर्षों में तेज़ी से आगे बढ़ेगा
hyperscale कंपनियों को अपने insights साझा करके पूरे community को तेज़ी से आगे बढ़ने में योगदान देना चाहिए

3 टिप्पणियां

secret3056 2025-02-13

वो PoP शायद BGP4 या TCP anycast है, और उसे कोई व्यक्ति निजी तौर पर इस्तेमाल करने का तरीका तो नहीं होगा, है न..? T_T

pribess 2025-02-13

मुझे ठीक-ठीक समझ नहीं आ रहा कि PoP को BGP4 या TCP anycast कहना वास्तव में किस अर्थ में कहा गया है, लेकिन अगर सवाल यह है कि क्या वे अपना खुद का AS चलाते हैं, तो हाँ।
आम तौर पर सामान्य multi-region services geolocation based balancing के साथ anycast DNS का ज़्यादा इस्तेमाल करती हैं।
हाँ, फिलहाल ऐसा नहीं है। अगर आपको multi-region PoP चाहिए, तो आप किसी दूसरे provider का उपयोग कर सकते हैं।

GN⁺ 2025-02-12

Hacker News राय

Threads के development के बाद, infra टीम को launch की तैयारी के लिए सिर्फ दो दिन की सूचना मिली। ज़्यादातर बड़े organizations को तो दर्जनों interdependent टीमों वाले project plan लिखने में ही दो दिन से ज़्यादा लग जाते हैं। लेकिन Meta में distributed sites पर जल्दी से war room बनाए गए ताकि infra और product टीमें real time में समस्याएँ हल कर सकें। यह app launch के सिर्फ 5 दिनों में 10 करोड़ users तक पहुँच गया और इतिहास का सबसे तेज़ी से बढ़ने वाला app बन गया
products को तेज़ी से launch करने की क्षमता बनाए रखना प्रभावशाली है। इसके लिए बहुत मेहनत चाहिए ताकि bureaucracy न बढ़े, और legal टीम या दूसरे विभाग approval gate न बना दें। या फिर war room के ज़रिए तेज़ी से काम पूरा करने की क्षमता चाहिए
जब मैं FB में था, तब मैंने firsthand देखा कि infra कितना मज़बूत है। product engineers कुछ ही दिनों में बड़े पैमाने के projects बना लेते थे। मैंने कई टीमों में tech lead के रूप में काम किया, और यहाँ जिन टीमों का ज़िक्र है उनमें HBase और ZippyDB टीमें भी शामिल हैं
यह अच्छा लगा कि ZippyDB का पहली बार सार्वजनिक रूप से ज़िक्र हुआ। developer efficiency में सुधार का ज़िक्र होना भी बहुत अच्छा लगा। हर दिन 10,000 services push होती हैं या सभी commits हो जाते हैं
FB छोड़ने के बाद मुझे ऐसा कुछ नहीं मिला। इसलिए startup के रूप में मैं वही infra बना रहा हूँ जिसकी मुझे ज़रूरत थी। Batteries Included
यह देखकर अफ़सोस होता है कि इन comments में इतना cynicism और negativity है। बहुत लोग Meta को नापसंद करते हैं, लेकिन असली article मेरे लिए विस्मयकारी था। मुझे पता नहीं था कि आधुनिक digital दुनिया को संभालने वाला infra कितना व्यापक और जटिल है। इस article को पढ़कर उसका scale देखना चौंकाने वाला है
company कई मायनों में बुरी हो सकती है, लेकिन article में जो कुछ भी आया है वह सब मेरे लिए हैरान करने वाला है
मैं आप लोगों जैसा engineer नहीं हूँ, इसलिए यह article शायद आपके लिए पुरानी खबर हो, लेकिन मैं "वाह" कहे बिना नहीं रह सका
अगर यह article पुराने ज़माने के sci-fi writers को दिखाया जाए, तो शायद वे भी चकित रह जाएँ
हैरानी होती है। यह सारी अद्भुत और प्रभावशाली technology और दुनिया के बेहतरीन engineers सिर्फ लोगों की आँखों के सामने और ज़्यादा ads डालने के लिए इस्तेमाल हो रहे हैं। आह
PHP web frontend को "serverless" या "function as a service" architecture के रूप में बताना दिलचस्प है। लगता है यह perspective का मामला है। यह एक single codebase वाली service है जिसमें कई endpoints deploy किए गए हैं। endpoint maintainers के नज़रिए से यह "serverless" हो सकता है, लेकिन हर abstraction की तरह इसमें भी leakage है
datacenter environment में simplicity और high-quality decision making की वजह से मैं centralized controllers को पसंद करता हूँ। कई मामलों में centralized control plane और distributed data plane को मिलाने वाला hybrid approach सबसे optimal होता है
यह approach बड़ी संख्या में servers वाले organizations के software networking (service mesh) और storage (database operations) के लिए सबसे बेहतर designs में से एक लगती है। यह देखकर हैरानी होती है कि IP networking भी BGP पर मुख्य रूप से निर्भर हुए बिना उसी model का पालन करती है
उम्मीद है कि local caching का इस्तेमाल L7 routers पर load कम करने और database queries की latency सुधारने के लिए किया जाएगा। clients cache invalidate कर सकते हैं और उचित timeout के बाद service mesh में फिर से lookup कर सकते हैं
तेज़ी से develop किए गए serverless functions और continuous deployment का मेल, जहाँ कोई भी पूरे codebase में edit कर सकता है, एक dystopian nightmare जैसा लगता है। debugging और bugs ढूँढने के लिए जिस logging की ज़रूरत होगी उसकी मात्रा बहुत ज़्यादा होगी
serverless functions लिखने के लिए Erlang का इस्तेमाल करना ऐसा लगता है जैसे BEAM के सारे बड़े फायदों से बचा जा रहा हो
product engineers मुख्य रूप से PHP, Python और Erlang में stateless serverless functions के रूप में code लिखते हैं। इससे simplicity, productivity और iteration speed में फ़ायदा होता है
developer productivity बढ़ाने के लिए Meta ने universally continuous deployment अपनाया है, और ज़्यादा developers को traditional service code के बजाय serverless functions लिखने में सक्षम बनाया है
non-AI computing workloads के लिए वे सिर्फ एक ही server type देते हैं, जिसमें एक CPU और DRAM की एक समान मात्रा होती है (पहले 64GB, अब 256GB)। सोच रहा हूँ कि क्या यह पूरे industry में सामान्य है, या सिर्फ Meta में ही आम है
जब image CDN109 में cache नहीं होती, और user request करता है, तो CDN109 request को नज़दीकी PoP तक forward करता है। PoP उस request को datacenter region के load balancer तक भेजता है, और load balancer storage system से image लाता है
जब 1MB image request की जाती है, तो क्या धीमे connection पर 100ms latency के साथ 1MB image serve करना कई बार round trip और बढ़ती latency से गुज़रने की तुलना में तेज़ नहीं होगा?
अगर मानें कि request Meta के systems से होकर जाती है, तो अंत में वह उसी datacenter तक पहुँचती है, और यह भी मानें कि कोई FTL technology नहीं है
hyperscalers के साथ स्पष्ट तुलना खास तौर पर दिलचस्प है। सोच रहा हूँ कि क्या वे अपना public cloud launch करने की तैयारी कर रहे हैं। काश Meta का कोई व्यक्ति इस पर अपनी राय दे