Scaling Cache Infrastructure at Pinterest

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

Bối cảnh

Tầng cache phân tán nằm gần đáy stack, đứng trước nhiều service và DB, hấp thụ phần lớn traffic backend: hàng nghìn máy EC2, hàng trăm TB, hơn 150 triệu request/giây lúc cao điểm (2020).
Mỗi API request fan-out thành một cây RPC qua hàng chục service; kết quả trung gian được cache theo kiểu lookaside, giúp giảm latency và giảm dung lượng cần cho các backend đắt.
Lịch sử phía client: routing/discovery lúc đầu nằm trong thư viện client (dễ vỡ, gắn với việc deploy binary) → một proxy tự xây (thiếu khối dựng sẵn cho high availability) → mcrouter.

Memcached + mcrouter:
- memcached đơn giản, rất hiệu quả: một r5.2xlarge chịu >100K req/s và hàng chục nghìn kết nối; được coi là service có throughput hiệu quả nhất của Pinterest; TLS và mTLS sẵn có;
- mcrouter (proxy tầng 7, Facebook mở mã năm 2014) chạy như sidecar cạnh mỗi service, cho app một endpoint duy nhất, tách control plane khỏi data plane (pool server tách khỏi policy routing), có sẵn observability (latency theo percentile, throughput theo client/server, xu hướng theo tiền tố key).
Extstore (flash NVMe): dung lượng mỗi instance từ ~55 GB (r5.2xlarge) lên ~1,7 TB (i3.2xlarge) với một phần nhỏ chi phí, mà latency end-to-end không giảm đáng kể. Cùng hướng với Netflix EVCache (Netflix 2018).
Sẵn sàng cao:
- tự failover sang một cụm dùng chung khi server chết hoặc chậm, health check chủ động để đưa server trở lại;
- replicate xuyên AZ cho use case quan trọng, mất trọn một AZ vẫn không downtime;
- shadow traffic và tiêm lỗi/latency giả lập trên traffic thật.
Sharding: consistent hashing để thêm hoặc bớt server mà hit rate chỉ ảnh hưởng cục bộ. Route theo tiền tố key tới các pool (ưu tiên AZ; L1 RAM → L2 flash).

Proxy trung gian thêm chi phí compute và I/O, nhưng các tính năng nó mang lại xứng đáng.
Cấu hình proxy dùng chung toàn cục: một thay đổi được áp lên hàng chục nghìn máy cùng lúc (rủi ro rollout), đổi lại mọi client thấy topology nhất quán.
~100 cụm memcached khác nhau: tốn công bảo trì nhưng cô lập được hiệu năng theo use case.
Consistent hashing không giải được hot key: lượng request bất thường cho vài key vẫn tạo shard nóng.

Cung cấp cache như một dịch vụ (sidecar + cấu hình tập trung) để team ứng dụng không phải lo tính nhất quán và high availability. Xem Nền tảng nội bộ cho service (đường ray chung).
Cache là đòn bẩy chi phí: mỗi request được phục vụ từ cache rẻ hơn nhiều so với backend. Xem Chi phí hạ tầng và build vs buy.
Hash chia đều key, nhưng không chia đều tải khi có hot key. Xem Hot partition và thundering herd.
Việc tiếp theo Pinterest nêu: nhúng memcached vào trong process cho use case cực nhạy latency; dư thừa đa region.