تقليل وقت نشر قنوات FAST من 15 دقيقة إلى دقيقة واحدة

جدولة برامج متعددة بنقرة واحدة — تجاوز سقف 15 دقيقة لـ AWS Lambda

يقوم مشغل قناة FAST بجدولة برامج شهر كامل ويضغط على نشر (Deploy) مرة واحدة. وراء تلك النقرة الواحدة، تتحول مئات البرامج إلى آلاف من إجراءات جدولة MediaLive التي يجب أن تصل إلى AWS بالترتيب، وكل ذلك ضمن سقف تنفيذ Lambda الذي يبلغ خمس عشرة دقيقة — وأي فشل في المنتصف يترك قناة بث مباشر بها فجوات. إليك كيف جعلنا نشر قوائم التشغيل الكبيرة بنقرة واحدة موثوقًا، ولماذا الخطوة التالية هي بيئة تشغيل مختلفة، وليست Lambda أكبر.

نظرة عامة سريعة

التحدي

نشر قائمة تشغيل ليس عملية كتابة — بل هو تنسيق. لكل برنامج يجدوله المشغل، يحتاج MediaLive إلى معرفة متى يجب تبديل المدخلات بالضبط، ومتى يجب تشغيل العلامة المائية لكل عرض، ومتى يجب إدراج نقاط إشارة SCTE-35، ومتى يجب دمج الإعلانات. والضغوط الهيكلية هي:

• عدد الإجراءات مضاعف، وليس إضافيًا. يصدر كل برنامج حوالي 7–8 إجراءات قبل الفواصل الإعلانية — تبديل إدخال واحد، أربعة تنشيطات للعلامات المائية (واحد لكل عرض لأن StaticImageOutputActivate يستخدم إحداثيات بكسل الإخراج)، وعلامتان SCTE-35. تضيف الفواصل الإعلانية ثلاثة إجراءات أخرى لكل منها. شهر يتضمن 360 برنامجًا يعني حوالي 2,800 إجراء عبر الشبكة.
• يفرض MediaLive الترتيب لكل قناة. إجراءات الجدولة مرتبطة بالوقت وتشير إلى بعضها البعض؛ لا يمكنك موازاة عمليات الكتابة لنفس القناة دون أن يرفضها الـ API بسبب التعارض.
• لدى AWS Lambda سقف ثابت مدته 15 دقيقة. ليس حدًا مرنًا، ولا إعدادًا. يجب أن ينتهي المنسق (orchestrator) ضمن هذا الحد وإلا ستنتهي القناة بنصف نشر.
• الفشل الجزئي غير مقبول تشغيليًا. إذا فشل البرنامج 174 من أصل 360 وألغى التشغيل، فلن يكون لدى المشغل رؤية للفرق بين ما تم نشره وما لم يتم. تذهب القناة للبث المباشر مع وجود فجوات؛ يرى المشاهدون شاشة سوداء حيث توقعوا محتوى.
• أرسل الإصدار الأول أمر BatchUpdateSchedule واحدًا لكل برنامج مع فترة انتظار 200 مللي ثانية بين البرامج. وهذا يعني حوالي 2.5 ثانية من وقت التنفيذ لكل برنامج. عند 360 برنامجًا، تكون قد تجاوزت بالفعل سقف Lambda قبل أن يقوم MediaLive بأي عمل حقيقي.

إذًا، المهمة ليست الكتابة بشكل أسرع. بل هي الكتابة لعدد مرات أقل، النجاة من الفشل الجزئي، والبقاء ضمن استدعاء واحد — دون فقدان ضمانات الترتيب التي يطلبها MediaLive.

لماذا تفشل الأساليب الحالية

تفشل جميع الحلول الواضحة لأسباب هيكلية، وليست مشاكل ضبط.

