OpenAI дахь Git-ийн өргөтгөл

Сүүлийн нэг жилд манай монорепозиторын хэмжээ болон түүнд тавигдах шаардлага асар хурдацтай өссөн. Codex-ийн боломж олгож буй зэрэгцээ ажлын хэмжээнд хүргэхийн тулд эх кодын хяналтын системээ шинэчлэх шаардлагатай нь тодорхой болсон.

Бид инженерийн ажлыг тасалдуулахгүй, багийнхаа Git ашиглах арга барилыг өөрчлөхгүйгээр Git репозиторын шинэ арын систем болох Pando-г бүтээсэн. Одоо OpenAI-ийн монорепозитор дахь бүх хөгжүүлэлт Pando дээр ажиллаж байна. Pando хоёр том зорилготой: нэгдүгээрт, олон салаа руу зэрэг push хийхэд оновчилсон, хэвтээ чиглэлд өргөжүүлэх боломжтой бичих үйлдэл. Хоёрдугаарт, унших нэвтрүүлэх чадамжийг дээд хэмжээнд хүргэж, клиентүүд сүлжээний зурвасын өргөнөө бүрэн ашиглах хурдаар өгөгдөл татах боломж бүрдүүлэх.

Бид Git протокол болон клиенттэй нийцтэй байдлыг хадгалан эдгээр зорилгод хүрсэн тул инженерүүд, агентууд одоогийн ажлын урсгалдаа Pando-г саадгүй нэвтрүүлж чадсан. Бодит ашиглалтад Pando push үйлдлийн медиан саатлыг бараг 5 дахин бууруулсан. Одоо өдөр бүр бараг нэг петабайт Git өгөгдөл дамжуулж байна.

Энд бид эх кодын хяналтын шинэ систем бүтээх болсон шалтгаан, мөн Git-тэй нийцтэй байдлыг хадгалахаар шийдсэн учраа тайлбарлана. Системээ Git-ийг өргөжүүлэх түгээмэл аргуудтай харьцуулж, Pando яагаад OpenAI-ийн өргөтгөх хэрэгцээг онцгой сайн хангаж байгааг тайлбарлана. Мөн дараагийн алхам, агентуудын ажлын цар хүрээг дэмжихийн тулд Git-д хэрхэн үргэлжлүүлэн хувь нэмэр оруулахаа өгүүлнэ.

Codex нь OpenAI-ийн хөгжүүлэлтийн цар хүрээ, хурдыг өөрчилж, инженерүүдэд хавьгүй олон ажлыг зэрэг хийх боломж олгосон. Үүний үр дүнд салаа, push, нэгтгэх үйлдэл олширч, хөгжүүлэлтийн орчин, судалгааны ажлууд болон CI-ээс илүү олон fetch, clone хийх болсон.

Эдгээр хэрэгцээ харилцан нэмэгддэг. Одоо нэг инженерийн хэд хэдэн өөрчлөлт CI-д зэрэг бэлэн болж, push бүр нэг коммитыг татах хэд хэдэн ажил эхлүүлж болно.

Өнгөрсөн оны эцэс орчмоос монорепозиторыг дэмждэг системүүд маань ачааллаа дийлэхгүй болж эхэлсэн. Fetch, push удааширч, нэгтгэх үйлдлүүд бүтэлгүйтэн, найдвартай байдал заримдаа 90%-иас доош унаж байв. Бид Git-ийн өөрийнх нь хязгаарт хүрсэн үү, эсвэл монорепозиторт үйлчилж буй арга маань хязгаартаа хүрсэн үү? Git нь цөмийн засваруудыг имэйлээр солилцдог нийгэмлэгээс үүссэн. Хорь гаруй жилийн турш программ бүтээх арга барил өөрчлөгдөхийн хэрээр хөгжүүлэгчид хэрэгслүүдээ Git-д нийцүүлэн хөгжүүлж ирсэн. Өөрсдийн монорепозиторт хүндрэл мэдрэгдэж эхлэхэд тэрхүү ажилд үргэлжлүүлэн тулгуурлах нь бидэнд чухал байлаа.

Танил ажлын урсгалаа хадгалахын зэрэгцээ өөр өөр салааны push-ийг зэрэгцээ боловсруулж, нэг түүхийг олон уншигчид зэрэг хүргэхээр арын системийг шинэчлэх боломж бидэнд харагдсан. Эх кодын хяналтын ажлын урсгалаа Git дээр суурилуулах нь клиентийн сайжруулалтууд OpenAI-ээс гадна ч тустай байх боломжийг бүрдүүлсэн. Бид өөрсдийн Git хувилбар⁠(шинэ цонхонд нээгдэнэ) дахь сайжруулалтуудыг үндсэн төсөлд нийлүүлж, нийт нийгэмлэгтэй хуваалцахыг хүссэн.

Эх кодын хяналтын системийг өргөжүүлэхэд хоёр гол чиглэл бий: олон бичигч өөр өөр салаа руу push хийх, олон уншигч нэг түүхийг татах. Pando аль алинд нь оновчлогдсон.

Нэгдүгээрт, Pando салаа бүрийн шинэчлэлтийг бие даан зохицуулдаг. Хамааралгүй салаанууд зэрэгцээ шинэчлэгдэж болох бөгөөд салаа татаж буй уншигч тухайн хувилбарт хэрэгтэй түүхийг авна. Харин үүний сул тал нь хэд хэдэн салаа харж буй уншигч тэдгээрийн өөр өөр агшин дахь төлөвийг харж болно.

Хоёрдугаарт, Pando клиент бүрд тусгай багц файл үүсгэхийн оронд fetch үйлдлүүдэд багц файлуудыг (олон объектыг хамтад нь шахах Git-ийн формат) дахин ашигладаг. Клиент өөрт байгаа зарим объектыг дахин татаж болох ч сервер бага тооцоолол хийж, ижил байтуудыг олон клиентэд хүргэж чадна.

