ProHoster > blog > administrasi > Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Masuk

Hi!

Pada artikel ini saya akan berbagi pengalaman saya membangun arsitektur layanan mikro untuk sebuah proyek menggunakan jaringan saraf.

Mari kita bicara tentang persyaratan arsitektur, melihat berbagai diagram struktural, menganalisis setiap komponen arsitektur yang telah selesai, dan juga mengevaluasi metrik teknis dari solusi.

Selamat membaca!

Beberapa kata tentang masalah dan solusinya

Ide utamanya adalah menilai daya tarik seseorang pada skala sepuluh poin berdasarkan foto.

Dalam artikel ini kita akan beralih dari menjelaskan jaringan saraf yang digunakan serta proses persiapan dan pelatihan data. Namun, dalam salah satu publikasi berikut ini, kami pasti akan kembali menganalisis alur penilaian secara mendalam.

Sekarang kita akan melalui jalur evaluasi di tingkat atas, dan akan fokus pada interaksi layanan mikro dalam konteks arsitektur proyek secara keseluruhan. 

Saat mengerjakan alur penilaian daya tarik, tugas tersebut dipecah menjadi komponen-komponen berikut:

  1. Memilih wajah di foto
  2. Peringkat setiap orang
  3. Render hasilnya

Yang pertama diselesaikan oleh kekuatan yang sudah terlatih MTCNN. Untuk yang kedua, jaringan saraf konvolusional dilatih di PyTorch, menggunakan ResNet34 – dari keseimbangan “kualitas / kecepatan inferensi pada CPU”

Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Diagram fungsional dari jalur evaluasi

Analisis persyaratan arsitektur proyek

Dalam siklus hidup ML tahapan proyek pengerjaan arsitektur dan otomatisasi penerapan model sering kali merupakan tahap yang paling memakan waktu dan sumber daya.

Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Siklus hidup proyek ML

Proyek ini tidak terkecuali - keputusan telah dibuat untuk menggabungkan jalur penilaian ke dalam layanan online, yang mengharuskan kita mendalami arsitekturnya. Persyaratan dasar berikut diidentifikasi:

  1. Penyimpanan log terpadu – semua layanan harus menulis log di satu tempat, sehingga mudah untuk dianalisis
  2. Kemungkinan penskalaan horizontal layanan penilaian - sebagai Hambatan yang paling mungkin terjadi
  3. Jumlah sumber daya prosesor yang sama harus dialokasikan untuk mengevaluasi setiap gambar guna menghindari outlier dalam distribusi waktu untuk inferensi
  4. Penerapan (ulang) cepat layanan tertentu dan tumpukan secara keseluruhan
  5. Kemampuan, jika perlu, untuk menggunakan objek umum di berbagai layanan

Arsitektur

Setelah menganalisis persyaratan, menjadi jelas bahwa arsitektur layanan mikro hampir sempurna.

Untuk menghilangkan sakit kepala yang tidak perlu, API Telegram dipilih sebagai frontend.

Pertama, mari kita lihat diagram struktur arsitektur yang telah selesai, kemudian beralih ke deskripsi masing-masing komponen, dan juga memformalkan proses pemrosesan gambar yang berhasil.

Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Diagram struktural arsitektur yang sudah jadi

Mari kita bicara lebih detail tentang masing-masing komponen diagram, yang menunjukkannya Tanggung Jawab Tunggal dalam proses evaluasi gambar.

Layanan mikro “attrai-telegram-bot”

Layanan mikro ini merangkum semua interaksi dengan API Telegram. Ada 2 skenario utama: bekerja dengan gambar kustom dan bekerja dengan hasil alur penilaian. Mari kita lihat kedua skenario tersebut secara umum.

Saat menerima pesan khusus dengan gambar:

  1. Filtrasi yang dilakukan terdiri dari pemeriksaan sebagai berikut:
    • Ketersediaan ukuran gambar yang optimal
    • Jumlah gambar pengguna yang sudah ada dalam antrean
  2. Saat melewati pemfilteran awal, gambar disimpan dalam volume buruh pelabuhan
  3. Sebuah tugas dihasilkan dalam antrian “to_estimate”, yang mencakup, antara lain, jalur ke gambar yang terletak di volume kami
  4. Jika langkah di atas berhasil diselesaikan, pengguna akan menerima pesan dengan perkiraan waktu pemrosesan gambar, yang dihitung berdasarkan jumlah tugas dalam antrian. Jika terjadi kesalahan, pengguna akan diberitahu secara eksplisit dengan mengirimkan pesan berisi informasi tentang apa yang mungkin salah.

