Wie Pinterest mit nur 6 Ingenieuren auf 11 Millionen Nutzer skalierte

xguru · 2023-11-13T10:45:01+09:00

Erkenntnisse Bewährte, gut bekannte Technologien verwenden Keep it Simple Nicht zu kreativ denken (Entscheidung für eine Architektur, die sich durch Hinzufügen identischer Nodes skalieren lässt) Die Optionen begrenzen DB-Sharding > Clustering Spaß haben! (Auch neue Ingenieure konnten bereits in der ersten Woche Code beitragen) März 2010: Closed Beta, 1 Ingenieur 1 MySQL-Server + 1 Webserver (Django + Python) + 1 Ingenieur (einschließlich der 2 Mitgründer). Gehostet bei Rackspace Januar 2011: 10.000 Nutzer (MAU), 2 Ingenieure AWS-EC2-Webserver-Stack (EC2 + S3 + CloudFront) Django + Python 4 Webserver für Redundanz NGINX als Reverse Proxy und Load Balancer 1 MySQL-Server mit 1 Read-only-Secondary MongoDB für Counter 1 Task Queue und 2 Task Processor (asynchrone Aufgaben) Oktober 2011: 3,2 Mio. MAU, 3 Ingenieure In 10 Monaten rasant gewachsen, die Nutzerzahl verdoppelte sich alle 1,5 Monate Die Veröffentlichung der iPhone-App im März 2011 war einer der Wachstumstreiber Mit dem schnellen Wachstum traten technische Probleme häufiger auf Pinterest machte zu diesem Zeitpunkt einen Fehler: „Die Architektur wurde übermäßig komplex gemacht“ Obwohl es nur 3 Ingenieure gab, wurden 5 verschiedene DB-Technologien für Daten verwendet MySQL wurde manuell geshardet, während gleichzeitig Cassandra und Membase (heute Couchbase) für das Clustering von Daten eingesetzt wurden Ihr „zu komplexer Stack“ Webserver-Stack (EC2 + S3 + Cloudnfront) Beginn der Migration des Backends zu Flask (Python) 16 Webserver 2 API-Engines 2 NGINX-Proxys 5 manuell geshardete MySQL-DBs + 9 Read-only-Secondaries 4 Cassandra-Nodes 15 Membase-Nodes (3 separate Cluster) 8 Memcache-Nodes 10 Redis-Nodes 3 Task Router + 4 Task Processor 4 Elastic Search-Nodes 3 Mongo-Cluster Clustering lief schief Theoretisch skaliert Clustering den Datastore automatisch, sorgt für Hochverfügbarkeit und Load Balancing und beseitigt SPOFs In der Praxis ist Clustering leider zu komplex, Upgrade-Mechanismen sind schwierig und es bringt große SPOFs mit sich Jede DB hat einen Cluster-Management-Algorithmus, der von DB zu DB routet Wenn Probleme in der DB auftreten, werden neue DBs hinzugefügt und müssen verwaltet werden Bei Pinterest führte jedoch ein Bug im Cluster-Management-Algorithmus dazu, dass die Daten aller Nodes beschädigt wurden, das Rebalancing stoppte und einige nicht behebbaren Probleme auftraten Was war Pinterests Lösung? Entfernung aller Clustering-Technologien aus dem System (Cassandra, Membase) Voller Fokus auf (besser bewährtes) MySQL + Memcached Januar 2012: 11 Mio. MAU, 6 Ingenieure Etwa 12 Mio. bis 21 Mio. DAU Zu diesem Zeitpunkt wurde Zeit in die Vereinfachung der Architektur investiert Clustering und Cassandra wurden entfernt und durch MySQL, Memcache und Sharding ersetzt Vereinfachter Stack Amazon EC2 + S3 + Akamai (ersetzt CloudFront) AWS ELB (Elastic Load Balancing) 90 Web Engines + 50 API Engines (mit Flask) 66 MySQL-DBs + 66 Secondaries 59 Redis-Instanzen 51 Memcache-Instanzen 1 Redis Task Manager + 25 Task Processor Geshardetes Apache Solr (ersetzt Elasticsearch) Entfernt: Cassandra, Membase, Elasticsearch, MongoDB, NGINX Wie Pinterest DBs manuell sharded hat Datenbank-Sharding ist eine Methode, ein einzelnes Dataset auf mehrere Datenbanken aufzuteilen Vorteile: Hochverfügbarkeit, Load Balancing, einfache Algorithmen für die Datenplatzierung, einfaches Aufteilen von Datenbanken zum Hinzufügen von Kapazität, einfacheres Auffinden von Daten Beim ersten Sharding traten Probleme auf, daher wurde das manuelle Sharding über mehrere Monate schrittweise eingeführt Reihenfolge der Umstellung 1 DB + Foreign Keys + Joins 1 DB + denormalisiert + Cache 1 DB + Read Slaves + Cache Mehrere funktional geshardete DBs + Read Slaves + Cache Nach ID geshardete DBs + Backup Slaves + Cache Table Joins und komplexe Queries wurden aus der Datenbankschicht entfernt und viel Caching hinzugefügt Da es viel Aufwand bedeutete, eindeutige Constraints über Datenbanken hinweg aufrechtzuerhalten, wurden Daten wie Benutzername und E-Mail in einer großen, nicht geshardeten Datenbank gespeichert Alle Tabellen wurden auf Shards verteilt Oktober 2012: 22 Mio. MAU, 40 Ingenieure Die Architektur blieb unverändert, es wurden lediglich einige identische Systeme hinzugefügt Amazon EC2 + S3 + CDNs (EdgeCast, Akamai, Level 3) 180 Webserver + 240 API-Engines (Flask) 88 MySQL-DBs + jeweils 88 Secondaries 110 Redis-Instanzen 200 Memcache-Instanzen 4 Redis Task Manager + 80 Task Processor Geshardetes Apache Solr Beginn der Migration von Festplatten zu SSDs Wichtige Erkenntnis: Begrenzte und bewährte Entscheidungen (limited, proven choices) waren besser Durch das Festhalten an EC2 und S3 war die Auswahl an Konfigurationsoptionen begrenzt, was die Zahl der Problemfälle reduzierte und die Einfachheit erhöhte Gleichzeitig konnten neue Instanzen in wenigen Sekunden bereitgestellt werden. Das heißt: 10 Memcache-Instanzen ließen sich in nur wenigen Minuten hinzufügen Pinterests Datenbankstruktur IDs Ähnlich wie Instagram hatte Pinterest wegen des Shardings eine eindeutige ID-Struktur Aufbau der 64-Bit-ID Shard ID: Welcher Shard. 16 Bit Type: Objekttyp (z. B. Pin) 10 Bit Local ID: Position in der Tabelle. 38 Bit Die Lookup-Struktur dieser ID war einfach ein simples Python-Dictionary Tables Es gab Objekt-Tabellen und Mapping-Tabellen Objekt-Tabellen für Pins, Boards, Kommentare, Nutzer usw. Lokale ID, gemappt auf MySQL Blob (JSON) Mapping-Tabellen für relationale Daten zwischen Objekten, etwa die Zuordnung von Boards zu Nutzern oder Likes zu Pins. Volle ID, gemappt auf volle ID und Timestamp Alle Queries waren aus Effizienzgründen PK- oder Index-Lookups. Alle Joins wurden entfernt

