Cloud elasticity là gì?

Mục lục

1. Cloud elasticity là gì?
2. Cơ chế hoạt động: vòng lặp đo – quyết định – cấp phát
3. Điều kiện kỹ thuật để ứng dụng co giãn được
4. Cloud elasticity khác scalability thế nào?
5. Ví dụ minh hoạ: đợt khuyến mãi của cửa hàng trực tuyến
6. Công cụ co giãn có tên gọi cụ thể
7. Ứng dụng cho doanh nghiệp Việt Nam
8. Ưu điểm và hạn chế
9. Khi nào nên và không nên dựa vào elasticity?
10. Checklist kiểm tra trước khi bật co giãn tự động
11. Câu hỏi thường gặp

Cloud elasticity là gì?

Cloud elasticity là đặc tính của đám mây cho phép tăng hoặc giảm năng lực CPU, bộ nhớ và lưu trữ theo nhu cầu thay đổi của tổ chức. Theo VMware, việc này có thể tự động, không cần lập kế hoạch công suất trước, hoặc làm thủ công khi hệ thống cảnh báo sắp thiếu tài nguyên.

Khái niệm này nằm trong định nghĩa điện toán đám mây của NIST (ấn phẩm SP 800-145, năm 2011) dưới tên “rapid elasticity”. Đây là một trong năm đặc tính thiết yếu của đám mây, nói về khả năng cấp phát và thu hồi tài nguyên nhanh, đôi khi tự động, để mở rộng ra hoặc co lại theo nhu cầu. Nếu cần nền tảng rộng hơn về mô hình IaaS, PaaS, SaaS, bạn xem bài điện toán đám mây tổng quan.

Có hai hướng co giãn mà bạn sẽ gặp trong tài liệu kỹ thuật:

• Co giãn ngang (scale-out / scale-in): thêm hoặc bớt số máy ảo, container chạy cùng một ứng dụng. Đây là kiểu phổ biến nhất khi nói về elasticity.
• Co giãn dọc (scale-up / scale-down): tăng hoặc giảm cấu hình của một máy, ví dụ từ 4 lên 8 vCPU. Kiểu này thường cần khởi động lại hoặc có giới hạn trần theo loại máy.

VMware lưu ý elasticity thường gắn với kiến trúc co giãn ngang và với tài nguyên đám mây công cộng tính phí theo mức dùng.

Cơ chế hoạt động: vòng lặp đo – quyết định – cấp phát

Elasticity không phải phép màu của nhà cung cấp. Đó là một vòng điều khiển có thể cấu hình. Hệ thống theo dõi các chỉ số như mức dùng CPU, bộ nhớ, lưu lượng mạng và tốc độ giao dịch. Khi chỉ số vượt ngưỡng bạn đặt, nền tảng thêm tài nguyên. Khi chỉ số xuống thấp đủ lâu, nền tảng thu hồi.

Ba kiểu chính sách co giãn

• Theo chỉ số (target tracking hoặc threshold): ví dụ giữ CPU trung bình quanh 60%. Hệ thống tự tính số bản cần để về mức đó.
• Theo lịch (scheduled): bạn biết trước 19h–22h mỗi tối thứ Sáu tải tăng, nên đặt lịch tăng số bản từ 18h45. Cách này bù được độ trễ khởi động.
• Dự báo (predictive): một số nền tảng học mẫu tải theo chu kỳ ngày, tuần để cấp phát trước. Cần có lịch sử tải đủ dài mới đáng tin.

Những tham số quyết định chất lượng co giãn

Phần lớn sự cố không đến từ việc “không có elasticity” mà từ cấu hình sai các tham số sau:

• Số bản tối thiểu và tối đa (min/max): min quá thấp khiến hệ thống chậm vào lúc tải vọt. Max không đặt khiến chi phí không có trần.
• Thời gian khởi động (warm-up): một máy ảo cần vài phút để khởi động, nạp ứng dụng và qua kiểm tra sức khoẻ. Trong lúc đó các bản cũ vẫn chịu tải. Container thường lên nhanh hơn máy ảo.
• Thời gian chờ thu hồi (cooldown, stabilization): nếu thu hồi quá nhanh, tải dao động nhẹ sẽ khiến hệ thống tăng giảm liên tục, gọi là “flapping”. Kubernetes Horizontal Pod Autoscaler có cửa sổ ổn định khi giảm để tránh hiện tượng này.
• Chỉ số chọn để co giãn: CPU hợp với ứng dụng xử lý nặng tính toán. Với hệ thống xử lý bất đồng bộ, độ dài hàng đợi hoặc độ trễ xử lý phản ánh tải thật hơn. Bạn có thể xem thêm cách hàng đợi hoạt động ở bài message queue.

