ہم نے deploys کو صفر 502 errors تک کیسے پہنچایا

Mythex کے backend کا ہر deploy کرتے وقت چند درخواستیں 502 Bad Gateway کے ساتھ ناکام ہو جاتی تھیں۔ زیادہ نہیں — لیکن deploy کے دوران 502 کا مطلب ہے کسی کا کلک بے اثر رہا، یا کوئی build جسے وہ دیکھ رہا تھا لمحہ بھر کو رک گیا۔ ہم نے اسے دو الگ مسائل تک پہنچایا: ایک خود کو ٹھیک کرنے والا watchdog جو ہمارے deploys سے لڑتا تھا، اور ایک فاصلہ جو اس وقت کا تھا جب سرور سننا بند کرتا تھا اور جب load balancer اسے ٹریفک بھیجنا بند کرتا تھا۔ درستگی کے بعد لگاتار تین production deploys میں گنتی 10 سے 6 اور پھر 0 پر آ گئی۔

ترتیب

ہماری API اور orchestrator ایک AWS Application Load Balancer (ALB) کے پیچھے سرورز کے ایک چھوٹے گروپ پر containers کے طور پر چلتے ہیں۔ ایک deploy ایک وقت میں ایک سرور کو اپ ڈیٹ کرتا ہے: پرانے containers کو خالی کرتا ہے، نئے شروع کرتا ہے، اور آگے بڑھتا ہے۔ ہر سرور پر ایک watchdog جانچتا ہے کہ containers چل رہے ہیں اور جو نہیں چل رہا اسے دوبارہ شروع کرتا ہے — یہ اس لیے ہے کہ رات 3 بجے کا کریش ہوا process کسی کو جگائے بغیر واپس آ جائے۔

دونوں اپنی جگہ معقول ہیں۔ مل کر وہ معقول نہیں رہے۔

مسئلہ 1: watchdog deploy سے دوڑ لگاتا تھا

Watchdog ہر منٹ ایک بار چلتا تھا اور ایک ناکام health check پر “ٹھیک” کرنا شروع کر دیتا تھا۔ deploy جان بوجھ کر 150 سیکنڈ تک سروسز کو خالی کرتا ہے — اس دوران health check کا ناکام ہونا متوقع ہے۔ تو watchdog ہر deploy کے دوران چل پڑتا تھا۔

زیادہ تر وقت وہ دوڑ بے ضرر ہار جاتا تھا۔ ایک بار وہ جیت گیا: اس نے deploy کے بیچ میں compose فائل دوبارہ لکھ دی (وہ فائل جو بتاتی ہے کون سے containers چلنے چاہئیں)، اور ایک سرور کو بغیر کسی gateway container کے چھوڑ دیا — جبکہ deploy job کامیابی کی اطلاع دے رہا تھا۔

حل:

• ایک lock۔ Deploy اب سرور کے bootstrap script والا وہی file lock لیتا ہے، تاکہ watchdog اور deploy کبھی ایک ساتھ نہ چلیں۔
• ایک کے بجائے چار اشارے۔ Watchdog عمل کرنے سے پہلے لگاتار چار ناکام checks مانگتا ہے۔ خالی ہوتی سروس اب مردہ نظر نہیں آتی۔
• ایک تعریف۔ Compose فائل کا اب ایک ہی ماخذ ہے، جو سرورز پر شائع ہوتا ہے، بجائے ان نقلوں کے جو الگ ہو سکتی تھیں۔
• جانچیں، بھروسہ نہ کریں۔ Deploy job اب اس لیے کامیاب نہیں ہوتا کہ ایک command واپس آ گئی۔ کامیاب ہونے سے پہلے وہ ہر سرور کی API، orchestrator، gateway اور publish worker کو جانچتا ہے۔

مسئلہ 2: سرور ٹریفک سے پہلے چلا گیا

دوسرا مسئلہ زیادہ خاموش تھا۔ جب deploy ایک سرور کو خالی کرتا ہے تو سرور اپنے health endpoint پر 503 دینا شروع کرتا ہے تاکہ load balancer اسے rotation سے نکال دے۔ ہمارا سرور یہ 5 سیکنڈ تک کرتا تھا، پھر بند ہو جاتا۔

مگر ALB health صرف وقفے وقفے سے جانچتا تھا، اور کسی target کو روکنے سے پہلے لگاتار کئی ناکام checks چاہتا تھا — آغاز سے انجام تک تقریباً 60 سیکنڈ تک۔ تو تقریباً 55 سیکنڈ تک load balancer اصل درخواستیں ایک ایسے سرور کو بھیجتا رہا جو سننا بند کر چکا تھا۔ یہی ہمارے 502s تھے۔

