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: softr8
15. Primer Paso
• Hosting para la app
– Heroku
• $ herokuapps:createmillion_dollar_stage
• $ herokuapps: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!
16. Como hacer un deployment?
• git push heroku master
• Click Deploy, ey deploy
17. Dia>20
• Usuariosreales
– Picos de latencia
• Primer outage
– Instanciaspequeñas
– Base de datoscompartida
18. Asique…
• Recap
– Ya no tienesjefesdiciendoquelasnuevastecnologias
no son lo suficientemente ‘estable’ parausarla
• Cutting edge technologies
– Muyprometedoras
– Pocadocumentación
– Developer felices
19. Sobrecarga de trabajo
• Contratación de nuevos developers
• Empiezadesarrollo de features en paralelo
20. Siguenllegandomásusuarios!
• Production database
• CDN
• Más app servers
• Pusher
• La million dollar idea estodo un exito!
21. Trabajando en conjunto
• Mas killer features
• Third party services
• Performance issues
• NewRelicProfesional
– Redisparasesiones
– Memcached fragment cache
22. Nuevas feature
• Share with your friends!
– Mastráfico
– Base de datos, el nuevocuello de botella
– Dobletea la capacidad!
• Actualizaciones en tiempo real
– Estanmatando los app servers!
– Migrar a app servers diseñadosparasoportar
forking
23. Nuevas features
• Background processing
– Resque al rescate!
• Phew, ya se teniaredis
– Mismosrecursos
• Mejoresestrategias de cache yexpiración
• Todobajo control.
24. Noticias del CEO
• Nuestraaplicacionva a ser promocionada en
un canal de television a nivelnacional!!
– OMG, a correr!
– Pronostico: 3x trafico del picomás alto a la vez
• Triplicar la capacidad?
• Click, click, click…. Listo
– Al final de més, “quequuueee, yestafactura?”
– En pocotiempoya se estanusandoesosrecursos
25. Noticias del CEO
• Necesitamos uptime de 99.997
– Deployment transparentes
– Mascapacidad
– Staging environments
26. Deuda de Ingenieria
• Muchos ‘add ons’
• Facturaciónva en aumento
• Ambientes de staging ‘iguales’ queproduccion
– QA
• Sincronizacion de datosdesdeproducción
– Base de datos
– Imagenes
– Usuarios, actualizar emails con ficticios
• Etc. == $$$$$$
27. Deployment desde cero
• Rails stack
– Web server
– Balancer/proxy
– App servers
– Database server
– Fulltext search engine
– Cache
– Deployment scripts
– Bootstrapingnuevosservidores
34. Dejandorastros – Rails side
• Reemplazar Rails Logger
– Una sola linea, se hace ‘grepable’
• Enmascarardatossensitivos
– Rails.config.filter_parameters+=
[:card_number, :cvv]
35. Problemascomúnes
• RepositoriosPrivados
– Crearcuentacompartiday registrar llaves de los
servidores
• Firewalls
– bundle pack
• Gems paradesarrollo con
dependenciasespeciales
– bundle install –without development test
36. Capistrano
• Herramientaparahacer de
maneraconsistente, repetitivaygarantizada, de
ployments de aplicaciones.
• Scripts (recipes)
– Ejecutan commandos de maneraremota via ssh
45. Migrando una app de servidores
físicos a una nube privada con ~15
mins de downtime
46. EventosPrincipales
• 8 Meses antes
– Se empezó a experimentar con Joyent smart
machines
– Complian con los SLA(Service Level
Agreement)internos
• No eraninstanciasvirtuales
• Son delimitadasporzonas
• No son ambientesvirtuales
• Rentaera mensualfijay no porusage
• SmartOS(solaris)
47. EventosPrincipales
• 6 Mesesantes
– Environments de demo se instalaron
• Todo en una sola instancia
– Nginx, mysql, RoR app
– JoyentproveiaPercona Smart Machines
• Joyenttrabajo con Perconaparacompilar lo
masoptimizado los binarios
• La aplicacion se migró a percona 5.1 de mysql 5.0.56
48. EventosPrincipales
• 4 Meses antes
– Ambiente de Staging en Joyent
• Se diseñoparadespues ser promovidocomo elnuevo
cluster de produccion
• 2 clusters
– 1 balanceador
– 8 app servers
• Percona smart machine
– 1 Master
– 2 replicas
– Se compro un nuevodominio
49. EventosPrincipales
• 3 meses antes
• Los Sysadmins se empezaron a quedarcalvos
– El ataque de ImageMagick!!!
– Se usabangemasespecificasparalinux
• Leianmac addresses, en zonas, no se tieneacceso a
lasmac address desde un solaris
• UUID generator estabaroto, lassesionescolisionaban
50. EventosPrincipales
• 2 Meses antes
– Incertidumbrepor el rendimiento
• Se hizo un stress performance muydetallado
• Httperf, ab, loadrunner
• Se optimizaronconfiguraciones
– HAProxy, queue time yestrategia de balanceo, last connection
vs round robin
– Nginx, se recompiloparausarotrodirectorio temporal
– MySQL, innodb buffer size al 70% de
memoriayarchivoportabla
51. EventosPrincipales
• 1.5 meses antes
– Si! Si lo hacemos…. ( comprandomisboletos a San
Francisco, uno con el viaje normal yotro con
regreso al diasiguiente )
– Trabajoexaustivo con
capistrano, debiasoportarhacer deployment a dos
ambientes
52. EventosPrincipales
• 1 Mes antes
– Se configuró la replica mysql multi-site
• El slave en joyent se promoveriacomo el master el dia
del movimiento
• En promedio 17 minutosatras del master
– En vez de usar el cluster de stage
comoproducción, se contrataronunoslimpios, se
corrieronlasrecipies de chef ycapistrano
• ImageMagick again!!! grrrrrr
54. EventosPrincipales
• 1 Semana antes
– Se saco un respaldocompleto de producciony se cargo en
la replica en joyent
• Replicacion multi-site trabajandobien
– 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 teniamospaginas de mantenimiento!!!! (alguiengritandole a los
diseñadores)
55. EventosPrincipales
• 2 dias antes (Lunes)
– Oh no!!! No teniamostareas de
capistranoparaactivarlasreglas del nginx
– Se puso la pagina de mantenimientoque los
diseñadoreshicieron
– Todobajo control, a descansar
57. EventosPrincipales
• El Dia de la migracion
– SysadminsyDevOpsllegando a la oficina ~5pm
– Ultimo dump de produccion se carga en la replica
• Oh ho!, la vpnextremadamentelenta, 8pm ydecia 14000
seconds behind master, shit!
• Se hizo un tunelsshpor la interface externa (viajandopor
internet), en 14 minutos se sincronizo
• Todolisto
58. EventosPrincipales
• Despues de 11pm
– Se empezotardepor la replica lenta
• Pagina de mantenimiento
• Esperarbackgrond jobs terminaran
• Apagartodos los app servers
• Esperar la replicaterminara de sincronizar master y se
promoviocomomaster
• Arrancar la aplicacion en joyent con el nuevo master
– Todoestonostomo 7 minutos!
59. EventosPrincipales
• Validando la aplicacion
– QA validopor un dominio especial
– 8minutosdespues, dio sign off
– Seactivaronlasredirecciones en nginx multi-site
– Se cambio el dns
– A rellenar la cafetera!
– 2 minutosdespues, callo la
primeraorden,Fiuuufff!!!!!
60. EventosPrincipales
• 3 hrs despues de la migracion
– ImageMagick issues!!
• Crap! Algunasimagenes se servianpor
PNG, eImageMagick no fuecompilado con soporte
PNG, a recompilartodos los clusters
– Se prendieronserviciosexternos
– Se levantootrareplicacionmuti-site de joyent a
rackspace
– Se arrancanaplicacionesinternas
61. EventosPrincipales
• 8am diasiguiente
– Ya se puedenir a dormir
– En el camino
• Riiiing! “El distribution center no recibeordenes!”
• Problemas de replicacion de dns, no se hizoreplicacion
multisite paraaplicacionesinternas, se harcodeo la
nueva IP en /etc/hosts, solved…
– A Dormir
62. Eventosprincipales
• Despues de la migracion
– Performance issues
• Base de datos 5x maslenta, nadiesabiaporque
– Servidormasgrande
– Filesystem mucho muytuneado
– Al final, despues de 2 semanas, se encontro el problema:
binarioscompilados con gcc 3.x, great! |-(
• Ruby poor performance, no tomabalas environment
variables del REE paratunear el garbage collector
• El directoriotmp se hizomasgrande
63. EventosPrincipales
• Al final:
– 20 ms mas lento que en rackspace
– 60% menos de facturacion
– Podemoscrecer on demand
– Sobrevivimosunaventa con un pico de 21k
rpm,350 clicks porsegundo!!!!