Eliminating toil with fully automated load testing

LinkedIn · 2019 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

Năm 2013 LinkedIn chạy nhiều data center và dựng TrafficShift để chuyển traffic thật giữa các DC khi có sự cố.
Định tuyến: member vào PoP qua GeoDNS (PoP là IPVS + Apache Traffic Server). Stickyrouting gán mỗi member một DC chính và một DC phụ bằng job Hadoop định kỳ (theo khoảng cách và capacity từng DC); cookie do ATS đặt chỉ ra bucket trong DC.
Load test hằng ngày bằng traffic thật: đánh dấu bucket ở các DC khác là offline để dồn traffic vào DC cần test, tìm QPS tối đa DC đó chịu được. Làm tay: kỹ sư chọn số bucket mỗi bước, khoảng chờ, thời lượng, vừa xem dashboard vừa canh kênh chat, mất 2–3 giờ mỗi ngày và căng thẳng.

Ba giai đoạn tự động: ramp nhanh tới 75% QPS mục tiêu, rồi 90% (có nghỉ để monitoring kịp báo), sau đó tiến từ từ trong cửa sổ giữa low watermark và high watermark quanh mục tiêu bằng hai hàm bước tăng/giảm số bucket.
Trễ của pipeline metric làm quyết định dựa trên số cũ; không sửa được ở nguồn nên họ query pipeline dày hơn để có số sát nhất.
Nút pause (để xem một alert hay lời phàn nàn của chủ service) và terminate bất cứ lúc nào.

Load test hằng ngày là cách biết DC có chịu được nếu phải gánh traffic của DC khác; làm tay tốn công và dễ sai trên traffic thật.

Cơ chế failover giữa DC cũng là công cụ load test: dồn traffic thật vào một DC để đo trần.
Tự động hoá việc điều khiển theo metric phải tính cả độ trễ của chính metric.
Luôn có nút dừng tay trong quy trình tự động chạy trên production.