სერვისის არქიტექტურის ზოგადი მიმოხილვა ნერვულ ქსელებზე დაფუძნებული გარეგნობის შეფასებისთვის

Entry

Hi!

ამ სტატიაში მე გაგიზიარებთ ჩემს გამოცდილებას მიკროსერვისის არქიტექტურის აგების შესახებ პროექტისთვის ნერვული ქსელების გამოყენებით.

მოდით ვისაუბროთ არქიტექტურის მოთხოვნებზე, გადავხედოთ სხვადასხვა სტრუქტურულ დიაგრამებს, გავაანალიზოთ მზა არქიტექტურის თითოეული კომპონენტი და ასევე შევაფასოთ გადაწყვეტის ტექნიკური მეტრიკა.

ისიამოვნეთ კითხვა!

რამდენიმე სიტყვა პრობლემისა და მისი გადაჭრის შესახებ

მთავარი იდეა არის ადამიანის მიმზიდველობის შეფასება ათბალიანი სკალით ფოტოზე დაყრდნობით.

ამ სტატიაში ჩვენ გადავალთ როგორც გამოყენებული ნერვული ქსელების, ასევე მონაცემთა მომზადებისა და ტრენინგის პროცესის აღწერისგან. თუმცა, ერთ-ერთ შემდეგ პუბლიკაციაში ჩვენ აუცილებლად დავუბრუნდებით შეფასების მილსადენის სიღრმისეულ დონეზე ანალიზს.

ახლა ჩვენ გავივლით შეფასების მილსადენს უმაღლეს დონეზე და ყურადღებას გავამახვილებთ მიკროსერვისების ურთიერთქმედებაზე მთლიანი პროექტის არქიტექტურის კონტექსტში. 

მიმზიდველობის შეფასების მილსადენზე მუშაობისას, ამოცანა დაიშალა შემდეგ კომპონენტებად:

1. სახეების შერჩევა ფოტოებში
2. თითოეული ადამიანის რეიტინგი
3. გამოიტანე შედეგი

პირველი მოგვარებულია წინასწარ მომზადებული ძალებით MTCNN. მეორესთვის, კონვოლუციური ნერვული ქსელი ჩატარდა PyTorch-ზე, გამოყენებით ResNet34 – ბალანსიდან „პროცესორზე დასკვნის ხარისხი/სიჩქარე“

შეფასების მილსადენის ფუნქციური დიაგრამა

პროექტის არქიტექტურის მოთხოვნების ანალიზი

სასიცოცხლო ციკლში ML პროექტის ეტაპები არქიტექტურაზე და მოდელის განლაგების ავტომატიზაციაზე, ხშირად ყველაზე შრომატევად და რესურსებს შორისაა.

ML პროექტის სასიცოცხლო ციკლი

ეს პროექტი არ არის გამონაკლისი - გადაწყდა შეფასების მილსადენის გადატანა ონლაინ სერვისში, რაც მოითხოვდა არქიტექტურაში ჩაძირვას. გამოვლინდა შემდეგი ძირითადი მოთხოვნები:

1. ჟურნალის ერთიანი შენახვა - ყველა სერვისმა უნდა დაწეროს ჟურნალი ერთ ადგილას, უნდა იყოს მოსახერხებელი ანალიზისთვის
2. შეფასების სერვისის ჰორიზონტალური სკალირების შესაძლებლობა - როგორც ყველაზე სავარაუდო Bottleneck
3. პროცესორის რესურსების იგივე რაოდენობა უნდა გამოიყოს თითოეული სურათის შესაფასებლად, რათა თავიდან იქნას აცილებული დასკვნისთვის დროის განაწილება.
4. როგორც კონკრეტული სერვისების, ისე მთლიანად სტეკის სწრაფი (ხელახალი) განლაგება
5. საჭიროების შემთხვევაში, სხვადასხვა სერვისებში საერთო ობიექტების გამოყენების შესაძლებლობა

არქიტექტურა

მოთხოვნების გაანალიზების შემდეგ აშკარა გახდა, რომ მიკროსერვისის არქიტექტურა თითქმის იდეალურად ჯდება.

ზედმეტი თავის ტკივილისგან თავის დასაღწევად, ტელეგრამის API აირჩიეს ფრონტენტად.

ჯერ გადავხედოთ დასრულებული არქიტექტურის სტრუქტურულ დიაგრამას, შემდეგ გადავიდეთ თითოეული კომპონენტის აღწერაზე და ასევე გავაფორმოთ გამოსახულების წარმატებული დამუშავების პროცესი.

დასრულებული არქიტექტურის სტრუქტურული დიაგრამა

მოდით ვისაუბროთ უფრო დეტალურად დიაგრამის თითოეულ კომპონენტზე, აღვნიშნავთ მათ ერთჯერად პასუხისმგებლობას გამოსახულების შეფასების პროცესში.

მიკროსერვისი "attrai-telegram-bot"

ეს მიკროსერვისი აერთიანებს ყველა ურთიერთქმედებას Telegram 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-ის დამატება პაკეტიდან ნაცრისფერი ჩვენი პითონის მიკროსერვისის root logger-ის დანარჩენ ოპერატორებს.

როგორც ვინმე, ვინც ადრე მხოლოდ ELK სტეკთან მუშაობდა, მე მქონდა საერთო პოზიტიური გამოცდილება Graylog-თან მუშაობისას. ერთადერთი, რაც დამთრგუნველია, არის კიბანას ფუნქციების უპირატესობა Graylog ვებ ინტერფეისზე.

კურდღელი MQ

კურდღელი MQ არის შეტყობინებების ბროკერი, რომელიც დაფუძნებულია AMQP პროტოკოლზე.