(engineercodex.substack.com)

41 Punkte von xguru 2023-11-13 | 1 Kommentare | Auf WhatsApp teilen

Erkenntnisse

Bewährte, gut bekannte Technologien verwenden
Keep it Simple
Nicht zu kreativ denken (Entscheidung für eine Architektur, die sich durch Hinzufügen identischer Nodes skalieren lässt)
Die Optionen begrenzen
DB-Sharding > Clustering
Spaß haben! (Auch neue Ingenieure konnten bereits in der ersten Woche Code beitragen)

März 2010: Closed Beta, 1 Ingenieur

1 MySQL-Server + 1 Webserver (Django + Python) + 1 Ingenieur (einschließlich der 2 Mitgründer). Gehostet bei Rackspace

Januar 2011: 10.000 Nutzer (MAU), 2 Ingenieure

AWS-EC2-Webserver-Stack (EC2 + S3 + CloudFront)
Django + Python
4 Webserver für Redundanz
NGINX als Reverse Proxy und Load Balancer
1 MySQL-Server mit 1 Read-only-Secondary
MongoDB für Counter
1 Task Queue und 2 Task Processor (asynchrone Aufgaben)

Oktober 2011: 3,2 Mio. MAU, 3 Ingenieure

In 10 Monaten rasant gewachsen, die Nutzerzahl verdoppelte sich alle 1,5 Monate
Die Veröffentlichung der iPhone-App im März 2011 war einer der Wachstumstreiber
Mit dem schnellen Wachstum traten technische Probleme häufiger auf
Pinterest machte zu diesem Zeitpunkt einen Fehler: „Die Architektur wurde übermäßig komplex gemacht“
Obwohl es nur 3 Ingenieure gab, wurden 5 verschiedene DB-Technologien für Daten verwendet
MySQL wurde manuell geshardet, während gleichzeitig Cassandra und Membase (heute Couchbase) für das Clustering von Daten eingesetzt wurden
Ihr „zu komplexer Stack“
- Webserver-Stack (EC2 + S3 + Cloudnfront)
  - Beginn der Migration des Backends zu Flask (Python)
