etcd के साथ एशिया पैसिफिक वीडियो ट्रैफिक को रूट करना
आठ एशिया-पैसिफिक बाजारों में सेवा देने वाले एक वीडियो-स्ट्रीमिंग प्लेटफॉर्म ने क्षेत्र-विशिष्ट कॉन्फ़िगरेशन को etcd में स्थानांतरित करके बार-बार होने वाली रूटिंग की गलती को रोक दिया। रूटिंग परिवर्तनों के प्रसार का समय (propagation time) घटकर लगभग एक सेकंड रह गया। अब संपादक बिना कोड छुए कुछ घंटों के लिए म्यूजिक पूल को बढ़ावा दे सकते थे, और प्लेटफॉर्म ने दक्षिण-कोरियाई दर्शकों को टोक्यो फीड भेजना बंद कर दिया।
पुराना तरीका क्यों विफल रहा
प्रत्येक राउटर हर अनुरोध के लिए तीन मान पढ़ता था: ट्रेंडिंग पूल, भाषा-विशिष्ट टोकनाइज़र, और एक फॉलबैक चेन। कोड परिवर्तनों के बजाय व्यावसायिक निर्णय—जैसे किसी नए कलाकार को प्रमोट करना, क्षेत्रीय आउटेज पर प्रतिक्रिया देना, या अनुशंसा एल्गोरिदम (recommendation algorithm) का परीक्षण करना—इन मानों को संचालित करते थे।
शुरुआत में, प्रत्येक डिप्लॉयमेंट रूटिंग टेबल के साथ एक JSON फ़ाइल को बंडल करता था। किसी घटना के दौरान, ऑन-कॉल इंजीनियर ने ट्रैफिक को बैकअप पूल पर भेजने के लिए एक नोड पर फ़ाइल को संपादित किया, लेकिन अन्य सात नोड्स को अपडेट नहीं किया। कॉन्फ़िगरेशन ड्रिफ्ट (Config drift) की समस्या उत्पन्न हुई: आठ देश अलग-अलग टेबल चला रहे थे, और कोई भी एकल स्रोत "सत्य" (truth) को सत्यापित नहीं कर पा रहा था। सियोल के दर्शकों को टोक्यो भेजने वाला बग बना रहा क्योंकि कोड वही रहा; केवल छिपी हुई कॉन्फ़िगरेशन अलग थी।
सत्य के एकल स्रोत (single source of truth) के रूप में etcd का चयन
टीम ने तीन विकल्पों की तुलना की:
- SQLite/MySQL – यह प्रत्येक राउटर को डेटाबेस को पोल करने के लिए मजबूर करता, जिससे लेटेंसी बढ़ती या क्वेरीज़ की बाढ़ आ जाती।
- Consul – एक ठोस सर्विस-डिस्कवरी टूल, लेकिन प्लेटफॉर्म को इसके पूर्ण मेश (mesh) फीचर्स की आवश्यकता नहीं थी।
- etcd – एक स्ट्रॉन्गली कंसिस्टेंट (strongly consistent) की-वैल्यू स्टोर जिसमें एक watch प्रिमिटिव है जो किसी कुंजी (key) के बदलते ही क्लाइंट्स को सूचित कर देता है।
watch फीचर ने बाजी पलट दी। प्रत्येक राउटर द्वारा बार-बार "क्या कुछ बदला है?" पूछने के बजाय, राउटर तब तक निष्क्रिय रहे जब तक etcd ने अपडेट नहीं भेजा। अनावश्यक नेटवर्क ट्रैफिक खत्म हो गया और प्रत्येक इंस्टेंस ने एक साथ बदलाव के बारे में जान लिया।
सिस्टम को सुरक्षित रखने वाले पैटर्न
केवल etcd ने सभी जोखिमों को हल नहीं किया। इंजीनियरों ने तीन पूरक पैटर्न जोड़े:
- Leases – एक संपादक एक अस्थायी बूस्ट सेट कर सकता है (जैसे, छह घंटे के लिए कोरियन-पॉप पूल का वेटेज बढ़ाना)। लीज़ अपने आप समाप्त हो जाती है, इसलिए बिना किसी मैनुअल रोलबैक के बूस्ट गायब हो जाता है।
- Compare-and-swap (CAS) – जब दो लोग एक साथ एक ही सेटिंग को संपादित करते हैं, तो CAS एक के लिए विफल हो जाता है, जिससे साइलेंट ओवरराइट (silent overwrites) को रोका जा सकता है।
- Sidecar process – PHP लंबे समय तक चलने वाले कनेक्शन के साथ संघर्ष करता है। प्रत्येक बॉक्स पर एक छोटा Go साइडकार etcd को मॉनिटर करता है और रूटिंग टेबल का एक स्नैपशॉट साझा-मेमोरी फ़ाइल (
/dev/shm) में लिखता है। PHP उस स्थानीय फ़ाइल को पढ़ता है, जिससे अनुरोध हैंडलिंग के दौरान किसी भी नेटवर्क राउंड-ट्रिप से बचा जा सके।
आर्किटेक्चर में निर्मित लचीलापन
नया डिज़ाइन कई सुरक्षा जाल (safety nets) जोड़ता है:
- Zero-latency reads – PHP हॉट पाथ स्थानीय मेमोरी से पढ़ता है, इसलिए अनुरोधों को रिमोट स्टोर का इंतज़ार करते हुए कभी रुकना नहीं पड़ता।
- Graceful degradation – यदि etcd डाउन हो जाता है, तो राउटर अंतिम ज्ञात सही कॉन्फ़िगरेशन को सर्व करना जारी रखते हैं, जिससे अचानक आउटेज से बचा जा सके।
- Reliable updates – साइडकार रीकनेक्शन लॉजिक को संभालता है और यह सुनिश्चित करता है कि कोई भी बदलाव मिस न हो, भले ही etcd कनेक्शन अस्थायी रूप से टूट जाए।
ज़मीनी स्तर पर क्या बदला
माइग्रेशन के बाद टीम ने पुराने या गलत रूटिंग डेटा के कारण होने वाली घटनाओं में भारी कमी देखी। अब एक एकल कंसोल वर्तमान कॉन्फ़िगरेशन दिखाता है, और कोई भी संपादन एक सेकंड के भीतर सभी आठ क्षेत्रों में फैल जाता है। अस्थायी बूस्ट उनकी लीज़ समाप्त होने पर अपने आप साफ हो जाते हैं, जिससे उन मैनुअल सफाई चरणों की आवश्यकता समाप्त हो जाती है जो पहले मानवीय त्रुटि का कारण बनते थे।
काउंटर-पॉइंट: साइडकार की लागत
साइडकार जोड़ने का मतलब है प्रति सर्वर एक दूसरा प्रोसेस और PHP-केंद्रित स्टैक में एक Go रनटाइम। कुछ ऑपरेटर अतिरिक्त मेमोरी उपयोग और दूसरे बाइनरी की निगरानी करने की आवश्यकता के बारे में चिंतित रहते हैं। व्यवहार में, साइडकार का फुटप्रिंट मामूली रहता है, और विश्वसनीयता के लाभ—विशेष रूप से यह गारंटी कि PHP कभी भी नेटवर्क कॉल पर ब्लॉक नहीं होगा—परिचालन ओवरहेड (operational overhead) से कहीं अधिक हैं।
आगे क्या देखें
मल्टी-रीजन सेवाओं का प्रबंधन करने वाली टीमों को इन पर नज़र रखनी चाहिए:
- etcd health metrics – रूटिंग लेयर एक एकल स्टोर पर टिकी है; क्वोरम (quorum) स्थिति और लेटेंसी पर नज़र रखें।
- Lease expiration handling – लीज़ के समय को व्यावसायिक विंडो के साथ मेल करें; बहुत लंबी लीज़ पुराने बूस्ट को बनाए रखती है।
- Scaling the watch load – जैसे-जैसे राउटर बढ़ते हैं, वॉच कनेक्शन भी बढ़ते हैं; etcd सर्वर के लिए क्षमता की योजना उसी के अनुसार बनाएं।
निष्कर्ष
किसी भी ऐसी सेवा के लिए जिसे कई क्षेत्रों (regions) में तेज़ और समन्वित कॉन्फ़िगरेशन परिवर्तनों की आवश्यकता होती है, etcd के watch, lease, और transaction primitives, फ़ाइल-आधारित कॉन्फ़िग्स या भारी-भरकम मेष (meshes) के मुकाबले एक हल्का और मजबूती से सुसंगत (strongly consistent) विकल्प प्रदान करते हैं। कॉन्फ़िगरेशन को पुश-ड्रिवन (push-driven) और सेल्फ-क्लीनिंग (self-cleaning) स्टोर में बदलने से घटनाओं (incidents) की एक पूरी श्रेणी समाप्त हो गई और प्लेटफॉर्म को उसके रूटिंग लॉजिक (routing logic) पर रीयल-टाइम नियंत्रण प्राप्त हुआ।