Chick-Fil-A की Edge Computing तकनीकी आर्किटेक्चर: Enterprise Restaurant Compute

• चिकन फास्टफूड चेन Chick-Fil-A हर रेस्टोरेंट में edge Kubernetes cluster चला रही है
• हर स्टोर के सभी डिवाइस (fryer, grill आदि) लगातार IoT telemetry जानकारी देते हैं, जिससे दसियों हज़ार डिवाइस जुड़े हुए हैं
• इन जानकारियों से real-time में demand forecast किया जाता है और इसे cloud पर भेजा जाता है, जहाँ analysis process चलती है
• अंदरूनी cooking process से लेकर mobile payment terminal (drive-through) तक सब कुछ integrated है

Restaurant Edge Compute platform

• आज के बहुत से सिस्टम cloud/data center के लिए बनाए गए हैं
• वे resource-constrained माहौल, कमजोर internet connection, और हज़ारों Kubernetes cluster वाले environment के लिए उपयुक्त नहीं हैं
• इसलिए उन्होंने इसे खुद बनाने का फैसला किया। MVP बनाया और उसे वास्तव में deploy करके सीखना शुरू किया

Hardware

• सामान्य consumer Intel NUC इस्तेमाल करने का निर्णय लिया
• NUC generations को जोड़कर 3-node cluster बनाया गया ताकि reliability, capacity, और HA configuration को लचीले ढंग से संभाला जा सके

OS

• पहली release में Ubuntu को base OS के रूप में इस्तेमाल किया गया
• design goal यह था कि NUC को बस सीधे restaurant में drop-ship कर दिया जाए, ताकि हर restaurant के लिए manual configuration की ज़रूरत न पड़े
• यानी, सारी provisioning dynamic और on-the-fly हो
• निश्चित रूप से कुछ security features भी हैं, ताकि दूसरे डिवाइस cluster में join न कर सकें या internal cloud services तक पहुँच न बना सकें

Edge Commander

• cluster bootstrapping और management process
• हर edge cluster node को एक ही image से बनाया जाता है
• इसमें कई disk partition और OverlayFS का इस्तेमाल करने वाली तरकीबें भी शामिल हैं
  • जैसे कुछ data को long-term बनाए रखना, या node की दूसरी partitions को remotely delete यानी "wipe" करना

Kubernetes

• K3s implementation का उपयोग करने का निर्णय लिया गया
  • यह Kubernetes spec के साथ compatible है, लेकिन कुछ features हटाए गए हैं। बड़े पैमाने पर configure और support करना बहुत आसान है
• क्योंकि यह cloud का उपयोग नहीं कर रहा, इसलिए Kubernetes की पूरी functionality की ज़रूरत नहीं है
• वे इससे बहुत संतुष्ट हैं और आगे इसे बदलने का इरादा नहीं है

GitOps

• पहली platform release बनाते समय ऐसा कोई GitOps agent solution नहीं था जो resource-constrained edge पर चल सके
• इसलिए 'Vessel' नाम का अपना agent विकसित किया गया
• यह Git Repo (हर store के लिए unique repo) को poll करता है और cluster changes को process करता है
• cloud के Kubernetes cluster पर open source GitLab instance host किया जा रहा है
• वे खुद Git server चलाने का बोझ नहीं लेना चाहते थे, लेकिन कोई cost-effective hosting solution license model नहीं मिला

Deployments

• GitOps के लिए हर location अपनी Git Repo को point करती है, जिसे Atlas कहा जाता है
• हर restaurant में नया deployment Atlas की master branch में नई configuration merge करके किया जा सकता है
• enterprise management के लिए इस approach में कुछ trade-off हैं, लेकिन इसने deployment state management और audit को बहुत सरल बना दिया

Supporting a Chain-Wide Deployment

• सबसे बड़ी चुनौती MVP को एक बहुत छोटे team द्वारा maintain किए जा सकने वाले, scalable और supportable platform में बदलना था

API First रणनीति

