برسی معماری زیرساخت ردیابی توزیع شده در Netflix

در این مطلب نحوه ایجاد زیرساخت ردیابی توزیع شده توسط نتفلیکس شرح داده می‌شود.

چکیده

به دلیل معماری پیچیده میکروسرویس‌های نتفلیکس، ردیابی توزیع‌شده مورد نیاز است:

• عیب یابی: ردیابی توزیع‌شده مانند یک GPS برای خطاها عمل می‌کند، ریشه اصلی را در سراسر سرویس‌ها مشخص می‌کند و نشان می‌دهد که آنها چگونه بر تجربه کاربر تأثیر می‌گذارند.
• بهینه‌سازی عملکرد: ردیابی به شناسایی گلوگاه‌ها و روابط میان Stream های گوناگون کمک می‌کند و کمک میکند همه چیز روان‌تر اجرا شود.
• مانیتورینگ: ردیابی توزیع‌شده به نتفلیکس یک view به صورت real-time از وضعیت خدمات ارائه می‌دهد و به آنها اجازه می‌دهد قبل از اینکه مشکلات بر کاربران تأثیر بگذارد، آنها را برطرف کنند.

به طور خلاصه، ردیابی توزیع‌شده نتفلیکس را قادر می‌سازد تا پلتفرم خود را کارآمد، قابل اعتماد و برای کاربران مفید نگه دارد.

۱- مقدمه

مشکل:

• مهندسان نتفلیکس برای بررسی ایرادات استریم داده‌ها مجبور به بررسی حجم عظیمی از داده‌ها و لاگ‌ها بودند.
• این فرآیند زمان‌بر، طاقت‌فرسا و مستعد خطا بود.

راه‌حل:

• استفاده از ردیابی توزیع‌شده برای جمع‌آوری و تجزیه و تحلیل داده‌های مربوط به تراکنش‌ها در سراسر سیستم.
• انتخاب ابزار Open-Zipkin به عنوان یک ابزار منبع باز محبوب برای ردیابی توزیع‌شده.

مزایای استفاده از ردیابی توزیع‌شده:

• شناسایی سریع‌تر ریشه ایرادات: با ردیابی مسیر درخواست در سراسر سیستم، می‌توان به سرعت محل بروز مشکل را مشخص کرد.
• کاهش زمان رفع ایراد: با تجزیه و تحلیل داده‌های جمع‌آوری شده، می‌توان به طور موثرتری اقدام به رفع ایراد نمود.
• بهبود عملکرد سیستم: با شناسایی گلوگاه‌ها و ناکارآمدی‌ها، می‌توان عملکرد سیستم را ارتقا داد.

در شروع کار ابزار open-source زیادی وجود نداشت ولی تا سال ۲۰۱۷ ابزار های نسبتا خوبی توسعه داده شد مانند Open-Tracing و Open-Zipkin. نتفلیکس Open-Zipkin را انتخاب کرد.

سه بخش اصلی زیرساخت:

1. کتابخانه‌های Tracer:

• این کتابخانه‌ها به کد برنامه اضافه می‌شوند و وظیفه جمع‌آوری اطلاعات مربوط به تراکنش‌ها را بر عهده دارند.
• اطلاعات جمع‌آوری شده شامل شناسه تراکنش، زمان شروع و پایان، نام و مدت زمان هر مرحله از تراکنش و… می‌شود.

2. پردازش استریم:

• داده‌های جمع‌آوری شده توسط کتابخانه‌های Tracer به سیستم پردازش استریم ارسال می‌شوند.
• این سیستم وظیفه پردازش و تجزیه و تحلیل داده‌های بلادرنگ را بر عهده دارد.

3. ذخیره‌سازی:

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

در ادامه درباره هر بخش و چالش های آن، توضیح می‌دهیم.

۲- بخش های اصلی زیرساخت

۲.۱ - کتابخانه Trace

وظایف کتابخانه trace:

