Δημιουργήστε επαναλαμβανόμενες, ασφαλείς και επεκτάσιμες ροές εργασιών μηχανικής εκμάθησης από άκρο σε άκρο χρησιμοποιώντας το Kubeflow στο AWS

Αυτή είναι μια φιλοξενούμενη ανάρτηση ιστολογίου γραμμένη με το athenahealth.

athenahealth κορυφαίος πάροχος λογισμικού και υπηρεσιών με δυνατότητα δικτύου για ιατρικούς ομίλους και συστήματα υγείας σε εθνικό επίπεδο. Τα ηλεκτρονικά αρχεία υγείας, η διαχείριση του κύκλου εσόδων και τα εργαλεία αφοσίωσης ασθενών επιτρέπουν την πρόσβαση ανά πάσα στιγμή, οπουδήποτε, οδηγώντας σε καλύτερα οικονομικά αποτελέσματα για τους πελάτες της και δίνοντας τη δυνατότητα στους πελάτες του παρόχου να παρέχουν καλύτερης ποιότητας φροντίδα.

Στον χώρο της τεχνητής νοημοσύνης (AI), το athenahealth χρησιμοποιεί την επιστήμη των δεδομένων και τη μηχανική μάθηση (ML) για να επιταχύνει τις επιχειρηματικές διαδικασίες και να παρέχει συστάσεις, προβλέψεις και πληροφορίες σε πολλές υπηρεσίες. Από την πρώτη εφαρμογή του σε αυτοματοποιημένες υπηρεσίες εγγράφων, την άψογη επεξεργασία εκατομμυρίων εγγράφων παρόχου-ασθενούς, έως την πιο πρόσφατη εργασία του στους εικονικούς βοηθούς και τη βελτίωση της απόδοσης του κύκλου εσόδων, το athenahealth συνεχίζει να εφαρμόζει την τεχνητή νοημοσύνη για να αυξήσει την αποτελεσματικότητα, τις δυνατότητες εξυπηρέτησης και καλύτερα αποτελέσματα για τους παρόχους και οι ασθενείς τους.

Αυτή η ανάρτηση ιστολογίου δείχνει πώς χρησιμοποιεί το athenahealth Kubeflow στο AWS (μια διανομή του Kubeflow ειδικά για το AWS) για τη δημιουργία και τον εξορθολογισμό μιας ροής εργασιών επιστήμης δεδομένων από άκρο σε άκρο που διατηρεί τα βασικά εργαλεία, βελτιστοποιεί τη λειτουργική απόδοση, αυξάνει την παραγωγικότητα των επιστημόνων δεδομένων και θέτει τις βάσεις για την πιο εύκολη επέκταση των δυνατοτήτων ML.

Το Kubeflow είναι η πλατφόρμα ML ανοιχτού κώδικα που είναι αφιερωμένη στο να κάνει τις αναπτύξεις ροών εργασίας ML στο Kubernetes απλές, φορητές και επεκτάσιμες. Το Kubeflow το επιτυγχάνει ενσωματώνοντας σχετικά εργαλεία ανοιχτού κώδικα που ενσωματώνονται καλά με το Kubernetes. Μερικά από αυτά τα έργα περιλαμβάνουν Argo για ενορχήστρωση αγωγών, Istio για service mesh, Jupyter για notebook, Spark, TensorBoard και Katib. Το Kubeflow Pipelines βοηθά στη δημιουργία και ανάπτυξη φορητών, επεκτάσιμων ροών εργασίας ML που μπορούν να περιλαμβάνουν βήματα όπως εξαγωγή δεδομένων, προεπεξεργασία, εκπαίδευση μοντέλων και αξιολόγηση μοντέλων με τη μορφή επαναλαμβανόμενων αγωγών.

Η AWS συμβάλλει στην κοινότητα Kubeflow ανοιχτού κώδικα παρέχοντας τη δική της διανομή Kubeflow (που ονομάζεται Kubeflow στο AWS) που βοηθά οργανισμούς όπως το athenahealth να δημιουργήσουν εξαιρετικά αξιόπιστες, ασφαλείς, φορητές και επεκτάσιμες ροές εργασίας ML με μειωμένο λειτουργικό κόστος μέσω ενσωμάτωσης με υπηρεσίες διαχείρισης AWS. Το AWS παρέχει διάφορες επιλογές ανάπτυξης Kubeflow, όπως ανάπτυξη με Amazon Cognito, ανάπτυξη με Υπηρεσία σχεσιακής βάσης δεδομένων Amazon (Amazon RDS) και Απλή υπηρεσία αποθήκευσης Amazon (Amazon S3) και ανάπτυξη βανίλιας. Για λεπτομέρειες σχετικά με την ενοποίηση υπηρεσιών και τα διαθέσιμα πρόσθετα για καθεμία από αυτές τις επιλογές, ανατρέξτε στο Ανάπτυξη.

Σήμερα, το Kubeflow στο AWS παρέχει μια σαφή διαδρομή για τη χρήση του Kubeflow, επαυξημένη με τις ακόλουθες υπηρεσίες AWS:

Πολλοί πελάτες AWS εκμεταλλεύονται το Kubeflow στη διανομή AWS, συμπεριλαμβανομένου του athenahealth.

Εδώ, η ομάδα του athenahealth MLOps συζητά τις προκλήσεις που αντιμετώπισαν και τις λύσεις που δημιούργησαν στο ταξίδι τους στο Kubeflow.

Προκλήσεις με το προηγούμενο περιβάλλον ML

Πριν από την υιοθέτηση του Kubeflow στο AWS, οι επιστήμονες δεδομένων μας χρησιμοποιούσαν ένα τυποποιημένο σύνολο εργαλείων και μια διαδικασία που επέτρεπε ευελιξία στην τεχνολογία και τη ροή εργασίας που χρησιμοποιούνται για την εκπαίδευση ενός συγκεκριμένου μοντέλου. Παραδείγματα στοιχείων του τυποποιημένου εργαλείου περιλαμβάνουν ένα API απορρόφησης δεδομένων, εργαλεία σάρωσης ασφαλείας, τη διοχέτευση CI/CD που κατασκευάστηκε και συντηρείται από άλλη ομάδα εντός του athenahealth και μια κοινή πλατφόρμα εξυπηρέτησης που κατασκευάστηκε και συντηρείται από την ομάδα MLOps. Ωστόσο, καθώς ωρίμαζε η χρήση AI και ML, η ποικιλία των εργαλείων και της υποδομής που δημιουργήθηκαν για κάθε μοντέλο αυξήθηκε. Παρόλο που ήμασταν ακόμη σε θέση να υποστηρίξουμε την υπάρχουσα διαδικασία, είδαμε τις ακόλουθες προκλήσεις στον ορίζοντα:

• Συντήρηση και ανάπτυξη – Η αναπαραγωγή και η διατήρηση περιβαλλόντων εκπαίδευσης μοντέλων χρειάστηκε μεγαλύτερη προσπάθεια καθώς αυξανόταν ο αριθμός των αναπτυγμένων μοντέλων. Κάθε έργο διατηρούσε λεπτομερή τεκμηρίωση που περιέγραφε πώς χρησιμοποιήθηκε κάθε σενάριο για την κατασκευή του τελικού μοντέλου. Σε πολλές περιπτώσεις, αυτή ήταν μια περίπλοκη διαδικασία που περιλάμβανε 5 έως 10 σενάρια με πολλές εξόδους το καθένα. Αυτά έπρεπε να παρακολουθούνται χειροκίνητα με λεπτομερείς οδηγίες για το πώς θα χρησιμοποιηθεί κάθε έξοδος σε επόμενες διαδικασίες. Η διατήρηση αυτού με την πάροδο του χρόνου έγινε δυσκίνητη. Επιπλέον, καθώς τα έργα έγιναν πιο πολύπλοκα, αυξήθηκε και ο αριθμός των εργαλείων. Για παράδειγμα, τα περισσότερα μοντέλα χρησιμοποιούσαν το Spark και το TensorFlow με GPU, που απαιτούσαν μεγαλύτερη ποικιλία διαμορφώσεων περιβάλλοντος. Με την πάροδο του χρόνου, οι χρήστες μεταβαίνονταν σε νεότερες εκδόσεις εργαλείων στα περιβάλλοντα ανάπτυξής τους, αλλά στη συνέχεια δεν μπορούσαν να εκτελέσουν παλαιότερα σενάρια όταν αυτές οι εκδόσεις έγιναν ασύμβατες. Κατά συνέπεια, η συντήρηση και η ενίσχυση παλαιότερων έργων απαιτούσε περισσότερο χρόνο και προσπάθεια μηχανικής. Επιπλέον, καθώς νέοι επιστήμονες δεδομένων εντάχθηκαν στην ομάδα, η μεταφορά γνώσης και η ενσωμάτωση χρειάστηκαν περισσότερο χρόνο, επειδή ο συγχρονισμός τοπικών περιβαλλόντων περιελάμβανε πολλές εξαρτήσεις χωρίς τεκμηρίωση. Η εναλλαγή μεταξύ έργων αντιμετώπισε τα ίδια προβλήματα, επειδή κάθε μοντέλο είχε τις δικές του ροές εργασίας.
• Ασφάλεια – Λαμβάνουμε σοβαρά υπόψη την ασφάλεια και, ως εκ τούτου, δίνουμε προτεραιότητα στη συμμόρφωση με όλες τις συμβατικές, νομικές και ρυθμιστικές υποχρεώσεις που σχετίζονται με την ML και την επιστήμη δεδομένων. Τα δεδομένα πρέπει να χρησιμοποιούνται, να αποθηκεύονται και να έχουν πρόσβαση με συγκεκριμένους τρόπους και έχουμε ενσωματώσει ισχυρές διαδικασίες για να διασφαλίσουμε ότι οι πρακτικές μας συμμορφώνονται με τις νομικές μας υποχρεώσεις καθώς και με τις βέλτιστες πρακτικές του κλάδου. Πριν από την υιοθέτηση του Kubeflow, η διασφάλιση της αποθήκευσης και της πρόσβασης στα δεδομένα με συγκεκριμένο τρόπο περιλάμβανε τακτική επαλήθευση σε πολλαπλές, διαφορετικές ροές εργασίας. Γνωρίζαμε ότι μπορούσαμε να βελτιώσουμε την αποτελεσματικότητα ενοποιώντας αυτές τις διαφορετικές ροές εργασίας σε μια ενιαία πλατφόρμα. Ωστόσο, αυτή η πλατφόρμα θα πρέπει να είναι αρκετά ευέλικτη ώστε να ενσωματώνεται καλά με τα τυποποιημένα εργαλεία μας.
• λειτουργίες – Είδαμε επίσης μια ευκαιρία να αυξήσουμε τη λειτουργική αποτελεσματικότητα και τη διαχείριση μέσω της συγκέντρωσης της καταγραφής και της παρακολούθησης των ροών εργασίας. Επειδή κάθε ομάδα είχε αναπτύξει τα δικά της εργαλεία, συλλέξαμε αυτές τις πληροφορίες από κάθε ροή εργασίας ξεχωριστά και τις συγκεντρώσαμε.

Η ομάδα της επιστήμης δεδομένων αξιολόγησε διάφορες λύσεις για την ενοποίηση των ροών εργασίας. Εκτός από την αντιμετώπιση αυτών των απαιτήσεων, αναζητήσαμε μια λύση που θα ενσωματωνόταν απρόσκοπτα με την υπάρχουσα τυποποιημένη υποδομή και εργαλεία. Επιλέξαμε το Amazon EKS και το Kubeflow στο AWS ως τη λύση ροής εργασιών μας.

Ο κύκλος ανάπτυξης του επιστήμονα δεδομένων που ενσωματώνει το Kubeflow

Ένα έργο επιστήμης δεδομένων ξεκινά με μια καθαρή πλάκα: χωρίς δεδομένα, χωρίς κώδικα, μόνο το επιχειρηματικό πρόβλημα που μπορεί να λυθεί με την ML. Η πρώτη εργασία είναι μια απόδειξη της έννοιας (POC) για να ανακαλύψετε εάν τα δεδομένα έχουν αρκετό σήμα για να καταστήσει ένα μοντέλο ML αποτελεσματικό στην επίλυση του επιχειρηματικού προβλήματος, ξεκινώντας με την αναζήτηση για το ακατέργαστο σύνολο δεδομένων από την αποθήκη δεδομένων Snowflake. Αυτό το στάδιο είναι επαναληπτικό και οι επιστήμονες δεδομένων χρησιμοποιούν Kubernetes pods ή σημειωματάρια Kubeflow Jupyter κατά τη διάρκεια αυτής της διαδικασίας.

Το σύμπλεγμα Kubeflow χρησιμοποιεί τον αυτόματο διαβαθμιστή συμπλέγματος Karpenter, ο οποίος διευκολύνει την περιστροφή πόρων για τους επιστήμονες δεδομένων, επειδή χρειάζεται μόνο να επικεντρωθούν στον καθορισμό των επιθυμητών τύπων παρουσιών, ενώ η εργασία παροχής γίνεται από ένα σύνολο προκαθορισμένων προμηθευτών Karpenter. Έχουμε ξεχωριστούς παρόχους για τύπους παρόχου CPU και GPU και όλες οι περιπτώσεις που υποστηρίζονται από το Amazon EKS εμπίπτουν σε μία από αυτές τις δύο κατηγορίες σύμφωνα με τη διαμόρφωση του παρόχου μας. Οι επιστήμονες δεδομένων επιλέγουν τύπους περιπτώσεων χρησιμοποιώντας επιλογείς κόμβων και η Karpenter φροντίζει για τη διαχείριση του κύκλου ζωής του κόμβου.

Αφού αναπτυχθεί το ερώτημα, οι επιστήμονες δεδομένων εξάγουν τα ακατέργαστα δεδομένα σε μια τοποθεσία στο Amazon S3 και στη συνέχεια εκκινούν έναν φορητό υπολογιστή Jupyter από το AWS Kubeflow UI για να εξερευνήσουν τα δεδομένα. Ο στόχος είναι να δημιουργηθεί το σύνολο χαρακτηριστικών που θα χρησιμοποιηθεί για την εκπαίδευση του πρώτου μοντέλου. Αυτό επιτρέπει στους επιστήμονες δεδομένων να προσδιορίσουν εάν υπάρχει αρκετό σήμα στα δεδομένα για την ικανοποίηση των επιχειρηματικών αναγκών του πελάτη.

