Kubernetes میں کافکا کلسٹر کے لیے مناسب سائز کا تعین کریں۔

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

Apache Kafka قابل بھروسہ، توسیع پذیر اور اعلیٰ کارکردگی والے ریئل ٹائم اسٹریمنگ سسٹمز بنانے کے لیے ایک تقسیم شدہ اسٹریمنگ پلیٹ فارم ہے۔ اس کی متاثر کن صلاحیتوں کو Kubernetes کا استعمال کرتے ہوئے بڑھایا جا سکتا ہے۔ اس کے لیے ہم نے ترقی کی ہے۔ اوپن سورس کافکا آپریٹر اور ایک ٹول کہا جاتا ہے۔ سپر ٹیوبز. وہ آپ کو کبرنیٹس پر کافکا چلانے اور اس کی مختلف خصوصیات کو استعمال کرنے کی اجازت دیتے ہیں، جیسے بروکر کنفیگریشن کو ٹھیک کرنا، ری بیلنسنگ کے ساتھ میٹرک پر مبنی اسکیلنگ، ریک بیداری، "نرم" (کریمانہ) اپ ڈیٹس وغیرہ کو رول آؤٹ کرنا

اپنے کلسٹر میں Supertubes آزمائیں:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

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

• ارے نہیں! کبرنیٹس کے لیے ایک اور کافکا آپریٹر;
• Prometheus میٹرکس کی بنیاد پر کافکا کی نگرانی اور کام کریں۔;
• کافکا نے کبرنیٹس پر آگاہی فراہم کی۔;
• اپاچی کافکا کو Istio - بینچ مارک پر چلانا;
• کافکا آپریٹر کے ساتھ صارف کی تصدیق شدہ اور کنٹرول شدہ کلسٹرز تک رسائی;
• کافکا رولنگ اپ گریڈ اور کوبرنیٹس پر متحرک کنفیگریشن;
• کافکا کے لیے ایلچی پروٹوکول فلٹر، میشڈ.

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

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

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

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

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

یہ مضمون ان اقدامات کے بارے میں بات کرے گا جو ہم ابتدائی کنفیگریشنز میں سست ترین اجزاء سے زیادہ سے زیادہ حاصل کرنے اور کافکا کلسٹر کے تھرو پٹ کی پیمائش کرنے کے لیے کرتے ہیں۔ ایک انتہائی لچکدار ترتیب کے لیے کم از کم تین چلانے والے بروکرز کی ضرورت ہوتی ہے (min.insync.replicas=3)، تین مختلف ایکسیسبیلٹی زونز میں تقسیم کیا گیا۔ Kubernetes انفراسٹرکچر کو ترتیب دینے، اسکیل کرنے اور اس کی نگرانی کے لیے، ہم ہائبرڈ کلاؤڈز کے لیے اپنا کنٹینر مینجمنٹ پلیٹ فارم استعمال کرتے ہیں۔ پائپ لائن. یہ آن پریمیس (ننگی دھات، VMware) اور پانچ قسم کے بادلوں (علی بابا، AWS، Azure، Google، Oracle) کے ساتھ ساتھ ان کے کسی بھی مرکب کو سپورٹ کرتا ہے۔

کافکا کلسٹر انفراسٹرکچر اور کنفیگریشن پر خیالات

ذیل کی مثالوں کے لیے، ہم نے کلاؤڈ فراہم کنندہ کے طور پر AWS اور Kubernetes کی تقسیم کے طور پر EKS کا انتخاب کیا۔ اسی طرح کی ترتیب کا استعمال کرتے ہوئے لاگو کیا جا سکتا ہے P.K.E - بنزائی کلاؤڈ سے Kubernetes کی تقسیم، CNCF سے تصدیق شدہ۔

ڈرائیو

ایمیزون مختلف پیشکش کرتا ہے۔ EBS حجم کی اقسام. اصل میں gp2 и io1 تاہم، اعلی تھرو پٹ کو یقینی بنانے کے لیے ایس ایس ڈی ڈرائیوز موجود ہیں۔ gp2 جمع شدہ کریڈٹ استعمال کرتا ہے۔ (I/O کریڈٹس)، لہذا ہم نے قسم کو ترجیح دی۔ io1، جو مسلسل اعلی تھرو پٹ پیش کرتا ہے۔