• business का पहला काम था सभी manual processes और validation steps को Restful API में wrap करना
• हर step के लिए comprehensive API suite बनाया गया, फिर उसके ऊपर orchestration layer बनाकर manual processes को automate करना शुरू किया गया
• comprehensive और अच्छी तरह documented PostMan project बनाने से, वे नए API का तेज़ी से उपयोग कर सके और support team के लिए Web UI बनाने को टाल सके
• OAuth का उपयोग करके API suite के लिए granular step-by-step access दिया गया। इससे खास functions को आसानी से lock किया जा सका, या ग्राहकों के लिए non-invasive status और reporting endpoints खोले जा सके

Dedicated Roll Out Team

• इतने कम समय में इतने सारे devices को पूरी chain में कैसे deploy किया गया?
• core development team बहुत छोटी थी, इसलिए platform support, development, और chain-wide rollout deployment सबको साथ संभालना कठिन था
• उन्होंने full rollout से पहले 3 NUC पहले ही भेजकर install कर दिए थे, और उसके बाद केवल configuration और validation steps बचे थे
• क्योंकि API suite चल रहा था, इसलिए platform launch/status monitoring/सरल support issue resolution के लिए एक "semi-technical support team" जल्दी बनाई जा सकी
• Pair-Support, playbook, और document feedback loop का उपयोग करके rollout team को तेज़ी से मजबूत किया गया
• कुछ ही हफ्तों में टीम self-sufficient हो गई और पूरी chain में rollout हासिल कर लिया
• उसके बाद संगठित structure के ज़रिए नए features और expansion के साथ-साथ platform के लिए शानदार support देना संभव हुआ
• उनका लक्ष्य व्यावहारिक हिस्सों को automate करना था, और बाकी support work को support chain में यथासंभव ऊँचे स्तर तक push करना था
• यह First Tier Support और Support DevOps team के बीच feedback loop के ज़रिए हासिल किया गया
  • सभी issues की शुरुआत first tier से होती है
  • यदि समस्या हल नहीं होती, या नई और जटिल समस्या आती है, तो उसे Support DevOps team को भेजा जाता है
  • दोनों टीमें मिलकर समस्या हल करती हैं, और First Tier team documentation और playbook अपडेट करती है ताकि अगली बार समान समस्या को सीधे संभाला जा सके
  • साप्ताहिक support retrospectives के माध्यम से DevOps team backlog में improvements और auto-remediation के अवसर जोड़े जाते हैं
  • साथ ही Support DevOps team, नए development team backlog को भी प्रभावित करती है ताकि नए tools या support improvement से जुड़ी चीज़ों की प्राथमिकता तय की जा सके

Monitoring and Auto-Remediation

• 2500 से अधिक K3s cluster मौजूद हैं
• monitoring process को बेहतर बनाकर cluster की सभी समस्याओं की पहले से पहचान और recovery करनी थी। इसके लिए बहुआयामी approach विकसित की गई

Synthetic Client

• core platform functions को test करने और समस्याओं (service issues, data latency आदि) का विश्लेषण करने के लिए cluster के भीतर container के रूप में चलने वाला Synthetic Client बनाया गया
• समस्या मिलने पर client API के ज़रिए Cloud Control Plane को report करता है। support team को alert जाता है और automated remediation process शुरू हो जाती है

Node Hearbeats

• Kubernetes cluster में self-healing capability होती है, इसलिए node failure होने पर active nodes के बीच workloads अपने आप rebalance हो जाते हैं
• node failure का पता लगाने के लिए cluster के हर node पर एक साधारण "Heartbeat Pod" deploy किया गया
• यह Pod समय-समय पर cloud API endpoint पर अपनी स्थिति report करता है

Auto Remediation

• साप्ताहिक support retrospectives के ज़रिए error, validation, और fix steps के बीच patterns मिले
• क्योंकि सभी support tools API-based थे, इसलिए इन APIs के ऊपर orchestration flows बनाए जा सके और आम समस्याओं के लिए auto remediation संभव हो सका

New Capabilities

• infrastructure में लगातार सुधार करते हुए, development team self-service और supportability बढ़ाने के लिए नए platform features विकसित करती रही

Deployment Orchestration

• उनका GitOps model सरल है
• शुरुआत manual changes से हुई, लेकिन जल्द ही cluster changes और कई restaurants में deployment के लिए "Fleet" नाम का tool बनाया गया
• platform बढ़ने के साथ पूरी chain में deploy करने और deployment failure/success की पुष्टि करने का तरीका चाहिए था
• दूसरी iteration में एक नया Deployment Orchestration API विकसित किया गया
  • API के साथ हर cluster में feedback agent deploy किया गया, ताकि deployment और status information को cloud में report किया जा सके