Αφού τα αποτελέσματα είναι ικανοποιητικά, οι επιστήμονες δεδομένων περνούν στο επόμενο στάδιο του κύκλου ανάπτυξης και μετατρέπουν τις ανακαλύψεις τους σε έναν στιβαρό αγωγό. Μετατρέπουν τον κωδικό POC σε κωδικό ποιότητας παραγωγής που εκτελείται σε κλίμακα. Για να διασφαλιστεί η συμμόρφωση μέσω της χρήσης εγκεκριμένων βιβλιοθηκών, δημιουργείται ένα κοντέινερ με την κατάλληλη βασική εικόνα Docker. Για τους επιστήμονες δεδομένων μας, ανακαλύψαμε ότι η παροχή μιας τυπικής εικόνας βάσης Python, TensorFlow και Spark παρέχει επαρκή ευελιξία για τους περισσότερους, αν όχι όλους, φόρτους εργασίας. Στη συνέχεια, μπορούν να χρησιμοποιήσουν το Dockerfile του στοιχείου τους για να προσαρμόσουν περαιτέρω το περιβάλλον ανάπτυξής τους. Αυτό το Dockerfile χρησιμοποιείται στη συνέχεια από τη διαδικασία CI/CD για τη δημιουργία της εικόνας των στοιχείων που θα χρησιμοποιηθούν στην παραγωγή, διατηρώντας επομένως τη συνέπεια μεταξύ των περιβαλλόντων ανάπτυξης και παραγωγής.

Έχουμε ένα εργαλείο που δίνει στους επιστήμονες δεδομένων τη δυνατότητα να εκκινήσουν το περιβάλλον ανάπτυξής τους σε ένα pod που τρέχει στο Kubernetes. Όταν εκτελείται αυτό το pod, οι επιστήμονες δεδομένων μπορούν στη συνέχεια να επισυνάψουν το Visual Studio Code IDE απευθείας στο pod και να διορθώσουν τον κώδικα του μοντέλου τους. Αφού εκτελέσουν επιτυχώς τον κώδικα, μπορούν στη συνέχεια να προωθήσουν τις αλλαγές τους στο git και δημιουργείται ένα νέο περιβάλλον ανάπτυξης με τις πιο πρόσφατες αλλαγές.

Η τυπική γραμμή επιστήμης δεδομένων αποτελείται από στάδια που περιλαμβάνουν εξαγωγή, προεπεξεργασία, εκπαίδευση και αξιολόγηση. Κάθε στάδιο στη διοχέτευση εμφανίζεται ως στοιχείο στο Kubeflow, το οποίο αποτελείται από ένα pod Kubernetes που εκτελεί μια εντολή με ορισμένες πληροφορίες που μεταβιβάζονται ως παραμέτρους. Αυτές οι παράμετροι μπορεί να είναι είτε στατικές τιμές είτε αναφορές σε έξοδο από προηγούμενο στοιχείο. Η εικόνα Docker που χρησιμοποιείται στο pod έχει δημιουργηθεί από τη διαδικασία CI/CD. Λεπτομέρειες σχετικά με αυτήν τη διαδικασία εμφανίζονται στη ροή εργασιών CI/CD που συζητείται στην επόμενη ενότητα.

Κύκλος ανάπτυξης στο Kubeflow. Η ροή εργασιών ανάπτυξης ξεκινά στα αριστερά με το POC. Το ολοκληρωμένο μοντέλο αναπτύσσεται στην πλατφόρμα εξυπηρέτησης μοντέλων athenahealth που λειτουργεί στο Amazon ECS.

Διαδικασία CI/CD που υποστηρίζει αυτοματοποιημένες ροές εργασίας

Ως μέρος της διαδικασίας CI/CD μας, χρησιμοποιούμε το Jenkins για τη δημιουργία και τη δοκιμή όλων των εικόνων στοιχείων Kubeflow παράλληλα. Με την επιτυχή ολοκλήρωση, το πρότυπο στοιχείου διοχέτευσης περιέχει δείκτες αναφοράς στις εικόνες και η προκύπτουσα διοχέτευση μεταφορτώνεται στο Kubeflow. Οι παράμετροι στον αγωγό Jenkins επιτρέπουν στους χρήστες να ξεκινήσουν τους αγωγούς και να εκτελέσουν τις δοκιμές εκπαίδευσης μοντέλων τους μετά από επιτυχημένες κατασκευές.

Εναλλακτικά, για να διατηρηθεί ένας σύντομος κύκλος ανάπτυξης, οι επιστήμονες δεδομένων μπορούν επίσης να ξεκινήσουν τον αγωγό από το τοπικό τους μηχάνημα, τροποποιώντας τυχόν παραμέτρους του αγωγού με τις οποίες μπορεί να πειραματίζονται.

Υπάρχουν εργαλεία για να διασφαλιστεί ότι οι δείκτες αναφοράς από την έκδοση CI/CD χρησιμοποιούνται από προεπιλογή. Εάν υπάρχει ένα αναπτύξιμο τεχνούργημα στο αποθετήριο, τότε η λογική CI/CD θα συνεχίσει να αναπτύσσει το τεχνούργημα στην πλατφόρμα εξυπηρέτησης μοντέλων athenahealth (την Υπηρεσία Πρόβλεψης) που εκτελείται στο Amazon ECS με AWS Fargate. Αφού περάσουν όλα αυτά τα στάδια, ο επιστήμονας δεδομένων συγχωνεύει τον κώδικα στον πρωτεύοντα κλάδο. Οι αγωγοί και τα αναπτυσσόμενα τεχνουργήματα στη συνέχεια ωθούνται στην παραγωγή.

Ροή εργασιών ανάπτυξης CI/CD. Αυτό το διάγραμμα περιγράφει τη ροή εργασιών δημιουργίας και ανάπτυξης της Επιστήμης Δεδομένων. Η διαδικασία CI/CD καθοδηγείται από Jenkins.

Ασφάλεια

Ενοποιώντας τις ροές εργασιών της επιστήμης δεδομένων, μπορέσαμε να συγκεντρώσουμε την προσέγγισή μας για τη διασφάλιση του αγωγού εκπαίδευσης. Σε αυτήν την ενότητα, συζητάμε την προσέγγισή μας στην ασφάλεια δεδομένων και συμπλέγματος.

Η ασφάλεια των δεδομένων

Η ασφάλεια των δεδομένων είναι υψίστης σημασίας στο athenahealth. Για το λόγο αυτό, αναπτύσσουμε και συντηρούμε υποδομές που είναι πλήρως συμβατές με τους κανονισμούς και τα πρότυπα που προστατεύουν την ασφάλεια και την ακεραιότητα αυτών των δεδομένων.

