Migrando Rails Apps entre Cloud y Bare Metal Servers

Edwin CruzCrowd Interactive, MagmaRails 2012

El diario de un CTO/Techy Co-founder

Dia 1

• Million dollar idea!• Investigación de mercado (alguien más ya lo

hizo?)

Dia 2

• Compra una caja de bebidas energizantes• Diseña el MVP

Dia 3

• Empieza a codificar la aplicacion

Dia 3-7

• Café• Café• Bebida energizante• Café• Dormir

Dia 7-10

• Se tiene algo estable• Hora de buscar co-founder– Inversionistas al parecer le creen mas a un grupo

de gente

Dia 1, Co-Founder

• Million dollar idea!• Investigación de mercado

Dia 2

• Diseña su MVP• Hace más investigacion• Busca techy co-founder

Dia 3

• Meetup

Dia 4

• Meetup

Dia 6

• Drinkup– Lo encuentra!

Dia 7

• Empiezan a trabajar

Dia >10

• Tienen un producto estable– MVP

We <3 ruby on rails

Primer Paso

• Hosting para la app– Heroku• $ heroku apps:create million_dollar_stage• $ heroku apps:info | grep 'Git URL'• $ git remote add heroku GIT_URL• $ git push heroku master• $ heroku run db:migrate

– Engine Yard• Click, copy, paste, click• ey deploy….. Deploy!

Como hacer un deployment?

• git push heroku master• Click Deploy, ey deploy

Dia >20

• Usuarios reales– Picos de latencia

• Primer outage– Instancias pequeñas– Base de datos compartida

Asi que…

• Recap– Ya no tienes jefes diciendo que las nuevas

tecnologias no son lo suficientemente ‘estable’ para usarla

• Cutting edge technologies– Muy prometedoras– Poca documentación– Developer felices

Sobrecarga de trabajo

• Contratación de nuevos developers• Empieza desarrollo de features en paralelo

Siguen llegando más usuarios!

• Production database• CDN• Más app servers• Pusher

• La million dollar idea es todo un exito!

Trabajando en conjunto

• Mas killer features• Third party services• Performance issues• NewRelic Profesional– Redis para sesiones– Memcached fragment cache

Nuevas feature

• Share with your friends!– Mas tráfico– Base de datos, el nuevo cuello de botella– Dobletea la capacidad!

• Actualizaciones en tiempo real– Estan matando los app servers!– Migrar a app servers diseñados para soportar

forking

Nuevas features

• Background processing– Resque al rescate!• Phew, ya se tenia redis

– Mismos recursos• Mejores estrategias de cache y expiración

• Todo bajo control.

Noticias del CEO

• Nuestra aplicacion va a ser promocionada en un canal de television a nivel nacional!!– OMG, a correr!– Pronostico: 3x trafico del pico más alto a la vez• Triplicar la capacidad?• Click, click, click…. Listo

– Al final de més, “que quuueee, y esta factura?”– En poco tiempo ya se estan usando esos recursos

Noticias del CEO

• Necesitamos uptime de 99.997– Deployment transparentes– Mas capacidad– Staging environments

Deuda de Ingenieria

• Muchos ‘add ons’• Facturación va en aumento• Ambientes de staging ‘iguales’ que produccion– QA• Sincronizacion de datos desde producción

– Base de datos– Imagenes– Usuarios, actualizar emails con ficticios

• Etc. == $$$$$$

Deployment desde cero

• Rails stack– Web server– Balancer/proxy– App servers– Database server– Fulltext search engine– Cache– Deployment scripts– Bootstraping nuevos servidores

Arquitecturanginx

haproxy

Unicorn

forkfork

fork

Unicorn

forkfork

fork

Unicorn

forkfork

fork

db

Antes que nada

• Que es un gem• Que es bundler• Nuestro amigo el Gemfile• Capistrano• Chef• RVM• Rbenv

Web Server

Dejando rastros - Nginx

haproxy

Deployments transparentes

Dejando rastros – Rails side

• Reemplazar Rails Logger– Una sola linea, se hace ‘grepable’

• Enmascarar datos sensitivos– Rails.config.filter_parameters +=

[:card_number, :cvv]

Problemas comúnes

• Repositorios Privados– Crear cuenta compartida y registrar llaves de los

servidores• Firewalls– bundle pack

• Gems para desarrollo con dependencias especiales– bundle install –without development test

Capistrano

• Herramienta para hacer de manera consistente, repetitiva y garantizada, deployments de aplicaciones.

• Scripts (recipes)– Ejecutan commandos de manera remota via ssh

Capistrano

$ capify .[add] writing './Capfile'[add] making directory './config'[add] writing './config/deploy.rb'[done] capified!

Capistrano(deploy.rb)

Capistano(deploy.rb)

Capistrano(deploy.rb)

Capistrano(deploy.rb)

current_pathcurrent_releaseshared_path

Capistrano(recipes)

Capistrano

• Como desarrollar facilmente?– Vagrant– Chef-solo

Vagrant

Migrando una app de servidores físicos a una nube privada con ~15 mins de downtime

Eventos Principales

• 8 Meses antes– Se empezó a experimentar con Joyent smart

machines– Complian con los SLA(Service Level Agreement)

internos• No eran instancias virtuales• Son delimitadas por zonas• No son ambientes virtuales• Renta era mensual fija y no por usage• SmartOS(solaris)

Eventos Principales