- 16 Webserver
- 2 API-Engines
- 2 NGINX-Proxys
- 5 manuell geshardete MySQL-DBs + 9 Read-only-Secondaries
- 4 Cassandra-Nodes
- 15 Membase-Nodes (3 separate Cluster)
- 8 Memcache-Nodes
- 10 Redis-Nodes
- 3 Task Router + 4 Task Processor
- 4 Elastic Search-Nodes
- 3 Mongo-Cluster
Clustering lief schief
- Theoretisch skaliert Clustering den Datastore automatisch, sorgt für Hochverfügbarkeit und Load Balancing und beseitigt SPOFs
- In der Praxis ist Clustering leider zu komplex, Upgrade-Mechanismen sind schwierig und es bringt große SPOFs mit sich
- Jede DB hat einen Cluster-Management-Algorithmus, der von DB zu DB routet
  - Wenn Probleme in der DB auftreten, werden neue DBs hinzugefügt und müssen verwaltet werden
  - Bei Pinterest führte jedoch ein Bug im Cluster-Management-Algorithmus dazu, dass die Daten aller Nodes beschädigt wurden, das Rebalancing stoppte und einige nicht behebbaren Probleme auftraten
Was war Pinterests Lösung?
- Entfernung aller Clustering-Technologien aus dem System (Cassandra, Membase)
- Voller Fokus auf (besser bewährtes) MySQL + Memcached

Januar 2012: 11 Mio. MAU, 6 Ingenieure

Etwa 12 Mio. bis 21 Mio. DAU
Zu diesem Zeitpunkt wurde Zeit in die Vereinfachung der Architektur investiert
Clustering und Cassandra wurden entfernt und durch MySQL, Memcache und Sharding ersetzt
Vereinfachter Stack
- Amazon EC2 + S3 + Akamai (ersetzt CloudFront)
- AWS ELB (Elastic Load Balancing)
- 90 Web Engines + 50 API Engines (mit Flask)
- 66 MySQL-DBs + 66 Secondaries
- 59 Redis-Instanzen
- 51 Memcache-Instanzen
- 1 Redis Task Manager + 25 Task Processor
- Geshardetes Apache Solr (ersetzt Elasticsearch)
- Entfernt: Cassandra, Membase, Elasticsearch, MongoDB, NGINX

