Κάπως, ιστορικά, ο κλάδος της πληροφορικής χωρίζεται σε δύο στρατόπεδα υπό όρους για οποιονδήποτε λόγο: σε αυτούς που είναι «υπέρ» και σε αυτούς που είναι «κατά». Επιπλέον, το αντικείμενο των διαφορών μπορεί να είναι εντελώς αυθαίρετο. Ποιο λειτουργικό σύστημα είναι καλύτερο: Win ή Linux; Σε smartphone Android ή iOS; Πρέπει να αποθηκεύσετε τα πάντα στα σύννεφα ή να τα τοποθετήσετε σε κρύο χώρο αποθήκευσης RAID και να βάλετε τις βίδες σε ένα χρηματοκιβώτιο; Οι άνθρωποι της PHP έχουν το δικαίωμα να ονομάζονται προγραμματιστές; Αυτές οι διαφωνίες έχουν, κατά καιρούς, αποκλειστικά υπαρξιακό χαρακτήρα και δεν έχουν άλλη βάση από το αθλητικό ενδιαφέρον.
Έτυχε με την εμφάνιση των κοντέινερ και όλης αυτής της αγαπημένης κουζίνας με docker και conditional k8, ξεκίνησαν οι συζητήσεις "υπέρ" και "κατά" της χρήσης νέων δυνατοτήτων σε διάφορους τομείς του backend. (Ας κάνουμε κράτηση εκ των προτέρων ότι αν και ο Kubernetes θα υποδεικνύεται συχνότερα ως ενορχηστρωτής σε αυτήν τη συζήτηση, η επιλογή αυτού του συγκεκριμένου εργαλείου δεν είναι θεμελιώδους σημασίας. Αντίθετα, μπορείτε να αντικαταστήσετε οποιοδήποτε άλλο που σας φαίνεται πιο βολικό και οικείο .)
Και, όπως φαίνεται, αυτή θα ήταν μια απλή διαμάχη μεταξύ των δύο όψεων του ίδιου νομίσματος. Τόσο παράλογη και ανελέητη όσο η αιώνια αντιπαράθεση Win vs Linux, στην οποία οι επαρκείς άνθρωποι υπάρχουν κάπου στη μέση. Αλλά στην περίπτωση της μεταφοράς εμπορευματοκιβωτίων, δεν είναι όλα τόσο απλά. Συνήθως σε τέτοιες διαφωνίες δεν υπάρχει η σωστή πλευρά, αλλά στην περίπτωση "χρήσης" ή "μη χρήσης" κοντέινερ για την αποθήκευση βάσεων δεδομένων, όλα ανατρέπονται. Διότι από μια ορισμένη άποψη, τόσο οι υποστηρικτές όσο και οι πολέμιοι αυτής της προσέγγισης έχουν δίκιο.
Φωτεινή πλευρά
Το επιχείρημα του Light Side μπορεί να περιγραφεί εν συντομία με μια φράση: "Γεια, το 2k19 είναι έξω από το παράθυρο!" Ακούγεται σαν λαϊκισμός, φυσικά, αλλά αν εμβαθύνεις στην κατάσταση, έχει τα πλεονεκτήματά του. Ας τα τακτοποιήσουμε τώρα.
Ας υποθέσουμε ότι έχετε ένα μεγάλο έργο ιστού. Θα μπορούσε να είχε κατασκευαστεί αρχικά με βάση μια προσέγγιση μικροϋπηρεσιών, ή κάποια στιγμή έφτασε σε αυτό μέσω μιας εξελικτικής διαδρομής - αυτό δεν είναι πολύ σημαντικό, στην πραγματικότητα. Διασκορπίσατε το έργο μας σε ξεχωριστές μικροϋπηρεσίες, ρυθμίσατε την ενορχήστρωση, την εξισορρόπηση φορτίου και την κλιμάκωση. Και τώρα, με ήσυχη τη συνείδησή σας, πίνετε ένα μοχίτο σε μια αιώρα κατά τη διάρκεια εφέ χάμπρα αντί να σηκώνετε πεσμένους διακομιστές. Αλλά σε όλες τις ενέργειες πρέπει να είστε συνεπείς. Πολύ συχνά, μόνο η ίδια η εφαρμογή - ο κώδικας - είναι κοντέινερ. Τι άλλο έχουμε εκτός από κώδικα;
Σωστά, δεδομένα. Η καρδιά κάθε έργου είναι τα δεδομένα του: αυτό μπορεί να είναι είτε ένα τυπικό DBMS - MySQL, Postgre, MongoDB, είτε αποθήκευση που χρησιμοποιείται για αναζήτηση (ElasticSearch), αποθήκευση κλειδιού-τιμής για προσωρινή αποθήκευση - για παράδειγμα, redis, κ.λπ. Προς το παρόν δεν είμαστε Θα μιλήσουμε για παραμορφωμένες επιλογές υλοποίησης backend όταν η βάση δεδομένων διακόπτεται λόγω κακώς γραπτών ερωτημάτων, και αντ' αυτού θα μιλήσουμε για τη διασφάλιση της ανοχής σφαλμάτων αυτής της ίδιας της βάσης δεδομένων υπό φόρτωση πελάτη. Εξάλλου, όταν δεσμεύουμε την εφαρμογή μας σε κοντέινερ και της αφήνουμε να κλιμακωθεί ελεύθερα για να επεξεργαστεί οποιονδήποτε αριθμό εισερχόμενων αιτημάτων, αυτό φυσικά αυξάνει το φόρτο στη βάση δεδομένων.
Στην πραγματικότητα, το κανάλι πρόσβασης στη βάση δεδομένων και ο διακομιστής στον οποίο εκτελείται γίνονται το μάτι της βελόνας στο όμορφο backend μας με κοντέινερ. Ταυτόχρονα, το κύριο κίνητρο της εικονικοποίησης εμπορευματοκιβωτίων είναι η κινητικότητα και η ευελιξία της δομής, η οποία μας επιτρέπει να οργανώσουμε την κατανομή των φορτίων αιχμής σε ολόκληρη την υποδομή που έχουμε στη διάθεσή μας όσο πιο αποτελεσματικά γίνεται. Δηλαδή, εάν δεν δεσμεύσουμε σε εμπορευματοκιβώτια και δεν αναπτύξουμε όλα τα υπάρχοντα στοιχεία του συστήματος σε όλο το σύμπλεγμα, κάνουμε ένα πολύ σοβαρό λάθος.
Είναι πολύ πιο λογικό να συγκεντρώνουμε όχι μόνο την ίδια την εφαρμογή, αλλά και τις υπηρεσίες που είναι υπεύθυνες για την αποθήκευση δεδομένων. Ομαδοποιώντας και αναπτύσσοντας διακομιστές ιστού που λειτουργούν ανεξάρτητα και κατανέμουν το φορτίο μεταξύ τους στα k8, λύνουμε ήδη το πρόβλημα του συγχρονισμού δεδομένων - τα ίδια σχόλια σε αναρτήσεις, αν πάρουμε ως παράδειγμα κάποια μέσα ενημέρωσης ή πλατφόρμα ιστολογίου. Σε κάθε περίπτωση, έχουμε μια intra-cluster, ακόμη και εικονική, αναπαράσταση της βάσης δεδομένων ως ExternalService. Το ερώτημα είναι ότι η ίδια η βάση δεδομένων δεν έχει ακόμη συγκεντρωθεί - οι διακομιστές ιστού που αναπτύσσονται στον κύβο λαμβάνουν πληροφορίες σχετικά με αλλαγές από τη βάση δεδομένων στατικής μάχης, η οποία περιστρέφεται χωριστά.
Αισθάνεστε μια σύλληψη; Χρησιμοποιούμε k8s ή Swarm για να κατανείμουμε το φορτίο και να αποφύγουμε τη συντριβή του κύριου διακομιστή web, αλλά δεν το κάνουμε αυτό για τη βάση δεδομένων. Αλλά αν η βάση δεδομένων καταρρεύσει, τότε ολόκληρη η υποδομή μας σε συμπλέγματα δεν έχει νόημα - τι ωφελούν οι κενές ιστοσελίδες που επιστρέφουν ένα σφάλμα πρόσβασης στη βάση δεδομένων;
Γι' αυτό είναι απαραίτητο να ομαδοποιηθούν όχι μόνο οι διακομιστές ιστού, όπως συνήθως γίνεται, αλλά και η υποδομή της βάσης δεδομένων. Μόνο έτσι μπορούμε να εξασφαλίσουμε μια δομή που λειτουργεί πλήρως σε μια ομάδα, αλλά ταυτόχρονα ανεξάρτητη μεταξύ τους. Επιπλέον, ακόμα κι αν το μισό από το backend μας «καταρρεύσει» υπό φόρτωση, το υπόλοιπο θα επιβιώσει και το σύστημα συγχρονισμού των βάσεων δεδομένων μεταξύ τους εντός του συμπλέγματος και η δυνατότητα ατελείωτης κλιμάκωσης και ανάπτυξης νέων συμπλεγμάτων θα σας βοηθήσουν να φτάσετε γρήγορα την απαιτούμενη χωρητικότητα - αν υπήρχαν ράφια στο κέντρο δεδομένων.
Επιπλέον, το μοντέλο βάσης δεδομένων που διανέμεται σε συμπλέγματα σας επιτρέπει να μεταφέρετε αυτήν ακριβώς τη βάση δεδομένων εκεί που χρειάζεται. Εάν μιλάμε για μια παγκόσμια υπηρεσία, τότε είναι εντελώς παράλογο να περιστρέφεται ένα σύμπλεγμα Ιστού κάπου στην περιοχή του Σαν Φρανσίσκο και ταυτόχρονα να στέλνετε πακέτα κατά την πρόσβαση σε μια βάση δεδομένων στην περιοχή της Μόσχας και πίσω.
Επίσης, η δημιουργία κοντέινερ της βάσης δεδομένων σας επιτρέπει να δημιουργήσετε όλα τα στοιχεία του συστήματος στο ίδιο επίπεδο αφαίρεσης. Το οποίο, με τη σειρά του, καθιστά δυνατή τη διαχείριση αυτού του συστήματος απευθείας από τον κώδικα, από προγραμματιστές, χωρίς την ενεργή συμμετοχή διαχειριστών. Οι προγραμματιστές θεώρησαν ότι χρειαζόταν ένα ξεχωριστό DBMS για το νέο υποέργο - εύκολο! έγραψε ένα αρχείο yaml, το ανέβασε στο σύμπλεγμα και τελειώσατε.
Και φυσικά, η εσωτερική λειτουργία είναι πολύ απλοποιημένη. Πες μου, πόσες φορές έχεις κλείσει τα μάτια σου όταν ένα νέο μέλος της ομάδας έβαλε τα χέρια του στη βάση δεδομένων μάχης για δουλειά; Ποιο, μάλιστα, είναι το μόνο που έχεις και στριφογυρίζει αυτή τη στιγμή; Φυσικά, είμαστε όλοι ενήλικες εδώ, και κάπου έχουμε ένα νέο εφεδρικό, και ακόμα πιο μακριά -πίσω από το ράφι με τα αγγούρια της γιαγιάς και τα παλιά σκι- άλλο ένα εφεδρικό, ίσως ακόμη και σε ψυκτικό χώρο, γιατί το γραφείο σας είχε ήδη πάρει φωτιά μια φορά. Παρόλα αυτά, κάθε εισαγωγή ενός νέου μέλους της ομάδας με πρόσβαση στην υποδομή μάχης και, φυσικά, στη βάση δεδομένων μάχης είναι ένας κουβάς validol για όλους. Λοιπόν, ποιος τον ξέρει, αρχάριος, μήπως είναι σταυρωμένος; Είναι τρομακτικό, θα συμφωνήσετε.
Η διαχείριση εμπορευματοκιβωτίων και, στην πραγματικότητα, η κατανεμημένη φυσική τοπολογία της βάσης δεδομένων του έργου σας βοηθά στην αποφυγή τέτοιων στιγμών επικύρωσης. Δεν εμπιστεύεστε έναν αρχάριο; ΕΝΤΑΞΕΙ! Ας του δώσουμε το δικό του σύμπλεγμα για να εργαστεί και ας αποσυνδέσουμε τη βάση δεδομένων από τα άλλα συμπλέγματα - συγχρονισμός μόνο με χειροκίνητη ώθηση και σύγχρονη περιστροφή δύο πλήκτρων (ένα για τον επικεφαλής της ομάδας, το άλλο για τον διαχειριστή). Και όλοι είναι ευχαριστημένοι.
Και τώρα ήρθε η ώρα να μετατραπούμε σε αντίπαλους της ομαδοποίησης βάσεων δεδομένων.
Σκοτεινή πλευρά
Υποστηρίζοντας γιατί δεν αξίζει τον κόπο να δεσμεύσουμε τη βάση δεδομένων και να συνεχίσουμε να την εκτελούμε σε έναν κεντρικό διακομιστή, δεν θα σκύψουμε στη ρητορική των ορθοδοξιών και δηλώσεων όπως "οι παππούδες έτρεχαν βάσεις δεδομένων σε υλικό, το ίδιο και εμείς!" Αντίθετα, ας προσπαθήσουμε να καταλήξουμε σε μια κατάσταση στην οποία η μεταφορά εμπορευματοκιβωτίων θα απέφερε πραγματικά απτά μερίσματα.
Συμφωνώ, τα έργα που χρειάζονται πραγματικά μια βάση σε ένα δοχείο μπορούν να μετρηθούν στα δάχτυλα του ενός χεριού από τον καλύτερο χειριστή της μηχανής φρεζαρίσματος. Ως επί το πλείστον, ακόμη και η χρήση των k8s ή του ίδιου του Docker Swarm είναι περιττή - πολύ συχνά αυτά τα εργαλεία καταφεύγουν λόγω της γενικής διαφημιστικής εκστρατείας των τεχνολογιών και των στάσεων του «παντοδύναμου» στο πρόσωπο των φύλων για να ωθήσουν τα πάντα στο σύννεφα και δοχεία. Λοιπόν, γιατί τώρα είναι της μόδας και το κάνουν όλοι.
Στις μισές τουλάχιστον περιπτώσεις, η χρήση του Kubernetis ή απλώς του Docker σε ένα έργο είναι περιττή. Το ζήτημα είναι ότι δεν το γνωρίζουν όλες οι ομάδες ή οι εταιρείες εξωτερικής ανάθεσης που έχουν προσληφθεί για τη συντήρηση της υποδομής του πελάτη. Είναι χειρότερο όταν επιβάλλονται κοντέινερ, επειδή κοστίζει μια συγκεκριμένη ποσότητα κερμάτων στον πελάτη.
Γενικά, υπάρχει η άποψη ότι η μαφία των docker/cube συνθλίβει βλακωδώς πελάτες που αναθέτουν σε εξωτερικούς συνεργάτες αυτά τα θέματα υποδομής. Άλλωστε, για να δουλέψουμε με clusters, χρειαζόμαστε μηχανικούς που να είναι ικανοί για αυτό και γενικά να κατανοούν την αρχιτεκτονική της υλοποιούμενης λύσης. Κάποτε περιγράψαμε ήδη την περίπτωσή μας με τη δημοσίευση Republic - εκεί εκπαιδεύσαμε την ομάδα του πελάτη να εργάζεται στην πραγματικότητα του Kubernetis και όλοι έμειναν ικανοποιημένοι. Και ήταν αξιοπρεπές. Συχνά, οι «υλιστές» του k8 κρατούν όμηρο την υποδομή του πελάτη - γιατί τώρα μόνο αυτοί καταλαβαίνουν πώς λειτουργούν όλα εκεί· δεν υπάρχουν ειδικοί από την πλευρά του πελάτη.
Τώρα φανταστείτε ότι με αυτόν τον τρόπο αναθέτουμε σε εξωτερικούς συνεργάτες όχι μόνο το τμήμα του διακομιστή web, αλλά και τη συντήρηση της βάσης δεδομένων. Είπαμε ότι το BD είναι η καρδιά και η απώλεια της καρδιάς είναι μοιραία για κάθε ζωντανό οργανισμό. Με λίγα λόγια, οι προοπτικές δεν είναι οι καλύτερες. Έτσι, αντί για το hype Kubernetis, πολλά έργα θα πρέπει απλώς να μην ασχολούνται με το κανονικό τιμολόγιο για το AWS, το οποίο θα λύσει όλα τα προβλήματα με το φορτίο στον ιστότοπο/έργο τους. Αλλά το AWS δεν είναι πλέον της μόδας και οι επιδείξεις αξίζουν περισσότερο από χρήματα - δυστυχώς, και στο περιβάλλον πληροφορικής.
ΕΝΤΑΞΕΙ. Ίσως το έργο χρειάζεται πραγματικά ομαδοποίηση, αλλά αν όλα είναι ξεκάθαρα με τις εφαρμογές χωρίς κράτος, τότε πώς μπορούμε να οργανώσουμε αξιοπρεπή συνδεσιμότητα δικτύου για μια συμπλεγμένη βάση δεδομένων;
Αν μιλάμε για μια απρόσκοπτη λύση μηχανικής, που είναι η μετάβαση στα k8s, τότε ο κύριος πονοκέφαλος μας είναι η αναπαραγωγή δεδομένων σε μια συμπλεγμένη βάση δεδομένων. Ορισμένα DBMS είναι αρχικά αρκετά πιστά στη διανομή δεδομένων μεταξύ των μεμονωμένων παρουσιών τους. Πολλοί άλλοι δεν είναι τόσο φιλόξενοι. Και πολύ συχνά το κύριο επιχείρημα για την επιλογή ενός ΣΔΒΔ για το έργο μας δεν είναι η δυνατότητα αναπαραγωγής με ελάχιστο κόστος πόρων και μηχανικής. Ειδικά αν το έργο δεν σχεδιάστηκε αρχικά ως microservice, αλλά απλώς εξελίχθηκε προς αυτή την κατεύθυνση.
Πιστεύουμε ότι δεν χρειάζεται να μιλήσουμε για την ταχύτητα των μονάδων δίσκου δικτύου - είναι αργοί. Εκείνοι. Δεν έχουμε ακόμα μια πραγματική ευκαιρία, αν συμβεί κάτι, να επανεκκινήσουμε μια παρουσία DBMS κάπου όπου υπάρχει περισσότερη, για παράδειγμα, ισχύς επεξεργαστή ή ελεύθερη μνήμη RAM. Πολύ γρήγορα θα αντιμετωπίσουμε την απόδοση του υποσυστήματος εικονικοποιημένου δίσκου. Κατά συνέπεια, το ΣΔΒΔ πρέπει να είναι καρφωμένο στο δικό του προσωπικό σύνολο μηχανών που βρίσκονται σε κοντινή απόσταση. Ή είναι απαραίτητο με κάποιο τρόπο να κρυώσει χωριστά ο αρκετά γρήγορος συγχρονισμός δεδομένων για τα υποτιθέμενα αποθέματα.
Συνεχίζοντας το θέμα των εικονικών συστημάτων αρχείων: Οι τόμοι Docker, δυστυχώς, δεν είναι χωρίς προβλήματα. Γενικά, σε ένα θέμα όπως η μακροπρόθεσμη αξιόπιστη αποθήκευση δεδομένων, θα ήθελα να αρκεστώ στα πιο απλά τεχνικά σχήματα. Και η προσθήκη ενός νέου στρώματος αφαίρεσης από το FS του κοντέινερ στο FS του γονικού κεντρικού υπολογιστή είναι ένας κίνδυνος από μόνος του. Αλλά όταν η λειτουργία του συστήματος υποστήριξης κοντέινερ αντιμετωπίζει επίσης δυσκολίες στη μετάδοση δεδομένων μεταξύ αυτών των επιπέδων, τότε είναι πραγματικά μια καταστροφή. Αυτή τη στιγμή, τα περισσότερα από τα προβλήματα που γνωρίζει η προοδευτική ανθρωπότητα φαίνεται να έχουν εξαλειφθεί. Καταλαβαίνετε όμως, όσο πιο περίπλοκος είναι ο μηχανισμός, τόσο πιο εύκολα σπάει.
Υπό το πρίσμα όλων αυτών των «περιπέτειών», είναι πολύ πιο κερδοφόρο και ευκολότερο να διατηρείτε τη βάση δεδομένων σε ένα μέρος, και ακόμη κι αν χρειάζεται να διαμορφώσετε την εφαρμογή σε κοντέινερ, αφήστε την να τρέξει μόνη της και μέσω της πύλης διανομής να λαμβάνει ταυτόχρονη επικοινωνία με το βάση δεδομένων, η οποία θα διαβαστεί και θα γραφτεί μόνο μία φορά και σε ένα μέρος. Αυτή η προσέγγιση μειώνει την πιθανότητα σφαλμάτων και αποσυγχρονισμού στο ελάχιστο.
Σε τι οδηγούμαστε; Επιπλέον, η αποθήκευση της βάσης δεδομένων είναι κατάλληλη όπου υπάρχει πραγματική ανάγκη. Δεν μπορείτε να γεμίσετε μια βάση δεδομένων πλήρους εφαρμογής και να την περιστρέψετε σαν να είχατε δύο δωδεκάδες microservices - δεν λειτουργεί με αυτόν τον τρόπο. Και αυτό πρέπει να γίνει ξεκάθαρα κατανοητό.
Αντί της εξόδου
Εάν περιμένετε ένα σαφές συμπέρασμα «για να εικονικοποιήσετε τη βάση δεδομένων ή όχι», τότε θα σας απογοητεύσουμε: δεν θα είναι εδώ. Γιατί κατά τη δημιουργία οποιασδήποτε λύσης υποδομής, πρέπει να καθοδηγείται όχι από τη μόδα και την πρόοδο, αλλά, πρώτα από όλα, από την κοινή λογική.
Υπάρχουν έργα για τα οποία οι αρχές και τα εργαλεία που συνοδεύουν το Kubernetis ταιριάζουν απόλυτα, και σε τέτοια έργα υπάρχει ειρήνη τουλάχιστον στην περιοχή του backend. Και υπάρχουν έργα που δεν χρειάζονται εμπορευματοκιβώτια, αλλά μια κανονική υποδομή διακομιστή, επειδή βασικά δεν μπορούν να επανακλιμακωθούν στο μοντέλο συμπλέγματος μικροϋπηρεσιών, γιατί θα πέσουν.
Πηγή: www.habr.com