إنشاء تدفقات عمل للتعلم الآلي من طرف إلى طرف قابلة للتكرار وآمنة وقابلة للتوسيع باستخدام Kubeflow على AWS

هذا منشور مدونة ضيف تمت كتابته مع athenahealth.

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

في مجال الذكاء الاصطناعي (AI) ، تستخدم athenahealth علوم البيانات والتعلم الآلي (ML) لتسريع العمليات التجارية وتقديم التوصيات والتنبؤات والرؤى عبر خدمات متعددة. من أول تطبيق له في خدمات المستندات المؤتمتة ، ومعالجة الملايين من مستندات الموفر والمريض بدون لمس ، إلى أحدث أعماله في المساعدين الافتراضيين وتحسين أداء دورة الإيرادات ، يواصل Athenahealth تطبيق الذكاء الاصطناعي للمساعدة في زيادة الكفاءة وقدرات الخدمة ونتائج أفضل لمقدمي الخدمات ومرضاهم.

يوضح منشور المدونة هذا كيفية استخدام athenahealth Kubeflow على AWS (توزيع Kubeflow الخاص بـ AWS) لبناء وتبسيط سير عمل علم البيانات الشامل الذي يحافظ على الأدوات الأساسية ، ويحسن الكفاءة التشغيلية ، ويزيد من إنتاجية علماء البيانات ، ويمهد الطريق لتوسيع قدرات التعلم الآلي الخاصة بهم بسهولة أكبر.

Kubeflow هو نظام أساسي مفتوح المصدر للتعلم الآلي مخصص لجعل عمليات نشر تدفقات عمل التعلم الآلي على Kubernetes بسيطة ومحمولة وقابلة للتطوير. يحقق Kubeflow هذا من خلال دمج أدوات مفتوحة المصدر ذات صلة تتكامل جيدًا مع Kubernetes. تتضمن بعض هذه المشاريع Argo لتنسيق خطوط الأنابيب ، و Istio لشبكة الخدمة ، و Jupyter لأجهزة الكمبيوتر المحمولة ، و Spark ، و TensorBoard ، و Katib. تساعد Kubeflow Pipelines في بناء ونشر تدفقات عمل ML قابلة للتطوير يمكن أن تتضمن خطوات مثل استخراج البيانات والمعالجة المسبقة والتدريب النموذجي وتقييم النموذج في شكل خطوط أنابيب قابلة للتكرار.

تساهم AWS في مجتمع Kubeflow مفتوح المصدر من خلال توفير توزيع Kubeflow الخاص بها (يسمى Kubeflow على AWS) الذي يساعد المؤسسات مثل athenahealth على بناء تدفقات عمل ML موثوقة وآمنة وقابلة للتطوير وقابلة للتطوير مع تقليل النفقات التشغيلية من خلال التكامل مع خدمات AWS المدارة. توفر AWS العديد من خيارات نشر Kubeflow مثل النشر باستخدام أمازون كوجنيتو، مع النشر خدمة قاعدة بيانات الأمازون (Amazon RDS) و خدمة تخزين أمازون البسيطة (Amazon S3) ونشر الفانيليا. للحصول على تفاصيل حول تكامل الخدمة والوظائف الإضافية المتاحة لكل خيار من هذه الخيارات ، يرجى الرجوع إلى قابل للفتح.

تقدم Kubeflow على AWS اليوم مسارًا واضحًا لاستخدام Kubeflow ، مدعومًا بخدمات AWS التالية:

يستفيد العديد من عملاء AWS من Kubeflow على توزيع AWS ، بما في ذلك athenahealth.

هنا ، يناقش فريق Athenahealth MLOps التحديات التي واجهوها والحلول التي ابتكروها في رحلة Kubeflow الخاصة بهم.

التحديات مع بيئة ML السابقة

قبل اعتمادنا لـ Kubeflow على AWS ، استخدم علماء البيانات لدينا مجموعة موحدة من الأدوات وعملية سمحت بالمرونة في التكنولوجيا وسير العمل المستخدم لتدريب نموذج معين. تتضمن أمثلة مكونات الأدوات المعيارية واجهة برمجة تطبيقات استيعاب البيانات وأدوات المسح الأمني ​​وخط أنابيب CI / CD الذي تم إنشاؤه وصيانته بواسطة فريق آخر داخل Athenahealth ومنصة خدمة مشتركة تم إنشاؤها وصيانتها بواسطة فريق MLOps. ومع ذلك ، مع نضوج استخدامنا للذكاء الاصطناعي والتعلم الآلي ، نمت مجموعة متنوعة من الأدوات والبنية التحتية التي تم إنشاؤها لكل نموذج. على الرغم من أننا كنا لا نزال قادرين على دعم العملية الحالية ، إلا أننا رأينا التحديات التالية في الأفق:

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