Selain itu, layanan mikro ini, seperti pekerja seledri, mendengarkan antrean “after_estimate”, yang ditujukan untuk tugas-tugas yang telah melewati jalur evaluasi.

Saat menerima tugas baru dari “after_estimate”:

  1. Jika gambar berhasil diproses, kami mengirimkan hasilnya kepada pengguna; jika tidak, kami memberitahukan adanya kesalahan.
  2. Menghapus gambar yang merupakan hasil dari pipa evaluasi

Layanan mikro evaluasi “attrai-estimator”

Layanan mikro ini adalah pekerja seledri dan merangkum segala sesuatu yang terkait dengan pipeline evaluasi gambar. Hanya ada satu algoritme yang berfungsi di sini – mari kita analisis.

Saat menerima tugas baru dari “to_estimate”:

  1. Mari kita jalankan gambar melalui jalur evaluasi:
    1. Memuat gambar ke dalam memori
    2. Kami membawa gambar ke ukuran yang diperlukan
    3. Menemukan semua wajah (MTCNN)
    4. Kami mengevaluasi semua wajah (kami menggabungkan wajah yang ditemukan pada langkah terakhir ke dalam batch dan menyimpulkan ResNet34)
    5. Render gambar akhir
      1. Mari kita menggambar kotak pembatasnya
      2. Menggambar peringkatnya
  2. Menghapus gambar khusus (asli).
  3. Menyimpan keluaran dari jalur evaluasi
  4. Kami menempatkan tugas dalam antrian “after_estimate”, yang didengarkan oleh layanan mikro “attrai-telegram-bot” yang dibahas di atas.

Graylog (+ mongoDB + Elasticsearch)

abu-abu adalah solusi untuk manajemen log terpusat. Dalam proyek ini, itu digunakan untuk tujuan yang dimaksudkan.

Pilihan ada pada dirinya, bukan pada pilihan biasanya RUSA BESAR tumpukan, karena kenyamanan bekerja dengannya dari Python. Yang perlu Anda lakukan untuk masuk ke Graylog adalah menambahkan GELFTTCPHandler dari paket abu-abu ke penangan root logger lainnya dari layanan mikro python kami.

Sebagai seseorang yang sebelumnya hanya bekerja dengan tumpukan ELK, secara keseluruhan saya mendapatkan pengalaman positif saat bekerja dengan Graylog. Satu-satunya hal yang menyedihkan adalah keunggulan fitur Kibana dibandingkan antarmuka web Graylog.

RabbitMQ

RabbitMQ adalah perantara pesan berdasarkan protokol AMQP.

Dalam proyek ini digunakan sebagai yang paling stabil dan teruji waktu broker untuk Seledri dan bekerja dalam mode tahan lama.

Redis

Redis adalah DBMS NoSQL yang bekerja dengan struktur data nilai kunci

Terkadang ada kebutuhan untuk menggunakan objek umum yang mengimplementasikan struktur data tertentu di layanan mikro Python yang berbeda.

Misalnya, Redis menyimpan peta hash dalam bentuk “telegram_user_id => jumlah tugas aktif dalam antrean”, yang memungkinkan Anda membatasi jumlah permintaan dari satu pengguna ke nilai tertentu dan, dengan demikian, mencegah serangan DoS.

Mari kita formalkan proses pemrosesan gambar yang sukses

  1. Pengguna mengirimkan gambar ke bot Telegram
  2. "attrai-telegram-bot" menerima pesan dari API Telegram dan menguraikannya
  3. Tugas dengan gambar ditambahkan ke antrian asinkron “to_estimate”
  4. Pengguna menerima pesan dengan waktu evaluasi yang direncanakan
  5. “attrai-estimator” mengambil tugas dari antrean “to_estimate”, menjalankan estimasi melalui pipeline dan menghasilkan tugas ke dalam antrean “after_estimate”
  6. "attrai-telegram-bot" mendengarkan antrian "after_estimate", mengirimkan hasilnya ke pengguna

DevOps

Terakhir, setelah meninjau arsitekturnya, Anda dapat beralih ke bagian yang sama menariknya - DevOps

Kawanan Docker

 

Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Kawanan Docker  — sistem pengelompokan, yang fungsinya diimplementasikan di dalam Mesin Docker dan langsung tersedia.

