PostgreSQL:n skaalaaus palvelee 800 miljoonaa ChatGPT‑käyttäjää

Jo vuosia PostgreSQL on ollut yksi tärkeimmistä taustalla toimivista tietojärjestelmistä, jotka tukevat keskeisiä tuotteita, kuten ChatGPT:tä ja OpenAI:n API:a. Käyttäjäkuntamme kasvaessa nopeasti, myös tietokantoihimme kohdistuvat vaatimukset ovat kasvaneet räjähdysmäisesti. Viime vuoden aikana PostgreSQL-kuormituksemme on kasvanut yli kymmenkertaiseksi, ja se jatkaa nopeaa kasvuaan.

Pyrkimyksemme kehittää tuotantoinfrastruktuuriamme tämän kasvun ylläpitämiseksi paljasti uuden oivalluksen: PostgreSQL:ää voidaan skaalata tukemaan luotettavasti paljon suurempia lukupainotteisia työkuormia kuin monet aiemmin pitivät mahdollisena. Järjestelmä (jonka on alun perin kehittänyt tutkijaryhmä Kalifornian yliopistossa, Berkeley) on mahdollistanut valtavan globaalin liikenteen tukemisen yhdellä ensisijaisella Azure PostgreSQL -joustavalla palvelininstanssilla⁠(avautuu uudessa ikkunassa) ja lähes 50 lukureplikalla, jotka ovat hajautettuina useille alueille ympäri maailmaa. Tämä on tarina siitä, kuinka olemme skaalanneet PostgreSQL:n OpenAI:ssa tukemaan miljoonia kyselyitä sekunnissa 800 miljoonalle käyttäjälle tiukan optimoinnin ja vankan suunnittelun avulla. Kerromme myös tärkeimmät oppimamme asiat, jotka olemme oppineet matkan varrella.

ChatGPT:n julkaisun jälkeen liikenne kasvoi ennennäkemättömällä nopeudella. Tämän tueksi toteutimme nopeasti laajoja optimointeja sekä sovellus- että PostgreSQL-tietokantatasolla, kasvatimme kapasiteettia lisäämällä instanssin kokoa ja laajensimme lisäämällä lukureplikoita. Tämä arkkitehtuuri on palvellut meitä erinomaisesti pitkän aikaa. Jatkuvien parannusten myötä se tarjoaa edelleen runsaasti mahdollisuuksia tulevaisuuden kasvuun.

Saattaa kuulostaa yllättävältä, että yhden pääarkkitehtuurin avulla voidaan vastata OpenAI:n mittakaavan vaatimuksiin, mutta tämän toteuttaminen käytännössä ei ole helppoa. Olemme havainneet useita SEV-tapauksia, jotka ovat johtuneet Postgresin ylikuormituksesta, ja ne noudattavat usein samaa kaavaa: ylävirran ongelma aiheuttaa äkillisen piikin tietokantakuormassa, kuten laajamittaiset välimuistivirheet välimuistikerroksen vian vuoksi, kalliiden monisuuntaisten liitosten aalto, joka kuormittaa CPU:n, tai uuden ominaisuuden julkaisun aiheuttama kirjoitusmyrsky. Kun resurssien käyttöaste nousee, kyselyiden viive kasvaa ja pyynnöt alkavat aikakatkaistua. Uudelleenyritykset lisäävät kuormitusta, mikä käynnistää noidankehän, joka voi heikentää koko ChatGPT- ja API-palveluiden toimintaa.

