OpenAI تبني Pando: واجهة Git خلفية رفعت سرعة الدفع 5 أضعاف تحت ضغط Codex

تخيّل أن كل مهندس في شركة حصل فجأة على عشرة مساعدين، وكل واحد منهم يدفع الشيفرة ويفتح الفروع ويشغّل CI. هذا بالضبط ما حدث في OpenAI عندما بدأ Codex بكتابة الشيفرة على نطاق واسع. لم يعد عنق الزجاجة في المستودع الأحادي هو البشر، بل خادم Git نفسه.

ما الذي تعطّل

منذ نهاية العام الماضي لم تعد الأنظمة المحيطة بالمستودع الأحادي قادرة على المواكبة: عمليات fetch وpush بطيئة، وعمليات دمج فاشلة، وموثوقية تقل أحيانًا عن 90%. والحمل ينمو بصورة مضاعِفة: يحتفظ المهندس الواحد بعدة تغييرات في CI، وكل عملية push تطلق عدة مهام تسحب الـ commit نفسه.

لم يتخلَّ المهندسون عن Git. قرروا الإبقاء على البروتوكول والعميل، كي لا يضطر البشر والوكلاء إلى إعادة تعلّم أي شيء، ويمكن إرسال التحسينات إلى المشروع الأصلي (upstream). استبدلوا الواجهة الخلفية فقط، ودون إيقاف العمل. هكذا وُلد Pando.

لماذا ليس 3PC ولا WAL

تصطدم الطرق التقليدية لتوسيع Git بنقطة تنسيق واحدة.

الخيار الأول: نسخ متماثلة كاملة والتزام ثلاثي المراحل. تتطلب كل عملية push عدة جولات تواصل بين المنسّق والنسخ، وتقع أقراص النسخ وشبكتها على المسار الحرج للكتابة. وتُحدَّث الـ ref واحدًا تلو الآخر.

الخيار الثاني: بيان (manifest) مشترك في مخزن blob مع سجل كتابة مسبقة. تُرفع الـ packs بالتوازي، لكن كل تحديث يغيّر بيانًا واحدًا عبر compare-and-swap. فتتزاحم عمليات الدفع إلى فروع غير مترابطة. تساعد المعالجة بالدُفعات لكنها تضيف زمن انتظار.

كيف يعمل Pando

تخلّى المؤلفون عن افتراضين معتادين.

الأول: اتساق المستودع بأكمله. يخزّن Pando ملف packfile الوارد ككائن blob غير قابل للتغيير، ويضع البيانات الوصفية (رأس الفرع الجديد، والـ pack، والاعتماديات على الإصدارات السابقة من الـ ref) في مخزن قابل للتوسع أفقيًا. يُحدَّث كل فرع بشكل مستقل مع قابلية التسلسل داخل ref واحد. وهذا اتساق سببي: يرى القارئ تاريخ من كتب الـ ref، لكن دون لقطة واحدة موحّدة للمستودع كله.

عمليًا، عند الاستنساخ أثناء تحديث الفرعين foo وbar، قد يرى عميل foo بالإصدار 1 وbar بالإصدار 2، ويرى آخر العكس. ويرى المؤلفون أن ما يهم البشر والوكلاء هو ترتيب تحديثات الفرع الواحد، لا ترتيب عام.

الثاني: pack فريد لكل عميل. عادةً يجمّع الخادم لكل عميل حزمته الخاصة كي لا يرسل ما لا حاجة إليه، وهذا يستهلك المعالج والقرص. أما Pando فيعيد استخدام ملفات packfile: قد يُنزّل العميل جزءًا من الكائنات التي لديه بالفعل، لكن الخادم يرسل البايتات نفسها إلى عملاء كثيرين تقريبًا دون حسابات. هدف القراءة: استهلاك كامل عرض النطاق الشبكي المتاح للعميل.

النتائج والقيود

في بيئة الإنتاج انخفض زمن الاستجابة الوسيط لعملية push بنحو 5 مرات، ويقدّم Pando قرابة بيتابايت من البيانات يوميًا. والثمن واضح: لا توجد لقطة شاملة لكل الـ refs، وحركة بيانات زائدة للعملاء الذين لديهم بعض الكائنات مسبقًا.

تتضمن المقالة أيضًا محاكاة على 1000 عميل تقارن ثلاثة نماذج، لكن المؤلفين يقارنون تطبيقاتهم على نماذج لا على معايير مستقلة. لم يُنشر كود Pando، وبدلًا من ذلك تعد OpenAI بتطوير عميل Git في المشروع الأصلي.

ماذا تفعل بهذا

إذا كان وكلاؤك ينشئون فروعًا كثيرة وعمليات دفع متوازية، فسيظهر عنق الزجاجة قريبًا في استضافة Git لا في النموذج. تحقّق من العمليات التي تتطلب فعلًا لقطة متسقة عالميًا للمستودع، وأيها يكفيها الترتيب داخل فرع واحد. ويجدر أيضًا قياس push-to-fetch latency: فهذا المقياس يُظهر كم ينتظر الوكيل حتى يرى وكيل آخر أو CI التزامه. وتابع تحسينات Git في المشروع الأصلي: فمن المرجّح أن تصل إلى الجميع.