Yandex.Market تلاش کیسے کام کرتی ہے اور اگر سرورز میں سے ایک ناکام ہوجاتا ہے تو کیا ہوتا ہے۔

ہیلو، میرا نام Evgeniy ہے. میں Yandex.Market سرچ انفراسٹرکچر میں کام کرتا ہوں۔ میں حبر برادری کو مارکیٹ کے اندرونی باورچی خانے کے بارے میں بتانا چاہتا ہوں - اور میرے پاس بتانے کے لیے بہت کچھ ہے۔ سب سے پہلے، مارکیٹ کی تلاش کیسے کام کرتی ہے، عمل اور فن تعمیر۔ ہم ہنگامی حالات سے کیسے نمٹتے ہیں: اگر ایک سرور بند ہو جائے تو کیا ہوتا ہے؟ اگر 100 ایسے سرورز ہوں تو کیا ہوگا؟

آپ یہ بھی سیکھیں گے کہ ہم سرورز کے ایک گروپ پر ایک ساتھ نئی فعالیت کیسے نافذ کرتے ہیں۔ اور ہم کس طرح پیچیدہ خدمات کو براہ راست پیداوار میں جانچتے ہیں، بغیر صارفین کو کوئی تکلیف پہنچائے۔ عام طور پر، مارکیٹ کی تلاش کس طرح کام کرتی ہے تاکہ ہر ایک کے پاس اچھا وقت ہو۔

ہمارے بارے میں تھوڑا سا: ہم کون سا مسئلہ حل کرتے ہیں۔

جب آپ متن درج کرتے ہیں، پیرامیٹرز کے لحاظ سے کسی پروڈکٹ کو تلاش کرتے ہیں، یا مختلف اسٹورز میں قیمتوں کا موازنہ کرتے ہیں، تو تمام درخواستیں سرچ سروس کو بھیجی جاتی ہیں۔ تلاش مارکیٹ میں سب سے بڑی خدمت ہے۔

ہم تلاش کی تمام درخواستوں پر کارروائی کرتے ہیں: market.yandex.ru، beru.ru، Supercheck سروس، Yandex.Advisor، موبائل ایپلیکیشنز سے۔ ہم yandex.ru پر تلاش کے نتائج میں مصنوعات کی پیشکش بھی شامل کرتے ہیں۔

سرچ سروس سے میرا مطلب صرف تلاش ہی نہیں بلکہ مارکیٹ پر موجود تمام پیشکشوں کے ساتھ ایک ڈیٹا بیس بھی ہے۔ پیمانہ یہ ہے: روزانہ ایک ارب سے زیادہ تلاش کی درخواستوں پر کارروائی کی جاتی ہے۔ اور ہر چیز کو بغیر کسی رکاوٹ کے تیزی سے کام کرنا چاہئے اور ہمیشہ مطلوبہ نتیجہ پیدا کرنا چاہئے۔

کیا ہے: مارکیٹ کا فن تعمیر

میں مارکیٹ کے موجودہ فن تعمیر کو مختصراً بیان کروں گا۔ اسے نیچے دیے گئے خاکے سے تقریباً بیان کیا جا سکتا ہے:

ہم کہتے ہیں کہ ایک پارٹنر اسٹور ہمارے پاس آتا ہے۔ وہ کہتا ہے کہ میں ایک کھلونا بیچنا چاہتا ہوں: یہ شریر بلی جس کے ساتھ squeaker ہے۔ اور ایک اور غصے والی بلی بغیر چیخے۔ اور صرف ایک بلی. پھر اسٹور کو پیشکشیں تیار کرنے کی ضرورت ہے جس کے لیے مارکیٹ تلاش کرتی ہے۔ سٹور پیشکشوں کے ساتھ ایک خصوصی ایکس ایم ایل تیار کرتا ہے اور ملحق انٹرفیس کے ذریعے اس ایکس ایم ایل کے راستے کو بتاتا ہے۔ انڈیکسر پھر وقتاً فوقتاً اس ایکس ایم ایل کو ڈاؤن لوڈ کرتا ہے، غلطیوں کی جانچ کرتا ہے اور تمام معلومات کو ایک بڑے ڈیٹا بیس میں محفوظ کرتا ہے۔

اس طرح کے بہت سے محفوظ شدہ ایکس ایم ایل ہیں۔ اس ڈیٹا بیس سے سرچ انڈیکس بنایا جاتا ہے۔ انڈیکس اندرونی شکل میں محفوظ ہے۔ انڈیکس بنانے کے بعد، لے آؤٹ سروس اسے سرچ سرورز پر اپ لوڈ کرتی ہے۔

