Cómo Pinterest escaló a 11 millones de usuarios con solo 6 ingenieros

Lecciones

• Usar tecnologías conocidas y probadas
• Keep it Simple
• No pensar de forma demasiado creativa (decidir una arquitectura que pudiera escalar agregando nodos idénticos)
• Limitar las opciones
• Sharding de BD > clustering
• ¡Divertirse! (incluso los ingenieros nuevos podían contribuir código desde su primera semana)

Marzo de 2010: beta cerrada, 1 ingeniero

• 1 MySQL + 1 servidor web (Django + Python) + 1 ingeniero (incluyendo a 2 cofundadores). Hospedado en Rackspace

Enero de 2011: 10 mil usuarios (MAU), 2 ingenieros

• Stack de servidores web en AWS EC2 (EC2 + S3 + CloudFront)
• Django + Python
• 4 servidores web para redundancia
• NGINX como proxy inverso y balanceador de carga
• 1 MySQL con 1 secundario de solo lectura
• MongoDB para contadores
• 1 cola de tareas y 2 procesadores de tareas (trabajos asíncronos)

Octubre de 2011: 3.2 millones de MAU, 3 ingenieros

• En 10 meses creció rápidamente, duplicando usuarios cada 1.5 meses
• Uno de los impulsores del crecimiento fue el lanzamiento de la app de iPhone en marzo de 2011
• A medida que crecían rápido, los problemas técnicos ocurrían con más frecuencia
• Pinterest cometió un error en esta etapa: "hicieron la arquitectura excesivamente compleja"
• Solo tenían 3 ingenieros, pero usaban 5 tecnologías de BD para sus datos
• Mientras hacían sharding manual de MySQL, al mismo tiempo usaban Cassandra y Membase (hoy Couchbase) para clusterizar datos
• Su "stack demasiado complejo"
  • Stack de servidores web (EC2 + S3 + Cloudnfront)
    • Empezaron a mover el backend a Flask (Python)
  • 16 servidores web
  • 2 motores de API
  • 2 proxies NGINX
  • 5 BD MySQL con sharding manual + 9 secundarios de solo lectura
  • 4 nodos de Cassandra
  • 15 nodos de Membase (3 clústeres separados)
  • 8 nodos de Memcache
  • 10 nodos de Redis
  • 3 routers de tareas + 4 procesadores de tareas
  • 4 nodos de Elastic Search
  • 3 clústeres de Mongo
• El clustering salió mal
  • En teoría, el clustering escala automáticamente el datastore, ofrece alta disponibilidad y balanceo de carga, y elimina los SPOF
  • Pero en la práctica, el clustering era demasiado complejo, tenía mecanismos de actualización difíciles y grandes SPOF
  • Cada BD tenía un algoritmo de administración del clúster para enrutar de una BD a otra
    • Si ocurría un problema en la BD, se agregaba una nueva BD y había que administrarla
    • Pero apareció un bug en el algoritmo de administración del clúster de Pinterest, lo que corrompió los datos de todos los nodos, detuvo el rebalanceo de datos y causó algunos problemas imposibles de corregir
• ¿La solución de Pinterest?
  • Eliminar del sistema todas las tecnologías de clustering (Cassandra, Membase)
  • Apostar totalmente por MySQL + Memcached (más probado)

Enero de 2012: 11 millones de MAU, 6 ingenieros

• Aproximadamente 12 millones y 2.1 millones de DAU
• En este punto dedicaron tiempo a simplificar la arquitectura
• Eliminaron clustering y Cassandra, y los reemplazaron por MySQL, Memcache y sharding
• Stack simplificado
  • Amazon EC2 + S3 + Akamai (en lugar de CloudFront)
  • AWS ELB (Elastic Load Balancing)
  • 90 Web Engines + 50 API Engines (usando Flask)
  • 66 BD MySQL + 66 secundarios
  • 59 instancias de Redis
  • 51 instancias de Memcache
  • 1 Redis Task Manager + 25 procesadores de tareas
  • Apache Solr con sharding (en lugar de Elasticsearch)
  • Eliminados: Cassanda, Membase, Elasticsearch, MongoDB, NGINX

Cómo Pinterest hizo sharding manual de su BD

El sharding de base de datos es una forma de dividir un conjunto de datos único en varias bases de datos
Ventajas: alta disponibilidad, balanceo de carga, algoritmos simples para la ubicación de datos, dividir fácilmente la base de datos para agregar capacidad, facilidad para encontrar datos

• Cuando comenzaron el sharding hubo problemas, así que avanzaron gradualmente con sharding manual durante varios meses
• Orden de la transición
  1. 1 BD + Foreign Keys + Joins
  2. 1 BD + Denormalized + Cache
  3. 1 BD + Read Slaves + Cache
  4. Varias BD con sharding funcional + Read Slaves + Cache
  5. BD con sharding por ID + Backup Slaves + Cache
• Eliminaron los joins de tablas y las consultas complejas de la capa de base de datos, y agregaron mucho caché
• Como mantener restricciones de unicidad en toda la base de datos requería mucho esfuerzo, datos como nombres de usuario y correos electrónicos se guardaban en una enorme base de datos sin sharding
• Todas las tablas se movieron a shards

Octubre de 2012: 22 millones de MAU, 40 ingenieros

• Mantuvieron la misma arquitectura, solo agregando más sistemas idénticos
  • Amazon EC2 + S3 + CDNs (EdgeCast, Akamai, Level 3)
  • 180 servidores web + 240 motores de API (Flask)
  • 88 BD MySQL + 88 secundarios cada una
  • 110 instancias de Redis
  • 200 instancias de Memcache
  • 4 Redis Task Managers + 80 procesadores de tareas
  • Apache Solr con sharding
• Empezaron a migrar de discos duros a SSD
• Lección importante: las elecciones limitadas y probadas (limited, proven choices) fueron mejores
• Al apegarse a EC2 y S3, limitaron las opciones de configuración, redujeron dolores de cabeza y aumentaron la simplicidad
• Pero las nuevas instancias podían estar listas en segundos. Es decir, podían agregar 10 instancias de Memcache en solo unos minutos

La estructura de base de datos de Pinterest

• IDs
  • Similar a Instragram, tenía una estructura de ID única debido al sharding
  • Composición del ID de 64 bits
    • Shard ID: a qué shard pertenece. 16 bits
    • Type: tipo de objeto (como un Pin). 10 bits
    • Local ID: posición en la tabla. 38 bits
  • La estructura de lookup de este ID era simplemente un diccionario simple de Python
• Tables
  • Había tablas de entidades y tablas de mapeo
  • Las tablas de objetos eran para pins, boards, comentarios, usuarios, etc. ID local mapeado a MySQL Blob (JSON)
  • Las tablas de mapeo eran para datos relacionales entre objetos, como mapear boards a usuarios o likes a pins. ID completo mapeado a ID completo y timestamp
  • Todas las consultas eran búsquedas por PK (clave primaria) o índice para eficiencia. Se eliminaron todos los joins

[xguru]

Cómo Instagram consiguió 14 millones de usuarios con solo 3 ingenieros
Es un artículo de la misma serie, y el contenido también se conecta.
"Mantenerlo simple. Usar tecnologías bien conocidas y comprobadas"