Developing Frogtek

El blog del Departamento de Tecnología

Mes: octubre 2017

Amazon Aurora: primeras experiencias

Este post es un resumen de como ha sido nuestra transición de un MySQL gestionado por nosotros mismos a Amazon Aurora: las cosas que nos han gustado mucho, las que nos han gustado menos, y cómo hemos tenido que cambiar algunos de nuestros procesos para adaptarnos a las particularidades y oportunidades de esta manera de acceder a los datos.

En febrero de 2016 ya había leído algunas cosas sobre Aurora: que era un servicio MySQL compatible, que prometía rendimientos muy superiores, más concurrencia, poder tener copias read only con latencias bajísimas y todo esto sin tener que preocuparte de desplegar instancias EC2 ni configurar servicios. Sonaba bien…Nombro febrero de 2016 porque en ese mes acudí al evento Data Analytics at AWS en Barcelona  y allí nos dijeron que Aurora era el servicio que más rápidamente había crecido en la historia de AWS y toda una suerte de bondades. Está claro que en un evento patrocinado por la empresa que lo desarrolla van a subrayar sus fortalezas frente a sus debilidades, pero con todo y con eso debo confesar que me volví en el tren pensando “y por qué no pasamos de nuestro MySQL y empezamos a usar Aurora”.

Creo que aquí vendría bien dar un poco de contexto. En Frogtek usamos diferentes tecnologías dependiendo de las preguntas que queremos hacer a nuestros datos. Una de ellas es MySQL. Antes de Aurora, teníamos un cluster master slave gestionado por nosotros mismos corriendo sobre instancias EC2. Este escenario cubría una doble necesidad: darnos alta disponibilidad y poder lanzar determinados procesos pesados contra la instancia slave.

Sin embargo este modelo nos causaba algunos problemas:

  • El nodo esclavo fundamentalmente lo usábamos para contestar SELECT pesados sin “molestar” al master. Pero teníamos problemas de sincronización, sufríamos desfases entre los datos que manejaba el master y el slave, algunas veces de minutos. Esto, aunque no era muy común nos generaba incertidumbre y una sensación de “no me puedo fiar de los datos del esclavo” por lo que ese nodo perdía gran parte de su funcionalidad.
  • Debíamos gestionar nosotros las copias de seguridad. Hacerlas, comprobarlas, almacenarlas. No son tareas muy complejas pero llevan tiempo.
  • Debíamos tunear nosotros la base datos.
  • Ocuparnos de la actualización del MySQL y del SO que corría por debajo. Gestionar el tamaño de las particiones, los EBS…

A priori Aurora tendría que solucionarnos estos problemas, así que en marzo del año pasado nos liamos la manta a la cabeza y migramos nuestra infraestructura MySQL a Aurora. El proceso de migración no fue muy doloroso: restauramos una copia de seguridad en Aurora, suscribimos nuestro nodo Aurora al MySQL gestionado por nosotros y cuando comprobamos que todo estaba bien lo promocionamos a master. Antes de hacerlo nosotros a mano, probamos el AWS Database Migration Service  pero no nos acabó de convencer. Seguramente porque cuando lo probamos nosotros estaba en beta, pero las pruebas que hicimos no nos acababan de funcionar bien.

Nuestro Aurora tiene un nodo master y un reader. Al poco de empezar a usarlo se nos presentó el primer problema. El endpoint del cluster no balanceaba automáticamente las peticiones entre nuestros nodos. Realmente no es que funcionara mal, nosotros pensábamos que lo haría y resultó que no, por lo que necesitábamos seguir configurando a mano nuestras aplicaciones para balancearlas. Este comportamiento lo solucionó ya AWS  en septiembre del año pasado y ahora puedes apuntar todo al endpoint del cluster y el solito va mandando las SELECT a alguno de los reader.

Esta son algunas de las cosas que nos han gustado del servicio, se van incluyendo nuevas funcionalidades periódicamente. Por ejemplo, desde que nosotros empezamos a usar Aurora hasta ahora han añadido:

  • Clonado de instancias.
  • Balanceo automático entre instancias.
  • Llamadas a una función de AWS Lambda desde un procedimiento almacenado.
  • Cargar datos desde AWS S3.

La gente de Percona, que inicialmente fueron bastante críticos con Aurora hicieron un test de rendimiento en 2015 y lo repitieron unos meses después y vieron una evolución positiva en el servicio.

Y ya que estamos con lo que nos ha gustado:

  • Servicio 100% gestionado. Dedicamos poquísimo tiempo al mantenimiento de la BBDD. Por ejemplo, la ampliación del disco es automática  y escalar horizontal y verticalmente es realmente sencillo.
  • Antes hacíamos las copias de seguridad con dumps que podían necesitar horas para terminar. Con los snapshot lo hemos reducido a minutos. En las restauraciones ganamos incluso más.
  • Poder levantar una base de datos exactamente igual a la de producción en minutos para poder hacer pruebas.
Pero no todo ha sido bueno, hay cosas que no nos han gustado y que hay que tener en cuenta si migras a Aurora desde un servicio gestionado por ti:
  • No vas a tener el privilegio SUPER de la base de datos. Así que no vas a poder matar conexiones o consultas de otros usuarios. Aurora soluciona eso con CALL mysql.rds_kill(ID) y
    CALL mysql.rds_kill_query(ID).
  • No vas a tener el permiso FILE. Si vas a poder seguir haciendo esto, por ejemplo: “LOAD DATA LOCAL INFILE ‘/home/ficherocarga.csv’” pero no vas a poder hacer un “SELECT * FROM really_big_table INTO OUTFILE ‘fichero’”.
  • Como no tienes acceso al sistema de ficheros que está usando por debajo, hay herramientas de MySQL que no vas a poder usar. Por ejemplo, XtraBackup (aunque si puedes restaurar una copia hecha con esa herramienta en Aurora), sin embargo  podrás seguir usando otras muy útiles como pt-online-schema-change
  • El precio. No es un servicio barato precisamente.

Desde el punto de vista del rendimiento, cuando nos planteamos Aurora, además de quererlo para quitarnos trabajo de gestión de la BBDD queríamos ver si era posible usarlo como base de datos para consultas analíticas sobre tablas de tamaño medio (decenas de millones de tuplas). Típicas consultas con agregaciones más o menos complejas usando ventanas temporales amplias. Vimos que no, que Aurora en este caso de uso no aportaba mucho a lo que ya habíamos vivido con el MySQL gestionado por nosotros. La sensación (confirmada con los test que hicieron en Percona) es que es un servicio que admite mucha concurrencia de consultas y conexiones pero el que una única consulta no va a ser más veloz o mucho más veloz que un MySQL normal. Por lo que nosotros seguíamos teniendo consultas que tardaban horas en finalizar. Cómo resolvimos esto lo contaremos en otro artículo, pero diré a modo de resumen que en nuestro caso Aurora no nos sirvió como BBDD analítica. Además, en este sentido, se echa de menos que la implementación SQL de Aurora no incluya, por ejemplo, funciones de ventana.

En definitiva,  estamos contentos con la decisión que tomamos. Nos ha ahorrado mucho tiempo en tareas de gestión y sobre todo nos ha dado tranquilidad y confianza en la capa de almacenamiento. No sustituye una base de datos OLAP, pero esto era un extra y aún sin eso, en nuestro caso, tenía sentido la migración.

Sobre la descentralización del talento

A principios de septiembre incorporamos a dos programadores nuevos al equipo, hasta la  semana pasada no nos conocimos en persona (en 3D), ésta semana ya se han ido y no volveremos a coincidir, como pronto, hasta enero.

