Pinterest đã mở rộng lên 11 triệu người dùng chỉ với 6 kỹ sư như thế nào

Những bài học rút ra

• Dùng các công nghệ phổ biến, đã được kiểm chứng
• Keep it Simple
• Đừng nghĩ quá sáng tạo (quyết định dùng kiến trúc có thể mở rộng bằng cách thêm các node giống hệt nhau)
• Giới hạn các lựa chọn
• Sharding DB > clustering
• Hãy vui vẻ! (ngay cả kỹ sư mới cũng có thể đóng góp code từ tuần đầu tiên)

Tháng 3/2010: closed beta, 1 kỹ sư

• 1 MySQL + 1 web server (Django + Python) + 1 kỹ sư (bao gồm 2 đồng sáng lập). Được host trên Rackspace

Tháng 1/2011: 10.000 người dùng (MAU), 2 kỹ sư

• Stack web server AWS EC2 (EC2 + S3 + CloudFront)
• Django + Python
• 4 web server để dự phòng
• Dùng NGINX làm reverse proxy kiêm load balancer
• 1 MySQL với 1 secondary chỉ đọc
• MongoDB cho counter
• 1 task queue và 2 task processor (tác vụ bất đồng bộ)

Tháng 10/2011: 3,2 triệu MAU, 3 kỹ sư

• Tăng trưởng cực nhanh trong 10 tháng, số người dùng tăng gấp đôi mỗi 1,5 tháng
• Một trong những động lực tăng trưởng là việc ra mắt ứng dụng iPhone vào tháng 3/2011
• Khi tăng trưởng nhanh, các vấn đề kỹ thuật xảy ra thường xuyên hơn
• Pinterest đã mắc sai lầm ở thời điểm này: "kiến trúc bị làm cho quá phức tạp"
• Chỉ có 3 kỹ sư nhưng dùng tới 5 công nghệ DB khác nhau cho dữ liệu
• Vừa sharding MySQL thủ công, vừa dùng Cassandra và Membase (nay là Couchbase) để clustering dữ liệu
• "Stack quá phức tạp" của họ
  • Stack web server (EC2 + S3 + Cloudnfront)
    • Bắt đầu chuyển backend sang Flask (Python)
  • 16 web server
  • 2 API engine
  • 2 proxy NGINX
  • 5 MySQL DB được sharding thủ công + 9 secondary chỉ đọc
  • 4 node Cassandra
  • 15 node Membase (3 cluster riêng biệt)
  • 8 node Memcache
  • 10 node Redis
  • 3 task router + 4 task processor
  • 4 node Elastic Search
  • 3 cluster Mongo
• Clustering đã đi sai hướng
  • Về lý thuyết, clustering tự động mở rộng datastore, cung cấp high availability và load balancing, đồng thời loại bỏ SPOF
  • Nhưng đáng tiếc là trên thực tế, clustering quá phức tạp, cơ chế nâng cấp khó khăn và tạo ra một SPOF lớn
  • Mỗi DB đều có một thuật toán quản lý cluster để định tuyến từ DB này sang DB khác
    • Khi DB gặp sự cố, DB mới sẽ được thêm vào và cần được quản lý
    • Nhưng thuật toán quản lý cluster của Pinterest bị lỗi, khiến dữ liệu trên mọi node bị hỏng, việc rebalance dữ liệu bị dừng lại và phát sinh một số vấn đề không thể sửa được
• Giải pháp của Pinterest là gì?
  • Loại bỏ mọi công nghệ clustering trong hệ thống (Cassandra, Membase)
  • All-in với MySQL + Memcached (đã được kiểm chứng hơn)

Tháng 1/2012: 11 triệu MAU, 6 kỹ sư

• Khoảng 12 triệu đến 21 triệu DAU
• Họ dành thời gian để đơn giản hóa kiến trúc ở giai đoạn này
• Loại bỏ clustering và Cassandra, thay bằng MySQL, Memcache và sharding
• Stack đã được đơn giản hóa
  • Amazon EC2 + S3 + Akamai (thay CloudFront)
  • AWS ELB (Elastic Load Balancing)
  • 90 Web Engines + 50 API Engines (dùng Flask)
  • 66 MySQL DB + 66 secondary
  • 59 Redis instance
  • 51 Memcache instance
  • 1 Redis Task Manager + 25 Task Processors
  • Apache Solr được sharding (thay Elasticsearch)
  • Những thứ bị loại bỏ: Cassanda, Membase, Elasticsearch, MongoDB, NGINX

