🥇Tarantool Cartridge: μοιράζοντας ένα Lua backend σε τρεις γραμμές

Στον Όμιλο Mail.ru έχουμε Tarantool - αυτός είναι ένας διακομιστής εφαρμογών στο Lua, ο οποίος λειτουργεί και ως βάση δεδομένων (ή το αντίστροφο;). Είναι γρήγορο και ωραίο, αλλά οι δυνατότητες ενός διακομιστή δεν είναι ακόμα απεριόριστες. Η κάθετη κλιμάκωση δεν είναι επίσης πανάκεια, επομένως το Tarantool διαθέτει εργαλεία για οριζόντια κλιμάκωση - τη μονάδα vshard [1]. Σας επιτρέπει να μοιράζετε δεδομένα σε πολλούς διακομιστές, αλλά πρέπει να τα πειράζετε για να τα ρυθμίσετε και να επισυνάψετε την επιχειρηματική λογική.

Καλά νέα: συγκεντρώσαμε μερικές μεγάλες λήψεις (π.χ [2], [3]) και δημιούργησε ένα άλλο πλαίσιο που θα απλοποιήσει σημαντικά τη λύση σε αυτό το πρόβλημα.

Φυσίγγιο Tarantool είναι ένα νέο πλαίσιο για την ανάπτυξη πολύπλοκων κατανεμημένων συστημάτων. Σας επιτρέπει να εστιάσετε στη σύνταξη επιχειρηματικής λογικής αντί να λύνετε προβλήματα υποδομής. Κάτω από την περικοπή θα σας πω πώς λειτουργεί αυτό το πλαίσιο και πώς να γράφετε κατανεμημένες υπηρεσίες χρησιμοποιώντας το.

Και ποιο ακριβώς είναι το πρόβλημα;

Έχουμε μια ταραντούλα, έχουμε vshard - τι άλλο θα θέλατε;

Πρώτον, είναι θέμα ευκολίας. Η διαμόρφωση vshard διαμορφώνεται μέσω πινάκων Lua. Για να λειτουργεί σωστά ένα κατανεμημένο σύστημα πολλαπλών διεργασιών Tarantool, η διαμόρφωση πρέπει να είναι η ίδια παντού. Κανείς δεν θέλει να το κάνει αυτό χειροκίνητα. Επομένως, χρησιμοποιούνται όλα τα είδη σεναρίων, Ansible και συστήματα ανάπτυξης.

Το ίδιο το Cartridge διαχειρίζεται τη διαμόρφωση vshard, το κάνει αυτό με βάση το δική σας κατανεμημένη διαμόρφωση. Πρόκειται ουσιαστικά για ένα απλό αρχείο YAML, ένα αντίγραφο του οποίου αποθηκεύεται σε κάθε παρουσία του Tarantool. Η απλοποίηση είναι ότι το ίδιο το πλαίσιο παρακολουθεί τη διαμόρφωσή του και διασφαλίζει ότι είναι το ίδιο παντού.

Δεύτερον, είναι και πάλι θέμα ευκολίας. Η διαμόρφωση vshard δεν έχει καμία σχέση με την ανάπτυξη της επιχειρηματικής λογικής και απλώς αποσπά την προσοχή του προγραμματιστή από τη δουλειά του. Όταν συζητάμε την αρχιτεκτονική ενός έργου, τις περισσότερες φορές μιλάμε για μεμονωμένα στοιχεία και την αλληλεπίδρασή τους. Είναι πολύ νωρίς για να σκεφτούμε να αναπτύξουμε ένα σύμπλεγμα σε 3 κέντρα δεδομένων.

Επιλύσαμε αυτά τα προβλήματα ξανά και ξανά, και κάποια στιγμή καταφέραμε να αναπτύξουμε μια προσέγγιση που απλοποίησε την εργασία με την εφαρμογή σε ολόκληρο τον κύκλο ζωής της: δημιουργία, ανάπτυξη, δοκιμή, CI/CD, συντήρηση.