قام فريق علوم البيانات بتقييم الحلول المختلفة لدمج مهام سير العمل. بالإضافة إلى تلبية هذه المتطلبات ، بحثنا عن حل يتكامل بسلاسة مع البنية التحتية والأدوات القياسية الحالية. اخترنا Amazon EKS و Kubeflow على AWS كحل لسير العمل لدينا.

تتضمن دورة تطوير عالم البيانات Kubeflow

يبدأ مشروع علم البيانات بسجل نظيف: لا توجد بيانات ، ولا رمز ، فقط مشكلة العمل التي يمكن حلها باستخدام ML. المهمة الأولى هي إثبات المفهوم (POC) لاكتشاف ما إذا كانت البيانات تحمل إشارة كافية لجعل نموذج ML فعالًا في حل مشكلة العمل ، بدءًا من الاستعلام عن مجموعة البيانات الأولية من مستودع بيانات Snowflake. هذه المرحلة تكرارية ، ويستخدم علماء البيانات بودات Kubernetes أو دفاتر Kubeflow Jupyter أثناء هذه العملية.

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

بعد تطوير الاستعلام ، يستخرج علماء البيانات البيانات الأولية إلى موقع على Amazon S3 ، ثم يطلقون دفتر Jupyter من واجهة مستخدم AWS Kubeflow لاستكشاف البيانات. الهدف هو إنشاء مجموعة الميزات التي سيتم استخدامها لتدريب النموذج الأول. يتيح ذلك لعلماء البيانات تحديد ما إذا كانت هناك إشارة كافية في البيانات لتلبية احتياجات عمل العميل.

بعد أن تكون النتائج مرضية ، ينتقل علماء البيانات إلى المرحلة التالية من دورة التطوير ويحولون اكتشافاتهم إلى خط أنابيب قوي. يقومون بتحويل كود POC إلى كود جودة الإنتاج الذي يعمل على نطاق واسع. لضمان الامتثال من خلال استخدام المكتبات المعتمدة ، يتم إنشاء حاوية باستخدام صورة Docker الأساسية المناسبة. بالنسبة لعلماء البيانات لدينا ، وجدنا أن توفير صورة قاعدة Python و TensorFlow و Spark القياسية يوفر مرونة كافية لمعظم ، إن لم يكن جميع ، أعباء العمل. يمكنهم بعد ذلك استخدام Dockerfile الخاص بالمكون الخاص بهم لتخصيص بيئة التطوير الخاصة بهم بشكل أكبر. ثم يتم استخدام ملف Dockerfile هذا من خلال عملية CI / CD لبناء صورة المكونات التي سيتم استخدامها في الإنتاج ، وبالتالي الحفاظ على الاتساق بين بيئات التطوير والإنتاج.

لدينا أداة تمنح علماء البيانات القدرة على إطلاق بيئة التطوير الخاصة بهم في حجرة تعمل على Kubernetes. عند تشغيل هذا الكبسولة ، يمكن لعلماء البيانات بعد ذلك إرفاق Visual Studio Code IDE مباشرة بالجراب وتصحيح رمز النموذج الخاص بهم. بعد تشغيل الكود بنجاح ، يمكنهم بعد ذلك دفع تغييراتهم إلى git وإنشاء بيئة تطوير جديدة مع أحدث التغييرات.

يتكون خط أنابيب علوم البيانات القياسي من مراحل تشمل الاستخراج والمعالجة المسبقة والتدريب والتقييم. تظهر كل مرحلة في خط الأنابيب كمكون في Kubeflow ، والذي يتكون من Kubernetes pod الذي يدير أمرًا مع بعض المعلومات التي تم تمريرها كمعلمات. يمكن أن تكون هذه المعلمات إما قيمًا ثابتة أو مراجع لإخراج من مكون سابق. تم إنشاء صورة Docker المستخدمة في الحجرة من عملية CI / CD. تظهر تفاصيل هذه العملية في سير عمل CI / CD الذي تمت مناقشته في القسم التالي.

