Το FastComments είναι έτοιμο για διάστημα!

! Αυτό το άρθρο περιέχει τεχνική ορολογία

Τι νέο υπάρχει

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

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

Μερικά ιστορικά στοιχεία, γιατί η αλλαγή

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

Τελικά μετακινήσαμε τις αναπαραγωγές της βάσης δεδομένων σε όλες τις ζώνες όπου είναι οι περισσότεροι χρήστες μας και επίσης αναπτύξαμε την εφαρμογή εκεί, και δημιουργήσαμε το δικό μας DNS και σύστημα μεσολαβητή (που περιγράφεται σε μεταγενέστερη ανάρτηση του blog) για να καθοδηγούμε τα αιτήματα στον πιο κοντινό κόμβο εφαρμογής. Αυτό καθιστά τις αναγνώσεις γρήγορες, αλλά τις εγγραφές πιο αργές, καθώς τώρα αντί να περιμένουμε για μια HTTP round trip προς το backend, περιμένουμε για μια HTTP round trip προς έναν κοντινό κόμβο, και αυτός ο κόμβος μπορεί να κάνει πολλές εγγραφές στη βάση δεδομένων πίσω στον κύριο. Δεν είναι καλό αυτό!

Έτσι, για να αντιμετωπίσουμε αυτό το πρόβλημα, αναδομήσαμε πολλές περιοχές της εφαρμογής για να λαμβάνουμε ένα readPreference στα επιχειρήματα της λειτουργίας, ώστε οι καλούντες να μπορούν να αποφασίσουν πόσο παλιές είναι αποδεκτές οι αναγνώσεις τους, και πέρα από αυτό κάναμε περισσότερες εγγραφές (όπως η καταγραφή στατιστικών μετριασμού για τις ενέργειες μετριασμού) fire-and-forget. Δεν είναι ιδανικό, αλλά επιτάχυνε σημαντικά τα πράγματα.

Ένα πρόβλημα που αντιμετωπίσαμε τρέχοντας το Mongo παγκοσμίως είναι οι δικτυακές διακοπές. Αν αρκετοί κόμβοι αποκοπούν, οι αναγνώσεις σταματούν καθώς κάθε κόμβος γίνεται αβέβαιος αν είναι αποδεκτό να εξυπηρετήσει τις αναγνώσεις. Υπάρχουν κάποιες λύσεις για αυτό, αλλά οι ακραίες περιπτώσεις γίνονται μπερδεμένες. Αυτό δεν είναι θεωρητικό ζήτημα - έχει συμβεί αρκετές φορές προκαλώντας σελίδες στις 3 το πρωί που μας κούρασαν, ακόμη και προσπαθώντας να ρυθμίσουμε το Mongo ώστε να είναι εντάξει με την αβεβαιότητα των εκλογών των replica set μέχρι ένα λεπτό διαφορά. Δυστυχώς, τα δίκτυα από το Σάο Πάολο προς το Φάλκενσταϊν, για παράδειγμα, δεν ήταν και πολύ καλά σε μερικούς από τους παρόχους φιλοξενίας μας. Η ρύθμιση του ελέγχου συμφόρησης κ.α. βοήθησε αλλά δεν έλυσε το πρόβλημα.

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

Έτσι αυτό είναι το σημείο που καταλήξαμε. Ορέγκον, Βιρτζίνια, Φάλκενσταϊν, Σάο Πάολο, Σιγκαπούρη, είναι όλα δικά τους replica sets και δέχονται εγγραφές. Η υλοποίηση στην ΕΕ (αν και μόνο τρία PoPs) έχει την ίδια συμπεριφορά.

Πώς λειτουργεί

Μερικά από αυτά τα έχουμε καλύψει στην προηγούμενη ενότητα, αλλά το TL;DR είναι ότι είναι CRDT-lite. Δημιουργήσαμε μια μεσολαβητική εφαρμογή (σε Rust, γιατί βέβαια) που κάθεται μεταξύ της εφαρμογής και του Mongo και την καθιστά πολυ-κύριο. Η μεσολαβητική εφαρμογή είναι ενημερωμένη για τους ομότιμους, διαχειρίζεται ελέγχους, αναπαραγωγή, παρακολούθηση και αρχικό συγχρονισμό. Είναι μια πολυ-κύρια αντικατάσταση για το σύστημα αναπαραγωγής του Mongo, συμπεριλαμβανομένων ορισμένων DDL εντολών.

