वितरित सिस्टम के शुरुआती लोगों के लिए सलाह

• वितरित सिस्टम इंजीनियर अक्सर मैदान में हुई गलतियों से मिले घावों के जरिए सीखते हैं
• नए इंजीनियरों को ऐसे घावों से बचाने के लिए यह लेख लिखा गया है

वितरित सिस्टम अक्सर विफल होते हैं

• वितरित सिस्टम, दूसरे software engineering क्षेत्रों से अलग, विफल होने की संभावना अधिक रखते हैं। खासकर आंशिक विफलता की संभावना ज्यादा होती है।
• जो सिस्टम इंजीनियर distributed computing में काम नहीं कर चुके हैं, वे अक्सर "बस दो सिस्टम में write भेज दो" या "सफल होने तक write retry करते रहो" जैसी बातें कहते हैं
• नेटवर्क सिस्टम, single machine की तुलना में अधिक बार विफल होते हैं, और ये विफलताएँ अक्सर आंशिक होती हैं
• एक write सफल हो सकती है और दूसरी विफल, तो अब डेटा का एक consistent view कैसे मिलेगा? ऐसी आंशिक विफलताओं पर तर्क करना कहीं अधिक कठिन है
• switch down हो सकता है, garbage collection की वजह से leader "गायब" हो सकता है, या socket write सफल दिख सकती है जबकि वास्तव में विफल हुई हो। local memory से पढ़ना, कुछ switches के पार पढ़ने से कहीं अधिक भरोसेमंद है
• "failure के लिए design" करना चाहिए

मज़बूत वितरित सिस्टम लिखना अधिक महंगा पड़ता है

• मज़बूत distributed solution बनाने में single machine solution की तुलना में अधिक लागत आती है।
• virtual machine और cloud तकनीकें distributed systems engineering को सस्ता बनाती हैं, लेकिन फिर भी इसकी लागत काफी रहती है।
• simulation उपयोगी है, लेकिन यह वास्तविक distributed environment में होने वाली सभी समस्याओं का समाधान नहीं कर सकती।

मज़बूत open source वितरित सिस्टम दुर्लभ हैं

• लंबे समय तक बहुत-सी machines चलाने की लागत open source community पर बोझ डालती है।
• शौकिया तौर पर open source code लिखने वालों के पास अक्सर distributed systems की कई समस्याओं को गहराई से समझने या हल करने के लिए पर्याप्त आर्थिक संसाधन नहीं होते।
• कुछ समस्याएँ company engineers हल करते हैं, लेकिन उनकी प्राथमिकताएँ हमेशा एक जैसी नहीं होतीं।

coordination बहुत कठिन है। जहाँ तक संभव हो, इससे बचना चाहिए

• horizontal scalability का मूल स्वतंत्रता है। machines के बीच communication और consensus को न्यूनतम रखना चाहिए।
• हर बार जब दो machines को किसी बात पर सहमत होना पड़ता है, service implementation और कठिन हो जाती है।
• Paxos algorithm को implement करना बेहद कठिन है।

अगर समस्या memory में समा सकती है, तो शायद वह मामूली समस्या है

• वितरित सिस्टम इंजीनियरों के लिए single machine तक सीमित समस्या आसान मानी जाती है।
• जब डेटा कुछ switches दूर हो, तो उसे तेज़ी से process करना और कठिन हो जाता है।

"धीमापन" सबसे कठिन समस्या है

• "धीमापन" का मतलब यह हो सकता है कि उपयोगकर्ता अनुरोध पूरा करने वाले कई सिस्टमों में से एक या अधिक धीमे हैं।
• आंशिक विफलताएँ graph में दिखाई नहीं देतीं, और जब तक वे स्पष्ट न हों, तब तक समस्या-समाधान के लिए ज़रूरी संसाधन पाना कठिन होता है।

पूरे सिस्टम में backpressure लागू करना चाहिए

• backpressure का अर्थ है कि serving system, requesting system को failure का संकेत दे, और requesting system इन failures को कैसे संभाले।
• backpressure mechanism न हो तो cascading failures या अनचाही message loss होने की संभावना बढ़ जाती है।

आंशिक रूप से उपलब्ध रहने के तरीके खोजने चाहिए

• इसका अर्थ है कि सिस्टम का कुछ हिस्सा विफल होने पर भी कुछ परिणाम लौटाए जा सकें।
• उदाहरण के लिए, search system अगर तय समय के भीतर सभी documents नहीं खोज पाता, तो वह जो परिणाम मिल चुके हैं, वही लौटा देता है।

metrics ही काम पूरा करने का एकमात्र तरीका हैं

• metrics को expose करना ही यह समझने का एकमात्र तरीका है कि सिस्टम वास्तव में कैसे काम कर रहा है।
• log files उपयोगी हैं, लेकिन वे अक्सर झूठ बोलती हैं। success logs ज़्यादातर मामलों में duplicate होते हैं, इसलिए उन्हें दर्ज नहीं किया जाता।

average नहीं, percentile का उपयोग करना चाहिए

• percentile, average की तुलना में अधिक सटीक और उपयोगी होते हैं। average अक्सर गलत फैसलों तक ले जाता है।

capacity का अनुमान लगाना सीखना चाहिए

• यह जानना महत्वपूर्ण है कि किसी काम को करने के लिए कितनी machines चाहिए होंगी।
• उदाहरण के लिए, आप अक्सर ऐसे rough calculations करेंगे जैसे memory में कितने tweet IDs रखे जा सकते हैं।

feature flags, infrastructure rollout का तरीका हैं

