نظرة عامة على بنية الخدمة لتقييم المظهر على أساس الشبكات العصبية

دخول

مرحبا!

سأشارك في هذه المقالة تجربتي في بناء بنية خدمات صغيرة لمشروع يستخدم الشبكات العصبية.

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

استمتع القراءة!

بضع كلمات عن المشكلة وحلها

الفكرة الرئيسية هي تقييم جاذبية الشخص على مقياس من عشر نقاط بناءً على الصورة.

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

سننتقل الآن عبر مسار التقييم على المستوى الأعلى، وسنركز على تفاعل الخدمات الصغيرة في سياق البنية الشاملة للمشروع. 

عند العمل على مسار تقييم الجاذبية، تم تقسيم المهمة إلى المكونات التالية:

1. اختيار الوجوه في الصور
2. تصنيف كل شخص
3. تقديم النتيجة

الأول يتم حله بواسطة قوى مدربة مسبقًا ام تي سي ان ان. أما بالنسبة للطريقة الثانية، فقد تم تدريب شبكة عصبية تلافيفية على PyTorch باستخدام ريسنت 34 – من التوازن “الجودة / سرعة الاستدلال على وحدة المعالجة المركزية”

مخطط وظيفي لخط أنابيب التقييم

تحليل متطلبات بنية المشروع

في دورة الحياة ML غالبًا ما تكون مراحل عمل المشروع على البنية وأتمتة نشر النموذج من بين المراحل الأكثر استهلاكًا للوقت والموارد.

دورة حياة مشروع ML

وهذا المشروع ليس استثناءً - فقد تم اتخاذ القرار بدمج مسار التقييم في خدمة عبر الإنترنت، الأمر الذي يتطلب الانغماس في الهندسة المعمارية. وتم تحديد المتطلبات الأساسية التالية:

1. تخزين السجل الموحد – يجب على جميع الخدمات كتابة السجلات في مكان واحد، ويجب أن تكون ملائمة للتحليل
2. إمكانية التوسع الأفقي لخدمة التقييم - باعتباره عنق الزجاجة الأكثر احتمالاً
3. يجب تخصيص نفس القدر من موارد المعالج لتقييم كل صورة لتجنب القيم المتطرفة في توزيع الوقت للاستدلال
4. (إعادة) نشر سريع لكل من الخدمات المحددة والمكدس ككل
5. القدرة، إذا لزم الأمر، على استخدام الأشياء المشتركة في خدمات مختلفة

هندسة معمارية

بعد تحليل المتطلبات، أصبح من الواضح أن بنية الخدمات الصغيرة تناسب تمامًا تقريبًا.

من أجل التخلص من المشاكل غير الضرورية، تم اختيار Telegram API كواجهة أمامية.

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

الرسم الهيكلي للهندسة المعمارية النهائية

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

الخدمة المصغرة "attrai-telegram-bot"

تتضمن هذه الخدمة المصغرة جميع التفاعلات مع Telegram API. هناك سيناريوهان رئيسيان: العمل باستخدام صورة مخصصة والعمل مع نتيجة مسار التقييم. دعونا ننظر إلى كلا السيناريوهين بشكل عام.

عند تلقي رسالة مخصصة تحتوي على صورة:

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

أيضًا، تستمع هذه الخدمة الصغيرة، مثل عامل الكرفس، إلى قائمة الانتظار "after_estimate"، المخصصة للمهام التي مرت عبر مسار التقييم.

عند استلام مهمة جديدة من "after_estimate":

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

تقييم الخدمات المصغرة "attrai-estimator"

هذه الخدمة الصغيرة عبارة عن عامل كرفس وتلخص كل ما يتعلق بمسار تقييم الصور. لا توجد سوى خوارزمية واحدة عاملة هنا – فلنحللها.

عند استلام مهمة جديدة من "to_estimate":

1. لنقم بتشغيل الصورة من خلال مسار التقييم:
   1. تحميل الصورة في الذاكرة
   2. نأتي الصورة إلى الحجم المطلوب
   3. البحث عن جميع الوجوه (MTCNN)
   4. نقوم بتقييم جميع الوجوه (نقوم بلف الوجوه الموجودة في الخطوة الأخيرة في دفعة ونستنتج ResNet34)
   5. تقديم الصورة النهائية
      1. دعونا نرسم المربعات المحيطة
      2. رسم التقييمات
2. حذف صورة مخصصة (أصلية).
3. حفظ المخرجات من مسار التقييم
4. نضع المهمة في قائمة الانتظار "after_estimate"، والتي يتم الاستماع إليها بواسطة الخدمة المصغرة "attrai-telegram-bot" التي تمت مناقشتها أعلاه.

Graylog (+ mongoDB + Elasticsearch)

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

وقع الاختيار عليه، وليس على المعتاد ELK المكدس، وذلك بسبب سهولة العمل معه من بايثون. كل ما عليك فعله لتسجيل الدخول إلى Graylog هو إضافة GELFTCPHandler من الحزمة greypy إلى بقية معالجات مسجل الجذر الخاصة بخدمة python الصغيرة الخاصة بنا.

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