Για να διασφαλίσουμε ότι τηρούμε τα πρότυπα συμμόρφωσης δεδομένων, παρέχουμε την υποδομή AWS σύμφωνα με τις εταιρικές κατευθυντήριες γραμμές της athenahealth. Οι δύο κύριοι χώροι αποθήκευσης δεδομένων είναι το Amazon RDS για μεταδεδομένα αγωγών υψηλής κλιμάκωσης και το Amazon S3 για τεχνουργήματα αγωγών και μοντέλων. Για το Amazon S3, διασφαλίζουμε ότι οι κάδοι είναι κρυπτογραφημένοι, τα τελικά σημεία HTTPS επιβάλλονται και οι πολιτικές κάδου και Διαχείριση ταυτότητας και πρόσβασης AWS Οι ρόλοι (IAM) ακολουθούν τις αρχές του ελάχιστου προνομίου όταν επιτρέπουν την πρόσβαση στα δεδομένα. Αυτό ισχύει και για τα δεδομένα RDS του Amazon: η κρυπτογράφηση είναι πάντα ενεργοποιημένη και οι ομάδες ασφαλείας και η πρόσβαση διαπιστευτηρίων ακολουθούν την αρχή του ελάχιστου προνομίου. Αυτή η τυποποίηση διασφαλίζει ότι μόνο εξουσιοδοτημένα μέρη έχουν πρόσβαση στα δεδομένα και ότι αυτή η πρόσβαση παρακολουθείται.

Εκτός από αυτά τα μέτρα, η πλατφόρμα υποβάλλεται επίσης σε αξιολογήσεις απειλών ασφαλείας και συνεχείς σαρώσεις ασφάλειας και συμμόρφωσης.

Αντιμετωπίζουμε επίσης τις απαιτήσεις διατήρησης δεδομένων μέσω της διαχείρισης του κύκλου ζωής δεδομένων για όλους τους κάδους S3 που περιέχουν ευαίσθητα δεδομένα. Αυτή η πολιτική μεταφέρει αυτόματα δεδομένα σε Παγετώνας Amazon S3 μετά από 30 ημέρες δημιουργίας. Η διαχείριση των εξαιρέσεων γίνεται μέσω αιτημάτων ανάκτησης δεδομένων και εγκρίνονται ή απορρίπτονται κατά περίπτωση. Αυτό διασφαλίζει ότι όλες οι ροές εργασίας συμμορφώνονται με την πολιτική διατήρησης δεδομένων. Αυτό λύνει επίσης το πρόβλημα με την ανάκτηση δεδομένων εάν ένα μοντέλο έχει κακή απόδοση και απαιτείται επανεκπαίδευση ή όταν ένα νέο μοντέλο πρέπει να αξιολογηθεί σε σχέση με μια ιστορική επανάληψη του συνόλου δεδομένων ενός παλαιότερου μοντέλου.

Για τον περιορισμό της πρόσβασης στο Amazon S3 και στο Amazon RDS από το Kubeflow στο AWS και στο Amazon EKS, χρησιμοποιούμε το IRSA (IAM Roles for Service Accounts), το οποίο παρέχει παροχή αδειών βάσει IAM για πόρους εντός του Kubernetes. Κάθε μισθωτής στο Kubeflow έχει έναν μοναδικό προ-δημιουργημένο λογαριασμό υπηρεσίας, τον οποίο δεσμεύουμε σε έναν ρόλο IAM που δημιουργήθηκε ειδικά για την εκπλήρωση των απαιτήσεων πρόσβασης ενοικιαστών. Η πρόσβαση των χρηστών στους ενοικιαστές περιορίζεται επίσης με τη χρήση της ιδιότητας μέλους ομάδας ομάδων χρηστών Amazon Cognito για κάθε χρήστη. Όταν ένας χρήστης επαληθεύεται στο σύμπλεγμα, το διακριτικό που δημιουργείται περιέχει ομαδικές αξιώσεις και το Kubernetes RBAC χρησιμοποιεί αυτές τις πληροφορίες για να επιτρέψει ή να αρνηθεί την πρόσβαση σε έναν συγκεκριμένο πόρο στο σύμπλεγμα. Αυτή η ρύθμιση εξηγείται λεπτομερέστερα στην επόμενη ενότητα.

Ασφάλεια συμπλέγματος με χρήση απομόνωσης πολλών χρηστών

Όπως σημειώσαμε στην προηγούμενη ενότητα, οι επιστήμονες δεδομένων εκτελούν διερευνητικές αναλύσεις δεδομένων, εκτελούν αναλύσεις δεδομένων και εκπαιδεύουν μοντέλα ML. Για την κατανομή πόρων, την οργάνωση δεδομένων και τη διαχείριση ροών εργασίας με βάση έργα, το Kubeflow στο AWS παρέχει απομόνωση με βάση τους χώρους ονομάτων Kubernetes. Αυτή η απομόνωση λειτουργεί για την αλληλεπίδραση με τη διεπαφή χρήστη Kubeflow. Ωστόσο, δεν παρέχει κανένα εργαλείο για τον έλεγχο της πρόσβασης στο Kubernetes API χρησιμοποιώντας το Kubectl. Αυτό σημαίνει ότι η πρόσβαση του χρήστη μπορεί να ελεγχθεί στο Kubeflow UI αλλά όχι μέσω του Kubernetes API μέσω Kubectl.

Η αρχιτεκτονική που περιγράφεται στο παρακάτω διάγραμμα αντιμετωπίζει αυτό το ζήτημα ενοποιώντας την πρόσβαση σε έργα στο Kubeflow με βάση τις συνδρομές ομάδων. Για να το επιτύχουμε αυτό, εκμεταλλευτήκαμε το Kubeflow στο μανιφέστο AWS, το οποίο έχει ενοποίηση με τις ομάδες χρηστών του Amazon Cognito. Επιπλέον, χρησιμοποιούμε τον έλεγχο πρόσβασης βάσει ρόλου του Kubernetes (RBAC) για τον έλεγχο της εξουσιοδότησης εντός του συμπλέγματος. Τα δικαιώματα χρήστη παρέχονται με βάση τη συμμετοχή στην ομάδα Amazon Cognito. Αυτές οι πληροφορίες μεταβιβάζονται στο σύμπλεγμα με το διακριτικό που δημιουργείται από τον πελάτη OIDC. Αυτή η διαδικασία απλοποιείται χάρη στην ενσωματωμένη λειτουργία Amazon EKS που επιτρέπει τη συσχέτιση παρόχων ταυτότητας OIDC για έλεγχο ταυτότητας με το σύμπλεγμα.

Από προεπιλογή, ο έλεγχος ταυτότητας Amazon EKS εκτελείται από τον έλεγχο ταυτότητας IAM, ο οποίος είναι ένα εργαλείο που επιτρέπει τον έλεγχο ταυτότητας με ένα σύμπλεγμα EKS χρησιμοποιώντας διαπιστευτήρια IAM. Αυτή η μέθοδος ελέγχου ταυτότητας έχει τα πλεονεκτήματά της. Ωστόσο, δεν είναι κατάλληλο για την περίπτωση χρήσης μας, επειδή το athenahealth χρησιμοποιεί το Microsoft Azure Active Directory για υπηρεσία ταυτότητας σε ολόκληρο τον οργανισμό.

