Að stækka PostgreSQL til að þjóna 800 milljónum ChatGPT‑notenda

Í mörg ár hefur PostgreSQL verið eitt mikilvægasta gagnakerfið á bak við tjöldin sem knýr kjarnavörur eins og ChatGPT og OpenAI API. Eftir því sem notendahópur okkar stækkar hratt, hafa kröfurnar á gagnagrunnana okkar einnig aukist verulega. Á síðasta ári hefur álag á PostgreSQL okkar vaxið meira en tífalt, og það heldur áfram að aukast hratt.

Viðleitni okkar til að efla framleiðsluinnviði okkar til að halda uppi þessum vexti leiddi í ljós nýja innsýn: Hægt er að stækka PostgreSQL til að styðja áreiðanlega mun stærri lestrarþung vinnuálag en margir héldu áður mögulegt. Kerfið (sem var upphaflega þróað af teymi vísindamanna við University of California, Berkeley) hefur gert okkur kleift að styðja við gríðarlega alþjóðlega umferð með einni aðal Azure PostgreSQL sveigjanlegri netþjónseiningu⁠(opnast í nýjum glugga) og nærri 50 leseftirmyndum sem dreifast yfir mörg svæði um allan heim. Þetta er sagan um hvernig við höfum stækkað PostgreSQL hjá OpenAI til að styðja við milljónir fyrirspurna á sekúndu fyrir 800 milljónir notenda með ítarlegum fínstillingum og traustri verkfræði; við munum einnig fjalla um helstu lærdóma sem við höfum dregið af þessu á leiðinni.

Eftir að ChatGPT var sett á laggirnar jókst umferðin á fordæmalausan hraða. Til að styðja við það innleiddum við hratt umfangsmiklar hagræðingar bæði á forrits- og PostgreSQL-gagnagrunnslögum, sköluðum upp með því að auka stærð tilviksins og sköluðum út með því að bæta við fleiri leseftirmyndum. Þessi högun hefur þjónað okkur vel í langan tíma. Með stöðugum umbótum heldur hún áfram að veita nægilegt svigrúm fyrir framtíðarvöxt.

Það kann að hljóma ótrúlega að ein aðalhögun geti mætt kröfum umfangs OpenAI; hins vegar er ekki einfalt að láta þetta virka í reynd. Við höfum séð nokkur SEV-tilvik af völdum ofálags á Postgres, og þau fylgja oft sama mynstri: vandamál ofar í keðjunni veldur skyndilegri aukningu á álagi á gagnagrunninn, svo sem víðtækum skyndiminnisskorti vegna bilunar í skyndiminnislagi, aukningu á dýrum margþátta samsetningum sem metta CPU, eða skrifstormi við útgáfu nýs eiginleika. Þegar nýting tilfanga eykst, eykst biðtími fyrir fyrirspurnir og beiðnir byrja að renna út á tíma. Endurtekningar auka síðan álagið enn frekar og koma af stað vítahring sem getur leitt til þess að öll ChatGPT- og API-þjónusta versni.

Þó að PostgreSQL skalist vel fyrir lestrarþungt vinnuálag okkar, þá stöndum við samt frammi fyrir áskorunum á tímabilum mikillar skrifumferðar. Þetta er að mestu leyti vegna útfærslu PostgreSQL á fjölútgáfu samhliða stjórnun (MVCC), sem gerir það minna skilvirkt fyrir vinnuálag með miklum skrifum. Til dæmis, þegar fyrirspurn uppfærir reit eða jafnvel eitt svið, er öll línan afrituð til að búa til nýja útgáfu. Við miklu skrifálagi leiðir þetta til verulegrar skrifmögnunar. Það eykur einnig lesmögnun, þar sem fyrirspurnir þurfa að skanna í gegnum margar útgáfur af færslum (dauðar færslur) til að ná í þá nýjustu. MVCC kynnir viðbótaráskoranir eins og uppblástur á töflum og atriðaskrám, aukið viðhaldsyfirálag á atriðaskrám og flókna fínstillingu á autovacuum. (Þú getur fundið ítarlega umfjöllun um þessi atriði í bloggfærslu sem ég skrifaði með Andy Pavlo prófessor við Carnegie Mellon University sem heitir The Part of PostgreSQL We Hate the Most⁠(opnast í nýjum glugga), sem er vitnað til⁠(opnast í nýjum glugga) á Wikipedia-síðu PostgreSQL.)

