ProHoster > Блог > Administrasi > Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

entri

Hello!

Ing artikel iki aku bakal nuduhake pengalaman mbangun arsitektur microservice kanggo proyek nggunakake jaringan syaraf.

Ayo ngobrol babagan syarat arsitektur, deleng macem-macem diagram struktural, nganalisa saben komponen arsitektur rampung, lan uga ngevaluasi metrik teknis solusi kasebut.

Seneng maca!

Sawetara tembung babagan masalah lan solusi

Ide utama yaiku kanggo ngevaluasi daya tarik wong ing skala sepuluh titik adhedhasar foto.

Ing artikel iki kita bakal pindhah saka njlèntrèhaké loro jaringan syaraf digunakake lan proses preparation lan latihan data. Nanging, ing salah sawijining publikasi ing ngisor iki, kita mesthi bakal bali maneh kanggo nganalisa pipeline penilaian ing tingkat sing jero.

Saiki kita bakal ngliwati pipa evaluasi ing tingkat paling dhuwur, lan bakal fokus ing interaksi layanan mikro ing konteks arsitektur proyek sakabèhé. 

Nalika nggarap pipa penilaian daya tarik, tugas kasebut dipérang dadi komponen ing ngisor iki:

  1. Milih pasuryan ing foto
  2. Rating saben wong
  3. Render asil

Pisanan ditanggulangi dening pasukan sing wis dilatih MTCNN. Kanggo sing kapindho, jaringan saraf convolutional dilatih ing PyTorch, nggunakake ResNet34 - saka imbangan "kualitas / kacepetan inferensi ing CPU"

Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

Diagram fungsional pipa evaluasi

Analisis syarat arsitektur proyek

Ing siklus urip ML tahapan proyek babagan arsitektur lan otomasi panyebaran model asring ana ing antarane sing paling akeh wektu lan sumber daya.

Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

Siklus urip proyek ML

Proyèk iki ora ana sing istiméwa - kaputusan digawe kanggo mbungkus pipa penilaian dadi layanan online, sing kudu nyemplungake awake dhewe ing arsitektur. Persyaratan dhasar ing ngisor iki diidentifikasi:

  1. Panyimpenan log terpadu - kabeh layanan kudu nulis log ing sak panggonan, mesthine trep kanggo nganalisa
  2. Kemungkinan skala horisontal layanan taksiran - minangka Bottleneck sing paling mungkin
  3. Jumlah sumber daya prosesor sing padha kudu dialokasikan kanggo ngevaluasi saben gambar supaya ora ana outlier ing distribusi wektu kanggo inferensi.
  4. Cepet (re) panyebaran loro layanan tartamtu lan tumpukan minangka kabèh
  5. Kemampuan, yen perlu, nggunakake obyek umum ing macem-macem layanan

arsitektur

Sawise nganalisa syarat kasebut, dadi jelas manawa arsitektur microservice cocog banget.

Kanggo nyingkirake sirah sing ora perlu, API Telegram dipilih minangka frontend.

Pisanan, ayo ndeleng diagram struktural arsitektur sing wis rampung, banjur pindhah menyang deskripsi saben komponen, lan uga ngresmikake proses pangolahan gambar sing sukses.

Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

Diagram struktural saka arsitektur rampung

Ayo dadi pirembagan ing liyane rinci babagan saben komponen saka diagram, denoting wong Tanggung jawab Single ing proses evaluasi gambar.

Layanan mikro "attrai-telegram-bot"

Layanan mikro iki ngemot kabeh interaksi karo API Telegram. Ana 2 skenario utama: nggarap gambar khusus lan nggarap asil pipo penilaian. Ayo katon ing loro skenario ing istilah umum.

Nalika nampa pesen khusus kanthi gambar:

  1. Filtrasi ditindakake, kalebu pemeriksaan ing ngisor iki:
    • Kasedhiyan ukuran gambar sing optimal
    • Jumlah gambar pangguna sing wis ana ing antrian
  2. Nalika ngliwati panyaring awal, gambar kasebut disimpen ing volume docker
  3. Tugas digawe ing antrian "kanggo_estimasi", sing kalebu, ing antarane, dalan menyang gambar sing ana ing volume kita.
  4. Yen langkah-langkah ing ndhuwur wis rampung kanthi sukses, pangguna bakal nampa pesen kanthi kira-kira wektu pangolahan gambar, sing diitung adhedhasar jumlah tugas ing antrian. Yen ana kesalahan, pangguna bakal dilaporake kanthi jelas kanthi ngirim pesen kanthi informasi babagan apa sing salah.

