- "Up: Portable Microservices Ready for the Cloud"
- Uber में 4,500 इंजीनियर और अनेक automated systems हर हफ्ते 4,500 Stateless माइक्रोसर्विसेज़ को 4,000 से अधिक बार deploy करते हैं
- ये सेवाएँ दुनिया भर में स्वतंत्र रूप से काम करने वाली सैकड़ों अलग-अलग टीमों द्वारा विकसित, deploy और operate की जाती हैं
- सेवाएँ आकार, रूप और कार्य में बहुत विविध हैं; कुछ छोटी हैं और आंतरिक कार्यों में उपयोग होती हैं, जबकि कुछ बड़ी हैं और बड़े पैमाने की real-time गणनाओं में उपयोग होती हैं
Uber की Stateless सेवाओं का इतिहास
- 2014 में Uber एक Python में लिखे गए monolith का उपयोग करता था और डेटा को एक PostgreSQL DB में स्टोर करता था
- बढ़त के साथ कंपनी ने अधिक इंजीनियर जोड़े और Microservice आर्किटेक्चर की ओर शिफ्ट किया
- सेवाओं की संख्या बढ़ने पर Uber ने µDeploy नाम का एक टूल बनाया, जिससे कोड को केंद्रीय रूप से बड़े पैमाने पर deploy किया जा सके
- इसने सभी Stateless सेवाओं को containerize किया और host management व placement को abstract किया
- इससे infrastructure group, business-unit माइक्रोसर्विसेज़ से स्वतंत्र रूप से host fleet को manage कर सका
- लेकिन service management और placement अब भी manual थे
- Uber का infrastructure, ऐसे मॉडल का अनुसरण करता है जिसमें zones के समूह मिलकर regions बनाते हैं
- एक region के भीतर zones के बीच latency इतनी कम होती है कि उसी region की सेवाओं के बीच synchronous communication प्रभावी रहता है
- प्रत्येक zone या तो Uber के स्वामित्व वाली machines का cluster हो सकता है या किसी public cloud provider का, लेकिन कोई specific zone हमेशा केवल एक ही provider का होता है
- सामान्य रूप से, जब तक सभी माइक्रोसर्विसेज़ एक ही region में हैं, उन्हें latency समस्या के बिना अन्य सेवाओं को call कर पाना चाहिए
- µDeploy में workload का geographic placement सिस्टम में centrally managed नहीं था, क्योंकि इंजीनियरों को अब भी Availability Zone स्तर पर physical placement manage करना पड़ता था
- यानी service engineers को सिर्फ यह नहीं तय करना होता था कि सेवा on-premises zone में चलेगी या नहीं, बल्कि यह भी तय करना होता था कि वह किस specific zone में चलेगी
- on-premises data center चलाते समय chip shortage और supply-chain समस्याओं के कारण lead time लंबा हो गया
- 13 फ़रवरी 2023 को Uber ने supply-chain issues के exposure को कम करने और diversification के लिए Oracle और Google के साथ partnership की
- बिज़नेस को सपोर्ट करने वाली सैकड़ों अलग-अलग सेवाएँ बनाने वाले हजारों Uber इंजीनियरों के लिए, "base infrastructure को abstract कर सकने वाला system" के बिना इस रणनीति को लागू करना असंभव था
Uber को cloud में माइग्रेट करने की तैयारी
- बिज़नेस को जारी रखते हुए 4,500 Stateless सेवाओं को cloud में migrate करने के लिए भारी स्तर के coordination और effort की ज़रूरत थी
- शुरू से ही स्पष्ट था कि यह काम error-prone है और manually coordinated effort से इसे manage करना लगभग असंभव है
- Stateless माइक्रोसर्विसेज़ की maintenance और management को scale पर संभालने के लिए सेवाओं को इस तरह बदलना पड़ा कि वे बिना human intervention के centralized deployment system द्वारा automatically managed हो सकें
- Stateless से आगे, Portability की ओर
- Region और Zone मॉडल के आधार पर Uber ने "Portability" की अवधारणा विकसित की
- Portability का अर्थ है ऐसी सेवा जो region के किसी भी zone में चल सके और जिसे infrastructure platform बिना human intervention के automatically नए zone में move कर सके
- इसमें public cloud providers के बीच move करना ही नहीं, बल्कि on-premises zones के अंदर और बाहर move करना भी शामिल है
- कुछ सेवाएँ zone configuration और zone resources की preference पर निर्भर होने के कारण सामान्य रूप से portable नहीं थीं
- cloud की ओर automated migration करने के लिए सभी सेवाओं का portable होना आवश्यक था
Uber को Portable बनाना
- 2021 और 2022 के दौरान Uber ने engineering-wide program चलाया ताकि यह सुनिश्चित किया जा सके कि सभी सेवाएँ portable हों
- कई मामलों में केवल code inspection के जरिए string constants और file names के उपयोग को देखकर portability violations का पता लगाया जा सकता था
- सरल मामलों के लिए linter rules लिखे गए, जो ऐसे code को highlight करते थे जो किसी specific physical location पर run होने के लिए hardcode किया गया दिखता था
- यह परीक्षण करने के लिए कि सेवा वास्तव में portable है या नहीं, सेवाओं को वास्तव में बिना human intervention के कई zones में move करके देखना पड़ा
- service owners के लिए ऐसा test toolkit बनाया गया जिससे वे अपनी सेवा की पहली move शुरू कर सकें
- यह safe और gradual code rollout के लिए मौजूद tools पर आधारित था, इसलिए service owners किसी भी समय deployment को मूल zone में rollback कर सकते थे और समस्या मिलने पर उसे ठीक कर सकते थे
- move सफलतापूर्वक पूरी होने पर उस सेवा को आगे से automatically move होने के लिए mark कर दिया जाता था
- अगले कुछ वर्षों में Uber ने यह process अपनी सभी सेवाओं पर दोहराई और अंततः सभी सेवाओं के लिए इसे पूरा कर लिया
- काम पूरा होने के बाद service engineers के हस्तक्षेप के बिना zone topology को बदला जा सकता था
- समय के साथ सेवाएँ portable बनी रहें, इसके लिए हर कुछ हफ्तों में सभी सेवाओं को लगातार zones के बीच migrate किया जाता था ताकि move capability का नियमित परीक्षण हो सके
- इससे services में regression का पता लगाना आसान हो गया, और समय के साथ इंजीनियरों को यह मानकर न चलने की आदत हो गई कि उनकी सेवा किसी specific zone placement पर निर्भर है
Up: Multi-Cloud Multi-Tenant Federation Control Plane
- सिस्टम के लिए निम्नलिखित शुरुआती लक्ष्य तय किए गए
- इंजीनियरों को infrastructure system के साथ interaction के लिए एक single point of entry देना
- सिस्टम पर सीधे deploy की गई सेवाओं के लिए best practices को manage और enforce करना, ताकि code rollout के दौरान उच्च स्तर की safety मिले
- Availability Zones के लिए service placement को automate करना; जब नई availability zone उपलब्ध हो तो deployment को नए zone में बदलना, और सामान्य रूप से Uber की high availability को support करने के लिए placements का centralized coordination करना
- मुश्किल infrastructure-level migrations को automate करना ताकि service engineers को migration में शामिल न होना पड़े
- High-level architecture
- Experience Layer:
- इंजीनियरों के सिस्टम के साथ interaction के विभिन्न तरीकों को implement करता है
- UI, Continuous Delivery, और सिस्टम को healthy state में रखने वाले robots आदि
- Balancer, जो workloads को लगातार कम उपयोग वाले clusters और zones की ओर move करता है
- Auto Scaler, जो प्रत्येक workload के लिए capacity allocation को लगातार optimize करता है
- Platform Layer:
- Experience layer द्वारा services के साथ interaction के लिए उपयोग की जाने वाली abstractions को implement करता है
- इसमें service और service environment abstractions शामिल हैं, जो service operations का conceptual model बनाती हैं, साथ ही service-level API भी
- Platform layer में service constraints को एक higher-level desired state के रूप में व्यक्त किया जाता है, जो actual service placement के desired properties का वर्णन करती है
- इसमें run होने वाली machines की performance और regional services के लिए कुल computing capacity पर constraints शामिल हो सकते हैं
- Federation Layer:
- computing clusters के साथ integrations को implement करता है
- upper layers द्वारा उपयोग किए जाने वाले region और zone abstractions को implement करने के लिए सभी clusters को capabilities और physical placement के आधार पर organize करता है
- platform से मिलने वाली high-level service desired state को zone और cluster placements में translate करता है; यह translation desired state के constraints और clusters की actual state पर आधारित होती है, जिसमें वर्तमान उपलब्ध capacity और वे clusters शामिल हैं जो cluster तथा secondary constraints को पूरा कर सकते हैं
- इस translation का परिणाम समय के साथ बदल सकता है, और बाद में अलग zone तथा cluster placements अधिक उपयुक्त हो सकते हैं
- Balancer की हर call और experience layer से शुरू किए गए अन्य कार्यों के कारण भी यह placement दोबारा calculate होकर बदल सकता है
- सिस्टम को safe बनाए रखने और services को healthy state में रखने के लिए change-management component, service health monitor करने वाले सभी systems के साथ integration के माध्यम से global state को थोड़ा-थोड़ा करके बदलने वाला rollout flow implement करता है
- rollout process में पूरे सिस्टम में canarying और health-signal monitoring शामिल है, और समस्या मिलने पर सिस्टम बदलाव शुरू होने से पहले वाली configuration और placement पर सेवाओं को तेज़ी से rollback कर देता है
- Regions
- regions में वास्तविक cluster instances शामिल होते हैं
- इनमें Peloton और Kubernetes® clusters शामिल हैं
- ये Up के बाहर हैं, लेकिन actual capacity placement के targets हैं और physical hosts पर container placement manage करते हैं
प्रभाव
- 2018 में Up पर काम शुरू हुआ, 2019 की शुरुआत में working prototype दिया गया, और 2020 के मध्य में platform औपचारिक रूप से लॉन्च किया गया
- इसके बाद Uber की सभी business lines में 4,000 से अधिक सेवाओं को legacy deployment platform से Up पर migrate किया गया
- इस migration का अधिकांश हिस्सा automated था, इसलिए टीम सबसे advanced use cases पर ध्यान केंद्रित कर सकी और अन्य टीमों के migration को support भी कर सकी
- इस अवधि में platform stability को सर्वोच्च प्राथमिकता दी गई, जिससे हर दिन लाखों users द्वारा उपयोग किए जाने वाले Uber systems के बीच बिज़नेस को स्थिर रूप से चलाया जा सका
- लगभग 2,000,000 computing cores को नए platform पर ले जाने वाला पूरा migration लगभग 2 वर्षों में चला और 2022 में सफलतापूर्वक पूरा हुआ
- इस migration के माध्यम से auto-scaling और efficiency efforts के जरिए बिज़नेस को अतिरिक्त capacity के रूप में कई करोड़ डॉलर वापस मिले
- manual service updates, नए zones को सेट up और populate करने, तथा Uber के जटिल infrastructure environment को navigate करना सीखने में लगने वाले engineering समय के दसियों हजार घंटे बचाए गए, जिससे महत्वपूर्ण financial cost savings हुई
आगे क्या
- µDeploy से Up पर migration पूरा होने के बाद, टीम अब ऐसे solutions और उनके आसपास user experiences बनाने पर ध्यान दे सकती है जिन्हें centralized automated तरीके से पूरे service fleet पर लागू किया जा सके
- Cloud migration
- Uber अपने fleet का एक बड़ा हिस्सा cloud में ले जा रहा है
- large-scale automation और Up द्वारा दिए गए abstraction layer की वजह से service teams इस बदलाव के लिए ज़रूरी infrastructure details से काफी हद तक मुक्त हो सकती हैं
- Automated Continuous Delivery
- लक्ष्य यह है कि automated pipelines का उपयोग करके code के production में deploy होने से पहले कई checks और tests चलाए जाएँ, ताकि production तक code deployment पूरी तरह automate किया जा सके
- 2023 में टीम जिस खास हिस्से पर ध्यान देने की योजना बना रही थी, वह services को "up to date" रखना है, ताकि production में चलने वाला सारा code नवीनतम security और library updates के साथ current बना रहे
- Deployment safety
- मौजूदा data से पता चलता है कि देखी गई घटनाओं का एक बड़ा हिस्सा code और configuration changes से जुड़ा है
- लक्ष्य यह है कि service lifecycle के manual पहलुओं, जैसे pre-production tests चलाना या gradual rollout policies सेट करना, को automate करके उन defects की दर को काफी कम किया जाए जो वास्तव में production तक पहुँचती हैं
- Platform
- Uber की सभी Stateless service fleet को एक umbrella platform के तहत organize करने से infrastructure platform products के बीच dependencies और interactions को अधिक स्पष्ट रूप से model किया जा सकेगा
- इससे न केवल code में unified model मिलेगा, बल्कि बाकी engineering organization को पूरी तरह integrated user experience भी मिलेगा
- पूरी infrastructure को एक ही जगह से observe और operate कर पाना टीम का अगला बड़ा लक्ष्य है
निष्कर्ष
- Up platform बनाने का प्रयास एक बड़े सांस्कृतिक बदलाव का संकेत है, क्योंकि अब सभी Stateless सेवाएँ समान best practices और automation का उपयोग करते हुए gradually deploy की जाती हैं
- rollout policies बदलने या large-scale library rollouts के लिए automation बनाने जैसे काम, जिनमें पहले कई महीनों का काम लगता था, अब centralized तरीके से संभव हो गए हैं
- Uber इंजीनियर infrastructure की चिंता किए बिना केवल code पर ध्यान दे सकें, इस दृष्टि को हासिल करने के लिए टीम Up के stakeholders और service owners के साथ लगातार काम जारी रखने की उम्मीद करती है
अभी कोई टिप्पणी नहीं है.