Điều kiện kỹ thuật để ứng dụng co giãn được

Nhiều doanh nghiệp chuyển hệ thống lên đám mây nhưng vẫn không co giãn được vì kiến trúc ứng dụng chưa cho phép. Ba điều kiện thường gặp:

1. Ứng dụng không giữ trạng thái trong từng máy (stateless). Phiên đăng nhập, giỏ hàng, tệp tải lên phải nằm ở nơi dùng chung như bộ nhớ đệm, cơ sở dữ liệu hoặc kho đối tượng. Nếu giỏ hàng nằm trong RAM của máy A, thu hồi máy A là khách mất giỏ.
2. Có bộ cân bằng tải (load balancer) phía trước. Bản mới chỉ có ích khi lưu lượng được chia đến nó, và bản sắp thu hồi phải được rút khỏi nhóm sau khi xử lý xong các yêu cầu đang dở.
3. Tầng dữ liệu không thành điểm nghẽn. Web có thể nhân lên 20 bản trong vài phút, nhưng một cơ sở dữ liệu duy nhất vẫn chịu số kết nối như cũ. Khi đó co giãn tầng web chỉ chuyển điểm nghẽn xuống database. Cách xử lý thường là bộ nhớ đệm, bản sao chỉ đọc (read replica) hoặc chia dữ liệu (sharding), và mỗi cách đều có chi phí thiết kế riêng.

Nền tảng bên dưới cũng quan trọng. Máy ảo dựa trên công nghệ ảo hoá nên có thể tạo từ một ảnh mẫu trong vài phút. Với container, Kubernetes cung cấp bộ co giãn Pod và co giãn cụm máy. Ở mức trừu tượng cao hơn, mô hình serverless để nhà cung cấp tự lo số bản chạy, nhưng bạn phải chấp nhận giới hạn về thời gian chạy và độ trễ khởi động lạnh.

Cloud elasticity khác scalability thế nào?

Hai khái niệm hay bị dùng lẫn. Cách phân biệt đơn giản: scalability trả lời “hệ thống có lớn lên được khi doanh nghiệp lớn lên không”, còn elasticity trả lời “hệ thống có kịp theo tải của giờ này, hôm nay không, và có co lại khi hết tải không”.

Tiêu chí	Elasticity (co giãn)	Scalability (mở rộng)
Câu hỏi trả lời	Có theo kịp biến động tải tức thời?	Có chịu được tăng trưởng lâu dài?
Khung thời gian	Phút đến giờ	Tháng đến năm
Chiều thay đổi	Tăng rồi giảm	Chủ yếu tăng
Cách thực hiện	Chính sách tự động, hoặc chỉnh tay nhanh	Quy hoạch kiến trúc, đổi gói, thêm cụm
Rủi ro chính	Phản ứng chậm, dao động, hoá đơn vọt	Kiến trúc chạm trần, nghẽn dữ liệu
Có trên máy chủ tại chỗ?	Khó, vì phần cứng phải mua trước	Có, bằng cách mua thêm phần cứng

Một hệ thống có thể scalable mà không elastic: ví dụ bạn nâng gói máy chủ mỗi năm nhưng không bao giờ hạ xuống. Ngược lại, elasticity không có ý nghĩa nếu kiến trúc không scalable, vì thêm bản mà không tăng được thông lượng.

Ví dụ minh hoạ: đợt khuyến mãi của cửa hàng trực tuyến

Ví dụ minh hoạ (số liệu giả định): một website bán đồ gia dụng bình thường chạy 3 máy ứng dụng. Mỗi tối thứ Sáu có chương trình giờ vàng từ 20h đến 22h, tải tăng gấp khoảng 5 lần. Nếu mua cố định 15 máy, 12 máy nhàn rỗi gần như cả tuần. Nếu giữ 3 máy, trang chậm đúng lúc khách muốn mua.

Với chính sách co giãn, bạn đặt min 3, max 18, lịch tăng lên 10 bản lúc 19h45, và chỉ số theo dõi là số yêu cầu mỗi bản. Nếu tải thực vượt dự kiến, chính sách theo chỉ số tiếp tục thêm bản đến mức trần. Sau 22h30 hệ thống thu hồi dần về 3. Bạn trả tiền cho các bản phụ chỉ trong khoảng ba giờ.

Hình trên cũng cho thấy giới hạn: đường bậc thang chỉ bám nhu cầu theo từng nấc. Đoạn tải tăng quá nhanh sẽ có khoảng ngắn công suất chưa kịp, nên người ta thường đặt thêm một khoảng đệm.

