Aukin afkastageta Git hjá OpenAI

Undanfarið ár hefur sameiginleg kóðageymsla okkar vaxið og kröfur til hennar aukist á ótrúlegum hraða. Ljóst var að við þyrftum að endurbæta útgáfustýringarkerfið okkar til að ráða við þá umfangsmiklu samhliða vinnu sem Codex gerir mögulega.

Við smíðuðum Pando, nýtt bakendakerfi fyrir Git-geymslur, án þess að trufla þróunarvinnu eða breyta því hvernig teymið okkar notar Git. Pando sér nú um alla þróun í sameiginlegri kóðageymslu OpenAI. Pando er hannað til að ná tveimur metnaðarfullum markmiðum: Í fyrsta lagi að auka skrifgetu með fleiri hnútum, með áherslu á samtímis sendingar á margar greinar. Í öðru lagi að hámarka lesafköst svo biðlarar geti sótt gögn nógu hratt til að fullnýta tiltæka netbandbreidd.

Við náðum þessum markmiðum án þess að fórna samhæfni við Git-samskiptaregluna og biðlarann. Þannig gátu bæði verkfræðingar okkar og fulltrúar tekið Pando átakalaust inn í núverandi vinnuferla. Í rekstri stytti Pando miðgildi sendingartíma niður í nær fimmtung. Það afhendir nú næstum eitt petabæti af Git-gögnum á dag.

Hér förum við yfir ástæður þess að við smíðuðum nýtt útgáfustýringarkerfi og hvers vegna við völdum að halda samhæfni við Git. Við berum kerfið okkar saman við algengar aðferðir til að auka getu Git og útskýrum hvers vegna Pando er einstaklega vel í stakk búið til að mæta vaxtarþörfum OpenAI. Við fjöllum einnig um næstu skref og hvernig við munum áfram leggja Git lið til að styðja við umfangsmikla vinnu fulltrúa.

Codex hefur breytt umfangi og hraða þróunar hjá OpenAI og gert verkfræðingum kleift að vinna að mun fleiri verkefnum samhliða. Það þýðir fleiri greinar og sendingar, fleiri sameiningar og meiri sókn og klónun frá þróunarumhverfum, rannsóknarverkum og samfelldri samþættingu (CI).

Þessar kröfur magna hver aðra. Einn verkfræðingur hefur nú nokkrar breytingar tilbúnar fyrir CI í einu og hver sending getur sett af stað mörg verk sem sækja sömu staðfestinguna.

Undir lok síðasta árs fóru kerfin sem studdu sameiginlegu kóðageymsluna okkar að eiga erfitt með að halda í við álagið. Sókn og sendingar voru hægar og sameiningar mistókust. Áreiðanleikinn fór stundum niður fyrir 90%. Höfðum við náð mörkum Git sjálfs eða þess hvernig við þjónuðum sameiginlegu kóðageymslunni okkar? Git spratt úr samfélagi sem skiptist á kjarnabótum í tölvupósti. Í meira en tvo áratugi hafa hugbúnaðarþróarar lagað verkfæri sín að Git eftir því sem vinnubrögð við hugbúnaðargerð hafa breyst. Þegar okkar eigin sameiginlega kóðageymsla fór að valda vandkvæðum skipti okkur máli að geta haldið áfram að byggja á þeirri vinnu.

Við sáum leið til að halda þessum kunnuglega vinnuferli en endursmíða bakendakerfið til að taka við sendingum á ólíkar greinar samhliða og afhenda mörgum lesendum sömu sögu samtímis. Með því að byggja útgáfustýringarferlið okkar á Git gátu umbætur á biðlaranum einnig gagnast utan OpenAI. Við vildum færa þær umbætur úr okkar eintaki af Git⁠(opnast í nýjum glugga) inn í aðalverkefnið og deila þeim þannig með samfélaginu öllu.

Aukin geta útgáfustýringarkerfis snýst um tvo meginþætti: marga skrifara sem senda á ólíkar greinar og marga lesendur sem sækja sömu sögu. Pando er fínstillt fyrir hvort tveggja.

Í fyrsta lagi samhæfir Pando uppfærslur hverrar greinar sjálfstætt. Uppfærslur á ótengdum greinum geta farið fram samhliða og lesandi sem sækir grein fær þá sögu sem þarf fyrir viðkomandi útgáfu. Á móti kemur að lesandi sem skoðar margar greinar getur séð stöðu þeirra á ólíkum tímapunktum.

Í öðru lagi endurnýtir Pando pakkaskrár (snið Git til að þjappa mörgum hlutum saman) milli sóttaraðgerða í stað þess að útbúa sérstaka pakkaskrá fyrir hvern biðlara. Biðlari gæti sótt suma hluti sem hann hefur þegar, en þjónninn getur afhent mörgum biðlurum sömu bætin með lítilli reiknivinnu.

