Ταχεία κλιμάκωση online αποθήκευσης για πάνω από 1 δισ. χρήστες του ChatGPT (Μέρος II)

Όλα τα προϊόντα της OpenAI απαιτούν γρήγορη, αξιόπιστη πρόσβαση σε δεδομένα, την οποία παρέχει η πλατφόρμα αποθήκευσής μας, το Habitat. Πρέπει να αποκρίνεται μέσα σε χιλιοστά του δευτερολέπτου σε περισσότερους από 1 δισεκατομμύριο χρήστες σε 40 γεωγραφικές περιοχές. Η υποδομή μας αντιμετώπισε μια εξαιρετικά δύσκολη πρόκληση: να υποστηρίξει εκρηκτική ανάπτυξη και νέες περιπτώσεις χρήσης, βελτιώνοντας παράλληλα την αξιοπιστία, τις επιδόσεις και την ταχύτητα ανάπτυξης προϊόντων. Για να την αντιμετωπίσουμε, χρειάστηκε να επανεξετάσουμε τον σχεδιασμό και τη λειτουργία της πλατφόρμας online αποθήκευσής μας. Σταθμίζαμε διαρκώς τους συμβιβασμούς, με την εξής σειρά: πρώτα επαρκής αξιοπιστία για την κρίσιμη κίνηση των προϊόντων, μετά επαρκής ταχύτητα για χρήστες σε όλο τον κόσμο και, τέλος, αποτελεσματική λειτουργία σε τεράστια κλίμακα.

Αυτή η σειρά δύο μερών εξηγεί πώς εξελίξαμε το Habitat από μια απλή βιβλιοθήκη πελάτη και βάση δεδομένων σε μια παγκοσμίως κατανεμημένη πλατφόρμα αποθήκευσης που εξυπηρετεί πάνω από 500 petabyte δεδομένων. Το Μέρος I εστίασε στην εξέλιξη του Habitat από πελάτη Python σε υπηρεσία. Κάλυψε επίσης τις τεχνικές που μας επέτρεψαν να επεκτείνουμε μια υπηρεσία βασισμένη στην Python πολύ πέρα από ό,τι πολλοί θα θεωρούσαν πρακτικά εφικτό.

Σε αυτή την ανάρτηση, το Μέρος II, παρουσιάζουμε πώς κλιμακώσαμε το υποκείμενο στοιχείο αποθήκευσης: το Azure Cosmos DB. Μέσα από στενή συνεργασία με την ομάδα του Azure, καταλήξαμε σε μια βιώσιμη προσέγγιση πολλών μισθωτών με από κοινού διαχειριζόμενα κοντέινερ και εξαιρετικές επιδόσεις ανάγνωσης σε τεράστια, παγκόσμια κλίμακα.

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

Αντίθετα, η αρχιτεκτονική πολλών μισθωτών αναθέτει τον έλεγχο σε μια κεντρική ομάδα βάσεων δεδομένων, με περισσότερη γνώση και εμπειρία στη δέσμευση πόρων. Δημιουργεί όμως δικά της προβλήματα, όπως τους «θορυβώδεις γείτονες», όπου ένας μισθωτής καταναλώνει ασυνήθιστα μεγάλο μερίδιο πόρων εις βάρος των υπολοίπων.

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

Πριν παρουσιάσουμε την πορεία μας με το Azure Cosmos DB, μερικές βασικές πληροφορίες:

• Ένας λογαριασμός Azure Cosmos DB ορίζει ένα σύνολο κοντέινερ και μια πολιτική αναπαραγωγής

• Για κάθε κοντέινερ δεσμεύεται συγκεκριμένη ρυθμαπόδοση σε μονάδες αιτημάτων ανά δευτερόλεπτο (RU/s)

• Τα δεδομένα κάθε κοντέινερ αποθηκεύονται με τον συνήθη διαμοιρασμό βάσει καθορισμένου κλειδιού λογικού διαμερίσματος, με τεκμηριωμένα όρια αποθήκευσης και ρυθμαπόδοσης ανά κλειδί

• Το Azure Cosmos DB κατανέμει τα κλειδιά λογικών διαμερισμάτων σε λιγότερα υποκείμενα φυσικά διαμερίσματα. Τα διασπά σε περισσότερα όταν ο αποθηκευμένος όγκος υπερβαίνει ένα όριο ή όταν το κοντέινερ χρειάζεται περισσότερα φυσικά διαμερίσματα για να υποστηρίξει τη δεσμευμένη ρυθμαπόδοση