Эдгээр шийдэл нь олон салаан дахь бичилтийг өргөжүүлж, унших хүсэлтийг кэшээс хангах боломж олгодог. Эдгээр нь хэрхэн уялддагийг ойлгохын тулд Git түүхийг хэрхэн хадгалж, дамжуулдгаас эхэлье.

Git нь репозиторын объектууд ба лавлагаанууд гэсэн хоёр хэсгийг хооронд нь нийцтэй байлгах ёстой.

Git репозитор файлуудын агшин дахь төлөв болон тэдгээрийг холбох түүхийг объектуудын граф хэлбэрээр бүртгэдэг. Объект нь блоб, мод, коммит эсвэл шошго байж болно. Блоб нь нэг файлын агуулгыг хадгалдаг. Харин мод нь нэрсийг блоб эсвэл бусад модтой холбож, хавтасны бүтцийг бүрдүүлдэг. Коммитууд язгуур мод болон тэг буюу түүнээс олон эцэг коммит руу зааж, репозиторын түүхийг бүрдүүлнэ.

Объектыг төрөл болон агуулгынх нь хэшээр тодорхойлдог. Объектууд мөн өөрчлөгдөшгүй: өөрчлөгдсөн файлыг бүртгэхэд шинэ блоб үүсэх бол өөрчлөгдөөгүй файл, хавтаснууд өмнөх объектуудыг дахин ашиглаж болно.

Салаа болон шошго нь коммит руу заадаг лавлагаа буюу “refs” юм. Салаанд коммит хийхэд шинэ коммит үүсэж, салааны лавлагаа түүн рүү заахаар шинэчлэгдэнэ.

Git объектуудыг “тусдаа” эсвэл “багцалсан” төлөвөөр хадгалдаг. Тусдаа объектууд объектын ID-аар танигдах бие даасан файлуудад хадгалагдана. Багцалсан объектууд нэг багц файлд хамт хадгалагдах тул төстэй объектуудыг нэг нэгнээсээ ялгарах өөрчлөлтөөр нь хадгалах боломжтой.

Git коммитын холбоосуудыг эцэг коммит, мод, блобуудаар нь даган объектыг олж чадвал тэр объектыг тухайн коммитоос хүрч болох объект гэнэ. Fetch хийх үед клиент ямар коммитууд хүсэж байгаагаа, мөн аль нь өөрт нь байгааг серверт хэлнэ. Сервер хүссэн коммитуудаас хүрч болох объектуудыг олж, клиентэд байгааг нь мэдэж буй объектуудыг хасаад, үлдсэнийг Git-ийн диск дээр ашигладаг ижил форматтай багц файл болгон илгээнэ. Бүрэн clone ямар ч объектгүй эхэлдэг тул хуулж буй түүхээс хүрч болох бүх объект хэрэгтэй.

Push нь нэг буюу хэд хэдэн лавлагааг шинэчлэхийг серверээс хүсэж, объектуудыг эсрэг чиглэлд дамжуулна. Клиент серверийн зарласан лавлагаануудыг ашиглан серверт байгаа объектуудыг дахин илгээхээс зайлсхийнэ. Иймээс илгээх багц өмнө нь байгаа объектуудаас хамаарч болно. Зөвхөн багцыг хүлээн авах нь шинэ түүхийг сэргээхэд хангалтгүй.

Git репозиторыг хуулбарлан байршуулна гэдэг нь объект, лавлагааг хоёуланг нь олон серверт ашиглах боломжтой байлгахыг хэлнэ. Реплика лавлагааны шинэ утгыг хүргэхээсээ өмнө тэр утгаас хүрч болох объектуудыг өгөх чадвартай байх ёстой. Үйлчилгээ мөн өрсөлдөж буй лавлагааны шинэчлэлтүүдийг зохицуулах хэрэгтэй. Өөрөөр хэлбэл, нэг салааг ижил хуучин үзүүрээс өөр өөр шинэ коммит руу шилжүүлэхийг оролдсон push-үүдийг зохицуулна. Репозиторын бүх бичилтийг нэг дараалалд оруулдаг системүүд хамааралгүй салаануудын push-ийг ч нэг нэгнээ хүлээхэд хүргэж болно.

Pando-г загварчлахдаа Git-д суурилсан эх кодын хяналтыг өргөжүүлэх уламжлалт аргуудыг үнэлсэн. Нэг нь гурван үе шаттай баталгаажуулалт (3PC, олон зангилаанд баталгаажуулалтыг зохицуулах протокол) ашиглан репликийн лавлагаануудыг шинэчилдэг. Нөгөө нь блоб хадгалах сан дахь нийтлэг урьдчилан бичих журналаар (WAL, өөрчлөлтийг хэрэглэхээс өмнө бичдэг бүртгэл) шинэчлэлтүүдийг дараалалд оруулдаг.

Бидний загварчилсан гурван үе шаттай баталгаажуулалтын шийдэлд Git үйлчилгээ репозиторын бүрэн хуулбарыг хэд хэдэн репликад хадгалдаг. Аль нэг сервер push хүлээн авахад ирсэн багц файлыг хуулж, бүх реплика руу зэрэг илгээнэ. Push-ийг нийтлэхийн тулд репликуудын олонх нь лавлагааны шинэчлэлтийг зөвшөөрөх ёстой. Үүнийг удирдаж буй серверийг зохицуулагч гэнэ. Зохицуулагч болон бусад реплика бүрийн хооронд олон удаагийн харилцаа шаардлагатай.

