عصبی نیٹ ورکس کی بنیاد پر ظاہری شکل کی تشخیص کے لیے سروس فن تعمیر کا عمومی جائزہ

داخلہ

ہیلو!

اس آرٹیکل میں میں نیورل نیٹ ورکس کا استعمال کرتے ہوئے ایک پروجیکٹ کے لیے مائیکرو سروس آرکیٹیکچر بنانے کے اپنے تجربے کا اشتراک کروں گا۔

آئیے آرکیٹیکچر کے تقاضوں کے بارے میں بات کرتے ہیں، مختلف ساختی خاکوں کو دیکھتے ہیں، مکمل فن تعمیر کے ہر ایک اجزاء کا تجزیہ کرتے ہیں، اور حل کے تکنیکی میٹرکس کا بھی جائزہ لیتے ہیں۔

پڑھنے کا لطف اٹھائیں!

مسئلہ اور اس کے حل کے بارے میں چند الفاظ

مرکزی خیال تصویر کی بنیاد پر دس نکاتی پیمانے پر کسی شخص کی کشش کا اندازہ لگانا ہے۔

اس مضمون میں ہم استعمال کیے جانے والے اعصابی نیٹ ورکس اور ڈیٹا کی تیاری اور تربیت کے عمل دونوں کو بیان کرنے سے ہٹ جائیں گے۔ تاہم، درج ذیل اشاعتوں میں سے ایک میں، ہم یقینی طور پر گہرائی کی سطح پر تشخیصی پائپ لائن کا تجزیہ کرنے کے لیے واپس آئیں گے۔

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

کشش کی تشخیص پائپ لائن پر کام کرتے وقت، کام کو مندرجہ ذیل اجزاء میں تقسیم کیا گیا تھا:

1. تصاویر میں چہروں کا انتخاب
2. ہر شخص کی درجہ بندی
3. نتیجہ پیش کریں۔

سب سے پہلے پہلے سے تربیت یافتہ افواج کی طرف سے حل کیا جاتا ہے ایم ٹی سی این این. دوسرے کے لیے، ایک convolutional عصبی نیٹ ورک کو PyTorch پر استعمال کرتے ہوئے تربیت دی گئی تھی۔ ResNet34 - بیلنس سے "سی پی یو پر اندازہ کی کوالٹی / رفتار"

تشخیصی پائپ لائن کا فنکشنل ڈایاگرام

پروجیکٹ فن تعمیر کی ضروریات کا تجزیہ

زندگی کے چکر میں ML ماڈل کی تعیناتی کے فن تعمیر اور آٹومیشن پر کام کے پروجیکٹ کے مراحل اکثر زیادہ وقت لینے والے اور وسائل کے استعمال میں ہوتے ہیں۔

ایم ایل پروجیکٹ کا لائف سائیکل

یہ پروجیکٹ کوئی مستثنیٰ نہیں ہے - اسسمنٹ پائپ لائن کو ایک آن لائن سروس میں لپیٹنے کا فیصلہ کیا گیا تھا، جس کے لیے خود کو فن تعمیر میں غرق کرنے کی ضرورت تھی۔ مندرجہ ذیل بنیادی ضروریات کی نشاندہی کی گئی تھی:

1. یونیفائیڈ لاگ اسٹوریج - تمام سروسز کو ایک جگہ لاگ لکھنا چاہیے، ان کا تجزیہ کرنے کے لیے آسان ہونا چاہیے۔
2. اسسمنٹ سروس کی افقی اسکیلنگ کا امکان - سب سے زیادہ ممکنہ رکاوٹ کے طور پر
3. پروسیسر کے وسائل کی اتنی ہی مقدار ہر تصویر کا جائزہ لینے کے لیے مختص کی جانی چاہیے تاکہ اندازہ لگانے کے لیے وقت کی تقسیم میں آؤٹ لیرز سے بچا جا سکے۔
4. مخصوص خدمات اور مجموعی طور پر اسٹیک دونوں کی تیز (دوبارہ) تعیناتی۔
5. اگر ضروری ہو تو مختلف خدمات میں عام اشیاء کو استعمال کرنے کی صلاحیت