دورة التطوير في Kubeflow. يبدأ سير عمل التطوير على اليسار مع نقطة الوصول. يتم نشر النموذج المكتمل في منصة خدمة نموذج Athenahealth التي تعمل على Amazon ECS.

عملية CI / CD تدعم سير العمل الآلي

كجزء من عملية CI / CD الخاصة بنا ، نستخدم Jenkins لبناء واختبار جميع صور مكونات Kubeflow بالتوازي. عند الانتهاء بنجاح ، يحتوي قالب مكون خط الأنابيب على مؤشرات مرجعية للصور ، ويتم تحميل خط الأنابيب الناتج إلى Kubeflow. تسمح المعلمات في خط أنابيب Jenkins للمستخدمين بإطلاق خطوط الأنابيب وإجراء اختبارات تدريب النموذج الخاصة بهم بعد عمليات الإنشاء الناجحة.

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

توجد أدوات لضمان استخدام المؤشرات المرجعية من إنشاء CI / CD بشكل افتراضي. إذا كانت هناك أداة قابلة للنشر في الريبو ، فسيستمر منطق CI / CD في نشر الأداة على منصة تقديم نموذج athenahealth (خدمة التنبؤ) التي تعمل على Amazon ECS مع AWS فارجيت. بعد مرور كل هذه المراحل ، يدمج عالم البيانات الكود في الفرع الأساسي. ثم يتم دفع خطوط الأنابيب والتحف القابلة للنشر إلى الإنتاج.

سير عمل نشر CI / CD. يصف هذا الرسم التخطيطي سير عمل إنشاء ونشر علوم البيانات. يتم تشغيل عملية CI / CD بواسطة جنكينز.

حماية

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

أمن البيانات

أمن البيانات في غاية الأهمية في Athenahealth. لهذا السبب ، نقوم بتطوير وصيانة بنية تحتية متوافقة تمامًا مع اللوائح والمعايير التي تحمي أمن وسلامة هذه البيانات.

للتأكد من أننا نلبي معايير الامتثال للبيانات ، فإننا نوفر البنية التحتية لـ AWS وفقًا لإرشادات مؤسسة Athenahealth الخاصة بنا. المخزنين الرئيسيين للبيانات هما Amazon RDS للبيانات الوصفية لخطوط الأنابيب القابلة للتطوير بدرجة كبيرة و Amazon S3 للنتائج الأثرية في خطوط الأنابيب والنماذج. بالنسبة إلى Amazon S3 ، نضمن تشفير الحاويات وفرض نقاط نهاية HTTPS وسياسات الحاوية و إدارة الهوية والوصول AWS تتبع أدوار (IAM) مبادئ الامتياز الأقل عند السماح بالوصول إلى البيانات. ينطبق هذا أيضًا على بيانات Amazon RDS: يتم تمكين التشفير دائمًا ، وتتبع مجموعات الأمان والوصول إلى بيانات الاعتماد مبدأ الامتياز الأقل. يضمن هذا التوحيد أن الأطراف المصرح لها فقط هي التي لديها حق الوصول إلى البيانات ، ويتم تتبع هذا الوصول.

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

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

لتقييد الوصول إلى Amazon S3 و Amazon RDS من داخل Kubeflow على AWS و Amazon EKS ، نستخدم IRSA (أدوار IAM لحسابات الخدمة) ، التي توفر الإذن المستند إلى IAM للموارد داخل Kubernetes. كل مستأجر في Kubeflow لديه حساب خدمة فريد تم إنشاؤه مسبقًا والذي نلزمه بدور IAM الذي تم إنشاؤه خصيصًا لتلبية متطلبات وصول المستأجر. وصول المستخدم إلى المستأجرين مقيد أيضًا باستخدام عضوية مجموعة تجمعات مستخدمي Amazon Cognito لكل مستخدم. عندما يتم مصادقة مستخدم إلى المجموعة ، فإن الرمز المميز الذي تم إنشاؤه يحتوي على مطالبات المجموعة ، ويستخدم Kubernetes RBAC هذه المعلومات للسماح أو رفض الوصول إلى مورد معين في المجموعة. يتم شرح هذا الإعداد بمزيد من التفصيل في القسم التالي.

أمن الكتلة باستخدام عزل متعدد المستخدمين

