اعصابي نيٽ ورڪ جي بنياد تي ظاهري تشخيص لاء خدمت جي فن تعمير جو عام جائزو

جائز آهي

هيلو!

هن آرٽيڪل ۾ آئون پنهنجي تجربي کي شيئر ڪندس مائڪروسروس فن تعمير جي تعمير لاءِ هڪ منصوبي لاءِ نيورل نيٽ ورڪ استعمال ڪندي.

اچو ته فن تعمير جي ضرورتن جي باري ۾ ڳالهايون، مختلف ڍانچي جي شڪلين کي ڏسو، مڪمل ٿيل فن تعمير جي هر هڪ اجزاء جو تجزيو ڪيو، ۽ حل جي ٽيڪنيڪل ميٽرڪ جو پڻ جائزو وٺو.

پڙهڻ جو مزو

مسئلو ۽ ان جي حل جي باري ۾ چند لفظ

بنيادي خيال هڪ تصوير جي بنياد تي ڏهن نقطي پيماني تي هڪ شخص جي ڪشش جو جائزو وٺڻ آهي.

هن مقالي ۾ اسين استعمال ڪيل نيرل نيٽ ورڪ ۽ ڊيٽا جي تياري ۽ تربيت جي عمل کي بيان ڪرڻ کان پري ٿي وينداسين. بهرحال، هيٺ ڏنل اشاعتن مان هڪ ۾، اسان ضرور ضرور واپس ڪنداسين تشخيص پائپ لائن جي تجزيي جي سطح تي.

ھاڻي اسان مٿين سطح تي تشخيصي پائپ لائن ذريعي وڃون ٿا، ۽ مجموعي منصوبي جي فن تعمير جي حوالي سان مائڪرو سروسز جي رابطي تي ڌيان ڏينداسين. 

جڏهن ڪشش جي تشخيص پائپ لائن تي ڪم ڪري رهيو آهي، اهو ڪم هيٺين حصن ۾ ورهايو ويو آهي:

1. تصويرن ۾ منهن جي چونڊ
2. هر شخص جي درجه بندي
3. نتيجو ڏيو

سڀ کان پهرين اڳ-تربيت جي قوتن پاران حل ڪيو ويو آهي MTCNN. ٻئين لاء، هڪ convolutional neural نيٽ ورڪ PyTorch تي تربيت ڪئي وئي، استعمال ڪندي ResNet34 - بيلنس مان "سي پي يو تي معيار / رفتار جو اندازو"

تشخيص پائپ لائن جو فنڪشنل ڊراگرام

منصوبي جي فن تعمير جي ضرورتن جو تجزيو

زندگيءَ جي چڪر ۾ ML آرڪيٽيڪچر تي ڪم جا منصوبا مرحلا ۽ ماڊل ڊيپلائيمينٽ جي آٽوميشن اڪثر وقت ۽ وسيلا استعمال ڪرڻ وارا هوندا آهن.

هڪ ايم ايل پروجيڪٽ جي زندگي چڪر

هي پروجيڪٽ ڪو به استثنا نه آهي - اهو فيصلو ڪيو ويو ته جائزي جي پائپ لائن کي هڪ آن لائن سروس ۾ لپائڻ، جنهن جي ضرورت آهي پاڻ کي فن تعمير ۾ وسارڻ. هيٺين بنيادي ضرورتن جي نشاندهي ڪئي وئي:

1. متحد لاگ اسٽوريج - سڀني خدمتن کي هڪ جڳهه تي لاگ لکڻ گهرجي، انهن کي تجزيو ڪرڻ لاء آسان هجڻ گهرجي
2. تشخيص سروس جي افقي اسڪيلنگ جو امڪان - سڀ کان وڌيڪ امڪاني طور تي رڪاوٽ
3. پروسيسر وسيلن جي ساڳئي مقدار کي هر تصوير جي تشخيص لاء مختص ڪيو وڃي ته جيئن وقت جي تقسيم ۾ ٻاهران کان بچڻ لاء.
4. فاسٽ (ٻيهر) ٻنهي مخصوص خدمتن جي مقرري ۽ مجموعي طور تي اسٽيڪ
5. صلاحيت، جيڪڏهن ضروري هجي ته، مختلف خدمتن ۾ عام شيون استعمال ڪرڻ لاء

