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

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

میں ایک طویل عرصے سے ایک ایسے آلے کی تلاش کر رہا ہوں جو اس طرح کے مسائل سے نمٹنے میں مدد کرے (میں نے اس کے بارے میں Habré پر لکھا: 1, 2)، لیکن آخر میں میں نے اپنا اوپن سورس حل بنایا۔ اس مضمون میں میں سروس میش اپروچ کے فوائد کے بارے میں بات کرتا ہوں اور اس کے نفاذ کے لیے ایک نیا ٹول شیئر کرتا ہوں۔

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

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

سروس میش نقطہ نظر

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

حل

اس نقطہ نظر کے پہلے ہی کئی نفاذ ہیں: Istio и linkerd2. وہ باکس سے باہر بہت ساری خصوصیات فراہم کرتے ہیں۔ لیکن ایک ہی وقت میں، وسائل پر ایک بڑا اوور ہیڈ آتا ہے۔ مزید برآں، جس کلسٹر میں اس طرح کا نظام چلتا ہے، اتنا ہی زیادہ وسائل نئے انفراسٹرکچر کو برقرار رکھنے کے لیے درکار ہوں گے۔ Avito میں، ہم kubernetes کلسٹر چلاتے ہیں جن میں سروس کے ہزاروں نمونے ہوتے ہیں (اور ان کی تعداد تیزی سے بڑھ رہی ہے)۔ اپنے موجودہ نفاذ میں، Istio فی سروس مثال کے طور پر ~ 300Mb RAM استعمال کرتا ہے۔ امکانات کی بڑی تعداد کی وجہ سے، شفاف توازن خدمات کے مجموعی جوابی وقت (10ms تک) کو بھی متاثر کرتا ہے۔

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

نتیجے کے طور پر، ہم اپنے فیصلے پر پہنچے:  نیترمیش.

نیترمیش

نیترمیش سسٹم میں خدمات کی تعداد سے قطع نظر، لامحدود پیمانے کی صلاحیت کے ساتھ ایک ہلکا پھلکا سروس میش حل ہے۔

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

آج کلاؤڈ کے زیادہ تر حل گولانگ میں لاگو ہوتے ہیں۔ اور یقیناً اس کی وجوہات ہیں۔ گولانگ میں نیٹ ورک ایپلی کیشنز کو لکھنا جو I/O کے ساتھ متضاد طور پر کام کرتی ہے اور ضرورت کے مطابق کوروں میں پیمانہ کرنا آسان اور کافی آسان ہے۔ اور، جو بھی بہت اہم ہے، کارکردگی اس مسئلے کو حل کرنے کے لیے کافی ہے۔ اسی لیے ہم نے بھی گولانگ کا انتخاب کیا۔

کارکردگی

ہم نے اپنی کوششوں کو زیادہ سے زیادہ پیداواری صلاحیت حاصل کرنے پر مرکوز رکھا ہے۔ ایک ایسے حل کے لیے جو سروس کی ہر مثال کے ساتھ لگا ہوا ہے، RAM اور CPU وقت کی ایک چھوٹی سی کھپت کی ضرورت ہے۔ اور یقیناً جواب میں تاخیر بھی چھوٹی ہونی چاہیے۔

آئیے دیکھتے ہیں کہ ہمیں کیا نتائج ملے۔

RAM

نیٹرمیش بغیر ٹریفک کے ~10Mb اور فی مثال 50 RPS تک کے بوجھ کے ساتھ زیادہ سے زیادہ 10000Mb استعمال کرتا ہے۔

Istio envoy proxy ہمارے کلسٹرز میں ہزاروں مثالوں کے ساتھ ہمیشہ ~300Mb استعمال کرتی ہے۔ یہ اسے پورے کلسٹر تک پیمانہ کرنے کی اجازت نہیں دیتا ہے۔

Netramesh کے ساتھ ہمیں میموری کی کھپت میں ~ 10x کمی ملی۔

CPU

CPU کا استعمال بوجھ کے نیچے نسبتاً برابر ہے۔ یہ سائڈ کار کو فی یونٹ وقت کی درخواستوں کی تعداد پر منحصر ہے۔ چوٹی پر فی سیکنڈ 3000 درخواستوں پر قدریں:

ایک اور اہم نکتہ ہے: Netramesh - ایک ایسا حل جس میں کنٹرول ہوائی جہاز اور بوجھ کے بغیر CPU وقت استعمال نہیں ہوتا۔ Istio کے ساتھ، سائڈ کار ہمیشہ سروس اینڈ پوائنٹس کو اپ ڈیٹ کرتے ہیں۔ نتیجے کے طور پر، ہم اس تصویر کو بغیر بوجھ کے دیکھ سکتے ہیں:

ہم خدمات کے درمیان رابطے کے لیے HTTP/1 استعمال کرتے ہیں۔ ایلچی کے ذریعے پراکسی کرتے وقت Istio کے جوابی وقت میں اضافہ 5-10ms تک تھا، جو ان خدمات کے لیے کافی ہے جو ایک ملی سیکنڈ میں جواب دینے کے لیے تیار ہیں۔ Netramesh کے ساتھ اس وقت 0.5-2ms تک کم ہو گیا ہے.

سکالٹیبل

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

سروس کی دریافت

نیٹرمیش سروس کی دریافت کے لیے کوئی اضافی طریقہ کار شامل نہیں کرتا ہے۔ نیٹرا سائڈ کار کے ذریعے تمام ٹریفک کو شفاف طریقے سے پراکسی کیا جاتا ہے۔

نیٹرمیش HTTP/1 ایپلیکیشن پروٹوکول کو سپورٹ کرتا ہے۔ اس کی وضاحت کرنے کے لیے، بندرگاہوں کی ایک قابل ترتیب فہرست استعمال کی جاتی ہے۔ عام طور پر، سسٹم میں کئی پورٹس ہوتے ہیں جن کے ذریعے HTTP مواصلت ہوتی ہے۔ مثال کے طور پر، ہم سروسز اور بیرونی درخواستوں کے درمیان تعامل کے لیے 80, 8890, 8080 استعمال کرتے ہیں۔ اس صورت میں، انہیں ماحولیاتی متغیر کا استعمال کرتے ہوئے سیٹ کیا جا سکتا ہے۔ NETRA_HTTP_PORTS.

اگر آپ Kubernetes کو بطور آرکیسٹریٹر استعمال کرتے ہیں اور سروسز کے درمیان انٹرا کلسٹر کمیونیکیشن کے لیے اس کے سروس ہستی کے طریقہ کار کو استعمال کرتے ہیں، تو طریقہ کار بالکل وہی رہتا ہے۔ سب سے پہلے، مائیکرو سروس kube-dns کا استعمال کرتے ہوئے ایک سروس IP ایڈریس حاصل کرتی ہے اور اس سے ایک نیا کنکشن کھولتی ہے۔ یہ تعلق سب سے پہلے مقامی نیٹرا سائڈ کار کے ساتھ قائم ہوتا ہے اور تمام TCP پیکٹ ابتدائی طور پر نیٹرا پر پہنچتے ہیں۔ اگلا، Netra-sidecar اصل منزل سے تعلق قائم کرتا ہے۔ نوڈ پر پوڈ آئی پی پر NAT بالکل ویسا ہی رہتا ہے جیسا کہ نیٹرا کے بغیر۔

تقسیم شدہ ٹریسنگ اور سیاق و سباق کو آگے بڑھانا

نیٹرمیش HTTP تعاملات کے بارے میں ٹریسنگ اسپین بھیجنے کے لیے درکار فعالیت فراہم کرتا ہے۔ Netra-sidecar HTTP پروٹوکول کو پارس کرتا ہے، درخواست میں تاخیر کی پیمائش کرتا ہے، اور HTTP ہیڈر سے ضروری معلومات نکالتا ہے۔ بالآخر، ہمیں ایک ہی جیجر سسٹم میں تمام نشانات ملتے ہیں۔ عمدہ ترتیب کے لیے، آپ سرکاری لائبریری کے ذریعے فراہم کردہ ماحولیاتی متغیرات کو بھی استعمال کر سکتے ہیں۔ jaeger go لائبریری.

لیکن ایک مسئلہ ہے۔ جب تک سروسز ایک خصوصی uber ہیڈر تیار اور بھیجتی ہیں، ہم سسٹم میں منسلک ٹریسنگ اسپین نہیں دیکھیں گے۔ اور یہ وہی ہے جو ہمیں فوری طور پر مسائل کی وجہ تلاش کرنے کی ضرورت ہے۔ یہاں پھر نیترمیش کے پاس ایک حل ہے۔ پراکسیز HTTP ہیڈرز کو پڑھتی ہیں اور، اگر ان میں uber ٹریس آئی ڈی نہیں ہے، تو ایک تخلیق کرتی ہیں۔ Netramesh آنے والی اور جانے والی درخواستوں کے بارے میں معلومات کو سائڈ کار میں بھی محفوظ کرتا ہے اور ضروری آؤٹ گوئنگ ریکوئسٹ ہیڈرز کے ساتھ ان کو افزودہ کرکے ان سے میل کھاتا ہے۔ خدمات میں آپ کو صرف ایک ہیڈر بھیجنے کی ضرورت ہے۔ X-Request-Id، جسے ماحولیاتی متغیر کا استعمال کرتے ہوئے ترتیب دیا جاسکتا ہے۔ NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh میں سیاق و سباق کے سائز کو کنٹرول کرنے کے لیے، آپ مندرجہ ذیل ماحولیاتی متغیرات کو سیٹ کر سکتے ہیں: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (وہ وقت جس کے لیے سیاق و سباق کو محفوظ کیا جائے گا) اور NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (سیاق و سباق کی صفائی کی تعدد)۔

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

