Γεια σας, με λένε Evgeniy. Εργάζομαι στην υποδομή αναζήτησης Yandex.Market. Θέλω να πω στην κοινότητα του Habr για την εσωτερική κουζίνα της Αγοράς - και έχω πολλά να πω. Πρώτα απ 'όλα, πώς λειτουργεί η αναζήτηση Αγοράς, διαδικασίες και αρχιτεκτονική. Πώς αντιμετωπίζουμε καταστάσεις έκτακτης ανάγκης: τι συμβαίνει εάν ένας διακομιστής διακοπεί; Τι γίνεται αν υπάρχουν 100 τέτοιοι διακομιστές;
Θα μάθετε επίσης πώς εφαρμόζουμε νέες λειτουργίες σε μια δέσμη διακομιστών ταυτόχρονα. Και πώς δοκιμάζουμε σύνθετες υπηρεσίες απευθείας στην παραγωγή, χωρίς να προκαλείται καμία ταλαιπωρία στους χρήστες. Γενικά πώς λειτουργεί η αναζήτηση Market για να περνάνε όλοι καλά.
Λίγα λόγια για εμάς: τι πρόβλημα λύνουμε
Όταν εισάγετε κείμενο, αναζητάτε ένα προϊόν με παραμέτρους ή συγκρίνετε τιμές σε διαφορετικά καταστήματα, όλα τα αιτήματα αποστέλλονται στην υπηρεσία αναζήτησης. Η αναζήτηση είναι η μεγαλύτερη υπηρεσία στην αγορά.
Επεξεργαζόμαστε όλα τα αιτήματα αναζήτησης: από τους ιστότοπους market.yandex.ru, beru.ru, την υπηρεσία Supercheck, Yandex.Advisor, εφαρμογές για κινητά. Περιλαμβάνουμε επίσης προσφορές προϊόντων στα αποτελέσματα αναζήτησης στο yandex.ru.
Με τον όρο υπηρεσία αναζήτησης εννοώ όχι μόνο την ίδια την αναζήτηση, αλλά και μια βάση δεδομένων με όλες τις προσφορές στην Αγορά. Η κλίμακα είναι η εξής: περισσότερα από ένα δισεκατομμύριο αιτήματα αναζήτησης υποβάλλονται σε επεξεργασία την ημέρα. Και όλα πρέπει να λειτουργούν γρήγορα, χωρίς διακοπές και να παράγουν πάντα το επιθυμητό αποτέλεσμα.
Τι είναι τι: Αρχιτεκτονική της αγοράς
Θα περιγράψω εν συντομία την τρέχουσα αρχιτεκτονική της Αγοράς. Μπορεί να περιγραφεί χονδρικά από το παρακάτω διάγραμμα:
Ας πούμε ότι μας έρχεται συνεργαζόμενο κατάστημα. Λέει ότι θέλω να πουλήσω ένα παιχνίδι: αυτή την κακιά γάτα με ένα τσιράκι. Και άλλη μια θυμωμένη γάτα χωρίς τσιράκι. Και μόνο μια γάτα. Στη συνέχεια, το κατάστημα πρέπει να ετοιμάσει προσφορές για τις οποίες αναζητά η Αγορά. Το κατάστημα δημιουργεί ένα ειδικό xml με προσφορές και επικοινωνεί τη διαδρομή προς αυτό το xml μέσω της διεπαφής συνεργατών. Στη συνέχεια, το ευρετήριο κατεβάζει περιοδικά αυτό το xml, ελέγχει για σφάλματα και αποθηκεύει όλες τις πληροφορίες σε μια τεράστια βάση δεδομένων.
Υπάρχουν πολλά τέτοια αποθηκευμένα xml. Ένα ευρετήριο αναζήτησης δημιουργείται από αυτήν τη βάση δεδομένων. Το ευρετήριο αποθηκεύεται σε εσωτερική μορφή. Μετά τη δημιουργία του ευρετηρίου, η υπηρεσία Layout το ανεβάζει σε διακομιστές αναζήτησης.
Ως αποτέλεσμα, μια θυμωμένη γάτα με ένα τρίξιμο εμφανίζεται στη βάση δεδομένων και το ευρετήριο της γάτας εμφανίζεται στον διακομιστή.
Θα σας πω πώς αναζητούμε μια γάτα στο μέρος για την αρχιτεκτονική αναζήτησης.
Αρχιτεκτονική αναζήτησης αγοράς
Ζούμε σε έναν κόσμο μικροϋπηρεσιών: κάθε εισερχόμενο αίτημα προκαλεί πολλά υποερωτήματα και δεκάδες υπηρεσίες εμπλέκονται στην επεξεργασία τους. Το διάγραμμα δείχνει μόνο μερικά:
Απλοποιημένο σύστημα επεξεργασίας αιτημάτων
Κάθε υπηρεσία έχει ένα υπέροχο πράγμα - το δικό της εξισορροπητή με ένα μοναδικό όνομα:
Ο εξισορροπητής μας παρέχει μεγαλύτερη ευελιξία στη διαχείριση της υπηρεσίας: μπορείτε, για παράδειγμα, να απενεργοποιήσετε τους διακομιστές, κάτι που απαιτείται συχνά για ενημερώσεις. Ο εξισορροπητής βλέπει ότι ο διακομιστής δεν είναι διαθέσιμος και ανακατευθύνει αυτόματα τα αιτήματα σε άλλους διακομιστές ή κέντρα δεδομένων. Κατά την προσθήκη ή την αφαίρεση ενός διακομιστή, το φορτίο ανακατανέμεται αυτόματα μεταξύ των διακομιστών.
Το μοναδικό όνομα του εξισορροπητή δεν εξαρτάται από το κέντρο δεδομένων. Όταν η υπηρεσία Α υποβάλλει αίτημα στον Β, τότε από προεπιλογή ο εξισορροπητής Β ανακατευθύνει το αίτημα στο τρέχον κέντρο δεδομένων. Εάν η υπηρεσία δεν είναι διαθέσιμη ή δεν υπάρχει στο τρέχον κέντρο δεδομένων, τότε το αίτημα ανακατευθύνεται σε άλλα κέντρα δεδομένων.
Ένα ενιαίο FQDN για όλα τα κέντρα δεδομένων επιτρέπει στην υπηρεσία Α να αφαιρεί πλήρως τις τοποθεσίες. Το αίτημά του για την υπηρεσία Β θα γίνεται πάντα αντικείμενο επεξεργασίας. Η εξαίρεση είναι η περίπτωση που η υπηρεσία βρίσκεται σε όλα τα κέντρα δεδομένων.
Αλλά δεν είναι όλα τόσο ρόδινα με αυτόν τον εξισορροπητή: έχουμε ένα πρόσθετο ενδιάμεσο στοιχείο. Ο εξισορροπητής ενδέχεται να είναι ασταθής και αυτό το πρόβλημα επιλύεται από πλεονάζοντες διακομιστές. Υπάρχει επίσης μια επιπλέον καθυστέρηση μεταξύ των υπηρεσιών Α και Β. Αλλά στην πράξη είναι μικρότερη από 1 ms και για τις περισσότερες υπηρεσίες αυτό δεν είναι κρίσιμο.
Αντιμετώπιση του απροσδόκητου: Εξισορρόπηση και ανθεκτικότητα υπηρεσίας αναζήτησης
Φανταστείτε ότι υπάρχει μια κατάρρευση: πρέπει να βρείτε μια γάτα με ένα squeaker, αλλά ο διακομιστής κολλάει. Ή 100 διακομιστές. Πώς να βγείτε έξω; Θα αφήσουμε πραγματικά τον χρήστη χωρίς γάτα;
Η κατάσταση είναι τρομακτική, αλλά είμαστε έτοιμοι για αυτό. Θα σου πω με τη σειρά.
Η υποδομή αναζήτησης βρίσκεται σε πολλά κέντρα δεδομένων:
Κατά το σχεδιασμό, περιλαμβάνουμε τη δυνατότητα τερματισμού λειτουργίας ενός κέντρου δεδομένων. Η ζωή είναι γεμάτη εκπλήξεις - για παράδειγμα, ένας εκσκαφέας μπορεί να κόψει ένα υπόγειο καλώδιο (ναι, αυτό συνέβη). Η χωρητικότητα στα υπόλοιπα κέντρα δεδομένων θα πρέπει να είναι επαρκής για να αντέχει το φορτίο αιχμής.
Ας εξετάσουμε ένα ενιαίο κέντρο δεδομένων. Κάθε κέντρο δεδομένων έχει το ίδιο σχήμα λειτουργίας εξισορροπητή:
Ένας εξισορροπητής είναι τουλάχιστον τρεις φυσικοί διακομιστές. Αυτός ο πλεονασμός γίνεται για αξιοπιστία. Οι ισορροπιστές λειτουργούν στο HAProx.
Επιλέξαμε το HAProx λόγω της υψηλής απόδοσης, των χαμηλών απαιτήσεων πόρων και της ευρείας λειτουργικότητας. Το λογισμικό αναζήτησής μας εκτελείται μέσα σε κάθε διακομιστή.
Η πιθανότητα αποτυχίας ενός διακομιστή είναι χαμηλή. Αλλά αν έχετε πολλούς διακομιστές, η πιθανότητα τουλάχιστον ένας να μειωθεί αυξάνεται.
Αυτό συμβαίνει στην πραγματικότητα: οι διακομιστές καταρρέουν. Επομένως, είναι απαραίτητο να παρακολουθείτε συνεχώς την κατάσταση όλων των διακομιστών. Εάν ο διακομιστής σταματήσει να ανταποκρίνεται, αποσυνδέεται αυτόματα από την κυκλοφορία. Για το σκοπό αυτό, το HAProxy διαθέτει ενσωματωμένο έλεγχο υγείας. Πηγαίνει σε όλους τους διακομιστές μία φορά το δευτερόλεπτο με ένα αίτημα HTTP "/ping".
Μια άλλη δυνατότητα του HAProxy: ο έλεγχος πράκτορα σάς επιτρέπει να φορτώνετε όλους τους διακομιστές ομοιόμορφα. Για να γίνει αυτό, το HAProxy συνδέεται με όλους τους διακομιστές και επιστρέφουν το βάρος τους ανάλογα με το τρέχον φορτίο από 1 έως 100. Το βάρος υπολογίζεται με βάση τον αριθμό των αιτημάτων στην ουρά για επεξεργασία και το φορτίο στον επεξεργαστή.
Τώρα για την εύρεση της γάτας. Η αναζήτηση καταλήγει σε αιτήματα όπως: /search?text=angry+cat. Για να είναι γρήγορη η αναζήτηση, ολόκληρο το ευρετήριο της γάτας πρέπει να ταιριάζει στη μνήμη RAM. Ακόμη και η ανάγνωση από το SSD δεν είναι αρκετά γρήγορη.
Μια φορά κι έναν καιρό, η βάση δεδομένων προσφορών ήταν μικρή και η μνήμη RAM ενός διακομιστή ήταν αρκετή για αυτήν. Καθώς η βάση προσφορών μεγάλωνε, τα πάντα δεν χωρούσαν πλέον σε αυτήν τη μνήμη RAM και τα δεδομένα χωρίστηκαν σε δύο μέρη: το θραύσμα 1 και το θραύσμα 2.
Αλλά αυτό συμβαίνει πάντα: οποιαδήποτε λύση, ακόμη και καλή, γεννά άλλα προβλήματα.
Ο εξισορροπητής πήγε ακόμα σε οποιονδήποτε διακομιστή. Αλλά στο μηχάνημα όπου ήρθε το αίτημα, υπήρχε μόνο το μισό του ευρετηρίου. Τα υπόλοιπα ήταν σε άλλους διακομιστές. Επομένως, ο διακομιστής έπρεπε να πάει σε κάποιο γειτονικό μηχάνημα. Μετά τη λήψη δεδομένων και από τους δύο διακομιστές, τα αποτελέσματα συνδυάστηκαν και ανακατατάχθηκαν.
Δεδομένου ότι ο εξισορροπητής κατανέμει ομοιόμορφα τα αιτήματα, όλοι οι διακομιστές ασχολήθηκαν με την ανακατάταξη και όχι απλώς την αποστολή δεδομένων.
Το πρόβλημα προέκυψε εάν ένας γειτονικός διακομιστής δεν ήταν διαθέσιμος. Η λύση ήταν να καθοριστούν αρκετοί διακομιστές με διαφορετικές προτεραιότητες ως «γειτονικός» διακομιστής. Αρχικά, το αίτημα στάλθηκε στους διακομιστές στο τρέχον rack. Εάν δεν υπήρχε απάντηση, το αίτημα στάλθηκε σε όλους τους διακομιστές σε αυτό το κέντρο δεδομένων. Και τέλος, το αίτημα πήγε σε άλλα κέντρα δεδομένων.
Καθώς ο αριθμός των προτάσεων αυξανόταν, τα δεδομένα χωρίστηκαν σε τέσσερα μέρη. Αλλά αυτό δεν ήταν το όριο.
Επί του παρόντος, χρησιμοποιείται μια διαμόρφωση οκτώ θραυσμάτων. Επιπλέον, για να εξοικονομηθεί ακόμη περισσότερη μνήμη, το ευρετήριο χωρίστηκε σε ένα τμήμα αναζήτησης (το οποίο χρησιμοποιείται για την αναζήτηση) και ένα τμήμα αποσπάσματος (το οποίο δεν εμπλέκεται στην αναζήτηση).
Ένας διακομιστής περιέχει πληροφορίες μόνο για ένα θραύσμα. Επομένως, για να κάνετε αναζήτηση στο πλήρες ευρετήριο, πρέπει να κάνετε αναζήτηση σε οκτώ διακομιστές που περιέχουν διαφορετικά θραύσματα.
Οι διακομιστές ομαδοποιούνται σε συμπλέγματα. Κάθε σύμπλεγμα περιέχει οκτώ μηχανές αναζήτησης και έναν διακομιστή αποσπασμάτων.
Ο διακομιστής αποσπάσματος εκτελεί μια βάση δεδομένων κλειδιού-τιμής με στατικά δεδομένα. Χρειάζονται για την έκδοση εγγράφων, για παράδειγμα, μια περιγραφή μιας γάτας με ένα τρίξιμο. Τα δεδομένα μεταφέρονται ειδικά σε ξεχωριστό διακομιστή ώστε να μην φορτώνεται η μνήμη των διακομιστών αναζήτησης.
Δεδομένου ότι τα αναγνωριστικά εγγράφων είναι μοναδικά μόνο σε ένα ευρετήριο, θα μπορούσε να προκύψει μια κατάσταση όπου δεν υπάρχουν έγγραφα στα αποσπάσματα. Λοιπόν, ή ότι για μια ταυτότητα θα υπάρχει διαφορετικό περιεχόμενο. Επομένως, για να λειτουργήσει η αναζήτηση και να επιστραφούν τα αποτελέσματα, χρειαζόταν συνέπεια σε ολόκληρο το σύμπλεγμα. Θα σας πω παρακάτω πώς παρακολουθούμε τη συνέπεια.
Η ίδια η αναζήτηση είναι δομημένη ως εξής: ένα αίτημα αναζήτησης μπορεί να έρθει σε οποιονδήποτε από τους οκτώ διακομιστές. Ας υποθέσουμε ότι ήρθε στον διακομιστή 1. Αυτός ο διακομιστής επεξεργάζεται όλα τα επιχειρήματα και κατανοεί τι και πώς να αναζητήσει. Ανάλογα με το εισερχόμενο αίτημα, ο διακομιστής μπορεί να υποβάλει πρόσθετα αιτήματα σε εξωτερικές υπηρεσίες για τις απαραίτητες πληροφορίες. Ένα αίτημα μπορεί να ακολουθηθεί από έως και δέκα αιτήματα προς εξωτερικές υπηρεσίες.
Μετά τη συλλογή των απαραίτητων πληροφοριών, ξεκινά μια αναζήτηση στη βάση δεδομένων προσφορών. Για να γίνει αυτό, γίνονται υποερωτήματα και στους οκτώ διακομιστές του συμπλέγματος.
Μόλις ληφθούν οι απαντήσεις, τα αποτελέσματα συνδυάζονται. Στο τέλος, ενδέχεται να χρειαστούν πολλά ακόμη δευτερεύοντα ερωτήματα στον διακομιστή αποσπασμάτων για τη δημιουργία των αποτελεσμάτων.
Τα ερωτήματα αναζήτησης μέσα στο σύμπλεγμα μοιάζουν με: /shard1?text=anry+cat. Επιπλέον, υποερωτήματα της φόρμας γίνονται συνεχώς μεταξύ όλων των διακομιστών εντός του συμπλέγματος μία φορά το δευτερόλεπτο: /κατάσταση.
Αίτηση /κατάσταση ανιχνεύει μια κατάσταση όπου ο διακομιστής δεν είναι διαθέσιμος.
Ελέγχει επίσης ότι η έκδοση της μηχανής αναζήτησης και η έκδοση ευρετηρίου είναι ίδιες σε όλους τους διακομιστές, διαφορετικά θα υπάρχουν ασυνεπή δεδομένα εντός του συμπλέγματος.
Παρά το γεγονός ότι ένας διακομιστής αποσπάσματος επεξεργάζεται αιτήματα από οκτώ μηχανές αναζήτησης, ο επεξεργαστής του είναι πολύ ελαφρά φορτωμένος. Επομένως, μεταφέρουμε τώρα τα δεδομένα του αποσπάσματος σε ξεχωριστή υπηρεσία.
Για τη μεταφορά δεδομένων, εισαγάγαμε γενικά κλειδιά για έγγραφα. Τώρα είναι αδύνατο για μια κατάσταση όπου το περιεχόμενο από άλλο έγγραφο επιστρέφεται χρησιμοποιώντας ένα κλειδί.
Αλλά η μετάβαση σε μια άλλη αρχιτεκτονική δεν έχει ολοκληρωθεί ακόμα. Τώρα θέλουμε να απαλλαγούμε από τον αποκλειστικό διακομιστή αποσπασμάτων. Και μετά απομακρυνθείτε εντελώς από τη δομή του συμπλέγματος. Αυτό θα μας επιτρέψει να συνεχίσουμε να κλιμακώνουμε εύκολα. Ένα επιπλέον μπόνους είναι η σημαντική εξοικονόμηση σιδήρου.
Και τώρα στις τρομακτικές ιστορίες με αίσιο τέλος. Ας εξετάσουμε αρκετές περιπτώσεις μη διαθεσιμότητας διακομιστή.
Συνέβη κάτι τρομερό: ένας διακομιστής δεν είναι διαθέσιμος
Ας υποθέσουμε ότι ένας διακομιστής δεν είναι διαθέσιμος. Στη συνέχεια, οι υπόλοιποι διακομιστές στο σύμπλεγμα μπορούν να συνεχίσουν να ανταποκρίνονται, αλλά τα αποτελέσματα αναζήτησης θα είναι ελλιπή.
Μέσω ελέγχου κατάστασης /κατάσταση Οι γειτονικοί διακομιστές κατανοούν ότι ένας δεν είναι διαθέσιμος. Επομένως, για να διατηρηθεί η πληρότητα, όλοι οι διακομιστές στο σύμπλεγμα ανά αίτημα /ping αρχίζουν να απαντούν στον εξισορροπητή ότι δεν είναι επίσης διαθέσιμοι. Αποδεικνύεται ότι όλοι οι διακομιστές στο σύμπλεγμα πέθαναν (κάτι που δεν είναι αλήθεια). Αυτό είναι το κύριο μειονέκτημα του σχήματος συμπλεγμάτων μας - γι' αυτό θέλουμε να ξεφύγουμε από αυτό.
Τα αιτήματα που αποτυγχάνουν με σφάλμα αποστέλλονται εκ νέου από τον εξισορροπητή σε άλλους διακομιστές.
Ο εξισορροπητής σταματά επίσης να στέλνει την κίνηση χρηστών σε νεκρούς διακομιστές, αλλά συνεχίζει να ελέγχει την κατάστασή τους.
Όταν ο διακομιστής γίνει διαθέσιμος, αρχίζει να ανταποκρίνεται /ping. Μόλις αρχίσουν να φτάνουν οι κανονικές αποκρίσεις σε ping από νεκρούς διακομιστές, οι εξισορροπητές αρχίζουν να στέλνουν εκεί την κίνηση των χρηστών. Η λειτουργία του συμπλέγματος αποκαταστάθηκε, γρήγορα.
Ακόμη χειρότερα: πολλοί διακομιστές δεν είναι διαθέσιμοι
Ένα σημαντικό μέρος των διακομιστών στο κέντρο δεδομένων έχει κοπεί. Τι να κάνετε, πού να τρέξετε; Ο εξισορροπητής έρχεται και πάλι στη διάσωση. Κάθε εξισορροπητής αποθηκεύει συνεχώς στη μνήμη τον τρέχοντα αριθμό ζωντανών διακομιστών. Υπολογίζει συνεχώς τη μέγιστη επισκεψιμότητα που μπορεί να επεξεργαστεί το τρέχον κέντρο δεδομένων.
Όταν πολλοί διακομιστές σε ένα κέντρο δεδομένων πέφτουν, ο εξισορροπητής συνειδητοποιεί ότι αυτό το κέντρο δεδομένων δεν μπορεί να επεξεργαστεί όλη την κίνηση.
Στη συνέχεια, η επιπλέον κίνηση αρχίζει να κατανέμεται τυχαία σε άλλα κέντρα δεδομένων. Όλα λειτουργούν, όλοι είναι ευχαριστημένοι.
Πώς το κάνουμε: δημοσίευση εκδόσεων
Τώρα ας μιλήσουμε για το πώς δημοσιεύουμε τις αλλαγές που έγιναν στην υπηρεσία. Εδώ έχουμε πάρει τον δρόμο της απλοποίησης των διαδικασιών: η κυκλοφορία μιας νέας έκδοσης είναι σχεδόν πλήρως αυτοματοποιημένη.
Όταν συγκεντρωθεί ένας ορισμένος αριθμός αλλαγών στο έργο, δημιουργείται αυτόματα μια νέα έκδοση και ξεκινά η κατασκευή της.
Στη συνέχεια, η υπηρεσία περνά σε δοκιμή, όπου ελέγχεται η σταθερότητα λειτουργίας.
Ταυτόχρονα, ξεκινά η αυτόματη δοκιμή απόδοσης. Αυτό το χειρίζεται ειδική υπηρεσία. Δεν θα μιλήσω για αυτό τώρα - η περιγραφή του αξίζει ξεχωριστό άρθρο.
Εάν η δημοσίευση στη δοκιμή είναι επιτυχής, η δημοσίευση της έκδοσης σε προσταθή ξεκινά αυτόματα. Το Prestable είναι ένα ειδικό σύμπλεγμα όπου κατευθύνεται η κανονική κίνηση χρηστών. Εάν εμφανίσει ένα σφάλμα, ο εξισορροπητής υποβάλλει εκ νέου αίτημα στην παραγωγή.
Στο prestable, οι χρόνοι απόκρισης μετρώνται και συγκρίνονται με την προηγούμενη έκδοση στην παραγωγή. Εάν όλα είναι καλά, τότε ένα άτομο συνδέεται: ελέγχει τα γραφήματα και τα αποτελέσματα των δοκιμών φορτίου και, στη συνέχεια, αρχίζει να κυκλοφορεί στην παραγωγή.
Ό,τι καλύτερο πηγαίνει στον χρήστη: Δοκιμή A/B
Δεν είναι πάντα προφανές εάν οι αλλαγές σε μια υπηρεσία θα αποφέρουν πραγματικά οφέλη. Για να μετρήσουν τη χρησιμότητα των αλλαγών, οι άνθρωποι κατέληξαν σε δοκιμές A/B. Θα σας πω λίγα λόγια για το πώς λειτουργεί στην αναζήτηση Yandex.Market.
Όλα ξεκινούν με την προσθήκη μιας νέας παραμέτρου CGI που επιτρέπει τη νέα λειτουργικότητα. Έστω η παράμετρός μας: market_new_functionality=1. Στη συνέχεια, στον κώδικα ενεργοποιούμε αυτήν τη λειτουργία εάν υπάρχει η σημαία:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Νέα λειτουργικότητα έρχεται στην παραγωγή.
Για την αυτοματοποίηση των δοκιμών A/B, υπάρχει μια ειδική υπηρεσία που δίνει λεπτομέρειες . Δημιουργείται ένα πείραμα στην υπηρεσία. Το μερίδιο επισκεψιμότητας ορίζεται, για παράδειγμα, 15%. Τα ποσοστά ορίζονται όχι για ερωτήματα, αλλά για χρήστες. Η διάρκεια του πειράματος υποδεικνύεται επίσης, για παράδειγμα, μια εβδομάδα.
Μπορούν να εκτελεστούν πολλά πειράματα ταυτόχρονα. Στις ρυθμίσεις μπορείτε να καθορίσετε εάν είναι δυνατή η διασταύρωση με άλλα πειράματα.
Ως αποτέλεσμα, η υπηρεσία προσθέτει αυτόματα ένα όρισμα market_new_functionality=1 στο 15% των χρηστών. Υπολογίζει επίσης αυτόματα τις επιλεγμένες μετρήσεις. Αφού ολοκληρωθεί το πείραμα, οι αναλυτές εξετάζουν τα αποτελέσματα και εξάγουν συμπεράσματα. Με βάση τα ευρήματα, λαμβάνεται η απόφαση να επεκταθεί στην παραγωγή ή τη βελτίωση.
Επιδέξιο χέρι της αγοράς: δοκιμές στην παραγωγή
Συμβαίνει συχνά να χρειάζεται να δοκιμάσετε τη λειτουργία μιας νέας λειτουργικότητας στην παραγωγή, αλλά δεν είστε σίγουροι πώς θα συμπεριφερθεί σε συνθήκες «μάχης» υπό βαρύ φορτίο.
Υπάρχει μια λύση: οι σημαίες στις παραμέτρους CGI μπορούν να χρησιμοποιηθούν όχι μόνο για δοκιμές A/B, αλλά και για δοκιμή νέων λειτουργιών.
Κατασκευάσαμε ένα εργαλείο που σας επιτρέπει να αλλάζετε άμεσα τη διαμόρφωση σε χιλιάδες διακομιστές χωρίς να εκτίθεται η υπηρεσία σε κινδύνους. Λέγεται Stop Tap. Η αρχική ιδέα ήταν να είναι δυνατή η γρήγορη απενεργοποίηση ορισμένων λειτουργιών χωρίς διάταξη. Στη συνέχεια το εργαλείο επεκτάθηκε και έγινε πιο περίπλοκο.
Το διάγραμμα ροής υπηρεσιών παρουσιάζεται παρακάτω:
Οι τιμές σημαίας ορίζονται μέσω του API. Η υπηρεσία διαχείρισης αποθηκεύει αυτές τις τιμές στη βάση δεδομένων. Όλοι οι διακομιστές πηγαίνουν στη βάση δεδομένων μία φορά κάθε δέκα δευτερόλεπτα, αντλούν τιμές σημαίας και εφαρμόζουν αυτές τις τιμές σε κάθε αίτημα.
Στο πάτημα Stop μπορείτε να ορίσετε δύο τύπους τιμών:
1) Εκφράσεις υπό όρους. Εφαρμόστε όταν μία από τις τιμές είναι αληθής. Για παράδειγμα:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Η τιμή "3" θα εφαρμοστεί κατά την επεξεργασία του αιτήματος στην τοποθεσία DC1. Και η τιμή είναι "4" όταν το αίτημα υποβάλλεται σε επεξεργασία στο δεύτερο σύμπλεγμα για τον ιστότοπο beru.ru.
2) Τιμές χωρίς όρους. Εφαρμογή από προεπιλογή εάν δεν πληρούται καμία από τις προϋποθέσεις. Για παράδειγμα:
αξία, αξία!
Εάν μια τιμή τελειώνει με θαυμαστικό, της δίνεται μεγαλύτερη προτεραιότητα.
Ο αναλυτής παραμέτρων CGI αναλύει τη διεύθυνση URL. Στη συνέχεια, εφαρμόζονται οι τιμές από το Stop Tap.
Εφαρμόζονται αξίες με τις ακόλουθες προτεραιότητες:
- Με αυξημένη προτεραιότητα από το Stop Tap (θαυμαστικό).
- Η τιμή από το αίτημα.
- Προεπιλεγμένη τιμή από το Stop tap.
- Προεπιλεγμένη τιμή στον κώδικα.
Υπάρχουν πολλές σημαίες που υποδεικνύονται σε τιμές υπό όρους - είναι αρκετές για όλα τα γνωστά σενάρια:
- Κέντρο δεδομένων.
- Περιβάλλον: παραγωγή, δοκιμή, σκιά.
- Τόπος διεξαγωγής: αγορά, beru.
- Αριθμός συμπλέγματος.
Με αυτό το εργαλείο, μπορείτε να ενεργοποιήσετε νέες λειτουργίες σε μια συγκεκριμένη ομάδα διακομιστών (για παράδειγμα, σε ένα μόνο κέντρο δεδομένων) και να ελέγξετε τη λειτουργία αυτής της λειτουργικότητας χωρίς ιδιαίτερο κίνδυνο για ολόκληρη την υπηρεσία. Ακόμα κι αν κάνατε ένα σοβαρό λάθος κάπου, όλα άρχισαν να πέφτουν και ολόκληρο το κέντρο δεδομένων κατέρρευσε, οι εξισορροπητές θα ανακατευθύνουν αιτήματα σε άλλα κέντρα δεδομένων. Οι τελικοί χρήστες δεν θα παρατηρήσουν τίποτα.
Εάν παρατηρήσετε κάποιο πρόβλημα, μπορείτε να επιστρέψετε αμέσως τη σημαία στην προηγούμενη τιμή και οι αλλαγές θα επαναφερθούν.
Αυτή η υπηρεσία έχει επίσης τα μειονεκτήματά της: οι προγραμματιστές την αγαπούν πολύ και συχνά προσπαθούν να προωθήσουν όλες τις αλλαγές στο Stop Tap. Προσπαθούμε να καταπολεμήσουμε την κατάχρηση.
Η προσέγγιση Stop Tap λειτουργεί καλά όταν έχετε ήδη σταθερό κώδικα έτοιμο να κυκλοφορήσει στην παραγωγή. Ταυτόχρονα, εξακολουθείτε να έχετε αμφιβολίες και θέλετε να ελέγξετε τον κωδικό σε συνθήκες «μάχης».
Ωστόσο, το Stop Tap δεν είναι κατάλληλο για δοκιμή κατά την ανάπτυξη. Υπάρχει ένα ξεχωριστό σύμπλεγμα για προγραμματιστές που ονομάζεται "σκιερό σύμπλεγμα".
Secret Testing: Shadow Cluster
Τα αιτήματα από ένα από τα συμπλέγματα διπλασιάζονται στο σκιερό σύμπλεγμα. Αλλά ο εξισορροπητής αγνοεί εντελώς τις απαντήσεις από αυτό το σύμπλεγμα. Το διάγραμμα λειτουργίας του παρουσιάζεται παρακάτω.
Λαμβάνουμε ένα σύμπλεγμα δοκιμών που βρίσκεται σε πραγματικές συνθήκες «μάχης». Η κανονική κίνηση χρηστών πηγαίνει εκεί. Το υλικό και στα δύο συμπλέγματα είναι το ίδιο, επομένως η απόδοση και τα σφάλματα μπορούν να συγκριθούν.
Και δεδομένου ότι ο εξισορροπητής αγνοεί εντελώς τις απαντήσεις, οι τελικοί χρήστες δεν θα βλέπουν απαντήσεις από το σύμπλεγμα σκιών. Επομένως, δεν είναι τρομακτικό να κάνεις λάθος.
Ευρήματα
Λοιπόν, πώς δημιουργήσαμε την αναζήτηση Αγοράς;
Για να πάνε όλα ομαλά, διαχωρίζουμε τη λειτουργικότητα σε ξεχωριστές υπηρεσίες. Με αυτόν τον τρόπο μπορούμε να κλιμακώσουμε μόνο εκείνα τα στοιχεία που χρειαζόμαστε και να κάνουμε τα εξαρτήματα πιο απλά. Είναι εύκολο να εκχωρήσετε ένα ξεχωριστό στοιχείο σε μια άλλη ομάδα και να μοιραστείτε τις ευθύνες για την εργασία σε αυτό. Και η σημαντική εξοικονόμηση σιδήρου με αυτήν την προσέγγιση είναι ένα προφανές πλεονέκτημα.
Το σκιερό σύμπλεγμα μας βοηθά επίσης: μπορούμε να αναπτύξουμε υπηρεσίες, να τις δοκιμάσουμε στη διαδικασία και να μην ενοχλήσουμε τον χρήστη.
Λοιπόν, δοκιμές στην παραγωγή, φυσικά. Θέλετε να αλλάξετε τη διαμόρφωση σε χιλιάδες διακομιστές; Εύκολα, χρησιμοποιήστε το Stop Tap. Με αυτόν τον τρόπο μπορείτε να αναπτύξετε αμέσως μια έτοιμη σύνθετη λύση και να επαναφέρετε σε μια σταθερή έκδοση εάν προκύψουν προβλήματα.
Ελπίζω να μπόρεσα να δείξω πώς κάνουμε την Αγορά γρήγορη και σταθερή με μια συνεχώς αυξανόμενη βάση προσφορών. Πώς επιλύουμε προβλήματα διακομιστή, αντιμετωπίζουμε έναν τεράστιο αριθμό αιτημάτων, βελτιώνουμε την ευελιξία της υπηρεσίας και το κάνουμε αυτό χωρίς να διακόπτουμε τις διαδικασίες εργασίας.
Πηγή: www.habr.com