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

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

Το Habitat είναι η πλατφόρμα διαδικτυακής αποθήκευσης που δημιουργήσαμε ώστε τα προϊόντα της OpenAI να έχουν γρήγορη και αξιόπιστη πρόσβαση στις απαραίτητες πληροφορίες. Το Habitat διαχειρίζεται πλέον πάνω από 70 εκατομμύρια αιτήματα ανά δευτερόλεπτο και υποστηρίζει, σε σχεδόν 40 γεωγραφικές περιοχές, προϊόντα που χρησιμοποιούνται κάθε εβδομάδα από περισσότερους από 1 δισεκατομμύριο ανθρώπους. Το Habitat κυκλοφόρησε αρχικά για να υποστηρίξει τα GPT στο DevDay 2023, ως μια απλή βιβλιοθήκη Python στην πλευρά του πελάτη, συνδεδεμένη με μία βάση δεδομένων. Σήμερα είναι ένα σύνθετο κατανεμημένο σύστημα που εξυπηρετεί πάνω από 500 petabyte δεδομένων.

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

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

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

Το Habitat ξεκίνησε από μια απλή ιδέα: οι μηχανικοί προϊόντων δεν θα έπρεπε να χρειάζεται να ασχολούνται με τη διαχείριση βάσεων δεδομένων. Το Habitat κυκλοφόρησε αρχικά για να υποστηρίξει τα GPT στο DevDay 2023, ως μια μικρή βιβλιοθήκη Python που αλληλεπιδρούσε με τον κύριο διακομιστή του ChatGPT. Υποστήριζε ένα μικρό σύνολο λειτουργιών που αντιστοιχίζονταν παρασκηνιακά στην εφαρμογή βάσης δεδομένων Azure Cosmos DB.

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

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

Αυτή η βιβλιοθήκη Python λειτούργησε καλά και το Habitat υιοθετήθηκε γρήγορα από τους μηχανικούς προϊόντων της OpenAI, παρότι δεν υπήρξε κεντρική, συντονισμένη προσπάθεια απομάκρυνσης από την αυτοεξυπηρετούμενη χρήση Postgres και Azure Cosmos DB.

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

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

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

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

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

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

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

Γνωρίζαμε ότι χρειαζόμασταν μια υπηρεσία, αλλά δεν θέλαμε ακόμη να εγκαταλείψουμε την Python, παρά την πρόσθετη επιβάρυνση που συνεπάγεται ως υπηρεσία. Η χρήση της Python για μια υπηρεσία υψηλής ρυθμαπόδοσης αύξησε την καθυστέρηση δικτύου και πρόσθεσε σημαντικό κόστος κλιμάκωσης CPU και μνήμης σε σύγκριση με την τοπική εκτέλεση της βιβλιοθήκης. Επιπλέον, γνωρίζαμε ότι οι ανεπάρκειες της Python δεν θα ήταν αποδεκτές σε 100πλάσια κλίμακα, οπότε μια μελλοντική επανεγγραφή ήταν σχεδόν βέβαιη.

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

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

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

Το asyncio βοηθά την Python να εκτελεί ταυτόχρονα φόρτους εργασίας που περιορίζονται από λειτουργίες I/O, αλλά δεν παρακάμπτει το GIL της Python ούτε παρέχει παραλληλισμό CPU. Πέρα από την προώθηση αιτημάτων με έντονο I/O, το Habitat αναλαμβάνει πολλές εργασίες υψηλής χρήσης CPU και παρασκηνίου: δρομολόγηση, συμπίεση, κρυπτογράφηση, υπολογισμό αθροισμάτων ελέγχου, ελέγχους εύρυθμης λειτουργίας κατάντη συστημάτων, σκιώδη εκτέλεση και αντιστάθμιση αιτημάτων.

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

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

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

Έτσι, περιορίζουμε κάθε διεργασία στην εξυπηρέτηση λίγων μόνο ταυτόχρονων αιτημάτων και, αντ’ αυτού, αυξάνουμε μαζικά τον αριθμό των διεργασιών worker της Python.

Κατά την αρχική διάθεση της υπηρεσίας, μέσω ανάλυσης προφίλ CPU σε πραγματικές συνθήκες εντοπίσαμε μία βασική αιτία της υψηλής καθυστέρησης asyncio —και των αντίστοιχων ακραίων καθυστερήσεων—: την περιοδική ανάλυση JSON των διαμορφώσεων σημαιών λειτουργιών μέσω του Statsig, ενός εργαλείου διαχείρισης σημαιών λειτουργιών που χρησιμοποιείται, μεταξύ άλλων, για δοκιμές A/B.

