Cómo Instagram está escalando su infraestructura al otro lado del océano

En 2014, dos años después de que Instagram se uniera a Facebook, el equipo de ingeniería de Instagram trasladó la infraestructura de la empresa de los servidores de Amazon Web Services (AWS) a los centros de datos de Facebook. Facebook tiene múltiples centros de datos en EE. UU. y Europa, pero, hasta hace poco, Instagram solo usaba centros de datos de EE. UU.

La razón principal por la que Instagram quiere escalar su infraestructura al otro lado del océano es que nos hemos quedado sin espacio en los Estados Unidos. A medida que el servicio continúa creciendo, Instagram ha llegado a un punto en el que debemos considerar aprovechar los centros de datos de Facebook en Europa. Un beneficio adicional: los centros de datos locales significarán una latencia más baja para los usuarios europeos, lo que creará una mejor experiencia de usuario en Instagram.

En 2015 Instagram redujo su infraestructura de uno a tres centros de datos para brindar la resiliencia que tanto se necesita: Nuestro equipo de ingeniería no quería revivir el desastre de AWS de 2012 cuando una tormenta masiva en Virginia derribó casi la mitad de sus instancias. La reducción de tres a cinco centros de datos fue trivial; simplemente aumentamos el factor de replicación y duplicamos los datos en las nuevas regiones; sin embargo, el ascenso es más difícil cuando el próximo centro de datos reside en otro continente.

Índice

Entender la infraestructura

Las infraestructuras se pueden dividir generalmente en dos tipos:

  • servicio apátrida generalmente se usa como un cálculo y se escala según el tráfico de usuarios (según sea necesario). El Django el servidor web es un ejemplo.
  • servicio estatal normalmente se usa como almacenamiento y debe ser consistente en todos los centros de datos. Ejemplos incluidos casandra Y TAO.

A todo el mundo le encantan los servicios sin estado: son fáciles de implementar y escalar, y puede activarlos cuando y donde los necesite. La verdad es que también necesitamos servicios con estado como Cassandra para almacenar datos de usuario. Ejecutar Cassandra con demasiadas copias no solo aumenta la complejidad del mantenimiento de la base de datos; también es un desperdicio de capacidad, sin mencionar el hecho de que las solicitudes de quórum viajan a través del océano es simplemente... lento.

También usa Instagram. TAO, un almacén de datos distribuido para el gráfico social, como almacenamiento de datos. Ejecutamos TAO como un solo maestro por fragmento y ningún esclavo actualiza el fragmento para ninguna solicitud de escritura. Reenvía todas las escrituras a la región principal del fragmento. Dado que toda la escritura tiene lugar en la región principal (que vive en los Estados Unidos), la latencia de escritura es insoportable en Europa. Usted puede notar que nuestro problema es fundamentalmente la velocidad de la luz.

Posibles soluciones

¿Podemos reducir el tiempo que tarda una solicitud en cruzar el océano (o incluso hacer desaparecer el viaje de ida y vuelta)? Aquí hay dos maneras en que podemos resolver este problema.

partición casandra

Para evitar que las solicitudes de quórum crucen el océano, estamos considerando dividir nuestro conjunto de datos en dos partes: Cassandra_EU y Cassandra_US. Si los almacenes de datos de usuarios europeos están en la partición Cassandra_EU y los almacenes de datos de usuarios de EE. UU. están en la partición Cassandra_US, las solicitudes de los usuarios no tendrán que viajar largas distancias para recuperar los datos.

Por ejemplo, imagine que hay cinco centros de datos en los Estados Unidos y tres en la Unión Europea. Si implementamos Cassandra en Europa duplicando los clústeres actuales, el factor de replicación será ocho y las solicitudes de quórum tendrán que hablar con cinco de las ocho réplicas.

Sin embargo, si podemos encontrar una forma de dividir los datos en dos conjuntos, tendremos una partición Cassandra_US con un factor de replicación de cinco y una partición Cassandra_EU con un factor de replicación de tres y cada una puede funcionar de forma independiente sin afectar a las demás. Mientras tanto, una solicitud de quórum para cada partición puede permanecer en el mismo continente, resolviendo el problema de la latencia de ida y vuelta.

Restringir TAO para escribir localmente

Para reducir la latencia de escritura de TAO, podemos limitar todas las escrituras de la UE a la región local. Debería verse casi idéntico al usuario final. Cuando enviamos una escritura a TAO, TAO se actualizará localmente y no bloqueará el envío de la escritura a la base de datos maestra de forma sincrónica; más bien pondrá en cola la escritura en la región local. En la región de escritura local, los datos estarán disponibles inmediatamente desde TAO, mientras que en otras regiones los datos estarán disponibles después de la propagación desde la región local. Esto es similar a las escrituras regulares de hoy, que se propagan desde la región maestra.

Aunque diferentes servicios pueden tener diferentes cuellos de botella, al enfocarnos en la idea de reducir o eliminar el tráfico marítimo, podemos abordar los problemas uno por uno.

Lecciones aprendidas

Como con cualquier proyecto de infraestructura, hemos aprendido algunas lecciones importantes en el camino. Estos son algunos de los principales.

No se apresure en un nuevo proyecto. Antes de comenzar a aprovisionar servidores en un nuevo centro de datos, asegúrese de comprender por qué necesita implementar el servicio en una nueva región, cuáles son las dependencias y cómo funcionarán las cosas cuando entre en juego la nueva región. Además, no olvide revisar sus planes de recuperación ante desastres y realizar los cambios necesarios.

No subestimes la complejidad. Siempre dedique suficiente tiempo a su agenda para cometer errores, encontrar bloqueos no planificados y aprender nuevas dependencias de las que no estaba al tanto. Es posible que se encuentre en un camino que, sin darse cuenta, reestructuraría la forma en que se construyó su infraestructura.

Conozca sus compensaciones. Las cosas siempre tienen un precio. Cuando particionamos nuestra base de datos Cassandra, ahorramos mucho espacio de almacenamiento al reducir el factor de replicación. Sin embargo, para asegurarnos de que cada partición aún estuviera lista para el desastre, necesitábamos más capacidad de Django en el frente para aceptar el tráfico de una región fallida porque ahora las particiones no pueden compartir capacidad entre sí.

Se paciente. De camino a la gira por los centros de datos europeos, no recuerdo cuántas veces dijimos "¡Oh, qué asco!" Pero las cosas siempre salen bien al final. Puede tomar más tiempo de lo esperado, pero tenga paciencia y trabaje en equipo: es un viaje súper divertido.


Sherry Xiao presentará Cross Atlantic: escalamiento de la infraestructura de Instagram de EE. UU. a Europa en LISA18, del 29 al 31 de octubre en Nashville, Tennessee.

Artículos de interés

Subir