سه قابلیت تازه AWS Resilience Hub برای تاب‌آوری سرویس‌های ابری
به گزارش وبلاگ معماری AWS، نسل جدید AWS Resilience Hub با سه قابلیت تازه برای هماهنگ نگه‌داشتن محدوده بارهای کاری و الزامات تاب‌آوری با محیط عملیاتی عرضه شده است. پشتیبانی از برچسب‌های Amazon EKS، تحلیل وابستگی‌ها با هوش مصنوعی مولد و اشتراک‌گذاری سیاست‌ها در AWS Organizations، مهم‌ترین تغییراتی هستند که تیم‌های زیرساخت ابری و مدیران پایداری سرویس باید به آن‌ها توجه کنند.
محدوده دقیق‌تر سرویس‌ها و تحلیل وابستگی‌ها
قابلیت نخست به تیم‌ها اجازه می‌دهد منابع Kubernetes را در یک کلاستر Amazon EKS بر اساس برچسب‌های موجود انتخاب کنند. در نتیجه، وقتی چند بار کاری در یک namespace مشترک اجرا می‌شوند، ارزیابی تاب‌آوری می‌تواند فقط منابع متعلق به یک سرویس مشخص را در بر بگیرد. انتخاب‌گرهای برچسب در هر namespace با منطق AND اعمال می‌شوند و در صورت نبود انتخاب‌گر، همه اشیای پشتیبانی‌شده همان namespace شناسایی خواهند شد. زیرساخت مشترک AWS مانند کلاستر، گروه نود، VPC و subnetها نیز در فهرست منابع باقی می‌ماند.
قابلیت Dependency Insights با استفاده از هوش مصنوعی مولد، وابستگی‌های کشف‌شده را خلاصه و موارد نیازمند بررسی را برجسته می‌کند. این بخش می‌تواند وابستگی بین Regionها، وابستگی‌های تازه، سرویس‌های شخص ثالث و الگوهای مصرف نامتوازن را مشخص کند. کشف وابستگی اختیاری و دارای هزینه جداگانه است؛ از فعالیت DNS در Amazon Route 53 Resolver استفاده می‌کند، به نصب عامل روی بار کاری نیاز ندارد و تا ۳۵ روز سابقه موجود را بررسی می‌کند.
AWS تأکید کرده است که این بینش‌ها راه‌حل خودکار تجویز نمی‌کنند و جای بررسی معماری را نمی‌گیرند. برای نمونه، مشاهده ارتباط با یک Region دیگر تنها موضوعی برای ارزیابی اثر آن بر بازیابی سرویس است. همچنین اتصال‌هایی که مستقیماً با آدرس IP برقرار می‌شوند در این روش دیده نمی‌شوند و تولید دوباره گزارش بینش‌ها فقط هر ۲۴ ساعت یک‌بار امکان‌پذیر است.
اشتراک سیاست تاب‌آوری میان حساب‌های سازمان
قابلیت سوم به حساب مدیریتی یا مدیر واگذارشده در AWS Organizations امکان می‌دهد یک سیاست تاب‌آوری مرکزی تعریف و آن را در اختیار حساب‌های عضو قرار دهد. این سیاست می‌تواند اهداف دسترس‌پذیری، بازیابی پس از اختلال Availability Zone یا Region و بازیابی داده را پوشش دهد. هر مالک سرویس می‌تواند سیاست مشترک را انتخاب کند و تیم مرکزی نیز رویدادهای اتصال یا جداسازی آن را برای پیگیری میزان پذیرش ببیند.
برای کسب‌وکارهایی که چند حساب AWS یا کلاستر مشترک دارند، این مجموعه قابلیت‌ها می‌تواند اختلاف میان معماری واقعی و مستندات بازیابی را زودتر آشکار کند و تعریف معیارهای یکسان را ساده‌تر سازد. با این حال، اتصال یک سیاست فقط پذیرش آن را نشان می‌دهد؛ اثبات انطباق سرویس همچنان به ارزیابی حالت‌های خرابی و آزمون تاب‌آوری نیاز دارد.
در مجموع، نسل جدید Resilience Hub مرزبندی سرویس، شناخت وابستگی‌ها و مدیریت مرکزی الزامات بازیابی را به یک جریان منسجم‌تر نزدیک می‌کند؛ اما تصمیم نهایی درباره تغییر معماری همچنان بر عهده تیم‌های فنی و کسب‌وکار است.