Лавлагааны шинэчлэлтийг зөвшөөрөхийн тулд реплика бүр өөрийн лавлагааг түгжиж, клиентийн хүлээж буй коммит руу заасан хэвээр эсэхийг шалгана. Дараа нь зохицуулагч зөвшөөрсөн репликуудад урьдчилан баталгаажуулах мэдэгдэл илгээнэ. Олонх нь урьдчилан баталгаажуулах мэдэгдлийг хүлээн авснаа баталмагц зохицуулагч шинэчлэлтийг гүйцэтгэхийг заана. Үүний дараа шинэ төлөвт хүрсэн аль ч реплика репозиторын локал хуулбараасаа салааны шинэ үзүүрийг зарлаж чадна.

Бүрэн репликууд хадгалах нь унших хүсэлтийг локалаас хангах боломж олгож, клиент аль репликийг сонгосноос үл хамааран бүх лавлагааны нийцтэй төлөвийг харахыг баталгаажуулдаг. Үүний улмаас лавлагаанууд нэг нэгээрээ шинэчлэгдэж, push бүр лавлагааны шинэчлэлтийг репликуудын хооронд зохицуулахын тулд олон удаа хүсэлт, хариу солилцох шаардлагатай болдог.

Кворум хүлээх нь push-ийн хугацааг репликагийн дискний гүйцэтгэл, харилцааны саатлаас хамааралтай болгодог. Бичилтийн хэмжээ өсөхөд репликууд ирж буй багцууд болон унших ачааллыг зэрэг дийлэх ёстой.

Бидний загварчилсан WAL-д суурилсан шийдэлд Git үйлчилгээ блоб хадгалах сан дахь нийтлэг манифестээр репозитор даяарх шинэчлэлтүүдийг дараалалд оруулдаг. Сервер push хүлээн авахдаа ирсэн багц файлыг блоб хадгалах санд байршуулж, репозиторын локал хуулбартаа лавлагааны шинэчлэлтийг бэлтгэнэ. Push-ийг нийтлэхийн тулд блоб хадгалах сан дахь нийтлэг манифестэд лавлагааны шинэчлэлтийг бүртгэж, багц файл руу заасан бичлэг нэмнэ. Дараа нь Git сервер харьцуулж-солих үйлдлээр манифестийг шинэчилнэ. Энэ нь манифестийг атомар байдлаар солих эсвэл өөрчлөлтөөс татгалзах үйлдэл юм. Хэрэв энэ хооронд өөр бичигч шинэчилсэн бол сервер завсрын бичлэгүүдийг уншиж, өөрийн лавлагааны шинэчлэлт хүчинтэй хэвээр эсэхийг шалгаад, өмнө байршуулсан багц файлаа ашиглан дахин оролдоно.

Бичигчид багц файлуудаа зэрэг байршуулж болох ч хамааралгүй салаануудын push хүртэл нэг манифестийг шинэчлэх шаардлагатай. Амжилттай харьцуулж-солих хүсэлт, хариуны нийт хугацаа репозитор шинэ манифест нийтлэх давтамжийг хязгаарладаг. Саатал багатай блоб хадгалах сан энэ алхмыг хурдасгана. Бөөнөөр боловсруулах нь нэг манифестээр хэд хэдэн лавлагааг зэрэг шинэчлэх боломж олгодог ч шинэчлэлтүүдийг дараалалд хүлээлгэж, саатлыг нэмэгдүүлдэг.

Блоб хадгалах сан багц файлуудыг зэрэг хүлээн авч чаддаг ч нийтлэг манифестийн шинэчлэлтүүд хоорондоо өрсөлдсөн хэвээр байна. Зөвхөн блоб хадгалах сангийн хүчин чадлыг нэмэх нь энэ гацааг арилгахгүй. Реплика бүр багцуудыг локалаас хүргэхийн өмнө блоб хадгалах сангаас уншиж, индексжүүлэх шаардлагатай хэвээр. Ирж буй бичилт энэ ажлаас хурдан бол репликууд хоцорч, клиентүүд шинээр push хийсэн коммитуудыг татахын тулд удаан хүлээнэ.

Ингээд Pando-ийн тухайд оръё. Pando нь олон клиентээс зэрэг push хүлээн авах хэмжээнд өргөжих зорилготой, Git репозиторт үйлчлэх шинэ архитектур юм. Энэ нь дараах байдлаар ажиллана:

Pando-г хөгжүүлэхээс өмнө бид Git-ийг хэвээр ашиглан шаардлагаа хангаж чадна гэж таамаглаж байв. Харин ихэнх Git системийн зайлшгүй шаардлага гэж үздэг зарим зүйлээс татгалзах хэрэгтэй байлаа:

• Репозитор даяарх нийцтэй төлөв: Бүх лавлагааны нэг агшин дахь нийцтэй төлөвийг харуулахын тулд репозитор даяар зохицуулалт хийх шаардлагатай. Бүх лавлагааны шинэчлэлтийг нэг дараалалд оруулдаг системд хамааралгүй салаануудын push үйлдлүүд зохицуулалтын нэг цэг дээр өрсөлдөнө.

• Клиент бүрд тусгай багц файл үүсгэх: Өөр өөр локал түүхтэй хоёр клиент нэг салааг татахад тэдэнд байгаа объектуудыг дахин илгээхгүйн тулд сервер тус бүрд нь өөр багц үүсгэх шаардлагатай болж болно. Эдгээр хариуг үүсгэхэд CPU болон дискний оролт/гаралтын нөөц зарцуулдаг тул олон уншигч клиентэд үйлчлэхээр өргөжүүлэхэд хүндрэлтэй.

Харин Pando нь бичих үйлдлийг өргөжүүлэхийн тулд нийцтэй төлөвийн шаардлагыг сулруулсан загвар буюу шалтгаант нийцлийг ашиглаж, унших үйлдлийг өргөжүүлэхийн тулд багц файлуудыг дахин ашигладаг.

