مرحبا اسمي إيفان دافيدوف ، أنا منخرط في أبحاث الأداء في Yandex.Money.

تخيل أن لديك خوادم قوية ، يستضيف كل منها عددًا من التطبيقات. إذا لم يكن هناك الكثير من الأخير ، فإنها لا تتداخل مع عمل بعضهم البعض - فهي مريحة ودافئة. بمجرد وصولك إلى الخدمات الصغيرة وانتزاع جزء من الوظيفة "الثقيلة" في تطبيقات منفصلة.

هنا يمكنك أن تُنفَّذ ، وسيكون هناك الكثير من الخدمات المجهرية ، مما سيصبح من الصعب إدارتها وضمان تحملها للأخطاء. نتيجة لذلك ، سيتم "تجميع" عشرات التطبيقات التي تقاتل من أجل الموارد المشتركة على كل خادم. سوف تتحول إلى "عائلة كبيرة" ، ولكن في عائلة كبيرة لا تنقر مع منقارك!

بمجرد أن واجهنا هذا أيضًا. ستكون قصتي عن ليالٍ ثقيلة بلا نوم ، عندما جلست تحت مصباح في الليل وأطلقت النار على الزناد. بدأ كل شيء مع حقيقة أننا بدأنا نلاحظ مشاكل الشبكة على خوادم المعركة.

لقد أثروا بشكل كبير على الأداء وقاموا بإجراء عمليات سحب كبيرة. في الوقت نفسه ، تبين أن نفس الأخطاء تحدث مع دفق مستخدم عادي ، ولكن إلى حد أقل بكثير.

تكمن المشكلة في استخدام مآخذ TCP بأكثر من 100٪. يحدث هذا عندما يتم فتح وإغلاق جميع مآخذ التوصيل على الخوادم باستمرار. لهذا السبب ، هناك مشاكل في الشبكة من التفاعل بين التطبيقات وأنواع مختلفة من الأخطاء تظهر - المضيف البعيد غير متوفر ، اتصال HTTP / HTTPS (مهلة الاتصال / القراءة ، إغلاق SSL نظير بشكل غير صحيح) وغيرهم.

حتى إذا لم يكن لديك خدمة الدفع الإلكتروني الخاصة بك ، فليس من الصعب للغاية تقييم مدى الألم أثناء أي عملية بيع منتظمة - تزداد حركة المرور عدة مرات ، وقد يؤدي تدهور الأداء إلى خسائر كبيرة. لذلك توصلنا إلى استنتاجين - نحتاج إلى تقييم كيفية استخدام القدرات الحالية ، وعزل التطبيقات عن بعضها البعض.

لعزل التطبيقات ، قررنا اللجوء إلى حاويات. للقيام بذلك ، استخدمنا برنامج Hypervisor الذي يحتوي على العديد من الحاويات المنفصلة مع التطبيقات. يتيح لك ذلك عزل موارد المعالج والذاكرة وأجهزة الإدخال / الإخراج والشبكات وكذلك معالجة الأشجار والمستخدمين وأنظمة الملفات وما إلى ذلك.

من خلال هذا النهج ، يتمتع كل تطبيق ببيئته الخاصة ، والتي توفر المرونة والعزلة والموثوقية وتحسين الأداء العام للنظام. هذا حل جميل وأنيق ، لكن قبل ذلك تحتاج إلى إجابة عدد من الأسئلة:

• ما هو هامش الأداء الذي يحتوي عليه مثيل التطبيق حاليًا؟
• كيف يتم تحجيم التطبيق وهل هناك مورد مكرر في التكوين الحالي؟
• هل من الممكن تحسين أداء مثيل واحد وما هو عنق الزجاجة؟

مع مثل هذه الأسئلة ، جاء إلينا الزملاء - فريق من الباحثين في الأداء.

ماذا نفعل؟

نحن نبذل قصارى جهدنا لضمان أداء خدمتنا ، وقبل كل شيء ، نقوم بالبحث والتحسين في العمليات التجارية لإنتاجنا. تمثل كل عملية تجارية ، سواء كانت تدفع ثمن البضائع في متجر به محفظة أو تقوم بتحويل الأموال بين المستخدمين ، في جوهرها ، سلسلة من الطلبات في النظام.

