System Design — Bài 5: Performance và availability: đo đúng, tối ưu đúng

Request mất 100 ms nhưng phần code bạn định tối ưu chỉ chiếm 3 ms. Làm đoạn đó nhanh gấp đôi chỉ tiết kiệm 1,5 ms. Để cải thiện trải nghiệm rõ rệt, phải nối số đo của từng thành phần với thời gian và tỉ lệ thành công của cả request.

Khóa học System Design: mục lục 21 bài — bạn đang đọc bài 5.

Đo cái gì, và đặt mục tiêu thế nào

Latency là thời gian một công việc mất để hoàn thành. Throughput là số công việc hoàn thành trong một đơn vị thời gian. Gom nhiều thao tác thành batch có thể tăng throughput nhưng làm công việc đầu tiên phải chờ lâu hơn.

Giá trị trung bình có thể che nhóm người dùng gặp trải nghiệm tệ. Nếu p99 là 250 mili giây, nghĩa là trong tập đo có khoảng 99 phần trăm request không vượt mức đó. Ta còn phải chỉ rõ endpoint, tải, khoảng thời gian và có tính request lỗi hay không.

Một mục tiêu hữu ích có dạng: ở 10.000 request mỗi giây với workload đã mô tả, p99 dưới mức đã chốt và tỉ lệ lỗi dưới ngưỡng. Tăng throughput bằng cách từ chối nhiều request thì chưa chắc đạt mục tiêu người dùng.

Tối ưu là một quá trình, không phải một bước

Giả sử request mất 100 mili giây, trong đó app xử lý ba mili giây và chờ database 97 mili giây. Dù làm phần app nhanh gấp đôi, tổng thời gian chỉ giảm một chút. Vì vậy phải xác định phần đóng góp lớn nhất trước.

Quy trình là đo baseline, đặt giả thuyết, thay đổi có giới hạn rồi đo lại với workload tương đương. Nếu thêm index, kiểm tra cả đọc nhanh hơn bao nhiêu, ghi chậm đi bao nhiêu và dung lượng tăng thế nào. Mỗi lần sửa có thể làm bottleneck chuyển sang chỗ khác.

Khi đạt mục tiêu với mức dự phòng phù hợp, có thể dừng. Tối ưu thêm luôn có chi phí phát triển, độ phức tạp và rủi ro. Chúng ta tối ưu cho mục tiêu nghiệp vụ, không theo đuổi một con số đẹp vô hạn.

Tuning theo loại tải

Với CPU-bound, CPU liên tục làm việc: nén dữ liệu, tính toán hoặc xử lý ảnh. Ta cần profiling để biết hàm nào tốn thời gian, rồi cải thiện thuật toán hoặc chia công việc. Thêm quá nhiều thread vượt số core không tự tạo thêm năng lực tính toán.

Với I/O-bound, thời gian phần lớn nằm ở chờ database, mạng hoặc ổ đĩa. Có thể giảm số lần gọi, gom batch hoặc dùng mô hình bất đồng bộ để tận dụng thời gian chờ. Tuy nhiên số kết nối xuống database vẫn cần giới hạn.

Ước lượng thread pool từ số core và tỉ lệ thời gian chờ/làm việc là điểm khởi đầu cho mô hình worker truyền thống, không phải cấu hình cố định cho mọi runtime. Virtual thread hay event loop thay đổi chi phí chờ nhưng không xóa giới hạn của hệ thống phía sau. Cuối cùng vẫn phải đo dưới tải đại diện.

Bottleneck nằm ở đâu

CPU cao có thể do tính toán thật hoặc chuyển ngữ cảnh quá nhiều. CPU thấp chưa có nghĩa hệ thống khỏe: request có thể đang đợi lock, connection pool hoặc I/O. Bộ nhớ cần xem cả dung lượng, tốc độ cấp phát và thời gian dọn rác.

Với disk, quan sát độ trễ và hàng đợi ngoài số thao tác mỗi giây. Với network, xem kích thước payload, số vòng gọi và thời gian chờ. Tracing giúp nối các đoạn đó thành đường đi của một request, còn metric tổng thể cho biết vấn đề xuất hiện khi nào.