Клиент салаа руу push хийхэд Pando ирсэн багц файлыг блоб хадгалах санд өөрчлөгдөшгүй блоб болгон хадгална. Салааны үзүүр өөрчлөгдөх бүрд Pando шинэ үзүүр, түүнийг агуулсан багц, багцын хамаарах өмнөх лавлагааны хувилбаруудыг багтаасан лавлагааны хувилбар-ыг мета өгөгдлийн санд бүртгэнэ. Блоб болон мета өгөгдлийн хадгалах санг хоёуланг нь хэвтээ чиглэлд өргөжүүлэх боломжтой.

Pando-оос коммит эсвэл лавлагаа татахын тулд лавлагааны хувилбаруудыг (багц файлуудыг) клиентэд дараалан дамжуулж, татаж буй хувилбарыг үүсгэсэн клиентийн төлөвийг сэргээнэ. Ингэснээр репозиторын хэмжээнд нийцтэй төлөвийн баталгаа сулрах ч лавлагаа тус бүрийн шинэчлэлтүүдийг цуваагаар гүйцэтгэсэнтэй адил үр дүнг баталгаажуулна. Клиентүүд зөвхөн нэг лавлагаа руу зэрэг push хийх үед зөрчилдөнө. Хэд хэдэн салаа уншиж буй клиент тэдгээрийг репозиторын нэг агшин дахь төлөв гэж үзэж болохгүй.

Энэ нь шалтгаант нийцэл-ийн нэг хэлбэр юм. Лавлагааг татахын тулд уншигч нь түүнийг үүсгэсэн бичигчийн түүхийг харна. Push хийх үед Pando клиент ба сервер ямар нийтлэг түүх дээр тохиролцохыг хянаж, клиентүүдийг бусадтай хуваалцахад хялбар багц файл үүсгэх нөхцөлөөр хангана.

Иймээс Pando нь Git үйлдлийн үед бүх лавлагааны нэг агшин дахь төлөвийг, мөн clone эсвэл fetch доторх лавлагааны шинэчлэлтүүдийн дарааллыг баталгаажуулдаггүй. Жишээ нь, бүрэн clone хийх тохиролцооны явцад foo болон bar салаа хоёулаа шинэчлэгдлээ гэж үзье. Тохиролцооны явцад нэг клиент foo-ийн 1-р хувилбар, bar-ийн 2-р хувилбарыг харж байхад нөгөө нь foo-ийн 2-р хувилбар, bar-ийн 1-р хувилбарыг харж болно. Бодит хэрэглээнд хэрэглэгчид болон агентууд лавлагааны шинэчлэлтүүдийн нийт дарааллаас бус, нэг лавлагааны шинэчлэлтийн дарааллаас хамаардаг.

Нийцтэй төлөвийн гурван загварыг харьцуулсан энэ симуляцид 1,000 клиент тус бүр өөр салаа сонгон, давтагдашгүй коммитуудыг дахин дахин push хийхээр тохируулж, нийт өнгөрсөн хугацаа болон push-ээс fetch хүртэлх саатлыг хэмжсэн. Сүүлийн үзүүлэлт нь хэрэглэгч, агентууд хамтран ажиллах эсвэл хувилбарын хяналтад тулгуурладаг бусад системийг ашиглахад шаардагдах бүтэн мөчлөгийн хугацааг хэмждэг тул ажлын ачааллын чухал хэмжүүр юм. Симуляцид энгийнээс өндөр хүчин чадалтай хүртэлх виртуал машин болон блоб хадгалах системүүдийг загварчилсан. Энэ симуляцид гурван үе шаттай баталгаажуулалтын репозитор даяарх нийцлийн шаардлагыг сулруулсан.

Загварчилсан гурван үе шаттай баталгаажуулалтын системийн диск ачаалал дунд дээд хүчин чадалдаа хүрэхэд бичих саатал эрс нэмэгдсэн. Харин урьдчилан бичих журналтай системүүдэд ижил шалтгаанаар серверүүд журналыг уншиж амжихгүй болж, унших саатал эрс нэмэгдсэн. Манай монорепозитор дээрх бодит туршилт болон энэ симуляцид аль алинд нь Pando ачаалалтай үед гүйцэтгэлийг бууруулалгүйгээр олон мянган клиентээс зэрэг push хүлээн авч чадсан.

Push боловсруулахдаа Pando ирж буй багц файлыг локал репозиторт задлахгүйгээр блоб хадгалах сан руу урсгалаар дамжуулах зуураа шалгадаг. Клиент fetch эхлүүлэхэд Pando түүнд хэрэгтэй хадгалсан багцуудыг сонгож, клиент тэдгээрийг татна. Аль ч сервер багц файлуудыг локал репозиторт хэрэглэх, эсвэл нөөц их шаардсан задлах, багцлах үйлдэл хийх шаардлагагүй. Pando серверүүд голчлон тохиролцоо хийх, багц файл сонгох үүрэгтэй тул ердийн техник хангамж дээр ажиллаж чадна.

Ингэснээр Pando нь клиентүүд, клиент ба Pando хоорондын сүлжээ, блоб хадгалах үйлчилгээний хүчин чадлын хязгаар хүртэл өргөжих боломжтой. Хүчин чадал хангалттай үед бие даасан салаан дээр ажилладаг клиент бүр өөрийн холболтын боломжит дээд хурдаар багц дамжуулж чадна. Ижил хурдаар илүү олон клиентэд үйлчлэхийн тулд Pando сервер нэмж, мета өгөгдлийн болон блоб хадгалах санг хамт өргөжүүлж болно.

