Từ vựng về scale: Throughput, Latency, QPS, SLA

Các cuộc thảo luận thiết kế hệ thống diễn ra nhanh vì mọi người dùng chung sáu từ: throughput, latency, scale dọc, scale ngang, QPS, percentile. Nếu các từ ấy mang nghĩa khác nhau với hai người trong phòng, cuộc thảo luận chỉ là vô nghĩa. Chương này định nghĩa chúng một lần, theo cách phần còn lại của series sẽ dùng, và gắn mỗi từ vào một công cụ .NET đo được thật.

Throughput vs latency nghĩa là gì - và vì sao đánh đổi?

Throughput là số request hệ thống xử lý xong mỗi giây (req/s, thường viết tắt QPS - "queries per second"). Latency là thời gian một request chờ trước khi nhận response (ms).

Đây không phải cùng một trục. Một service có thể vừa throughput cao vừa latency cao (job batch trả 10000 kết quả trong 5 giây), hoặc throughput thấp + latency thấp (máy dev một user). Sự đánh đổi xuất hiện dưới tải: khi đẩy QPS gần trần hệ thống, queue hình thành, queue làm tăng latency. Định luật Little nói rõ quan hệ:

số request đồng thời trung bình = throughput * latency trung bình

Phục vụ 1000 req/s với latency trung bình 50 ms thì có 50 request đồng thời đang xử lý. Đẩy lên latency 100 ms là 100 đồng thời - nghĩa là áp lực thread/connection pool nhiều hơn, GC nhiều hơn, contention nhiều hơn, và latency tăng tiếp. Vòng lặp phản hồi này là lý do các service sập phi tuyến khi quá tải kéo dài.

graph LR
    QPS[Throughput tăng] --> Q[Queue lớn]
    Q --> Lat[Latency tăng]
    Lat --> Conc[Đồng thời tăng]
    Conc --> Press[Áp lực tài nguyên]
    Press --> Lat
    style Lat fill:#fbb,stroke:#c00

Vì sao báo p50, p95, p99 thay vì trung bình?

Phân phối latency không phải normal - đuôi dày. Một web service điển hình có thể là 30 ms cho 95/100 request, rồi 200 ms cho 4, rồi 2000 ms cho 1. Trung bình là 56 ms; user chờ 2 giây không thấy "trung bình" gì.

Percentile cắt phân phối trung thực. p50 (median) - một nửa user chờ tối đa số này. p95 - 1 trong 20 chờ lâu hơn. p99 - 1 trong 100. p99.9 - 1 trong 1000, con số đánh thức oncall.

Hai service có cùng trung bình có thể có p99 khác hẳn. Chọn percentile khớp nỗi đau user của bạn - p95 cho UX bình thường, p99 cho luồng giao dịch, p99.9 cho API thanh toán. Instrumentation OpenTelemetry của ASP.NET Core emit trực tiếp:

builder.Services.AddOpenTelemetry()
    .WithMetrics(b => b
        .AddAspNetCoreInstrumentation()    // histogram http.server.request.duration
        .AddRuntimeInstrumentation()        // GC, thread pool
        .AddPrometheusExporter());

Rồi trong Grafana query histogram_quantile(0.99, ...) là có số. Chương 13 xử lý phần dây nối; chương này chỉ đặt kỳ vọng mọi tuyên ngôn về latency phải nói rõ percentile.

Scale dọc và scale ngang khác nhau ra sao?

Scale dọc (vertical) là làm một máy lớn hơn - nhiều CPU, nhiều RAM, đĩa nhanh hơn. Trần là giá single-box tăng siêu tuyến: tier CPU kế tiếp thường giá 4x cho 2x hiệu năng, và đến lúc nào đó bạn trả tiền cho phần cứng không có trên menu của cloud provider.

Scale ngang (horizontal) là thêm nhiều máy chia tải. Trần ở đây là chi phí phối hợp: các máy phải đồng thuận về data, điều hướng traffic giữa nhau, fail over khi một con chết. Tier web stateless scale ngang gần như miễn phí; database stateful thì không.

Bậc thang thực dụng cho service .NET: scale dọc tier web trước (đi từ 4 lên 16 vCPU trên App Service plan); khi một máy không đủ thì thêm replica sau load balancer; khi một database là điểm nghẽn thì thêm read replica; chỉ khi cái đó cũng đầy mới nhìn sang sharding. Mỗi bước rẻ hơn bước tiếp theo; nhảy bước chỉ khi có bằng chứng.

