Auto Scaling Group (ASG) là gì?
Trong thực tế, tải đặt lên một ứng dụng hoặc website có thể thay đổi rất chóng vánh, nếu còn nhớ ở phần High Availability & Scalability trên AWS chúng ta có lấy ví dụ về trang web đăng ký học của các trường đại học, thì đây ví dụ chính xác nhất.
Các trang đăng ký học thường chịu tải gần như bằng 0 vào giai đoạn giữa hoặc cuối kì học, nhưng tải sẽ tăng đột biến trong vài ngày khi sinh viên ồ ạt vào đăng ký học. Thường thì đây là vấn đề khó giải quyết dưới onpremise (đây có lẽ cũng là lý do mà câu chuyện đăng ký học vẫn tiếp diễn ở nhiều trường từ năm này qua năm khác).
Tuy nhiên nếu triển khai ứng dụng trên Cloud nói chung hay AWS nói riêng, vấn đề này có thể giải quyết rất nhanh chóng và với chi phí không quá lớn.
Đối với Auto Scaling Group trên AWS, dịch vụ này được xây dựng nhằm cung cấp các tính năng chính như sau:
- Scale out/scale in (tăng/giảm) số lượng instances EC2 phù hợp với sự thay đổi của tải đặt lên hệ thống.
- Cho phép người dùng có thể kiểm soát số lượng instances tối thiều và tối đa, nhằm tránh các lỗi không xác định gây ảnh hưởng hệ thống hoặc làm gia tăng chi phí.
- Tự động đăng ký mới các instances với các bộ cân bằng tải cũng như thay thế các Instances gặp sự cố (VD: bị terminated hoặc gặp lỗi).
Note: Thông thường, quá trình scale instances mới sẽ không diễn ra ngay lập tức mà sẽ mất một khoảng thời gian (thường là vài phút) do cần khởi tạo các EC2 instances mới, do đó cần lưu ý để thiết kế các chiến lược scale sao cho tối ưu với nhu cầu của hệ thống
ASG được AWS cung cấp miễn phí, tuy nhiên chúng ta sẽ cần chi trả chi phí cho mỗi EC2 instances được sử dụng bởi chúng.
ASG hoạt động với cân bằng tải thế nào?
Các bộ cân bằng tải là thành phần không thể thiếu khi triển khai các cụm Auto Scaling, nguyên nhân là dịch vụ ASG chỉ cung cấp khả năng tự động điều chỉnh số lượng EC2 Instances, tuy nhiên sẽ vô nghĩa nếu các request vẫn được chuyển toàn bộ về máy chủ ban đầu, tại đây, các bộ cân bằng tải sẽ đóng vai trò phân phối các requests một cách hợp lý tới các instances trong cụm.
Các thành phần của Auto Scaling Group
Launch Template
Trước đây, chúng ta có 2 khái niệm Launch Template và Launch Configurations, tuy nhiên Launch Configurations đã bị loại bỏ trên các phiên bản AWS gần đây (31/12/2022).
Một Launch Template bao gồm các thành phần sau:
- AMI + Instance Type: Khi dịch vụ ASG thực hiện thao tác Scale, nó cần biết chính xác nó cần nhân bản loại instances như thế nào và trên instances đó đang cài đặt những gì.
- EC2 User Data: Tương tự như khi khởi tạo một EC2 riêng lẻ, chúng ta có thể thiết lập các câu lệnh khi instance khởi động. Tất nhiên giống với EC2, User Data là tính năng thuộc vào loại Optional.
- Các thiết lập khác tương tự như khi thiết lập EC2 instance riêng lẻ: EBS Volumes, Security Groups, SSH Key Pair, IAM Roles.
- Network + Subnets Information: Các thông tin liên quan đến Network mà ASG đặt trong nó.
- Load Balancer: Như đã nói ở trên, các bộ cân bằng tải là thứ không thể thiếu khi triển khai ASG.
Số lượng Instance mà ASG sẽ sử dụng
Khi triển khai ASG, chúng ta sẽ cần cung cấp các thông tin liên quan đến số lượng instances tối thiểu (Min Size - Số instances sẽ sử dụng khi không tải hoặc tải rất thấp), số lượng instances tối đa (Max Size - số instances tối đa mà cụm ASG được phép scale, điều này là tối quan trọng giúp tránh trường hợp cụm ASG scale quá nhiều instances dẫn đến chi phí tăng mất kiểm soát) và số lượng instances mà cụm ASG sẽ chứa khi khởi tạo (Initial Capacity).
Scaling Policies
Tùy vào mỗi hệ thống cũng như chiến lược của các đội ngũ khác nhau, chúng ta có thể có các chiến lược scaling khác nhau cho phù hợp với hoàn cảnh. Nói một cách dễ hiểu, Scaling Policies cho phép người dùng quyết định khi nào thì các cụm ASG sẽ bắt đầu scale thêm các instances mới. Điều này tương đối quan trọng do như đã nói ở phần trên, quá trình scale không thể diễn ra ngay lập tức mà nó sẽ cần một khoản thời gian (thường là vài phút). Trong thời gian đó nếu các instances hiện hữu đã ở trong tình trạng quá tải thì dịch vụ vẫn sẽ có thể bị gián đoạn cho đến khi các instances mới được bổ sung vào cụm, điều này đem lại rủi do tương đối lớn cho hệ thống.
Auto Scaling - CloudWatch Alarms & Scaling
Ở phần trên, chúng ta đã trao đổi về việc cần xác định thời điểm thích hợp để kích hoạt ASG nhằm đảm bảo hệ thống hoạt động trơn tru nhất, vậy làm thể nào để các cụm ASG biết được rằng đã đến lúc chúng cần thực hiện công tác Scale? Một trong các phương án phổ biến nhất là có thể thông qua CloudWatch alarms.
CloudWatch alarms cung cấp nhiều phương án để có thể trigger Scaling của các cụm ASG (Ví dụ như scale khi CPU đến giới hạn, scale khi bộ nhớ đạt tới 90% hay một chỉ số custom phức tạp nào đó).
Các chỉ số như Average CPU sẽ được tính toán cho toàn bộ các instances trong cụm.
Dựa trên các chỉ số (metrics) mà CloudWatch alarms cung cấp, chúng ta có thể thiết lập các chiến lược scaling phù hợp.
Auto Scaling Groups – Dynamic Scaling Policies
Quá trình scaling nếu thực hiện đơn giản như các ý tưởng nói ở phần Scaling Policies có vẻ tương đối chung chung và khó thực hiện. Vậy sau khi đã biết về Cloudwatch Alarm, chúng ta có các phương án nào để có thể "động" hóa quá trình thiết lập các điều kiện scale của các cụm ASG? Có một vài phương án phổ biến có thể kể tới như sau:
- Target Tracking Scaling: Phương án này tương đối đơn giản, khi một chỉ số nhất định vượt ngưỡng, quá trình scale sẽ được kích hoạt. Ví dụ, khi chỉ số CPU trung bình của cụm đạt 60%, hãy bắt đầu scale.
- Simple / Step Scaling: Chúng ta sẽ thiết lập các ngưỡng để tăng/giảm số lượng instances phù hợp với lượng tải đến hệ thống, ví dụ nếu chỉ số CPU trung bình >70%, hãy scale thêm 2 instances hoặc trong trường hợp chỉ số CPU trung bình giảm đi mỗi 30%, hãy bỏ đi 1 instances.
- Scheduled Actions: Nếu biết chắc rằng hệ thống sẽ tăng tải trong một khoảng thời gian nhất định, hãy thiết lập nó. Ví dụ người dùng chủ yếu tập trung sử dụng ứng dụng vào giờ hành chính, hãy thiết lập sao cho cụm ASG tăng số lượng instances vào mỗi 8h sáng đến 5h chiều mỗi ngày từ thứ 2 đến thứ 6.
Auto Scaling Groups – Predictive Scaling
Việc xác định được một chiến lược scale hợp lý cho ứng dụng có thể mất nhiều thời gian và công sức cũng như trải qua nhiều "nỗi đau" trong quá trình vận hành. Tuy nhiên vì AWS nẵm giữ các dữ liệu về tải cũng như lịch sử scale của cụm, vậy nên bên cạnh khả năng truy cập các dữ liệu này, AWS còn cung cấp một cách liên tục các dự báo dựa trên dữ liệu mà nó thu thập được, từ đó cung cấp một liều thuốc "giảm đau" cho người dùng.
Các metrics thường dùng khi sử dụng ASG
Cloudwatch cung cấp đủ loại metrics tùy theo mong muốn của người dùng, điều này cung cấp khả năng thiết lập cũng như tùy chỉnh các metrics cho phép người dùng đưa ra một chiến lược scale sát nhất với ứng dụng, tuy nhiên nếu muốn một số gợi ý thì phần dưới đây sẽ cung cấp một số metrics cơ bản:
- CPUUtilization: Chỉ số CPU trung bình trên toàn bộ các instances trong cụm. Đây là chỉ số tương đối chính xác vì khi chỉ số này lên quá cao, các instances hiện hữu có thể gặp tình trạng quá tải hàng loạt gây lỗi toàn bộ dịch vụ.
- RequestCountPerTarget: Chỉ số này giúp giữ ổn định lượng request được chuyển đến mỗi EC2 instances. Nếu đã nắm được một instances với cấu hình định trước sẽ có thể chịu được tải bao nhiêu, đây là một chỉ số tuyệt vời.
- Average Network In / Out: Sử dụng khi ứng dụng có các ràng buộc liên quan đến network, đây là trường hợp đặc thù cũng như ít phổ biến hơn 2 chỉ số trên.
Auto Scaling Groups - Scaling Cooldowns
Như đã nhắc đến vài lần trong bài viết này, quá trình scale không diễn ra ngay lập tức mà sẽ cần vài phút để một instances được thiết lập và đưa vào hoạt động. Khoảng thời gian này gọi là Cooldowns Period (thời gian hồi chiêu 
), mặc định là 300 giây tuy nhiên có thể nhiều hơn.
Trong suốt thời gian "hồi chiêu" này, ASG sẽ không khởi chạy mới hay tắt bất cứ instances nào khác nhằm tránh ảnh hưởng đến các metrics đã được đo lường.
Một lời khuyên mà có lẽ ai cũng sẽ nhận ra đó là hãy sử dụng các ready-to-use AMI để giảm thiểu thời gian cấu hình cũng như Cooldowns Period. Một phương án thường dùng là hãy thiết lập ứng dụng chạy hoàn chỉnh trên một EC2 bên ngoài cụm ASG, sau đó khởi tạo ready-to-use AMI từ EC2 này.