قطعی گیتهاب: مقصر فقط یه تنظیم غلط نبود
خلاصهٔ کاملتر
قطعی اخیر گیتهاب وقتی رخ داد که یه پاد سایدکار Istio (یعنی یه پروسهی شبکهای که کنار هر سرویس اجرا میشه و ترافیکشو مدیریت میکنه) به سقف همزمانیش رسید و نتونست درست اسکیل بشه، چون سیاست اتوسیلینگ فقط بار روی سرویس اصلی رو میدید، نه بار روی خود سایدکار رو. لورین هاکستاین، نویسندهی این پست، میگه این جزئیات از نوشتهی عمومی گیتهاب دربارهٔ قطعی اومده.
به گفتهٔ نویسنده، اتوسیلینگ یعنی بهجای آماده کردن سرویس برای اوج بار، منابعش رو بر اساس بار لحظهای کم و زیاد کنی، و این کار به یه سیاست مشخص نیاز داره که معیار بار رو تعریف کنه. CPU utilization یه معیار رایجه ولی همیشه جواب نمیده: وقتی سرویس از تردپول استفاده میکنه و درخواستهای پاییندستی کند میشن، همهی تردها منتظر I/O میمونن و سرویس اشباع میشه، در حالی که CPU پایین نشون داده میشه. همین اتفاق تو قطعی ژانویه ۲۰۲۱ اسلک افتاد و اونا اسکیل رو بر اساس تعداد تردها تنظیم کردن.
نویسنده میگه چون هر سرویس زیر بار رفتار متفاوتی داره، سیاست اتوسیلینگ هر سرویس عملاً دستساز و مخصوص همونه و فقط با تست بار میشه درستیشو سنجید؛ در حالی که تیم صاحب سرویس، علاوه بر منطق کسبوکار، مسئول یه سیستم کنترل عملیاتی هم شده که خودش متخصصش نیست. برای همین از نظر اون تعجبی نداره که یه سیاست بدتنظیم تو این قطعی نقش داشته باشه.
با این حال نویسنده هشدار میده که میخکوب شدن روی همین یه ایراد، همون چیزیه که دیوید وودز بهش میگه مغالطهی جایگزینی مؤلفه، یعنی این تصور که راه بهتر کردن پایداری فقط پیدا کردن و رفع اجزای معیوبه. به گفتهٔ اون سیستم شما همین الان پر از عیبهای پنهانه و با این حال مدام قطع نمیشه، پس عیب یه مؤلفه بهتنهایی سیستم رو نمیخوابونه. چیزی که باید جدی گرفته بشه تعامل بین عواملیه: ترافیک اسکرپرها، سیاست اتوسیلینگ، اشباع سایدکار Istio، منطق ریترای، نودهای HAProxy و ترافیک احراز هویت.
نویسنده آخرش میگه چون این یه نوشتهی عمومی و سریعه، خیلی جزئیات (مثل اینکه این سیاست قبل از اومدن سایدکار Istio هم وجود داشته یا نه، یا اینکه ترافیک مشکلساز از چه نوعی بوده و چرا زیاد شده) توش نیست. ولی این سوالا رو تو گزارشهای داخلی سازمان خودتون میتونین بپرسین و جوابشو بگیرین.
نکات کلیدی:
- سیاست اتوسیلینگ سرویس درگیر فقط بار خود سرویس رو میدید، نه سقف همزمانی سایدکار Istio
- CPU پایین یعنی اشباعنبودن نیست؛ تردهای بلاکشده روی I/O همین وضع رو میسازن (نمونه: قطعی ژانویه ۲۰۲۱ اسلک)
- هر سیاست اتوسیلینگ عملاً دستسازه و فقط با تست بار قابل اعتبارسنجیه
- «مغالطهی جایگزینی مؤلفه» (اصطلاح دیوید وودز): تصور اینکه پایداری فقط با رفع اجزای معیوب میاد
- عوامل درگیر: ترافیک اسکرپرها، اتوسیلینگ، سایدکار Istio، ریترای، نودهای HAProxy و ترافیک احراز هویت