فن تعمیر

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

غیر ضروری سر درد سے چھٹکارا پانے کے لیے ٹیلیگرام API کو فرنٹ اینڈ کے طور پر چنا گیا۔

سب سے پہلے، آئیے تیار شدہ فن تعمیر کے ساختی خاکے کو دیکھتے ہیں، پھر ہر ایک اجزاء کی تفصیل کی طرف بڑھتے ہیں، اور کامیاب امیج پروسیسنگ کے عمل کو بھی باقاعدہ بناتے ہیں۔

تیار شدہ فن تعمیر کا ساختی خاکہ

آئیے تصویر کی تشخیص کے عمل میں انہیں واحد ذمہ داری کی نشاندہی کرتے ہوئے، خاکہ کے ہر ایک اجزاء کے بارے میں مزید تفصیل سے بات کرتے ہیں۔

مائیکرو سروس "اٹرای-ٹیلیگرام-بوٹ"

یہ مائیکرو سروس ٹیلیگرام API کے ساتھ تمام تعاملات کو سمیٹتی ہے۔ 2 اہم منظرنامے ہیں: حسب ضرورت تصویر کے ساتھ کام کرنا اور تشخیصی پائپ لائن کے نتیجے کے ساتھ کام کرنا۔ آئیے عام اصطلاحات میں دونوں منظرناموں کو دیکھیں۔

تصویر کے ساتھ حسب ضرورت پیغام موصول ہونے پر:

1. فلٹریشن کی جاتی ہے، جس میں درج ذیل چیک ہوتے ہیں:
   • بہترین تصویری سائز کی دستیابی
   • صارف کی تصاویر کی تعداد پہلے ہی قطار میں ہے۔
2. ابتدائی فلٹرنگ کو پاس کرتے وقت، تصویر کو ڈوکر والیوم میں محفوظ کیا جاتا ہے۔
3. "to_estimate" قطار میں ایک ٹاسک تیار کیا جاتا ہے، جس میں دیگر چیزوں کے علاوہ، ہمارے حجم میں موجود تصویر کا راستہ بھی شامل ہوتا ہے۔
4. اگر مندرجہ بالا مراحل کامیابی سے مکمل ہو جاتے ہیں، تو صارف کو تصویری پروسیسنگ کے تخمینی وقت کے ساتھ ایک پیغام ملے گا، جس کا حساب قطار میں کاموں کی تعداد کی بنیاد پر کیا جاتا ہے۔ اگر کوئی خرابی واقع ہوتی ہے تو، صارف کو واضح طور پر مطلع کیا جائے گا کہ کیا غلطی ہوئی ہے اس بارے میں معلومات کے ساتھ ایک پیغام بھیج کر۔

اس کے علاوہ، یہ مائیکرو سروس، سیلری ورکر کی طرح، "after_esttimate" قطار کو سنتا ہے، جس کا مقصد ان کاموں کے لیے ہوتا ہے جو تشخیصی پائپ لائن سے گزر چکے ہوتے ہیں۔

"after_estimate" سے نیا ٹاسک وصول کرتے وقت:

1. اگر تصویر پر کامیابی سے کارروائی ہو جاتی ہے، تو ہم نتیجہ صارف کو بھیج دیتے ہیں؛ اگر نہیں، تو ہم ایک غلطی کے بارے میں مطلع کرتے ہیں۔
2. اس تصویر کو ہٹانا جو تشخیصی پائپ لائن کا نتیجہ ہے۔

تشخیص مائیکرو سرویس "اٹرائی-اسٹیمیٹر"

یہ مائیکرو سروس سیلری ورکر ہے اور امیج ایویلیویشن پائپ لائن سے متعلق ہر چیز کو سمیٹ لیتی ہے۔ یہاں صرف ایک کام کرنے والا الگورتھم ہے - آئیے اس کا تجزیہ کریں۔

"to_estimate" سے نیا کام موصول ہونے پر:

1. آئیے تصویر کو تشخیصی پائپ لائن کے ذریعے چلائیں:
   1. تصویر کو میموری میں لوڈ کیا جا رہا ہے۔
   2. ہم تصویر کو مطلوبہ سائز میں لاتے ہیں۔
   3. تمام چہرے تلاش کرنا (MTCNN)
   4. ہم تمام چہروں کا جائزہ لیتے ہیں (ہم آخری مرحلے میں پائے جانے والے چہروں کو بیچ میں لپیٹتے ہیں اور ResNet34 کا اندازہ لگاتے ہیں)
   5. حتمی تصویر پیش کریں۔
      1. آئیے باؤنڈنگ بکس کھینچتے ہیں۔
      2. درجہ بندی ڈرائنگ
2. اپنی مرضی کے مطابق (اصل) تصویر کو حذف کرنا
3. تشخیصی پائپ لائن سے آؤٹ پٹ کو بچانا
4. ہم نے اس کام کو "after_esttimate" قطار میں ڈال دیا، جسے اوپر زیر بحث "attrai-telegram-bot" مائیکرو سروس کے ذریعے سنا جاتا ہے۔

Graylog (+ mongoDB + Elasticsearch)

گرےلوگ مرکزی لاگ مینجمنٹ کے لیے ایک حل ہے۔ اس منصوبے میں، اسے اپنے مطلوبہ مقصد کے لیے استعمال کیا گیا تھا۔

انتخاب اس پر گرا، اور عام پر نہیں ELK stack، ازگر سے اس کے ساتھ کام کرنے کی سہولت کی وجہ سے۔ Graylog میں لاگ ان کرنے کے لیے آپ کو بس پیکج سے GELFTCPHhandler کو شامل کرنے کی ضرورت ہے۔ خاکستری ہمارے python microservice کے باقی روٹ لاگر ہینڈلرز کو۔

کسی ایسے شخص کے طور پر جس نے پہلے صرف ELK اسٹیک کے ساتھ کام کیا تھا، مجھے Graylog کے ساتھ کام کرتے ہوئے مجموعی طور پر مثبت تجربہ ملا۔ صرف ایک چیز جو افسردہ کرتی ہے وہ ہے Graylog ویب انٹرفیس پر Kibana کی خصوصیات میں برتری۔

خرگوش

خرگوش AMQP پروٹوکول پر مبنی ایک میسج بروکر ہے۔

اس منصوبے میں اسے بطور استعمال کیا گیا تھا۔ سب سے زیادہ مستحکم اور وقت کا تجربہ سیلری کے لیے بروکر اور پائیدار موڈ میں کام کیا۔

ریڈس

ریڈس ایک NoSQL DBMS ہے جو کلیدی قدر ڈیٹا ڈھانچے کے ساتھ کام کرتا ہے۔

بعض اوقات عام اشیاء کو استعمال کرنے کی ضرورت ہوتی ہے جو مختلف Python مائیکرو سروسز میں مخصوص ڈیٹا ڈھانچے کو نافذ کرتی ہیں۔

مثال کے طور پر، Redis "telegram_user_id => قطار میں فعال کاموں کی تعداد" فارم کا ایک ہیش میپ اسٹور کرتا ہے، جو آپ کو ایک صارف کی درخواستوں کی تعداد کو ایک خاص قدر تک محدود کرنے کی اجازت دیتا ہے اور اس طرح، DoS حملوں کو روکتا ہے۔

آئیے کامیاب امیج پروسیسنگ کے عمل کو باقاعدہ بنائیں

1. صارف ٹیلیگرام بوٹ کو ایک تصویر بھیجتا ہے۔
2. "attrai-telegram-bot" ٹیلیگرام API سے ایک پیغام وصول کرتا ہے اور اسے پارس کرتا ہے۔
3. تصویر کے ساتھ کام کو غیر مطابقت پذیر قطار "to_estimate" میں شامل کیا گیا ہے
4. صارف کو منصوبہ بند تشخیص کے وقت کے ساتھ ایک پیغام موصول ہوتا ہے۔
5. "attrai-estimator" "to_estimate" قطار سے ایک ٹاسک لیتا ہے، پائپ لائن کے ذریعے تخمینہ چلاتا ہے اور ٹاسک کو "after_esttimate" قطار میں تیار کرتا ہے۔
6. "attrai-telegram-bot" "after_estimate" قطار کو سن کر نتیجہ صارف کو بھیجتا ہے