• 6 Meses antes– Environments de demo se instalaron• Todo en una sola instancia

– Nginx, mysql, RoR app

– Joyent proveia Percona Smart Machines• Joyent trabajo con Percona para compilar lo mas

optimizado los binarios• La aplicacion se migró a percona 5.1 de mysql 5.0.56

Eventos Principales

• 4 Meses antes– Ambiente de Staging en Joyent• Se diseño para despues ser promovido como el nuevo

cluster de produccion• 2 clusters

– 1 balanceador– 8 app servers

• Percona smart machine– 1 Master– 2 replicas

– Se compro un nuevo dominio

Eventos Principales

• 3 meses antes• Los Sysadmins se empezaron a quedar calvos– El ataque de ImageMagick!!!– Se usaban gemas especificas para linux• Leian mac addresses, en zonas, no se tiene acceso a las

mac address desde un solaris• UUID generator estaba roto, las sesiones colisionaban

Eventos Principales

• 2 Meses antes– Incertidumbre por el rendimiento• Se hizo un stress performance muy detallado• Httperf, ab, loadrunner• Se optimizaron configuraciones

– HAProxy, queue time y estrategia de balanceo, last connection vs round robin

– Nginx, se recompilo para usar otro directorio temporal– MySQL, innodb buffer size al 70% de memoria y archivo por

tabla

Eventos Principales

• 1.5 meses antes– Si! Si lo hacemos…. ( comprando mis boletos a San

Francisco, uno con el viaje normal y otro con regreso al dia siguiente )

– Trabajo exaustivo con capistrano, debia soportar hacer deployment a dos ambientes

Eventos Principales

• 1 Mes antes– Se configuró la replica mysql multi-site• El slave en joyent se promoveria como el master el dia

del movimiento• En promedio 17 minutos atras del master

– En vez de usar el cluster de stage como producción, se contrataron unos limpios, se corrieron las recipies de chef y capistrano• ImageMagick again!!! grrrrrr

Eventos Principales

• 2 Semanas antes– Planeo detallado minuto por minuto lo que

pasaria• QA Pidio 2 hrs para validacion, wait what!???

– Miercoles 11pm empezaria todo

Eventos Principales

• 1 Semana antes– Se saco un respaldo completo de produccion y se cargo en

la replica en joyent• Replicacion multi-site trabajando bien

– Reglas del nginx• Reroute, entre clusters• Down page, pagina de mantenimiento• Redirect, redireccion multi-site

– DNS TTL al minimo– Jueves 12 am pagina de mantenimiento…. pagina de que?

• No teniamos paginas de mantenimiento!!!! (alguien gritandole a los diseñadores)

Eventos Principales

• 2 dias antes (Lunes)– Oh no!!! No teniamos tareas de capistrano para

activar las reglas del nginx– Se puso la pagina de mantenimiento que los

diseñadores hicieron– Todo bajo control, a descansar

Eventos Principales

• 1 dia antes(Martes)– Sysadmins y DevOps descansando, dia off

Eventos Principales

• El Dia de la migracion– Sysadmins y DevOps llegando a la oficina ~5pm– Ultimo dump de produccion se carga en la replica• Oh ho!, la vpn extremadamente lenta, 8pm y decia

14000 seconds behind master, shit!• Se hizo un tunel ssh por la interface externa (viajando

por internet), en 14 minutos se sincronizo• Todo listo

Eventos Principales

• Despues de 11pm– Se empezo tarde por la replica lenta• Pagina de mantenimiento• Esperar backgrond jobs terminaran• Apagar todos los app servers• Esperar la replica terminara de sincronizar master y se

promovio como master• Arrancar la aplicacion en joyent con el nuevo master

– Todo esto nos tomo 7 minutos!

Eventos Principales

• Validando la aplicacion– QA valido por un dominio especial– 8 minutos despues, dio sign off– Se activaron las redirecciones en nginx multi-site– Se cambio el dns– A rellenar la cafetera!– 2 minutos despues, callo la primera orden,

Fiuuufff!!!!!

Eventos Principales

• 3 hrs despues de la migracion– ImageMagick issues!!• Crap! Algunas imagenes se servian por PNG, e

ImageMagick no fue compilado con soporte PNG, a recompilar todos los clusters

– Se prendieron servicios externos– Se levanto otra replicacion muti-site de joyent a

rackspace– Se arrancan aplicaciones internas

Eventos Principales

• 8am dia siguiente– Ya se pueden ir a dormir– En el camino• Riiiing! “El distribution center no recibe ordenes!”• Problemas de replicacion de dns, no se hizo replicacion

multisite para aplicaciones internas, se harcodeo la nueva IP en /etc/hosts, solved…

– A Dormir

Eventos principales

• Despues de la migracion– Performance issues• Base de datos 5x mas lenta, nadie sabia porque

– Servidor mas grande– Filesystem mucho muy tuneado– Al final, despues de 2 semanas, se encontro el problema:

binarios compilados con gcc 3.x, great! |-(

• Ruby poor performance, no tomaba las environment variables del REE para tunear el garbage collector• El directorio tmp se hizo mas grande

Eventos Principales

• Al final:– 20 ms mas lento que en rackspace– 60% menos de facturacion– Podemos crecer on demand– Sobrevivimos una venta con un pico de 21k

rpm,350 clicks por segundo!!!!

Gracias!

Edwin Cruz@softr8

Tiempo para preguntas?