Az OpenAI új háttérrendszert, Pando-t mutatta be, amely a meglévő Git-protokollt és Git-ügyfelet megtartva a monorepo írási és olvasási skálázhatósági problémáit célozza meg. A rendszert arra tervezték, hogy egyszerre nagyszámú, független branche-re érkező pushokat, illetve sok párhuzamos fetchet és clone-ot szolgáljon ki hatékonyan. A fejlesztés fő indítéka az volt, hogy a Codex és más ügynökök (agents) munkafolyamatai miatt jelentősen megnőtt a párhuzamos fejlesztések száma és igénye.
Miért kellett új megoldás?
Az elmúlt évben az OpenAI monorepo-jának mérete és az egyidejű terhelés olyan gyorsan növekedett, hogy a meglévő forráskezelő-rendszerek időnként 90% alá eső megbízhatósággal és lassú fetch/push válaszidőkkel küzdöttek. A csapat azt szerette volna megőrizni, hogy a fejlesztők és ügynökeik ne változtassanak a megszokott Git-alapú munkafolyamatokon, miközben a háttérrendszer képes legyen párhuzamosan fogadni pushokat különböző branchekre és gyorsan kiszolgálni olvasókat.
Pando alapelvei és működése
Pando két kulcsfontosságú célt tűzött ki: (1) vízszintesen skálázható írások, azaz sok párhuzamos push kezelése különböző refekre; (2) nagy read-throughput, hogy a kliensek ki tudják használni a rendelkezésre álló hálózati sávszélességüket. Mindkettőt úgy érte el, hogy megtartotta a Git protokoll és kliens kompatibilitást.
A hagyományos Git-szolgáltatásokkal szemben Pando két fontos kompromisszumot alkalmaz:
- Repository-szintű szigorú, pillanatnyi konzisztencia helyett laza, kauzális konzisztenciát kínál: az egyes refekre vonatkozó frissítések sorosíthatók, de a teljes tároló összes refjének egyetlen, globális pillanatképe nem garantált minden olvasó számára ugyanabban az időpontban. Így független branchekre érkező pushok nem akadályozzák egymást.
- Ahelyett, hogy egyedi packfile-okat generálna minden kliens számára, Pando újrahasznosítja a beérkezett packfile-okat: a szerver tárolja a push során kapott packfile-okat immutable blobként, és ugyanazt a bájtsort szolgálhatja ki sok kliensnek alacsony számítási költséggel.
Technikailag Pando push esetén a beérkező packfile-t áramoltatva feltölti egy blob store-ba és egy metaadat-tárban (Turtle) ref verziókat rögzít, amelyek összekapcsolják a ref új tipjét a hozzá tartozó packfile-lel és függőségeivel. A fetch során a szerver a kliens have/want információját ref verziókra fordítja le, és a szükséges ismert packfile URI-kat adja vissza; maga a packletlet (Express) a régiós cache-ekből adja a csomagokat.
Összehasonlítás más skálázási megközelítésekkel
A cikkben két hagyományos megoldást modelleztek: (1) háromfázisú commit alapú replikáció, ahol a teljes repository-t több replika tartja és a ref frissítéseket kvórum koordinálja; (2) write-ahead log (WAL) jellegű megoldás, ahol egy közös manifest rendezi az update-eket blob storage-ban. Mindkét megközelítésnek vannak korlátai: a 3PC-alapú megoldásnál a ref frissítések sorosítása és a replikák kvórumra várása írható késleltetést okoz; a WAL-alapú tervezésnél a megosztott manifest okozhat versengést és a replikák lemaradása olvasási késlekedéshez vezet.
A szimulációk és valós tesztek szerint Pando képes sok ezer párhuzamos író támogatására anélkül, hogy a teljesítmény terhelés alatt drámaian romlana.
Csomagkezelés, hirdetés és compaction
A Git-protokoll tárgyalja, hogy a szerver mely refeket „hirdeti” a kliens felé a push tárgyaláskor. Pando minimalizálja a hirdetett refek számát — alapértelmezésben csak egy kijelölt trunk-ot hirdet —, így a kliens által létrehozott packfile függése kiszámítható, és a szerver újra tudja használni azt későbbi fetchek kiszolgálására. Ennek ára, hogy egymásra épülő branch-sorozatoknál a kliens nagyobb packfile-t tud előállítani és ismétlődő objektumokat küldhet.
A Pando esetében a median push során előálló packfile méret a monorepo-n belül 20 KiB alatt van, és a 99. percentilis kevesebb mint 3 MiB. Ez a kompromisszum a szerveroldali újrahasznosítást és a későbbi gyors fetchet segíti.
Mivel napi szinten nagyon sok L0 (kis) pack jön létre, Pando háttérben compaction munkákat végez: az L0 packokat hierarchikus szinteken (például L1–L4) gyűjti össze és idővel repackeli, javítva a tömörítést és a fetch tervezés hatékonyságát. A rendszer megtart minden szinten lévő packot szolgálatra, így nem végzi el a hagyományos értelemben vett azonnali garbage collection-t.
Telepítés, validálás és teljesítmény
A Pando fejlesztését 10 hét alatt vitték el a kick-offtól a termelésbe; a szolgáltatás 2024 áprilisában kezdte kiszolgálni a production forgalmat (a cikk szerint „April of this year”). A fejlesztés Rust-ban történt, zöldmezős projektként, és tartalmazott konformancia teszteket a Git viselkedés ellenőrzésére, valamint determinisztikus szimulációs tesztelést a versenyhelyzetek felderítésére.
A váltás hatásai az OpenAI monorepo-jára:
- A median push késleltetés majdnem ötszörös javulást mutatott (a cikk „cut median push latency by nearly 5x”), más helyen ~80%-os csökkenést említenek ugyanennek a metrikának.
- Pando képes közel egy petabyte Git-adatot szolgáltatni naponta.
- Egy óra alatt több mint 57 terabájtnyi Git-pack került kiszolgálásra, ebből több mint 99% helyi lemez cache-ből.
- Helyi Express cache-ekkel a cache hit ráta 99% fölötti.
- Standard felhő VM-ek mellett is képesek klienseit 10 Gbps linkeket telíteni clone/fetch műveletekkel.
Kapcsolódás az upstream Git-hez és jövő
Pando megtartotta a Git protokoll és kliens kompatibilitást, ami lehetővé tette, hogy a feltárt problémákat és fejlesztéseket visszajuttassák az upstream Git-be. Például javították a packfile-uri letöltési és párhuzamos indexelési útvonalakat, hozzáadtak tracinget a packfile-uri-k letöltéséhez és csomaggenerálási byte-számlálást, illetve bevezették az „explicit haves” fogalmát a klienskliensben. Néhány változtatás már bekerült az upstream Git-be, továbbiakat nyilvános repójukban tartanak.
Pando nem csak az OpenAI monorepo számára készült: a csapat vizsgálja a rendszer további felhasználási módjait, például olyan munkaterheléseket, ahol sok ügynök együtt dolgozik egy közös Git-tárhelyen. Az OpenAI tervezi a technológia megosztását is azokkal a külső felhasználókkal, akik hasonló skálázási problémákkal találkoznak.
Összegzés
Pando újraértelmezte a Git-skálázás néhány konvencionális feltételezését azáltal, hogy kauzális konzisztenciát és pack-reuse-t alkalmaz. Ennek eredményeként az OpenAI monorepo-ja nagyobb párhuzamosságot, jobb merge-megbízhatóságot és jelentősen rövidebb push-válaszidőket ért el anélkül, hogy a fejlesztők és ügynökök Git-alapú munkameneteit megváltoztatta volna. A fejlesztők visszajuttatják tapasztalataikat és javításaikat az open-source Git közösséghez, hogy a technológia mások számára is hasznos legyen.