Frogtek España es un equipo distribuido que trabaja en remoto. Probablemente hace ya años que lo somos porque, aunque sólo hace dos años que nos instalamos en el 80%-100% de teletrabajo, desde siempre hemos colaborado con latinoamérica separados, inevitablemente, por miles de km de distancia y unas 7 horas de diferencia. Y los últimos hechos no hacen sino confirmar esta afirmación ya que hemos unido al equipo a dos personas de la provincia de Córdoba que ni siquiera viven en la misma ciudad. Así que en los stand-up matutinos nos hablamos desde Huesca, Zaragoza, Vitoria, La Orotava, Córdoba y Añora… y por la tarde ya le ponemos el toque exótico añadiéndole cuatro personas en la Ciudad de México que, aunque no forman parte de Frogtek España, sí lo hacen del equipo de Tecnología.

Llegar hasta aquí no ha sido un camino rápido, ni siquiera premeditado. Frogtek, como casi todas las empresas, nació con una sede que visitábamos cinco días a la semana, mañana y tarde. Una sede en un pequeño Parque Tecnológico de una ciudad sin una gran cantera de programadores, cercana a la ciudad-región por antonomasia (Zaragoza) mucho mejor dotada en cantidad de casi cualquier cosa (excepto restaurantes con estrellas Michelín). Pero hacer 75 km dos veces al día, día sí y día también es bastante cansado y caro y pronto le fuimos perdiendo el miedo, unos (ellos), a pedir días de teletrabajo, otros (yo principalmente), a trabajar con un equipo que no ve. Primero cayeron los viernes, el eslabón más débil de la cadena. Al tiempo cayeron los lunes y así estuvimos una temporada con un 40% de teletrabajo que circunstancialmente llegaba a convertirse en un 60% o un 80%, cuando no quedaba otro remedio. Pero fue a principios de 2015 cuando tomamos la decisión de reducir nuestras visitas a la oficina a un solo día a la semana, opcional y sólo de la gente que vivimos a menos de una hora de Huesca, dejando que el resto practique un 100% de teletrabajo. La excepción a esta regla es cuando, una semana cada tres o cuatro meses, nos juntamos todos para vernos en persona e irnos de cena y de excursión por la montaña (también hacemos retros, priorizamos tareas y hasta curramos, pero eso es secundario). Todo esto que nació de a) la tozudez del que “fundó” Frogtek España en Huesca porque él vivía allí (hay gente pa tó) y b) la “pereza” de los de Zaragoza para hacer 75km de autovía, se ha acabado convirtiendo en, primero, una gran ventaja competitiva para nosotros y, segundo, un pequeño ejemplo de lo que a muchos nos gustaría que fuera más normal en España.

La ventaja competitiva es clara y empieza por dejar de preocuparte por dónde están las personas en el equipo. Si uno de ellos se quiere volver a Tenerife, si otro tiene que pasar un año en Tortosa, si a la pareja del de más acá la destinan a Vitoria o si cualquiera se quiere ir un mes en verano a su pueblo, ninguna de esas situaciones tiene por qué convertirse  en un problema para nadie. Por otro lado está el tan manido acceso al talento allá donde esté, aunque yo le daría la vuelta a la frase: más que acceder al talento allá donde esté, se trataría de permitir que el talento vaya allá donde quiere estar y no me refiero a una empresa, me refiero a una ciudad, a un pueblo o a donde sea que se quiera vivir. Si algo me ha enseñado este último proceso de selección es que hay mucha hambre, en el buen sentido, por poder trabajar en proyectos interesantes sin tener que sacrificar tu vida en el altar de Madrid y/o Barcelona, con perdón de quienes consideran que son ciudades estupendas para vivir. Hemos recibido candidaturas, por supuesto, de Huesca y Zaragoza, pero también de almerienses que no querían ir a Madrid, o de lucenses o extremeños que querían salir de Barcelona o Madrid y a los que sus empresas, la mayoría multinacionales, solo les ofrecía uno o dos días de teletrabajo. Hemos recibido un gran porcentaje de candidatos atraídos principalmente por estas dos palabras: “trabajo remoto”. Semanalmente veo las ofertas que aparecen en la Bonilista, por poner un ejemplo de ofertas de empresas talentosas y atractivas, y lo cierto es que son realmente imaginativas e interesantes: horario flexible, días de teletrabajo, comida saludable (y de la otra) gratis, mesa de ping-pong, tráete tu mascota, date un masaje, aprende idiomas… eso sí, hay pocas que digan: Trabaja dónde quieras. Todos los días. Punto. ¿Por qué? Con las grandes empresas y sus enormes y, las más de las veces, burocratizados departamentos el panorama no es muy distinto. Seguramente a los snacks gratis se les una un plan de pensiones, un seguro de salud privado y  los consabidos uno o dos días de teletrabajo pero, en estos casos supongo que pasar de esos simbólicos días en casa al remoto total es mucho más complicado. Y no lo estoy criticando, el teletrabajo parcial es muy útil, nos ha permitido a muchos organizarnos mucho mejor y conciliar el trabajo con todas esas otras cosas que te pasan antes, durante y después del trabajo, la vida, e imagino que es muchísimo más agradecido si vives en una gran ciudad en la que moverse para hacer cualquier gestión, o simplemente ir al centro, cuesta el mismo tiempo que desde Huesca, bajar a Zaragoza, plantarte en Ordesa o pasar la ITV+cambiar tu empadronamiento+pasar por el banco+renovar DNI+pasaporte del tirón (sí, en hora y media, es posible). El teletrabajo parcial es un avance pero, para muchas personas, no ataca el problema fundamental y es que la gente quiere trabajar en su casa, entendiendo “su casa” en sentido amplio, es decir, aquel sitio que te permite realizarte mejor como persona… o, simplemente, allá donde te apetece estar en cada momento. Así que, aunque no ha sido premeditado, aunque ha sido por pura comodidad, el hecho ser un poco pioneros en el trabajo 100% distribuido en España, es una de nuestras grandes ventajas competitivas. Genial.