Агент локал орчинд файлуудыг засаж, коммит үүсгээд git push ажиллуулна. Энэ нь салааг шинэчлэхийн тулд тухайн өөрчлөлтүүдийн багц файлыг үүсгэдэг. Pando багцыг хүлээн авч, блоб хадгалах сан руу урсгалаар дамжуулна. Ирсэн push-ийг нэг удаагийн декодлолтоор шалгасны дараа Pando олон түлхүүрт транзакц ашиглан мета өгөгдлийн санд лавлагааны хувилбар бүртгэж, лавлагааны заагчийг атомар байдлаар шинэчилнэ. Ингэснээр Pando “өөрийн бичсэнээ унших” нийцлийг баталгаажуулдаг. Энэ бичих үйлдэл бүхэлдээ $O(1)$ тооны мета өгөгдөл унших, бичих үйлдэл шаарддаг.

Өөр клиент салааг татах үед Pando түүнд байгаа түүхийг ашиглан хадгалсан багцуудаас сонгоно. Энэ үйлдэл $O(\log \Delta)$ тооны мета өгөгдөл уншилт шаарддаг. Энд $\Delta$ нь клиентэд байгаа болон хүсэж буй төлөвийн хоорондох лавлагааны хувилбаруудаар хэмжсэн хамгийн богино зай юм. Сервер багц файлын URI хаягуудыг буцааж, клиент тэдгээрийг бүс нутгийн кэшүүдэд багц файл хадгалдаг Express үйлчилгээгээр дамжуулан татна.

Энэ шийдэл Pando-ийн архитектурын push, fetch, шахалт гэсэн гурван гол үйлчилгээнд тулгуурладаг.

Клиент push хийхэд уламжлалт Git сервер бүх хөзрөө дэлгэсэн покерын тоглогч шиг өөрт байгаа бүх салааг клиентэд харуулдаг. Дараа нь клиент коммит, мод, блобуудыг цуглуулж, серверт байгааг нь мэдэж буй объектуудыг хассан багц файл үүсгэнэ.

Илүү олон лавлагаа зарлах нь push-ийн хэмжээг багасгаж болно. Гэхдээ бичигчийн хассан объектууд өөр клиентэд байхгүй байж болох тул багцыг дахин ашиглахад хүндрэл учруулж болно.

Pando өөр арга хэрэглэдэг. Бүх хөзрөө дэлгэхийн оронд зөвхөн сонгосон хэдэн салааг клиентэд зарладаг. Үүнд хоёр шалтгаан бий:

1. Бүх лавлагааны нийцтэй төлөвийг харуулах нь нөөц их шаарддаг. Сая сая салаатай үед зөвхөн лавлагаа зарлах өгөгдөл 100 MiB-аас давж болно. Үүний тулд сервер бүр ихээхэн зохицуулалт шаардсан, байнга шинэчлэгддэг харгалзуулалт хөтлөх эсвэл лавлагааны тоотой хамт зардал нь өсөх өгөгдлийн сангийн хүсэлт гүйцэтгэх ёстой.

2. Клиентэд лавлагааны зөвхөн хэсгийг харуулснаар түүний үүсгэх багц зөвхөн серверийн ил тод хасахыг зөвшөөрсөн объектуудаас хамаарна. Хамаарлуудыг бүртгэснээр Pando нэг push-д клиентээс үүсгэсэн багц файлыг дараагийн fetch-ийн хариу болгон дахин ашиглах боломжтой.

Git сервер олон лавлагаа зарлах тусам push хийж буй клиентүүдэд объект хасах суурь олон болж, жижиг багц үүсгэх боломж нэмэгдэнэ. Гэхдээ эдгээр багц файлыг дахин ашиглахын тулд сервер татаж буй клиентэд хамаарал бүр нь байгааг батлах чадвартай байх ёстой. Үгүй бол багц файлд клиентэд хэрэгтэй объектууд дутуу байж болно.

Нөгөө талаас, Git сервер огт лавлагаа зарлахгүй бол клиент репозиторын бүх түүхийг агуулсан багц файл үүсгэнэ. Тэр багц файлыг өөр ямар ч клиент ашиглаж болох ч аль ч салааг татах нь үндсэндээ бүрэн clone хийхтэй адил болж, их зардал гаргана.

Анхдагч тохиргоогоор клиент шинэ боломжийн салаа руу push хийхэд Pando зөвхөн тусгайлан сонгосон үндсэн салааг суурь болгон зарладаг. Ингэснээр репозиторын салаа нэмэгдсэн ч зарлах өгөгдлийн хэмжээ хэвээр үлдэнэ. Гэхдээ сул талууд бий. Инженер нэг салаа руу олон удаа push хийх эсвэл нэг боломжийн салаан дээр нөгөөг давхарлан үүсгэхэд клиент үндсэн салаанд байхгүй бүхнийг дахин илгээх шаардлагатай.

Үүний улмаас салааны дараалсан push-үүд томорч, давхардсан байж болох объектууд агуулан, клиентийн сүлжээний багтаамжаас нэмж зарцуулна. Манай монорепозиторт энэ аргаар үүссэн багц файлын медиан хэмжээ 20 KiB-аас бага, 99-р перцентиль нь 3 MiB-аас бага байв. Зарласан үндсэн салааны түүхтэй уншигч тэр нэг багц файлаар салааг татах боломжтой тул бидний хувьд энэ нь оновчтой сонголт байсан.

Клиентэд зарлах лавлагаануудыг сонгосны дараа Pando push-ийг хүлээн авч, мета өгөгдлийн сангаа шинэчилнэ. Pando мета өгөгдлийн шинэчлэлтийг синхрон ба асинхрон хэсэгт хуваадаг. Синхрон шинэчлэлт нь клиентүүд шинээр шинэчлэгдсэн коммитыг шууд татах боломжийг баталгаажуулна. Энэ нь шинэ лавлагааны хувилбар бичиж, заагчийг түүн рүү чиглүүлнэ. Шинэ үзүүр, багц файлын тохиролцоонд ашигласан хамаарлууд, push-ээр ирсэн багц файлын холбоосыг мөн хадгална.

