Πολλές νεοφυείς επιχειρήσεις έχουν περάσει από αυτό: πλήθος νέων χρηστών εγγράφονται καθημερινά και η ομάδα ανάπτυξης αγωνίζεται να διατηρήσει την υπηρεσία σε λειτουργία.
Είναι ωραίο πρόβλημα, αλλά υπάρχουν ελάχιστες σαφείς πληροφορίες στον Ιστό σχετικά με το πώς να κλιμακώσετε προσεκτικά μια εφαρμογή Ιστού από το μηδέν σε εκατοντάδες χιλιάδες χρήστες. Τυπικά υπάρχουν είτε λύσεις πυρκαγιάς είτε λύσεις συμφόρησης (και συχνά και τα δύο). Επομένως, οι άνθρωποι χρησιμοποιούν μάλλον κλισέ τεχνικές για να κλιμακώσουν το ερασιτεχνικό τους έργο σε κάτι πραγματικά σοβαρό.
Ας προσπαθήσουμε να φιλτράρουμε τις πληροφορίες και να γράψουμε τον βασικό τύπο. Θα κλιμακώσουμε τον νέο μας ιστότοπο κοινής χρήσης φωτογραφιών Graminsta βήμα προς βήμα από 1 σε 100 χρήστες.
Ας γράψουμε ποιες συγκεκριμένες ενέργειες πρέπει να γίνουν όταν το κοινό αυξάνεται σε 10, 100, 1000, 10 και 000 άτομα.
1 χρήστης: 1 μηχανή
Σχεδόν κάθε εφαρμογή, είτε πρόκειται για ιστότοπο είτε για κινητή εφαρμογή, έχει τρία βασικά στοιχεία:
- API
- βάση δεδομένων
- πελάτης (η ίδια η εφαρμογή για κινητά ή ιστότοπος)
Η βάση δεδομένων αποθηκεύει μόνιμα δεδομένα. Το API εξυπηρετεί αιτήματα προς και γύρω από αυτά τα δεδομένα. Ο πελάτης μεταδίδει δεδομένα στον χρήστη.
Κατέληξα στο συμπέρασμα ότι είναι πολύ πιο εύκολο να μιλήσουμε για την κλιμάκωση μιας εφαρμογής εάν, από αρχιτεκτονική άποψη, ο πελάτης και οι οντότητες API είναι τελείως διαχωρισμένοι.
Όταν ξεκινάμε για πρώτη φορά τη δημιουργία μιας εφαρμογής, και τα τρία στοιχεία μπορούν να εκτελεστούν στον ίδιο διακομιστή. Κατά κάποιο τρόπο, αυτό είναι παρόμοιο με το περιβάλλον ανάπτυξης μας: ένας μηχανικός εκτελεί τη βάση δεδομένων, το API και τον πελάτη στον ίδιο υπολογιστή.
Θεωρητικά, θα μπορούσαμε να το αναπτύξουμε στο σύννεφο σε μία μόνο παρουσία DigitalOcean Droplet ή AWS EC2, όπως φαίνεται παρακάτω:
Με αυτό, αν υπάρχουν περισσότεροι από ένας χρήστες σε έναν ιστότοπο, είναι σχεδόν πάντα λογικό να αφιερώνεται ένα επίπεδο βάσης δεδομένων.
10 χρήστες: μετακίνηση της βάσης δεδομένων σε ξεχωριστό επίπεδο
Ο διαχωρισμός της βάσης δεδομένων σε διαχειριζόμενες υπηρεσίες όπως το Amazon RDS ή η Digital Ocean Managed Database θα μας εξυπηρετήσει καλά για μεγάλο χρονικό διάστημα. Είναι λίγο πιο ακριβό από την αυτο-φιλοξενία σε ένα μόνο μηχάνημα ή μια παρουσία EC2, αλλά με αυτές τις υπηρεσίες λαμβάνετε πολλές χρήσιμες επεκτάσεις από το κουτί που θα σας φανούν χρήσιμες στο μέλλον: δημιουργία αντιγράφων ασφαλείας πολλών περιοχών, ανάγνωση αντιγράφων, αυτόματη αντίγραφα ασφαλείας και πολλά άλλα.
Έτσι φαίνεται το σύστημα τώρα:
100 χρήστες: μετακίνηση του πελάτη σε ξεχωριστό επίπεδο
Ευτυχώς, στους πρώτους χρήστες μας άρεσε πολύ η εφαρμογή μας. Η κίνηση γίνεται πιο σταθερή, οπότε ήρθε η ώρα να μετακινήσετε τον πελάτη σε ξεχωριστό επίπεδο. πρέπει να σημειωθεί ότι διαχωρισμός Οι οντότητες είναι μια βασική πτυχή της δημιουργίας μιας επεκτάσιμης εφαρμογής. Καθώς ένα μέρος του συστήματος λαμβάνει περισσότερη επισκεψιμότητα, μπορούμε να το χωρίσουμε για να ελέγξουμε τον τρόπο με τον οποίο η υπηρεσία κλιμακώνεται με βάση συγκεκριμένα μοτίβα κυκλοφορίας.
Αυτός είναι ο λόγος που μου αρέσει να θεωρώ τον πελάτη ξεχωριστό από το API. Αυτό καθιστά πολύ εύκολο να σκεφτείτε την ανάπτυξη για πολλές πλατφόρμες: ιστός, ιστός για κινητά, iOS, Android, εφαρμογές για υπολογιστές, υπηρεσίες τρίτων κ.λπ. Είναι όλοι απλώς πελάτες που χρησιμοποιούν το ίδιο API.
Για παράδειγμα, τώρα οι χρήστες μας ζητούν συχνότερα να κυκλοφορήσουν μια εφαρμογή για κινητά. Εάν διαχωρίσετε τις οντότητες πελάτη και API, αυτό γίνεται ευκολότερο.
Έτσι μοιάζει ένα τέτοιο σύστημα:
1000 χρήστες: προσθήκη load balancer
Η κατάσταση βελτιώνεται. Οι χρήστες του Graminsta ανεβάζουν όλο και περισσότερες φωτογραφίες. Ο αριθμός των εγγραφών αυξάνεται επίσης. Ο μοναχικός μας διακομιστής API δυσκολεύεται να παρακολουθήσει όλη την επισκεψιμότητα. Χρειάζεστε περισσότερο σίδηρο!
Το Load balancer είναι μια πολύ ισχυρή ιδέα. Η βασική ιδέα είναι ότι βάζουμε έναν εξισορροπητή φορτίου μπροστά από το API και κατανέμει την κίνηση σε μεμονωμένες περιπτώσεις υπηρεσιών. Αυτός είναι ο τρόπος με τον οποίο κλιμακώνουμε οριζόντια, δηλαδή προσθέτουμε περισσότερους διακομιστές με τον ίδιο κώδικα, αυξάνοντας τον αριθμό των αιτημάτων που μπορούμε να επεξεργαστούμε.
Θα τοποθετήσουμε ξεχωριστούς εξισορροπητές φορτίου μπροστά από το πρόγραμμα-πελάτη ιστού και μπροστά από το API. Αυτό σημαίνει ότι μπορείτε να εκτελέσετε πολλές παρουσίες με κώδικα API και κώδικα πελάτη web. Το πρόγραμμα εξισορρόπησης φορτίου θα κατευθύνει αιτήματα στον διακομιστή που είναι λιγότερο φορτωμένος.
Εδώ έχουμε ένα άλλο σημαντικό πλεονέκτημα - πλεονασμό. Όταν μια παρουσία αποτυγχάνει (ίσως υπερφορτωθεί ή συντρίβεται), μένουμε με άλλες που συνεχίζουν να ανταποκρίνονται σε εισερχόμενα αιτήματα. Εάν λειτουργούσε μόνο ένα παράδειγμα, τότε σε περίπτωση αποτυχίας ολόκληρο το σύστημα θα κολλούσε.
Ο εξισορροπητής φορτίου παρέχει επίσης αυτόματη κλιμάκωση. Μπορούμε να το διαμορφώσουμε ώστε να αυξάνει τον αριθμό των περιπτώσεων πριν από τη μέγιστη φόρτωση και να τον μειώνει όταν όλοι οι χρήστες κοιμούνται.
Με έναν εξισορροπητή φορτίου, το επίπεδο API μπορεί να κλιμακωθεί σχεδόν επ' αόριστον, προσθέτοντας απλώς νέες παρουσίες καθώς αυξάνεται ο αριθμός των αιτημάτων.
Σημείωση. Αυτήν τη στιγμή το σύστημά μας μοιάζει πολύ με αυτό που προσφέρουν οι εταιρείες PaaS όπως η Heroku ή η Elastic Beanstalk στο AWS (γι' αυτό είναι τόσο δημοφιλείς). Το Heroku τοποθετεί τη βάση δεδομένων σε έναν ξεχωριστό κεντρικό υπολογιστή, διαχειρίζεται έναν εξισορροπητή φορτίου αυτόματης κλιμάκωσης και σας επιτρέπει να φιλοξενήσετε τον πελάτη Ιστού ξεχωριστά από το API. Αυτός είναι ένας πολύ καλός λόγος για να χρησιμοποιήσετε το Heroku για έργα πρώιμου σταδίου ή startups - λαμβάνετε όλες τις βασικές υπηρεσίες από το κουτί.
10 χρήστες: CDN
Ίσως έπρεπε να το είχαμε κάνει από την αρχή. Η επεξεργασία αιτημάτων και η αποδοχή νέων φωτογραφιών αρχίζει να επιβαρύνει πάρα πολύ τους διακομιστές μας.
Σε αυτό το στάδιο, πρέπει να χρησιμοποιήσετε μια υπηρεσία cloud για την αποθήκευση στατικού περιεχομένου - εικόνων, βίντεο και πολλά άλλα (AWS S3 ή Digital Ocean Spaces). Γενικά, το API μας θα πρέπει να αποφεύγει να χειρίζεται πράγματα όπως η προβολή εικόνων και η μεταφόρτωση εικόνων στον διακομιστή.
Ένα άλλο πλεονέκτημα της φιλοξενίας cloud είναι το CDN (το AWS αποκαλεί αυτό το πρόσθετο Cloudfront, αλλά πολλοί πάροχοι αποθήκευσης cloud το προσφέρουν εκτός συσκευασίας). Το CDN αποθηκεύει αυτόματα τις εικόνες μας σε διάφορα κέντρα δεδομένων σε όλο τον κόσμο.
Αν και το κύριο κέντρο δεδομένων μας μπορεί να βρίσκεται στο Οχάιο, εάν κάποιος ζητήσει μια εικόνα από την Ιαπωνία, ο πάροχος cloud θα δημιουργήσει ένα αντίγραφο και θα το αποθηκεύσει στο ιαπωνικό κέντρο δεδομένων του. Το επόμενο άτομο που θα ζητήσει αυτήν την εικόνα στην Ιαπωνία θα τη λάβει πολύ πιο γρήγορα. Αυτό είναι σημαντικό όταν εργαζόμαστε με μεγάλα αρχεία, όπως φωτογραφίες ή βίντεο, που χρειάζονται πολύ χρόνο για τη λήψη και τη μετάδοση σε ολόκληρο τον πλανήτη.
100 χρήστες: κλιμάκωση του επιπέδου δεδομένων
Το CDN βοήθησε πολύ: η επισκεψιμότητα αυξάνεται με πλήρη ταχύτητα. Ο διάσημος video blogger Mavid Mobrick μόλις εγγράφηκε μαζί μας και δημοσίευσε την «ιστορία» του, όπως λένε. Χάρη στον εξισορροπητή φορτίου, η χρήση της CPU και της μνήμης στους διακομιστές API διατηρείται σε χαμηλά επίπεδα (εκτελούνται δέκα περιπτώσεις API), αλλά αρχίζουμε να λαμβάνουμε πολλά χρονικά όρια για αιτήματα... από πού προέρχονται αυτές οι καθυστερήσεις;
Ψάχνοντας λίγο τις μετρήσεις, βλέπουμε ότι η CPU στον διακομιστή της βάσης δεδομένων είναι φορτωμένη κατά 80-90%. Είμαστε στο όριο.
Η κλιμάκωση του επιπέδου δεδομένων είναι ίσως το πιο δύσκολο μέρος της εξίσωσης. Οι διακομιστές API εξυπηρετούν αιτήματα χωρίς κατάσταση, επομένως απλώς προσθέτουμε περισσότερες παρουσίες API. Μύτη η πλειοψηφία οι βάσεις δεδομένων δεν μπορούν να το κάνουν αυτό. Θα μιλήσουμε για δημοφιλή συστήματα διαχείρισης σχεσιακών βάσεων δεδομένων (PostgreSQL, MySQL κ.λπ.).
Προσωρινή αποθήκευση
Ένας από τους ευκολότερους τρόπους για να αυξήσουμε την απόδοση της βάσης δεδομένων μας είναι να εισαγάγουμε ένα νέο στοιχείο: το επίπεδο κρυφής μνήμης. Η πιο συνηθισμένη μέθοδος προσωρινής αποθήκευσης είναι ένας χώρος αποθήκευσης εγγραφών κλειδιού-τιμής στη μνήμη, όπως το Redis ή το Memcached. Τα περισσότερα cloud έχουν μια διαχειριζόμενη έκδοση αυτών των υπηρεσιών: Elasticache στο AWS και Memorystore στο Google Cloud.
Η κρυφή μνήμη είναι χρήσιμη όταν μια υπηρεσία πραγματοποιεί πολλές επαναλαμβανόμενες κλήσεις στη βάση δεδομένων για να ανακτήσει τις ίδιες πληροφορίες. Ουσιαστικά, έχουμε πρόσβαση στη βάση δεδομένων μόνο μία φορά, αποθηκεύουμε τις πληροφορίες στην κρυφή μνήμη και δεν τις αγγίζουμε ξανά.
Για παράδειγμα, στην υπηρεσία μας Graminsta, κάθε φορά που κάποιος πηγαίνει στη σελίδα προφίλ του αστεριού Mobrik, ο διακομιστής API ρωτά τη βάση δεδομένων για πληροφορίες από το προφίλ του. Αυτό συμβαίνει ξανά και ξανά. Δεδομένου ότι οι πληροφορίες προφίλ του Mobrik δεν αλλάζουν με κάθε αίτημα, είναι εξαιρετικό για αποθήκευση στην κρυφή μνήμη.
Θα αποθηκεύσουμε τα αποτελέσματα από τη βάση δεδομένων στο Redis κατά κλειδί user:id με περίοδο ισχύος 30 δευτερολέπτων. Τώρα, όταν κάποιος πηγαίνει στο προφίλ του Mobrik, πρώτα τσεκάρουμε το Redis και αν υπάρχουν τα δεδομένα, απλά τα μεταφέρουμε απευθείας από το Redis. Τώρα τα αιτήματα στο πιο δημοφιλές προφίλ στον ιστότοπο ουσιαστικά δεν φορτώνουν τη βάση δεδομένων μας.
Ένα άλλο πλεονέκτημα των περισσότερων υπηρεσιών προσωρινής αποθήκευσης είναι ότι είναι ευκολότερο να κλιμακωθούν από τους διακομιστές βάσεων δεδομένων. Το Redis διαθέτει ενσωματωμένη λειτουργία Redis Cluster. Παρόμοιο με έναν εξισορροπητή φορτίου, σας επιτρέπει να διανείμετε την κρυφή μνήμη Redis σε πολλαπλά μηχανήματα (σε χιλιάδες διακομιστές εάν χρειάζεται).
Σχεδόν όλες οι εφαρμογές μεγάλης κλίμακας χρησιμοποιούν προσωρινή αποθήκευση· είναι απολύτως αναπόσπαστο μέρος ενός γρήγορου API. Η ταχύτερη επεξεργασία ερωτημάτων και ο πιο παραγωγικός κώδικας είναι όλα σημαντικά, αλλά χωρίς προσωρινή μνήμη είναι σχεδόν αδύνατο να κλιμακωθεί μια υπηρεσία σε εκατομμύρια χρήστες.
Διαβάστε αντίγραφα
Όταν ο αριθμός των ερωτημάτων στη βάση δεδομένων έχει αυξηθεί πολύ, ένα ακόμη πράγμα που μπορούμε να κάνουμε είναι να προσθέσουμε αντίγραφα ανάγνωσης στο σύστημα διαχείρισης βάσης δεδομένων. Με τις διαχειριζόμενες υπηρεσίες που περιγράφονται παραπάνω, αυτό μπορεί να γίνει με ένα κλικ. Το αντίγραφο ανάγνωσης θα παραμείνει τρέχον στην κύρια βάση δεδομένων και είναι διαθέσιμο για δηλώσεις SELECT.
Εδώ είναι το σύστημά μας τώρα:
Επόμενα βήματα
Καθώς η εφαρμογή συνεχίζει να κλιμακώνεται, θα συνεχίσουμε να διαχωρίζουμε τις υπηρεσίες για να τις κλιμακώνουμε ανεξάρτητα. Για παράδειγμα, εάν αρχίσουμε να χρησιμοποιούμε Websockets, τότε είναι λογικό να τραβήξουμε τον κώδικα επεξεργασίας Websockets σε μια ξεχωριστή υπηρεσία. Μπορούμε να το τοποθετήσουμε σε νέες περιπτώσεις πίσω από το δικό μας πρόγραμμα εξισορρόπησης φορτίου, το οποίο μπορεί να αυξηθεί και να μειωθεί με βάση τις ανοιχτές συνδέσεις Websockets και ανεξάρτητα από τον αριθμό των αιτημάτων HTTP.
Θα συνεχίσουμε επίσης να καταπολεμούμε τους περιορισμούς σε επίπεδο βάσης δεδομένων. Είναι σε αυτό το στάδιο που είναι καιρός να μελετήσουμε την κατάτμηση και τον διαμοιρασμό της βάσης δεδομένων. Και οι δύο προσεγγίσεις απαιτούν επιπλέον επιβάρυνση, αλλά σας επιτρέπουν να κλιμακώνετε τη βάση δεδομένων σχεδόν επ' αόριστον.
Θέλουμε επίσης να εγκαταστήσουμε μια υπηρεσία παρακολούθησης και ανάλυσης όπως το New Relic ή το Datadog. Αυτό θα σας βοηθήσει να εντοπίσετε αργά ερωτήματα και να κατανοήσετε πού χρειάζεται βελτίωση. Καθώς κλιμακώνουμε, θέλουμε να επικεντρωθούμε στην εύρεση σημείων συμφόρησης και στην εξάλειψή τους—συχνά χρησιμοποιώντας μερικές από τις ιδέες από προηγούμενες ενότητες.
πηγές
Αυτή η ανάρτηση είναι εμπνευσμένη από ένα από τα . Ήθελα να κάνω το άρθρο λίγο πιο συγκεκριμένο για τα αρχικά στάδια των έργων και να το λύσω από έναν πωλητή. Φροντίστε να διαβάσετε αν σας ενδιαφέρει αυτό το θέμα.
Υποσημειώσεις
- Αν και παρόμοια ως προς την κατανομή φορτίου σε πολλαπλές περιπτώσεις, η υποκείμενη υλοποίηση ενός συμπλέγματος Redis είναι πολύ διαφορετική από έναν εξισορροπητή φορτίου.
Πηγή: www.habr.com