Shipyard: Slack के अगली पीढ़ी के EC2 प्लेटफ़ॉर्म के निर्माण की कहानी

 (slack.engineering)
2 पॉइंट द्वारा GN⁺ 2 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Slack ने लंबे समय तक चलने वाले EC2 को लगातार संशोधित करने वाले पुराने तरीके से immutable AMI-आधारित replacement deployment पर स्विच किया, ताकि उन workloads पर भी आधुनिक deployment तरीका लागू किया जा सके जिन्हें container में ले जाना मुश्किल है
  • साझा base image slack-zero के ऊपर service-specific images बनाई जाती हैं, भारी configuration image baking के दौरान की जाती है, और environment-specific secrets व metadata केवल boot के समय लागू किए जाते हैं
  • Deployment orchestrator Gondola AMI और version-specified Chef artifacts को एक deployment unit के रूप में मैनेज करता है, और metrics-आधारित phased rollout, halt, और automatic rollback करता है
  • Peekaboo पूरे EC2 inventory की लगभग real-time visibility देता है, और The Reaper दूषित या उम्र पार कर चुके instances को rate limiting और pause controls के तहत replace करता है
  • यह short-lived services के लिए प्रभावी है, लेकिन long-running instances जैसे data nodes, GitHub Enterprise, और Atlassian JIRA, जिन्हें जल्दी replace नहीं किया जा सकता, उनके लिए अलग patching तरीकों और deployment executors की ज़रूरत होती है

लगातार संशोधित होने वाले EC2 मॉडल की सीमाएँ

  • Slack ने पुराने single Chef stack को resilient multi-stack structure में बदला, और versioned cookbook deployment व safe promotion process लागू कर, दसियों हज़ार EC2 instances के लिए reliability और operational control बढ़ाया
  • इसके बाद segmented production environments, signal-based Chef execution, और बेहतर rollout तरीकों को लागू किया गया, जिससे teams को cookbook दोबारा लिखे बिना failures के impact scope को काफ़ी कम करने में मदद मिली
    • Safety Without Disruption चरण में legacy platform को स्थिर रखते हुए आगे की architecture planning के लिए समय मिला
  • लेकिन long-running instances को लगातार update करने वाला मॉडल service-level deployment को कठिन बनाता था, infrastructure drift से बचना संभव नहीं था, और कई layers के बदलावों को coordinate करना जटिल होता जा रहा था
  • Containers ने कुछ workloads की समस्याएँ हल कीं, लेकिन सभी systems को आसानी से migrate नहीं किया जा सकता था, इसलिए ऐसा platform चाहिए था जो immutability, phased deployment, और automated safety controls को सीधे EC2 पर लागू कर सके

Shipyard द्वारा दिया गया EC2 operating model

  • Shipyard Slack का अगली पीढ़ी का EC2 platform है, जो infrastructure को लगातार संशोधित होने वाले instances नहीं बल्कि deployable artifacts के रूप में मानता है
  • यह service-level deployment capability को build और orchestration systems के साथ जोड़ता है, ताकि application deployment platforms जैसी safety और predictability EC2 updates पर भी लागू की जा सके

  • कई architectures और operating systems का समर्थन

    • यह AMD64 और ARM-आधारित Graviton सहित कई CPU architectures को support करता है, और Ubuntu, RHEL, Amazon Linux का उपयोग कर सकता है
    • Teams cost, performance, और compatibility के आधार पर instances और operating system चुन सकती हैं, बिना अलग platform implementation के
    • यह खास तौर पर उन infrastructure components, Kubernetes worker nodes, और egress network stack के लिए उपयुक्त है जिन्हें container में migrate करना कठिन है

  • Metrics-आधारित सुरक्षित deployment

    • हर service, Gondola के साथ integrate होकर, metrics-based automated safety checks सहित phased rollout चलाती है
    • Service health signals के आधार पर deployments को अपने-आप रोका जा सकता है या पिछले healthy version पर automatic rollback किया जा सकता है

  • तेज़ और predictable provisioning

    • यह containers जैसी layered image structure का उपयोग करता है, जिसमें common golden base image के ऊपर service-specific images बनाई जाती हैं
    • Runtime पर होने वाले काम को कम करके, instances कई regions में तेज़ी और स्थिरता से चालू होते हैं

  • सरल configuration management

    • पहले scheduled Chef jobs समय-समय पर configuration को जाँचकर दोबारा लागू करती थीं, ताकि manual changes या unexpected changes को desired state में वापस लाया जा सके
    • Shipyard में configuration केवल image baking और initial provisioning जैसे स्पष्ट lifecycle phases में ही लागू होती है
    • Configuration management tools पूरे system को लगातार बदलने के बजाय मुख्यतः services deploy करने के लिए इस्तेमाल होते हैं
    • इससे background load और अनचाहे overwrites कम होते हैं, और क्योंकि instances समय के साथ लगातार नहीं बदलते, उनके behavior को समझना आसान हो जाता है

  • सीमित lifetime वाले instances

    • हर instance को limited lifetime दी जाती है और उसे नियमित रूप से अपने-आप replace किया जाता है
    • इससे संभावित vulnerabilities के असर डालने का समय कम होता है, और teams को running instances में बदलाव करने के बजाय उन्हें replace करने के लिए प्रोत्साहित किया जाता है