نتیجتاً، ڈیٹا بیس میں ایک غصے والی بلی، جس میں چیختا ہے، ظاہر ہوتا ہے، اور بلی کا انڈیکس سرور پر ظاہر ہوتا ہے۔

میں آپ کو بتاؤں گا کہ ہم کس طرح تلاش کے فن تعمیر کے حصے میں بلی کو تلاش کرتے ہیں۔

مارکیٹ کی تلاش کا فن تعمیر

ہم مائیکرو سروسز کی دنیا میں رہتے ہیں: ہر آنے والی درخواست market.yandex.ru بہت سارے سوالات کا سبب بنتا ہے، اور درجنوں خدمات ان کی پروسیسنگ میں شامل ہیں۔ خاکہ صرف چند دکھاتا ہے:

آسان درخواست پروسیسنگ اسکیم

ہر سروس میں ایک حیرت انگیز چیز ہوتی ہے - اس کا اپنا بیلنس ایک منفرد نام کے ساتھ:

بیلنسر ہمیں سروس کے انتظام میں زیادہ لچک دیتا ہے: آپ، مثال کے طور پر، سرورز کو بند کر سکتے ہیں، جو اکثر اپ ڈیٹس کے لیے درکار ہوتے ہیں۔ بیلنسر دیکھتا ہے کہ سرور دستیاب نہیں ہے اور خود بخود درخواستوں کو دوسرے سرورز یا ڈیٹا سینٹرز پر بھیج دیتا ہے۔ سرور کو شامل کرتے یا ہٹاتے وقت، لوڈ خود بخود سرورز کے درمیان دوبارہ تقسیم ہو جاتا ہے۔

بیلنسر کا منفرد نام ڈیٹا سینٹر پر منحصر نہیں ہے۔ جب سروس A B سے درخواست کرتا ہے، تو بذریعہ ڈیفالٹ بیلنس B درخواست کو موجودہ ڈیٹا سینٹر کو بھیج دیتا ہے۔ اگر سروس دستیاب نہیں ہے یا موجودہ ڈیٹا سینٹر میں موجود نہیں ہے، تو درخواست کو دوسرے ڈیٹا سینٹرز پر بھیج دیا جاتا ہے۔

تمام ڈیٹا سینٹرز کے لیے ایک واحد FQDN سروس A کو مقامات سے مکمل طور پر خلاصہ کرنے کی اجازت دیتا ہے۔ سروس B کے لیے اس کی درخواست پر ہمیشہ عمل کیا جائے گا۔ استثناء اس صورت میں ہے جب سروس تمام ڈیٹا سینٹرز میں واقع ہو۔

لیکن اس بیلنس کے ساتھ ہر چیز اتنی گلابی نہیں ہے: ہمارے پاس ایک اضافی انٹرمیڈیٹ جزو ہے۔ بیلنس غیر مستحکم ہو سکتا ہے، اور یہ مسئلہ بے کار سرورز کے ذریعے حل کیا جاتا ہے۔ خدمات A اور B کے درمیان ایک اضافی تاخیر بھی ہوتی ہے۔ لیکن عملی طور پر یہ 1 ms سے کم ہے اور زیادہ تر خدمات کے لیے یہ اہم نہیں ہے۔

غیر متوقع سے نمٹنا: سرچ سروس میں توازن اور لچک

تصور کریں کہ ایک گراوٹ ہے: آپ کو ایک بلی کو تلاش کرنے کی ضرورت ہے جس میں چیکر ہے، لیکن سرور کریش ہو جاتا ہے۔ یا 100 سرورز۔ کیسے نکلیں؟ کیا ہم واقعی صارف کو بلی کے بغیر چھوڑنے جا رہے ہیں؟

صورتحال خوفناک ہے لیکن ہم اس کے لیے تیار ہیں۔ میں آپ کو ترتیب سے بتاؤں گا۔

تلاش کا بنیادی ڈھانچہ کئی ڈیٹا سینٹرز میں واقع ہے:

ڈیزائن کرتے وقت، ہم ایک ڈیٹا سینٹر کو بند کرنے کا امکان شامل کرتے ہیں۔ زندگی حیرتوں سے بھری ہوئی ہے - مثال کے طور پر، ایک کھدائی کرنے والا زیر زمین کیبل کاٹ سکتا ہے (ہاں، ایسا ہوا)۔ بقیہ ڈیٹا سینٹرز کی گنجائش چوٹی کے بوجھ کو برداشت کرنے کے لیے کافی ہونی چاہیے۔