• "فقط ارفع مهلة Lambda." لا يمكنك ذلك. خمس عشرة دقيقة هي سقف صارم تفرضه AWS على تنفيذ Lambda؛ إنه ليس مفتاح ضبط في وحدة التحكم. حتى لو كان كذلك، فإن التكلفة لكل برنامج تزداد مع الكتالوج — شراء المزيد من الوقت يؤجل فقط السقف التالي.
• "الانتقال إلى ECS Fargate أو EC2." لقد نظرنا في الأمر ورفضناه. الحاويات طويلة الأمد تعني أننا نتحمل مسؤولية بيئة التشغيل: فحوصات السلامة، التوسع التلقائي، المفاضلات بين التشغيل البارد والمجموعة الدافئة، تحديد نطاق IAM، وتناوب المناوبة لخدمة تعمل على دفعات. يمنحنا Lambda عزلة لكل استدعاء وتكلفة خاملة صفرية لأعباء العمل المتقطعة بطبيعتها. لم نكن مستعدين للتخلي عن ذلك لإصلاح عنق زجاجة واحد.
• "موازاة عمليات كتابة MediaLive." يقوم MediaLive بتسلسل تحديثات الجدولة لكل قناة. مكالمات BatchUpdateSchedule المتزامنة ضد نفس القناة تتنافس على الجدول الزمني للإجراءات ويتم رفضها. التوازي الشرعي الوحيد هو داخل دفعة، وليس عبر الدفعات.
• "فقط دعه ينهار ودع المشغل يعيد المحاولة." هذا هو الخيار الأسوأ. عندما يتوقف النشر عند البرنامج N، تكون القناة في حالة لا يمكن لأحد وصفها من واجهة المستخدم. لا يحصل المشغلون على مقارنة؛ بل يحصلون على صندوق أسود وقناة بث مباشر بها فجوات. يجب على النظام إما أن ينشر كل شيء أو ينشر نتائج جزئية مع حالة لكل برنامج يمكن للمشغل التصرف بناءً عليها.

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

حلنا

نقل التكلفة خارج Lambda قبل بدء الحلقة، ودمج عمليات كتابة MediaLive داخل الحلقة، والتراجع إلى الإرسال لكل برنامج فقط عندما تفشل دفعة. ثلاث أفكار، بهذا الترتيب — وقرار متعمد بأن سقف الـ 15 دقيقة مناسب لأحجام الكتالوجات التي ننشرها حاليًا. عندما تتجاوز قوائم التشغيل استدعاءً واحدًا، فإن الحل ليس Lambda أكبر؛ بل هو بيئة تشغيل مختلفة.

البنية

• الواجهة الخلفية لـ NestJS (schedule.service.ts) — تقوم بالتهيئة المسبقة للنشر: رحلة ذهاب وعودة واحدة إلى Mongo لجميع مقاطع الفيديو الفريدة، وواحدة لجميع علامات الإعلانات، ثم تشغيل ffprobe بالتوازي عبر عناوين URL الفريدة لمقاطع الفيديو مع تخزين النتائج مؤقتًا لحلقة الإثراء.
• منسق Lambda (fastChannel-lambda-fun/index.js) — يتحمل مسؤولية حلقة التجميع، وتقييد معدل الإرسال لكل دفعة، وآلية التراجع لكل برنامج، وتنظيف العناصر المعلقة (orphan sweep).
• MediaLive BatchUpdateScheduleCommand — هي واجهة الكتابة الوحيدة. يتدفق كل إجراء — تبديل الإدخال، العلامة المائية، SCTE-35، دمج الإعلان — من خلالها.
• MongoDB — مصدر الحقيقة للبرامج ومقاطع الفيديو وعلامات الإعلان؛ لا يتم الاستعلام عنها أبدًا داخل الحلقة الداخلية.
• خريطة scheduleResults — حالة scheduled / error لكل برنامج تُعاد إلى الواجهة الخلفية بحيث يحصل المشغل على مقارنة، وليس تتبعًا للمكدس (stack trace).

قرارات هندسية رئيسية

1. التهيئة المسبقة للأجزاء البطيئة قبل بدء الحلقة. كان الكود الأصلي يقوم بعملية بحث في Mongo لكل جدول استدعاء لـ ffprobe لكل جدول داخل حلقة الإثراء — وهو سيناريو N+1 كلاسيكي يدفع مرتين. تقوم الواجهة الخلفية الحالية بجلب كل فيديو وعلامة إعلانية فريدة دفعة واحدة في رحلة ذهاب وعودة واحدة لكل منها، ثم تشغل ffprobe بالتوازي عبر عناوين URL الفريدة وتخزن النتائج مؤقتًا في ذاكرة تخزين مؤقتة للحل. تصبح الحلقة الداخلية عملية وصول إلى ذاكرة التخزين المؤقت. يتم دفع تكلفة ffprobe مرة واحدة لكل عنوان URL فريد، وليس بشكل تسلسلي في الحلقة.