Sin embargo, dejando al margen lo que le interesa a Frogtek y centrándonos en lo que nos interesa a los profesionales del sector y, por qué no decirlo, en lo que le interesa a la España vacía, creo que estamos ante una gran oportunidad que no deberíamos dejar escapar. Se habla mucho de todos los puestos de trabajo que la tecnología va a dejar obsoletos pero no tanto de todas las oficinas que podría vaciar, y menos aún del proceso de descentralización del talento que podría conseguirse. Huesca es la segunda ciudad de Aragón, sin embargo es sólo la quinta ciudad con más aragoneses de España: Madrid, Barcelona, Valencia suman muchas Huescas en su interior (y alguna que otra Zaragoza). Huescas compuestas por personas que tuvieron que marcharse de casa ya para formarse y que acabaron “exiliadas” para poder trabajar de lo suyo. Y quien dice Huesca, dice Teruel, dice Soria, Segovia, Cuenca, Zamora, Palencia, Lugo… dice Cáceres… ciudades donde se vive bien y se trabaja mal eclipsadas por ciudades donde se vive mal pero se trabaja bien. Resulta paradójico todo el tiempo, dinero y talento que invertimos muchos en formarnos para ganarnos una vida peor y pasarla anhelando una mejor, con los nuestros o adondequiera que nos apetezca estar y que no suele coincidir con donde tenemos que estar. Por eso, en un sector como el TIC, casi completamente digital, con un gran valor añadido, llamado a liderar la economía, en un sector en el que sí se puede estaría bien empezar a pensar en volver a casa, en devolver ese conocimiento y esa riqueza a unas zonas que han aportado tantas ausencias, tanto tiempo, tanta nostalgia y soledad y que a cambio solo reciben una visita los puentes largos y lo que nos sobra de las vacaciones que nos hemos ganado con nuestro destierro remunerado en la capital.

¿Se va realmente a producir esta descentralización? No lo sé. ¿Se puede ayudar a que esto pase de alguna manera (aparte de predicando, con el ejemplo, en el desierto… demográfico)? No lo sé. ¿Defenderé lo mismo si un día nuestro equipo es de 50 o 100 personas en lugar de 12? No lo sé. ¿Podré seguir trabajando en remoto el día que no esté en Frogtek? No lo sé. ¿Será mi primera prioridad a la hora elegir un nuevo proyecto? Eso sí lo sé.