جيت هاب تعيد بناء بنية جيت التحتية لمواجهة التضخم الهائل في حركة بيانات وكلاء الذكاء الاصطناعي

تواجه منصة جيت هاب (GitHub) نمواً غير مسبوق في كثافة العمليات على نظام جيت (Git)، مدفوعاً بانتشار برمجيات ووكلاء الذكاء الاصطناعي (AI Agents) الذين يولدون تدفقات مكثفة ومتواصلة من التعديلات والتحديثات. ولمواجهة القيود الفيزيائية لسعة الطاقة في مراكز البيانات التقليدية وسلاسل الإمداد، كشفت الشركة عن خطة معمارية أدت حتى الآن إلى نقل نُسخ من 99.99999% من مستودعاتها لتستقر بشكل مشترك بين مراكز بياناتها الخاصة وسحابة مايكروسوفت أزور (Microsoft Azure).

عائق التأخير وقفل المستودع الكامل

أوضحت جيت هاب أن المستودعات الأكثر استخداماً وتعديلاً على المنصة—والتي تمثل النسبة المتبقية الضئيلة (0.00001%)—كانت تقف أمام حاجز تقني يتمثل في زمن الاستجابة عبر الشبكة. فعند نقل البيانات إلى منطقة أزور المركزية في الولايات المتحدة (Central US)، والتي تبعد نحو ألف ميل عن مراكز بيانات المنصة، يضيف كل اتصال شبكي زمن تأخير يقارب 25 ميلي ثانية في رحلة الذهاب والإياب.

في المعمارية القديمة لنظام المزامنة والإجماع "سبوكس" (Spokes)، كانت أي عملية كتابة جديدة تتطلب فرض قفل شامل على مستوى المستودع بأكمله (Repository-wide lock) لحين استجابة النسخ المتطابقة (Replicas). وبسبب احتجاز القفل الشامل، أصبحت النسخة الأبطأ شبكياً هي التي تحدد زمن الاستجابة والسقف الأقصى لإنتاجية المستودع كاملة، مما تسبب في اختناق المستودعات النشطة التي تتلقى دفعات كود متكررة من المطورين والوكلاء الذكاء الاصطناعي.

الإجماع القائم على المراجع الفردية

لتجاوز هذا الاختناق، أعادت جيت هاب صياغة آلية الإجماع عبر تطبيق مبدئها المعماري الأول: "تقليل التنسيق وإلغاء القفل غير الضروري". وبدلاً من إغلاق المستودع بالكامل أثناء التحديث، أصبح نطاق الإجماع والقفل ينطبق حصرياً على المراجع الفردية (Per-reference serialization) مثل الفروع (Branches) أو الوسوم (Tags).

وبما أن معظم عمليات الكتابة المتزامنة التي ينفذها المطورون أو وكلاء الذكاء الاصطناعي تستهدف فروعاً مختلفة، فإن التعديلات لم تعد تنتظر بعضها البعض في طابور واحد. وأظهرت الاختبارات الداخلية التي أفرزتها الشركة تحت أحمال واقعية زيادة في قدرة استيعاب عمليات الكتابة بمقدار 3 إلى 4 أضعاف مع انخفاض ملحوظ في زمن التأخير.

فصل التخزين عن المعالجة وتعميم التخزين الكائني

تتضمن المرحلة الثانية تطبيق المبدأ المعماري الثاني: "فصل التخزين عن قدرات المعالجة" (Decoupling storage from compute). تتميز معظم مستودعات جيت بكثافة عمليات القراءة مقارنة بالكتابة، حيث تتراوح النسبة بين 100 إلى 1,000 عملية قراءة مقابل كل عملية كتابة واحدة. وفي المعمارية القديمة، كانت القراءة والكتابة تتنافسان على نفس الموارد والذاكرة.

لحل ذلك، أدرجت جيت هاب التخزين الكائني (Azure Blob Storage) كعضو افتراضي في مجلس الإجماع يُدعى "النسخة الافتراضية للكتابة" (Virtual Write Replica). وتعمل هذه النسخة كسلسلة عابرة تقوم بتجميع المعاملات وتدفق التعديلات باستدامة إلى التخزين السحابي. وبمجرد تأكيد التخزين، يمكن للمنصة إطلاق عدد غير محدود من نسخ القراءة الافتراضية (Virtual Read Replicas) القابلة للتوسع حسب الطلب، حيث تقوم هذه النسخ بتحديث ذاكرتها المؤقتة خلف الكواليس دون التأثير على سرعة كتابة البيانات أو المزامنة.

ما الذي يتغير عملياً لبنية تطوير البرمجيات؟

يعكس هذا التحول الهندسي في جيت هاب كيفية إعادة تصميم الأنظمة الموزعة الضخمة لتتحمل طبيعة العمل الآلي المعتمد على الذكاء الاصطناعي، ويمكن تلخيص أبرز الآثار العملية فيما يلي:

• رفع سقف الإنتاجية: تمكين وكلاء الذكاء الاصطناعي والمطورين من إجراء دفعات متزامنة مكثفة دون حدوث حظر (Lock) على المستودعات الكبرى.
• مرونة توسيع القراءة: إمكانية زيادة خوادم القراءة وتخصيص ذاكرة التخزين المؤقت لها بشكل مستقل دون الحاجة لخوض إجراءات الإجماع الثقيلة.
• استمرارية النظام الأساسي: تحديث المكونات الداخلية لنظام "سبوكس" الذي ينفذ أكثر من 100 مليار عملية يومياً دون الحاجة لإيقاف الخدمة أو التضحية بسلامة البيانات.