Þessar ákvarðanir gera okkur kleift að auka skrifgetu yfir margar greinar og þjóna lestri úr skyndiminni. Til að sjá hvernig þetta vinnur saman skulum við byrja á því hvernig Git vistar og flytur sögu.

Git þarf að geta haldið tveimur hlutum geymslu samstilltum: hlutum og tilvísunum.

Git-geymsla skráir skyndimyndir af skrám og söguna sem tengir þær saman sem net hluta. Hlutur getur verið gagnablokk, tré, staðfesting eða merki. Gagnablokkir geyma innihald einstakra skráa og tré tengja nöfn við gagnablokkir eða önnur tré til að mynda möppuskipan. Staðfestingar vísa á rótartré og enga eða fleiri foreldra sína, sem eru eldri staðfestingar, og mynda þannig sögu geymslunnar.

Hlutar eru auðkenndir með hakkgildi af gerð þeirra og innihaldi. Hlutar eru einnig óbreytanlegir: þegar breytt skrá er skráð verður til ný gagnablokk, en óbreyttar skrár og möppur geta endurnýtt fyrirliggjandi hluti.

Greinar og merki eru tilvísanir, eða „refs“, sem vísa á staðfestingar. Þegar breytingar eru staðfestar á grein verður til ný staðfesting og tilvísun greinarinnar er uppfærð þannig að hún vísi á hana.

Git geymir hluti ýmist „lausa“ eða „pakkaða“. Lausir hlutir eru geymdir í stökum skrám sem eru auðkenndar með auðkenni hlutarins. Pakkaðir hlutir eru geymdir saman í pakkaskrá, svo hægt sé að geyma svipaða hluti sem mismun miðað við aðra hluti.

Í Git er hlutur aðgengilegur frá staðfestingu ef Git getur fundið hann með því að fylgja tenglum frá staðfestingunni í gegnum foreldra hennar, tré og gagnablokkir. Við sókn segir biðlarinn þjóninum hvaða staðfestingar hann vill fá og hvaða staðfestingar hann hefur þegar. Þjónninn finnur hlutina sem eru aðgengilegir frá umbeðnum staðfestingum, sleppir þeim sem hann veit að biðlarinn hefur þegar og sendir afganginn í pakkaskrá á sama sniði og Git notar á diski. Heildarklónun byrjar án nokkurra hluta og þarf því alla hluti sem eru aðgengilegir frá sögunni sem er verið að klóna.

Sending flytur hluti í hina áttina með því að biðja þjóninn að uppfæra eina eða fleiri tilvísanir. Biðlarinn notar tilvísanirnar sem þjónninn gefur upp til að forðast að senda hluti sem þjónninn hefur þegar. Pakkinn sem er sendur getur því verið háður fyrirliggjandi hlutum: það nægir ekki að taka aðeins við pakkanum til að endurskapa nýju söguna.

Afritun Git-geymslu felur í sér að halda bæði hlutum og tilvísunum tiltækum á mörgum þjónum. Áður en eftirmynd getur afhent nýtt gildi tilvísunar verður hún að geta útvegað þá hluti sem eru aðgengilegir frá því gildi. Þjónustan þarf einnig að samhæfa uppfærslur tilvísana sem rekast á, þ.e. sendingar sem reyna að færa sömu grein frá sama gamla endapunkti yfir á ólíkar nýjar staðfestingar. Kerfi sem setja öll skrif í geymslu í eina röð geta látið sendingar á ótengdar greinar bíða hver eftir annarri.

Við hönnun Pando mátum við hefðbundnar leiðir til að auka getu útgáfustýringar með Git: annars vegar að samhæfa uppfærslur tilvísana milli eftirmynda geymslunnar með þriggja þrepa staðfestingu (3PC, samskiptareglu til að samhæfa staðfestingu yfir marga hnúta), og hins vegar að raða uppfærslum með sameiginlegri forskráningardagbók (WAL, skrá yfir breytingar sem er skrifuð áður en þær eru framkvæmdar) í gagnablokkageymslu.

Í hönnuninni með þriggja þrepa staðfestingu sem við hermdum heldur Git-þjónustan fullkomnu afriti af geymslunni á nokkrum eftirmyndum. Þegar einhver þjónn tekur við sendingu er pakkaskráin afrituð og send til allra eftirmynda samhliða. Til að birta sendinguna verður meirihluti eftirmynda að samþykkja uppfærslu tilvísunarinnar. Þjónninn sem stýrir þessu er samhæfingaraðilinn og ferlið krefst margra umferða samskipta milli hans og hverrar annarrar eftirmyndar.