Vaikka PostgreSQL skaalautuu hyvin lukupainotteisiin työkuormiin, kohtaamme silti haasteita suurten kirjoitusliikennemäärien aikana. Tämä johtuu suurelta osin PostgreSQL:n moniversioisen samanaikaisuuden hallinnan (MVCC) toteutuksesta, mikä tekee siitä vähemmän tehokkaan kirjoitusintensiivisissä työkuormissa. Esimerkiksi, kun kysely päivittää tuple-tyyppisen tietueen tai jopa yhden kentän, koko rivi kopioidaan uuden version luomiseksi. Suurilla kirjoituskuormilla tämä johtaa merkittävään kirjoitusvahvistukseen. Se myös lisää lukemisen vahvistusta, koska kyselyt joutuvat skannaamaan useita tuple-versioita (vanha tuple) saadakseen uusimman version. MVCC tuo mukanaan lisähaasteita, kuten taulukoiden ja indeksien paisuminen, lisääntynyt indeksien ylläpidon kuormitus sekä monimutkainen autovacuum-säätö. (Näistä aiheista löytyy syvällisempi katsaus blogista, jonka kirjoitin yhdessä Carnegie Mellonin yliopiston professori Andy Pavlon kanssa. Blogin nimi on The Part of PostgreSQL We Hate the Most⁠(avautuu uudessa ikkunassa) (PostgreSQL:n osa, jota vihaamme eniten), ja se on mainittu⁠(avautuu uudessa ikkunassa) PostgreSQL:n Wikipedia-sivulla.)

Näiden rajoitusten lieventämiseksi ja kirjoituspaineen vähentämiseksi olemme siirtäneet ja jatkamme siirtämistä pirstoutuneisiin työkuormiin (eli työkuormiin, jotka voidaan osioida vaakasuunnassa), kirjoituspainotteiset työkuormat pirstoutuneisiin järjestelmiin, kuten Azure Cosmos DB:hen, optimoimalla sovelluslogiikkaa tarpeettomien kirjoitusten vähentämiseksi. Emme myöskään enää salli uusien taulukoiden lisäämistä nykyiseen PostgreSQL-käyttöönottoon. Uudet työkuormat oletuksena siirtyvät pirstoutuneisiin järjestelmiin.

Vaikka infrastruktuurimme on kehittynyt, PostgreSQL on pysynyt pirstoutumattomana, ja kaikki kirjoituksia palvelee yksi ensisijainen instanssi. Ensisijainen syy on, että olemassa olevien sovellustyökuormien pirstominen olisi erittäin monimutkaista ja aikaa vievää, vaatisi muutoksia satoihin päätepisteisiin ja voisi kestää kuukausia tai jopa vuosia. Koska työkuormamme ovat pääasiassa lukupainotteista ja olemme toteuttaneet laajoja optimointeja, nykyinen arkkitehtuuri tarjoaa edelleen runsaasti liikkumavaraa jatkuvan liikenteen kasvun tukemiseen. Vaikka emme sulje pois mahdollisuutta pirstoa PostgreSQL:ää tulevaisuudessa, se ei ole lähitulevaisuuden prioriteetti, koska meillä on riittävästi liikkumavaraa nykyiseen ja tulevaan kasvuun.

Seuraavissa osioissa käsittelemme kohtaamiamme haasteita ja laajoja optimointeja, jotka toteutimme niiden ratkaisemiseksi ja estääksemme tulevia käyttökatkoksia, vieden PostgreSQL:n äärirajoille ja skaalaten sen miljooniin kyselyihin sekunnissa (QPS).

Haaste: Kun kirjoittajia on vain yksi, yhden ensisijaisen kokoonpanon kirjoituskapasiteetti ei skaalaudu. Voimakkaat kirjoitushuipput voivat nopeasti ylikuormittaa ensisijaisen palvelimen ja vaikuttaa palveluihin, kuten ChatGPT ja API.

