Pinterest'in yalnızca 6 mühendisle 11 milyon kullanıcıya nasıl ölçeklendiği

Dersler

• İyi bilinen, kendini kanıtlamış teknolojileri kullanın
• Keep it Simple
• Fazla yaratıcı düşünmeyin (aynı düğümleri ekleyerek ölçeklenebilen bir mimari seçtiler)
• Seçenekleri sınırlayın
• DB sharding > clustering
• Eğlenin! (Yeni mühendisler bile ilk haftadan itibaren koda katkı yapabiliyordu)

Mart 2010: kapalı beta, 1 mühendis

• 1 MySQL sunucusu + 1 web sunucusu (Django + Python) + 1 mühendis (2 kurucu ortak dahil). Rackspace'te barındırılıyordu

Ocak 2011: 10 bin kullanıcı (MAU), 2 mühendis

• AWS EC2 web sunucusu yığını (EC2 + S3 + CloudFront)
• Django + Python
• Yedeklilik için 4 web sunucusu
• NGINX'i reverse proxy ve load balancer olarak kullandılar
• 1 MySQL sunucusu ve 1 read-only secondary
• Sayaçlar için MongoDB
• 1 görev kuyruğu ve 2 görev işleyici (asenkron işler)

Ekim 2011: 3,2 milyon MAU, 3 mühendis

• 10 ay boyunca çok hızlı büyüdüler; kullanıcı sayısı her 1,5 ayda bir ikiye katlandı
• 2011 Mart'ta iPhone uygulamasının çıkışı büyümeyi tetikleyen etkenlerden biriydi
• Hızlı büyümeyle birlikte teknik sorunlar daha sık ortaya çıkmaya başladı
• Pinterest bu noktada hata yaptı: "mimariyi gereğinden fazla karmaşık hale getirdiler"
• Mühendis sayısı sadece 3 olmasına rağmen, veriler için 5 farklı DB teknolojisi kullanıyorlardı
• MySQL'i manuel olarak shard ederken aynı anda Cassandra ve Membase'i (bugünkü Couchbase) kullanarak verileri cluster ettiler
• "Aşırı karmaşık stack"leri
  • Web sunucusu stack'i (EC2 + S3 + Cloudnfront)
    • Backend'i Flask (Python)'a taşımaya başladılar
  • 16 web sunucusu
  • 2 API engine
  • 2 NGINX proxy
  • Manuel shard edilmiş 5 MySQL DB + 9 read-only secondary
  • 4 Cassandra düğümü
  • 15 Membase düğümü (3 ayrı cluster)
  • 8 Memcache düğümü
  • 10 Redis düğümü
  • 3 task router + 4 task processor
  • 4 Elastic Search düğümü
  • 3 Mongo cluster'ı
• Clustering yanlış bir seçimdi
  • Teoride clustering, veri deposunu otomatik olarak ölçeklendirir, yüksek erişilebilirlik ve load balancing sağlar, ayrıca SPOF'u ortadan kaldırır
  • Ancak ne yazık ki pratikte clustering çok karmaşıktı, yükseltme mekanizmaları zordu ve büyük bir SPOF içeriyordu
  • Her DB'nin, DB'den DB'ye yönlendirme yapan bir cluster yönetim algoritması vardı
    • DB'de sorun çıktığında yeni bir DB eklenmesi ve bunun yönetilmesi gerekiyordu
    • Fakat Pinterest'in cluster yönetim algoritmasındaki bir bug tüm düğümlerdeki verilerin bozulmasına yol açtı, veri yeniden dengeleme durdu ve düzeltilemeyen bazı sorunlar oluştu
• Pinterest'in çözümü ne oldu?
  • Sistemdeki tüm clustering teknolojilerini (Cassandra, Membase) kaldırmak
  • (Daha kanıtlanmış olan) MySQL + Memcached'e tamamen geçmek

Ocak 2012: 11 milyon MAU, 6 mühendis

