Kỹ sư QLTT Ghi chú ôn thi
← Về danh sách
Hạ tầng & Đám mây
#오토스케일링#탄력성#수평확장#클라우드#131회
Cập nhật lần cuối · 2026-09-17

Tự động co giãn (Auto Scaling)

1. Tổng quan

A. Định nghĩa

Công nghệ vận hành đám mây tự động tăng (scale-out/up) hoặc giảm (scale-in/down) tài nguyên tính toán theo sự thay đổi của tải (lưu lượng, mức sử dụng tài nguyên) nhằm đồng thời tối ưu hiệu năng, tính sẵn sàng và chi phí của dịch vụ.

Lý do Auto Scaling được xem là giá trị cốt lõi của đám mây là vì đây chính là cơ chế hiện thực hóa 'tính đàn hồi (Elasticity)' mà đám mây đề cao. Tính đàn hồi là khả năng tăng giảm tài nguyên theo nhu cầu; nếu không được tự động hóa, con người sẽ phải theo dõi chỉ số ngày đêm để bật tắt máy chủ, điều này trên thực tế là bất khả thi. Auto Scaling ủy thác việc phán đoán và thực thi này cho quy tắc (chính sách), nhờ đó điều chỉnh tài nguyên theo nhu cầu theo thời gian thực mà không cần con người can thiệp.

B. Bối cảnh ra đời và sự cần thiết

Việc tính toán công suất trong thời kỳ on-premise (phòng máy tự vận hành) mang một nghịch lý căn bản. Máy chủ là tài sản cố định, mua một lần dùng nhiều năm, nên người quản trị buộc phải mua dư máy chủ dựa trên lưu lượng tối đa (đỉnh). Kết quả là phần lớn tài nguyên nhàn rỗi và bị lãng phí vào thời điểm bình thường, ngược lại nếu dự báo thận trọng ở mức thấp thì dịch vụ sẽ sập khi lưu lượng dồn đến do sự kiện hay chiến dịch marketing. Tức là không thể thoát khỏi thế lưỡng phân 'hoặc lãng phí, hoặc sự cố'.

Auto Scaling giải quyết trực diện nghịch lý này. Khi lưu lượng dồn đến, tài nguyên tự động tăng để ngăn sự cố; khi vắng vẻ, tài nguyên giảm để tiết kiệm chi phí. Nói cách khác, nó hoàn thiện lợi ích của mô hình trả theo mức dùng (pay-as-you-go) của đám mây: 'chỉ dùng lượng cần thiết và chỉ trả cho lượng đã dùng'. Ví dụ, khi nền tảng thương mại điện tử đón lưu lượng gấp hơn 10 lần bình thường vào các dịp cao điểm như Black Friday hay Ngày độc thân (Quang Côn Tiết), các instance được tự động bổ sung trong vài phút để chịu tải, còn vào khung giờ rạng sáng thì giảm xuống số lượng tối thiểu để tiết kiệm chi phí. Netflix hấp thụ sự gia tăng lượt xem vào những khung giờ nhất định bằng mở rộng tự động, hay hệ thống đăng ký học phần của các trường đại học tại Hàn Quốc chuẩn bị cho đợt tràn tải tại thời điểm mở cổng bằng mở rộng theo lịch, là những ví dụ tiêu biểu.

C. Đặc điểm

Auto Scaling có các đặc điểm: ① tính tự động dựa trên chỉ số, ② tính hai chiều tăng và giảm, ③ tính khai báo quy định hành vi bằng chính sách, ④ hướng tới tính sẵn sàng cao khi kết hợp với bộ cân bằng tải và kiểm tra sức khỏe (health check). Đặc biệt, không đơn thuần là 'nhiều thì tăng', mà còn lọc ra các instance bất thường bằng health check và thay thế chúng, nên Auto Scaling vừa là công cụ mở rộng vừa là công cụ phục hồi (resilience) hiện thực hóa tự chữa lành (self-healing).

2. Cấu trúc tổng thể và nguyên lý hoạt động

