How Discord Supercharges Network Disks for Extreme Low Latency

Discord · 2022 · 3. Quy mô lớn · Độ khó: Nâng cao — bài gốc

Bối cảnh

Discord chạy các cụm ScyllaDB trên Google Cloud, khoảng 4 tỉ tin nhắn/ngày (2022). Khi tải cao, hàng đợi đọc đĩa của DB tăng mãi và query bắt đầu timeout.
Nguyên nhân: Persistent Disk của GCP là đĩa qua mạng, latency mỗi thao tác cỡ 1–2 ms so với khoảng 0,5 ms của đĩa gắn trực tiếp. Song song trong DB có giới hạn, quá ngưỡng thì phải chờ đĩa.
Local SSD (NVMe) nhanh nhưng, theo Discord, kém tin cậy trong thử nghiệm của họ: hỏng đĩa hoặc host gặp sự cố là mất dữ liệu, không snapshot được. Gần như mọi server của Discord dùng Persistent Disk.

Thu hẹp yêu cầu: ở lại GCP, giữ snapshot cho backup, ưu tiên latency đọc (workload đọc nhiều), không giảm uptime. Ghi chậm và không resize nóng thì chấp nhận được.
Ý tưởng là write-through cache: đọc từ Local SSD, ghi vào Persistent Disk. Thử dm-cache, lvm-cache, bcache thì gặp vấn đề: đọc trúng bad sector trên đĩa cache làm hỏng cả thao tác đọc, và ScyllaDB tự tắt khi gặp lỗi I/O.
Dùng md (software RAID của Linux): RAID0 ghép nhiều Local SSD 375 GB thành một đĩa đủ lớn, rồi RAID1 giữa mảng đó và Persistent Disk đánh dấu write-mostly, nên đọc chỉ đi vào SSD, ghi đi cả hai. Không cần RAID5/6 vì GCP không cho thay Local SSD hỏng (cả server bị chuyển sang phần cứng khác).
Kết quả: ở tải đỉnh DB không còn dồn hàng đợi đĩa, latency query không đổi; nhét được nhiều query hơn trên cùng server. Bài hẹn phần 2 về các edge case trên cloud.

Không có loại đĩa cloud nào vừa nhanh vừa bền vừa snapshot được; ghép hai loại ở tầng kernel lấy đúng thuộc tính cần cho từng chiều (đọc từ local, độ bền từ đĩa mạng).

Latency đĩa trên cloud khác hẳn data center vật lý; theo Discord, đó lẽ ra phải là mối quan tâm từ đầu khi triển khai DB.
Liệt kê lại yêu cầu và bỏ những thứ không thật cần (resize nóng, latency ghi) mới mở ra thiết kế ghép.
Đường cache phải xử lý được lỗi của chính tầng cache (bad sector), nếu không cache biến thành điểm hỏng mới.