تعمير

ضرورتن جي تجزيو ڪرڻ کان پوء، اهو واضح ٿيو ته مائڪرو سروس فن تعمير تقريبن مڪمل طور تي ٺهڪي اچي ٿي.

غير ضروري سر درد کان نجات حاصل ڪرڻ لاء، ٽيليگرام API کي فرنٽ اينڊ طور چونڊيو ويو.

پهرين، اچو ته مڪمل ٿيل فن تعمير جي ڍانچي جي شڪل کي ڏسو، پوء هر هڪ اجزاء جي وضاحت ڏانهن وڃو، ۽ ڪامياب تصويري پروسيسنگ جي عمل کي پڻ رسمي ڪريو.

ختم ٿيل فن تعمير جو ساختي خاڪو

اچو ته ڊاگرام جي هر هڪ اجزاء جي باري ۾ وڌيڪ تفصيل سان ڳالهايون، انهن کي تصوير جي تشخيص جي عمل ۾ اڪيلو ذميواري جي نشاندهي ڪندي.

Microservice "attrai-telegram-bot"

هي microservice ٽيليگرام API سان سڀني ڳالهين کي گڏ ڪري ٿو. هتي 2 مکيه منظرنامي آهن: هڪ ڪسٽم تصوير سان ڪم ڪرڻ ۽ تشخيص پائپ لائن جي نتيجي سان ڪم ڪرڻ. اچو ته عام اصطلاحن ۾ ٻنهي منظرنامي کي ڏسو.

جڏهن تصوير سان ڪسٽم پيغام وصول ڪيو وڃي:

1. فلٽريشن ڪيو ويندو آهي، جنهن ۾ هيٺيان چيڪ شامل آهن:
   • بهترين تصويري سائيز جي دستيابي
   • استعمال ڪندڙ تصويرن جو تعداد اڳ ۾ ئي قطار ۾
2. جڏهن شروعاتي فلٽرنگ کي گذري ٿو، تصوير ڊاکر حجم ۾ محفوظ ڪئي وئي آهي
3. هڪ ڪم "to_estimate" قطار ۾ پيدا ڪيو ويو آهي، جنهن ۾ شامل آهي، ٻين شين جي وچ ۾، اسان جي حجم ۾ واقع تصوير ڏانهن رستو
4. جيڪڏهن مٿيون قدم ڪاميابيءَ سان مڪمل ٿي ويا آهن، صارف کي لڳ ڀڳ تصويري پروسيسنگ وقت سان گڏ هڪ پيغام ملندو، جيڪو قطار ۾ ڪمن جي تعداد جي بنياد تي ڳڻيو ويندو. جيڪڏهن ڪا غلطي ٿئي ٿي، صارف کي واضح طور تي اطلاع ڏنو ويندو پيغام موڪلڻ سان معلومات سان ته ڇا غلط ٿي چڪو آهي.

انهي سان گڏ، هي مائڪرو سروس، هڪ سيلري ورڪر وانگر، "after_estimate" قطار ٻڌي ٿو، جيڪو انهن ڪمن لاء آهي جيڪي تشخيص پائپ لائن ذريعي گذري ويا آهن.

جڏهن "after_estimate" کان نئون ڪم وصول ڪيو وڃي:

1. جيڪڏهن تصوير ڪاميابي سان پروسيس ڪئي وئي آهي، اسان نتيجو موڪليندا آهيون صارف کي؛ جيڪڏهن نه، اسان هڪ غلطي بابت مطلع ڪنداسين.
2. تصوير کي هٽائڻ جيڪو تشخيص پائپ لائن جو نتيجو آهي

تشخيص مائڪرو سروس "اٽرائي-اسٽميٽر"

