Wed Sep 10 2025
...
Η FastComments Είναι Τώρα Παγκοσμίως Κατανεμημένη
Τι Είναι Νέο
Προβλήματος, η FastComments είχε μια πολύ παραδοσιακή αρχιτεκτονική για μια εφαρμογή web. Είχαμε τους servers εφαρμογών μας, βάσεις δεδομένων και μερικές άλλες υπηρεσίες. Αυτό ήταν διπλότυπο σε δύο περιοχές (us-west και eu). Αν ήσαστε στη Γαλλία και θέλατε να δείτε μια συζήτηση σχολίων για έναν πελάτη που φιλοξενούνταν στο παγκόσμιο datacenter μας, οι αιτήσεις σας έπρεπε να πάνε όλο το δρόμο μέχρι το us-west για τα δεδομένα σχολίων.
Όχι πια! Τώρα τα δεδομένα σχολίων και όλα τα μέσα αναπαράγονται παγκοσμίως για πελάτες στην παγκόσμια ανάπτυξή μας, και για πελάτες στην ευρωπαϊκή ανάπτυξή μας, έχουμε τρία σημεία παρουσίας στην ΕΕ όπου τα δεδομένα αναπαράγονται. Οι αιτήσεις σας πηγαίνουν στον πλησιέστερο κόμβο στην ΕΕ.
Πώς Λειτουργούσε Παλαιότερα
Εκτός από τις βάσεις δεδομένων που είχαν αρκετούς ζωντανούς αντιγράφους σε περιοχές και παρόχους cloud, όλες οι υπηρεσίες αναπτύχθηκαν σε μία μόνο εμφάνιση ανά τύπο υπηρεσίας. Αυτό σήμαινε ότι για κάθε περιοχή είχαμε έναν server εφαρμογών, έναν server pubsub και έναν media server. Το σχέδιο ήταν να κλιμακώσουμε κάθετα όσο μπορούσαμε καθώς αυτό διατηρούσε τα πράγματα απλά. Η συγγραφή κώδικα ήταν εύκολη - πάντα γνωρίζατε ότι μπορούσατε να "διαβάσετε τις δικές σας εγγραφές" όταν προσπαθούσατε να καταγράψετε στη βάση δεδομένων. Η υποδομή ήταν εύκολη, με την εξαίρεση των ενημερώσεων ασφαλείας που θα χρειαζόταν ένα λεπτό downtime.
Το Πρόβλημα
Το πρόβλημα άρχισε προφανώς όταν φτάσαμε σε χωρητικότητα. Έτσι βελτιώσαμε, και τελικά έπρεπε να ανεβάσουμε το μέγεθος της εμφάνισης για εκείνη την υπηρεσία.
Αυτό άρχισε να γίνεται οικονομικά απαγορευτικό στο Linode, όπου μια εμφάνιση $144 είναι περίπου ισοδύναμη, βάσει των δοκιμών μας, με ένα κόμβο $20 OVH, και ακόμα κι αν αλλάξαμε παρόχους φιλοξενίας, θα είχαμε μοναδικά σημεία αποτυχίας σε όλη την περιοχή - και πάροχοι όπως η OVH τείνουν να έχουν μεγαλύτερους χρόνους αποκατάστασης από την Linode για προβλήματα συντήρησης.
RiR :)
Για τα πρώτα χρόνια, οι υπηρεσίες PubSub και Media στην FastComments γράφτηκαν σε Java. Η Java επιλέχθηκε επειδή είχε σχετικά υψηλή απόδοση για την προσπάθεια που καταβλήθηκε, και μετά από χρόνια ρύθμισης του GC, δοκιμάζοντας G1GC, Shenandoah, και Z1, αποφασίσαμε να μην ξαναχρησιμοποιήσουμε Java. Η χρήση μνήμης ήταν απλώς πολύ μεγάλη και καθώς αυτές οι υπηρεσίες ήταν πολύ σταθερές μόλις ολοκληρωθούν, τα οφέλη της Java έχασαν την αξία τους. Επίσης, αυτές οι υπηρεσίες έπρεπε να διαχειριστούν το πρόβλημα του "thundering herd", που σήμαινε ότι η JVM προσπαθούσε να διαχειριστεί τη μέγιστη κυκλοφορία όταν η JIT δεν είχε καν ενεργοποιηθεί ακόμα. Αυτές οι υπηρεσίες ήταν ιδανικοί υποψήφιοι για μετάβαση σε C++ ή Rust.
Η Rust επιλέχθηκε διότι δεν είμαστε ειδικοί στην C++ και ένα λάθος στον κώδικα δικτύου θα μπορούσε να εκθέσει τα δεδομένα ενός πελάτη σε άλλο. Η Rust μας βοηθά να αποτρέψουμε αυτούς τους τύπους προβλημάτων.
Θέλαμε να ενοποιήσουμε αυτές τις υπηρεσίες ούτως ή άλλως, οπότε ενώ θα μπορούσαμε να κάνουμε άλλη μια βελτίωση ίσως με GraalVM, αποφασίσαμε να μεταβούμε στη Rust και να τελειώνουμε με αυτό.
Η μετανάστευση δεν ήταν χωρίς προβλήματα. Αυτές οι υπηρεσίες πρέπει να τερματίσουν SSL, να υποστηρίζουν HTTP 1.1, HTTP/2, και ούτω καθεξής. Κάνουν πράγματα όπως η διαχείριση πολλών ροών δεδομένων ταυτόχρονα, διαβάζοντας μέσα από μια edge on-disk lru cache, S3, βάσεις δεδομένων, και επικοινωνώντας σε ένα mesh. Το οικοσύστημα της Java, Vertx και Netty, ήταν πολύ καλό για αυτά τα πράγματα. Πιέζουμε το οικοσύστημα βιβλιοθηκών στα όριά του, και το γεγονός ότι δεν έχουμε πολλά εμπειρία με τις βιβλιοθήκες Rust σήμαινε ότι είχαμε κάποιες δοκιμές και λάθη. Αυτό προκάλεσε κάποια downtime, και ζητούμε συγνώμη γι' αυτό.
Δοκιμάσαμε επίσης διάφορους διαχειριστές μνήμης, καταλήγοντας στο mimalloc για τους προσαρμοσμένους DNS servers μας και στη libc για το transport layer. Δεν χρησιμοποιούμε Nginx ή Apache, αντίθετα χρησιμοποιούμε τον δικό μας συνδυασμό ενός προσαρμοσμένου DNS server που δρομολογεί τους πελάτες παγκοσμίως βάσει ενός μνημονικού δείκτη που ανακατασκευάζεται εβδομαδιαία από το Maxmind και του transport layer μας σε Rust που διατηρεί ένα mesh με τις άλλες περιπτώσεις μεταφοράς. Το transport τερματίζει το SSL, χειρίζεται τη δουλειά pubsub, και είναι το CDN μας. Το όφελος από αυτό είναι λιγότερη overhead κατά τη μεταφορά πραγμάτων μεταξύ υπηρεσιών, και λιγότερη overhead/αφαίρεση υποδομής. Το μειονέκτημα είναι η ορατότητα, οπότε οι καλοί μετρητές είναι σημαντικοί.
Σχετικά με την απόδοση που προκύπτει, οι υπηρεσίες Rust χρησιμοποιούσαν περίπου το 10-30% της μνήμης από τις υπηρεσίες Java, παρά όλη τη δουλειά μας. Διαβάζω βιβλία όπως το Java Concurrency in Practice για διασκέδαση, οπότε ενώ δεν είμαι ειδικός γνωρίζω ένα ή δύο πράγματα για τη συγγραφή ταχέων υπηρεσιών JVM, και ήταν πολύ πιο εύκολο να το επιτύχω αυτό με τη Rust. Επιπλέον, οι κορυφές μηνυμάτων σε μεγάλους αριθμούς συνδρομητών θα καταγραφούν μόλις στο CPU όταν οι υπηρεσίες JVM θα ξόδευαν το 40% του χρόνου τους στο GC, παρά το γεγονός ότι γράφαμε τον κώδικα περισσότερο σαν μηχανή παιχνιδιών και λιγότερο όπως ο τυπικός server. Δεν μπορώ να πω ότι είμαι μεγάλος θαυμαστής της Rust, αλλά για υπηρεσίες που κάνουν πολύ δουλειά και δεν αλλάζουν πολύ μετά την αρχική ανάπτυξη, είναι τέλεια. Η κύρια επιχειρηματική λογική μας παραμένει στην TypeScript.
Η Νέα Αρχιτεκτονική
Η νέα αρχιτεκτονική δεν έχει πια "κατοικίδια" κόμβους. Αντίθετα, κάθε server είναι ένα πλήρες αντίγραφο με όλες τις ίδιες υπηρεσίες και σχεδόν ταυτόσημη διαμόρφωση. Κάθε μία εκτελεί τη μεταφορά, DNS, τον server εφαρμογής, και ένα αντίγραφο της βάσης δεδομένων. Όλοι οι κόμβοι διατηρούν πλήρη κρυπτογράφηση δίσκου με αυτόματη ξεκλείδωμα με Dropbear.
Κάθε server τρέχει τη routing μεταφορά που τερματίζει τις αιτήσεις και τις διαχειρίζεται είτε ως websocket, ροή http, ή αίτημα cdn. Αυτοί οι servers συνδέονται μεταξύ τους και κάθε ένας από αυτούς παρέχει έναν χάρτη του παγκόσμιου δικτύου προς τον τοπικό DNS server του για να ενημερώσει το DNS σε πραγματικό χρόνο πού βρίσκεται κάθε ζωντανός κόμβος παγκοσμίως.
Ένα όφελος της νέας αρχιτεκτονικής είναι η αναδρομή. Αν ένας πελάτης σε μία περιοχή μας χτυπήσει πολύ σκληρά, οι άλλες περιοχές παραμένουν online.
Ο κώδικας εφαρμογής πρέπει τώρα να είναι πολύ προσεκτικός σχετικά με ποιες ερωτήσεις μπορούν να χτυπήσουν τον πλησιέστερο κόμβο ή ποιες πρέπει να πάνε στην κύρια βάση δεδομένων, που μπορεί να είναι μακριά. Κάνοντας ένα λάθος μπορεί δραστικά να μειώσει την απόδοση. Αυτό σημαίνει επίσης ότι οι εγγραφές από ορισμένες περιοχές μπορεί να είναι αργές, και αυτό απαιτεί προσεκτή ρύθμιση και βελτιστοποίηση. Τώρα ακολουθούμε ένα μοτίβο εσωτερικά στον κώδικα όπου όλες οι μέθοδοι που χτυπούν τη βάση δεδομένων παίρνουν ένα επιχείρημα readPreference, έτσι ώστε οι καλούντες μέχρι την κορυφή να αποφασίζουν ρητά πώς να ερωτήσουν.
Το όφελος είναι πολύ καλή οριζόντια κλιμάκωση για αναγνώσεις. Η FastComments είναι πολύ υπέρ των αναγνώσεων, αλλά δεν πρέπει να ξεχνάμε τους μεσολαβητές μας! Οι μεσολαβητές εργάζονται μέρα και νύχτα σε όλο τον κόσμο και θέλουμε η εμπειρία τους να παραμείνει καλή. Ως μέρος αυτής της ανάπτυξης έχουμε συνεργαστεί με μερικούς από αυτούς για να διασφαλίσουμε ότι τα εργαλεία μετριασμού παραμένουν γρήγορα.
Μπορούμε επίσης να επιλέξουμε hardware, που είναι διασκεδαστικό και ανταμείβει. Οι νέοι servers είναι ένας συνδυασμός i5-13500 και Ryzen 5 5600X, και η ΕΕ είναι σε κάποιους παλαιότερους Xeon. Στις δοκιμές μας όλοι αυτοί ήταν πολύ πιο γρήγοροι από τους πιο ακριβούς servers που εξετάζαμε σε άλλους παρόχους. Το μειονέκτημα είναι περισσότερη εργασία ρύθμισης, αλλά το έχουμε αυτοματοποιήσει, μαζί με την παρακολούθηση SMART δίσκων για αποτυχίες κ.λπ.
Κάνοντας αυτές τις δουλειές σημαίνει ότι μπορούμε να συνεχίσουμε να προσφέρουμε ανταγωνιστική τιμολόγηση.
Η Ανάπτυξη
Η ανάπτυξη των τελευταίων μηνών καθώς επανασχεδιάζουμε τις υπηρεσίες και μεταφερόμαστε σε νέους παρόχους φιλοξενίας είχε σκαμπανεβάσματα, σας ευχαριστούμε για την υπομονή σας.
Στην αρχική ανάπτυξη, οι μετρητές μας έδειξαν αύξηση σε αιτήσεις που διαρκούν > 100ms. Προσπαθούμε να μην έχουμε πολλές αιτήσεις που διαρκούν τόσο πολύ για οτιδήποτε.
Ακόμη κάνουμε σταδιακή πρόοδο στην βελτίωση απόδοσης για ορισμένες περιοχές. Ευχαριστούμε όλους όσους έχουν δώσει ανατροφοδότηση μέχρι στιγμής.
Σκέψεις Κατά τη Χρήση του API
Το API παραμένει ισχυρά συνεπές - μπορείτε να διαβάσετε τις δικές σας εγγραφές - για να διατηρήσει την οπισθοδρομική συμβατότητα και να κρατήσει τα πράγματα απλά για τους προγραμματιστές. Για να επιτρέψει στους προγραμματιστές να επιλέξουν την απόδοση σε βάρος της συνέπειας, σχεδιάζουμε να αποκαλύψουμε την παράμετρο readPreference. Το όφελος είναι ότι ενδέχεται επίσης να προσφέρουμε έκπτωση σε πόντους για αυτές τις κλήσεις API.
Όλοι οι δημόσιοι τελικοί σημειωτές, όπως για την εξυπηρέτηση του δημόσιου widget σχολίων, διαβάζουν πάντα από την πλησιέστερη (τοπική) βάση δεδομένων σε εκείνον τον κόμβο.
Γιατί Όχι Απλά Να Χρησιμοποιήσετε Ένα Κανονικό CDN
Οι συζητήσεις σχολίων δεν είναι σταθερές, είναι ζωντανές, και η εφαρμογή μιας ζωντανής ροής σε παλαιά στατικά δεδομένα δεν λειτουργεί επίσης, καθώς όταν βλέπετε μια συζήτηση ως ανώνυμος χρήστης, αποκτάτε μια "ανώνυμη συνεδρία". Σε αυτή την ανώνυμη συνεδρία μπορείτε να κάνετε πράγματα όπως το να αποκλείσετε και να επισημάνετε άλλους χρήστες, και πρέπει να δείξετε αν ο ανώνυμος χρήστης του άρεσε ένα συγκεκριμένο σχόλιο, και ούτω καθεξής. Οι συζητήσεις σχολίων μπορούν επίσης να κλειδώνονται πίσω από SSO, πιστοποίηση ή ομάδες χρηστών.
Τέλος, ο τύπος "προοδευτικής βελτίωσης" όπου τα δυναμικά δεδομένα αντιστοιχίζονται στα στατικά δεδομένα από το CDN σας δίνει κακή εμπειρία, όπου το περιεχόμενο πηδά γύρω ή αλλάζει μετά από μερικά δευτερόλεπτα. Θα προτιμούσαμε να μην το κάνουμε αυτό.
Ποιος Έχει Τώρα Τα Δεδομένα Μου
Τα δεδομένα σας δεν αποθηκεύονται πια στο Linode. Αναπαράγονται ζωντανά μεταξύ Hetzner και OVH με πλήρη κρυπτογράφηση δίσκου, και όλη η επικοινωνία μεταξύ των backend servers γίνεται με TLS. Διατηρούμε μερικές κληρονομικές εμφανίσεις Linode για outbound webhook proxies, αλλά κανένα δεδομένα ή μέσα δεν παραμένουν αποθηκευμένα στο Linode.
Σε Σύνοψη
Όπως και με όλες τις σημαντικές εκδόσεις, είμαστε ευχαριστημένοι που μπορέσαμε να αφιερώσουμε χρόνο για να βελτιστοποιήσουμε, να δοκιμάσουμε και να απελευθερώσουμε σωστά αυτή την αλλαγή. Η FastComments θα πρέπει να κλιμακώνει καλύτερα και να έχει καλύτερη uptime στο μακροπρόθεσμο με αυτή τη δουλειά. Ενημερώστε μας παρακάτω αν ανακαλύψετε οποιαδήποτε προβλήματα.