flowchart TB
  U[Lưu lượng người dùng] --> LB[Bộ cân bằng tải]
  LB --> G["Nhóm Auto Scaling (ASG)"]
  subgraph G["Nhóm Auto Scaling"]
    I1[Instance 1]
    I2[Instance 2]
    I3["Instance N (thay đổi)"]
  end
  MON["Giám sát (thu thập chỉ số)"] --> POL["Chính sách co giãn (đánh giá ngưỡng)"]
  POL -->|Quyết định tăng/giảm| G
  I1 -. chỉ số .-> MON
  I2 -. chỉ số .-> MON
  I3 -. chỉ số .-> MON
  LB -->|Health check| G
  style G fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style POL fill:#fef3e8,stroke:#ed8f2f,stroke-width:2px

Hoạt động của Auto Scaling sẽ rõ ràng khi được hiểu như một điều khiển vòng kín (closed-loop control). Trước tiên, hệ thống giám sát định kỳ thu thập các chỉ số như CPU, bộ nhớ, số yêu cầu, thời gian phản hồi của từng instance. Các chỉ số thu thập được so sánh với ngưỡng do chính sách co giãn định nghĩa, và nếu thỏa điều kiện, lệnh tăng hoặc giảm instance được gửi tới nhóm Auto Scaling (ASG, Auto Scaling Group). Instance mới được nhân bản đồng nhất từ template định sẵn (máy ảnh, script khởi động), tự động đăng ký vào bộ cân bằng tải, và bắt đầu nhận lưu lượng thực sau khi vượt qua health check. Chu trình này quay liên tục để quy mô tài nguyên bám theo nhu cầu.

Trong cấu trúc này, bốn thành phần là cốt lõi và cần được phân tích để hiểu từng thành phần.

A. Nhóm Auto Scaling (ASG) áp đặt phạm vi an toàn của tài nguyên bằng ba giá trị biên 'số lượng tối thiểu, số lượng mong muốn, số lượng tối đa'. Số tối thiểu là ngưỡng dưới của tính sẵn sàng luôn được duy trì kể cả khi gần như không có lưu lượng; số mong muốn là số lượng mục tiêu đang muốn duy trì; số tối đa là ngưỡng trên để ngăn bùng nổ chi phí và sự cố. Nếu thiếu ba giá trị này, Auto Scaling rất dễ mất kiểm soát. Ví dụ, đặt tối thiểu là 2 thì khi một máy chết vẫn còn ít nhất một máy sống để bảo đảm không gián đoạn, đặt tối đa là 20 thì ngay cả với tải bất thường, hóa đơn cũng không phình ra vô hạn.

B. Bộ cân bằng tải (LB) phân phối đều lưu lượng tới các instance được bổ sung và lập tức loại khỏi danh sách đích các instance không vượt qua health check. Không có bộ cân bằng tải, dù tăng instance, lưu lượng vẫn dồn vào một máy và mở rộng ngang không thành lập. Có thể nói bộ cân bằng tải là tiền đề vật lý của mở rộng ngang.

C. Launch Template (template khởi chạy) cho phép bất kỳ instance nào cũng được nhân bản tức thì với cùng máy ảnh, phần mềm và script khởi tạo. Nhờ đó, instance mới khởi chạy hoạt động hoàn toàn giống instance hiện có và kết quả mở rộng trở nên có thể dự đoán. Nếu cấu hình mỗi instance khác nhau, mỗi lần mở rộng sẽ phát sinh lỗi không lường trước, vì vậy nguyên tắc hạ tầng bất biến (immutable infrastructure) rất quan trọng ở đây.

D. Giám sát·health check thu thập chỉ số để cung cấp căn cứ cho việc đánh giá chính sách, đồng thời phát hiện instance bất thường để kích hoạt thay thế. Chính yếu tố này biến Auto Scaling thành hệ thống tự chữa lành chứ không chỉ là bộ mở rộng đơn thuần.

