Giới thiệu Elastic Beanstalk

AWS Elastic Beanstalk là một dịch vụ dễ sử dụng để triển khai và mở rộng các ứng dụng web và dịch vụ được phát triển bằng Java, .NET, PHP, Node.js, Python, Ruby, Go và Docker trên những máy chủ quen thuộc như Apache, Nginx, Passenger và IIS.

4 chiến lược deploy của Elastic Beanstalk

Elastic Beanstalk có 4 chiến lược để deploy:

• All at Once
• Rolling
• Rolling with additional batch
• Immutable

All at Once

All at Once là chiến lược deploy version mới tất cả các instance hiện có cùng 1 lúc.

Ở trong hình trên ta có 4 instance đang chạy version 1 của phần mềm và đang cần deploy lên version 2

Khi đó, chiến lược All at Once sẽ update version cho tất cả các instance như dưới đây. Điều đó sẽ dẫn đến cả 4 instance sẽ tạm ngừng hoạt động trong 1 khoảng thời gian gọi là downtime.

Sau khi deploy, tất cả các instance sẽ đều có version 2.

All at Once là chiến lược có downtime lớn nhất nhưng cũng có thời gian deploy nhanh nhất, đơn giản nhất.

Rolling

Rolling là chiến lược deploy có sử dụng batch

Khi deploy với Rolling, chúng ta cần định nghĩa batch size. Ở đây ở batch size là 50%.

Với batch size là 50% thì khi deploy sẽ có 2 instance được deploy trước. Khi này, capacity còn 50%

Sau khi deploy xong 50%, có 2 instance đã được update version mới. Sau đó mới là update 2 instance còn lại. Khi này, capacity là 100% nhưng user có thể truy cập vào version khác nhau của hệ thống

Sau đó, 2 instance còn lại cũng được update lại version mới. Quá trình giống trên.

Cuối cùng thì cả 4 instance được update.

Theo như quá trình như trên, Rolling sẽ không có downtime, nhưng người dùng sẽ gặp phải trường hợp có nơi version cũ, có nơi version mới. Và vấn đề về capacity cũng có thể ảnh hưởng tới tốc độ truy cập.

Rolling with additional batch

Về căn bản thì cái này nó cũng giống Rolling nhưng sẽ deploy thêm instance để sao cho capacity là 100%

Trước hết thì cũng đặt batch size là 50% như Rolling

Tiếp đó, hệ thống sẽ thêm 2 instance mới với version mới vào Auto Scaling group. Capacity là 100%

2 instance mới được attach vào hệ thống. User lúc này có khả năng sẽ truy cập vào các version khác nhau tại thời điểm này

Ngắt 2 instance version 1 ra và deploy version 2 vào 2 instance ấy. Hệ thống vẫn có 4 instance hoạt động với capacity 100%

Sau đó, hệ thống sẽ có 4 instance version 2 và 2 instance version 1. Ngắt kết nối 2 instance version 1 kia và ngắt chúng sẽ deploy xong

Rolling with additional batch khác Rolling ở chỗ deploy thêm instance để giữ cho capicity là 100%. Không gây ảnh hưởng tốc độ.

Immutable

Immutable là cách deploy mà không làm ảnh hưởng đến các version hiện có

Chúng ta lại có hình ảnh quen thuộc với 1 ứng dụng có 4 instance ở version 1Khi áp dụng chiếc lược Immutable, 1 Auto Scaling Group mới sẽ được tạo ra với 1 instance được deploy version 2

Khi Auto Scaling Group mới và instance có version 2 được tạo thành công, Load Balancer sẽ kết nối tới Instance có version 2

Lúc này, trong Auto Scaling Group mới, có 3 instance version 2 được deploy thêm.

Kết thúc bước trên, Load Balancer được kết nối với 8 instance ở 2 Auto Scaling Group.

Bước cuối cùng, Load Balancer sẽ ngắt kết nối tới các instance cũ và việc deploy hoàn thành.

Chiến lược này sẽ không cho downtime, nhưng thời gian deploy là lâu nhất.

Lựa chọn môi trường và các deploy

Môi trường	Lựa chọn
Instance đơn	All at Once
	Immutable
Load Balancer, Auto Scaling Group	All at Once
Rolling
Rolling with additional batch
	Immutable

Blue/Green

Các chiến lược deploy kia rất hay, trừ việc ngay cả không có downtime thì đều có tình huống: Trong thời gian deploy, các user khác nhau có thể truy cập vào các version khác nhau

Vì vậy, Blue/Green deploy được tạo ra để trong thời gian deploy, người dùng sẽ truy cập chỉ 1 version của ứng dụng.

Blue/Green deploy

Chúng ta lại có 1 hệ thống có 4 instance với v1.

Đầu tiên, môi trường sẽ được clone lại. 2 hệ thống sẽ giống nhau về mọi mặt ngoại trừ DNS.Sau đó, ở hệ thống thứ 2 sẽ thực hiện deploy theo chiến lược All at Once. Do hệ thống thứ 2 chưa được công khai nên sẽ không có vấn đề gì.

Sau khi có hệ thống với version mới, DNS sẽ được thay đổi và việc deploy hoàn thành

Blue/Green khác gì Immutable

Bình thường nhìn từ kết quả vào thì nhau, nhưng như giải thích ở trên, Immutable vẫn xảy ra sự lẫn lộn version khi truy cập, còn Blue/Green thì không.

Blue/Green Dploy thì tạo hẳn 1 môi trường mới, còn Immutable chỉ diễn ra ở 1 môi trường

Tham khảo

• https://dev.classmethod.jp/articles/elastic-beanstalk-deploy-policy/
• https://aws.amazon.com/vi/elasticbeanstalk/

Về VTI Cloud

VTI Cloud là Đối tác cấp cao (Advanced Consulting Partner) của Amazon Web Services (AWS) và Đối tác vàng (Gold Partner) của Microsoft. Với đội ngũ hơn 100+ kỹ sư về giải pháp được chứng nhận bởi AWS và mong muốn hỗ trợ khách hàng trong hành trình chuyển đổi số và dịch chuyển lên đám mây AWS, VTI Cloud tự hào là đơn vị tiên phong trong việc tư vấn giải pháp, phát triển phần mềm và triển khai hạ tầng AWS cho khách hàng tại Việt Nam và Nhật Bản.

Xây dựng các kiến trúc an toàn, hiệu suất cao, linh hoạt, và tối ưu chi phí cho khách hàng là nhiệm vụ hàng đầu của VTI Cloud trong sứ mệnh công nghệ hóa doanh nghiệp.

Liên hệ với chúng tôi: Tại đây