Το Cartridge εισάγει την έννοια του ρόλου για κάθε διαδικασία Tarantool. Οι ρόλοι είναι μια έννοια που επιτρέπει σε έναν προγραμματιστή να επικεντρωθεί στη σύνταξη κώδικα. Όλοι οι διαθέσιμοι ρόλοι στο έργο μπορούν να εκτελεστούν σε μία παρουσία του Tarantool και αυτό θα είναι αρκετό για δοκιμές.

Βασικά χαρακτηριστικά του Tarantool Cartridge:

αυτοματοποιημένη ενορχήστρωση συμπλέγματος?
επέκταση της λειτουργικότητας της εφαρμογής χρησιμοποιώντας νέους ρόλους.
πρότυπο εφαρμογής για ανάπτυξη και ανάπτυξη·
ενσωματωμένη αυτόματη κοινή χρήση.
ενοποίηση με το πλαίσιο δοκιμών Luatest·
διαχείριση συμπλέγματος με χρήση WebUI και API.
εργαλεία συσκευασίας και ανάπτυξης.

Γειά σου Κόσμε!

Ανυπομονώ να δείξω το ίδιο το πλαίσιο, οπότε θα αφήσουμε την ιστορία για την αρχιτεκτονική για αργότερα και θα ξεκινήσουμε με κάτι απλό. Αν υποθέσουμε ότι το ίδιο το Tarantool είναι ήδη εγκατεστημένο, τότε το μόνο που μένει είναι να κάνουμε

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

Αυτές οι δύο εντολές θα εγκαταστήσουν τα βοηθητικά προγράμματα της γραμμής εντολών και θα σας επιτρέψουν να δημιουργήσετε την πρώτη σας εφαρμογή από το πρότυπο:

$ cartridge create --name myapp

Και αυτό είναι που παίρνουμε:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

Αυτό είναι ένα αποθετήριο git με ένα έτοιμο "Hello, World!" εφαρμογή. Ας προσπαθήσουμε να το εκτελέσουμε αμέσως, έχοντας προηγουμένως εγκαταστήσει τις εξαρτήσεις (συμπεριλαμβανομένου του ίδιου του πλαισίου):

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

Έτσι, έχουμε έναν κόμβο που εκτελείται για τη μελλοντική μοιρασμένη εφαρμογή. Ένας περίεργος λαϊκός μπορεί να ανοίξει αμέσως τη διεπαφή ιστού, να διαμορφώσει ένα σύμπλεγμα ενός κόμβου με το ποντίκι και να απολαύσει το αποτέλεσμα, αλλά είναι πολύ νωρίς για να χαρούμε. Μέχρι στιγμής, η εφαρμογή δεν μπορεί να κάνει τίποτα χρήσιμο, επομένως θα σας πω για την ανάπτυξη αργότερα, αλλά τώρα ήρθε η ώρα να γράψετε κώδικα.

Ανάπτυξη εφαρμογής

Φανταστείτε, σχεδιάζουμε ένα έργο που πρέπει να λαμβάνει δεδομένα, να τα αποθηκεύει και να δημιουργεί μια αναφορά μία φορά την ημέρα.

Αρχίζουμε να σχεδιάζουμε ένα διάγραμμα και τοποθετούμε τρία στοιχεία σε αυτό: πύλη, αποθήκευση και χρονοπρογραμματιστή. Εργαζόμαστε περαιτέρω στην αρχιτεκτονική. Εφόσον χρησιμοποιούμε το vshard ως αποθήκευση, προσθέτουμε το vshard-router και το vshard-storage στο σχήμα. Ούτε η πύλη ούτε ο προγραμματιστής θα έχουν απευθείας πρόσβαση στο χώρο αποθήκευσης· γι' αυτό είναι ο δρομολογητής, γι' αυτό δημιουργήθηκε.

Αυτό το διάγραμμα εξακολουθεί να μην αντιπροσωπεύει ακριβώς αυτό που θα χτίσουμε στο έργο επειδή τα στοιχεία φαίνονται αφηρημένα. Πρέπει ακόμα να δούμε πώς θα προβληθεί αυτό στο πραγματικό Tarantool - ας ομαδοποιήσουμε τα στοιχεία μας κατά διαδικασία.

