- Bản chất của cuộc tranh luận không phải là monolithic vs microservices, mà là liệu hệ thống phân tán có đáng với giá trị mang lại so với overhead phát triển/vận hành hay không
- Máy chủ đơn hiện đại có hàng chục đến hàng trăm lõi, bộ nhớ cấp TB, I/O hàng chục đến hàng trăm Gbps, nên có dư địa hiệu năng đủ lớn để gánh phần lớn dịch vụ web
- Các benchmark thực tế cho thấy một máy chủ có thể đạt Nginx 500 nghìn RPS, PostgreSQL 70 nghìn IOPS, NoSQL 1 triệu IOPS, mã hóa 4K 75 FPS và các mức xử lý hiệu năng cao khác
- Dùng cloud giúp tăng tính tiện lợi và độ sẵn sàng, nhưng premium chi phí khá lớn nên cần cân nhắc hiệu quả đầu tư
- Chỉ khi mô hình sử dụng biến động cực lớn thì kiến trúc cloud-native, serverless mới có lợi thế về chi phí
- Tuy nhiên, premium chi phí của serverless/cấu hình microVM là rất lớn, và nếu workload liên tục/có thể dự đoán thì mở rộng theo chiều dọc sẽ kinh tế hơn
- Độ sẵn sàng có thể được giải quyết phần lớn bằng dự phòng chính/phụ (hoặc 2×2) và kết hợp phần cứng khác nhau, còn chiến lược chỉ phân tán CDN và backup là hợp lý
Tổng quan: giá trị của “một máy chủ lớn” so với hệ thống phân tán
- Cốt lõi của tranh luận “monolithic vs. microservices” là đánh giá xem việc áp dụng hệ thống phân tán có đáng với thời gian và chi phí thực tế của lập trình viên hay không
- Phần mềm hiện đại chạy trên ảo hóa máy chủ và nhiều lớp trừu tượng khác nhau; ngay cả “serverless” hay “bare metal” rốt cuộc cũng được xây dựng trên tài nguyên máy chủ vật lý
- Máy chủ ngày nay có hiệu năng trên chi phí cao hơn nhiều so với những gì ta thường nghĩ
- So với trước đây, cấu hình máy chủ đã tăng vọt về số lõi, băng thông bộ nhớ, làn PCIe, lưu trữ NVMe, và nhiều dịch vụ có thể đạt QPS mục tiêu mà không cần phân tán
Hiệu năng mạnh mẽ của phần cứng máy chủ
- Máy chủ ví dụ của Microsoft Azure có cấu hình 2 CPU máy chủ AMD thế hệ 3, tổng cộng 128 lõi 256 luồng
- Một máy chủ đơn có thể đạt mức hiệu năng tính toán khoảng 4 TFLOPs, vượt cả siêu máy tính đầu những năm 2000
- Bố trí 16 khe DDR4-3200 cho mỗi socket RAM cho phép mở rộng tối đa 8TB bộ nhớ, và trên thị trường mua sắm thực tế cũng đã hỗ trợ 1TB RAM
- Tổng cộng 128 làn PCIe Gen4, cùng 30 SSD NVMe và card mạng 50~100Gbps cho phép kết nối lưu trữ và mạng hiệu năng cao
Có thể làm gì với một máy chủ đơn như vậy (trích benchmark)
- Có thể đạt truyền video 400–800 Gbps, NoSQL 1 triệu IOPS, PostgreSQL 70 nghìn IOPS, Nginx 500 nghìn RPS
- Ngay cả với các tác vụ ngốn CPU, bộ nhớ, I/O như build Linux kernel trong 20 giây, mã hóa x264 4K 75FPS, máy chủ vẫn cho throughput cao
So sánh chi phí thuê/mua máy chủ
- OVHCloud: có thể thuê máy chủ 128 lõi/512GB RAM với giá khoảng $1,318/tháng
- Hetzner: cung cấp máy chủ 32 lõi/128GB RAM với giá €140/tháng, mức giá thay đổi theo cấu hình
- AWS m6a.metal: máy chủ 96 lõi vật lý/768GB RAM có giá $8.29/giờ, khoảng $6,055/tháng, cho thấy premium cloud rất lớn
- Nếu mua trực tiếp máy chủ cấu hình tương tự từ Dell thì giá khoảng $40,000, có thể hoàn vốn so với cloud trong khoảng 8 tháng
- Nếu giả định cùng throughput bằng serverless thì ước tính premium chi phí là gấp 5.5 lần so với instance, gấp 25 lần so với hosting giá rẻ
Vì sao hệ thống phân tán từng được ưa chuộng
- Trước đây (quanh năm 2010), do giới hạn về hiệu năng CPU, bộ nhớ và thiết bị lưu trữ, các dịch vụ quy mô lớn buộc phải dùng nhiều máy chủ kết hợp
- Gần đây, nhờ máy chủ đơn cỡ lớn, SSD NVMe, băng thông bộ nhớ cao, giới hạn xử lý của một node đơn đã được nâng lên đáng kể, nhưng các đơn vị VM và container vẫn thường được thiết kế dựa trên tài nguyên máy chủ nhỏ
Khi nào chỉ một máy chủ lớn là đủ
- Phần lớn dịch vụ web dưới 10k QPS chỉ cần một máy là đủ; các dịch vụ đơn giản thậm chí có thể đạt đến mức hàng triệu QPS
- Ngay cả streaming video, control plane trên một máy chủ đơn vẫn là phương án thực tế, và có thể dùng benchmark cùng bảng hiệu năng chung để ước tính kích thước máy chủ phù hợp
- Trừ các tình huống đặc biệt, chỉ cần cấu hình máy chủ chính và máy chủ backup là đủ để đảm bảo độ sẵn sàng
“Cao” hơn là “rộng”: ưu tiên vài máy chủ lớn thay vì cả cụm nhiều máy nhỏ
- Ngay cả khi cần cluster, một vài máy chủ lớn vẫn có overhead điều phối (O(n)) thấp hơn nhiều máy chủ nhỏ
- Nói cách khác, về dài hạn, giảm số lượng máy và tăng cấu hình thường hiệu quả hơn
- Với serverless và mô hình dựa trên container ngắn hạn, tỷ lệ overhead còn lớn hơn nữa
- Nhược điểm là điểm lỗi đơn, nhưng có thể giảm đáng kể chỉ với mô hình chính/phụ (ở các DC khác nhau)
- Vững chắc hơn nữa là cấu hình 2×2 (2 máy ở DC chính + 2 máy ở DC phụ) kết hợp với triển khai phần cứng/nhà sản xuất khác nhau để tránh lỗi tương quan
- Khi thuê máy chủ, đa dạng hóa model máy chủ giúp giảm rủi ro hỏng dây chuyền của đĩa hoặc SSD cùng lô
Ưu điểm và giới hạn của việc dùng cloud
- Cloud mạnh ở độ sẵn sàng, tốc độ khôi phục, sự tiện lợi trong vận hành, và những điểm này xứng đáng với chi phí premium
- Có thể khởi động lại nhanh chóng trong phạm vi chi phí mà không bị downtime, đồng thời tận dụng pool tài nguyên quy mô lớn được quản lý như một grid
- Nhà cung cấp máy chủ thuê riêng có giá rẻ hơn, nhưng bị giới hạn về chất lượng, mạng và hỗ trợ cao cấp
- Tuy nhiên, đội ngũ bán hàng cloud thường khuyến nghị kiến trúc phụ thuộc vendor như VM autoscale, serverless, HA DB managed, nên cần cảnh giác với chi phí và độ phức tạp
- Bản thân việc xử lý lưu lượng lớn không phải là lý do chính để dùng cloud-native; trên thực tế có nhiều trường hợp một máy chủ lớn đơn lẻ vẫn có thể phục vụ hàng triệu người dùng đồng thời
Chi phí tải đỉnh và tiêu chí cho tải bursty
- Luôn sẽ có ai đó phải chuẩn bị năng lực cho tải đỉnh, nên cuối cùng chi phí cho peak sẽ được tính ở đâu đó trong chuỗi cung ứng
- Với các tác vụ bursty hoặc tạm thời (ví dụ: mô phỏng quy mô lớn chạy một lần), serverless/autoscale là kinh tế; nhưng với tải liên tục và có thể dự đoán, vận hành cố định trên máy chủ lớn hiệu quả chi phí hơn
- Nếu tận dụng cam kết 1 năm/spot/đàm phán với sales, chi phí instance còn có thể thấp hơn nữa, và premium so với serverless sẽ còn lớn hơn
Đánh giá định lượng về “premium cloud”
- Điện toán serverless như AWS Lambda có thể phát sinh premium chi phí cao hơn 5 đến 30 lần so với cùng một máy chủ
- Giả định: một máy chủ giá $8.2944/giờ cung cấp 1k QPS, 768GB RAM; nếu thay cùng throughput đó bằng Lambda thì chi phí sẽ vào khoảng $46/giờ, tức premium 5.5 lần
- Ước tính premium gấp 25 lần so với thuê OVH, và chỉ cần đạt 5% mức sử dụng thì hosting giá rẻ đã kinh tế hơn serverless
- Nếu tận dụng hợp đồng dài hạn, spot instance, v.v. thì chênh lệch premium còn có thể lớn hơn
- Dù QPS khác nhau, nếu quy đổi theo memory-time thì hệ số premium tương tự nhau, và điều cốt yếu là scale máy chủ theo kích thước workload
Những phản biện và ngộ nhận phổ biến
- “Dùng cloud thì không cần nhân sự vận hành hệ thống”: thực tế chỉ là đổi tên vai trò thành Cloud Ops; vẫn cần năng lực về tài liệu, theo dõi thay đổi, xử lý deprecation, nên đây còn có thể là yếu tố làm tăng chi phí nhân sự
- “Dùng cloud thì không cần cập nhật bảo mật”: một phần có thể được miễn, nhưng chỉ giới hạn trong những mảng dễ tự động hóa; còn kiểm toán thư viện và xác minh cấu hình vẫn cần thiết
- “Cloud có thiết kế HA nên có thể yên tâm”: độ phức tạp gia tăng tạo ra điểm yếu mới, và ngay cả dự phòng đa region hoặc đa provider cũng không thể loại bỏ hoàn toàn sự cố tương quan
- “Cloud giúp tốc độ phát triển nhanh hơn”: đây là lợi thế về độ linh hoạt ban đầu, nên cứ dùng; nhưng cần theo dõi điểm bẻ cong chi phí để chuyển đổi đúng thời điểm
- “Lưu lượng của chúng tôi rất bursty”: trong trường hợp này, serverless/autoscale là phù hợp
- “Còn CDN thì sao?”: giảm độ trễ và tiết kiệm băng thông là thứ nên mua dưới dạng phân tán, và backup cũng tương tự, là hạng mục nên mua ngoài
Monolithic vs. microservices và cấu trúc máy chủ
- "Máy chủ lớn" thường gắn với kiến trúc monolithic, nhưng cũng có thể triển khai microservices dưới dạng nhiều container trên cùng một máy chủ
- Tuy nhiên, overhead của giao tiếp liên tiến trình, triển khai và quan sát vẫn là gánh nặng ngay cả trên một host đơn, nên lợi ích hiệu năng thực tế so với độ phức tạp sẽ giảm đi đáng kể
- Với quy mô ban đầu hoặc vừa và nhỏ, monolithic hoặc một vài service có lợi hơn về độ đơn giản trong vận hành
Kết luận
- Trong đa số trường hợp, thay vì mở rộng ngang hay kiến trúc tập trung vào cloud, chọn mở rộng dọc (một máy chủ lớn) sẽ đơn giản và kinh tế hơn
- Nếu kết hợp dự phòng chính/phụ, phần cứng dị chủng, và tách riêng CDN/backup, có thể đạt được độ tin cậy thực dụng trong vận hành, đồng thời có ưu thế lớn về tổng chi phí sở hữu (TCO) trong môi trường tải liên tục
- Chỉ cần có chiến lược dự phòng phần cứng vững chắc, cách tiếp cận “một máy chủ lớn” sẽ là lựa chọn rất phù hợp cho dịch vụ thực tế
Chưa có bình luận nào.