RabbitMQ

RabbitMQ هو وسيط رسائل يعتمد على بروتوكول AMQP.

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

رديس

رديس هو NoSQL DBMS الذي يعمل مع هياكل البيانات ذات القيمة الرئيسية

في بعض الأحيان تكون هناك حاجة لاستخدام كائنات شائعة تنفذ هياكل بيانات معينة في خدمات بايثون الصغيرة المختلفة.

على سبيل المثال، يقوم Redis بتخزين خريطة تجزئة بالنموذج "telegram_user_id => عدد المهام النشطة في قائمة الانتظار"، والتي تسمح لك بتحديد عدد الطلبات من مستخدم واحد إلى قيمة معينة، وبالتالي منع هجمات DoS.

دعونا إضفاء الطابع الرسمي على عملية معالجة الصور الناجحة

1. يرسل المستخدم صورة إلى روبوت Telegram
2. يتلقى "attrai-telegram-bot" رسالة من Telegram API ويقوم بتحليلها
3. تتم إضافة المهمة التي تحتوي على الصورة إلى قائمة الانتظار غير المتزامنة "to_estimate"
4. يتلقى المستخدم رسالة مع وقت التقييم المخطط له
5. يأخذ "attrai-estimator" مهمة من قائمة الانتظار "to_estimate"، ويقوم بتشغيل التقديرات عبر المسار وينتج المهمة في قائمة الانتظار "after_estimate"
6. "attrai-telegram-bot" الذي يستمع إلى قائمة الانتظار "after_estimate"، يرسل النتيجة إلى المستخدم

DevOps

أخيرًا، بعد مراجعة البنية، يمكنك الانتقال إلى الجزء المثير للاهتمام بنفس القدر - DevOps

عامل ميناء سرب

 

عامل ميناء سرب  - نظام تجميع، يتم تنفيذ وظائفه داخل Docker Engine ومتوفر خارج الصندوق.

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

مجموعة تضم مديرًا قائدًا واحدًا وثلاثة عمال

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

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

دوكر ستاك

في وضع السرب، يكون مسؤولاً عن نشر الأكوام (مجموعات من خدمات عامل الإرساء) مكدس عامل الميناء

وهو يدعم تكوينات إنشاء عامل الإرساء، مما يسمح لك باستخدام معلمات النشر بشكل إضافي.  

على سبيل المثال، باستخدام هذه المعلمات، كانت الموارد لكل مثيل من مثيلات الخدمة الصغيرة للتقييم محدودة (نحن نخصص N من النوى لمثيلات N، وفي الخدمة الصغيرة نفسها نحدد عدد النوى التي تستخدمها PyTorch بمركز واحد)

attrai_estimator:
  image: 'erqups/attrai_estimator:1.2'
  deploy:
    replicas: 4
    resources:
      limits:
        cpus: '4'
    restart_policy:
      condition: on-failure
      …

من المهم ملاحظة أن Redis وRabbitMQ وGraylog هي خدمات ذات حالة محددة ولا يمكن توسيع نطاقها بسهولة مثل "attrai-estimator".

ينذر بالسؤال - لماذا لا Kubernetes؟

يبدو أن استخدام Kubernetes في المشاريع الصغيرة والمتوسطة الحجم يعد بمثابة نفقة عامة؛ يمكن الحصول على جميع الوظائف الضرورية من Docker Swarm، وهو سهل الاستخدام تمامًا لمنسق الحاويات وله أيضًا حاجز منخفض للدخول.

بنية التحتية

تم نشر كل هذا على نظام VDS بالخصائص التالية:

• وحدة المعالجة المركزية: معالج Intel® Xeon® Gold 4 رباعي النواة بسرعة 5120 جيجا هرتز
• ذاكرة الوصول العشوائي: 8 GB
• SSD: 160 جيجا بايت

بعد اختبار التحميل المحلي، بدا أنه مع التدفق الكبير للمستخدمين، سيكون هذا الجهاز كافيا.

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

بعض المزيد من الرسومات

عدد المستخدمين الفريدين وطلبات التقييم منذ النشر، اعتمادًا على اليوم

توزيع وقت استنتاج خط أنابيب التقييم

النتائج

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

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

سأضيف أنه في البداية كانت المقالة أطول، ولكن لكي لا أقوم بنشر قراءة طويلة، قررت حذف بعض النقاط في هذه المقالة - وسنعود إليها في المنشورات المستقبلية.

يمكنك النقر على الروبوت على Telegram - @AttraiBot، وسيعمل على الأقل حتى نهاية خريف 2020. اسمحوا لي أن أذكرك أنه لا يتم تخزين أي بيانات مستخدم - لا الصور الأصلية ولا نتائج مسار التقييم - يتم هدم كل شيء بعد المعالجة.

المصدر: www.habr.com