2. دمج عمليات كتابة MediaLive في دفعات بحوالي 25. داخل المنسق، تتراكم الإجراءات في أمر BatchUpdateScheduleCommand واحد حتى يتم وضع 200 إجراء في قائمة الانتظار أو الوصول إلى البرنامج الأخير. بما أن كل برنامج ينتج حوالي 7-8 إجراءات، فإن الدفعات تحتوي بشكل طبيعي على حوالي 25 برنامجًا لكل منها. تم اختيار الحد الأقصى لـ 200 إجراء بحذر للبقاء أقل بكثير من حدود حمولة MediaLive لكل طلب وتقليل فرصة رفض الدفعة بسبب الحجم — كبيرة بما يكفي لتعويض تكلفة الشبكة، وصغيرة بما يكفي لجعل آلية التراجع لكل برنامج (القرار التالي) غير مكلفة عند الحاجة لتشغيلها. رحلة ذهاب وعودة واحدة عبر الشبكة تحل محل خمس وعشرين. التحكم في سرعة الإرسال (throttle) الذي كان يبلغ 200 مللي ثانية بين كل برنامج أصبح الآن بين كل دفعة.

3. التجميع للسرعة، وآلية التراجع للصحة. الدمج آمن فقط إذا لم يفسد برنامج واحد سيء البرامج الأربعة والعشرين الأخرى في دفعته. عندما يرمي submitProgramBatch خطأً، تستدعي كتلة `catch` دالة retryBatchAsIndividuals، والتي تعيد إرسال كل برنامج في الدفعة الفاشلة كـ BatchUpdateScheduleCommand خاص به، وتسجل status: 'scheduled' أو status: 'error' لكل برنامج، وتتوقف لمدة 200 مللي ثانية بين المحاولات، وتعيد تثبيت الجدول الزمني للإجراءات بعد كل نجاح جزئي. المسار السريع مجمع. مسار الاسترداد دقيق. يحصل المشغل على مقارنة لكل برنامج في كلتا الحالتين.

4. إزالة العناصر المعلقة في النهاية، لا تمنعها أثناء التنفيذ. تعمل sweepIncompleteProgramGroups مرة واحدة في نهاية النشر وتزيل أي مجموعة إجراءات لم تصل إلى حالة إنهاء نظيفة. نحن لا نحاول عمدًا الحفاظ على اتساق القناة داخليًا أثناء الحلقة — فذلك يعني مسار تراجع يجب أن يتناسب بدوره مع ميزانية الـ 15 دقيقة. التنظيف هو عملية مسح واحدة، وليس معاملة (transaction).

5. لا تضخّم Lambda؛ استبدلها عندما يتضخم الكتالوج. لكل ما ننشره اليوم، ينتهي مسار الاستدعاء الفردي بشكل جيد ضمن الميزانية. التوسع الحقيقي هو تقسيم باستخدام Step Functions — تقسيم قائمة التشغيل، وتشغيل الأجزاء كآلات حالة متوازية، ثم إعادة تجميعها. هذا هو المسار لقوائم التشغيل التي تزيد عن شهر واحد وستة أشهر. إنه مصمم، ولم يتم نشره بعد. تسميته الخطوة التالية أكثر فائدة من التظاهر بأنه قيد التشغيل بالفعل.

النتائج

• في الاختبارات الداخلية، اكتمل نشر 195 برنامجًا في حوالي 44 ثانية — انخفاضًا من خط الأساس الذي كان يستغرق عدة دقائق، وبرنامجًا واحدًا في كل مرة.
• الهدف الموثق لقائمة تشغيل تضم 360 برنامجًا (حوالي شهر واحد) هو ≤90 ثانية، ضمن مهلة الواجهة الخلفية البالغة 615 ثانية وسقف Lambda البالغ 15 دقيقة.
• لم يعد برنامج واحد سيء في دفعة يلغي الـ 24 برنامجًا الأخرى. يحصل المشغل على خريطة حالة لكل برنامج من كل عملية نشر.
• الأجزاء البطيئة من الطلب — عمليات البحث في Mongo و ffprobe — يتم دفع تكلفتها مرة واحدة لكل مورد فريد، وليس مرة واحدة لكل إدخال جدول.
• توقف سقف الـ 15 دقيقة عن كونه العامل المحدد لأحجام الكتالوجات التي نرسلها بالفعل. وعندما يصبح كذلك مرة أخرى، سيكون تقسيم Step Functions هو الحل، وليس Lambda أكبر.

مجموعة التقنيات: AWS Lambda · AWS MediaLive · NestJS · MongoDB · Node 18 · ffprobe · TypeScript · AWS SDK v3