

Khi ứng dụng bắt đầu tăng tải, máy chủ hiện tại có thể không còn đủ tài nguyên để xử lý ổn định. Lúc này, doanh nghiệp thường phải lựa chọn giữa việc nâng cấp máy chủ hiện có hoặc mở rộng sang nhiều máy chủ mới. Vậy Vertical Scaling là gì, hoạt động như thế nào và phù hợp trong trường hợp nào? Bài viết dưới đây sẽ giúp làm rõ cách mở rộng này trước khi so sánh với Horizontal Scaling.
Vertical scaling (mở rộng theo chiều dọc), còn được gọi là scaling up hoặc scaling down, là quá trình tăng dung lượng hoặc năng lực của một thành phần phần cứng hoặc phần mềm riêng lẻ trong hệ thống.
Thay vì thêm nhiều hệ thống mới, chúng ta nâng cấp chính hệ thống hiện tại. Có thể tăng sức mạnh cho máy bằng cách thêm bộ xử lý tốt hơn, tăng RAM, bổ sung các tài nguyên như năng lực xử lý của CPU, dung lượng lưu trữ của một máy chủ hoặc thực hiện các điều chỉnh khác để nâng cao hiệu năng.
Cách này đơn giản để triển khai và phù hợp với các ứng dụng monolithic và các ứng dụng quy mô nhỏ.
Vertical Scaling có thể được hình dung giống như việc mở rộng sức chứa của một cây cầu để phục vụ nhiều phương tiện hơn. Khi cây cầu được làm chắc hơn và rộng hơn, nó có thể chịu tải lớn hơn mà không cần xây thêm làn đường mới.

Các ví dụ sau minh họa cách vertical scaling cải thiện năng lực hệ thống bằng cách nâng cấp tài nguyên của một máy chủ duy nhất:
Một ví dụ khác: Nếu một API được chạy trên một máy ảo được cấp 1 lõi CPU và 512 megabyte RAM, thì việc scaling up API đó có thể là tăng gấp đôi số lõi CPU và RAM. Khi đó, API sẽ có 2 lõi CPU chuyên dụng và 1.024 megabyte RAM. Với cấu hình mới này, API về lý thuyết có thể xử lý lượng tải gần như gấp đôi. Tuy nhiên, các giới hạn về băng thông mạng, tốc độ lưu trữ và những yếu tố khác có thể làm giảm hiệu quả của vertical scaling. Ngoài ra, vertical scaling cũng đặt ra thách thức về quản lý tài nguyên, nhưng các phần mềm chuyên dụng thường có thể xử lý vấn đề này.
💡 Netflix sử dụng cả Horizontal Scaling và Vertical Scaling, cho thấy hiệu quả của cách tiếp cận kết hợp trong việc xử lý hoạt động phân phối nội dung toàn cầu và các tập dữ liệu khổng lồ.

Ưu điểm của Vertical Scaling là dễ triển khai, ít thay đổi kiến trúc và giúp tăng hiệu năng nhanh bằng cách nâng cấp CPU, RAM hoặc storage cho máy chủ hiện có. Cụ thể:
Ngoài ra, Vertical Scaling còn phát sinh chi phí “ẩn” không dễ nhận thấy khi nâng cấp. Ví dụ, việc phụ thuộc vào một hệ thống có điểm lỗi duy nhất sẽ gây thiệt hại lớn khi downtime xảy ra. Theo nghiên cứu năm 2022 của Enterprise Management Associates (EMA) và BigPanda, downtime khiến doanh nghiệp thiệt hại trung bình 12.900 USD mỗi phút. Những chi phí này nhanh chóng xóa sạch khoản tiết kiệm ban đầu khi lựa chọn Vertical Scaling.

