خلال العام الماضي، ومع النمو الهائل لحركة مرور Git، بدأت 99.99999% من مستودعات Git على GitHub بالوجود في مكانين في آن واحد: مراكز بيانات GitHub الخاصة وAzure. أما المستودعات المتبقية، وهي من بين الأكثر نشاطًا على المنصة، فيعيقها شيء واحد فقط: زمن انتقال ذهابًا وإيابًا يبلغ 25 مللي ثانية.
في منشور مدونة سابق، حددت GitHub مبدأين وراء بنية التخزين من الجيل التالي:
- تقليل التنسيق.
- فصل التخزين عن الحوسبة.
في هذا المنشور، ستنظر GitHub في الجسر الفوري بين تصميمها القديم والجديد. ستتحدث عن كيفية قيام تغيير في طريقة تسلسل النصاب لعمليات الكتابة بنقل المستودعات الأكثر نشاطًا إلى Azure، وكيف تفتح هذه الخطوة نفسها الباب أمام النسخ المتماثلة التي لا تحتفظ بحالة دائمة خاصة بها.
كيف وصلت GitHub إلى هنا؟
كان توقيت وشكل هذه الخطوة مدفوعين بالتحول نحو الوكلاء: النمو السريع لحركة المرور، والسقف الصارم لقدرة الطاقة في مراكز بيانات GitHub والمنطقة الجغرافية المحيطة، وقيود سلسلة التوريد المادية. في بداية عملية الترحيل، منحت السعة المتبقية مع جميع التوسعات الممكنة وقتًا كافيًا للترحيل بأمان، ولكن ليس ببطء.
بينما كانت GitHub قد قامت بوضع نماذج أولية لأساليب معمارية جديدة لتوسيع نطاق Git على البنية التحتية السحابية، فإن تغيير بنية التخزين ومنصة الاستضافة في نفس الوقت، تحت هذا النمو، كان ينطوي على مخاطر كبيرة. نظرًا لحجم GitHub ومدى أهمية الخدمة للمجتمع، كانت هناك حاجة لتسلسل العمل بعناية: نقل البيانات أولاً، ثم تطوير البنية بمجرد وصولها.
تُعد عمليات Git خدمة من المستوى صفر (Tier 0): إنها وظيفة أساسية لـ GitHub، وكل شيء تقريبًا في GitHub يعتمد على بيانات المستودع. وهذا يعني أن البيانات والخدمات وكل تبعية كان يجب أن تنتقل أولاً. وصلت النسخة الأولى من المستودع إلى منطقة وسط الولايات المتحدة في Azure في أغسطس 2025. اليوم، تحتوي معظم المستودعات على نسختين من أصل خمس نسخ متماثلة في Azure، وتخدم Azure حوالي نصف حركة مرور Git. خلال معظم تلك الفترة، استوعبت Azure نمو GitHub بينما ظلت مراكز بياناتها الخاصة مستقرة.
أثناء الترحيل، تتبع حركة المرور البيانات. تحتوي معظم المستودعات على خمس نسخ متماثلة لتحقيق التوازن بين المتانة والتوافر وقابلية التوسع. لتقليل زمن انتقال القراءة، يستخدم Spokes التوجيه التفضيلي لتوجيه حركة المرور إلى نسخة متماثلة في نفس المنطقة ونطاق التوفر مثل الطلب. ومع انتقال النسخ المتماثلة إلى Azure، تزداد حصة حركة المرور التي يمكن خدمتها من Azure مع كل واحدة، حتى تصل النسخة المتماثلة الأخيرة وتتوقف المنطقة القديمة عن تلقي الطلبات بالكامل. يمر كل مستودع بهذه العملية.
ماذا عن المستودعات المتبقية؟
ماذا عن الـ 0.00001% المتبقية من المستودعات؟
في البنية الحالية، المستودع المستضاف في أكثر من منطقة لديه سقف أقل لإنتاجية الكتابة. يحتاج نصاب Spokes فقط إلى أغلبية لتأكيد عملية كتابة، لكنه ينتظر استجابة كل نسخة متماثلة سليمة (حتى انتهاء المهلة) قبل المتابعة، لذا فإن النسخ المتماثلة البطيئة تؤخر كل عملية كتابة بدلاً من التأخر. عمليًا، هذا يعني أن أبطأ نسخة متماثلة سليمة تحدد زمن انتقال كل عملية كتابة، ولأن كل عملية كتابة تحتفظ بقفل على مستوى المستودع حتى يتم تأكيدها، فإنها تحدد أيضًا سقف الإنتاجية. بمجرد أن توجد نسخة متماثلة في منطقة Azure المستهدفة، تكون على بعد حوالي 1000 ميل من مراكز بيانات GitHub، مما يجعل كل رحلة شبكة ذهابًا وإيابًا حوالي 25 مللي ثانية، وتتطلب عملية الكتابة عدة رحلات ذهابًا وإيابًا. لا يمكن للمستودع الذي يقترب بالفعل من سقف إنتاجيته استيعاب ذلك في كل عملية كتابة متسلسلة؛ سيتأخر أكثر مع كل عملية دفع.
هنا يأتي دور المبدأ الأول لـ GitHub، وهو تقليل التنسيق. وبالتحديد لهذه الحالة: لا تسلسل ما لا يحتاج إلى التسلسل. تنطبق متطلبات اتساق Git على كل مرجع على حدة. ينطبق هذا سواء كان التحديث تقدمًا سريعًا، أو دفعًا إجباريًا، أو حذفًا. ولكن في معظم الحالات، لا تعتمد التحديثات لمرجعيات مختلفة على بعضها البعض ويمكن تطبيقها بشكل مستقل.
لذلك، تقوم GitHub بتغيير نطاق النصاب من المستودع بأكمله إلى المرجعيات الفردية.
إن الاحتفاظ بقفل على مستوى المستودع لتحديث المرجع بالكامل، بما في ذلك الرحلات ذهابًا وإيابًا، يحول النصاب إلى قائمة طلبات فردية غير مرتبة مع عملية كتابة واحدة قيد التنفيذ في كل مرة. تستغرق كل عملية كتابة في تلك القائمة وقتًا طويلاً مثل أبطأ نسخة متماثلة سليمة. ومع نمو معدل الكتابة، تنمو القائمة أيضًا، وتنتظر كل عملية كتابة وقتًا أطول من سابقتها.
مع التسلسل لكل مرجع، يجب أن تنتظر عمليات الكتابة التي تتنافس على مرجع مشترك فقط بعضها البعض. عمليًا، تلمس معظم عمليات الكتابة إلى المستودع مرجعيات مختلفة — على سبيل المثال، الوكلاء والمطورون الذين يدفعون إلى فروعهم الخاصة — لذلك لم تعد تنتظر بعضها البعض. لا تزال كل عملية كتابة تشهد زمن انتقال عبر المناطق، ولكن يمكن أن تكون عمليات الكتابة إلى مرجعيات مختلفة قيد التنفيذ في نفس الوقت. وهذا يزيل عنق الزجاجة الوحيد في المستودع. يمكن تصور كيفية تراكم قوائم الانتظار والمهلات بمقارنة النهجين جنبًا إلى جنب تحت حمل مماثل.
تزيد هذه التغييرات من سقف إنتاجية الكتابة للمستودع تقريبًا بما يتناسب مع عدد المرجعيات التي يتم الكتابة إليها في وقت واحد، وتدخل المستودعات المتبقية الأخيرة إلى Azure. في الاختبارات الداخلية بحركة مرور واقعية، شهدت عمليات الكتابة إلى مرجعيات مختلفة باستمرار إنتاجية أعلى بمقدار 3-4 أضعاف بزمن انتقال أقل.
كيف يمكن توسيع نطاق عمليات القراءة بشكل مستقل؟
معظم المستودعات منحرفة بشدة نحو القراءة، حيث تتراوح نسبة القراءات إلى الكتابات بين 100 و 1000 قراءة لكل عملية كتابة. اليوم، تصل عمليات القراءة والكتابة إلى نفس النسخ المتماثلة، لذا فهي تتنافس على نفس الموارد ولا يمكن توسيع نطاقها بشكل مستقل.
يغير فصل التخزين عن الحوسبة ذلك. بمجرد تخزين بيانات المستودع بشكل دائم في Azure Blob Storage وتحديثها مع كل عملية كتابة واردة، يمكن البدء في فصل حركة مرور القراءة عن نصاب الكتابة، وتوسيع نطاق الحوسبة اللازمة لكل منهما بشكل مستقل. على سبيل المثال، ستستفيد عمليات القراءة من ذاكرة تخزين مؤقت أكبر بكثير مما يتم توفيره لها اليوم، ولكن هذه الذاكرة مطلوبة أيضًا للضغط. بمجرد فصلهما، يحصل كل منهما على تكوينه الخاص.
الخطوة الأولى هي جعل تخزين الكائنات عضوًا في النصاب، ولكنه عضو خاص يسمى نسخة متماثلة افتراضية. الحوسبة التي تمثلها هي أول عقدة مؤقتة بالكامل. تعمل كجسر لتخزين الكائنات، حيث تقوم ببث عمليات الكتابة الواردة ولا تخدم أي قراءات. ولأنها عضو في النصاب، لا يتم الإقرار بعملية الكتابة حتى تصبح دائمة في تخزين الكائنات.
يضيف ذلك القليل من زمن الانتقال إلى كل عملية كتابة، ولكن تمامًا مثل الرحلة ذهابًا وإيابًا عبر المناطق، فإن التسلسل لكل مرجع يمنعه من أن يصبح عنق زجاجة في الإنتاجية. تجمع النسخة المتماثلة الافتراضية للكتابة أيضًا المعاملات على المرجعيات المنفصلة في مجموعة واحدة من عمليات الإدخال/الإخراج للشبكة إلى تخزين الكائنات، لذا فإن المستودع المزدحم يدفع ثمن رحلة ذهابًا وإيابًا واحدة عبر العديد من عمليات الكتابة المتزامنة بدلاً من واحدة لكل عملية كتابة. في الوقت الحالي، تتعامل النسخة المتماثلة الافتراضية للكتابة أيضًا مع الضغط، وترث النسخ المتماثلة للقراءة الحالة المضغوطة.
مع وجود النسخة المتماثلة الافتراضية للكتابة، يمكن توسيع نطاق العديد من النسخ المتماثلة الافتراضية للقراءة حسب حاجة المستودع، عند الطلب. تقوم كل نسخة متماثلة للقراءة بتسخين ذاكرة التخزين المؤقت الخاصة بها من Azure Blob Storage وتبدأ في استقبال حركة مرور القراءة دون الانضمام إلى النصاب، باستخدام تخزين الكائنات كمصدر للحقيقة ومطابقة حالتها المحلية معه في الخلفية.
تفتح هذه الخطوة نطاقًا كبيرًا للقراءة. في الاختبارات الداخلية، وجدت أداة اختبار التحميل الموزعة لـ GitHub باستمرار سقوفًا في البنية الحالية. مقابل النسخ المتماثلة الافتراضية للقراءة، وصلت الأداة إلى حدودها أولاً. كما أنها تأتي مع بعض التحديات التي يتم حلها في الخطوات اللاحقة:
- تبدأ النسخ المتماثلة الافتراضية للقراءة في المطابقة مع تخزين الكائنات في الخلفية، مما يجعلها مناسبة لبعض أعباء عمل القراءة ولكن ليس كلها. تتطلب خدمة كل نوع من أنواع القراءة نقل هذه المطابقة بشكل مباشر، وجلب حالة المرجع والبيانات التي تغيرت فقط منذ آخر تحديث للنسخة المتماثلة.
- بينما زادت GitHub إنتاجية الكتابة تدريجيًا عن طريق التحول إلى نموذج لكل مرجع، يظل النصاب هو العامل المحدد لزيادة الإنتاجية بشكل أكبر.
ما الذي يأتي بعد ذلك؟
تم بناء GitHub اليوم على نصاب Spokes، وعلى مر السنين أصبح Spokes أكثر بكثير من مجرد منسق نصاب.
الغالبية العظمى مما يقع تحت مظلة خدمة Spokes ينطبق بنفس القدر على البنية الجديدة كما ينطبق على البنية الحالية. لكن GitHub تدرك أيضًا أن بروتوكول الالتزام الذي أوصل GitHub إلى مليار مستودع لن يوصلها إلى المليار التالي وما بعده.
لم تنته GitHub بعد. مع هذه الخطوات، فإن الحد التالي هو إنتاجية الكتابة. لا تزال كل عملية كتابة تنتظر النسخ المتماثلة التي تحتفظ كل منها بنسخة كاملة من المستودع، ومع ذلك فإن جزءًا صغيرًا جدًا من عملية الكتابة يحتاج بالفعل إلى الترتيب. كائنات Git غير قابلة للتغيير ويتم تسميتها بمحتوياتها، لذلك يمكن تخزينها دون اتفاق أي شخص عليها. ما تبقى صغير، والجزء الصعب هو ترتيبه بأسرع ما يمكن دون نقل عنق الزجاجة إلى مكان آخر. تصميم ذلك على لوح أبيض شيء. القيام بذلك تحت مليار مستودع يكتب إليها المطورون والوكلاء على مدار الساعة شيء آخر. الوصول إلى هناك أجبر GitHub على إعادة التفكير في التأثيرات من الدرجة الثانية أيضًا، مثل مكان وجود حالة المرجع الدائمة وكيفية توسيع نطاق الضغط وجمع البيانات المهملة.
حركة مرور الوكلاء لا تتباطأ، وكل من هذه الخطوات تمنح المستودعات مساحة أكبر مع وصولها، دون انتظار الحالة النهائية.
يأتي الأسبوع المقبل: في GitHub Universe وفي المنشور الأخير من هذه السلسلة، ستأخذ GitHub جولة في تلك الحالة النهائية، وما تفعله لإنتاجية الكتابة، والمشكلات من الدرجة الثانية التي كان عليها حلها للوصول إلى هناك، ولماذا لا تزال هناك مجموعة توافق (صغيرة) في مكان ما في المكدس.
شكرًا لـ Brian Celenza على مساهماتهم في هذا المنشور.
جرّب الأداة: مولد التجزئة والتحقق من سلامة الملفات