Απομόνωση χώρου ονομάτων Kubernetes. Οι Επιστήμονες Δεδομένων μπορούν να αποκτήσουν συμμετοχή σε μία ή περισσότερες ομάδες ανάλογα με τις ανάγκες της εργασίας τους. Η πρόσβαση ελέγχεται σε τακτική βάση και αφαιρείται ανάλογα με την περίπτωση.

Το Azure Active Directory, ως υπηρεσία ταυτότητας σε επίπεδο επιχείρησης, είναι η πηγή της αλήθειας για τον έλεγχο της πρόσβασης των χρηστών στο σύμπλεγμα Kubeflow. Η ρύθμιση για αυτό περιλαμβάνει τη δημιουργία μιας Azure Enterprise Application που λειτουργεί ως κύρια υπηρεσία και την προσθήκη ομάδων για διάφορους ενοικιαστές που απαιτούν πρόσβαση στο σύμπλεγμα. Αυτή η ρύθμιση στο Azure αντικατοπτρίζεται στο Amazon Cognito με τη δημιουργία ενός ομοσπονδιακού πάροχου ταυτότητας OIDC που αναθέτει σε τρίτους την ευθύνη ελέγχου ταυτότητας στο Azure. Η πρόσβαση στις ομάδες Azure ελέγχεται από το SailPoint IdentityIQ, το οποίο στέλνει αιτήματα πρόσβασης στον κάτοχο του έργου για να επιτρέψει ή να απορρίψει ανάλογα με την περίπτωση. Στη δεξαμενή χρηστών του Amazon Cognito, δημιουργούνται δύο προγράμματα-πελάτες εφαρμογών: ο ένας χρησιμοποιείται για τη ρύθμιση του ελέγχου ταυτότητας για το σύμπλεγμα Kubernetes χρησιμοποιώντας τον πάροχο ταυτότητας OIDC και ο άλλος για τη διασφάλιση του ελέγχου ταυτότητας Kubeflow στη διεπαφή χρήστη Kubeflow. Αυτοί οι πελάτες έχουν διαμορφωθεί για να μεταβιβάζουν αξιώσεις ομάδας κατά τον έλεγχο ταυτότητας με το σύμπλεγμα και αυτές οι ομαδικές αξιώσεις χρησιμοποιούνται παράλληλα με το RBAC για τη ρύθμιση της εξουσιοδότησης εντός του συμπλέγματος.

Οι δεσμεύσεις ρόλων Kubernetes RBAC ρυθμίζονται μεταξύ των ομάδων και του ρόλου συμπλέγματος Kubeflow-edit, ο οποίος δημιουργείται κατά την εγκατάσταση του Kubeflow στο σύμπλεγμα. Αυτή η σύνδεση ρόλων διασφαλίζει ότι κάθε χρήστης που αλληλεπιδρά με το σύμπλεγμα μετά τη σύνδεση μέσω OIDC μπορεί να έχει πρόσβαση στους χώρους ονομάτων για τους οποίους έχει δικαιώματα, όπως ορίζεται στις ομαδικές αξιώσεις. Αν και αυτό λειτουργεί για χρήστες που αλληλεπιδρούν με το σύμπλεγμα χρησιμοποιώντας Kubectl, η διεπαφή χρήστη Kubeflow δεν παρέχει πρόσβαση σε χρήστες βάσει της ιδιότητας μέλους ομάδας επειδή δεν χρησιμοποιεί RBAC. Αντίθετα, χρησιμοποιεί τον πόρο της Πολιτικής εξουσιοδότησης Istio για τον έλεγχο της πρόσβασης των χρηστών. Για να ξεπεράσουμε αυτήν την πρόκληση, αναπτύξαμε έναν προσαρμοσμένο ελεγκτή που συγχρονίζει τους χρήστες ρωτώντας τις ομάδες Amazon Cognito και προσθέτει ή αφαιρεί αντίστοιχες δεσμεύσεις ρόλων για κάθε χρήστη και όχι ανά ομάδα. Αυτή η ρύθμιση επιτρέπει στους χρήστες να έχουν το ίδιο επίπεδο αδειών όταν αλληλεπιδρούν τόσο με το Kubeflow UI όσο και με το Kubectl.

Λειτουργική αποδοτικότητα

Σε αυτήν την ενότητα, συζητάμε πώς εκμεταλλευτήκαμε τα εργαλεία ανοιχτού κώδικα και AWS που έχουμε στη διάθεσή μας για τη διαχείριση και τον εντοπισμό σφαλμάτων στις ροές εργασίας μας καθώς και για την ελαχιστοποίηση του λειτουργικού αντίκτυπου της αναβάθμισης του Kubeflow.

Καταγραφή και παρακολούθηση

Για την καταγραφή, χρησιμοποιούμε το FluentD για να προωθήσουμε όλα τα αρχεία καταγραφής κοντέινερ Amazon OpenSearch Service και μετρήσεις συστήματος στον Προμηθέα. Στη συνέχεια χρησιμοποιούμε το Kibana και τη διεπαφή χρήστη Grafana για αναζήτηση και φιλτράρισμα αρχείων καταγραφής και μετρήσεων. Το παρακάτω διάγραμμα περιγράφει πώς το ρυθμίσαμε.

Καταγραφή Kubeflow. Χρησιμοποιούμε τόσο το Grafana UI όσο και το Kibana για να προβάλουμε και να κοσκινίζουμε τα αρχεία καταγραφής

Το παρακάτω στιγμιότυπο οθόνης είναι μια προβολή διεπαφής χρήστη Kibana από τη διοχέτευσή μας.

Δείγμα προβολής διεπαφής χρήστη Kibana. Το Kibana επιτρέπει προσαρμοσμένες προβολές.

Ασφαλείς αναβαθμίσεις συμπλέγματος Kubeflow

Καθώς ενσωματώνουμε τους χρήστες στο Kubeflow στο AWS, διατηρούμε μια αξιόπιστη και συνεπή εμπειρία χρήστη, επιτρέποντας παράλληλα στην ομάδα MLOps να παραμείνει ευέλικτη με την κυκλοφορία και την ενσωμάτωση νέων χαρακτηριστικών. Επιφανειακά, το Kustomize φαίνεται αρθρωτό για εμάς για να επιτρέπει την εργασία και την αναβάθμιση ενός στοιχείου τη φορά χωρίς να επηρεάζει άλλα, επιτρέποντάς μας έτσι να προσθέτουμε νέες δυνατότητες με ελάχιστη αναστάτωση στους χρήστες. Ωστόσο, στην πράξη υπάρχουν σενάρια όπου η καλύτερη προσέγγιση είναι απλώς η δημιουργία ενός νέου συμπλέγματος Kubernetes αντί της εφαρμογής αναβαθμίσεων σε επίπεδο στοιχείου για υπάρχοντα συμπλέγματα. Βρήκαμε δύο περιπτώσεις χρήσης όπου ήταν πιο λογικό να δημιουργήσουμε εντελώς νέα συμπλέγματα:

• Αναβάθμιση σε έκδοση Kubernetes όπου το AWS παρέχει επιτόπιες αναβαθμίσεις συμπλέγματος. Ωστόσο, καθίσταται δύσκολο να ελεγχθεί εάν καθένας από τους πόρους Kubeflow και Kubernetes λειτουργεί όπως προβλέπεται και τα μανιφέστα διατηρούν συμβατότητα προς τα πίσω.
• Η αναβάθμιση του Kubeflow σε μια νεότερη έκδοση, όπου υπάρχουν πολλές δυνατότητες που έχουν προστεθεί ή τροποποιηθεί και σχεδόν πάντα δεν είναι μια πολλά υποσχόμενη ιδέα να πραγματοποιούνται επιτόπιες αναβαθμίσεις σε ένα υπάρχον σύμπλεγμα Kubernetes.

Για την αντιμετώπιση αυτού του ζητήματος, αναπτύξαμε μια στρατηγική που μας δίνει τη δυνατότητα να έχουμε ασφαλείς αντικαταστάσεις συμπλέγματος χωρίς να επηρεάζουμε τυχόν υπάρχοντες φόρτους εργασίας. Για να το πετύχουμε αυτό έπρεπε να πληρούμε τα ακόλουθα κριτήρια:

• Διαχωρίστε τους πόρους αποθήκευσης και υπολογισμού του Kubeflow, έτσι ώστε τα μεταδεδομένα διοχέτευσης, τα τεχνουργήματα διοχέτευσης και τα δεδομένα χρήστη να διατηρούνται κατά την κατάργηση της παροχής του παλαιότερου συμπλέγματος
• Ενσωμάτωση με το Kubeflow σε μανιφέστα AWS, έτσι ώστε όταν πραγματοποιείται αναβάθμιση έκδοσης Kubeflow, απαιτούνται ελάχιστες αλλαγές
• Έχετε έναν εύκολο τρόπο να επιστρέψετε εάν τα πράγματα πάνε στραβά μετά την αναβάθμιση συμπλέγματος
• Έχετε μια απλή διεπαφή για την προώθηση ενός υποψηφίου συμπλέγματος στην παραγωγή

Το παρακάτω διάγραμμα απεικονίζει αυτή την αρχιτεκτονική.

Ασφαλής αναβάθμιση συμπλέγματος Kubeflow. Μόλις η δοκιμή του Kubeflow Candidate είναι επιτυχής, προωθείται στο Kubeflow Prod μέσω μιας ενημέρωσης στη διαδρομή 53.

Το Kubeflow στα μανιφέστα AWS είναι προσυσκευασμένα με ενσωματώσεις Amazon RDS και Amazon S3. Με αυτές τις διαχειριζόμενες υπηρεσίες που λειτουργούν ως κοινά καταστήματα δεδομένων, μπορούμε να δημιουργήσουμε μια μπλε-πράσινη στρατηγική ανάπτυξης. Για να το πετύχουμε αυτό, διασφαλίσαμε ότι τα μεταδεδομένα του αγωγού παραμένουν στο Amazon RDS, το οποίο λειτουργεί ανεξάρτητα από το σύμπλεγμα EKS, και ότι τα αρχεία καταγραφής και τα τεχνουργήματα του αγωγού παραμένουν στο Amazon S3. Εκτός από τα μεταδεδομένα διοχέτευσης και τα τεχνουργήματα, ρυθμίσαμε επίσης το FluentD για τη δρομολόγηση αρχείων καταγραφής pod στην Υπηρεσία OpenSearch της Amazon.

Αυτό διασφαλίζει ότι το επίπεδο αποθήκευσης είναι πλήρως διαχωρισμένο από το επίπεδο υπολογισμού και έτσι επιτρέπει τη δοκιμή αλλαγών κατά τις ενημερώσεις της έκδοσης Kubeflow σε ένα εντελώς νέο σύμπλεγμα EKS. Αφού όλα τα τεστ είναι επιτυχή, μπορούμε απλώς να το αλλάξουμε Η διαδρομή του Αμαζονίου 53 Εγγραφή DNS στο υποψήφιο σύμπλεγμα που φιλοξενεί το Kubeflow. Επίσης, διατηρούμε το παλιό σύμπλεγμα σε λειτουργία ως εφεδρικό για μερικές ημέρες, σε περίπτωση που χρειαστεί να επιστρέψουμε.

Οφέλη του Amazon EKS και του Kubeflow στο AWS για τον αγωγό ML μας

Το Amazon EKS και το πακέτο Kubeflow on AWS μετέφεραν τη ροή εργασιών ανάπτυξης σε ένα μοτίβο που ενθαρρύνει έντονα την επαναλαμβανόμενη εκπαίδευση μοντέλων. Αυτά τα εργαλεία μας επιτρέπουν να έχουμε πλήρως καθορισμένα συμπλέγματα με πλήρως καθορισμένους μισθωτές και να εκτελούμε πλήρως καθορισμένο κώδικα.

Πολλά κέρδη από τη δημιουργία αυτής της πλατφόρμας είναι λιγότερο ποσοτικά και έχουν να κάνουν περισσότερο με τον τρόπο με τον οποίο βελτιώθηκαν οι ροές εργασίας τόσο για τους προγραμματιστές της πλατφόρμας όσο και για τους χρήστες. Για παράδειγμα, το MinIO αντικαταστάθηκε με άμεση πρόσβαση στο Amazon S3, κάτι που μας φέρνει πιο κοντά στις αρχικές ροές εργασίας μας και μειώνει τον αριθμό των υπηρεσιών που πρέπει να διατηρήσουμε. Μπορούμε επίσης να χρησιμοποιήσουμε το Amazon RDS ως backend για το Kubeflow, το οποίο επιτρέπει ευκολότερες μετακινήσεις μεταξύ συμπλεγμάτων και μας δίνει τη δυνατότητα να δημιουργούμε αντίγραφα ασφαλείας των αγωγών μας κάθε βράδυ.

Βρήκαμε επίσης ωφέλιμες τις βελτιώσεις στην ενσωμάτωση του Kubeflow με τις διαχειριζόμενες υπηρεσίες AWS. Για παράδειγμα, με τα Amazon RDS, Amazon S3 και Amazon Cognito προρυθμισμένα στα μανιφέστα Kubeflow στο AWS, εξοικονομούμε χρόνο και προσπάθεια ενημέρωσης σε νεότερες διανομές του Kubeflow. Όταν συνηθίζαμε να τροποποιούμε τις επίσημες δηλώσεις Kubeflow με μη αυτόματο τρόπο, η ενημέρωση σε μια νέα έκδοση θα χρειαζόταν αρκετές εβδομάδες, από τη σχεδίαση έως τη δοκιμή.

