Thiết kế hệ thống - ước lượng tải, load balancer, cache, queue, replication và partitioning

Hệ thống của bạn cần những thành phần nào, và cần thêm từ lúc nào? Developer backend nào cũng gặp câu hỏi này khi sản phẩm bắt đầu có người dùng thật. Câu trả lời nằm ở requirement, tải cao điểm và constraint của chính hệ thống đó, nên khoá học đi từ những đầu vào này tới kiến trúc, rồi tới cách tìm bottleneck và so sánh phương án.

1. 01Viết requirement bằng số liệu — Bạn phân biệt functional requirement, non-functional requirement và constraint, rồi biến những yêu cầu chung chung về tốc độ và độ ổn định thành số liệu đo được: SLO, error budget, RPO và RTO.
2. 02Ước lượng trước khi dựng hệ thống — Từ tải cao điểm theo từng phút, tỉ lệ đọc/ghi và payload, bạn ước lượng nhanh dung lượng lưu trữ, băng thông và số instance cần chạy, chừa headroom và ghi rõ từng giả định để sau này đối chiếu với metric thật.
3. 03Chỉ định nơi giữ dữ liệu gốc — Bạn chọn source of truth cho từng loại dữ liệu và bảo đảm cache, search index hay bảng báo cáo đều dựng lại được từ đó.
4. 04Chọn thành phần theo triệu chứng đo được — Với load balancer, cache, queue, read replica, partition, object storage và CDN, bạn biết lúc nào cần đến từng thành phần, nó cải thiện được số liệu nào và đi kèm tradeoff gì.
5. 05Tìm bottleneck trước khi thêm máy — Bạn xem utilization, saturation và errors ở từng chặng trên request path để tìm tài nguyên bão hòa sớm nhất, rồi chỉ ra lỗi ở một thành phần sẽ lan ra những đâu.
6. 06So sánh phương án và ghi lại quyết định — Bạn thiết lập hai phương án từ cùng một đầu vào thiết kế, so sánh theo latency, chi phí mỗi tháng, số thành phần phải vận hành và failure mode, rồi ghi quyết định cùng phương án bị loại vào ADR (Architecture Decision Record, bản ghi quyết định kiến trúc).

• Tăng số instance của app từ 3 lên 6, throughput vẫn giữ ở 1.200 request/giây còn p99 tăng từ 180 ms lên 650 msCPU của Postgres primary đã gần chạm giới hạn, nên thêm instance app chỉ dồn thêm truy vấn vào đúng chặng đang bão hòa.
• Dashboard báo trung bình 40 request/giây nhưng nginx trả 502 lúc 20:00 mỗi tốiSố trung bình theo ngày che mất 3 phút tải tăng lên 900 request/giây sau mỗi lần gửi push notification khuyến mãi, gấp ba mức app chịu được.
• Benchmark đạt 2.000 request/giây nên một instance được coi là dư sức cho 500 request/giâyBenchmark đo trên /health với 5 ms mỗi request, còn API chat mất 80 ms nên mỗi instance chỉ chịu khoảng 125 request/giây.

1. 01Bắt đầu từ triệu chứng thật— Bài nào cũng mở bằng một dashboard, một đoạn log hay một hóa đơn cloud có số liệu cụ thể; thành phần hay khái niệm chỉ xuất hiện khi bạn đã thấy nó giải quyết triệu chứng nào.
2. 02Phép tính kèm hình vẽ— Các phép tính đều ghi rõ đơn vị và giả định, còn ảnh minh họa vẽ request path, chỗ giữ state, chặng bão hòa và thành phần được thêm vào sau khi sửa.
3. 03Quiz ở các bài cần tính toán— Các bài về cách đọc dashboard, workload, ước lượng, sáu thành phần, bottleneck và cách lỗi lan ra có quiz ngắn, trong đó nhiều câu yêu cầu bạn làm phép tính trước khi chọn đáp án.
4. 04Áp dụng cho hệ thống của bạn— Phần lớn các bài khép lại bằng một bài tập trên hệ thống bạn đang có: vẽ request path, lập bảng constraint, viết hai dòng SLO hay một ADR.
5. 05Ba demo kit chạy bằng Docker— Mỗi bài tình huống kèm một kit để coding agent của bạn dựng lại hệ thống trên laptop, chạy k6 ở mức tải cố định và cho bạn thấy triệu chứng của bài; khi bạn yêu cầu, agent áp dụng cách xử lý mà bài trình bày rồi chạy lại cùng kịch bản để so sánh.