Til að samþykkja uppfærslu tilvísunar læsir hver eftirmynd sínu afriti af tilvísuninni og athugar hvort hún vísi enn á staðfestinguna sem biðlarinn gerir ráð fyrir. Samhæfingaraðilinn sendir síðan forstaðfestingarskilaboð til eftirmyndanna sem samþykkja. Þegar meirihluti hefur staðfest móttöku skilaboðanna segir samhæfingaraðilinn þeim að framkvæma uppfærsluna. Þá getur hvaða uppfærð eftirmynd sem er gefið upp nýjan endapunkt greinarinnar úr sínu staðbundna afriti af geymslunni.

Með því að halda úti heildstæðum eftirmyndum er hægt að þjóna lestri staðbundið og tryggja að biðlarar fái samræmda sýn á allar tilvísanir, óháð því hvaða eftirmynd þeir velja. Fyrir vikið eru tilvísanir uppfærðar ein í einu og hver sending krefst margra samskiptaumferða til að samhæfa uppfærsluna milli eftirmynda.

Þar sem bíða þarf eftir nægilegum fjölda eftirmynda ráðast sendingartímar meðal annars af diskafköstum þeirra og samskiptatöf. Eftir því sem skrifum fjölgar þurfa eftirmyndirnar að halda í við bæði innkomandi pakka og lesumferð.

Í hönnuninni sem við útfærðum með WAL notar Git-þjónustan sameiginlega skrá í gagnablokkageymslu til að raða uppfærslum í allri geymslunni. Þegar þjónn tekur við sendingu hleður hann pakkaskránni í gagnablokkageymslu og undirbýr uppfærslu tilvísunarinnar í sínu staðbundna afriti af geymslunni. Til að birta sendinguna bætir hann færslu við sameiginlega skrá í gagnablokkageymslunni. Færslan skráir uppfærslu tilvísunarinnar og vísar á pakkaskrána. Git-þjónninn uppfærir síðan skrána með samanburðar- og skiptiaðgerð. Aðgerðin skiptir skránni út í einu ódeilanlegu skrefi eða hafnar breytingunni. Ef annar skrifari hefur uppfært hana á meðan les þjónninn færslurnar sem hafa bæst við, athugar hvort uppfærsla hans á tilvísuninni sé enn gild og reynir aftur með pakkaskránni sem hann hefur þegar hlaðið upp.

Skrifarar geta hlaðið pakkaskrám upp samhliða, en jafnvel sendingar á ótengdar greinar krefjast uppfærslu á sömu skránni. Heildartími vel heppnaðrar samanburðar- og skiptiaðgerðar takmarkar hversu oft geymslan getur birt nýja skrá. Gagnablokkageymsla með litla bið gerir þetta skref hraðvirkt. Með lotuvinnslu getur ein skrá uppfært nokkrar tilvísanir í einu, en þá þarf að setja uppfærslur í biðröð og biðtíminn lengist.

Gagnablokkageymslan getur tekið við pakkaskrám samhliða, en uppfærslur á sameiginlegu skránni keppa enn hver við aðra. Aukin geta gagnablokkageymslunnar ein og sér leysir ekki þann flöskuháls. Hver eftirmynd þarf enn að lesa pakka úr gagnablokkageymslunni og skrá þá í atriðaskrár áður en hún getur afhent þá staðbundið. Ef innkomandi skrif eru hraðari en sú vinna dragast eftirmyndirnar aftur úr og biðlarar bíða lengur eftir að geta sótt nýsendar staðfestingar.

Þá komum við að Pando. Pando er ný kerfisgerð til að þjóna Git-geymslum, hönnuð til að ráða við marga biðlara sem senda breytingar samtímis. Svona virkar það:

Áður en við þróuðum Pando grunaði okkur að við gætum uppfyllt kröfur okkar án þess að gefa eftir varðandi Git. Við þurftum þó að slaka á sumu sem flest Git-kerfi líta á sem sjálfsagðar kröfur:

• Samræmi í allri geymslunni: Samræmd skyndimynd af öllum tilvísunum á tilteknum tímapunkti krefst samhæfingar yfir alla geymsluna. Í kerfi sem raðar öllum uppfærslum tilvísana í eina röð keppa sendingar á ótengdar greinar um einn samhæfingarpunkt.

• Sérstök pakkaskrá fyrir hvern biðlara: Ef tveir biðlarar með ólíka staðbundna sögu sækja sömu grein gæti þjónninn þurft að útbúa sérstakan pakka fyrir hvorn þeirra til að forðast að senda hluti sem þeir hafa þegar. Að útbúa þessi svör kostar örgjörvavinnu og lestur og skrif á disk, sem gerir erfitt að þjóna miklum fjölda lesenda.

Í staðinn notar Pando vægari samræmiskröfur (orsakasamræmi) til að auka skrifgetu og endurnýtir pakkaskrár til að auka lesgetu.