Үүний зэрэгцээ шахалт товлох зэрэг асинхрон ажлыг мөн тэр транзакцад бүртгэнэ. Маш том push-ийн хувьд коммитуудын зөвхөн хэсгийг синхроноор бичнэ. Ингэснээр push-ийн хэмжээнээс үл хамааран мета өгөгдлийн санд тогтмол тооны унших, бичих үйлдэл хийхэд хангалттай.

Хамгийн чухал нь Pando серверүүд хамааралгүй лавлагаануудын push-ийг бие даан хүлээн авч чадна. Өрсөлдөөн үүсэх цорын ганц түлхүүр нь лавлагааны заагч бөгөөд бид үүнийг атомар харьцуулж-солихтой төстэй үйлдлээр хамгаалдаг. Pando сервер, мета өгөгдлийн сангийн өргөтгөх нэгж эсвэл блоб хадгалах сан нэмснээр бичих нэвтрүүлэх чадамжийг өсгөж болно.

Клиент fetch хийхдээ серверт протоколд have болон want гэж нэрлэдэг хоёр багц коммитын ID өгнө. Уламжлалт Git сервер байгаа коммитуудаас хүрч болох болон хүссэн коммитуудаас хүрч болох объектуудын олонлогийн ялгаврыг тооцоолж, шахаад клиент рүү илгээнэ. Нээлттэй эхийн Git сервер энэ үйлдлийг хурдасгах олон төрлийн локал индекстэй ч багц файлуудыг тооцоолж үүсгэхэд их нөөц шаардагдах бөгөөд ерөнхийдөө кэшлэхэд тохиромжгүй.

Харин Pando push хийх үед бүртгэсэн коммитын харгалзуулалтаас клиентийн have болон want-ыг хайж, тухайн коммитуудыг агуулсан лавлагааны хувилбаруудыг олно. Тэдгээр лавлагааны хувилбар бүр Pando-ийн өмнө нь хүлээн авсан багц файлтай холбогдоно. Сервер үүнийг ашиглан клиентэд юу хэрэгтэйг тогтоож, шаардлагатай объектуудыг хамарсан багц файлуудыг сонгоно.

Git протокол clone эсвэл fetch-ийн HTTP хариунд зөвхөн нэг багц файл илгээхийг зөвшөөрдөг. Гэхдээ Git протоколын төдийлөн үнэлэгддэггүй packfile-uri боломж нь нэмэлт багцуудыг тусад нь татах холбоосуудыг серверээс буцаах боломж олгодог. Pando зөвхөн энэ аргыг ашиглаж, хариу дотор хоосон багц файл дамжуулдаг. Энэ боломжийг дэмжихийн тулд OpenAI packfile-uri-ийн хэд хэдэн сайжруулалтыг үндсэн төсөлд нийлүүлсэн.

OpenAI-ийн системүүд газарзүйн олон бүсэд ажилладаг тул бүс бүрд локал кэштэй Pando кластер ажиллуулдаг. Багц хүргэх Express үйлчилгээ блоб хадгалах санг, өөр тусдаа үйлчилгээ мета өгөгдлийн санг кэшилдэг. Эдгээр кэшийн ачаар Pando коммитын ID-аар ирсэн хүсэлт эсвэл лавлагааг тусгайлан унших хүсэлтийг тухайн кластерын кэшилсэн төлөвөөс бүрэн хангаж чадна. Багц файлын хүсэлтүүдийг Express серверүүд рүү чиглүүлэхдээ тогтвортой хэшлэл ашигладаг бөгөөд кэшээс олдох хувь 99%-иас давдаг.

Энэ кэшийн систем маш өндөр нэвтрүүлэх чадамжтай тул клиент ба Pando хоорондын сүлжээний багтаамжийг бүрэн ашиглаж чадна. Эдгээр багц файлын URI болон локал кэшийн тусламжтайгаар зөвхөн үүлэн үйлчилгээний стандарт виртуал машин ашигласан ч clone, fetch үйлдлүүд 10 Gbps холболтын багтаамжийг бүрэн ашиглаж байгааг баталгаажуулсан.

Ихэнх Git серверт өсөж буй репозиторын гүйцэтгэлийг хадгалахын тулд дахин багцлах, хэрэгцээгүй өгөгдлийг цэвэрлэх шаардлагатай. Энэ хоёр алхам хоёулаа зай чөлөөлдөг ч тооцоолол болон оролт/гаралтын нөөц их шаарддаг.

OpenAI-ийн монорепозитор шиг хурдан өөрчлөгддөг репозиторт сүүлийн fetch-ээс хойших push бүрийн багц файлын URI-г тусад нь илгээх нь боломжгүй шахам. Клиент үндсэн салаагаа шинэ төлөвт хүргэхийн тулд өдөр бүр хэдэн арван мянган багц файл татах хэрэгтэй болно.

Үүний оронд Pando журнал бүтэцтэй нэгтгэх модны шахалттай төстэй шийдэл ашиглан багцуудыг арын горимд нэгтгэж, энэ нэмэлт зардлыг бууруулдаг. Push бүр Pando-ийн “L0” гэж нэрлэдэг багц файл үүсгэдэг бөгөөд энэ нь Pando-ийн дамжуулах өгөгдлийн хамгийн жижиг нэгж юм. Арын горимын процессууд эдгээр багц файлыг лавлагааны дараалсан хувилбаруудыг хамарсан бүлгүүдэд аажмаар цуглуулна. Бүлгүүдийн хэмжээ L0-ээс эхлэн геометр прогрессоор өснө. Одоогоор манай монорепозитор L4 хүртэлх түвшний багц файлын хамрах бүлэг ашиглаж байна.