• Yaklaşık 12 milyon ile 21 milyon DAU arasında
• Bu noktada mimariyi sadeleştirmeye zaman ayırdılar
• Clustering ve Cassandra'yı kaldırıp yerine MySQL, Memcache ve sharding kullandılar
• Sadeleştirilmiş stack
  • Amazon EC2 + S3 + Akamai (CloudFront'un yerine)
  • AWS ELB (Elastic Load Balancing)
  • 90 Web Engine + 50 API Engine (Flask kullanarak)
  • 66 MySQL DB + 66 secondary
  • 59 Redis instance
  • 51 Memcache instance
  • 1 Redis Task Manager + 25 Task Processor
  • Shard edilmiş Apache Solr (Elasticsearch'in yerine)
  • Kaldırılanlar: Cassandra, Membase, Elasticsearch, MongoDB, NGINX

Pinterest'in DB'yi manuel olarak shard etme yöntemi

Database sharding, tek bir veri kümesini birden fazla veritabanına bölme yöntemidir
Avantajlar: yüksek erişilebilirlik, load balancing, veri yerleştirme için basit algoritmalar, kapasite eklemek için veritabanını kolayca bölme, veriyi kolay bulma

• İlk shard etme denemesinde sorunlar yaşadıkları için, birkaç ay boyunca kademeli biçimde manuel sharding yaptılar
• Geçiş sırası
  1. 1 DB + Foreign Keys + Joins
  2. 1 DB + Denormalized + Cache
  3. 1 DB + Read Slaves + Cache
  4. Birden fazla işlevsel olarak shard edilmiş DB + Read Slaves + Cache
  5. ID'ye göre shard edilmiş DB + Backup Slaves + Cache
• Veritabanı katmanında tablo join'lerini ve karmaşık sorguları kaldırıp yoğun cache eklediler
• Veritabanları genelinde benzersiz kısıtları korumak çok emek istediği için, kullanıcı adı ve e-posta gibi verileri shard edilmemiş dev bir veritabanında tuttular
• Tüm tablolar shard'lara taşındı

Ekim 2012: 22 milyon MAU, 40 mühendis

• Mimarinin kendisini koruyup sadece birkaç tane daha aynı sistemi eklediler
  • Amazon EC2 + S3 + CDN'ler (EdgeCast, Akamai, Level 3)
  • 180 web sunucusu + 240 API engine (Flask)
  • 88 MySQL DB + her biri için 88 secondary
  • 110 Redis instance
  • 200 Memcache instance
  • 4 Redis Task Manager + 80 Task Processor
  • Shard edilmiş Apache Solr
• HDD'den SSD'ye geçmeye başladılar
• Önemli ders: sınırlı ve kendini kanıtlamış seçimlerin (limited, proven choices) daha iyi olduğuydu
• EC2 ve S3'e bağlı kalmaları, yapılandırma seçeneklerini sınırlayarak sorunları azalttı ve sadeliği artırdı
• Ancak yeni instance'lar saniyeler içinde hazır hale gelebiliyordu. Yani sadece birkaç dakika içinde 10 Memcache instance eklemek mümkündü

Pinterest'in veritabanı yapısı

• ID'ler
  • Instagram'a benzer biçimde, sharding nedeniyle benzersiz bir ID yapıları vardı
  • 64 bit ID'nin bileşimi
    • Shard ID: hangi shard olduğu. 16 bit
    • Type: nesne tipi (Pin gibi) 10 bit
    • Local ID: tablodaki konum. 38 bit
  • Bu ID'nin lookup yapısı sadece basit bir Python dictionary'siydi
• Tablolar
  • Varlık tabloları ve eşleme tabloları vardı
  • Varlık tabloları; pin, pano, yorum, kullanıcı vb. için MySQL Blob (JSON) ile eşlenen local ID'lerden oluşuyordu
  • Eşleme tabloları ise panoyu kullanıcıya eşlemek veya beğeniyi pine eşlemek gibi nesneler arası ilişkisel veriler için kullanılıyordu; full ID ve timestamp'e eşlenen full ID yapısındaydı
  • Tüm sorgular verimlilik için PK (birincil anahtar) veya index lookup kullanıyordu. Tüm join'ler kaldırıldı

[xguru]

Instagram’ın yalnızca 3 mühendisle 14 milyon kullanıcıya ulaşmasının yolu
Bununla aynı seriden bir yazı ve içerik de birbirine bağlanıyor.
"Basit tutun. İyi bilinen ve kendini kanıtlamış teknolojileri kullanın"