Þegar biðlari sendir breytingar á grein vistar Pando pakkaskrána sem berst sem óbreytanlega gagnablokk í gagnablokkageymslu. Í hvert sinn sem greinin færist skráir Pando útgáfu tilvísunar í lýsigagnageymslu. Hún inniheldur nýja endapunktinn, pakkann sem lagði hann til og allar eldri útgáfur tilvísana sem pakkinn er háður. Bæði gagnablokkageymslan og lýsigagnageymslan styðja lárétta skölun.

Til að sækja staðfestingu eða tilvísun úr Pando þarf að senda biðlaranum safn af útgáfum tilvísana (pakkaskrám) í réttri röð. Þannig er endurskapað ástand biðlarans sem bjó til útgáfu tilvísunarinnar sem verið er að sækja. Þetta veitir veikara samræmi í geymslunni í heild, en tryggir að uppfærslur einstakra tilvísana séu jafngildar raðbundinni keyrslu. Árekstrar milli biðlara verða aðeins þegar þeir senda breytingar á sömu tilvísun samtímis. Biðlari sem les nokkrar greinar getur ekki gengið út frá því að sá lestur lýsi einum tímapunkti í allri geymslunni.

Þetta er ein tegund orsakasamræmis. Til að sækja tilvísun sér lesandinn sögu þess skrifara sem bjó hana til. Við sendingu stýrir Pando því hvaða sameiginlegu sögu biðlari og þjónn koma sér saman um og tryggir þannig að biðlarar búi til pakkaskrár sem auðveldara er að deila.

Því veitir Pando hvorki stöðu allra tilvísana á einum tímapunkti við Git-aðgerðir né röðun uppfærslna á tilvísunum innan klónunar eða sóttaraðgerðar. Segjum til dæmis að greinarnar foo og bar séu báðar uppfærðar meðan samið er um heildarklónun. Meðan á samningaviðræðunum stendur gæti einn biðlari séð foo í útgáfu 1 og bar í útgáfu 2, en annar séð foo í útgáfu 2 og bar í útgáfu 1. Í reynd skiptir heildarröð uppfærslna á tilvísunum notendur og fulltrúa ekki máli; þeir reiða sig þess í stað á röð uppfærslna á einni tilvísun.

Í þessari hermun á samræmisaðferðunum þremur látum við 1.000 biðlara velja hver sína grein og senda síðan ítrekað einstakar staðfestingar. Við mælum heildartímann sem líður og biðina frá sendingu þar til hægt er að sækja breytingar. Síðarnefnda mælingin skiptir máli fyrir vinnsluálag, því hún mælir heildarbið í samskiptum notenda og fulltrúa við samstarf eða notkun annarra kerfa sem reiða sig á útgáfustýringu. Hermunin nær yfir búnað allt frá hefðbundnum til afkastamikilla sýndarvéla og gagnablokkageymslukerfa. Í þessari hermun höfum við slakað á samræmiskröfum fyrir geymsluna í heild í þriggja þrepa staðfestingu.

Kerfið með þriggja þrepa staðfestingu sýnir mun meiri skrifbið undir álagi þegar diskarnir ná fullri nýtingu. Kerfi með forskráningardagbók sýna hins vegar mun meiri lesbið af sömu ástæðu, þar sem þjónar ná ekki að lesa nógu hratt úr dagbókinni. Bæði í raunprófunum á sameiginlegri kóðageymslu okkar og í þessari hermun styður Pando mörg þúsund biðlara sem geta sent breytingar samtímis án þess að skerða afköst undir álagi.

Við móttöku sendingar sannprófar Pando pakkaskrána um leið og henni er streymt í gagnablokkageymslu, án þess að afpakka henni í staðbundna geymslu. Þegar biðlari byrjar að sækja velur Pando þá vistuðu pakka sem lesandinn þarf og lesandinn sækir þá. Enginn þjónn þarf að bæta pakkaskrám við staðbundna geymslu eða sinna kostnaðarsamri afpökkun og pökkun. Þar sem þessir þjónar sjá aðallega um samningaviðræður og val á pakkaskrám geta Pando-þjónar keyrt á hefðbundnum vélbúnaði.

Þannig getur Pando vaxið þar til takmörkum biðlaranna, netsins milli þeirra og Pando eða gagnablokkageymsluþjónustunnar er náð. Með nægri afkastagetu geta biðlarar sem vinna á óháðum greinum flutt pakka eins hratt og tenging hvers og eins leyfir. Til að þjóna fleiri biðlurum á þeim hraða getum við bætt við Pando-þjónum og aukið getu lýsigagna- og gagnablokkageymslunnar samhliða.

