نمای کلی معماری سرویس برای ارزیابی ظاهر بر اساس شبکه های عصبی

ورود

سلام!

در این مقاله من تجربه خود را از ساخت یک معماری میکروسرویس برای یک پروژه با استفاده از شبکه های عصبی به اشتراک خواهم گذاشت.

بیایید در مورد الزامات معماری صحبت کنیم، به نمودارهای ساختاری مختلف نگاه کنیم، هر یک از اجزای معماری نهایی را تجزیه و تحلیل کنیم، و همچنین معیارهای فنی راه حل را ارزیابی کنیم.

لذت بردن از خواندن!

چند کلمه در مورد مشکل و راه حل آن

ایده اصلی ارزیابی جذابیت یک فرد در مقیاس ده درجه ای بر اساس عکس است.

در این مقاله از توصیف شبکه‌های عصبی مورد استفاده و فرآیند آماده‌سازی و آموزش داده‌ها دور می‌شویم. با این حال، در یکی از انتشارات زیر، ما قطعا به تحلیل خط لوله ارزیابی در سطح عمیق باز خواهیم گشت.

اکنون ما از طریق خط لوله ارزیابی در سطح بالا می گذریم و بر تعامل میکروسرویس ها در زمینه معماری کلی پروژه تمرکز می کنیم. 

هنگام کار بر روی خط لوله ارزیابی جذابیت، وظیفه به اجزای زیر تقسیم شد:

1. انتخاب چهره در عکس ها
2. رتبه بندی هر فرد
3. نتیجه را رندر کنید

اولین مورد توسط نیروهای از پیش آموزش دیده حل می شود MTCNN. برای دوم، یک شبکه عصبی کانولوشنال با استفاده از PyTorch آموزش داده شد ResNet34 - از تعادل "کیفیت / سرعت استنتاج در CPU"

نمودار عملکردی خط لوله ارزیابی

تجزیه و تحلیل الزامات معماری پروژه

در چرخه زندگی ML مراحل پروژه کار بر روی معماری و اتوماسیون استقرار مدل اغلب از زمان‌برترین و پر مصرف‌ترین منابع هستند.

چرخه حیات یک پروژه ML

این پروژه از این قاعده مستثنی نیست - تصمیم گرفته شد تا خط لوله ارزیابی را در یک سرویس آنلاین قرار دهیم، که نیاز به غوطه ور شدن در معماری داشت. الزامات اساسی زیر مشخص شد:

1. ذخیره‌سازی گزارش یکپارچه - همه سرویس‌ها باید گزارش‌ها را در یک مکان بنویسند، تجزیه و تحلیل آنها باید راحت باشد
2. امکان مقیاس بندی افقی سرویس ارزیابی - به عنوان محتمل ترین تنگنا
3. مقدار یکسانی از منابع پردازنده باید برای ارزیابی هر تصویر اختصاص داده شود تا از موارد پرت در توزیع زمان برای استنتاج جلوگیری شود.
4. استقرار سریع (دوباره) هر دو سرویس خاص و پشته به عنوان یک کل
5. امکان استفاده از اشیاء مشترک در سرویس های مختلف در صورت لزوم

معماری

پس از تجزیه و تحلیل الزامات، مشخص شد که معماری میکروسرویس تقریباً کاملاً مطابقت دارد.

برای رهایی از سردردهای غیرضروری، API تلگرام به عنوان فرانت اند انتخاب شد.

ابتدا، بیایید به نمودار ساختاری معماری تکمیل شده نگاه کنیم، سپس به توضیح هر یک از اجزای آن بپردازیم و همچنین روند پردازش موفق تصویر را رسمی کنیم.

نمودار ساختاری معماری تمام شده

بیایید با جزئیات بیشتر در مورد هر یک از اجزای نمودار صحبت کنیم و آنها را به عنوان مسئولیت واحد در فرآیند ارزیابی تصویر نشان دهیم.

میکروسرویس “attrai-telegram-bot”

این میکروسرویس تمام تعاملات با API تلگرام را در بر می گیرد. 2 سناریو اصلی وجود دارد: کار با یک تصویر سفارشی و کار با نتیجه یک خط لوله ارزیابی. بیایید به هر دو سناریو به صورت کلی نگاه کنیم.

هنگام دریافت یک پیام سفارشی با یک تصویر:

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 را از بسته اضافه کنید خاکستری رنگ به بقیه گردانندگان روت لاگر میکروسرویس پایتون ما.

به عنوان فردی که قبلا فقط با پشته ELK کار کرده بودم، در حین کار با Graylog تجربه کلی مثبتی داشتم. تنها چیزی که مایوس کننده است برتری ویژگی های Kibana نسبت به رابط وب Graylog است.

خرگوش ام کیو

خرگوش ام کیو یک کارگزار پیام مبتنی بر پروتکل AMQP است.

در این پروژه به عنوان استفاده شد پایدارترین و با زمان تست شده دلال کرفس و در حالت بادوام کار کرد.

Redis

Redis یک DBMS NoSQL است که با ساختارهای داده کلید-مقدار کار می کند

گاهی اوقات نیاز به استفاده از اشیاء مشترکی وجود دارد که ساختارهای داده خاصی را در میکروسرویس های مختلف پایتون پیاده سازی می کنند.