• feature flags सिस्टम में नए features rollout करने का एक सामान्य तरीका हैं।
• feature flags का उपयोग करने से project के बारे में confidence मिलता है और failure की लागत कम होती है।

ID space समझदारी से चुनना चाहिए

• सिस्टम का ID space उसकी संरचना को आकार देता है।
• उदाहरण के लिए, Twitter API का tweet ID एक साधारण 64-bit संख्या है, जो किसी अन्य डेटा से जुड़ा नहीं होता।

data locality का लाभ उठाना चाहिए

• डेटा की processing और caching को persistent storage के करीब रखना अधिक कुशल होता है।
• network में pointer dereference और fread(3) की तुलना में अधिक विफलताएँ और latency होती हैं।

cached data को वापस persistent storage में लिखना बुरा है

• यह समस्या कई सिस्टमों में दिखाई देती है। खासकर उन सिस्टमों में जिन्हें distributed systems का कम अनुभव रखने वाले लोगों ने design किया हो।

कंप्यूटर आपकी सोच से अधिक काम कर सकते हैं

• कम अनुभवी practitioners की ओर से कंप्यूटर की क्षमता को लेकर बहुत-सी गलत धारणाएँ फैली होती हैं।
• आधुनिक web servers कुछ सौ milliseconds में हज़ारों requests संभाल सकते हैं।

CAP theorem का उपयोग करके सिस्टम की आलोचना करनी चाहिए

• CAP theorem ऐसा कुछ नहीं है जिसका उपयोग सिस्टम बनाने के लिए किया जाए। लेकिन distributed systems design की आलोचना करने में यह उपयोगी है।

services को extract करना चाहिए

• services से आशय ऐसे distributed systems से है जिनमें storage systems की तुलना में ऊँचे स्तर की logic शामिल होती है।
• service extraction, library बनाने की तुलना में अधिक तेज़ और आसान deployment दे सकता है।

GN⁺ का सारांश

• वितरित सिस्टम इंजीनियरिंग, उच्च विफलता संभावना और आंशिक विफलताओं के कारण, दूसरे software engineering क्षेत्रों से अलग है।
• मज़बूत वितरित सिस्टम लिखने में अधिक लागत लगती है, और open source community में ऐसे सिस्टम दुर्लभ हैं।
• coordination, data locality, backpressure और partial availability जैसी अवधारणाओं को समझना और लागू करना महत्वपूर्ण है।
• metrics, percentile, feature flags और ID space selection जैसे तरीकों से सिस्टम की दक्षता और स्थिरता बढ़ाई जा सकती है।
• CAP theorem का उपयोग करके सिस्टम की आलोचना करना, और ज़रूरत पड़ने पर services को extract करना अच्छा है।

[GN⁺]

Hacker News राय

• CALM (Consistency as Logical Monotonicity) सिद्धांत CAP की तुलना में समझना आसान है और अधिक बुनियादी निष्कर्ष है

  • Idempotence, CRDTs, WALs, Raft सभी CALM सिद्धांत के विशेष मामले हैं
  • लिंक: CALM सिद्धांत पेपर

• exactly-once delivery असंभव है, और आपको at-most-once या at-least-once delivery में से एक चुनना होगा

• अच्छा लेख है। 8 साल पुराना होने के बावजूद इसमें अब भी बहुत सी बातें प्रासंगिक हैं

• पिछली चर्चाओं के लिंक:

  • 12 साल पहले की चर्चा
  • 8 साल पहले की चर्चा

• व्यावहारिक और यथार्थवादी व्याख्या अच्छी लगी। "microservices" जैसे चलताऊ buzzword नहीं हैं

  • यह सलाह single system पर भी लागू हो सकती है
  • IPC या threads के बीच coordination जैसे विभिन्न distributed components पर विचार करना चाहिए
  • single CPU से multi-CPU और multiple computers तक distribution का एक spectrum मौजूद है

• Lookout में काम करते समय Jeff Hodges ने यह निबंध साझा किया था

  • उन्होंने इस बात पर ज़ोर दिया कि engineering राजनीतिक होती है
  • 10 साल बाद भी engineering leadership और SRE/DevOps के intersection को अच्छी तरह समझने वाले लोग बहुत कम हैं

• इस लेख के लेखक के साथ काम करने का अनुभव है

  • Jeff बहुत सकारात्मक थे और उनसे बहुत कुछ सीखा जा सकता था
  • वे चुनौतियों के बारे में ईमानदार थे और mentoring व सलाह के लिए बहुत सहजता से उपलब्ध रहते थे

• 2013 के बाद बहुत कुछ बदल गया है

  • उस समय cloud services कम mature थीं
  • आज AWS जैसी services का उपयोग करने पर distributed systems की ज़्यादातर समस्याएँ हल की जा सकती हैं
  • theoretical distributed computing concepts को लेकर चिंता करने की लगभग ज़रूरत नहीं है
  • practical चीज़ें, जैसे logging, debugging, backpressure आदि, अब भी ध्यान में रखनी पड़ती हैं
  • availability सैद्धांतिक रूप से महत्वपूर्ण है, लेकिन व्यवहार में कम महत्वपूर्ण है
  • ज़्यादातर कंपनियाँ कुछ घंटों का downtime सह सकती हैं
  • distributed computing के सैद्धांतिक और व्यावहारिक दोनों पहलुओं से जूझने वाले 1% engineers भाग्यशाली हैं
  • मैंने पहले distributed databases और papers पर काम किया है, लेकिन व्यवहार में इन चीज़ों की चिंता करने की बहुत कम ज़रूरत पड़ी
  • लिंक: PostgreSQL fsync समस्या
  • लिंक: ScalienDB
  • लिंक: पेपर