OpenAI تعيد بناء مخزن Habitat: 500 بيتابايت من البيانات و1 مليار مستخدم على Cosmos DB

تخدم منصة Habitat، التي تقوم عليها خدمات ChatGPT وAPI وCodex والخدمات الداخلية في OpenAI، أكثر من 1 مليار مستخدم في 40 منطقة جغرافية، وتخزّن ما يزيد على 500 بيتابايت من البيانات. ويجب أن تأتي الاستجابة خلال أجزاء من الثانية (بالميلي ثانية). في الجزء الثاني من التحليل الهندسي، روى Jon Lee وHrachya Hakobyan وChaomin Yu كيف استخلص الفريق أقصى ما يمكن من Azure Cosmos DB، ومرّ بثلاثة نماذج لتعدد المستأجرين، ثم عاد في النهاية إلى حاوية مشتركة واحدة.

المرحلة الأولى: حاوية مشتركة وثلاث مشكلات نظامية

في البداية، قبلت OpenAI أي حِمل من العملاء، واعتمدت على الحد الموثّق في Cosmos DB البالغ 10K RU/s لكل مفتاح شريحة منطقي (logical partition key) بوصفه ضغطاً عكسياً (back pressure) طبيعياً. وكانت في كل حساب حاوية واحدة افتراضياً. نجح ذلك إلى أن كشف التوسع عن ثلاث مشكلات.

الأولى: بسبب قرارات مبكرة في تصميم API، تُرك اختيار مفتاح الشريحة للعملاء. وتداخلت المفاتيح الشائعة، مثل user_id أو workspace_id، بين سيناريوهات منتجات مختلفة، فتقاسمت هذه السيناريوهات حد المفتاح الواحد. الثانية: تُطبَّق الحدود فعلياً على مستوى الشريحة الفيزيائية، ولذلك لا يبلغ المفتاح المنطقي 10 000 RU/s، وتزاحم الأحمالُ الموجودة على الشريحة نفسها بعضَها بعضاً. وقد أثّرت ميزات ثانوية في مسارات حرجة مثل تسجيل الدخول وإنشاء الحساب. الثالثة: يُوزَّع معدل إنتاجية الحاوية بالتساوي بين الشرائح الفيزيائية. وعندما تنمو البيانات وتنقسم الشرائح، يبقى إجمالي التزويد (provisioning) كما هو، بينما ينخفض الحد المتاح لكل شريحة. وفي السيناريوهات الثقيلة الشبيهة بالـ blob، كان نمو التخزين وحده يقلّص الإنتاجية المتاحة رغم ثبات حركة المرور.

المرحلة الثانية: عزل لم يتوسع تنظيمياً

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

لكن التكاليف التشغيلية الإضافية ازدادت. والسبب الرئيسي: في الحاوية المشتركة، لم يكن انتقال سيناريو جديد من 0 إلى 1 مليون QPS يحرّك المجموع الكلي إلا قليلاً. أما في حاوية مخصصة بسعة 10K RU/s، فإن القفزة نفسها، من 1K RU/s في اختبار الحِمل إلى 1M RU/s عند الإطلاق، كانت تعني 10 000% من الهامش المتاح. في المقابل، لا تشكّل القفزة في حاوية مشتركة بسعة 100M RU/s عند تحميل 80% سوى نحو 5%. وكانت الفرق تُطلق الميزات وتنسى التوسع مسبقاً، وفي يوم الإطلاق يجلس المهندسون في غرف معالجة الحوادث (SEV). وكان تخطيط السعة يتطلب من كل فريق معرفة بمنتجه، وتفاوتت جودة هذا العمل تفاوتاً كبيراً.

المرحلة الثالثة: العودة إلى الحاوية المشتركة بالتعاون مع

Azure

عادت OpenAI إلى تعدد المستأجرين افتراضياً، وعالجت مع فريق Azure العيوب الأصلية:

• Hot key throttling. يمنع تقييد المفاتيح الأكثر سخونة أولاً أن يستهلك مفتاح واحد كامل إنتاجية الشريحة الفيزيائية.
• Quality of Service. طلبات متعددة المستويات: الأحمال غير المتصلة (offline)، مثل الإدراج الجماعي (bulk) وعمليات التصدير، تحصل على أولوية منخفضة وتُقيَّد أولاً، بينما تبقى حركة المستخدمين التفاعلية دون مساس.
• وضع serverless الجديد. كان الوضع السابق يتوسع بحسب التخزين فقط، ويحدّ كل شريحة فيزيائية بـ 5K RU/s. أما الجديد فيسمح لكل شريحة بالنمو حتى 10K RU/s، ويضيف التقسيم (splits) بحسب حِمل RU إلى جانب التقسيم بحسب الحجم. ولم تعد هناك حاجة إلى المراقبة اليدوية ولا إلى رفع التزويد يدوياً.

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

ما يمكن الاستفادة منه

يمكن قراءة تجربة OpenAI بوصفها قائمة مراجعة لأي فريق يبني منصة بيانات مشتركة.

• لا تترك للعملاء اختيار مفتاح الشريحة. فقد اضطرت OpenAI لاحقاً إلى تعويض هذا الخيار المبكر في API ببنية تحتية كاملة.
• راقب الحد الفعلي لكل شريحة فيزيائية، لا الحد لكل مفتاح منطقي. فهذا الحد ينخفض عند التقسيم دون أي تغيّر في حركة المرور.
• العزل بالحاويات مكلف تنظيمياً: يتحول كل فريق إلى مخطِّط للسعة، ولا يعود هناك نمو مستقر في المجموع الكلي.
• امنح حركة المرور أولويات. يجب أن تُقيَّد عمليات الإدراج الجماعي (bulk) والتصدير قبل طلبات المستخدمين.
• إذا كان حجم التشغيل كبيراً، فاطلب من المورّد إدخال تحسينات. فقد حصلت OpenAI من Azure على وضع serverless مخصص، ولم تلتفّ على القيود من جانبها.

وتصف OpenAI نفسها بأنها لا تزال في بداية الطريق في مجال تعدد المستأجرين. لكن المكسب واضح حتى الآن: غرف SEV أقل عند الإطلاق، وعمل يدوي أقل لدى فرق المنتجات.