نحن نجري تجارب ونعد تقارير لتقييم أداء النظام بكثافة عالية للطلبات الواردة. تحتوي التقارير على مقاييس أداء ووصفًا تفصيليًا للمشكلات والاختناقات التي تم تحديدها. بمساعدة هذه المعلومات ، نقوم بتحسين وتحسين نظامنا.

إن تقييم إمكانات كل تطبيق معقد بسبب حقيقة أن العديد من الخدمات المصغرة التي تستخدم قوة جميع الحالات المعنية تشارك في تنظيم تسلسل طلبات العمليات التجارية.

من الناحية المجازية ، نحن نعرف قوة جيشنا ، لكننا لا نعرف إمكانات كل من المقاتلين. لذلك ، بالإضافة إلى البحث المستمر ، من الضروري تقييم الموارد المستخدمة كجزء من عملية إدارة القدرات. وتسمى هذه العملية إدارة القدرات.

يساعد بحثنا في تحديد ومنع نقص الموارد والتنبؤ بمشتريات الحديد والحصول على بيانات دقيقة حول القدرات الحالية والمحتملة للنظام. كجزء من هذه العملية ، تتم مراقبة أداء التطبيق الفعلي (المتوسط ​​والحد الأقصى) ويتم توفير بيانات المخزون الحالي.

جوهر إدارة القدرات هو إيجاد توازن بين الموارد المستهلكة والإنتاجية.

الايجابيات:

• في أي لحظة من المعروف ما يحدث لأداء كل تطبيق.
• مخاطر أقل عند إضافة خدمات microservices جديدة.
• انخفاض تكاليف شراء المعدات الجديدة.
• وتستخدم تلك القدرات الموجودة بالفعل بذكاء أكبر.

كيف تعمل إدارة القدرات

دعنا نعود إلى وضعنا مع العديد من التطبيقات. لقد أجرينا دراسة تهدف إلى تقييم كيفية استخدام القدرات على خوادم الإنتاج.

باختصار ، خطة العمل هي كما يلي:

1. تحديد كثافة المستخدم على تطبيقات محددة.
2. جعل ملف تعريف اطلاق النار.
3. تقييم أداء كل مثيل التطبيق.
4. معدل التدرجية.
5. تجميع التقارير والاستنتاجات على الحد الأدنى المطلوب من الحالات لكل تطبيق في بيئة قتالية.

والآن بمزيد من التفاصيل.

الأدوات

نستخدم Heka و Zabbix لجمع مقاييس كثافة مخصصة. يستخدم Grafana لتصور المقاييس التي تم جمعها.

يلزم Zabbix لمراقبة موارد الخادم ، مثل: وحدة المعالجة المركزية والذاكرة واتصالات الشبكة وقواعد البيانات وغيرها. يوفر Heka بيانات عن عدد ووقت تنفيذ الطلبات الواردة / الصادرة ، ومجموعة من المقاييس في قوائم انتظار التطبيق الداخلي وكمية لا حصر لها من البيانات الأخرى. Grafana هي أداة تصور مرنة تستخدمها فرق Yandex.Money المختلفة. نحن لسنا استثناء.

يمكن أن تظهر Grafana ، على سبيل المثال ، مثل هذه الأشياء

يستخدم أباتشي JMeter كمولد حركة المرور. من خلال مساعدتها ، يتم تجميع سيناريو التصوير ، والذي يتضمن تنفيذ الطلبات ، ومراقبة صلاحية الاستجابة ، والتحكم المرن في تدفق الخلاصة ، وأكثر من ذلك بكثير. هذه الأداة لها كل من إيجابيات وسلبيات ، ولكن لتعمق "لماذا هذا المنتج معين؟" لن أفعل.