Hãy tổng hợp hoạt động bằng một ví dụ số đơn giản. Với chính sách theo dõi mục tiêu 'duy trì CPU trung bình 50%, mỗi instance ở CPU 100% = xử lý 100 RPS', thì lúc bình thường 400 RPS được đáp ứng bằng 8 máy (50 RPS mỗi máy). Khi lưu lượng tăng gấp 3 lên 1.200 RPS, để duy trì mục tiêu 50%, hệ thống tăng số máy lên khoảng 24, rồi khi giảm lại còn 400 RPS thì thu về 8 máy. Việc số lượng máy tự động hội tụ tỷ lệ thuận với tải như vậy chính là bản chất của Auto Scaling.

3. Loại mở rộng — Mở rộng ngang và mở rộng dọc

flowchart LR
  A[Auto Scaling] --> H["Mở rộng ngang<br/>Scale-out/in<br/>(điều chỉnh số lượng instance)"]
  A --> V["Mở rộng dọc<br/>Scale-up/down<br/>(điều chỉnh cấu hình instance)"]
  H --> H1[Phân tán thông lượng bằng tăng số máy]
  V --> V1[Tăng cường hiệu năng một instance]
  style A fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style H fill:#e8fef0,stroke:#2fb36f,stroke-width:2px
  style V fill:#fef3e8,stroke:#ed8f2f,stroke-width:2px

Mở rộng có hai hướng khác nhau, và việc chọn hướng nào quyết định thiết kế kiến trúc.

Mở rộng ngang (Scale-out/in) là phương thức tăng hoặc giảm 'số lượng' instance cùng cấu hình. Vì yêu cầu được chia cho nhiều máy xử lý, có thể điều chỉnh công suất không gián đoạn mà không phải dừng dịch vụ, và ưu điểm lớn nhất là về lý thuyết có thể mở rộng không giới hạn. Đây là lý do các dịch vụ web, API quy mô lớn gần như không có ngoại lệ đều chọn mở rộng ngang. Tuy nhiên, bắt buộc phải có tiền đề là bộ cân bằng tải phân phối yêu cầu cho nhiều instance và thiết kế phi trạng thái (Stateless) không lưu trạng thái như phiên, tệp trên một máy chủ cụ thể. Bởi nếu trạng thái bị gắn với một máy chủ cụ thể, khi máy chủ đó biến mất do thu nhỏ thì dữ liệu sẽ bị mất.

Mở rộng dọc (Scale-up/down) là phương thức tăng hoặc giảm chính cấu hình CPU, bộ nhớ của một instance. Ưu điểm là cài đặt đơn giản vì chỉ cần nâng cấu hình mà không phải thay đổi cấu trúc ứng dụng, nhưng thường khi đổi cấu hình phải khởi động lại nên xảy ra gián đoạn tức thời, và cuối cùng sẽ chạm giới hạn là cấu hình tối đa mà một máy vật lý đơn lẻ có thể cung cấp.

Vì vậy, mở rộng dọc thường được dùng hạn chế ở các tầng có trạng thái (stateful) khó phân tán ngang như cơ sở dữ liệu quan hệ. Do đặc tính dữ liệu phải tập trung một chỗ nên khó tăng số máy, trước hết người ta nâng cấu hình để chống đỡ. Trong thực tế, chiến lược lai kết hợp tầng web·ứng dụng theo chiều ngang và tầng DB theo chiều dọc (hoặc thêm bản sao đọc) là phổ biến, và việc tự động hóa hướng nào được quyết định bởi tầng đó có trạng thái hay không.

Loại Phương thức Ưu điểm Ràng buộc Tầng phù hợp
Mở rộng ngang Tăng giảm số lượng instance Không gián đoạn·sẵn sàng cao, mở rộng gần như vô hạn Cần thiết kế phi trạng thái·bộ cân bằng tải Web·API·worker
Mở rộng dọc Tăng giảm cấu hình instance Cài đặt đơn giản, không cần đổi ứng dụng Phát sinh khởi động lại·giới hạn vật lý DB·máy chủ đơn kế thừa

4. Chính sách co giãn — Khi nào mở rộng

