etcd کے ذریعے ایشیا پیسیفک ویڈیو ٹریفک کی روٹنگ
آٹھ ایشیا پیسیفک مارکیٹوں کو خدمات فراہم کرنے والے ایک ویڈیو اسٹریمنگ پلیٹ فارم نے ریجن کے لحاظ سے مخصوص کنفیگریشن کو etcd میں منتقل کر کے روٹنگ کی بار بار ہونے والی غلطی کو روک دیا۔ روٹنگ کی تبدیلیوں کے پھیلنے کا وقت (propagation time) کم ہو کر تقریباً ایک سیکنڈ رہ گیا۔ اب ایڈیٹرز کوڈ کو چھوئے بغیر چند گھنٹوں کے لیے میوزک پول کو بوسٹ کر سکتے ہیں، اور پلیٹ فارم نے جنوبی کوریائی ناظرین کو ٹوکیو فیڈ بھیجنا بند کر دیا ہے۔
پرانا طریقہ کار کیوں ناکام ہوا
ہر روٹر ہر درخواست کے لیے تین ویلیوز پڑھتا تھا: ٹرینڈنگ پول، زبان کے لحاظ سے مخصوص ٹوکنائزر (tokenizer)، اور ایک فال بیک چین (fallback chain)۔ کاروباری فیصلے—جیسے کسی نئے آرٹسٹ کی تشہیر کرنا، کسی علاقائی تعطل پر ردعمل دینا، یا کسی سفارشاتی الگورتھم (recommendation algorithm) کی جانچ کرنا—ان ویلیوز کو چلا رہے تھے، نہ کہ کوڈ کی تبدیلیاں۔
شروع میں ہر ڈیپلائمنٹ روٹنگ ٹیبل کے ساتھ ایک JSON فائل شامل کرتا تھا۔ کسی واقعے کے دوران، آن کال انجینئر نے ٹریفک کو بیک اپ پول کی طرف موڑنے کے لیے ایک نوڈ پر فائل میں ترمیم کی لیکن باقی سات نوڈز کو اپ ڈیٹ نہیں کیا۔ اس کے نتیجے میں 'کنفیگ ڈرِفٹ' (config drift) پیدا ہوا: آٹھ ممالک مختلف ٹیبلز چلا رہے تھے، اور کوئی بھی واحد ذریعہ "حقیقت" (truth) کی تصدیق نہیں کر سکتا تھا۔ وہ بگ جو سیول کے ناظرین کو ٹوکیو بھیج رہا تھا، برقرار رہا کیونکہ کوڈ وہی رہا؛ صرف چھپی ہوئی کنفیگریشن مختلف تھی۔
واحد ذریعہِ حقیقت (single source of truth) کے طور پر etcd کا انتخاب
ٹیم نے تین آپشنز کا موازنہ کیا:
- SQLite/MySQL – یہ ہر روٹر کو ڈیٹا بیس سے ڈیٹا لینے (poll کرنے) پر مجبور کرتا، جس سے لیٹنسی (latency) بڑھ جاتی یا کوئریز کا بوجھ بڑھ جاتا۔
- Consul – ایک مضبوط سروس ڈسکوری ٹول ہے، لیکن پلیٹ فارم کو اس کے مکمل میش (mesh) فیچرز کی ضرورت نہیں تھی۔
- etcd – ایک مضبوط طور پر کنسسٹنٹ (strongly consistent) کی-ویلیو اسٹور ہے جس میں ایک watch پرائمٹیو ہے جو کلائنٹس کو اس لمحے مطلع کرتا ہے جب کوئی کی (key) تبدیل ہوتی ہے۔
'watch' فیچر نے فیصلہ کن کردار ادا کیا۔ ہر روٹر کے بار بار یہ پوچھنے کے بجائے کہ "کیا کچھ بدلا ہے؟"، روٹرز تب تک خاموش رہے جب تک etcd نے اپ ڈیٹ نہیں بھیجی۔ غیر ضروری نیٹ ورک ٹریفک ختم ہو گئی اور ہر انسٹنس کو بیک وقت تبدیلی کا علم ہو گیا۔
وہ پیٹرنز جو سسٹم کو محفوظ رکھتے ہیں
Etcd اکیلے تمام خطرات کو حل نہیں کرتا تھا۔ انجینئرز نے تین تکمیلی پیٹرنز شامل کیے:
- Leases – ایک ایڈیٹر عارضی بوسٹ سیٹ کر سکتا ہے (مثلاً چھ گھنٹوں کے لیے کورین پاپ پول کا وزن بڑھانا)۔ لیز خود بخود ختم ہو جاتی ہے، اس لیے دستی طور پر رول بیک کیے بغیر بوسٹ ختم ہو جاتا ہے۔
- Compare-and-swap (CAS) – جب دو لوگ بیک وقت ایک ہی سیٹنگ میں ترمیم کرتے ہیں، تو CAS ایک کے لیے واضح طور پر ناکام ہو جاتا ہے، جس سے خاموشی سے اوور رائٹ (overwrite) ہونے سے بچا جا سکتا ہے۔
- Sidecar process – PHP طویل مدتی کنکشنز کے ساتھ جدوجہد کرتا ہے۔ ہر باکس پر ایک چھوٹا سا Go سائیڈ کار (sidecar) etcd پر نظر رکھتا ہے اور روٹنگ ٹیبل کا ایک اسنیپ شاٹ شیئرڈ میموری فائل (
/dev/shm) میں لکھتا ہے۔ PHP اس مقامی فائل کو پڑھتا ہے، جس سے درخواست ہینڈلنگ کے دوران نیٹ ورک کے کسی بھی راؤنڈ ٹرپ سے بچا جا سکتا ہے۔
آرکیٹیکچر میں شامل لچک (Resilience)
نیا ڈیزائن کئی حفاظتی جال فراہم کرتا ہے:
- Zero-latency reads – PHP کا ہاٹ پاتھ مقامی میموری سے پڑھتا ہے، اس لیے درخواستیں کسی ریموٹ اسٹور کا انتظار کرتے ہوئے کبھی نہیں رکتی ہیں۔
- Graceful degradation – اگر etcd ڈاؤن ہو جائے، تو روٹرز آخری معلوم درست کنفیگریشن فراہم کرتے رہتے ہیں، جس سے اچانک تعطل سے بچا جا سکتا ہے۔
- Reliable updates – سائیڈ کار ری کنکشن لاجک کو سنبھالتا ہے اور اس بات کی ضمانت دیتا ہے کہ کوئی بھی تبدیلی مس نہ ہو، چاہے etcd کنکشن عارضی طور پر ٹوٹ بھی جائے۔
عملی طور پر کیا تبدیلی آئی
مائیگریشن کے بعد ٹیم نے پرانی یا غلط روٹنگ ڈیٹا کی وجہ سے ہونے والے واقعات میں نمایاں کمی دیکھی۔ اب ایک ہی کنسول موجودہ کنفیگریشن دکھاتا ہے، اور کوئی بھی ترمیم ایک سیکنڈ کے اندر تمام آٹھ ریجنز تک پہنچ جاتی ہے۔ عارضی بوسٹس اپنی لیز ختم ہونے پر خود بخود ختم ہو جاتے ہیں، جس سے دستی صفائی کے مراحل ختم ہو جاتے ہیں جو پہلے انسانی غلطی کا باعث بنتے تھے۔
ایک دوسرا پہلو: سائیڈ کار کی قیمت
سائیڈ کار شامل کرنے کا مطلب ہے فی سرور ایک دوسرا پروسیس اور PHP پر مبنی اسٹیک میں Go رن ٹائم۔ کچھ آپریٹرز اضافی میموری کے استعمال اور ایک اور بائنری کی نگرانی کی ضرورت کے بارے میں فکر مند ہوتے ہیں۔ عملی طور پر سائیڈ کار کا اثر (footprint) معمولی رہتا ہے، اور بھروسہ مندی کے فوائد—خاص طور پر یہ ضمانت کہ PHP نیٹ ورک کال پر کبھی بلاک نہیں ہوگا—آپریشنل بوجھ سے کہیں زیادہ ہیں۔
آگے کن چیزوں پر نظر رکھنی چاہیے
ایسی ٹیمیں جو ملٹی ریجن سروسز کا انتظام کرتی ہیں، انہیں درج ذیل چیزوں کی نگرانی کرنی چاہیے:
- etcd health metrics – روٹنگ لیئر ایک واحد اسٹور پر منحصر ہے؛ کورم (quorum) کی صورتحال اور لیٹنسی پر نظر رکھیں۔
- Lease expiration handling – لیز کے اوقات کو کاروباری دورانیے کے مطابق رکھیں؛ بہت طویل لیز پرانی بوسٹس کو برقرار رکھتی ہے۔
- Scaling the watch load – جیسے جیسے روٹرز بڑھتے ہیں، 'watch' کنکشنز بھی بڑھتے ہیں؛ اسی کے مطابق etcd سرورز کی گنجائش کا منصوبہ بنائیں۔
خلاصہ
کسی بھی ایسی سروس کے لیے جسے متعدد ریجنز میں تیز رفتار اور مربوط کنفیگریشن تبدیلیوں کی ضرورت ہو، etcd کے watch، lease، اور transaction primitives، فائل پر مبنی کنفیگز یا بھاری بھرکم میشز کے مقابلے میں ایک ہلکا پھلکا اور مضبوط تسلسل (strongly consistent) فراہم کرنے والا متبادل پیش کرتے ہیں۔ کنفیگریشن کو ایک پش-ڈریون (push-driven) اور خودکار صفائی کرنے والے (self-cleaning) اسٹور میں تبدیل کرنے سے حادثات کی ایک پوری قسم کا خاتمہ ہو گیا اور پلیٹ فارم کو اس کے روٹنگ لاجک پر ریئل ٹائم کنٹرول حاصل ہو گیا۔