با بیش از ۲۷۵ میلیون مشترک در سراسر جهان، نتفلیکس همچنان یک غول پخش استریمینگ به شمار می‌رود. اگر هنوز به این موضوع مطمئن نیستید، کافی است این رقم را با ۲۰۰ میلیون مشترک Prime Video یا Disney+، Hulu و ESPN+ که مجموعاً ۲۲۹ میلیون مشترک دارند مقایسه کنید.
و حتی با اینکه نتفلیکس اولین سرویس ویدئو بر اساس تقاضا نبود (Prime Video آمازون در سپتامبر ۲۰۰۶ و اولین نسخه یوتیوب در پایان ۲۰۰۵ راه‌اندازی شد)، نتفلیکس همچنان پادشاه است. تقریباً ۶۰٪ خانوارهای بریتانیا حداقل یک بیننده نتفلیکس دارند.
پس چگونه شرکتی که بلاک‌باستر یک بار پیشنهاد خرید آن به مبلغ ۵۰ میلیون دلار را رد کرد، تبدیل به شرکتی با ارزش ۱۵۰ میلیارد دلار شد؟ سریال‌های محبوب، مثل آن با دوستان در نیویورک، و محتواهای اورجینال، مثل گروهی از دوستان که همواره با اتفاقات عجیب در یک شهر کوچک ایندیانا مواجه می‌شوند، بدون شک بخشی از دلایل هستند.
اما همان‌طور که ویدیا اروایند از نتفلیکس در سمینار Austin API 2024 توضیح داد، این‌ها تنها دلایل موفقیت انفجاری نتفلیکس نیستند. بخش بزرگی از موفقیت برند، به رویکرد انتزاع داده و API-first آن بازمی‌گردد.
در ادامه، ما به بررسی ساختار فنی شرکت می‌پردازیم تا راه‌هایی برای تقلید از چابکی و توانایی مقیاس‌بندی آن‌ها پیدا کنیم.
رویکرد API-First نتفلیکس
ما پیش‌تر درباره رشد شرکت‌های API-first نوشته‌ایم و نتفلیکس را به‌عنوان یکی از این نمونه‌ها معرفی کرده‌ایم.
نسخه کوتاه داستان این است: با شکستن سیستم‌های مونولیتیک خود، نتفلیکس یک API جداشده و قابل توسعه ایجاد کرد که می‌تواند از طیف وسیعی از دستگاه‌ها بدون نیاز به DVD یا اپلیکیشن‌های اختصاصی دسترسی پیدا کند.
در سال ۲۰۲۱، ما نوشتیم که نتفلیکس از GraphQL Microservices (GQLMS) به‌عنوان بک‌اند استفاده کرده تا مزایایی از جمله افزایش درک سازمانی و استقرار سریع‌تر به دست آورد. توجه داشته باشید که GraphQL تنها در سال ۲۰۱۵ به‌صورت متن‌باز منتشر شد و سپس در سال ۲۰۱۸ به بنیاد GraphQL منتقل شد. این تجربیات نشان می‌دهد که نتفلیکس هرگز از استفاده از تکنولوژی جدید برای کسب مزیت رقابتی خودداری نکرده است.
البته استفاده از صدها میکروسرویس — نتفلیکس در حال حاضر بیش از ۱۰۰۰ مورد استفاده می‌کند — می‌تواند پیچیدگی، مشکلات ترجمه داده و خرابی‌های زنجیره‌ای ایجاد کند. انتزاع داده یکی از روش‌هایی است که نتفلیکس برای کاهش این ریسک‌ها استفاده کرده است.
استفاده‌های بیشتر، مشکلات بیشتر
اگر بخواهید، می‌توانید نتفلیکس را روی هر چیزی از دستگاه‌های قدیمی Roku گرفته تا یخچال‌های هوشمند مشاهده کنید. این انعطاف‌پذیری یکی از بزرگ‌ترین نقاط قوت نتفلیکس است، اما در عین حال مشکل بزرگی برای خود شرکت ایجاد می‌کند: سناریوهای استفاده بسیار متنوع.
اروایند به‌طور خاص اشاره می‌کند که وقتی تدابیر انتزاعی وجود ندارد، هر برنامه باید بتواند فرمت‌های مختلف داده را از طیف گسترده‌ای از APIها درک کند. این به معنای تلاش اضافی برای تیم‌های کلاینت است که ممکن است نیاز داشته باشند با همه این APIها کار کنند.
به عبارت دیگر، تیم‌های کلاینت باید با «زبان‌های مختلف، لبه‌های خشن، پارامترهای تنظیم» و غیره آشنا شوند. برای حل این مشکل، اروایند دو پرسش مطرح می‌کند:
-
«آیا می‌توانیم الگوهای مشترک را گرفته و راه‌حل مشترک ارائه دهیم؟»
-
«آیا راه‌حل می‌تواند عمومی و بدون وابستگی به ذخیره‌سازی باشد؟»
اجزای انتزاع و مجازی‌سازی
یکی از راه‌حل‌ها، معرفی لایه‌های انتزاع داده است. با انتزاع، شما یک سیستم پیچیده را به بخش‌های کوچک با مرزهای تعریف‌شده تقسیم می‌کنید. اروایند توضیح می‌دهد که انتزاع و مجازی‌سازی می‌توانند در سیستم‌های توزیع‌شده با امکان جابجایی بین پیاده‌سازی‌ها و لایه‌بندی سیستم‌ها برای حل مشکلات بزرگ‌تر کمک کنند.
این کار می‌تواند با استفاده از یک دروازه داده به‌عنوان سرور انتزاع انجام شود تا آنچه بین برنامه کلاینت و موتورهای ذخیره‌سازی/APIها رخ می‌دهد، مخفی بماند. اروایند سه مؤلفه اصلی انتزاع را چنین بیان می‌کند: یک کلاینت انتزاع که در برنامه کلاینت قرار دارد، یک دروازه (سرور انتزاع) و یک کنترل‌پلن.
او تأکید می‌کند: «وقتی بسیاری از برنامه‌ها به یک لایه انتزاعی متصل هستند، می‌تواند یک نقطه شکست ایجاد کند. بنابراین باید فکر کنیم چگونه می‌توانیم این‌ها را به‌گونه‌ای پیاده‌سازی کنیم که جداسازی و جلوگیری از مشکل همسایه پرصدا را فراهم کند.»
یکی از روش‌های دستیابی به این جداسازی، شاردینگ است. در اینجا، مجموعه‌های مختلفی از برنامه‌ها به لایه‌های انتزاعی خود متصل می‌شوند و یک کنترل‌پلن می‌داند چگونه با بانک‌های اطلاعاتی مختلف صحبت کند، که باعث دستیابی به جداسازی موردنظر می‌شود.
اروایند همچنین تأکید می‌کند که نباید انتزاع را یک سرور ساده در نظر گرفت. در واقع، می‌توان از فرآیندهای مختلف مانند انتزاع کلید-مقدار (KV)، انتزاع درختی (همراه با KV) یا شخصی‌سازی UI (همراه با KV) برای افزودن لایه‌های اضافی استفاده کرد.
آسان‌تر کردن مهاجرت با انتزاع
اروایند توضیح می‌دهد که انتزاع می‌تواند برای Shadow Writing استفاده شود که مهاجرت را آسان‌تر می‌کند. او می‌گوید: «مهاجرت‌ها دردناک هستند. تقریباً یک سال و نیم طول کشید تا ما ۲۵۰ خوشه Cassandra را از Cassandra 2.0 به ۳.۰ منتقل کنیم.»
با Shadow Writing، او ادامه می‌دهد: «ما با DB1 شروع می‌کنیم، تنها پیاده‌سازی شما. سپس DB2 را اضافه می‌کنیم و اکنون با هر دو بانک اطلاعاتی به‌طور موازی صحبت می‌کنیم. داده‌ها از DB2 به DB1 منتقل می‌شوند تا پشتیبانی شود. همه این‌ها بدون دخالت کلاینت انجام می‌شود. سپس DB2 را به عنوان اصلی ترفیع می‌دهیم و در این نقطه DB1 غیر فعال می‌شود.»
اروایند تأکید می‌کند که «API شما قرارداد شما با کلاینت است. بدون توجه به تعداد لایه‌های انتزاعی، شما باید API تمیز و ساده‌ای در سمت کلاینت داشته باشید تا بدون اطلاع از پشت صحنه از آن استفاده کنند.» در مورد نتفلیکس، همه این عملیات پشت صحنه در یک UI یکپارچه و ساده بسته‌بندی شده است.
آغاز مسیر انتزاع
اروایند در پایان درباره اجزای اصلی KV انتزاع صحبت می‌کند:
-
Chunking
-
فشرده‌سازی
-
کشینگ و Nearline Caching
-
Adaptive Pagination
-
سیگنال‌دهی و SLO Signaling
-
Summarization
-
Dictionary Compression
و با نقل‌قولی از مارک اندرسن پایان می‌دهد:
«هر لایه جدید انتزاع، فرصتی برای بازطراحی کامل همه چیز است، که همه چیز را کمی سریع‌تر، کم‌مصرف‌تر، زیباتر، آسان‌تر برای استفاده و ارزان‌تر می‌کند.»
اگرچه اکثر توسعه‌دهندگان API نیازی به مقیاس‌بندی به اندازه نتفلیکس ندارند، انتزاع ابزار ارزشمندی است زیرا انعطاف‌پذیری بیشتری در ارائه سرویس فراهم می‌کند.
وقتی یک endpoint یک برنامه مصرف‌کننده را از زیرساخت جدا می‌کند، امکان ایجاد تغییرات پشت صحنه بدون تأثیر منفی بر API فراهم می‌شود. همچنین با حرکت به سمت چارچوب‌های متادیتای مشترک و مدل‌سازی بدون وابستگی به زبان، انتزاع مکمل ایده API-first به‌شمار می‌آید.
