نتفلیکس بخش عمدهٔ بارهای دسته‌ای خود را از راه‌حل درون‌سازمانی Compute Managed Batch (CMB) به Kueue، سیستم متن‌باز و بومی Kubernetes برای اجرای دسته‌ای، منتقل کرد. مهندسان قابلیت‌های داخلی را به معادل‌های Kueue نگاشتند و با حفظ سازگاری API، مهاجرتی تدریجی و بدون اختلال برای کاربران فراهم کردند.

چرایی مهاجرت از CMB به Kueue

از سال 2018 نتفلیکس از CMB برای مدیریت کارهای دسته‌ای روی پلتفرم کانتینری Titus استفاده می‌کرد. CMB با سلسله‌مراتب مستأجران ظرفیت را مدیریت و بارها را بین چند سل (خوشهٔ Kubernetes) فدره می‌کرد، اما بسیاری از قابلیت‌های کلیدی آن در پروژه‌های متن‌باز اکوسیستم Kubernetes توسعه یافته‌اند.

تیم مهندسی متوجه شد افزودن قابلیت‌های جدید در CMB دشوار است، زیرا یکپارچگی کافی با Kubernetes نداشت. Kueue از جمله امکاناتی مانند صف‌بندی با سیاست‌های اولویت، مدیریت پیشرفتهٔ منابع، زمان‌بندی چندخوشه‌ای و مشاهده‌پذیری بهتر را ارائه می‌دهد و به‌دلیل پذیرش گسترده و سرعت نوآوری، گزینهٔ مناسب‌تری شد. کد و مستندات Kueue در GitHub در دسترس است.

چیدمان مهاجرت و نگاشت مفاهیم

فرایند مهاجرت شفاف و با هدف حداقل‌سازی اختلال برای کاربران طراحی شد. سطح پشتیبانی لازم برای نرخ راه‌اندازی کانتینر و توان عملیاتی تعریف و تضمین شد. مهاجرت به‌صورت مستأجری (tenant-bound) انجام گرفت و مکانیزم بازگشت (rollback) آسان برای کاهش ریسک آماده شد.

نگاشت مفهومی به‌صورت زیر انجام شد: مستأجران داخلی در CMB به Cohort در Kueue نگاشت شدند و مستأجران برگ (leaf tenants) به ترکیب منابع ClusterQueue و LocalQueue تبدیل گشتند. انواع منابع (resource flavors) و سهمیه‌های اسمی برای بازتولید نیازمندی‌های ظرفیتی از CMB پیکربندی شدند تا رفتار و ضمانت‌های ظرفیت حفظ شود.

معماری نگاشت CMB به Kueue و منابع ClusterQueue

مقیاس و افزایش بهره‌وری منابع

نتفلیکس اکنون میلیون‌ها بار کاری دسته‌ای را با Kueue در تولید مدیریت می‌کند و فرایند مهاجرت همچنان ادامه دارد. یکی از نتایج مهم، افزایش میانگین استفاده از منابع از طریق سازوکاری مبتنی بر «تقسیم منصفانه مبتنی بر پیش‌دستی» بود؛ این مکانیزم ضمن حفظ معنای رزرو، ظرفیت بیکار را به سایر مستأجران اختصاص می‌دهد تا بهره‌وری کلی سیستم افزایش یابد.

نمایی از داشبورد مشاهده‌پذیری و مترک‌ها در پلتفرم

نکات کلیدی تجربهٔ مهاجرت

  • انتقال شروعی از پیچیده‌ترین مشتری: اولویت‌دهی به بزرگ‌ترین و پیچیده‌ترین مشتری باعث کسب اطمینان عملیاتی شد و مهاجرت تولیدی را در حدود چهار هفته ممکن کرد.
  • حفظ سازگاری API: ثابت نگه‌داشتن API سطح تجربهٔ کاربری را یکپارچه نگه داشت و ریسک‌های پذیرش را کاهش داد.
  • آزمون بار خارج از تولید: اجرای تست‌های بار و شبیه‌سازی در محیط غیرتولیدی امکان تنظیم دقیق پارامترهای عملکردی را فراهم کرد تا نیازمندی‌های توان عملیاتی برآورده شوند.
مهندسان در حال آزمایش و بهینه‌سازی پیکربندی‌ها برای مهاجرت

چشم‌انداز

این انتقال نمایانگر گرایش گسترده‌تر به راه‌حل‌های بومی Kubernetes است؛ راه‌حل‌هایی که از مزایای اکوسیستم متن‌باز بهره می‌برند و امکان همگام‌سازی سریع با نوآوری‌های جامعهٔ متن‌باز را فراهم می‌کنند. با تکمیل مهاجرت، نتفلیکس قادر خواهد بود سریع‌تر قابلیت‌های جدید را پیاده‌سازی کند و هزینهٔ نگهداری کدهای سفارشی را کاهش دهد؛ همچنین مشارکت در پروژه‌هایی مانند Kueue به سود کل جامعهٔ زیرساخت ابری خواهد بود.

گزارش فنی تیم نتفلیکس در بلاگ فناوری نتفلیکس منتشر شده و برای مطالعهٔ جزئیات بیشتر در دسترس است.