• نظارت بر تمام درخواست‌ها: این کتابخانه وظیفه رصد و جمع‌آوری اطلاعات مربوط به تمام درخواست‌هایی که از سرویس‌های استریم عبور می‌کنند را بر عهده دارد.
• ایجاد امکان ادغام آسان: کتابخانه trace به گونه‌ای طراحی شده است که به سادگی با سرویس‌های در حال اجرا ادغام شود.

نحوه عملکرد کتابخانه trace:

• جمع آوری با استفاده از رصد IPC و درخواست‌های کلاینت: کتابخانه trace برای جمع‌آوری اطلاعات از دو روش IPC (ارتباط بین فرآیندی) محلی و درخواست‌های کلاینت‌ها به میکروسرویس‌ها استفاده می‌کند.
• اضافه کردن برچسب‌های مرتبط با زیرساخت: محیط در حال اجرا، برچسب‌های مرتبط با زیرساخت مانند نام سرویس، گروه auto-scaling (ASG) و آیدی کانتینر را به اطلاعات جمع‌آوری شده اضافه می‌کند.
• استفاده از اطلاعات برای کوئری و join کردن لاگ‌ها: اطلاعات جمع‌آوری شده و برچسب‌گذاری شده برای کوئری زدن و join کردن اطلاعات لاگ‌ها به منظور تجزیه و تحلیل و عیب‌یابی استفاده می‌شود.

نکات تکمیلی:

• کتابخانه trace نقش کلیدی در ردیابی توزیع‌شده ایفا می‌کند و به جمع‌آوری اطلاعات مربوط به تراکنش‌ها در سراسر سیستم کمک می‌کند.
• زیر نظر داشتن IPC و درخواست‌های کلاینت، کتابخانه trace را به یک ابزار انعطاف‌پذیر برای ادغام با انواع مختلف سرویس‌ها تبدیل می‌کند.
• اضافه کردن برچسب‌های مرتبط با زیرساخت، امکان جستجو و فیلتر کردن اطلاعات لاگ‌ها را به منظور عیب‌یابی دقیق‌تر فراهم می‌کند.

مزایای استفاده از کتابخانه trace:

• شناسایی سریع‌تر ریشه ایرادات: با ردیابی مسیر درخواست در سراسر سیستم، می‌توان به سرعت محل بروز مشکل را مشخص کرد.
• کاهش زمان رفع ایراد: با تجزیه و تحلیل داده‌های جمع‌آوری شده، می‌توان به طور موثرتری اقدام به رفع ایراد نمود.
• بهبود عملکرد سیستم: با شناسایی گلوگاه‌ها و ناکارآمدی‌ها، می‌توان عملکرد سیستم را ارتقا داد.

۲.۲- پردازش استریم

چالش‌های پردازش استریم:

• حجم بالای داده‌ها: ردیابی توزیع‌شده می‌تواند حجم عظیمی از داده‌ها را تولید کند.
• نیاز به تجزیه و تحلیل بلادرنگ: برای عیب‌یابی سریع و موثر، لازم است داده‌ها به صورت بلادرنگ تجزیه و تحلیل شوند.
• مصرف منابع: پردازش و تجزیه و تحلیل حجم بالای داده‌ها می‌تواند به مصرف قابل توجه CPU، حافظه و سایر منابع سیستم منجر شود.

راه‌حل‌های تیم نتفلیکس:

1. استفاده از ابزار Mantis:

• ابزار Mantis، ابزاری منبع باز است که توسط نتفلیکس برای مدیریت و پردازش داده‌های ردیابی توزیع‌شده توسعه یافته است.
• ابزار Mantis، به طور خاص برای غلبه بر چالش‌های پردازش استریم در مقیاس بزرگ طراحی شده است.

2. بافر کردن و پردازش همزمان:

• ابزار Mantis داده‌های ردیابی را در حافظه بافر می‌کند و آنها را به صورت همزمان پردازش می‌کند.
• این رویکرد به کاهش تاخیر و افزایش کارایی پردازش کمک می‌کند.

