Bỏ qua tới nội dung
CloudDojo
Phần 1/7 · 11 phút

Cấu hình Auto Scaling group: launch template, subnet và capacity

0/20
Từ khóa của phần nàyChọn một từ để xem nghĩa trước khi đọc

Thay vì chạy một số EC2 instance cố định, Auto Scaling group tự launch thêm instance khi tải tăng và terminate bớt instance khi tải giảm; để làm được điều đó, nhóm cần một launch template mô tả cách launch instance mới.

Trước đây ứng dụng báo cáo của MFTECH chạy trên một EC2 On-Demand duy nhất, và mỗi đợt tăng tải đều gây lỗi 5xx. Để chuyển sang Auto Scaling group, nhóm vận hành tạo AMI từ instance hiện tại, khai báo AMI đó trong một launch template, sau đó chọn subnet và purchase options cho nhóm. Thử từng lựa chọn dưới đây:

Cấu hình launch

Launch template lt-mftech-web, phiên bản 3: AMI của ứng dụng, instance type, key pair, security group, user data. Mỗi lần đổi AMI, tạo phiên bản mới thay vì tạo lại từ đầu.

Subnets
Purchase optionsOn-Demand trên phần base
ap-southeast-1a
ap-southeast-1b
On-Demand base: 4On-Demand: 1Spot: 3
  • Trải trên 2 AZ trong ap-southeast-1; ASG cố gắng phân bổ đều instance giữa các AZ.
  • Mixed instances policy: phần base luôn là On-Demand (ASG launch đủ base trước khi launch Spot); phần vượt base chia theo tỉ lệ phần trăm, làm tròn lên về phía On-Demand. Reserved Instances hoặc Savings Plans giảm giá cho các instance On-Demand, Spot giảm chi phí cho phần tải tăng thêm của ứng dụng stateless.

Ba điểm cần nắm. Thứ nhất, launch template mô tả cách launch instance (AMI, instance type, key pair, security group…) và có nhiều phiên bản; launch configuration là cơ chế cũ, không sửa được sau khi tạo và không hỗ trợ kết hợp On-Demand với Spot hay nhiều instance type. Thứ hai, ASG là tài nguyên theo Region: trải được trên nhiều AZ nhưng không trải được trên nhiều Region; kiến trúc nhiều Region cần một ASG tại mỗi Region. Thứ ba, mixed instances policy cho phép một ASG chạy cả On-Demand và Spot: phần base On-Demand cho tải nền, phần vượt base chia theo tỉ lệ. Khi tải nền ổn định ở một mức suốt năm, mua Reserved Instances (hoặc Savings Plans) cho phần nền đó; không dùng Spot cho phần nền vì EC2 có thể thu hồi Spot Instance khi không còn capacity.

Đối tác thanh toán yêu cầu MFTECH cung cấp IP cố định để đưa vào firewall. Elastic IP không gán được cho Auto Scaling group: Elastic IP chỉ được associate với một instance hoặc một network interface, trong khi ASG chỉ là nhóm quản lý các instance được tạo và thay thế liên tục. Nếu bắt buộc từng instance có Elastic IP, phải tự gắn khi instance khởi động (ví dụ script trong user data hoặc một launch lifecycle hook gọi API AssociateAddress). Cách thông dụng hơn là đặt IP tĩnh ở tầng phía trước: NLB internet-facing cho phép chọn một Elastic IP cho mỗi AZ, hoặc AWS Global Accelerator cung cấp IP tĩnh cho nhiều Region (bài ELB, phần 1).

Kích thước nhóm do ba giá trị quyết định. Desired capacity là số instance ASG cố gắng duy trì; minimum và maximum là giới hạn mà scaling policy và scheduled action không được vượt qua. Phòng kế toán cần đúng 10 instance vào giờ chạy bảng lương cuối tháng:

min 2 · desired 2 · max 12

Phòng kế toán của MFTECH chạy bảng lương lúc 9:00 ngày cuối tháng, cần 10 instance; ngày thường 2 instance là đủ. Thử từng thao tác và quan sát desired capacity.

Ghi nhớ:
  • Launch template: định nghĩa instance, có phiên bản, bắt buộc khi kết hợp On-Demand với Spot.
  • ASG trải trên nhiều AZ trong một Region, không trải qua Region.
  • Cần một số instance cụ thể vào một thời điểm: scheduled action đặt desired capacity; min/max chỉ là giới hạn của khoảng co giãn.
  • Tải nền cố định: Reserved Instances; phần dao động: On-Demand và Spot qua mixed instances policy.
  • Elastic IP gắn với instance hoặc network interface, không gắn với ASG; IP tĩnh cho cả nhóm: NLB với Elastic IP hoặc Global Accelerator.