Η μετάβαση στο Amazon EKS μας δίνει την ευκαιρία να ορίσουμε το cluster μας στο Kustomize (τώρα μέρος του Kubectl) και στο Terraform. Αποδεικνύεται ότι για εργασία σε πλατφόρμα, τα Kubernetes και Terraform είναι πολύ εύκολο να εργαστούν αφού αφιερώσετε αρκετό χρόνο για να μάθετε. Μετά από πολλές επαναλήψεις, τα εργαλεία που έχουμε στη διάθεσή μας καθιστούν πολύ εύκολη την εκτέλεση τυπικών λειτουργιών πλατφόρμας, όπως η αναβάθμιση ενός στοιχείου ή η εναλλαγή ενός ολόκληρου συμπλέγματος ανάπτυξης. Σε σύγκριση με την εκτέλεση εργασιών ακατέργαστων Amazon Elastic Compute Cloud Σε περιπτώσεις (Amazon EC2), είναι δύσκολο να συγκρίνουμε τι τεράστια διαφορά έχει να έχουμε καλά καθορισμένα pods με εγγυημένους μηχανισμούς εκκαθάρισης πόρων και επανάληψης ενσωματωμένων μηχανισμών.

Το Kubernetes παρέχει εξαιρετικά πρότυπα ασφαλείας και έχουμε γρατσουνίσει μόνο την επιφάνεια αυτού που μας επιτρέπει να κάνουμε η απομόνωση πολλών χρηστών. Βλέπουμε την απομόνωση πολλών χρηστών ως ένα μοτίβο που έχει μεγαλύτερη απόδοση στο μέλλον, όταν η πλατφόρμα εκπαίδευσης παράγει δεδομένα σε επίπεδο παραγωγής και προσελκύουμε προγραμματιστές εκτός της ομάδας μας.

Εν τω μεταξύ, το Kubeflow μας επιτρέπει να έχουμε αναπαραγώγιμη εκπαίδευση μοντέλων. Ακόμη και με τα ίδια δεδομένα, καμία εκπαίδευση δεν παράγει πανομοιότυπα μοντέλα, αλλά έχουμε το επόμενο καλύτερο πράγμα. Με το Kubeflow, γνωρίζουμε ακριβώς ποιος κώδικας και τα δεδομένα χρησιμοποιήθηκαν για την εκπαίδευση ενός μοντέλου. Η ενσωμάτωση έχει βελτιωθεί πολύ, επειδή κάθε βήμα στη διοχέτευσή μας ορίζεται σαφώς και μέσω προγραμματισμού. Όταν οι νέοι επιστήμονες δεδομένων έχουν το καθήκον να διορθώσουν ένα σφάλμα, χρειάζονται πολύ λιγότερο χειρισμό επειδή υπάρχει μια σαφής δομή για τον τρόπο χρήσης των εξόδων κώδικα μεταξύ των σταδίων.

Η χρήση του Kubeflow αποφέρει επίσης πολλές βελτιώσεις απόδοσης σε σύγκριση με την εκτέλεση σε μία μόνο παρουσία EC2. Συχνά στην εκπαίδευση μοντέλων, οι επιστήμονες δεδομένων χρειάζονται διαφορετικά εργαλεία και βελτιστοποιήσεις για προεπεξεργασία και εκπαίδευση. Για παράδειγμα, η προεπεξεργασία εκτελείται συχνά με χρήση κατανεμημένων εργαλείων επεξεργασίας δεδομένων, όπως το Spark, ενώ η εκπαίδευση εκτελείται συχνά με χρήση παρουσιών GPU. Με τους αγωγούς Kubeflow, μπορούν να καθορίσουν διαφορετικούς τύπους παρουσιών για διαφορετικά στάδια του αγωγού. Αυτό τους επιτρέπει να χρησιμοποιούν τις ισχυρές παρουσίες GPU σε ένα στάδιο και έναν στόλο μικρότερων μηχανημάτων για κατανεμημένη επεξεργασία σε ένα άλλο στάδιο. Επίσης, επειδή οι αγωγοί Kubeflow περιγράφουν τις εξαρτήσεις μεταξύ των σταδίων, οι αγωγοί μπορούν να εκτελούν στάδια παράλληλα.

Τέλος, επειδή δημιουργήσαμε μια διαδικασία για την προσθήκη ενοικιαστών στο σύμπλεγμα, υπάρχει πλέον ένας πιο επίσημος τρόπος εγγραφής ομάδων σε έναν μισθωτή στο σύμπλεγμα. Επειδή χρησιμοποιούμε το Kubecost για την παρακολούθηση του κόστους στο σύμπλεγμα EKS μας, μας επιτρέπει να αποδώσουμε κόστος σε ένα μεμονωμένο έργο αντί να αποδίδεται κόστος σε επίπεδο λογαριασμού, το οποίο περιλαμβάνει όλα τα έργα επιστήμης δεδομένων. Το Kubecost παρουσιάζει μια αναφορά των χρημάτων που δαπανήθηκαν ανά χώρο ονομάτων, η οποία είναι στενά συνδεδεμένη με τον μισθωτή ή την ομάδα που είναι υπεύθυνη για τη λειτουργία του αγωγού.

Παρά όλα τα πλεονεκτήματα, θα πρέπει να προσέχουμε να αναλαμβάνουμε αυτό το είδος μετεγκατάστασης μόνο εάν υπάρχει πλήρης αγορά εισόδου από τους χρήστες. Οι χρήστες που αφιερώνουν χρόνο έχουν πολλά οφέλη από τη χρήση του Amazon EKS και του Kubernetes, αλλά υπάρχει μια σημαντική καμπύλη μάθησης.

Συμπέρασμα

Με την εφαρμογή του αγωγού Kubeflow σε AWS στην υποδομή ML από άκρο σε άκρο, μπορέσαμε να ενοποιήσουμε και να τυποποιήσουμε τις ροές εργασιών επιστήμης δεδομένων, διατηρώντας παράλληλα τα βασικά εργαλεία μας (όπως CI/CD και εξυπηρέτηση μοντέλων). Οι επιστήμονες δεδομένων μας μπορούν πλέον να κινούνται μεταξύ έργων που βασίζονται σε αυτήν τη ροή εργασίας χωρίς να μάθουν πώς να διατηρούν ένα εντελώς διαφορετικό σύνολο εργαλείων. Για ορισμένα από τα μοντέλα μας, μας εξέπληξε ευχάριστα η ταχύτητα της νέας ροής εργασίας (πέντε φορές ταχύτερη), η οποία επέτρεψε περισσότερες επαναλήψεις εκπαίδευσης και κατά συνέπεια την παραγωγή μοντέλων με καλύτερες προβλέψεις.

Έχουμε επίσης δημιουργήσει μια σταθερή βάση για να αυξήσουμε τις δυνατότητές μας στα MLOps και να κλιμακώσουμε τον αριθμό και το μέγεθος των έργων μας. Για παράδειγμα, καθώς σκληρύνουμε τη στάση διακυβέρνησής μας στη γενεαλογία και την παρακολούθηση μοντέλων, μειώσαμε την εστίασή μας από περισσότερες από 15 ροές εργασίας σε μόνο μία. Και όταν η ευπάθεια Log4shell εμφανίστηκε στα τέλη του 2021, μπορέσαμε να επικεντρωθούμε σε μια ενιαία ροή εργασίας και να διορθώσουμε γρήγορα όπως απαιτείται (εκτέλεση Μητρώο εμπορευματοκιβωτίων Amazon Elastic (Amazon ECR) σαρώνει, αναβαθμίζει την υπηρεσία Amazon OpenSearch Service, ενημερώνει τα εργαλεία μας και πολλά άλλα) με ελάχιστο αντίκτυπο στη συνεχιζόμενη εργασία των επιστημόνων δεδομένων. Καθώς οι βελτιώσεις AWS και Kubeflow γίνονται διαθέσιμες, μπορούμε να τις ενσωματώσουμε όπως νομίζουμε.