حل یہ تھا کہ دونوں timelines کو ہم آہنگ کیا جائے:

• Target group اب ہر 5 سیکنڈ میں جانچتا ہے اور 2 ناکامیوں کے بعد target کو unhealthy نشان زد کرتا ہے — نوٹس کرنے میں تقریباً 10 سیکنڈ۔
• Drain health checks میں ناکامی شروع ہونے کے بعد 15 سیکنڈ تک اصل ٹریفک کی خدمت جاری رکھتا ہے، تاکہ ہمیشہ اوورلیپ رہے۔
• یہ settings اس script میں رہتی ہیں جو infrastructure فراہم کرتا ہے، کسی console میں نہیں جس پر کسی نے ایک بار کلک کیا ہو۔

نمبروں کو ایک دوسرے کو سہارا دینے کے لیے رکھنا

ایسے timeouts ایک دوسرے پر منحصر ہوتے ہیں۔ Drain کو اس وقت سے لمبا ہونا چاہیے جو balancer کو نوٹس کرنے میں لگتا ہے؛ drain اور shutdown مل کر container کے زبردستی ختم ہونے سے پہلے مکمل ہونے چاہئیں۔ چھ مہینے بعد کوئی ایک نمبر بدل دے اور خاموشی سے بگ واپس لے آئے، یہ آسان ہے۔

اس لیے ہم نے ان تعلقات کو tests کے طور پر لکھا: drain کو health-check کے وقفے ضرب ناکامی کی حد سے لمبا ہونا چاہیے؛ دوبارہ healthy نشان ہونے کا وقت مختصر رہنا چاہیے؛ پورا drain container کی stop grace period کے اندر فٹ ہونا چاہیے۔ دوسرے نمبروں کے بغیر ایک نمبر بدلیں تو CI ناکام ہو جاتا ہے۔ ہم نے tests کو بھی mutation-test کیا — ہر نمبر کو غلط قدر پر بدلا اور دیکھا کہ کوئی test اسے پکڑتا ہے یا نہیں۔

deploy کو ناپنا آسانی سے غلط ہو جاتا ہے

ہماری پہلی پیمائش نے بتایا کہ ایک صاف deploy تقریباً 3% ٹوٹا ہوا تھا۔ ایسا نہیں تھا۔ ہم ہر غیر 200 جواب گن رہے تھے، اور drain کے دوران health endpoint سے آنے والا 503 ناکامی نہیں — drain کا اپنا کام ہے، جو balancer کو بتاتا ہے کہ اس سرور کو نہ چنے، جبکہ وہ اصل درخواستیں پھر بھی پیش کرتا رہتا ہے۔

صارف جو محسوس کرتا ہے وہ 502 ہے: درخواست کسی تک پہنچی ہی نہیں۔ صرف انہیں گننے سے اصل تصویر ملی — تین production deploys میں 10، پھر 6، پھر 0۔

ہم نے اس سے کیا سیکھا

• خود ٹھیک ہونے والے نظام کو منصوبہ بند downtime کا علم ہونا چاہیے۔ وہ watchdog جو deploy اور کریش میں فرق نہ کر سکے، آخرکار deploy سے لڑے گا۔
• Drain ایک ہاتھ ملانا ہے۔ سرور کو تب تک خدمت جاری رکھنی ہوتی ہے جب تک load balancer ثابت طور پر ٹریفک بھیجنا بند نہ کر دے، اور وہ وقت balancer پر طے ہوتا ہے، سرور پر نہیں۔
• Invariants کو tests میں لکھیں۔ آپریشنل نمبر بگڑ جاتے ہیں۔ جو tests انہیں ایک دوسرے سے جوڑتے ہیں وہ نہیں بگڑتے۔
• ناپنے سے پہلے طے کریں کہ کیا ناپ رہے ہیں۔ “غلطیاں” غلط پیمانہ تھا؛ “وہ درخواستیں جو کسی تک نہ پہنچیں” درست پیمانہ تھا۔

اگر آپ Mythex پر ایپ publish کرتے ہیں تو ان میں سے کچھ بھی آپ کو نظر نہیں آتا — یہی مقصد ہے۔ متعلقہ: آپ کی published ایپ دوبارہ publish کرتے وقت بھی کیسے چلتی رہتی ہے۔