Από προεπιλογή, το Statsig ήταν ρυθμισμένο να ελέγχει κάθε λεπτό για ανανεωμένες διαμορφώσεις, χωρίς χρονική διακύμανση, ενώ η διαμόρφωση περιλάμβανε κάθε κανόνα παραγωγής από όλες τις υπηρεσίες. Παράλληλα, είχε ληφθεί η αρχιτεκτονική απόφαση να εκτελούνται έως 8 διεργασίες Python ανά pod, ώστε να αυξηθεί η χρήση CPU και να μειωθούν οι καθυστερήσεις. Ο συνδυασμός αυτών σήμαινε ότι κάθε λεπτό υπήρχε μια στιγμή κατά την οποία όλοι οι worker κάθε pod σταματούσαν την επεξεργασία ενεργών αιτημάτων και αφιέρωναν τους κύκλους CPU στην ανάλυση ενός τεράστιου αρχείου διαμόρφωσης.

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

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

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

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

Υποψιαστήκαμε ότι έφταιγε η συγκέντρωση συνδέσεων και δοκιμάσαμε την υπόθεση περιορίζοντας τη μέγιστη διάρκεια επαναχρησιμοποίησης συνδέσεων. Αυτό περιόρισε πράγματι την υποβάθμιση και επιβεβαίωσε την κατεύθυνση της έρευνάς μας. Περαιτέρω έρευνα έδειξε ότι το aiohttp TCPConnector της Python χρησιμοποιεί από προεπιλογή επαναχρησιμοποίηση συνδέσεων LIFO: για το επόμενο αίτημα επιλέγεται η σύνδεση που επέστρεψε πιο πρόσφατα. Κανονικά, αυτή είναι μια λογική προεπιλογή: η επαναχρησιμοποίηση πρόσφατων συνδέσεων επιτρέπει στις πρόσθετες συνδέσεις που δημιουργήθηκαν για αιφνίδια αυξημένη κίνηση να λήξουν λόγω αδράνειας, μειώνοντας την επιβάρυνση συντήρησής τους. Στη δική μας περίπτωση, δημιούργησε μετασταθερή αστοχία. Κατά την αιφνίδια αύξηση αιτημάτων, τα αιτήματα προς πιο αργούς, υπερφορτωμένους διακομιστές επέστρεφαν αργότερα τις συνδέσεις στη συγκέντρωση. Έτσι, επιλέγονταν συχνότερα από τα επόμενα αιτήματα, συγκεντρώνοντας σταδιακά περισσότερη κίνηση στα pod που ήδη δυσκολεύονταν. Η τροποποίηση της συγκέντρωσης συνδέσεων ώστε να χρησιμοποιεί επαναχρησιμοποίηση FIFO διέκοψε αυτόν τον βρόχο ανάδρασης και μείωσε ακόμη και τη διακύμανση των αιτημάτων στη σταθερή κατάσταση.

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

Μια παρενέργεια της ρύθμισης για χαμηλή καθυστέρηση asyncio και της ύπαρξης τόσων διεργασιών Python είναι ότι γίνεται πολύ εύκολο να κατακλυστούν οι κατάντη εξαρτήσεις από τον τεράστιο αριθμό συνδέσεων, φαινόμενο γνωστό ως «thundering herd».

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

Βασιζόμαστε επίσης στο Envoy για να μεγιστοποιούμε τη σύγκλιση των συνδέσεων. Το χρησιμοποιούμε για να αναβαθμίζουμε τις συνδέσεις HTTP/1 της Python σε HTTP/2, αξιοποιώντας την πολυπλεξία, και έπειτα να συγκεντρώνουμε αυτές τις συνδέσεις και να παρατείνουμε τη διάρκεια ζωής τους. Το Envoy μάς παρέχει επίσης ένα κεντρικό σημείο για την εφαρμογή ορίων ρυθμού και μηχανισμών διακοπής κυκλώματος, οι οποίοι θα ήταν λιγότερο αποτελεσματικοί σε κάθε αυτόνομη διεργασία Python.