Trong quá trình phát triển ứng dụng, hệ thống có thể gặp tình trạng quá tải khi lượng người dùng, dữ liệu hoặc request tăng lên. Để cải thiện hiệu năng và khả năng xử lý, hai phương pháp mở rộng thường được sử dụng là Horizontal Scaling và Vertical Scaling.
Mỗi phương pháp có cách triển khai, ưu điểm và giới hạn riêng. Việc hiểu rõ sự khác nhau giữa Horizontal Scaling và Vertical Scaling giúp lựa chọn mô hình mở rộng phù hợp với quy mô hệ thống, chi phí vận hành và yêu cầu về độ ổn định.
Tiêu chí | Horizontal Scaling | Vertical Scaling |
| Định nghĩa | Mở rộng hệ thống bằng cách thêm nhiều máy chủ/máy tính để phân tán tải. | Mở rộng hệ thống bằng cách tăng tài nguyên cho một máy chủ hiện có, như CPU, RAM hoặc dung lượng lưu trữ. |
| Cách mở rộng | Thêm nhiều máy chủ mới vào hệ thống để chia sẻ workload. | Nâng cấp phần cứng hoặc tài nguyên của một máy chủ duy nhất. |
| Khả năng mở rộng | Có khả năng mở rộng lớn, phù hợp với hệ thống cần tăng trưởng liên tục; giới hạn chủ yếu nằm ở kiến trúc phần mềm. | Bị giới hạn bởi năng lực tối đa của một máy chủ vật lý hoặc máy ảo. |
| Chi phí | Chi phí ban đầu có thể cao hơn do cần thêm máy chủ và hạ tầng quản lý, nhưng hiệu quả hơn về lâu dài với hệ thống quy mô lớn. | Chi phí ban đầu thường thấp hơn, nhưng có thể trở nên tốn kém khi cần nâng cấp phần cứng cấu hình cao. |
| Độ phức tạp | Phức tạp hơn vì liên quan đến hệ thống phân tán, đồng bộ dữ liệu, cân bằng tải và quản lý nhiều node. | Đơn giản hơn vì chủ yếu chỉ nâng cấp và vận hành trên một máy chủ. |
| Tính linh hoạt | Linh hoạt cao vì có thể bổ sung hoặc loại bỏ máy chủ tùy theo nhu cầu tải. | Kém linh hoạt hơn do phụ thuộc vào khả năng nâng cấp của một máy chủ duy nhất. |
| Hiệu năng | Cải thiện hiệu năng bằng cách phân phối lưu lượng truy cập hoặc dữ liệu trên nhiều máy chủ. | Hiệu năng tăng trực tiếp khi bổ sung CPU, RAM hoặc storage, nhưng chỉ đến giới hạn phần cứng. |
| Khả năng chịu lỗi | Tốt hơn vì workload được phân tán trên nhiều máy chủ; nếu một máy gặp sự cố, hệ thống vẫn có thể tiếp tục hoạt động nếu được thiết kế đúng. | Thấp hơn vì hệ thống phụ thuộc nhiều vào một máy chủ; nếu máy này gặp lỗi, toàn bộ ứng dụng có thể bị ảnh hưởng. |
| Rủi ro single point of failure | Giảm rủi ro điểm lỗi duy nhất nhờ phân tán tài nguyên trên nhiều máy chủ. | Có rủi ro single point of failure cao hơn nếu không có cơ chế dự phòng hoặc backup. |
| Downtime khi mở rộng | Thường có thể mở rộng mà không cần dừng hệ thống nếu kiến trúc hỗ trợ tự động thêm node. | Có thể cần downtime khi nâng cấp phần cứng hoặc thay đổi cấu hình máy chủ. |
| Sử dụng tài nguyên | Tài nguyên được phân bổ hiệu quả hơn giữa nhiều máy chủ, đặc biệt với workload biến động. | Có thể xảy ra tình trạng thiếu tài nguyên khi tải tăng hoặc dư thừa tài nguyên khi tải thấp. |
| Cân bằng tải | Thường cần load balancing để phân phối traffic giữa các máy chủ. | Thường không cần load balancing vì workload chủ yếu chạy trên một máy chủ chính. |
| Cách giao tiếp | Dựa vào giao tiếp qua mạng giữa nhiều máy chủ hoặc nhiều node trong hệ thống. | Chủ yếu xử lý và giao tiếp nội bộ trong một máy chủ duy nhất. |
| Mức độ quản lý | Khó quản lý hơn vì cần theo dõi nhiều máy chủ, mạng, dữ liệu và trạng thái hệ thống phân tán. | Dễ quản lý hơn vì phạm vi vận hành tập trung trên một máy chủ. |
| Trường hợp phù hợp | Phù hợp với ứng dụng web, hệ thống phân tán, nền tảng có nhiều người dùng hoặc lưu lượng truy cập cao. | Phù hợp với ứng dụng có nhu cầu mở rộng vừa phải hoặc cần tăng nhanh tài nguyên xử lý trên một máy. |
| Loại workload phù hợp | Phù hợp với workload có thể chia nhỏ, xử lý song song hoặc phân phối qua nhiều node. | Phù hợp với workload cần xử lý chuyên sâu trên một máy, chẳng hạn như tác vụ tính toán nặng hoặc cơ sở dữ liệu nhỏ đến trung bình. |
| Ví dụ | Cassandra, MongoDB, Google Cloud Spanner, hệ thống web nhiều node. | MySQL, Amazon RDS, máy chủ ứng dụng được nâng cấp CPU/RAM. |
Vertical Scaling phù hợp với các hệ thống cần tăng tài nguyên xử lý trên một máy chủ duy nhất, đặc biệt khi ứng dụng chưa có nhu cầu mở rộng quá lớn hoặc kiến trúc hiện tại vẫn vận hành tốt trên một server. Cách tiếp cận này thường được lựa chọn khi doanh nghiệp muốn nâng cấp nhanh CPU, RAM, dung lượng lưu trữ hoặc hiệu năng xử lý mà chưa cần thay đổi nhiều về kiến trúc hệ thống.
Vertical Scaling thường phù hợp trong các trường hợp sau:
Tuy nhiên, Vertical Scaling có giới hạn rõ ràng vì hiệu năng chỉ tăng đến mức tối đa mà phần cứng cho phép. Khi hệ thống bắt đầu có nhiều người dùng, traffic tăng nhanh hoặc yêu cầu độ sẵn sàng cao hơn, doanh nghiệp thường cần cân nhắc kết hợp thêm Horizontal Scaling.
Horizontal Scaling phù hợp với các hệ thống cần mở rộng lớn, xử lý nhiều người dùng đồng thời hoặc có lưu lượng truy cập biến động mạnh. Thay vì nâng cấp một máy chủ duy nhất, phương pháp này bổ sung thêm nhiều máy chủ hoặc node để phân tán workload, tăng throughput và cải thiện khả năng chịu lỗi của hệ thống.
Horizontal Scaling thường phù hợp trong các trường hợp sau:
Điểm cần lưu ý là Horizontal Scaling thường phức tạp hơn Vertical Scaling vì liên quan đến load balancing, service discovery, đồng bộ dữ liệu, monitoring và quản lý hệ thống phân tán. Vì vậy, phương pháp này phù hợp hơn với các hệ thống đã có yêu cầu mở rộng rõ ràng hoặc cần đảm bảo hiệu năng ở quy mô lớn.