DevOps

آخر میں، فن تعمیر کا جائزہ لینے کے بعد، آپ اتنے ہی دلچسپ حصے کی طرف بڑھ سکتے ہیں - DevOps

ڈاکر بھیڑ

 

ڈاکر بھیڑ  - ایک کلسٹرنگ سسٹم، جس کی فعالیت ڈوکر انجن کے اندر لاگو ہوتی ہے اور باکس سے باہر دستیاب ہوتی ہے۔

"swarm" کا استعمال کرتے ہوئے، ہمارے کلسٹر میں تمام نوڈس کو 2 اقسام میں تقسیم کیا جا سکتا ہے - کارکن اور مینیجر۔ پہلی قسم کی مشینوں پر، کنٹینرز کے گروپس (ڈھیر) تعینات کیے جاتے ہیں، دوسری قسم کی مشینیں اسکیلنگ، توازن اور دیگر ٹھنڈی خصوصیات. مینیجرز بھی بطور ڈیفالٹ کارکن ہوتے ہیں۔

ایک لیڈر مینیجر اور تین کارکنوں کے ساتھ کلسٹر

کم از کم ممکنہ کلسٹر سائز 1 نوڈ ہے؛ ایک مشین بیک وقت لیڈر مینیجر اور ورکر کے طور پر کام کرے گی۔ منصوبے کے سائز اور غلطی کو برداشت کرنے کے لیے کم از کم تقاضوں کی بنیاد پر، یہ طریقہ استعمال کرنے کا فیصلہ کیا گیا۔

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

ڈاکر اسٹیک

سوارم موڈ میں، وہ ڈھیروں کی تعیناتی کے لیے ذمہ دار ہے (ڈاکر سروسز کے سیٹ) ڈاکر اسٹیک

یہ docker-compose configs کو سپورٹ کرتا ہے، جو آپ کو اضافی طور پر تعیناتی کے اختیارات استعمال کرنے کی اجازت دیتا ہے۔  

مثال کے طور پر، ان پیرامیٹرز کا استعمال کرتے ہوئے، ہر تشخیصی مائیکرو سرویس مثالوں کے وسائل محدود تھے (ہم 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
• رام: 8 GB
• ایس ایس ڈی: 160 جی بی

مقامی لوڈ کی جانچ کے بعد، ایسا لگتا تھا کہ صارفین کی شدید آمد کے ساتھ، یہ مشین کافی ہوگی۔

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

کچھ اور گرافکس

دن کے لحاظ سے، تعیناتی کے بعد سے منفرد صارفین اور تشخیص کی درخواستوں کی تعداد

تشخیص پائپ لائن کا اندازہ وقت کی تقسیم

نتائج

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

میں سمجھتا ہوں کہ چھوٹے اور درمیانے درجے کے منصوبے جو اپنے عمل میں CPU پر نیورل نیٹ ورکس کے حقیقی وقت کا اندازہ استعمال کرتے ہیں وہ اس مضمون میں بیان کردہ طریقوں کو کامیابی سے اپنا سکتے ہیں۔

میں شامل کروں گا کہ ابتدائی طور پر مضمون لمبا تھا، لیکن طویل مطالعہ شائع نہ کرنے کے لیے، میں نے اس مضمون کے کچھ نکات کو چھوڑنے کا فیصلہ کیا - ہم مستقبل کی اشاعتوں میں ان پر واپس جائیں گے۔

آپ ٹیلیگرام پر بوٹ کو پوک کر سکتے ہیں - @AttraiBot، یہ کم از کم 2020 کے خزاں کے اختتام تک کام کرے گا۔ میں آپ کو یاد دلاتا ہوں کہ صارف کا کوئی ڈیٹا محفوظ نہیں کیا جاتا ہے - نہ ہی اصل تصاویر، اور نہ ہی تشخیصی پائپ لائن کے نتائج - پروسیسنگ کے بعد ہر چیز کو منہدم کر دیا جاتا ہے۔

ماخذ: www.habr.com