سب کو ہیلو، میرا نام الیگزینڈر ہے، میں CIAN میں بطور انجینئر کام کرتا ہوں اور سسٹم ایڈمنسٹریشن اور انفراسٹرکچر کے عمل کی آٹومیشن میں شامل ہوں۔ پچھلے مضامین میں سے ایک کے تبصروں میں، ہم سے یہ بتانے کو کہا گیا تھا کہ ہمیں روزانہ 4 ٹی بی لاگ کہاں سے ملتے ہیں اور ہم ان کے ساتھ کیا کرتے ہیں۔ ہاں، ہمارے پاس بہت سارے لاگز ہیں، اور ان پر کارروائی کرنے کے لیے ایک علیحدہ انفراسٹرکچر کلسٹر بنایا گیا ہے، جو ہمیں مسائل کو تیزی سے حل کرنے کی اجازت دیتا ہے۔ اس مضمون میں میں اس بارے میں بات کروں گا کہ ہم نے ڈیٹا کے بڑھتے ہوئے بہاؤ کے ساتھ کام کرنے کے لیے اسے ایک سال کے دوران کیسے ڈھال لیا۔
ہم نے کہاں سے شروع کیا؟
پچھلے کچھ سالوں میں، cian.ru پر بوجھ بہت تیزی سے بڑھ گیا ہے، اور 2018 کی تیسری سہ ماہی تک، وسائل کی ٹریفک 11.2 ملین منفرد صارفین تک پہنچ گئی۔ اس وقت، نازک لمحات میں ہم نے 40% لاگز کھو دیے، یہی وجہ ہے کہ ہم واقعات سے جلدی نہیں نمٹ سکے اور انہیں حل کرنے میں کافی وقت اور کوشش صرف کی۔ ہم اکثر مسئلہ کی وجہ بھی نہیں ڈھونڈ پاتے، اور یہ کچھ وقت کے بعد دوبارہ ہو جاتا ہے۔ یہ جہنم تھا اور اس کے بارے میں کچھ کرنا تھا۔
اس وقت، ہم نے نوشتہ جات کو ذخیرہ کرنے کے لیے معیاری اشاریہ کی ترتیبات کے ساتھ ElasticSearch ورژن 10 کے ساتھ 5.5.2 ڈیٹا نوڈس کا کلسٹر استعمال کیا۔ یہ ایک سال سے زیادہ پہلے ایک مقبول اور سستی حل کے طور پر متعارف کرایا گیا تھا: تب نوشتہ جات کا بہاؤ اتنا بڑا نہیں تھا، غیر معیاری ترتیب کے ساتھ آنے کا کوئی فائدہ نہیں تھا۔
آنے والے لاگز کی پروسیسنگ Logstash کے ذریعے پانچ ElasticSearch کوآرڈینیٹرز پر مختلف پورٹس پر فراہم کی گئی تھی۔ ایک انڈیکس، سائز سے قطع نظر، پانچ شارڈز پر مشتمل ہوتا ہے۔ ایک گھنٹہ اور روزانہ کی گردش کا اہتمام کیا گیا، جس کے نتیجے میں، کلسٹر میں ہر گھنٹے تقریباً 100 نئے شارڈز نمودار ہوئے۔ اگرچہ بہت زیادہ لاگز نہیں تھے، کلسٹر نے اچھی طرح سے مقابلہ کیا اور کسی نے اس کی ترتیبات پر توجہ نہیں دی۔
تیز رفتار ترقی کے چیلنجز
تخلیق شدہ لاگز کا حجم بہت تیزی سے بڑھ گیا، کیونکہ دو عمل ایک دوسرے کو اوورلیپ کر رہے تھے۔ ایک طرف، سروس کے صارفین کی تعداد میں اضافہ ہوا. دوسری طرف، ہم نے C# اور Python میں اپنے پرانے monoliths کو دیکھتے ہوئے، ایک مائیکرو سروس فن تعمیر کو فعال طور پر تبدیل کرنا شروع کیا۔ کئی درجن نئی مائیکرو سروسز جنہوں نے یک سنگی کے حصوں کی جگہ لے لی، بنیادی ڈھانچے کے کلسٹر کے لیے نمایاں طور پر زیادہ لاگز تیار کیے۔
یہ اسکیلنگ تھی جس نے ہمیں اس مقام تک پہنچایا جہاں کلسٹر عملی طور پر غیر منظم ہو گیا۔ جب لاگز 20 ہزار پیغامات فی سیکنڈ کی شرح سے آنا شروع ہوئے تو بار بار بیکار گردش نے شارڈز کی تعداد 6 ہزار تک بڑھا دی، اور فی نوڈ 600 سے زیادہ شارڈز تھے۔
اس کی وجہ سے RAM کو مختص کرنے میں مسائل پیدا ہوئے، اور جب ایک نوڈ کریش ہو گیا، تمام شارڈز بیک وقت حرکت کرنے لگے، ٹریفک میں کئی گنا اضافہ ہو گیا اور دوسرے نوڈس لوڈ ہو گئے، جس کی وجہ سے کلسٹر میں ڈیٹا لکھنا تقریباً ناممکن ہو گیا۔ اور اس عرصے میں ہم بغیر نوشتہ جات کے رہ گئے۔ اور اگر سرور کے ساتھ کوئی مسئلہ تھا، تو ہم نے بنیادی طور پر کلسٹر کا 1/10 کھو دیا۔ چھوٹے اشاریہ جات کی ایک بڑی تعداد نے پیچیدگی کا اضافہ کیا۔
لاگ کے بغیر، ہم اس واقعے کی وجوہات کو نہیں سمجھتے تھے اور جلد یا بدیر دوبارہ اسی ریک پر قدم رکھ سکتے تھے، اور ہماری ٹیم کے نظریے میں یہ ناقابل قبول تھا، کیونکہ ہمارے تمام کام کا طریقہ کار اس کے برعکس کرنے کے لیے ڈیزائن کیا گیا ہے - کبھی نہیں دہرائیں گے۔ ایک ہی مسائل. ایسا کرنے کے لیے، ہمیں لاگز کی مکمل مقدار اور ان کی ڈیلیوری تقریباً حقیقی وقت میں درکار تھی، کیونکہ آن ڈیوٹی انجینئرز کی ایک ٹیم نے نہ صرف میٹرکس، بلکہ لاگز سے بھی الرٹس کی نگرانی کی۔ مسئلے کے پیمانے کو سمجھنے کے لیے، اس وقت لاگز کا کل حجم تقریباً 2 ٹی بی فی دن تھا۔
ہم نے لاگز کے نقصان کو مکمل طور پر ختم کرنے اور ELK کلسٹر کو ان کی ترسیل کے وقت کو فورس میجر کے دوران زیادہ سے زیادہ 15 منٹ تک کم کرنے کا ایک ہدف مقرر کیا (بعد میں ہم نے اندرونی KPI کے طور پر اس اعداد و شمار پر انحصار کیا)۔
نیا گردش کا طریقہ کار اور گرم گرم نوڈس
ہم نے ElasticSearch ورژن کو 5.5.2 سے 6.4.3 تک اپ ڈیٹ کرکے کلسٹر کنورژن شروع کیا۔ ایک بار پھر ہمارا ورژن 5 کلسٹر مر گیا، اور ہم نے اسے آف کرنے اور اسے مکمل طور پر اپ ڈیٹ کرنے کا فیصلہ کیا - ابھی تک کوئی لاگز نہیں ہیں۔ تو ہم نے یہ تبدیلی صرف چند گھنٹوں میں کی۔
اس مرحلے میں سب سے بڑے پیمانے پر تبدیلی اپاچی کافکا کو تین نوڈس پر ایک کوآرڈینیٹر کے ساتھ ایک انٹرمیڈیٹ بفر کے طور پر نافذ کرنا تھا۔ میسج بروکر نے ہمیں ElasticSearch کے مسائل کے دوران لاگز کھونے سے بچایا۔ ایک ہی وقت میں، ہم نے کلسٹر میں 2 نوڈس شامل کیے اور ڈیٹا سینٹر میں مختلف ریکوں میں موجود تین "ہاٹ" نوڈس کے ساتھ گرم-گرم فن تعمیر میں تبدیل ہو گئے۔ ہم نے ایک ماسک کا استعمال کرتے ہوئے لاگ ان کو ری ڈائریکٹ کیا جو کسی بھی حالت میں ضائع نہیں ہونا چاہیے - nginx کے ساتھ ساتھ ایپلیکیشن ایرر لاگز۔ بقیہ نوڈس پر معمولی لاگز بھیجے گئے تھے - ڈیبگ، وارننگ، وغیرہ، اور 24 گھنٹوں کے بعد، "ہاٹ" نوڈس سے "اہم" لاگز منتقل کر دیے گئے۔
چھوٹے اشاریہ جات کی تعداد میں اضافہ نہ کرنے کے لیے، ہم نے وقت کی گردش سے رول اوور میکانزم کو تبدیل کیا۔ فورمز پر بہت ساری معلومات موجود تھیں کہ انڈیکس سائز کے حساب سے گردش بہت ناقابل اعتبار ہے، لہذا ہم نے انڈیکس میں دستاویزات کی تعداد کے حساب سے گردش استعمال کرنے کا فیصلہ کیا۔ ہم نے ہر انڈیکس کا تجزیہ کیا اور دستاویزات کی تعداد کو ریکارڈ کیا جس کے بعد گردش کو کام کرنا چاہئے۔ اس طرح، ہم شارڈ کے بہترین سائز تک پہنچ گئے ہیں - 50 GB سے زیادہ نہیں۔
کلسٹر کی اصلاح
تاہم، ہم مکمل طور پر مسائل سے چھٹکارا حاصل نہیں کر سکے ہیں۔ بدقسمتی سے، چھوٹے اشاریہ جات اب بھی نمودار ہوئے: وہ مخصوص حجم تک نہیں پہنچے، گھمائے نہیں گئے، اور تین دن سے پرانے اشاریہ جات کی عالمی صفائی کے ذریعے حذف کر دیے گئے، کیونکہ ہم نے تاریخ کے حساب سے گردش کو ہٹا دیا ہے۔ اس کی وجہ سے ڈیٹا کا نقصان ہوا کہ کلسٹر سے انڈیکس مکمل طور پر غائب ہو گیا، اور غیر موجود انڈیکس پر لکھنے کی کوشش نے کیوریٹر کی منطق کو توڑ دیا جسے ہم نے انتظام کے لیے استعمال کیا۔ لکھنے کے لیے عرف کو انڈیکس میں تبدیل کر دیا گیا اور اس نے رول اوور کی منطق کو توڑ دیا، جس کی وجہ سے کچھ انڈیکسز کی بے قابو ترقی 600 GB تک ہو گئی۔
مثال کے طور پر، گردش کی تشکیل کے لیے:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
اگر کوئی رول اوور عرف نہیں تھا، تو ایک خرابی پیش آگئی:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
ہم نے اس مسئلے کے حل کو اگلی تکرار کے لیے چھوڑ دیا اور ایک اور مسئلہ اٹھایا: ہم نے Logstash کی پل لاجک پر سوئچ کیا، جو آنے والے لاگز کو پروسیس کرتا ہے (غیر ضروری معلومات کو ہٹانا اور افزودہ کرنا)۔ ہم نے اسے ڈوکر میں رکھا، جسے ہم docker-compose کے ذریعے لانچ کرتے ہیں، اور ہم نے وہاں logstash-exporter بھی رکھا، جو لاگ اسٹریم کی آپریشنل نگرانی کے لیے میٹرکس کو Prometheus کو بھیجتا ہے۔ اس طرح ہم نے اپنے آپ کو ہر قسم کے لاگ پر کارروائی کرنے کے لیے ذمہ دار لاگ اسٹاش مثالوں کی تعداد کو آسانی سے تبدیل کرنے کا موقع فراہم کیا۔
جب ہم کلسٹر کو بہتر کر رہے تھے، cian.ru کی ٹریفک ہر ماہ 12,8 ملین منفرد صارفین تک بڑھ گئی۔ نتیجے کے طور پر، یہ پتہ چلا کہ ہماری تبدیلیاں پیداوار میں تبدیلیوں کے پیچھے تھوڑی تھیں، اور ہمیں اس حقیقت کا سامنا کرنا پڑا کہ "گرم" نوڈس بوجھ کا مقابلہ نہیں کر سکے اور لاگز کی پوری ترسیل کو سست کر دیا۔ ہمیں ناکامی کے بغیر "ہاٹ" ڈیٹا موصول ہوا، لیکن ہمیں باقی کی ترسیل میں مداخلت کرنی پڑی اور اشاریہ جات کو یکساں طور پر تقسیم کرنے کے لیے دستی رول اوور کرنا پڑا۔
ایک ہی وقت میں، کلسٹر میں لاگ اسٹیش مثالوں کی ترتیب کو اسکیل کرنا اور تبدیل کرنا اس حقیقت کی وجہ سے پیچیدہ تھا کہ یہ ایک مقامی ڈاکر کمپوز تھا، اور تمام اعمال دستی طور پر انجام دیئے گئے تھے (نئے سروں کو شامل کرنے کے لیے، یہ ضروری تھا کہ دستی طور پر تمام کاموں میں سرورز اور ہر جگہ docker-compose up -d کرتے ہیں)۔
لاگ دوبارہ تقسیم
اس سال ستمبر میں، ہم ابھی بھی یک سنگی کو کاٹ رہے تھے، کلسٹر پر بوجھ بڑھ رہا تھا، اور لاگز کا بہاؤ 30 ہزار پیغامات فی سیکنڈ کے قریب پہنچ رہا تھا۔
ہم نے ہارڈویئر اپ ڈیٹ کے ساتھ اگلی تکرار شروع کی۔ ہم نے پانچ کوآرڈینیٹرز سے تین میں تبدیل کیا، ڈیٹا نوڈس کو تبدیل کیا اور رقم اور ذخیرہ کرنے کی جگہ کے لحاظ سے جیت گئے۔ نوڈس کے لیے ہم دو کنفیگریشن استعمال کرتے ہیں:
- "ہاٹ" نوڈس کے لیے: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 Hot1 کے لیے اور 3 Hot2 کے لیے)۔
- "گرم" نوڈس کے لیے: E3-1230 v6 / 4Tb SSD / 32 Gb x 4۔
اس تکرار پر، ہم نے مائیکرو سروسز کے رسائی لاگز کے ساتھ انڈیکس کو منتقل کیا، جو فرنٹ لائن nginx لاگز کے برابر جگہ لیتا ہے، تین "ہاٹ" نوڈس کے دوسرے گروپ میں۔ اب ہم 20 گھنٹے کے لیے "ہاٹ" نوڈس پر ڈیٹا اسٹور کرتے ہیں، اور پھر انہیں "گرم" نوڈس میں باقی لاگز میں منتقل کرتے ہیں۔
ہم نے چھوٹے اشاریہ جات کے غائب ہونے کا مسئلہ ان کی گردش کو دوبارہ ترتیب دے کر حل کیا۔ اب اشاریہ جات کو ہر 23 گھنٹے میں کسی بھی صورت میں گھمایا جاتا ہے، چاہے وہاں بہت کم ڈیٹا موجود ہو۔ اس سے شارڈز کی تعداد میں قدرے اضافہ ہوا (ان میں سے تقریباً 800 تھے)، لیکن کلسٹر کی کارکردگی کے نقطہ نظر سے یہ قابل برداشت ہے۔
نتیجے کے طور پر، کلسٹر میں چھ "گرم" اور صرف چار "گرم" نوڈس تھے۔ یہ طویل وقت کے وقفوں پر درخواستوں پر تھوڑی تاخیر کا سبب بنتا ہے، لیکن مستقبل میں نوڈس کی تعداد میں اضافہ یہ مسئلہ حل کر دے گا۔
اس تکرار نے نیم خودکار اسکیلنگ کی کمی کا مسئلہ بھی حل کردیا۔ ایسا کرنے کے لیے، ہم نے ایک انفراسٹرکچر Nomad کلسٹر تعینات کیا - جیسا کہ ہم پہلے ہی پروڈکشن میں تعینات کر چکے ہیں۔ ابھی کے لیے، Logstash کی مقدار لوڈ کے لحاظ سے خود بخود تبدیل نہیں ہوتی ہے، لیکن ہم اس تک پہنچیں گے۔
مستقبل کے لئے منصوبوں
لاگو کنفیگریشن کا پیمانہ بالکل درست ہے، اور اب ہم 13,3 TB ڈیٹا ذخیرہ کرتے ہیں - تمام لاگز 4 دن کے لیے، جو الرٹس کے ہنگامی تجزیہ کے لیے ضروری ہے۔ ہم کچھ لاگز کو میٹرکس میں تبدیل کرتے ہیں، جنہیں ہم گریفائٹ میں شامل کرتے ہیں۔ انجینئرز کے کام کو آسان بنانے کے لیے، ہمارے پاس بنیادی ڈھانچے کے کلسٹر کے لیے میٹرکس اور عام مسائل کی نیم خودکار مرمت کے لیے اسکرپٹ ہیں۔ ڈیٹا نوڈس کی تعداد بڑھانے کے بعد، جس کا منصوبہ اگلے سال کے لیے بنایا گیا ہے، ہم 4 سے 7 دن تک ڈیٹا اسٹوریج پر جائیں گے۔ یہ آپریشنل کام کے لیے کافی ہوگا، کیونکہ ہم ہمیشہ واقعات کی جلد از جلد تحقیقات کرنے کی کوشش کرتے ہیں، اور طویل مدتی تحقیقات کے لیے ٹیلی میٹری ڈیٹا موجود ہوتا ہے۔
اکتوبر 2019 میں، cian.ru پر ٹریفک پہلے ہی ہر ماہ 15,3 ملین منفرد صارفین تک بڑھ چکی ہے۔ یہ نوشتہ جات کی فراہمی کے لیے تعمیراتی حل کا ایک سنگین امتحان بن گیا۔
اب ہم ElasticSearch کو ورژن 7 میں اپ ڈیٹ کرنے کی تیاری کر رہے ہیں۔ تاہم، اس کے لیے ہمیں ElasticSearch میں بہت سے اشاریہ جات کی میپنگ کو اپ ڈیٹ کرنا پڑے گا، کیونکہ وہ ورژن 5.5 سے منتقل ہوئے ہیں اور ورژن 6 میں انہیں فرسودہ قرار دیا گیا ہے (وہ صرف ورژن میں موجود نہیں ہیں۔ 7)۔ اس کا مطلب یہ ہے کہ اپ ڈیٹ کے عمل کے دوران یقینی طور پر کسی نہ کسی قسم کی زبردستی میجر ہوگی، جو مسئلہ حل ہونے تک ہمیں بغیر لاگ کے چھوڑ دے گی۔ ورژن 7 کے، ہم سب سے زیادہ بہتر انٹرفیس اور نئے فلٹرز کے ساتھ کبانا کے منتظر ہیں۔
ہم نے اپنا بنیادی مقصد حاصل کر لیا: ہم نے لاگز کو کھونا بند کر دیا اور انفراسٹرکچر کلسٹر کے ڈاؤن ٹائم کو 2-3 کریش فی ہفتہ سے کم کر کے ماہانہ چند گھنٹے کی دیکھ بھال کا کام کر دیا۔ پیداوار میں یہ تمام کام تقریبا پوشیدہ ہے. تاہم، اب ہم اس بات کا تعین کر سکتے ہیں کہ ہماری سروس کے ساتھ کیا ہو رہا ہے، ہم اسے فوری طور پر خاموش موڈ میں کر سکتے ہیں اور اس بات کی فکر نہیں کرتے کہ لاگز ضائع ہو جائیں گے۔ عام طور پر، ہم مطمئن، خوش اور نئے کارناموں کی تیاری کر رہے ہیں، جس کے بارے میں ہم بعد میں بات کریں گے۔
ماخذ: www.habr.com