معرفی معماری Service Topology نتفلیکس

ر دنیای توسعه نرم‌افزار، معماری میکروسرویس شبیه به یک شمشیر دولبه است. وقتی همه‌چیز به درستی کار می‌کند، سرعت توسعه و مقیاس‌پذیری بی‌نظیر است؛ اما کافی است در سیستمی با هزاران سرویس درهم‌تنیده یک قطعی رخ دهد تا مهندسان با یک کابوس تمام‌عیار مواجه شوند. پیدا کردن ریشه خطا (Root Cause) در این جنگلِ ارتباطات، یکی از بزرگترین چالش‌های مهندسیِ قابلیت اطمینان سایت (SRE) است.

نتفلیکس که ترافیک آن بخش عظیمی از پهنای باند کل اینترنت را تشکیل می‌دهد، اخیراً پرده از معماری سیستم داخلی جدیدی به نام Service Topology برداشته است. این سیستم با خلق یک گراف زنده و لحظه‌ای از وابستگی هزاران میکروسرویس، به مهندسان نشان می‌دهد که در زیر پوست این پلتفرم عظیم دقیقاً چه می‌گذرد.

ریشه مشکل: چهار سال سردرگمی در پشتیبانی مهندسی

انگیزه اصلی ساخت این پلتفرم، تحلیل الگوی پرتکرارِ درخواست‌های پشتیبانی مهندسان نتفلیکس طی چهار سال گذشته بود. مهندسان در زمان بروز خطا یا افت پرفورمنس، همیشه با سه معمای حل‌نشده روبه‌رو بودند: ۱. سرویس‌ها دقیقاً در این لحظه چه وابستگی‌هایی به هم دارند؟ ۲. شعاع تخریب (Blast Radius) یک تغییرِ کانفیگ یا قطعی چقدر است؟ ۳. آیا این خطا از داخل خود سرویس (Local) نشأت گرفته یا ریشه در یک سرویس بالادستی (Upstream) دارد؟

تا پیش از این، پاسخ به این سوالات نیازمند زیر و رو کردن ابزارهای رایج مانیتورینگ بود. لاگ‌ها، متریک‌ها و تریس‌ها هر کدام تکه‌ای از پازل را در اختیار داشتند، اما هیچ‌کدام قادر نبودند تصویر یکپارچه و واضحی از نحوه اتصال سرویس‌ها در زمان اجرا (Runtime) ارائه دهند.

سه‌گانه طلاییِ نتفلیکس برای کشف حقیقت

برای حل این نقطه کور، نتفلیکس متوجه شد که هیچ منبع داده‌ای به تنهایی بی‌نقص نیست. بنابراین معماری خود را بر پایه ترکیب (Merge) سه منبع کاملاً مجزا بنا کرد که هر لایه، نقاط ضعف لایه دیگر را پوشش می‌دهد:

• ۱. لاگ‌های جریان شبکه در سطح کرنل (eBPF): این فناوری در پایین‌ترین سطح سیستم‌عامل کار می‌کند و تمام ترافیک شبکه را می‌بلعد. مزیت eBPF این است که یک دید صددرصدی و کامل به مهندسان می‌دهد، حتی اگر برنامه‌نویسانِ یک اپلیکیشن فراموش کرده باشند کدهای مانیتورینگ را در برنامه خود پیاده کنند. اما نقطه‌ضعفش این است که «کور» است؛ یعنی کانتکست اپلیکیشن را نمی‌داند و مثلاً متوجه نمی‌شود کدام API Endpoint مشخص در حال فراخوانی است.
• ۲. متریک‌های ارتباط درون‌پردازشی (IPC): این متریک‌ها که توسط خود سرویس‌ها ساطع (Emit) می‌شوند، دقیقاً جزئیات پروتکل و اندپوینت‌ها را فاش می‌کنند. اما محدودیت آن‌ها این است که فقط برای سرویس‌هایی کار می‌کنند که از قبل ابزارهای مانیتورینگ (Instrumentation) روی آن‌ها نصب شده باشد.
• ۳. تریس‌های توزیع‌شده (Distributed Traces): این لایه مسیر واقعی ریکوئست‌ها را (از جمله انشعاب‌های شرطی در کد) به دقت نشان می‌دهد. اما به دلیل حجم وحشتناک داده‌ها، نتفلیکس مجبور است آن‌ها را به صورت نمونه‌برداری (Sampling) جمع‌آوری کند، در نتیجه همیشه تصویر کاملی ارائه نمی‌دهند.

در سیستم Service Topology، مهندسان می‌توانند در زمان کوئری گرفتن، این سه لایه را به صورت موازی با هم ترکیب کنند تا یک گراف بی‌نقص از وضعیت شبکه به دست آورند.

معماری پایپ‌لاین: دور زدن لودبالانسرها برای رسیدن به کد

