What Powers Instagram: Hundreds of Instances, Dozens of Technologies

Instagram · 2011 · 1. Khởi đầu · Độ khó: Dễ — bài gốc

Bối cảnh

Sau hơn 1 năm ra mắt (12/2011): 14 triệu+ user, 3 kỹ sư, hơn 100 instance EC2. Ba nguyên tắc chọn công nghệ: giữ thật đơn giản; không phát minh lại bánh xe; dùng công nghệ đã kiểm chứng khi có thể.

Thay đổi chính (stack 2011, từ trên xuống)

Hosting: Ubuntu 11.04 trên Amazon EC2. Chưa tự host vì chỉ có 3 kỹ sư.
Load balancing: trước dùng 2 máy nginx + DNS round-robin (đổi máy chậm vì chờ DNS cập nhật); sau chuyển sang ELB với 3 nginx phía sau, terminate SSL ở ELB.
App: Django trên 25+ máy High-CPU (workload nặng CPU hơn RAM), stateless nên scale ngang dễ. Gunicorn thay Apache/mod_wsgi; Fabric để deploy song song trong vài giây.
Dữ liệu:
- PostgreSQL cho user, metadata ảnh, tag; shard chính gồm 12 máy nhớ lớn + 12 replica ở zone khác (xem Instagram 2011).
- EBS không đủ seek/giây, nên working set phải nằm trong RAM; EBS ghép software RAID.
- Streaming replication, snapshot EBS (đóng băng XFS để snapshot nhất quán).
- PgBouncer pool kết nối, được nhắc là thay đổi có tác động lớn tới hiệu năng.
- Ảnh lưu trên S3 + CloudFront.
- Redis cho feed chính, activity feed, session.
- Solr cho geo-search sau khi Postgres đã shard.
- 6 máy Memcached.
Bất đồng bộ: Gearman với ~200 worker Python, dùng để chia sẻ sang Twitter/Facebook và để fan-out feed, nhờ vậy đăng ảnh nhanh như nhau với user nhiều hay ít follower. Push notification qua pyapns (hơn 1 tỷ push).
Giám sát: Munin (cả metric nghiệp vụ như ảnh/giây), Pingdom, PagerDuty, Sentry.

Vì sao

Đội 3 người phải vận hành được. Họ chọn đồ quen thuộc, có sẵn, ít tự viết. Họ chưa dùng ElastiCache vì không rẻ hơn tự chạy.

Bài học cho SWE

Một monolith Django + Postgres + Redis + Memcached đủ cho hàng chục triệu user nếu giữ app stateless và working set trong RAM.
Đẩy việc nặng ra hàng đợi (chia sẻ mạng xã hội, fan-out) để request chính trả về nhanh.
Pool kết nối DB (PgBouncer) là tối ưu rẻ mà hiệu quả lớn.