1. 01

   Request đi qua những đâu, state nằm ở đâu và đọc dashboard thế nào

   Bài nền đưa ra cách vẽ hệ thống mà cả khoá học dùng chung: request path đi từ client tới database, mọi chỗ đang giữ state được đánh dấu riêng. Bạn phân biệt tầng stateless với tầng stateful, chuyển session ra một nơi lưu chung để có thể thêm instance app an toàn, và thấy app stateless không có nghĩa là state đã biến mất khỏi hệ thống. Chặng nào trên request path cũng có thể chậm hoặc hỏng, nên các bài sau đều quay lại hình vẽ này.

   Bài thứ hai mở bằng một dashboard có ba panel đều xanh, trong khi chỉ trong một phút đã có 90 lần bấm đặt hàng nhận lỗi 503. Bạn đọc latency theo p50, p95 và p99 thay cho số trung bình, vì trong gần 18.000 request thành công của phút đó, 180 request chờ khoảng 2,5 giây chỉ kéo số trung bình từ 100 ms lên 124 ms. Throughput cần được đọc cùng latency, vì API xử lý xong nhiều request hơn chưa chắc khách đã chờ ít hơn.

   Error rate thì phải được tính trên request của đúng thao tác cần theo dõi: cùng 90 lỗi, chia cho mọi request của API thì được 0,5%, chia riêng cho request đặt hàng thì được 7,5%. Cuối bài, bạn phân biệt utilization với saturation: CPU mới 45%, nhưng connection pool đã dùng hết và khoảng 25 request đang xếp hàng chờ connection.

2. 02

   Các loại requirement và cách biến chúng thành số liệu

   API xuất hóa đơn PDF qua hết mười hai test chức năng, nhưng tối ngày cuối tháng p99 của nó tăng lên 40 giây, vì chưa ai hỏi có bao nhiêu cửa hàng sẽ xuất hóa đơn cùng lúc. Từ tình huống đó, bạn phân biệt functional requirement, non-functional requirement và constraint (ngân sách, team, công nghệ sẵn có). Nhóm bài cũng đưa ra tám câu hỏi về non-functional requirement nên hỏi trước khi thiết kế.

   Ở trang thanh toán, yêu cầu mơ hồ về tốc độ và độ ổn định được viết lại thành hai dòng SLO: với SLO 99,9% trong 30 ngày, chỉ 15 phút sập vào giờ cao điểm đã dùng hết error budget của cả tháng. Phần cuối nhóm trình bày RPO, RTO và cách xếp ưu tiên khi hai requirement mâu thuẫn nhau.

3. 03

   Mô tả workload, ước lượng nhanh và xác định dữ liệu gốc

   Bạn mô tả workload bằng tải cao điểm theo từng phút, burst, tỉ lệ đọc/ghi, payload và tốc độ tăng của tải và dữ liệu, lấy từ access log thay vì dựa vào số trung bình theo ngày. Phần ước lượng nhanh (back-of-the-envelope) tính dung lượng lưu trữ và băng thông cho một tính năng chat chưa ra mắt, rồi dùng Little’s Law để chọn số instance: với cùng 500 request/giây, khi mỗi request mất 400 ms thay vì 80 ms, số request đang xử lý cùng lúc tăng gấp năm lần. Bài cuối nhóm trình bày cách xác định source of truth cho từng loại dữ liệu, để cache, search index hay bảng báo cáo luôn dựng lại được từ đó.

4. 04

   Các thành phần cơ bản: khi nào cần và tradeoff

   Sáu bài, mỗi bài một thành phần, cùng xét ba điểm: khi nào cần, cải thiện được số liệu nào và tradeoff là gì. Load balancer chia tải và loại instance đã chết khỏi danh sách nhận request, nhưng tự nó có thể trở thành single point of failure. Với cache-aside và hit ratio 88%, CPU của Postgres giảm từ 85% xuống khoảng 16%, đổi lại người dùng có thể thấy dữ liệu cũ trong khoảng thời gian TTL.

   Queue đưa việc gửi email ra khỏi request đăng ký; read replica nhận những truy vấn đọc mà dữ liệu cũ vài giây vẫn chấp nhận được; partition theo ngày thay job xóa dữ liệu cũ chạy suốt đêm bằng một câu lệnh drop partition. Bài về object storage và CDN đưa ra một kết quả nhiều người không ngờ: khi CDN phục vụ 95% số byte ảnh, chi phí băng thông chỉ giảm khoảng 28%, còn thời gian backup database được rút ngắn từ 5 giờ xuống khoảng 30 phút.

5. 05

   Hệ thống lớn lên theo từng nấc

   Một cửa hàng online nhỏ chạy tám tháng đầu chỉ với một app và một Postgres, tới năm thứ ba đã có bảy thành phần, và hóa đơn hạ tầng tăng từ khoảng 3 triệu đồng lên 24 triệu đồng mỗi tháng. Ở mỗi nấc, bạn thấy triệu chứng đo được nào báo hiệu đã tới lúc lên nấc, thành phần nào được thêm vào và vì sao, cùng những thành phần chưa cần dù hay xuất hiện trong sơ đồ của các hệ thống lớn.

   Nhóm kết thúc bằng bài tình huống về dịch vụ rút gọn link: một link chiến dịch bị share mạnh làm p99 của redirect tăng từ 12 ms lên 1,8 giây. Từ requirement và bản ước lượng tải, bạn đặt cache trước database để đưa p99 về dưới 50 ms, rồi so sánh hai cách sinh mã ngắn không trùng nhau.