آئیے ایک ہی ڈیٹا سینٹر پر غور کریں۔ ہر ڈیٹا سینٹر میں ایک ہی بیلنس آپریشن اسکیم ہے:

ایک بیلنس کم از کم تین جسمانی سرورز ہیں۔ یہ فالتو پن وشوسنییتا کے لیے بنایا گیا ہے۔ بیلنسرز HAProx پر چلتے ہیں۔

ہم نے HAProx کو اس کی اعلی کارکردگی، کم وسائل کی ضروریات اور وسیع فعالیت کی وجہ سے منتخب کیا۔ ہمارا سرچ سافٹ ویئر ہر سرور کے اندر چلتا ہے۔

ایک سرور کے ناکام ہونے کا امکان کم ہے۔ لیکن اگر آپ کے پاس بہت سے سرور ہیں تو کم از کم ایک کے نیچے جانے کا امکان بڑھ جاتا ہے۔

حقیقت میں یہی ہوتا ہے: سرورز کریش۔ لہذا، تمام سرورز کی حیثیت کو مسلسل مانیٹر کرنا ضروری ہے۔ اگر سرور جواب دینا بند کر دیتا ہے، تو یہ خود بخود ٹریفک سے منقطع ہو جاتا ہے۔ اس مقصد کے لیے، HAProxy میں بلٹ ان ہیلتھ چیک ہے۔ یہ HTTP درخواست "/ping" کے ساتھ سیکنڈ میں ایک بار تمام سرورز پر جاتا ہے۔

HAProxy کی ایک اور خصوصیت: ایجنٹ چیک آپ کو تمام سرورز کو یکساں طور پر لوڈ کرنے کی اجازت دیتا ہے۔ ایسا کرنے کے لیے، HAProxy تمام سرورز سے منسلک ہوتا ہے، اور وہ اپنا وزن 1 سے 100 تک کے موجودہ لوڈ کے لحاظ سے واپس کرتے ہیں۔ وزن کا حساب پروسیسنگ کے لیے قطار میں موجود درخواستوں کی تعداد اور پروسیسر پر بوجھ کی بنیاد پر کیا جاتا ہے۔

اب بلی کو تلاش کرنے کے بارے میں۔ درخواستوں میں تلاش کے نتائج جیسے: /search?text=angry+cat. تلاش کے تیز ہونے کے لیے، بلی کا پورا انڈیکس RAM میں فٹ ہونا چاہیے۔ یہاں تک کہ SSD سے پڑھنا بھی تیز نہیں ہے۔

ایک زمانے میں، پیشکش کا ڈیٹا بیس چھوٹا تھا، اور اس کے لیے ایک سرور کی ریم کافی تھی۔ جیسے جیسے پیشکش کی بنیاد بڑھتی گئی، سب کچھ اب اس RAM میں فٹ نہیں رہتا، اور ڈیٹا کو دو حصوں میں تقسیم کیا گیا: شارڈ 1 اور شارڈ 2۔

لیکن یہ ہمیشہ ہوتا ہے: کوئی بھی حل، یہاں تک کہ ایک اچھا، دوسرے مسائل کو جنم دیتا ہے۔

بیلنس اب بھی کسی بھی سرور پر چلا گیا۔ لیکن جس مشین پر درخواست آئی، وہاں انڈیکس کا نصف ہی تھا۔ باقی دوسرے سرورز پر تھا۔ لہذا، سرور کو کسی ہمسایہ مشین پر جانا پڑا۔ دونوں سرورز سے ڈیٹا حاصل کرنے کے بعد، نتائج کو یکجا کر کے دوبارہ درجہ بندی کیا گیا۔

چونکہ بیلنسر درخواستوں کو یکساں طور پر تقسیم کرتا ہے، اس لیے تمام سرورز ری رینکنگ میں مصروف تھے، نہ کہ صرف ڈیٹا بھیجنے میں۔

مسئلہ اس وقت پیش آیا جب پڑوسی سرور دستیاب نہ تھا۔ حل یہ تھا کہ "پڑوسی" سرور کے طور پر مختلف ترجیحات کے ساتھ متعدد سرورز کی وضاحت کی جائے۔ پہلے، درخواست موجودہ ریک میں سرورز کو بھیجی گئی۔ اگر کوئی جواب نہیں تھا، تو درخواست اس ڈیٹا سینٹر کے تمام سرورز کو بھیج دی گئی تھی۔ اور آخر میں، درخواست دوسرے ڈیٹا سینٹرز تک گئی۔
جیسے جیسے تجاویز کی تعداد میں اضافہ ہوا، ڈیٹا کو چار حصوں میں تقسیم کیا گیا۔ لیکن یہ حد نہیں تھی۔