Αρχικά επιτρέπαμε να περνά κάθε φόρτος πελάτη, βασιζόμενοι στο δηλωμένο όριο των 10 χιλ. RU/s ανά κλειδί λογικού διαμερίσματος για την άσκηση αντίθλιψης. Στο ξεκίνημα χρησιμοποιούσαμε επίσης μόνο ένα προεπιλεγμένο κοντέινερ Azure Cosmos DB σε κάθε λογαριασμό. Αυτό λειτουργούσε αρκετά καλά, αλλά αποδείχθηκε προβληματικό για μερικούς λόγους:

Λόγω των αρχικών επιλογών στο API, δώσαμε απευθείας στους πελάτες τη δυνατότητα επιλογής κλειδιού λογικού διαμερίσματος. Ως αποτέλεσμα, έχουμε συχνές συγκρούσεις σε κοινά κλειδιά διαμερισμάτων, όπως user_id ή workspace_id, μεταξύ διαφορετικών περιπτώσεων χρήσης προϊόντων. Επειδή αυτές οι περιπτώσεις χρήσης μοιράζονταν τα όρια του Azure Cosmos DB στα ίδια κλειδιά λογικών διαμερισμάτων, ο σχεδιασμός περιόριζε τη συνολική ρυθμαπόδοση για κάθε χρήστη.

Ένα συνηθισμένο πρόβλημα κατά την κλιμάκωση του Postgres, πριν μεταβούμε στο Habitat και το Azure Cosmos DB, ήταν ότι πολλά αιτήματα από έναν οργανισμό ή κλειδί με πολύ έντονη δραστηριότητα —έναν μισθωτή που δημιουργούσε δυσανάλογα υψηλό φόρτο— μπορούσαν να θέσουν εκτός λειτουργίας ολόκληρη τη βάση δεδομένων. Καταβάλαμε σημαντική συλλογική προσπάθεια για την προσωρινή αποθήκευση αυτών των κλειδιών και την προσθήκη μηχανισμών μίσθωσης στις αστοχίες προσωρινής μνήμης, ώστε ο φόρτος από αυτές να μην κατακλύζει την υποκείμενη βάση δεδομένων.

Παρότι τα τεκμηριωμένα όρια μεγέθους δεδομένων και ρυθμαπόδοσης αφορούν τα κλειδιά λογικών διαμερισμάτων, στην πράξη τα όρια επιβάλλονται στο φυσικό διαμέρισμα. Αυτό σημαίνει ότι τα λογικά διαμερίσματα δεν μπορούν να φτάσουν τις 10.000 RU/s. Αντίθετα, μοιράζονται τα όρια του φυσικού διαμερίσματος με κάθε άλλο κλειδί λογικού διαμερίσματος που φιλοξενείται εκεί.

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

Το όριο ρυθμαπόδοσης ενός φυσικού διαμερίσματος είναι επίσης μεταβλητό και εξαρτάται από τη συνολική ρυθμαπόδοση που έχει εκχωρηθεί στο κοντέινερ του Azure Cosmos DB. Η δεσμευμένη ρυθμαπόδοση του κοντέινερ κατανέμεται περίπου ισόποσα στα φυσικά του διαμερίσματα.

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

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

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

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

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

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

Στο παλιό κοινόχρηστο προεπιλεγμένο κοντέινερ, μια νέα περίπτωση χρήσης που ανέβαινε από 0 σε 1 εκατομμύριο QPS δύσκολα θα άλλαζε αισθητά τη συνολική χρήση. Σε ένα απομονωμένο κοντέινερ, όμως, η ίδια άνοδος από 0 σε 1 εκατομμύριο QPS μπορεί να σήμαινε 1.000 φορές μεγαλύτερο φόρτο από τη βασική στάθμη που προερχόταν μόνο από εσωτερική δοκιμαστική χρήση.

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

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

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

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

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

Καθώς ο οργανισμός μεγάλωνε, αυτά τα λειτουργικά προβλήματα γίνονταν δυσκολότερα στη διαχείριση. Χωρίς μία κεντρική ομάδα υπεύθυνη για τον σχεδιασμό, πολλές ομάδες κατέληγαν να σχεδιάζουν ανεπαρκώς. Έτσι, επιστρέψαμε τελικά σε μια λύση πολλών μισθωτών και συνεργαστήκαμε στενά με την ομάδα του Azure για να διορθώσουμε τα αρχικά προβλήματα, σχεδιάζοντας μια αρχιτεκτονική κοινής χρήσης πόρων:

Περιορίζοντας πρώτα τα αιτήματα για τα κλειδιά με τον μεγαλύτερο φόρτο, εμποδίζουμε τους «θορυβώδεις γείτονες» να καταναλώνουν όλη τη διαθέσιμη ρυθμαπόδοση ενός φυσικού διαμερίσματος. Έτσι μειώνεται το φαινόμενο κατά το οποίο ένα μόνο επιβαρυμένο κλειδί μπορεί να επηρεάσει ολόκληρη την υπηρεσία.

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

Το Azure Cosmos DB διέθετε ήδη λειτουργία χωρίς διακομιστή, η οποία θα έλυνε το πρόβλημα των αδύναμων διαμερισμάτων που είχαμε στη λειτουργία με δεσμευμένους πόρους. Υπήρχε όμως ένα σημαντικό μειονέκτημα: η κλιμάκωση βασιζόταν μόνο στη χρήση αποθηκευτικού χώρου και η χρήση RU περιοριζόταν στις 5 χιλ. RU/s ανά φυσικό διαμέρισμα. Αυτό θα έλυνε το πρόβλημα των αδύναμων διαμερισμάτων, αλλά θα εμπόδιζε την κλιμάκωση περιπτώσεων χρήσης με υψηλές απαιτήσεις σε RU.

Η ομάδα του Azure Cosmos DB ανέπτυξε για εμάς μια νέα, βελτιωμένη λειτουργία χωρίς διακομιστή. Επέτρεπε σε κάθε φυσικό διαμέρισμα να φτάνει έως τις 10 χιλ. RU/s και πρόσθετε διασπάσεις βάσει χρήσης RU, πέρα από εκείνες βάσει αποθηκευτικού χώρου. Έτσι, σταματήσαμε να παρακολουθούμε και να αυξάνουμε χειροκίνητα τη δυναμικότητα των κοντέινερ.

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

Όταν οι εταιρείες φτάνουν στην κλίμακα της OpenAI, οι διαχειριζόμενες υπηρεσίες γίνονται λιγότερο «διαχειριζόμενες». Πολλοί φόρτοι εργασίας ξεφεύγουν από τα συνήθη όρια της υποδομής του παρόχου cloud. Καθώς η OpenAI έγινε ένας από τους μεγαλύτερους χρήστες του Azure Cosmos DB, η επιτυχής λειτουργία του απαιτούσε διαφορετική προσέγγιση: κοινές δοκιμές, κοινούς πίνακες παρακολούθησης, απευθείας διαύλους επικοινωνίας μεταξύ μηχανικών και κοινή ευθύνη για μορφές αστοχίας που εμφανίζονται μόνο στη δική μας κλίμακα. Σήμερα, ο μεγαλύτερος λογαριασμός μας στο Azure Cosmos DB αποθηκεύει δεκάδες petabyte δεδομένων και εξυπηρετεί πάνω από 20 εκατ. QPS. Απ’ όσο γνωρίζουμε, είμαστε η μόνη εταιρεία που έχει θέσει το Azure Cosmos DB σε λειτουργία σε τέτοια κλίμακα.

Στα τέλη του 2024, μια περιφερειακή διακοπή λειτουργίας κατέδειξε γιατί ήταν αναγκαία αυτή η συνεργασία. Τότε, μια διακοπή ρεύματος έπληξε την κύρια περιοχή του Azure για έναν από τους μεγαλύτερους λογαριασμούς μας στο Azure Cosmos DB. Κατά τη μετάβαση στην εφεδρική υποδομή που ακολούθησε, διαπιστώσαμε ότι οι μεγαλύτεροι λογαριασμοί μας χρειάζονταν αρκετές ώρες για να μεταβούν σε δευτερεύουσα περιοχή. Ούτε εμείς ούτε η ομάδα του Azure Cosmos DB το είχαμε δοκιμάσει στη δική μας κλίμακα.

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

