Habitat: come OpenAI ha scalato lo storage online per oltre un miliardo di utenti (Parte II)

Introduzione a Habitat e alla sua evoluzione

Tutti i prodotti OpenAI richiedono accesso rapido e affidabile ai dati, fornito dalla piattaforma di storage interna, Habitat. Il sistema deve rispondere in millisecondi per più di un miliardo di utenti distribuiti in 40 regioni geografiche. La sfida principale è stata far fronte a una crescita esplosiva, a nuovi casi d’uso e, contemporaneamente, migliorare affidabilità, prestazioni e velocità di sviluppo per i team di prodotto.

Il percorso è stato suddiviso in tre fasi: prima raggiungere la stabilità necessaria per il traffico mission‑critical, poi garantire la velocità per gli utenti globali, infine operare con efficienza su larga scala. La prima parte della serie (Parte I) ha illustrato il passaggio da una libreria client Python a un servizio indipendente, evidenziando le tecniche che hanno permesso a un servizio basato su Python di superare i limiti tradizionali.

In questa seconda parte approfondiamo come è stato scalato il componente di storage sottostante, Azure Cosmos DB, e come, grazie a una stretta collaborazione con il team Azure, si è arrivati a una soluzione di multi‑tenancy co‑gestita con prestazioni di lettura eccellenti a livello globale.

Cos’è Habitat?

Habitat è la piattaforma di storage online costruita per consentire ai prodotti OpenAI di accedere rapidamente e in modo affidabile alle informazioni necessarie.

• Request
• Response
• Changes (CDC)

Multi‑tenancy: affidabilità e scala

Man mano che le aziende crescono, le infrastrutture passano da sistemi single‑tenant a soluzioni multi‑tenant. Il modello single‑tenant, in cui ogni team mantiene il proprio sistema, riduce il raggio d'azione di eventuali guasti e facilita l'isolamento delle risorse. Tuttavia, con l’aumento del numero di team, questa modalità diventa costosa e porta spesso a un eccessivo provisioning.

Il modello multi‑tenant, gestito da un team centralizzato, offre una migliore capacità di pianificazione delle risorse, ma introduce problemi come i “noisy‑neighbor”, dove un tenant consuma una quota sproporzionata di risorse a discapito degli altri.

Habitat ha dovuto bilanciare questi trade‑off per creare un sistema di storage affidabile ed efficiente. Dopo diversi cicli di sperimentazione, è passata da un unico container multi‑tenant di Azure Cosmos DB a container singoli per alcuni casi d’uso, per poi ritornare a un container multi‑tenant di default, sfruttando al massimo le primitive native di Cosmos DB.

Premessa su Azure Cosmos DB

Prima di entrare nei dettagli della migrazione, è utile ricordare alcuni concetti chiave di Azure Cosmos DB:

• Un account Cosmos definisce un set di container e una politica di replica.
• Ogni container è provisionato con un determinato throughput espresso in request units al secondo (RU/s).
• I dati sono shardati secondo una chiave di partizione logica, con limiti documentati di storage e throughput per chiave.
• Cosmos gestisce lo sharding delle chiavi logiche su partizioni fisiche, creando nuove partizioni fisiche quando lo storage supera una soglia o quando il throughput richiesto supera la capacità della partizione corrente.

Fase I: Affidarsi alle primitive di Cosmos DB

Inizialmente Habitat consentiva a qualsiasi client di caricare dati, basandosi sul limite di 10 000 RU/s per chiave di partizione logica come meccanismo di back‑pressure. L’intero account utilizzava un unico container di default per tutti i prodotti. Questo approccio ha funzionato per un periodo, ma ha evidenziato diverse criticità.

Limiti della chiave di partizione logica

Le scelte API iniziali esponevano direttamente la chiave di partizione logica ai client, generando collisioni frequenti su chiavi comuni come userid o workspaceid. Poiché più casi d’uso condividevano lo stesso limite di throughput per quelle chiavi, la capacità complessiva per un singolo utente veniva limitata.

Un problema analogo era stato riscontrato in Postgres prima della migrazione: una singola organizzazione “hot” o una chiave molto attiva poteva saturare l’intero database. La soluzione adottata era stata quella di cache e lease per mitigare il carico sui miss della cache.

Noisy neighbors

I limiti documentati di dimensione e throughput si applicano alle chiavi logiche, ma le restrizioni reali vengono applicate alle partizioni fisiche. Di conseguenza, le chiavi logiche non possono raggiungere i 10 000 RU/s in modo indipendente, ma condividono il limite della partizione fisica su cui risiedono.

