مقدمه: چالش خرابیهای پنهان در زیرساخت ابری
مدیریت خرابیهای آشکار، مانند از کار افتادن یک سرور، بخش آسان کار است. اما خرابیهایی که واقعاً کل مناطق را تحت تأثیر قرار میدهند، آنهایی هستند که بهراحتی قابل تشخیص نیستند. یک ناحیه (Zone) که کند است اما کاملاً از کار نیفتاده، بخشی از ترافیک را از دست میدهد اما همچنان از بررسیهای سلامت عبور میکند. در AWS، هر منطقه (Region) زیرساخت خود را در چندین منطقه در دسترس (Availability Zones) با منابع برق، سرمایش و شبکه مستقل پخش میکند. بنابراین اگر یک ناحیه دچار مشکل شود، برنامه شما از سایر نواحی به سرویسدهی ادامه میدهد. اما نکته دشوار اینجاست که مناطق به ندرت بهصورت تمیز از کار میافتند. در این فضای خاکستری، رفتار پیشفرض بسیاری از سیستمهای خودکار – تشخیص ناسالمی و جایگزینی – میتواند یک مشکل تکناحیهای را به یک قطعی منطقهای تبدیل کند.
تجربه AWS از ساخت تابآوری ناحیهای در Amazon EKS
تیم AWS با ساخت تابآوری ناحیهای (Zonal Resiliency) در Amazon Elastic Kubernetes Service (EKS)، طی سالها مهندسی و اصلاح مداوم بر اساس حوادث واقعی تولید، درسهای ارزشمندی آموخت. سیستمی که در نهایت ساخته شد، امروز از هر کلاستر EKS محافظت میکند. این مقاله به بررسی آنچه در سطح کنترل (Control Plane) Kubernetes که EKS برای هر کلاستر اجرا میکند، آنچه در سطح داده (Data Plane) برای بارهای کاری شما ارائه میشود، و اصولی که این دو را به هم متصل میکند، میپردازد.
مهمترین اصل: پایداری ایستا (Static Stability)
پایداری ایستا اصلی است که در طول یک آسیب ناحیهای، باارزشترین کاری که یک سیستم میتواند انجام دهد این است که واکنش نشان ندهد. بهجای واکنش سریع، سیستم باید ظرفیت موجود را حفظ کند، دور ناحیه بد مسیریابی کند و صبر کند. این رویکرد از تبدیل یک مشکل محدود به یک بحران گسترده جلوگیری میکند.
چرا سطح کنترل (Control Plane) به تابآوری ناحیهای نیاز دارد؟
سطح کنترل EKS از دو بخش اصلی تشکیل شده است: سرور API (نقطه پایانی که kubectl و کنترلرها با آن صحبت میکنند) و ذخیرهگاه داده etcd که وضعیت کامل کلاستر را نگه میدارد. برای تابآوری، این مؤلفهها در چندین منطقه در دسترس پخش میشوند. اگر یک ناحیه غیرقابل دسترس شود، نمونههای باقیمانده در مناطق دیگر به سرویسدهی ادامه میدهند. اما چرا این کار ساده روی کاغذ، به سالها مهندسی نیاز داشت؟ پاسخ در آن چیزی است که در دوره خاکستری قبل از از کار افتادن کامل یک ناحیه رخ میدهد.
دوره خاکستری: وقتی مناطق بهصورت خاکستری از کار میافتند
متداولترین حالت خرابی در سالهای اولیه AWS شامل بررسیهای سلامت و مقیاسبندی خودکار بود. نمونههای سطح کنترل پشت یک متعادلکننده بار شبکه قرار دارند و یک گروه مقیاسبندی خودکار سلامت آنها را نظارت میکند. منطق بررسی سلامت بهصورت مجزا منطقی است: اگر یک نمونه چندین بار در سی ثانیه بررسیها را شکست بخورد، آن را ناسالم علامتگذاری کرده و جایگزین میکند. اما در طول یک آسیب شبکه ناحیهای، این رفتار آبشاری میشود.
یک پارتیشن کوتاه باعث میشود سرورهای API در ناحیه آسیبدیده بررسیهای سلامت را شکست دهند، زیرا شبکه جلوی آنها آسیب دیده است، نه به این دلیل که خود سرورها خراب هستند. گروه مقیاسبندی آنها را خاتمه میدهد و سپس سعی میکند جایگزینهایی را در همان ناحیه آسیبدیده راهاندازی کند که تهیهکننده نیز در آنجا شکست میخورد. وقتی این راهاندازیها شکست میخورند، گروه مقیاسبندی تا سی دقیقه عقبنشینی میکند.
بررسی سلامت متعادلکننده بار نیز تا حدی به این بستگی دارد که آیا سرور API میتواند به etcd دسترسی پیدا کند. بنابراین یک نوسان شبکه بین نواحی میتواند نمونههای سالم را بهعنوان شکستخورده علامتگذاری کند. اثر خالص: یک نوسان سیثانیهای میتواند خاتمهها را در بخش بزرگی از ناوگان ایجاد کند، کشهای گرم را دور بریزد، بار را به وابستگیهای در حال تقلا اضافه کند، و سپس پس از حل رویداد اصلی، از بهبود برای سی دقیقه خودداری کند.
راهحل: تغییر ناحیهای خودکار برای سطح کنترل
AWS یک مکانیسم تغییر وزن خودکار ساخت که فعالیت سطح کنترل را در حدود دو دقیقه از یک ناحیه آسیبدیده خارج میکند. این تغییر بهصورت موازی علیه چندین سیستم عمل میکند:
- در لایه DNS: برای کلاسترهایی که از طریق یک نقطه پایانی عمومی قابل دسترسی هستند، سطح کنترل پشت یک متعادلکننده بار قرار دارد که آدرسهای آن از طریق DNS با بررسیهای سلامت هر ناحیه توزیع میشود. با فعالسازی تغییر، بررسی سلامت برای ناحیه آسیبدیده شکست میخورد و DNS ارائه سوابق آن ناحیه را متوقف میکند.
- در لایه شبکه و مقیاسبندی: وزن نمونههای سالم در سایر نواحی افزایش یافته و ترافیک بهسمت آنها هدایت میشود.
- در سطح etcd: اعضای غیرفعال etcd در ناحیه آسیبدیده از خوشه حذف میشوند تا از اختلال در نوشتن دادهها جلوگیری شود.
پایداری ایستا در عمل: حفظ ظرفیت و صبر
مهمترین نکته در این مکانیسم، حفظ ظرفیت موجود و عدم واکنش سریع است. بهجای تلاش برای جایگزینی نمونههای از دست رفته در ناحیه آسیبدیده، سیستم آنها را رها کرده و از ظرفیت سالم در سایر نواحی استفاده میکند. این رویکرد باعث میشود که خرابی از یک ناحیه فراتر نرود و سیستم بهسرعت پس از رفع مشکل به حالت عادی بازگردد.
درسهای آموخته شده برای معماری Kubernetes
این تجربیات AWS نشان میدهد که برای طراحی سیستمهای تابآور در Kubernetes، باید به نکات زیر توجه کرد:
- از واکنش سریع به خرابیهای جزئی خودداری کنید. همیشه فرض نکنید که یک نمونه ناسالم باید فوراً جایگزین شود.
- پایداری ایستا را در طراحی خود بگنجانید. سیستم باید در شرایط بحرانی «تغییر وضعیت» ندهد، بلکه ظرفیت موجود را حفظ کرده و مسیریابی مجدد انجام دهد.
- بررسیهای سلامت را با دقت طراحی کنید. بررسیهای سلامت نباید به عواملی وابسته باشند که ممکن است در اثر مشکلات شبکه تحت تأثیر قرار گیرند.
- از مکانیسمهای تغییر وزن خودکار استفاده کنید. این مکانیسمها میتوانند در عرض چند دقیقه ترافیک را از مناطق آسیبدیده دور کنند.
نتیجهگیری
تجربه AWS در اجرای Kubernetes روی میلیونها کلاستر نشان داد که بزرگترین تهدیدها برای تابآوری ناحیهای، خرابیهای آشکار نیستند، بلکه رفتارهای خودکار و نادرست در مواجهه با خرابیهای جزئی و خاکستری هستند. با اتخاذ اصل پایداری ایستا و پیادهسازی مکانیسمهای تغییر وزن خودکار، EKS توانسته است از تبدیل مشکلات تکناحیهای به قطعیهای منطقهای جلوگیری کند. این درسها برای هر معماری ابری که به دنبال تابآوری واقعی است، حیاتی است.