Σε κάθε διακοπή, τόσο η OpenAI όσο και το Azure ακολούθησαν τις διαδικασίες διαχείρισης περιστατικών, εντοπίζοντας αρκετές βασικές αιτίες και εφαρμόζοντας διορθώσεις. Οι διακοπές αυτές, όμως, ήταν συμπτώματα ενός ευρύτερου συστημικού προβλήματος στον τρόπο με τον οποίο η ομάδα μας και η ομάδα του Azure Cosmos DB λειτουργούσαν και έκαναν δοκιμές. Αρχικά, οι διαχειριζόμενες υπηρεσίες μάς επέτρεψαν να κινηθούμε γρήγορα και να εστιάσουμε στους επιχειρηματικούς στόχους. Σε μεγάλη κλίμακα, οι διαχειριζόμενες υπηρεσίες γίνονται λιγότερο διαχειριζόμενες και απαιτούν στενή συνεργασία με τον πάροχο σε όλα τα επίπεδα, από τον σχεδιασμό έως τη λειτουργία.

Σήμερα, οι ομάδες μηχανικών του Habitat και του Azure παρακολουθούν από κοινού κάθε επίπεδο του Habitat, από τα επίπεδα υπηρεσιών μας έως τα επίπεδα φυσικής αποθήκευσης του Azure Cosmos DB. Λειτουργούμε και δοκιμάζουμε αλλαγές σε έναν λογαριασμό Azure Cosmos DB μεγέθους παραγωγής, που όμως δεν χρησιμοποιείται στην παραγωγή. Δοκιμάζουμε και βελτιώνουμε μαζί τα SDK και καθορίζουμε βέλτιστες πρακτικές για την κλιμάκωση και τη διαστασιολόγηση των λογαριασμών μας στο Azure Cosmos DB. Οι μηχανικοί μας επικοινωνούν απευθείας μέσω του Teams και έχουμε ακόμη δημιουργήσει τρόπους άμεσης ειδοποίησης των εφημερευόντων της άλλης ομάδας, χωρίς να περνάμε από βαθμίδες υποστήριξης.

Τον τελευταίο χρόνο συνεργαστήκαμε εκτενώς για να βελτιώσουμε την κλιμάκωση του επιπέδου ελέγχου και της πύλης του Azure Cosmos DB. Προσθέσαμε προστασία από υπερφόρτωση και προσωρινή αποθήκευση διαφόρων μεταδεδομένων του Azure Cosmos DB στην πύλη του, ώστε να προστατεύσουμε το διαμέρισμα μεταδεδομένων. Μειώσαμε την πίεση από τις διεργασίες Python του habitat-service με δεξαμενές συνδέσεων και συχνότερη επαναχρησιμοποίησή τους, τοποθετήσαμε φόρτους εργασίας στην ίδια περιοχή όπου ήταν εφικτό και απομονώσαμε τους κρίσιμους φόρτους από τους μη διαδραστικούς φόρτους μέσω διαφορετικών VPC.

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

Όπως αναφέραμε στο Μέρος I, η βασική μας φιλοσοφία είναι: πρώτα να λειτουργεί, μετά να είναι γρήγορο και τέλος οικονομικό. Πρώτα η αξιοπιστία, μετά οι επιδόσεις και έπειτα η αποδοτικότητα. Το Habitat είχε γίνει κρίσιμη υποδομή για την OpenAI, οπότε πρώτη προτεραιότητα ήταν να διασφαλίσουμε την αξιοπιστία του. Καθώς το σύστημα σταθεροποιήθηκε το 2025 και η OpenAI επεκτεινόταν παγκοσμίως, ο χρόνος απόκρισης έγινε ο επόμενος περιοριστικός παράγοντας για χρήστες και ομάδες προϊόντων.

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

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

Το 2026 αυτό αποτελεί βασική μας προτεραιότητα. Αναπτύξαμε μια πολυεπίπεδη στρατηγική βελτιστοποίησης των αναγνώσεων, που αντιπροσωπεύουν πάνω από το 90% των αιτημάτων του Habitat:

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

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

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

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

Για φόρτους με τις αυστηρότερες απαιτήσεις χρόνου απόκρισης, όπως τα μεταδεδομένα ελέγχου ταυτότητας που χρειάζονται σε κάθε αίτημα, μειώνουμε τον χρόνο μετ’ επιστροφής (RTT) μεταξύ υπολογιστικών πόρων και Habitat, χρησιμοποιώντας λογαριασμούς Azure Cosmos DB με εκτεταμένη αναπαραγωγή σε πολλές δευτερεύουσες περιοχές. Ορισμένοι λογαριασμοί αναπαράγονται και στις 40 περιοχές του Azure όπου εξυπηρετούμε κίνηση, ενώ άλλοι σε τουλάχιστον μία περιοχή ανά ήπειρο.

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

