نتفلیکس تصمیم گرفت موتور مقیاس‌پذیری بیش از ۳۰,۰۰۰ جاب استریمینگ آپاچی فلیمک خود را در چندین ناحیه AWS به نسخه اپن‌سورس منتقل کند، پس از اینکه رویکرد سنتی سطح خوشه (Cluster-level) در برابر پیچیدگی پایپ‌لاین‌های Stateful با اپراتورهای ناهمگن ناکام ماند. نتیجه: یکی از تیم‌ها موفق شد هزینه محاسبه فلیمک را ۵۸٪ کاهش داده و حدود ۱.۱ میلیون دلار در سال ذخیره کند.

از مانتیس و اتلس تا اتوسکیلر بومی فلیمک

سفر نتفلیکس با فلیمک از سال ۲۰۱۷ آغاز شد. حدود ۲۰۱۹ اولین اتوسکیلر داخلی روی پلتفرم مانتیس پیاده‌سازی شد که تلِمتری سطح خوشه — شامل CPU، شبکه، تاخیر کافکا، نرخ ورودی و مصرف — را از اتلس جمع‌آوری می‌کرد. این سیستم تعداد کل TaskManagerها را تنظیم می‌کرد و مصرف منابع را در هزاران پایپ‌لین بین ۲۵ تا ۴۵ درصد کاهش داد.

مقایسه معماری دو اتوسکیلر فلیمک در نتفلیکس

محدودیت واحد مقیاس‌پذیری: وقتی همه اپراتورها یک سرنوشت مشترک دارند

مشکل اصلی در «واحد مقیاس‌پذیری» نهفته بود. اتوسکیلر قدیمی درباره کل خوشه استدلال می‌کرد، نه اپراتورهای جداگانه. در نتیجه تمام اپراتورهای یک جاب تصمیم مقیاس‌پذیری مشترکی داشتند. برای پایپ‌لاین‌های ساده شاید کار کند، اما برای جاب‌های Stateful حاوی شاخه‌ها، جوین‌ها و ترابایت‌های State — که بخش‌های مختلف دیتافلو نیازمندی‌های پردازش کاملاً متفاوتی دارند — این رویکرد بی‌عمل می‌شود.

نرخ پردازش واقعی (True Processing Rate): کلید اتوسکیلر اپن‌سورس

اتوسکیلر جدید فلیمک، که در FLIP-271 مستند شده، مسیر دیگری را می‌پیرد. از متریک‌های جاب در حال اجرا برای تخمین «نرخ پردازش واقعی» هر اپراتور از طریق سوگناما (Throughput) و زمان پرشغلی (Busy Time) استفاده می‌کند. سپس گراف جاب (Job Graph) را پیمایش کرده و موازی‌سازی مورد نیاز برای هر رأس (Vertex) را به‌صورت جداگانه محاسبه می‌کند.

ریشه‌های این ایده به پروژه DS2 برمی‌گردد. واسیلِی کالاوری، محقق سیستمی عضو تیم، توضیح می‌دهد: «ابتدا تحلیل مسیر بحرانی (Critical Path Analysis) را بررسی کردیم، اما فهمیدیم نرخ پردازش واقعی به عنوان یک خط پایه ساده، فوق‌العاده کار می‌کند.» این سادگی بعداً ستون فقرات کار اتوسکیلینگ فلیمک شد.

معماری اتوسکیلر فلیمک مبتنی بر OSS با Temporal workflows

یکپارچه‌سازی با کنترل‌پلین داخلی و چالش‌های مقیاس بزرگ

نتفلیکس اتوسکیلر را مستقیماً از طریق اپراتور کوبرنتیز فلیمک مستقر نکرد. به جای آن، یک سرویس Spring Boot از Temporal workflows برای جداسازی تصمیمات اتوسکیلینگ برای جاب‌های جداگانه بهره می‌برد. تغییرات فنی دیگری نیز اعمال شده:

  • جمع‌آوری متریک JobManager برای پشتیبانی از جاب‌های با تا ۳,۰۰۰ Subtask بازنویسی شد
  • فیلترینگ متریک سمت سرور اضافه شد
  • زیرگراف‌های Forward Connected در طول مقیاس‌پذیری حفظ می‌شوند
  • مدیریت بک‌فشار سینک (Sink Backpressure) پیاده‌سازی شد

مسئله اتصال Forward و FLINK-38538

تغییر موازی‌سازی در سراسر یک اتصال FORWARD می‌تواند نیاز به توزیع مجدد (Redistribution) داده‌ها داشته باشد. پیاده‌سازی نتفلیکس اپراتورهای forward connected را به‌صورت یکپارچه نگه می‌دارد تا از این سربار جلوگیری کند. یک Issue باز با شناسه FLINK-38538 نیز مواردی را برجسته می‌کند که در آن اپراتورهای پرشغال تحت تأثیر تصمیمات مقیاس‌پذیری مبتنی بر نسبت خروجی قرار می‌گیرند.

DAG جاب فلیمک با موازی‌سازی فعلی و مورد نظر برای هر Vertex

تفاوت با KEDA و استراتژی مقیاس‌پذیری محافظه‌کارانه

برخلاف اتوسکیلرهای رویدادمحور عمومی مانند KEDA، که بارهای کاری را بر اساس متریک‌ها یا رویدادهای خارجی مقیاس‌پذیری می‌کنند، اتوسکیلر فلیمک درباره گراف دیتافلو داخلی و ظرفیت اپراتورها استدلال می‌کند. نتفلیکس در حال حاضر از هدف استفاده (Utilization Target) ۰.۴۵ استفاده می‌کند — کمتر از پیش‌فرض ۰.۷ جامعه فلیمک — تا مقیاس‌پذیری مجدد агресив (شدید) جاب‌های Stateful بزرگ را که هزینه بازیابی State بالایی دارند، مهار کند.

نگاه به آینده: فلیمک ۲ و معماری State تفکیک‌شده

شرکت قصد دارد موارد استفاده باقی‌مانده اتوسکیلینگ داخلی را به پیاده‌سازی اپن‌سورس مهاجرت دهد. در موازاة، معماری State تفکیک‌شده (Disaggregated State) فلیمک ۲ مورد بررسی قرار می‌گیرد تا هزینه بازیابی State در طول مقیاس‌پذیری مجدد — یکی از چالش‌های اصلی استریمینگ در مقیاس انبوه — را به طور بنیادین کاهش دهد.