6. 06

   Tìm bottleneck và xem lỗi lan ra như thế nào

   Bottleneck đầu tiên là tài nguyên bão hòa sớm nhất trên request path, và thêm tài nguyên ở chỗ khác không làm throughput tăng. Bạn tìm nó bằng cách xem utilization, saturation và errors ở từng chặng, rồi ước lượng throughput tối đa mà tài nguyên đó chịu được để biết bottleneck sẽ chuyển sang đâu sau khi sửa.

   Bài tiếp theo giải thích vì sao lỗi ở một service phụ lan sang cả những endpoint không gọi tới nó, và cách tính availability khi request phải đi qua nhiều thành phần nối tiếp hoặc khi một tầng có instance dự phòng. Trong ví dụ, số phút tầng app không dùng được mỗi tháng giảm từ khoảng 216 phút xuống khoảng 1 phút chỉ nhờ thêm một instance. Ở bài tình huống cuối nhóm, bạn lần ngược từ một triệu chứng lặp lại đúng giờ mỗi sáng để tìm ra tài nguyên mà API đặt hàng và job báo cáo đang dùng chung, rồi chuyển báo cáo sang một replica riêng và partition bảng orders theo tháng.

7. 07

   Thiết lập, so sánh phương án và ghi lại quyết định thiết kế

   Khách gõ sai chính tả thì trang tìm kiếm không trả về sản phẩm nào. Từ cùng requirement, constraint và workload, bạn thiết lập hai phương án thật sự khác nhau: tìm gần đúng ngay trong Postgres bằng extension trigram, hoặc thêm Elasticsearch đồng bộ dữ liệu từ Postgres.

   Bảng so sánh thay những dòng ưu nhược điểm chung chung bằng giá trị đo ở cùng một workload: latency, chi phí mỗi tháng, số thành phần phải vận hành, failure mode và độ trễ đồng bộ. Quyết định được ghi vào ADR cùng bối cảnh có số liệu, phương án bị loại và điều kiện xem lại, để một năm sau team không phải mất hai tuần đo lại từ đầu. Bài tình huống cuối khoá thêm một đợt flash sale với tải dự kiến 8.000 request/giây vào cửa hàng đang chạy ổn ở 200 request/giây, và bạn so sánh hai kiến trúc ghép từ những thành phần đã học bằng cùng một kịch bản load test k6.

1. 01Dấu hiệuTăng số instance của app từ 3 lên 6, throughput vẫn giữ ở 1.200 request/giây còn p99 tăng từ 180 ms lên 650 msThực raCPU của Postgres primary đã gần chạm giới hạn, nên thêm instance app chỉ dồn thêm truy vấn vào đúng chặng đang bão hòa.
2. 02Dấu hiệuDashboard báo trung bình 40 request/giây nhưng nginx trả 502 lúc 20:00 mỗi tốiThực raSố trung bình theo ngày che mất 3 phút tải tăng lên 900 request/giây sau mỗi lần gửi push notification khuyến mãi, gấp ba mức app chịu được.
3. 03Dấu hiệuBenchmark đạt 2.000 request/giây nên một instance được coi là dư sức cho 500 request/giâyThực raBenchmark đo trên /health với 5 ms mỗi request, còn API chat mất 80 ms nên mỗi instance chỉ chịu khoảng 125 request/giây.
4. 04Dấu hiệuChạy app trên ba instance thay vì một, instance nào cũng dưới 40% CPU mà người dùng liên tục bị đăng xuấtThực raSession nằm trong RAM của từng instance, và load balancer gửi request tới instance không có session đó.
5. 05Dấu hiệuCheckout trả 504 trong khi CPU của app mới 15%Thực raLatency của service gợi ý sản phẩm tăng từ 40 ms lên 8 giây, trang chi tiết sản phẩm gọi nó đồng bộ và giữ hết 200 thread của app trong lúc chờ.
6. 06Dấu hiệuĐúng 8:00 mỗi sáng, p99 của API đặt hàng tăng từ 80 ms lên 2,5 giây dù số request mỗi giây không đổiThực raJob báo cáo doanh thu quét bảng orders trên cùng Postgres primary và tranh chấp đĩa với API đặt hàng.
7. 07Dấu hiệuSearch index và bảng báo cáo lệch với Postgres sau một sự cố đồng bộ, không ai nói được bản nào đúngThực raTeam chưa chỉ định source of truth cho từng loại dữ liệu, nên không ai biết phải dựng lại các bản dẫn xuất từ đâu.