Uga, layanan mikro iki, kaya buruh celery, ngrungokake antrian "after_estimate", sing dimaksudake kanggo tugas sing wis liwat pipa evaluasi.

Nalika nampa tugas anyar saka "after_estimate":

  1. Yen gambar diproses kanthi sukses, kita ngirim asil menyang pangguna; yen ora, kita bakal menehi kabar babagan kesalahan.
  2. Mbusak gambar sing minangka asil saka pipa evaluasi

Evaluasi microservice "attrai-estimator"

Layanan mikro iki minangka pekerja celery lan ngrampungake kabeh sing ana gandhengane karo pipa evaluasi gambar. Mung ana siji algoritma sing bisa digunakake ing kene - ayo analisa.

Nalika nampa tugas anyar saka "to_estimate":

  1. Ayo mbukak gambar liwat pipa evaluasi:
    1. Ngunggah gambar menyang memori
    2. Kita nggawa gambar menyang ukuran sing dibutuhake
    3. Nggoleki kabeh pasuryan (MTCNN)
    4. Kita ngevaluasi kabeh pasuryan (kita mbungkus pasuryan sing ditemokake ing langkah pungkasan dadi batch lan inferensi ResNet34)
    5. Nggawe gambar pungkasan
      1. Ayo nggambar kothak wates
      2. Nggambar rating
  2. Mbusak gambar khusus (asli).
  3. Nyimpen output saka pipa evaluasi
  4. Kita sijine tugas ing "after_estimate" antrian, kang dirungokake dening microservice "attrai-telegram-bot" rembugan ndhuwur.

Graylog (+ mongoDB + Elasticsearch)

greylog minangka solusi kanggo manajemen log terpusat. Ing proyek iki, digunakake kanggo tujuan sing dimaksud.

Pilihan tiba ing dheweke, lan ora ing sing biasa ELK tumpukan, amarga penak nggarap saka Python. Kabeh sing perlu dilakoni kanggo mlebu menyang Graylog yaiku nambah GELTCPHandler saka paket kasebut werna abu-abu menyang liyane saka panangan root logger saka microservice python kita.

Minangka wong sing sadurunge mung nggarap tumpukan ELK, aku duwe pengalaman positif sakabèhé nalika nggarap Graylog. Siji-sijine sing nyenengake yaiku keunggulan fitur Kibana ing antarmuka web Graylog.

KelinciMQ

KelinciMQ iku makelar pesen adhedhasar protokol AMQP.

Ing project iki digunakake minangka paling stabil lan wektu-dites broker kanggo Celery lan makarya ing mode awet.

Redis

Redis yaiku DBMS NoSQL sing bisa digunakake karo struktur data nilai kunci

Kadhangkala ana perlu kanggo nggunakake obyek umum sing ngleksanakake struktur data tartamtu ing microservices Python beda.

Contone, Redis nyimpen peta hash saka wangun "telegram_user_id => jumlah tugas aktif ing antrian," sing ngidini sampeyan mbatesi jumlah panjalukan saka siji pangguna menyang nilai tartamtu lan, kanthi mangkono, nyegah serangan DoS.

Ayo dadi resmi proses pangolahan gambar sing sukses

  1. Pangguna ngirim gambar menyang bot Telegram
  2. "attrai-telegram-bot" nampa pesen saka Telegram API lan ngurai
  3. Tugas karo gambar ditambahake menyang antrian asinkron "to_estimate"
  4. Pangguna nampa pesen kanthi wektu pambiji sing direncanakake
  5. "attrai-estimator" njupuk tugas saka antrian "to_estimate", nglakokake taksiran liwat pipa lan ngasilake tugas menyang antrian "after_estimate".
  6. "attrai-telegram-bot" ngrungokake antrian "after_estimate", ngirim asil menyang pangguna

DevOps

Pungkasan, sawise mriksa arsitektur, sampeyan bisa pindhah menyang bagean sing padha menarik - DevOps

Grombolan Docker

 

Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

Grombolan Docker  - sistem clustering, fungsi kang dipun ginakaken nang Docker Engine lan kasedhiya metu saka kothak.

