Είσοδος
Γεια σας!
Σε αυτό το άρθρο θα μοιραστώ την εμπειρία μου από την κατασκευή μιας αρχιτεκτονικής microservice για ένα έργο χρησιμοποιώντας νευρωνικά δίκτυα.
Ας μιλήσουμε για τις απαιτήσεις αρχιτεκτονικής, ας δούμε διάφορα δομικά διαγράμματα, αναλύσουμε κάθε ένα από τα στοιχεία της τελικής αρχιτεκτονικής και επίσης αξιολογούμε τις τεχνικές μετρήσεις της λύσης.
Απολαύστε την ανάγνωση!
Λίγα λόγια για το πρόβλημα και τη λύση του
Η κύρια ιδέα είναι να αξιολογηθεί η ελκυστικότητα ενός ατόμου σε μια κλίμακα δέκα βαθμών με βάση μια φωτογραφία.
Σε αυτό το άρθρο θα απομακρυνθούμε από την περιγραφή τόσο των νευρωνικών δικτύων που χρησιμοποιούνται όσο και της διαδικασίας προετοιμασίας και εκπαίδευσης δεδομένων. Ωστόσο, σε μία από τις ακόλουθες δημοσιεύσεις, σίγουρα θα επιστρέψουμε στην ανάλυση του αγωγού αξιολόγησης σε βάθος.
Τώρα θα περάσουμε από τον αγωγό αξιολόγησης στο ανώτατο επίπεδο και θα επικεντρωθούμε στην αλληλεπίδραση των μικροϋπηρεσιών στο πλαίσιο της συνολικής αρχιτεκτονικής του έργου.
Κατά την εργασία στον αγωγό αξιολόγησης ελκυστικότητας, η εργασία αναλύθηκε στα ακόλουθα στοιχεία:
- Επιλογή προσώπων στις φωτογραφίες
- Βαθμολογία κάθε ατόμου
- Αποδώστε το αποτέλεσμα
Το πρώτο λύνεται από τις δυνάμεις των προεκπαιδευμένων . Για το δεύτερο, ένα συνελικτικό νευρωνικό δίκτυο εκπαιδεύτηκε στο PyTorch, χρησιμοποιώντας – από την ισορροπία «ποιότητα / ταχύτητα συμπερασμάτων στη CPU»
Λειτουργικό διάγραμμα του αγωγού αξιολόγησης
Ανάλυση απαιτήσεων αρχιτεκτονικής έργου
Στον κύκλο ζωής Τα στάδια εργασίας του έργου για την αρχιτεκτονική και την αυτοματοποίηση της ανάπτυξης μοντέλων είναι συχνά από τα πιο χρονοβόρα και πιο απαιτητικά πόρους.
Κύκλος ζωής ενός έργου ML
Αυτό το έργο δεν αποτελεί εξαίρεση - πάρθηκε η απόφαση να αναδιπλωθεί ο αγωγός αξιολόγησης σε μια διαδικτυακή υπηρεσία, η οποία απαιτούσε να βυθιστούμε στην αρχιτεκτονική. Προσδιορίστηκαν οι ακόλουθες βασικές απαιτήσεις:
- Ενοποιημένη αποθήκευση αρχείων καταγραφής – όλες οι υπηρεσίες θα πρέπει να γράφουν αρχεία καταγραφής σε ένα μέρος, θα πρέπει να είναι βολικό να αναλυθούν
- Δυνατότητα οριζόντιας κλιμάκωσης της υπηρεσίας αξιολόγησης - ως το πιο πιθανό Bottleneck
- Ο ίδιος αριθμός πόρων επεξεργαστή θα πρέπει να διατεθεί για την αξιολόγηση κάθε εικόνας, προκειμένου να αποφευχθούν ακραίες τιμές στην κατανομή του χρόνου για συμπεράσματα
- Γρήγορη (επαν)ανάπτυξη τόσο των συγκεκριμένων υπηρεσιών όσο και της στοίβας συνολικά
- Η δυνατότητα, εάν είναι απαραίτητο, χρήσης κοινών αντικειμένων σε διαφορετικές υπηρεσίες
Αρχιτεκτονική
Μετά την ανάλυση των απαιτήσεων, έγινε προφανές ότι η αρχιτεκτονική microservice ταιριάζει σχεδόν τέλεια.
Για να απαλλαγούμε από περιττούς πονοκεφάλους, το Telegram API επιλέχθηκε ως frontend.
Αρχικά, ας δούμε το δομικό διάγραμμα της τελικής αρχιτεκτονικής και, στη συνέχεια, ας προχωρήσουμε σε μια περιγραφή καθενός από τα στοιχεία και, επίσης, επισημοποιούμε τη διαδικασία της επιτυχημένης επεξεργασίας εικόνας.
Δομικό διάγραμμα της τελικής αρχιτεκτονικής
Ας μιλήσουμε αναλυτικότερα για καθένα από τα στοιχεία του διαγράμματος, δηλώνοντάς τα Ενιαία Ευθύνη στη διαδικασία αξιολόγησης εικόνας.
Microservice “attrai-telegram-bot”
Αυτή η μικρουπηρεσία ενσωματώνει όλες τις αλληλεπιδράσεις με το Telegram API. Υπάρχουν 2 κύρια σενάρια: η εργασία με μια προσαρμοσμένη εικόνα και η εργασία με το αποτέλεσμα ενός αγωγού αξιολόγησης. Ας δούμε και τα δύο σενάρια γενικά.
Όταν λαμβάνετε ένα προσαρμοσμένο μήνυμα με μια εικόνα:
- Η διήθηση πραγματοποιείται, η οποία αποτελείται από τους ακόλουθους ελέγχους:
- Διαθεσιμότητα βέλτιστου μεγέθους εικόνας
- Αριθμός εικόνων χρήστη που βρίσκονται ήδη στην ουρά
- Κατά τη διέλευση του αρχικού φιλτραρίσματος, η εικόνα αποθηκεύεται στον τόμο του docker
- Παράγεται μια εργασία στην ουρά "to_estimate", η οποία περιλαμβάνει, μεταξύ άλλων, τη διαδρομή προς την εικόνα που βρίσκεται στον τόμο μας
- Εάν τα παραπάνω βήματα ολοκληρωθούν με επιτυχία, ο χρήστης θα λάβει ένα μήνυμα με τον κατά προσέγγιση χρόνο επεξεργασίας εικόνας, ο οποίος υπολογίζεται με βάση τον αριθμό των εργασιών στην ουρά. Εάν παρουσιαστεί κάποιο σφάλμα, ο χρήστης θα ειδοποιηθεί ρητά στέλνοντας ένα μήνυμα με πληροφορίες σχετικά με το τι μπορεί να έχει πάει στραβά.
Επίσης, αυτή η μικρουπηρεσία, όπως ένας εργάτης σέλινου, ακούει την ουρά "after_estimate", η οποία προορίζεται για εργασίες που έχουν περάσει από τη γραμμή αξιολόγησης.
Όταν λαμβάνετε μια νέα εργασία από το "after_estimate":
- Εάν η επεξεργασία της εικόνας είναι επιτυχής, στέλνουμε το αποτέλεσμα στον χρήστη, εάν όχι, ειδοποιούμε για ένα σφάλμα.
- Αφαίρεση της εικόνας που είναι το αποτέλεσμα του αγωγού αξιολόγησης
Μικροϋπηρεσία αξιολόγησης «attrai-estimator»
Αυτή η μικρουπηρεσία είναι ένας εργάτης σέλινου και ενσωματώνει οτιδήποτε σχετίζεται με τον αγωγό αξιολόγησης εικόνας. Υπάρχει μόνο ένας αλγόριθμος εργασίας εδώ - ας τον αναλύσουμε.
Όταν λαμβάνετε μια νέα εργασία από το "to_estimate":
- Ας τρέξουμε την εικόνα μέσω του αγωγού αξιολόγησης:
- Φόρτωση της εικόνας στη μνήμη
- Φέρνουμε την εικόνα στο απαιτούμενο μέγεθος
- Εύρεση όλων των προσώπων (MTCNN)
- Αξιολογούμε όλα τα πρόσωπα (τυλίγουμε τα πρόσωπα που βρέθηκαν στο τελευταίο βήμα σε μια παρτίδα και συμπεραίνουμε το ResNet34)
- Αποδώστε την τελική εικόνα
- Ας σχεδιάσουμε τα πλαίσια οριοθέτησης
- Σχεδιάζοντας τις βαθμολογίες
- Διαγραφή προσαρμοσμένης (πρωτότυπης) εικόνας
- Αποθήκευση της παραγωγής από τη γραμμή αξιολόγησης
- Βάζουμε την εργασία στην ουρά "after_estimate", την οποία ακούει η μικρουπηρεσία "attrai-telegram-bot" που συζητήθηκε παραπάνω.
Graylog (+ mongoDB + Elasticsearch)
είναι μια λύση για κεντρική διαχείριση αρχείων καταγραφής. Σε αυτό το έργο, χρησιμοποιήθηκε για τον προορισμό του.
Η επιλογή έπεσε πάνω του και όχι στη συνηθισμένη στοίβα, λόγω της ευκολίας της εργασίας με αυτό από την Python. Το μόνο που χρειάζεται να κάνετε για να συνδεθείτε στο Graylog είναι να προσθέσετε το GELFTCPHandler από το πακέτο στους υπόλοιπους χειριστές root logger της microservice python.
Ως κάποιος που στο παρελθόν είχα δουλέψει μόνο με τη στοίβα ELK, είχα μια γενικά θετική εμπειρία ενώ δούλευα με τη Graylog. Το μόνο πράγμα που είναι καταθλιπτικό είναι η υπεροχή των δυνατοτήτων Kibana σε σχέση με τη διεπαφή ιστού Graylog.
RabbitMQ
είναι ένας μεσίτης μηνυμάτων που βασίζεται στο πρωτόκολλο AMQP.
Σε αυτό το έργο χρησιμοποιήθηκε ως μεσίτη για το Celery και εργάστηκε σε ανθεκτική λειτουργία.
Ρέντη
είναι ένα NoSQL DBMS που λειτουργεί με δομές δεδομένων κλειδιού-τιμής
Μερικές φορές υπάρχει ανάγκη χρήσης κοινών αντικειμένων που υλοποιούν ορισμένες δομές δεδομένων σε διαφορετικές μικροϋπηρεσίες Python.
Για παράδειγμα, το Redis αποθηκεύει ένα hashmap της μορφής "telegram_user_id => αριθμός ενεργών εργασιών στην ουρά", που σας επιτρέπει να περιορίσετε τον αριθμό των αιτημάτων από έναν χρήστη σε μια συγκεκριμένη τιμή και, ως εκ τούτου, να αποτρέψετε επιθέσεις DoS.
Ας επισημοποιήσουμε τη διαδικασία της επιτυχημένης επεξεργασίας εικόνας
- Ο χρήστης στέλνει μια εικόνα στο bot του Telegram
- Το "attrai-telegram-bot" λαμβάνει ένα μήνυμα από το Telegram API και το αναλύει
- Η εργασία με την εικόνα προστίθεται στην ασύγχρονη ουρά "to_estimate"
- Ο χρήστης λαμβάνει ένα μήνυμα με τον προγραμματισμένο χρόνο αξιολόγησης
- Το "attrai-estimator" παίρνει μια εργασία από την ουρά "to_estimate", εκτελεί τις εκτιμήσεις μέσω του pipeline και παράγει την εργασία στην ουρά "after_estimate"
- Το "attrai-telegram-bot" ακούγοντας την ουρά "after_estimate", στέλνει το αποτέλεσμα στον χρήστη
DevOps
Τέλος, αφού αναθεωρήσετε την αρχιτεκτονική, μπορείτε να προχωρήσετε στο εξίσου ενδιαφέρον κομμάτι - DevOps
Σμήνος Docker
— ένα σύστημα ομαδοποίησης, η λειτουργικότητα του οποίου υλοποιείται μέσα στο Docker Engine και είναι διαθέσιμο εκτός συσκευασίας.
Χρησιμοποιώντας ένα «σμήνος», όλοι οι κόμβοι στο σύμπλεγμα μας μπορούν να χωριστούν σε 2 τύπους – εργαζόμενος και διαχειριστής. Στις μηχανές του πρώτου τύπου, αναπτύσσονται ομάδες δοχείων (στοίβες), οι μηχανές του δεύτερου τύπου είναι υπεύθυνες για την κλιμάκωση, την εξισορρόπηση και . Οι διευθυντές είναι επίσης εργαζόμενοι από προεπιλογή.
Συγκέντρωση με έναν επικεφαλής διευθυντή και τρεις εργαζόμενους
Το ελάχιστο δυνατό μέγεθος συμπλέγματος είναι 1 κόμβος· ένα μεμονωμένο μηχάνημα θα λειτουργεί ταυτόχρονα ως επικεφαλής διαχειριστής και ως εργαζόμενος. Με βάση το μέγεθος του έργου και τις ελάχιστες απαιτήσεις για ανοχή σφαλμάτων, αποφασίστηκε να χρησιμοποιηθεί αυτή η προσέγγιση.
Κοιτάζοντας το μέλλον, θα πω ότι από την πρώτη παράδοση παραγωγής, που ήταν στα μέσα Ιουνίου, δεν υπήρξαν προβλήματα που να σχετίζονται με αυτήν την οργάνωση cluster (αλλά αυτό δεν σημαίνει ότι μια τέτοια οργάνωση είναι με οποιονδήποτε τρόπο αποδεκτή σε οποιαδήποτε μεσαία-μεγάλη έργα, τα οποία υπόκεινται σε απαιτήσεις ανοχής σφαλμάτων).
Docker Stack
Στη λειτουργία σμήνος, είναι υπεύθυνος για την ανάπτυξη στοίβων (σετ υπηρεσιών docker)
Υποστηρίζει διαμορφώσεις docker-compose, επιτρέποντάς σας να χρησιμοποιείτε επιπλέον παραμέτρους ανάπτυξης.
Για παράδειγμα, χρησιμοποιώντας αυτές τις παραμέτρους, οι πόροι για κάθε μια από τις περιπτώσεις μικροϋπηρεσιών αξιολόγησης ήταν περιορισμένοι (διαθέτουμε N πυρήνες για N παρουσίες, στην ίδια την 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 είναι κρατικές υπηρεσίες και δεν μπορούν να κλιμακωθούν τόσο εύκολα όσο το "attrai-estimator"
Προμηνύοντας το ερώτημα - γιατί όχι ο Kubernetes;
Φαίνεται ότι η χρήση του Kubernetes σε μικρού και μεσαίου μεγέθους έργα είναι επιβάρυνση· όλες οι απαραίτητες λειτουργίες μπορούν να ληφθούν από το Docker Swarm, το οποίο είναι αρκετά φιλικό προς τον χρήστη για έναν ενορχηστρωτή κοντέινερ και έχει επίσης χαμηλό εμπόδιο εισόδου.
Υποδομή
Όλα αυτά αναπτύχθηκαν σε VDS με τα ακόλουθα χαρακτηριστικά:
- CPU: CPU 4 πυρήνων Intel® Xeon® Gold 5120 @ 2.20 GHz
- RAM: 8 GB
- SSD: 160 GB
Μετά από τοπικές δοκιμές φορτίου, φάνηκε ότι με μια σοβαρή εισροή χρηστών, αυτό το μηχάνημα θα ήταν αρκετό.
Όμως, αμέσως μετά την ανάπτυξη, δημοσίευσα έναν σύνδεσμο προς έναν από τους πιο δημοφιλείς πίνακες εικόνας στην ΚΑΚ (ναι, ο ίδιος), μετά τον οποίο οι άνθρωποι ενδιαφέρθηκαν και σε λίγες ώρες η υπηρεσία επεξεργάστηκε με επιτυχία δεκάδες χιλιάδες εικόνες. Ταυτόχρονα, σε στιγμές αιχμής, οι πόροι CPU και RAM δεν χρησιμοποιήθηκαν ούτε κατά το ήμισυ.
Μερικά ακόμα γραφικά
Αριθμός μοναδικών χρηστών και αιτήματα αξιολόγησης από την ανάπτυξη, ανάλογα με την ημέρα
Κατανομή χρόνου συμπερασμάτων αγωγού αξιολόγησης
Ευρήματα
Συνοψίζοντας, μπορώ να πω ότι η αρχιτεκτονική και η προσέγγιση για την ενορχήστρωση των κοντέινερ δικαιολογούνται πλήρως - ακόμη και σε στιγμές αιχμής δεν υπήρχαν πτώσεις ή χαλάρωση στον χρόνο επεξεργασίας.
Νομίζω ότι τα μικρού και μεσαίου μεγέθους έργα που χρησιμοποιούν συμπέρασμα σε πραγματικό χρόνο νευρωνικών δικτύων στη CPU στη διαδικασία τους μπορούν να υιοθετήσουν με επιτυχία τις πρακτικές που περιγράφονται σε αυτό το άρθρο.
Θα προσθέσω ότι αρχικά το άρθρο ήταν μεγαλύτερο, αλλά για να μην δημοσιεύσω πολύ καιρό, αποφάσισα να παραλείψω ορισμένα σημεία σε αυτό το άρθρο - θα επιστρέψουμε σε αυτά σε μελλοντικές δημοσιεύσεις.
Μπορείτε να τοποθετήσετε το bot στο Telegram - @AttraiBot, θα λειτουργήσει τουλάχιστον μέχρι το τέλος του φθινοπώρου του 2020. Να σας υπενθυμίσω ότι δεν αποθηκεύονται δεδομένα χρήστη - ούτε οι αρχικές εικόνες, ούτε τα αποτελέσματα του αγωγού αξιολόγησης - όλα κατεδαφίζονται μετά την επεξεργασία.
Πηγή: www.habr.com