Til að draga úr þessum takmörkunum og minnka skrifþrýsting höfum við fært, og höldum áfram að færa, sundurliðanlegt (þ.e. vinnuálag sem hægt er að skipta lárétt, skrifþungt vinnuálag í sundurhlutuð kerfi eins og Azure Cosmos DB, fínstilltu forritsfræðina til að lágmarka óþarfa skrif. Við leyfum ekki lengur að bæta nýjum töflum við núverandi PostgreSQL-innleiðingu. Ný vinnuálög eru sjálfgefin á skipt kerfi.

Jafnvel þótt innviðir okkar hafi þróast hefur PostgreSQL haldist óskipt, með einu aðaltilviki sem þjónar öllum skrifum. Meginrökin eru þau að það væri afar flókið og tímafrekt að skipta núverandi vinnuálagi forrita niður í brot, sem myndi krefjast breytinga á hundruðum endapunkta forrita og gæti tekið marga mánuði eða jafnvel mörg ár. Þar sem vinnuálag okkar er aðallega lesmikið og við höfum innleitt umfangsmiklar hagræðingar, veitir núverandi uppbygging samt nægilegt svigrúm til að styðja við áframhaldandi vöxt umferðar. Þó við útilokum ekki að skipta PostgreSQL í brot í framtíðinni, er það ekki forgangsverkefni á næstunni þar sem við höfum nægilegt svigrúm fyrir núverandi og framtíðarvöxt.

Í næstu hlutum munum við kafa djúpt í þær áskoranir sem við stóðum frammi fyrir og þær umfangsmiklu hagræðingar sem við innleiddum til að takast á við þær og koma í veg fyrir framtíðarbilanir, ýta PostgreSQL út á þolmörk sín og stækka það í milljónir fyrirspurna á sekúndu (QPS).

Áskorun: Með aðeins einum rithöfundi getur uppsetning með einum aðalhöfundi ekki aukið skrifgetu. Miklir skriftoppar geta fljótt ofhlaðið aðalþjóninn og haft áhrif á þjónustur eins og ChatGPT og API okkar.

Lausn: Við lágmörkum álag á aðalhnútinn eins og kostur er—bæði lestur og skrif—til að tryggja að hann hafi næga afkastagetu til að takast á við skyndilegar skrifaukningar. Lesumferð er færð yfir á eftirmyndir þegar mögulegt er. Hins vegar verða sumar lesfyrirspurnir að vera áfram á aðalþjóninum þar sem þær eru hluti af skriffærslum. Fyrir þau leggjum við áherslu á að tryggja að þau séu skilvirk og komast hjá hægum fyrirspurnum. Fyrir skrifumferð höfum við flutt skrifþungt vinnuálag sem hægt er að brjóta yfir í brotin kerfi eins og Azure CosmosDB. Vinnsluálag sem er erfiðara að skipta upp en samt skilar miklu magni af skrifum tekur lengri tíma að flytja, og það ferli er enn í gangi. Við höfum einnig fínstillt forritin okkar af mikilli nákvæmni til að draga úr skrifálagi; til dæmis höfum við lagað villur í forritum sem ollu óþarfa skrifum og kynnt til sögunnar löt skrif, þar sem við á, til að jafna út umferðartoppa. Að auki, þegar við fyllum út töflureiti, framfylgjum við ströngum hraðatakmörkunum til að koma í veg fyrir óhóflegt ritálag.

Áskorun: Við fundum nokkrar dýrar fyrirspurnir í PostgreSQL. Áður fyrr hefðu skyndilegar aukningar í þessum fyrirspurnum tekið mikið magn af örgjörva, sem hægði á bæði ChatGPT og API beiðnum.

Lausn: Nokkrar dýrar fyrirspurnir, eins og þær sem sameina margar töflur, geta verulega dregið úr afköstum eða jafnvel stöðvað alla þjónustuna. Við þurfum að fínstilla PostgreSQL-fyrirspurnir stöðugt til að tryggja að þær séu skilvirkar og forðast algeng andmynstur í Online Transaction Processing (OLTP). Til dæmis fundum við einu sinni mjög kostnaðarsama fyrirspurn sem tengdi saman 12 töflur, þar sem toppar í þessari fyrirspurn voru ábyrgir fyrir fyrri alvarlegum SEV-atvikum. Við ættum að forðast flóknar margtöflusamsetningar þegar mögulegt er. Ef tengingar eru nauðsynlegar, lærðum við að íhuga að brjóta niður fyrirspurnina og færa flókna tengingarökfræði yfir í forritalagið í staðinn. Margar af þessum vandamálafyrirspurnum eru búnar til af Object-Relational Mapping-rammaverkum (ORM), svo það er mikilvægt að yfirfara vandlega SQL sem þau búa til og tryggja að það virki eins og búist er við. Það er einnig algengt að finna langvarandi aðgerðalausar fyrirspurnir í PostgreSQL. Að stilla tímalokanir eins og idle_in_transaction_session_timeout er nauðsynlegt til að koma í veg fyrir að þær hindri autovacuum.

Áskorun: Ef leseftirmynd fellur niður, er enn hægt að beina umferð til annarra eftirmynda. Hins vegar, að treysta á einn skrifara þýðir að hafa einn bilunarpunkt—ef hann bilar, hefur það áhrif á alla þjónustuna.

Lausn: Flestar mikilvægustu beiðnirnar fela aðeins í sér lesfyrirspurnir. Til að draga úr hættu á einum bilunarpunkti í aðalþjóninum, færðum við lesbeiðnirnar frá skrifaranum yfir á eftirmyndir, sem tryggir að hægt sé að halda áfram að afgreiða þær jafnvel þótt aðalþjónninn falli út. Þótt skrifaðgerðir myndu enn mistakast, eru áhrifin minni; þetta er ekki lengur SEV0 þar sem lestur er enn í boði.

Til að draga úr bilunum í aðalkerfinu keyrum við aðalkerfið í High-Availability (HA) stillingum með heitum biðþjóni, stöðugt samstilltri eftirmynd sem er alltaf tilbúið að taka við umferð. Ef aðalkerfið fer niður eða þarf að taka það úr notkun vegna viðhalds, getum við fljótt fært varakerfið í aðalhlutverk til að lágmarka niðurtíma. Azure PostgreSQL-teymið hefur unnið mikið starf til að tryggja að þessar bilunarviðgerðir haldist öruggar og áreiðanlegar jafnvel undir mjög miklu álagi. Til að bregðast við bilunum í leseftirmyndum setjum við upp margar eftirmyndir í hverju svæði með nægilegu afkastarými, sem tryggir að bilun í einni eftirmynd valdi ekki bilun á öllu svæðinu.

Áskorun: Við lendum oft í aðstæðum þar sem ákveðnar beiðnir nota óhóflega mikið af auðlindum á PostgreSQL-tilvikum. Þetta getur valdið skertri frammistöðu fyrir önnur vinnuálög sem keyra á sömu tilvikum. Til dæmis getur innleiðing nýrrar eiginleika valdið óhagkvæmum fyrirspurnum sem nota PostgreSQL CPU mikið og hægja á beiðnum fyrir aðra mikilvæga eiginleika.

Lausn: Við rekum um það bil 50 leseftirmyndir á mörgum landfræðilegum svæðum til að lágmarka biðtíma. Hins vegar, með núverandi högun, verður aðalhnúturinn að streyma WAL til allra eftirmynda. Þótt það nú skali vel með mjög stórum tilvikagerðum og mikilli netbandbreidd, getum við ekki haldið áfram að bæta við eftirmyndum endalaust án þess að aðalhnúturinn verði að lokum ofhlaðinn. Til að bregðast við þessu erum við að vinna með Azure PostgreSQL-teyminu að stigvaxandi eftirmyndun⁠(opnast í nýjum glugga), þar sem bráðaeftirmyndir miðla WAL til afrita neðar í keðjunni. Þessi nálgun gerir okkur kleift að stækka í hugsanlega yfir hundrað eftirmyndir án þess að yfirhlaða aðalhnútinn. Hins vegar bætir það einnig við rekstrarflækjustig, sérstaklega í tengslum við stjórnun á bilunarviðbrögðum. Eiginleikinn er enn í prófun; við munum tryggja að hann sé traustur og geti skipt örugglega yfir áður en við setjum hann í framleiðslu.

Áskorun: Skyndileg aukning á umferð á tilteknum endapunktum, aukning á kostnaðarsömum fyrirspurnum eða endurtekningarstormur getur fljótt tæmt mikilvægar auðlindir eins og CPU, I/O og tengingar, sem veldur víðtækri þjónusturýrnun.

Lausn: Við innleiddum hraðatakmarkanir á mörgum lögum—í forriti, tengingasafnara, proxy og fyrirspurnum—til að koma í veg fyrir að skyndilegir umferðartoppar yfirgnæfðu gagnagrunnstilvik og kveiktu keðjuverkandi bilanir. Það er einnig mikilvægt að forðast of stutt endurprófunarbil sem geta valdið endurprófunarstormum. Við bættum einnig ORM-lagið til að styðja við hraðatakmarkanir og, þegar þörf krefur, loka algjörlega á tiltekna fyrirspurnarvinnslu. Þessi markvissa tegund álagsstýringar gerir kleift að ná skjótum bata eftir skyndilegum aukningum á kostnaðarsömum fyrirspurnum.

Áskorun: Jafnvel smávægileg skemabreyting, eins og að breyta dálkategund, getur kallað á heildarendurskráningu töflu⁠(opnast í nýjum glugga). Þess vegna beitum við skemabreytingum af varfærni—takmörkum þær við léttar aðgerðir og forðumst þær sem endurskrifa heilar töflur.

Lausn: Aðeins léttar skemabreytingar eru leyfðar, eins og að bæta við eða fjarlægja dálka sem ekki krefjast fullrar endurskrifunar á töflunni. Við framfylgjum ströngu 5 sekúndna tímamarki á breytingum á skema. Það er leyfilegt að búa til og eyða atriðaskrám samhliða. Breytingar á skema eru takmarkaðar við núverandi töflur. Ef nýr eiginleiki krefst viðbótartaflna, verða þær að vera í öðrum skiptikerfum, svo sem Azure CosmosDB, frekar en PostgreSQL. Þegar fyllt er aftur í töflureit, beitum við ströngum hraðatakmörkunum til að koma í veg fyrir skyndilegar aukningar í skrifum. Þótt þetta ferli geti stundum tekið meira en viku, tryggir það stöðugleika og kemur í veg fyrir áhrif á framleiðslu.

Þessi viðleitni sýnir að með réttri hönnun og hagræðingu er hægt að skala Azure PostgreSQL til að takast á við stærstu framleiðsluvinnuálögin. PostgreSQL ræður við milljónir QPS fyrir lesþung vinnuálag og knýr mikilvægustu vörur OpenAI, eins og ChatGPT og API-verkvanginn. Við bættum við tæplega 50 leseftirmyndum, héldum eftirmyndunartöf nánast í núlli, viðhéldum lestri með lítilli töf yfir landfræðilega dreifð svæði og byggðum upp nægilegt svigrúm í afkastagetu til að styðja við framtíðarvöxt.

Þessi skölun virkar á meðan hún lágmarkar biðtíma og bætir áreiðanleika. Við bjóðum stöðugt upp á lága tveggja stafa millisekúndna p99 seinkun á biðlarahliðinni og fimm-níu tiltækileika í framleiðslu. Og á síðustu 12 mánuðum höfum við aðeins lent í einu SEV-0 PostgreSQL-atviki (það átti sér stað við vinsæla kynningu⁠(opnast í nýjum glugga) á ChatGPT ImageGen, þegar skrifumferðin jókst skyndilega um meira en 10x þar sem yfir 100 milljónir nýrra notenda skráðu sig innan viku.)

Þó að við séum ánægð með hversu langt PostgreSQL hefur komið okkur, höldum við áfram að ýta á mörk þess til að tryggja að við höfum nægilegt svigrúm fyrir framtíðarvöxt. Við höfum þegar flutt skrifþungt vinnuálag sem hægt er að skala yfir í skipt kerfi okkar eins og CosmosDB. Eftirstandandi skrifþung vinnuálög eru erfiðari að skipta upp í skörf—við erum að flytja þau virkan til að létta enn frekar á skrifum af PostgreSQL aðalþjóninum. Við erum einnig að vinna með Azure til að virkja stigvaxandi afritun svo við getum örugglega stækkað í mun fleiri lesafrit.

Horft fram á veginn munum við halda áfram að kanna fleiri leiðir til að stækka enn frekar, þar á meðal skipt PostgreSQL eða önnur dreifð kerfi, eftir því sem kröfur innviða okkar aukast.