توسيع التخزين المتصل بسرعة لخدمة أكثر من مليار مستخدم لـChatGPT

تعتمد جميع منتجات OpenAI على الوصول السريع والموثوق إلى البيانات، سواء عند تسجيل الدخول أو مراجعة إعدادات Codex أو بدء محادثة جديدة في ChatGPT. قد يتطلب كل إجراء من هذه الإجراءات عمليات بحث مستقلة كثيرة في البيانات قبل أن يتمكن المنتج من الاستجابة. إذا كانت هذه الطلبات بطيئة، بدا المنتج بطيئًا. وإذا فشلت، توقف المنتج تمامًا عن العمل.

Habitat هي منصة التخزين المتصل التي بنيناها لتمكين منتجات OpenAI من الوصول بسرعة وموثوقية إلى المعلومات المطلوبة. تعالج Habitat الآن أكثر من 70 مليون طلب كل ثانية، وتدعم منتجات يستخدمها أكثر من مليار شخص أسبوعيًا في قرابة 40 منطقة جغرافية. أُطلقت Habitat أول مرة لدعم GPTs في DevDay 2023، وبدأت كمكتبة Python بسيطة لدى العميل ومتّصلة بقاعدة بيانات واحدة. وهي اليوم نظام موزع معقد يخدم أكثر من 500 بيتابايت من البيانات.

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

مع نمو OpenAI، كان على Habitat أن تنمو معها: أولًا لتصبح موثوقة بما يكفي لحركة المنتجات بالغة الأهمية، ثم سريعة بما يكفي للمستخدمين حول العالم، وأخيرًا لتعمل ببراعة على نطاق هائل. هذه التدوينة هي الأولى في سلسلة من جزأين حول كيفية توسيع التخزين المتصل. سنشرح في هذه التدوينة كيف تطورت Habitat، ولماذا حوّلناها من مكتبة إلى خدمة، وكيف وسّعنا خدمة مكتوبة بلغة غير شائعة في مجموعات تقنيات تقديم الخدمات، وهي Python، لتصبح طبقة منصة تخزين موثوقة.

وفي تدوينة لاحقة، سنشرح بالتفصيل كيف حققنا موثوقية تعدد المستأجرين على نطاق واسع، واستراتيجيتنا متعددة الطبقات لتحسين أداء القراءة، وكيف وسّعنا شراكتنا مع Azure Cosmos DB لتلبية طلب غير مسبوق بموثوقية.

انطلقت Habitat من فكرة بسيطة: ينبغي ألا يضطر مهندسو المنتجات إلى التفكير في إدارة قواعد البيانات. أُطلقت Habitat أول مرة لدعم GPTs في DevDay 2023 كمكتبة Python صغيرة تتفاعل مع خادم ChatGPT الرئيسي. كانت تدعم مجموعة صغيرة من العمليات التي ترتبط خلف الكواليس بتطبيق قاعدة البيانات Azure Cosmos DB.

كانت مهمة المكتبة منح فرق المنتجات طريقة بسيطة لتخزين البيانات واستردادها دون الحاجة إلى إتقان التفاصيل الأساسية. تولت Habitat العمل اللازم: تحديد نوع البيانات المعنية، ومن أين تأتي أو إلى أين تذهب، وما إذا كان الطلب مسموحًا، وغير ذلك.

لم يكن على مهندسي المنتجات الانشغال بالبحث في المخطط أو التوجيه أو التخويل أو التشفير أو التسلسل أو تشكيل الطلبات أو تجميع الاتصالات. ولم يكونوا بحاجة حتى إلى التفكير في مصدر البيانات، سواء كان Azure Cosmos DB أو ذاكرات التخزين المؤقت أو أنواع تخزين أخرى.

أثبتت مكتبة Python هذه نجاحها، وانتشر استخدام Habitat سريعًا بين مهندسي المنتجات في OpenAI، رغم عدم وجود توجه مركزي منظم للابتعاد عن Postgres وAzure Cosmos DB ذاتيي الخدمة.