هي microservice هڪ سيلري ڪم ڪندڙ آهي ۽ تصوير جي تشخيص پائپ لائن سان لاڳاپيل هر شي کي شامل ڪري ٿو. هتي صرف هڪ ڪم ڪندڙ الگورتھم آهي - اچو ته ان جو تجزيو ڪريون.

جڏهن "to_estimate" کان نئون ڪم حاصل ڪيو وڃي:

1. اچو ته تصوير کي تشخيص پائپ لائن ذريعي هلون:
   1. تصوير کي ميموري ۾ لوڊ ڪندي
   2. اسان تصوير کي گهربل سائيز ۾ آڻينداسين
   3. سڀ منهن ڳولڻ (MTCNN)
   4. اسان سڀني چهرن جو جائزو وٺون ٿا (اسان آخري مرحلي ۾ مليل چهرن کي بيچ ۾ ويڙهيون ٿا ۽ ResNet34 جو اندازو لڳايون ٿا)
   5. آخري تصوير ڏيو
      1. اچو ته بائونڊنگ باڪس ڪڍون
      2. درجا بندي ڪرڻ
2. ڪسٽم (اصل) تصوير کي ختم ڪرڻ
3. تشخيص پائپ لائن مان ٻاھر محفوظ ڪرڻ
4. اسان ڪم کي "after_estimate" قطار ۾ رکون ٿا، جيڪو مٿي ڄاڻايل "attrai-telegram-bot" microservice پاران ٻڌو ويو آهي.

Graylog (+ mongoDB + Elasticsearch)

سريلي بلاگ مرڪزي لاگ مينيجمينٽ لاء هڪ حل آهي. هن منصوبي ۾، ان کي ان جي مقصد لاء استعمال ڪيو ويو.

انتخاب هن تي ڪري پيو، ۽ عام طور تي نه ايل stack، ان سان گڏ Python کان ڪم ڪرڻ جي سهولت جي ڪري. گريلوگ ۾ لاگ ان ڪرڻ لاءِ توهان کي صرف ڪرڻ جي ضرورت آهي شامل ڪريو GELFTCPHandler پيڪ مان ڳاڙهو اسان جي python microservice جي باقي روٽ لاگر هينڊلر تائين.

جيئن ته ڪو ماڻهو جيڪو اڳ ۾ صرف ELK اسٽيڪ سان ڪم ڪيو هو، مون کي گريلوگ سان ڪم ڪرڻ دوران مجموعي طور تي مثبت تجربو هو. صرف هڪ شيء جيڪا اداس ڪري رهي آهي گريلوگ ويب انٽرفيس مٿان ڪبانا جي خاصيتن ۾ برتري آهي.

رباب ايم

رباب ايم AMQP پروٽوڪول تي ٻڌل هڪ پيغام بروکر آهي.

هن منصوبي ۾ ان کي استعمال ڪيو ويو سڀ کان وڌيڪ مستحڪم ۽ وقت جي آزمائش سيلري لاء بروکر ۽ پائيدار موڊ ۾ ڪم ڪيو.

Redis

Redis هڪ NoSQL DBMS آهي جيڪو ڪم ڪري ٿو اهم-قدر واري ڊيٽا جي جوڙجڪ سان

ڪڏهن ڪڏهن عام شيون استعمال ڪرڻ جي ضرورت هوندي آهي جيڪي مختلف Python microservices ۾ ڪجهه ڊيٽا جي جوڙجڪ کي لاڳو ڪن ٿيون.

مثال طور، ريڊس فارم جو هڪ هيش ميپ اسٽور ڪري ٿو “telegram_user_id => قطار ۾ فعال ڪمن جو تعداد،“ جيڪو توهان کي اجازت ڏئي ٿو ته هڪ صارف جي درخواستن جي تعداد کي هڪ خاص قدر تائين محدود ڪري، ان ڪري، DoS حملن کي روڪيو.

اچو ته ڪامياب تصويري پروسيسنگ جي عمل کي رسمي ڪريون

