Resilience Engineering at LinkedIn with Project Waterbear

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

Bối cảnh

Càng nhiều microservice thì càng nhiều phụ thuộc, điểm hỏng và miền lỗi. Năm 2017 trang chủ phụ thuộc hơn 550 endpoint. SRE nhận "độ bền ứng dụng như một dịch vụ": đo, phân tích và đưa best practice cho chủ service.

Chaos engineering:
- LinkedOut: inject lỗi (timeout, exception, delay) ở phía client Rest.li, bật bằng bump dependency + config. Chọn đối tượng bằng hệ A/B LiX (tới từng member, từng request, từng method), nên chạy được ngay trên production mà member không bị ảnh hưởng. Có web app và Chrome extension liệt kê mọi service phía dưới của một trang.
- FireDrill: giả lập lỗi hạ tầng (mạng, đĩa, CPU/RAM ở mức host bằng module SaltStack), sau đó tới nguồn, switch, rack.
Thay đổi văn hoá, graceful degradation: xác định core flow không được hỏng, giảm core dependency, nghĩ cách xuống cấp: đổi bằng thời gian (gọi sang DC khác), đổi bằng độ phức tạp (nguồn thay thế, dữ liệu cache), đổi bằng tính năng (search phức tạp → đơn giản, cá nhân hoá → mặc định). Thuyết phục bằng pilot thành công, roadshow, training, cân nhắc nhãn "Waterbear certified" ngoài điểm service scorecard.
Sửa mặc định Rest.li: lỗi một node trong cụm lớn lọt ra người dùng vì degrader (load balancer client) dùng mặc định chờ 10 giây mới coi request là chậm, quá dễ dãi với service hàng nghìn QPS, latency dưới 10 ms. D2Tuner đề xuất cấu hình degrader cho từng service theo số liệu lịch sử.

Theo LinkedIn, đa số chủ service giữ cấu hình mặc định, nên sửa framework dùng chung phủ được nhiều lỗi hơn đi sửa từng service.

Inject lỗi ở thư viện client có sẵn trong mọi service, chọn đối tượng bằng hệ A/B đã có, thì thử lỗi trên production rẻ và an toàn.
Mặc định của framework phải hợp với service điển hình; mặc định sai lặng lẽ biến lỗi một node thành lỗi người dùng.
Xác định core flow trước rồi mới bàn degrade cái gì.