مسیریابی ترافیک ویدئویی در منطقه آسیا-اقیانوسیه با استفاده از etcd

یک پلتفرم پخش ویدئویی که به هشت بازار در منطقه آسیا-اقیانوسیه خدمات می‌دهد، با انتقال پیکربندی‌های مختص هر منطقه به etcd، از بروز یک خطای مسیریابی مکرر جلوگیری کرد. زمان انتشار تغییرات مسیریابی به حدود یک ثانیه کاهش یافت. اکنون ویرایشگران می‌توانستند بدون دستکاری در کد، یک مجموعه موسیقی (music pool) را برای چند ساعت تقویت کنند و پلتفرم نیز دیگر فید توکیو را برای بینندگان کره جنوبی ارسال نکرد.

چرا رویکرد قدیمی از کار افتاد

هر روتر برای هر درخواست، سه مقدار را می‌خواند: مجموعه ترند (trending pool)، توکن‌ساز (tokenizer) مختص زبان، و زنجیره جایگزین (fallback chain). تصمیمات تجاری — مانند تبلیغ یک هنرمند جدید، واکنش به یک قطعی منطقه‌ای یا آزمایش یک الگوریتم پیشنهاددهنده — این مقادیر را هدایت می‌کردند، نه تغییرات در کد.

در ابتدا، هر استقرار (deployment) شامل یک فایل JSON حاوی جدول مسیریابی بود. در طول یک حادثه، مهندسِ آن‌کال (on-call) فایل را در یک گره (node) ویرایش کرد تا ترافیک را به یک مجموعه پشتیبان هدایت کند، اما هرگز هفت گره دیگر را به‌روزرسانی نکرد. پدیده «انحراف پیکربندی» (config drift) پدیدار شد: هشت کشور جداول متفاوتی را اجرا می‌کردند و هیچ منبع واحدی «حقیقت» را تأیید نمی‌کرد. باگی که بینندگان سئول را به توکیو هدایت می‌کرد، پابرجا ماند زیرا کد ثابت بود و تنها پیکربندی‌های پنهان تفاوت داشتند.

انتخاب etcd به عنوان منبع واحد حقیقت (single source of truth)

تیم سه گزینه را با هم مقایسه کرد:

  • SQLite/MySQL – هر روتر را مجبور به پرس‌وجوی مکرر (poll) از پایگاه داده می‌کرد که باعث افزایش تأخیر یا هجوم پرس‌وجوها می‌شد.
  • Consul – یک ابزار قدرتمند برای کشف سرویس (service-discovery) است، اما پلتفرم به تمام ویژگی‌های شبکه مش (mesh) آن نیاز نداشت.
  • etcd – یک ذخیره‌ساز کلید-مقدار با سازگاری قوی (strongly consistent) که دارای یک قابلیت اولیه watch است و به محض تغییر یک کلید، به کلاینت‌ها اطلاع می‌دهد.

قابلیت watch باعث چربیدن کفه ترازو شد. به جای اینکه هر روتر مدام بپرسد «آیا چیزی تغییر کرده است؟»، روترها تا زمانی که etcd یک به‌روزرسانی را ارسال (push) نمی‌کرد، در حالت انتظار می‌ماندند. ترافیک شبکه غیرضروری از بین رفت و هر نمونه (instance) به‌طور همزمان از تغییر مطلع شد.

الگوهایی برای حفظ امنیت سیستم