Δεν έχει νόημα η διατήρηση του vshard-router και της πύλης σε ξεχωριστές περιπτώσεις. Γιατί πρέπει να σερφάρουμε ξανά στο δίκτυο εάν αυτό είναι ήδη ευθύνη του δρομολογητή; Πρέπει να εκτελούνται με την ίδια διαδικασία. Δηλαδή, τόσο το gateway όσο και το vshard.router.cfg αρχικοποιούνται σε μία διεργασία και αφήνονται να αλληλεπιδρούν τοπικά.

Στο στάδιο του σχεδιασμού, ήταν βολικό να δουλεύω με τρία στοιχεία, αλλά εγώ, ως προγραμματιστής, ενώ γράφω τον κώδικα, δεν θέλω να σκεφτώ την εκκίνηση τριών παρουσιών του Tarnatool. Πρέπει να εκτελέσω δοκιμές και να ελέγξω ότι έγραψα σωστά το gateway. Ή ίσως θέλω να δείξω ένα χαρακτηριστικό στους συναδέλφους μου. Γιατί να μπω στην ταλαιπωρία της ανάπτυξης τριών αντιγράφων; Έτσι γεννήθηκε η έννοια των ρόλων. Ένας ρόλος είναι μια κανονική μονάδα luash της οποίας ο κύκλος ζωής διαχειρίζεται το Cartridge. Σε αυτό το παράδειγμα υπάρχουν τέσσερα από αυτά - πύλη, δρομολογητής, χώρος αποθήκευσης, προγραμματιστής. Μπορεί να υπάρχουν περισσότερα σε άλλο έργο. Όλοι οι ρόλοι μπορούν να εκτελεστούν σε μία διαδικασία και αυτό θα είναι αρκετό.

Και όταν πρόκειται για την ανάπτυξη στη σκηνή ή την παραγωγή, τότε θα εκχωρήσουμε σε κάθε διαδικασία Tarantool το δικό της σύνολο ρόλων ανάλογα με τις δυνατότητες υλικού:

Διαχείριση τοπολογίας

Οι πληροφορίες σχετικά με το πού εκτελούνται οι ρόλοι πρέπει να αποθηκευτούν κάπου. Και αυτό το "κάπου" είναι η κατανεμημένη διαμόρφωση, την οποία ανέφερα ήδη παραπάνω. Το πιο σημαντικό πράγμα για αυτό είναι η τοπολογία συμπλέγματος. Ακολουθούν 3 ομάδες αναπαραγωγής 5 διεργασιών Tarantool:

Δεν θέλουμε να χάσουμε δεδομένα, επομένως αντιμετωπίζουμε με προσοχή τις πληροφορίες σχετικά με τις διεργασίες που εκτελούνται. Το Cartridge παρακολουθεί τη διαμόρφωση χρησιμοποιώντας μια δέσμευση δύο φάσεων. Μόλις θέλουμε να ενημερώσουμε τη διαμόρφωση, πρώτα ελέγχει ότι όλες οι παρουσίες είναι διαθέσιμες και έτοιμες να αποδεχτούν τη νέα διαμόρφωση. Μετά από αυτό, η δεύτερη φάση εφαρμόζει τη διαμόρφωση. Έτσι, ακόμα κι αν αποδειχθεί ότι ένα αντίγραφο δεν είναι προσωρινά διαθέσιμο, τίποτα κακό δεν θα συμβεί. Η διαμόρφωση απλά δεν θα εφαρμοστεί και θα δείτε ένα σφάλμα εκ των προτέρων.

