تصميم خدمة بث الفيديو

تصميم خدمة بث الفيديو

تخدم يوتيوب أكثر من 500 ساعة فيديو يُرفع كل دقيقة وتوصّل أكثر من مليار ساعة مشاهدة يوميًا في أكثر من 100 دولة. يجبرك تصميم نظام بهذا الحجم على حل ثلاث مشكلات صعبة ومتمايزة في آنٍ واحد: الاستيعاب (كيف تتحول الرفعات الخام إلى ملفات قابلة للبث؟)، التخزين (أين تعيش مئات البيتابايتات من الفيديو؟)، والتوصيل (كيف يحصل كل مشاهد على كل جهاز على تشغيل سلس؟). لكل مشكلة قصتها المعمارية الخاصة، وتجتمع معًا لتُشكّل واحدة من أكثر دراسات حالة الأنظمة الموزعة إفادةً.

المتطلبات

المتطلبات الوظيفية:

• يستطيع المستخدمون رفع مقاطع الفيديو (حتى 10 جيجابايت لكل مقطع).
• تُحوَّل المقاطع المرفوعة إلى دقات متعددة (360p و720p و1080p و4K) وصيغ متعددة (MP4/H.264 وWebM/VP9 ومقاطع HLS).
• يستطيع المستخدمون بث الفيديو بمعدل بت تكيفي — تتكيف الجودة تلقائيًا مع عرض النطاق المتاح.
• يستطيع المستخدمون البحث والإعجاب والتعليق والاشتراك (خارج نطاق هذا الدرس؛ نركز على الرفع والبث).

المتطلبات غير الوظيفية:

• التوافر: 99.99% — حتى انقطاع بنسبة 0.01% يؤثر على ملايين المشاهدين المتزامنين.
• زمن الاستجابة: يجب أن يبدأ تشغيل الفيديو خلال ثانيتين؛ وإقرار الرفع خلال 500 ميلي ثانية.
• الإنتاجية: 500 ساعة/دقيقة رفعًا؛ ذروة النطاق الترددي الصادر في عشرات التيرابت في الثانية عالميًا.
• المتانة: يجب ألا يُفقد الفيديو المرفوع أبدًا (3 نسخ متكررة جغرافيًا على الأقل).
• قابلية التوسع: يجب أن تتوسع أفقيًا لكل من الاستيعاب والتوصيل دون إعادة هيكلة.

تقدير الحجم

• التخزين: 500 ساعة × 60 دقيقة × ~1 جيجابايت/دقيقة خام ≈ 30 تيرابايت فيديو خام في الساعة. بعد تحويل الترميز إلى 5 دقات، تكلفة التخزين لكل جيجابايت خام حوالي 2–3×. عند 30 تيرابايت/ساعة، يعني ذلك 70–90 تيرابايت من التخزين النهائي في الساعة، أو ~650 بيتابايت سنويًا — وهذا هو السبب في امتلاك يوتيوب لمراكز بياناتها الخاصة.
• النطاق الترددي (الصادر): مليار ساعة مشاهدة/يوم ÷ 86,400 ثانية ≈ ~11.6 مليون بث متزامن. بمعدل بت متوسط 2 ميجابت/ثانية: ~23 تيرابت/ثانية إجمالي الصادر. لا يستطيع أي نقطة حضور CDN منفردة خدمة هذا؛ يتطلب الأمر هرمية CDN عالمية متعددة المستويات.
• عمال تحويل الترميز: معالجة ساعة واحدة من فيديو 4K تستغرق ~20–40 دقيقة من وقت المعالج لكل دقة. 500 ساعة/دقيقة رفعًا × 5 دقات × 30 دقيقة/مهمة = 75,000 دقيقة معالج من تحويل الترميز في الدقيقة الفعلية — مشكلة حوسبة متوازية هائلة.

البنية العامة

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

تعمق 1 — خط أنابيب الرفع

رفع فيديو خام قد يصل إلى جيجابايتات. إرساله كطلب HTTP POST واحد هش — قطع شبكي لمدة 30 ثانية يُفشل الرفع بالكامل. بدلًا من ذلك، يُقسّم العميل الملف إلى أجزاء (عادةً 5–20 ميجابايت لكل جزء) ويرفع كل جزء باستقلالية. يُعيد الخادم تجميعها. يُمكّن هذا الرفع القابل للاستئناف: إذا انقطع الاتصال عند الجزء 47، يستأنف العميل من الجزء 48.

تستخدم يوتيوب بروتوكول GCS للرفع القابل للاستئناف. توفر AWS S3 Multipart Upload. النمط دائمًا: (1) ابدأ الرفع ← احصل على معرف الرفع، (2) ارفع الأجزاء بأرقامها، (3) أكمل الرفع ← يقوم التخزين بدمج الأجزاء.

