How Medium Detects Hotspots in DynamoDB using ElasticSearch, Logstash and Kibana

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

Site chặn crawler; wiki đọc toàn văn qua trình duyệt, ghi chú bằng lời của wiki.

Bối cảnh

Kho phân tán scale ngang bằng cách chia dữ liệu cho nhiều server; chỉ được lợi khi truy cập đều. Ví dụ của bài: 26 server theo chữ cái đầu của họ, nếu 99% request hỏi "John Doe" thì throughput thực vẫn chỉ bằng một server.
Với DynamoDB (2015) điều này khó hơn: chỉ đặt được capacity đọc/ghi (RCU/WCU) cho cả bảng, và DynamoDB chia capacity đó cho số partition mà không cho biết có bao nhiêu partition. Ví dụ của Medium: đặt 1.400 WCU, nếu bảng có 28 partition thì mỗi partition chỉ có 50 WCU; biểu đồ tổng thấy dư capacity mà vẫn có đỉnh 150.000 request bị throttle.
Thêm khó: không gộp partition khi giảm dữ liệu hay capacity; CloudTrail không có access log; CloudWatch khi đó chỉ báo theo 5 phút (về sau 1 phút). Kết quả là phải cấp dư cả bảng cho partition bận nhất.

Tự tạo access log cho DynamoDB: mỗi service ghi một file log cho các lệnh gọi DynamoDB, đẩy qua Logstash Forwarder → Logstash → Elasticsearch, xem bằng Kibana.
Biểu đồ "top key" theo bảng: bảng truy cập đều thì key nhiều nhất cũng chỉ vài lần; bảng postChunk có một key lên 400 lần, át mọi key khác. Khi đó tăng RCU gần như không giúp gì.

Capacity tổng không nói gì khi tải lệch: phải nhìn theo key/partition (Hot partition và thundering herd).
Dịch vụ managed giấu số partition thì tự đo phía client bằng access log của chính mình.
Biết key nóng là gì thì mới chọn đúng cách chữa (sửa truy cập, cache) thay vì chỉ tăng capacity; cùng bài toán với Segment 2017 (Segment 2017).