ამ პროექტში ის გამოიყენებოდა როგორც ყველაზე სტაბილური და დროში გამოცდილი ბროკერი ნიახურისთვის და მუშაობდა გამძლე რეჟიმში.

Redis

Redis არის NoSQL DBMS, რომელიც მუშაობს გასაღები-მნიშვნელობის მონაცემთა სტრუქტურებთან

ზოგჯერ საჭიროა საერთო ობიექტების გამოყენება, რომლებიც ახორციელებენ მონაცემთა გარკვეულ სტრუქტურებს Python-ის სხვადასხვა მიკროსერვისებში.

მაგალითად, 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-ის შიგნით და ხელმისაწვდომია ყუთში.

"Swarm"-ის გამოყენებით, ჩვენს კლასტერში ყველა კვანძი შეიძლება დაიყოს 2 ტიპად - მუშაკი და მენეჯერი. პირველი ტიპის მანქანებზე განლაგებულია კონტეინერების ჯგუფები (დაწყობები), მეორე ტიპის მანქანები პასუხისმგებელნი არიან სკალირებაზე, დაბალანსებაზე და სხვა მაგარი თვისებები. მენეჯერები ასევე სტანდარტულად მუშები არიან.

კლასტერი ერთ ლიდერ მენეჯერთან და სამ მუშაკთან ერთად

კლასტერის მინიმალური შესაძლო ზომა არის 1 კვანძი; ერთი მანქანა ერთდროულად იმოქმედებს როგორც ლიდერი მენეჯერი და მუშაკი. პროექტის ზომიდან და ხარვეზების ტოლერანტობის მინიმალური მოთხოვნებიდან გამომდინარე, გადაწყდა ამ მიდგომის გამოყენება.

წინ რომ ვუყურებ, ვიტყვი, რომ პირველი წარმოების მიწოდების შემდეგ, რომელიც ივნისის შუა რიცხვებში იყო, ამ კლასტერულ ორგანიზაციასთან დაკავშირებული არანაირი პრობლემა არ ყოფილა (მაგრამ ეს არ ნიშნავს, რომ ასეთი ორგანიზაცია არანაირად მისაღებია ნებისმიერი საშუალო და დიდი მასშტაბით. პროექტები, რომლებიც ექვემდებარება შეცდომების შემწყნარებლობის მოთხოვნებს).

დოკერ სტეკი

Swarm რეჟიმში, ის პასუხისმგებელია სტეკების განლაგებაზე (დოკერის სერვისების ნაკრები) დოკერის დასტა

იგი მხარს უჭერს 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-ის გამოყენება მცირე და საშუალო ზომის პროექტებში ზედმეტია; ყველა საჭირო ფუნქციის მიღება შესაძლებელია Docker Swarm-ისგან, რომელიც საკმაოდ მოსახერხებელია კონტეინერის ორკესტრისთვის და ასევე აქვს დაბალი ბარიერი შესვლისთვის.

ინფრასტრუქტურის

ეს ყველაფერი განლაგდა VDS-ზე შემდეგი მახასიათებლებით:

• პროცესორი: 4 ბირთვიანი Intel® Xeon® Gold 5120 CPU @ 2.20 GHz
• RAM: 8 GB
• SSD: 160 გბ

ადგილობრივი დატვირთვის ტესტირების შემდეგ, ჩანდა, რომ მომხმარებელთა სერიოზული შემოდინებით, ეს მანქანა საკმარისი იქნებოდა.

მაგრამ, განლაგებისთანავე, მე გამოვაქვეყნე ბმული დსთ-ში ერთ-ერთ ყველაზე პოპულარულ გამოსახულებაზე (დიახ, იგივე), რის შემდეგაც ხალხი დაინტერესდა და რამდენიმე საათში სერვისმა წარმატებით დაამუშავა ათიათასობით სურათი. ამავდროულად, პიკის მომენტებში, CPU და RAM რესურსები ნახევარზეც კი არ იყო გამოყენებული.

კიდევ რამდენიმე გრაფიკა

უნიკალური მომხმარებლების რაოდენობა და შეფასების მოთხოვნები განლაგების შემდეგ, დღის მიხედვით

მილსადენის შეფასების დასკვნის დროის განაწილება

დასკვნები

რომ შევაჯამოთ, შემიძლია ვთქვა, რომ კონტეინერების ორკესტრირების არქიტექტურამ და მიდგომამ სრულად გაამართლა საკუთარი თავი - პიკის მომენტებშიც კი არ ყოფილა დამუშავების დროში ვარდნა ან ჩავარდნა. 

მე ვფიქრობ, რომ მცირე და საშუალო ზომის პროექტებს, რომლებიც იყენებენ რეალურ დროში ნერვული ქსელების დასკვნას CPU-ზე, შეუძლიათ წარმატებით მიიღონ ამ სტატიაში აღწერილი პრაქტიკა.

დავამატებ, რომ თავდაპირველად სტატია უფრო გრძელი იყო, მაგრამ იმისათვის, რომ არ გამომექვეყნებინა დიდი ხნის განმავლობაში, გადავწყვიტე ამ სტატიაში გამომეტოვებინა რამდენიმე პუნქტი - მათ მომავალ პუბლიკაციებში დავუბრუნდებით.

შეგიძლიათ ბოტი დადოთ Telegram-ზე - @AttraiBot, ის იმუშავებს მინიმუმ 2020 წლის შემოდგომის ბოლომდე. შეგახსენებთ, რომ მომხმარებლის მონაცემები არ ინახება - არც ორიგინალური სურათები და არც შეფასების მილსადენის შედეგები - დამუშავების შემდეგ ყველაფერი იშლება.

წყარო: www.habr.com