Peekaboo inventory और पूरी fleet visibility

  • Peekaboo एक inventory system है जो Chef Server की जगह cloud events और instance metadata का उपयोग करके EC2 fleet की स्थिति को लगभग real-time में दिखाता है
  • यह Shipyard के बाहर deploy किए गए instances को भी track करता है, जिससे पूरी fleet को एक जगह देखा जा सकता है
  • यह AWS EventBridge, OpenSearch, और Lambda पर बना है, और निम्न interfaces देता है
    • fleet exploration के लिए UI
    • system integration के लिए API
    • तेज़ command-line checks के लिए CLI
  • EC2 जानकारी को centralize करके यह पूरे environment में telemetry और management points को एकीकृत करता है

slack-zero golden base image

  • slack-zero एक साझा machine image है जिसे Compute Platform Team ने बनाया है और Security व Monitoring teams के साथ मिलकर maintain किया जाता है
  • यह वह standardized और trusted base है जिससे सभी services inherit करती हैं, और service teams इसी के ऊपर अपना runtime environment बनाती हैं
  • Image में निम्न चीज़ें शामिल हैं
    • operating system baseline और security hardening settings
    • networking और service discovery configuration
    • monitoring और security agents
    • common tools और foundational system configuration
  • Base image को immutable और ephemeral ऑब्जेक्ट की तरह माना जाता है
    • जब security patch, monitoring update, या networking improvement की ज़रूरत होती है, तो नई slack-zero image बनाई जाती है
    • नीचे की service images नए base पर फिर से build होकर बदलाव inherit करती हैं

  • AWS Image Builder क्यों चुना गया

    • slack-zero अब पुराने Packer की जगह AWS Image Builder से बनाया जाता है
    • Lifecycle policies पुराने AMIs को अपने-आप साफ़ करती हैं, जिससे storage cost कम होती है
    • नई image बनने पर यह account-specific latest AMI को point करने वाले AWS Systems Manager(SSM) parameters को update करता है, और service pipelines इन्हें पढ़कर latest base का उपयोग करती हैं
    • Image baking सफल होने पर EventBridge और Lambda service owner account की downstream pipelines को अपने-आप शुरू करते हैं
    • AMI publish करने से पहले temporary instances पर validation tests चलाए जाते हैं, जिससे production rollout का risk कम होता है

Service images की baking और provisioning

  • हर service team slack-zero के आधार पर अपनी AMI बनाती है, shared platform components inherit करते हुए भी runtime environment पर control रखती है
  • Service image pipeline निम्न चीज़ें परिभाषित करती है
    • install किया जाने वाला software
    • service को configure करने का तरीका
    • उस service के लिए instance initialization process
  • अधिकांश configuration को image में शामिल किया जाता है, ताकि execution speed और consistency बढ़े और configuration drift न्यूनतम रहे

  • दो चरणों में ज़िम्मेदारियों का विभाजन

    • Baking चरण में packages और environments के बीच shared रहने वाली configuration install की जाती है, ताकि instance के चलने से पहले ही वह अधिकतर तैयार और healthy state में हो
    • Provisioning चरण में boot के समय केवल environment-dependent settings लागू की जाती हैं, जैसे secrets, region-specific configuration, और deployment metadata
    • आमतौर पर इसमें configuration files रखना, secrets fetch करना, और service start करना शामिल होता है
    • Package installation जैसे भारी काम baking में ले जाने से instances मिनटों नहीं बल्कि सेकंडों में चालू हो सकते हैं
    • तेज़ startup scaling events, sequential deployments, और automatic instance replacement के लिए महत्वपूर्ण है, और minimal provisioning runtime adaptation के दौरान होने वाले drift को भी सीमित करती है

