Slack का cellular architecture में माइग्रेशन

 (slack.engineering)
5 पॉइंट द्वारा GN⁺ 2023-08-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Slack ने पिछले 1.5 साल में redundancy बढ़ाने और site failure के असर को सीमित करने के लिए single structure से cell-based structure (Cellular Architecture) में बदलाव किया
  • जून 2021 में network outage के कारण Slack ग्राहकों को service degradation का सामना करना पड़ा था; इसके बाद Slack service की resilience बेहतर बनाने की जरूरत ने इस बदलाव को आगे बढ़ाया
  • cellular structure में हर service प्रत्येक availability zone (AZ) में एक virtual service की तरह काम करती है, जिससे एक AZ में failure होने पर उसका असर दूसरे AZ पर नहीं पड़ता
  • इसमें problem वाले AZ से traffic drain करने की क्षमता भी शामिल है, जिससे उसे सिस्टम के बाकी हिस्सों से प्रभावी ढंग से isolate किया जा सकता है
  • drain mechanism को तेज, error-free, gradual और drain किए जा रहे AZ के resources से independent तरीके से डिज़ाइन किया गया है
  • cellular structure में बदलाव में siloing नाम की strategy भी शामिल है, जिसमें services केवल अपने ही AZ के भीतर traffic receive और send करती हैं। इससे एक ही AZ के भीतर सभी failures को सीमित रखने में मदद मिलती है
  • traffic movement mechanism के implementation का फोकस उस सिस्टम पर था जो user queries को core services तक route करता है
  • नई architecture, AZ draining को support करने के लिए Envoy की weighted clusters feature और RTDS के जरिए dynamic weight assignment का उपयोग करती है
  • इस बदलाव ने Slack के operations और services बनाने के तरीके को बदल दिया, और traffic management तथा failure mitigation के लिए मजबूत नए tools दिए
  • भविष्य की blog posts में technical implementation details को और गहराई से समझाया जाएगा और यह चर्चा होगी कि नई architecture ने Slack के operations को कैसे प्रभावित किया

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

1 टिप्पणियां

 
GN⁺ 2023-08-27
Hacker News टिप्पणियाँ
  • Slack का cellular architecture में migration उनकी अनोखी operations और monitoring approach की वजह से दिलचस्पी पैदा करता है.
  • कंपनी की रणनीति एक single AWS availability zone (AZ) के requests को resolve करना, operations को सरल बनाना और monitoring को आसान करना है.
  • यह approach clusters के बीच metrics की तुलना करके एक single cluster में incidents को आसानी से detect और mitigate करने में मदद करती है.
  • हालांकि, इस रणनीति में compute, cache आदि में duplication होता है, क्योंकि ज़्यादातर services को कई clusters में चलाना पड़ता है.
  • कुछ users ने Slack के API request system की efficiency पर सवाल उठाए, क्योंकि यह service backend में सैकड़ों RPCs तक fan-out कर सकता है.
  • AWS availability zone affinity इस्तेमाल करने और ऊपर के routing point पर down हुए AZ को बस drop कर देने के बीच अंतर को लेकर बहस है.
  • AWS USE1 में सब कुछ चलाने की redundancy को लेकर चिंता जताई गई, क्योंकि USE1 से जुड़ी समस्याएँ कई services को प्रभावित कर सकती हैं.
  • इस architecture में user data को कैसे handle किया जाता है, खासकर AZ failure के समय, इस पर सवाल उठे.
  • कुछ users ने अतीत में काम किए गए समान architectures को याद किया, जैसे Metal Cell नाम का distributed operating system.
  • इस बात पर चर्चा हुई कि नए user requests न आने पर भी resource-heavy tasks अलग किए गए AZ में अनिश्चित समय तक चलते रह सकते हैं.
  • users यह जानना चाहते हैं कि Slack इस समय किस programming language में लिखा गया है, और क्या यह अभी भी Hack/PHP है.
  • कुछ users ने Slack की performance को लेकर निराशा जताई और इसकी तुलना Discord जैसे दूसरे chat apps से नकारात्मक रूप से की.