Questo ha permesso a tenant rumorosi di influenzare chiavi logiche non correlate, con impatti su flussi critici come login e signup.

Partizioni deboli

Il throughput per partizione fisica dipende dal throughput totale provisionato per il container e viene distribuito in modo approssimativamente uniforme. Quando il volume dei dati cresce, le partizioni fisiche si suddividono, ma il throughput totale rimane invariato, riducendo la capacità per partizione.

Per i casi d’uso più “blob‑like”, la crescita dello storage riduceva la capacità di throughput, creando un “failure mode” in cui il carico rimaneva stabile ma la capacità diminuiva.

Divisione delle partizioni

Una partizione si divide quando raggiunge il limite di storage; ciascuna partizione figlia eredita metà del throughput della madre, riducendo ulteriormente la capacità disponibile per i carichi attivi.

Fase II: Isolamento dei carichi e single‑tenant

Per mitigare i problemi di partizionamento e noisy‑neighbor, Habitat ha introdotto container separati per i casi d’uso più critici. Ogni container disponeva di partizioni fisiche proprie, limitando l’impatto dei carichi rumorosi.

È stato inoltre sviluppato uno script per sincronizzare il throughput totale di ogni container con il numero di partizioni fisiche, gestendo così le partizioni deboli.

Vantaggi e svantaggi del modello single‑tenant

• Vantaggi: isolamento delle partizioni, riduzione dei noisy‑neighbor, capacità di ottimizzare il provisioning per caso d’uso specifico.
• Svantaggi: overhead nella creazione e nella pianificazione delle capacità per ogni nuovo container; necessità di migrare dati da container legacy.

Molti team sono stati incoraggiati a creare container separati per nuovi servizi o funzionalità importanti, ma le migrazioni dei dati legacy hanno richiesto tempo e hanno introdotto nuovi punti di fallimento.

Fase III: Ritorno al multi‑tenant con ottimizzazioni

Con l’aumento del carico sul container di default, gli incidenti di produzione sono cresciuti. Habitat ha quindi deciso di tornare a un modello multi‑tenant di default, ma con una gestione più fine delle partizioni e delle risorse.

Le principali azioni intraprese sono state:

• Utilizzare le primitive di Azure Cosmos DB per la gestione automatica delle partizioni.
• Implementare meccanismi di throttling basati su chiavi logiche per limitare i carichi “hot”.
• Adottare una politica di “co‑managed containers”, in cui i team di prodotto condividono container ma hanno linee guida rigide per la scelta delle chiavi di partizione.
• Monitorare costantemente il rapporto tra storage e throughput per evitare la divisione delle partizioni con perdita di capacità.

Queste misure hanno permesso di mantenere le prestazioni di lettura a livello globale, riducendo al contempo la complessità operativa e i costi di provisioning.

Lezioni apprese e prossimi passi

Il percorso di Habitat dimostra che la scalabilità di una piattaforma di storage richiede una valutazione continua dei trade‑off tra isolamento, efficienza e complessità. Le principali lezioni includono:

• Iniziare con affidabilità, poi velocità, infine scala. La stabilità è la base su cui costruire prestazioni elevate.
• Il design delle chiavi di partizione è cruciale. Scelte sbagliate portano a collisioni e a noisy‑neighbor.
• Il modello multi‑tenant può funzionare a grandi scale se supportato da primitive native. Azure Cosmos DB fornisce gli strumenti necessari, ma è fondamentale usarli correttamente.
• Automazione e monitoraggio sono indispensabili. Script per sincronizzare throughput e partizioni riducono gli interventi manuali.

Guardando al futuro, Habitat continuerà a ottimizzare la gestione delle partizioni, a esplorare soluzioni di caching più avanzate e a valutare l’adozione di nuovi servizi di storage che possano offrire ulteriori vantaggi di latenza e costi.

Conclusioni

Habitat è passata da una semplice libreria Python a una piattaforma di storage globale che gestisce oltre 500 petabyte di dati per più di un miliardo di utenti. Il viaggio attraverso le fasi di single‑tenant, multi‑tenant e co‑managed container ha permesso di superare limitazioni tecniche di Azure Cosmos DB, garantendo prestazioni di lettura a livello mondiale. La combinazione di design attento delle chiavi di partizione, automazione del provisioning e collaborazione stretta con il team Azure ha trasformato una sfida di scala in un caso di studio di successo per le architetture cloud moderne.