Άρτεμ Ντενίσοφ ( , )
Το Badoo είναι ο μεγαλύτερος ιστότοπος γνωριμιών στον κόσμο. Αυτή τη στιγμή έχουμε περίπου 330 εκατομμύρια εγγεγραμμένους χρήστες παγκοσμίως. Αλλά αυτό που είναι πολύ πιο σημαντικό στο πλαίσιο της σημερινής μας συνομιλίας είναι ότι αποθηκεύουμε περίπου 3 petabyte φωτογραφιών χρηστών. Κάθε μέρα οι χρήστες μας ανεβάζουν περίπου 3,5 εκατομμύρια νέες φωτογραφίες και ο φόρτος ανάγνωσης είναι περίπου 80 χιλιάδες αιτήματα ανά δευτερόλεπτο. Αυτό είναι αρκετά για το backend μας, και μερικές φορές υπάρχουν δυσκολίες με αυτό.
Θα μιλήσω για τη σχεδίαση αυτού του συστήματος, το οποίο αποθηκεύει και στέλνει φωτογραφίες στο σύνολό του, και θα ρίξω μια ματιά σε αυτό από τη σκοπιά του προγραμματιστή. Θα υπάρξει μια σύντομη αναδρομή για το πώς εξελίχθηκε, όπου θα περιγράψω τα κύρια ορόσημα, αλλά θα μιλήσω μόνο λεπτομερέστερα για τις λύσεις που χρησιμοποιούμε αυτήν τη στιγμή.
Τώρα ας ξεκινήσουμε.
Όπως είπα, αυτό θα είναι μια αναδρομική, και για να το ξεκινήσουμε από κάπου, ας πάρουμε το πιο συνηθισμένο παράδειγμα.
Έχουμε ένα κοινό καθήκον, πρέπει να αποδεχόμαστε, να αποθηκεύουμε και να στέλνουμε φωτογραφίες χρηστών. Σε αυτή τη μορφή, η εργασία είναι γενική, μπορούμε να χρησιμοποιήσουμε οτιδήποτε:
- σύγχρονη αποθήκευση cloud,
- μια λύση σε κουτί, από την οποία υπάρχουν επίσης πολλά τώρα.
- Μπορούμε να εγκαταστήσουμε πολλά μηχανήματα στο κέντρο δεδομένων μας και να τοποθετήσουμε μεγάλους σκληρούς δίσκους σε αυτά και να αποθηκεύσουμε φωτογραφίες εκεί.
Το Badoo ιστορικά - τόσο τώρα όσο και τότε (την εποχή που ήταν μόλις στα σπάργανα) - ζει στους δικούς του διακομιστές, μέσα στα δικά μας DC. Επομένως, αυτή η επιλογή ήταν η βέλτιστη για εμάς.
Μόλις τραβήξαμε πολλά μηχανήματα, τα ονομάσαμε "φωτογραφίες" και πήραμε ένα σύμπλεγμα που αποθηκεύει φωτογραφίες. Φαίνεται όμως ότι κάτι λείπει. Για να λειτουργήσουν όλα αυτά, πρέπει να προσδιορίσουμε με κάποιο τρόπο σε ποιο μηχάνημα θα αποθηκεύσουμε ποιες φωτογραφίες. Και εδώ, επίσης, δεν χρειάζεται να ανοίξουμε την Αμερική.
Προσθέτουμε κάποιο πεδίο στον αποθηκευτικό μας χώρο με πληροφορίες σχετικά με τους χρήστες. Αυτό θα είναι το κλειδί κοινής χρήσης. Στην περίπτωσή μας, το ονομάσαμε place_id και αυτό το αναγνωριστικό θέσης δείχνει το μέρος όπου αποθηκεύονται οι φωτογραφίες των χρηστών. Φτιάχνουμε χάρτες.
Στο πρώτο στάδιο, αυτό μπορεί να γίνει ακόμη και χειροκίνητα - λέμε ότι μια φωτογραφία αυτού του χρήστη με μια τέτοια θέση θα προσγειωθεί σε έναν τέτοιο διακομιστή. Χάρη σε αυτόν τον χάρτη, γνωρίζουμε πάντα πότε ένας χρήστης ανεβάζει μια φωτογραφία, πού να την αποθηκεύσουμε και ξέρουμε από πού να τη δώσουμε.
Αυτό είναι ένα απολύτως ασήμαντο σχέδιο, αλλά έχει αρκετά σημαντικά πλεονεκτήματα. Το πρώτο είναι ότι είναι απλό, όπως είπα, και το δεύτερο είναι ότι με αυτήν την προσέγγιση μπορούμε εύκολα να κλιμακώσουμε οριζόντια, απλώς παραδίδοντας νέα αυτοκίνητα και προσθέτοντάς τα στον χάρτη. Δεν χρειάζεται να κάνετε κάτι άλλο.
Έτσι ήταν για μας για κάποιο διάστημα.
Αυτό ήταν γύρω στο 2009. Παρέδωσαν αυτοκίνητα, παρέδωσαν...
Και κάποια στιγμή αρχίσαμε να παρατηρούμε ότι αυτό το σχήμα έχει ορισμένα μειονεκτήματα. Ποια είναι τα μειονεκτήματα;
Πρώτα απ 'όλα, υπάρχει περιορισμένη χωρητικότητα. Δεν μπορούμε να στριμώξουμε τόσους σκληρούς δίσκους σε έναν φυσικό διακομιστή όσο θα θέλαμε. Και αυτό έχει γίνει ένα συγκεκριμένο πρόβλημα με την πάροδο του χρόνου και με την αύξηση του συνόλου δεδομένων.
Και δεύτερον. Αυτή είναι μια άτυπη διαμόρφωση μηχανών, καθώς τέτοιες μηχανές είναι δύσκολο να επαναχρησιμοποιηθούν σε κάποια άλλα clusters· είναι αρκετά συγκεκριμένα, δηλ. θα πρέπει να είναι αδύναμα σε απόδοση, αλλά ταυτόχρονα με μεγάλο σκληρό δίσκο.
Όλα αυτά ήταν για το 2009, αλλά, κατ' αρχήν, αυτές οι απαιτήσεις εξακολουθούν να είναι επίκαιρες σήμερα. Έχουμε μια αναδρομική, οπότε το 2009 όλα ήταν εντελώς άσχημα με αυτό.
Και το τελευταίο σημείο είναι η τιμή.
Η τιμή ήταν πολύ τσουχτερή εκείνη την εποχή και έπρεπε να ψάξουμε για κάποιες εναλλακτικές. Εκείνοι. χρειαζόταν να αξιοποιήσουμε με κάποιο τρόπο καλύτερα τόσο τον χώρο στα κέντρα δεδομένων όσο και τους φυσικούς διακομιστές στους οποίους βρίσκονται όλα αυτά. Και οι μηχανικοί του συστήματος μας ξεκίνησαν μια μεγάλη μελέτη στην οποία εξέτασαν ένα σωρό διαφορετικές επιλογές. Εξέτασαν επίσης συστήματα συμπλέγματος αρχείων όπως το PolyCeph και το Luster. Υπήρχαν προβλήματα απόδοσης και αρκετά δύσκολη λειτουργία. Αρνήθηκαν. Προσπαθήσαμε να προσαρτήσουμε ολόκληρο το σύνολο δεδομένων μέσω NFS σε κάθε αυτοκίνητο, προκειμένου να το κλιμακώσουμε με κάποιο τρόπο. Η ανάγνωση πήγε επίσης άσχημα, δοκιμάσαμε διαφορετικές λύσεις από διαφορετικούς προμηθευτές.
Και στο τέλος, καταλήξαμε στο να χρησιμοποιούμε το λεγόμενο Δίκτυο Περιοχής Αποθήκευσης.
Πρόκειται για μεγάλα SHD που έχουν σχεδιαστεί ειδικά για την αποθήκευση μεγάλων ποσοτήτων δεδομένων. Είναι ράφια με δίσκους που τοποθετούνται στις τελικές μηχανές οπτικής εξόδου. Οτι. έχουμε ένα είδος δεξαμενής μηχανημάτων, αρκετά μικρά, και αυτά τα SHD, τα οποία είναι διαφανή στη λογική αποστολής μας, δηλ. για το nginx μας ή οποιονδήποτε άλλο να εξυπηρετήσει αιτήματα για αυτές τις φωτογραφίες.
Αυτή η απόφαση είχε προφανή πλεονεκτήματα. Αυτό είναι το SHD. Αποσκοπεί στην αποθήκευση φωτογραφιών. Αυτό είναι φθηνότερο από τον απλό εξοπλισμό μηχανών με σκληρούς δίσκους.
Δεύτερο συν.
Αυτό είναι ότι η χωρητικότητα έχει γίνει πολύ μεγαλύτερη, δηλ. μπορούμε να φιλοξενήσουμε πολύ περισσότερο χώρο αποθήκευσης σε πολύ μικρότερο όγκο.
Υπήρχαν όμως και μειονεκτήματα που εμφανίστηκαν αρκετά γρήγορα. Καθώς ο αριθμός των χρηστών και ο φόρτος σε αυτό το σύστημα αυξανόταν, άρχισαν να δημιουργούνται προβλήματα απόδοσης. Και το πρόβλημα εδώ είναι αρκετά προφανές - κάθε SHD που έχει σχεδιαστεί για να αποθηκεύει πολλές φωτογραφίες σε μικρό όγκο, κατά κανόνα, υποφέρει από εντατική ανάγνωση. Αυτό ισχύει στην πραγματικότητα για οποιοδήποτε χώρο αποθήκευσης cloud ή οτιδήποτε άλλο. Τώρα δεν έχουμε έναν ιδανικό αποθηκευτικό χώρο που θα μπορούσε να είναι απείρως επεκτάσιμος, θα μπορούσατε να βάλετε οτιδήποτε σε αυτό και θα ανεχόταν πολύ καλά τις αναγνώσεις. Ειδικά περιστασιακά αναγνώσματα.
Όπως συμβαίνει με τις φωτογραφίες μας, επειδή οι φωτογραφίες ζητούνται ασυνεπώς και αυτό θα επηρεάσει σε μεγάλο βαθμό την απόδοσή τους.
Ακόμη και σύμφωνα με τα σημερινά στοιχεία, αν έχουμε κάπου πάνω από 500 RPS για φωτογραφίες σε ένα μηχάνημα στο οποίο είναι συνδεδεμένος ο χώρος αποθήκευσης, τα προβλήματα αρχίζουν ήδη. Και ήταν αρκετά κακό για εμάς, επειδή ο αριθμός των χρηστών αυξάνεται, τα πράγματα θα γίνουν μόνο χειρότερα. Αυτό πρέπει να βελτιστοποιηθεί με κάποιο τρόπο.
Προκειμένου να βελτιστοποιήσουμε, αποφασίσαμε εκείνη τη στιγμή, προφανώς, να δούμε το προφίλ φόρτωσης - τι, γενικά, συμβαίνει, τι πρέπει να βελτιστοποιηθεί.
Και εδώ όλα παίζουν στα χέρια μας.
Είπα ήδη στην πρώτη διαφάνεια: έχουμε 80 χιλιάδες αιτήματα ανάγνωσης ανά δευτερόλεπτο με μόνο 3,5 εκατομμύρια μεταφορτώσεις την ημέρα. Δηλαδή, αυτή είναι μια διαφορά τριών τάξεων μεγέθους. Είναι προφανές ότι η ανάγνωση πρέπει να βελτιστοποιηθεί και είναι πρακτικά σαφές πώς.
Υπάρχει ένα ακόμη μικρό σημείο. Οι ιδιαιτερότητες της υπηρεσίας είναι τέτοιες που ένα άτομο εγγράφεται, ανεβάζει μια φωτογραφία, στη συνέχεια αρχίζει να κοιτάζει ενεργά άλλους ανθρώπους, τους αρέσουν και εμφανίζεται ενεργά σε άλλα άτομα. Μετά βρίσκει σύντροφο ή δεν βρίσκει σύντροφο, εξαρτάται από το πώς θα βγει και σταματά να χρησιμοποιεί την υπηρεσία για λίγο. Αυτή τη στιγμή, όταν το χρησιμοποιεί, οι φωτογραφίες του είναι πολύ καυτές - είναι περιζήτητες, πολύς κόσμος τις βλέπει. Μόλις σταματήσει να το κάνει αυτό, πολύ γρήγορα εγκαταλείπει την έκθεση σε άλλους ανθρώπους όπως πριν, και οι φωτογραφίες του δεν ζητούνται σχεδόν ποτέ.
Εκείνοι. Έχουμε ένα πολύ μικρό hot σύνολο δεδομένων. Ταυτόχρονα όμως υπάρχουν πολλά αιτήματα για εκείνον. Και μια εντελώς προφανής λύση εδώ είναι να προσθέσετε μια προσωρινή μνήμη.
Μια κρυφή μνήμη με LRU θα λύσει όλα μας τα προβλήματα. Τι κάνουμε?
Προσθέτουμε ένα άλλο σχετικά μικρό μπροστά από το μεγάλο μας cluster με αποθηκευτικό χώρο, το οποίο λέγεται photocaches. Αυτό είναι ουσιαστικά απλώς ένας διακομιστής μεσολάβησης προσωρινής αποθήκευσης.
Πώς λειτουργεί από μέσα; Εδώ είναι ο χρήστης μας, εδώ είναι ο χώρος αποθήκευσης. Όλα είναι ίδια με πριν. Τι προσθέτουμε ενδιάμεσα;
Είναι απλώς ένα μηχάνημα με φυσικό τοπικό δίσκο, το οποίο είναι γρήγορο. Αυτό είναι με έναν SSD, για παράδειγμα. Και κάποιο είδος τοπικής προσωρινής μνήμης αποθηκεύεται σε αυτόν τον δίσκο.
Πως μοιάζει? Ο χρήστης στέλνει αίτημα για φωτογραφία. Το NGINX το αναζητά πρώτα στην τοπική κρυφή μνήμη. Αν όχι, τότε απλώς περάστε proxy_pass στον αποθηκευτικό μας χώρο, κατεβάστε τη φωτογραφία από εκεί και δώστε τη στον χρήστη.
Αλλά αυτό είναι πολύ κοινότοπο και δεν είναι ξεκάθαρο τι συμβαίνει μέσα. Λειτουργεί κάπως έτσι.
Η κρυφή μνήμη χωρίζεται λογικά σε τρία επίπεδα. Όταν λέω «τρία στρώματα», αυτό δεν σημαίνει ότι υπάρχει κάποιου είδους περίπλοκο σύστημα. Όχι, αυτοί είναι μόνο τρεις κατάλογοι υπό όρους στο σύστημα αρχείων:
- Αυτό είναι ένα buffer όπου πηγαίνουν οι φωτογραφίες που μόλις λήφθηκαν από έναν διακομιστή μεσολάβησης.
- Αυτή είναι μια καυτή κρυφή μνήμη που αποθηκεύει τις φωτογραφίες που έχουν ζητηθεί ενεργά αυτήν τη στιγμή.
- Και μια κρύα κρυφή μνήμη, όπου οι φωτογραφίες απομακρύνονται σταδιακά από τη ζεστή κρυφή μνήμη όταν έρχονται λιγότερα αιτήματα.
Για να λειτουργήσει αυτό, πρέπει να διαχειριστούμε με κάποιο τρόπο αυτήν την προσωρινή μνήμη, πρέπει να αναδιατάξουμε τις φωτογραφίες σε αυτήν κ.λπ. Αυτή είναι επίσης μια πολύ πρωτόγονη διαδικασία.
Το Nginx απλώς γράφει στο RAMDisk access.log για κάθε αίτημα, στο οποίο υποδεικνύει τη διαδρομή προς τη φωτογραφία που έχει εξυπηρετήσει αυτήν τη στιγμή (σχετική διαδρομή, φυσικά) και ποιο διαμέρισμα εξυπηρετήθηκε. Εκείνοι. μπορεί να λέει "φωτογραφία 1" και μετά είτε buffer, είτε hot cache, είτε cold cache ή proxy.
Ανάλογα με αυτό, πρέπει να αποφασίσουμε με κάποιο τρόπο τι θα κάνουμε με τη φωτογραφία.
Έχουμε έναν μικρό δαίμονα που τρέχει σε κάθε μηχάνημα που διαβάζει συνεχώς αυτό το αρχείο καταγραφής και αποθηκεύει στατιστικά στοιχεία σχετικά με τη χρήση ορισμένων φωτογραφιών στη μνήμη του.
Απλώς μαζεύει εκεί, κρατάει τα γκισέ και κάνει περιοδικά τα εξής. Μετακινεί ενεργά ζητούμενες φωτογραφίες, για τις οποίες έρχονται πολλά αιτήματα, στο hot cache, όπου κι αν βρίσκονται.
Οι φωτογραφίες που ζητούνται σπάνια και έχουν ζητηθεί λιγότερο συχνά προωθούνται σταδιακά από τη ζεστή κρυφή μνήμη στην ψυχρή.
Και όταν μας τελειώνει ο χώρος στην κρυφή μνήμη, απλά αρχίζουμε να διαγράφουμε τα πάντα από την κρύα κρυφή μνήμη αδιακρίτως. Και παρεμπιπτόντως, αυτό λειτουργεί καλά.
Προκειμένου η φωτογραφία να αποθηκευτεί αμέσως όταν γίνεται μεσολάβηση στο buffer, χρησιμοποιούμε την οδηγία proxy_store και το buffer είναι επίσης RAMDisk, δηλ. για τον χρήστη λειτουργεί πολύ γρήγορα. Αυτό αφορά τα εσωτερικά του ίδιου του διακομιστή προσωρινής αποθήκευσης.
Το ερώτημα που απομένει είναι πώς να διανείμετε αιτήματα σε αυτούς τους διακομιστές.
Ας υποθέσουμε ότι υπάρχει ένα σύμπλεγμα είκοσι μηχανών αποθήκευσης και τρεις διακομιστές προσωρινής αποθήκευσης (έτσι συνέβη).
Πρέπει να προσδιορίσουμε με κάποιο τρόπο ποια αιτήματα είναι για ποιες φωτογραφίες και πού να τις προσγειώσουμε.
Η πιο συνηθισμένη επιλογή είναι το Round Robin. Ή να το κάνει τυχαία;
Αυτό έχει προφανώς μια σειρά από μειονεκτήματα επειδή θα χρησιμοποιούσαμε την κρυφή μνήμη πολύ αναποτελεσματική σε μια τέτοια κατάσταση. Τα αιτήματα θα προσγειωθούν σε ορισμένες τυχαίες μηχανές: εδώ αποθηκεύτηκε προσωρινά, αλλά στην επόμενη δεν είναι πλέον εκεί. Και αν όλα αυτά λειτουργήσουν, θα είναι πολύ κακό. Ακόμη και με μικρό αριθμό μηχανών στο σύμπλεγμα.
Πρέπει να προσδιορίσουμε με κάποιο τρόπο ξεκάθαρα ποιος διακομιστής θα προσγειώσει το αίτημα.
Υπάρχει ένας μπανάλ τρόπος. Παίρνουμε τον κατακερματισμό από τη διεύθυνση URL ή τον κατακερματισμό από το κλειδί κοινής χρήσης, που βρίσκεται στη διεύθυνση URL, και το διαιρούμε με τον αριθμό των διακομιστών. Θα δουλέψω? Θα.
Εκείνοι. Έχουμε ένα αίτημα 2%, για παράδειγμα, για κάποιο "example_url" θα προσγειώνεται πάντα στον διακομιστή με το δείκτη "XNUMX" και η προσωρινή μνήμη θα διατίθεται συνεχώς όσο το δυνατόν καλύτερα.
Αλλά υπάρχει ένα πρόβλημα με την ανανέωση σε ένα τέτοιο σχήμα. Ανανέωση - Εννοώ αλλαγή του αριθμού των διακομιστών.
Ας υποθέσουμε ότι το σύμπλεγμα προσωρινής αποθήκευσης δεν μπορεί πλέον να αντεπεξέλθει και αποφασίζουμε να προσθέσουμε άλλο μηχάνημα.
Ας προσθέσουμε.
Τώρα όλα διαιρούνται όχι με τρία, αλλά με τέσσερα. Έτσι, σχεδόν όλα τα κλειδιά που είχαμε, σχεδόν όλα τα URL βρίσκονται πλέον σε άλλους διακομιστές. Ολόκληρη η προσωρινή μνήμη ακυρώθηκε απλώς για μια στιγμή. Όλα τα αιτήματα έπεσαν στο σύμπλεγμα αποθηκευτικού χώρου μας, δεν ήταν καλά, αποτυχία υπηρεσίας και δυσαρεστημένοι χρήστες. Δεν θέλω να το κάνω αυτό.
Ούτε αυτή η επιλογή μας ταιριάζει.
Οτι. τι πρέπει να κάνουμε? Πρέπει με κάποιο τρόπο να χρησιμοποιούμε αποτελεσματικά την κρυφή μνήμη, να προσαρμόζουμε το ίδιο αίτημα στον ίδιο διακομιστή ξανά και ξανά, αλλά να είμαστε ανθεκτικοί στο resharding. Και υπάρχει μια τέτοια λύση, δεν είναι τόσο περίπλοκη. Ονομάζεται συνεπής κατακερματισμός.
Πώς μοιάζει;
Παίρνουμε κάποια συνάρτηση από το κλειδί κοινής χρήσης και απλώνουμε όλες τις τιμές της στον κύκλο. Εκείνοι. στο σημείο 0, οι ελάχιστες και μέγιστες τιμές του συγκλίνουν. Στη συνέχεια, τοποθετούμε όλους τους διακομιστές μας στον ίδιο κύκλο περίπου με αυτόν τον τρόπο:
Κάθε διακομιστής ορίζεται από ένα σημείο και ο τομέας που πηγαίνει δεξιόστροφα σε αυτόν, εξυπηρετείται από αυτόν τον κεντρικό υπολογιστή. Όταν μας έρχονται αιτήματα, βλέπουμε αμέσως ότι, για παράδειγμα, το αίτημα Α - έχει κατακερματισμό εκεί - και εξυπηρετείται από τον διακομιστή 2. Αίτημα Β - από τον διακομιστή 3. Και ούτω καθεξής.
Τι συμβαίνει σε αυτήν την περίπτωση κατά τη διάρκεια του ανανεωμένου παλμού;
Δεν ακυρώνουμε ολόκληρη την προσωρινή μνήμη, όπως πριν, και δεν μετατοπίζουμε όλα τα κλειδιά, αλλά μετατοπίζουμε κάθε τομέα σε μικρή απόσταση, έτσι ώστε, μιλώντας σχετικά, ο έκτος διακομιστής μας, που θέλουμε να προσθέσουμε, να χωράει στον ελεύθερο χώρο και το προσθέτουμε εκεί.
Φυσικά, σε μια τέτοια κατάσταση τα κλειδιά βγαίνουν επίσης. Αλλά φεύγουν πολύ πιο αδύναμοι από πριν. Και βλέπουμε ότι τα δύο πρώτα κλειδιά μας παρέμειναν στους διακομιστές τους και ο διακομιστής προσωρινής αποθήκευσης μόνο για το τελευταίο κλειδί άλλαξε. Αυτό λειτουργεί αρκετά αποτελεσματικά και αν προσθέσετε νέους κεντρικούς υπολογιστές σταδιακά, τότε δεν υπάρχει μεγάλο πρόβλημα εδώ. Προσθέτετε και προσθέτετε λίγο κάθε φορά, περιμένετε μέχρι να γεμίσει ξανά η προσωρινή μνήμη και όλα λειτουργούν καλά.
Το μόνο ερώτημα παραμένει με τις αρνήσεις. Ας υποθέσουμε ότι κάποιο είδος αυτοκινήτου είναι εκτός λειτουργίας.
Και δεν θα θέλαμε πραγματικά να αναδημιουργήσουμε αυτόν τον χάρτη αυτήν τη στιγμή, να ακυρώσουμε μέρος της κρυφής μνήμης και ούτω καθεξής, εάν, για παράδειγμα, το μηχάνημα είχε επανεκκινηθεί και πρέπει να κάνουμε με κάποιο τρόπο αιτήματα εξυπηρέτησης. Απλώς διατηρούμε μια εφεδρική προσωρινή μνήμη φωτογραφιών σε κάθε τοποθεσία, η οποία λειτουργεί ως αντικατάσταση για κάθε μηχάνημα που είναι προς το παρόν εκτός λειτουργίας. Και αν ξαφνικά ένας από τους διακομιστές μας γίνει μη διαθέσιμος, η κίνηση πηγαίνει εκεί. Φυσικά, δεν έχουμε καμία κρυφή μνήμη εκεί, δηλ. είναι κρύο, αλλά τουλάχιστον τα αιτήματα των χρηστών υποβάλλονται σε επεξεργασία. Αν αυτό είναι ένα μικρό διάστημα, τότε το βιώνουμε εντελώς ήρεμα. Απλώς υπάρχει περισσότερο φορτίο στην αποθήκευση. Εάν αυτό το διάστημα είναι μεγάλο, τότε μπορούμε ήδη να λάβουμε μια απόφαση - να αφαιρέσουμε αυτόν τον διακομιστή από τον χάρτη ή όχι, ή ίσως να τον αντικαταστήσουμε με άλλον.
Πρόκειται για το σύστημα προσωρινής αποθήκευσης. Ας δούμε τα αποτελέσματα.
Φαίνεται ότι δεν υπάρχει τίποτα περίπλοκο εδώ. Αλλά αυτή η μέθοδος διαχείρισης της κρυφής μνήμης μας έδωσε ένα ποσοστό κόλπων περίπου 98%. Εκείνοι. Από αυτές τις 80 χιλιάδες αιτήματα ανά δευτερόλεπτο, μόνο 1600 φτάνουν στον χώρο αποθήκευσης, και αυτό είναι ένα απολύτως φυσιολογικό φορτίο, το αντέχουν ήρεμα, έχουμε πάντα απόθεμα.
Τοποθετήσαμε αυτούς τους διακομιστές σε τρία από τα DC μας και λάβαμε τρία σημεία παρουσίας - την Πράγα, το Μαϊάμι και το Χονγκ Κονγκ.
Οτι. βρίσκονται λίγο πολύ τοπικά σε κάθε μία από τις αγορές-στόχους μας.
Και ως ένα ωραίο μπόνους, πήραμε αυτόν τον διακομιστή μεσολάβησης προσωρινής αποθήκευσης, στον οποίο η CPU είναι στην πραγματικότητα αδρανής, επειδή δεν είναι τόσο απαραίτητος για την προβολή περιεχομένου. Και εκεί, χρησιμοποιώντας το NGINX+ Lua, εφαρμόσαμε πολλή χρηστική λογική.
Για παράδειγμα, μπορούμε να πειραματιστούμε με το webp ή το προοδευτικό jpeg (αυτές είναι αποτελεσματικές σύγχρονες μορφές), να δούμε πώς επηρεάζει την κυκλοφορία, να πάρουμε κάποιες αποφάσεις, να το ενεργοποιήσουμε για ορισμένες χώρες κ.λπ. κάντε δυναμική αλλαγή μεγέθους ή περικόψτε φωτογραφίες εν κινήσει.
Αυτή είναι μια καλή περίπτωση χρήσης όταν, για παράδειγμα, έχετε μια εφαρμογή για κινητά που εμφανίζει φωτογραφίες και η εφαρμογή για κινητά δεν θέλει να σπαταλήσει τη CPU του πελάτη ζητώντας μια μεγάλη φωτογραφία και στη συνέχεια αλλάξτε το μέγεθός της σε ένα συγκεκριμένο μέγεθος για να την ωθήσει σε η θέα. Μπορούμε απλά να καθορίσουμε δυναμικά ορισμένες παραμέτρους στη διεύθυνση URL υπό όρους UPort και η κρυφή μνήμη φωτογραφιών θα αλλάξει το μέγεθος της ίδιας της φωτογραφίας. Κατά κανόνα, θα επιλέξει το μέγεθος που έχουμε φυσικά στο δίσκο, όσο το δυνατόν πιο κοντά στο ζητούμενο, και θα το πουλήσει σε συγκεκριμένες συντεταγμένες.
Παρεμπιπτόντως, έχουμε δημοσιοποιήσει τις εγγραφές βίντεο των τελευταίων πέντε ετών του συνεδρίου των προγραμματιστών συστημάτων υψηλού φορτίου . Παρακολουθήστε, μάθετε, μοιραστείτε και εγγραφείτε .
Μπορούμε επίσης να προσθέσουμε πολλή λογική προϊόντων εκεί. Για παράδειγμα, μπορούμε να προσθέσουμε διαφορετικά υδατογραφήματα χρησιμοποιώντας παραμέτρους URL, μπορούμε να θολώνουμε, να θολώνουμε ή να κάνουμε εικονοστοιχεία στις φωτογραφίες. Αυτό συμβαίνει όταν θέλουμε να δείξουμε μια φωτογραφία ενός ατόμου, αλλά δεν θέλουμε να δείξουμε το πρόσωπό του, αυτό λειτουργεί καλά, όλα εφαρμόζονται εδώ.
Τι πήραμε; Έχουμε τρεις πόντους παρουσίας, καλό ποσοστό κόλπων και ταυτόχρονα δεν έχουμε CPU σε αδράνεια σε αυτά τα μηχανήματα. Έχει γίνει πλέον, φυσικά, πιο σημαντικός από πριν. Πρέπει να δώσουμε στον εαυτό μας πιο δυνατά αυτοκίνητα, αλλά αξίζει τον κόπο.
Αυτό αφορά την επιστροφή φωτογραφιών. Όλα εδώ είναι αρκετά ξεκάθαρα και προφανή. Νομίζω ότι δεν ανακάλυψα την Αμερική, σχεδόν κάθε CDN λειτουργεί με αυτόν τον τρόπο.
Και, πιθανότατα, ένας εκλεπτυσμένος ακροατής μπορεί να έχει μια ερώτηση: γιατί να μην αλλάξουμε τα πάντα σε CDN; Θα ήταν περίπου το ίδιο· όλα τα σύγχρονα CDN μπορούν να το κάνουν αυτό. Και υπάρχουν αρκετοί λόγοι.
Το πρώτο είναι φωτογραφίες.
Αυτό είναι ένα από τα βασικά σημεία της υποδομής μας και χρειαζόμαστε όσο το δυνατόν περισσότερο έλεγχο πάνω σε αυτό. Εάν αυτή είναι κάποιο είδος λύσης από τρίτο προμηθευτή και δεν έχετε καμία εξουσία πάνω σε αυτό, θα είναι πολύ δύσκολο για εσάς να ζήσετε με αυτό όταν έχετε ένα μεγάλο σύνολο δεδομένων και όταν έχετε πολύ μεγάλη ροή των αιτημάτων των χρηστών.
Επιτρέψτε μου να σας δώσω ένα παράδειγμα. Τώρα, με την υποδομή μας, μπορούμε, για παράδειγμα, σε περίπτωση προβλημάτων ή υπόγειων χτυπημάτων, να πάμε στο μηχάνημα και να τα βρούμε εκεί, σχετικά. Μπορούμε να προσθέσουμε τη συλλογή κάποιων μετρήσεων που χρειαζόμαστε μόνο, μπορούμε να πειραματιστούμε με κάποιο τρόπο, να δούμε πώς αυτό επηρεάζει τα γραφήματα και ούτω καθεξής. Τώρα συλλέγονται πολλά στατιστικά στοιχεία για αυτό το σύμπλεγμα προσωρινής αποθήκευσης. Και το εξετάζουμε περιοδικά και περνάμε πολύ χρόνο εξερευνώντας κάποιες ανωμαλίες. Εάν ήταν στην πλευρά του CDN, θα ήταν πολύ πιο δύσκολο να ελεγχθεί. Ή, για παράδειγμα, αν συμβεί κάποιο είδος ατυχήματος, ξέρουμε τι συνέβη, ξέρουμε πώς να ζήσουμε με αυτό και πώς να το ξεπεράσουμε. Αυτό είναι το πρώτο συμπέρασμα.
Το δεύτερο συμπέρασμα είναι επίσης μάλλον ιστορικό, επειδή το σύστημα αναπτύσσεται εδώ και πολύ καιρό, και υπήρχαν πολλές διαφορετικές επιχειρηματικές απαιτήσεις σε διαφορετικά στάδια, και δεν ταιριάζουν πάντα στην ιδέα του CDN.
Και το σημείο που προκύπτει από το προηγούμενο είναι
Αυτό συμβαίνει γιατί στις κρυφές μνήμες φωτογραφιών έχουμε πολύ συγκεκριμένη λογική, η οποία δεν μπορεί πάντα να προστεθεί κατόπιν αιτήματος. Είναι απίθανο οποιοδήποτε CDN να προσθέσει κάποια προσαρμοσμένα πράγματα σε εσάς κατόπιν αιτήματός σας. Για παράδειγμα, κρυπτογράφηση διευθύνσεων URL εάν δεν θέλετε ο πελάτης να μπορεί να αλλάξει κάτι. Θέλετε να αλλάξετε τη διεύθυνση URL στο διακομιστή και να την κρυπτογραφήσετε και, στη συνέχεια, να στείλετε ορισμένες δυναμικές παραμέτρους εδώ.
Τι συμπέρασμα συνεπάγεται αυτό; Στην περίπτωσή μας, το CDN δεν είναι μια πολύ καλή εναλλακτική.
Και στην περίπτωσή σας, εάν έχετε συγκεκριμένες επιχειρηματικές απαιτήσεις, τότε μπορείτε πολύ εύκολα να εφαρμόσετε αυτό που σας έδειξα μόνοι σας. Και αυτό θα λειτουργήσει τέλεια με παρόμοιο προφίλ φορτίου.
Αλλά αν έχετε κάποιο είδος γενικής λύσης και η εργασία δεν είναι πολύ συγκεκριμένη, μπορείτε να πάρετε με απόλυτη ασφάλεια ένα CDN. Ή εάν ο χρόνος και οι πόροι είναι πιο σημαντικοί για εσάς από τον έλεγχο.
Και τα σύγχρονα CDN έχουν σχεδόν όλα όσα σας είπα τώρα. Με εξαίρεση τα συν ή πλην κάποια χαρακτηριστικά.
Πρόκειται για την προσφορά φωτογραφιών.
Ας προχωρήσουμε τώρα λίγο στην αναδρομή μας και ας μιλήσουμε για αποθήκευση.
Το 2013 περνούσε.
Προστέθηκαν διακομιστές προσωρινής αποθήκευσης, τα προβλήματα απόδοσης εξαφανίστηκαν. Ολα ειναι καλά. Το σύνολο δεδομένων αυξάνεται. Από το 2013, είχαμε περίπου 80 διακομιστές συνδεδεμένους στην αποθήκευση και περίπου 40 διακομιστές προσωρινής αποθήκευσης σε κάθε DC. Πρόκειται για 560 terabytes δεδομένων σε κάθε DC, δηλ. περίπου ένα petabyte συνολικά.
Και με την αύξηση του συνόλου δεδομένων, το λειτουργικό κόστος άρχισε να αυξάνεται σημαντικά. Τι σήμαινε αυτό;
Σε αυτό το διάγραμμα που σχεδιάζεται - με ένα SAN, με μηχανήματα και κρυφές μνήμες συνδεδεμένες σε αυτό - υπάρχουν πολλά σημεία αστοχίας. Αν είχαμε ήδη αντιμετωπίσει την αποτυχία των διακομιστών προσωρινής αποθήκευσης, όλα ήταν λίγο πολύ προβλέψιμα και κατανοητά, αλλά από την πλευρά της αποθήκευσης όλα ήταν πολύ χειρότερα.
Πρώτον, υπάρχει το ίδιο το Storage Area Network (SAN), το οποίο μπορεί να αποτύχει.
Δεύτερον, συνδέεται μέσω οπτικών με τις ακραίες μηχανές. Μπορεί να υπάρχουν προβλήματα με τις οπτικές κάρτες και τα μπουζί.
Φυσικά, δεν υπάρχουν τόσα πολλά από αυτά όπως με το ίδιο το SAN, αλλά, ωστόσο, αυτά είναι επίσης σημεία αποτυχίας.
Ακολουθεί το ίδιο το μηχάνημα, το οποίο συνδέεται με την αποθήκευση. Μπορεί επίσης να αποτύχει.
Συνολικά έχουμε τρία σημεία αποτυχίας.
Επιπλέον, εκτός από τα σημεία αστοχίας, υπάρχει βαριά συντήρηση της ίδιας της αποθήκευσης.
Αυτό είναι ένα πολύπλοκο σύστημα πολλαπλών συστατικών και οι μηχανικοί συστημάτων μπορεί να δυσκολευτούν να δουλέψουν μαζί του.
Και το τελευταίο, πιο σημαντικό σημείο. Εάν παρουσιαστεί μια αποτυχία σε οποιοδήποτε από αυτά τα τρία σημεία, έχουμε μη μηδενική πιθανότητα να χάσουμε δεδομένα χρήστη επειδή το σύστημα αρχείων μπορεί να διακοπεί.
Ας υποθέσουμε ότι το σύστημα αρχείων μας είναι κατεστραμμένο. Πρώτον, η ανάκτησή του διαρκεί πολύ - μπορεί να διαρκέσει μια εβδομάδα με μεγάλο όγκο δεδομένων. Και δεύτερον, στο τέλος πιθανότατα θα καταλήξουμε με ένα σωρό ακατανόητα αρχεία που θα πρέπει με κάποιο τρόπο να συνδυαστούν σε φωτογραφίες χρηστών. Και κινδυνεύουμε να χάσουμε δεδομένα. Ο κίνδυνος είναι αρκετά υψηλός. Και όσο πιο συχνά συμβαίνουν τέτοιες καταστάσεις και όσο περισσότερα προβλήματα προκύπτουν σε ολόκληρη αυτή την αλυσίδα, τόσο μεγαλύτερος είναι αυτός ο κίνδυνος.
Κάτι έπρεπε να γίνει γι' αυτό. Και αποφασίσαμε ότι χρειάζεται απλώς να δημιουργήσουμε αντίγραφα ασφαλείας των δεδομένων. Αυτή είναι στην πραγματικότητα μια προφανής και καλή λύση. Τι καναμε?
Έτσι έμοιαζε ο διακομιστής μας όταν ήταν συνδεδεμένος στο χώρο αποθήκευσης πριν. Αυτό είναι ένα κύριο τμήμα, είναι απλώς μια συσκευή μπλοκ που στην πραγματικότητα αντιπροσωπεύει μια βάση για απομακρυσμένη αποθήκευση μέσω οπτικών.
Μόλις προσθέσαμε μια δεύτερη ενότητα.
Τοποθετήσαμε ένα δεύτερο αποθηκευτικό χώρο δίπλα του (ευτυχώς, δεν είναι τόσο ακριβό από άποψη χρημάτων) και το ονομάσαμε εφεδρικό διαμέρισμα. Συνδέεται και μέσω οπτικών και βρίσκεται στο ίδιο μηχάνημα. Πρέπει όμως με κάποιο τρόπο να συγχρονίσουμε τα δεδομένα μεταξύ τους.
Εδώ κάνουμε απλώς μια ασύγχρονη ουρά κοντά.
Δεν είναι πολύ απασχολημένη. Ξέρουμε ότι δεν έχουμε αρκετούς δίσκους. Η ουρά είναι απλώς ένας πίνακας στη MySQL στον οποίο γράφονται γραμμές όπως "πρέπει να δημιουργήσετε αντίγραφα ασφαλείας αυτής της φωτογραφίας". Με οποιαδήποτε αλλαγή ή μεταφόρτωση, αντιγράφουμε από το κύριο διαμέρισμα σε αντίγραφο ασφαλείας χρησιμοποιώντας έναν ασύγχρονο ή απλώς κάποιου είδους εργάτη στο παρασκήνιο.
Και έτσι έχουμε πάντα δύο συνεπείς ενότητες. Ακόμα κι αν ένα μέρος αυτού του συστήματος αποτύχει, μπορούμε πάντα να αλλάξουμε το κύριο διαμέρισμα με ένα αντίγραφο ασφαλείας και όλα θα συνεχίσουν να λειτουργούν.
Αλλά εξαιτίας αυτού, το φορτίο ανάγνωσης αυξάνεται πολύ, επειδή... εκτός από τους πελάτες που διαβάζουν από την κύρια ενότητα, επειδή κοιτάζουν πρώτα τη φωτογραφία εκεί (είναι πιο πρόσφατη εκεί) και μετά την αναζητούν στο αντίγραφο ασφαλείας, αν δεν την έχουν βρει (αλλά το NGINX κάνει απλώς αυτό), Το σύστημά μας είναι επίσης ένα αντίγραφο ασφαλείας που διαβάζεται τώρα από το κύριο διαμέρισμα. Δεν είναι ότι αυτό ήταν ένα σημείο συμφόρησης, αλλά δεν ήθελα να αυξήσω το φορτίο, ουσιαστικά, ακριβώς έτσι.
Και προσθέσαμε έναν τρίτο δίσκο, που είναι ένας μικρός SSD, και τον ονομάσαμε buffer.
Πώς λειτουργεί τώρα.
Ο χρήστης ανεβάζει μια φωτογραφία στο buffer και, στη συνέχεια, ένα συμβάν ρίχνεται στην ουρά που υποδεικνύει ότι πρέπει να αντιγραφεί σε δύο ενότητες. Αντιγράφεται και η φωτογραφία μένει στο buffer για κάποιο χρονικό διάστημα (ας πούμε, μια μέρα) και μόνο τότε αφαιρείται από εκεί. Αυτό βελτιώνει σημαντικά την εμπειρία χρήστη, επειδή ο χρήστης ανεβάζει μια φωτογραφία, κατά κανόνα, αρχίζουν να ακολουθούν αμέσως αιτήματα ή ο ίδιος ενημέρωσε τη σελίδα και την ανανέωσε. Όλα όμως εξαρτώνται από την εφαρμογή που κάνει το upload.
Ή, για παράδειγμα, άλλα άτομα στα οποία άρχισε να εμφανίζεται στέλνουν αμέσως αιτήματα μετά από αυτήν τη φωτογραφία. Δεν είναι ακόμα στη μνήμη cache, το πρώτο αίτημα πραγματοποιείται πολύ γρήγορα. Ουσιαστικά το ίδιο όπως από μια κρυφή μνήμη φωτογραφιών. Η αργή αποθήκευση δεν εμπλέκεται καθόλου σε αυτό. Και όταν μια μέρα αργότερα καθαριστεί, είτε είναι ήδη αποθηκευμένο στην κρυφή μνήμη στο επίπεδο προσωρινής αποθήκευσης, είτε, πιθανότατα, κανείς δεν το χρειάζεται πια. Εκείνοι. Η εμπειρία χρήστη εδώ έχει αναπτυχθεί πολύ καλά λόγω τόσο απλών χειρισμών.
Λοιπόν, και το πιο σημαντικό: σταματήσαμε να χάνουμε δεδομένα.
Ας πούμε ότι σταματήσαμε ενδεχομένως χάσουμε δεδομένα, γιατί δεν τα χάσαμε πραγματικά. Υπήρχε όμως κίνδυνος. Βλέπουμε ότι αυτή η λύση είναι, φυσικά, καλή, αλλά είναι λίγο σαν να εξομαλύνει τα συμπτώματα του προβλήματος, αντί να το λύνει πλήρως. Και κάποια προβλήματα παραμένουν εδώ.
Πρώτον, αυτό είναι ένα σημείο αποτυχίας με τη μορφή του ίδιου του φυσικού κεντρικού υπολογιστή στον οποίο λειτουργεί όλος αυτός ο μηχανισμός· δεν έχει εξαφανιστεί.
Δεύτερον, υπάρχουν ακόμα προβλήματα με τα SAN, παραμένει η βαριά συντήρησή τους κ.λπ. Δεν ήταν ότι ήταν κρίσιμος παράγοντας, αλλά ήθελα να προσπαθήσω με κάποιο τρόπο να ζήσω χωρίς αυτό.
Και φτιάξαμε την τρίτη έκδοση (στην πραγματικότητα, τη δεύτερη μάλιστα) - την έκδοση κράτησης. Πώς έμοιαζε;
Αυτό ήταν -
Τα κύρια προβλήματά μας είναι με το γεγονός ότι πρόκειται για φυσικό οικοδεσπότη.
Πρώτον, καταργούμε τα SAN επειδή θέλουμε να πειραματιστούμε, θέλουμε να δοκιμάσουμε μόνο τοπικούς σκληρούς δίσκους.
Αυτό είναι ήδη 2014-2015 και εκείνη την εποχή η κατάσταση με τους δίσκους και τη χωρητικότητά τους σε έναν κεντρικό υπολογιστή έγινε πολύ καλύτερη. Αποφασίσαμε γιατί να μην το δοκιμάσουμε.
Και, στη συνέχεια, παίρνουμε απλώς το εφεδρικό μας διαμέρισμα και το μεταφέρουμε φυσικά σε ένα ξεχωριστό μηχάνημα.
Έτσι, παίρνουμε αυτό το διάγραμμα. Έχουμε δύο αυτοκίνητα που αποθηκεύουν τα ίδια σύνολα δεδομένων. Δημιουργούν πλήρη αντίγραφα ασφαλείας μεταξύ τους και συγχρονίζουν δεδομένα μέσω του δικτύου μέσω μιας ασύγχρονης ουράς στην ίδια MySQL.
Γιατί αυτό λειτουργεί καλά είναι επειδή έχουμε λίγους δίσκους. Εκείνοι. αν η γραφή ήταν συγκρίσιμη με την ανάγνωση, ίσως θα είχαμε κάποιου είδους επιβάρυνση δικτύου και προβλήματα. Υπάρχει λίγο γράψιμο, πολύ διάβασμα - αυτή η μέθοδος λειτουργεί καλά, δηλ. Σπάνια αντιγράφουμε φωτογραφίες μεταξύ αυτών των δύο διακομιστών.
Πώς λειτουργεί αυτό, αν κοιτάξετε λίγο πιο αναλυτικά.
Μεταφόρτωση. Ο εξισορροπητής απλώς επιλέγει τυχαίους κεντρικούς υπολογιστές με ένα ζευγάρι και ανεβάζει σε αυτόν. Ταυτόχρονα, κάνει φυσικά υγειονομικούς ελέγχους και φροντίζει να μην πέσει έξω το αυτοκίνητο. Εκείνοι. ανεβάζει φωτογραφίες μόνο σε έναν ζωντανό διακομιστή και, στη συνέχεια, μέσω μιας ασύγχρονης ουράς, όλα αντιγράφονται στον γείτονά του. Με το upload όλα είναι εξαιρετικά απλά.
Το εγχείρημα είναι λίγο πιο δύσκολο.
Ο Lua μας βοήθησε εδώ, γιατί μπορεί να είναι δύσκολο να κάνουμε τέτοια λογική στο vanilla NGINX. Πρώτα κάνουμε ένα αίτημα στον πρώτο διακομιστή, για να δούμε αν υπάρχει η φωτογραφία, γιατί ενδεχομένως θα μπορούσε να μεταφορτωθεί, για παράδειγμα, σε έναν γείτονα, αλλά δεν έχει φτάσει ακόμα εδώ. Αν υπάρχει η φωτογραφία, είναι καλό. Το δίνουμε αμέσως στον πελάτη και, ενδεχομένως, το αποθηκεύουμε προσωρινά.
Εάν δεν υπάρχει, απλώς κάνουμε ένα αίτημα στον γείτονά μας και είμαστε εγγυημένοι ότι θα το λάβουμε από εκεί.
Οτι. και πάλι μπορούμε να πούμε: μπορεί να υπάρχουν προβλήματα με την απόδοση, επειδή υπάρχουν συνεχείς διαδρομές μετ' επιστροφής - η φωτογραφία ανέβηκε, δεν είναι εδώ, κάνουμε δύο αιτήματα αντί για ένα, αυτό θα πρέπει να λειτουργήσει αργά.
Στην περίπτωσή μας, αυτό δεν λειτουργεί αργά.
Συλλέγουμε ένα σωρό μετρήσεις σε αυτό το σύστημα και το έξυπνο ποσοστό υπό όρους ενός τέτοιου μηχανισμού είναι περίπου 95%. Εκείνοι. Η καθυστέρηση αυτού του αντιγράφου ασφαλείας είναι μικρή και λόγω αυτού είμαστε σχεδόν εγγυημένοι, αφού ανέβει η φωτογραφία, θα την τραβήξουμε την πρώτη φορά και δεν θα χρειαστεί να πάμε πουθενά δύο φορές.
Λοιπόν, τι άλλο έχουμε που είναι πραγματικά υπέροχο;
Προηγουμένως, είχαμε την κύρια κατάτμηση αντιγράφων ασφαλείας και διαβάζαμε από αυτά διαδοχικά. Εκείνοι. Πάντα ψάχναμε πρώτα στο κύριο και μετά στο εφεδρικό. Ήταν μια κίνηση.
Τώρα χρησιμοποιούμε την ανάγνωση από δύο μηχανές ταυτόχρονα. Διανέμουμε αιτήματα χρησιμοποιώντας Round Robin. Σε ένα μικρό ποσοστό των περιπτώσεων κάνουμε δύο αιτήματα. Αλλά συνολικά, τώρα έχουμε διπλάσιο απόθεμα ανάγνωσης από ό,τι πριν. Και μειώθηκε πολύ το φορτίο τόσο στα μηχανήματα αποστολής όσο και απευθείας στα αποθηκευτικά μηχανήματα, που είχαμε και εμείς τότε.
Όσο για την ανοχή σφαλμάτων. Στην πραγματικότητα, γι' αυτό παλέψαμε κυρίως. Με ανοχή σφαλμάτων, όλα έγιναν υπέροχα εδώ.
Ένα αυτοκίνητο χαλάει.
Κανένα πρόβλημα! Ένας μηχανικός συστήματος μπορεί να μην ξυπνήσει καν τη νύχτα, θα περιμένει μέχρι το πρωί, δεν θα συμβεί τίποτα κακό.
Αν ακόμη και αν αυτό το μηχάνημα αποτύχει, η ουρά είναι εκτός λειτουργίας, δεν υπάρχουν προβλήματα, το κούτσουρο απλώς θα συγκεντρωθεί πρώτα στο ζωντανό μηχάνημα και μετά θα προστεθεί στην ουρά και μετά στο αυτοκίνητο που θα τεθεί σε λειτουργία μετά από κάποιο χρονικό διάστημα.
Το ίδιο και με τη συντήρηση. Απλώς απενεργοποιούμε ένα από τα μηχανήματα, το τραβάμε χειροκίνητα από όλες τις πισίνες, σταματά να λαμβάνει κίνηση, κάνουμε κάποιο είδος συντήρησης, επεξεργαζόμαστε κάτι, μετά το επιστρέφουμε σε υπηρεσία και αυτό το αντίγραφο ασφαλείας φτάνει πολύ γρήγορα. Εκείνοι. ανά ημέρα, ο χρόνος διακοπής λειτουργίας ενός αυτοκινήτου φτάνει μέσα σε λίγα λεπτά. Αυτό είναι πραγματικά πολύ λίγο. Με ανοχή σφαλμάτων, ξαναλέω, όλα είναι ωραία εδώ.
Ποια συμπεράσματα μπορούν να εξαχθούν από αυτό το σύστημα απολύσεων;
Έχουμε ανοχή σφαλμάτων.
Εύχρηστος. Δεδομένου ότι τα μηχανήματα διαθέτουν τοπικούς σκληρούς δίσκους, αυτό είναι πολύ πιο βολικό από επιχειρησιακή άποψη για τους μηχανικούς που εργάζονται με αυτό.
Πήραμε διπλό επίδομα ανάγνωσης.
Αυτό είναι ένα πολύ καλό μπόνους εκτός από την ανοχή σφαλμάτων.
Υπάρχουν όμως και προβλήματα. Τώρα έχουμε μια πολύ πιο περίπλοκη ανάπτυξη ορισμένων χαρακτηριστικών που σχετίζονται με αυτό, επειδή το σύστημα έχει γίνει 100% τελικά συνεπές.
Πρέπει, ας πούμε, σε κάποια εργασία στο παρασκήνιο, να σκεφτόμαστε συνεχώς: "Σε ποιο διακομιστή τρέχουμε τώρα;", "Υπάρχει πραγματικά μια τρέχουσα φωτογραφία εδώ;" και τα λοιπά. Αυτό, φυσικά, έχει ολοκληρωθεί, και για τον προγραμματιστή που γράφει επιχειρηματική λογική, είναι διαφανές. Ωστόσο, αυτό το μεγάλο περίπλοκο στρώμα έχει εμφανιστεί. Αλλά είμαστε έτοιμοι να το ανεχτούμε με αντάλλαγμα τα καλούδια που λάβαμε από αυτό.
Και εδώ προκύπτει πάλι κάποια σύγκρουση.
Είπα στην αρχή ότι το να αποθηκεύεις τα πάντα σε τοπικούς σκληρούς δίσκους είναι κακό. Και τώρα λέω ότι μας άρεσε.
Ναι, πράγματι, με την πάροδο του χρόνου η κατάσταση έχει αλλάξει πολύ και τώρα αυτή η προσέγγιση έχει πολλά πλεονεκτήματα. Πρώτον, έχουμε πολύ απλούστερη λειτουργία.
Δεύτερον, είναι πιο παραγωγικό, επειδή δεν έχουμε αυτούς τους αυτόματους ελεγκτές ή συνδέσεις με ράφια δίσκων.
Υπάρχει ένας τεράστιος όγκος μηχανημάτων εκεί, και αυτοί είναι μόνο μερικοί δίσκοι που συναρμολογούνται εδώ στο μηχάνημα σε μια επιδρομή.
Υπάρχουν όμως και μειονεκτήματα.
Αυτό είναι περίπου 1,5 φορές πιο ακριβό από τη χρήση SAN ακόμα και σε σημερινές τιμές. Ως εκ τούτου, αποφασίσαμε να μην μετατρέψουμε τολμηρά ολόκληρο το μεγάλο μας σύμπλεγμα σε αυτοκίνητα με τοπικούς σκληρούς δίσκους και αποφασίσαμε να αφήσουμε μια υβριδική λύση.
Οι μισές από τις μηχανές μας λειτουργούν με σκληρούς δίσκους (καλά, όχι οι μισοί - πιθανώς το 30 τοις εκατό). Και τα υπόλοιπα είναι παλιά αυτοκίνητα που είχαν το πρώτο πρόγραμμα κρατήσεων. Απλώς τα επανατοποθετήσαμε, αφού δεν χρειαζόμασταν νέα δεδομένα ή οτιδήποτε άλλο, απλώς μετακινήσαμε τα mount από έναν φυσικό κεντρικό υπολογιστή σε δύο.
Και τώρα έχουμε ένα μεγάλο απόθεμα ανάγνωσης, και το επεκτείναμε. Αν νωρίτερα τοποθετούσαμε μια αποθήκευση σε ένα μηχάνημα, τώρα τοποθετούμε τέσσερις, για παράδειγμα, σε ένα ζεύγος. Και δουλεύει μια χαρά.
Ας κάνουμε μια σύντομη περίληψη του τι καταφέραμε, για τι παλέψαμε και αν τα καταφέραμε.
Αποτελέσματα της
Έχουμε χρήστες - έως και 33 εκατομμύρια.
Έχουμε τρία σημεία παρουσίας - Πράγα, Μαϊάμι, Χονγκ Κονγκ.
Περιέχουν ένα επίπεδο προσωρινής αποθήκευσης, το οποίο αποτελείται από αυτοκίνητα με γρήγορους τοπικούς δίσκους (SSD), στα οποία τρέχουν απλά μηχανήματα από το NGINX, το access.log του και οι δαίμονες Python, που επεξεργάζονται όλα αυτά και διαχειρίζονται την κρυφή μνήμη.
Εάν θέλετε, είστε στο έργο σας, εάν οι φωτογραφίες δεν είναι τόσο κρίσιμες για εσάς όσο για εμάς ή εάν ο έλεγχος αντιστάθμισης έναντι της ταχύτητας ανάπτυξης και του κόστους των πόρων είναι προς την άλλη κατεύθυνση για εσάς, τότε μπορείτε να το αντικαταστήσετε με ασφάλεια με ένα CDN, τα σύγχρονα CDN είναι καλά.
Ακολουθεί το επίπεδο αποθήκευσης, στο οποίο έχουμε συστάδες ζευγών μηχανημάτων που δημιουργούν αντίγραφα ασφαλείας μεταξύ τους, τα αρχεία αντιγράφονται ασύγχρονα από το ένα στο άλλο όποτε αλλάζουν.
Επιπλέον, ορισμένα από αυτά τα μηχανήματα λειτουργούν με τοπικούς σκληρούς δίσκους.
Ορισμένα από αυτά τα μηχανήματα είναι συνδεδεμένα με SAN.
Και, αφενός, είναι πιο βολικό στη χρήση και λίγο πιο παραγωγικό, αφετέρου, είναι βολικό όσον αφορά την πυκνότητα τοποθέτησης και την τιμή ανά gigabyte.
Αυτή είναι μια τόσο σύντομη επισκόπηση της αρχιτεκτονικής του τι πήραμε και πώς αναπτύχθηκε όλο αυτό.
Μερικές ακόμα συμβουλές από τον καπετάνιο, πολύ απλές.
Πρώτον, αν ξαφνικά αποφασίσετε ότι πρέπει επειγόντως να βελτιώσετε τα πάντα στην υποδομή φωτογραφιών σας, μετρήστε πρώτα, γιατί ίσως τίποτα δεν χρειάζεται να βελτιωθεί.
Επιτρέψτε μου να σας δώσω ένα παράδειγμα. Έχουμε ένα σύμπλεγμα μηχανημάτων που στέλνουν φωτογραφίες από συνημμένα σε συνομιλίες, και το πρόγραμμα λειτουργεί εκεί από το 2009 και κανείς δεν υποφέρει από αυτό. Όλοι είναι καλά, σε όλους αρέσουν τα πάντα.
Για να μετρήσετε, κρεμάστε πρώτα ένα σωρό μετρήσεις, δείτε τις και μετά αποφασίστε με τι είστε δυσαρεστημένοι και τι πρέπει να βελτιωθεί. Για να το μετρήσουμε αυτό, έχουμε ένα δροσερό εργαλείο που ονομάζεται Pinba.
Σας επιτρέπει να συλλέγετε πολύ λεπτομερή στατιστικά στοιχεία από το NGINX για κάθε αίτημα και κωδικούς απάντησης, καθώς και κατανομή των χρόνων - ό,τι θέλετε. Έχει δεσμεύσεις με όλα τα είδη διαφορετικών συστημάτων ανάλυσης και, στη συνέχεια, μπορείτε να τα δείτε όλα όμορφα.
Πρώτα το μετρήσαμε, μετά το βελτιώσαμε.
Περαιτέρω. Βελτιστοποιούμε την ανάγνωση με προσωρινή μνήμη, τη γραφή με τη διαμοιρασμό, αλλά αυτό είναι ένα προφανές σημείο.
Περαιτέρω. Εάν μόλις τώρα ξεκινάτε να χτίζετε το σύστημά σας, τότε είναι πολύ καλύτερο να κάνετε φωτογραφίες ως αμετάβλητα αρχεία. Επειδή χάνετε αμέσως μια ολόκληρη κατηγορία προβλημάτων με την ακύρωση της προσωρινής μνήμης, με το πώς η λογική πρέπει να βρει τη σωστή έκδοση της φωτογραφίας κ.λπ.
Ας υποθέσουμε ότι ανεβάσατε εκατό, μετά το περιστρέψατε, κάνατε το έτσι ώστε να είναι ένα φυσικά διαφορετικό αρχείο. Εκείνοι. δεν χρειάζεται να σκεφτείς: τώρα θα εξοικονομήσω λίγο χώρο, θα το γράψω στο ίδιο αρχείο, θα αλλάξω την έκδοση. Αυτό δεν λειτουργεί πάντα καλά και προκαλεί πολλούς πονοκεφάλους αργότερα.
Επόμενο σημείο. Σχετικά με την αλλαγή μεγέθους on the fly.
Παλαιότερα, όταν οι χρήστες ανέβαζαν μια φωτογραφία, κόβαμε αμέσως μια ολόκληρη δέσμη μεγεθών για όλες τις περιπτώσεις, για διαφορετικούς πελάτες, και ήταν όλα στο δίσκο. Τώρα το έχουμε εγκαταλείψει αυτό.
Αφήσαμε μόνο τρία κύρια μεγέθη: μικρό, μεσαίο και μεγάλο. Απλώς μειώνουμε την κλίμακα όλων των άλλων από το μέγεθος που βρίσκεται πίσω από αυτό που μας ζητήθηκε στο Uport, απλώς κάνουμε τη μείωση της κλίμακας και το δίνουμε στον χρήστη.
Η CPU του επιπέδου προσωρινής αποθήκευσης εδώ αποδεικνύεται πολύ φθηνότερη από ό,τι αν αναδημιουργούσαμε συνεχώς αυτά τα μεγέθη σε κάθε χώρο αποθήκευσης. Ας υποθέσουμε ότι θέλουμε να προσθέσουμε ένα νέο, αυτό θα διαρκέσει ένα μήνα - εκτελέστε ένα σενάριο παντού που θα τα έκανε όλα αυτά τακτοποιημένα, χωρίς να καταστρέψει το σύμπλεγμα. Εκείνοι. Εάν έχετε τη δυνατότητα να επιλέξετε τώρα, είναι καλύτερο να κάνετε όσο το δυνατόν λιγότερα φυσικά μεγέθη, αλλά έτσι ώστε τουλάχιστον κάποια διανομή να είναι, ας πούμε, τρία. Και όλα τα άλλα μπορούν απλά να αλλάξουν το μέγεθος αμέσως χρησιμοποιώντας έτοιμες μονάδες. Είναι όλα πολύ εύκολα και προσβάσιμα τώρα.
Και η σταδιακή ασύγχρονη δημιουργία αντιγράφων ασφαλείας είναι καλή.
Όπως έχει δείξει η πρακτική μας, αυτό το σχήμα λειτουργεί εξαιρετικά με την καθυστερημένη αντιγραφή αλλαγμένων αρχείων.
Το τελευταίο σημείο είναι επίσης προφανές. Αν η υποδομή σας δεν έχει τέτοια προβλήματα τώρα, αλλά υπάρχει κάτι που μπορεί να σπάσει, σίγουρα θα σπάσει όταν γίνει λίγο παραπάνω. Επομένως, είναι καλύτερο να το σκεφτείτε εκ των προτέρων και να μην αντιμετωπίσετε προβλήματα με αυτό. Μόνο αυτό ήθελα να πω.
Επαφές
»
»
Αυτή η έκθεση είναι μια απομαγνητοφώνηση μιας από τις καλύτερες ομιλίες στο συνέδριο των προγραμματιστών συστημάτων υψηλού φορτίου . Απομένει λιγότερο από ένας μήνας μέχρι το συνέδριο HighLoad++ 2017.
Το έχουμε ήδη έτοιμο , το πρόγραμμα διαμορφώνεται τώρα ενεργά.
Φέτος συνεχίζουμε να εξερευνούμε το θέμα των αρχιτεκτονικών και της κλιμάκωσης:
- / Igor Vasiliev
- / Ντμίτρι Εγκόροφ
- / Ανατόλι Πλασκόφσκι
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Χρησιμοποιούμε επίσης μερικά από αυτά τα υλικά στο διαδικτυακό μας εκπαιδευτικό σεμινάριο για την ανάπτυξη συστημάτων υψηλού φορτίου είναι μια αλυσίδα από ειδικά επιλεγμένα γράμματα, άρθρα, υλικά, βίντεο. Το σχολικό μας βιβλίο περιέχει ήδη περισσότερα από 30 μοναδικά υλικά. Συνδέω-συωδεομαι!
Πηγή: www.habr.com