اختلال ۸ ساعته گیت‌هاب چگونه به یک بحران زنجیره‌ای تبدیل شد؟

01

از 02

آغاز بحران از مرکز داده Central US

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

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

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

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

گیت‌هاب برای کنترل وضعیت بخشی از ترافیک را به منطقه Northern Virginia هدایت کرد، اما انتقال ترافیک مشکل تازه‌ای را آشکار کرد. پاسخ‌های کند یکی از نقاط پایانی داخلی باعث فعال شدن یک باگ پنهان در سازوکار تلاش مجدد VS Code شد.

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

بیشتر بخوانید: ابزار کدنویسی هوش مصنوعی GitHub Copilot از مرز ۲۰ میلیون کاربر عبور کرد

02

از 02

جهش ۱۰ برابری درخواست‌های Copilot

شدت مشکل را می‌توان در آمار Copilot Token Service مشاهده کرد. این سرویس در شرایط عادی بین ۷ هزار تا ۹ هزار درخواست را در هر ثانیه پردازش می‌کند. تعداد درخواست‌ها در جریان این اختلال به ۷۰ هزار تا ۱۰۰ هزار درخواست در ثانیه رسید.

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

گیت‌هاب در نهایت چند اقدام را برای تثبیت وضعیت انجام داد. این شرکت تعداد تلاش‌های مجدد در دروازه را کاهش داد و برخی درخواست‌های مربوط به توکن را به‌طور موقت با پاسخ HTTP 403 مسدود کرد. مهندسان سپس ترافیک را به‌صورت تدریجی بازگرداندند تا از ایجاد موج جدیدی از درخواست‌ها جلوگیری کنند.

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

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

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

افزایش استفاده از ابزارهای هوش مصنوعی باعث شده است گیت‌هاب دسترس‌پذیری و افزایش ظرفیت زیرساخت را نسبت به عرضه قابلیت‌های جدید در اولویت قرار دهد. فشار ناشی از رشد تقاضا به اندازه‌ای بوده که مایکروسافت حتی برای اجاره ظرفیت پردازشی از Amazon Web Services، یکی از مهم‌ترین رقبای خود در بازار خدمات ابری، آماده شده بود.

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