ومع تطور احتياجات المنتجات، كان من السهل على المطورين إضافة دعم ميزات مثل التخزين المؤقت لدى العميل أو الضغط أو التشفير إلى المكتبة المشتركة.

بحلول منتصف عام 2025، بلغت Habitat حدود إمكاناتها كتطبيق يعمل لدى العميل. مع ازدياد تعقيد طبقة Habitat وارتفاع عدد خدمات OpenAI، أصبحت تغييرات البروتوكول المتوافقة مع الإصدارات السابقة غير عملية.

في إحدى الحالات، أردنا تقليص نطاق تأثير أي انقطاع في منطقة واحدة على مجموعات بياناتنا الأهم، وذلك بنقلها إلى مجموعة من حسابات Azure Cosmos DB الموزعة إقليميًا. تطلّب هذا التغيير إضافة منطق توجيه إلى العميل مع تعطيله خلف علامة ميزة، وضمان نشره لدى جميع العملاء، ثم تفعيل العلامة.

استغرق تنسيق عمليات النشر عبر عشرات الخدمات والعمل مع كل فريق لإتمامها أيامًا. وقبل التفعيل، أدركنا أننا نريد نسخ بعض الطلبات احتياطيًا للتأكد من صحة منطق التقسيم. واستغرق نشر ذلك يومين آخرين. وإصلاح خطأ أدركنا وجوده؟ يومان آخران. في النهاية أصبحنا جاهزين لتفعيل العلامة، لكن أحد الفرق أعاد خدمته لأسباب غير مرتبطة إلى إصدار سابق من العميل يحوي خطأ، فتسبب في الانقطاع الذي بذلنا جهدًا كبيرًا لتجنبه.

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

بفصل منطق التخزين في خدمة مستقلة، أنشأنا نقطة تحكم واحدة لعمليات النشر وقابلية الرصد وتحسينات المنصة. وبدلًا من إدارة تحديثات متفرقة، أصبح بإمكاننا تنفيذ التحسينات مركزيًا لتستفيد منها جميع منتجات OpenAI فورًا.

توفر لنا الخدمة المركزية أيضًا نقطة تحكم واحدة لتقديم أقوى الركائز الأساسية لأمن البيانات وخصوصيتها. خدمة Habitat هي المكان الذي يمكننا فيه فرض سياسات التحكم في الوصول مركزيًا، وتسجيل عمليات التدقيق، وتقييد الوصول إلى موارد التخزين الأساسية مثل Azure Cosmos DB. تؤدي Habitat دورًا حاسمًا في حماية بيانات المستخدمين ومنع الوصول غير المصرح به من جهات خارجية أو داخلية أو وكلاء.

كنا نعلم أننا بحاجة إلى خدمة، لكننا لم نرغب بعد في الانتقال من Python، رغم الأعباء الإضافية لتشغيلها كخدمة. أدى استخدام Python في خدمة عالية الإنتاجية إلى زيادة زمن استجابة الشبكة وإضافة تكاليف كبيرة لتوسيع موارد CPU والذاكرة مقارنة بتشغيل المكتبة محليًا. كما أدركنا أن أوجه القصور في Python لن تكون مقبولة عند بلوغ مئة ضعف من الحجم، ما جعل إعادة الكتابة لاحقًا شبه مؤكدة.

ومع ذلك، رأينا في ذلك تحمّلًا استراتيجيًا للدين التقني. لم يكن هدفنا الأساسي آنذاك تحسين التكلفة أو الموارد، بل تمكين مطوري المنتجات من المضي قدمًا وتحقيق استقرار المنصة. وبقبول مقايضات أداء خدمة Python على المدى القصير، استطعنا إعطاء الأولوية لتحديات أكثر إلحاحًا، وترسيخ واجهات API الأساسية، وبناء بنية تحتية متينة.

وراهنّا بحساب أيضًا على أن التطور السريع لنماذج البرمجة لدينا سيبسّط المسار التقني مستقبلًا. راهنّا على أن Codex وGPT سيجعلان الانتقال الكامل من Python ممكنًا عندما يحين وقته. وقد ثبت لاحقًا أن رهاننا كان صائبًا.