• इससे पूरी chain के लिए releases और self-managed canary deployment pattern बनाना संभव हुआ
• इस बदलाव से टीम deployments को बारीकी से tune और observe कर सकी, जिससे deployment reliability बढ़ गई

Log Exfiltration

• शुरू में internal DevOps team को restaurant के K3s cluster तक सीधी पहुँच दी गई थी, ताकि वे real-time status ले सकें और logs खोज सकें
• basic log exfiltration functionality थी, लेकिन latency और network issues के कारण इसका इस्तेमाल बहुत कठिन था
• क्योंकि वे clusters तक remote access को न्यूनतम रखना चाहते थे, इसलिए उन्होंने API endpoints जोड़े
• अब अधिक शक्तिशाली log exfiltration functionality जोड़ दी गई है
• Vector नाम के open source tool का उपयोग करके edge clusters से logs collect और forward किए जाते हैं
  • यह filtering, storage and forwarding, और automatic log rotation functionality देता है
  • cloud side पर दूसरी Vector services सेटअप करके सभी edges से आने वाले logs collect किए जाते हैं, rules लागू किए जाते हैं, और कई tools (Data Dog, Grafana, CloudWatch आदि) को forward किया जाता है

Metrics and Dashboards

• Prometheus Remote Write का उपयोग करके सभी restaurants से metrics collect कर cloud के central Grafana तक भेजने की क्षमता जोड़ी गई
• हर K3s cluster status, nodes, और core services के workloads को capture करता है
• custom business metrics publish करने की क्षमता भी जोड़ी गई

निष्कर्ष

• उनका "Restaurant Compute Platform" और support process अब इतना mature हो चुका है कि एक छोटा development team भी उच्च स्तर की reliability और customer support दे सके

सीखी गई बातें

• एक छोटे team को MVP business-critical Edge Compute platform बनाने के लिए बेहतरीन engineering और समझदारी भरे trade-off की ज़रूरत होती है
• 2500 से अधिक Kubernetes cluster को एक छोटे team द्वारा operate करना बहुत कठिन काम है, लेकिन API-first automation approach ने बहुत मदद की
• cloud-first दुनिया से आने पर सबसे बड़ी चुनौती यह थी कि edge में constraints होते हैं (computing capacity, limited network bandwidth, remote access)
• constraints को समझने में पर्याप्त समय लगाना अच्छा है, और फिर यह सोचना कि उन्हें हटाया जाए (जिसमें समय और लागत अधिक लग सकती है) या उन्हें manage किया जाए

[ddwax89]

कमाल है haha

[ragingwind]

वाकई इसे बिलकुल नींव से बनाया है। लागू करने की प्रक्रिया में यह काफ़ी प्रेरणा भी देता है।

[nicewook]

1. यह वाकई बहुत शानदार और रोमांचक केस है। मैं भी ऐसा एक बनाकर देखना चाहूँगा।
2. यह जानकर कुछ राहत मिलती है कि यह 2018 से चल रहा विषय था। यानी इसे एक ही दिन में झटपट नहीं बनाया गया था।
   बाद में इसे एक बार फिर आराम से पूरा पढ़ना चाहूँगा।

[kbumsik]

Chick-fil-A का चिकन बर्गर बहुत स्वादिष्ट है haha

2018 में भी इसी विषय पर एक पोस्ट आई थी, तब यह थोड़ा प्रयोगात्मक लगा था, लेकिन लगता है कि इसे अब तक बनाए रखा गया है। इस लेख में भी दिखता है कि इस दौरान काफी अनुभव और know-how जमा हुआ है।

https://medium.com/@cfatechblog/…

[xguru]

यह स्टोर अभी भारत में नहीं आया है, इसलिए यहाँ इसकी पहचान लगभग नहीं के बराबर है, लेकिन Piper Sandler की साल में दो बार प्रकाशित होने वाली अमेरिका के किशोरों की कॉरपोरेट पसंद सर्वे में यह हमेशा रेस्टोरेंट पसंद में नंबर 1 रहने वाला, किशोरों के बीच बेहद लोकप्रिय रेस्टोरेंट भी है।