مثال کی اقسام

کافکا کی کارکردگی آپریٹنگ سسٹم کے صفحہ کیشے پر بہت زیادہ منحصر ہے، لہذا ہمیں بروکرز (JVM) اور صفحہ کیشے کے لیے کافی میموری کے ساتھ مثالوں کی ضرورت ہے۔ مثال c5.2x بڑا - ایک اچھی شروعات، کیونکہ اس میں 16 جی بی میموری ہے اور EBS کے ساتھ کام کرنے کے لیے موزوں ہے۔. اس کا نقصان یہ ہے کہ یہ ہر 30 گھنٹے میں صرف 24 منٹ سے زیادہ کے لیے زیادہ سے زیادہ کارکردگی فراہم کرنے کے قابل ہے۔ اگر آپ کے کام کے بوجھ کو طویل عرصے کے دوران اعلی کارکردگی کی ضرورت ہوتی ہے، تو آپ مثال کی دیگر اقسام پر غور کر سکتے ہیں۔ بالکل وہی ہے جو ہم نے کیا، پر روک دیا c5.4x بڑا. یہ زیادہ سے زیادہ تھرو پٹ فراہم کرتا ہے۔ 593,75 Mb/s. EBS والیوم کا زیادہ سے زیادہ تھرو پٹ io1 مثال سے زیادہ c5.4x بڑا، لہذا بنیادی ڈھانچے کا سب سے سست عنصر اس مثال کی قسم کا I/O تھرو پٹ ہونے کا امکان ہے (جس کی ہمارے لوڈ ٹیسٹ کو بھی تصدیق کرنی چاہئے)۔

Сеть

نیٹ ورک تھرو پٹ VM مثال اور ڈسک کی کارکردگی کے مقابلے کافی بڑا ہونا چاہیے، ورنہ نیٹ ورک رکاوٹ بن جاتا ہے۔ ہمارے معاملے میں، نیٹ ورک انٹرفیس c5.4x بڑا 10 Gb/s تک کی رفتار کو سپورٹ کرتا ہے، جو کہ VM مثال کے I/O تھرو پٹ سے نمایاں طور پر زیادہ ہے۔

بروکر کی تعیناتی

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

جاوا ورژن

منطقی انتخاب Java 11 ہے کیونکہ یہ Docker کے ساتھ اس لحاظ سے مطابقت رکھتا ہے کہ JVM اس کنٹینر پر دستیاب پروسیسرز اور میموری کا درست تعین کرتا ہے جس میں بروکر چل رہا ہے۔ یہ جانتے ہوئے کہ CPU کی حدود اہم ہیں، JVM اندرونی اور شفاف طریقے سے GC تھریڈز اور JIT تھریڈز کی تعداد کو سیٹ کرتا ہے۔ ہم نے کافکا کی تصویر استعمال کی۔ banzaicloud/kafka:2.13-2.4.0، جس میں جاوا 2.4.0 پر کافکا ورژن 2.13 (اسکالا 11) شامل ہے۔

اگر آپ Kubernetes پر Java/JVM کے بارے میں مزید جاننا چاہتے ہیں تو ہماری درج ذیل پوسٹس کو دیکھیں:

• میری جاوا ایپلیکیشن OOMKilled کیوں ہے۔;
• جاوا 10 ایپلی کیشنز کے لیے کنٹینرز کو صحیح طریقے سے سائز کرنے کا طریقہ.

بروکر میموری کی ترتیبات

بروکر میموری کو کنفیگر کرنے کے دو اہم پہلو ہیں: JVM کے لیے سیٹنگز اور Kubernetes pod کے لیے۔ پوڈ کے لیے مقرر کردہ میموری کی حد زیادہ سے زیادہ ہیپ سائز سے زیادہ ہونی چاہیے تاکہ JVM کے پاس جاوا میٹا اسپیس کے لیے جگہ ہو، جو اس کی اپنی میموری میں رہتی ہے، اور آپریٹنگ سسٹم پیج کیشے کے لیے، جسے کافکا فعال طور پر استعمال کرتا ہے۔ اپنے ٹیسٹوں میں ہم نے پیرامیٹرز کے ساتھ کافکا بروکرز کا آغاز کیا۔ -Xmx4G -Xms2G، اور پوڈ کے لئے میموری کی حد تھی۔ 10 Gi. براہ کرم نوٹ کریں کہ JVM کے لیے میموری سیٹنگ خود بخود استعمال کر کے حاصل کی جا سکتی ہے۔ -XX:MaxRAMPercentage и -X:MinRAMPercentageپوڈ کے لیے میموری کی حد کی بنیاد پر۔