كما لاحظنا في القسم السابق ، يقوم علماء البيانات بإجراء تحليلات استكشافية للبيانات وتشغيل تحليلات البيانات وتدريب نماذج تعلم الآلة. لتخصيص الموارد وتنظيم البيانات وإدارة سير العمل بناءً على المشاريع ، توفر Kubeflow على AWS العزلة بناءً على مساحات أسماء Kubernetes. تعمل هذه العزلة للتفاعل مع Kubeflow UI ؛ ومع ذلك ، فإنه لا يوفر أي أدوات للتحكم في الوصول إلى Kubernetes API باستخدام Kubectl. هذا يعني أنه يمكن التحكم في وصول المستخدم على Kubeflow UI ولكن ليس عبر Kubernetes API عبر Kubectl.

تتناول البنية الموصوفة في الرسم التخطيطي التالي هذه المشكلة عن طريق توحيد الوصول إلى المشاريع في Kubeflow بناءً على عضوية المجموعة. لتحقيق ذلك ، استفدنا من Kubeflow في قوائم AWS ، والتي تتكامل مع مجموعات مستخدمي Amazon Cognito. بالإضافة إلى ذلك ، نستخدم التحكم في الوصول المستند إلى الأدوار (RBAC) لـ Kubernetes للتحكم في التفويض داخل المجموعة. يتم توفير أذونات المستخدم بناءً على عضوية مجموعة Amazon Cognito. يتم تمرير هذه المعلومات إلى الكتلة باستخدام الرمز المميز الذي تم إنشاؤه بواسطة عميل OIDC. تم تبسيط هذه العملية بفضل وظيفة Amazon EKS المدمجة التي تسمح بربط موفري هوية OIDC للمصادقة مع المجموعة.

بشكل افتراضي ، يتم تنفيذ مصادقة Amazon EKS بواسطة مصدق IAM ، وهي أداة تتيح المصادقة باستخدام مجموعة EKS باستخدام بيانات اعتماد IAM. طريقة المصادقة هذه لها مزاياها ؛ ومع ذلك ، فهي ليست مناسبة لحالة الاستخدام الخاصة بنا لأن athenahealth تستخدم Microsoft Azure Active Directory لخدمة الهوية عبر المؤسسة.

عزل مساحة اسم Kubernetes. يمكن لعلماء البيانات الحصول على عضوية في مجموعة واحدة أو مجموعات متعددة حسب الحاجة لعملهم. تتم مراجعة الوصول على أساس منتظم وإزالته حسب الاقتضاء.

يعد Azure Active Directory ، باعتباره خدمة هوية على مستوى المؤسسة ، مصدر الحقيقة للتحكم في وصول المستخدم إلى مجموعة Kubeflow. يتضمن الإعداد الخاص بذلك إنشاء تطبيق Azure Enterprise الذي يعمل كمسؤول خدمة وإضافة مجموعات لمستأجرين مختلفين يحتاجون إلى الوصول إلى نظام المجموعة. ينعكس هذا الإعداد على Azure في Amazon Cognito من خلال إعداد موفر هوية OIDC متحد يستعين بمصادر خارجية لمسؤولية المصادقة إلى Azure. يتم التحكم في الوصول إلى مجموعات Azure بواسطة SailPoint IdentityIQ ، الذي يرسل طلبات الوصول إلى مالك المشروع للسماح أو الرفض حسب الاقتضاء. في تجمع مستخدمي Amazon Cognito ، يتم إنشاء عميلين للتطبيق: يستخدم أحدهما لإعداد المصادقة لمجموعة Kubernetes باستخدام موفر هوية OIDC ، والآخر لتأمين مصادقة Kubeflow في واجهة مستخدم Kubeflow. يتم تكوين هؤلاء العملاء لتمرير مطالبات المجموعة عند المصادقة مع الكتلة ، ويتم استخدام مطالبات المجموعة هذه جنبًا إلى جنب مع RBAC لإعداد التفويض داخل المجموعة.

