استراتژیهای Canary و Linear در Amazon ECS
خلاصهٔ کاملتر
Amazon ECS اخیراً پشتیبانی از دو استراتژی دیپلوی تدریجی رو اضافه کرده: linear و canary. این قابلیتها کنار blue/green و rolling که قبلاً وجود داشتن، یه لایه کنترل بیشتری به تیمهای عملیاتی میدن تا بتونن نسخههای جدید رو با ریسک کمتری منتشر کنن.
در استراتژی linear، ترافیک در گامهای مساوی جابجا میشه — مثلاً هر ۵ دقیقه ۱۰٪ — تا وقتی که کل ترافیک به نسخه جدید برسه. در استراتژی canary، ابتدا فقط یه درصد کوچیک (مثلاً ۵٪) به نسخه جدید میره و برای یه بازه زمانی مشخص مانیتور میشه؛ اگه همه چیز خوب بود، بقیه ترافیک یکجا منتقل میشه.
زیرساخت هر دو استراتژی روی Elastic Load Balancing weighted target groups بنا شده. ECS دو target group — آبی (نسخه قدیم) و سبز (نسخه جدید) — رو مدیریت میکنه و وزن ترافیک بینشون رو تنظیم میکنه. CloudWatch Alarms هم همیشه در حال نظارته و اگه خطا یا تأخیر از آستانه تعریفشده رد بشه، دیپلوی متوقف و ترافیک به نسخه پایدار برمیگرده.
برای فعالسازی استراتژی linear، کافیه سرویس ECS رو با پارامترهای مناسب آپدیت کنی:
"strategy": "LINEAR",
"linearConfiguration": {
"stepPercent": 10,
"stepBakeTimeInMinutes": 5
}و برای canary:
"strategy": "CANARY",
"canaryConfiguration": {
"canaryPercent": 5,
"canaryBakeTimeInMinutes": 20
}bake time یه مفهوم مهمه — بازهای که بعد از هر گام جابجایی ترافیک، هر دو نسخه آبی و سبز با هم اجرا میشن. این بازه باید به اندازهای باشه که خطاهای احتمالی (مثلاً افزایش نرخ ۵XX یا latency بالا) فرصت داشته باشن توی CloudWatch ظاهر بشن. هرچه bake time بیشتر باشه، هزینه بیشتره اما امنیت رولبک هم بیشتره.
نکات کلیدی:
- استراتژی linear برای APIها و microserviceها مناسبه؛ canary برای سرویسهای حساس مثل پرداخت یا مدلهای ML
- هر دو استراتژی از lifecycle hooks پشتیبانی میکنن تا بتونی Lambda برای validation سفارشی اضافه کنی
- رولبک نیازی به ریدیپلوی نداره — فقط وزن ترافیک برمیگرده
- این قابلیتها در تمام Regions تجاری AWS در دسترسن