1. صارف هڪ تصوير موڪلي ٿو ٽيليگرام بوٽ ڏانهن
2. "attrai-telegram-bot" ٽيليگرام API مان هڪ پيغام وصول ڪري ٿو ۽ ان کي پارس ڪري ٿو
3. تصوير سان گڏ ڪم کي شامل ڪيو ويو آهي asynchronous قطار “to_estimate”
4. صارف منصوبابندي ڪيل تشخيص وقت سان هڪ پيغام وصول ڪري ٿو
5. "attrai-estimator" "to_estimate" قطار مان هڪ ٽاسڪ وٺندو آهي، تخميني کي پائيپ لائين ذريعي هلائي ٿو ۽ ڪم کي "after_estimate" قطار ۾ پيدا ڪري ٿو
6. "attrai-telegram-bot" ٻڌي "after_estimate" قطار کي، نتيجو موڪلي ٿو صارف کي

DevOps

آخرڪار، فن تعمير جو جائزو وٺڻ کان پوء، توهان اڳتي وڌائي سگهو ٿا برابر دلچسپ حصو - DevOps

دکائيندڙ تلوار

 

دکائيندڙ تلوار  - هڪ ڪلسترنگ سسٽم، جنهن جي ڪارڪردگي Docker انجڻ جي اندر لاڳو ڪئي وئي آهي ۽ دٻي کان ٻاهر موجود آهي.

"swarm" استعمال ڪندي، اسان جي ڪلستر ۾ سڀني نوڊس کي 2 قسمن ۾ ورهائي سگھجي ٿو - ڪم ڪندڙ ۽ مينيجر. پهرين قسم جي مشينن تي، ڪنٽينرز جا گروپ (اسٽيڪ) لڳايا ويندا آهن، ٻئي قسم جون مشينون اسڪيلنگ، بيلنس ۽ ٻيون ٿڌيون خاصيتون. مينيجر پڻ ڊفالٽ طور ڪم ڪندڙ آهن.

هڪ ليڊر مئنيجر ۽ ٽن ڪارڪنن سان گڏ ڪلستر

گھٽ ۾ گھٽ ممڪن ڪلستر سائيز 1 نوڊ آھي؛ ھڪڙي مشين ھڪڙي وقت ھڪڙي ليڊر مئنيجر ۽ ھڪڙي ڪم ڪندڙ طور ڪم ڪندي. منصوبي جي ماپ جي بنياد تي ۽ غلطي رواداري جي گھٽ ۾ گھٽ ضرورتن جي بنياد تي، ھن طريقي کي استعمال ڪرڻ جو فيصلو ڪيو ويو.

اڳتي ڏسندي، مان چوندس ته پهرين پيداوار جي ترسيل کان وٺي، جيڪا جون جي وچ ۾ هئي، هن ڪلسٽر تنظيم سان لاڳاپيل ڪو مسئلو ناهي (پر ان جو مطلب اهو ناهي ته اهڙي تنظيم ڪنهن به طريقي سان قابل قبول آهي وچولي وڏي ۾. پروجيڪٽ، جيڪي غلطي رواداري گهرجن جي تابع آهن).

ڊڪر اسٽيڪ

سوارم موڊ ۾، هو اسٽيڪ کي ترتيب ڏيڻ جو ذميوار آهي (ڊاڪر سروسز جو سيٽ) ڊڪر اسٽيڪ

اهو سپورٽ ڪري ٿو docker-compose configs، توهان کي اضافي طور تي استعمال ڪرڻ جي اجازت ڏئي ٿو ترتيب ڏيڻ جا اختيار.  

مثال طور، انهن پيرا ميٽرز کي استعمال ڪندي، هر هڪ تشخيصي مائڪسرو سروس مثالن لاءِ وسيلا محدود هئا (اسان N مثالن لاءِ N cores مختص ڪريون ٿا، خود microservice ۾ اسان PyTorch پاران استعمال ڪيل ڪور جي تعداد کي محدود ڪريون ٿا)

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