Thông thường, có thể scale up trước khi hệ thống còn đơn giản, traffic chưa quá lớn và bottleneck nằm rõ ở tài nguyên máy chủ như CPU, RAM, disk I/O hoặc network. Đây là cách nhanh để cải thiện hiệu năng mà chưa phải thay đổi nhiều kiến trúc.
Nên scale out khi workload tăng liên tục, một máy chủ không còn đủ khả năng xử lý, hoặc hệ thống cần tăng tính sẵn sàng. Nếu mục tiêu là phục vụ nhiều người dùng đồng thời, giảm rủi ro downtime và mở rộng linh hoạt theo nhu cầu, Horizontal Scaling thường phù hợp hơn.
Trong phần lớn trường hợp, có. Khi hệ thống có nhiều server hoặc instance cùng xử lý request, cần một cơ chế phân phối traffic đến các node phù hợp. Load Balancer giúp chia tải, tránh một server bị quá tải và hỗ trợ chuyển request sang node khác nếu một node gặp lỗi.
Tuy nhiên, Load Balancer không phải thành phần duy nhất. Để Horizontal Scaling vận hành tốt, hệ thống còn cần health check, session management, monitoring, logging tập trung và cơ chế tự động thêm/bớt instance nếu chạy trên cloud.
Có. Trong thực tế, nhiều hệ thống không chỉ chọn một trong hai. Giai đoạn đầu có thể dùng Vertical Scaling để tăng nhanh năng lực xử lý. Khi hệ thống lớn hơn, có thể kết hợp thêm Horizontal Scaling để phân tán tải và tăng khả năng chịu lỗi.
Cách tiếp cận kết hợp này thường hợp lý hơn vì mỗi mô hình giải quyết một phần khác nhau của bài toán. Vertical Scaling giúp tăng sức mạnh từng node, còn Horizontal Scaling giúp hệ thống mở rộng linh hoạt và bền vững hơn khi tải tăng mạnh.
Tóm lại, Vertical Scaling là gì có thể hiểu đơn giản là cách mở rộng hệ thống bằng việc tăng tài nguyên cho máy chủ hiện có. Phương pháp này phù hợp với các ứng dụng cần nâng cấp nhanh CPU, RAM hoặc storage mà chưa muốn thay đổi kiến trúc. Tuy nhiên, do bị giới hạn bởi phần cứng, doanh nghiệp cần cân nhắc thời điểm kết hợp thêm Horizontal Scaling để đảm bảo khả năng mở rộng lâu dài.
