Bài 17: Chế Độ Lỗi & Khả Năng Chống Chịu

Bài 16 vừa dựng xong bộ đo. Bài này dùng nó để nhìn một hiện tượng mà nếu chỉ nghe kể thì rất khó tin: hệ thống tự đánh sập chính mình bằng lưu lượng do chính nó sinh ra, sau khi nguyên nhân gốc đã qua từ lâu.

Bốn phép đo của lab. Thứ nhất, một chuỗi ba tầng mà mỗi tầng thử lại ba lần biến 30 request người dùng thành 810 lần đập vào service tận cùng — đúng 27 lần, và không tầng nào làm gì sai cả. Thứ hai, backoff không jitter làm lưu lượng dồn cục gấp 19,6 lần mức trung bình; thêm jitter kéo xuống 5,3 lần. Thứ ba, circuit breaker cắt số lời gọi vào một dependency đang ốm từ 17 xuống 7 và biến 5.291 ms ngồi chờ thành 2.173 ms. Thứ tư, timeout đặt sai chỗ khiến server làm trọn 50.000 ms công toi — 100 phản hồi hoàn chỉnh mà không ai nhận.

17.1 Cascade failure: khi hệ thống tự đánh sập mình

Cơ chế lan truyền luôn giống nhau và không phụ thuộc công nghệ. Một dependency chậm đi — chưa chết, chỉ chậm. Người gọi nó giữ kết nối và luồng để chờ. Kết nối bị giữ lâu hơn nghĩa là pool cạn nhanh hơn. Pool cạn thì chính người gọi cũng bắt đầu chậm, và người gọi nó cũng bắt đầu giữ kết nối lâu hơn. Trong vài chục giây, một sự cố nhỏ ở tầng dưới cùng đã lan ngược lên tới người dùng.

Đặc điểm nguy hiểm nhất của cascade là nó tự duy trì: sau khi nguyên nhân gốc đã được khắc phục, hệ thống vẫn tiếp tục sập, vì bây giờ thứ giữ nó sập là chính lưu lượng retry đang dồn ứ. Và nguồn khuếch đại lớn nhất của lưu lượng đó là một thứ trông vô hại trong code review.

// This code shows up at EVERY layer, and at every layer it looks reasonable:
// "if the call fails, retry a few times, the network might just be flaky".
for (let attempt = 1; attempt <= 3; attempt++) {
  const r = await callDownstream();
  if (r.ok) return r;
}
throw new Error('downstream failed');

Không ai nhìn thấy vấn đề khi review đoạn đó, vì vấn đề không nằm trong đoạn đó — nó nằm ở tích của cả chuỗi. Lab dựng ba tầng thật, mỗi tầng chạy đúng đoạn code trên, rồi đếm số lần service tận cùng bị gọi:

$ ./tools/resilience-test.sh amplify 30 0
  30 request nguoi dung · chuoi 3 tang · moi tang thu lai 3 lan · budget=0
     app1 leafHits=810 retry=60  budgetDenied=0
     app2 leafHits=0   retry=540 budgetDenied=0
     app3 leafHits=0   retry=180 budgetDenied=0
  (30 x 27 = 810 lan dap vao service tan cung)

810 lần cho 30 request. Hệ số 27 = 3 × 3 × 3, và nó xuất hiện đúng vào lúc service tận cùng đang yếu nhất — vì chính sự yếu đó mới sinh ra retry. Đây là vòng phản hồi dương thuần tuý: càng yếu thì càng bị gọi nhiều, càng bị gọi nhiều thì càng yếu.

17.2 Retry cho đúng: điều kiện, backoff, và jitter

Ba điều kiện phải thoả đồng thời thì mới được retry. Thiếu một là hỏng:

Điều kiện thứ ba là điều kiện hay bị làm nửa vời nhất: nhiều hệ có backoff nhưng không có jitter. Hậu quả rất cụ thể — khi một service sập rồi sống lại, tất cả client đã cùng gặp lỗi tại một thời điểm, nên chúng cũng cùng chờ đúng 100 ms, rồi cùng chờ đúng 200 ms, rồi 400 ms. Mỗi mốc đó là một đợt sóng đồng bộ.

Lab cho 200 client cùng hỏng một lúc rồi thử lại 4 lần, hai chế độ dùng cùng công thức backoff:

Cột đáng nhìn là hệ số dồn cục — đỉnh cao gấp bao nhiêu lần mức trung bình. Không jitter cho 19,6 lần: server vừa hồi phục phải hứng một cú gấp gần 20 lần tải trung bình, và cú đó thường đủ để giết nó lần nữa, sinh ra vòng lặp sập–hồi–sập. Thêm jitter kéo hệ số xuống 5,3 và đỉnh xuống còn một phần ba.

17.3 Timeout và deadline: đừng làm việc cho một request đã chết

Mọi lời gọi mạng phải có timeout. Câu này nghe hiển nhiên tới mức dễ bỏ qua, nhưng mặc định của rất nhiều thư viện HTTP là vô hạn — nghĩa là mặc định của bạn cũng đang là vô hạn, trừ khi bạn đã chủ động đặt. Một lời gọi không timeout giữ kết nối vô thời hạn, và đó chính là bước đầu tiên của cơ chế cascade ở mục 17.1.

Nhưng có timeout thôi chưa đủ; timeout phải giảm dần theo độ sâu. Nếu tầng ngoài chờ 1 giây còn tầng trong chờ 3 giây, thì tầng ngoài bỏ cuộc trước trong khi cả chuỗi phía sau vẫn cày tiếp cho một request không còn ai chờ. Lab đo đúng tình huống đó: client bỏ cuộc sau 100 ms, server làm việc 500 ms.

{
  "role": "deadline",
  "soRequest": 100,
  "timeoutPhiaClient": 100,       // client gives up, all 100 requests
  "serverVanLamViec": 100,        // server STILL does all 100 x 500ms of work
  "phanHoiKhongAiNhan": 100,      // 100 complete responses, nobody receives them
  "congToiMs": 50000              // 50 seconds of CPU and I/O for nobody
}

Điểm đáng sợ nhất của con số này là nó vô hình trên dashboard. Nhìn từ phía server, 100 request đó hoàn tất bình thường, không lỗi, thời gian xử lý đúng như thiết kế. Nhìn từ phía người dùng, cả 100 đều thất bại. Hai bên nhìn cùng một hệ thống và thấy hai sự thật trái ngược — và bên có dashboard là bên đang nhìn sai.

Cách sửa gọi là truyền deadline: thay vì mỗi tầng tự đặt timeout riêng, tầng đầu tính ra một mốc thời gian tuyệt đối mà request phải xong trước đó, rồi truyền mốc ấy xuống dưới. Mỗi tầng kiểm tra mốc đó trước khi làm việc, và bỏ ngay nếu đã quá hạn. Kết quả: không ai làm việc cho một request đã chết.

17.4 Circuit breaker và bulkhead

Retry giả định lỗi là tạm thời. Khi một dependency đã hỏng thật sự, giả định đó sai — và mỗi lần thử lại chỉ thêm một khoảng chờ nữa trước khi nhận cùng một lỗi. Circuit breaker là cơ chế nhận ra điều đó và ngừng gọi hẳn trong một khoảng thời gian, cho dependency chỗ thở và cho chính mình khỏi phải ngồi chờ.

Lab cho một dependency chết trong 5 giây đầu (mỗi lời gọi treo 300 ms rồi trả 503) rồi sống lại:

Đọc bảng theo hai chiều. Với dependency: số lời gọi đập vào nó giảm 59% đúng lúc nó cần yên tĩnh nhất. Với chính người gọi: 5,3 giây ngồi chờ biến thành 2,2 giây, và 407 request được trả lời ngay lập tức thay vì treo — nghĩa là luồng và kết nối được giải phóng, tức là cascade bị chặn ngay tại đây.

Bulkhead giải một vấn đề anh em: ngay cả khi có breaker, nếu mọi dependency dùng chung một connection pool thì một dependency chậm vẫn hút cạn pool trước khi breaker kịp mở. Cách vá là chia pool riêng cho từng dependency — đúng như khoang kín trên tàu thuỷ mà cái tên gợi ra: một khoang ngập nước không làm chìm cả tàu.

17.5 Suy giảm có kiểm soát và chaos engineering

Ba mục trên đều nói về chuyện không làm hệ thống tệ thêm. Mục này nói về chuyện làm nó vẫn còn dùng được khi một phần đã hỏng. Nguyên tắc: một kết quả suy giảm gần như luôn tốt hơn một trang lỗi.