يتم إعداد روابط دور Kubernetes RBAC بين المجموعات ودور المجموعة Kubeflow-edit ، والذي يتم إنشاؤه عند تثبيت Kubeflow في المجموعة. يضمن ربط الدور هذا أن أي مستخدم يتفاعل مع الكتلة بعد تسجيل الدخول عبر OIDC يمكنه الوصول إلى مساحات الأسماء التي لديهم أذونات لها كما هو محدد في مطالبات المجموعة الخاصة بهم. على الرغم من أن هذا يعمل للمستخدمين الذين يتفاعلون مع المجموعة باستخدام Kubectl ، إلا أن Kubeflow UI لا توفر حاليًا الوصول إلى المستخدمين بناءً على عضوية المجموعة لأنها لا تستخدم RBAC. بدلاً من ذلك ، يستخدم مورد Istio Authorization Policy للتحكم في وصول المستخدمين. للتغلب على هذا التحدي ، قمنا بتطوير وحدة تحكم مخصصة تزامن المستخدمين عن طريق استطلاع مجموعات Amazon Cognito وتضيف أو تزيل روابط الأدوار المقابلة لكل مستخدم بدلاً من المجموعة. يتيح هذا الإعداد للمستخدمين الحصول على نفس مستوى الأذونات عند التفاعل مع كل من Kubeflow UI و Kubectl.

كفاءة العملية

في هذا القسم ، نناقش كيف استفدنا من المصدر المفتوح وأدوات AWS المتاحة لنا لإدارة عمليات سير العمل وتصحيحها وكذلك لتقليل التأثير التشغيلي لترقية Kubeflow.

تسجيل الدخول والرقابة

للتسجيل ، نستخدم FluentD لدفع جميع سجلات الحاويات لدينا إلى خدمة Amazon OpenSearch ومقاييس النظام لبروميثيوس. ثم نستخدم Kibana و Grafana UI للبحث عن السجلات والمقاييس وتصفيتها. يصف الرسم البياني التالي كيفية إعداد هذا.

تسجيل Kubeflow. نستخدم كلاً من Grafana UI و Kibana لعرض السجلات وتنقيتها

لقطة الشاشة التالية هي طريقة عرض Kibana UI من خط الأنابيب الخاص بنا.

نموذج عرض Kibana UI. يسمح Kibana بعرض مخصص.

ترقيات كتلة Kubeflow الآمنة

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

• الترقية إلى إصدار Kubernetes حيث توفر AWS ترقيات مجمعة موضعية. ومع ذلك ، يصبح من الصعب اختبار ما إذا كانت كل من موارد Kubeflow و Kubernetes تعمل على النحو المنشود وتحتفظ البيانات بالتوافق مع الإصدارات السابقة.
• ترقية Kubeflow إلى إصدار أحدث حيث توجد العديد من الميزات المضافة أو المعدلة ودائمًا ما لا تكون فكرة واعدة لإجراء ترقيات موضعية على مجموعة Kubernetes الحالية.

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

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

يوضح الرسم البياني التالي هذه العمارة.

ترقية مجموعة Kubeflow الآمنة. بمجرد نجاح اختبار Kubeflow Candidate ، يتم ترقيته إلى Kubeflow Prod من خلال تحديث الطريق 53.

تأتي Kubeflow على بيانات AWS معبأة مسبقًا مع تكامل Amazon RDS و Amazon S3. من خلال هذه الخدمات المدارة التي تعمل كمخازن بيانات مشتركة ، يمكننا إعداد استراتيجية نشر باللونين الأزرق والأخضر. ولتحقيق ذلك ، تأكدنا من استمرار البيانات الوصفية لخط الأنابيب في Amazon RDS ، والتي تعمل بشكل مستقل عن مجموعة EKS ، كما أن سجلات خطوط الأنابيب والتحف ما زالت موجودة في Amazon S3. بالإضافة إلى البيانات الوصفية والتحف لخط الأنابيب ، قمنا أيضًا بإعداد FluentD لتوجيه سجلات pod إلى Amazon OpenSearch Service.

يضمن ذلك فصل طبقة التخزين تمامًا عن طبقة الحوسبة ، وبالتالي يتيح اختبار التغييرات أثناء تحديثات إصدار Kubeflow على مجموعة EKS جديدة تمامًا. بعد نجاح جميع الاختبارات ، يمكننا ببساطة تغيير ملف الأمازون الطريق 53 سجل DNS إلى كتلة المرشح التي تستضيف Kubeflow. أيضًا ، نحافظ على تشغيل المجموعة القديمة كنسخة احتياطية لبضعة أيام فقط في حالة احتياجنا إلى التراجع.

مزايا Amazon EKS و Kubeflow على AWS لخط أنابيب ML الخاص بنا

