Cómo Instagram escaló a 14 millones de usuarios con solo 3 ingenieros

Instagram escalado desde De 0 a 14 millones de usuarios en poco más de un añode octubre de 2010 a diciembre de 2011. Hicieron esto con solo 3 ingenieros.

Lo hicieron siguiendo 3 principios clave y teniendo una pila tecnológica confiable.

• Mantenga las cosas muy simples.

• No reinventes la rueda.

• Utilice tecnologías sólidas y probadas cuando sea posible.

Antes de continuar… quiero presentarles Prueba SWE.

Es un recurso de más de 450 preguntas para revelar sus lagunas en el conocimiento del dominio del software, como bases de datos, almacenamiento en caché y redes. Es perfecto para sentirse más seguro en el trabajo o repasar conocimientos antes de las entrevistas.

Es una compra de por vida con actualizaciones de por vida incluidas.

Echa un vistazo al cuestionario SWE

La primera infraestructura de Instagram se ejecutaba en AWS, utilizando EC2 con Ubuntu Linux. Como referencia, EC2 es el servicio de Amazon que permite a los desarrolladores alquilar computadoras virtuales.

Para facilitar las cosas, y como me gusta pensar en el usuario desde la perspectiva de un ingeniero, Repasemos la vida de una sesión de usuario. (Marcado con Session:)

Session: A user opens the Instagram app.

Instagram se lanzó inicialmente como una aplicación para iOS en 2010. Desde que se lanzó Swift en 2014, podemos asumir que Instagram se escribió usando Objective-C y una combinación de otras cosas como UIKit.

Session: After opening the app, a request to grab the main feed photos is sent to the backend, where it hits Instagram’s load balancer.

Instagram usado Balanceador de carga elástico de Amazon. Tenían 3 instancias de NGINX que se intercambiaban dentro y fuera dependiendo de si estaban en buen estado.

Cada solicitud llega primero al equilibrador de carga antes de enrutarse al servidor de aplicaciones real.

Session: The load balancer sends the request to the application server, which holds the logic to process the request correctly.

Se utiliza el servidor de aplicaciones de Instagram Django y fue escrito en Python, con gunicornio como su servidor WSGI.

Como repaso, una WSGI (Web Server Gateway Interface) reenvía solicitudes desde un servidor web a una aplicación web.

uso de instagram Tela para ejecutar comandos en paralelo en muchas instancias a la vez. Esto permite implementar código en solo segundos.

Estos vivían en más de 25 máquinas Amazon High-CPU Extra-Large. Dado que el servidor en sí no tiene estado, cuando necesitaban manejar más solicitudes, podían agregar más máquinas.

Session: The application server sees that the request needs data for the main feed. For this, let’s say it needs:

1. latest relevant photo IDs

2. the actual photos that match those photo IDs

3. user data for those photos.

Session: The application server grabs the latest relevant photo IDs from Postgres.

El servidor de aplicaciones extraería datos de PostgreSQLque almacenaba la mayoría de los datos de Instagram, como usuarios y metadatos de fotografías.

Las conexiones entre Postgres y Django se agruparon usando Pgbouncer.

Instagram fragmentó sus datos por el volumen que estaban recibiendo (más de 25 fotos y 90 me gusta por segundo). Usaron código para asignar varios miles de fragmentos «lógicos» a unos pocos fragmentos físicos.

Un desafío interesante que Instagram enfrentó y resolvió es generar identificaciones que pudieran ordenarse por tiempo. Sus ID resultantes, ordenables por tiempo, se veían así:

• 41 bits por tiempo en milisegundos (nos da 41 años de ID con una época personalizada)

• 13 bits que representan el ID del fragmento lógico

• 10 bits que representan una secuencia de incremento automático, módulo 1024. Esto significa que podemos generar 1024 ID, por fragmento, por milisegundo

(Puedes leer más aquí.)

Thanks to the sortable-by-time IDs in Postgres, the application server has successfully received the latest relevant photo IDs.

Session: The application server then gets the actual photos that match those photo IDs with fast CDN links so that they load fast for the user.

Se almacenaron varios terabytes de fotografías en Amazon T3. Estas fotos se entregaron rápidamente a los usuarios que utilizaban Amazon. Frente a la nube.

Session: To get the user data from Postgres, the application server (Django) matches photo IDs to user IDs using Redis.

Instagram usado Redis para almacenar un mapeo de alrededor de 300 millones de fotos al ID de usuario que las creó, para saber qué fragmento consultar al obtener fotos para el feed principal, el feed de actividades, etc. Todo Redis se almacenó en la memoria para disminuir la latencia y estaba dividido en varias máquinas.

Con un hash inteligente, Instagram pudo almacenar 300 millones de asignaciones de claves en menos de 5 GB.

Esta asignación de valor-clave de fotoID a ID de usuario era necesaria para saber qué fragmento de Postgres consultar.

Session: Thanks to efficient caching using Memcached, getting user data from Postgres was fast since the response was recently cached.

Para el almacenamiento en caché general, se utilizó Instagram Memcached. Tenían 6 instancias de Memcached en ese momento. Memcached es relativamente sencillo de superponer a Django.

Dato interesante: dos años después, en 2013, Facebook publicó un documento histórico sobre cómo escalaron Memcached para ayudarlos a manejar miles de millones de solicitudes por segundo.

Session: The user now sees the home feed, populated with the latest pictures from people he is following.

Tanto Postgres como Redis se ejecutaron en un configuración de réplica maestra y utilizó instantáneas de Amazon EBS (Elastic Block Store) para realizar copias de seguridad frecuentes de los sistemas.

Session: Now, let’s say the user closes the app, but then gets a push notification that a friend posted a photo.

Esta notificación push fue enviada usando piapns, junto con los mil millones de notificaciones push que Instagram ya había enviado. Pyapns es un proveedor universal de Apple Push Notification Service (APNS) de código abierto.

Session: The user really liked this photo! So he decided to share it on Twitter.

En el backend, la tarea se introduce en Alemaniauna cola de tareas que encargó el trabajo a máquinas mejor adaptadas. Instagram tenía ~200 trabajadores de Python consumiendo la cola de tareas de Gearman.

Gearman se utilizó para múltiples tareas asincrónicas, como enviar actividades (como una nueva foto publicada) a todos los seguidores de un usuario (esto se llama fanout).

Session: Uh oh! The Instagram app crashed because something erred on the server and sent an erroneous response. The three Instagram engineers get alerted instantly.

Instagram usado Centinelauna aplicación Django de código abierto, para monitorear errores de Python en tiempo real.

Malo se utilizó para graficar métricas de todo el sistema y alertar anomalías. Instagram tenía un montón de complementos Munin personalizados para rastrear métricas a nivel de aplicación, como fotos publicadas por segundo.

pingdom se utilizó para el seguimiento del servicio externo y Servicio de buscapersonas Se utilizó para la gestión de incidencias y notificaciones.

Fuentes: