تو آپ میٹرکس جمع کرتے ہیں۔ جیسا کہ ہم ہیں۔ ہم میٹرکس بھی جمع کرتے ہیں۔ بالکل، کاروبار کے لئے ضروری ہے. آج ہم اپنے مانیٹرنگ سسٹم کے پہلے لنک کے بارے میں بات کریں گے - ایک statsd-مطابق مجموعی سرور ، ہم نے اسے کیوں لکھا اور ہم نے بروبیک کو کیوں ترک کیا۔
ہمارے پچھلے مضامین سے (, ) آپ یہ جان سکتے ہیں کہ کچھ وقت تک ہم نے ٹیگز کا استعمال کرتے ہوئے جمع کیا۔ . یہ C میں لکھا گیا ہے۔ کوڈ کے نقطہ نظر سے، یہ ایک پلگ کی طرح آسان ہے (جب آپ اپنا حصہ ڈالنا چاہتے ہیں تو یہ ضروری ہے) اور سب سے اہم بات یہ ہے کہ یہ ہمارے 2 ملین میٹرکس فی سیکنڈ (MPS) کے حجم کو اپنے عروج پر ہینڈل کرتا ہے۔ بغیر کسی پریشانی کے۔ دستاویزات میں ستارے کے ساتھ 4 ملین MPS کی حمایت کی گئی ہے۔ اس کا مطلب ہے کہ اگر آپ لینکس پر نیٹ ورک کو درست طریقے سے ترتیب دیتے ہیں تو آپ کو بیان کردہ اعداد و شمار ملیں گے۔ (ہم نہیں جانتے کہ اگر آپ نیٹ ورک کو اسی طرح چھوڑ دیتے ہیں تو آپ کو کتنے MPS مل سکتے ہیں)۔ ان فوائد کے باوجود، ہمیں بروبیک کے بارے میں کئی سنگین شکایات تھیں۔
دعویٰ 1۔ پروجیکٹ کے ڈویلپر، گیتھب نے اس کی حمایت کرنا بند کر دیا: پیچ اور اصلاحات شائع کرنا، ہمارا اور (صرف ہمارا ہی نہیں) PR کو قبول کرنا۔ پچھلے چند مہینوں میں (کہیں فروری تا مارچ 2018 سے) سرگرمیاں دوبارہ شروع ہوئی ہیں، لیکن اس سے پہلے تقریباً 2 سال مکمل پر سکون تھے۔ اس کے علاوہ، پراجیکٹ تیار کیا جا رہا ہے ، جو نئی خصوصیات کے تعارف میں ایک سنگین رکاوٹ بن سکتی ہے۔
دعویٰ 2۔ حساب کی درستگی۔ Brubeck مجموعی طور پر 65536 اقدار کو جمع کرتا ہے۔ ہمارے معاملے میں، کچھ میٹرکس کے لیے، جمع کی مدت (30 سیکنڈ) کے دوران، بہت زیادہ قدریں آ سکتی ہیں (1 عروج پر)۔ اس نمونے کے نتیجے میں، زیادہ سے زیادہ اور کم از کم قدریں بیکار دکھائی دیتی ہیں۔ مثال کے طور پر، اس طرح:
جیسا کہ تھا
کیسا ہونا چاہیے تھا۔
اسی وجہ سے، رقوم کا عام طور پر غلط حساب لگایا جاتا ہے۔ یہاں 32 بٹ فلوٹ اوور فلو کے ساتھ ایک بگ شامل کریں، جو بظاہر معصوم میٹرک حاصل کرنے پر سرور کو عام طور پر سیگفالٹ پر بھیج دیتا ہے، اور سب کچھ بہت اچھا ہو جاتا ہے۔ بگ، ویسے، ٹھیک نہیں کیا گیا ہے۔
اور آخر دعویٰ ایکس. لکھنے کے وقت، ہم اسے تمام 14 کم و بیش کام کرنے والے statsd نفاذ کے سامنے پیش کرنے کے لیے تیار ہیں جو ہم تلاش کرنے کے قابل تھے۔ آئیے تصور کریں کہ کچھ سنگل انفراسٹرکچر اتنا بڑھ گیا ہے کہ 4 ملین MPS کو قبول کرنا اب کافی نہیں ہے۔ یا یہاں تک کہ اگر یہ ابھی تک نہیں بڑھی ہے، لیکن میٹرکس پہلے ہی آپ کے لیے اتنے اہم ہیں کہ چارٹ میں 2-3 منٹ کی کمی بھی پہلے سے ہی اہم بن سکتی ہے اور مینیجرز کے درمیان ناقابل تسخیر افسردگی کا سبب بن سکتی ہے۔ چونکہ ڈپریشن کا علاج ایک ناشکرا کام ہے، اس لیے تکنیکی حل کی ضرورت ہے۔
سب سے پہلے، غلطی کو برداشت کرنا، تاکہ سرور پر اچانک کوئی مسئلہ دفتر میں نفسیاتی زومبی اپوکیلیپس کا سبب نہ بنے۔ دوم، لینکس نیٹ ورک اسٹیک میں گہرائی میں کھودنے اور مطلوبہ سائز تک "چوڑائی میں" بڑھتے ہوئے، 4 ملین سے زیادہ MPS کو قبول کرنے کے قابل ہونے کے لیے اسکیلنگ۔
چونکہ ہمارے پاس اسکیلنگ کی گنجائش تھی، اس لیے ہم نے غلطی برداشت کرنے کا فیصلہ کیا۔ "کے بارے میں! غلطی برداشت! یہ آسان ہے، ہم یہ کر سکتے ہیں،" ہم نے سوچا اور 2 سرورز لانچ کیے، ہر ایک پر بروبیک کی ایک کاپی اٹھائی۔ ایسا کرنے کے لیے، ہمیں میٹرکس کے ساتھ ٹریفک کو دونوں سرورز پر کاپی کرنا پڑا اور یہاں تک کہ اس کے لیے لکھنا پڑا . ہم نے اس کے ساتھ فالٹ ٹولرنس کا مسئلہ حل کیا، لیکن... بہت اچھا نہیں۔ پہلے تو سب کچھ بہت اچھا لگتا تھا: ہر بروبیک جمع کرنے کا اپنا ورژن اکٹھا کرتا ہے، ہر 30 سیکنڈ میں ایک بار گریفائٹ کو ڈیٹا لکھتا ہے، پرانے وقفے کو اوور رائٹ کرتا ہے (یہ گریفائٹ کی طرف کیا جاتا ہے)۔ اگر ایک سرور اچانک فیل ہو جاتا ہے، تو ہمارے پاس ہمیشہ دوسرا سرور ہوتا ہے جس کی اپنی مجموعی ڈیٹا کی کاپی ہوتی ہے۔ لیکن یہاں مسئلہ ہے: اگر سرور ناکام ہوجاتا ہے، تو گراف پر ایک "آرا" ظاہر ہوتا ہے۔ یہ اس حقیقت کی وجہ سے ہے کہ بروبیک کے 30 سیکنڈ کے وقفے مطابقت پذیر نہیں ہوتے ہیں، اور حادثے کے وقت ان میں سے ایک کو اوور رائٹ نہیں کیا جاتا ہے۔ جب دوسرا سرور شروع ہوتا ہے تو وہی ہوتا ہے۔ کافی قابل برداشت، لیکن میں بہتر چاہتا ہوں! اسکیل ایبلٹی کا مسئلہ بھی دور نہیں ہوا۔ تمام میٹرکس اب بھی ایک سرور پر "اڑتے" ہیں، اور اس لیے ہم نیٹ ورک کی سطح کے لحاظ سے، اسی 2-4 ملین MPS تک محدود ہیں۔
اگر آپ اس مسئلے کے بارے میں تھوڑا سا سوچتے ہیں اور اسی وقت بیلچے سے برف کھودتے ہیں، تو درج ذیل واضح خیال ذہن میں آسکتا ہے: آپ کو ایک statsd کی ضرورت ہے جو تقسیم شدہ موڈ میں کام کر سکے۔ یعنی، وہ جو وقت اور میٹرکس میں نوڈس کے درمیان ہم آہنگی کو نافذ کرتا ہے۔ "یقینا، ایسا حل شاید پہلے سے موجود ہے،" ہم نے کہا اور گوگل پر گئے…. اور انہیں کچھ نہیں ملا۔ مختلف اعدادوشمار کے لیے دستاویزات کے ذریعے جانے کے بعد ( 11.12.2017 دسمبر XNUMX تک)، ہمیں بالکل کچھ نہیں ملا۔ بظاہر، نہ تو ڈویلپرز اور نہ ہی ان حلوں کے صارفین کو ابھی تک بہت سارے میٹرکس کا سامنا کرنا پڑا ہے، ورنہ وہ یقینی طور پر کچھ لے کر آئیں گے۔
اور پھر ہمیں "کھلونا" statsd - bioyino کے بارے میں یاد آیا، جو Just for Fun hackathon میں لکھا گیا تھا (اس پروجیکٹ کا نام ہیکاتھون کے آغاز سے پہلے اسکرپٹ کے ذریعے تیار کیا گیا تھا) اور ہمیں احساس ہوا کہ ہمیں فوری طور پر اپنے اعدادوشمار کی ضرورت ہے۔ کس لیے؟
- کیونکہ دنیا میں statsd کلون بہت کم ہیں،
- کیونکہ مطلوبہ یا مطلوبہ فالٹ ٹولرنس اور اسکیل ایبلٹی کے قریب فراہم کرنا ممکن ہے (بشمول سرورز کے درمیان مجموعی میٹرکس کو ہم آہنگ کرنا اور تنازعات بھیجنے کے مسئلے کو حل کرنا)
- کیونکہ میٹرکس کا حساب کرنا بروبیک سے زیادہ درست طریقے سے ممکن ہے،
- کیونکہ آپ خود مزید تفصیلی اعدادوشمار جمع کر سکتے ہیں، جو کہ brubeck نے عملی طور پر ہمیں فراہم نہیں کیے،
- کیونکہ مجھے اپنی ہائپر پرفارمنس ڈسٹری بیوٹڈ اسکیل لیب ایپلیکیشن کو پروگرام کرنے کا موقع ملا، جو کہ ایک اور ہائپرفور کے فن تعمیر کو مکمل طور پر نہیں دہرائے گا... ٹھیک ہے، بس۔
کس پر لکھوں؟ بالکل، زنگ میں. کیوں؟
- کیونکہ پہلے سے ہی ایک پروٹو ٹائپ حل موجود تھا،
- کیونکہ مضمون کا مصنف اس وقت زنگ کو پہلے سے جانتا تھا اور اسے اوپن سورس میں ڈالنے کے موقع کے ساتھ پروڈکشن کے لیے اس میں کچھ لکھنے کے لیے بے چین تھا،
- کیونکہ موصول ہونے والی ٹریفک کی نوعیت کی وجہ سے GC والی زبانیں ہمارے لیے موزوں نہیں ہیں (تقریباً حقیقی وقت) اور GC کے وقفے عملی طور پر ناقابل قبول ہیں،
- کیونکہ آپ کو C کے مقابلے زیادہ سے زیادہ کارکردگی کی ضرورت ہے۔
- کیونکہ زنگ ہمیں بے خوف ہم آہنگی فراہم کرتا ہے، اور اگر ہم اسے C/C++ میں لکھنا شروع کر دیتے، تو ہم بروبیک سے کہیں زیادہ کمزوریوں، بفر اوور فلو، ریس کے حالات اور دیگر خوفناک الفاظ کا شکار ہو جاتے۔
زنگ کے خلاف بھی ایک دلیل تھی۔ کمپنی کو زنگ میں پروجیکٹ بنانے کا کوئی تجربہ نہیں تھا، اور اب ہم اسے مرکزی پروجیکٹ میں استعمال کرنے کا بھی ارادہ نہیں رکھتے ہیں۔ اس لیے شدید اندیشے تھے کہ کچھ بھی کام نہیں آئے گا، لیکن ہم نے موقع لینے کا فیصلہ کیا اور کوشش کی۔
وقت گزر گیا...
آخر کار کئی ناکام کوششوں کے بعد پہلا ورکنگ ورژن تیار ہو گیا۔ کیا ہوا؟ ایسا ہی ہوا۔
ہر نوڈ میٹرکس کا اپنا سیٹ حاصل کرتا ہے اور انہیں جمع کرتا ہے، اور ان اقسام کے لیے میٹرکس کو جمع نہیں کرتا جہاں حتمی جمع کے لیے ان کا پورا سیٹ درکار ہوتا ہے۔ نوڈس کسی طرح کے تقسیم شدہ لاک پروٹوکول کے ذریعہ ایک دوسرے سے جڑے ہوئے ہیں، جو آپ کو ان میں سے صرف ایک کو منتخب کرنے کی اجازت دیتا ہے (یہاں ہم نے پکارا) جو عظیم کو میٹرکس بھیجنے کے لائق ہے۔ یہ مسئلہ فی الحال حل کیا جا رہا ہے۔ ، لیکن مستقبل میں مصنف کے عزائم میں توسیع ہوتی ہے۔ بیڑا، جہاں سب سے زیادہ قابل، یقینا، اتفاق رائے لیڈر نوڈ ہو گا. اتفاق رائے کے علاوہ، نوڈس اکثر (ایک بار فی سیکنڈ بذریعہ ڈیفالٹ) اپنے پڑوسیوں کو پہلے سے جمع شدہ میٹرکس کے وہ حصے بھیجتے ہیں جنہیں وہ اس سیکنڈ میں جمع کرنے میں کامیاب ہو جاتے ہیں۔ اس سے پتہ چلتا ہے کہ اسکیلنگ اور فالٹ ٹولرنس محفوظ ہیں - ہر نوڈ میں اب بھی میٹرکس کا ایک مکمل سیٹ ہوتا ہے، لیکن میٹرکس پہلے سے جمع کر کے TCP کے ذریعے بھیجے جاتے ہیں اور بائنری پروٹوکول میں انکوڈ کیے جاتے ہیں، اس لیے UDP کے مقابلے ڈپلیکیشن کے اخراجات نمایاں طور پر کم ہو جاتے ہیں۔ آنے والی میٹرکس کی کافی بڑی تعداد کے باوجود، جمع کرنے کے لیے بہت کم میموری اور اس سے بھی کم CPU کی ضرورت ہوتی ہے۔ ہمارے انتہائی کمپریسیبل میرٹکس کے لیے، یہ صرف چند دسیوں میگا بائٹس ڈیٹا ہے۔ اضافی بونس کے طور پر، ہمیں گریفائٹ میں کوئی غیر ضروری ڈیٹا دوبارہ نہیں ملتا، جیسا کہ بربیک کے معاملے میں تھا۔
میٹرکس والے UDP پیکٹ ایک سادہ راؤنڈ رابن کے ذریعے نیٹ ورک آلات پر نوڈس کے درمیان غیر متوازن ہیں۔ بلاشبہ، نیٹ ورک ہارڈویئر پیکٹوں کے مواد کو پارس نہیں کرتا ہے اور اس لیے فی سیکنڈ 4M سے زیادہ پیکٹ کھینچ سکتا ہے، ان میٹرکس کا ذکر نہیں کرنا جس کے بارے میں اسے کچھ بھی نہیں معلوم۔ اگر ہم اس بات کو مدنظر رکھیں کہ میٹرکس ہر پیکٹ میں ایک وقت میں نہیں آتے ہیں، تو ہم اس جگہ پر کارکردگی کے مسائل کا اندازہ نہیں لگاتے ہیں۔ اگر سرور کریش ہو جاتا ہے، تو نیٹ ورک ڈیوائس تیزی سے (1-2 سیکنڈ کے اندر) اس حقیقت کا پتہ لگا لیتی ہے اور کریش ہونے والے سرور کو گردش سے ہٹا دیتی ہے۔ اس کے نتیجے میں، غیر فعال (یعنی، نان لیڈر) نوڈس کو چارٹس میں کمی کو دیکھے بغیر عملی طور پر آن اور آف کیا جا سکتا ہے۔ زیادہ سے زیادہ جو ہم کھوتے ہیں وہ میٹرکس کا حصہ ہے جو آخری سیکنڈ میں آیا تھا۔ لیڈر کا اچانک نقصان/شٹ ڈاؤن/سوئچ اب بھی ایک معمولی بے ضابطگی پیدا کرے گا (30 سیکنڈ کا وقفہ اب بھی مطابقت پذیر نہیں ہے)، لیکن اگر نوڈس کے درمیان مواصلت ہے، تو ان مسائل کو کم کیا جا سکتا ہے، مثال کے طور پر، ہم وقت سازی کے پیکٹ بھیج کر .
اندرونی ساخت کے بارے میں تھوڑا سا. ایپلی کیشن بلاشبہ ملٹی تھریڈڈ ہے، لیکن تھریڈنگ فن تعمیر بروبیک میں استعمال ہونے والے فن تعمیر سے مختلف ہے۔ بروبیک میں تھریڈز ایک جیسے ہیں - ان میں سے ہر ایک معلومات جمع کرنے اور جمع کرنے دونوں کے لیے ذمہ دار ہے۔ بائیوینو میں، کارکنوں کو دو گروہوں میں تقسیم کیا جاتا ہے: نیٹ ورک کے ذمہ دار اور جمع کرنے کے ذمہ دار۔ یہ تقسیم آپ کو میٹرکس کی قسم کے لحاظ سے ایپلیکیشن کو زیادہ لچکدار طریقے سے منظم کرنے کی اجازت دیتی ہے: جہاں انتہائی جمع کی ضرورت ہو، آپ ایگریگیٹرز کو شامل کر سکتے ہیں، جہاں بہت زیادہ نیٹ ورک ٹریفک ہے، آپ نیٹ ورک کے بہاؤ کی تعداد شامل کر سکتے ہیں۔ اس وقت، ہمارے سرورز پر ہم 8 نیٹ ورک اور 4 ایگریگیشن فلو میں کام کرتے ہیں۔
گنتی (جمع کرنے کا ذمہ دار) حصہ کافی بورنگ ہے۔ نیٹ ورک کے بہاؤ سے بھرے ہوئے بفرز کو گنتی کے بہاؤ میں تقسیم کیا جاتا ہے، جہاں بعد میں ان کا تجزیہ اور جمع کیا جاتا ہے۔ درخواست پر، دوسرے نوڈس کو بھیجنے کے لیے میٹرکس دیے جاتے ہیں۔ یہ سب، بشمول نوڈس کے درمیان ڈیٹا بھیجنا اور قونصل کے ساتھ کام کرنا، فریم ورک پر چلتے ہوئے، متضاد طور پر انجام دیا جاتا ہے۔ .
ترقی کے دوران بہت زیادہ مسائل میٹرکس وصول کرنے کے لیے ذمہ دار نیٹ ورک کے حصے کی وجہ سے پیدا ہوئے۔ نیٹ ورک کے بہاؤ کو الگ الگ اداروں میں الگ کرنے کا بنیادی مقصد بہاؤ کے خرچ ہونے والے وقت کو کم کرنے کی خواہش تھی۔ کوئی ساکٹ سے ڈیٹا پڑھنے کے لیے۔ غیر مطابقت پذیر UDP اور ریگولر recvmsg کا استعمال کرنے والے اختیارات تیزی سے غائب ہو گئے: پہلا ایونٹ پروسیسنگ کے لیے بہت زیادہ یوزر اسپیس CPU استعمال کرتا ہے، دوسرے کو بہت زیادہ سیاق و سباق کے سوئچز کی ضرورت ہوتی ہے۔ اس لیے اب استعمال کیا جاتا ہے۔ بڑے بفرز کے ساتھ (اور بفرز، حضرات افسران، آپ کے لیے کچھ نہیں ہیں!) ریگولر UDP کے لیے سپورٹ ہلکے کیسز کے لیے مخصوص ہے جہاں recvmmsg کی ضرورت نہیں ہے۔ ملٹی میسج موڈ میں، اہم چیز کو حاصل کرنا ممکن ہے: زیادہ تر وقت، نیٹ ورک تھریڈ OS کی قطار کو ریک کرتا ہے - ساکٹ سے ڈیٹا پڑھتا ہے اور اسے یوزر اسپیس بفر میں منتقل کرتا ہے، صرف کبھی کبھار اس کو بھرا ہوا بفر دینے کے لیے سوئچ کرتا ہے۔ جمع کرنے والے ساکٹ میں قطار عملی طور پر جمع نہیں ہوتی ہے، گرے ہوئے پیکٹوں کی تعداد عملی طور پر نہیں بڑھتی ہے۔
نوٹ
پہلے سے طے شدہ ترتیبات میں، بفر کا سائز کافی بڑا مقرر کیا جاتا ہے۔ اگر آپ اچانک سرور کو خود آزمانے کا فیصلہ کرتے ہیں، تو آپ کو اس حقیقت کا سامنا کرنا پڑ سکتا ہے کہ تھوڑی تعداد میں میٹرکس بھیجنے کے بعد، وہ گریفائٹ میں نہیں پہنچیں گے، نیٹ ورک اسٹریم بفر میں باقی رہیں گے۔ تھوڑی تعداد میں میٹرکس کے ساتھ کام کرنے کے لیے، آپ کو ترتیب میں چھوٹی قدروں پر بفسائز اور ٹاسک-قطار-سائز سیٹ کرنے کی ضرورت ہے۔
آخر میں، چارٹ سے محبت کرنے والوں کے لیے کچھ چارٹس۔
ہر سرور کے لیے آنے والے میٹرکس کی تعداد کے اعداد و شمار: 2 ملین سے زیادہ MPS۔
نوڈس میں سے ایک کو غیر فعال کرنا اور آنے والی میٹرکس کو دوبارہ تقسیم کرنا۔
آؤٹ گوئنگ میٹرکس کے اعدادوشمار: صرف ایک نوڈ ہمیشہ بھیجتا ہے - چھاپہ دار باس۔
ہر نوڈ کے آپریشن کے اعدادوشمار، مختلف سسٹم ماڈیولز میں غلطیوں کو مدنظر رکھتے ہوئے۔
آنے والی میٹرکس کی تفصیل (میٹرک کے نام پوشیدہ ہیں)۔
ہم اس سب کے ساتھ آگے کیا کرنے کی منصوبہ بندی کر رہے ہیں؟ بے شک، کوڈ لکھیں، لعنت...! اس منصوبے کو اصل میں اوپن سورس بنانے کا منصوبہ بنایا گیا تھا اور زندگی بھر ایسا ہی رہے گا۔ ہمارے فوری منصوبوں میں Raft کے اپنے ورژن پر سوئچ کرنا، ہم مرتبہ پروٹوکول کو زیادہ پورٹیبل میں تبدیل کرنا، اضافی داخلی اعدادوشمار متعارف کرانا، میٹرکس کی نئی اقسام، بگ فکسز اور دیگر بہتری شامل ہیں۔
بلاشبہ، پروجیکٹ کی ترقی میں مدد کرنے کے لیے ہر کسی کا خیرمقدم ہے: PR، مسائل، اگر ممکن ہو تو ہم جواب دیں گے، بہتر کریں گے، وغیرہ۔
یہ کہنے کے ساتھ ہی، بس لوگو، ہمارے ہاتھی خرید لو!
ماخذ: www.habr.com