Pinterest ने सिर्फ 6 इंजीनियरों के साथ 1.1 करोड़ उपयोगकर्ताओं तक कैसे स्केल किया

सीखें

• जानी-पहचानी, प्रमाणित तकनीकों का उपयोग
• Keep it Simple
• बहुत ज़्यादा रचनात्मक तरीके से न सोचना (ऐसी आर्किटेक्चर चुनना जिसे वही नोड जोड़कर स्केल किया जा सके)
• विकल्प सीमित रखना
• DB sharding > clustering
• मज़े से काम करना! (नए इंजीनियर भी पहले हफ्ते से कोड में योगदान कर सकते थे)

मार्च 2010: क्लोज़्ड बीटा, 1 इंजीनियर

• 1 MySQL सर्वर + 1 वेब सर्वर (Django + Python) + 1 इंजीनियर (2 सह-संस्थापकों सहित). Rackspace पर होस्टेड

जनवरी 2011: 10 हज़ार उपयोगकर्ता (MAU), 2 इंजीनियर

• AWS EC2 वेब सर्वर स्टैक (EC2 + S3 + CloudFront)
• Django + Python
• redundancy के लिए 4 वेब सर्वर
• NGINX को reverse proxy और load balancer के रूप में
• 1 MySQL सर्वर के साथ 1 read-only secondary
• counter के लिए MongoDB
• 1 task queue और 2 task processor (asynchronous काम)

अक्टूबर 2011: 32 लाख MAU, 3 इंजीनियर

• 10 महीनों में तेज़ी से वृद्धि हुई और हर 1.5 महीने में उपयोगकर्ता दोगुने हो रहे थे
• मार्च 2011 में iPhone ऐप लॉन्च होना वृद्धि के प्रमुख कारणों में से एक था
• तेज़ी से बढ़ते हुए तकनीकी समस्याएँ अधिक बार आने लगीं
• Pinterest ने इस समय गलती की: "आर्किटेक्चर को ज़रूरत से ज़्यादा जटिल बना दिया"
• इंजीनियर सिर्फ 3 थे, लेकिन डेटा के लिए 5 तरह की DB तकनीकें इस्तेमाल हो रही थीं
• MySQL को manually shard करते हुए साथ ही Cassandra और Membase (अब Couchbase) का उपयोग कर डेटा को cluster किया गया
• उनका "बहुत जटिल स्टैक"
  • वेब सर्वर स्टैक (EC2 + S3 + Cloudnfront)
    • बैकएंड को Flask(Python) पर शिफ्ट करना शुरू किया
  • 16 वेब सर्वर
  • 2 API इंजन
  • 2 NGINX proxy
  • manually sharded 5 MySQL DBs + 9 read-only secondaries
  • 4 Cassandra nodes
  • 15 Membase nodes (3 अलग क्लस्टर)
  • 8 Memcache nodes
  • 10 Redis nodes
  • 3 task router + 4 task processor
  • 4 Elastic Search nodes
  • 3 Mongo clusters
• clustering गलत साबित हुई
  • सिद्धांत रूप से clustering अपने-आप datastore को scale करती है, high availability और load balancing देती है, और SPOF हटाती है
  • लेकिन वास्तविकता में clustering बहुत जटिल थी, upgrade mechanism कठिन था, और एक बड़ा SPOF मौजूद था
  • हर DB में DB-से-DB routing के लिए cluster management algorithm था
    • DB में समस्या आने पर नया DB जोड़ा जाता और उसका प्रबंधन करना पड़ता
    • लेकिन Pinterest के cluster management algorithm में bug आ गया, जिससे सभी nodes का data corrupt हो गया, data rebalancing रुक गई, और कुछ ऐसी समस्याएँ पैदा हुईं जिन्हें ठीक नहीं किया जा सकता था
• Pinterest का समाधान?
  • सिस्टम से सभी clustering तकनीकें (Cassandra, Membase) हटा दीं
  • (ज़्यादा प्रमाणित) MySQL + Memcached पर पूरा ध्यान लगाया

जनवरी 2012: 1.1 करोड़ MAU, 6 इंजीनियर

