etcd वापरून आशिया पॅसिफिक व्हिडिओ ट्रॅफिकचे राउटिंग (Routing) करणे
आठ आशिया-पॅसिफिक बाजारपेठांना सेवा देणाऱ्या एका व्हिडिओ-स्ट्रीमिंग प्लॅटफॉर्मने क्षेत्र-विशिष्ट कॉन्फिगरेशन etcd मध्ये हलवून वारंवार होणारी राउटिंगची चूक थांबवली. राउटिंग बदलांचा प्रसार वेळ (Propagation time) सुमारे एक सेकंद इतका कमी झाला. आता एडिटर्स कोडला स्पर्श न करता काही तासांसाठी म्युझिक पूल (music pool) वाढवू शकत होते, आणि प्लॅटफॉर्मने दक्षिण-कोरियन प्रेक्षकांना टोकियो फीड पाठवणे थांबवले.
जुना दृष्टिकोन का अयशस्वी झाला
प्रत्येक राउटर प्रत्येक विनंतीसाठी तीन मूल्ये वाचत असे: ट्रेंडिंग पूल, भाषा-विशिष्ट टोकेनायझर (tokenizer) आणि फॉलबॅक चेन (fallback chain). कोडमधील बदलांऐवजी व्यावसायिक निर्णय—जसे की नवीन कलाकाराला प्रोत्साहन देणे, प्रादेशिक आउटेजला (outage) प्रतिसाद देणे किंवा शिफारस अल्गोरिदमची (recommendation algorithm) चाचणी घेणे—या मूल्यांना नियंत्रित करत होते.
सुरुवातीला, प्रत्येक डिप्लॉयमेंटमध्ये राउटिंग टेबलसह एक JSON फाईल समाविष्ट असे. एखाद्या घटनेदरम्यान, ऑन-कॉल इंजिनिअरने ट्रॅफिक बॅकअप पूलकडे वळवण्यासाठी एका नोडवरील फाईल संपादित केली, परंतु इतर सात नोड्स अपडेट केले नाहीत. यामुळे 'कॉन्फिग ड्रिफ्ट' (Config drift) निर्माण झाला: आठ देश भिन्न तक्ते (tables) वापरत होते आणि कोणताही एक स्रोत 'सत्य' (truth) सत्यापित करू शकत नव्हता. सोल प्रेक्षकांना टोकियोकडे पाठवणारी त्रुटी कायम राहिली कारण कोड तोच होता; फक्त लपलेले कॉन्फिगरेशन वेगळे होते.
'सिंगल सोर्स ऑफ ट्रुथ' म्हणून etcd ची निवड
टीमने तीन पर्यायांची तुलना केली:
- SQLite/MySQL – यामुळे प्रत्येक राउटरला डेटाबेस पोल (poll) करावा लागला असता, ज्यामुळे लॅटन्सी (latency) वाढली असती किंवा क्वेरीचा ताण आला असता.
- Consul – एक भक्कम सर्व्हिस-डिस्कव्हरी टूल आहे, परंतु प्लॅटफॉर्मला त्याच्या पूर्ण मेश (mesh) वैशिष्ट्यांची गरज नव्हती.
- etcd – एक स्ट्रॉन्गली कन्सिस्टंट (strongly consistent) की-व्हॅल्यू स्टोअर, ज्यामध्ये एक watch प्रायमिटिव्ह आहे जो की (key) बदलताच क्लायंटला सूचित करतो.
'watch' वैशिष्ट्याने निर्णय निर्णायक ठरवला. प्रत्येक राउटरने वारंवार "काही बदलले आहे का?" असे विचारण्याऐवजी, etcd ने अपडेट पुश करेपर्यंत राउटर शांत बसू लागले. अनावश्यक नेटवर्क ट्रॅफिक संपले आणि प्रत्येक इन्स्टन्सला एकाच वेळी बदलाची माहिती मिळाली.
सिस्टम सुरक्षित ठेवणारे पॅटर्न (Patterns)
केवळ etcd मुळे सर्व धोके दूर झाले नाहीत. इंजिनिअर्सनी तीन पूरक पॅटर्न जोडले:
- Leases – एक एडिटर तात्पुरता बूस्ट सेट करू शकतो (उदा. सहा तासांसाठी कोरियन-पॉप पूलचे वजन वाढवणे). लीज (lease) आपोआप संपते, त्यामुळे मॅन्युअल रोलबॅकशिवाय बूस्ट निघून जातो.
- Compare-and-swap (CAS) – जेव्हा दोन व्यक्ती एकाच वेळी एकच सेटिंग एडिट करतात, तेव्हा CAS एकासाठी स्पष्टपणे अयशस्वी ठरते, ज्यामुळे शांतपणे ओव्हरराईट (overwrite) होण्यापासून बचाव होतो.
- Sidecar process – PHP ला दीर्घकाळ चालणाऱ्या कनेक्शन्ससोबत संघर्ष करावा लागतो. प्रत्येक बॉक्सवर एक छोटा Go sidecar etcd वर लक्ष ठेवतो आणि राउटिंग टेबलचा स्नॅपशॉट शेअर-मेमरी फाईलमध्ये (
/dev/shm) लिहितो. PHP ती स्थानिक फाईल वाचते, ज्यामुळे रिक्वेस्ट हँडलिंग दरम्यान कोणताही नेटवर्क राउंड-ट्रिप टाळता येतो.
आर्किटेक्चरमध्ये अंतर्भूत असलेली लवचिकता (Resilience)
नवीन डिझाइनमध्ये अनेक सुरक्षा कवच जोडली आहेत:
- झिरो-लॅटन्सी रीड्स (Zero-latency reads) – PHP हॉट पाथ स्थानिक मेमरीमधून वाचतो, त्यामुळे रिमोट स्टोअरची वाट पाहत रिक्वेस्ट कधीही थांबत नाही.
- ग्रॅसफुल डिग्रेडेशन (Graceful degradation) – जर etcd डाऊन झाले, तर राउटर शेवटची ज्ञात असलेली चांगली कॉन्फिगरेशन सेवा देत राहतात, ज्यामुळे अचानक आउटेज टाळता येतो.
- विश्वसनीय अपडेट्स – साइडकार रीकनेक्शन लॉजिक हाताळतो आणि etcd कनेक्शन तात्पुरते तुटले तरी कोणताही बदल सुटणार नाही याची खात्री देतो.
प्रत्यक्ष कामात काय बदल झाले
मायग्रेशननंतर, टीमने जुन्या किंवा विसंगत राउटिंग डेटाကြောင့် होणाऱ्या घटनांमध्ये मोठी घट पाहिली. आता एकाच कन्सोलवर सध्याचे कॉन्फिगरेशन दिसते आणि कोणताही बदल एका सेकंदात सर्व आठ क्षेत्रांमध्ये प्रसारित होतो. तात्पुरते बूस्ट्स त्यांची लीज संपल्यावर आपोआप निघून जातात, ज्यामुळे मॅन्युअल क्लिन-अपची गरज उरत नाही आणि मानवी चुका टाळता येतात.
प्रतिवाद: साइडकारचा खर्च (the cost of a sidecar)
साइडकार जोडणे म्हणजे प्रत्येक सर्व्हरवर दुसरी प्रोसेस आणि PHP-केंद्रित स्टॅकमध्ये Go रनटाइम असणे. काही ऑपरेटर्स अतिरिक्त मेमरी वापर आणि दुसऱ्या बायनरीवर लक्ष ठेवण्याच्या गरजेबद्दल काळजी करतात. प्रत्यक्षात, साइडकारचा वापर मर्यादित राहतो आणि मिळणारे फायदे—विशेषतः PHP ने नेटवर्क कॉलसाठी कधीही ब्लॉक होणार नाही याची खात्री—ऑपरेशनल ओव्हरहेडपेक्षा जास्त आहेत.
पुढे काय लक्ष ठेवायचे
मल्टी-रिजन सेवा व्यवस्थापित करणाऱ्या टीम्सनी खालील गोष्टींवर लक्ष दिले पाहिजे:
- etcd हेल्थ मेट्रिक्स – राउटिंग लेयर एकाच स्टोअरवर अवलंबून आहे; क्वोरम स्टेटस (quorum status) आणि लॅटन्सीवर लक्ष ठेवा.
- Lease expiration handling – लीजचा वेळ व्यावसायिक विंडोशी जुळवा; खूप जास्त वेळ असलेली लीज जुना बूस्ट कायम ठेवू शकते.
- Scaling the watch load – जसे राउटर वाढतील, तसे 'watch' कनेक्शन्स वाढतील; त्यानुसार etcd सर्व्हरसाठी क्षमता नियोजन करा.
निष्कर्ष (Takeaway)
ज्या कोणत्याही सेवेला अनेक क्षेत्रांमध्ये जलद आणि समन्वित कॉन्फिगरेशन बदलांची आवश्यकता असते, त्यासाठी etcd चे watch, lease आणि transaction primitives हे फाईल-आधारित कॉन्फिग्स किंवा heavyweight मेशेसना एक हलका आणि प्रबळ सुसंगत (strongly consistent) पर्याय देतात. कॉन्फिगरेशनला पुश-ड्रिव्हन आणि स्वयंचलितपणे स्वच्छ होणाऱ्या (self-cleaning) स्टोअरमध्ये रूपांतरित केल्यामुळे, एका मोठ्या प्रकारच्या तांत्रिक समस्यांचे निर्मूलन झाले आणि प्लॅटफॉर्मला त्याच्या राउटिंग लॉजिकवर रिअल-टाइम नियंत्रण मिळाले.