نقلت Amazon EKS و Kubeflow على حزمة AWS سير عمل التطوير الخاص بنا إلى نمط يشجع بشدة تدريب النموذج القابل للتكرار. تتيح لنا هذه الأدوات الحصول على مجموعات محددة تمامًا مع مستأجرين محددين تمامًا وتشغيل كود محدد بالكامل.

الكثير من المكاسب من بناء هذه المنصة أقل كمية ولها علاقة أكبر بكيفية تحسين سير العمل لكل من مطوري النظام الأساسي والمستخدمين. على سبيل المثال ، تم استبدال MinIO بإمكانية الوصول المباشر إلى Amazon S3 ، مما يجعلنا أقرب إلى مهام سير العمل الأصلية لدينا ويقلل من عدد الخدمات التي يجب أن نحافظ عليها. يمكننا أيضًا استخدام Amazon RDS كخلفية لـ Kubeflow ، مما يتيح عمليات الترحيل الأسهل بين المجموعات ويمنحنا القدرة على نسخ خطوط الأنابيب احتياطيًا ليلاً.

وجدنا أيضًا أن التحسينات في تكامل Kubeflow مع خدمات AWS المدارة مفيدة. على سبيل المثال ، مع Amazon RDS و Amazon S3 و Amazon Cognito التي تم تكوينها مسبقًا في Kubeflow على بيانات AWS ، فإننا نوفر الوقت والجهد في التحديث إلى التوزيعات الأحدث من Kubeflow. عندما اعتدنا على تعديل بيانات Kubeflow الرسمية يدويًا ، فإن التحديث إلى إصدار جديد قد يستغرق عدة أسابيع ، من التصميم إلى الاختبار.

يمنحنا التبديل إلى Amazon EKS الفرصة لتحديد مجموعتنا في Kustomize (الآن جزء من Kubectl) و Terraform. اتضح أنه بالنسبة للعمل على النظام الأساسي ، من السهل جدًا التعامل مع Kubernetes و Terraform بعد تخصيص وقت كافٍ للتعلم. بعد العديد من التكرارات ، تجعل الأدوات المتاحة لنا من السهل جدًا إجراء عمليات النظام الأساسي القياسية مثل ترقية أحد المكونات أو تبديل مجموعة تطوير كاملة. مقارنة بتشغيل الوظائف من الخام الأمازون الحوسبة المرنة السحابية (Amazon EC2) ، من الصعب مقارنة الاختلاف الهائل الذي يحدثه في الحصول على حُبر محددة جيدًا مع آليات مضمونة لتنظيف الموارد وإعادة المحاولة.

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

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

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

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

على الرغم من كل الفوائد ، فإننا نحذر من إجراء هذا النوع من الترحيل فقط إذا كان هناك اشتراك إجمالي من المستخدمين. يحصل المستخدمون الذين يقضون وقتًا على الكثير من الفوائد من استخدام Amazon EKS و Kubernetes ، ولكن هناك منحنى تعليمي مهم.

وفي الختام

من خلال تنفيذ Kubeflow على خط أنابيب AWS في البنية التحتية لتعليم الكمبيوتر من طرف إلى طرف ، تمكنا من توحيد وتوحيد تدفقات عمل علوم البيانات الخاصة بنا مع الاحتفاظ بأدواتنا الأساسية (مثل CI / CD وخدمة النموذج). يمكن لعلماء البيانات لدينا الآن التنقل بين المشاريع بناءً على سير العمل هذا دون الحاجة إلى تعلُّم كيفية الحفاظ على مجموعة أدوات مختلفة تمامًا. بالنسبة لبعض نماذجنا ، فوجئنا أيضًا بسرور من سرعة سير العمل الجديد (أسرع بخمس مرات) ، مما سمح بمزيد من التكرارات التدريبية وبالتالي إنتاج نماذج بتنبؤات أفضل.

لقد أنشأنا أيضًا أساسًا متينًا لزيادة قدرات MLOps الخاصة بنا وتوسيع نطاق مشاريعنا وحجمها. على سبيل المثال ، بينما نعمل على تقوية وضع الحوكمة لدينا في نسب النموذج والتتبع ، قللنا تركيزنا من أكثر من 15 مهمة سير عمل إلى مهمة واحدة فقط. وعندما ظهرت ثغرة Log4shell في أواخر عام 2021 ، تمكنا من التركيز على سير عمل واحد ومعالجتها بسرعة حسب الحاجة (أداء سجل الأمازون المرنة للحاويات (Amazon ECR) بالمسح وترقية Amazon OpenSearch Service وتحديث أدواتنا والمزيد) بأقل تأثير على العمل المستمر لعلماء البيانات. عندما تصبح تحسينات AWS و Kubeflow متاحة ، يمكننا دمجها على النحو الذي نراه مناسبًا.

