Zero Downtime، Rollback فوری و انتشار هوشمندانه‌تر، با مثال‌های ساده، نمودارها و راهنمای انتخاب استراتژی مناسب.
قبلا انتشار نسخه جدید نرم‌افزار به این معنا بود که باید یک ساعت خلوت انتخاب می‌کردیم، صفحه‌ای با پیام «در حال تعمیر و نگهداری» نمایش می‌دادیم و امیدوار بودیم مشکلی پیش نیاید. امروزه کاربران انتظار دارند اپلیکیشن‌ها به‌صورت پیوسته و بدون ایجاد اختلال به‌روزرسانی شوند، بدون اینکه حتی متوجه این تغییرات شوند. رسیدن به چنین تجربه‌ای به یک Deployment Strategy یا استراتژی دپلوی نیاز دارد، روشی ساختاریافته برای انتقال کد جدید به محیط پروداکشن که در عین کنترل ریسک، امکان انتشار نسخه‌های جدید را فراهم می‌کند.
در این مقاله، چهار استراتژی پرکاربرد در مهندسی نرم‌افزار مدرن را بررسی می‌کنیم. برای هر استراتژی، ایده اصلی، یک مثال قابل‌درک، منطق فنی، مزایا و محدودیت‌ها و شرایط مناسب استفاده از آن را توضیح می‌دهیم.
چرا استراتژی دپلوی اهمیت دارد؟
هر بار دپلوی کردن، نوعی مدیریت ریسک است. ممکن است کد در محیط Staging به‌درستی کار کرده باشد، تست‌ها با موفقیت اجرا شده باشند و Pull Request هم تایید شده باشد، اما فقط محیط پروداکشن است که کاربران واقعی، الگوهای واقعی ترافیک و داده‌ها را در مقیاس عملیاتی در خود دارد.
هدف از داشتن یک استراتژی دپلوی پاسخ به یک سوال کاربردی است: چطور کد جدید را در معرض شرایط واقعی قرار دهیم، بدون اینکه در صورت وجود مشکل، آسیبی ایجاد کنیم؟
چهار استراتژی زیر در طیفی از رویکردها قرار می‌گیرند. در یک سمت این طیف، Blue-Green با هدف بازیابی فوری طراحی شده است. در سمت دیگر، A/B Testing قرار دارد که تمرکزش بر اندازه‌گیری و مقایسه عملکرد نسخه‌هاست.
۱. Blue-Green Deployment
در روش Blue-Green Deployment، دو محیط پروداکشن یکسان به‌صورت هم‌زمان وجود دارند که معمولا آن‌ها را Blue و Green می‌نامیم. در هر لحظه فقط یکی از این دو محیط به کاربران واقعی سرویس می‌دهد و محیط دیگر غیرفعال است تا نسخه بعدی نرم‌افزار روی آن مستقر شود.
تصور کنید صحنه یک تئاتر روی سکویی بزرگ و چرخان ساخته شده است. در یک سمت سکو، یعنی بخش Blue، بازیگران مشغول اجرای نمایش فعلی برای تماشاگران هستند. در سمت دیگر که از دید تماشاگران پنهان است، گروه طراحی صحنه با آرامش دکور نمایش بعدی را آماده می‌کند و تمرین‌ها را انجام می‌دهد. وقتی همه‌چیز آماده شد، کارگردان دکمه‌ای را فشار می‌دهد، سکو ۱۸۰ درجه می‌چرخد و تماشاگران بلافاصله نمایش جدید را می‌بینند. در تمام این مدت، حتی برای یک لحظه هم پرده بسته نمی‌شود.
مهم‌ترین مزیت این روش، Zero Downtime یا جلوگیری از قطعی سرویس است. مهندسان نسخه جدید را روی محیط غیرفعال دپلوی می‌کنند و سپس ترافیک را به آن منتقل می‌کنند. اگر بلافاصله یک باگ بحرانی ظاهر شود، می‌توانند مسیر را برعکس کنند و کاربران را در عرض چند میلی‌ثانیه به محیط پایدار قبلی برگردانند. همین قابلیت Rollback سریع است که این استراتژی را برای انتشار نسخه‌های حساس و پرریسک جذاب می‌کند.
در معماری معمول این روش، ابتدا تمام ترافیک مرورگرها به Blue، یعنی محیط فعال، هدایت می‌شود و Green غیرفعال باقی می‌ماند. پس از تغییر مسیر، Green به محیط فعال پروداکشن تبدیل می‌شود و Blue در حالت آماده‌به‌کار قرار می‌گیرد. در این الگو، لود بالانسر (Load Balancer) صرفا مسیر فعال ترافیک را تغییر می‌دهد.
مهم‌ترین محدودیت این روش، هزینه زیرساخت است. نگهداری دو محیط کامل پروداکشن تقریبا به دو برابر منابع زیرساختی نیاز دارد، با اینکه در هر لحظه فقط یکی از آن‌ها ترافیک را پردازش می‌کند.
چالش مهم دیگر، مدیریت State مشترک است. معمولا هر دو محیط به یک دیتابیس مشترک متصل هستند، بنابراین تغییرات اسکیما (Schema) باید در زمان جابه‌جایی با هر دو نسخه سازگار باشند. تیم‌های دوآپس و مهندسی Release معمولا این روش را با استفاده از لود بالانسرهایی مانند NGINX یا AWS Elastic Load Balancing و در کنار Containerization پیاده‌سازی می‌کنند.
۲. Canary Deployment
در روش Canary Deployment، نسخه جدید ابتدا برای بخش کوچکی از کاربران منتشر می‌شود. سپس، با افزایش اطمینان از عملکرد صحیح آن، انتشار به‌تدریج گسترش پیدا می‌کند.
نام این روش از قناری‌هایی گرفته شده است که معدن‌کاران در گذشته با خود به داخل معدن می‌بردند تا پیش از آنکه گاز سمی جان تمام اعضای گروه را تهدید کند، از وجود خطر مطلع شوند.
فرض کنید یک سرآشپز می‌خواهد غذای جدیدی را به منوی رستوران اضافه کند. به‌جای اینکه غذا را هم‌زمان برای تمام مشتریان سرو کند، ابتدا آن را به چند مشتری ثابت و مورد اعتماد پیشنهاد می‌دهد و واکنش آن‌ها را بررسی می‌کند. اگر بازخوردها مثبت باشد، غذا وارد منوی اصلی می‌شود. اگر مشکلی وجود داشته باشد، فقط تعداد کمی از مشتریان تحت تاثیر قرار گرفته‌اند و سرآشپز می‌تواند دستور پخت را اصلاح کند.
منطق اصلی این روش، کنترل آماری ریسک است. برای مثال، با هدایت ۱ درصد از ترافیک به نسخه جدید، می‌توانید نرخ خطا، Latency و رفتار کاربران را در شرایط واقعی پروداکشن بررسی کنید، درحالی‌که دامنه تاثیر احتمالی خرابی محدود می‌ماند.
اگر معیارهای عملکردی در وضعیت مناسبی باشند، سهم ترافیک نسخه جدید را به ۵ درصد، سپس ۲۵ درصد و به همین ترتیب افزایش می‌دهید تا نسخه جدید تمام ترافیک را مدیریت کند.
یک مدل ذهنی مفید این است که تا زمانی که شواهد کافی درباره پایداری نسخه جدید به دست نیاورده‌اید، سهم کاربران نسخه پایدار، یعنی 1-p، نزدیک به ۱۰۰ درصد باقی بماند، در این رابطه، p سهم ترافیکی است که به نسخه جدید اختصاص داده شده است.
Canary Deployment زمانی بسیار کاربردی است که به اعتبارسنجی در دنیای واقعی نیاز دارید، برای مثال، بررسی عملکرد نرم‌افزار زیر بار واقعی که محیط Staging به‌تنهایی نمی‌تواند آن را به‌خوبی شبیه‌سازی کند.
البته این روش به Observability قوی نیاز دارد. بدون مانیتورینگ قابل‌اعتماد و سازوکارهای خودکار برای Rollback، نمی‌توانید به‌درستی تشخیص دهید که نسخه Canary عملکرد خوبی دارد یا به‌آرامی در حال بروز مشکل است. در این صورت، هدف اصلی این استراتژی از بین می‌رود.
۳. Rolling Deployment
در روش Rolling Deployment، سرورها به‌صورت تدریجی به‌روزرسانی می‌شوند. در هر مرحله، تعدادی از Instanceهای قدیمی با Instanceهای جدید جایگزین می‌شوند تا در نهایت تمام سرورها نسخه جدید را اجرا کنند.
برخلاف Blue-Green، این روش به یک محیط کامل پروداکشن دیگر نیاز ندارد، به همین دلیل، در بسیاری از پلتفرم‌های ارکستریشن کانتینر، مانند کوبرنتیز، به‌عنوان یک روش پیش‌فرض استفاده می‌شود.
تصور کنید می‌خواهید یک حصار طولانی را رنگ‌آمیزی کنید. به‌جای اینکه کل حصار را پایین بیاورید، هر بار فقط یک تخته را رنگ می‌کنید. حصار در تمام مدت پابرجا و قابل استفاده باقی می‌ماند و فقط بخش کوچکی از آن در حال کار است. در نهایت، تمام تخته‌ها رنگ جدیدی دارند، بدون اینکه لازم باشد حصار را از ابتدا برپا کنید.
مزیت اصلی این روش، استفاده بهینه از زیرساخت موجود است. چون نیازی به ایجاد یک محیط کامل جدید ندارید، هزینه‌ها پایین می‌مانند و به‌روزرسانی به‌تدریج در سراسر کلاستر انجام می‌شود.
در مقابل، طی فرایند دپلوی دو نسخه از نرم‌افزار هم‌زمان اجرا می‌شوند. اگر این دو نسخه با یکدیگر Backward Compatible نباشند، ممکن است مشکلاتی به وجود بیاید، به‌خصوص زمانی که هر دو به یک دیتابیس مشترک متصل هستند.
Rollback نیز در این روش کندتر است. به‌جای تغییر مسیر ترافیک با یک سوئیچ ساده، باید فرایند جایگزینی Instanceها را معکوس کنید. به همین دلیل، بازیابی پس از یک انتشار ناموفق ممکن است چند دقیقه طول بکشد، نه چند میلی‌ثانیه.
۴. A/B Testing Deployment
درحالی‌که سه استراتژی قبلی عمدتا بر ایمنی انتشار تمرکز دارند، A/B Testing با هدف اندازه‌گیری و مقایسه عملکرد به کار می‌رود.
در این روش، گروه‌های مختلف کاربران به نسخه‌های متفاوت یک قابلیت هدایت می‌شوند تا رفتار آن‌ها مقایسه شود و مشخص شود کدام نسخه در دستیابی به یک هدف تجاری مشخص عملکرد بهتری دارد.
تصور کنید یک کتاب‌فروشی دو چیدمان متفاوت برای نمایش کتاب‌ها در نظر می‌گیرد، یکی نزدیک ورودی و دیگری کنار صندوق. سپس بررسی می‌کند که کدام چیدمان به فروش کتاب‌های بیشتری منجر می‌شود. هر دو چیدمان واقعا در حال استفاده هستند و این آزمایش مشخص می‌کند کدام طراحی نتیجه بهتری دارد.
تفاوت اصلی این روش با استراتژی‌های قبلی، هدف استفاده از آن است.
در Canary Deployment سوال این است: «آیا این نسخه پایدار است؟»
اما در A/B Testing سوال این است: «آیا این نسخه بهتر عمل می‌کند؟»
در A/B Testing، هدایت کاربران معمولا بر اساس ویژگی‌های آن‌ها یا تخصیص تصادفی انجام می‌شود، نه صرفا افزایش تدریجی درصد ترافیک. همچنین، موفقیت نسخه‌ها با معیارهایی مانند Conversion Rate یا میزان تعامل کاربران سنجیده می‌شود، نه فقط نرخ خطا.
در عمل، تیم‌ها می‌توانند چند تکنیک را با هم ترکیب کنند. برای مثال، یک قابلیت ابتدا از بررسی پایداری با Canary Deployment عبور می‌کند و سپس وارد آزمایش A/B می‌شود تا مشخص شود آیا واقعا تجربه محصول را بهبود می‌دهد یا خیر.
مقایسه چهار استراتژی Deploy
هیچ استراتژی‌ای برای تمام شرایط بهترین انتخاب نیست؛ هرکدام برای اولویت متفاوتی طراحی شده‌اند. جدول زیر تفاوت‌های اصلی این چهار روش را از نظر معیارهایی که معمولا در تصمیم‌گیری نقش دارند، خلاصه می‌کند.
| استراتژی | هدف اصلی | سرعت Rollback | هزینه زیرساخت | ریسک ناسازگاری با دیتابیس |
|---|---|---|---|---|
| Blue-Green | بدون قطعی سرویس و بازیابی فوری | فوری (در حد میلی‌ثانیه) | زیاد (دو برابر شدن محیط‌ها) | متوسط |
| Canary | مواجهه تدریجی و کنترل‌شده با ریسک | سریع | متوسط | متوسط |
| Rolling | استفاده بهینه از منابع | کند (Instance به Instance) | کم | زیاد |
| A/B Testing | بهینه‌سازی مبتنی بر داده | متغیر | متوسط | کم |
راهنمای انتخاب استراتژی دپلوی
اگر مطمئن نیستید برای انتشار یک نسخه مشخص از کدام روش استفاده کنید، پاسخ به چند سوال به‌ترتیب می‌تواند انتخاب را ساده‌تر کند. ابتدا هدف خود را مشخص کنید و سپس محدودیت‌هایی مانند هزینه زیرساخت و بلوغ سیستم مانیتورینگ را در نظر بگیرید.
راهنمای تصمیم‌گیری را از بالا به پایین دنبال کنید:
- اگر می‌خواهید بدانید کدام نسخه عملکرد بهتری دارد، از A/B Testing استفاده کنید.
- اگر به انتشار ایمن و Rollback فوری نیاز دارید، Blue-Green گزینه مناسبی است، البته به شرطی که توانایی تامین هزینه دو محیط کامل پروداکشن را داشته باشید.
- اگر نمی‌توانید هزینه دو محیط کامل را بپردازید، یا سیستم آن‌قدر حساس نیست که چنین هزینه‌ای را توجیه کند، بلوغ سیستم مانیتورینگ تعیین‌کننده می‌شود.
- اگر Observability لحظه‌ای و قابل‌اعتماد دارید، Canary می‌تواند گزینه امن‌تری برای انتشار تدریجی باشد.
- اگر ابزارها و سازوکارهای مانیتورینگ کافی ندارید، تیم‌ها معمولا به سراغ Rolling Deployment ساده‌تر می‌روند.
اشتباهات رایج که باید از آن‌ها اجتناب کنید
یکی از رایج‌ترین اشتباهات در هر چهار استراتژی، نادیده گرفتن دیتابیس است.
در روش‌های Blue-Green، Canary و Rolling، ممکن است دو نسخه از اپلیکیشن در بخشی از فرایند دپلوی به‌صورت هم‌زمان با داده‌های مشترک کار کنند. در چنین شرایطی، یک مایگریشن که با نسخه قبلی سازگار نیست، می‌تواند باعث خراب شدن داده‌ها یا از کار افتادن نسخه قدیمی شود، حتی اگر کد نسخه جدید کاملا درست باشد.
راهکار استاندارد برای این مسئله، الگوی Expand-and-Contract است. در این الگو، ابتدا ستون‌ها یا جدول‌های جدید را بدون حذف ساختارهای قدیمی اضافه می‌کنید. سپس نسخه جدید کد را دپلوی می‌کنید و تنها پس از انتقال تمام Instanceها به نسخه جدید، ساختارهای قدیمی را حذف می‌کنید.
اشتباه دوم، در نظر گرفتن Rollback به‌عنوان یک گزینه ساده و بررسی‌نشده است. Rollback فوری فقط زمانی مفید است که فرایند آن را از قبل تمرین کرده باشید و مطمئن شوید محیط قبلی واقعا سالم است.
در نهایت، Canary و A/B Testing در صورت ضعیف بودن Observability ممکن است بدون هشدار مشخصی شکست بخورند، زیرا هر دو برای تصمیم‌گیری درباره ادامه انتشار یا بازگشت به نسخه قبلی به معیارهای قابل‌اعتماد وابسته‌اند.
بنابراین، سرمایه‌گذاری روی مانیتورینگ یک کار تکمیلی نیست، بلکه پیش‌نیاز استفاده موثر از استراتژی‌های پیشرفته‌تر دپلوی است.
دیدگاه‌ها
ثبت دیدگاه