Fulltrúi breytir skrám, býr til staðfestingu staðbundið og keyrir git push. Það býr til pakkaskrá með breytingunum til að uppfæra grein. Pando tekur við pakkanum og streymir honum í gagnablokkageymslu. Eftir að hafa sannprófað sendinguna með einni umferð afkóðunar notar Pando færslu yfir marga lykla til að skrá útgáfu tilvísunar í lýsigagnageymsluna okkar og uppfæra bendil tilvísunarinnar í einni ódeilanlegri aðgerð. Þannig getur Pando tryggt samræmi þar sem biðlari sér alltaf eigin skrif við lestur. Öll skrifaðgerðin krefst $O(1)$ les- og skrifaðgerða á lýsigögnum.

Þegar annar biðlari sækir greinina velur Pando safn vistaðra pakka út frá sögunni sem biðlarinn hefur þegar. Þessi aðgerð krefst $O(\log \Delta)$ lesaðgerða á lýsigögnum, þar sem $\Delta$ er stysta fjarlægðin, talin í útgáfum tilvísana, milli þess sem biðlarinn hefur og þess sem hann vill fá. Þjónninn skilar URI-vísum á pakkaskrár og biðlarinn sækir þær í gegnum þjónustuna Express, sem geymir pakkaskrár í svæðisbundnu skyndiminni.

Þessi hönnun byggir á þremur meginþjónustum í kerfisgerð Pando: sendingum, sókn og þjöppun.

Þegar biðlari sendir breytingar er hefðbundinn Git-þjónn eins og pókerspilari sem sýnir öll spilin sín: hann birtir biðlaranum allar greinar sem hann hefur. Biðlarinn safnar þá staðfestingum, trjám og gagnablokkum til að búa til pakkaskrá sem sleppir hlutum sem hann veit að þjónninn hefur þegar.

Með því að gefa upp fleiri tilvísanir má minnka sendinguna. Það getur líka gert pakkann erfiðari í endurnýtingu, því annan biðlara gæti vantað hluti sem skrifarinn sleppti.

Pando fer aðra leið. Í stað þess að sýna öll spilin gefur það biðlaranum aðeins upp valið safn greina. Þetta er gert af tveimur ástæðum:

1. Það er kostnaðarsamt að veita samræmda sýn á allar tilvísanir. Þegar greinarnar telja milljónir geta upplýsingarnar um tilvísanir einar og sér farið yfir 100 MiB. Til að veita þær þarf hver þjónn annaðhvort að viðhalda uppfærðri vörpun, með umtalsverðri samhæfingarvinnu, eða keyra gagnagrunnsfyrirspurn sem vex í hlutfalli við fjölda tilvísana.

2. Ef biðlaranum er aðeins gefinn upp hluti tilvísananna býr hann til pakka sem er aðeins háður því sem þjónninn leyfir honum sérstaklega að sleppa. Með því að rekja þessi tengsl getur Pando endurnýtt pakkaskrá sem biðlari býr til í einni sendingu og afhent hana sem svar við síðari gagnasókn.

Því fleiri tilvísanir sem Git-þjónn gefur upp, þeim mun fleiri heimildir geta biðlarar notað til að útiloka hluti úr sendingum og búa þannig til minni pakka. Til að endurnýta þessar pakkaskrár þarf þjónninn þó að geta sannreynt að biðlararnir sem sækja þær hafi allt sem þær eru háðar. Annars gæti pakkaskráin sleppt hlutum sem biðlarinn þarf.

Ef Git-þjónn gefur hins vegar engar tilvísanir upp myndi biðlarinn búa til pakkaskrá með allri sögu geymslunnar. Hvaða annar biðlari sem er getur notað þá pakkaskrá, en það hefur þann mikla kostnað í för með sér að sókn hverrar greinar jafngildir í raun heildarklónun.

Þegar biðlari sendir nýja eiginleikagrein gefur Pando sjálfgefið aðeins upp eina tiltekna aðalgrein sem grunn. Þannig haldast upplýsingarnar jafn stórar þótt greinum í geymslunni fjölgi, en því fylgja málamiðlanir. Þegar verkfræðingur sendir oft á sömu grein eða byggir eina eiginleikagrein ofan á aðra þarf biðlarinn að endursenda allt sem er utan aðalgreinarinnar.

Þetta stækkar hverja sendingu á greinina, bætir mögulega við óþörfum hlutum og notar meiri bandbreidd biðlarans. Í sameiginlegri kóðageymslu okkar var miðgildi stærðar pakkaskráa sem urðu til á þennan hátt undir 20 KiB og 99. hundraðshlutamarkið undir 3 MiB. Fyrir okkur var þetta skynsamleg málamiðlun, því lesandi sem hefur þegar uppgefna sögu aðalgreinarinnar getur sótt greinina með þessari einu pakkaskrá.

Eftir að hafa valið hvaða tilvísanir biðlaranum eru gefnar upp tekur Pando við sendingunni og uppfærir lýsigagnageymsluna. Pando skiptir uppfærslu lýsigagna í samstilltan og ósamstilltan hluta. Samstillta uppfærslan tryggir að biðlarar geti strax sótt nýuppfærðu staðfestinguna. Hún skráir nýja útgáfu tilvísunar og uppfærir bendil tilvísunarinnar þannig að hann vísi á nýju útgáfuna. Jafnframt er nýi endapunkturinn vistaður, ásamt tengslunum sem notuð voru við samning um pakkaskrána og tengli á pakkaskrána sem var send.