لم يكن تشغيل Habitat كخدمة Python مثاليًا من حيث الأداء، لكنه كان خيارًا ضروريًا. تتيح لنا Python التحرك بسرعة، لكن ذلك لا يعني تجاهل الحذر وقبول أزمنة استجابة أسوأ بكثير. عندما يؤدي طلب المستخدم العادي إلى مئات استدعاءات قاعدة البيانات، يشعر المستخدم بأبطأ استدعاء منها. وجدنا أن التحدي الأساسي في تشغيل خدمة Python بهذا الحجم هو إدارة أزمنة الاستجابة الطرفية.

تساعد asyncio لغة Python على تنفيذ أعباء العمل المقيدة بعمليات الإدخال والإخراج بالتزامن، لكنها لا تتجاوز قفل GIL في Python ولا توفر توازي CPU. إلى جانب تمرير الطلبات كثيفة الإدخال والإخراج، تتولى Habitat العديد من المهام كثيفة CPU والمهام الخلفية: التوجيه والضغط والتشفير وحساب المجاميع الاختبارية وفحص سلامة الخدمات التابعة ونسخ الطلبات احتياطيًا والتحوط.

مع كثرة أعباء CPU والمهام الخلفية في خدمتنا، يمكن لتأخير جدولة asyncio أن يهيمن بسهولة على زمن الاستجابة الطرفي للطلبات. قبل ضبط الخدمة لإطلاقها الأولي، أظهرت تتبعات الطلبات ذات زمن الاستجابة عند p99 وما فوق أن التخزين التابع كان يستجيب بسرعة، لكن الطلبات كثيرًا ما كانت تتوقف بانتظار إعادة جدولة الروتين التعاوني المسؤول لتحليل الاستجابة.

في خدمات Python لدى OpenAI، وجدنا أنه إلى جانب قياس مؤشرات الاستخدام والتشبع المعتادة للذاكرة وCPU والشبكة والقرص، من الضروري مراقبة حلقة asyncio ومدى انشغالها ثم ضبطها وفقًا لذلك.

من خلال جدولة المهام الخلفية دوريًا وتسجيل الفارق بين وقت التنفيذ المتوقع والفعلي، يمكننا قياس تأخير جدولة حلقة الأحداث تجريبيًا وفي الوقت الفعلي. عند الاستخدام المرتفع ومع كثرة المهام المكلفة، يكفي عدد متواضع من الطلبات المتزامنة لكل عملية لإحداث تذبذب ملحوظ في الجدولة، يصل إلى مئات المللي ثانية وإلى عدة ثوانٍ في بعض الحالات القصوى.

لذلك نُبقي كل عملية مخصصة لخدمة عدد قليل من الطلبات المتزامنة، ونوسّع بدلًا من ذلك عدد عمليات Python العاملة بدرجة كبيرة.

خلال إطلاق خدمتنا الأول، كشف تحليل CPU الحي للخدمة أحد الأسباب الجذرية لارتفاع تأخير asyncio وما نتج عنه من ارتفاع أزمنة الاستجابة الطرفية: التحليل الدوري لإعدادات علامات الميزات بصيغة JSON عبر Statsig، وهي أداة لإدارة علامات الميزات وإجراء اختبارات A/B وغيرها.

افتراضيًا، كانت Statsig مضبوطة لاستقصاء الإعدادات المحدّثة كل دقيقة بلا تذبذب، وكانت الإعدادات تشمل جميع قواعد الإنتاج في كل خدمة. وفي موضع آخر، اتُخذ قرار معماري بتشغيل ما يصل إلى 8 عمليات Python في كل وحدة Pod لرفع استخدام CPU وخفض أزمنة الاستجابة. عند جمع ذلك كله، كانت كل وحدة Pod تشهد في كل دقيقة لحظة تتوقف فيها جميع عملياتها العاملة عن معالجة الطلبات الجارية، لتنفق دورات CPU بدلًا من ذلك على تحليل ملف إعدادات ضخم.

كان الحل مباشرًا بعد أن ساعدنا تحليل CPU على تحديد السبب الجذري: نشر إعدادات أصغر وموجّهة، وإطالة فترة التحديث، وإضافة بعض التذبذب إلى مثل هذه المهام الخلفية.

