Lessons in resilience at SoundCloud

Bài tóm tắt SoundCloud 2016 3. Quy mô lớn Độ khó: Trung bình

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

Bối cảnh

  • Phần lớn service của SoundCloud nói chuyện bằng JSON qua HTTP trên Finagle, nên khả năng chịu lỗi ở tầng này quyết định uptime.
  • Circuit breaker v1: ba trạng thái Closed → Open (sau n lỗi liên tiếp, chặn mọi request trong một thời gian cố định) → Half-Open (cho một request thử). Hệ quả: một lỗi có thể là yếu tố quyết định mở mạch, chặn mọi request tới service đó; người dùng chịu trải nghiệm kém, và phải restart client bằng tay để reset trạng thái.

Những câu hỏi khi chạy tải cao

  • Dự đoán sức khoẻ chính xác hơn bằng cửa sổ trượt và tỉ lệ thành công, thay cho n lỗi liên tiếp?
  • Một vài instance hỏng (ví dụ một vùng mạng trong data center) trong khi đa số khoẻ: có công bằng khi chặn cả service?
  • Service vẫn sống nhưng trả 5xx liên tục: client có dùng thông tin tầng ứng dụng để quyết định không?

Thay đổi chính

Ghép các module có sẵn của Finagle thành chính sách cho client:

  • Failure accrual: chính sách thành công theo cửa sổ (thời gian hoặc số request), tỉ lệ thành công tối thiểu, thời gian đánh dấu một instance là không dùng được.
  • Theo dõi sức khoẻ theo từng instance cộng client-side load balancing: request chỉ đi tới instance khoẻ, instance xấu được bỏ qua tạm thời để hồi phục. Vài node hỏng không còn làm cả service "biến mất".
  • Response classification: client tự định nghĩa thế nào là lỗi dựa trên giao thức (ví dụ HTTP 5xx), không chỉ tín hiệu mạng.
  • Chuyển cửa sổ từ số request sang thời gian, vì khó chọn ngưỡng hợp cho cả service traffic cao lẫn thấp. Cách làm tương tự cho client DB, cache.
  • Theo bài, Ribbon + Hystrix của Netflix là lựa chọn thay thế tương đương.

Câu hỏi bài để ngỏ

Chính sách retry của client; khi traffic tăng đột ngột thì chặn ở edge thế nào để giữ hệ lõi.

Bài học cho SWE

Liên quan