Ένας λόγος που μπορέσαμε να κλιμακώσουμε τόσο πολύ την Python ήταν το περιορισμένο API του Habitat, το οποίο διατηρεί προβλέψιμο το κόστος των αιτημάτων. Αντί να επιτρέπει στους πελάτες να δημιουργούν αυθαίρετα ερωτήματα SQL, τα οποία θα μπορούσαν να προκαλέσουν σαρώσεις μεγάλων πινάκων ή συνδέσεις πολλών πινάκων, το Habitat διαθέτει ένα απλό API NoSQL. Η απουσία ενός ισχυρού API αποτελεί συνειδητό συμβιβασμό στον σχεδιασμό του Habitat.

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

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

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

Το Habitat διαθέτει ένα API NoSQL που βασίζεται σε τύπους αντικειμένων και ακμών τους οποίους ορίζει ο πελάτης, εμπνευσμένο από το TAO⁠(ανοίγει σε νέο παράθυρο). Οι πελάτες προκαθορίζουν αντικείμενα και ακμές, καθώς και τις μεταξύ τους σχέσεις, αλλά όχι το περιεχόμενο κάθε τύπου. Οι σχέσεις που προκύπτουν μοιάζουν με γράφο, αλλά το ίδιο το Habitat δεν υποστηρίζει τυπικά ερωτήματα διάσχισης γράφου, πέρα από την αναζήτηση των άμεσων ακμών ενός συγκεκριμένου αντικειμένου.

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

Για πελάτες με πιο σύνθετες ανάγκες υποβολής ερωτημάτων, παρέχουμε μια δευτερεύουσα προβολή του Habitat εκτός σύνδεσης μέσω του Rockset. Χρησιμοποιούμε καταγραφή αλλαγών δεδομένων (CDC) για τη ροή αλλαγών από τον διαδικτυακό χώρο αποθήκευσης προς απομονωμένες παρουσίες Rockset, σχεδόν σε πραγματικό χρόνο. Κάθε ομάδα πελάτη είναι υπεύθυνη για την κλιμάκωση της δικής της παρουσίας Rockset σύμφωνα με τις σύνθετες ανάγκες υποβολής ερωτημάτων.

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

Η αναβολή της επανεγγραφής από την Python για έναν χρόνο μάς επέτρεψε να εστιάσουμε σε πιο επείγουσες και ουσιαστικές προκλήσεις κατά την περίοδο εκρηκτικής ανάπτυξης. Με την πλατφόρμα να ωριμάζει, την ανάπτυξή μας να επιταχύνεται και την υπηρεσία να είναι η δεύτερη μεγαλύτερη στην OpenAI σε αριθμό πυρήνων —και τέταρτη ως προς το αποτύπωμα Envoy—, είχε έρθει πλέον η ώρα να αφήσουμε πίσω την Python. Στο αποκορύφωμά της, η Python μάς βοήθησε να εξυπηρετούμε πάνω από 20 εκατομμύρια αιτήματα ανά δευτερόλεπτο.

Το δεύτερο τρίμηνο του 2026, με μόλις 2 μηχανικούς, το Codex και το GPT‑5.5, καταφέραμε να επανεγγράψουμε ολόκληρη την υπηρεσία σε Rust. Η νέα υπηρεσία Rust διαχειρίζεται πλέον το 95% των αιτημάτων παραγωγής. Τις επόμενες εβδομάδες θα καταργήσουμε πλήρως την Python. Τα δεδομένα μας δείχνουν ότι η υπηρεσία Rust είναι 6 φορές αποδοτικότερη ως προς τη CPU και 15 φορές αποδοτικότερη ως προς τη μνήμη από την έκδοση Python, με σημαντικά χαμηλότερες μέσες και ακραίες καθυστερήσεις. Σχεδιάζουμε να μοιραστούμε περισσότερα συμπεράσματα σε μελλοντική ανάρτηση.

Η υπηρεσία Python —και πλέον Rust— είναι μόνο μία πτυχή του Habitat. Στο δεύτερο μέρος αυτής της σειράς, όπου εξηγούμε πώς κλιμακώσαμε γρήγορα τον διαδικτυακό χώρο αποθήκευσής μας για την εξυπηρέτηση πάνω από 1 δισεκατομμυρίου χρηστών του ChatGPT, θα μιλήσουμε για το επίπεδο αποθήκευσης και για το πώς το Habitat εξυπηρετεί πάνω από 500 petabyte και περισσότερα από 70 εκατομμύρια αιτήματα ανά δευτερόλεπτο.

Αν θέλετε να εργαστείτε σε συστήματα OLTP κορυφαίας κλίμακας και σας ενδιαφέρει αυτού του είδους η μηχανική, δείτε αυτή την ανοιχτή θέση στην ομάδα μας⁠.