AMI replacement-केंद्रित fleet update

  • Changes को नई AMI बनाकर deployment pipeline के जरिए rollout किया जाता है, और मौजूदा instances को patch करने के बजाय controlled replacement से fleet update की जाती है
  • Auto Scaling Group(ASG) के लिए AWS Instance Refresh, और Kubernetes worker fleets के लिए Karpenter का उपयोग होता है
  • जिन services की deployment requirements विशेष हैं, वे अलग executors जोड़ सकती हैं, और Gondola अलग-अलग patterns को एकसमान deployment experience में समेटता है

  • Emergency fix path

    • Emergency में running instances पर सीमित configuration changes लागू की जा सकती हैं, लेकिन बाद में standard deployment pipeline के जरिए उन instances को replace करना ज़रूरी है
    • AWS Systems Manager के predefined documents से चुनी हुई Chef recipe चलाकर emergency fix लागू किया जाता है
    • System स्थिर होने पर instances को cycle करके इच्छित immutable state में वापस लाया जाता है

Gondola का phased deployment

  • Customer pipelines को service और operational requirements के अनुसार कई stages में बनाया जा सकता है
  • हर Gondola stage, ASG, Kubernetes cluster, या EC2 instance group जैसी एक deployment unit को दर्शाती है
  • Egress Team हर availability zone में अलग canary और production ASG रखती है, और stages को इस तरह रखती है कि updates क्रम से आगे बढ़ें
  • Gondola हर stage को update करते समय प्रमुख metrics की निगरानी करता है, और समस्या मिलने पर अपने-आप rollback करके failure propagation को रोकता है

  • Deployment artifacts और executors

    • Gondola द्वारा बनाया गया deployment package दो भागों से बना होता है
      • fleet में deploy की जाने वाली AMI
      • Git commit से जुड़ी versioned recipes वाला Chef artifact
    • इन दोनों को एक deployment unit माना जाता है, और हर stage service-defined executor के जरिए rollout होती है
    • ASG deployment में executor नई AMI और configuration के साथ launch template update करता है
    • Chef code को Amazon S3 में package किया जाता है
    • नए instances का built-in bootstrapper सही artifact fetch करके संबंधित recipes चलाता है
    • Configuration metadata का उपयोग करके केवल उस role के लिए उपयुक्त settings लागू की जाती हैं
    • Kubernetes worker fleet में executor, Karpenter के लिए उपयोग होने वाली AMI और वही configuration metadata भेजता है, और nodes भी इसी तरीके से bootstrap होते हैं
    • Special deployments के लिए नए executors जोड़ने पर भी AMI, versioned configuration artifacts, और metadata-based bootstrap तरीका वही रहता है

Platform teams और service teams के बीच ज़िम्मेदारियों का बँटवारा

  • Compute, Security, और Monitoring teams base layer के global infrastructure components, security patches, और required settings को manage करती हैं
  • Service teams उसी base के ऊपर अपना software और service-specific settings जोड़कर AMI बनाती हैं
  • जब Compute team security patches, monitoring agents, या networking changes deploy करती है, तब service teams को updated base image को अपनी AMI में शामिल करना होता है
  • यह shared responsibility model service-level autonomy बनाए रखते हुए fleet की consistency, security, और reliability को संतुलित करता है

पूर्ण immutability नहीं, secrets एक अपवाद

  • Shipyard instances के packages और configurations का अधिकांश हिस्सा baking के समय तय हो जाता है, लेकिन secrets इसका अपवाद हैं
  • हर instance की Consul Template service, fleet replace किए बिना Vault के नए secrets deploy करती है
  • क्योंकि credentials या certificates को dynamically update किया जा सकता है, इसलिए Shipyard core systems और service layer के लिए स्थिर लेकिन semi-immutable infrastructure है
  • इससे stability और predictability बनी रहती है, और ज़रूरी runtime secrets को आवश्यकता पड़ने पर update किया जा सकता है