درخواست کے ماخذ کا تعین کرنا

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

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

Роутинг трафика и внутренности Netramesh

نیٹرمیش دو اہم اجزاء پر مشتمل ہے۔ پہلا، netra-init، ٹریفک کو روکنے کے لیے نیٹ ورک کے اصول طے کرتا ہے۔ وہ استعمال کرتا ہے iptables ری ڈائریکٹ قواعد سائڈ کار پر ٹریفک کے تمام یا کچھ حصے کو روکنا، جو نیٹرمیش کا دوسرا اہم جزو ہے۔ آپ کنفیگر کر سکتے ہیں کہ آنے والے اور جانے والے TCP سیشنز کے لیے کن بندرگاہوں کو روکنے کی ضرورت ہے: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

ٹول میں ایک دلچسپ خصوصیت بھی ہے - امکانی روٹنگ۔ اگر آپ نیٹرمیش کو خصوصی طور پر ٹریسنگ اسپین جمع کرنے کے لیے استعمال کرتے ہیں، تو پیداواری ماحول میں آپ وسائل کو بچا سکتے ہیں اور متغیرات کا استعمال کرتے ہوئے امکانی روٹنگ کو فعال کر سکتے ہیں۔ NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 سے 1 تک)۔ پہلے سے طے شدہ قدر 1 ہے (تمام ٹریفک کو روک دیا گیا ہے)۔

کامیاب مداخلت کے بعد، Netra sidecar نئے کنکشن کو قبول کرتا ہے اور استعمال کرتا ہے۔ SO_ORIGINAL_DST اصل منزل حاصل کرنے کے لیے ساکٹ آپشن۔ نیترا پھر اصل آئی پی ایڈریس سے ایک نیا کنکشن کھولتا ہے اور فریقین کے درمیان دو طرفہ TCP کمیونیکیشن قائم کرتا ہے، وہاں سے گزرنے والی تمام ٹریفک کو سنتا ہے۔ اگر پورٹ کو HTTP کے طور پر بیان کیا گیا ہے، تو Netra اسے پارس کرنے اور ٹریس کرنے کی کوشش کرتا ہے۔ اگر HTTP پارسنگ ناکام ہو جاتی ہے، تو Netra واپس TCP پر آ جاتا ہے اور شفاف طریقے سے بائٹس کو پراکسی کرتا ہے۔

انحصار کا گراف بنانا

Jaeger میں بڑی مقدار میں ٹریسنگ کی معلومات حاصل کرنے کے بعد، میں سسٹم میں تعاملات کا مکمل گراف حاصل کرنا چاہتا ہوں۔ لیکن اگر آپ کا سسٹم کافی بھرا ہوا ہے اور روزانہ اربوں ٹریسنگ اسپین جمع ہوتے ہیں تو ان کو جمع کرنا اتنا آسان کام نہیں ہوتا ہے۔ ایسا کرنے کا ایک سرکاری طریقہ ہے: چنگاری انحصار. تاہم، مکمل گراف بنانے میں گھنٹے لگیں گے اور آپ کو پچھلے XNUMX گھنٹوں سے Jaeger سے پورا ڈیٹا سیٹ ڈاؤن لوڈ کرنے پر مجبور کر دے گا۔

اگر آپ ٹریسنگ اسپین کو ذخیرہ کرنے کے لیے Elasticsearch استعمال کر رہے ہیں، تو آپ استعمال کر سکتے ہیں۔ گولانگ کی ایک سادہ افادیت، جو Elasticsearch کی خصوصیات اور صلاحیتوں کا استعمال کرتے ہوئے منٹوں میں وہی گراف بنائے گا۔

Netramesh کا استعمال کیسے کریں۔

نیٹرا کو کسی بھی آرکیسٹریٹر چلانے والی کسی بھی سروس میں آسانی سے شامل کیا جا سکتا ہے۔ آپ ایک مثال دیکھ سکتے ہیں۔ یہاں.

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

نیترمیش کا مستقبل

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

مستقبل میں، Netramesh HTTP کے علاوہ دیگر ایپلیکیشن لیئر پروٹوکول کو سپورٹ کرے گا۔ L7 روٹنگ مستقبل قریب میں دستیاب ہوگی۔

اگر آپ کو اسی طرح کے مسائل درپیش ہیں تو Netramesh کا استعمال کریں اور ہمیں سوالات اور تجاویز کے ساتھ لکھیں۔

ماخذ: www.habr.com