بروکر پروسیسر کی ترتیبات

عام طور پر، آپ کافکا کے استعمال کردہ دھاگوں کی تعداد میں اضافہ کر کے متوازی عمل کو بڑھا کر کارکردگی کو بہتر بنا سکتے ہیں۔ کافکا کے لیے جتنے زیادہ پروسیسرز دستیاب ہوں گے، اتنا ہی بہتر ہے۔ اپنے ٹیسٹ میں، ہم نے 6 پروسیسرز کی حد کے ساتھ آغاز کیا اور آہستہ آہستہ (دوبارہ کے ذریعے) ان کی تعداد بڑھا کر 15 کر دی۔ اس کے علاوہ، ہم نے num.network.threads=12 بروکر سیٹنگز میں ان تھریڈز کی تعداد بڑھانے کے لیے جو نیٹ ورک سے ڈیٹا وصول کرتے ہیں اور اسے بھیجتے ہیں۔ فوری طور پر دریافت کیا کہ پیروکار بروکرز کو فوری طور پر نقلیں موصول نہیں ہو سکتیں، انہوں نے اٹھایا num.replica.fetchers 4 تک اس رفتار کو بڑھانے کے لیے جس پر پیروکار بروکرز نے رہنماؤں کے پیغامات کی نقل تیار کی۔

لوڈ جنریشن ٹول

آپ کو یہ یقینی بنانا چاہیے کہ کافکا کلسٹر (جس کا بینچ مارک کیا جا رہا ہے) اپنے زیادہ سے زیادہ لوڈ تک پہنچنے سے پہلے منتخب لوڈ جنریٹر کی صلاحیت ختم نہ ہو۔ دوسرے لفظوں میں، یہ ضروری ہے کہ لوڈ جنریشن ٹول کی صلاحیتوں کا ابتدائی جائزہ لیا جائے، اور اس کے لیے کافی تعداد میں پروسیسرز اور میموری کے ساتھ مثال کی اقسام بھی منتخب کی جائیں۔ اس صورت میں، ہمارا ٹول کافکا کلسٹر سے زیادہ بوجھ پیدا کرے گا۔ بہت سے تجربات کے بعد، ہم تین کاپیوں پر آباد ہوئے c5.4x بڑاجن میں سے ہر ایک میں جنریٹر چل رہا تھا۔

بینچ مارکنگ

کارکردگی کی پیمائش ایک تکراری عمل ہے جس میں درج ذیل مراحل شامل ہیں:

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

اگلا حصہ ان اقدامات کی وضاحت کرتا ہے جو ٹیسٹ کلسٹر بینچ مارکنگ کے عمل کے دوران انجام دیے گئے تھے۔

فورم کے اوزار

مندرجہ ذیل ٹولز کو تیزی سے بنیادی ترتیب ترتیب دینے، بوجھ پیدا کرنے اور کارکردگی کی پیمائش کرنے کے لیے استعمال کیا گیا:

• بنزئی کلاؤڈ پائپ لائن ایمیزون سی سے ای کے ایس کلسٹر کو منظم کرنے کے لیے Prometheus (کافکا اور انفراسٹرکچر میٹرکس جمع کرنے کے لیے) اور گرافانا (ان میٹرکس کو دیکھنے کے لیے)۔ ہم نے فائدہ اٹھایا ضم в پائپ لائن وہ خدمات جو فیڈریٹڈ مانیٹرنگ، سنٹرلائزڈ لاگ کلیکشن، خطرے کی سکیننگ، ڈیزاسٹر ریکوری، انٹرپرائز گریڈ سیکیورٹی اور بہت کچھ فراہم کرتی ہیں۔
• سنگرینیل - کافکا کلسٹر کو لوڈ کرنے کا ایک ٹول۔
• کافکا میٹرکس اور انفراسٹرکچر کو دیکھنے کے لیے گرافانا ڈیش بورڈز: کبرنیٹس کافکا, نوڈ برآمد کنندہ.
• Kubernetes پر کافکا کلسٹر قائم کرنے کے آسان ترین طریقے کے لیے Supertubes CLI۔ زوکیپر، کافکا آپریٹر، ایلچی اور بہت سے دوسرے اجزاء نصب کیے گئے ہیں اور کوبرنیٹس پر پروڈکشن کے لیے تیار کافکا کلسٹر چلانے کے لیے مناسب طریقے سے ترتیب دیے گئے ہیں۔
  • انسٹال کرنا سپر ٹیوب سی ایل آئی فراہم کردہ ہدایات کا استعمال کریں یہاں.