Эдгээр хамрах бүлэг хоёр үүрэгтэй. Хамрах бүлэг хангалттай дүүрмэгц шахалтын процесс түүнийг авч, нэг багц файл үүсгэнэ. Ингэхдээ багц файл доторх объектуудыг дахин зохион байгуулж, шахалтын харьцааг сайжруулна. Мөн лавлагааны хувилбаруудын алгасах жагсаалт болж, fetch тохиролцооны гүйцэтгэлийг сайжруулдаг. Pando түвшин бүрийн индексийг зэрэг шалгаснаар клиент рүү илгээх багцуудыг логарифм хугацаанд сонгож чадна. Дахин багцалсан эсэхээс үл хамааран эдгээр хамрах бүлэг fetch төлөвлөлтийг илүү үр ашигтай болгож, Pando-ийн нэвтрүүлэх чадамж болон сааталд тавигдах шаардлагыг бууруулдаг.

Олон Git серверээс ялгаатай нь бүх түвшний багц файлыг хадгалж, устгах эсвэл хэрэгцээгүй өгөгдөл гэж цэвэрлэхгүй. Клиентүүдийн fetch хүсэлт дэх have болон want-д үндэслэн бүх түвшний багцуудыг тасралтгүй ашиглан үйлчилдэг. Pando-г API болгон ашигладаг клиентүүд багц файлаас дурын объект уншихад L4-өөс илүү L0-д бага өгөгдөл унших хандлагатай. Учир нь L0 дахь объект шахагдсан байх магадлал бага.

Pando-ийн шахалт клиентэд дамжуулах нийт өгөгдлийг эрс багасгадаг. Мөн клиент хэр хоцорсноос хамаарах багц төлөвлөлтийн зардлыг шугаман өсөлтөөс бага байлгах боломж олгодог. Энэ нь том, хурдан өөрчлөгддөг репозиторуудад онцгой чухал бөгөөд ийм репозитор программ хөгжүүлэлтийн шинэ хэвийн байдал болно гэж бид үзэж байна.

Бид Pando-г Codex-той хамт бүтээж, төслийг эхлүүлснээс хойш ердөө 10 долоо хоногт бодит ашиглалтад оруулсан. Pando-ийн цөмийн загварыг ганц инженер гаргаж, агентуудын багууд хэрэгжүүлэн, цөөн инженер нэвтрүүлсэн. Pando энэ оны дөрөвдүгээр сараас бодит хэрэглээний хүсэлтүүдэд үйлчилж эхэлсэн бөгөөд OpenAI-д ашигладаг эх кодын хяналтын томоохон хэрэгслийн системийн нэг хэсэг юм.

Pando-ийн загварыг баталгаажуулахдаа бид олон төрлийн арга ашигласан. Бид илүү аюулгүй программын суурь бүтээх⁠ зарчмуудаа хэрэгжүүлсэн. Шинээр эхэлсэн төсөл учраас Pando-г Rust дээр, хуучин системийн хамааралгүйгээр хэрэгжүүлэхээр шийдсэн. Агентууд өөрчлөлтөө Git-ийн стандарт ажиллагаатай харьцуулан шалгах боломжтой нийцлийн тестийн багц бичсэн. Мөн системийн инвариант болон шинж чанаруудыг шалгах детерминистик симуляцийн тестийн хамгаалалт хөгжүүлсэн. Ингэснээр тохиролцоо, багц төлөвлөлт дэх илрүүлэхэд хэцүү өрсөлдөөний нөхцөл болон регрессийг олж, бууруулсан.

Энэ системийг бүтээхэд олон загвар хувь нэмэр оруулсан. Шинэ загварууд гарах бүрд тэдгээрийг ашиглан Pando-ийн гүйцэтгэл, найдвартай байдлыг сайжруулсан. GPT‑6 Astra ашигласан агентууд Lean болон TLA+ дээр “Pando-ийн онол”-ыг формалчилсан. Үүгээр бид хэрэгжүүлэлтийн алдааг олж засах, системийн шинж чанаруудыг батлах ажлыг хийсэн. Pando дахь захын тохиолдлуудыг олж засахаар олон тасралтгүй сесс хэдэн зуун цаг ажилласан. Мөн Daybreak-ийн чадамжтай загваруудыг ашиглан Git, Pando-ийн эмзэг талыг довтолгооны туршилтаар шалгах агентуудыг цаг наргүй ажиллуулдаг.

Бид эхлээд Pando-г одоогийн эх кодын хяналтын системийн унших, бичих үйлдлийг дамжуулах прокси болгон нэвтрүүлсэн. Ингэснээр Pando болон өмнөх системийн төлөвийг ижил байлгаж, үйлчилгээг тасалдуулахгүйгээр хүсэлтүүдийг Pando руу аюулгүй шилжүүлэх боломжтой болсон.

Кэшийн шийдлийнхээ хүрээнд Pando хүсэлтүүдийг проксигоор дамжуулахаас өмнө давхардлыг нь арилгаж, нэгтгэж чадна. Ингэснээр системүүдийг нэг нэгээр нь Pando руу шилжүүлэх зуур одоогийн хэрэгслүүдийн хэвийн ажиллагааг хадгалсан. Илүү олон ажлын ачааллыг Pando руу шилжүүлэх тусам тэдгээрийн push Pando-ийн кэшийг дүүргэж, өмнөх арын системийн найдвартай байдлыг сайжруулсан.

Pando ашиглах үеийн гүйцэтгэлийг оновчлохын тулд бид нийтэд нээлттэй Git түгээлтээ хөгжүүлэгчдийн компьютерт болон ChatGPT‑ийн суурин апп дотор нийлүүлж эхэлсэн. Клиентүүдийг Pando руу үе шаттай шилжүүлэхдээ Git CLI-г бүрхсэн дотоод хэрэгсэл ашигласан. Бид өөрчлөлтийн хүсэлт, кодын хяналтад зориулсан олон хэрэгсэл, мөн автоматжуулалтын API-ууд бүтээсэн. Git-ийн урсгалтай хамт хуучин API, webhook болон репозитор таталтаас хамааралтай олон зуун интеграцийг шилжүүлсэн.

