Booking.com با Watt هزینهی Node.js رو ۳۸ درصد کم کرد
خلاصهٔ کاملتر
Matteo Collina، سازندهی Platformatic، تو خبرنامهش از case study تازهی Booking.com نوشته. Booking سرویس اصلی رندر Node.js خودشو از pm2 به Watt (ابزار Platformatic برای اجرای اپهای Node.js) منتقل کرده. نتیجه: ۳۸ درصد هزینهی محاسبهی کمتر، ۳۰ درصد پاد کمتر، ۲۰ درصد حافظهی کمتر برای هر پاد و تا ۱۰ درصد latency بهتر در p75، p99 و p99.9. بدون سختافزار جدید و بدون تغییر کد سرویس.
فرق اصلی تو مسیر درخواسته. تو ماژول cluster ابزار pm2 هر درخواست از یه پروسهی ناظر رد میشه و با IPC (یعنی ارتباط بین پروسهها) به worker میرسه. ولی تو Watt هر worker thread با SO_REUSEPORT مستقیم از kernel اتصال میگیره. یعنی یه مرحله کمتر تو مسیر درخواست. به گفتهی نویسنده، تو تستهای بار ترکیبی این باعث شد ۴۰ تا ۵۰ درصد درخواست بیشتر با همون SLO مربوط به latency پاسخ داده بشه.
یه مشکل جالب هم پیش اومد. با SO_REUSEPORT خود kernel با hash کردن آدرس و پورت اتصال تصمیم میگیره کدوم worker درخواستو بگیره. چون tcp_tw_reuse اتصالهای loopback رو دوباره استفاده میکنه، hash همیشه روی یه worker میافتاد و بار نامتوازن میشد. شلوغترین threadها تا ۴۰ درصد بیشتر از خلوتترینها بار داشتن.
راهحل Booking این بود که به جای جنگیدن با kernel، هر worker روی پورت خودش گوش بده و nginx که از قبل جلوی سرویس بود، load balancing رو انجام بده. round robin خوب جواب داد. برای یه سرویس هم endpointهای سنگین رندر و endpointهای سبک رو به workerهای جدا (۴+۱) دادن و با least_conn چند درصد دیگه از tail latency کم کردن. Watt این حالتو با تنظیم portAssignment روی مقدار perWorkerIncrement پشتیبانی میکنه.
Watt همچنین threadهایی رو که event loop رو قفل میکنن خودش تشخیص میده و ریاستارت میکنه. نویسنده میگه همیشه طرفدار همین رفتار بوده: worker گیر کرده باید ریاستارت بشه، نه فقط زیر نظر باشه. Booking هم مهاجرتو به شکل یه A/B تست واقعی تو production انجام داد: دو نصب کامل با تعداد پاد و منابع یکسان کنار هم اجرا شدن و ترافیک تو لایهی routing تقسیم شد.
نکات کلیدی:
- مهاجرت از pm2 به Watt هزینهی محاسبهی Booking.com رو ۳۸ درصد کم کرد.
- تعداد پادها ۳۰ درصد و حافظهی هر پاد ۲۰ درصد کمتر شد و latency تا ۱۰ درصد بهتر شد.
- workerهای Watt با SO_REUSEPORT مستقیم از kernel اتصال میگیرن و IPC حذف میشه.
- در تست بار ترکیبی ۴۰ تا ۵۰ درصد درخواست بیشتر با همون SLO پاسخ داده شد.
- برای رفع بار نامتوازن، هر worker پورت جدا گرفت و nginx با round robin یا least_conn بار رو پخش کرد.
- هیچ خطی از کد سرویس تغییر نکرد و سختافزار جدیدی هم اضافه نشد.




