migrando rails apps entre cloud y bare metal servers
DESCRIPTION
Platica dada en MagmaRails 2012, aqui comparto mis experiencias de migrar aplicaciones rails de bare metal servers a custom cloud, de PaaS a bare metal servers y todas las combinaciones. Cualquier pregunta twitter: softr8TRANSCRIPT
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?