Ví dụ 730 request mỗi giây và thời gian trung bình một phần mười giây cho khoảng 73 request trong hệ thống. Nếu thực tế hàng đợi tăng liên tục, điều kiện ổn định đã không còn; cần giảm tải hoặc tăng năng lực xử lý.

Availability — đo và giữ

Availability có thể cải thiện bằng cách làm hệ ít hỏng hơn hoặc phục hồi nhanh hơn. Vì vậy rollback tự động, phát hiện lỗi sớm và thao tác phục hồi đã luyện tập có giá trị kiến trúc rõ ràng.

Nếu hai thành phần bắt buộc nối tiếp có độ khả dụng 99,9 và 99,5 phần trăm, dưới giả định lỗi độc lập, độ khả dụng chung là tích của hai số: khoảng 99,4 phần trăm. Thêm phụ thuộc vào đường chính có thể làm giảm kết quả chung.

Với phương án dự phòng, xác suất cả hai cùng hỏng quyết định mức cải thiện. Công thức 1 − (1 − P) × (1 − F) giả định hai nhánh độc lập và cùng tiêu chí thành công. Hai service dùng chung database hoặc cùng nguồn điện không thỏa giả định đó. Fallback trả nội dung rỗng cũng chưa chắc được tính là thành công theo yêu cầu nghiệp vụ.

Ba phép tính để kiểm tra trực giác

Little's Law, trong trạng thái ổn định:
L = throughput x thời gian trung bình
  = 730 request/s x 0,1 s = 73 request in-flight

Hai phụ thuộc bắt buộc, giả định lỗi độc lập:
A = 0,999 x 0,995 = 0,994005 = 99,4005%

Fallback, lỗi độc lập và cùng tiêu chí thành công:
A = 1 - (1 - 0,995) x (1 - 0,9999)
  = 99,99995%

73 request in-flight không đồng nghĩa 73 OS thread. Công thức availability cũng không áp dụng trực tiếp nếu hai nhánh dùng chung một database, mạng hoặc nguồn điện. Queue nhận công việc và DB hoàn tất nghiệp vụ là hai tiêu chí thành công khác nhau.

Thuật ngữ cần nhớ

• SLO — Service Level Objective: Mục tiêu mức dịch vụ, ví dụ 99,9% request thành công hoặc 99% request dưới 250 ms trong cửa sổ đo xác định.

• MTBF — Mean Time Between Failures: Thời gian trung bình giữa các lần hỏng trong mô hình độ tin cậy; trong phép tính khả dụng đơn giản của bài, dùng thời gian hoạt động trung bình giữa các lần hỏng.

• MTTR — Mean Time To Repair/Restore: Thời gian trung bình để sửa hoặc khôi phục dịch vụ sau sự cố; phải thống nhất thời điểm bắt đầu/kết thúc khi đo.

• CPU — Central Processing Unit: Bộ xử lý trung tâm; CPU-bound là tải bị giới hạn chủ yếu bởi thời gian tính toán.

• I/O — Input/Output: Vào/ra: trao đổi dữ liệu với đĩa, mạng hoặc thiết bị; I/O-bound là tải dành nhiều thời gian chờ các thao tác này.

Bài tập tự thực hành

Hai phụ thuộc bắt buộc đều đạt 99,9%; tính composite availability.

Gợi ý kiểm tra lời giải

Khoảng 99,8001% nếu độc lập; thảo luận lỗi tương quan và định nghĩa thành công.

Tự kiểm tra sau bài học

• Đo throughput hoàn thành cùng latency và tỉ lệ lỗi.

• So sánh baseline với cùng workload sau mỗi thay đổi.

• Kiểm tra lỗi tương quan và định nghĩa thành công khi tính availability.

Đọc thêm từ tài liệu gốc

AWS Well-Architected: Availability

Tiếp tục lộ trình

Bài trước — Scalability: mở rộng hệ thống từ đúng điểm nghẽn

Bài tiếp — Đường đi của request: DNS, CDN, Load Balancer và Gateway

Xem toàn bộ khóa học System Design 21 bài