Chính sách co giãn là thứ quyết định khi nào và điều chỉnh bao nhiêu, và độ tinh vi của chính sách quyết định hiệu quả thực tế của Auto Scaling. Chính sách được chia chủ yếu thành ba nhánh.

Chính sách động (Dynamic) là phương thức phổ biến nhất, điều chỉnh tài nguyên theo thời gian thực khi các chỉ số như mức sử dụng CPU, số yêu cầu mỗi giây (RPS), độ trễ phản hồi vượt lên hoặc xuống dưới ngưỡng. Ví dụ, đặt quy tắc như 'CPU trung bình vượt 70% kéo dài 3 phút thì thêm 2 máy, dưới 30% kéo dài 10 phút thì bớt 1 máy'. Vượt ra ngoài ngưỡng đơn giản (step scaling), phương thức theo dõi mục tiêu (target tracking) — chỉ định giá trị mục tiêu và để hệ thống tự điều chỉnh số máy — được dùng rộng rãi; giống như bộ điều nhiệt, chỉ cần đưa mục tiêu 'luôn duy trì CPU quanh mức 50%' nên vận hành đơn giản.

Chính sách dự đoán (Predictive) là phương thức dùng học máy học các mẫu lưu lượng trong quá khứ để chủ động chuẩn bị tài nguyên 'trước khi' tải tăng. Chính sách động về bản chất phản ứng 'sau khi' tải tăng nên phát sinh độ trễ bằng thời gian chuẩn bị, còn chính sách dự đoán kéo sớm độ trễ này, giảm sự cố tức thời ở đầu đợt tăng đột biến. Hiệu quả đặc biệt lớn với các dịch vụ có mẫu chu kỳ rõ rệt lặp lại hằng tuần (ví dụ: tăng vọt vào giờ đi làm các ngày trong tuần).

Chính sách theo lịch (Scheduled) là phương thức chuẩn bị sẵn số máy phù hợp với các sự kiện đã biết trước thời điểm như 'bắt đầu làm việc lúc 9 giờ sáng mỗi ngày', 'batch quyết toán cuối mỗi tháng', '10 phút trước khi mở đăng ký học phần'. Với các mẫu rõ ràng tới mức không cần dự đoán, chính sách theo lịch là chắc chắn nhất. Trong trường hợp đã biết trước sẽ có đợt tràn tải theo từng giây như mở bán vé, chỉ chính sách động thì việc bổ sung không theo kịp đợt tràn tải, nên bắt buộc phải mở rộng quy mô trước theo lịch.

Trong thực tế, thay vì dùng ba chính sách này một cách loại trừ, cách làm chuẩn là áp dụng chồng lớp: dùng lịch để xác định quy mô cơ bản, dùng dự đoán để kéo sớm đường cong và dùng động để hiệu chỉnh sai lệch. Phụ thuộc vào chỉ một chính sách sẽ tạo điểm mù, còn chồng lớp cả ba có thể hấp thụ mẫu đã biết, mẫu đã học và biến động ngoài dự kiến.

Chính sách Tiêu chí đánh giá Đặc điểm Ứng dụng tiêu biểu
Động (Dynamic) Ngưỡng·giá trị mục tiêu của chỉ số Phản ứng sau, đa dụng Ứng phó biến động lưu lượng thường xuyên
Dự đoán (Predictive) Dự báo nhu cầu bằng ML Chủ động trước, giảm độ trễ Dịch vụ có mẫu chu kỳ
Theo lịch (Scheduled) Lịch trình đã biết Chuẩn bị cho sự kiện xác định Batch·mở bán·giờ làm việc

5. So sánh — Auto Scaling vs bổ sung thủ công, và quan hệ với serverless