• लगभग 1200万 से 2100 DAU
• इस समय आर्किटेक्चर को सरल बनाने में समय लगाया गया
• clustering और Cassandra हटाकर उसकी जगह MySQL, Memcache, sharding लाई गई
• सरल किया गया स्टैक
  • Amazon EC2 + S3 + Akamai (CloudFront का विकल्प)
  • AWS ELB (Elastic Load Balancing)
  • 90 Web Engines + 50 API Engines (Flask का उपयोग)
  • 66 MySQL DBs + 66 secondaries
  • 59 Redis Instances
  • 51 Memcache Instances
  • 1 Redis Task Manager + 25 Task Processors
  • sharded Apache Solr (Elasticsearch का विकल्प)
  • हटाए गए: Cassanda, Membase, Elasticsearch, MongoDB, NGINX

Pinterest ने DB को manually shard कैसे किया

database sharding एक single dataset को कई databases में बाँटने की विधि है
फायदे: high availability, load balancing, data placement के लिए सरल algorithm, database को आसानी से बाँटकर capacity बढ़ाना, data ढूँढना आसान

• पहली बार sharding करते समय समस्याएँ आईं, इसलिए कई महीनों में धीरे-धीरे manual sharding की गई
• transition का क्रम
  1. 1 DB + Foreign Keys + Joins
  2. 1 DB + Denormalized + Cache
  3. 1 DB + Read Slaves + Cache
  4. कई functionally sharded DBs + Read Slaves + Cache
  5. ID से sharded DBs + Backup Slaves + Cache
• database layer से table joins और complex queries हटाकर बहुत सारा caching जोड़ा गया
• पूरे database में unique constraints बनाए रखने के लिए बहुत मेहनत लगती थी, इसलिए username और email जैसे data को एक बड़े non-sharded database में रखा गया
• सभी tables shards पर रखी गईं

अक्टूबर 2012: 2.2 करोड़ MAU, 40 इंजीनियर

• आर्किटेक्चर वही रखा गया, बस उसी तरह के कुछ और सिस्टम जोड़ दिए गए
  • Amazon EC2 + S3 + CDNs (EdgeCast, Akamai, Level 3)
  • 180 web servers + 240 API engines (Flask)
  • 88 MySQL DBs + 88 secondaries each
  • 110 Redis instances
  • 200 Memcache instances
  • 4 Redis Task Managers + 80 Task Processors
  • Sharded Apache Solr
• hard disk से SSD पर जाना शुरू किया
• महत्वपूर्ण सीख: सीमित और प्रमाणित विकल्प (limited, proven choices) बेहतर थे
• EC2 और S3 पर टिके रहने से configuration choices सीमित रहीं, जिससे परेशानियाँ कम हुईं और सरलता बढ़ी
• साथ ही नए instances कुछ ही सेकंड में तैयार किए जा सकते थे. यानी कुछ ही मिनटों में 10 Memcache instances जोड़े जा सकते थे

Pinterest की database संरचना

• IDs
  • Instagram की तरह, sharding की वजह से इसका unique ID structure था
  • 64bit ID की संरचना
    • Shard ID : कौन-सा shard है. 16 bit
    • Type : object type (जैसे Pin) 10 bit
    • Local ID : table में position. 38 bit
  • इस ID की lookup संरचना बस एक simple Python dictionary थी
• Tables
  • entity tables और mapping tables थीं
  • object tables Pins, boards, comments, users आदि के लिए थीं. local ID को MySQL Blob(JSON) से map किया जाता था
  • mapping tables objects के बीच relational data के लिए थीं, जैसे board को user से map करना या like को pin से map करना. full ID को timestamp के साथ full ID से map किया जाता था
  • सभी queries दक्षता के लिए PK (primary key) या index lookup थीं. सभी joins हटा दिए गए

[xguru]

Instagram ने केवल 3 इंजीनियरों के साथ 1.4 करोड़ यूज़र्स कैसे हासिल किए
यह उसी सीरीज़ का लेख है, और इसकी सामग्री भी आपस में जुड़ती है।
"इसे सरल बनाए रखें। अच्छी तरह जानी-पहचानी और परखी हुई तकनीकों का उपयोग करें"