فی الحال، آٹھ شارڈز کی ترتیب استعمال کی جاتی ہے۔ اس کے علاوہ، مزید میموری کو بچانے کے لیے، انڈیکس کو سرچ پارٹ (جو سرچ کرنے کے لیے استعمال کیا جاتا ہے) اور ایک ٹکڑا حصہ (جو تلاش میں شامل نہیں ہے) میں تقسیم کیا گیا تھا۔

ایک سرور میں صرف ایک شارڈ کی معلومات ہوتی ہیں۔ لہذا، مکمل انڈیکس تلاش کرنے کے لیے، آپ کو مختلف شارڈز پر مشتمل آٹھ سرورز پر تلاش کرنے کی ضرورت ہے۔

سرورز کو کلسٹرز میں گروپ کیا گیا ہے۔ ہر کلسٹر میں آٹھ سرچ انجن اور ایک اسنیپٹ سرور ہوتا ہے۔

اسنیپٹ سرور جامد ڈیٹا کے ساتھ کلیدی قدر کا ڈیٹا بیس چلاتا ہے۔ دستاویزات جاری کرنے کے لیے ان کی ضرورت ہوتی ہے، مثال کے طور پر، ایک بلی کی تفصیل جس کے ساتھ squeaker ہے۔ ڈیٹا کو خاص طور پر علیحدہ سرور پر منتقل کیا جاتا ہے تاکہ سرچ سرورز کی میموری کو لوڈ نہ کیا جائے۔

چونکہ دستاویز کی شناخت صرف ایک انڈیکس کے اندر منفرد ہوتی ہے، اس لیے ایسی صورت حال پیدا ہو سکتی ہے جب ٹکڑوں میں کوئی دستاویزات نہ ہوں۔ ٹھیک ہے، یا یہ کہ ایک آئی ڈی کے لیے مختلف مواد ہوگا۔ لہذا، تلاش کے کام کرنے اور نتائج کو واپس کرنے کے لیے، پورے کلسٹر میں مستقل مزاجی کی ضرورت تھی۔ میں آپ کو ذیل میں بتاؤں گا کہ ہم مستقل مزاجی کی نگرانی کیسے کرتے ہیں۔

تلاش کا خود ساختہ اس طرح ہے: تلاش کی درخواست آٹھ سرورز میں سے کسی پر بھی آسکتی ہے۔ فرض کریں کہ وہ سرور 1 پر آیا ہے۔ یہ سرور تمام دلائل پر کارروائی کرتا ہے اور سمجھتا ہے کہ کیا اور کیسے تلاش کرنا ہے۔ آنے والی درخواست پر منحصر ہے، سرور ضروری معلومات کے لیے بیرونی خدمات سے اضافی درخواستیں کر سکتا ہے۔ ایک درخواست کے بعد بیرونی خدمات کے لیے دس درخواستوں تک کی جا سکتی ہے۔

ضروری معلومات جمع کرنے کے بعد، پیشکش کے ڈیٹا بیس میں تلاش شروع ہوتی ہے۔ ایسا کرنے کے لیے، کلسٹر کے تمام آٹھ سرورز پر ذیلی سوالات کیے جاتے ہیں۔

جوابات موصول ہونے کے بعد، نتائج کو یکجا کر دیا جاتا ہے۔ آخر میں، نتائج پیدا کرنے کے لیے اسنیپٹ سرور کے لیے کئی مزید ذیلی سوالات کی ضرورت پڑ سکتی ہے۔

کلسٹر کے اندر تلاش کے سوالات اس طرح نظر آتے ہیں: /shard1?text=angry+cat. اس کے علاوہ، فارم کے ذیلی سوالات کلسٹر کے اندر موجود تمام سرورز کے درمیان ایک سیکنڈ میں مسلسل بنائے جاتے ہیں: /حالت.

درخواست کریں۔ /حالت ایسی صورتحال کا پتہ لگاتا ہے جہاں سرور دستیاب نہیں ہے۔

یہ اس بات کو بھی کنٹرول کرتا ہے کہ سرچ انجن ورژن اور انڈیکس ورژن تمام سرورز پر یکساں ہیں، ورنہ کلسٹر کے اندر متضاد ڈیٹا ہوگا۔