بالإضافة إلى JMeter ، يتم استخدام إطار yandex-tank - أداة لاختبار الضغط وتحليل أداء خدمات الويب والتطبيقات. يسمح لك بتوصيل الوحدات النمطية الخاصة بك للحصول على أي وظائف مطلوبة وعرض النتائج في وحدة التحكم أو في شكل رسوم بيانية. يتم عرض نتائج إطلاق النار لدينا في Lunapark (على غرار https://overload.yandex.net ) ، حيث يمكننا أن نلاحظها بالتفصيل في الوقت الحقيقي ، وحتى قمم الثانية ، وتوفير السلطة التقديرية اللازمة والكافية ، وبالتالي الاستجابة بسرعة أكبر للانفجارات ، الناشئة عن اطلاق النار. في الجرافان ، يمكن للمرء أيضًا ضبط الصلابة ، لكن هذا الحل أغلى من حيث الموارد المادية والمنطقية. وأحيانًا نقوم حتى بتحميل بيانات أولية وتصورها من خلال واجهة المستخدم الرسومية Jmeter. ولكن فقط - shhh!

الحديث عن التدهور. تقريبا أي أعطال تحدث في التطبيق تحت تدفق كبير من حركة المرور يتم تحليلها بسرعة باستخدام Kibana . ولكن هذا أيضًا ليس حلاً سحريًا - يمكن تحليل بعض مشكلات الشبكة فقط عن طريق إزالة حركة المرور وتحليلها.

باستخدام Grafana ، قمنا بتحليل كثافة المستخدم في التطبيق لعدة أشهر. قررنا أخذ إجمالي وقت المعالج لتنفيذ الطلبات كوحدة قياس ، أي عدد الطلبات ووقت تنفيذها. لذلك قمنا بتجميع قائمة بأكثر الطلبات "الثقيلة" التي تشكل معظم التدفق إلى التطبيق. كانت هذه القائمة هي التي شكلت أساس ملف تعريف الرماية.

كثافة المستخدم لكل تطبيق لعدة أشهر

اطلاق النار والرؤية الشخصية

ندعو إطلاق إطلاق البرنامج النصي كجزء من تجربة. يتكون ملف التعريف من جزأين.

الجزء الأول هو كتابة برنامج نصي للاستعلام. أثناء التنفيذ ، من الضروري تحليل كثافة المستخدم لكل طلب وارد للتطبيق وجعل نسبة مئوية فيما بينها لتحديد أهم الطلبات التي طال انتظارها. الجزء الثاني هو اختيار معايير نمو التدفق: مع ما كثافة ولأي وقت لتحميل.

لمزيد من الوضوح ، يتم توضيح منهجية تجميع ملف التعريف بشكل أفضل بواسطة المثال.

ينشئ Grafana رسمًا بيانيًا يعكس كثافة المستخدم وحصة كل طلب في إجمالي التدفق. استنادًا إلى وقت التوزيع والاستجابة هذا لكل طلب ، يتم إنشاء مجموعات في JMeter ، كل منها عبارة عن مولد حركة مرور مستقل. يعتمد السيناريو على أكثر الطلبات "ثقيلة" ، حيث يصعب تنفيذ كل شيء (في بعض التطبيقات يوجد أكثر من مائة) ، وهذا ليس مطلوبًا دائمًا بسبب كثافته المنخفضة نسبيًا.

النسبة المئوية للاستعلامات

تبحث هذه الدراسة في كثافة المستخدم في التدفق الثابت ، وغالبًا ما يتم اعتبار "الرشقات" التي تحدث بشكل دوري في القطاع الخاص.

في مثالنا ، يتم النظر في مجموعتين. تضمنت المجموعة الأولى "الطلب 1" و "الطلب 2" بنسبة 1 إلى 2. وبالمثل ، تضمنت المجموعة الثانية الطلبين 3 و 4. أما الطلبات المتبقية للمكون فهي أقل كثافة ، لذلك نحن لا ندرجها في البرنامج النصي.

استعلامات التجميع في Jmeter

بناءً على متوسط ​​وقت الاستجابة لكل مجموعة ، يتم تقدير الأداء بالصيغة:

x = 1000 / t ، حيث t هو متوسط ​​الوقت ، ms

نحصل على نتيجة الحساب ونقدر الكثافة التقريبية مع زيادة عدد الخيوط:

TPS = x * p ، حيث p هو عدد سلاسل العمليات ، TPS هي معاملة في الثانية ، و x هي نتيجة الحساب السابق.

إذا تمت معالجة الطلب في 500 مللي ثانية ، فعندئذٍ مع تيار واحد ، لدينا 2 Tps ، ومع 100 مؤشر ترابط مثالي ، يجب أن يكون 200 Tps. بناءً على النتائج التي تم الحصول عليها ، يمكن تحديد معايير النمو الأولية. بعد التكرار الأول للبحث ، عادة ما يتم ضبط هذه المعلمات.

عندما يكون سيناريو التصوير جاهزًا ، نبدأ في إطلاق النار لمدة دقيقة واحدة في دفق واحد. يتم ذلك من أجل التحقق من إمكانية تشغيل البرنامج النصي بتدفق ثابت ، وتقييم وقت الاستجابة للطلبات في كل مجموعة وللحصول على نسبة مئوية من الطلبات.

عند تشغيل ملف التعريف هذا ، وجدنا أنه بنفس الكثافة ، يتم الحفاظ على نسبة الطلبات ، لأن متوسط ​​وقت الاستجابة في المجموعة الثانية أطول من المجموعة الأولى. لذلك ، وضعنا نفس معدل التدفق لكلا الفريقين. في حالات أخرى ، سيكون من الضروري اختيار المعلمات لكل مجموعة على حدة.

في هذا المثال ، تم تطبيق الكثافة بشكل تدريجي ، أي تمت إضافة عدد معين من التدفقات خلال فترة زمنية معينة.

خيارات نمو الشدة

كانت معايير نمو الشدة كما يلي:

• العدد المستهدف للخيوط هو 100 (يتم تحديده أثناء المشاهدة).
• النمو لمدة 1000 ثانية (~ 16 دقيقة).
• 100 خطوة.

وبالتالي ، كل 10 ثوان نضيف تيار واحد. يختلف الفاصل الزمني بين إضافة مؤشرات الترابط وعدد مؤشرات الترابط المضافة وفقًا لسلوك النظام في خطوة معينة. غالبًا ما يتم تزويد الشدة بنمو سلس ، بحيث يمكنك تتبع حالة النظام في كل مرحلة.

اطلاق النار

عادة ، يبدأ إطلاق النار في الليل من الخوادم البعيدة. في هذا الوقت ، تكون حركة المستخدم ضئيلة للغاية - وهذا يعني أن إطلاق النار لن يؤثر على المستخدمين ، وسيكون الخطأ في النتائج أقل.

وفقًا لنتائج أول عملية إطلاق في حالة واحدة ، نقوم بضبط عدد مؤشرات الترابط ووقت النمو ، وتحليل سلوك النظام ككل وإيجاد انحرافات في العمل. بعد كل التعديلات ، يبدأ إطلاق النار المتكرر في مثيل واحد. في هذه المرحلة ، نحدد الحد الأقصى للأداء ونراقب استخدام موارد الأجهزة لكل من الخادم مع التطبيق وكل ما وراءه.

وفقًا لنتائج التصوير ، كان أداء مثيل واحد من طلبنا يبلغ حوالي 1000 طن. في الوقت نفسه ، تم تسجيل زيادة في وقت الاستجابة لجميع الطلبات دون زيادة الإنتاجية ، أي أننا حققنا التشبع ، ولكن ليس التدهور.

في المرحلة التالية ، قارنا النتائج التي تم الحصول عليها من حالات أخرى. هذا أمر مهم ، نظرًا لأن الأجهزة يمكن أن تختلف ، مما يعني أن الحالات المختلفة يمكن أن تعطي مؤشرات مختلفة جدًا. لذلك كان معنا - تحولت بعض الخوادم إلى أن حجمها أكبر إنتاجية بسبب التوليد والخصائص. لذلك ، حددنا مجموعة من الخوادم التي حققت أفضل النتائج وبحثنا مدى قابليتها للتطوير.

مقارنة أداء الخادم

قابلية التوسع والاختناق

الخطوة التالية هي التحقق من الأداء في الحالات 2 و 3 و 4. من الناحية النظرية ، يجب أن ينمو الأداء بشكل خطي مع زيادة عدد الحالات. في الممارسة العملية ، هذا ليس هو الحال عادة.

في مثالنا ، اتضح أنه خيار مثالي تقريبًا.

سبب تشبع نمو الإنتاجية هو استنفاد تجمعات الموصلات قبل الواجهة الخلفية اللاحقة. يتم حل هذا عن طريق التحكم في حجم التجمعات على الجانب الصادر والوارد ويؤدي إلى زيادة في أداء التطبيق.

في دراسات أخرى ، صادفنا أشياء أكثر إثارة للاهتمام. وقد أظهرت التجارب أنه إلى جانب الأداء ، فإن استخدام وحدة المعالجة المركزية واتصالات قاعدة البيانات ينمو بسرعة. في حالتنا ، حدث هذا لأننا في التكوين بمثيل واحد واجهنا إعداداتنا الخاصة لتجمعات التطبيقات ، وفي حالتين ضاعفنا هذا الرقم ، وبالتالي ضاعفنا الدفق السابق. لم تكن قاعدة البيانات جاهزة لمثل هذا المجلد. وبسبب هذا ، بدأت تجمعات قاعدة البيانات تصبح مسدودة ، ووصلت النسبة المئوية لوحدة المعالجة المركزية المستهلكة إلى علامة حرجة بنسبة 99٪ ، وزاد وقت معالجة الطلبات ، وانخفض جزء من حركة المرور تمامًا. وحصلنا على هذه النتائج بالفعل في حالتين!

لإقناع أنفسنا أخيرًا بمخاوفنا ، أطلقنا النار على 3 حالات. كانت النتائج كما كانت في الأولين تقريبًا ، إلا أنها سرعان ما تعرضت للاضطراب.

يوجد مثال آخر على "المقابس" ، وهو في رأيي هو الأكثر إيلامًا - هذا رمز مكتوب بشكل سيئ. يمكن أن يكون هناك أي شيء تريده ، بدءًا من استعلامات قاعدة البيانات التي تعمل في غضون دقائق ، وتنتهي برمز يسيء تخصيص ذاكرة جهاز Java.

ملخص

نتيجة لذلك ، يحتوي هامش التطبيق الذي تم بحثه في تطبيق المثال الخاص بنا على هامش أداء أكثر من 5 مرات.

لزيادة الإنتاجية ، من الضروري حساب عدد كافٍ من تجمعات المعالج في إعدادات التطبيق. حالتان لتطبيق معين كافية ، واستخدام كل 15 المتاحة هي زائدة عن الحاجة.

بعد الدراسة ، تم الحصول على النتائج التالية:

• تم تحديد كثافة المستخدم لمدة شهر واحد ومراقبته.
• تم تحديد هامش الأداء لمثيل واحد من التطبيق.
• يتم الحصول على النتائج حول الأخطاء التي تحدث تحت دفق كبير.
• تم تحديد اختناقات لمزيد من العمل لزيادة الإنتاجية.
• تم تحديد الحد الأدنى لعدد مثيلات التشغيل الصحيح للتطبيق. ونتيجة لذلك ، تم الكشف عن الاستخدام المفرط للقدرات.

شكلت نتائج الدراسة أساس مشروع نقل المكونات إلى حاويات ، والتي سنناقشها في المقالات التالية. الآن يمكننا أن نقول على وجه اليقين كم من الحاويات ومع ما هي الخصائص اللازمة ل ، وكيفية استخدام قدراتها بعقلانية وما ينبغي العمل عليها لضمان الأداء السليم.

تعال إلى غرفة الدردشة الحميمة من telegram حيث يمكنك دائمًا طلب المشورة ومساعدة الزملاء والتحدث فقط عن أبحاث الإنتاجية.

هذا كل شيء لهذا اليوم. اطرح أسئلة في التعليقات واشترك في مدونة Yandex.Money - سنتحدث قريبًا عن التصيد الاحتيالي وكيفية تجنبه.