Η διαφορά από άλλα εργαλεία είναι ότι δεν ακολουθεί το oplog. Η παρακολούθηση του oplog, ή η χρήση change streams, δεν θα λειτουργούσε, επειδή δείχνουν μόνο την τελική κατάσταση του αντικειμένου μετά την εγγραφή, καθιστώντας αδύνατο να διαχειριστούμε συγκρούσεις. Χρειάζεται να καταγράψουμε κάθε λειτουργία $set, $inc και να αναπαραγάγουμε αυτή την ίδια λειτουργία.

Αυτή είναι μια λύση συγκεκριμένης χρήσης. Δεν θα λειτουργούσε για όλα τα προϊόντα. Μπορείτε να πείτε ότι είναι domain-driven design :). Λειτουργεί για εμάς γιατί από την αρχή προσέχουμε πολύ να $set μόνο τα πεδία που αλλάζουμε σε έγγραφα - ποτέ δεν χρησιμοποιούμε το replaceOne του Mongo, για παράδειγμα. Το ίδιο ισχύει και για τους μετρητές. Ποτέ δεν κάνετε SET VOTES = 5. Αντίθετα, θα γράφατε INCREMENT VOTES BY 5, καθώς αυτό επιτρέπει τελική συνέπεια. Οι κατανεμημένοι αποκλεισμοί διαχειρίζονται από don't. Μόνο ένας κόμβος ανά σύμπλεγma έχει σημαία ρυθμισμένη να τρέχει cron. Αν και αυτό μπορεί να φαίνεται περιορισμένο, μπορούμε να αγοράσουμε διακομιστές με terabytes RAM, οπότε μπορούμε να πάρουμε αυτή την παραχώρηση για να μειώσουμε τον κίνδυνο και την πολυπλοκότητα.

Διαβάζοντας τις δικές σας εγγραφές

Για τους προγραμματιστές που χρησιμοποιούν το API, θα πρέπει να είστε σε θέση να διαβάσετε τις δικές σας εγγραφές όπως πριν (κάντε μια κλήση API για να δημιουργήσετε ένα σχόλιο, στη συνέχεια καταγράψτε τα σχόλια και δείτε τη νέα καταχώριση σε αυτή τη λίστα). Η παρατήρηση είναι ότι δεν μπορείτε να το κάνετε αυτό μεταξύ περιοχών. Αν το backend σας τρέχει μόνο σε μία περιοχή, όπως η west-us, τότε θα πρέπει να είστε σε θέση να διαβάσετε τις δικές σας εγγραφές εκτός αν, μεταξύ της εγγραφής σας και της ανάγνωσής σας, αυτός ο κόμβος πέσει και η προσωρινή μνήμη DNS σας ενημερωθεί για να δείξει τον επόμενο κοντινότερο κόμβο. Εφόσον αυτό δεν συμβεί, η ανάγνωση των δικών σας εγγραφών είναι αξιόπιστη.

Μπορείτε επίσης να καθορίσετε ποιο σημείο παρουσίας χρησιμοποιείτε. Περισσότερες πληροφορίες εδώ.

Δοκιμές & Η Μετανάστευση

Περίπου το μισό από τον κώδικα στο σύστημα είναι το δοκιμαστικό πλαίσιο, το πλαίσιο και οι δοκιμές. Ωστόσο, η κυκλοφορία είχε κάποιες αναταραχές, με περισσότερο χρόνο διακοπής (1 ώρα για την ΕΕ και 20 λεπτά για τον παγκόσμιο) από ότι επιθυμούσαμε, αλλά είμαστε χαρούμενοι που περάσαμε αυτό το ορόσημο και σας ευχαριστούμε για την υπομονή σας!

Στο συμπέρασμα & Τι σημαίνει αυτό για εσάς

Το FastComments θα πρέπει τώρα να είναι ταχύτερο και πιο ανθεκτικό από ποτέ, και τώρα μπορούμε να επιστρέψουμε στην εργασία μας για νέα χαρακτηριστικά :)

Ευχαριστώ!