الاستخدام الواسع النطاق لتقنيات Apache-stack هو اتجاه واضح. وكافكا في طليعة الشعبية: اليوم ، الأشخاص الذين يعرفون وسيط الرسائل ، ربما يتجاوزون عدد الذين اعتادوا على رؤية كلمة فرانز بجانب كلمة كافكا.
نحن أنفسنا نستخدم هذه التكنولوجيا بنشاط في مشاريعنا. لكنها دائما مثيرة للاهتمام ، ولكن كيف تعمل من أجل الآخرين؟ ومن المثير للاهتمام مضاعفة إذا كان هذا ليس مجرد مثال من ممارسات شخص ما ، ولكن اختبار مركّز للتكنولوجيا. لذلك ، قمنا بترجمة مقال حديث يتحدث عن كيفية قيام Dropbox بالبحث التجريبي عن حدود الفرص وحدود التحمل في كافكا. ووجد ما أراد.
استكشاف حدود النطاق الترددي كافكا على دروببوإكسيعد Apache Kafka حلاً شائعًا للتدفق الموزع والمعالجة المتسلسلة لكميات كبيرة من البيانات. يستخدم على نطاق واسع في صناعة التكنولوجيا الفائقة ، و Dropbox ليست استثناء. تلعب Kafka دورًا مهمًا في بنية البيانات الخاصة بالعديد من أنظمتنا الموزعة الهامة - تحليل البيانات والتعلم الآلي والرصد والاسترجاع ومعالجة الدفق (الرأس) (وهذه مجرد أمثلة قليلة).
في Dropbox ، تتم إدارة مجموعات كافكا بواسطة فريق Jetstream ، الذي تتمثل مسؤوليته الأساسية في تقديم خدمات عالية الجودة متعلقة بكافكا. يعد فهم حد النطاق الترددي كافكا ضمن البنية التحتية لـ Dropbox أمرًا ضروريًا لاتخاذ القرارات الصائبة حول كيفية تخصيص الموارد في حالات الاستخدام المختلفة ، وكان هذا أحد أهداف الفريق ذات الأولوية. لقد أنشأنا مؤخرًا منصة اختبار آلية لتحقيق ذلك. وفي هذا المنشور نود أن نشارك طريقتنا والنتائج.
منصة الاختبار
يوضح الشكل أعلاه معلمات منصة الاختبار الخاصة بنا لهذه الدراسة. نحن نستخدم Spark لاستضافة عملاء Kafka ، مما يسمح لنا بإنتاج واستهلاك حركة المرور في مجلد تعسفي. لقد أنشأنا ثلاث مجموعات من كافكا ذات أحجام مختلفة ، بحيث تم ضبط حجم الكتلة بشكل حرفي لإعادة توجيه حركة المرور إلى نقطة أخرى. ابتكر كافكا موضوعًا لإنتاج واستهلاك اختبار المرور. للبساطة ، قمنا بتوزيع حركة المرور عبر جميع الوسطاء بالتساوي. للقيام بذلك ، أنشأنا موضوع اختبار مع عدد الأقسام عشرة أضعاف عدد الوسطاء. كل وسيط يؤدي بالضبط 10 أقسام. نظرًا لأن الكتابة إلى قسم ما تكون متسلسلة ، يمكن أن تؤدي الأقسام القليلة المخصصة لسمسار واحد إلى كتابة تنافسية ، مما يحد من عرض النطاق الترددي. أظهرت تجاربنا أن الرقم 10 يعد رقمًا جيدًا للتغلب على صعوبات عنق الزجاجة المرتبطة بالتسجيل التنافسي.
نظرًا للطبيعة الموزعة للبنية التحتية الخاصة بنا ، يقع عملائنا في مناطق مختلفة من الولايات المتحدة. بالنظر إلى أن عدد زياراتنا التجريبية أقل بكثير من الحد المسموح به لقنوات صندوق إسقاط Dropbox ، يمكننا أن نفترض بثقة أن هذا الحد من عدد الزيارات الإقليمية ينطبق أيضًا على حركة المرور المحلية.
ما يؤثر على الحمل؟هناك العديد من العوامل التي يمكن أن تؤثر على تحميل مجموعة Kafka: عدد المنتجين ، وعدد مجموعات المستهلكين ، والإزاحة الأولية للمستهلكين ، وعدد الرسائل في الثانية ، وحجم كل رسالة ، وعدد الموضوعات والأقسام المعنية. وهذه ليست سوى بعض منهم. درجة الحرية في تحديد المعلمات عالية. وبالتالي ، نحن بحاجة إلى إيجاد العوامل المهيمنة من أجل تقليل تعقيد الاختبار إلى مستوى مقبول.
درسنا مجموعات مختلفة من المعلمات التي وجدناها مناسبة. لقد توصلنا إلى نتيجة غير مفاجئة مفادها أن العوامل المهيمنة التي ينبغي أخذها في الاعتبار هي المكونات الرئيسية للتحميل: عدد الرسائل التي يتم إنتاجها في الثانية (ثوانٍ / ثانية) وعدد البايتات لكل رسالة (b / s).
نموذج المروراتخذنا نهجا رسميا لفهم القيود المفروضة على كافكا. هناك مساحة حركة المرور ذات الصلة لمجموعة Kafka معينة. تقابل كل نقطة في هذا الفضاء متعدد الأبعاد حالة فريدة من نوعها لحركة المرور تنطبق على كافكا وتم تقديمها كمتجه للمعلمات: <s / s ، b / s ، # المنتجون ، # مجموعات المستهلكين ، # الموضوعات ، ...>. جميع حالات المرور التي لا تؤدي إلى ازدحام KafKa تشكل فضاءًا مغلقًا سيحد سطحه من كتلة Kafka.
بالنسبة للاختبار الأول الذي أجريناه ، اخترنا s / s و b / s كمعلمات رئيسية وخفضنا مساحة حركة المرور إلى طائرة ثنائية الأبعاد. تشكل حدود حركة المرور المسموح بها مناطق تتبع واضحة. إن اكتشاف حد كافكا في حالتنا يعادل تحديد القيم الحدية لهذه المنطقة.
أتمتة الاختبارمن أجل تعيين الحدود بدقة كافية ، كان لا بد من إجراء مئات الاختبارات مع المعلمات المختلفة - والتي سيكون من غير المنطقي للغاية للقيام يدويا. لذلك ، قمنا بتطوير خوارزمية تسمح لك بإجراء جميع التجارب دون تدخل بشري.
معدل الازدحاممن المهم جدًا العثور على مجموعة من المؤشرات التي تتيح لك تقييم حالة كافكا برمجيًا. درسنا مجموعة واسعة من المؤشرات الممكنة واستقرنا على عينة صغيرة التالية:
- دفق إدخال / إخراج بسيط أقل من 20٪: هذا يعني أن مجموعة مهام سير العمل التي تستخدمها كافكا لمعالجة طلبات العملاء مشغولة للغاية ولا يمكنها التعامل مع المهام الواردة.
- التغير في مجموعة النسخ المتماثلة المتزامنة (ISR) بأكثر من 50٪: هذا يعني أنه عند استخدام حركة مرور لمدة 50٪ من الوقت المرصود ، لا يتوفر لدى وسيط واحد على الأقل وقت لتكرار البيانات الواردة من زعيمه.
يتم استخدام نفس المؤشرات في Jetstream لمراقبة حالة كافكا وتكون بمثابة إشارات الإنذار الأولى من الحمل الزائد العنقودي.
العثور على الحدودلتحديد قيمة حدود واحدة ، نصلح b / s ثم نغير s / s لجلب Kafka إلى التحميل الزائد. من الممكن تحديد قيمة s / s الحدود عندما نعرف قيمة s / s الآمنة وقريبة من ذلك ، ولكن بالفعل تسبب في التحميل الزائد. من هذين ، يتم أخذ قيمة s / s الآمنة كقيمة حد. كما هو موضح أدناه ، يتم تشكيل خط القيم الحدية وفقًا لنتائج اختبارات مماثلة مع مؤشرات مختلفة b / s:
تجدر الإشارة إلى أنه بدلاً من تنظيم s / s مباشرة ، جربنا مع عدد مختلف من الشركات المصنعة التي لها نفس سرعة الإنتاج ، والتي يرمز إليها بواسطة np. الشيء هو أن معالجة الدُفعات للرسائل تعقد التحكم في سرعة إنتاج شركة واحدة. تغيير في عدد الشركات المصنعة ، على النقيض من ذلك ، يسمح لك بتغيير حركة المرور بشكل خطي. وفقًا لبحثنا المبكر ، لن تؤدي الزيادة البسيطة في عدد الشركات المصنعة إلى إحداث فرق ملحوظ في الحمل على كافكا.
بادئ ذي بدء ، نجد قيمة حد منفصلة باستخدام بحث ثنائي. يبدأ البحث بنطاق كبير جدًا np [0، max] ، حيث يمثل max القيمة التي ستؤدي بالضرورة إلى التحميل الزائد. في كل تكرار ، يتم تحديد قيمة متوسطة لإنشاء حركة مرور. إذا كانت كافكا محملة بهذه القيمة ، فإن هذه القيمة المتوسطة تصبح الحد الأعلى الجديد ؛ خلاف ذلك ، يصبح الحد الأدنى الجديد. تتوقف عملية البحث عندما يتم تضييق النطاق بما فيه الكفاية. ثم نأخذ في الاعتبار مؤشرات s / s ، والتي ترتبط بالحد الأدنى المحدد لقيم الحدود.
النتيجة
كما ترون في الرسم البياني أعلاه ، قمنا بتعيين القيم الحدودية لـ Kafka بأحجام مختلفة. بناءً على النتائج ، توصلنا إلى استنتاج مفاده أن الحد الأقصى للإنتاجية المحتملة للبنية التحتية Dropbox هو 60 ميجا بايت / ثانية لكل وسيط.
يجب التأكيد على أن هذا هو الحد المحافظ ، لأن محتوى رسائلنا التجريبية كان عشوائيًا قدر الإمكان من أجل تقليل تأثير ضغط الرسائل الداخلية في كافكا. عندما تصل حركة المرور إلى الحد الأقصى ، يتم استخدام كل من محرك الأقراص والشبكة بالكامل. في النصوص العملية ، تتوافق رسائل كافكا عادةً مع نمط معين ، نظرًا لأنها غالباً ما تتشكل بواسطة خوارزميات مماثلة. يوفر هذا فرصًا كبيرة لتحسين ضغط الرسائل. لقد اختبرنا سيناريو متطرفًا ، عندما تتكون الرسائل من حرف واحد ، وسجلنا صبيبًا أعلى بكثير ، لأن القرص والشبكة لم يعدا عنق الزجاجة.
بالإضافة إلى ذلك ، تكون مؤشرات الإنتاجية هذه صحيحة إذا كان هناك ما لا يقل عن 5 مجموعات مستهلكية تشترك في الموضوع الذي تم اختباره. بمعنى آخر ، يتم تحقيق عرض نطاق التسجيل المشار إليه عندما يكون عرض نطاق القراءة أكبر بـ 5 مرات. عندما يتجاوز عدد مجموعات المستهلكين 5 ، يبدأ عرض النطاق الترددي للتسجيل في الانخفاض حيث تصبح الشبكة عنق الزجاجة. نظرًا لأن نسبة حركة القراءة والكتابة أقل من 5 في الحالات التي يتم فيها استخدام مجموعات إنتاج Dropbox ، فإن النطاق الترددي الذي تم الحصول عليه يمتد إلى جميع مجموعات الإنتاج.
هذه النتيجة سوف تساعدك على تخطيط الموارد بشكل أفضل لكافكا في المستقبل. على سبيل المثال ، إذا أردنا السماح لما يصل إلى 20٪ من جميع الوسطاء بالعمل دون اتصال بالإنترنت ، فيجب أن يكون الحد الأقصى لعرض النطاق الترددي الآمن للوسيط الواحد 60 ميجابايت / ثانية * 0.8 ~ = 50 ميجابايت / ثانية. يمكن استخدام هذا الرقم من الآن فصاعدا لتحديد حجم الكتلة ، حسب الإنتاجية المخطط لحالات الاستخدام المستقبلية.
أدوات للعمل في المستقبلستكون المنصة والاختبار الآلي أدوات قيمة لفريق Jetstream في عملهما في المستقبل. عندما ننتقل إلى جهاز جديد ، أو نغير تكوين الشبكة أو نقوم بتحديث إصدار Kafka ، يمكننا ببساطة إعادة تشغيل هذه الاختبارات والحصول على بيانات جديدة عن الحدود المسموح بها للتكوين الجديد. يمكننا تطبيق المنهجية نفسها لدراسة العوامل الأخرى التي يمكن أن تؤثر على أداء كافكا بطرق مختلفة. أخيرًا ، يمكن للنظام الأساسي أن يعمل بمثابة أداة اختبار Jetstream لمحاكاة خيارات حركة المرور الجديدة أو إعادة إنشاء المشكلات في بيئة معزولة.
لتلخيصفي هذه المقالة ، قدمنا نهجنا المنهجي لفهم قيود كافكا. من المهم الإشارة إلى أننا حققنا هذه النتائج استنادًا إلى البنية الأساسية لـ Dropbox ، لذلك قد لا تكون أرقامنا قابلة للتطبيق على عمليات تثبيت Kafka الأخرى نظرًا للاختلاف في ظروف الأجهزة والبرامج والشبكة. نأمل أن تساعد المنهجية المقدمة هنا القراء على فهم أنظمتهم الخاصة.