النشر الأزرق والأخضر للنموذج يستخدم أسطولًا قائمًا وآخر جديدًا. في مسار SageMaker الموثق، ينشأ الأخضر ثم تحول حركة الطلبات إليه، وتنتهي خدمة الأزرق بعد فترة المراقبة المقررة. [1]
الخلاصة السريعة
اربط كل طلب بالأسطول الذي أسند إليه في سجل معلوم؛ خبر تحويل الحركة وحده لا يحدد نسخة طلب سابق أو يثبت جودة تنبؤ جديد.
- المسار الموثق يجهز الأخضر، ويحول الحركة، ثم ينهي الأزرق بعد المراقبة؛ لبعض خصائص نقاط النهاية استثناءات من دعم هذا المسار. [1]
- في عقدنا الافتراضي يبقى الطلب ق 1 مع الأزرق الذي قبله؛ تحديث توجيه الطلبات اللاحقة لا يعيد إسناده وفق هذا العقد، وليس قاعدة لكل خدمة.
- الطلب ق 2 سجل قبوله لدى الأخضر بعد التحويل؛ وقت إرسال المستخدم أو انتهاء الجواب وحده لا يثبت جهة التنفيذ.
- توثق الخدمة تحويلًا دفعة واحدة أو بنمط تجريبي أو خطي، وفترة مراقبة مع إمكانية تراجع عند الإنذارات؛ اختيار النمط لا يثبت جودة كل جواب. [1]
ما الذي يتغير عند نشر الأخضر؟
تصف وثائق SageMaker تجهيز أسطول أخضر جديد ثم نقل الحركة من الأزرق إليه. لا تتاح حواجز النشر هذه لبعض خصائص نقاط النهاية المذكورة في الوثائق. [1]
نستخدم اللونين لتسمية مجموعتين من موارد تقديم نموذج، دون ربط اللون بفئة التنبؤ. يمكن أن يبقى اسم نقطة النهاية في بطاقة المستخدم واحدًا، بينما يتغير الأسطول الذي يستقبل الطلب بحسب خطة النشر.
قبل تفسير سجل، سم ما يقصده صاحبه بالتحويل: إعداد توجيه، أو قبول طلب، أو إنهاء مورد. هذه أحداث مختلفة في تمريننا. ولا نعتبر الإعلان عن تجهيز الأخضر دليلًا على أن طلبًا معينًا وصل إليه.
اكتب عقد الطلب الذي بدأ سابقًا
نؤلف خدمة لها قاعدة معلنة: عند قبول الطلب تسجل جهة إسناده، ويواصل العمل لدى تلك الجهة حتى نهايته. عند الحد الزمني ت تغير الجهة للطلبات التي تقبل بعده. هذا تعريف لخدمة افتراضية، وليس وصفًا شاملًا لسلوك كل منصة.
قبل ت قبل الأزرق الطلب ق 1. ما زال الطلب يعمل عندما وقع تحديث التوجيه. تحت قاعدتنا يبقى ق 1 مع الأزرق؛ لا ننقل هويته إلى الأخضر لمجرد أن جواب ق 1 عاد بعد ت.
لو كانت خدمة أخرى تلغي العمل أو تعيد المحاولة، نحتاج عقدها وسجل محاولاتها قبل حمل الاستنتاج إليها. المثال يعزل تحديد الإسناد، ولا يثبت أن الأزرق ظل متاحًا مدة معينة في نشر فعلي.
أي حدث يثبت جهة طلب جديد؟
بعد ت تقبل الخدمة ق 2 وتسجل الأخضر جهة له. صار لدينا دليل مباشر في تمريننا على الإسناد المختلف: ق 1 للأزرق، وق 2 للأخضر. لم نستخرج ذلك من عنوان نقطة النهاية المشترك.
تخيل أن المستخدم أرسل ق 2 قبل ت، لكن قبوله وقع بعده. قاعدتنا مبنية على القبول المسجل، فتظل جهة ق 2 الأخضر. تقديم ساعة الإرسال بدل ساعة القبول يغير الحدث الذي نسند إليه الحكم.
وعند غياب سجل الجهة نقول إنها غير معلومة لهذا الطلب. لا نخمنها من سرعة الجواب أو نصه؛ قد يتفق مخرجان من نسختين مختلفتين. كما لا نجعل اللون الأخضر حكمًا بأن التنبؤ أصح.
هل اسم التحويل يصف طريقة واحدة؟
تعرض الوثائق أنماط الدفعة الواحدة والتجريبي والخطي، وفترة مراقبة يمكن أن تؤدي فيها إنذارات مهيأة إلى تراجع الحركة. [1]
لذلك لا نأخذ كلمة «تحويل» وحدها دليلًا على عبور جميع الطلبات الجديدة إلى الأخضر في لحظة واحدة لكل إعداد. في بطاقة المراجعة نكتب النمط والحد الذي اعتمدناه وسجل الجهة، ونترك سلوك الطلب الجاري معلنًا في عقده.
لم ننشئ أسطولًا أو نحول مرورًا أو نقس زمنًا. الرسم يوضح الطلبين تحت قاعدة الإسناد التي ألفناها. يفيد هذا الفصل عندما يراجع الفريق جوابًا ظهر قرب تحديث النموذج: أي سجل يربطه فعلًا بالنسخة المقصودة؟
المصادر ومتابعة القراءة
- Amazon SageMaker: Blue/Green Deployments (يفتح في نافذة جديدة)docs.aws.amazon.com
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.