Spotify comenzó a utilizar Google Cloud Platform (GCP) en 2016, con inversiones de 450 millones de dólares en tres años. Para Google, la plataforma de streaming de música se convirtió en un cliente de referencia, no solo por su marca y escala, sino también por su reputación como una empresa centrada en la ingeniería y orientada a los datos.
Desde entonces, Spotify ha cerrado ambos data centers instalados en EE. UU. y estará libre de infraestructura on-premise para finales de año, tras una compleja migración.
¿Por qué migrar?
Ramon van Alteren, director de ingeniería de Spotify, comenta que, si se piensa en la cantidad de esfuerzo necesario para mantener la capacidad de cómputo, almacenamiento y red de una empresa global que atiende a más de 170 millones de usuarios, se trata de una cantidad considerable de trabajo.
Además de evitar que los desarrolladores se preocuparan por el aprovisionamiento y mantenimiento de la infraestructura, la empresa también quería aprovechar algunas de las innovaciones de Google Cloud, específicamente el data warehouse en la nube BigQuery, Pub/Sub para el envío de mensajes, además de la herramienta DataFlow para el procesamiento por lotes y streaming.
Migración de servicios: paso a paso
El plan de migración actual se formuló en 2015 y se dividió en dos partes: servicios y datos. La migración de servicios se centró en la transferencia de casi 1.200 microservicios de los data centers a Google Cloud Platform.
Los tres objetivos principales durante la migración, según van Alteren, fueron minimizar la interrupción del desarrollo de productos, terminar lo más rápido posible para evitar el costo y la complejidad de operar en un entorno híbrido, y garantizar que Spotify no tuviera ningún servicio ejecutándose en sus data centers.
Una de las primeras acciones que realizaron las empresas fue conformar un pequeño equipo de migración de ingenieros y crear una visualización en tiempo real de todo el estado de la migración para que los ingenieros pudieran monitorear el progreso del proyecto.
Esta visualización parecía un conjunto de burbujas rojas (data center) y verdes (Google Cloud), donde cada burbuja representaba un sistema y el tamaño de la burbuja representaba el número de máquinas involucradas.
La migración de servicios comenzó con el mapeo de dependencias, ya que la arquitectura de Spotify implica que cada microservicio depende de otros 10 a 15 para atender una solicitud del cliente. Esto significaba que una migración "big bang", en la que todo se detiene, no era una opción, ya que los clientes esperan una disponibilidad constante del servicio.
En su lugar, los equipos de ingeniería de Spotify recibieron la tarea de transferir sus servicios a la nube en un sprint de dos semanas, período durante el cual detuvieron efectivamente cualquier desarrollo de productos. Esto también permitió a estos equipos comenzar a evaluar su arquitectura y dar de baja cualquier elemento innecesario.
Una de las cosas que Google Cloud hizo específicamente para Spotify durante la migración fue la opción de Virtual Private Cloud (VPC). “Esto permite construir algo similar a una red interna que conecta múltiples proyectos y les permite comunicarse entre sí”, dijo van Alteren.
Esto permite a los equipos tener un buen control de sus demandas y, con ello, logran hacer lo que necesitan; si algo sale mal, se limita solo a su sector y no afecta a toda la empresa.
Una vez que la migración estuvo en pleno desarrollo, el equipo central de migración comenzó a inducir fallas en secreto en estos sistemas en la nube, registrando cómo reaccionaban los equipos ante la nueva arquitectura.
“Esto ayudó a garantizar que los sistemas de monitoreo se extendieran adecuadamente a la nueva implementación en la nube. Si un equipo no se daba cuenta, finalmente contábamos con este manual de procedimientos con el que podían comenzar a utilizar modos de falla en la nube que tal vez no tenían en el pasado”, explica Peter Mark Verwoerd, arquitecto de soluciones de Google.
En mayo de 2017, se completó cada sprint de migración y el tráfico se estaba redirigiendo a Google Cloud. Luego, en diciembre de 2017, Spotify alcanzó al 100% de los usuarios y ya había cerrado el primero de sus cuatro data centers. Desde entonces, se cerró el segundo data center y los dos últimos, ambos en Europa, se cerrarán a finales de este año.
Migración de datos
Debido a un gráfico de dependencias altamente complejo, fue un desafío mover 20,000 tareas diarias de datos a GCP sin causar fallas en el flujo, según Josh Baer, gerente senior de producto para la infraestructura de machine learning de Spotify.
Spotify comenzó evaluando la posibilidad de una migración 'big bang'. Sin embargo, incluso con un enlace de red de 160 gigabits por segundo, se necesitarían dos meses para copiar los datos del cluster de Hadoop a la infraestructura de Google. “No seríamos un gran negocio si estuviéramos desconectados durante dos meses”, agregó.
La mejor estrategia, entonces, fue copiar los datos. “A medida que transfieres tu trabajo a GCP, copias tus dependencias y luego puedes trasladar tu trabajo”, explicó. “Entonces, si tienes consumidores downstream, tal vez tengas que copiar la salida de tu trabajo de regreso a nuestro cluster local para que no se vean afectados. Como la mayor parte de la migración de datos duró de seis a 12 meses, estuvimos ejecutando muchas de estas tareas para llenar vacíos en nuestro árbol de dependencias.
Lecciones aprendidas
Max Charas, ingeniero de nube de Google, advierte: “esta estrategia de migración está muy personalizada para Spotify, por lo que, para cualquiera que quiera hacer algo similar, podría verse muy diferente”.
La empresa aprendió algunas lecciones importantes con la migración. La primera de ellas fue la preparación. “Nos preparamos probablemente dos años antes de la migración y cada migración tomó alrededor de un año. Intentamos crear un caso de uso mínimo para mostrar los beneficios de la migración a GCP, pero no podía ser algo pequeño si queríamos mostrar el valor real”, dice Charas.
En segundo lugar, el enfoque. Para Van Alteren, es realmente increíble lo que se puede lograr con un equipo de ingenieros enfocado en una sola cosa. Esto también ayuda a los socios de negocio, quienes prefieren un período corto sin desarrollo de productos en lugar de un período prolongado.
La tercera fue la creación de un equipo de migración dedicado para actuar como soporte, ayudándoles a identificar lo que necesitan, transmitir experiencias y aprendizajes pasados, y proveer exactamente los recursos que requieren.
La última fue “salir del entorno híbrido lo antes posible; todos estos trabajos de copia son costosos y complejos”, dijo Baer.
Resultados
Con la migración, los desarrolladores tienen más libertad y mayor escala, sin sacrificar la calidad del servicio. “La calidad del servicio es algo que medimos diligentemente y no hubo degradación”, dijo Van Alteren. “Entre los beneficios se encuentra nuestro pipeline de entrega de eventos, que procesa los pagos de regalías para los titulares de derechos. Cuando nos mudamos a la nube, el pipeline transportaba en su punto máximo 800,000 eventos por segundo, y ahora procesa tres millones por segundo”, concluye.
servicios de migración de datos
"Y qué pueden aprender las empresas de ello; la migración fue compleja, pero ahora los desarrolladores tienen más libertad y mayor escala."