• Trang sản phẩm mất phần gợi ý cá nhân hoá — vẫn mua được hàng.
• Dữ liệu cache cũ 10 phút thay vì lỗi — với đa số màn hình, không ai nhận ra.
• Ẩn số lượt xem khi service thống kê chết — không ai vào vì con số đó.
• Giá trị mặc định an toàn thay vì gọi service cấu hình — miễn là mặc định đó được kiểm thử.

Điều kiện tiên quyết giống hệt điều kiện của load shedding có ưu tiên ở Bài 13: bạn phải biết trước đường đi nào phải sống bằng mọi giá, và biết trước phần nào có thể tắt. Đó là quyết định sản phẩm, không phải quyết định kỹ thuật, và nó phải có trước sự cố.

Tự làm lại các phép đo

cd blog/sysdesign/sysdesign-lab

# --- Retry amplification: 3-tier chain, each tier retries 3 times ---
./tools/resilience-test.sh amplify 30 0   # 810 hits on the leaf service (27x)
./tools/resilience-test.sh amplify 30 1   #  69 hits with a 10% retry budget enabled (11.7x fewer)

# --- Retry storm: with and without jitter ---
./tools/resilience-test.sh jitter
#   no jitter: peak 185/20ms · mean 9.4  · burst factor 19.6x · lasts 1,694ms
#   jitter   : peak  65/20ms · mean 12.3 · burst factor  5.3x · lasts 1,302ms

# --- Circuit breaker: dependency dies for 5s then recovers ---
./tools/resilience-test.sh breaker
#   no breaker: 17 calls downstream · 5,291ms wasted waiting ·   0 immediate rejections
#   breaker   :  7 calls downstream · 2,173ms wasted waiting · 407 immediate rejections

# --- Timeout placed in the wrong spot ---
./tools/resilience-test.sh deadline
#   100 client-side timeouts · server STILL does all 100 · 50,000ms wasted work

Tóm lại

Cascade failure không phải một loại lỗi mà là một chế độ hoạt động mà hệ thống rơi vào, và nó tự duy trì sau khi nguyên nhân gốc đã qua. Nguồn năng lượng nuôi nó là retry: ba tầng, mỗi tầng ba lần, biến 30 request thành 810 lần đập vào service tận cùng — đúng lúc service đó yếu nhất. Không tầng nào làm gì sai; hệ số 27 chỉ tồn tại ở mức toàn hệ thống, nên cách duy nhất phát hiện là đếm số lần service tận cùng bị gọi cho một request.

Ba cơ chế vá, mỗi cái giải một phần khác nhau. Retry budget chặn chính sự khuếch đại: 810 xuống 69, giảm 11,7 lần, vì nó giới hạn theo tỉ lệ chứ không theo số lần. Jitter chặn sóng đồng bộ: hệ số dồn cục 19,6 lần xuống 5,3 lần, và còn xong sớm hơn. Circuit breaker chặn việc ngồi chờ: 5,3 giây chờ thành 2,2 giây, 407 request được trả lời ngay thay vì treo — và đó chính là chỗ luồng, kết nối được giải phóng.

Về timeout, con số đáng nhớ nhất của bài là 50.000 ms công toi: 100 phản hồi hoàn chỉnh mà không ai nhận, và không có gì trên dashboard của server báo hiệu điều đó — từ phía nó, mọi request đều hoàn tất bình thường. Timeout phải giảm dần từ ngoài vào trong, và cách đúng là truyền deadline tuyệt đối chứ không phải để mỗi tầng tự đặt số của mình.

Cuối cùng, một bài học đến từ chính quá trình viết lab này: bản circuit breaker đầu tiên thiếu nhánh "thăm dò thất bại → mở lại ngay", và nó kẹt vĩnh viễn ở half-open — từ chối mọi request mãi mãi kể cả sau khi dependency đã khoẻ, mà không ném ra một lỗi nào. Cơ chế chống chịu cũng là code, và code cũng có bug; khác biệt là bug ở đây chỉ lộ ra đúng lúc bạn cần nó nhất. Đó là toàn bộ lý lẽ của chaos engineering.

Bài 18 là bài cuối: ghép tất cả lại thành một hệ thống thật, chạy nó, đo nó, tìm nút cổ chai, vá, rồi đo lại — với số liệu trước và sau cho từng bước, để thấy rõ bước nào đáng công và bước nào chỉ thêm phức tạp.