Αυτό μας φέρνει σε μια σημαντική και υποτιμημένη πτυχή της υιοθέτησης του Kubeflow σχετικά με το AWS. Ένα από τα κρίσιμα αποτελέσματα αυτού του ταξιδιού είναι η δυνατότητα απρόσκοπτης διάθεσης αναβαθμίσεων και βελτιώσεων στο Kubeflow για τους επιστήμονες δεδομένων μας. Αν και συζητήσαμε την προσέγγισή μας σε αυτό νωρίτερα, βασιζόμαστε επίσης στις εκδηλώσεις Kubeflow που παρέχονται από το AWS. Ξεκινήσαμε το ταξίδι μας στο Kubeflow ως απόδειξη της ιδέας το 2019, πριν από την κυκλοφορία της έκδοσης 1.0.0. (Αυτή τη στιγμή βρισκόμαστε στην 1.4.1, αξιολογούμε την 1.5. Η AWS εργάζεται ήδη στην έκδοση 1.6.) Στα 3 χρόνια που μεσολάβησαν, υπήρξαν τουλάχιστον έξι εκδόσεις με σημαντικό περιεχόμενο. Μέσω της πειθαρχημένης προσέγγισής της για την ενσωμάτωση και την επικύρωση αυτών των αναβαθμίσεων και την κυκλοφορία των εκδηλώσεων σε ένα προβλέψιμο, αξιόπιστο χρονοδιάγραμμα, η ομάδα Kubeflow στο AWS ήταν ζωτικής σημασίας για να μπορέσει η ομάδα του athenahealth MLOps να σχεδιάσει τον οδικό χάρτη ανάπτυξης και, κατά συνέπεια, τις κατανομές πόρων και τους τομείς εστίασής μας , περαιτέρω στο μέλλον με μεγαλύτερη αυτοπεποίθηση.

Μπορείτε να ακολουθήσετε το Αποθετήριο AWS Labs GitHub για να παρακολουθείτε όλες τις συνεισφορές AWS στο Kubeflow. Μπορείτε επίσης να βρείτε ομάδες AWS στο Kubeflow #AWS Slack Channel; Τα σχόλιά σας εκεί βοηθούν το AWS να δώσει προτεραιότητα στις επόμενες δυνατότητες για να συνεισφέρει στο έργο Kubeflow.

---

Σχετικά με τους συγγραφείς

Kanwaljit Khurmi είναι Senior Solutions Architect στο Amazon Web Services. Συνεργάζεται με τους πελάτες του AWS για να παρέχει καθοδήγηση και τεχνική βοήθεια βοηθώντας τους να βελτιώσουν την αξία των λύσεών τους όταν χρησιμοποιούν το AWS. Η Kanwaljit ειδικεύεται στο να βοηθά τους πελάτες με εφαρμογές κοντέινερ και μηχανικής εκμάθησης.

Τάιλερ Κάλμπαχ είναι Κύριο Μέλος του Τεχνικού Προσωπικού στο athenahealth. Ο Tyler έχει περίπου 7 χρόνια εμπειρίας στο Analytics, στην Επιστήμη Δεδομένων, στα Νευρωνικά Δίκτυα και στην ανάπτυξη εφαρμογών Μηχανικής Μάθησης στον χώρο της Υγείας. Έχει συνεισφέρει σε πολλές λύσεις Machine Learning που εξυπηρετούν επί του παρόντος την κυκλοφορία παραγωγής. Επί του παρόντος εργάζεται ως Κύριος Επιστήμονας Δεδομένων στον Οργανισμό Μηχανικών του athenahealth, ο Tyler είναι μέρος της ομάδας που έχει δημιουργήσει τη νέα πλατφόρμα εκπαίδευσης μηχανικής μάθησης για το athenahealth από την αρχή αυτής της προσπάθειας.

Βίκτορ Κρίλοφ είναι Κύριο Μέλος του Τεχνικού Προσωπικού στο athenahealth. Ο Victor είναι μηχανικός και master scrum, βοηθώντας τους επιστήμονες δεδομένων να δημιουργήσουν ασφαλείς αγωγούς γρήγορης μηχανικής εκμάθησης. Στο athenahealth έχει εργαστεί σε διεπαφές, κλινικές παραγγελίες, συνταγές, προγραμματισμό, analytics και τώρα μηχανική μάθηση. Εκτιμά τον καθαρά γραμμένο και καλά ελεγμένο κώδικα, αλλά έχει μια ανθυγιεινή εμμονή με τους κωδικούς one-liners. Στον ελεύθερο χρόνο του απολαμβάνει να ακούει podcast ενώ κάνει βόλτα τον σκύλο του.

Σασάνκ Βεμούρι είναι Επικεφαλής Τεχνικού Προσωπικού στο athenahealth. Έχει εμπειρία στην ανάπτυξη λύσεων που βασίζονται σε δεδομένα σε τομείς όπως η υγειονομική περίθαλψη, η ασφάλιση και η βιοπληροφορική. Η Sasank εργάζεται επί του παρόντος με το σχεδιασμό και την ανάπτυξη πλατφορμών εκπαίδευσης μηχανικής μάθησης και συμπερασμάτων σε AWS και Kubernetes που βοηθούν στην εκπαίδευση και την ανάπτυξη λύσεων ML σε κλίμακα.

Anu Tumkur είναι Αρχιτέκτονας στο athenahealth. Η Anu έχει πάνω από δύο δεκαετίες αρχιτεκτονικής, σχεδίασης, εμπειρίας ανάπτυξης κατασκευής διαφόρων προϊόντων λογισμικού στη μηχανική εκμάθηση, λειτουργίες cloud, μεγάλα δεδομένα, αγωγούς κατανεμημένων δεδομένων σε πραγματικό χρόνο, τεχνολογία διαφημίσεων, ανάλυση δεδομένων, αναλύσεις μέσων κοινωνικής δικτύωσης. Η Anu εργάζεται επί του παρόντος ως αρχιτέκτονας στον οργανισμό Product Engineering του athenahealth στις ομάδες Machine Learning Platform και Data Pipeline.

Ουίλιαμ Τσεν είναι Ανώτερος Διευθυντής Μηχανικών στο athenahealth. Διαθέτει πάνω από 20 χρόνια ηγετικής εμπειρίας στον τομέα της μηχανικής στην κατασκευή λύσεων στον τομέα της υγειονομικής περίθαλψης, πληροφορικής κατανεμημένης μεγάλων δεδομένων, ευφυών οπτικών δικτύων, συστημάτων επεξεργασίας βίντεο σε πραγματικό χρόνο, εταιρικού λογισμικού και ομαδικής αναδοχής υγειονομικής περίθαλψης. Ο William ηγείται επί του παρόντος δύο φοβερών ομάδων στο athenahealth, τις μηχανικές ομάδες Machine Learning Operations και DevOps, στον οργανισμό Product Engineering.