للحفاظ على انخفاض تأخير asyncio، من الضروري أيضًا موازنة أحمال الطلبات جيدًا بين عمليات الخادم؛ فقد يعمل تجميع الاتصالات ضد هذا الهدف إن لم يُضبط جيدًا.

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

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

شككنا في مجموعة الاتصالات واختبرنا ذلك بوضع حد أقصى لمدة إعادة استخدام الاتصال، ما حدّ بالفعل من التدهور وأكد صحة مسار تحقيقنا. كشف المزيد من التحقيق أن TCPConnector في aiohttp بلغة Python يستخدم افتراضيًا إعادة الاتصالات بنمط LIFO: يُختار أحدث اتصال عاد للطلب التالي. وهذا إعداد افتراضي معقول عادة؛ فإعادة استخدام الاتصالات الحديثة تتيح للاتصالات الإضافية المنشأة لمعالجة التدفقات المفاجئة أن تنتهي مهلتها وهي خاملة، ما يقلل عبء الاحتفاظ بها. لكنها أحدثت لدينا إخفاقًا شبه مستقر في هذه الحالة. أثناء تدفق مفاجئ للطلبات، أعادت الطلبات الموجهة إلى الخوادم الأبطأ والمحملة فوق طاقتها الاتصالات إلى المجموعة لاحقًا، فاختارتها الطلبات اللاحقة بوتيرة أعلى وركزت تدريجيًا مزيدًا من الحركة على وحدات Pod المتعثرة في الأساس. كسر تعديل مجموعة الاتصالات لاستخدام نمط FIFO حلقة الملاحظات هذه، بل خفّض أيضًا تفاوت الطلبات في حالة الاستقرار.

نعتمد اليوم في الغالب على Istio وEnvoy لتجميع الاتصالات وتقديم استراتيجيات موازنة أكثر وعيًا بأحمال الخوادم في بنية OpenAI التحتية، وبذلك نتجنب المشكلة تمامًا.

من الآثار الجانبية للضبط بهدف خفض تأخير asyncio ووجود هذا العدد الكبير من عمليات Python أن إغراق الاعتماديات التابعة بالعدد الهائل من الاتصالات يصبح سهلًا جدًا، وهي ظاهرة تُعرف باسم «القطيع الهادر».

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

نعتمد أيضًا على Envoy لزيادة تجميع اتصالاتنا الواردة إلى أقصى حد. نستخدمه لترقية اتصالات HTTP/1 في Python إلى HTTP/2 للاستفادة من تعدد الإرسال، ثم لتجميع تلك الاتصالات وإطالة عمرها. يمنحنا Envoy أيضًا موضعًا مركزيًا لتطبيق حدود المعدل وقواطع الدوائر، التي ستكون أقل فاعلية داخل كل عملية Python مستقلة.

من أسباب قدرتنا على توسيع Python إلى هذا الحد واجهة API المقيّدة في Habitat، التي تُبقي تكلفة الطلبات قابلة للتوقع. بدلًا من السماح للعملاء بإنشاء استعلامات SQL اعتباطية قد تؤدي إلى مسح جداول ضخمة أو ربط جداول كثيرة، توفر Habitat واجهة API بسيطة بتقنية NoSQL. يُعد غياب واجهة API قوية مقايضة مقصودة في تصميم Habitat.

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

قبل انتقالنا إلى Habitat وAzure Cosmos DB، كانت معظم بيانات OpenAI المتصلة بالإنترنت مخزنة في Postgres. كان من السهل آنذاك مراجعة جميع تغييرات الاستعلامات والمخططات للتأكد من حسن سلوكها وعملها على بيانات مفهرسة قبل نشرها في الإنتاج. ومع نمو الفريق والمنتجات، سرعان ما تعذرت إدارة ذلك وأصبح سببًا متكررًا للانقطاعات، إذ كان استعلام جديد واحد مكلف على مسار نشط كفيلًا بإسقاط قاعدة البيانات.