اس حقیقت کے باوجود کہ ایک ٹکڑا سرور آٹھ سرچ انجنوں کی درخواستوں پر کارروائی کرتا ہے، اس کا پروسیسر بہت ہلکا بھرا ہوا ہے۔ لہذا، اب ہم اسنیپٹ ڈیٹا کو الگ سروس میں منتقل کر رہے ہیں۔

ڈیٹا کی منتقلی کے لیے، ہم نے دستاویزات کے لیے یونیورسل کیز متعارف کرائی ہیں۔ اب ایسی صورت حال کے لیے یہ ناممکن ہے کہ ایک کلید کا استعمال کرتے ہوئے کسی اور دستاویز سے مواد واپس کیا جائے۔

لیکن دوسرے فن تعمیر میں منتقلی ابھی مکمل نہیں ہوئی ہے۔ اب ہم سرشار اسنیپٹ سرور سے چھٹکارا حاصل کرنا چاہتے ہیں۔ اور پھر کلسٹر ڈھانچے سے مکمل طور پر ہٹ جائیں۔ یہ ہمیں آسانی سے پیمانے پر جاری رکھنے کی اجازت دے گا۔ ایک اضافی بونس اہم آئرن کی بچت ہے۔

اور اب خوش کن انجام کے ساتھ خوفناک کہانیاں۔ آئیے سرور کی عدم دستیابی کے متعدد معاملات پر غور کریں۔

کچھ خوفناک ہوا: ایک سرور دستیاب نہیں ہے۔

ہم کہتے ہیں کہ ایک سرور دستیاب نہیں ہے۔ پھر کلسٹر میں باقی سرورز جواب دینا جاری رکھ سکتے ہیں، لیکن تلاش کے نتائج نامکمل ہوں گے۔

اسٹیٹس چیک کے ذریعے /حالت پڑوسی سرور سمجھتے ہیں کہ ایک دستیاب نہیں ہے۔ لہذا، مکمل کو برقرار رکھنے کے لیے، کلسٹر میں تمام سرورز فی درخواست /پنگ وہ بیلنسر کو جواب دینا شروع کر دیتے ہیں کہ وہ بھی دستیاب نہیں ہیں۔ یہ پتہ چلتا ہے کہ کلسٹر کے تمام سرورز مر گئے (جو درست نہیں ہے)۔ یہ ہماری کلسٹر اسکیم کی بنیادی خرابی ہے - اسی لیے ہم اس سے دور ہونا چاہتے ہیں۔

وہ درخواستیں جو غلطی کے ساتھ ناکام ہوجاتی ہیں دوسرے سرورز پر بیلنسر کے ذریعہ دوبارہ بھیجی جاتی ہیں۔
بیلنسر صارف کی ٹریفک کو ڈیڈ سرورز پر بھیجنا بھی بند کر دیتا ہے، لیکن ان کی حیثیت کو چیک کرتا رہتا ہے۔

جب سرور دستیاب ہو جاتا ہے، تو یہ جواب دینا شروع کر دیتا ہے۔ /پنگ. جیسے ہی ڈیڈ سرورز سے پنگز کے معمول کے جوابات آنا شروع ہو جاتے ہیں، بیلنسرز وہاں صارف کی ٹریفک بھیجنا شروع کر دیتے ہیں۔ کلسٹر آپریشن بحال ہو گیا ہے، جلدی۔

اس سے بھی بدتر: بہت سے سرورز دستیاب نہیں ہیں۔

ڈیٹا سینٹر میں سرورز کا ایک اہم حصہ کاٹ دیا گیا ہے۔ کیا کریں، کہاں بھاگیں؟ بیلنس دوبارہ بچانے کے لیے آتا ہے۔ ہر بیلنسر مسلسل لائیو سرورز کی موجودہ تعداد کو میموری میں محفوظ کرتا ہے۔ یہ مسلسل ٹریفک کی زیادہ سے زیادہ مقدار کا حساب لگاتا ہے جس پر موجودہ ڈیٹا سینٹر کارروائی کر سکتا ہے۔

جب ڈیٹا سینٹر میں بہت سے سرورز نیچے جاتے ہیں، تو بیلنسر کو احساس ہوتا ہے کہ یہ ڈیٹا سینٹر تمام ٹریفک پر کارروائی نہیں کر سکتا۔

پھر اضافی ٹریفک دوسرے ڈیٹا سینٹرز میں تصادفی طور پر تقسیم ہونا شروع ہو جاتی ہے۔ سب کام کرتا ہے، سب خوش ہیں۔

