تولید لحظه‌نگار: نگاربن، اولین سرویس استریمینگ ایرانی
تلاش ما همیشه در لحظه‌نگار، این بوده که بتونیم یک محصول خوب ارائه کنیم و این باور رو داریم که محصول خوب، سایر مشکلات رو حل خواهد کرد. دی ماه سال پیش تصمیم گرفتیم که تغییراتی جدی رو در زیرساخت لحظه‌نگار انجام بدیم و به هدف خودمون نزدیک تر شیم.
زیرساخت لحظه‌نگار، قبلا سه قسمت اصلی داشت:
۱. وب‌سرویس و وب‌سایت
۲. موتور استریمینگ
۳. وب‌سوکت (چت)
وب‌سرویس و وب‌سایت لحظه‌نگار
وب‌سرویس و وب‌سایت لحظه‌نگار، مثل تمام سرویس‌های اینترنتی دیگر، نقطه شروع تعامل کاربر با محصول ما بوده و هست. حتی سایر اجزا برای اینکه به درستی کار خودشون رو انجام بدند، نیازمند ارتباط با وب‌سرویس هستند.
برای این قسمت، از ابتدا تصمیم گرفتیم که به سمت Kubernetes بریم و در آینده بچه‌های تیم فنی لحظه‌نگار توی همین وبلاگ، بیشتر در موردش توضیح خواهند داد. برخی از کار‌هایی که انجام دادیم:
۱. بازبینی، بهبود و آماده‌سازی کد‌ها
۲. بازبینی و اصلاح دیتابیس
۳. Dockerize کردن
۴. راه‌اندازی کلاستر Kubernetes
۵. راه‌اندازی CI/CD
۶. HA کردن تمام Componentهای اصلی مثل MySQL, Redis, Nginx, PHP-FPM, HAProxy و …
۷. راه‌اندازی زیرساخت مانیتورینگ و آلرتینگ با Prometheus
۸. راه‌اندازی ELK برای Logging
ما قبلا از Wowza استفاده می‌کردیم که وظیفه دریافت استریم، آماده کردن اون برای تحویل و تحویل به کاربران رو بر عهده داشت.
این معماری مشکلات زیادی داشت و ما هم خیلی زود متوجه اون‌ها شدیم.
۱. ما در لحظه‌نگار از ABR استفاده می‌کنیم که نیازمند منابع زیادی هست و با رشد تعداد استریم‌های همزمان، فراهم کردن اون منابع در یک ماشین ممکن نبود. همچنین قصد داشتیم که کیفیت‌ها و Codecهای بهتری رو اضافه کنیم که باز با مشکل منابع روبرو بودیم. (جهت تصور: ۲۰استریم همزمان در ۴ کیفیت تمام منابع یک سرور ۳۲هسته‌ای ما رو درگیر می‌کنه.)
۲. موتور استریمینگ مستقیما درگیر تحویل محتوا بود، و با تعداد بالای بیننده‌های همزمان، دچار مشکل می‌شد.
۳. حدود ۲۰٪ از کاربران ما، خارج از ایران هستند (یا از VPN استفاده می‌کنند) و با توجه به مشکلات اینترنت کشور، تحویل محتوای زنده از سرور ایران به اون‌ها ممکن نبود و با مشکل مواجه می‌شدند.
۴. برخی از کاربران قصد استریم از خارج از کشور رو داشتند، که مجددا به‌دلیل اینترنت کشور، معمولا با مشکل مواجه بودند.
۵. فضای ذخیره‌سازی محدود بود و حتی با توجه به اینکه ما برای بازپخش‌ها، ABR نداشتیم، چندین مرتبه مجبور به پاک کردن بازپخش‌های قدیمی شدیم. (البته الان همه اون‌ها رو برگردوندیم)
۶. هیچ Replicationای وجود نداشت و با Down شدن Wowza، عملا سرویس ما بلااستفاده بود.
۷. Wowza با تمام امکانات خوبی که داره، پاسخ‌گوی امکاناتی که ما برای آینده برنامه‌ریزی کرده بودیم، نبود.
با در نظر گرفتن همه این موارد، از دی شروع به تحقیق و توسعه یک موتور استریمینگ اختصاصی کردیم و اسم اون رو NegarBone(نِگاربُن) گذاشتیم. چندین نسخه آزمایشی توسعه دادیم (که ۳ نسخه اول حتی برای تست هم روی سرور نرفت!). به مرور پس از تست‌های داخلی، از اوایل خرداد، در کنار Wowza برخی از استریم‌های لحظه‌نگار رو به صورت تصادفی (و انتخابی) روی NegarBone فرستادیم. نهایتا یک ماه پیش Wowza رو حذف کردیم و الان همه استریم‌های لحظه‌نگار توسط نگاربن، هندل می‌شه.
۱. تمام اجزا رو جدا کردیم تا بتونیم هر کدوم رو جدا اسکیل کنیم. بین همه اجزا هسته NegarBone هست که وظیفه هماهنگی رو برعهده داره. هسته NegarBone رو با NodeJS نوشتیم.
۲. LahzeCDN RTMP Ingest رو اضافه کردیم، که هر کاربر بتونه با توجه به موقعیت مکانی، روی یکی از سرور‌ها استریم کنه و مشکلی نداشته باشه. برای RTMP Ingest از SRS استفاده کردیم.
۳. هسته اصلی، با توجه به وضعیت منابع و موقعیت مکانی ورودی RTMP، یک Node از کلاستر Transcoding رو مسئول اون استریم قرار میده. از اون به بعد اون Node، هسته اصلی رو آپدیت می‌کنه و در جریان میذاره و به مرور فایل‌های ضبط شده برای باز‌پخش رو روی Storage آپلود می‌کنه. Transcoder رو با NodeJS، LibAV و C نوشتیم.
۴. LahzeCDN رو راه انداختیم که با دریافت استریم از Transcoder و کش کردن استریم، می‌تونه به ده‌ها هزار نفر، استریم رو تحویل بده.
۵. با توجه به محدودیت‌هایی که داشتیم و نمی‌تونستیم برای CDN از روش‌هایی مثل Anycast استفاده کنیم و Geo-Location Based DNS هم مشکلات خودش رو داشت، روی API این مورد رو کنترل کردیم. API از یک Internal Service استفاده می‌کنه و برای هر درخواستی که دریافت می‌کنه، یک CDN Endpoint اختصاص میده.
۶. داریم بررسی می‌کنیم که اگر بشه، بعضی از قسمت‌های NegarBone رو به صورت OpenSource منتشر کنیم.
وب‌سوکت (چت)
این موضوع رو بصورت کامل در این پست می‌تونید بخونید.
معرفی موتور استریمینگ نگاربن