يقودنا هذا إلى جانب مهم ومقلل من قيمة Kubeflow بشأن اعتماد AWS. تتمثل إحدى النتائج المهمة لهذه الرحلة في القدرة على طرح ترقيات وتحسينات على Kubeflow بسلاسة لعلماء البيانات لدينا. على الرغم من أننا ناقشنا نهجنا في هذا الأمر في وقت سابق ، إلا أننا نعتمد أيضًا على بيانات Kubeflow المقدمة من AWS. بدأنا رحلة Kubeflow كدليل على المفهوم في عام 2019 ، قبل إصدار الإصدار 1.0.0. (نحن حاليًا في الإصدار 1.4.1 ، بتقييم 1.5. تعمل AWS بالفعل على الإصدار 1.6). في السنوات الثلاث الفاصلة ، كان هناك ستة إصدارات على الأقل ذات محتوى جوهري. من خلال نهجهم المنضبط لدمج هذه الترقيات والتحقق من صحتها وإصدار البيانات وفقًا لجدول زمني يمكن التنبؤ به وموثوق به ، كان فريق Kubeflow في AWS حاسمًا في تمكين فريق Athenahealth MLOps من تخطيط خارطة طريق التطوير الخاصة بنا ، وبالتالي تخصيص مواردنا ومجالات تركيزنا ، في المستقبل بثقة أكبر.

يمكنك متابعة مستودع AWS Labs GitHub لتتبع جميع مساهمات AWS في Kubeflow. يمكنك أيضًا العثور على فرق AWS على موقع قناة Kubeflow #AWS Slack؛ تساعد ملاحظاتك هناك AWS في تحديد أولويات الميزات التالية للمساهمة في مشروع Kubeflow.

---

عن المؤلفين

كانوالجيت خورمي هو مهندس حلول أول في Amazon Web Services. إنه يعمل مع عملاء AWS لتقديم التوجيه والمساعدة الفنية لمساعدتهم على تحسين قيمة حلولهم عند استخدام AWS. Kanwaljit متخصص في مساعدة العملاء في استخدام الحاويات وتطبيقات التعلم الآلي.

تايلر كالباخ هو عضو رئيسي في الطاقم الفني في Athenahealth. يتمتع تايلر بخبرة 7 سنوات تقريبًا في التحليلات وعلوم البيانات والشبكات العصبية وتطوير تطبيقات التعلم الآلي في مجال الرعاية الصحية. لقد ساهم في العديد من حلول التعلم الآلي التي تخدم حاليًا حركة الإنتاج. يعمل حاليًا كعالم بيانات رئيسي في منظمة هندسة Athenahealth ، وكان Tyler جزءًا من الفريق الذي قام ببناء منصة تدريب التعلم الآلي الجديدة لـ athenahealth من بداية هذا الجهد.

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

ساسانك فيموري هو عضو رئيسي في الطاقم الفني في Athenahealth. لديه خبرة في العمل على تطوير حلول تعتمد على البيانات عبر مجالات مثل الرعاية الصحية والتأمين والمعلوماتية الحيوية. تعمل Sasank حاليًا على تصميم وتطوير أنظمة التدريب على التعلم الآلي والاستدلال على AWS و Kubernetes التي تساعد في التدريب ونشر حلول التعلم الآلي على نطاق واسع.

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

وليام تسن هو مدير هندسة أول في Athenahealth. لديه أكثر من 20 عامًا من الخبرة في القيادة الهندسية في بناء الحلول في مجال تكنولوجيا المعلومات للرعاية الصحية ، والحوسبة الموزعة للبيانات الضخمة ، والشبكات البصرية الذكية ، وأنظمة تحرير الفيديو في الوقت الفعلي ، وبرامج المؤسسات ، والاكتتاب الجماعي للرعاية الصحية. يقود ويليام حاليًا فريقين رائعين في athenahealth ، وفرق هندسة عمليات التعلم الآلي و DevOps ، في منظمة هندسة المنتجات.