Επίσης, στην ενότητα τοπολογία, υποδεικνύεται μια τόσο σημαντική παράμετρος όπως ο αρχηγός κάθε ομάδας αναπαραγωγής. Συνήθως αυτό είναι το αντίγραφο που ηχογραφείται. Τα υπόλοιπα είναι συνήθως μόνο για ανάγνωση, αν και μπορεί να υπάρχουν εξαιρέσεις. Μερικές φορές οι γενναίοι προγραμματιστές δεν φοβούνται τις συγκρούσεις και μπορούν να γράφουν δεδομένα σε πολλά αντίγραφα παράλληλα, αλλά υπάρχουν ορισμένες λειτουργίες που, ανεξάρτητα από το τι, δεν πρέπει να εκτελούνται δύο φορές. Για αυτό υπάρχει ένα σημάδι ενός ηγέτη.

Η ζωή των ρόλων

Για να υπάρχει ένας αφηρημένος ρόλος σε μια τέτοια αρχιτεκτονική, το πλαίσιο πρέπει να τους διαχειριστεί με κάποιο τρόπο. Φυσικά, ο έλεγχος πραγματοποιείται χωρίς επανεκκίνηση της διαδικασίας Tarantool. Υπάρχουν 4 επιστροφές κλήσης για τη διαχείριση ρόλων. Το ίδιο το Cartridge θα τα καλέσει ανάλογα με το τι είναι γραμμένο στην κατανεμημένη του διαμόρφωση, εφαρμόζοντας έτσι τη διαμόρφωση σε συγκεκριμένους ρόλους.

function init()
function validate_config()
function apply_config()
function stop()

Κάθε ρόλος έχει μια λειτουργία init. Καλείται μία φορά είτε όταν ο ρόλος είναι ενεργοποιημένος είτε όταν γίνεται επανεκκίνηση του Tarantool. Είναι βολικό εκεί, για παράδειγμα, να αρχικοποιήσετε το box.space.create, ή ο προγραμματιστής μπορεί να εκκινήσει κάποια ίνα παρασκηνίου που θα εκτελεί εργασία σε συγκεκριμένα χρονικά διαστήματα.

Μία λειτουργία init μπορεί να μην είναι αρκετό. Το Cartridge επιτρέπει στους ρόλους να επωφεληθούν από την κατανεμημένη διαμόρφωση που χρησιμοποιεί για την αποθήκευση της τοπολογίας. Μπορούμε να δηλώσουμε μια νέα ενότητα στην ίδια διαμόρφωση και να αποθηκεύσουμε ένα τμήμα της διαμόρφωσης της επιχείρησης σε αυτήν. Στο παράδειγμά μου, αυτό θα μπορούσε να είναι ένα σχήμα δεδομένων ή ρυθμίσεις προγραμματισμού για το ρόλο του προγραμματιστή.

Κλήσεις συμπλέγματος validate_config и apply_config κάθε φορά που αλλάζει η κατανεμημένη διαμόρφωση. Όταν μια διαμόρφωση εφαρμόζεται από μια δέσμευση δύο φάσεων, το σύμπλεγμα ελέγχει ότι κάθε ρόλος είναι έτοιμος να αποδεχτεί αυτήν τη νέα διαμόρφωση και, εάν είναι απαραίτητο, αναφέρει ένα σφάλμα στον χρήστη. Όταν όλοι συμφωνούν ότι η διαμόρφωση είναι κανονική, τότε το apply_config.

Επίσης οι ρόλοι έχουν μέθοδο stop, το οποίο χρειάζεται για να καθαρίσει το αποτέλεσμα του ρόλου. Εάν πούμε ότι ο προγραμματιστής δεν χρειάζεται πλέον σε αυτόν τον διακομιστή, μπορεί να σταματήσει αυτές τις ίνες με τις οποίες ξεκίνησε init.

