Harbor

Máy tính hạ tầng

Nhập số người dùng và thói quen sử dụng, máy tính ước lượng số instance API, cấu hình database, read replica, RAM Redis, lưu trữ, băng thông và mức hạ tầng phù hợp.

6 phút đọcHạ tầng theo quy mô

Cách dùng

Nhập số người dùng hoạt động mỗi ngày (DAU), số request mỗi người, hệ số đỉnh, tỉ lệ ghi, tỉ lệ hit cache và kích thước dữ liệu. Máy tính trả về số instance API, cấu hình database, số read replica, RAM Redis, dung lượng lưu trữ, băng thông và gợi ý mức hạ tầng. Số mẫu ban đầu là kịch bản 1 triệu DAU dùng trong bài Chọn server. Mọi kết quả là ước lượng.1

Máy tính hạ tầng

Gợi ý mức
Mức 2 · Tăng trưởng: API tự scale sau load balancer, Redis, queue, CDN, Postgres có replica.
Request trung bình347,2 /s
Request lúc đỉnh1.736,1 /s
Ghi / đọc lúc đỉnh173,6 / 1.562,5 /s
Request xử lý cùng lúc (L = λ × W)104,2
API Node.js 2 vCPU · 4 GB3 instance · 6 vCPU · 12 GB RAM
Tải xuống database sau cache408 truy vấn/s
Cấu hình database4 vCPU · 16 GB · Primary + standby ở zone khác
Read replica gợi ý0–1
Redis2,86 GB RAM · 1.736 thao tác/s
Lưu trữ mỗi năm / 3 năm1,1 TB / 3,29 TB
Băng thông ra lúc đỉnh69,4 Mbps

Công thức

Máy tính dùng đúng các quy tắc của khoá học (quy tắc ước lượng của khoá học, xem Chọn server).2 Ba phép tính cơ bản có cùng cách làm với Grokking ch.5: request mỗi giây bằng DAU nhân số request chia 86.400 giây; lưu trữ bằng số ghi nhân kích thước nhân số ngày; băng thông bằng dung lượng chia 86.400 giây rồi nhân 8 để đổi byte sang bit.3

avg       = DAU × request mỗi người ÷ 86.400
peak      = avg × hệ số đỉnh
ghi       = peak × tỉ lệ ghi;   đọc = peak − ghi
đồng thời = peak × thời gian xử lý (s)         (định luật Little)
instances = max(2, ceil(peak ÷ 600))           mỗi máy 2 vCPU · 4 GB
DB load   = ghi + đọc × (1 − tỉ lệ hit)
replicas  = ceil(đọc sau cache ÷ 3.000)
Redis RAM = số item × (kích thước + 100 B) × 1,3
lưu trữ   = DAU × request × tỉ lệ ghi × kích thước ghi × 365   (mỗi năm)
băng thông = peak × kích thước response × 8                     (bit/s)

Số 600 đến từ năng lực ước lượng 1.000 req/s của máy 2 vCPU · 4 GB, chỉ cho chạy tối đa 60% (quy tắc ước lượng của khoá học, không phải số trong sách).2 Grokking ch.5 cũng chỉ ra rằng RPS một server phụ thuộc loại tải và nhiều yếu tố khác nên chỉ nên dùng làm cận trên hợp lý.1 Máy tính không cộng máy dự phòng N+1, bạn tự cộng khi trình bày. Định luật Little (đồng thời = tốc độ × thời gian xử lý) chưa có nguồn trong thư viện.4

Cấu hình database theo tải sau cache (quy tắc ước lượng của khoá học, tham chiếu Grokking ch.5: một MySQL đơn lẻ khoảng 1.000 QPS và key-value store khoảng 10.000 QPS, rất thay đổi theo truy vấn và máy):25

DB loadCấu hình gợi ý
< 300 q/s2 vCPU · 8 GB, một instance, backup tự động
< 1.500 q/s4 vCPU · 16 GB, primary + standby ở zone khác
< 4.000 q/s8 vCPU · 32 GB, primary + standby + 1–2 read replica
< 15.000 q/s16 vCPU · 64 GB, primary + 2–3 read replica, ghi nặng qua queue
≥ 15.000 q/sNhiều node: sharding hoặc DB phân tán

Mức hạ tầng:

  • Mức 1: DAU ≤ 50.000 và đỉnh < 300 req/s.
  • Mức 2: đỉnh < 20.000 req/s.
  • Mức 3: còn lại.

Redis được đánh dấu cần Cluster khi thao tác lúc đỉnh vượt khoảng 80.000/s, tức 80% của mốc khoảng 100.000 thao tác/s một node.26 Mô tả từng mức ở bài Hạ tầng theo quy mô.

