Enforce Timeout: A DoorDash Reliability Methodology

DoorDash · 2018 · 2. Tăng trưởng · Độ khó: Cơ bản — bài gốc

Bối cảnh

Câu hỏi trong một cuộc họp quản lý: bỏ statement_timeout của PostgreSQL thì sao? Với hàng trăm kỹ sư đẩy code mỗi ngày, theo tác giả, sớm muộn sẽ có sự cố do dùng tài nguyên không giới hạn.

Lập luận: timeout không làm việc nào nhanh hơn, nhưng đặt cận trên để ngoại lệ không gây thiệt hại lớn. Không có timeout thì tỉ lệ lỗi không tăng trong khi tài nguyên tiêu thụ cứ tăng, tới khi hệ bão hoà và thông lượng sụt, khó tìm nguyên nhân. Có timeout thì thiệt hại hiện ra trong error rate.
Đặt timeout theo kiến trúc upstream/downstream: timeout của request con không được vượt timeout của cha (quy tắc "Tower of Hanoi timeouts"), nếu không timeout ở cha che mất lỗi lẽ ra bắt được ở con.
Với database: CPU và I/O là tài nguyên chịu nặng nhất từ query chậm. Thử vài query nặng nhất trên staging, AWS Performance Insights gợi ý cần instance lớn gấp 1.000 lần. Trên Aurora còn quan trọng hơn: mọi node dùng chung tầng storage, I/O bất ngờ có thể khiến replica tự khởi động lại khi thấy mình lag quá nhiều.
Hạ statement_timeout của DB chính từ 30 giây (dài hơn cả Harakiri của uwsgi) xuống 2 giây trong khoảng một năm, vẫn đang hạ tiếp (cảm hứng từ Thumbtack hạ xuống 1 giây).
Vòng phản hồi: PgAnalyze lấy thời gian từng query từ pg_stat_activity; lỗi do chạm timeout hiện trong Sentry và New Relic; xem tỉ lệ lỗi hằng tuần, có ủng hộ của tổ chức để sửa.

Timeout biến lỗi tràn tài nguyên âm thầm thành lỗi nhìn thấy được, sửa được, và giữ bán kính hỏng nhỏ.

Mọi thứ cần timeout: tạo kết nối, khoá, query, transaction, request web.
Timeout lồng nhau: con ngắn hơn cha.
Hạ timeout dần, kèm công cụ quan sát và quy trình sửa lỗi phát sinh, thay vì một lần.