Cómo mover la infraestructura de máquinas virtuales clásicas a contenedores orquestados por Kubernetes

Esta publicación de blog trata sobre cómo GráficoMogul retiró sus últimas piezas de infraestructura en DigitalOcean, marcando su migración a AWS como completa.

El viaje no fue su migración habitual de AWS, ya que implicó mover nuestra infraestructura de máquinas virtuales clásicas a contenedores orquestados por Kubernetes.

En una serie de artículos, compartiremos nuestras experiencias sobre:

• Nuestro viaje a AWS EKS (servicio administrado de Kubernetes).
• Algunos de los obstáculos más críticos que encontramos.
• Nuestra pila y herramientas actuales.
• Nuestros planes de infraestructura en el futuro, con la esperanza de que puedan ser útiles para toda la comunidad.

La vida con DigitalOcean

Desde nuestro inicio en 2014 y hasta mediados de 2021, toda nuestra infraestructura se ha ejecutado en gotitas de DigitalOcean (máquinas virtuales en la nube autogestionadas). Necesitábamos un proveedor de nube que nos permitiera despegar de manera rápida, confiable y rentable.

DigitalOcean tenía mucho sentido y fue una gran elección. Estamos donde estamos gracias a ellos. Esa elección nos dio la libertad de centrarnos en la creación de productos sin preocuparnos por la escalabilidad y la complejidad de la infraestructura, aspectos que suelen aparecer en una etapa posterior.

Cada aspecto de nuestra infraestructura fue aprovisionado, configurado y administrado internamente. Utilizamos herramientas de administración de configuración e infraestructura como código (Saltstack y Terraform) para administrar las cosas.

Seguimos creciendo a lo largo de los años y, en 2019, nos encontramos frente a una flota de alrededor de 50 máquinas que necesitaban constantemente administración, actualizaciones de software, parches de seguridad, etc. Y con nuevos proyectos en nuestra cartera, esperábamos que nuestras necesidades de potencia de cómputo se duplicaran para fines de 2020.

¿Por qué moverse y por qué ahora?

A pesar de la gran elección que fue DigitalOcean, nuestro crecimiento orgánico fue empujando los límites de nuestra configuración a lo largo de los años. Enfrentamos desafíos con múltiples áreas, algunas reparables y prevenibles, otras no.

Varias fallas

• Ventanas de mantenimiento no anunciadas ad-hoc que repentinamente interrumpieron la producción.

  
  

• Fallas de hardware en varias ocasiones, lo que afecta nuestra configuración de base de datos primaria y réplica (por ejemplo, gotas que ingresan a un "estado de migración en vivo a otras máquinas de hardware" sin previo aviso, lo que significa 1-2 horas de tiempo de inactividad para esa gota).

  
  

• Problemas de red inexplicables con latencia entre nuestras máquinas que el equipo de soporte de DigitalOcean nunca resolvió (esto fue crítico para nuestro retraso de réplicas de lectura de Postgres, instancias de Redis y HA en general).

Desaprobación de la región AMS2

Nuestra región de DigitalOcean (AMS2) se anunció como "próximamente retirada", lo que significa soporte limitado. No podíamos asegurar recursos adicionales a pedido, y ejecutar tareas simples generalmente significaba una planificación prolongada y recursos desperdiciados.

Cosas simples como actualizar una versión de Postgres y aprovisionar una nueva máquina para realizar una tarea se estaban volviendo imposibles de hacer.

Opciones de hardware limitadas

Estar en el espacio de análisis de suscripciones significa operaciones de uso intensivo de datos, grandes volúmenes y la capacidad de escalar a menudo en consecuencia.

Las máquinas modernas con recursos de hardware más extensos solo estaban disponibles en otras regiones. La degradación del rendimiento de la red era un hecho frecuente y pronto nos dimos cuenta de que migrar a una región diferente era nuestra mejor opción.

Falta de funciones de nube modernas y servicios administrados

El volumen de trabajo operativo para mantener nuestra infraestructura a fin de mantener la tasa de crecimiento (y lidiar con la deuda tecnológica simultáneamente) aumentó.

Tuvimos que analizar detenidamente nuestra configuración y comprender si mudarnos a una región diferente de DigitalOcean o a un nuevo proveedor de nube era la mejor opción.

¿Deberíamos quedarnos o deberíamos irnos?

Comenzamos a investigar los beneficios de permanecer con DigitalOcean y simplemente mudarnos a una nueva región: una opción más tranquila, más rápida, más barata y menos dolorosa.

