Auto Scaling (tạm dịch: Tự động Mở rộng) là dịch vụ giúp tự động điều chỉnh số lượng EC2 Instance theo các chính sách đã định nghĩa trước. Mục tiêu là đảm bảo ứng dụng luôn có đủ tài nguyên để đáp ứng nhu cầu, đồng thời tối ưu chi phí bằng cách giảm bớt tài nguyên khi không cần thiết.
Trong bài này:
1. Auto Scaling Group (ASG)
Để sử dụng Auto Scaling, ta tạo một Auto Scaling Group (ASG). Đây đơn giản là một tập hợp các EC2 Instance, người dùng có thể đặt 3 tham số để kiểm soát:
- Minimum Size: số Instance tối thiểu trong nhóm. ASG sẽ không bao giờ giảm số instance xuống dưới mức này.
- Maximum Size: số Instance tối đa trong nhóm. Số lượng Instance sẽ không bao giờ vượt quá mức này.
- Desired Capacity: là số Instance sẽ chạy trong nhóm. Nếu không đặt scaling policy, ASG sẽ luôn duy trì số Instance bằng với Desired Capacity. Nếu có scaling policy, khi cần thêm hoặc bớt Instance, AWS tự động thay đổi giá trị Desired Capacity trong khoảng từ Minimum Size đến Maximum Size, do đó số lượng Instance được cấp phát trong nhóm cũng thay đổi theo.
Khi tạo ASG, ta cần chỉ rõ thông số của các Instance trong nhóm. Thông số này được định nghĩa trong một Launch Template, bao gồm các thông tin như:
- AMI sẽ dùng.
- Loại Instance.
- Ổ EBS cũng như Instance Store.
- VPC, Subnet và Security Group.
- IAM Role.
Launch Template có thể được tái sử dụng cho nhiều ASG, giúp tiết kiệm thời gian và công sức cấu hình. Ngoài ra, Launch Template hỗ trợ phiên bản (versioning), cho phép tạo các phiên bản khác nhau của cùng một template. Khi tạo hoặc cập nhật ASG, có thể chọn một phiên bản cụ thể của Launch Template. Lưu ý, không thể chỉnh sửa Launch Template sau khi được tạo, chỉ có thể tạo phiên bản mới rồi sử dụng.
2. Các Chính sách Mở rộng
2.2.1. Manual Scaling
Như tên gọi, Manual Scaling là điều chỉnh số Instance trong ASG thủ công bằng cách thay đổi giá trị Desired Capacity. AWS sẽ tự động khởi tạo hoặc dừng các Instance để đạt số lượng mong muốn.
2.2.2. Scheduled Scaling
Nếu ứng dụng có lưu lượng truy cập thay đổi theo lịch trình có thể dự đoán được (ví dụ: tăng vào giờ hành chính, giảm vào ban đêm), có thể sử dụng Scheduled Scaling, thao tác trên giao diện, CLI, hoặc API.
Ví dụ, giả sử ta có một ASG tên awscoban-asg, để tăng số Instance lên 3 vào lúc 9 giờ sáng và giảm về 1 lúc 7 giờ tối mỗi ngày, có thể dùng hai lệnh AWS CLI sau:
aws autoscaling put-scheduled-update-group-action --scheduled-action-name inc-at-9am \
--auto-scaling-group-name awscoban-asg --recurrence "0 9 * * *" --desired-capacity 3
aws autoscaling put-scheduled-update-group-action --scheduled-action-name dec-at-7pm \
--auto-scaling-group-name awscoban-asg --recurrence "0 19 * * *" --desired-capacity 1
Trong đó, tham số --recurrence dùng định dạng cron để chỉ định thời gian thực hiện hành động. Cú pháp như sau:
Phút Giờ Ngày-trong-tháng Tháng Ngày-trong-tuần
Giá trị * của một trường nghĩa là “bất kỳ”. Ví dụ, 0 9 * * * nghĩa là “9:00 tất cả các ngày”.
2.2.3. Dynamic Scaling
Đây là một nhóm phương pháp mở rộng/thu hẹp ASG dựa trên tải thực tế, thông qua các chỉ số (metric) (như CPUUtilization, NetworkIn, NetworkOut, v.v.).
Do đó, đều cần tích hợp với CloudWatch.
Các phương pháp phổ biến gồm:
2.2.3.1. Target Tracking Scaling
Như tên gọi, phương pháp này theo dõi metric (có sẵn hoặc tự tạo) và tự động điều chỉnh số Instance để giữ metric đó ở gần giá trị mục tiêu.
Người dùng chỉ cần định nghĩa metric cần theo dõi và giá trị mục tiêu, AWS tự động tạo và quản lý CloudWatch Alarm để kích hoạt hành động mở rộng/thu hẹp ASG khi metric rời xa giá trị mục tiêu.
Một chính sách hay dùng là trong các hệ thống phân tán, một nhóm EC2 Instance trong ASG đóng vai trò consumer, xử lý các tác vụ được đưa vào một hàng đợi SQS. Ta có thể theo dõi số lượng tác vụ trong hàng đợi qua metric ApproximateNumberOfMessagesVisible, và đặt mục tiêu giữ số lượng tin nhắn trong hàng đợi ở mức thấp (ví dụ: 0 hoặc 1). Khi số tin nhắn tăng lên, ASG tự động tăng số lượng Instance để xử lý nhanh hơn, và ngược lại, giảm số Instance khi hàng đợi trống.
2.2.3.2. Step Scaling
Phương pháp này tăng/giảm số lượng Instance dựa theo các ngưỡng xác định của metric.
Ví dụ:
- Khi
CPUUtilizationtăng tới 50%, tăng thêm 1 Instance. - Khi
CPUUtilizationtăng tới 75%, tăng thêm 2 Instance nữa. - Khi
CPUUtilizationgiảm tới 75%, giảm bớt 2 Instance. - Khi
CPUUtilizationgiảm tới 50%, giảm bớt 1 Instance nữa.
Lưu ý, số Instance trong ASG sẽ luôn được giữ trong khoảng từ Minimum Size đến Maximum Size đã định nghĩa trước.
2.2.3.3. Simple Scaling
Đây là phương pháp cũ, ít được dùng. Tương tự như Step Scaling, nhưng chỉ có một bước điều chỉnh duy nhất.
Cooldown: Step Scaling và Simple Scaling đều nên áp dụng cooldown, đây là một khoảng thời gian chờ sau khi thực hiện hành động mở rộng/thu hẹp, để hệ thống ổn định. Trong thời gian này, dù metric có biến động vượt quá các ngưỡng khác, việc mở rộng/thu hẹp vẫn bị bỏ qua. Mặc định, cooldown là 300 giây (5 phút), nhưng có thể tùy chỉnh theo nhu cầu.
2.2.4. Predictive Scaling
Phương pháp này sử dụng Học Máy để phân tích tải trong quá khứ, từ đó dự đoán nhu cầu trong tương lai và tự động điều chỉnh số Instance trong ASG trước khi tải tăng lên. Phù hợp với:
- Ứng dụng có lưu lượng truy cập thay đổi theo chu kỳ (ví dụ: tăng vào giờ hành chính, giảm vào ban đêm), hoặc định kỳ (ví dụ: tăng vào các ngày lễ, sự kiện đặc biệt).
- Ứng dụng cần thời gian khởi động dài, do đó cần dự đoán trước để đảm bảo tài nguyên sẵn sàng khi cần, giảm độ trễ khi cần mở rộng.
3. ASG Lifecycle & Hook
EC2 Instance trong ASG trải qua một chuỗi các trạng thái trong vòng đời (lifecycle) khác với trạng thái của một Instance thông thường.
3.1. Scale Out
Scale Out là quá trình thêm Instance mới vào ASG (out nghĩa là mở rộng ra), bao gồm các trạng thái sau:
Pending: ASG bắt đầu khởi tạo Instance dựa trên Launch Template.Pending:Wait: Trạng thái tạm dừng, chờ thực hiện các thao tác tùy chỉnh (nếu có) qua lifecycle hook. Ví dụ: cài đặt phần mềm, tải dữ liệu về, v.v.Pending:Proceed: Đã thực hiện xong hook, Instance đang được thêm vào Load Balancer.InService: Instance đã sẵn sàng. Thực tế, nếu không cấu hình hook nào, Instance sẽ chuyển thẳng từPendingsangInService.
3.2. Scale In
Ngược lại, Scale In là quá trình loại bỏ Instance khỏi ASG (in nghĩa là thu hẹp lại), bao gồm các trạng thái sau:
Terminating: ASG bắt đầu dừng và xóa Instance.Terminating:Wait: Trạng thái tạm dừng, chờ thực hiện các thao tác tùy chỉnh (nếu có) qua lifecycle hook. Ví dụ như gửi thông báo, sao lưu dữ liệu, v.v.Terminating:Proceed: Đã thực hiện xong hook, Instance đang được gỡ khỏi Load Balancer.Terminated: Instance đã bị xóa hoàn toàn. Nếu không cấu hình hook nào, Instance sẽ chuyển thẳng từTerminatingsangTerminated.
3.3. Lifecycle Hook
Hook là cơ chế cho phép can thiệp vào lifecycle của các instance trong ASG, chèn các bước xử lý tùy chỉnh để cấu hình theo ý muốn. Hai loại hook phổ biến là:
autoscaling:EC2_INSTANCE_LAUNCHING: kích hoạt khi một Instance mới được khởi tạo trong ASG, chuyển trạng thái từPendingsangPending:Wait.autoscaling:EC2_INSTANCE_TERMINATING: kích hoạt khi một Instance bị loại bỏ khỏi ASG, chuyển trạng thái từTerminatingsangTerminating:Wait.
Ví dụ, dưới đây ta tạo một hook tên waiting-user-data cho ASG awscoban-asg, gắn vào các Instance đang được khởi tạo khi Scale Out. Hook này đơn giản giữ Instance ở trạng thái Pending:Wait trong 3600 giây (1 giờ), để chờ chạy xong User Data Script để khởi tạo Instance trước khi sử dụng.
aws autoscaling put-lifecycle-hook \
--auto-scaling-group-name awscoban-asg \
--lifecycle-hook-name waiting-user-data \
--lifecycle-transition autoscaling:EC2_INSTANCE_LAUNCHING \
--heartbeat-timeout 3600
Tài liệu tham khảo
- Giới thiệu về EC2 Auto Scaling
- Một Câu hỏi hay trên StackOverflow về ASG
- Launch Template
- Các Chính sách Mở rộng
- Scaling Lifecycle
- Lifecycle Hook
Tiếp theo, hay tìm hiểu về cân bằng tải với Load Balancer.