Khi một service chậm đi, các server gọi đến nó bị giữ lại để chờ phản hồi, và cả những tính năng không liên quan cũng đứng lại.
Vì sao Một service như DB hay xác thực bị chậm → Dẫn đến Thread và kết nối của các server gọi đến bị giữ lại để chờ phản hồi, việc thử lại các yêu cầu thất bại càng làm tăng tải → Trên màn hình Cả những tính năng tưởng như không liên quan cũng chậm hoặc đứng hết
Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Hạ tầng mạng (Đội hạ tầng)
Việc cần làm (Đội phát triển game)
Đặt timeout cho mọi lời gọi, circuit breaker, cô lập theo từng tính năng (bulkhead), thử lại với khoảng cách tăng dần và giới hạn số lần, tách phần trả lời health check khỏi các tác vụ nặng.
Việc cần làm (Đội hạ tầng)
Nới số lần thất bại và khoảng cách health check của bộ cân bằng tải để server chỉ chậm trong chốc lát không bị loại ngay, giới hạn số server bị loại cùng lúc.
Trên đồ thị
Chạm giới hạn rồi đi ngang · Thời gian phản hồi và tỷ lệ lỗi theo service, số thread và kết nối đang dùng
Chỗ cần xem
Đặt thời gian phản hồi, tỷ lệ lỗi, số lần thử lại của từng service lên cùng một màn hình với trục thời gian khớp nhau, rồi tìm chỗ chậm đi đầu tiên. Nếu nằm sau bộ cân bằng tải: thời gian phản hồi của target (AWS ALB là TargetResponseTime), số lỗi 5xx của target (HTTPCode_Target_5XX_Count), số target bị loại vì không khỏe (UnHealthyHostCount)
Đúng nếu
độ trễ của một service tăng trước, sau đó số thread và kết nối đang dùng ở phía gọi service đó chạm giới hạn, lỗi lan sang service khác, số lần thử lại và số target bị loại cũng tăng theo
Loại trừ nếu
nhiều service cùng chậm đi trong cùng một khoảnh khắc → xem trước sự cố ở tài nguyên dùng chung (DB, mạng, host)
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm
Health check (kiểm tra xem server còn sống không) cũng làm sự cố dây chuyền lan rộng hơn. Khi server đang bận trả lời kiểm tra chậm, bộ cân bằng tải loại bỏ luôn server vẫn còn chạy tốt, lưu lượng của nó dồn sang các server còn lại, và server tiếp theo cũng chậm theo.
Circuit Breaker PatternMicrosoft Azure Yêu cầu bị kẹt cho tới timeout chiếm giữ thread và kết nối DB, làm cả những tính năng không liên quan thất bại theo; khi lỗi tích lại trong một khoảng thời gian định trước thì từ chối lời gọi ngay
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Chuỗi gọi 5 tầng mà mỗi tầng thử lại 3 lần thì tải lên DB tăng 243 lần; chỉ thử lại ở một chỗ và giới hạn bằng token bucket
CloudWatch metrics for your Application Load BalancerAWS TargetResponseTime (thời gian từ khi yêu cầu rời bộ cân bằng tải đến khi target bắt đầu phản hồi), HTTPCode_Target_5XX_Count (số lỗi 5xx do target trả về), UnHealthyHostCount (số target không khỏe)