كيف حافظت OpenAI على استقرار Azure Cosmos DB تحت حمل مليار مستخدم لـ ChatGPT

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

مشكلة القاعدة المشتركة و"الجيران الصاخبين"

في البداية، كانت جميع المنتجات تكتب بياناتها في قاعدة بيانات (حاوية) Cosmos DB مشتركة واحدة. لكل مفتاح — مثل معرّف المستخدم — حد أقصى يبلغ 10 آلاف عملية في الثانية، لكن من الناحية العملية لا يُطبّق هذا الحد على المفتاح نفسه، بل على القسم الفعلي من القرص الذي يُخزَّن فيه هذا المفتاح مع مفاتيح أخرى. وقد تسبب هذا في مشكلتين:

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

كما اكتُشفت مشكلة إضافية تتعلق بـ"الأقسام الضعيفة": عندما يكبر قسم القرص وتقسمه Cosmos DB إلى اثنين، كانت سعة النقل لكل منهما تنخفض إلى النصف — أي أن نمو حجم البيانات نفسه كان يقلل السرعة، حتى دون زيادة عدد الطلبات.

العزل عبر قواعد بيانات منفصلة — وتكلفته

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

• كان على فرق المنتجات أن تطلب مسبقًا سعة النقل اللازمة للإطلاق بنفسها — وكانت كثيرًا ما تنسى ذلك، مما جعل الإطلاقات تترافق مع اجتماعات طوارئ لتوسيع النطاق في اللحظات الأخيرة.
• حمل كان سيكون غير ملحوظ في قاعدة بيانات مشتركة (الزيادة من 1000 إلى مليون طلب في الثانية تمثل فقط 5% من السعة الكلية) أصبح في قاعدة منفصلة يمثل تجاوزًا بمقدار ألف مرة عن الموارد المخطط لها.
• انتشر تخطيط السعة في الشركة بأكملها بدلًا من أن يكون مركزيًا في فريق واحد، وتفاوتت جودة هذا التخطيط بشكل كبير من فريق إلى آخر.

العودة إلى القاعدة المشتركة — لكن مع توازن ذكي

بعد أن أدرك فريق Habitat أن أيًا من النهجين لا يمكن توسيعه تنظيميًا، أعاد هو وفرق مهندسي Microsoft تطوير آلية Cosmos DB نفسها:

• أضافوا تحديدًا لأكثر المفاتيح "سخونة" على رأس الأولوية، بحيث لا يتمكن عميل واحد عدواني من الاستحواذ على كل سعة النقل لقسم معين.
• أدخلوا ترتيب أولوية للطلبات (QoS): فمهام الخلفية مثل عمليات التصدير الجماعي للبيانات يتم تقليصها أولًا، بينما تُترك طلبات المستخدمين التفاعلية للأخير.
• طوّروا بالتعاون مع Azure وضع Cosmos DB بدون خادم (serverless)، الذي رفع الحد من 5 آلاف إلى 10 آلاف عملية في الثانية لكل قسم، وأضاف تقسيمًا تلقائيًا بناءً على الحمل، لا على حجم البيانات فقط.

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

هندسة مشتركة مع Microsoft

أكبر حساب لدى OpenAI في Cosmos DB يخزّن عشرات البيتابايت ويستقبل أكثر من 20 مليون طلب في الثانية — ويصفه الكاتبان بأنه أكبر استخدام معروف لهذه الخدمة. وعلى هذا المستوى من الحجم، يتوقف الدعم التقني النموذجي لمزود الخدمة السحابية عن العمل بفعالية: في نهاية عام 2024، أظهر عطل في الطاقة في منطقة ما أن التبديل إلى منطقة احتياطية لحسابات بهذا الحجم يستغرق عدة ساعات — وهو أمر لم يُختبر من قبل بهذا الحجم. وبعد شهر، عند التبديل العكسي، حدث عطل ثانٍ: تدفّق العملاء بشكل جماعي لإعادة الاتصال بالمنطقة الأصلية وأثقلوا بوابتها، بينما لم يكن قد عاد إليها إلا جزء من البيانات.

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

الاستنتاج الرئيسي لفرق الهندسة: الأنظمة المتعددة المستخدمين (المشتركة) أقل تكلفة وأسهل في التشغيل، لكنها تتطلب آليات عزل مدمجة من مزود الخدمة نفسه — وبدونها، يصبح البديل الوحيد هو التقسيم اليدوي إلى قواعد بيانات منفصلة، وهو ما يكتفي بنقل مشكلة تخطيط السعة إلى عشرات الفرق.