Nggunakake "grombolan", kabeh kelenjar ing kluster kita bisa dipérang dadi 2 jinis - buruh lan manajer. Ing mesin jinis pisanan, klompok wadhah (tumpukan) disebarake, mesin saka jinis liya tanggung jawab kanggo skala, imbangan lan fitur kelangan liyane. Manajer uga minangka buruh kanthi standar.

Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

Kluster karo siji manajer pimpinan lan telung buruh

Ukuran kluster minimal sing bisa ditindakake yaiku 1 simpul; mesin siji bakal tumindak minangka manajer pimpinan lan buruh. Adhedhasar ukuran proyek lan syarat minimal kanggo toleransi kesalahan, diputusake nggunakake pendekatan iki.

Ing ngarep, aku bakal ujar manawa wiwit pangiriman produksi pisanan, yaiku ing pertengahan Juni, ora ana masalah sing ana gandhengane karo organisasi kluster iki (nanging iki ora ateges manawa organisasi kasebut bisa ditampa kanthi cara apa wae. proyek, sing tundhuk karo syarat toleransi fault).

Tumpukan Docker

Ing mode swarm, dheweke tanggung jawab kanggo nyebarake tumpukan (set layanan docker) tumpukan docker

Ndhukung konfigurasi docker-compose, ngidini sampeyan nggunakake opsi panyebaran tambahan.  

Contone, nggunakake paramèter kasebut, sumber daya kanggo saben instance microservice evaluasi diwatesi (kita nyedhiyakake N inti kanggo N instans, ing microservice dhewe mbatesi jumlah inti sing digunakake dening PyTorch dadi siji)

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

Wigati dicathet yen Redis, RabbitMQ lan Graylog minangka layanan stateful lan ora bisa diukur kanthi gampang kaya "attrai-estimator"

Foreshadowing pitakonan - kok ora Kubernetes?

Katon yen nggunakake Kubernetes ing proyek cilik lan medium minangka overhead; kabeh fungsi sing dibutuhake bisa dipikolehi saka Docker Swarm, sing cukup pangguna-loropaken kanggo orkestra kontainer lan uga duwe alangan sing sithik kanggo mlebu.

Infrastruktur

Kabeh iki disebarake ing VDS kanthi karakteristik ing ngisor iki:

  • CPU: 4 inti Intel® Xeon® Gold 5120 CPU @ 2.20GHz
  • RAM: 8 GB
  • SSD: 160GB

Sawise tes beban lokal, katon manawa kanthi akeh pangguna pangguna, mesin iki bakal cukup.

Nanging, sanalika sawise penyebaran, aku ngirim link menyang salah sawijining papan gambar sing paling populer ing CIS (yup, sing padha), sawise wong dadi kasengsem lan ing sawetara jam layanan kasebut kasil ngolah puluhan ewu gambar. Ing wektu sing padha, ing wektu puncak, sumber daya CPU lan RAM ora setengah digunakake.

Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf
Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

Sawetara grafis liyane

Jumlah pangguna unik lan panjaluk evaluasi wiwit penyebaran, gumantung ing dina

Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

Distribusi wektu inferensi pipa evaluasi

Gambaran umum arsitektur layanan kanggo penilaian tampilan adhedhasar jaringan saraf

temonan

Kanggo ngringkes, aku bisa ujar manawa arsitektur lan pendekatan kanggo orkestrasi kontaner mbenerake awake dhewe - sanajan ing wektu puncak ora ana tetes utawa dips ing wektu pangolahan. 

Aku mikir yen proyek cilik lan medium sing nggunakake inferensi nyata-wektu saka jaringan syaraf ing CPU ing proses bisa kasil nganggo laku diterangake ing artikel iki.

Aku bakal nambah manawa wiwitane artikel kasebut luwih dawa, nanging supaya ora ngirim maca sing dawa, aku mutusake ngilangi sawetara poin ing artikel iki - kita bakal bali menyang publikasi sabanjure.

Sampeyan bisa nyopot bot ing Telegram - @AttraiBot, bakal bisa paling ora nganti pungkasan musim gugur 2020. Ayo kula ngelingake yen ora ana data pangguna sing disimpen - ora gambar asli, utawa asil pipa evaluasi - kabeh dibongkar sawise diproses.

Source: www.habr.com

Add a comment