Cách Pinterest sharding DB thủ công

> Database sharding là cách phân chia một tập dữ liệu đơn lẻ thành nhiều cơ sở dữ liệu
Ưu điểm: high availability, load balancing, thuật toán đơn giản cho việc phân bổ dữ liệu, dễ chia nhỏ cơ sở dữ liệu để tăng dung lượng, dễ tìm dữ liệu

• Khi mới sharding họ gặp vấn đề, nên đã thực hiện sharding thủ công dần dần trong vài tháng
• Thứ tự chuyển đổi
  1. 1 DB + Foreign Keys + Joins
  2. 1 DB + Denormalized + Cache
  3. 1 DB + Read Slaves + Cache
  4. Nhiều DB được sharding theo chức năng + Read Slaves + Cache
  5. Các DB được sharding theo ID + Backup Slaves + Cache
• Loại bỏ table join và các truy vấn phức tạp ở tầng cơ sở dữ liệu, đồng thời thêm rất nhiều caching
• Do cần rất nhiều công sức để duy trì các ràng buộc unique trên toàn bộ cơ sở dữ liệu, dữ liệu như tên người dùng và email được lưu trong một cơ sở dữ liệu khổng lồ không sharding
• Mọi bảng đều được đưa lên shard

Tháng 10/2012: 22 triệu MAU, 40 kỹ sư

• Giữ nguyên kiến trúc và chỉ bổ sung thêm một số hệ thống giống hệt nhau
  • Amazon EC2 + S3 + CDNs (EdgeCast, Akamai, Level 3)
  • 180 web servers + 240 API engines (Flask)
  • 88 MySQL DB + 88 secondary mỗi DB
  • 110 Redis instance
  • 200 Memcache instance
  • 4 Redis Task Managers + 80 Task Processors
  • Apache Solr được sharding
• Bắt đầu chuyển từ ổ cứng sang SSD
• Bài học quan trọng: các lựa chọn hạn chế và đã được kiểm chứng (limited, proven choices) là tốt hơn
• Việc bám sát EC2 và S3 đã giới hạn số lượng lựa chọn cấu hình, từ đó giảm rắc rối và tăng tính đơn giản
• Nhưng các instance mới có thể sẵn sàng chỉ trong vài giây. Nghĩa là có thể thêm 10 Memcache instance chỉ trong vài phút

Cấu trúc cơ sở dữ liệu của Pinterest

• IDs
  • Tương tự Instagram, họ có cấu trúc ID unique do sharding
  • Cấu trúc của ID 64bit
    • Shard ID: shard nào. 16 bit
    • Type: loại đối tượng (như Pin) 10 bit
    • Local ID: vị trí trong bảng. 38 bit
  • Cấu trúc lookup của ID này chỉ đơn giản là một dictionary Python
• Tables
  • Có các bảng đối tượng và bảng ánh xạ
  • Bảng đối tượng dành cho pin, board, bình luận, người dùng... Local ID được ánh xạ tới MySQL Blob (JSON)
  • Bảng ánh xạ là các bảng cho dữ liệu quan hệ giữa các đối tượng, chẳng hạn ánh xạ board với người dùng hoặc lượt thích với pin. Full ID được ánh xạ tới full ID và timestamp
  • Mọi truy vấn đều là tra cứu PK (khóa chính) hoặc index để tối ưu hiệu năng. Loại bỏ mọi join

[xguru]

Cách Instagram đạt được 14 triệu người dùng chỉ với 3 kỹ sư
Đây cũng là một bài trong cùng chuỗi, và nội dung cũng được kết nối với nhau.
"Hãy giữ mọi thứ đơn giản. Hãy dùng những công nghệ quen thuộc và đã được kiểm chứng"