Dengan menggunakan “swarm”, semua node di cluster kami dapat dibagi menjadi 2 jenis – pekerja dan manajer. Pada mesin tipe pertama, kelompok kontainer (tumpukan) dikerahkan, mesin tipe kedua bertanggung jawab untuk penskalaan, penyeimbangan, dan fitur keren lainnya. Manajer juga merupakan pekerja secara default.

Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Cluster dengan satu manajer pemimpin dan tiga pekerja

Ukuran cluster minimum yang mungkin adalah 1 node; satu mesin akan bertindak secara bersamaan sebagai manajer pemimpin dan pekerja. Berdasarkan ukuran proyek dan persyaratan minimum toleransi kesalahan, diputuskan untuk menggunakan pendekatan ini.

Ke depan, saya akan mengatakan bahwa sejak pengiriman produksi pertama, yaitu pada pertengahan Juni, tidak ada masalah yang terkait dengan organisasi klaster ini (tetapi ini tidak berarti bahwa organisasi semacam itu dapat diterima dalam skala menengah-besar mana pun. proyek, yang tunduk pada persyaratan toleransi kesalahan).

Tumpukan Docker

Dalam mode gerombolan, dia bertanggung jawab untuk menyebarkan tumpukan (kumpulan layanan buruh pelabuhan) tumpukan buruh pelabuhan

Ini mendukung konfigurasi pembuatan buruh pelabuhan, memungkinkan Anda untuk menggunakan parameter penerapan tambahan.  

Misalnya, dengan menggunakan parameter ini, sumber daya untuk setiap instans layanan mikro evaluasi menjadi terbatas (kami mengalokasikan N inti untuk N instans, dalam layanan mikro itu sendiri kami membatasi jumlah inti yang digunakan oleh PyTorch menjadi satu)

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

Penting untuk dicatat bahwa Redis, RabbitMQ, dan Graylog adalah layanan stateful dan tidak dapat diskalakan semudah “attrai-estimator”

Membayangkan pertanyaan - mengapa bukan Kubernetes?

Tampaknya menggunakan Kubernetes dalam proyek-proyek kecil dan menengah merupakan sebuah overhead; semua fungsi yang diperlukan dapat diperoleh dari Docker Swarm, yang cukup mudah digunakan untuk orkestrator container dan juga memiliki hambatan masuk yang rendah.

Infrastruktur

Semua ini diterapkan pada VDS dengan karakteristik sebagai berikut:

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

Setelah pengujian beban lokal, tampaknya dengan banyaknya pengguna, mesin ini sudah cukup.

Namun, segera setelah penerapan, saya memposting tautan ke salah satu papan gambar paling populer di CIS (ya, yang sama), setelah itu orang-orang menjadi tertarik dan dalam beberapa jam layanan tersebut berhasil memproses puluhan ribu gambar. Pada saat yang sama, pada saat-saat puncak, sumber daya CPU dan RAM bahkan tidak terpakai setengahnya.

Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf
Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Beberapa grafis lagi

Jumlah pengguna unik dan permintaan evaluasi sejak penerapan, bergantung pada harinya

Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Distribusi waktu inferensi pipeline evaluasi

Gambaran umum arsitektur layanan untuk penilaian penampilan berdasarkan jaringan saraf

Temuan

Ringkasnya, saya dapat mengatakan bahwa arsitektur dan pendekatan terhadap orkestrasi container sepenuhnya dapat dibenarkan - bahkan pada saat-saat puncak tidak ada penurunan atau penurunan waktu pemrosesan. 

Menurut saya proyek kecil dan menengah yang menggunakan inferensi jaringan saraf CPU secara real-time dalam prosesnya dapat berhasil mengadopsi praktik yang dijelaskan dalam artikel ini.

Saya akan menambahkan bahwa awalnya artikelnya lebih panjang, tetapi agar tidak memposting artikel yang panjang, saya memutuskan untuk menghilangkan beberapa poin dalam artikel ini - kami akan kembali ke poin tersebut di publikasi mendatang.

Anda dapat menyodok bot di Telegram - @AttraiBot, ini akan berfungsi setidaknya hingga akhir musim gugur 2020. Izinkan saya mengingatkan Anda bahwa tidak ada data pengguna yang disimpan - baik gambar asli, maupun hasil jalur evaluasi - semuanya dihancurkan setelah diproses.

Sumber: www.habr.com

Tambah komentar