System Design — Bài 3: Ước lượng capacity và phân tích trade-off
Ước lượng hữu ích khi nó thay đổi một quyết định: cần cache bao nhiêu, có phải chia dữ liệu hay chưa, hoặc đường ghi có đủ headroom không. Ta dùng URL Shortener để luyện cách tính, rồi xem việc tách trách nhiệm có thể giảm một đánh đổi như thế nào.
Khóa học System Design: mục lục 21 bài — bạn đang đọc bài 3.
Ước lượng để làm gì, và ước lượng thế nào
Ước lượng giúp phân biệt một bài toán vài chục request mỗi giây với một bài toán hàng trăm nghìn. Nó cũng giúp nhận ra bottleneck có thể nằm ở dung lượng, tốc độ ghi hay số kết nối đồng thời.
Ta chia bài toán thành các phần nhỏ: người dùng hoạt động, số thao tác mỗi người, kích thước dữ liệu và thời gian lưu. Tính riêng rồi ghép lại. Khi thiếu dữ liệu, hãy nói rõ giả định và thử xem kết quả thay đổi thế nào nếu giả định tăng gấp đôi.
Mức dự phòng 20% chỉ là ví dụ, không phải mức đủ cho mọi hệ thống. Nếu một máy trong cụm chết hoặc traffic tăng mười lần, cần headroom khác. Tương tự, quy tắc tám mươi 20 là giả thuyết về phân bố truy cập; phải đo hot set trước khi dùng nó để mua bộ nhớ.
Các con số cần thuộc lòng
Về dung lượng, kiểu số 32 bit thường cần bốn byte dữ liệu thô. Nhưng một bản ghi trong database còn có tên trường hoặc metadata, index và overhead của storage engine. Chuỗi UTF-8 có số byte biến đổi; số ký tự nhìn thấy không tự suy ra số byte.
Về latency, cần phân biệt bậc độ lớn của truy cập bộ nhớ, ổ đĩa và mạng xa. Đây là mốc minh họa; phần cứng, kích thước thao tác và hàng đợi có thể thay đổi kết quả. Ý nghĩa thiết kế là tránh đặt nhiều thao tác chậm nối tiếp trên đường người dùng phải chờ.
Về availability, một phần trăm downtime trong một năm tương đương hơn ba ngày. Bốn số chín còn khoảng 52 phút. Mỗi mục tiêu cao hơn cần được gắn với chi phí và cách đo, thay vì chọn nhiều số chín cho đẹp.
Mẹo tính nhanh
Luôn viết đơn vị sau con số. Mười triệu request mỗi ngày chia 100.000 giây mỗi ngày cho khoảng 100 request mỗi giây. Nếu bỏ đơn vị, rất dễ nhầm megabyte mỗi giây với megabit mỗi giây.
Little's Law cho biết trong trạng thái ổn định, số công việc trung bình đang ở trong hệ thống bằng tốc độ công việc đi qua nhân thời gian trung bình ở trong đó. Một nghìn request mỗi giây, mỗi request ở lại một phần mười giây, tương đương 100 request đang xử lý hoặc chờ trung bình. Đây không phải công thức tính trực tiếp số thread, vì một thread có thể phục vụ nhiều thao tác bất đồng bộ.
Quy tắc 70 hai ước lượng thời gian gấp đôi khi tăng trưởng lãi kép: tăng 24 phần trăm mỗi năm thì khoảng ba năm gấp đôi. Nó giúp hình dung xu hướng; kế hoạch capacity vẫn phải kiểm tra các kịch bản cụ thể.
Bài mẫu — ước lượng URL Shortener
Giả sử mỗi ngày tạo 10 triệu đường dẫn và lượt đọc gấp 100 lần lượt ghi. Dùng 100.000 giây mỗi ngày để làm tròn, ta có khoảng 100 lượt ghi và 10.000 lượt đọc mỗi giây. Đây là trung bình; tải đỉnh cần giả định hoặc số đo riêng.
Mỗi bản ghi 1,1 kilobyte, giữ bốn năm và làm tròn mỗi năm 400 ngày thì dữ liệu gốc là 17,6 terabyte. Ba bản sao thành 52,8 terabyte, chưa tính index, overhead và dung lượng trống phục vụ vận hành.
Nếu hot set bằng 20 phần trăm số URL tạo trong một ngày, phần payload cache là 2,2 gigabyte. TTL một ngày không tự tạo ra giả định đó. Với payload mỗi lượt 1,1 kilobyte, băng thông ghi khoảng 0,11 megabyte mỗi giây, đọc khoảng mười một megabyte mỗi giây. Payload mạng và kích thước bản ghi cũng cần kiểm chứng riêng.
Bản đồ trade-off
Cache dùng thêm bộ nhớ để giảm thời gian đọc, nhưng đưa vào vấn đề dữ liệu cũ. Nén giảm số byte truyền hoặc lưu, nhưng cần thêm xử lý. Đồng bộ nhiều bản sao trước khi báo thành công có thể tăng độ trễ, đổi lại nâng mức bảo đảm mà hệ thống hướng tới.
Với CAP, tình huống cần chú ý là khi các nhóm máy không liên lạc được. Ta không thể vừa bảo đảm mọi thao tác nhìn như đi qua một bản dữ liệu duy nhất, vừa bảo đảm mọi request tới node còn sống đều được phục vụ thành công theo yêu cầu của định lý. Chúng ta sẽ phân tích kỹ ở bài 11.
Không nên biến tên cặp đánh đổi thành khẩu hiệu. Hãy nói cụ thể thành phần nào trả chi phí, người dùng nào chịu ảnh hưởng và trong tình huống nào. Đôi khi thay đổi cách tổ chức có thể giảm đáng kể sự xung đột.
Gỡ trade-off bằng SEPARATION
Separation nghĩa là tách các phần có nhu cầu khác nhau để chúng không buộc phải dùng chung một cách xử lý. Ví dụ, tìm kiếm sản phẩm cần truy vấn linh hoạt còn xác nhận đơn cần giao dịch chặt chẽ. Ta có thể giữ database giao dịch làm nguồn sự thật và xây chỉ mục tìm kiếm riêng.
Tách theo thời gian là chọn cách vận hành phù hợp từng giai đoạn hoặc từng mức tải. Tách theo không gian là để thành phần chuyên biệt phục vụ nhu cầu riêng. Tách bộ phận với tổng thể là cô lập lỗi: phần gợi ý ngừng hoạt động nhưng mua hàng vẫn chạy được.
Tách ra không làm chi phí biến mất. Ta có thể giảm xung đột đọc và ghi nhưng phải xử lý đồng bộ dữ liệu và vận hành thêm thành phần. Câu hỏi đúng là tổng lợi ích có đáng với chi phí mới hay không; các giới hạn cơ bản như CAP vẫn còn.
Bảng tính URL Shortener bằng đơn vị thập phân
Giả định: 10.000.000 URL/ngày; đọc:ghi = 100:1
Tính nhẩm: 100.000 giây/ngày; 400 ngày/năm
Payload: 1,1 KB/bản ghi; lưu 4 năm
Ghi trung bình = 10.000.000 / 100.000 = 100/s
Đọc trung bình = 100 x 100 = 10.000/s
Payload lưu = 10M x 400 x 4 x 1,1 KB = 17,6 TB
3 bản sao = 17,6 x 3 = 52,8 TB
Hot set giả định = 20% x 10M x 1,1 KB = 2,2 GB
Băng thông ghi = 100 x 1,1 KB = 0,11 MB/s
Băng thông đọc = 10.000 x 1,1 KB = 11 MB/sĐây là phép tính nhẩm bảo toàn bậc độ lớn. Một ngày thực có 86.400 giây, nên QPS ghi chính xác hơn là khoảng 116/s. Dung lượng trên chưa có index, metadata, headroom; tải đỉnh và payload response phải được xác định riêng. TTL không tự quyết định hot set.
Thuật ngữ cần nhớ
QPS — Queries Per Second: Số truy vấn mỗi giây; trong bài ước lượng cần nói rõ đang đếm truy vấn dữ liệu hay lượt gọi đọc. Trung bình và đỉnh là hai giá trị khác nhau.
RPS — Requests Per Second: Số request mỗi giây. Little’s Law dùng tốc độ đến và thời gian trong hệ thống để ước lượng số request đang xử lý trung bình.
DAU — Daily Active Users: Số người dùng hoạt động trong một ngày theo định nghĩa của sản phẩm; nhân với số hành động mỗi người để ước lượng tổng request/ngày.
CAP — Consistency, Availability, Partition Tolerance: Nhất quán theo thứ tự thời gian thực; mọi request tới node không lỗi được phản hồi; và khả năng xét hoạt động khi mạng bị chia cắt. Khi partition xảy ra, không thể bảo đảm đầy đủ cả hai thuộc tính đầu theo định nghĩa của định lý.
Bài tập tự thực hành
Tăng lượng tạo URL từ 10M lên 20M/ngày, giữ các giả định khác.
Gợi ý kiểm tra lời giải
Ghi ≈ 200/s, đọc ≈ 20K/s; payload lưu 35,2 TB, ba bản sao 105,6 TB; cache 4,4 GB chỉ khi giữ nguyên giả định hot set.
Tự kiểm tra sau bài học
Mỗi phép tính có đơn vị và giả định làm tròn.
Phân biệt payload với tổng dung lượng vận hành, trung bình với đỉnh.
Mỗi kết quả dẫn tới một quyết định hoặc một phép đo tiếp theo.
Tiếp tục lộ trình
Bài trước — Làm rõ yêu cầu: từ chức năng đến mục tiêu đo được
Site Admin
Engineer and writer. Building things with TypeScript and distributed systems.
Bình luận (0)
Bạn cần đăng nhập bằng Google để bình luận.
Hãy là người bình luận đầu tiên.