Οι ρόλοι μπορούν να αλληλεπιδράσουν μεταξύ τους. Έχουμε συνηθίσει να γράφουμε κλήσεις συναρτήσεων στο Lua, αλλά μπορεί να συμβεί μια δεδομένη διεργασία να μην έχει τον ρόλο που χρειαζόμαστε. Για τη διευκόλυνση των κλήσεων μέσω του δικτύου, χρησιμοποιούμε τη βοηθητική μονάδα rpc (κλήση απομακρυσμένης διαδικασίας), η οποία είναι κατασκευασμένη με βάση το τυπικό netbox που είναι ενσωματωμένο στο Tarantool. Αυτό μπορεί να είναι χρήσιμο εάν, για παράδειγμα, η πύλη σας θέλει να ζητήσει απευθείας από τον προγραμματιστή να κάνει τη δουλειά αυτή τη στιγμή, αντί να περιμένει μια μέρα.

Ένα άλλο σημαντικό σημείο είναι η διασφάλιση της ανοχής σφαλμάτων. Το Cartridge χρησιμοποιεί το πρωτόκολλο SWIM για την παρακολούθηση της υγείας [4]. Εν ολίγοις, οι διεργασίες ανταλλάσσουν «φήμες» μεταξύ τους μέσω UDP—κάθε διεργασία λέει στους γείτονές της τα τελευταία νέα και εκείνοι απαντούν. Αν ξαφνικά δεν έρθει η απάντηση, ο Tarantool αρχίζει να υποψιάζεται ότι κάτι δεν πάει καλά και μετά από λίγο απαγγέλλει τον θάνατο και αρχίζει να λέει σε όλους γύρω από αυτά τα νέα.

Με βάση αυτό το πρωτόκολλο, το Cartridge οργανώνει την αυτόματη επεξεργασία αποτυχίας. Κάθε διεργασία παρακολουθεί το περιβάλλον της και αν ο ηγέτης σταματήσει ξαφνικά να ανταποκρίνεται, το αντίγραφο μπορεί να αναλάβει τον ρόλο του και η Cartridge διαμορφώνει τους ρόλους που εκτελούνται ανάλογα.

Πρέπει να είστε προσεκτικοί εδώ, γιατί η συχνή εναλλαγή εμπρός και πίσω μπορεί να οδηγήσει σε διενέξεις δεδομένων κατά την αναπαραγωγή. Φυσικά, δεν πρέπει να ενεργοποιήσετε την αυτόματη ανακατεύθυνση τυχαία. Πρέπει να καταλάβουμε ξεκάθαρα τι συμβαίνει και να είμαστε σίγουροι ότι η αναπαραγωγή δεν θα σπάσει μετά την αποκατάσταση του ηγέτη και την επιστροφή του στέμματος σε αυτόν.

Από όλα αυτά, μπορεί να έχετε την αίσθηση ότι οι ρόλοι είναι παρόμοιοι με τις μικροϋπηρεσίες. Κατά μία έννοια, είναι ακριβώς αυτό, μόνο ως ενότητες μέσα στις διαδικασίες Tarantool. Υπάρχουν όμως και ορισμένες θεμελιώδεις διαφορές. Πρώτον, όλοι οι ρόλοι του έργου πρέπει να βρίσκονται στην ίδια βάση κώδικα. Και όλες οι διεργασίες Tarantool θα πρέπει να ξεκινούν από την ίδια βάση κώδικα, έτσι ώστε να μην υπάρχουν εκπλήξεις όπως αυτές που προσπαθούμε να αρχικοποιήσουμε τον προγραμματιστή, αλλά απλώς δεν υπάρχει. Επίσης, δεν πρέπει να επιτρέπετε διαφορές στις εκδόσεις κώδικα, γιατί η συμπεριφορά του συστήματος σε μια τέτοια κατάσταση είναι πολύ δύσκολο να προβλεφθεί και να εντοπιστεί σφάλματα.

Σε αντίθεση με το Docker, δεν μπορούμε απλώς να πάρουμε "εικόνα" ρόλου, να τον πάμε σε άλλο μηχάνημα και να τον τρέξουμε εκεί. Οι ρόλοι μας δεν είναι τόσο απομονωμένοι όσο τα δοχεία Docker. Επίσης, δεν μπορούμε να εκτελέσουμε δύο ίδιους ρόλους σε μία παρουσία. Ένας ρόλος είτε υπάρχει είτε δεν υπάρχει· κατά μία έννοια, είναι singleton. Και τρίτον, οι ρόλοι πρέπει να είναι ίδιοι σε ολόκληρη την ομάδα αναπαραγωγής, γιατί διαφορετικά θα ήταν παράλογο - τα δεδομένα είναι ίδια, αλλά η διαμόρφωση είναι διαφορετική.