Ratkaisu: minimoimme ensisijaisen palvelimen kuormitusta mahdollisimman paljon – sekä lukemisen että kirjoittamisen osalta, jotta sillä on riittävästi kapasiteettia käsitellä kirjoituspiikkejä. Lukuliikenne siirretään replikoille aina kun mahdollista. Jotkin lukukyselyt on kuitenkin pidettävä ensisijaisessa palvelimessa, koska ne ovat osa kirjoitustapahtumia. Niiden osalta keskitymme varmistamaan, että ne ovat tehokkaita ja että vältämme hitaita kyselyitä. Kirjoitusliikenteen osalta olemme siirtäneet jaettavat, kirjoituspainotteiset työkuormat pirstoutuneisiin järjestelmiin, kuten Azure CosmosDB:hen. Työkuormat, joita on vaikeampi pirstouttaa mutta jotka tuottavat silti suuren kirjoitusvolyymin, vievät pidempään siirtää, ja prosessi on edelleen käynnissä. Optimoimme myös sovelluksiamme aggressiivisesti kirjoituskuormituksen vähentämiseksi. Esimerkiksi korjasimme sovellusten virheitä, jotka aiheuttivat turhia kirjoituksia, ja otimme käyttöön viivästettyjä kirjoituksia, kun se oli tarkoituksenmukaista, liikenteen piikkien tasoittamiseksi. Lisäksi taulukon kenttien täyttämisessä noudatamme tiukkoja nopeusrajoituksia, jotta vältetään liiallinen kirjoituskuormitus.

Haaste: Tunnistimme useita kalliita kyselyitä PostgreSQL:ssä. Aiemmin näiden kyselyjen äkilliset volyymipiikit kuluttivat suuria määriä CPU-tehoa, mikä hidasti sekä ChatGPT:tä että API-pyyntöjä.

Ratkaisu: Muutamat kalliit kyselyt, kuten useiden taulukoiden yhdistäminen, voivat heikentää merkittävästi tai jopa kaataa koko palvelun. Meidän täytyy jatkuvasti optimoida PostgreSQL-kyselyitä varmistaaksemme niiden tehokkuuden ja välttääksemme yleisiä Online Transaction Processing (OLTP) -antimalleja. Esimerkiksi kerran havaitsimme erittäin kalliin kyselyn, joka yhdisti 12 taulukkoa ja jonka piikit olivat aiheuttaneet aiemmin vakavia SEV-tapauksia. Meidän tulisi välttää monimutkaisia usean taulun liitoksia aina kun mahdollista. Jos liitokset ovat tarpeen, opimme harkitsemaan kyselyn jakamista osiin ja siirtämään monimutkaisen liitoslogiikan sovelluskerrokseen. Monet näistä ongelmallisista kyselyistä luodaan Object-Relational Mapping -kehyksillä (ORM), joten on tärkeää tarkistaa huolellisesti niiden tuottama SQL ja varmistaa, että se toimii odotetulla tavalla. On myös tavallista löytää pitkäkestoisia käyttämättömiä kyselyitä PostgreSQL:ssä. Aikakatkaisujen, kuten idle_in_transaction_session_timeout, määrittäminen on tärkeää, jotta ne eivät estä autovacuum-toimintoa.

Haaste: Jos lukureplika kaatuu, liikenne voidaan silti ohjata muihin replikoihin. Yhden kirjoittajan varaan luottaminen tarkoittaa kuitenkin yhtä ainoaa vikakohtaa – jos se kaatuu, koko palvelu kärsii.

Ratkaisu: Suurin osa kriittisistä pyynnöistä koskee vain lukukyselyjä. Ensisijaisen palvelimen yksittäisen vikakohdan vaikutusten lieventämiseksi siirsimme nämä lukutoiminnot kirjoittajalta replikoihin, jolloin pyynnöt voivat jatkua myös ensisijaisen palvelimen kaatuessa. Kirjoitustoiminnot epäonnistuvat edelleen, mutta vaikutus on vähäisempi; kyseessä ei ole enää SEV0, koska lukutoiminnot ovat edelleen käytettävissä.