Ωστόσο, και αυτή η προσέγγιση περιορίζεται τελικά από τη χωρητικότητα, γι’ αυτό εφαρμόζεται μόνο σε λίγα, προσεκτικά επιλεγμένα σύνολα δεδομένων.

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

Έχουμε ενσωματώσει στο Habitat ένα κατανεμημένο επίπεδο προσωρινής μνήμης τύπου lookaside. Αποθηκεύει αντίγραφα αντικειμένων και ακμών με πρόσφατη πρόσβαση σε διακομιστές Valkey της υποδομής μας, κοντά στα σημεία επεξεργασίας των αιτημάτων χρηστών. Συνήθως, τέτοιες προσωρινές μνήμες χρησιμοποιούν έναν χρόνο ζωής (TTL) που εξισορροπεί το ποσοστό επιτυχιών με την παλαιότητα των δεδομένων. Οι σύντομοι TTL μειώνουν την παλαιότητα, αλλά περιορίζουν το όφελος της προσωρινής μνήμης: τα στοιχεία λήγουν γρήγορα και πρέπει να ανακτώνται συχνότερα. Οι μεγαλύτεροι TTL βελτιώνουν τα ποσοστά επιτυχιών, αλλά παρέχουν παρωχημένα δεδομένα για περισσότερο χρόνο, προκαλώντας κακή εμπειρία χρήσης και απρόβλεπτη συμπεριφορά προϊόντων.

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

Υιοθετήσαμε μια πιο προηγμένη προσέγγιση ακύρωσης, ακολουθώντας το παράδειγμα συστημάτων όπως το TAO της Meta. Η ενσωματωμένη προσωρινή μνήμη του Habitat βασίζεται στην καταγραφή αλλαγών δεδομένων (CDC), μέσω της ροής αλλαγών του Azure Cosmos DB, για να διαδίδει ακυρώσεις παγκοσμίως μέσα σε δευτερόλεπτα. Έτσι επιτυγχάνει υψηλά ποσοστά επιτυχιών με χαμηλή παλαιότητα δεδομένων. Μια υπηρεσία στην υποδομή μας διαβάζει αυτή τη ροή αλλαγών και ακυρώνει καταχωρίσεις στις τοπικές προσωρινές μνήμες όταν ενημερώνονται τα υποκείμενα δεδομένα. Στην επόμενη ανάγνωση, τα δεδομένα δεν βρίσκονται στην προσωρινή μνήμη και αυτή συμπληρώνεται με την πιο πρόσφατη έκδοσή τους.

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

Συνολικά, οι αλλαγές αυτές μείωσαν το παγκόσμιο p50 του χρόνου απόκρισης των αναγνώσεων από περίπου 120 ms σε περίπου 10 ms: βελτίωση κατά 12 φορές από τότε που εστιάσαμε στις επιδόσεις, στις αρχές του έτους.

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

Η αξιόπιστη και κλιμακούμενη CDC —η διάδοση αλλαγών της βάσης δεδομένων σε κατάντη συστήματα— είναι κρίσιμη όχι μόνο για τη στρατηγική προσωρινής αποθήκευσης του Habitat. Εκατομμύρια καταγεγραμμένες αλλαγές ανά δευτερόλεπτο, από χιλιάδες κοντέινερ και εκατομμύρια διαμερίσματά τους, διοχετεύονται σε πάνω από εκατό θέματα Kafka. Τροφοδοτούν επίσης δευτερεύοντα ευρετήρια με τελική συνέπεια, ροές μετακίνησης δεδομένων, αναλύσεις εκτός πραγματικού χρόνου, καθώς και λειτουργίες προϊόντων σε πραγματικό χρόνο. Καθώς η υποκείμενη υποδομή μας επεκτείνεται παγκοσμίως, η παρακολούθηση αλλαγών στις γραμμές γίνεται όλο και πιο περίπλοκη. Για να καταχωρίσει ένας πελάτης συνάρτηση επανάκλησης που εκτελείται όταν αλλάζουν γραμμές του τύπου του, πρέπει πρώτα, μεταξύ άλλων, να εντοπίσει τους λογαριασμούς και τα κοντέινερ Cosmos που περιέχουν τα δεδομένα του και ποια εγκατάσταση CDC τα παρακολουθεί στις αντίστοιχες περιοχές. Πρέπει επίσης να κλιμακώσει σωστά το σύνολο διεργασιών εργασίας της CDC, το Kafka και τον καταναλωτή του. Η πλατφόρμα CDC μας στοχεύει να κρύψει όλη αυτή την πολυπλοκότητα από τους προγραμματιστές προϊόντων. Παρέχει μια απλή διεπαφή όπου οι πελάτες καταχωρίζουν τη συνάρτηση που θέλουν να καλείται για τις αλλαγμένες γραμμές τους, ενώ εμείς αναλαμβάνουμε τη διασύνδεση και την κλιμάκωση.