Εργαλεία ανάπτυξης

Υποσχέθηκα να δείξω πώς το Cartridge βοηθά στην ανάπτυξη εφαρμογών. Για να διευκολύνει τη ζωή των άλλων, το πλαίσιο συσκευάζει πακέτα RPM:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

Το εγκατεστημένο πακέτο περιέχει σχεδόν όλα όσα χρειάζεστε: τόσο την εφαρμογή όσο και τις εγκατεστημένες εξαρτήσεις. Το Tarantool θα φτάσει επίσης στον διακομιστή ως εξάρτηση του πακέτου RPM και η υπηρεσία μας είναι έτοιμη να ξεκινήσει. Αυτό γίνεται μέσω του systemd, αλλά πρώτα πρέπει να γράψετε μια μικρή ρύθμιση παραμέτρων. Τουλάχιστον, καθορίστε το URI κάθε διεργασίας. Τρία είναι αρκετά για παράδειγμα.

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

Υπάρχει μια ενδιαφέρουσα απόχρωση εδώ. Αντί να καθορίσουμε μόνο τη θύρα δυαδικού πρωτοκόλλου, καθορίζουμε ολόκληρη τη δημόσια διεύθυνση της διαδικασίας, συμπεριλαμβανομένου του ονόματος κεντρικού υπολογιστή. Αυτό είναι απαραίτητο ώστε οι κόμβοι του συμπλέγματος να γνωρίζουν πώς να συνδέονται μεταξύ τους. Είναι κακή ιδέα να χρησιμοποιήσετε το 0.0.0.0 ως διεύθυνση advertise_uri· θα πρέπει να είναι μια εξωτερική διεύθυνση IP, όχι μια υποδοχή υποδοχής. Χωρίς αυτό, τίποτα δεν θα λειτουργήσει, επομένως το Cartridge απλά δεν θα σας αφήσει να εκκινήσετε έναν κόμβο με λάθος advertise_uri.

Τώρα που η διαμόρφωση είναι έτοιμη, μπορείτε να ξεκινήσετε τις διαδικασίες. Δεδομένου ότι μια κανονική μονάδα systemd δεν επιτρέπει την εκκίνηση περισσότερων από μία διεργασιών, οι εφαρμογές στο Cartridge εγκαθίστανται από το λεγόμενο. instantiated μονάδες που λειτουργούν ως εξής:

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

Στη διαμόρφωση, καθορίσαμε τη θύρα HTTP στην οποία το Cartridge εξυπηρετεί τη διεπαφή ιστού - 8080. Ας πάμε σε αυτήν και ας ρίξουμε μια ματιά:

Βλέπουμε ότι παρόλο που οι διεργασίες εκτελούνται, δεν έχουν ακόμη ρυθμιστεί. Το φυσίγγιο δεν γνωρίζει ακόμη ποιος πρέπει να αντιγράψει με ποιον και δεν μπορεί να πάρει απόφαση από μόνο του, επομένως περιμένει τις ενέργειές μας. Αλλά δεν έχουμε πολλές επιλογές: η ζωή ενός νέου συμπλέγματος ξεκινά με τη διαμόρφωση του πρώτου κόμβου. Στη συνέχεια, θα προσθέσουμε τους άλλους στο σύμπλεγμα, θα τους αναθέσουμε ρόλους και σε αυτό το σημείο η ανάπτυξη μπορεί να θεωρηθεί επιτυχώς ολοκληρωμένη.

Ας ρίξουμε ένα ποτήρι από το αγαπημένο σας ποτό και ας χαλαρώσουμε μετά από μια κουραστική εβδομάδα εργασίας. Η εφαρμογή μπορεί να χρησιμοποιηθεί.