ہم یہ کیسے کرتے ہیں: ریلیز کی اشاعت

اب آئیے اس بارے میں بات کرتے ہیں کہ ہم سروس میں کی گئی تبدیلیوں کو کیسے شائع کرتے ہیں۔ یہاں ہم نے عمل کو آسان بنانے کا راستہ اختیار کیا ہے: نئی ریلیز کا آغاز تقریباً مکمل طور پر خودکار ہے۔
جب پروجیکٹ میں تبدیلیوں کی ایک خاص تعداد جمع ہوجاتی ہے، تو ایک نئی ریلیز خود بخود بن جاتی ہے اور اس کی تعمیر شروع ہوجاتی ہے۔

پھر سروس کو جانچ کے لیے لے جایا جاتا ہے، جہاں آپریشن کے استحکام کی جانچ کی جاتی ہے۔

ایک ہی وقت میں، خود کار طریقے سے کارکردگی کی جانچ شروع کی جاتی ہے. یہ ایک خصوصی سروس کے ذریعہ سنبھالا جاتا ہے۔ میں اب اس پر بات نہیں کروں گا - اس کی تفصیل ایک الگ مضمون کے لائق ہے۔

اگر ٹیسٹنگ میں اشاعت کامیاب ہو جاتی ہے، تو پریسٹیبل میں ریلیز کی اشاعت خود بخود شروع ہو جاتی ہے۔ Prestable ایک خاص کلسٹر ہے جہاں عام صارف ٹریفک کو ہدایت کی جاتی ہے۔ اگر یہ غلطی لوٹاتا ہے تو بیلنسر پروڈکشن کے لیے دوبارہ درخواست کرتا ہے۔

Prestable میں، ردعمل کے اوقات کی پیمائش کی جاتی ہے اور پیداوار میں پچھلی ریلیز کے ساتھ موازنہ کیا جاتا ہے۔ اگر سب کچھ ٹھیک ہے، تو ایک شخص جوڑتا ہے: گرافس اور لوڈ ٹیسٹنگ کے نتائج کو چیک کرتا ہے اور پھر پروڈکشن میں شروع ہوتا ہے۔

تمام بہترین صارف کو جاتا ہے: A/B ٹیسٹنگ

یہ ہمیشہ واضح نہیں ہوتا ہے کہ آیا کسی سروس میں تبدیلیوں سے حقیقی فوائد حاصل ہوں گے۔ تبدیلیوں کی افادیت کی پیمائش کرنے کے لیے، لوگ A/B ٹیسٹنگ لے کر آئے۔ میں آپ کو تھوڑا بتاؤں گا کہ یہ Yandex.Market تلاش میں کیسے کام کرتا ہے۔

یہ سب ایک نیا CGI پیرامیٹر شامل کرنے سے شروع ہوتا ہے جو نئی فعالیت کو قابل بناتا ہے۔ ہمارے پیرامیٹر کو ہونے دیں: market_new_functionality=1. پھر کوڈ میں ہم اس فعالیت کو فعال کرتے ہیں اگر پرچم موجود ہے:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

نئی فعالیت کو پیداوار میں لایا جا رہا ہے۔

A/B ٹیسٹنگ کو خودکار بنانے کے لیے، ایک وقف خدمت ہے جو تفصیلی معلومات فراہم کرتی ہے۔ یہاں بیان کیا گیا ہے. سروس میں ایک تجربہ بنایا گیا ہے۔ ٹریفک کا حصہ مقرر کیا گیا ہے، مثال کے طور پر، 15%۔ فیصد سوالات کے لیے نہیں بلکہ صارفین کے لیے مقرر کیے گئے ہیں۔ تجربے کی مدت بھی بتائی جاتی ہے، مثال کے طور پر، ایک ہفتہ۔

ایک ساتھ کئی تجربات کیے جا سکتے ہیں۔ ترتیبات میں آپ یہ بتا سکتے ہیں کہ آیا دوسرے تجربات کے ساتھ تقاطع ممکن ہے۔

نتیجے کے طور پر، سروس خود بخود ایک دلیل شامل کرتی ہے۔ market_new_functionality=1 15٪ صارفین تک۔ یہ خود بخود منتخب میٹرکس کا حساب لگاتا ہے۔ تجربہ مکمل ہونے کے بعد، تجزیہ کار نتائج کو دیکھتے ہیں اور نتائج اخذ کرتے ہیں۔ نتائج کی بنیاد پر، پیداوار یا تطہیر کے لیے رول آؤٹ کرنے کا فیصلہ کیا جاتا ہے۔

