Instagration Pt. 2: Scaling our infrastructure to multiple data centers

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

Bối cảnh

2013, khoảng một năm sau khi về Facebook: 200 triệu user/tháng, 20 tỷ ảnh. Họ bắt đầu "Instagration", chuyển từ AWS sang hạ tầng Facebook.
2015: 400 triệu MAU, 40 tỷ ảnh/video, hơn 1 triệu request/giây.
Động lực:
- Năm 2012 một cơn bão ở Virginia làm sập gần nửa số instance, đội nhỏ mất 36 giờ dựng lại hạ tầng.
- Sự cố cục bộ (mất điện một rack memcache) cũng cần đường lui.
- Mở rộng dung lượng linh hoạt hơn ở các data center của Facebook.

Thay đổi chính

Từ 1 lên 3 data center ở Mỹ. Ý chính: phân biệt dữ liệu global (phải replicate) và dữ liệu local (ví dụ job async chỉ dùng trong vùng).

Storage: PostgreSQL và Cassandra replicate xuyên vùng, nhất quán sau (eventual). Mỗi vùng có read replica vì đọc nhiều hơn ghi rất nhiều. Ghi Postgres vẫn đi về primary ở vùng khác.
Compute: web server và async worker stateless, chỉ dùng dữ liệu cùng vùng.
Cache theo vùng, vỡ tính nhất quán: comment ghi ở vùng A thì follower ở vùng B không thấy. Giải pháp: dùng PgQ ghi một sự kiện invalidate cache vào cùng DB. Replica nhận cả dữ liệu lẫn sự kiện; một process ở mỗi vùng đọc sự kiện và xoá cache vùng đó.
Hệ quả: tải đọc DB tăng. Hai cách giảm:
- Denormalize counter (số like lưu sẵn trong DB, cập nhật cùng transaction với like) thay vì select count(*) mất hàng trăm ms.
- Memcache lease: khi cache miss, chỉ một web server được đi DB lấy dữ liệu ("first miss"); các server khác nhận giá trị cũ hoặc chờ ("hot miss"). Đây là cách chặn thundering herd khi post của người nổi tiếng nhận like dồn dập.
Latency 60ms giữa các vùng làm read replica mới không bắt kịp primary (đọc log từ storage xa chậm hơn tốc độ sinh log). Sửa: chạy thêm một streamer ghi log ra đĩa local ngay khi bắt đầu copy snapshot. Thời gian dựng replica giảm một nửa.

Vì sao

Theo Instagram: chịu được mất cả một data center, linh hoạt dung lượng. Không lâu sau khi chuyển xong, Facebook chủ động tắt một data center vào giờ cao điểm (diễn tập thảm hoạ) và user không nhận ra.

Bài học cho SWE

Đa vùng phá vỡ giả định "cache cập nhật trực tiếp". Phải chuyển sang invalidate theo luồng replication.
Sửa một chỗ (invalidate) đẩy tải sang chỗ khác (DB). Phải tính trước và có biện pháp đi kèm (counter, lease).
Diễn tập tắt data center thật là cách kiểm chứng duy nhất đáng tin.