‏متا با ZGateway معماری ZippyDB رو نجات داد

مهندس‌های متا می‌گن ZippyDB که بزرگ‌ترین دیتابیس کلید-مقداری (key-value store) اونهاست، قبلاً یه مشکل ساختاری داشت: هر کدوم از حدود یک میلیون کلاینتش مستقیم به هزاران سرور دیتابیس وصل می‌شد. این یعنی یه شبکه‌ی درهم از صدها هزار کانکشن TLS که بیشترشون بیکار بودن ولی همچنان حافظه و CPU مصرف می‌کردن. وقتی یه دسته کلاینت ری‌استارت می‌شد یا دیپلوی جدید می‌اومد، یهو انبوه کانکشن جدید به سرورها هجوم می‌آورد و باعث می‌شد بعضی سرورها به خاطر تموم شدن فایل دیسکریپتور کرش کنن و وارد چرخه ری‌استارت پشت سر هم بشن.

برای حل این مشکل متا یه لایه پروکسی بی‌حالت (stateless) به اسم ZGateway ساخته که بین کلاینت‌ها و سرورهای دیتابیس می‌نشینه. این پروکسی الان بیش از یک میلیارد عملیات در ثانیه رو رد می‌کنه، حدود ۴۰ درصد کل ترافیک ZippyDB رو مدیریت می‌کنه (که قراره به بالای ۶۰ درصد برسه) و فقط حدود ۶ درصد سربار اضافه به عملیات معمولی تحمیل می‌کنه. مزیت اصلیش اینه که تعداد کلاینت‌ها دیگه مستقیم روی تعداد کانکشن‌های سرور تاثیر نمی‌ذاره؛ طبق محاسبات متا، این تغییر کل کانکشن‌های سیستم رو حدود ۱۹ برابر کم کرده.

یکی از کارهای مهم ZGateway ترکیب کردن (batching) درخواست‌های چند کلاینت مختلفه که به یه شارد (shard) یکسان می‌رن؛ به جای اینکه هر درخواست جدا به سرور بره، چندتاشون با هم یکی می‌شن و به‌صورت یه درخواست بزرگ‌تر ارسال می‌شن. این کار هم بار روی سرورها رو کم می‌کنه هم باعث می‌شه اگه هزاران کلاینت هم‌زمان دنبال یه کلید داغ (hot key) باشن، فقط یه درخواست واقعی به سرور بره نه هزاران‌تا. برای اینکه نگه‌داشتن این درخواست‌ها تو حافظه باعث مشکل نشه، دو مکانیزم ایمنی گذاشتن: حذف درخواست‌های قدیمی بعد از یه مدت مشخص و یه سقف برای تعداد درخواست‌های هم‌زمان در حال پردازش.

چون ZGateway ترافیک صدها تیم مختلف رو با هم مدیریت می‌کنه، باید مطمئن شه یه تیم شلوغ بقیه رو تحت تاثیر قرار نمی‌ده. برای همین یه سیستم به اسم Discriminant Load Shedding ساختن که برای هر تیم یه صف جدا نگه می‌داره. تو یه تست با بیش از ۹۰ درصد مصرف CPU روی حدود ۱۳۵۰ تیم فعال، فقط ۶ تیم شلوغ محدود شدن و ۱۳۴۴ تیم بقیه بدون هیچ رد درخواستی با ۹۹.۹ درصد موفقیت کار کردن. علاوه بر این، ZGateway بار بین سرورهای خودش رو هم بر اساس مصرف CPU هر سرور تنظیم می‌کنه و در صورت مشکل تو یه منطقه جغرافیایی، ترافیک رو به مناطق سالم نزدیک منتقل می‌کنه.

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

نکات کلیدی:

• ZGateway بیش از ۱ میلیارد عملیات در ثانیه رو مدیریت می‌کنه و حدود ۴۰ درصد ترافیک ZippyDB رو حمل می‌کنه
• استفاده از این پروکسی تعداد کل کانکشن‌های سیستم رو حدود ۱۹ برابر کم کرده
• سیستم Discriminant Load Shedding تو یه تست سنگین فقط ۶ تیم شلوغ از ۱۳۵۰ تیم رو محدود کرد
• برنامه بعدی متا استفاده از ایجنت‌های هوش مصنوعی برای مدیریت خودکار این پروکسیه