Ένα εσωτερικό επίπεδο ελέγχου διασφαλίζει συνεχώς ότι καταγράφονται οι αλλαγές όλων των απαιτούμενων κοντέινερ, επιλέγει τις περιοχές Cosmos από τις οποίες θα διαβάζει και κατανέμει αποδοτικά την εργασία σε χιλιάδες διεργασίες, σε πολλές γεωγραφικές περιοχές. Οι περιοχές αντιγράφων και οι αναγνώσεις ροής χαμηλότερης προτεραιότητας προστατεύουν την ευαίσθητη στον χρόνο απόκρισης κίνηση του Habitat από τους φόρτους καταγραφής στο παρασκήνιο. Σε ένα τόσο μεγάλο σύνολο διεργασιών, προκύπτουν συνεχώς καταρρεύσεις, προβλήματα κοντέινερ, σφάλματα αποθήκευσης μισθώσεων, μη έγκυρες ρυθμίσεις και αστοχίες προορισμού. Θωρακίσαμε τον κύκλο ζωής των διεργασιών CDC και τη διαχείριση μισθώσεων, απομονώσαμε τις αστοχίες μεταξύ ροών και δημιουργήσαμε δικλίδες ασφαλείας για αλλαγές ρυθμίσεων και νέες εκδόσεις. Χρησιμοποιούμε ουρές μη παραδοτέων μηνυμάτων, ώστε οι μόνιμες αποτυχίες παράδοσης να μην εμποδίζουν την επεξεργασία των επόμενων μηνυμάτων στην ουρά. Αντέχουμε περιφερειακές διακοπές λειτουργίας στρέφοντας τις διεργασίες ανάγνωσης σε εναλλακτικές περιοχές Cosmos. Στη δική μας κλίμακα, χρειάστηκε ακόμη να αλλάξουμε το SDK CDC του Azure για αποδοτικότερη αποθήκευση σημείων ελέγχου: τα συγκεντρώνουμε σε παρτίδες στη μνήμη και τα εγγράφουμε μόνιμα μόνο περιοδικά.

Παρότι η εσωτερική χρήση του Azure Cosmos DB από το Habitat είναι περίπλοκη, η αξία του ήταν πάντα ότι κρύβει τις λεπτομέρειες της υποδομής από τους προγραμματιστές, επιταχύνοντας την ανάπτυξη προϊόντων. Το ίδιο ισχύει για την πλατφόρμα CDC μας.

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

Για να κλιμακώσουμε το Habitat και την αποθήκευση συνομιλιών για το επόμενο δισεκατομμύριο χρήστες, πρέπει να αντιμετωπίσουμε τη δυσκολία αναπαραγωγής των δεδομένων σε όλη την υποδομή μας, σε ακόμη μεγαλύτερη κλίμακα. Για να προλάβουμε αυτή την ανάγκη, αναπτύσσουμε εσωτερικά ένα προσαρμοσμένο σύστημα online αποθήκευσης κλίμακας exabyte, βελτιστοποιημένο για τους ογκώδεις τύπους δεδομένων του Habitat. Το υπό ανάπτυξη σύστημα συνδυάζει τον πυρήνα RocksDB Cloud της Rockset με αναπαραγωγή βασισμένη στο Raft. Υλοποιεί το ίδιο μοντέλο εγγράφων με το Azure Cosmos DB, αλλά χρησιμοποιεί αποθήκευση αποσυνδεδεμένη από τους υπολογιστικούς πόρους και φυσική αναπαραγωγή, μειώνοντας την απαιτούμενη χωρητικότητα flash με αντάλλαγμα χαμηλότερο μέγιστο QPS.

Αν σας ενδιαφέρει να εργαστείτε σε τέτοια έργα υποδομής δεδομένων, σε κλίμακα που αγγίζει τα όρια της τεχνολογίας, δείτε τις ανοιχτές θέσεις μας⁠.