اهو نوٽ ڪرڻ ضروري آهي ته Redis، RabbitMQ ۽ Graylog رياستي خدمتون آهن ۽ انهن کي آسانيءَ سان نه ٿو ماپي سگهجي ”اٽرائي-اسٽميٽر“

سوال پيش ڪندي - ڇو نه ڪبرنيٽس؟

اهو لڳي ٿو ته ڪبرنيٽس کي ننڍي ۽ وچولي انداز جي منصوبن ۾ استعمال ڪرڻ هڪ مٿانهون آهي؛ تمام ضروري ڪارڪردگي Docker Swarm مان حاصل ڪري سگهجي ٿي، جيڪا ڪافي صارف-دوست آهي ڪنٽينر آرڪيسٽرٽر لاءِ ۽ ان ۾ داخلا لاءِ گهٽ رڪاوٽ پڻ آهي.

انفراسٹرڪچر

اهو سڀ ڪجهه هيٺ ڏنل خاصيتن سان VDS تي لڳايو ويو آهي:

• سي پي يو: 4 ڪور Intel® Xeon® Gold 5120 CPU @ 2.20GHz
• رام: 8 GB
• ايس ايس ڊي: 160 GB

مقامي لوڊ جاچ کان پوء، اهو لڳي ٿو ته صارفين جي هڪ سنگين آمد سان، هي مشين ڪافي هوندي.

پر، فوري طور تي تعیناتي کان پوء، مون CIS ۾ سڀ کان وڌيڪ مشهور تصويري بورڊن مان هڪ لنڪ پوسٽ ڪيو (يپ، اهو ساڳيو)، جنهن کان پوء ماڻهن ۾ دلچسپي ورتي ۽ چند ڪلاڪن ۾ خدمت ڪاميابيء سان هزارين تصويرون تي عمل ڪيو. ساڳئي وقت، چوٽي جي لمحن تي، سي پي يو ۽ رام وسيلن کي اڌ استعمال نه ڪيو ويو.

ڪجھ وڌيڪ گرافڪس

منفرد استعمال ڪندڙن جو تعداد ۽ تعينات جي درخواستن جو تعين ڪرڻ کان وٺي، ڏينھن تي منحصر آھي

پائپ لائن جو اندازو لڳائڻ وقت جي تقسيم

پهچڻ

اختصار ڪرڻ لاءِ، مان اهو چئي سگهان ٿو ته ڪنٽينرز جي آرڪيسٽريشن جي فن تعمير ۽ انداز پاڻ کي مڪمل طور تي صحيح ثابت ڪيو - جيتوڻيڪ چوٽي جي لمحن تي به پروسيسنگ جي وقت ۾ ڪو ڦوٽو يا ڇڪڻ نه هو. 

مان سمجهان ٿو ته ننڍڙا ۽ وچولي قسم جا منصوبا جيڪي سي پي يو تي نيورل نيٽ ورڪ جو حقيقي وقت استعمال ڪن ٿا انهن جي عمل ۾ ڪاميابيءَ سان هن مضمون ۾ بيان ڪيل طريقا اختيار ڪري سگهن ٿا.

مان شامل ڪندس ته شروعات ۾ آرٽيڪل ڊگهو هو، پر ڊگهي پڙهڻ جي پوسٽ نه ڪرڻ لاء، مون هن مضمون ۾ ڪجهه نقطا ختم ڪرڻ جو فيصلو ڪيو - اسان انهن کي مستقبل جي اشاعتن ۾ واپس ڪنداسين.

توهان ٽيليگرام تي بوٽ کي پڪڙي سگهو ٿا - @AttraiBot، اهو ڪم ڪندو گهٽ ۾ گهٽ 2020 جي خزاں جي آخر تائين. مان توهان کي ياد ڏيان ٿو ته ڪو به صارف ڊيٽا محفوظ نه آهي - نه ئي اصل تصويرون، ۽ نه ئي تشخيص پائپ لائن جا نتيجا - پروسيسنگ کان پوء هر شيء ختم ٿي وئي آهي.

جو ذريعو: www.habr.com