Ensisijaisten vikojen lieventämiseksi käytämme ensisijaista palvelinta High-Availability (HA) -tilassa yhdessä hot standby -varajärjestelmän kanssa, joka on jatkuvasti synkronoitu replika ja aina valmis ottamaan palveluliikenteen vastuulleen. Jos ensisijainen palvelin kaatuu tai se on otettava pois käytöstä huoltoa varten, voimme nopeasti vaihtaa varapalvelimen käyttöön minimoidaksemme käyttökatkot. Azure PostgreSQL -tiimi on tehnyt merkittävää työtä varmistaakseen, että nämä failoverit pysyvät turvallisina ja luotettavina myös erittäin suuren kuormituksen alla. Lukureplikoiden vikatilanteiden hallitsemiseksi otamme käyttöön useita replikoita jokaisessa alueessa riittävällä kapasiteettivarmuudella, jotta yhden replikaan vika ei aiheuta alueellista käyttökatkosta.

Haaste: Kohtaamme usein tilanteita, joissa tietyt pyynnöt kuluttavat suhteettoman paljon resursseja PostgreSQL-instansseissa. Tämä voi heikentää muiden samoilla instansseilla suoritettavien työkuormien suorituskykyä. Esimerkiksi uuden ominaisuuden julkaisu voi tuoda mukanaan tehottomia kyselyitä, jotka kuluttavat runsaasti PostgreSQL CPU:n tehoa ja hidastavat muiden kriittisten ominaisuuksien pyyntöjä.

Ratkaisu: Käytämme lähes 50 lukureplikaa eri maantieteellisillä alueilla viiveen vähentämiseksi. Nykyisessä arkkitehtuurissa pääpalvelimen on kuitenkin lähetettävä WAL jokaiselle replikalle. Vaikka se skaalautuu tällä hetkellä hyvin erittäin suurten instanssityyppien ja suuren verkkokaistanleveyden kanssa, emme voi jatkaa replikoiden lisäämistä loputtomiin ilman, että pääpalvelin lopulta ylikuormittuu. Tämän ongelman ratkaisemiseksi teemme yhteistyötä Azure PostgreSQL -tiimin kanssa kaskadireplikointiin⁠(avautuu uudessa ikkunassa) liittyen, jossa välireplikot välittävät WAL:n alavirran replikoille. Tämä lähestymistapa mahdollistaa skaalautumisen jopa yli sataan replikaan ilman, että pääpalvelin ylikuormittuu. Se lisää kuitenkin myös toiminnan monimutkaisuutta, erityisesti vikasietoisuuden hallinnan osalta. Ominaisuus on vielä testausvaiheessa; varmistamme, että se on vankka ja voi siirtyä turvallisesti varajärjestelmään ennen kuin otamme sen käyttöön tuotannossa.

Haaste: Äkillinen liikenteen kasvu tietyissä päätepisteissä, kalliiden kyselyiden lisääntyminen tai uudelleenyritysten myrsky voi nopeasti kuluttaa loppuun kriittiset resurssit, kuten CPU:n, I/O:n ja yhteydet, mikä aiheuttaa laajamittaista palvelun heikkenemistä.

Ratkaisu: Otimme käyttöön käyttörajoitukset useilla tasoilla – sovelluksessa, yhteyksien yhdistämisessä, välityspalvelimessa ja kyselyissä – jotta äkilliset liikennepiikit eivät kuormittaisi tietokantainstansseja liikaa ja aiheuttaisi ketjureaktioita. On myös tärkeää välttää liian lyhyitä uudelleenyritysvälejä, jotka voivat aiheuttaa uudelleenyritysmyrskyjä. Paransimme myös ORM-kerrosta tukemaan nopeusrajoitusta ja tarvittaessa estämään kokonaan tietyt kyselytiivisteet. Tämä kohdennettu kuormituksen keventämisen muoto mahdollistaa nopean palautumisen kalliiden kyselyjen äkillisistä piikeistä.