Codex өөрөө хөгжүүлэгчид болон багуудад шилжихэд нь тусалсан. Одоо байгаа ажлын хуулбаруудыг бэлтгэх, агентуудыг шинэ систем ашиглахад чиглүүлэх ур чадварууд бүтээсэн. Үүний үр дүнд хөгжүүлэгчид хөгжүүлэлтийн орчин, үйлчилгээгээ шилжүүлэхийг Codex-оос хүсэхэд л хангалттай болсон.

Pando руу шилжсэнээр нэгтгэх үйлдлийн найдвартай байдал сайжирч, push-ийн медиан саатал бараг 80%-иар буурсан.

Pando ердөө цөөн CPU цөмөөр өдөрт нэг петабайт Git өгөгдөл дамжуулж чадна. Pando нэг цагт 57 терабайтаас их Git багц дамжуулсан бөгөөд байтуудын 99%-иас илүүг локал дискний кэшээс өгсөн.

Багцуудыг дахин ашигласнаар үйлчлэх зангилаануудад бага тооцоолол хийж, олон клиентэд ижил репозиторын түүхийг татуулах боломжтой. Энэ жишээнд нэг репозитор харуулсан ч Pando илүү олныг дэмжихээр бүтээгдсэн. Эрэлт өсөхөд өгөгдөл хүргэлт болон Git тохиролцооны хүчин чадлыг тус тусад нь өргөжүүлж болно.

Pando-г Git протокол болон клиент дээр бүтээсэн нь Git-ийн алдааг олж, өөрийнх нь гүйцэтгэлийг сайжруулах боломжуудыг илрүүлэхэд тусалсан.

Жишээ нь, Pando дахин ашиглах багцуудыг клиентэд шууд хүргэдэг тул тэдгээрийг татах, индексжүүлэх нь системийг хурдан, найдвартай болгох гол хэсэг болсон. Энэ ажлаар зэрэгцээ таталт, тасарсан дамжуулалтын дараах цэвэрлэгээ, аль хэдийн дууссан таталтыг үргэлжлүүлэхтэй холбоотой захын тохиолдлууд илэрсэн. Бид эдгээр ажиллагааг засаж, fetch-д байгаа багцыг хүлээн авахдаа хийх шалгалтууд нэмээд, уг ажлаа үндсэн төсөлд нийлүүлсэн.

Мөн цаг хугацаа, сүлжээний багтаамж юунд зарцуулагдаж байгааг харахын тулд packfile-uri таталтын мөрдөлт, багц үүсгэлтийн байтын тоолуур нэмсэн. Ингэснээр удаан fetch багц үүсгэхэд үү, дамжуулахад уу цаг зарцуулж байгааг ялгахад хялбар болсон.

OpenAI-ийн Git хувилбар⁠(шинэ цонхонд нээгдэнэ) дахь клиент бие даасан багцуудыг зэрэгцээ татаж, индексжүүлж чадна. Бид “ил тод заасан байгаа коммитууд” гэсэн ойлголт нэмсэн. Ингэснээр сервер салааны одоогийн үзүүрийг push хийж буй клиент багцаасаа хасаж болох түүхээс тусад нь зарлаж чадна. Pando дээр энэ нь клиентүүдэд --force-with-lease ашиглан боломжийн салаа өөрчлөгдөөгүйг шалгаад, зөвхөн үндсэн салааг суурь болгон багц үүсгэх боломж олгодог. Дараа нь тухайн үндсэн салааны түүхтэй хэн ч ижил багцыг ашиглан салааг татаж чадна.

Эдгээр сайжруулалтын зарим нь Git-ийн үндсэн төсөлд, бусад олон сайжруулалт манай нийтэд нээлттэй репозиторт аль хэдийн орсон. Эдгээр сайжруулалтыг Pando-оос гадна ч хэрэгтэй болгохын тулд бид Git нийгэмлэгтэй үргэлжлүүлэн ажиллаж байна. Энэ ажлын явцыг манай нийтэд нээлттэй засварын хяналтын хуудас⁠(шинэ цонхонд нээгдэнэ) дээрээс дагаж болно.

Git репозиторыг өргөжүүлэх уламжлалт ойлголтыг шинээр авч үзсэнээр Pando нь инженерүүд, агентуудын ашиглаж буй Git ажлын урсгалыг өөрчлөлгүйгээр монорепозиторыг өргөжүүлэх боломж олгож байна. Pando манай монорепозиторт илүү олон ажлыг зэрэгцээ гүйцэтгэх боломж нээж, нэгтгэх үйлдлийн найдвартай байдлыг сайжруулан, кодын өөрчлөлтийг нийтлэх хугацааг богиносгосон. Монорепозитороос гадна OpenAI дотор Pando-г ашиглах бусад боломжийг, тухайлбал олон агент нэг Git репозиторт хамтран ажиллах шаардлагатай ачааллуудыг судалж байна.

Инженерүүд, агентууд илүү их программ бүтээхийн хэрээр OpenAI-ээс гаднах олон баг эх кодын хяналтад бидний тулгарсан хязгаарлалтуудтай учирна. Одоо бид Pando-г бий болгосон технологийг хэрэглэгчидтэйгээ хуваалцах арга замыг судалж байна.

Pando нь Git репозиторын хэрэглэгчид болон администраторуудын хорин жилийн туршлагад тулгуурладаг. Бид Pando-г үргэлжлүүлэн хөгжүүлэхийн зэрэгцээ нээлттэй эхийн Git нийгэмлэгтэй хамтран ажиллаж, Git-ийн нийт хэрэглэгчдэд тустай сайжруулалтуудаа хуваалцана.