Pero al mismo tiempo, tratamos este movimiento como una oportunidad para modernizar partes de nuestra pila al servicio del crecimiento esperado de usuarios y una mayor tasa de progreso.

Al final de nuestra evaluación, nos dimos cuenta de que los requisitos imprescindibles específicos serían difíciles de cumplir permaneciendo y simplemente cambiando de región. Los más importantes fueron:

• Flexibilidad en los recursos informáticos de escalado automático.

• Bases de datos administradas.

• Aprovisionamiento de recursos en función del uso temporal.

• Baja (más) latencia.

• Interoperabilidad de servicios.

• Infraestructura basada en contenedores con orquestación de Kubernetes.

  
  

Esta lista de requisitos, junto con los desafíos enumerados en la sección anterior, inclinó la balanza a favor de cambiar de proveedor.

¿Por qué AWS?

Elegir un nuevo proveedor de nube para potenciar la infraestructura de ChartMogul fue un largo viaje. Investigamos el mercado y descubrimos muchas ventajas y desventajas que un nuevo proveedor podría aportar.

Nuestras opciones eran Amazon Web Services (AWS), Google Cloud (GCP) y Azure. Finalmente, decidimos optar por AWS. A continuación enumeramos algunas de las principales razones.

Experiencia del equipo

Ya estábamos usando algunos servicios de AWS en producción (p. ej., S3 para almacenar copias de seguridad incrementales de Postgres). Más importante aún, algunos de nuestros ingenieros tenían experiencia profesional previa en el uso extensivo de varios servicios de AWS en sistemas de producción.

Escalabilidad

• Podemos aumentar o disminuir las instancias de AWS con solo presionar un botón.

  
  

• Podemos aprovisionar instantáneamente recursos como bases de datos RDS y recursos informáticos temporalmente.

  
  

• Podemos iterar a través de experimentos y pruebas de conceptos rápidamente.

  
  

• La flexibilidad y la escalabilidad de los grupos de nodos de Kubernetes respaldados por el escalado automático de EC2 son difíciles de superar.

Seguridad de datos y cumplimiento

La seguridad de los datos siempre ha sido una prioridad. A lo largo de los años, las capacidades de seguridad de AWS han crecido sustancialmente.

La cantidad de nuevos servicios desarrollados por AWS en torno a la seguridad de los datos cubre la mayoría de nuestras necesidades en el espacio de contenedores/Kubernetes.

Funcionan bien con servicios bien establecidos, como el aislamiento de VPC privado, el control detallado de las políticas y los roles de IAM.

En cuanto al cumplimiento, planeamos obtener la certificación SOC II lo antes posible, y descubrimos que los programas de cumplimiento de AWS son una ventaja que puede ayudar a acelerar ese viaje.

Servicios gestionados

Postgres está en el centro de lo que hacemos en ChartMogul y, por lo general, dedicamos mucho tiempo a administrar activamente nuestra flota de máquinas de bases de datos para respaldar nuestro crecimiento.

La alta disponibilidad y confiabilidad de las bases de datos se estaban convirtiendo en preocupaciones crecientes, por lo que decidimos evaluar varias ofertas de los principales proveedores de nube con PostgreSQL administrado. AWS RDS fue el claro ganador.

Kubernetes administrado fue otro factor importante a considerar, y esto estuvo de la mano con Google Cloud (GCP). Kubernetes administrado de Google (GKE) se sintió mejor que lo que tenía AWS en ese momento, pero comparar RDS con CloudSQL no fue tan parecido en cuanto a características.

Sin embargo, hoy en día parece que AWS se está poniendo al día con EKS; Nos beneficiamos de excelentes características de RDS, como la flexibilidad de las instantáneas, la durabilidad de las copias de seguridad (con SLA), las réplicas de lectura para Postgres, las actualizaciones sencillas, las IOPS dedicadas, las métricas de Cloudwatch, las Perspectivas de rendimiento, y la lista continúa.

La cantidad insana de servicios de AWS

En el momento de escribir este artículo, AWS ofrece más de 200 servicios. La mayoría de ellos le brindan la posibilidad de obtener acceso instantáneo a servicios administrados desde tantas áreas como computación, bases de datos, análisis de datos, almacenamiento de datos, sin servidor y almacenamiento.

Nuestros equipos de ingeniería ahora pueden aprovechar las integraciones de primer nivel para resolver problemas centrales rápidamente y priorizar la compra frente a la construcción donde tenga sentido.

Recuperación de desastres