Công cụ co giãn có tên gọi cụ thể

Mỗi nhà cung cấp lớn có tính năng riêng, bạn nên đọc tài liệu chính thức của họ để biết giới hạn hiện hành:

• AWS: Auto Scaling Groups cho máy ảo EC2, kèm Application Auto Scaling cho một số dịch vụ khác.
• Microsoft Azure: Virtual Machine Scale Sets và tính năng autoscale cho nhiều dịch vụ ứng dụng.
• Google Cloud: Managed Instance Groups có autoscaler.
• Kubernetes: Horizontal Pod Autoscaler (tăng giảm số Pod), Vertical Pod Autoscaler (chỉnh tài nguyên mỗi Pod) và Cluster Autoscaler (tăng giảm số node).

Nhà cung cấp trong nước cũng có dịch vụ máy chủ ảo, nhưng mức độ hỗ trợ co giãn tự động khác nhau. Trước khi chọn, hãy hỏi trực tiếp: có API để tạo máy theo kịch bản không, mất bao lâu để lên máy mới, và giới hạn hạn mức (quota) mặc định là bao nhiêu.

Ứng dụng cho doanh nghiệp Việt Nam

• Thương mại điện tử và bán lẻ: tải tăng quanh các đợt khuyến mãi như ngày đôi (11.11, 12.12), Tết, Black Friday. Tải theo lịch nên dùng chính sách theo lịch kết hợp theo chỉ số.
• Ứng dụng nội bộ theo giờ hành chính: hệ thống chấm công, báo cáo hay phần mềm kế toán đám mây dùng nhiều đầu tháng, cuối quý khi chốt sổ. Nhiều nhà cung cấp ERP trên đám mây tự lo phần này ở phía họ, bạn nên hỏi họ co giãn thế nào trong kỳ khoá sổ.
• Xử lý theo lô: kết xuất báo cáo, chuyển đổi video, huấn luyện mô hình. Bạn thuê nhiều máy trong vài giờ rồi tắt. Lợi ích rõ nhất vì tải không cần phản hồi tức thời.
• Cổng đăng ký, tra cứu theo đợt: các dịch vụ như tuyển sinh, kê khai trực tuyến có đỉnh rất ngắn gần hạn chót. Tải này khó đoán chi tiết nhưng biết trước thời điểm, nên cần lịch nâng công suất cộng với dự phòng tự động.

Ưu điểm và hạn chế

Ưu điểm

• Bớt cấu hình dư thừa: elasticity giúp tránh cấp phát thừa tài nguyên (over-provisioning) và cấp phát thiếu (under-provisioning).
• Không chờ mua phần cứng: hạ tầng truyền thống cần can thiệp thủ công và lập kế hoạch công suất từ trước, còn hạ tầng đàn hồi tự tăng giảm theo tải.
• Giảm việc giám sát thủ công: đội vận hành không phải canh biểu đồ tải để thêm hoặc bớt máy.

Hạn chế cần biết trước

• Hoá đơn khó dự đoán. Chi phí biến động theo tải. Một lỗi vòng lặp trong ứng dụng, hoặc lưu lượng rác, có thể kéo số bản lên mức trần và giữ ở đó.
• Tấn công làm tăng chi phí. Khi bị tấn công từ chối dịch vụ, hệ thống co giãn có thể giữ dịch vụ sống nhưng tốn tiền cho lưu lượng không phải khách hàng. Bạn nên đọc các dạng tấn công DDoS để đặt lớp lọc lưu lượng phía trước và đặt ngưỡng tối đa phù hợp.
• Độ trễ khi tải tăng đột ngột. Máy mới cần thời gian khởi động. Tải vọt trong vài chục giây vẫn có thể gây lỗi trước khi bản mới sẵn sàng.
• Giới hạn hạn mức. Nhà cung cấp đặt quota cho từng khu vực và loại máy. Vào mùa cao điểm, yêu cầu vượt hạn mức sẽ bị từ chối, nên bạn phải xin nâng hạn mức từ trước.
• Độ phức tạp vận hành. Cần ghi nhật ký, theo dõi và kiểm tra thử tải để biết chính sách có hoạt động đúng không.

Về cam kết dịch vụ, elasticity không được hiểu là bảo đảm uptime. Phần cam kết nằm trong thoả thuận mức dịch vụ, và thường chỉ tính cho độ sẵn sàng của hạ tầng nhà cung cấp, không tính lỗi do cấu hình co giãn của bạn.

Khi nào nên và không nên dựa vào elasticity?

Quyết định phụ thuộc vào hai câu hỏi: tải của bạn có dao động mạnh không, và ứng dụng có chạy được nhiều bản song song không. Ma trận dưới đây tóm tắt bốn trường hợp.