ای کے ایس کلسٹر

وقف کارکن نوڈس کے ساتھ ایک EKS کلسٹر تیار کریں۔ c5.4x بڑا کافکا بروکرز کے ساتھ پوڈز کے لیے مختلف دستیابی زونز کے ساتھ ساتھ لوڈ جنریٹر اور مانیٹرنگ انفراسٹرکچر کے لیے وقف نوڈس۔

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

ایک بار جب EKS کلسٹر تیار اور چل رہا ہے، اس کے مربوط کو فعال کریں۔ نگرانی کی خدمت - وہ پرومیتھیس اور گرافانا کو ایک کلسٹر میں تعینات کرے گی۔

کافکا سسٹم کے اجزاء

سپر ٹیوب CLI کا استعمال کرتے ہوئے EKS میں کافکا سسٹم کے اجزاء (Zookeper، kafka-operator) انسٹال کریں:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

کافکا کلسٹر

پہلے سے طے شدہ طور پر، EKS قسم کی EBS والیوم استعمال کرتا ہے۔ gp2، لہذا آپ کو حجم کی بنیاد پر ایک علیحدہ اسٹوریج کلاس بنانے کی ضرورت ہے۔ io1 کافکا کلسٹر کے لیے:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

بروکرز کے لیے پیرامیٹر سیٹ کریں۔ min.insync.replicas=3 اور بروکر پوڈز کو نوڈس پر تین مختلف دستیابی زونز میں تعینات کریں:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

موضوعات

ہم نے متوازی طور پر تین لوڈ جنریٹر مثالیں چلائیں۔ ان میں سے ہر ایک اپنے اپنے موضوع پر لکھتا ہے، یعنی ہمیں کل تین عنوانات درکار ہیں:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

ہر موضوع کے لیے، نقل کا عنصر 3 ہے — انتہائی دستیاب پروڈکشن سسٹمز کے لیے کم از کم تجویز کردہ قدر۔

لوڈ جنریشن ٹول

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

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

نوٹ کرنے کے لئے چند نکات:

• لوڈ جنریٹر 512 بائٹس کی لمبائی کے پیغامات تیار کرتا ہے اور انہیں 500 پیغامات کے بیچ میں کافکا کو شائع کرتا ہے۔
• ایک دلیل کا استعمال کرتے ہوئے -required-acks=all اشاعت کو کامیاب سمجھا جاتا ہے جب پیغام کی تمام مطابقت پذیر نقلیں موصول ہوتی ہیں اور کافکا بروکرز کی طرف سے تصدیق کی جاتی ہے۔ اس کا مطلب یہ ہے کہ بینچ مارک میں ہم نے نہ صرف پیغامات وصول کرنے والے رہنماؤں کی رفتار کی پیمائش کی بلکہ ان کے پیروکار بھی پیغامات کی نقل کرتے ہیں۔ اس ٹیسٹ کا مقصد صارفین کی پڑھنے کی رفتار کا اندازہ لگانا نہیں ہے۔ (صارفین) حال ہی میں موصول ہونے والے پیغامات جو اب بھی OS صفحہ کیشے میں موجود ہیں، اور اس کا موازنہ ڈسک پر محفوظ کردہ پیغامات کی پڑھنے کی رفتار سے۔
• لوڈ جنریٹر متوازی طور پر 20 کارکنوں کو چلاتا ہے (-workers=20)۔ ہر کارکن میں 5 پروڈیوسر ہوتے ہیں جو کافکا کلسٹر سے کارکن کے کنکشن کا اشتراک کرتے ہیں۔ نتیجے کے طور پر، ہر جنریٹر کے 100 پروڈیوسر ہوتے ہیں، اور وہ سب کافکا کلسٹر کو پیغامات بھیجتے ہیں۔