La nube de AWS es una parte esencial de nuestro plan de recuperación ante desastres. Esto se debe a que las instancias son fáciles de activar, podemos promover réplicas de lectura de RDS a primarias con solo hacer clic en un botón, las instantáneas son muy sencillas, podemos alojarlas en varias regiones y tenemos una integración de primer nivel con nuestra herramienta IaC de elección.

Créditos AWS

Obtuvimos $100 000 en créditos a través del programa AWS Startup. Pudimos planificar, probar y completar nuestra migración sin gastos considerables.

Migración a AWS

Nuestra migración de DigitalOcean a AWS fue un viaje de diez meses. Todo el esfuerzo fue respaldado por voluntarios de todos nuestros equipos de ingeniería e impulsado por un ingeniero de DevOps, un ingeniero de back-end y nuestro jefe de ingeniería.

Algunas cosas implicaron ensayo y error. Probamos varias formas de:

• Mover datos de Postgres a RDS con un tiempo de inactividad casi nulo.

  
  

• Migrar nuestra aplicación y servicios de una arquitectura basada en VM a contenedores en Kubernetes.

  
  

• Cambiando fundamentalmente la forma en que implementamos.

Había un plan perfecto y todo se veía bien para ir en papel, pero aprendimos por las malas que las cosas no siempre saldrán según lo planeado.

A veces, nuestro objetivo de migración de tiempo de inactividad cercano a cero estuvo en grave riesgo, y volvimos a la mesa de dibujo.

La perseverancia, el empuje y el fantástico esfuerzo de equipo nos ayudaron a superar los desafíos que enfrentamos.

La planificación cuidadosa también hizo maravillas; Dada nuestra capacidad, establecimos desde el principio que dividir la migración real en tres etapas (o días) funcionaría mejor.

Semana anterior al día D

• Inicie la replicación de Postgres desde DigitalOcean a instancias de RDS.
• Revise nuestra futura infraestructura de producción de AWS.
• Configuración de secretos (AWS Parameter Store).
• Asegúrese de que las canalizaciones de CI/CD estén listas para implementarse en nuestros nuevos clústeres de Kubernetes.

El día antes del día D

• Prepare nuestra infraestructura de grabadora de webhook temporal de AWS (perder eventos durante nuestra migración no era una opción).

  
  

• Mueva algunos datos por adelantado (p. ej., DigitalOcean Spaces a S3).

  
  

• Actualice todos los secretos de la tienda de parámetros a los valores de producción.

  
  

• Preparar cambios de DNS.

  
  

• Establezca todas las implementaciones de Kubernetes en cero pods para evitar que los servicios accedan a los datos de producción durante la migración.

Día D: apretando el interruptor

• Redirigir todos los webhooks a la grabadora temporal de AWS.

  
  

• Detenga todos los servicios en DigitalOcean.

  
  

• Espere a que la replicación de Postgres se ponga al día con las últimas actualizaciones.

  
  

• Compare los datos de DigitalOcean y RDS Postgres (para garantizar la integridad y la actualización de la replicación).

  
  

• Elimine la suscripción de RDS a Postgres ejecutándose en DigitalOcean.

  
  

• Cree réplicas de lectura de RDS.

  
  

• Actualice los secretos de nuestra tienda de parámetros con nuevos extremos y secretos de RDS.

  
  

• Implemente en Kubernetes y reinicie PgBouncer para cargar nuevas configuraciones.

  
  

• Cambie los registros DNS de app.chartmogul.com a AWS.

  
  

¡En este punto, estábamos ejecutando nuestra carga de trabajo de producción en la nueva infraestructura brillante! Terminamos todo en 10 horas (inicialmente estimamos 8 horas, no está mal).

Desafíos con AWS

El mayor problema fue con el servicio DMS (servicio administrado de AWS para mover bases de datos a RDS).

No fue tan fácil de usar como se anuncia. En nuestro caso con Postgres, no fue útil. Eventualmente, desarrollamos una forma personalizada de mover datos a AWS.

También nos dimos cuenta de que mover bases de datos sin tiempo de inactividad a AWS con soporte de webhook es complicado. Desarrollamos un enfoque personalizado para respaldar esta configuración.

Más sobre estos enfoques personalizados en futuros artículos.

Artículos futuros en la serie

Busque artículos futuros que documenten nuestro viaje de migración de DigitalOcean a AWS. Tocaremos temas como:

• Por qué elegimos Kubernetes para potenciar ChartMogul.
• Cómo migramos PostgreSQL a RDS.
• Cómo migramos nuestra aplicación Rails a Kubernetes.
• Cómo configuramos un túnel IPSEC a AWS VPC.