Nên dùng khi

• Tải có đỉnh rõ nhưng ngắn, như đợt khuyến mãi, kỳ chốt sổ, hạn chót kê khai.
• Ứng dụng đã stateless hoặc đã đóng gói container và có kiểm tra sức khoẻ.
• Bạn đo được độ trễ và lỗi theo từng giây để chính sách có chỉ số tốt mà bám.

Chưa nên, hoặc cần cân nhắc kỹ khi

• Phần mềm cũ lưu phiên trong bộ nhớ máy, hoặc giấy phép tính theo từng máy hay từng nhân CPU. Mỗi bản mới sinh thêm phí bản quyền.
• Tải gần như phẳng quanh năm. Khi đó một cam kết dùng dài hạn (reserved, savings plan) thường rẻ hơn, và bạn nên hỏi nhà cung cấp về mức chiết khấu cụ thể thay vì phỏng đoán.
• Hệ thống bắt buộc đặt tại chỗ vì lý do độ trễ hoặc quy định. Bạn có thể kết hợp đám mây lai: giữ lõi dữ liệu tại chỗ, “tràn” phần tải đỉnh lên đám mây công cộng (cloud bursting), với điều kiện đường truyền và đồng bộ dữ liệu đã được thiết kế.

Checklist kiểm tra trước khi bật co giãn tự động

1. Ghi lại mẫu tải trong 4 tuần gần nhất: giờ cao điểm, giờ thấp điểm, ngày đặc biệt.
2. Xác nhận bản mới tạo ra có cùng ảnh mẫu, cấu hình, biến môi trường và kết nối được tới cơ sở dữ liệu.
3. Đặt min và max, tính chi phí ở mức max chạy liên tục 24 giờ để biết trường hợp xấu nhất.
4. Bật cảnh báo ngân sách (budget alert) theo ngày, không chỉ theo tháng.
5. Chạy kiểm thử tải trên môi trường thử, quan sát thời gian từ lúc vượt ngưỡng đến lúc bản mới nhận được yêu cầu.
6. Kiểm tra chiều thu hồi: bản đang xử lý giao dịch dở có được chờ hoàn tất (connection draining) không.
7. Kiểm tra hạn mức khu vực và xin nâng nếu cần, trước mùa cao điểm.

Lỗi thường gặp nhất là chỉ thử chiều tăng mà quên thử chiều giảm. Hệ quả là bản bị thu hồi giữa giao dịch hoặc máy không bao giờ tắt vì chỉ số được chọn không giảm xuống ngưỡng.

Câu hỏi thường gặp

Cloud elasticity có giống auto scaling không?

Không hoàn toàn. Elasticity là đặc tính của đám mây, còn auto scaling là một cách hiện thực hóa đặc tính đó bằng chính sách tự động. Elasticity cũng có thể thực hiện thủ công, khi người quản trị nhận cảnh báo rồi tự thêm hoặc bớt tài nguyên.

Elasticity có làm giảm chi phí chắc chắn không?

Không chắc chắn. Chi phí giảm khi tải dao động và bạn thu hồi đúng lúc. Nếu tải phẳng, hoặc chính sách đặt min quá cao, hoặc không có trần max, hoá đơn có thể không giảm, thậm chí tăng.

Doanh nghiệp nhỏ có cần elasticity không?

Phụ thuộc vào ứng dụng. Nếu bạn dùng phần mềm dạng dịch vụ, nhà cung cấp đã lo co giãn ở phía họ. Nếu bạn tự vận hành website có đợt cao điểm rõ rệt thì elasticity đáng xem xét. Nếu hệ thống chỉ có vài chục người dùng nội bộ, một máy cấu hình đủ dùng thường đơn giản hơn.

Vì sao đã lên đám mây mà hệ thống vẫn nghẽn khi tải cao?

Thường do ba nguyên nhân: ứng dụng giữ trạng thái trong từng máy nên không nhân bản được, cơ sở dữ liệu là điểm nghẽn, hoặc máy mới khởi động chậm hơn tốc độ tăng tải. Bạn cần xác định nghẽn ở tầng nào trước khi chỉnh chính sách.

Elasticity có áp dụng cho lưu trữ và mạng không?

Có. Kho lưu trữ đối tượng thường tăng dung lượng theo mức dùng mà bạn không phải cấp phát trước, còn băng thông có thể tăng theo gói hoặc theo cơ chế tính phí theo lưu lượng. Mức độ co giãn khác nhau theo từng dịch vụ, nên hãy đọc điều khoản của dịch vụ cụ thể.