Để hiểu giá trị của Auto Scaling cần so sánh với các phương án thay thế. Bổ sung thủ công là phương thức người quản trị xem chỉ số rồi tự tay tăng máy chủ; tính linh hoạt trong phán đoán cao nhưng khó ứng phó tức thì với đợt tăng vào ban đêm hay cuối tuần, và có sự can thiệp của sai sót, chậm trễ của con người. Ngược lại, Auto Scaling phản ứng nhất quán và nhanh, nhưng nếu thiết kế chính sách sai sẽ xảy ra dao động (flapping) — tăng giảm không cần thiết lặp đi lặp lại. Lý do căn bản tạo ra khác biệt này nằm ở 'chủ thể phán đoán là con người hay quy tắc', và hàm ý thực tiễn rất rõ ràng — tối ưu là tự động hóa các tải lặp lại có quy tắc được định nghĩa tốt, và con người chỉ can thiệp vào các tình huống ngoại lệ cần phán đoán.

Mặt khác, cũng cần nói đến quan hệ với serverless (FaaS, ví dụ: AWS Lambda). Nếu Auto Scaling truyền thống điều chỉnh theo 'đơn vị instance (máy chủ ảo)' trong vài phút, thì serverless mở rộng từ 0 theo 'đơn vị yêu cầu' trong mili giây~giây. Tức là serverless có thể xem là hình thái chi tiết hóa tột cùng của Auto Scaling.

Tuy nhiên, serverless có ràng buộc về thời gian thực thi và duy trì trạng thái, và có độ trễ khởi động lạnh (cold start) khi phải khởi chạy instance mới lúc được gọi đột ngột sau thời gian dài không có yêu cầu, nên với các dịch vụ lớn chạy thường trực và nhạy cảm với độ trễ phản hồi, Auto Scaling dựa trên instance·container vẫn thường hiệu quả hơn về chi phí. Tiêu chí lựa chọn là 'lưu lượng gián đoạn đến mức nào' và 'thời gian xử lý mỗi yêu cầu dài đến đâu'. Tác vụ gián đoạn, đơn lẻ thì serverless có lợi, lưu lượng liên tục, khối lượng lớn thì Auto Scaling có lợi, và trong thực tế cấu hình lai dùng cả hai cũng rất phổ biến.

6. Chuyên sâu — Auto Scaling trên Kubernetes và xu hướng mới

Khi container và Kubernetes trở thành tiêu chuẩn, Auto Scaling đã tiến hóa thành dạng chi tiết và đa tầng hơn. Kubernetes cung cấp mở rộng tự động ở ba tầng. HPA (Horizontal Pod Autoscaler) là mở rộng ngang tăng số lượng pod (nhóm container) theo chỉ số, VPA (Vertical Pod Autoscaler) là mở rộng dọc điều chỉnh lượng yêu cầu CPU, bộ nhớ cấp cho pod, và Cluster Autoscaler (cùng Karpenter) mở rộng node pool khi chính các node (máy chủ ảo) để chạy pod bị thiếu. Tức là mở rộng ở đơn vị ứng dụng (pod) và đơn vị hạ tầng (node) ăn khớp và vận hành theo phân tầng.

Xu hướng đang được chú ý gần đây là mở rộng tự động hướng sự kiện (KEDA, Kubernetes Event-Driven Autoscaling). Nếu HPA truyền thống chủ yếu phản ứng với chỉ số tài nguyên như CPU, bộ nhớ, thì KEDA phản ứng trực tiếp với chỉ số nghiệp vụ như lượng tồn đọng trong hàng đợi tin nhắn, độ trễ (lag) của Kafka consumer, độ dài luồng sự kiện để mở rộng. Ví dụ, khi tin nhắn dồn lại trong hàng đợi xử lý đơn hàng thì lập tức tăng pod tiêu thụ, và khi hàng đợi trống thì giảm xuống tận 0. Đây là sự chuyển đổi tư duy, điều chỉnh tài nguyên theo 'khối lượng công việc thực sự phải xử lý chứ không phải tài nguyên', hiện thực hóa hiệu quả gần với serverless trong môi trường container.

Ngoài ra, việc kết hợp dự báo chuỗi thời gian·học tăng cường vào mở rộng dự đoán, co giãn đa đám mây lựa chọn vị trí mở rộng bằng cách cân nhắc đồng thời chi phí và tính sẵn sàng trên nhiều đám mây·khu vực, hay chiến lược hỗn hợp ưu tiên dùng instance spot để giảm chi phí đang lan rộng từ góc độ FinOps (tối ưu chi phí đám mây). Auto Scaling giờ đây đang chuyển vị thế, vượt khỏi mở rộng đơn thuần để trở thành điều phối tài nguyên thông minh tối ưu đồng thời hiệu năng, tính sẵn sàng và chi phí.