مارکیٹ کا ماہر ہاتھ: پیداوار میں جانچ

یہ اکثر ہوتا ہے کہ آپ کو پیداوار میں ایک نئی فعالیت کے آپریشن کی جانچ کرنے کی ضرورت ہے، لیکن آپ کو یقین نہیں ہے کہ یہ بھاری بوجھ کے تحت "جنگی" حالات میں کیسے برتاؤ کرے گا۔

ایک حل ہے: CGI پیرامیٹرز میں جھنڈوں کو نہ صرف A/B ٹیسٹنگ کے لیے استعمال کیا جا سکتا ہے، بلکہ نئی فعالیت کو جانچنے کے لیے بھی استعمال کیا جا سکتا ہے۔

ہم نے ایک ایسا ٹول بنایا ہے جو آپ کو سروس کو خطرات سے دوچار کیے بغیر فوری طور پر ہزاروں سرورز پر کنفیگریشن تبدیل کرنے کی اجازت دیتا ہے۔ اسے "Stop Tap" کہتے ہیں۔ اصل خیال یہ تھا کہ بغیر کسی ترتیب کے کچھ فعالیت کو فوری طور پر غیر فعال کر دیا جائے۔ پھر ٹول پھیل گیا اور مزید پیچیدہ ہو گیا۔

خدمت کے بہاؤ کا خاکہ ذیل میں پیش کیا گیا ہے:

پرچم کی قدریں API کے ذریعے سیٹ کی جاتی ہیں۔ مینجمنٹ سروس ان اقدار کو ڈیٹا بیس میں محفوظ کرتی ہے۔ تمام سرورز ہر دس سیکنڈ میں ایک بار ڈیٹابیس پر جاتے ہیں، فلیگ ویلیوز کو پمپ کرتے ہیں اور ان اقدار کو ہر درخواست پر لاگو کرتے ہیں۔

اسٹاپ ٹیپ میں آپ دو قسم کی اقدار سیٹ کر سکتے ہیں:

1) مشروط اظہار۔ اس وقت لاگو کریں جب کوئی ایک قدر درست ہو۔ مثال کے طور پر:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

DC3 مقام پر درخواست پر کارروائی ہونے پر قدر "1" کا اطلاق ہوگا۔ اور جب beru.ru سائٹ کے دوسرے کلسٹر پر درخواست پر کارروائی کی جاتی ہے تو قیمت "4" ہوتی ہے۔

2) غیر مشروط اقدار۔ اگر کوئی بھی شرائط پوری نہیں ہوتی ہیں تو بطور ڈیفالٹ درخواست دیں۔ مثال کے طور پر:

قدر، قدر!

اگر کوئی قدر فجائیہ کے ساتھ ختم ہوتی ہے تو اسے اعلیٰ ترجیح دی جاتی ہے۔

CGI پیرامیٹر پارسر URL کو پارس کرتا ہے۔ پھر اسٹاپ ٹیپ سے اقدار کا اطلاق ہوتا ہے۔

درج ذیل ترجیحات کے ساتھ اقدار کا اطلاق ہوتا ہے:

1. اسٹاپ ٹیپ (فجائیہ نشان) سے بڑھی ہوئی ترجیح کے ساتھ۔
2. درخواست سے قیمت۔
3. اسٹاپ ٹیپ سے ڈیفالٹ ویلیو۔
4. کوڈ میں ڈیفالٹ قدر۔

بہت سے جھنڈے ہیں جو مشروط اقدار میں اشارہ کیے گئے ہیں - وہ ہمارے لیے معلوم تمام منظرناموں کے لیے کافی ہیں:

• ڈیٹا سینٹر۔
• ماحولیات: پیداوار، جانچ، سایہ۔
• مقام: بازار، بیرو۔
• کلسٹر نمبر۔

اس ٹول کے ذریعے، آپ سرورز کے مخصوص گروپ (مثال کے طور پر، صرف ایک ڈیٹا سینٹر میں) پر نئی فعالیت کو فعال کر سکتے ہیں اور پوری سروس کو کسی خاص خطرے کے بغیر اس فعالیت کے آپریشن کی جانچ کر سکتے ہیں۔ یہاں تک کہ اگر آپ نے کہیں سنگین غلطی کی ہے، سب کچھ گرنا شروع ہو گیا اور پورا ڈیٹا سینٹر نیچے چلا گیا، بیلنسرز درخواستوں کو دوسرے ڈیٹا سینٹرز کو بھیج دیں گے۔ اختتامی صارفین کو کچھ نظر نہیں آئے گا۔

