Σημείωση. μετάφρ.: στις αρχές Αυγούστου, η Red Hat μίλησε δημόσια για την επίλυση προβλημάτων προσβασιμότητας που είχαν αντιμετωπίσει οι χρήστες της υπηρεσίας της τους προηγούμενους μήνες (Βασίζεται σε ένα μητρώο εικόνων κοντέινερ, το οποίο έλαβε η εταιρεία μαζί με την αγορά του CoreOS). Ανεξάρτητα από το ενδιαφέρον σας για αυτήν καθαυτή την υπηρεσία, η διαδρομή που ακολούθησαν οι μηχανικοί SRE της εταιρείας για τη διάγνωση και την εξάλειψη των αιτιών του ατυχήματος είναι διδακτική.
Στις 19 Μαΐου, νωρίς το πρωί (Ανατολική θερινή ώρα, EDT), η υπηρεσία quay.io συνετρίβη. Το ατύχημα επηρέασε τόσο τους καταναλωτές του quay.io όσο και τα έργα ανοιχτού κώδικα που χρησιμοποιούν το quay.io ως πλατφόρμα για την κατασκευή και τη διανομή λογισμικού. Η Red Hat εκτιμά την εμπιστοσύνη και των δύο.
Μια ομάδα μηχανικών SRE ενεπλάκη αμέσως και προσπάθησε να σταθεροποιήσει την υπηρεσία Quay το συντομότερο δυνατό. Ωστόσο, ενώ το έκαναν αυτό, οι πελάτες έχασαν την ικανότητα να προωθήσουν νέες εικόνες και μόνο περιστασιακά μπορούσαν να τραβήξουν τις υπάρχουσες. Για άγνωστο λόγο, η βάση δεδομένων quay.io αποκλείστηκε μετά την κλιμάκωση της υπηρεσίας σε πλήρη χωρητικότητα.
«Τι άλλαξε;" - αυτή είναι η πρώτη ερώτηση που γίνεται συνήθως σε τέτοιες περιπτώσεις. Παρατηρήσαμε ότι λίγο πριν από το ζήτημα, το OpenShift Dedicated cluster (το οποίο εκτελεί το quay.io) άρχισε να ενημερώνεται στην έκδοση 4.3.19. Δεδομένου ότι το quay.io εκτελείται σε Red Hat OpenShift Dedicated (OSD), οι τακτικές ενημερώσεις ήταν ρουτίνα και δεν προκάλεσαν ποτέ προβλήματα. Επιπλέον, κατά τους προηγούμενους έξι μήνες, έχουμε αναβαθμίσει τα Quay clusters αρκετές φορές χωρίς καμία διακοπή στην υπηρεσία.
Ενώ προσπαθούσαμε να επαναφέρουμε την υπηρεσία, άλλοι μηχανικοί άρχισαν να προετοιμάζουν ένα νέο σύμπλεγμα OSD με την προηγούμενη έκδοση του λογισμικού, ώστε αν συνέβαινε κάτι, να μπορούν να αναπτύξουν τα πάντα σε αυτό.
Ανάλυση των βαθύτερων αιτίων
Το κύριο σύμπτωμα της αποτυχίας ήταν μια χιονοστιβάδα δεκάδων χιλιάδων συνδέσεων βάσης δεδομένων, που κατέστησαν την παρουσία MySQL ουσιαστικά μη λειτουργική. Αυτό κατέστησε δύσκολη τη διάγνωση του προβλήματος. Έχουμε θέσει ένα όριο στον μέγιστο αριθμό συνδέσεων από πελάτες για να βοηθήσουμε την ομάδα SRE να αξιολογήσει το πρόβλημα. Δεν παρατηρήσαμε καμία ασυνήθιστη κίνηση στη βάση δεδομένων: στην πραγματικότητα, τα περισσότερα αιτήματα διαβάστηκαν και μόνο μερικά έγιναν εγγραφή.
Προσπαθήσαμε επίσης να εντοπίσουμε ένα μοτίβο στην κίνηση της βάσης δεδομένων που θα μπορούσε να προκαλέσει αυτή τη χιονοστιβάδα. Ωστόσο, δεν μπορέσαμε να βρούμε μοτίβα στα αρχεία καταγραφής. Ενώ περιμέναμε να είναι έτοιμο το νέο σύμπλεγμα με OSD 4.3.18, συνεχίσαμε να προσπαθούμε να λανσάρουμε quay.io pods. Κάθε φορά που το σύμπλεγμα έφτανε σε πλήρη χωρητικότητα, η βάση δεδομένων παγώνει. Αυτό σήμαινε ότι ήταν απαραίτητη η επανεκκίνηση της παρουσίας RDS εκτός από όλα τα pods quay.io.
Μέχρι το απόγευμα, σταθεροποιήσαμε την υπηρεσία σε λειτουργία μόνο για ανάγνωση και απενεργοποιήσαμε όσο το δυνατόν περισσότερες μη βασικές λειτουργίες (για παράδειγμα, συλλογή απορριμμάτων χώρου ονομάτων) για να μειώσουμε το φόρτο στη βάση δεδομένων. Τα παγώματα έχουν σταματήσει αλλά ο λόγος δεν βρέθηκε ποτέ. Το νέο σύμπλεγμα OSD ήταν έτοιμο και μεταφέραμε την υπηρεσία, συνδέσαμε την κυκλοφορία και συνεχίσαμε την παρακολούθηση.
Το Quay.io λειτούργησε σταθερά στο νέο σύμπλεγμα OSD, οπότε επιστρέψαμε στα αρχεία καταγραφής της βάσης δεδομένων, αλλά δεν μπορούσαμε να βρούμε έναν συσχετισμό που να εξηγεί τα μπλοκαρίσματα. Οι μηχανικοί του OpenShift συνεργάστηκαν μαζί μας για να καταλάβουμε εάν οι αλλαγές στο Red Hat OpenShift 4.3.19 θα μπορούσαν να προκαλέσουν προβλήματα με το Quay. Ωστόσο, δεν βρέθηκε τίποτα, και Δεν ήταν δυνατή η αναπαραγωγή του προβλήματος σε εργαστηριακές συνθήκες.
Δεύτερη αποτυχία
Στις 28 Μαΐου, λίγο πριν το μεσημέρι EDT, το quay.io κατέρρευσε ξανά με το ίδιο σύμπτωμα: η βάση δεδομένων ήταν αποκλεισμένη. Και πάλι ρίξαμε όλες μας τις δυνάμεις στην έρευνα. Πρώτα απ 'όλα, ήταν απαραίτητο να επαναφέρετε την υπηρεσία. Ωστόσο Αυτή τη φορά η επανεκκίνηση του RDS και η επανεκκίνηση των pods quay.io δεν οδήγησαν σε τίποτα: άλλη μια χιονοστιβάδα συνδέσεων έχει κατακλύσει τη βάση. Μα γιατί?
Το Quay είναι γραμμένο σε Python και κάθε pod λειτουργεί ως ένα ενιαίο μονολιθικό δοχείο. Ο χρόνος εκτέλεσης του κοντέινερ εκτελεί πολλές παράλληλες εργασίες ταυτόχρονα. Χρησιμοποιούμε τη βιβλιοθήκη gevent κάτω από gunicorn για την επεξεργασία αιτημάτων ιστού. Όταν ένα αίτημα έρχεται στο Quay (μέσω του δικού μας API ή μέσω του API Docker), του εκχωρείται ένας gevent worker. Συνήθως αυτός ο εργαζόμενος πρέπει να επικοινωνήσει με τη βάση δεδομένων. Μετά την πρώτη αποτυχία, ανακαλύψαμε ότι οι εργαζόμενοι του gevent συνδέονταν στη βάση δεδομένων χρησιμοποιώντας προεπιλεγμένες ρυθμίσεις.
Δεδομένου του σημαντικού αριθμού Quay pod και χιλιάδων εισερχόμενων αιτημάτων ανά δευτερόλεπτο, ένας μεγάλος αριθμός συνδέσεων βάσης δεδομένων θα μπορούσε θεωρητικά να κατακλύσει την παρουσία της MySQL. Χάρη στην παρακολούθηση, ήταν γνωστό ότι η Quay επεξεργάζεται κατά μέσο όρο 5 χιλιάδες αιτήματα ανά δευτερόλεπτο. Ο αριθμός των συνδέσεων στη βάση δεδομένων ήταν περίπου ο ίδιος. 5 χιλιάδες συνδέσεις ήταν πολύ εντός των δυνατοτήτων της παρουσίας μας RDS (κάτι που δεν μπορούμε να πούμε για δεκάδες χιλιάδες). Για κάποιο λόγο υπήρξαν απροσδόκητες αιχμές στον αριθμό των συνδέσεων, ωστόσο, δεν παρατηρήσαμε καμία συσχέτιση με εισερχόμενα αιτήματα.
Αυτή τη φορά ήμασταν αποφασισμένοι να βρούμε και να εξαλείψουμε την πηγή του προβλήματος και να μην περιοριστούμε σε μια επανεκκίνηση. Στη βάση κωδικών Quay έγιναν αλλαγές για να περιοριστεί ο αριθμός των συνδέσεων στη βάση δεδομένων για κάθε εργαζόμενο gevent. Αυτός ο αριθμός έγινε παράμετρος στη διαμόρφωση: κατέστη δυνατή η αλλαγή του εν κινήσει χωρίς τη δημιουργία μιας νέας εικόνας κοντέινερ. Για να μάθουμε πόσες συνδέσεις θα μπορούσαν να αντιμετωπιστούν ρεαλιστικά, εκτελέσαμε πολλές δοκιμές σε ένα περιβάλλον σταδίου, ορίζοντας διαφορετικές τιμές για να δούμε πώς αυτό θα επηρεάσει τα σενάρια δοκιμών φορτίου. Ως αποτέλεσμα, ανακαλύφθηκε ότι Το Quay αρχίζει να ρίχνει 502 σφάλματα όταν ο αριθμός των συνδέσεων ξεπεράσει τις 10 χιλιάδες.
Αναπτύξαμε αμέσως αυτήν τη νέα έκδοση στην παραγωγή και αρχίσαμε να παρακολουθούμε το πρόγραμμα σύνδεσης της βάσης δεδομένων. Στο παρελθόν, η βάση ήταν κλειδωμένη μετά από περίπου 20 λεπτά. Μετά από 30 λεπτά χωρίς προβλήματα είχαμε ελπίδα, και μια ώρα αργότερα είχαμε εμπιστοσύνη. Αποκαταστήσαμε την επισκεψιμότητα στον ιστότοπο και ξεκινήσαμε τη μεταθανάτια ανάλυση.
Έχοντας καταφέρει να παρακάμψει το πρόβλημα που οδηγεί σε αποκλεισμό, δεν μάθαμε τους πραγματικούς λόγους του. Επιβεβαιώθηκε ότι δεν σχετίζεται με καμία αλλαγή στο OpenShift 4.3.19, αφού το ίδιο συνέβη και στην έκδοση 4.3.18, η οποία παλαιότερα λειτουργούσε με το Quay χωρίς προβλήματα.
Σαφώς και κάτι άλλο κρυβόταν στο σύμπλεγμα.
Αναλυτική Μελέτη
Το Quay.io χρησιμοποίησε τις προεπιλεγμένες ρυθμίσεις για να συνδεθεί στη βάση δεδομένων για έξι χρόνια χωρίς κανένα πρόβλημα. Τι άλλαξε; Είναι σαφές ότι όλο αυτό το διάστημα η επισκεψιμότητα στο quay.io αυξάνεται σταθερά. Στην περίπτωσή μας, φαινόταν σαν να είχε επιτευχθεί κάποια τιμή κατωφλίου, η οποία χρησίμευσε ως έναυσμα για μια χιονοστιβάδα συνδέσεων. Συνεχίσαμε να μελετάμε τα αρχεία καταγραφής της βάσης δεδομένων μετά τη δεύτερη αποτυχία, αλλά δεν βρήκαμε μοτίβα ή προφανείς σχέσεις.
Εν τω μεταξύ, η ομάδα SRE εργάζεται για βελτιώσεις στην παρατηρησιμότητα των αιτημάτων του Quay και στη συνολική υγεία των υπηρεσιών. Έχουν αναπτυχθεί νέες μετρήσεις και πίνακες εργαλείων, δείχνοντας ποια μέρη του Quay έχουν τη μεγαλύτερη ζήτηση από τους πελάτες.
Το Quay.io λειτούργησε καλά μέχρι τις 9 Ιουνίου. Σήμερα το πρωί (EDT) είδαμε και πάλι σημαντική αύξηση στον αριθμό των συνδέσεων βάσεων δεδομένων. Αυτή τη φορά δεν υπήρχε χρόνος διακοπής, δεδομένου ότι η νέα παράμετρος περιόριζε τον αριθμό τους και δεν τους επέτρεπε να υπερβούν την απόδοση της MySQL. Ωστόσο, για περίπου μισή ώρα, πολλοί χρήστες σημείωσαν αργή απόδοση του quay.io. Συλλέξαμε γρήγορα όλα τα πιθανά δεδομένα χρησιμοποιώντας τα πρόσθετα εργαλεία παρακολούθησης. Ξαφνικά εμφανίστηκε ένα μοτίβο.
Λίγο πριν από την αύξηση των συνδέσεων, ένας μεγάλος αριθμός αιτημάτων υποβλήθηκε στο App Registry API. Το μητρώο εφαρμογών είναι μια ελάχιστα γνωστή δυνατότητα του quay.io. Σας επιτρέπει να αποθηκεύετε πράγματα όπως χάρτες Helm και δοχεία με πλούσια μεταδεδομένα. Οι περισσότεροι χρήστες του quay.io δεν λειτουργούν με αυτήν τη δυνατότητα, αλλά το Red Hat OpenShift το χρησιμοποιεί ενεργά. Το OperatorHub ως μέρος του OpenShift αποθηκεύει όλους τους χειριστές στο Μητρώο εφαρμογών. Αυτοί οι χειριστές αποτελούν τη βάση για το οικοσύστημα φόρτου εργασίας OpenShift και το μοντέλο λειτουργίας με επίκεντρο τους συνεργάτες (Λειτουργίες 2ης ημέρας).
Κάθε σύμπλεγμα OpenShift 4 χρησιμοποιεί τελεστές από το ενσωματωμένο OperatorHub για να δημοσιεύσει έναν κατάλογο τελεστών που είναι διαθέσιμοι για εγκατάσταση και να παρέχει ενημερώσεις σε αυτούς που είναι ήδη εγκατεστημένοι. Με την αυξανόμενη δημοτικότητα του OpenShift 4, ο αριθμός των συμπλεγμάτων σε αυτό σε όλο τον κόσμο έχει επίσης αυξηθεί. Κάθε ένα από αυτά τα συμπλέγματα κατεβάζει περιεχόμενο χειριστή για να εκτελέσει το ενσωματωμένο OperatorHub, χρησιμοποιώντας το Μητρώο εφαρμογών στο quay.io ως backend. Στην αναζήτησή μας για την πηγή του προβλήματος, παραλείψαμε το γεγονός ότι καθώς το OpenShift αυξανόταν σταδιακά σε δημοτικότητα, αυξήθηκε και το φόρτο σε μία από τις σπάνια χρησιμοποιούμενες συναρτήσεις quay.io..
Κάναμε κάποια ανάλυση της κυκλοφορίας αιτημάτων μητρώου εφαρμογών και ρίξαμε μια ματιά στον κωδικό μητρώου. Αμέσως αποκαλύφθηκαν ελλείψεις, λόγω των οποίων τα ερωτήματα στη βάση δεδομένων δεν διαμορφώθηκαν βέλτιστα. Όταν το φορτίο ήταν χαμηλό, δεν προκαλούσαν προβλήματα, αλλά όταν το φορτίο αυξανόταν, γίνονταν πηγή προβλημάτων. Το Μητρώο εφαρμογών αποδείχθηκε ότι είχε δύο προβληματικά τελικά σημεία που δεν ανταποκρίνονταν καλά στην αύξηση του φόρτου: το πρώτο παρείχε μια λίστα με όλα τα πακέτα στο χώρο αποθήκευσης, το δεύτερο επέστρεφε όλα τα blobs για το πακέτο.
Εξάλειψη αιτιών
Την επόμενη εβδομάδα δαπανήσαμε βελτιστοποιώντας τον κώδικα του ίδιου του Μητρώου Εφαρμογών και του περιβάλλοντος του. Σαφώς αναποτελεσματικά ερωτήματα SQL επεξεργάστηκαν ξανά και οι περιττές κλήσεις εντολών εξαλείφθηκαν tar (έτρεχε κάθε φορά που ανακτήθηκαν blobs), η προσωρινή αποθήκευση προστέθηκε όπου ήταν δυνατόν. Στη συνέχεια, πραγματοποιήσαμε εκτεταμένες δοκιμές απόδοσης και συγκρίναμε την ταχύτητα του Μητρώου εφαρμογών πριν και μετά τις αλλαγές.
Τα αιτήματα API που προηγουμένως χρειάζονταν έως και μισό λεπτό τώρα ολοκληρώνονται σε χιλιοστά του δευτερολέπτου. Την επόμενη εβδομάδα εφαρμόσαμε τις αλλαγές στην παραγωγή και από τότε το quay.io λειτουργεί σταθερά. Κατά τη διάρκεια αυτής της περιόδου, υπήρξαν πολλές απότομες αιχμές στην επισκεψιμότητα στο τελικό σημείο του Μητρώου εφαρμογών, αλλά οι βελτιώσεις που έγιναν απέτρεψαν τις διακοπές της βάσης δεδομένων.
Τι μάθαμε;
Είναι σαφές ότι οποιαδήποτε υπηρεσία προσπαθεί να αποφύγει το χρόνο διακοπής λειτουργίας. Στην περίπτωσή μας, πιστεύουμε ότι οι πρόσφατες διακοπές βοήθησαν στη βελτίωση του quay.io. Έχουμε μάθει μερικά βασικά μαθήματα που θα θέλαμε να μοιραστούμε:
- Τα δεδομένα σχετικά με το ποιος χρησιμοποιεί την υπηρεσία σας και πώς δεν είναι ποτέ περιττά. Επειδή το Quay «απλώς λειτούργησε», δεν χρειάστηκε ποτέ να αφιερώσουμε χρόνο για τη βελτιστοποίηση της κυκλοφορίας και τη διαχείριση του φορτίου. Όλα αυτά δημιούργησαν μια ψευδή αίσθηση ασφάλειας που η υπηρεσία μπορούσε να κλιμακωθεί επ' αόριστον.
- Όταν η υπηρεσία πέσει, Η επαναφορά και λειτουργία του είναι κορυφαία προτεραιότητα.. Επειδή το Quay συνέχισε να υποφέρει από μια κλειδωμένη βάση δεδομένων κατά την πρώτη διακοπή, οι τυπικές διαδικασίες μας δεν είχαν το επιδιωκόμενο αποτέλεσμα και δεν μπορέσαμε να επαναφέρουμε την υπηρεσία χρησιμοποιώντας αυτές. Αυτό οδήγησε σε μια κατάσταση όπου έπρεπε να δαπανηθεί χρόνος για την ανάλυση και τη συλλογή δεδομένων με την ελπίδα να βρεθεί η βασική αιτία - αντί να επικεντρωθούν όλες οι προσπάθειες στην αποκατάσταση της λειτουργικότητας.
- Αξιολογήστε τον αντίκτυπο κάθε δυνατότητας υπηρεσίας. Οι πελάτες σπάνια χρησιμοποιούσαν το Μητρώο εφαρμογών, επομένως δεν ήταν προτεραιότητα για την ομάδα μας. Όταν ορισμένες δυνατότητες προϊόντος χρησιμοποιούνται ελάχιστα, τα σφάλματα τους σπάνια εμφανίζονται και οι προγραμματιστές σταματούν να παρακολουθούν τον κώδικα. Είναι εύκολο να πέσουμε θύματα της λανθασμένης αντίληψης ότι έτσι θα έπρεπε να είναι - μέχρι που ξαφνικά αυτή η λειτουργία βρεθεί στο επίκεντρο ενός σημαντικού περιστατικού.
Ποιο είναι το επόμενο;
Η εργασία για τη διασφάλιση της σταθερότητας της υπηρεσίας δεν σταματά ποτέ και τη βελτιώνουμε συνεχώς. Καθώς ο όγκος της κίνησης συνεχίζει να αυξάνεται στο quay.io, αναγνωρίζουμε ότι έχουμε ευθύνη να κάνουμε ό,τι μπορούμε για να ανταποκριθούμε στην εμπιστοσύνη των πελατών μας. Ως εκ τούτου, επί του παρόντος εργαζόμαστε για τις ακόλουθες εργασίες:
- Αναπτύξτε αντίγραφα βάσης δεδομένων μόνο για ανάγνωση για να βοηθήσετε την υπηρεσία να χειριστεί την κατάλληλη κίνηση σε περίπτωση προβλημάτων με την κύρια παρουσία RDS.
- Ενημέρωση μιας παρουσίας RDS. Η ίδια η τρέχουσα έκδοση δεν είναι το πρόβλημα. Αντίθετα, θέλουμε απλώς να αφαιρέσουμε το ψευδές ίχνος (το οποίο ακολουθήσαμε κατά τη διάρκεια της αποτυχίας). Η διατήρηση του λογισμικού ενημερωμένο θα εξαλείψει έναν άλλο παράγοντα σε περίπτωση μελλοντικών διακοπών λειτουργίας.
- Πρόσθετη προσωρινή αποθήκευση σε ολόκληρο το σύμπλεγμα. Συνεχίζουμε να αναζητούμε περιοχές όπου η προσωρινή αποθήκευση μπορεί να μειώσει το φόρτο στη βάση δεδομένων.
- Προσθήκη τείχους προστασίας εφαρμογών ιστού (WAF) για να δείτε ποιος συνδέεται στο quay.io και γιατί.
- Ξεκινώντας με την επόμενη έκδοση, τα συμπλέγματα Red Hat OpenShift θα εγκαταλείψουν το Μητρώο εφαρμογών υπέρ των Καταλόγων χειριστή που βασίζονται σε εικόνες κοντέινερ που είναι διαθέσιμες στο quay.io.
- Μια μακροπρόθεσμη αντικατάσταση του Μητρώου εφαρμογών θα μπορούσε να είναι η υποστήριξη των προδιαγραφών τεχνουργημάτων Open Container Initiative (OCI). Αυτήν τη στιγμή εφαρμόζεται ως εγγενής λειτουργία Quay και θα είναι διαθέσιμη στους χρήστες όταν οριστικοποιηθεί η ίδια η προδιαγραφή.
Όλα τα παραπάνω αποτελούν μέρος της συνεχιζόμενης επένδυσης της Red Hat στο quay.io καθώς μεταβαίνουμε από μια μικρή ομάδα «στυλ startup» σε μια ώριμη πλατφόρμα που βασίζεται σε SRE. Γνωρίζουμε ότι πολλοί από τους πελάτες μας βασίζονται στο quay.io στην καθημερινή τους εργασία (συμπεριλαμβανομένης της Red Hat!) και προσπαθούμε να είμαστε όσο το δυνατόν πιο διαφανείς σχετικά με τις πρόσφατες διακοπές λειτουργίας και τις συνεχείς προσπάθειες βελτίωσης.
ΥΓ από τον μεταφραστή
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- «».
Πηγή: www.habr.com