Cần thuộc số nào để suy nghĩ bằng QPS?

Số tròn hữu ích cho ước lượng nhanh:

• 1 RPS = 86,400 req/ngày - service 10 RPS làm ~864K request/ngày, service 100 RPS làm ~8.6M.
• 1 KB row * 1M row = 1 GB - bảng triệu user với vài field mỗi row chỉ ~1 GB, thoải mái nằm trong free tier.
• L1 cache ~1 ns, RAM ~100 ns, SSD ~100 µs, network round-trip ~500 µs LAN / ~50 ms internet - khoảng cách bảy bậc giữa RAM và mạng là lý do cache tồn tại.
• Một node Postgres ~5K-20K write/s - tuỳ kích thước row, độ bền, cấu hình fsync. Nếu thiết kế cần 100K write/s thì bạn đã vào lãnh địa của chương 5.

Chương 2 (back-of-envelope) luyện những con số này nghiêm túc.

SLI, SLO, SLA quan hệ với nhau ra sao?

Ba vòng tròn lồng nhau, dung sai từ nhỏ đến lớn:

• SLI (indicator) - metric thực sự đo. "Tỉ lệ thành công của POST /checkout, cửa sổ 5 phút". Một số, lấy mẫu liên tục.
• SLO (objective) - mục tiêu nội bộ trên SLI ấy. "99.9% trong 30 ngày". Đây là cái team tối ưu cho.
• SLA (agreement) - cam kết bên ngoài, thường kèm khoản refund. "Uptime tháng >= 99.5%, nếu không trả khách 10%". Luôn yếu hơn SLO để có biên.

Số học: 99.9% trong 30 ngày = 43 phút downtime cho phép. 99% = 7.2 giờ. Phép tính căng nhanh. Hai sự cố hai giờ trong một quý đã thổi bay SLO 99.9%. Kỷ luật viết SLO ra giấy ép cuộc trò chuyện trung thực về tính năng nào xứng đáng thêm số 9 và tính năng nào có thể xuống cấp được.

Bộ từ vựng này trông ra sao trong service .NET thật?

Một service ASP.NET Core đơn giản lộ cả bộ từ điển trong một lệnh qua dotnet-counters:

// Chạy từ command line trên instance đã deploy:
// dotnet-counters monitor --process-id <pid>
//   System.Runtime
//   Microsoft.AspNetCore.Hosting
//   Microsoft.AspNetCore.Server.Kestrel

// Bạn sẽ thấy live, mỗi giây:
//   - requests-per-second                    (throughput / QPS)
//   - current-requests                       (N theo Little's Law)
//   - request-duration histogram             (phân phối latency)
//   - cpu-usage, working-set, gc-pause-ms    (tín hiệu quá tải)
//   - active-connections, queued-requests    (back-pressure Kestrel)

Mọi chương trong series đều trích một trong các tín hiệu này. Chương rate limit chặn QPS; chương observability xuất chúng sang Prometheus; chương circuit breaker phản ứng khi chúng vượt ngưỡng. Biết các từ nghĩa là hiểu các chương ấy làm gì với các từ.

Khi nào bộ từ vựng này không còn hữu ích?

Hai trường hợp.

Một, khi bạn còn ở giai đoạn prototype: cụ thể về p99 là phí công trong khi schema còn đổi mỗi tuần. Dùng trung bình và "thấy nhanh / thấy chậm" cho đến khi traffic là thật.

Hai, cho workload batch / ETL nơi tổng thời gian job quan trọng hơn latency từng request. Báo p99 cho job Spark đêm là sai trục - đúng trục là thời gian job và chi phí mỗi row. Phần lớn service .NET trong series là interactive request/response, nên cách suy nghĩ percentile áp dụng được; chương 23 (analytics events pipeline) là chỗ duy nhất metric batch chiếm ưu thế.

Đi tiếp đâu từ đây?

Chương kế tiếp: ước lượng nhanh back-of-envelope - biến từ điển này thành con số bạn vẽ được trên bảng. Sau đó, CAP và consistency giới thiệu bộ từ vựng thứ hai điều khiển mọi quyết định database trong series.