The Reaper की replacement policy

  • The Reaper दो तरह के inputs के आधार पर replacement targets तय करता है
    • contamination signals, जो security tools या AWS EC2 events जैसे external systems से आते हैं और बताते हैं कि instance desired state से बाहर चला गया है
    • periodic checks, जो देखते हैं कि instance allowed maximum lifetime से ज़्यादा समय से चल रहा है या नहीं
  • इनमें से कोई भी condition पूरी होने पर service policy के अनुसार instance replacement schedule किया जाता है
  • Emergency के लिए manual remote access की अनुमति है, लेकिन production-grade node में direct access होने पर signal generate होता है और वह instance बाद में replacement target के रूप में चिह्नित हो जाता है
  • Peekaboo के साथ integration के जरिए पूरी fleet में instance age track की जाती है, और maximum lifetime तक पहुँचने वाले nodes वही graceful termination और replacement process follow करते हैं
  • आगे चलकर योजना यह है कि software updates या configuration drift जैसे केवल meaningful changes ही replacement trigger करें, जबकि read-only या low-risk operations बेवजह cycling न पैदा करें; इसके लिए context-aware capability जोड़ी जाएगी

  • Replacement speed और emergency control

    • Built-in rate limiting के ज़रिए एक बार में replace होने वाले instances की संख्या service, region, और availability zone के हिसाब से तय की जाती है, ताकि अचानक capacity impact न हो
    • S3 में control object रखकर काम करने वाला global pause mechanism, “big red button”, incidents या high-risk periods में Reaper की सारी activity रोक सकता है
    • CLI से rate limits manage करना, configuration verify करना, और global pause को enable या disable करना संभव है
    • जिन break-glass स्थितियों में गहरी जाँच की ज़रूरत हो, वहाँ short-lived SSH certificates जैसे controlled access methods का उपयोग किया जा सकता है

Ship Quick के साथ वास्तविक infrastructure testing

  • Ship Quick एक developer workflow है जिसमें platform teams और service owners pull request merge करने से पहले वास्तविक infrastructure पर यथार्थवादी baking और provisioning tests चलाते हैं
  • Developers cookbook repository से CLI command चलाते हैं और YAML file के जरिए test cases परिभाषित करते हैं
  • Ship Quick निम्न क्रम में काम करता है
    • cookbook को package करके S3 में upload करता है
    • workflow message को queue में भेजता है
    • Longshoremen द्वारा managed worker instances job को लेती हैं
    • worker Auto Scaling Group से अलग होकर Chef workflow चलाता है
    • logs को CLI में stream करने के बाद terminate हो जाता है, और developer चाहे तो debugging के लिए उसे बनाए रख सकता है

  • Base layer के अनुसार worker fleets

    • Bootstrap structure की वजह से दो अलग worker fleets चलाई जाती हैं
    • Basic Ubuntu fleet clean Ubuntu AMI पर base image की baking और testing करती है, क्योंकि slack-zero खुद अपने ऊपर build नहीं हो सकता
    • slack-zero fleet उन service team cookbooks का परीक्षण करती है जो pre-baked slack-zero पर निर्भर हैं
    • यह production जैसे base पर provisioning validate करती है
    • इसे लगातार latest images से update किया जाता है ताकि यह current production environment को reflect करे
    • दोनों fleets demand के अनुसार auto-scale होती हैं
    • जो teams अपने AWS account में images बनाती हैं, वे isolation बनाए रखने के लिए dedicated worker fleet configure कर सकती हैं और Ship Quick jobs उसी fleet को भेज सकती हैं

Long-running workloads तक विस्तार

  • Shipyard फिलहाल short-lived services में प्रभावी रूप से काम कर रहा है, और legacy EC2 platform की teams को लगातार onboard कर रहा है
  • अगली चुनौती वे long-running instances हैं जिन्हें जल्दी cycle नहीं किया जा सकता
    • Slack data nodes
    • GitHub Enterprise जैसी singleton services
    • Atlassian JIRA जैसे third-party business technology instances
  • ऐसे workloads के लिए safe patching और update methods, और ऐसी lifecycle policies चाहिए जिन्हें The Reaper सही ढंग से संभाल सके
  • Service teams के साथ मिलकर Gondola के लिए long-running workload executor विकसित किया जा रहा है, और adoption बढ़ने के साथ tools, developer workflows, और deployment experience को लगातार बेहतर बनाने की योजना है
  • आगे Shipyard API, image pipelines, developer workflows, inventory system के components, और platform विस्तार के दौरान सामने आई चुनौतियों पर अलग से चर्चा की जाएगी

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.