به عنوان مثال، Redis یک نقشه به شکل "telegram_user_id => تعداد وظایف فعال در صف" را ذخیره می کند، که به شما امکان می دهد تعداد درخواست های یک کاربر را به مقدار خاصی محدود کنید و در نتیجه از حملات DoS جلوگیری کنید.

بیایید روند پردازش تصویر موفق را رسمی کنیم

1. کاربر تصویری را برای ربات تلگرام ارسال می کند
2. "attrai-telegram-bot" یک پیام از API تلگرام دریافت می کند و آن را تجزیه می کند
3. کار با تصویر به صف ناهمزمان "to_estimate" اضافه می شود
4. کاربر پیامی با زمان ارزیابی برنامه ریزی شده دریافت می کند
5. "attrai-estimator" یک کار را از صف "to_estimate" می گیرد، تخمین ها را از طریق خط لوله اجرا می کند و وظیفه را در صف "after_estimate" تولید می کند.
6. "attrai-telegram-bot" با گوش دادن به صف "after_estimate" نتیجه را برای کاربر ارسال می کند.

DevOps

در نهایت، پس از بررسی معماری، می توانید به بخش به همان اندازه جالب - DevOps بروید

داکر سوارم

 

داکر سوارم  - یک سیستم خوشه بندی که عملکرد آن در داخل Docker Engine پیاده سازی شده و خارج از جعبه در دسترس است.

با استفاده از "ازدحام"، تمام گره ها در خوشه ما را می توان به 2 نوع - کارگر و مدیر تقسیم کرد. در ماشین‌های نوع اول، گروه‌هایی از کانتینرها (پشته‌ها) مستقر می‌شوند، ماشین‌های نوع دوم وظیفه جرم‌گیری، بالانس‌سازی و سایر ویژگی های جالب. مدیران نیز به طور پیش فرض کارگر هستند.

خوشه با یک مدیر رهبر و سه کارگر

حداقل اندازه خوشه ممکن 1 گره است؛ یک ماشین به طور همزمان به عنوان مدیر رهبر و کارگر عمل می کند. بر اساس اندازه پروژه و حداقل الزامات برای تحمل خطا، تصمیم به استفاده از این رویکرد گرفته شد.

با نگاهی به آینده، می گویم که از اولین تحویل تولید، که در اواسط خرداد بود، هیچ مشکلی در ارتباط با این سازمان خوشه ای وجود نداشته است (اما این بدان معنا نیست که چنین سازمانی به هیچ وجه در هر متوسط ​​و بزرگ قابل قبول است. پروژه هایی که مشمول الزامات تحمل خطا هستند).

Docker Stack

در حالت ازدحام، او مسئول استقرار پشته ها (مجموعه خدمات داکر) است. پشته داکر

از پیکربندی‌های docker-compose پشتیبانی می‌کند و به شما امکان می‌دهد تا از پارامترهای استقرار نیز استفاده کنید.  

به عنوان مثال، با استفاده از این پارامترها، منابع برای هر یک از نمونه های میکروسرویس ارزیابی محدود بود (ما 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 با ویژگی های زیر مستقر شدند:

• CPU: 4 هسته ای Intel® Xeon® Gold 5120 CPU @ 2.20GHz
• RAM: 8 GB
• SSD: 160 گیگابایت

پس از آزمایش بار محلی، به نظر می رسید که با هجوم جدی کاربران، این دستگاه کافی باشد.

اما، بلافاصله پس از استقرار، من پیوندی به یکی از محبوب ترین ایمیجبوردها در کشورهای مستقل مشترک المنافع (آره، همان) ارسال کردم، پس از آن مردم علاقه مند شدند و در عرض چند ساعت این سرویس ده ها هزار تصویر را با موفقیت پردازش کرد. در همان زمان، در لحظات اوج، منابع CPU و RAM حتی به نصف استفاده نمی شد.

چند گرافیک بیشتر

تعداد کاربران منحصر به فرد و درخواست های ارزیابی از زمان استقرار، بسته به روز

توزیع زمان استنتاج خط لوله ارزیابی

یافته ها

به طور خلاصه، می توانم بگویم که معماری و رویکرد ارکستراسیون کانتینرها کاملاً خود را توجیه می کند - حتی در لحظات اوج هیچ افت یا کاهشی در زمان پردازش وجود نداشت. 

من فکر می‌کنم که پروژه‌های کوچک و متوسطی که از استنتاج بلادرنگ شبکه‌های عصبی بر روی CPU در فرآیند خود استفاده می‌کنند، می‌توانند با موفقیت از شیوه‌های توصیف شده در این مقاله استفاده کنند.

اضافه می کنم که در ابتدا مقاله طولانی تر بود ، اما برای اینکه طولانی مدت پست نشود ، تصمیم گرفتم برخی از نکات را در این مقاله حذف کنم - در انتشارات بعدی به آنها باز خواهیم گشت.

می‌توانید ربات را در تلگرام - @AttraiBot بکشید، حداقل تا پایان پاییز 2020 کار می‌کند. اجازه دهید به شما یادآوری کنم که هیچ داده کاربر ذخیره نمی شود - نه تصاویر اصلی و نه نتایج خط لوله ارزیابی - همه چیز پس از پردازش تخریب می شود.

منبع: www.habr.com