Wie Pinterest DBs manuell sharded hat

Datenbank-Sharding ist eine Methode, ein einzelnes Dataset auf mehrere Datenbanken aufzuteilen
Vorteile: Hochverfügbarkeit, Load Balancing, einfache Algorithmen für die Datenplatzierung, einfaches Aufteilen von Datenbanken zum Hinzufügen von Kapazität, einfacheres Auffinden von Daten

Beim ersten Sharding traten Probleme auf, daher wurde das manuelle Sharding über mehrere Monate schrittweise eingeführt
Reihenfolge der Umstellung
1. 1 DB + Foreign Keys + Joins
2. 1 DB + denormalisiert + Cache
3. 1 DB + Read Slaves + Cache
4. Mehrere funktional geshardete DBs + Read Slaves + Cache
5. Nach ID geshardete DBs + Backup Slaves + Cache
Table Joins und komplexe Queries wurden aus der Datenbankschicht entfernt und viel Caching hinzugefügt
Da es viel Aufwand bedeutete, eindeutige Constraints über Datenbanken hinweg aufrechtzuerhalten, wurden Daten wie Benutzername und E-Mail in einer großen, nicht geshardeten Datenbank gespeichert
Alle Tabellen wurden auf Shards verteilt

Oktober 2012: 22 Mio. MAU, 40 Ingenieure

Die Architektur blieb unverändert, es wurden lediglich einige identische Systeme hinzugefügt
- Amazon EC2 + S3 + CDNs (EdgeCast, Akamai, Level 3)
- 180 Webserver + 240 API-Engines (Flask)
- 88 MySQL-DBs + jeweils 88 Secondaries
- 110 Redis-Instanzen
- 200 Memcache-Instanzen
- 4 Redis Task Manager + 80 Task Processor
- Geshardetes Apache Solr
Beginn der Migration von Festplatten zu SSDs
Wichtige Erkenntnis: Begrenzte und bewährte Entscheidungen (limited, proven choices) waren besser
Durch das Festhalten an EC2 und S3 war die Auswahl an Konfigurationsoptionen begrenzt, was die Zahl der Problemfälle reduzierte und die Einfachheit erhöhte
Gleichzeitig konnten neue Instanzen in wenigen Sekunden bereitgestellt werden. Das heißt: 10 Memcache-Instanzen ließen sich in nur wenigen Minuten hinzufügen

Pinterests Datenbankstruktur

IDs
- Ähnlich wie Instagram hatte Pinterest wegen des Shardings eine eindeutige ID-Struktur
- Aufbau der 64-Bit-ID
  - Shard ID: Welcher Shard. 16 Bit
  - Type: Objekttyp (z. B. Pin) 10 Bit
  - Local ID: Position in der Tabelle. 38 Bit
- Die Lookup-Struktur dieser ID war einfach ein simples Python-Dictionary
Tables
- Es gab Objekt-Tabellen und Mapping-Tabellen
- Objekt-Tabellen für Pins, Boards, Kommentare, Nutzer usw. Lokale ID, gemappt auf MySQL Blob (JSON)
- Mapping-Tabellen für relationale Daten zwischen Objekten, etwa die Zuordnung von Boards zu Nutzern oder Likes zu Pins. Volle ID, gemappt auf volle ID und Timestamp
- Alle Queries waren aus Effizienzgründen PK- oder Index-Lookups. Alle Joins wurden entfernt

1 Kommentare

xguru 2023-11-13

Wie Instagram mit nur 3 Ingenieuren auf 14 Millionen Nutzer skaliert hat
Das ist ein Artikel aus derselben Reihe, und inhaltlich hängt er ebenfalls damit zusammen.
„Einfach halten. Bekannte und bewährte Technologien verwenden“