Scalability — mô tả tải bằng tham số, không bằng cảm tính

TL;DR: Scalability không phải một tính từ ("hệ này scale được") mà là một câu hỏi định lượng: khi tham số tải tăng, cần thêm tài nguyên gì để giữ hiệu năng? Bước một là mô tả tải bằng tham số (load parameter) — request/giây, tỉ lệ đọc/ghi, số kết nối đồng thời, fan-out — chứ không nói "nhiều người dùng". Bước hai là chọn hướng mở rộng: scale-up (máy mạnh hơn) hay scale-out (nhiều máy hơn). Scale-up đơn giản nhưng đụng trần vật lý và giá; scale-out gần như vô hạn nhưng kéo theo mọi bài toán phân tán của track này. Đo hiệu năng bằng response time phân phối (percentile), không bằng trung bình — lý do sẽ rõ ở bài tail latency.

Khi ai đó nói "hệ của tôi scale được", hãy hỏi lại: scale theo tham số nào? Một hệ mở rộng tốt khi số người đọc tăng có thể sập khi số người ghi tăng — hai tham số tải khác nhau, hai bài toán khác nhau. Không có "scalable" chung chung; chỉ có "scalable theo tham số X".

Bài này cho bạn cách nói về tải một cách cụ thể để câu hỏi mở rộng trở nên trả lời được, rồi so hai hướng mở rộng cơ bản.

1. Analogy — quán ăn giờ cao điểm

Một quán ăn phục vụ tốt lúc vắng. Câu hỏi scalability là: khi khách tăng gấp đôi, làm sao giữ thời gian ra món như cũ? Có hai cách. Thuê một siêu đầu bếp làm nhanh gấp đôi (scale-up) — nhưng không có đầu bếp nào nhanh vô hạn, và người giỏi nhất đắt phi lý. Hoặc mở thêm nhiều bếp song song (scale-out) — gần như thêm bao nhiêu cũng được, nhưng giờ phải điều phối: chia đơn cho bếp nào, gộp món ra sao, bếp này nghỉ thì đơn đi đâu.

2. Mô tả tải bằng tham số — "nhiều" là vô nghĩa

Câu "hệ chịu được nhiều tải không" không trả lời được cho tới khi định nghĩa tải bằng con số. Load parameter là đại lượng mô tả tải phù hợp với hệ:

• Throughput — số request (hoặc bản ghi) xử lý mỗi giây.
• Tỉ lệ đọc/ghi — một hệ đọc-nhiều và một hệ ghi-nhiều mở rộng theo hai hướng hoàn toàn khác.
• Số kết nối đồng thời — bao nhiêu client giữ kết nối cùng lúc.
• Fan-out — một thao tác kéo theo bao nhiêu thao tác phụ. Ví dụ: một người đăng bài, hệ phải ghi vào feed của hàng nghìn người theo dõi — một ghi logic nở thành hàng nghìn ghi thật.

Chọn đúng load parameter là nửa lời giải. Fan-out là ví dụ kinh điển: hệ "chịu được" 10.000 bài đăng/giây nghe ổn, nhưng nếu mỗi bài fan-out tới trung bình 500 người theo dõi thì tải ghi thật là 5 triệu/giây — con số hoàn toàn khác. Nói "10.000 bài/giây" mà quên fan-out là mô tả tải sai.

3. Đo hiệu năng — nhìn phân phối, không nhìn trung bình

Khi tải tăng, "hiệu năng" (response time) phải đo bằng phân phối (percentile p50/p95/p99), không phải trung bình — trung bình giấu mất những request chậm nhất. Đây là câu hỏi được đào sâu trọn vẹn ở bài 03 — Tail latency: vì sao trung bình nói dối, và tail bị khuếch đại ra sao khi fan-out.

4. Scale-up hay scale-out — chọn hướng mở rộng nào?

Scale-up (vertical) — thay bằng máy mạnh hơn: nhiều CPU, nhiều RAM. Ưu: đơn giản, không đổi kiến trúc, code chạy y nguyên. Nhược: có trần vật lý (không có máy vô hạn mạnh) và giá tăng phi tuyến — máy gấp đôi sức mạnh thường đắt hơn gấp đôi rất nhiều.

Scale-out (horizontal) — thêm nhiều máy thường, chia việc ra: đặt một lớp chia tải (load balancer) trước nhiều bản. Ưu: mở rộng gần như vô hạn bằng phần cứng rẻ, và nhiều máy còn giúp reliability (redundancy — nhớ bài 01). Nhược: kéo theo mọi bài toán phân tán — dữ liệu phải nhân bản hoặc phân mảnh, các máy phải đồng bộ, và xuất hiện các fault mà một máy không có (một node chết giữa chừng, mạng giữa các máy không tin cậy).

flowchart TB
  subgraph UP["Scale-up (vertical)"]
    S1["1 may nho"] --> S2["1 may lon hon (nhieu CPU/RAM)"]
  end
  subgraph OUT["Scale-out (horizontal)"]
    LB["Load balancer"] --> N1["may 1"]
    LB --> N2["may 2"]
    LB --> N3["may 3"]
  end

Thực tế phần lớn hệ lớn dùng cả hai: scale-up tới điểm giá còn hợp lý, rồi scale-out. Nhưng scale-out là lý do cả track này tồn tại — nó đổi bài toán "làm máy mạnh hơn" (kỹ thuật phần cứng) thành "phối hợp nhiều máy không tin cậy" (kỹ thuật phân tán).

5. Pitfall — "cứ mua máy to hơn" và đo bằng trung bình

❌ "He cham? Mua may to gap doi."
   -> dung 1 thoi gian, roi lai dung tran vat ly + gia phi tuyen
   -> van la MOT may -> single point of failure (nho bai 01)

❌ Do bang response time TRUNG BINH -> thay dep -> tuong on
   -> tail (p99) van cao -> 1% nguoi dung kho so ma dashboard khong thay

6. 📚 Đào sâu — nguồn gốc & tài liệu

7. Liên hệ các bài khác

• Bài 01 — Reliability: scale-out thêm máy vừa tăng throughput vừa tạo redundancy (reliability) — nhưng cũng thêm fault phân tán; hai thước đo đan vào nhau.
• Bài 03 — Tail latency: mục 3 chỉ bắc cầu tới percentile — bài 03 đào sâu vì sao p99 mới là thước đo trải nghiệm thật, và tail bị khuếch đại khi fan-out.
• Bài 04 — Maintainability: scale-out làm hệ phức tạp hơn để vận hành — đánh đổi với simplicity, một trục của maintainability.

8. Tóm tắt

• Scalability là câu hỏi định lượng theo từng load parameter, không phải nhãn "scale được".
• Mô tả tải bằng tham số: throughput, tỉ lệ đọc/ghi, kết nối đồng thời, fan-out — chọn đúng tham số là nửa lời giải.
• Đo hiệu năng bằng phân phối response time (percentile), không bằng trung bình — trung bình giấu tail.
• Scale-up: đơn giản nhưng đụng trần vật lý + giá phi tuyến. Scale-out: gần vô hạn + tăng redundancy, nhưng kéo theo mọi bài toán phân tán.
• Hệ lớn thường dùng cả hai; scale-out là lý do track này tồn tại — đổi "máy mạnh hơn" thành "phối hợp nhiều máy không tin cậy".
• Anti-pattern: scale-up như phản xạ + đo bằng trung bình → trì hoãn bài toán thật và giấu tail hỏng.

9. Tự kiểm tra

Bài tiếp theo: Tail latency — đo bằng p99, không bằng trung bình