Ví dụ

Số mẫu (giả định của khoá học, dùng quy tắc ở trên):2 1 triệu DAU, 30 request/người, đỉnh ×5, 10% ghi, mỗi ghi 1.000 B, lưu 3 năm, hit 85%, xử lý 60 ms, response 5 KB, 2 triệu item nóng mỗi item 1.000 B.

BướcTínhKết quả
Trung bình1.000.000 × 30 ÷ 86.400≈ 347 req/s
Đỉnh347 × 5≈ 1.736 req/s
Ghi / đọc10% / 90%≈ 174 / 1.562 req/s
Đồng thời1.736 × 0,06≈ 104 request
APImax(2, ceil(1.736 ÷ 600))3 instance · 6 vCPU · 12 GB
DB load174 + 1.562 × 0,15≈ 408 q/s
Database300 ≤ 408 < 1.5004 vCPU · 16 GB, primary + standby
Read replicaceil(234 ÷ 3.000) = 10–1
Redis2.000.000 × 1.100 × 1,3≈ 2,9 GB, ~1.736 thao tác/s
Lưu trữ1.000.000 × 30 × 0,1 × 1.000 × 365≈ 1,1 TB/năm, ≈ 3,3 TB/3 năm
Băng thông1.736 × 5 KB × 8≈ 69 Mbps
MứcDAU > 50.000, đỉnh < 20.000Mức 2

Khi trình bày, cộng một máy dự phòng: 4 instance API.

Giới hạn

  • Năng lực 1.000 req/s mỗi máy và 3.000 truy vấn đọc mỗi replica là giả định thận trọng của khoá học cho API I/O-bound đơn giản.2 Endpoint nặng có thể thấp hơn nhiều: Grokking ch.5 nêu tác vụ xử lý ảnh có thể chỉ đạt tối đa 50 RPS trong khi server phục vụ nội dung tĩnh từ RAM có thể đạt 500 nghìn RPS.7
  • Máy tính không tính phần việc CPU-bound (xử lý ảnh, video), WebSocket, tìm kiếm hay phân tích dữ liệu.
  • Chi phí và cấu hình thật phụ thuộc nhà cung cấp và truy vấn của bạn.1

Lưu ý: Trước khi mua hạ tầng thật, load test một instance với dữ liệu cỡ production, đo năng lực thật, rồi thay con số 600 trong công thức. Cách làm có ở bài Chọn server, dựa trên mục Performance Tests của Building Microservices: tăng dần tải, môi trường và dữ liệu giống production.8

Nguồn trích dẫn

  1. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · bài "Examples of Resource Estimation", mục "Number of servers required" (ở mức thiết kế, ước lượng thô là phù hợp vì mục đích là tìm cận trên hợp lý). ↩ ↩2 ↩3

  2. Quy tắc ước lượng của khoá học, xem bài Chọn server. Không phải số liệu trích từ sách; cần load test với ứng dụng thật. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  3. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · bài "Examples of Resource Estimation", các mục "Number of servers required", "Storage requirements" và "Bandwidth requirements". ↩

  4. Lý thuyết · Định luật Little: trong hệ thống ổn định, số yêu cầu đang xử lý trung bình L bằng tốc độ đến λ nhân thời gian ở lại trung bình W, tức L = λ × W. Ví dụ λ = 470 req/s và W = 0,08 s thì L = 470 × 0,08 ≈ 38 request cùng lúc; mỗi instance xử lý được c request đồng thời thì cần ít nhất L ÷ c instance, rồi chia thêm cho 0,6 để chừa chỗ cho đỉnh. Định luật đúng cho mọi hàng đợi ổn định, không phụ thuộc phân phối thời gian đến hay thời gian xử lý, nên dùng được để kiểm tra chéo kết quả ước lượng. ↩

  5. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · bài "Put Back-of-the-envelope Numbers in Perspective", mục "Standard numbers to remember", bảng "Important Rates". ↩

  6. Redis in Action · ch.6 Application components in Redis · §6.2 Distributed locking › 6.2.2 Simple locks (tr. 120–121; Redis thực hiện 100.000 thao tác/s trên phần cứng gần đây). ↩

  7. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · bài "Put Back-of-the-envelope Numbers in Perspective", mục "Requests estimation" (đoạn cuối). ↩

  8. Building Microservices (Sam Newman) (file .zip, tải về giải nén) · ch.7 Testing · mục "Performance Tests" (tr. 152–153). ↩

Đọc thêm trong thư viện
Grokking · ch.5 Back-of-the-envelope Calculations ↗Building Microservices · ch.7 Testing ↗Redis in Action · ch.6 ↗