خلاصه ای از رویداد خدمات AWS در منطقه ویرجینیای شمالی (US-EAST-1). 10 دسامبر 2021
خلاصه ای از رویداد خدمات AWS در منطقه ویرجینیای شمالی (US-EAST-1).
10 دسامبر 2021
خلاصه موضوع
برای توضیح این رویداد، لازم است کمی در مورد شبکه داخلی های AWS به اشتراک بگذاریم. در حالی که اکثر سرویس‌های AWS و همه برنامه‌های کاربردی مشتری در شبکه اصلی AWS اجرا می‌شوند، AWS از یک شبکه داخلی برای میزبانی خدمات اساسی از جمله نظارت، DNS داخلی، خدمات مجوز و بخش‌هایی از صفحه کنترل EC2 استفاده می‌کند. به دلیل اهمیت این خدمات در این شبکه داخلی، ما این شبکه را با چندین دستگاه شبکه ایزوله جغرافیایی متصل می کنیم و ظرفیت این شبکه را به میزان قابل توجهی افزایش می دهیم تا از دسترسی بالای این اتصال شبکه اطمینان حاصل کنیم. این دستگاه های شبکه، مسیریابی اضافی و ترجمه آدرس شبکه را ارائه می دهند که به خدمات AWS اجازه می دهد بین شبکه داخلی و شبکه اصلی AWS ارتباط برقرار کنند. در ساعت 7:30 صبح PST، یک فعالیت خودکار برای مقیاس کردن ظرفیت یکی از سرویس‌های AWS میزبانی شده در شبکه اصلی AWS، رفتار غیرمنتظره‌ای را از سوی تعداد زیادی از مشتریان در داخل شبکه داخلی ایجاد کرد. این منجر به افزایش شدید فعالیت اتصال شد که دستگاه های شبکه بین شبکه داخلی و شبکه اصلی AWS را تحت الشعاع قرار داد و منجر به تاخیر در برقراری ارتباط بین این شبکه ها شد. این تأخیرها ، تأخیر و خطاها را برای سرویس‌هایی که بین این شبکه‌ها ارتباط برقرار می‌کنند، افزایش می‌دهد که منجر به تلاش‌های مجدد برای اتصال بیشتر و ازدحام و مشکلات عملکردی مداوم در دستگاه‌های متصل کننده دو شبکه می شود.
این ازدحام بلافاصله بر در دسترس بودن داده‌های نظارتی بی‌درنگ برای تیم‌های عملیات داخلی ما تأثیر گذاشت، که توانایی آنها را برای یافتن منبع ازدحام و رفع آن مختل کرد. در عوض اپراتورها برای درک آنچه اتفاق می‌افتد به گزارش‌ها تکیه کردند و در ابتدا خطاهای DNS داخلی را شناسایی کردند. از آنجایی که DNS داخلی برای همه سرویس‌ها اساسی است و تصور می‌شد این ترافیک به ازدحام کمک می‌کند، تیم‌ها بر انتقال ترافیک داخلی DNS از مسیرهای پرتراکم شبکه تمرکز کردند. در ساعت 9:28 صبح PST، تیم این کار را به پایان رساند و خطاهای وضوح DNS به طور کامل بازیابی شدند. این تغییر در دسترس بودن چندین سرویس تحت تأثیر را با کاهش بار روی دستگاه‌های شبکه تأثیرگذار بهبود بخشید، اما تأثیر سرویس AWS را به طور کامل برطرف نکرد یا تراکم را از بین نبرد. نکته مهم این است که داده های نظارت هنوز برای تیم عملیاتی ما قابل مشاهده نبود، بنابراین آنها مجبور بودند به حل مشکل با کاهش دید سیستم ادامه دهند. اپراتورها به کار بر روی مجموعه ای از اقدامات اصلاحی برای کاهش ازدحام در شبکه داخلی از جمله شناسایی منابع اصلی ترافیک برای ایزوله کردن به دستگاه های شبکه اختصاصی، غیرفعال کردن برخی از خدمات ترافیک شبکه سنگین و برخط کردن ظرفیت شبکه اضافی ادامه دادند. این به چند دلیل به کندی پیش رفت. اول، تأثیر بر نظارت داخلی توانایی ما را برای درک مشکل محدود کرد. دوم، سیستم‌های استقرار داخلی ما، که در شبکه داخلی ما اجرا می‌شوند، تحت تأثیر قرار گرفتند، که تلاش‌های اصلاحی ما را بیشتر کند کرد. در نهایت، از آنجایی که بسیاری از سرویس‌های AWS در شبکه اصلی AWS و برنامه‌های مشتری AWS هنوز به طور عادی کار می‌کردند، ما می‌خواستیم در حین ایجاد تغییرات برای جلوگیری از تأثیرگذاری بر حجم کاری عملکرد، بسیار سنجیده عمل کنیم. همانطور که تیم های عملیات به اعمال اقدامات اصلاحی که در بالا توضیح داده شد ادامه دادند، ازدحام تا ساعت 1:34 بعد از ظهر PST به طور قابل توجهی بهبود یافت و تمام دستگاه های شبکه تا ساعت 2:22 بعد از ظهر PST به طور کامل بهبود یافتند. اقدامات متعددی برای جلوگیری از تکرار این رویداد انجام داده ایم. ما فوراً فعالیت‌های مقیاس‌بندی را که باعث این رویداد شد غیرفعال کردیم و تا زمانی که همه اقدامات اصلاحی را انجام ندهیم، آنها را از سر نمی‌گیریم. سیستم های ما به اندازه کافی مقیاس بندی شده اند تا در کوتاه مدت نیازی به از سرگیری این فعالیت ها نداشته باشیم. کلاینت های شبکه ما رفتارهای بازگشت درخواست را به خوبی آزمایش کرده اند که به گونه ای طراحی شده اند که به سیستم های ما اجازه می دهد تا از این نوع رویدادهای ازدحام بازیابی شوند، اما یک مشکل پنهان مانع از این شد که این کلاینت ها به اندازه کافی در این رویداد عقب نشینی کنند. این مسیر کد برای سال‌ها در حال تولید بوده است، اما فعالیت مقیاس‌بندی خودکار رفتاری را که قبلاً مشاهده نشده بود، آغاز کرد. ما در حال توسعه راه حلی برای این مشکل هستیم و انتظار داریم این تغییر را طی دو هفته آینده اعمال کنیم. ما همچنین پیکربندی شبکه اضافی را مستقر کرده‌ایم که از دستگاه‌های شبکه تحت تأثیر احتمالی حتی در مواجهه با یک رویداد ازدحام مشابه محافظت می‌کند. این اصلاحات به ما این اطمینان را می دهد که شاهد تکرار این موضوع نخواهیم بود. تاثیر سرویس AWS در حالی که بار کاری مشتری AWS مستقیماً تحت تأثیر مشکلات شبکه داخلی توضیح داده شده در بالا قرار نگرفت، مشکلات شبکه باعث تأثیر بر تعدادی از خدمات AWS شد که به نوبه خود بر مشتریانی که از این قابلیت‌های خدمات استفاده می‌کردند تأثیر گذاشت. از آنجایی که شبکه اصلی AWS تحت تأثیر قرار نگرفت، برخی از برنامه‌های کاربردی مشتری که بر این قابلیت‌ها تکیه نمی‌کردند، تنها تأثیر کمتری را از این رویداد تجربه کردند.
چندین سرویس AWS بر روی سطوح کنترلی که برای ایجاد و مدیریت منابع AWS استفاده می‌شوند، تأثیر داشتند. این هواپیماهای کنترلی از خدمات میزبانی شده در شبکه داخلی استفاده می کنند. به عنوان مثال، در حالی که نمونه‌های EC2 در حال اجرا تحت تأثیر این رویداد قرار نگرفتند، APIهای EC2 که مشتریان برای راه‌اندازی نمونه‌های جدید یا توصیف نمونه‌های فعلی خود استفاده می‌کنند، با شروع از ساعت 7:33 صبح به وقت PST، نرخ خطا و تأخیر بیشتری را تجربه کردند. در ساعت 1:15 بعد از ظهر PDT، با بهبود ازدحام، نرخ خطا و تاخیر EC2 API شروع به بهبود کرد، به جز برای راه اندازی نمونه های جدید EC2، که تا 2:40 بعد از ظهر PST بهبود یافتند. مشتریان سرویس‌های AWS مانند Amazon RDS، EMR، Workspaces نمی‌توانستند منابع جدیدی ایجاد کنند، زیرا قادر به راه‌اندازی نمونه‌های جدید EC2 در طول رویداد نبودند. به طور مشابه، Elastic Load Balancers موجود در طول رویداد سالم باقی ماندند، اما نرخ خطای API و تأخیر بالا برای API های ELB منجر به افزایش زمان تهیه برای متعادل کننده های بار جدید و تاخیر در زمان ثبت نمونه برای افزودن نمونه های جدید به متعادل کننده های بار موجود شد. علاوه بر این، APIهای Route 53 از ساعت 7:30 صبح به وقت PST تا ساعت 2:30 بعد از ظهر PST دچار اختلال شدند و از ایجاد تغییرات در ورودی‌های DNS توسط مشتریان جلوگیری می‌کردند، اما ورودی‌های DNS موجود و پاسخ‌های درخواست‌های DNS در طول این رویداد تحت تأثیر قرار نگرفتند. مشتریان همچنین در طول رویداد با خطاهای ورود به کنسول AWS در منطقه آسیب دیده مواجه شدند. دسترسی کنسول به طور کامل تا ساعت 2:22 بعد از ظهر PST بازیابی شد. Amazon Secure Token Service (STS) در هنگام ارائه اعتبارنامه برای ارائه دهندگان هویت شخص ثالث از طریق OpenID Connect (OIDC) تاخیرهای زیادی را تجربه کرد. این منجر به خرابی ورود به سیستم سایر سرویس‌های AWS شد که از STS برای احراز هویت استفاده می‌کنند، مانند Redshift. در حالی که تأخیرها در ساعت 2:22 بعد از ظهر به وقت PST بهبود یافتند، زمانی که مشکل مربوط به دستگاه‌های شبکه برطرف شد، بازیابی کامل STS در ساعت 4:28 بعد از ظهر PST رخ داد. مشتریان همچنین تحت تأثیر تأخیرهای نظارت CloudWatch در طول این رویداد قرار گرفتند و در نتیجه درک تأثیر بر برنامه های خود دشوار بود. مقدار کمی از داده‌های نظارتی CloudWatch در طول این رویداد جمع‌آوری نشده است و ممکن است در برخی معیارها برای بخش‌هایی از رویداد وجود نداشته باشد. مشتریانی که به Amazon S3 و DynamoDB دسترسی دارند تحت تأثیر این رویداد قرار نگرفتند. با این حال، دسترسی به سطل‌های Amazon S3 و جداول DynamoDB از طریق VPC Endpoints در طول این رویداد مختل شد.
های AWS Lambda و فراخوانی توابع Lambda به طور معمول در طول رویداد عمل کردند. با این حال، API Gateway، که اغلب برای فراخوانی توابع Lambda و همچنین یک سرویس مدیریت API برای برنامه‌های کاربردی مشتری استفاده می‌شود، با افزایش نرخ خطا مواجه شد. سرورهای API Gateway تحت تأثیر ناتوانی آنها در برقراری ارتباط با شبکه داخلی در اوایل این رویداد قرار گرفتند. در نتیجه این خطاها، بسیاری از سرورهای API Gateway در نهایت به وضعیتی رسیدند که برای ارائه موفقیت آمیز درخواست ها باید جایگزین شوند. این معمولاً از طریق یک فرآیند بازیافت خودکار اتفاق می‌افتد، اما تا زمانی که APIهای EC2 شروع به بازیابی نکردند، این امکان وجود نداشت. در حالی که API Gateways شروع به بازیابی در ساعت 1:35 بعد از ظهر به وقت PST کرد، خطاها و تأخیرها همچنان بالا ماند زیرا ظرفیت API Gateway توسط فرآیند خودکار که از طریق بک لاگ سرورهای آسیب‌دیده کار می‌کرد بازیافت شد. این سرویس تا ساعت 4:37 بعد از ظهر به وقت PST بهبود یافت، اما مشتریان API Gateway ممکن است برای چندین ساعت با تثبیت کامل API Gateways سطوح پایینی از خطاها و throttling را تجربه کنند. تیم API Gateway در حال کار بر روی مجموعه‌ای از اقدامات کاهشی است تا اطمینان حاصل کند که سرورهای API Gateway حتی زمانی که شبکه داخلی در دسترس نیست سالم می‌مانند و در فرآیند بازیافت بهبودهایی را برای سرعت بخشیدن به تلاش‌های بازیابی در صورت بروز مشکل مشابه در آینده انجام می‌دهند. EventBridge که اغلب همراه با لامبدا نیز استفاده می‌شود، در مراحل اولیه رویداد با خطاهای بالایی مواجه شد اما در ساعت 9:28 صبح به وقت PST زمانی که مشکل DNS داخلی حل شد، مقداری بهبود یافت. با این حال، در طول تلاش‌های کاهش بار برای کاهش بار روی دستگاه‌های شبکه آسیب‌دیده، اپراتورها تحویل رویداد را برای EventBridge در ساعت 12:35 بعد از ظهر غیرفعال کردند. تحویل رویداد در ساعت 2:35 بعد از ظهر PST مجدداً فعال شد، با این حال سرویس تاخیر تحویل رویداد را تا ساعت 6:40 بعد از ظهر PST تجربه کرد زیرا رویدادهای عقب افتاده را پردازش می کرد.
سرویس‌های کانتینر AWS، از جمله Fargate، ECS و EKS، نرخ‌های خطای API و تأخیر بیشتری را در طول رویداد تجربه کردند. در حالی که نمونه‌های کانتینر موجود (کارها یا غلاف‌ها) به طور عادی در طول رویداد به کار خود ادامه می‌دهند، اگر یک نمونه کانتینر خاتمه یابد یا دچار نقص شود، نمی‌توان آن را مجدداً راه‌اندازی کرد زیرا به APIهای صفحه کنترل EC2 که در بالا توضیح داده شد، راه‌اندازی نشد. در ساعت 1:35 بعد از ظهر به وقت PST، بیشتر نرخ‌های خطای API مربوط به کانتینر به حالت عادی بازگشتند، اما Fargate با افزایش بار درخواست به دلیل انباشتگی نمونه‌های کانتینر که باید شروع به کار می‌کردند، افزایش یافت که منجر به افزایش نرخ خطا و خطاهای ظرفیت ناکافی شد. به عنوان استخر ظرفیت کانتینر در حال تکمیل شدن بود. در ساعت 5:00 بعد از ظهر PST، نرخ خطای API Fargate شروع به بازگشت به سطوح عادی کرد. برخی از مشتریان چندین ساعت پس از بازیابی، خطاهای ظرفیت ناکافی را برای اندازه‌های کار “4 vCPU” مشاهده کردند. آمازون کانکت برای رسیدگی به تماس‌های تلفنی، جلسات چت و مخاطبین وظیفه در طول رویداد، نرخ‌های خرابی بالایی را تجربه کرد. مشکلات مربوط به دروازه‌های API که توسط Connect برای اجرای توابع Lambda استفاده می‌شد، منجر به افزایش نرخ شکست برای تماس‌های تلفنی ورودی، جلسات چت یا مخاطبین وظیفه شد. در ساعت 4:41 بعد از ظهر به وقت PST، زمانی که دروازه API آسیب دیده به طور کامل بهبود یافت، آمازون کانکت فعالیت های عادی خود را از سر گرفت. ارتباط رویداد ما می‌دانیم که رویدادهایی مانند این زمانی تأثیرگذارتر و ناامیدکننده‌تر می‌شوند که اطلاعات مربوط به آنچه اتفاق می‌افتد به آسانی در دسترس نباشد. اختلال در سیستم‌های نظارت ما درک ما از این رویداد را به تأخیر انداخت و ازدحام شبکه باعث شد ابزار داشبورد سلامت خدمات ما به درستی در منطقه آماده به کار ما از کار بیفتد. تا ساعت 8:22 صبح به وقت PST، داشبورد سلامت سرویس را با موفقیت به‌روزرسانی می‌کردیم. از آنجایی که تأثیر سرویس‌ها در طول این رویداد همه از یک علت ریشه‌ای منشا می‌گرفت، ما تصمیم گرفتیم به‌روزرسانی‌ها را از طریق یک بنر جهانی در داشبورد خدمات سلامت ارائه کنیم، که از آن زمان متوجه شدیم که پیدا کردن اطلاعات در مورد این مشکل را برای برخی از مشتریان دشوار می‌کند. مرکز تماس پشتیبانی ما همچنین به شبکه AWS داخلی متکی است، بنابراین توانایی ایجاد موارد پشتیبانی از ساعت 7:33 صبح تا 2:25 بعد از ظهر به وقت محلی تحت تأثیر قرار گرفت. ما روی بهبودهای متعددی در خدمات پشتیبانی خود کار کرده‌ایم تا اطمینان حاصل کنیم که می‌توانیم با اطمینان بیشتر و سریع‌تر در طول مسائل عملیاتی با مشتریان ارتباط برقرار کنیم. ما انتظار داریم نسخه جدیدی از داشبورد سلامت سرویس خود را در اوایل سال آینده منتشر کنیم که درک تأثیر سرویس و معماری سیستم پشتیبانی جدید را که به طور فعال در چندین منطقه AWS اجرا می شود را آسان تر می کند تا اطمینان حاصل شود که در برقراری ارتباط با مشتریان تاخیری نداریم.
در آستانه نزدیک شدن در نهایت، ما می خواهیم به دلیل تأثیری که این رویداد برای مشتریان ما ایجاد کرد، عذرخواهی کنیم. در حالی که ما به سابقه در دسترس بودن خود افتخار می کنیم، می دانیم که خدمات ما برای مشتریان، برنامه های کاربردی و کاربران نهایی و کسب و کار آنها چقدر حیاتی است. ما می دانیم که این رویداد به روش های قابل توجهی بر بسیاری از مشتریان تأثیر گذاشته است. ما هر کاری که بتوانیم انجام خواهیم داد تا از این رویداد بیاموزیم و از آن برای بهبود بیشتر در دسترس بودن خود استفاده کنیم.