کلسٹر کی صحت کی نگرانی

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

• لوڈ جنریٹر شائع شدہ پیغامات کی تعداد اور غلطی کی شرح کے بارے میں معیاری اعدادوشمار لکھتا ہے۔ غلطی کی شرح ایک ہی رہنا چاہئے۔ 0,00%.
• کروز کنٹرولکافکا آپریٹر کے ذریعے تعینات کیا گیا، ایک ڈیش بورڈ فراہم کرتا ہے جہاں ہم کلسٹر کی حالت کی نگرانی بھی کر سکتے ہیں۔ اس پینل کو دیکھنے کے لیے یہ کریں:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• آئی ایس آر کی سطح ("مطابقت پذیر" نقلوں کی تعداد) سکڑنا اور توسیع 0 کے برابر ہے۔

پیمائش کے نتائج

3 بروکرز، پیغام کا سائز - 512 بائٹس

تین بروکرز میں یکساں طور پر تقسیم کے ساتھ، ہم کارکردگی حاصل کرنے کے قابل تھے۔ ~500 Mb/s (تقریباً 990 ہزار پیغامات فی سیکنڈ):

JVM ورچوئل مشین کی میموری کی کھپت 2 GB سے زیادہ نہیں تھی:

ڈسک تھرو پٹ ان تینوں مثالوں پر زیادہ سے زیادہ I/O نوڈ تھرو پٹ تک پہنچ گیا جن پر بروکرز چل رہے تھے:

نوڈس کے ذریعہ میموری کے استعمال کے اعداد و شمار سے، یہ اس بات کی پیروی کرتا ہے کہ سسٹم بفرنگ اور کیشنگ میں ~ 10-15 GB کا وقت لگا:

3 بروکرز، پیغام کا سائز - 100 بائٹس

جیسے جیسے پیغام کا سائز کم ہوتا ہے، تھرو پٹ تقریباً 15-20% تک گر جاتا ہے: ہر پیغام پر کارروائی کرنے میں صرف ہونے والا وقت اس پر اثر انداز ہوتا ہے۔ اس کے علاوہ پروسیسر کا بوجھ تقریباً دوگنا ہو گیا ہے۔

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

4 بروکرز، پیغام کا سائز - 512 بائٹس

آپ آسانی سے نئے بروکرز کو شامل کرکے اور پارٹیشنز کا توازن برقرار رکھ کر کافکا کلسٹر کی کارکردگی کو آسانی سے بڑھا سکتے ہیں (یہ یقینی بناتا ہے کہ بوجھ بروکرز کے درمیان یکساں طور پر تقسیم ہو)۔ ہمارے معاملے میں، ایک بروکر کو شامل کرنے کے بعد، کلسٹر تھرو پٹ تک بڑھ گیا۔ ~580 Mb/s (~1,1 ملین پیغامات فی سیکنڈ). ترقی توقع سے کم نکلی: اس کی بنیادی طور پر پارٹیشنز کے عدم توازن سے وضاحت کی گئی ہے (تمام بروکرز اپنی صلاحیتوں کے عروج پر کام نہیں کرتے)۔

JVM مشین کی میموری کی کھپت 2 GB سے کم رہی:

ڈرائیوز والے بروکرز کا کام پارٹیشنز کے عدم توازن سے متاثر ہوا:

نتائج

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

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

اگر آپ بنزئی کلاؤڈ ٹیکنالوجیز اور اوپن سورس پروجیکٹس میں دلچسپی رکھتے ہیں، تو کمپنی کو سبسکرائب کریں GitHub کے, لنکڈ یا ٹویٹر.

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

• «K8s میں Redis آپریٹر کے ساتھ ایک کہانی اور اس ڈیٹا بیس سے ڈیٹا کا تجزیہ کرنے کے لیے افادیت کا ایک چھوٹا جائزہ؛ "
• «RabbitMQ کی Kubernetes میں بغیر کسی رکاوٹ کی منتقلی؛ "
• «CoreOS سے zetcd: ZooKeeper کی جگہ...etcd اسٹوریج'.

ماخذ: www.habr.com