تكمن المشكلة هنا في اختلال التكلفة: فكتابة استعلامات SQL مكلفة وصعبة التشغيل أمر رخيص وسهل. نتجنب ذلك في Habitat ونجعل الاستعلامات المكلفة واضحة للغاية من جهة العميل. لا توجد استعلامات غير محدودة يمكنها إثقال Habitat، كما تتطلب عمليات الربط المعقدة واجتياز الرسوم البيانية من فرق المنتجات تحمل بعض العمل الشاق، ما يساعد عمومًا على تحسين التصاميم لتكون أكفأ.

توفر Habitat واجهة NoSQL API مصممة حول أنواع الكائنات والحواف التي يحددها العميل، ومستوحاة من TAO⁠(يفتح في نافذة جديدة). يعرّف العملاء مسبقًا الكائنات والحواف وعلاقاتها ببعضها، لكن ليس محتوى كل نوع. تشبه العلاقات الناتجة رسمًا بيانيًا، لكن Habitat نفسها لا تدعم استعلامات الاجتياز المعتادة خارج نطاق الاستعلام عن الحواف المباشرة لكائن محدد.

نقسّم هذا الرسم بحيث يوجد كل كائن وحوافه المقابلة معًا في قسم على مستوى التخزين، لكننا لا نبذل جهدًا منظمًا على مستوى قاعدة البيانات لجمع الكائنات مع الكائنات البعيدة التي تشير إليها حوافها. والنتيجة أن النموذج يُقسّم بسهولة لتحقيق قابلية التوسع الأفقي، لكن اجتياز الرسم غير كفء لأن أي انتقال بين كائنين قد يتطلب الجلب من حسابين مختلفين تمامًا في Azure Cosmos DB ومخزنين في منطقتين مختلفتين.

وللعملاء ذوي احتياجات الاستعلام الأكثر تعقيدًا، نوفر عرضًا ثانويًا غير متصل لبيانات Habitat عبر Rockset. نستخدم التقاط تغييرات البيانات (CDC) لبث التغييرات من التخزين المتصل إلى مثيلات Rockset معزولة في وقت شبه حقيقي. يتحمل كل فريق عميل مسؤولية توسيع مثيل Rockset الخاص به لتلبية احتياجاته من الاستعلامات المعقدة.

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

أتاح لنا تأجيل إعادة كتابة Python عامًا التركيز على تحديات أكثر إلحاحًا وتأثيرًا خلال نمونا الفائق. مع نضج المنصة واستمرار تسارع نمونا، وبعد أن أصبحت الخدمة الثانية لدى OpenAI من حيث عدد الأنوية والرابعة من حيث انتشار Envoy، حان أخيرًا وقت تجاوز Python. في ذروتها، ساعدتنا Python على خدمة أكثر من 20 مليون طلب كل ثانية.

في الربع الثاني من 2026، تمكنا بمهندسين اثنين فقط وبمساعدة Codex وGPT‑5.5 من إعادة كتابة الخدمة بالكامل بلغة Rust. تعالج خدمة Rust الجديدة الآن 95% من طلبات الإنتاج، وسنتوقف تمامًا عن استخدام Python خلال الأسابيع المقبلة. تُظهر بياناتنا أن خدمة Rust أكفأ في استخدام CPU بست مرات وفي استخدام الذاكرة بخمس عشرة مرة من إصدار Python، مع انخفاض كبير في متوسط زمن الاستجابة وزمنه الطرفي. نخطط لمشاركة المزيد من الدروس في تدوينة مقبلة.

خدمة Python، ثم Rust الآن، ليست سوى جانب واحد من Habitat. في الجزء الثاني من هذه السلسلة التي تشرح كيف وسّعنا تخزيننا المتصل بسرعة لخدمة أكثر من مليار مستخدم لـChatGPT، سنتناول طبقة التخزين وكيف تخدم Habitat أكثر من 500 بيتابايت وأكثر من 70 مليون طلب كل ثانية.

إذا أردت العمل على أنظمة OLTP بنطاق رائد وكنت مهتمًا بهذا النوع من الهندسة، فاطّلع على هذه الوظيفة الشاغرة ضمن فريقنا⁠.