Bagaimana Pinterest berkembang hingga 11 juta pengguna hanya dengan 6 engineer

Pelajaran

• Gunakan teknologi yang sudah dikenal dan terbukti
• Keep it Simple
• Jangan berpikir terlalu kreatif (memilih arsitektur yang bisa diskalakan dengan menambahkan node yang sama)
• Batasi pilihan
• Sharding DB > clustering
• Bersenang-senang! (bahkan engineer baru bisa berkontribusi ke kode sejak minggu pertama)

Maret 2010: closed beta, 1 engineer

• 1 MySQL + 1 web server (Django + Python) + 1 engineer (termasuk 2 co-founder). Hosting di Rackspace

Januari 2011: 10 ribu pengguna (MAU), 2 engineer

• Stack web server AWS EC2 (EC2 + S3 + CloudFront)
• Django + Python
• 4 web server untuk redundansi
• NGINX sebagai reverse proxy dan load balancer
• 1 MySQL dengan 1 secondary read-only
• MongoDB untuk counter
• 1 task queue dan 2 task processor (pekerjaan asinkron)

Oktober 2011: 3,2 juta MAU, 3 engineer

• Tumbuh sangat cepat selama 10 bulan, jumlah pengguna berlipat ganda setiap 1,5 bulan
• Peluncuran aplikasi iPhone pada Maret 2011 menjadi salah satu pendorong pertumbuhan
• Saat tumbuh cepat, masalah teknis jadi lebih sering muncul
• Pinterest membuat kesalahan pada masa ini: "membuat arsitektur terlalu rumit"
• Engineer hanya 3 orang, tetapi ada 5 teknologi database berbeda yang dipakai untuk data
• Mereka melakukan sharding MySQL secara manual sambil menggunakan Cassandra dan Membase (sekarang Couchbase) untuk clustering data
• "Stack yang terlalu rumit" mereka
  • Stack web server (EC2 + S3 + Cloudnfront)
    • Mulai memindahkan backend ke Flask (Python)
  • 16 web server
  • 2 API engine
  • 2 proxy NGINX
  • 5 DB MySQL yang di-shard manual + 9 secondary read-only
  • 4 node Cassandra
  • 15 node Membase (3 cluster terpisah)
  • 8 node Memcache
  • 10 node Redis
  • 3 task router + 4 task processor
  • 4 node Elastic Search
  • 3 cluster Mongo
• Clustering berjalan salah
  • Secara teori, clustering otomatis menskalakan data store, memberi high availability dan load balancing, serta menghilangkan SPOF
  • Sayangnya dalam praktik, clustering terlalu rumit, mekanisme upgrade sulit, dan memiliki SPOF besar
  • Tiap DB punya algoritma manajemen cluster untuk routing dari DB ke DB
    • Saat ada masalah pada DB, DB baru ditambahkan dan harus dikelola
    • Namun algoritma manajemen cluster Pinterest mengalami bug, sehingga data di semua node rusak, rebalancing data berhenti, dan muncul beberapa masalah yang tidak bisa diperbaiki
• Solusi Pinterest?
  • Menghapus semua teknologi clustering dari sistem (Cassandra, Membase)
  • Full commit ke MySQL + Memcached (yang lebih terbukti)

Januari 2012: 11 juta MAU, 6 engineer

• Sekitar 12 juta hingga 21 juta DAU
• Pada titik ini mereka meluangkan waktu untuk menyederhanakan arsitektur
• Menghapus clustering dan Cassandra lalu menggantinya dengan MySQL, Memcache, dan sharding
• Stack yang disederhanakan
  • Amazon EC2 + S3 + Akamai (pengganti CloudFront)
  • AWS ELB (Elastic Load Balancing)
  • 90 Web Engines + 50 API Engines (menggunakan Flask)
  • 66 DB MySQL + 66 secondary
  • 59 instance Redis
  • 51 instance Memcache
  • 1 Redis Task Manager + 25 Task Processors
  • Apache Solr yang di-shard (pengganti Elasticsearch)
  • Yang dihapus: Cassanda, Membase, Elasticsearch, MongoDB, NGINX

Cara Pinterest melakukan sharding DB secara manual

Sharding database adalah cara membagi satu dataset menjadi beberapa database
Kelebihan: high availability, load balancing, algoritma sederhana untuk penempatan data, mudah membagi database untuk menambah kapasitas, mudah menemukan data

• Saat pertama kali melakukan sharding muncul masalah, jadi selama beberapa bulan mereka melakukannya secara bertahap dan manual
• Urutan transisi
  1. 1 DB + Foreign Keys + Joins
  2. 1 DB + Denormalized + Cache
  3. 1 DB + Read Slaves + Cache
  4. Banyak DB yang di-shard secara fungsional + Read Slaves + Cache
  5. DB yang di-shard berdasarkan ID + Backup Slaves + Cache
• Menghapus table join dan query kompleks di lapisan database lalu menambahkan banyak caching
• Karena butuh banyak usaha untuk menjaga unique constraint di seluruh database, data seperti username dan email disimpan di database besar yang tidak di-shard
• Semua tabel ditempatkan ke shard

Oktober 2012: 22 juta MAU, 40 engineer

• Arsitektur dipertahankan seperti adanya, hanya menambahkan beberapa sistem yang sama
  • Amazon EC2 + S3 + CDNs (EdgeCast, Akamai, Level 3)
  • 180 web servers + 240 API engines (Flask)
  • 88 MySQL DBs + masing-masing 88 secondary
  • 110 instance Redis
  • 200 instance Memcache
  • 4 Redis Task Managers + 80 Task Processors
  • Apache Solr yang di-shard
• Mulai bermigrasi dari hard disk ke SSD
• Pelajaran penting: pilihan yang terbatas dan terbukti (limited, proven choices) adalah yang terbaik
• Karena tetap memakai EC2 dan S3, pilihan konfigurasi menjadi terbatas sehingga masalah berkurang dan kesederhanaan meningkat
• Namun instance baru bisa siap dalam hitungan detik. Artinya, 10 instance Memcache bisa ditambahkan hanya dalam beberapa menit

Struktur database Pinterest

• IDs
  • Mirip Instagram, karena sharding mereka punya struktur ID yang unik
  • Komposisi ID 64 bit
    • Shard ID: shard yang mana. 16 bit
    • Type: tipe objek (seperti Pin). 10 bit
    • Local ID: posisi dalam tabel. 38 bit
  • Struktur lookup untuk ID ini hanyalah dictionary Python sederhana
• Tables
  • Ada tabel objek dan tabel mapping
  • Tabel objek untuk Pin, board, komentar, pengguna, dan lain-lain. Local ID dipetakan ke MySQL Blob (JSON)
  • Tabel mapping adalah tabel untuk data relasional antarobjek, seperti memetakan board ke pengguna atau like ke pin. Full ID dipetakan ke full ID dan timestamp
  • Semua query menggunakan lookup PK (primary key) atau indeks demi efisiensi. Semua join dihapus

[xguru]

Bagaimana Instagram meraih 14 juta pengguna hanya dengan 3 engineer
Ini tampaknya tulisan dari seri yang sama, dan isinya juga saling terhubung.
"Jaga agar tetap sederhana. Gunakan teknologi yang sudah dikenal luas dan terbukti."