Haaste: Jopa pieni skeemamuutos, kuten saraketyypin muuttaminen, voi aiheuttaa koko taulun uudelleenkirjoituksen⁠(avautuu uudessa ikkunassa). Siksi teemme skeemamuutoksia varoen – rajoitamme ne kevyisiin toimenpiteisiin ja vältämme muutoksia, jotka kirjoittavat kokonaisia taulukoita uudelleen.

Ratkaisu: Vain kevyet skeeman muutokset ovat sallittuja, kuten tiettyjen sarakkeiden lisääminen tai poistaminen, kunhan ne eivät aiheuta taulukon täydellistä uudelleenkirjoitusta. Sovellamme tiukkaa viiden sekunnin aikakatkaisua skeemamuutoksiin. Indeksien luominen ja poistaminen samanaikaisesti on sallittua. Skeemamuutokset on rajoitettu olemassa oleviin tauluihin. Jos uusi ominaisuus vaatii lisätaulukoita, niiden on oltava vaihtoehtoisissa pirstoutuneissa järjestelmissä, kuten Azure CosmosDB:ssä, eikä PostgreSQL:ssä. Kun täytämme taulukon kenttää jälkikäteen, asetamme tiukat käyttörajat kirjoitushuippujen estämiseksi. Vaikka tämä prosessi voi joskus kestää yli viikon, se takaa vakauden ja estää tuotantoon kohdistuvat vaikutukset.

Tämä hanke osoittaa, että oikealla suunnittelulla ja optimoinneilla Azure PostgreSQL voidaan skaalata käsittelemään suurimpiakin tuotantotyökuormia. PostgreSQL käsittelee miljoonia QPS-pyyntöjä lukupainotteisissa työkuormissa ja tukee OpenAI:n tärkeimpiä tuotteita, kuten ChatGPT:tä ja API-alustaa. Lisäsimme lähes 50 lukureplikaa pitäen samalla replikaatioviiveen lähes nollassa, ylläpidimme matalan viiveen lukuja maantieteellisesti hajautetuilla alueilla ja loimme riittävästi kapasiteettia tulevan kasvun tukemiseksi.

Tämä skaalaus toimii samalla, kun viive minimoidaan ja luotettavuus paranee. Tarjoamme jatkuvasti alle 10 millisekunnin p99-viiveen asiakaspuolella ja 99,999 %:n käytettävyyden tuotannossa. Ja viimeisten 12 kuukauden aikana meillä on ollut vain yksi SEV-0 PostgreSQL -häiriö (se tapahtui ChatGPT ImageGenin viraalijulkaisun⁠(avautuu uudessa ikkunassa) aikana, kun kirjoitusliikenne kasvoi äkillisesti yli 10-kertaiseksi, kun yli 100 miljoonaa uutta käyttäjää rekisteröityi viikon kuluessa.)

Vaikka olemme tyytyväisiä siihen, miten pitkälle PostgreSQL on vienyt meidät, jatkamme sen rajojen koettelemista varmistaaksemme, että meillä on riittävästi liikkumavaraa tulevaa kasvua varten. Olemme jo siirtäneet pirstottavat, kirjoituspainotteiset työkuormat pirstottuihin järjestelmiimme, kuten CosmosDB:hen. Jäljellä olevat kirjoituspainotteiset työkuormat ovat haastavampia jakaa osiin – olemme parhaillaan siirtämässä niitäkin, jotta voimme edelleen keventää kirjoituksia PostgreSQL-pääinstanssilta. Teemme myös yhteistyötä Azuren kanssa kaskadireplikointitoiminnon mahdollistamiseksi, jotta voimme turvallisesti laajentaa lukureplikoiden määrää merkittävästi.

Tulevaisuudessa jatkamme uusien lähestymistapojen tutkimista skaalaamisen laajentamiseksi, kuten pirstaloitu PostgreSQL tai vaihtoehtoiset hajautetut järjestelmät, kun infrastruktuurimme vaatimukset kasvavat.