یکی از چالش‌های فنیِ جذاب در نقشه‌برداری شبکه، حضور واسطه‌هاست. داده‌های خام شبکه مسیر ترافیک را از طریق درگاه‌های NAT و لودبالانسرها (Load Balancers) نشان می‌دهند. اما برای یک برنامه‌نویس که به دنبال باگ می‌گردد، دیدن لودبالانسر در نقشه کاملاً گیج‌کننده است؛ او فقط می‌خواهد بداند «سرویس A» مستقیماً با چه پروتکلی با «سرویس B» حرف می‌زند.

نتفلیکس برای حل این معضل، یک پایپ‌لاین تجمیع داده طراحی کرده است که روی Apache Pekko Streams و کانسومرهای چندمنطقه‌ایِ Kafka اجرا می‌شود. در مرحله دوم این پایپ‌لاین (Intermediary Resolution)، مسیرهای چندمرحله‌ایِ شبکه فشرده (Collapse) می‌شوند و واسطه‌ها به صورت خودکار حذف می‌گردند تا لبه‌های گراف مستقیماً اپلیکیشن‌ها را به هم وصل کنند. این پردازش مرحله‌ای باعث می‌شود سیستم زیر بارِ سنگینِ ترافیکِ لودبالانسرها دچار گلوگاه نشود.

داده‌های نهایی در یک دیتابیس توزیع‌شده گراف‌محور (توسعه‌یافته توسط خود نتفلیکس) ذخیره می‌شوند. خروجی نیز از طریق یک gRPC API با سرعت پاسخ‌گویی زیر یک ثانیه (Sub-second) در اختیار مهندسان قرار می‌گیرد و از کوئری‌های پیچیده و فیلتر بر اساس دامین بیزینسی پشتیبانی می‌کند.

ماشین زمان مهندسی

گرفتن اسنپ‌شات (Snapshot) مداوم از گرافِ شبکه‌ای به این وسعت، هزینه‌های ذخیره‌سازی را به شدت بالا می‌برد. راهکار نتفلیکس، استفاده از روش «تجمیع پنجره‌زمانی» (Time-window Aggregation) است. این قابلیت جذاب به مهندسان اجازه می‌دهد در زمان سفر کنند؛ مثلاً گراف شبکه را دقیقاً در ساعت ۲:۱۵ بامداد (لحظه شروع یک Incident) لود کنند و تغییرات وابستگی‌ها را با شروع قطعی سیستم تطبیق دهند.

درس‌آموخته‌ها؛ چرا ابزارهای آماده شکست خوردند؟

تیم مهندسی نتفلیکس تأکید می‌کند که این سیستم، حاصل درس گرفتن از چندین تلاش شکست‌خورده است:

• مرگ نقشه‌های استاتیک: در محیطی که کدها روزی ده‌ها بار دیپلوی می‌شوند، نقشه‌های ایستا یا با تأخیر، عملاً هیچ ارزشی ندارند.
• دیوار مقیاس‌پذیری: ابزارهای آماده‌ای که در مقیاس‌های کوچکتر عالی کار می‌کردند، زیر بارِ ترافیک و تعداد سرویس‌های نتفلیکس کاملاً فلج شدند.
• دیتای ناقص، بدتر از بی‌دیتایی: آن‌ها به یک قانون طلایی رسیدند: داشتن نقشه وابستگی ناقص یا اشتباه، بسیار خطرناک‌تر از نداشتن نقشه است؛ زیرا در زمان بحران، مهندسان را به مسیرهای کاملاً اشتباه هدایت کرده و زمان بازیابی (MTTR) را طولانی‌تر می‌کند.

نگاهی به آینده: هوش مصنوعی و RCA خودکار

انتشار این مقاله فنی از سوی نتفلیکس اتفاق نادری در صنعت است. اکثر شرکت‌ها معماری درنگ‌درنگ (Real-time) خود را در این سطحِ وسیع، به عنوان یک مزیت رقابتیِ به شدت محرمانه نگه می‌دارند. بیشتر مستندات فعلی صنعت، گراف‌ها را صرفاً یک زیرساخت جانبی (مثلاً برای تأمین کانتکستِ ایجنت‌های AI) می‌دانند.

اما نتفلیکس نقشه‌های بزرگتری دارد. در قدم بعدی، آن‌ها قصد دارند رویدادهای مربوط به دیپلوی و تغییرات کانفیگ را هم به این گراف تزریق کنند. هدف نهایی، خلق یک سیستم تحلیل خودکار ریشه‌یابی خطا (Automated RCA) است؛ سیستمی که به محض بروز خطای 500، به گراف شبکه نگاه می‌کند و به جای انسان تشخیص می‌دهد که کدام دیپلوی در کدام میکروسرویسِ بالادستی، باعث بروز این فاجعه شده است.