Configuración guiada por búsqueda de aplicaciones basadas en microservicios en la nube

Configuraci´on guiada por b´usqueda de aplicaciones basadas en microservicios en la nube Jos´e Antonio Parejo1*, Aurora Ram´ırez2, Jos´e Ra´ul Romero2, Sergio Segura1y Antonio Ruiz-Cort´es1 Dpto. de Lenguajes y Sistemas Inform´aticos, Univ. de Sevilla1, Dpto. de Inform´atica y An´alisis Num´erico, Universidad de C´ordoba2 [email protected],{aramirez,jrromero}@uco.es,{sergiosegura,aruiz}@us.es Resumen Organizaciones como Netflix, Google o Amazon hacen uso de arquitecturas basadas en microservicios, lo que ha disparado el inter´es de la comunidad en ingenier´ıa del software por este estilo arquitect´onico. No obstante, el buen uso de este estilo arquitect´onico supone nuevos retos, como determinar qu´e instancias de servicios se despliegan o establecer la mejor configuraci´on de la nube que los aloja, conforme a la carga de trabajo esperada para cumplir los Acuerdos de Nivel de Servicio. Se trata de un problema de optimizaci´on en el que deben considerarse simult´aneamente m´ultiples propiedades, a menudo en conflicto entre s´ı. Por ello, tras formular este caso como un problema de b´usqueda, se discutir´a c´omo el uso de t´ecnicas multi-objetivo puede mejorar las soluciones actuales, permiti´endonos escoger los proveedores y configuraciones apropiadas para disminuir los costes de explotaci´on, y asegurar la disponibilidad de los servicios cr´ıticos sin empobrecer el tiempo de respuesta. Keywords: microservicios, optimizaci´on multi-objetivo, cloud computing, Acuerdos de Nivel de Servicio 1. Introducci´on La evoluci´on de las arquitecturas distribuidas ha desembocado en la definici´on de un estilo arquitect´onico denominado arquitectura basada en microservicios. Este estilo arquitect´onico ha sido aplicado con ´exito en organizaciones como Google, Ebay [5], Netflix [4], o Amazon [2] para aplicaciones con cargas de peticiones masivas que deben ofrecer tiempos de respuesta bajos, y alta disponibilidad. En este tipo de aplicaciones los distintos m´odulos o historias de usuario de la aplicaci´on se implementan como servicios web RESTful independientes. De esta forma, se alcanza un nivel de modularidad que facilita el control del redespliegue en ´unicamente aquellas partes que soportan mayor carga de trabajo y, consecuentemente, evitan el uso indiscriminado de la infraestructura. *Este trabajo ha sido sufragado parcialmente por la Comisi´on Europea(FEDER), y los gobiernos de Espa˜na y Andaluc´ıa mediante los proyectos BELI (TIN2015-70560-R), THEOS (TIC-5906), COPAS (TIC-1867) y TIN2014-55252-P, la Red de Excelencia SEBASENet (TIN2015-71841-REDT) y el programa FPU (FPU13/01466). 2 J.A. Parejo, A. Ram´ırez, J.R. Romero, S. Segura, A. Ruiz-Cort´es Sin embargo, diversos autores han se˜nalado que, junto con las ventajas que ofrece este estilo arquitect´onico, aparecen tambi´en nuevos retos y decisiones a tomar. Una de ellas es determinar la manera en que los microservicios se distribuir´an en las distintas m´aquinas virtuales (MVs) en el caso de realizar un despliegue en la nube. Concretamente, con el objetivo de aprovechar la elasticidad y el modelo de pago por uso que se emplea normalmente en la nube se hace necesario decidir: i) las MVs que se van a usar y sus caracter´ısticas concretas, ii) cu´antas instancias de cada microservicio se van a desplegar, y en qu´e maquinas virtuales concretas lo har´an, y iii) las reglas de escalado a aplicar sobre la infraestructura y los microservicios para adaptarse a la carga de trabajo conforme a los Acuerdos de Nivel de Servicio (ANS) establecidos. En este art´ıculo, se presenta y formaliza este problema, identificando un conjunto de objetivos de inter´es que lo configuran como un problema multi-objetivo susceptible de ser abordado mediante t´ecnicas de b´usqueda. 2. Ejemplo motivador Supongamos una aplicaci´on de gesti´on de personal donde se controla el horario, acceso a las instalacciones, y las tareas que realizan los empleados de una organizaci´on durante su jornada de trabajo. Dichas tareas corresponden adem´as a diversos proyectos que la organizaci´on desea gestionar. Podr´ıamos identificar 4 microservicios: gesti´on de usuarios, gesti´on de instalaciones y control de acceso, gesti´on de tareas y proyectos, y gesti´on de sesiones de trabajo (que asocian a usuarios con tareas concretas durante un n´umero de horas). Cada microservicio podr´ıa tener asociado una base de datos (BD) para la gesti´on de su informaci´on, que es compartida por todas sus instancias, y se tendr´a adicionalmente un registro de instancias de servicios disponibles que es a su vez otro microservicio. El esquema de despliegue m´as simple posible, es aquel en el que todos los microservicios y bases de datos se despliegan sobre la misma MV, y no se realiza ning´un tipo de escalado en base a la utilizaci´on. Uno de los esquemas de despliegue alternativo posibles es aquel en el que hay 2 MVs, y cada microservicio tiene un ´unico despliegue en alguna de las MVs. La figura 1 muestra ambos esquemas como diagramas de componentes UML decorados. 3. Configuraci´on de aplicaciones basadas en microservicios en la nube Sea S={s1, . . . , sn}el conjunto de microservicios a desplegar en la nube. Sea N={n1, . . . , nMaxMV }un conjunto de m´aquinas virtuales, cada una con una configuraci´on de proveedor de cloud determinada. Sea C={c1, . . . , cl}el conjunto de configuraciones posibles de m´aquinas virtuales proporcionadas por un conjunto de proveedores de infraestructura en la nube. Una configuraci´on de la arquitectura cloud viene determinada por el valor de las variables: xi,j ,yi,j, yzj, ST y GT. Donde xi,j son variables binarias que indican si el microservicio Configuraci´on de apps basadas en microservicios: un problema de SBSE 3 Figura 1. Dos opciones de despliegue para nuestro ejemplo iest´a despegado en la MV j, para cada valor de i, al menos una variable tiene un valor de 1, es decir, todo microservicio se despliega en al menos una MV. Las variables binarias yi,j indican si la BD asociada al microservicio iest´a desplegada en la MV j, para cada i, solo una variable tiene un valor de 1, es decir, la BD de cada servicio se despliega en una ´unica MV. Las variables zj∈Cindican la configuraci´on concreta de la MV j.GT indica el l´ımite de utilizaci´on de las MVs a partir del cual se aplicar´a una regla de crecimiento de la infraestructura (se instanciar´a una nueva VM y se desplegar´an nuevas instancias de los microservicios con m´as carta), y ST que indica el l´ımite de utilizaci´on de las MVs a partir del cual se aplicar´a una regla de reducci´on de la infraestructura (se destruir´a una VM). Obviamente, 0 ≤ST < GT ≤100, donde 100 significa una utilizaci´on m´axima de la potencia de computaci´on de las VMs instanciadas actualmente. MaxMV es el l´ımite m´aximo de MVs que se pueden desplegar para una configuraci´on. Dado un conjunto Ade ANSs acordados con distintos usuarios, y una carga de trabajo esperada ωpara un periodo de tiempo concreto (que especifica el volumen de peticiones que se realizar´an en cada instante para cada servicio y el ANS concreto que corresponde a cada una), un conjunto interesante de objetivos a optimizar para una instancia de este problema ser´ıa: Minimizaci´on del coste total de la infraestructura D(ω, x, y, z). Este objetivo pretende minimizar el coste total del despliegue calculado como el sumatorio del coste de cada MV, que depende a su vez de la configuraci´on de dichas VMs. 4 J.A. Parejo, A. Ram´ırez, J.R. Romero, S. Segura, A. Ruiz-Cort´es Minimizaci´on del n´umero de puntos ´unicos de fallo F(x, y, z). Si un microservicio no est´a replicado, ese ´unico despliegue supone un punto ´unico de fallo para la l´ogica de la aplicaci´on. Este objetivo pretende minimizar el n´umero de puntos de este tipo sobre todo el conjunto de microservicios, para hacer la aplicaci´on lo m´as robusta posible. Minimizaci´on del tiempo de respuesta medio T(ω, x, y, z). Dependiendo del n´umero de despliegues, la configuraci´on de las MVs y el perfil de carga de peticiones de cada servicio, tendremos un tiempo medio de repuesta para las peticiones. Este objetivo pretende minimizar dicho tiempo. Minimizaci´on del n´umero de violaciones de los ANS V(A, ω, x, y, z). Dado un conjunto de ANSs con los distintos usuarios, es posible simular el comportamiento del sistema bajo un determinado perfil de carga de peticiones por usuario. Esto permitir´ıa calcular el n´umero de peticiones para las que se han incumplido los ANS. Minimizaci´on del n´umero de reconfiguraciones en la arquitectura R(A, ω, x, y, z). Una reconfiguraci´on es la instanciaci´on o parada de una MV, con los correspondientes despliegues de servicios y BDs. Pueden existir limitaciones o costes asociado a las reconfiguraciones. Establecer el equilibrio apropiado entre objetivos contrapuestos como el coste y el tiempo de respuesta va a depender en gran medida de las preferencias de los usuarios. Adem´as, dado que cada MV puede tener asociado un gran n´umero de configuraciones (m´as de 17.000 para Amazon [3]), el espacio de b´usqueda resultante es enorme. Por ello, planteamos la necesidad de abordar este problema de optimizaci´on multi-objetivo mediante t´ecnicas de b´usqueda heur´ısticas. En concreto, los algoritmos evolutivos multi-objetivo (MOEAs) nos permitir´an explorar de manera eficiente el espacio de configuraciones, estableciendo diferentes compromisos entre los criterios de calidad. En cuanto al trabajo futuro, pretendemos estudiar las caracter´ısticas del problema para aplicar MOEAs, ya que puede ser necesario aplicar t´ecnicas avanzadas dado el n´umero de objetivos definidos. Para ello utilizaremos datos reales de Amazon, y el simulador CDOSim [1]. Referencias 1. Fittkau, F., Frey, S., Hasselbring, W.: Cdosim: Simulating cloud deployment options for software migration support. In: 6th IEEE Int. Workshop on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems. pp. 37–46 (2012) 2. Fulton, S.M.: What led amazon to its own microservices architecture. Web Page (2015), http://thenewstack.io/led-amazon-microservices-architecture/ 3. Garc´ıa-Gal´an, J., Trinidad, P., Rana, O.F., Ruiz-Cort´es, A.: Automated configuration support for infrastructure migration to the cloud. Future Generation Computer Systems 55, 200–212 (2016) 4. Mauro, T.: Adopting microservices at netflix: Lessons for architectural design. Blog entry, https://www.nginx.com/blog/ microservices-at-netflix-architectural-best-practices/ 5. Shoup, R.: Service architectures at scale: Lessons from google and ebay. Talk at InfoQ.com, http://www.infoq.com/presentations/ service-arch-scale-google-ebay