etcd به تنهایی تمام ریسک‌ها را حل نکرد. مهندسان سه الگوی مکمل را اضافه کردند:

  1. اجاره‌ها (Leases) – یک ویرایشگر می‌تواند یک تقویت موقت تنظیم کند (مثلاً افزایش وزن یک مجموعه کی-پاپ برای شش ساعت). مدت اجاره به‌طور خودکار منقضی می‌شود، بنابراین تقویت بدون نیاز به بازگشت دستی (rollback) از بین می‌رود.
  2. مقایسه و جایگزینی (CAS) – وقتی دو نفر به‌طور همزمان یک تنظیم را ویرایش می‌کنند، CAS برای یکی از آن‌ها با خطا مواجه می‌شود تا از بازنویسی بی‌صدا جلوگیری شود.
  3. فرآیند Sidecar – زبان PHP با اتصالات طولانی‌مدت مشکل دارد. یک sidecar کوچک با زبان Go در هر سرور، etcd را زیر نظر می‌گیرد و یک اسنپ‌شات از جدول مسیریابی را در یک فایل حافظه مشترک (/dev/shm) می‌نویسد. PHP آن فایل محلی را می‌خواند و از هرگونه رفت و برگشت شبکه (network round-trip) در حین پردازش درخواست جلوگیری می‌کند.

تاب‌آوریِ نهفته در معماری

طرح جدید چندین لایه حفاظتی اضافه می‌کند:

  • خواندن با تأخیر صفر – مسیر اصلی (hot path) در PHP از حافظه محلی می‌خواند، بنابراین درخواست‌ها هرگز برای انتظار برای یک ذخیره‌ساز از راه دور متوقف نمی‌شوند.
  • کاهش تدریجی عملکرد (Graceful degradation) – اگر etcd از دسترس خارج شود، روترها همچنان آخرین پیکربندی معتبر شناخته‌شده را ارائه می‌دهند و از قطعی ناگهانی جلوگیری می‌کنند.
  • به‌روزرسانی‌های قابل اعتماد – sidecar منطق اتصال مجدد را مدیریت می‌کند و تضمین می‌کند که حتی در صورت قطع موقت اتصال etcd، هیچ تغییری از قلم نیفتد.

تغییرات در عمل

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

نکته مقابل: هزینه استفاده از sidecar

افزودن یک sidecar به معنای داشتن یک فرآیند دوم در هر سرور و یک محیط اجرای Go در یک پشته (stack) متمرکز بر PHP است. برخی از اپراتورها نگران مصرف اضافی حافظه و نیاز به نظارت بر یک باینری دیگر هستند. در عمل، ردپای (footprint) sidecar ناچیز باقی می‌ماند و دستاوردهای مربوط به قابلیت اطمینان — به‌ویژه تضمین اینکه PHP هرگز در یک فراخوانی شبکه مسدود (block) نمی‌شود — بر هزینه‌های عملیاتی می‌چربد.

موارد بعدی که باید زیر نظر داشت

تیم‌هایی که سرویس‌های چند منطقه‌ای را مدیریت می‌کنند، باید موارد زیر را زیر نظر داشته باشند:

  • معیارهای سلامت etcd – لایه مسیریابی به یک ذخیره‌ساز واحد وابسته است؛ وضعیت کوئوروم (quorum) و تأخیر را زیر نظر داشته باشید.
  • مدیریت انقضای اجاره – زمان‌های اجاره را با بازه‌های زمانی تجاری مطابقت دهید؛ اجاره‌های بیش از حد طولانی باعث باقی ماندن تقویت‌های قدیمی می‌شوند.
  • مقیاس‌پذیری بار watch – با افزایش تعداد روترها، اتصالات watch نیز افزایش می‌یابد؛ ظرفیت سرورهای etcd را بر همین اساس برنامه‌ریزی کنید.

نتیجه‌گیری

برای هر سرویسی که به تغییرات پیکربندی سریع و هماهنگ در چندین منطقه نیاز دارد، قابلیت‌های پایه (primitives) watch، lease و transaction در etcd، جایگزینی سبک و با سازگاری قوی (strongly consistent) برای پیکربندی‌های مبتنی بر فایل یا مش‌های (meshes) سنگین ارائه می‌دهند. تبدیل پیکربندی به یک مخزن مبتنی بر push و خودپاک‌شونده، یک دسته کامل از حوادث را از میان برداشت و کنترل بی‌درنگ (real-time) بر منطق مسیریابی را برای پلتفرم فراهم کرد.