Um leið er ósamstillt vinna, svo sem tímasetning þjöppunar, skráð í sömu færslu. Í mjög stórum sendingum er aðeins hluti staðfestinganna skrifaður samstillt. Þannig þurfum við aðeins fastan fjölda les- og skrifaðgerða á lýsigagnageymslunni, óháð stærð sendingarinnar.

Mikilvægt er að Pando-þjónar geta tekið sjálfstætt við sendingum á ótengdar tilvísanir. Eini lykillinn sem keppt er um er bendill tilvísunarinnar. Við vörðum hann með ódeilanlegri aðgerð sem líkist samanburði og skiptum. Við getum aukið skrifafköst með því að bæta við Pando-þjónum, einingum í lýsigagnageymslu eða gagnablokkageymslum.

Þegar biðlari sækir gögn sendir hann þjóninum tvö mengi auðkenna staðfestinga, sem nefnast have og want í samskiptareglunni. Hefðbundinn Git-þjónn reiknar mengjamismun hlutanna sem nást frá því sem biðlarinn hefur og þeirra sem nást frá því sem hann óskar eftir, þjappar þeim og sendir niðurstöðuna til biðlarans. Þótt opni Git-þjónninn hafi ýmsar staðbundnar atriðaskrár til að flýta fyrir þessari aðgerð getur verið kostnaðarsamt að reikna þessar pakkaskrár og yfirleitt er erfitt að nýta skyndiminni fyrir þær.

Pando notar þess í stað varpanir staðfestinga sem skráðar eru við sendingar til að fletta upp have og want hjá biðlaranum og finna safn útgáfa tilvísana sem innihalda þessar staðfestingar. Hver þessara útgáfa tilvísana tengist pakkaskrá sem Pando hefur áður tekið við. Þjónninn notar þetta til að finna hvað biðlarinn þarf og velur pakkaskrár sem ná yfir allt mengi þeirra hluta.

Git-samskiptareglan leyfir aðeins eina pakkaskrá í HTTP-svari við klónun eða sókn. Vanmetinn eiginleiki Git-samskiptareglunnar, packfile-uri, gerir þjóninum þó kleift að skila tenglum til að sækja fleiri pakka sérstaklega. Pando notar eingöngu þessa leið og sendir tóma pakkaskrá í sjálfu svarinu. Til að styðja þennan eiginleika lagði OpenAI nokkrar umbætur á packfile-uri til aðalverkefnisins.

Kerfi OpenAI starfa á mörgum landsvæðum, svo við rekum Pando-klasa með staðbundnu skyndiminni á hverju þeirra. Pakkaafhendingarþjónustan Express heldur skyndiminni fyrir gagnablokkageymsluna okkar og sérstök þjónusta heldur skyndiminni fyrir lýsigagnageymsluna. Þetta skyndiminni gerir Pando kleift að svara beiðnum um auðkenni staðfestingar eða sérstakan lestur tilvísunar eingöngu út frá skyndiminninu í viðkomandi klasa. Við notum samræmda hökkun til að beina beiðnum um pakkaskrár á Express-þjóna og yfir 99% beiðna hitta í skyndiminni.

Þetta skyndiminniskerfi skilar afar miklum afköstum og getur fullnýtt netgetuna milli biðlara og Pando. Með þessum URI-vísum á pakkaskrár og staðbundnu skyndiminni höfum við staðfest að klónun og sókn fullnýta 10 Gbps nettengingar með aðeins hefðbundnum sýndarvélum skýjaþjónustuaðila.

Flestir Git-þjónar þurfa endurpökkun og hreinsun ónotaðra gagna til að viðhalda afköstum þegar geymsla vex. Bæði skrefin losa pláss en krefjast mikillar reiknivinnu og inn-/úttaks.

Í geymslu sem breytist jafn hratt og sameiginleg kóðageymsla OpenAI er óraunhæft að senda sérstakan URI-vísi á pakkaskrá fyrir hverja sendingu frá síðustu sókn. Biðlari þyrfti að sækja tugi þúsunda pakkaskráa daglega til að uppfæra aðalgreinina sína.

Pando sameinar þess í stað pakka í bakgrunni til að draga úr þessari aukavinnu, með hönnun sem líkist þjöppun í dagbókarskipuðum samrunatrjám. Hver sending býr til pakkaskrá sem Pando nefnir „L0“ og er minnsta gagnaeiningin sem Pando getur flutt. Með tímanum safna bakgrunnsferli þessum pakkaskrám í þekjur sem ná yfir röð útgáfa tilvísana og stækka í rúmfræðilegri röð frá L0. Í dag notar sameiginlega kóðageymslan okkar pakkaskrárþekjur allt að L4.

