A medida que las empresas evolucionan sus stacks tecnológicos hacia un modelo más nativo de la nube, vemos una tendencia creciente: migraciones parciales o configuraciones de nube híbrida, muchas veces como pasos intermedios hacia una migración total.
Migración a la nube
Hace poco, una empresa de e-commerce estaba migrando sus aplicaciones en contenedores de AWS a GCP para aprovechar el servicio gestionado de Kubernetes de Google, GKE.
Los archivos del catálogo de productos y las fotos estaban almacenados en S3, el servicio de almacenamiento de objetos de Amazon; el DNS se gestionaba con AWS Route 53 y usaban el CDN de Cloudflare. Como primer paso, migraron las bases de datos y desplegaron sus aplicaciones en paralelo en clusters de Kubernetes.
El siguiente paso era cambiar del CDN de Cloudflare al de Google, pero dejando los archivos estáticos en S3 por el momento. Otro requisito era seguir aprovechando su DNS gestionado en AWS Route 53.
Ejemplo de migración a la nube en varias fases para una empresa de e-commerce
Este artículo muestra paso a paso cómo cachear el contenido de un bucket de AWS S3 desde GCP Cloud CDN usando un load balancer y un network endpoint group (NEG). Para simplificar, en este ejemplo no genero un certificado SSL ni agrego un frontend HTTP(S), aunque normalmente ese sería un paso adicional.
Configuración inicial del demo
- Crear el bucket inicial de S3 con archivos para hacer pruebas
Crea el bucket de S3 (anota su nombre, lo necesitarás más adelante para configurar el Host en el LB)
2. Sube los archivos de prueba y edita la metadata para agregar el header Cache-control
Archivos de ejemplo cargados
Header Cache-control agregado (requerido para el CDN)
3. Verifica que el contenido devuelve los headers correctos
Configurar el load balancer y el NEG en GCP
- Agrega o edita el tipo de backend para el tipo "Internet network endpoint group"
2. Selecciona el network endpoint group (NEG) o "crear nuevo"
Nota: es posible que tengas que crear primero el Network Endpoint Group (NEG) para que aparezca en el menú desplegable de la configuración de backend del Load Balancer. Si no lo ves, puedes elegir "Create Internet network endpoint group", pero tendrás que refrescar la pantalla del load balancer para que aparezca.
Selecciona "Fully qualified domain name" e ingresa el FQDN de la ubicación de tu bucket de S3 (a veces puedes tener tu propia entrada de DNS apuntando ahí, lo cual también funciona).
3. Habilita Cloud CDN y agrega un header personalizado (que coincida con el hostname del bucket de S3)
Después de seleccionar el "Backend type" para el NEG externo, marca "Enable Cloud CDN" y luego despliega las opciones de la parte inferior para crear un header personalizado.
El truco para que funcione es agregar el host header personalizado que coincida con el hostname de S3, como se muestra abajo.
4. Agrega o edita el frontend
5. Guarda el load balancer y verifica que esté configurado con el NEG
6. Verifica que el contenido se devuelve y llega al caché
Confirma que llegas al contenido (también desde el navegador)
Prueba varias veces en el navegador y luego revisa los logs (lo más rápido es con Stackdriver logs); expande una entrada y confirma que viene del caché.
Confirma que el caché funciona para el tráfico del load balancer
Actualizar las entradas de DNS para redirigir el tráfico a Cloud CDN
Una vez que confirmes que todo funciona como se espera y que el contenido viene del caché, cuando estés listo basta con editar tus entradas de DNS.
En este caso, el CDN lo proveía Cloudflare y existía una entrada de DNS cdn-environment-location.myco.com apuntando al CNAME something.cloudflare.com. Solo necesitas crear un nuevo registro A apuntando a la IP externa del load balancer de Google (por ejemplo, gcp-lb-development-cdn.myco.com) y luego cambiar el CNAME para que apunte a esa nueva entrada.
Por precaución, te sugiero acortar el TTL en tu entrada de CDN en producción el día anterior, por si algo sale mal: así, cuando edites el CNAME, podrás revertir y el caché de DNS de los clientes no se mantendrá por mucho tiempo.
Resumen de los pasos:
- Acortar el TTL del dominio actual del CDN
- Agregar un registro A apuntando a la IP del load balancer de GCP
- Editar el registro CNAME del dominio actual del CDN (reemplazar el FQDN de Cloudflare)
- Verificar que el contenido se enruta a través de Cloud CDN
¡Felicidades, funcionó! Ahora protégelo con un frontend HTTP(S) ;-)
Costos a considerar en soluciones cloud
Aunque es posible hacer proxy de las solicitudes desde Cloud CDN hacia buckets de S3, para que funcione hay que agregar headers personalizados, y esto tiene un costo. Actualmente es de aproximadamente $0.75 por cada millón de solicitudes, con un tope de $500 al mes. En un sitio grande con mucho tráfico, esto puede acumularse rápido.
Puede que sea poco comparado con lo que se paga en Cloudflare (no tenemos certeza de sus precios), pero vale la pena tenerlo en cuenta. A largo plazo, el plan es migrar los archivos estáticos a buckets de Google Cloud Storage y, como soportan la misma API de S3, los cambios de código requeridos serán mínimos o ninguno.
Resumen
Como ves, migrar entre proveedores tecnológicos no es tan complicado como podría parecer. De todos modos, un enfoque más seguro es dividir el trabajo en fases más pequeñas para poder hacer rollback fácilmente ante cualquier problema y minimizar la interrupción del negocio.