قطعی اخیر آمازون وب سرویس (AWS) که بخش قابل توجهی از اینترنت، بازی‌ها و حتی دستگاه‌های خانه هوشمند را برای روزها از کار انداخت، به طور گسترده‌ای در اخبار پوشش داده شد. معماری توزیع‌شده خدمات ابری باید مشتریان را از چنین خرابی‌هایی محافظت کند، پس چه اشتباهی رخ داد؟ آمازون یک تحلیل فنی دقیق پس از خرابی را منتشر کرد، و همانطور که شعر معروف هایکو می‌گوید: “DNS نیست. / محال است DNS باشد. / DNS بود.”

به عنوان یک قیاس تقریبی، آنچه را که هنگام تصادف اتومبیل رخ می‌دهد در نظر بگیرید. یک ترافیک سنگین برای مایل‌ها کشیده می‌شود، با اثری آکاردئونی که مدت‌ها پس از پاکسازی صحنه تصادف ادامه می‌یابد. اولین مشکل نسبتاً سریع برطرف شد، با یک قطعی سه ساعته از ۱۹ اکتبر ساعت ۱۱:۴۸ شب تا ۲۰ اکتبر ساعت ۲:۴۰ صبح. با این حال، همانند مثال ترافیک، وابستگی‌ها شروع به از کار افتادن کردند و تا مدت‌ها بعد به طور کامل آنلاین نشدند.

گزارش شده است که علت اصلی این بود که پیکربندی DNS برای DynamoDB (سرویس پایگاه داده) خراب شده و در Route53 (سرویس DNS) منتشر شده بود. به نوبه خود، بخش‌هایی از EC2 (سرویس ماشین مجازی) نیز از کار افتاد، زیرا سرویس‌های مدیریت خودکار آن به DynamoDB متکی هستند. متعادل‌کننده بار شبکه آمازون نیز به طور طبیعی به DNS وابسته است، بنابراین آن نیز با مشکلاتی مواجه شد.

شایان ذکر است که خرابی DynamoDB در کل منطقه US-East-1، به خودی خود، برای از کار انداختن میلیون‌ها وب‌سایت و سرویس کافی است. با این حال، عدم توانایی در راه‌اندازی نمونه‌های EC2 بسیار بدتر بود، و تحت تأثیر قرار گرفتن متعادل‌سازی بار، یک فاجعه تمام‌عیار بود.

مشکل فنی خاص پشت خرابی DNS، باگ “مورد علاقه” یک برنامه‌نویس بود: یک شرایط رقابتی (race condition)، که در آن دو رویداد تکراری به طور مداوم اثرات یکدیگر را بازسازی یا خنثی می‌کنند — GIF معروف باگز بانی و دافی داک با پوستر گویاست.

حل و فصل DNS دیتابیس DynamoDB از دو جزء استفاده می‌کند: یک برنامه‌ریز DNS (DNS Planner) که، همانطور که از نامش پیداست، به صورت دوره‌ای یک طرح جدید صادر می‌کند که بار سیستم و در دسترس بودن را در نظر می‌گیرد. مجریان DNS (DNS Enactors)، هر زمان که یک طرح جدید را می‌بینند، آن را به عنوان یک تراکنش در Route53 اعمال می‌کنند، به این معنی که یک طرح یا به طور کامل اعمال می‌شود یا نمی‌شود. تا اینجا همه چیز خوب است.

آنچه اتفاق افتاد این بود که اولین مجری DNS با آرامش تمام مشغول اعمال آنچه ما آن را “طرح قدیمی” می‌نامیم، بود. با ورود طرح‌های جدید، مجری دیگری یکی را برداشت و اعمال کرد. اکنون داده‌های خوب و به‌روز شده در Route53 وجود دارد، و یک پاکسازی از طرح‌های قدیمی (شامل طرح قدیمی) صادر می‌شود، درست در همان لحظه که اولین مجری اعمال طرح قدیمی را به پایان رساند.

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

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

به عنوان گیلاس روی کیک (از نظر فنی، زیر آن)، متعادل‌کننده بار شبکه آمازون (NLB) نیز آسیب دید، زیرا تأخیر در رفع ورودی‌های DNS و انتشار بعدی آنها باعث شد متعادل‌کننده بار، نمونه‌های جدید EC2 را با وضعیت شبکه ناسازگار راه‌اندازی کند. همچنین به دلیل آن، بسیاری از بررسی‌های سلامت NLB با شکست مواجه شدند، حتی اگر زیرساخت اصلی در واقع به درستی کار می‌کرد. این بررسی‌های سلامت ناموفق باعث شد گره‌های NLB و اهداف پشتیبان (حدس بزنید چه شد!) از DNS حذف شوند، فقط برای اینکه بعداً بازگردند.

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

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