3. استفاده از MQL برای کاوش در داده‌ها:

• زبان MQL (Mantis Query Language) یک زبان کوئری مشابه SQL است که برای تجزیه و تحلیل داده‌های ردیابی در Mantis استفاده می‌شود.
• زبان MQL به کاربران امکان می‌دهد به طور دقیق و کارآمد داده‌ها را جستجو و فیلتر کنند و اطلاعات مورد نیاز خود را برای عیب‌یابی و رفع مشکلات پیدا کنند.

مزایای استفاده از راه‌حل‌های تیم نتفلیکس:

• کاهش حجم داده‌ها: Mantis با استفاده از تکنیک‌های فشرده‌سازی و نمونه‌گیری، حجم داده‌های جمع‌آوری شده را به طور قابل توجهی کاهش می‌دهد.
• تجزیه و تحلیل بلادرنگ: Mantis با استفاده از پردازش همزمان، امکان تجزیه و تحلیل داده‌ها را به صورت بلادرنگ فراهم می‌کند.
• کاهش مصرف منابع: Mantis با استفاده از تکنیک‌های مختلف بهینه‌سازی، مصرف CPU، حافظه و سایر منابع را به حداقل می‌رساند.

نکات تکمیلی

• پردازش استریم یک بخش حیاتی از ردیابی توزیع‌شده است و به تجزیه و تحلیل داده‌ها در زمان واقعی برای عیب‌یابی و رفع مشکلات کمک می‌کند.
• ابزار Mantis و زبان MQL ابزارهای قدرتمندی هستند که به تیم‌های مهندسی برای مدیریت و پردازش داده‌های ردیابی توزیع‌شده در مقیاس بزرگ کمک می‌کنند.

۲.۳ ذخیره سازی

چالش‌های ذخیره‌سازی داده‌ها:

1. رشد حجم داده‌ها:

• با رشد تعداد و محبوبیت سرویس‌های استریم، حجم داده‌های ردیابی شده به طور قابل توجهی افزایش یافت.
• این حجم از داده‌ها از ظرفیت کلاسترهای Elasticsearch که در ابتدا در نظر گرفته شده بود، فراتر رفت.

2. مقیاس‌پذیری:

• تغییر مقیاس کلاسترهای Elasticsearch به منظور افزایش ظرفیت ذخیره‌سازی، فرآیندی پیچیده و چالش‌برانگیز است.
• این امر نیازمند تخصص فنی بالا و صرف زمان و هزینه قابل توجهی است.

3. افزایش هزینه‌ها:

• با افزایش حجم داده‌ها، نیاز به حافظه‌های SSD با سرعت بالا نیز افزایش یافت.
• استفاده از حافظه‌های SSD، هزینه‌های ذخیره‌سازی را به طور قابل توجهی افزایش می‌دهد.

راه‌حل‌های تیم نتفلیکس:

1. مهاجرت به Cassandra:

• تیم نتفلیکس برای حل مشکل مقیاس‌پذیری، به پایگاه داده Cassandra مهاجرت کرد.
• پایگاه داده Cassandra به دلیل مقیاس‌پذیری افقی و تحمل خطای بالا، برای ذخیره‌سازی حجم عظیمی از داده‌ها مناسب است.

2. بهینه‌سازی منابع ذخیره‌سازی:

• تیم نتفلیکس با استفاده از تکنیک‌های مختلف فشرده‌سازی و رمزگذاری، حجم داده‌های ذخیره‌شده را به طور قابل توجهی کاهش داد.
• همچنین با استفاده از فیلترهای مناسب، فقط داده‌های ضروری و مفید را ذخیره کردند.

3. استفاده از EBS:

• تیم نتفلیکس به جای استفاده از حافظه‌های SSD، از EBS (Elastic Block Store) که نوعی حافظه ابری است، استفاده کرد.
• حافظه EBS از نظر پرفورمنس و سرعت مقیاس‌دهی، مزایای قابل توجهی نسبت به SSD ها دارد.

4. فشرده‌سازی داده‌ها:

• تیم نتفلیکس از ابزار zstd برای فشرده‌سازی داده‌ها استفاده کرد.
• این ابزار حجم داده‌ها را تا نصف کاهش داد، بدون اینکه به کیفیت و کارایی داده‌ها آسیبی برساند.

5. استفاده از حافظه طبقه‌بندی شده:

• تیم نتفلیکس از حافظه طبقه‌بندی شده (Tiered Storage) استفاده کرد.
• در این روش، داده‌ها بر اساس اهمیت، حجم و میزان استفاده، در سطوح مختلف حافظه ذخیره‌سازی می‌شوند.
• این روش به صرفه‌جویی در هزینه‌ها و ارتقای کارایی ذخیره‌سازی کمک می‌کند.

مزایای راه‌حل‌های تیم نتفلیکس:

• مقیاس‌پذیری: راه‌حل‌های ارائه شده توسط تیم نتفلیکس، مقیاس‌پذیری و انعطاف‌پذیری بالایی برای ذخیره‌سازی حجم عظیمی از داده‌ها را فراهم می‌کنند.
• کاهش هزینه‌ها: با استفاده از تکنیک‌های مختلف بهینه‌سازی، هزینه‌های ذخیره‌سازی به طور قابل توجهی کاهش پیدا کرد.
• بهبود کارایی: راه‌حل‌های ارائه شده، کارایی و عملکرد ذخیره‌سازی داده‌ها را ارتقا می‌دهند.

مراحل بهینه‌سازی ذخیره سازی داده‌ها توسط نتفلیکس

• سال ۲۰۱۷: ElasticeSearch
• سال ۲۰۱۸: Cassandra روی SSD
• سال ۲۰۱۹: Cassandra روی EBS
• سال ۲۰۲۰: بهبود فشرده‌سازی داده‌‌ها و فیلتر کردن داده‌ها
• سال ۲۰۲۱: Tiered Storage

۳- ابزار های ردیابی:

• Zipkin
• Jaeger

۳.۱- معماری ابزار Zipkin

چکیده:

• ابزار Open-Zipkin یک ابزار منبع باز محبوب برای ردیابی توزیع‌شده است.
• این ابزار شامل اجزای مختلفی مانند Collector، Storage و Query Service می‌شود.
• مولفه Collector وظیفه دریافت داده‌ها از کتابخانه‌های Tracer را بر عهده دارد.
• مولفه Storage داده‌ها را ذخیره می‌کند و Query Service امکان جستجو و تجزیه و تحلیل داده‌ها را فراهم می‌کند.

توضیحات

همانطور که گفته شد، نتفلیکس از ابزار Zipkin برای جمع آوری داده Trace استفاده کرد. در این بخش معماری این ابزار را برسی می‌کنیم.

این ابزار، اطلاعات را از قسمت های مختلف داخل معماری سیستم جمع آوری کرده و از طریق یک رابط کاربری اطلاعاتی را نمایش می‌دهد.

موارد استفاده از این ابزار:

1. بهبود کارایی سیستم:

• با شناسایی گلوگاه‌ها و ناکارآمدی‌ها در سیستم خود، می‌توانید آنها را رفع کرده و کارایی سیستم را به طور قابل توجهی ارتقا دهید.
• ابزار Zipkin با نمایش زمان صرف شده در هر بخش از سیستم، به شما کمک می‌کند تا نقاطی که نیاز به بهینه‌سازی دارند را به سرعت پیدا کنید.

2. نمایش وابستگی میان میکروسرویس‌ها:

• ابزار Zipkin به شما کمک می‌کند تا وابستگی‌های بین میکروسرویس‌های مختلف در سیستم خود را به طور واضح مشاهده کنید.
• این امر به شما در درک بهتر نحوه عملکرد سیستم و عیب‌یابی مشکلات مربوط به وابستگی‌ها کمک می‌کند.

3. عیب یابی ارورها:

• ابزار Zipkin با ارائه اطلاعات دقیق در مورد هر درخواست، به شما کمک می‌کند تا علت اصلی خطاها را به سرعت پیدا کنید.
• می‌توانید از Zipkin برای ردیابی مسیر درخواست در سراسر سیستم و شناسایی نقطه ای که خطا رخ داده است استفاده کنید.

4. مانیتورینگ و alerting:

• ابزار Zipkin می‌تواند برای جمع‌آوری و تجزیه و تحلیل داده‌های مربوط به عملکرد سیستم شما استفاده شود. می‌توانید از این داده‌ها برای ایجاد داشبوردهای مانیتورینگ و تنظیم هشدارها برای شناسایی و رفع مشکلات به طور پیشگیرانه استفاده کنید.

پنج کامپوننت اصلی:

1. Instrumented Services
2. Collector
3. Storage
4. API
5. Web UI

1. مولفه Instrumented Services (سرویس‌های ابزارگذاری شده):

- شامل برنامه‌ها یا سیستم‌هایی هستند که قصد دارید با Zipkin آنها را رصد کنید.
- کتابخانه‌های مختلفی برای زبان‌ها و چارچوب‌های مختلف برای ابزارگذاری کد برنامه شما با Zipkin ارائه شده است.
- این کتابخانه‌ها وظایف زیر را انجام می‌دهند:

• ایجاد شناسه‌های ردیابی و spanها برای هر درخواست.
• اضافه کردن annotation و tag به داده‌ها برای ذخیره اطلاعات مربوط به درخواست.
• ارسال داده‌های ردیابی به Collector.

۲. مولفه Collector (جمع‌آوری کننده):

- پس از آماده شدن داده‌های ردیابی، Collector آنها را جمع‌آوری و پردازش می‌کند.
- وظایف اصلی Collector عبارتند از:

• دریافت داده‌های ردیابی از Instrumentation Services از طریق پروتکل‌های مختلف (HTTP، Kafka، RabbitMQ، Scribe).
• اعتبارسنجی داده‌های ردیابی برای اطمینان از صحت و کامل بودن آنها.
• نمونه‌گیری (Sampling) از داده‌های ردیابی (در صورت نیاز) برای کاهش حجم داده.
• ذخیره داده‌های ردیابی در Storage.

۳. مولفه Storage (ذخیره‌سازی):

- پس از جمع‌آوری و اعتبارسنجی، Storage داده‌های ردیابی را ذخیره می‌کند.
- ابزار Zipkin از گزینه‌های ذخیره‌سازی مختلفی پشتیبانی می‌کند، از جمله:

• پایگاه داده Cassandra: پایگاه داده NoSQL با مقیاس پذیری بالا و عملکرد مناسب.
• پایگاه داده Kafka: سیستم صف پیام‌رسان که برای ذخیره‌سازی و پردازش داده‌های ردیابی به صورت real-time مناسب است.
• پایگاه داده Elasticsearch: موتور جستجو که برای تجزیه و تحلیل و جستجوی داده‌های ردیابی ایده‌آل است.

۳. مولفه API (سرویس پرس و جو Zipkin):

- یک رابط RESTful را برای پرس و جو و تجزیه و تحلیل داده‌های ردیابی ذخیره‌شده ارائه می‌دهد.
- توسعه‌دهندگان می‌توانند از این API برای موارد زیر استفاده کنند:

• بازیابی ردیابی‌های خاص بر اساس شناسه ردیابی، بازه زمانی یا معیارهای دیگر.
• فیلتر کردن داده‌های ردیابی برای یافتن اطلاعات خاص.
• جمع‌آوری داده‌های ردیابی برای تجزیه و تحلیل و شناسایی روندها.

۵. مولفه Web UI (رابط کاربری وب):

- یک رابط گرافیکی برای مشاهده و تجزیه و تحلیل داده‌های ردیابی ارائه می‌دهد.
- مولفه Web UI به کاربران امکان می‌دهد:

• ردیابی‌های individual را به صورت گرافیکی مشاهده کنند.
• فیلتر و جستجوی ردیابی‌ها بر اساس معیارهای مختلف.
• تجزیه و تحلیل داده‌های ردیابی برای شناسایی گلوگاه‌ها و مشکلات عملکردی.

ملاحظات معماری نرم‌افزار:

• مقیاس پذیری: Zipkin برای مقیاس پذیری افقی طراحی شده است، به این معنی که می‌توانید با اضافه کردن Collector و Storage بیشتر، آن را به منظور مدیریت حجم داده‌های ردیابی بیشتر ارتقا دهید.
• امنیت: Zipkin از رمزنگاری برای محافظت از داده‌های ردیابی در حین انتقال و ذخیره‌سازی استفاده می‌کند.
• نظارت: Zipkin معیارهای مختلفی را برای نظارت بر عملکرد و سلامت سیستم ارائه می‌دهد.

نحوه ارتباط اجزای Zipkin با یکدیگر:

اجزای Zipkin برای جمع‌آوری، ذخیره‌سازی و تجزیه و تحلیل داده‌های ردیابی، در سراسر زیرساخت میکروسرویس‌ها به طور یکپارچه با یکدیگر ارتباط برقرار می‌کنند. در ادامه نحوه ارتباط آنها با یکدیگر شرح داده شده است:

۱. ردیاب (Tracer) به جمع‌آوری‌کننده (Collector):

- پروتکل: gRPC یا HTTP (قابل تنظیم)
- داده: داده‌های ردیابی شامل spans، annotations و tags برای هر درخواست‌.
- جریان:

• هر سرویس مجهز به Zipkin پس از اتمام درخواست، داده‌های ردیابی را به جمع‌آوری‌کننده ارسال می‌کند.
• جمع‌آوری‌کننده به طور همزمان داده‌ها را از ردیاب‌های مختلف دریافت می‌کند.

۲. جمع‌آوری‌کننده (Collector) به حافظه (Storage):

- پروتکل: بسته به Storage انتخاب شده متفاوت است (به عنوان مثال، CQL برای Cassandra، قالب پیام Kafka برای Kafka و غیره)
- داده: داده‌های پردازش شده و جمع‌آوری شده.
- جریان:

• جمع‌آوری‌کننده قبل از ارسال داده‌ها به ذخیره‌سازی، آنها را اعتبارسنجی و در صورت نیاز نمونه‌گیری(Sampling) می‌کند.
• اStorage داده‌ها را برای درخواست های دریافت بعدی، ذخیره می‌کند.

۳. سرویس پرس و جو (Query Service) به حافظه:

- پروتکل: بسته به حافظه انتخاب شده.
- داده: کوئری مربوط به دریافت Traceها.
- جریان:

• کاربران برای انجام پرس و جو با API سرویس کوئری تعامل دارند.
• سرویس پرس و جو، درخواست‌ها را به فرمت قابل فهم برای سرویس حافظه تبدیل می‌کند و به حافظه ارسال می‌کند.
• حافظه بر اساس کوئری، داده‌ها را دریافت و پردازش می‌کند و نتایج را به سرویس پرس و جو برمی‌گرداند.

۴. سرویس پرس و جو به کاربران:

- پروتکل: API RESTful (JSON یا Protobuf).
- داده: مطابق با query، داده‌های trace.
- جریان:

• سرویس پرس و جو نتایج را از حافظه دریافت می‌کند و آنها را برای استفاده کاربر آماده می‌کند.
• کاربران از طریق API یا ابزارهای بصری مانند Zipkin UI یا Grafana به داده‌های ردیابی دسترسی پیدا می‌کنند.
  

مراجع

• https://zipkin.io/pages/architecture.html
• https://github.com/openzipkin/zipkin
• https://www.jaegertracing.io/docs/1.53/architecture/
• https://en.wikipedia.org/wiki/Tiered_storage
• https://netflix.github.io/mantis/
• https://netflixtechblog.com/building-netflixs-distributed-tracing-infrastructure-bb856c319304

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است