تعمق 2 — تحويل الترميز على نطاق واسع

يجب أن يصبح فيديو مرفوع واحد ملفات عديدة — دقات مختلفة (360p و480p و720p و1080p و2160p) وترميزات مختلفة (H.264 لأوسع توافق؛ VP9/AV1 لضغط أفضل بنسبة 30–50%). مضروبًا في 500 ساعة رفع في الدقيقة، هذه مشكلة حوسبة متوازية هائلة.

بنت يوتيوب نظام Transcoder الخاص بها الذي يقسم كل فيديو إلى مقاطع من بضع ثوانٍ، يوزع المقاطع عبر آلاف الأجهزة بالتوازي، ويعيد تجميع النتائج. الفكرة المعمارية الجوهرية: يمكنك موازنة تحويل الترميز على المحور الزمني — يمكن للمقطع 1 أن يُحوَّل ترميزه على الجهاز A بينما المقطع 2 يُحوَّل ترميزه على الجهاز B. هذا يختصر وقت معالجة فيديو مدته ساعتان من ساعات إلى دقائق.

على مستوى الصناعة يُعين هذا النمط على: رسم بياني موجه لا دوري (DAG) من المهام حيث كل عقدة تمثل تحويلًا (تقسيم ← ترميز ← صور مصغرة ← دمج ← نشر). يُنسّق محرك سير العمل (Apache Airflow أو AWS Step Functions أو مشغّل DAG مخصص) هذا الرسم البياني.

تعمق 3 — بنية التخزين

تعيش بيانات الفيديو في مخزن الكائنات (Amazon S3 أو Google Cloud Storage أو نظام ملفات Colossus الخاص بيوتيوب). مخازن الكائنات مثالية لأن:

• الملفات غير قابلة للتغيير بعد الكتابة — لا تعارضات تحديث، لا قفل.
• تتوسع إلى إكسابايتات دون ترحيل للمخطط.
• لها واجهة مفتاح-قيمة مسطحة: bucket/videoId/720p/segment_042.ts.
• تدعم سياسات دورة الحياة: نقل الفيديوهات النادرة الوصول تلقائيًا إلى تخزين بارد أرخص.

تعيش البيانات الوصفية (العنوان والوصف والمالك وعدد المشاهدات والحالة وعناوين URL للدقات) في قاعدة بيانات علائقية (MySQL مع نسخ قراءة في يوتيوب). تستخدم عدادات المشاهدات والإعجابات والتعليقات خدمة عداد منفصلة تقبل حركة كتابة عالية وتُفرغ دوريًا في قاعدة البيانات الرئيسية — لا تستطيع تحمّل قفل على مستوى الصف في جدول الفيديوهات لكل حدث تشغيل.

تعمق 4 — توصيل CDN ومعدل البت التكيفي

خدمة 23 تيرابت/ثانية من أصل واحد مستحيلة فيزيائيًا. الحل هو شبكة توصيل المحتوى (CDN): شبكة عالمية من مئات نقاط الحضور (PoPs) التي تخزّن مقاطع الفيديو مؤقتًا بالقرب من المشاهدين. تُشغّل يوتيوب CDN خاصة بها (Google Global Cache) مُكمَّلة بذاكرات تخزين مؤقت مُضمَّنة في مزودي خدمة الإنترنت.

البروتوكول الذي يُمكّن البث السلس عبر اتصالات متغيرة عرض النطاق هو HTTP Live Streaming (HLS). كيف يعمل:

1. يُنتج مُعبّئ HLS مانيفيست رئيسي (.m3u8) يسرد جميع مستويات الجودة المتاحة.
2. لكل مستوى جودة مانيفيست وسائط خاص يسرد مقاطع قصيرة (ملفات .ts، عادةً 6–10 ثوانٍ لكل منها).
3. يُنزّل المشغّل المانيفيست الرئيسي، ويختار جودة أولية بناءً على عرض النطاق الحالي، ويبدأ جلب المقاطع.
4. بعد كل مقطع، يقيس المشغّل إنتاجية التنزيل. إذا انخفض عرض النطاق، ينتقل إلى مانيفيست جودة أقل للمقطع التالي — بسلاسة، في منتصف الفيديو.

تُخزّن CDN كلًا من مقاطع الفيديو الثابتة (TTL طويل، فعليًا إلى الأبد) والمناشير (TTL أقصر لنشر تغييرات مستوى الجودة). تحمي عناوين URL الموقّعة أو الرموز المميزة المحتوى المدفوع: يُصدر خادم API عنوان URL محدود الوقت موقّعًا بـ HMAC؛ تتحقق حافة CDN من التوقيع قبل تقديم المقطع.

ملخص المقايضات