Þessar þekjur þjóna tvíþættum tilgangi. Þegar þekja er orðin nægilega full tekur þjöppunarferli hana að sér og býr til eina pakkaskrá. Þetta bætir þjöppunarhlutfallið með því að endurraða hlutunum inni í pakkaskránni. En það flýtir líka fyrir samningaviðræðum við sókn með því að virka sem stökklisti yfir útgáfur tilvísana. Með því að fara samtímis yfir atriðaskrár á hverju stigi getur Pando valið pakka til að senda biðlara á lógaritmískum tíma. Þessar pakkaskrárþekjur, hvort sem þær hafa verið endurpakkaðar eða ekki, gera skipulagningu sóknar skilvirkari og draga bæði úr kröfum um afköst og biðtíma í Pando.

Ólíkt því sem tíðkast á mörgum Git-þjónum eru pakkaskrár varðveittar á öllum stigum en ekki hent eða fjarlægðar við hreinsun. Pakkar á öllum stigum eru stöðugt notaðir til að þjóna biðlurum út frá have og want sem þeir tilgreina við sókn. Þegar biðlarar nota Pando sem API þarf auk þess yfirleitt að lesa minna gagnamagn úr L0 en L4 til að lesa tiltekinn hlut úr pakkaskrá, því minni líkur eru á að hann sé þjappaður.

Þjöppun í Pando minnkar heildargagnamagnið sem sent er til biðlara verulega og tryggir að vinna við pakkaskipulagningu vex hægar en línulega með því hversu langt biðlarinn er á eftir. Þetta er sérstaklega mikilvægt fyrir stórar geymslur sem breytast hratt, en við teljum að slíkar geymslur verði algengar í hugbúnaðarþróun.

Við smíðuðum Pando með Codex og fórum frá upphafi verkefnis til rekstrar á aðeins 10 vikum. Einn verkfræðingur hannaði kjarna Pando, teymi fulltrúa útfærðu hann og örfáir verkfræðingar tóku hann í notkun. Pando byrjaði að þjóna raunálagi í apríl á þessu ári og er einn hluti stærra safns útgáfustýringartóla sem notuð eru hjá OpenAI.

Við beittum fjölbreyttum aðferðum til að sannreyna hönnun Pando. Við beittum meginreglum okkar um að byggja öruggari undirstöður hugbúnaðar⁠. Þar sem verkefnið hófst frá grunni ákváðum við að útfæra Pando í Rust og án eldri hugbúnaðartenginga. Við skrifuðum samræmisprófasafn svo fulltrúar gætu prófað breytingar sínar gagnvart hefðbundinni hegðun Git. Við þróuðum einnig kerfi fyrir ákvarðanlega hermiprófun til að kanna óbreytur og eiginleika kerfisins. Þannig gátum við fundið og dregið úr lúmskum kapphlaupsvillum og afturför í samningaviðræðum og pakkaskipulagningu.

Mörg líkön lögðu sitt af mörkum til kerfisins. Þegar ný líkön urðu aðgengileg notuðum við þau til að bæta afköst og áreiðanleika Pando. Með GPT‑6 Astra skrifuðu fulltrúar Lean og TLA+ til að setja fram formlega „kenningu um Pando“. Við notuðum hana til að finna og laga villur í útfærslunni og sanna eiginleika kerfisins. Margar lotur keyrðu samfellt í hundruð klukkustunda við að finna og laga jaðartilvik í Pando. Við látum líka fulltrúa keyra allan sólarhringinn til að öryggisprófa Git og Pando með árásum, með líkönum sem hafa Daybreak-getu.

Við tókum Pando fyrst í notkun sem milliþjón sem áframsendi lestur og skrif í núverandi útgáfustýringarkerfi okkar. Þannig gátum við haldið Pando og eldra kerfinu samstilltum og flutt umferð örugglega yfir á Pando án rekstrarstöðvunar.

Skyndiminnishönnun Pando gerir því einnig kleift að fjarlægja tvíteknar beiðnir og sameina beiðnir áður en þær eru áframsendar. Þetta hélt núverandi verkfærum okkar í góðu lagi á meðan við fluttum kerfin eitt af öðru yfir á Pando. Eftir því sem við færðum meira vinnsluálag yfir á Pando fylltu sendingarnar skyndiminni þess og bættu áreiðanleika fyrra bakendakerfisins.

