Blue-Green ও Canary Deploy
- ●Deployment strategy ঠিক করে নতুন version কীভাবে live হবে — downtime ও ঝুঁকি কমানোই মূল লক্ষ্য।
- ●Blue-Green-এ দুটি সমান environment থাকে, traffic মুহূর্তে switch হয়; Canary-তে অল্প user-এ আগে test হয়।
- ●Rollback সহজ রাখা ও zero-downtime নিশ্চিত করা যেকোনো deploy strategy-র প্রাণ।
সমস্যাটা কী?
তোমার অ্যাপ live, লক্ষ লক্ষ ব্যবহারকারী প্রতি সেকেন্ডে ব্যবহার করছে। এখন তুমি একটা নতুন feature deploy করতে চাও। যদি তুমি পুরোনো version বন্ধ করে নতুনটা চালাও, তাহলে মাঝখানের কয়েক সেকেন্ড/মিনিট অ্যাপ ডাউন থাকবে — ব্যবহারকারীরা error পাবে, ব্যবসার ক্ষতি হবে।
আরও বড় বিপদ — নতুন version-এ যদি লুকানো bug থাকে? সব user একসাথে সেই bug-এ পড়লে বিপর্যয়। তখন দ্রুত আগের version-এ rollback করা দরকার, কিন্তু সেটাও যদি কঠিন হয়?
এই সমস্যাগুলোর সমাধানই হলো বিভিন্ন deployment strategy — যা ঠিক করে নতুন version কীভাবে, কত দ্রুত, কতটা ঝুঁকি নিয়ে live হবে।
মূল ধারণা
Deployment strategy হলো একটি নতুন version production-এ আনার পরিকল্পিত পদ্ধতি, যার লক্ষ্য downtime ও ঝুঁকি কমানো এবং প্রয়োজনে দ্রুত rollback নিশ্চিত করা।
দুটি মূল চাওয়া সবসময় থাকে — zero downtime (deploy-এর সময় অ্যাপ চালু থাকবে) আর নিরাপদ rollback (সমস্যা হলে দ্রুত আগের অবস্থায় ফেরা)। বিভিন্ন strategy এই দুটোর মধ্যে ভিন্ন ভিন্ন ভারসাম্য আনে।
কীভাবে কাজ করে
বিভিন্ন strategy-র তুলনা
| Strategy | Downtime | Rollback গতি | Resource খরচ | ঝুঁকি |
|---|---|---|---|---|
| Recreate | হ্যাঁ (থাকে) | ধীর | কম | বেশি |
| Rolling | নেই | মাঝারি | কম | মাঝারি |
| Blue-Green | নেই | তাৎক্ষণিক | বেশি (দ্বিগুণ) | কম |
| Canary | নেই | দ্রুত | মাঝারি | সবচেয়ে কম |
Recreate
সবচেয়ে সরল — পুরোনো version পুরোপুরি বন্ধ করো, তারপর নতুনটা চালু করো। মাঝখানে downtime হয়। শুধু internal tool বা যেখানে downtime সমস্যা নয়, সেখানে চলে।
Rolling
ধীরে ধীরে instance বদলানো হয় — একবারে কয়েকটা instance নতুন version-এ যায়, বাকিরা পুরোনো version-এ traffic সামলায়। Kubernetes-এর default। Downtime নেই, কিন্তু কিছুক্ষণ পুরোনো ও নতুন version একসাথে চলে।
Blue-Green
দুটি একদম সমান environment — Blue (বর্তমান live) আর Green (নতুন version)। Green-এ নতুন version deploy ও test করা হয়, তারপর load balancer-এ traffic এক মুহূর্তে Blue থেকে Green-এ switch করা হয়। সমস্যা হলে আবার Blue-তে switch — তাৎক্ষণিক rollback। অসুবিধা: দ্বিগুণ resource লাগে।
Canary
খনি শ্রমিকরা আগে খাঁচায় ক্যানারি পাখি নিয়ে যেত — পাখি অসুস্থ হলে বুঝত বাতাসে বিষ। তেমনি, প্রথমে অল্প (যেমন 5%) user-কে নতুন version দেওয়া হয়। তাদের কাছে error/latency monitor করা হয়। সব ভালো হলে ধীরে ধীরে 25%, 50%, 100% — বাড়ানো হয়। সমস্যা ধরা পড়লে শুধু অল্প user প্রভাবিত হয়।
ভাবো তুমি একটা বিরিয়ানির দোকানের মালিক, নতুন রেসিপি চালু করতে চাও। Recreate হলো — পুরোনো রান্না বন্ধ করে নতুন রান্না শুরু (এর মধ্যে দোকান বন্ধ, খদ্দের ফিরে যায়)। Blue-Green হলো — পাশে আরেকটা চুলায় নতুন রেসিপি পুরো রেডি করে রাখলে, তারপর হঠাৎ সব খদ্দেরকে নতুন হাঁড়ি থেকে দেওয়া শুরু; খারাপ হলে আগের হাঁড়িতে ফেরা। Canary হলো — প্রথমে ১০ জন খদ্দেরকে নতুন বিরিয়ানি চাখিয়ে দেখা; পছন্দ হলে সবাইকে দেওয়া, না হলে শুধু ১০ জনই খেল।
কৌশল
Feature Flag
Deployment আর "release"-কে আলাদা করার শক্তিশালী কৌশল। Code deploy হয়ে যায়, কিন্তু নতুন feature একটা flag (on/off switch)-এর পেছনে লুকানো থাকে। তুমি কোনো code পরিবর্তন ছাড়াই flag চালু করে নির্দিষ্ট user-দের জন্য feature খুলে দিতে পারো, সমস্যা হলে সাথে সাথে বন্ধ করতে পারো।
if featureFlag("new_checkout").isEnabledFor(user):
showNewCheckout()
else:
showOldCheckout()
Rollback পরিকল্পনা
প্রতিটি deploy-এর আগে ভাবো — "ভেঙে গেলে কীভাবে ফিরব?" আগের version-এর image সংরক্ষিত রাখো, database migration backward-compatible রাখো।
কখন ব্যবহার করবে / করবে না
- Recreate: internal tool, downtime সমস্যা নয় এমন জায়গায়।
- Rolling: সাধারণ stateless web service, resource সীমিত।
- Blue-Green: critical অ্যাপ, যেখানে দ্রুত rollback জরুরি এবং দ্বিগুণ resource সামলানো যায়।
- Canary: high-traffic অ্যাপ, যেখানে নতুন version-এর ঝুঁকি যাচাই করা সবচেয়ে গুরুত্বপূর্ণ।
Blue-Green বা Canary-তে যখন পুরোনো ও নতুন version একসাথে চলে, তখন database compatibility একটা বড় ফাঁদ। নতুন version যদি database schema বদলায় এমনভাবে যা পুরোনো version বুঝতে পারে না, তাহলে rollback করার সময় সব ভেঙে পড়বে। তাই migration সবসময় backward-compatible রাখো — আগে column যোগ করো, পরে পুরোনো code সরাও।
বাস্তব উদাহরণ
Facebook বা Netflix-এর মতো বড় কোম্পানি প্রায় সবসময় Canary + Feature Flag ব্যবহার করে। তারা নতুন feature প্রথমে নিজেদের কর্মীদের, তারপর একটা ছোট দেশের অল্প user-কে দেয়। Error rate, latency, business metric (যেমন checkout সংখ্যা) monitor করে। কিছু খারাপ দেখলে feature flag বন্ধ করে দেয় — কোনো নতুন deploy ছাড়াই।
একটা bangladeshi fintech-এর কথা ভাবো — তারা নতুন payment flow Blue-Green-এ deploy করে। Green environment-এ পুরো test করে, তারপর গভীর রাতে (কম traffic-এ) traffic switch করে। সকালে সমস্যা দেখা দিলে এক ক্লিকে Blue-তে ফিরে যায়, ব্যবহারকারী টেরও পায় না।
Interview-তে "zero-downtime deploy কীভাবে করবে?" প্রশ্নে শুধু একটা strategy বলে থেমো না। বলো — Rolling default, কিন্তু দ্রুত rollback লাগলে Blue-Green, আর ঝুঁকি যাচাই করতে হলে Canary। সবচেয়ে গুরুত্বপূর্ণ — feature flag দিয়ে deploy আর release আলাদা করার কথা বললে interviewer বুঝবে তুমি বাস্তব production সমস্যা বোঝো।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Blue-Green deployment-এর মূল সুবিধা কী?
2. Canary deployment কীভাবে কাজ করে?
3. Recreate strategy-র বড় অসুবিধা কী?