اگر آپ کو کوئی مسئلہ نظر آتا ہے، تو آپ فوری طور پر پرچم کو اس کی سابقہ ​​قدر پر واپس کر سکتے ہیں اور تبدیلیاں واپس کر دی جائیں گی۔

اس سروس کے منفی پہلو بھی ہیں: ڈویلپرز اسے بہت پسند کرتے ہیں اور اکثر سٹاپ ٹیپ میں تمام تبدیلیوں کو آگے بڑھانے کی کوشش کرتے ہیں۔ ہم غلط استعمال سے نمٹنے کی کوشش کر رہے ہیں۔

اسٹاپ ٹیپ اپروچ اس وقت اچھی طرح کام کرتا ہے جب آپ کے پاس پہلے سے ہی مستحکم کوڈ تیار ہو جو پروڈکشن کے لیے تیار ہو۔ ایک ہی وقت میں، آپ کو اب بھی شک ہے، اور آپ کوڈ کو "جنگی" حالات میں چیک کرنا چاہتے ہیں۔

تاہم، Stop Tap ترقی کے دوران جانچ کے لیے موزوں نہیں ہے۔ ڈویلپرز کے لیے ایک الگ کلسٹر ہے جسے "شیڈو کلسٹر" کہا جاتا ہے۔

خفیہ جانچ: شیڈو کلسٹر

کلسٹرز میں سے ایک کی درخواستوں کو شیڈو کلسٹر میں ڈپلیکیٹ کیا جاتا ہے۔ لیکن بیلنسر اس کلسٹر کے جوابات کو مکمل طور پر نظر انداز کرتا ہے۔ اس کے آپریشن کا خاکہ ذیل میں پیش کیا گیا ہے۔

ہمیں ایک ٹیسٹ کلسٹر ملتا ہے جو حقیقی "جنگی" حالات میں ہوتا ہے۔ عام صارف ٹریفک وہاں جاتا ہے۔ دونوں کلسٹرز میں ہارڈ ویئر ایک جیسا ہے، اس لیے کارکردگی اور غلطیوں کا موازنہ کیا جا سکتا ہے۔

اور چونکہ بیلنسر جوابات کو مکمل طور پر نظر انداز کرتا ہے، اس لیے آخری صارفین شیڈو کلسٹر سے جوابات نہیں دیکھ پائیں گے۔ لہذا، غلطی کرنا خوفناک نہیں ہے.

نتائج

تو، ہم نے مارکیٹ کی تلاش کیسے بنائی؟

ہر چیز کو آسانی سے چلانے کے لیے، ہم فعالیت کو الگ الگ خدمات میں الگ کرتے ہیں۔ اس طرح ہم صرف ان اجزاء کی پیمائش کر سکتے ہیں جن کی ہمیں ضرورت ہے اور اجزاء کو آسان بنا سکتے ہیں۔ کسی دوسری ٹیم کو علیحدہ جزو تفویض کرنا اور اس پر کام کرنے کی ذمہ داریوں کا اشتراک کرنا آسان ہے۔ اور اس نقطہ نظر کے ساتھ لوہے میں اہم بچت ایک واضح پلس ہے۔

شیڈو کلسٹر بھی ہماری مدد کرتا ہے: ہم خدمات تیار کر سکتے ہیں، عمل میں ان کی جانچ کر سکتے ہیں اور صارف کو پریشان نہیں کر سکتے ہیں۔

ٹھیک ہے، پیداوار میں جانچ، یقینا. ہزاروں سرورز پر کنفیگریشن تبدیل کرنے کی ضرورت ہے؟ آسان، اسٹاپ ٹیپ کا استعمال کریں۔ اس طرح آپ فوری طور پر ایک ریڈی میڈ کمپلیکس حل کو رول آؤٹ کر سکتے ہیں اور مسائل پیدا ہونے پر ایک مستحکم ورژن پر واپس جا سکتے ہیں۔

مجھے امید ہے کہ میں یہ دکھانے کے قابل تھا کہ ہم پیشکشوں کے بڑھتے ہوئے بنیاد کے ساتھ کس طرح مارکیٹ کو تیز اور مستحکم بناتے ہیں۔ ہم سرور کے مسائل کو کیسے حل کرتے ہیں، درخواستوں کی ایک بڑی تعداد سے نمٹتے ہیں، سروس کی لچک کو بہتر بناتے ہیں اور کام کے عمل میں رکاوٹ کے بغیر ایسا کرتے ہیں۔

ماخذ: www.habr.com