Til að hámarka afköst við notkun Pando fórum við að dreifa opinberri útgáfu okkar af Git á vélar þróara og með ChatGPT‑skjáborðsforritinu. Við notuðum innri umgjörð utan um skipanalínuviðmót Git til að færa biðlara yfir á Pando í áföngum. Við bjuggum til mörg önnur verkfæri fyrir breytingabeiðnir og kóðarýni, auk API-viðmóta fyrir sjálfvirkni. Samhliða Git-umferðinni fluttum við hundruð samþættinga sem byggðu á eldri API-viðmótum, vefkrókum og niðurhali geymslna.

Codex sjálft hjálpaði þróurum og teymum að skipta um kerfi. Við bjuggum til færnieiningar til að undirbúa fyrirliggjandi vinnueintök og leiðbeina fulltrúum við notkun nýja kerfisins. Þar með gátu þróarar einfaldlega beðið Codex um að flytja þróunarumhverfi sín og þjónustur.

Skiptin yfir í Pando bættu áreiðanleika sameininga og lækkuðu miðgildi sendingartíma um nær 80%.

Pando getur afhent eitt petabæti af Git-gögnum á dag með aðeins örfáum örgjörvakjörnum. Pando hefur afhent meira en 57 terabæti af Git-pökkum á einni klukkustund og yfir 99% þeirra bæta komu úr staðbundnu diskskyndiminni.

Með endurnýtingu pakka geta margir biðlarar sótt sömu sögu geymslunnar með lítilli reiknivinnu á hnútunum sem afhenda gögnin. Þetta dæmi sýnir eina geymslu, en Pando er hannað til að styðja margar fleiri. Þegar eftirspurn vex getum við aukið getu gagnaafhendingar og Git-samningaviðræðna óháð hvoru öðru.

Með því að byggja Pando á Git-samskiptareglunni og biðlaranum fundum við villur og tækifæri til að bæta afköst Git sjálfs.

Pando afhendir til dæmis endurnýtanlega pakka beint til biðlara. Niðurhal þeirra og skráning í atriðaskrár varð því lykilþáttur í að gera kerfið hraðvirkt og áreiðanlegt. Sú vinna leiddi í ljós jaðartilvik við samhliða niðurhal, tiltekt eftir rofna flutninga og endurupptöku niðurhals sem hafði þegar lokið. Við löguðum þessa verkferla, bættum við sannprófun þegar fyrirliggjandi pakki er samþykktur fyrir sókn og lögðum þá vinnu til aðalverkefnisins.

Við þurftum líka að sjá í hvað tími og bandbreidd fóru. Því bættum við rakningu við packfile-uri-niðurhal og bætatalningu við pakkagerð, svo auðveldara væri að sjá hvort hæg sókn eyddi tímanum í að búa til pakka eða flytja þá.

Í Git-útgáfu OpenAI⁠(opnast í nýjum glugga) getur biðlarinn sótt óháða pakka og skráð þá í atriðaskrár samhliða. Við bættum við hugtakinu „sérstaklega tilgreind fyrirliggjandi gögn“, svo þjónn geti gefið upp núverandi endapunkt greinar óháð þeirri sögu sem sendandi biðlari má sleppa úr pakkanum sínum. Í Pando gerir þetta biðlurum kleift að nota --force-with-lease til að athuga hvort eiginleikagrein hafi færst og búa til pakkann með aðalgreinina eina sem grunn. Hver sem hefur þá sögu aðalgreinarinnar getur síðan sótt greinina með sama pakka.

Nokkrar þessara umbóta eru þegar komnar í aðalútgáfu Git og margar aðrar í opinberu geymsluna okkar. Við vinnum áfram með Git-samfélaginu að því að láta þessar umbætur gagnast víðar en í Pando. Þú getur fylgst með þeirri vinnu í opinberu yfirliti okkar yfir kóðabætur⁠(opnast í nýjum glugga).

Með því að endurhugsa viðteknar hugmyndir um hvernig auka megi getu Git-geymslna gerir Pando okkur kleift að stækka sameiginlega kóðageymslu okkar án þess að breyta Git-vinnuferlunum sem verkfræðingar okkar og fulltrúar nota nú þegar. Í sameiginlegri kóðageymslu okkar hefur Pando gert meiri samhliða vinnslu mögulega, aukið áreiðanleika sameininga og stytt tímann sem tekur að birta kóðabreytingar. Við erum einnig að kanna aðra notkun Pando innan OpenAI, þar á meðal verkefni þar sem mikill fjöldi fulltrúa þarf að vinna saman í sameiginlegri Git-geymslu.

Eftir því sem verkfræðingar og fulltrúar búa til meiri hugbúnað munu fleiri teymi utan OpenAI rekast á sömu takmarkanir útgáfustýringar og við. Við erum nú að kanna leiðir til að deila tækninni að baki Pando með notendum okkar.

Pando byggir á tveggja áratuga reynslu notenda og rekstraraðila Git-geymslna. Við munum halda áfram að þróa Pando og vinna með opna Git-samfélaginu að því að deila öllum umbótum sem geta gagnast Git-notendum almennt.