رؤية TrueFoundry

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

رؤية TrueFoundry (5-10 سنوات)

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

تخيل سير عمل حيث، بعد كتابة الكود — يمكنني استدعاء "جني" وإخباره بمتطلباتي مثل نوع الخدمة (بلا خادم، مهمة مجدولة، قاعدة بيانات، خدمة API)، ومتطلبات الموارد مثل وحدة المعالجة المركزية، الذاكرة، إلخ، ويقوم "الجني" بإنشاء الخدمة بأفضل الممارسات مثل Gitops، والبنية التحتية ككود (IAC) ثم يعرض لوحة تحكم بجميع المقاييس التي تم إنشاؤها.

نهدف إلى تحقيق الأمور التالية باستخدام servicefoundry:

توفير البنية التحتية المركزي باستخدام IAC

ستقوم ServiceFoundry بتوفير واستضافة مكونات البنية التحتية مفتوحة المصدر الأكثر استخدامًا على سحابة المستخدم. بعض الأمثلة على ذلك يمكن أن تكون:

1. إطلاق مجموعة Kubernetes مع تكوين أفضل ممارسات الأمان.
2. تثبيت مكونات البنية التحتية المركزية (أو استخدام خدمات مُدارة) مثل Kafka، Spark، Redis، Prometheus، Grafana، إلخ.
3. يمكننا استخدام خدمات سحابية مُدارة لبعضها مثل AWS Elastic Search.
4. إطلاق قواعد البيانات، طبقات التخزين. (استخدم الإصدارات المُدارة حاليًا)
5. أنظمة تنسيق خطوط الأنابيب مثل Airflow، Argo، إلخ.
6. التكامل المستمر / التسليم المستمر (CI / CD) (Github Actions، Gitlab، AWS Code pipelines)
7. تجميع السجلات (ELK، EFK)
8. المراقبة (المقاييس القياسية والمخصصة)
9. التنبيهات

إنشاء خدمة

1. بناء ونشر الخدمات بناءً على قوالب قابلة للتكوين. ستكون ServiceFoundry مجموعة من المبادئ المحددة لأتمتة ما يلي:

• إدارة التبعيات والتعبئة (دوكر، زيب)
• الاختبار
• إدارة التكوين (تكوينات ثابتة ومتغيرة ديناميكيًا)
• توفير البنية التحتية (فوق البنية التحتية المركزية التي تم توفيرها مسبقًا)
• تهيئة التحجيم التلقائي
• CI/CD
• تجميع السجلات
• إنشاء لوحات المعلومات بمقاييس قياسية (يمكن للمستخدمين إضافة مقاييس مخصصة)
• التنبيهات

على غرار ما سبق، نريد أيضًا أن نفعل الشيء نفسه لنماذج التعلم الآلي وقواعد البيانات.

تهدف ServiceFoundry إلى تبسيط نشر ومراقبة الأنواع القياسية من الخدمات:

1. خدمة واجهة برمجة تطبيقات موزعة الحمل (مع التحجيم التلقائي بناءً على معايير مختلفة)
2. خدمة المهام (مهام كرون، مهام يتم تشغيلها بواسطة الأحداث)
3. بلا خادم
4. خدمات ذات حالة
5. موقع ويب ثابت

كتالوج الخدمات والرسم البياني

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

1. رابط إلى مستودع GitHub
2. التكوين
3. روابط المراقبة
4. الفريق والمالكون
5. إمكانية إضافة أعضاء بصلاحيات وصول مختلفة.
6. التكلفة

TrueFoundry MLOps (منصة تعتمد على التعلم الآلي أولاً)

سيكون التركيز الأولي لـ TrueFoundry هو توفير منصة MlOps سلسة تركز على مسار عمل ما بعد بناء النموذج وتجعل من السهل جدًا على علماء البيانات نشر نماذجهم ومراقبتها وإعادة تدريبها.

يتكون مسار عمل التعلم الآلي من البنية التحتية المركزية التالية:

فيما يلي شرح موجز للخطوات المختلفة المتضمنة:

1. مسار عمل البيانات ومخزن الميزات: هذه في الأساس مشكلة بيانات ضخمة حيث نحتاج إلى الحصول على الميزات التي ستُستخدم في النموذج، والتي يتم حسابها من بحيرة البيانات وتكون متاحة ضمن القيود الزمنية المطلوبة لكل من التدريب والإنتاج دون تباين. وعادةً ما تستخدم محرك تنسيق سير العمل مثل Airflow وArgo وKubeflow pipelines.
2. تدريب النموذج: تدريب النموذج هو في الأساس مهمة موزعة تتطلب قدرة حاسوبية عالية ويمكن تشغيلها على أجهزة متعددة. ويجب أن توفر أيضًا مرونة مدمجة عبر حفظ نقاط التحقق واستعادتها.
3. خدمة النموذج: هذه في الأساس خدمة مصغرة تتلقى طلبات لإجراء تنبؤات النموذج ويمكن أن تكون لها متطلبات متنوعة مثل وحدة معالجة الرسوميات (GPU) ومتطلبات الحوسبة والذاكرة العالية. وعادةً ما يتم استضافة كل نموذج كخدمة مصغرة واحدة — وبالتالي عندما يتوسع فريق ليضم عشرات النماذج، يصبح الأمر مشكلة إدارة عشرات الخدمات المصغرة، وهي مشكلة كبيرة بحد ذاتها.
4. مراقبة النموذج: يشمل ذلك مراقبة مقاييس النظام ومراقبة خاصة بالتعلم الآلي تتعلق بأداء النموذج وتدهوره. ويتطلب هذا أيضًا أنظمة لتخزين البيانات المسجلة، وتشغيل التجميعات عليها، وأخيرًا حساب المقاييس.
5. إدارة النموذج: يتتبع هذا جميع البيانات المتعلقة بالنماذج وإصداراتها وتجاربها المختلفة. وهو مفيد للغاية لتصحيح الأخطاء لاحقًا والعودة إلى إصدار سابق.

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

يبدو سير العمل النموذجي في الشركات لمسار عمل التعلم الآلي كالتالي:

الهدف الرئيسي لمنصة تعلم الآلة

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

لا نتعامل مع أي من المشكلات المتعلقة بالبيانات الآن — سيتم تقديم هذا القسم لاحقًا.

تتألف منصة تعلم آلة أساسية من الخدمات التالية (بصرف النظر عن البنية التحتية المركزية)

1. التدريب (مهمة مجدولة بمحفزات مختلفة)
2. خدمة النماذج (خدمة واجهة برمجة تطبيقات موزعة الحمل)
3. التخزين (المخرجات، مجموعات البيانات، بيانات استدلال النماذج)
4. خدمة مراقبة تعلم الآلة (خدمة لحساب المقاييس من البيانات)
5. خدمة هندسة الميزات

إذا تمكنا من نشر هذه الخدمات بسهولة، والحفاظ على إدارة الإصدارات عبر المراحل المختلفة، وتوليد المراقبة لكل منها، فستصبح مشكلة عمليات تعلم الآلة (ML Ops) أبسط بكثير.

نُشرت هذه المدونة لأول مرة على منصة Medium على الرابط التالي: https://abhishekch09.medium.com/d8e159743a4b