7. Lưu ý và hàm ý

Từ góc độ Kỹ sư chuyên nghiệp, các điểm cần cân nhắc khi triển khai và vận hành Auto Scaling như sau.

  1. Thiết kế phi trạng thái (Stateless) là tiền đề tuyệt đối của mở rộng ngang. Nếu lưu phiên, tệp tải lên, cache cục bộ trên một instance cụ thể thì khi thu nhỏ, dữ liệu bị mất và phiên người dùng bị ngắt. Trạng thái phải được tách ra kho lưu trữ bên ngoài như Redis, DB, object storage, và ứng dụng phải được thiết kế theo nguyên tắc 'dùng một lần (cattle, not pets)' có thể chết bất cứ lúc nào mà không sao. Đây là khoản đầu tư kiến trúc trước cho Auto Scaling.

  2. Phải kiểm soát đồng thời thời gian chuẩn bị (Warm-up) và dao động (Flapping). Từ khi instance khởi động đến khi nhận lưu lượng mất vài chục giây~vài phút, nên phải đặt ngưỡng và thời điểm bổ sung có dư địa để không chậm hơn đợt tăng đột biến. Đồng thời, để ngăn dao động thu nhỏ và bổ sung lặp lại trong khoảng ngắn, phải đặt thời gian làm mát (cooldown) và vùng đệm (hysteresis). 'Tăng nhanh, giảm chậm' là quy tắc kinh nghiệm cho vận hành ổn định.

  3. Phải tích hợp trần chi phí và phòng thủ bùng nổ vào chính sách. Auto Scaling không chỉ phản ứng với tăng đột biến lưu lượng mà còn với tải bất thường do tấn công DDoS hay lỗi ứng dụng, có thể tăng tài nguyên vô hạn, và điều này sẽ quay lại thành hóa đơn không lường trước. Phải thiết kế giới hạn số máy tối đa, cảnh báo chi phí, liên kết với WAF·giới hạn yêu cầu (rate limiting) để với 'lưu lượng xấu thì chặn chứ không mở rộng'.

  4. Khả năng quan sát (Observability) và lựa chọn chỉ số quyết định thành bại. Nếu chỉ nhìn chỉ số tài nguyên như CPU, có thể lệch với trải nghiệm người dùng thực tế (độ trễ phản hồi, tỷ lệ lỗi). Phải chọn chỉ số phù hợp đặc tính dịch vụ như độ dài hàng đợi, RPS, độ trễ p95, và cần vòng phản hồi liên tục quan sát, tinh chỉnh quyết định mở rộng và kết quả. Nếu chỉ số không chính xác, Auto Scaling ngược lại sẽ khuếch đại sự cố.

  5. Phải liên kết với khôi phục thảm họa và đa vùng sẵn sàng. Nếu bố trí phân tán nhóm Auto Scaling trên nhiều vùng sẵn sàng (AZ), khi một trung tâm dữ liệu gặp sự cố, các vùng khác tự động bù số máy để giữ tính sẵn sàng. Auto Scaling phải được thiết kế tích hợp như trục cốt lõi của kiến trúc sẵn sàng cao·tự chữa lành, vượt ra ngoài vai trò công cụ mở rộng.

Tài liệu tham khảo

Tóm tắt một câu: Auto Scaling là công nghệ đàn hồi đám mây tự động tăng giảm tài nguyên (ngang·dọc) theo tải để đồng thời tối ưu hiệu năng, tính sẵn sàng và chi phí; với tiền đề là thiết kế phi trạng thái và cân bằng tải, nó áp dụng chồng lớp các chính sách động, dự đoán, theo lịch, và đang được chi tiết hóa qua HPA/VPA, KEDA của Kubernetes cùng serverless để tiến hóa thành điều phối tài nguyên thông minh.