Part 1/7 · 11 phút

Auto Scaling group configuration: launch template, subnets and capacity

0/20
Từ khóa của phần nàyChọn một từ để xem nghĩa trước khi đọc

Instead of running a fixed number of EC2 instances, an Auto Scaling group launches instances as load rises and terminates them as it falls; to do that, the group needs a launch template that describes how to launch a new instance.

MFTECH’s reporting application used to run on a single On-Demand EC2 instance, and every load spike caused 5xx errors. To move it to an Auto Scaling group, the operations team creates an AMI from the current instance, declares that AMI in a launch template, then chooses the subnets and purchase options for the group. Try each choice below:

Cấu hình launch

Launch template lt-mftech-web, phiên bản 3: AMI của ứng dụng, instance type, key pair, security group, user data. Mỗi lần đổi AMI, tạo phiên bản mới thay vì tạo lại từ đầu.

Subnets
Purchase optionsOn-Demand trên phần base
ap-southeast-1a
ap-southeast-1b
On-Demand base: 4On-Demand: 1Spot: 3
  • Trải trên 2 AZ trong ap-southeast-1; ASG cố gắng phân bổ đều instance giữa các AZ.
  • Mixed instances policy: phần base luôn là On-Demand (ASG launch đủ base trước khi launch Spot); phần vượt base chia theo tỉ lệ phần trăm, làm tròn lên về phía On-Demand. Reserved Instances hoặc Savings Plans giảm giá cho các instance On-Demand, Spot giảm chi phí cho phần tải tăng thêm của ứng dụng stateless.

Three points matter. First, a launch template describes how to launch an instance (AMI, instance type, key pair, security groups…) and has multiple versions; a launch configuration is the legacy mechanism, cannot be modified after creation and does not support combining On-Demand and Spot or multiple instance types. Second, an ASG is a regional construct: it can span Availability Zones but cannot span AWS Regions; a multi-Region architecture needs one ASG in each Region. Third, a mixed instances policy lets one ASG run both On-Demand and Spot: an On-Demand base for the steady load, and capacity above the base split by percentage. When the steady load stays at a known level all year, buy Reserved Instances (or a Savings Plan) for it; do not use Spot for the baseline, because EC2 can reclaim a Spot Instance when capacity is no longer available.

A payment partner asks MFTECH for fixed IP addresses to add to its firewall. An Elastic IP address cannot be assigned to an Auto Scaling group: an Elastic IP address is associated with an instance or a network interface, while an ASG is only a group that manages instances that are constantly launched and replaced. If each instance really must have an Elastic IP address, you associate it yourself at launch (for example a user data script or a launch lifecycle hook that calls the AssociateAddress API). The more common approach is a static IP in front: an internet-facing NLB lets you select one Elastic IP address per AZ, or AWS Global Accelerator provides static IP addresses across Regions (ELB lesson, part 1).

Three values decide the group’s size. Desired capacity is the number of instances the ASG tries to maintain; minimum and maximum are limits that scaling policies and scheduled actions cannot cross. The accounting team needs exactly 10 instances during the month-end payroll hour:

min 2 · desired 2 · max 12

Phòng kế toán của MFTECH chạy bảng lương lúc 9:00 ngày cuối tháng, cần 10 instance; ngày thường 2 instance là đủ. Thử từng thao tác và quan sát desired capacity.

Ghi nhớ:
  • Launch template: defines the instance, is versioned, and is required to combine On-Demand and Spot.
  • An ASG spans multiple AZs in one Region, never across Regions.
  • A specific number of instances at a specific time: a scheduled action sets desired capacity; min/max are only the limits of the scaling range.
  • Fixed baseline load: Reserved Instances; the variable part: On-Demand and Spot through a mixed instances policy.
  • An Elastic IP address attaches to an instance or network interface, never to an ASG; static IPs for the whole group: an NLB with Elastic IPs or Global Accelerator.

Kiểm tra nhanh

Trả lời để ghi nhận đã đọc phần này. Câu trả lời sai sẽ được nhắc ôn lại vào những ngày sau.

MFTECH muốn một Auto Scaling group chạy cả On-Demand và Spot Instance, với nhiều instance type. Nhóm cần cấu hình gì?
Đối tác thanh toán cần IP tĩnh của MFTECH để đưa vào firewall, trong khi các instance phía sau do Auto Scaling group tạo và thay thế liên tục. Phương án nào phù hợp?

Đã trả lời 0/2 câu