Departamento de Sistemas y Computación
Grupo de Comunicaciones y Tecnología de Informaciónde - COMIT
Análisis de elasticidad y tolerancia a fallos
en Arquitecturas de Aplicaciones Web:
Arquitecturas Reactiva y Microservicios
Oscar Kiyoshige Garcés Aparicio
Trabajo de grado presentado para optar
por el título de Magíster en Ingeniería de Sistemas y Computación en la Universidad de los Andes
Diciembre, 2015
Tabla de Contenidos i
Índice de ilustraciones iii
Índice de Tablas iv
1 Introducción 1
1.1 Contexto . . . 1
1.2 Descripción del Problema . . . 2
1.2.1 Objetivo General . . . 2
1.2.2 Objetivos específicos . . . 3
1.3 Contribución de la Tesis . . . 3
1.4 Organización del documento . . . 3
2 Contexto 5 2.1 Arquitecturas Monolíticas . . . 6
2.2 Sistemas Distribuidos . . . 7
2.3 SOC, SOA y Microservicios . . . 8
2.3.1 Service Oriented Computing . . . 9
2.3.2 Service Oriented Architecture . . . 9
2.3.3 Microservicios . . . 10
2.3.4 Arquitectura Reactiva . . . 11
3 Estado del Arte 15 3.1 Elasticidad . . . 15
3.2 Tolerancia a fallos . . . 16
3.2.1 Benchmarks . . . 18
3.2.2 Benchmarks de Tolerancia a Fallos . . . 20
3.2.3 Benchmarks en Arquitecturas de microservicios y en Arquitecturas Reactivas . . . 21
4 Estrategia de Solución 22 4.1 Prueba de Elasticidad . . . 23
4.1.1 Objetivo . . . 23
4.1.2 Estrategia . . . 23
4.2 Prueba de Tolerancia a Fallos . . . 25
4.2.1 Objetivo . . . 26
4.2.2 Estrategia . . . 26
4.2.3 Métricas . . . 26
4.3 Software . . . 27
ii Tabla de Contenido
5 Validación 29
5.1 Prototipo . . . 29
5.2 Arquitectura Reactiva . . . 30
5.2.1 Play! Framework usando akka-clúster . . . 31
5.3 Arquitectura basada en microservicios . . . 31
5.3.1 Patrones de descubrimiento . . . 31
5.3.2 Tolerancia a fallos . . . 32
5.4 Selección del IaaS (Infrastructure as a Service) . . . 33
5.5 Ejecución de las pruebas . . . 33
5.5.1 Prueba de elasticidad . . . 33
5.5.2 Prueba de tolerancia a fallos . . . 36
6 Conclusiones y trabajo futuro 40
2.1 Imagen obtenida de [10] . . . 6
2.2 Relación entre SOC, SOA y Microservicios . . . 13
4.1 Proceso de pruebas de Software ISO-29119 . . . 22
4.2 Cambio de Carga en el tiempo: Número de solicitudes por unidad de tiempo . . . 24
4.3 Cambio de Carga y de recursos en el tiempo: Número de solicitudes por unidad de tiempo . . . 25
4.4 Cambio de Carga e inyección de fallos en el tiempo . . . 27
5.1 Prototipo desarrollado con Cluster de Actores . . . 32
5.2 Prototipo desarrollado con microservicios . . . 33
5.3 Resultados elasticidad - Arquitectura Reactiva . . . 34
5.4 Resultados elasticidad - Arquitectura basada en Microservicios . 35 5.5 Resultados Tolerancia a Fallos - Arquitectura Reactiva . . . 37
5.6 Resultados Tolerancia a Fallos - Arquitectura Reactiva . . . 37
5.7 Resultados Tolerancia a Fallos - Arquitectura basada en microservicios . . . 38
5.8 Resultados Tolerancia a Fallos - Arquitectura basada en microservicios . . . 39
Índice de Tablas
2.1 Diferencias entre SOA y Microservicios . . . 12
4.1 Configuración de prueba de carga para evaluar Elasticidad y Tolerancia y Fallos . . . 28
5.1 Requerimiento Funcional: R1 - Simular uso intensivo de CPU . . 30 5.2 Requerimiento Funcional: R2 - Retornar cuotas del proceso de
liquidación de un Crédito . . . 30 5.3 Resultados elasticidad - Arquitectura Reactiva . . . 34 5.4 Resultados elasticidad - Arquitectura basada en Microservicios . 35 5.5 Resultados Tolerancia a Fallas - Arquitectura reactiva . . . 36 5.6 Resultados Tolerancia a Fallas - Arquitectura basada en
microservicios . . . 38
1
Introducción
1.1 Contexto
En veinte años, la World Wide Web (web) se ha transformado en dos dimensiones. La primera, desde el tipo de servicios ofrecidos que consistían en la creación y acceso a contenido de tipo estático, sin cambios en el tiempo y creados por un grupo de usuarios. Ahora, el contenido es dinámico, ya que se modifica constantemente, en tiempo real y desarrollado por diversas fuentes como usuarios, dispositivos y sensores. Asimismo, han surgido aplicaciones que crean nuevos servicios y formas de comunicación entre los seres humanos. Estos servicios han traído como consecuencia nuevos modelos de negocios y nuevas metodologías de acceso e interacción con la información. Entre estos, se encuentran las plataformas de transacciones bancarias, pasarelas de pagos y plataformas para el comercio electrónico; plataformas de aprendizaje virtual y redes de colaboración (e.g., Foros, Redes sociales); y demás sistemas críticos y sensibles a fallos e.g., Sistemas críticos empresariales, telemedicina.
La segunda dimensión está relacionada con la población de usuarios capaces de acceder a la web. En el 2014, se estimaba que existía una penetración del 40% de la población global [1], lo que trae consigo aumento en la demanda de nuevos servicios, y cambios en las aplicaciones para satisfacer la demanda de acceso de grandes cantidades de usuarios de forma concurrente.
Estas transformaciones han causado que las aplicaciones web consideren dos requerimientos: la tolerancia a fallos, para así tener la capacidad de ofrecer aplicaciones sensibles a fallos y sistemas críticos; y la elasticidad, para soportar la demanda de los usuarios concurrentes. De esta manera, se han planteado soluciones desde la arquitectura computacional y la arquitectura de solución. Desde la arquitectura de infraestructura computacional se han desarrollado paradigmas como es el caso delCloud Computing, el cual permite la consolidación de sistemas elásticos y tolerante a fallos; los nuevos paradigmas generan nuevos retos y consideraciones al ser sistemas distribuidos. Desde el punto de vista de arquitectura de solución, se han elaborado propuestas con características adaptadas a este nuevo paradigma de infraestructura computacional. Ahora
2 1.2. Descripción del Problema
bien, para aplicaciones web han surgido dos arquitecturas de solución con estas cualidades y que además argumentan que son soluciones, en especial, de los requerimientos de tolerancia a fallos y elasticidad; estas son: Arquitecturas basadas en microservicios (en el desarrollo del documento se le denominan microservicios) y arquitecturas reactivas.
1.2 Descripción del Problema
Las arquitecturas reactivas y microservicios, han sido diseñadas para adaptarse a las transformaciones de la web. La primera como una solución a necesidades específicas de la web, en especial la tolerancia a fallos, cambios en tiempo real y la elasticidad. Por su parte, microservicios ha sido una adopción de grandes empresas e importantes aplicaciones web, e.g., Netflix, LinkedIn, con los propósitos específicos de generar ventajas en el desarrollo, cambios de las aplicaciones y elasticidad. Sin embargo, los autores presentan que se cuenta con los mecanismos y el diseño para la tolerancia a fallos.
En este sentido, los autores y defensores de las arquitecturas reactiva [2],[3] y microservicios [4] sostienen que se encuentran diseñadas para suplir con los requerimientos destacados en este trabajo, i.e. la tolerancia a fallos y la elasticidad; no obstante, no se cuentan con evidencias cuantificables que lo demuestren. Asimismo, no se encuentran herramientas para la toma de decisiones, como el caso de la elección de la arquitectura para los nuevos desarrollos de aplicaciones web que deban cumplir con estos requerimientos.
Existen múltiples definiciones, métricas y cálculos mediante los cuales se pueden cuantificar la elasticidad y la tolerancia a fallos, temas discutidos en profundidad en el capítulo 2. Las herramientas y técnicas existentes para la elaboración de pruebas de elasticidad y tolerancia a fallos, como Yahoo Cloud Serving Benchmark (YCSB) [5], Standard Performance Evaluation Corporation (SPEC) [6], Transactional Processing Performance Council (TPC) [7], que son especificaciones de las pruebas y los datos para sistemas de bases de datos transaccionales. Por otra parte, AUToCLES [8] y JMeter [9] son herramientas para la automatización de pruebas, con la limitante de no estar orientada a métricas de elasticidad y tolerancia a fallos. A pesar de su importancia, estas soluciones no proponen pruebas para aplicaciones web, ni estrategias para la validación de la tolerancia a fallos y elasticidad.
Lo anterior permite evidenciar que en la literatura no está presente una evaluación cuantificable de las arquitecturas relacionadas con los requerimientos resaltados; así como tampoco, un conjunto de pruebas de elasticidad y tolerancia a fallos sobre aplicaciones web, que permitan la toma de decisiones sobre la elección de una arquitectura para nuevos proyectos web.
Por consiguiente, esta investigación desarrolla los siguientes objetivos:
1.2.1 Objetivo General
Comparar las arquitecturas de aplicaciones web, reactiva y microservicios, para así evidenciar la más adecuada en los requerimientos de Tolerancia a fallos y elasticidad.
1.2.2 Objetivos específicos
1. Construir un prototipo de aplicación web que represente cada una de las arquitecturas estudiadas.
2. Seleccionar una definición y métricas para el cálculo de tolerancia a fallos y elasticidad.
3. Diseñar e implementar un conjunto de pruebas que permitan calcular la elasticidad y el porcentaje de tolerancia a fallos.
4. Analizar los resultados la elasticidad y el porcentaje de tolerancia a fallos en cada uno de los prototipos de las arquitecturas desarrolladas.
1.3 Contribución de la Tesis
• Contribución 1: Definir los conceptos de elasticidad, tolerancia a fallos y microservicios
La revisión de la literatura manifiesta que los conceptos de elasticidad, tolerancia a fallos y microservicios tienen múltiples definiciones. De esta manera, este trabajo tiene como contribución realizar una revisión de los conceptos para elaborar una definición propia de cada uno de los anteriores conceptos.
• Contribución 2: Crear herramientas para medición de elasticidad y tolerancia a fallos
Este trabajo exhibe un conjunto herramientas, definición e implementación de pruebas y herramientas de automatización, para la cuantificación de los requerimientos de elasticidad y tolerancia a fallos.
• Contribución 3: Comparar dos arquitecturas de aplicaciones web
Las actuales aplicaciones web pueden estar diseñadas con base en diferentes arquitecturas, entre las que se encuentran las arquitecturas reactiva y microservicios. Este trabajo consiste en la comparación de las arquitecturas con respecto a la efectividad en los requerimientos de tolerancia a fallos y elasticidad.
1.4 Organización del documento
Con el propósito de cumplir con los objetivos y contribuciones planteadas, este documento se divide de la siguiente forma: primero, en el contexto (capítulo 2) se construye una definición de los conceptos que aborda la tesis, arquitecturas reactivas y microservicios, así como también conceptualizaciones importantes
4 1.4. Organización del documento
para la elaboración de las definiciones, como lo son arquitecturas orientadas a servicios (SOA), arquitecturas monolíticas y sistemas distribuidos. Segundo, en la sección del estado del arte (capítulo 3) se abordan trabajos relacionados con las pruebas de tolerancia a fallos y de escalabilidad que se encuentran en la literatura, así como también trabajos relacionados con mediciones de desempeño de las dos arquitecturas seleccionadas. A continuación, en el capítulo 4 se describe la estrategia de solución plateada para el desarrollo del trabajo y su posterior validación e implementación en el capítulo 5. Por último, el capítulo 6 desarrolla las conclusiones y el trabajo futuro establecido para dar continuidad a la propuesta actual.
2
Contexto
En esta sección se describe el contexto relacionado con la web y las arquitecturas a estudiar. Esto incluye el desarrollo de los conceptos esenciales para la definición de las arquitecturas que se emplean en el desarrollo del documento. Primero, se debe conocer la diferencia entre los conceptos de arquitectura, modelo de referencia y arquitectura de referencia; luego dar una visión general de las arquitecturas utilizadas, en un principio, en aplicaciones web y sus problemas adyacentes. Luego, se describen las nuevas arquitecturas y metodologías para responder dos interrogantes, los problemas encontrados en las arquitecturas propuestas en un principio y los requerimientos definidos para este documento.
Para comprender el contexto del problema, es necesario agregar algunas definiciones. Bass et al. en [10] definen y describen las relaciones entre los diferentes conceptos, a saber, patrón de arquitectura, modelo de referencia y arquitectura de referencia. El primer concepto es una descripción de los elementos y sus relaciones, ambos conforman una familia de arquitecturas capaces de satisfacer unas restricciones dadas, en otras palabras, se solucionan en un problema específico. En [11] se cita “Cada patrón describe un problema el cual ocurre, una y otra vez en nuestro entorno, y luego describe la solución a ese problema, de la manera que se pueda usar esta solución un millón de veces [. . . ]" e.g., Un patrón arquitectural como Model-View-Controller (MVC) define tres componentes y desacopla la funcionalidad de la Vista, los datos y la lógica del negocio. Un modelo de referencia es definido como una descomposición estándar de un problema conocido en partes que cooperan para resolverlo e.g., El modelo de referencia TCP/IP describe las capas por las que deben pasar los datos en las comunicaciones entre dispositivos. Por último, una arquitectura de referencia es un modelo de referencia implementado en elementos de software y en el intercambio de datos e.g., implementación del modelo de referencia de TCP/IP.
En la Figura 2.1 se muestra las relaciones entre los diferentes conceptos desde lo general; sin embargo, es partir de las relaciones dirigidas que se evidencia mayor especificidad de elementos en el diseño, desde un diseño abstracto hasta una implementación determinada.
6 2.1. Arquitecturas Monolíticas
Modelo Referencial
Patrón Arquitectural
Arquitectura de Referencia
Arquitectura de Software
Figure 2.1 Imagen obtenida de [10]
Las anteriores definiciones permiten dar una mirada general al problema, para continuar con la explicación de las propuestas de arquitecturas de solución. En principio, las arquitecturas de solución se consideran monolíticas, fáciles de implementar y desplegar por los pequeños equipos de desarrollo, pero con desventajas en la escalabilidad, en la tolerancia a fallos y en equipos de desarrollo con diferentes especialidades y habilidades.
2.1 Arquitecturas Monolíticas
Las aplicaciones web se encuentran desarrolladas bajo una arquitectura distribuida denominada cliente-servidor. Normalmente, el cliente es un
Web Browser (navegador) (e.g., Safari, Google Chrome, Opera e Internet
Explorer) encargado de presentar información al usuario; mientras el servidor ejecuta una aplicación y retorna la información almacenada a los navegadores. Inicialmente, las aplicaciones web se encontraban desplegadas y diseñadas para ser almacenadas o desplegadas en un solo servidor. Al cual se le adicionaba la responsabilidad de responder a todas las solicitudes realizadas por los navegadores.
Precisamente, las arquitecturas descritas en este trabajo brindan soluciones en las aplicaciones alojadas del lado del servidor. La evolución de la web trajo consigo la transformación de diferentes conceptos, entre esos el de monolítico. Anteriormente, monolítica se denominaba a una aplicaciónstandalone diseñada para contener todas las funciones en un solo despliegue (e.g., Sistemas Operativos, desarrollos empresariales en sistemas como AS/400); mientras que soluciones distribuidas basadas en cliente-servidor no eran clasificados como tal. Hoy en día, los defensores de microservicios en [12] han extendido la definición de las aplicaciones monolíticas, para incluir las que pueden ser distribuidase.g., cliente-servidor, pero que en un solo servidor se encuentran todos los servicios disponibles. En ese sentido, Cockcorftet al. en [13] establecen que una aplicación monolítica es aquella en que los componentes se encuentran desplegados en un mismo proceso y se comunican mediante métodos regulares i.e. llamado al sistema, comunicaciones entre procesos, entre otros. Por su parte, Tammer Saleh en [14] describe que los sistemas monolíticos se encuentran conformados por grandes cantidades de líneas de códigos y funcionalidades acopladas; ambos
factores podrían presentar mayor cantidad de problemas, en especial, relacionado con la elasticidad y la tolerancia a fallos, debido a que existe un alto acoplamiento de la solución o a la generación de latencias y errores en sistemas dependientes de unMiddleware [15].
No obstante, los sistemas monolíticos presentan ventajas como se describe en [16] y que los autores logran listar:
1. La facilidad de desarrollo de un proyecto, se construyen componentes acoplados y dependientes, además los IDE’s (Integrated Development
Environment) actuales están diseñados para la implementación de soluciones
monolíticas. 2. Construcción de pruebas generales de las funcionalidades. 3. El despliegue, dado que solo se debe realizar el de una sola aplicación y en un único servidor. 4. Escalabiliad de las aplicaciones, la demanda de más recursos computaciones se puede solucionar asignándolos en una sola instancia (escalar verticalmente), o a través declúster de despliegues de una sola aplicación usando algún reverse proxy o balanceador de cargas). 5. No existen problemas ni la complejidad de los sistemas distribuidos.
La implementación de soluciones monolíticas presentan ciertas desventajas relacionadas con los altos costos de escalar aplicaciones y cumplir con el requerimiento de elasticidad. Estas generalmente están conformadas por una aplicación desplegada en un servidor robusto, responsable de toda la aplicación y de la información almacenada. Esto implica, si un fragmento de código o funcionalidad necesita una mayor cantidad de recursos computacionales no es posible asignárselos de forma exclusiva y controlada, sino a la aplicación completa.
Sin embargo, se incrementa la dificultad de desarrollo en equipos dada la cantidad de funcionalidades acopladas en un solo despliegue. Adicionalmente, los requerimientos destacados, la tolerancia a fallos y la elasticidad, recaerían en la capacidad del servidor. De esta manera, el sistema colapsaría frente a cualquier fallo en el servidor. Para esto se debe implementar mecanismos de tolerancia a fallos como Active/Standby failover,
Active/Active failover y redundancy, los cuales se hace una ampliación
conceptual en Sección 3, que no garantizan la continuidad del servicio.
Una vez identificadas estas desventajas en arquitecturas monolíticas, surgen arquitecturas desacopladas y pensadas para escalar, que en esencia se encuentran adaptadas a la elasticidad, como lo son los sistemas distribuidos y arquitecturas de microservicios.
2.2 Sistemas Distribuidos
Como se ha mencionado, las arquitecturas web en esencia son soluciones distribuidas, sin embargo para cumplir con los requerimientos de elasticidad y tolerancia a fallas, deben estar diseñadas e implementadas bajo arquitecturas de sistemas distribuidos más complejos y robustos.
Un sistema distribuido es un conjunto de computadores independientes, que tienen una determinada configuración e interacción con el fin de brindar un servicio (Tanenbaum en [17]); sin embargo, para el usuario final, esta interacción es transparente, lo que genera la apariencia de la existencia de un único recurso computacional. Una aplicación web puede estar diseñada bajo una
8 2.3. SOC, SOA y Microservicios
arquitectura distribuida, robusta y con mayor complejidad, bajo las restricciones y consideraciones generadas por este tipo de soluciones. Rotem-Ga-Oz en [18] recopila los planteamientos de autores como Peter Deutsch y James Gosling, sobre ocho consideraciones que se deben tener al diseñar sistemas distribuidos, como lo son:
1. La red es confiable.
2. La latencia es cero.
3. El ancho de banda es infinito.
4. La red es segura.
5. La topología no cambia.
6. Solo hay un administrador.
7. El costo del transporte es cero.
8. La red es homogénea.
Estas se deben considerar como restricciones en el diseño de las soluciones.
Como se ha enfatizado, los sistemas distribuidos fueron planteados con el propósito de satisfacer las transformaciones y los constantes cambios en la web [19]. Así pues, han surgido múltiples soluciones a partir de: los avances en arquitectura de infraestructura y telecomunicaciones; las arquitecturas de solución con nuevos patrones de diseño, modelos de referencia y arquitecturas de referencia, tales como SOA (Service Oriented Architecture), SOC (Service Oriented Computing) y Component-based Programming.
En la actualidad, gracias a la difusión por parte de empresas como Netflix, LinkedIn [20, 21] existe una tendencia de soluciones en la que se utiliza un patrón arquitectural orientado por servicios. Así como también, exponen las ventajas sobre las arquitecturas monolíticas y como una propuesta para el requerimiento la elasticidad. La comunidad ha denominado este tipo arquitecturas bajo un nombre específico, microservicios. Por lo que ha generado gran controversia las difusas diferencias con la bien conocida SOA (Services Oriented Architecture).
Este trabajo presenta como contribución, la diferenciación entre los conceptos SOA y microservicios, y la definición de este último para tener un concepto único en el documento.
2.3 SOC, SOA y Microservicios
En esta sección, se hace una distinción entre los conceptos de arquitecturas orientadas por servicios (SOA) y microservicios. Con base en una investigación y tipificación a nivel conceptual, se tiene como resultado de la tesis definiciones propias a microservicios y sus respectivas características.
2.3.1 Service Oriented Computing
Tsai et al. [22] y Thomas Erl en [23] definenService Oriented Computing (SOC)
como un paradigma de desarrollo de sistemas distribuidos en el que se definen conceptos bases de SOA. Sin embargo, se puede ampliar el alcance e incluir a las arquitecturas de microservicios como parte de SOC, gracias a la naturaleza de la creación de servicios como unidad funcional.
Como conclusión, en esta sección se muestra la relación entre SOC, SOA y microservicios. Así pues, primero se deben definir conceptos los cuales sirven como insumos para las conclusiones.
2.3.2 Service Oriented Architecture
SOA ha sido bastante estudiada, sin embargo se encuentran dos grandes definiciones divergentes:
• Como Patrón o estilo Arquitectural: Autores como Erl [24, 23], Barry et al. [25], entienden a SOA como un patrón arquitectural, en el cual se diseña, se implementan y se coordinan servicios con el fin de soportar o automatizar los procesos de negocio. Esto con objetivos entre los que se destacan: Bajo acoplamiento, contrato de servicios, autonomía de cada servicio, reusabilidad y no guardar estados dentro de las aplicaciones [26]. Para Tsai et al. [22] no existe diferencia entre SOC y SOA, pues define a SOA como un paradigma que abstrae este tipo de sistemas distribuidos. Por otra parte, surgieron soluciones arquitecturales e implementaciones intermedias para realizar la orquestación de los servicios y necesarias para desacoplar las funcionalidades. Así, patrones como SAGA [27] y ESB (Enterprise Service Bus) son elementos que todos los autores proponen como parte de la construcción de una solución SOA. SOA se encuentra diseñada para cumplir con unas restricciones, entre los cuales se recalca el bajo acoplamiento y el uso contratos de los servicios pues se menciona que los proveedores y consumidores de servicios, deben ser capaces de solicitar, interpretar y responder mensajes, de forma que el sistema sea estable y el desarrollo del mismo se encuentre estandarizado.
• Como Modelo de referencia: Con el fin de estandarizar y realizar una unificación a las tantas definiciones de patrones existentes, OASIS (Advancing Open Standards for the Information Society) decide publicar un modelo de referencia [28] en el que se plantean los elementos esenciales para SOA. El primero es la entidad, responable de crear las funcionalidades
(capabilities) encargadas de solucionar los problemas de la empresa. bajo
esta premisa, el modelo de referencia describe siete conceptos:
1. Servicio: Mecanismo para acceder a las funcionalidades de las entidades.
2. Descripción del servicio: A grandes rasgos, el modelo de referencia indica que debe existir una descripción de un servicio, el cual consta de información relevante para el consumo y respuestas ofrecidas por los servicios, entre los que se encuentra la estructura de la información a solicitar o responder, la semántica de la información y los métodos de interacción.
10 2.3. SOC, SOA y Microservicios
3. Visibilidad: Capacidad de identificar el consumidor y proveedor de los servicios y los permisos entre los mismos.
4. Contexto de ejecución: El contexto abarca todo lo relacionado con la infraestructura, i.e. componentes de Hardware, computadores, elementos de telecomunicaciones, en la que se ejecutan los servicios, las entidades que procesan (consumen o proveen servicios) y los contratos.
5. Efecto en el mundo real: Es la capacidad de ver persistir cambios en un sistema distribuido que tiene elementos compartidos. Es deseado que los cambios que suceden a una variable compartida debe ser consistente en todo el sistema.
6. Contrato: Es la generación de un acuerdo entre el proveedor y el consumidor de los servicios, con el fin de registrar lo que se desea (y como) solicitar y lo que se acuerda a responder. Esto incluye, establecer acuerdos de calidad de servicio, tiempos de respuesta, entre otros.
7. Interacción: Mecanismos para realizar la interacción y ejecutar acciones entre los servicios, este concepto se encuentra relacionado con el contrato y las políticas establecidas por los servicios, el contexto en el que se encuentra ejecutándose, hasta con el visibilidad entre los mismos.
Como se observa, SOA tiene varios tópicos transversales, debido a que se encuentra diseñado para proveer soluciones a entornos empresariales, que tengan necesidades complejas y capacidad de soportar aplicaciones sensibles y críticas para el negocio. En el momento que las empresas decidieron adoptar este tipo de arquitecturas, varios proveedores presentaron sus productos: IBM con WebSpehere [29], Oracle [30] y productos open source como Mule ESB (Ahora integrado en la plataforma Anypoint). Esta proliferación de productos dio a conocer a SOA como un sistema de integración de aplicaciones empresariales que utilizaba unMiddleware, esto acarreó a la generación de grandes obstáculos, tales como el diseño de la arquitectura de solución y despliegue de ESB, diseño e implementación de interfaces para la integración con las aplicaciones nuevas y legadas, así como también se difundió una errónea concepción de SOA, sus principios y motivaciones.
SOA se puede definir desde dos perspectivas, como patrón arquitectural, en el que muchos autores enfatizan en el uso de middlewares como: Elemento de integración (lo que ha generado dificultades en las implementaciones); y como un modelo de referencia, en el que solo se hace descripción a alto nivel de elementos que componen y la comunicación entre los mismos. Autores, la comunidad y empresas emergentes (start-ups) han intentado mejorar las soluciones orientadas por servicios a través de la eliminación de las desventajas documentadas de las arquitecturas tradicionales y las orientadas por servicios, como lo son problemas asociados a la elasticidad y tolerancia a fallos. Las nuevas aproximaciones se han concentrado en un nuevo patrón llamado microservicios.
2.3.3 Microservicios
El concepto de microservicios se ha propagado en los últimos años gracias a empresas como Netflix, Amazon, Twitter y start-ups como se evidencia en [14,
20, 21, 31, 32] y a los autores que han trabajado en las iniciativas que intentan definir el concepto y los objetivos, como Fowler en [4], Richardson [13] y la comunidad [12].
A pesar de los grandes aportes y su divulgación, no se tiene una definición clara que permita suprimir la dicotomía con el concepto de SOA [33]. Concretamente, para Richardson y Fowler en [13, 4] respectivamente, definen a una arquitectura de microservicios como un patrón centrado en la división de las funcionalidades en pequeños servicios. Cada servicio debe ser autónomo, desplegado en único proceso y utilizar mecanismos ligeros de comunicación entre los mismos. Esta definición es bastante difusa, lo que implica que autores como Little y Steve Jones en [33] no logren diferenciar los dos conceptos y concluyen que las arquitecturas de microservicios es una versión simplificada de SOA.
En el siguiente cuadro se puede precisar las diferencias entre microservicios y SOA (Cuadro. 2.1). La comparación se realiza con las características que se describen en [4, 12]: ventajas y desventajas; objetivo de los patrones; granuralidad de los servicios, ya que se comparan arquitecturas orientadas a servicios y es necesario analizar el grado de granularidad de los mismos y por último si se considera un patrón arquitectural, por definición, debe satisfacer unas restricciones o solucionar un problema recurrente.
Desde el punto de vista conceptual existe una diferencia entre el modelo de referencia y el patrón arquitectural de SOA, puesto que sus alcances y objetivos son diferentes. Como se muestra en la Tabla 2.1; los microservicios tienen principios diferentes a SOA, pero en la praxis no están totalmente aislados, dado que comparten conceptos tales como: los mecanismos de descubrimiento y registro de servicios; mecanismos de intercambio de solicitudes; hasta el concepto de división de capabilities en servicios independientes. La diferencia que se encuentra es en el conjunto de objetivos a alcanzar y en como dividir las funcionalidades para cumplir con las restricciones. Por otra parte, en [31] presentan una metodología para adoptar microservicios y de como se debería orientar el desarrollo. La metodología incluye un estilo para el diseño, Domain Driven Development (DDD), que cuenta con la ventaja de desacoplar los microservicios y no generar alto acoplamiento por las dependencias.
De esta manera, extendemos la definición a; una arquitectura de microservicio es un patrón arquitectural que se encuentra bajo ciertas restricciones de diseño: Bajo acoplamiento, escalabilidad y elasticidad, tolerancia a fallos, división de responsabilidades (datos, lógica, despliegue). De acuerdo con la necesidad, un servicio debe ser atómico, la granularidad está dada por los requerimientos y por decisiones de diseño si tenemos en cuenta que la comunicación entre los microservicios es liviana y no debe haber alto procesamiento ni consumo de recursos en los elementos intermedios.
En la figura 2.2 se puede ver la relación entre SOC, SOA (como patrón arquitectural) y microservicios: SOA y microservicios son patrones arquitecturales que se encuentran dentro de un paradigma de desarrollo orientados por servicios (SOC).
2.3.4 Arquitectura Reactiva
La programación reactiva, es un término bastante estudiado para definir a un paradigma de programación y por lo tanto se tiene bastante información. La programación reactiva se centra en dos grandes conceptos mencionados en [35]:
12 2.3. SOC, SOA y Microservicios
SOA Patrón SOA RM Arquitectura de
Microservicios División en
Equipos de Desarrollo
Por aplicación No aplica Por microservicio
Tipo de
aplicaciones
Empresarial Empresarial General
Objetivo Desacoplar, Integrar aplicaciones
empresariales
Desacoplar e integrar aplicaciones Desacoplar, endpoints robustos pipelines ligeros Granularidad de los servicios
Dependiendo de la aplicación y del diseño de la solución
No Aplica Servicios pequeños
(Autores establecen que entre 10 y 100 LoC [31, 32] o SRP (Single Responsibility Principle) [34]) )
Restricciones a satisfacer
Bajo acoplamiento, contrato de servicios, autonomía de cada servicio, reusabilidad, sin estado.
No aplica Facilidad de despliegue
y automatización, Escalabilidad y resiliencia, Computación distribuida: Descentralizar procesamiento, datos, diferentes stack tecnológicos, Orientado al desarrollador. Distribuir
responsabilidades de un sistema monolítico.
Table 2.1 Diferencias entre SOA y Microservicios
• Comportamientos: Son valores variables en el tiempo, es decir que son los valores reactivos.
• Eventos: Secuencias de ocurrencias ordenadas en el tiempo.
Adicionalmente, las aplicaciones reactivas son soluciones orientadas por eventos donde lo más importante es la notificación e intercambio de ocurrencias de estos dentro del sistema. Por esto, se plantearon Functional Reactive
Programming (FRP) y lenguajes como Haskell [36], (Functional Reactive
Animation) FRAN [37], que permiten la creación de comportamientos que reaccionen a eventos y desarrollo aplicaciones reactivas, en especial en las áreas de animación, robótica, interfaces gráfica, usando lenguajes funcionales declarativos y bajo el paradigma de programación reactiva.
Odersky et al. en [38] plantea Scala como un lenguaje que puede construir componentes alternativos a la implementación del patrón Observer. El patrón
Observer es la solución predominante para capturar los cambios en los estados
SOC
SOA Microservicios
Figure 2.2 Relación entre SOC, SOA y Microservicios
El caso es que el cambio de un objeto debe actualizar el estado de otros (propagar el cambio) y no se sabe cuantos objetos necesitan ser modificados. Odersky et al. en [38] hacen una crítica a este patrón con la justificación que se quebrantan principios como: Encapsulación, al tener que compartir el estado con otras clases; distancia semántica, difícil entender la intención del desarrollador y el código; Abstracción, el patrón promueve el uso de interfaces robustas, y no se puede abstraer sobre la fuente del evento de forma individual. Para contrarrestar esto, se propone la programación reactiva a través de un lenguaje de programación (Scala) y de un framework Scala.React con el fin de permitir la propagación del cambio.
Teniendo ya un paradigma de programación, algunos años después, se escribió un manifiesto [3] sobre una arquitectura centrada en cuatro requerimientos y que toda solución web actual debería soportar:
• Responsividad: Todo sistema debe responder a las solicitudes por parte del usuario, esto quiere decir que debe existir una continuidad en la prestación de las funcionalidades del sistema, i.e. el sistema siempre debe reaccionar a las solicitudes por parte de los usuarios.
• Elasticidad: La capacidad del sistema de escalar para atender una cantidad de usuarios bajo demanda, es decir el sistema debe reaccionar a los cambios del número de solicitudes.
• Orientados por eventos: Un sistema debe responder a los eventos, por lo tanto los eventos son el elemento esencial de intercambio dentro del sistema, es decir el sistema debe reaccionar a los eventos generados.
• Resiliencia: Un sistema debe ser capaz de reaccionar a los puntos de fallas y recuperarse para mantener la responsividad.
En el caso de las arquitecturas reactivas, esta extiende la programación reactiva solo como paradigma de desarrollo, sino más bien a la arquitectura de una solución que reacciona a los eventos, cambios de volúmenes de peticiones, a los fallos dentro del sistema, en general un sistema que siempre sea capaz de reaccionar.
14 2.3. SOC, SOA y Microservicios
La empresa TypeSafe ha sido la encargada de desarrollar una plataforma, la cual la denominan como reactiva, Play [39], y consta de varios elementos que permiten clasificarla como una plataforma reactiva.
En el tutorial [40] se describen varias formas en que las aplicaciones pueden ser reactivas:
1. Reactive Push: Es la capacidad de enviar datos desde el lado del servidor al cliente, en el caso de la plataforma se utilizan WebSockets para el envío de información entre las partes.
2. Reactive Pull: Es la capacidad de comunicación desde el lado del cliente hacia el servidor para obtener los datos necesarios y pasarlos a la interfaz gráfica.
3. Reactive UI: Un sistema debe mostrar datos en tiempo real al usuario final, lo cual la interfaz gráfica también debe ser reactiva. Para esto, se utilizan frameworks orientados por eventos, como lo son Javascript y JQuery.
4. Reactive Request: Algunas llamadas pueden ser asincrónicas, esto con el fin, de no ocupar procesos en esperar las llamadas (una ventaja de Play
Non-Blocking IOs). Play está soportado por Akka [2], una implementación
del modelo de Actores propuestos por Agha [41] para la ejecución de procesos de forma concurrente, permite tener una gran cantidad de procesos (actores) capaces de responder de forma asincrónica solicitudes, en la teoría esto se refleja en ventajas como lo son: Resiliencia, Escalabilidad
yNon-blocking IOs
5. Reactive Composition: Es el conjunto de solicitudes.
6. 2-way Reactive: Es la comunicación bidireccional entre el cliente y el servidor, esto quiere decir que el sistema es tanto Reactive Push como Reactive Pull.
3
Estado del Arte
Las arquitecturas reactiva y microservicios, son descritas como soluciones para dos requerimientos específicos, la tolerancia a fallos y la elasticidad. Como se muestra en el capítulo 1 estas son necesidades que surgen gracias a las transformaciones de la web. Este documento desea comparar las dos arquitecturas teniendo en cuenta los dos requerimientos, para esto es necesario seleccionar, primero, la definición de los conceptos de elasticidad y tolerancia a fallos. Además, la elección de métricas y herramientas para hacer la medición adecuada para elaborar la comparación.
3.1 Elasticidad
En otras áreas del conocimiento definen la elasticidad como una capacidad mensurable e.g., Economía es la medición de dependencia entre variables, en Física la capacidad de un material en retornar al estado original luego de una deformación, que ha sido adaptada al contexto de la computación como un atributo del paradigma Cloud Computing bajo ciertas definiciones ambiguas y contradictorias; Herbst en [42] recopila cinco de estas contradicciones, las cuales considera ambiguas e incapaces de definir adecuadamente el concepto, así como tampoco, de capturar los aspectos más importantes:
1. La Open Data Center Alliance (ODCA) define elasticidad como una capacidad para escalar teniendo en cuenta la carga dentro del sistema.
2. La National Institute of Standards and Technology (NIST) plantea la elasticidad como un atributo de Cloud Computing que permite asignar mayor capacidad a los recursos para responder rápidamente a una demanda.
3. Edwin Schouten autor de Author at Thoughts On Cloud encuentra que elasticidad es otro nombre que se atribuyó a la escalabilidad.
4. Rich Wolski (CTO de la Empresa dedicada a Cloud Computing, Eucalyptus) plantea que la elasticidad mide la habilidad de Cloud para
16 3.2. Tolerancia a fallos
distribuir una solicitud a diferentes recursos.
5. Reuven Cohen, por su parte, establece que la elasticidad cuantifica la capacidad de gestionar, medir, predecir y adaptar la habilidad de responder de una aplicación, basada en las demandas.
Las principales críticas a los anteriores aspectos son la falta de inclusión de varios conceptos: a) Medición, ya que es un concepto necesario dada la naturaleza del concepto y las aproximaciones de otras áreas. b) El marco de Tiempo en el cual se realiza dicha medición. c) Automatización, la elasticidad responde a cambios dinámicos bajo demanda, la respuesta debe ser automática.
Así pues, frente a las críticas el aporte en [42] es una definición concisa de elasticidad, la cual la define como: “El grado en el cuál un sistema es capaz de adaptarse a los cambios de carga de trabajo, aprovisionando y desabasteciendo recursos de una forma automática, lo cual en cada punto en el tiempo los recursos
disponibles corresponden a la actual demanda tan cerca como sea posible". Bajo
este concepto de elasticidad se trabajará durante el desarrollo de la tesis, debido a que es una definición que logra unificar varias definiciones de entidades como la ODCA y la NIST; además es relevante pues el concepto es generalizado, no solo se le atribuye al paradigma de Cloud Computing, sino a cualquier sistema.
Como se ha mencionado, la elasticidad es atribuida al paradigma de Cloud
Computing, sin embargo, existen arquitecturas de solución las cuales no son
fáciles de adaptarse a los cambios de recursos de infraestructura de forma dinámica,e.g.,Clústersde servidores. Por ende, la elasticidad no solo se centraría en la medición de la infraestructura, sino también en la capacidad en la que las arquitecturas de solución tienen para adaptarse a los cambios de carga de trabajo aprovisionando o desabasteciendo recursos en un marco de tiempo.
3.2 Tolerancia a fallos
Como se mencionó en el capítulo 2 la tolerancia a fallos en los sistemas distribuidos es un término bastante estudiado. Esto se justifica a través de las ocho falacias de los sistemas distribuidos, la red no es confiable y los recursos no están exentos de eventualidades que generen no disponibilidad de los sistemas. En este caso, diferentes paradigmas como Cloud Computing solucionan los inconvenientes, dado que se cuentan con grandes niveles de alta disponibilidad (e.g., AWS tiene un nivel del 99,95% es decir 44 minutos al mes1). Sin embargo, otros inconvenientes de la aplicación, el sistema debería ser capaz de ofrecer un servicio continuo y tolerar los fallos.
Bajo esta idea, se debe definir lo qué es un fallo. Fernandez et al. en [43] explica el concepto de defecto como un evento generado en algún componente del sistema y que compromete el correcto funcionamiento del mismo, estos se pueden propagar por el sistema y en el peor de los casos colapsarlo, es decir que el sistema produzca comportamiento deseado. Por otra parte, [44] explica tres conceptos: Defecto (Fault en Inglés), el cual genera un Error. Error es la configuración de un estado incorrecto dentro del sistema y al ocurrir genera una falla. La falla (Failure en Inglés), representa la condición en que el sistema no
1
presenta el comportamiento esperado. A partir de las anteriores definiciones, se entiende por falla, al estado en el que se encuentra un sistema al no presentar el comportamiento deseado, e.g., suponga que un servidor web se encuentra conectado a otro de Bases de datos, con el propósito de persistir todas las transacciones de los usuarios. En un instante de tiempo, hay un problema con la Memoria RAM del servidor de Bases de datos, este es un defecto que causa un error, el reinicio del proceso del DBMS (Database Management System). Luego, esta secuencia de eventos ocasionan una falla en todo el sistema, pues el servidor Web no se puede conectar a la base de datos y no podrá atender a las nuevas solicitudes. Si el sistemaNoes Tolerante a Fallos, colapsará y se deberán realizar un proceso de recuperación, generalmente volver a inicializarlo completamente. En el caso opuesto, el sistema será capaz de gestionar el fallo sin comprometer el servicio a los usuarios.
Por su parte Jhawaret al. [44] formalmente define Tolerancia a Fallos como la capacidad de un sistema de continuar con su funcionamiento en presencia de fallas.
Los defectos se pueden clasificar en dos:
1. [43, 45, 46] lo denotan comoDefectos de Hardware, en el caso de [44] lo nombraDefecto de choque (Crash Fault). Los autores, describen este defecto como problemas físicos que pueden ocurrir y que el recurso queda completamente fuera de servicio. e.g., Problemas de Red o energía.
2. En [43, 45, 46] son defectos en Software y en el caso de [44] es un Defecto Byzantino (Byzantine Fault). Este tipo de defectos son los que en un momento de falla el sistema continúa en funcionamiento pero con un comportamiento no predecible. e.g., Códigos fuentes con errores, entradas inesperadas a los módulos del software.
Es cierto que existen fallos, también se encuentran técnicas para mitigarlas. Se debe contar con un sistema Tolerante a Fallos e implementar estrategias, que entre las cuales se encuentran:
1. Replicación: Es la técnica más común para mantener alta disponibilidad de recursos críticos. Consiste en replicar tanto el Hardware, Software y componentes de red. Así, una vez exista una falla, el componente replicado es el encargado de continuar con el funcionamiento. Se puede deducir, la existencia de dos tipos de configuraciones: Activo-Activo, en el cuál los dos componentes replicados se encuentran funcionando mediante un balanceador de carga encargado de distribuir las peticiones, y Activo-Pasivo, una vez falle el componente activo el pasivo es el encargado de continuar con el sistema. Esta estrategia se puede extender a Defectos de Software, Aghaet al. [41] y Fernandezet al. [43] plantean mecanismos en los cualesAgentes yActores replicados y distribuidos pueden colaborar en la Tolerancia a Fallos.
2. Monitoreo y Supervisión: Fernandez et al. citeFernandez-Diaz2015 centran su propuesta en esta estrategia, pues su aproximación es de un lenguaje de programación basado en Sistemas Multi-agentes (MAS) y cuyo objetivo es un sistema Tolerante a Fallos mediante la supervisión de los agentes que componen el sistema y reaccionando a las fallas que se presenten. Por su parte [44], hace una breve descripción de la estrategia y
18 3.2. Tolerancia a fallos
se resalta que aunque es muy sencilla, es muy importante en la detección fallas y la posterior reacción.
3. Checkpoint y reinicio: Consiste en capturar y almacenar todo el estado
del sistema teniendo en cuenta ciertos parámetros configurados e.g., Cada x segundos o después denlíneas de código, y detectado el fallo se reinicia desde el último estado almacenado [44].
Ya se cuenta con la definición propia para elasticidad y tolerancia a fallos. Ahora, se hace una revisión de las soluciones y herramientas actuales para el cálculo de elasticidad y posteriormente de tolerancia a fallos.
3.2.1 Benchmarks
Los Benchmarks se definen como un conjunto de pruebas con el objetivo de
medir una determinada variable. Esta propuesta se centra en la medición de dos grandes características de las arquitecturas web: Elasticidad y Tolerancia a Fallos.
Benchmarks de elasticidad
De acuerdo con [47] un Benchmark de Elasticidad mide el rendimiento de un sistema dentro de un marco temporal y de cambios en las cargas de trabajo; por lo que se deben proponer medidas que permitan concluir el grado de elasticidad de un sistema.
Variables de medición Elasticidad para Klems [47] es el grado de eficiencia en el que un sistema escala el número de recursos en tiempo de ejecución bajo términos de velocidad. Así, se contempla el impacto en el rendimiento teniendo en cuenta la carga actual al sistema. Para cuantificar ese grado, se propone medir latencias en los tiempos de respuesta, en tres diferentes instantes de tiempo, antes, durante y después de escalar el recurso. El autor sostiene que estas facultan a la medición y concluir sobre el impacto en el rendimiento del sistema y sobre el tiempo que toma configurar las nuevas asignaciones de recursos (escalado).
Autores como Almeida et al. en [48] miden la elasticidad basándose en penalidades: sobre-provisionado e infra-provisionado, de esta manera se mide grado en el que el sistema reacciona a la demanda de carga de trabajo. Para obtener los resultados, Almeida propone las siguientes mediciones y fórmulas:
1. Penalidad por sobre-aprovisionamiento (Over-provisioning
penaly): El sistema sobre-aprovisionado cumple con los cambios de las
cargas de trabajo, sin embargo se estarían utilizando más recursos de los necesarios. Para el cálculo de sobre-aprovisionamiento se tiene:
overprovp=
Pn
i=1
expectedrt(i)
executiontime(i)
n
Debido a que el tiempo de ejecución en un entorno sobre-aprovisionado va a ser menor que el tiempo esperado. Así, mayor el valor de overprovp,
quiere decir que el tiempo de ejecución es menor al tiempo esperado y esta es una característica de un sistema que está sobre-aprovisionado.
Los autores proponen otra ecuación de sobre-aprovisionamiento. Como el promedio de las tazones entre el tiempo de respuesta esperado y el tiempo total del grupo de consultas, i.e. el tiempo gastado por un grupo de consultas i que se incluye en la ecuación si satisface la ecuación expectedrt−δ > querygrouprt. El autor incluye δ para obtener un rango
de tiempos de respuestas esperados por las consultas.
overprovp =
Pn
i=1
expectedet(i)
querygrouprt(i)
n
2. Penalidad por infra-aprovisionamiento (Under-provisioning
penalty): Se encuentra relacionado con una mala elasticidad, dado que no
cubre con lo mínimo demandado por los cambios en las cargas de trabajo. En el otro contexto, donde existiese elasticidad, escalaría los recursos para responder a los cambios y evitar esta penalidad. En la siguiente ecuación, se hace un cálculo del nivel de infra-aprovisionamineto, del cuál se puede inducir que es el promedio de las razones entre tiempos de ejecución que no cumplen con un límite establecido y los tiempos de respuestas que cumplen con dicho límite.
underprovp =
Pn
i=1
violatedet(i)
expectedrt(i)
n
Ahora bien, existe una relación inversamente proporcional entre
underprovp y elasticidad; Mayorunderprovp menor elasticidad, dado que
concluiría que los tiempos de ejecución en los que no estarían dentro del límite establecido son mayores a los tiempos de respuesta esperados.
La elasticidad, entonces, se obtiene de la suma de las penalidades, los autores decidieron agregar dos pesos a la ecuación para diferenciar la importancia entre los valores de las penalidades.
elasticity = x∗underprovp+y∗overprovp x+y
Existen otras aproximaciones para encontrar la elasticidad, Weberet al. [49] y Herbest et al.Herbst2013 proponen hacer mediciones básicas que dan una noción de elasticidad y a partir de estas mediciones se encuentran métricas relevantes para el concepto de elasticidad.
• A¯ es el tiempo promedio que toma cambiar de un estado infra-aprovisionado a un óptimo sobre-aprovisionado.
• P
A es el tiempo acumulado en el estado infra-aprovisionado
• U¯ es la cantidad de recursos infra-aprovisionados.
• P
U es la cantidad acumulada de recursos infra-aprovisionados.
• B¯,P
B, ¯O,P
O son análogos a las anteriores mediciones, en un contexto sobre-aprovisionado.
20 3.2. Tolerancia a fallos
• T duración total del tiempo de evaluación
A partir de estas mediciones básicas, se calculan las métricas relevantes de elasticidad:
• Velocidad para escalar: PA
• Precisión (periodos de sobre-aprovisionamiento): Pd=
P
O T
• Elasticidad: Eu = A¯∗1U¯
Estas mediciones en conjunto constituyen la percepción de un sistema con características de elasticidad.
Herramientas de Medición En las diferentes referencias bibliográficas, se han encontrado que se han creado herramientas para automatizar las mediciones de cargas de trabajo, algunas se orientan a las pruebas en sistemas de bases de datos.
1. Yahoo Cloud Serving Benchmark (YCSB) [5]: Esta solución tiene como objetivo desarrollar unFramework y un conjunto de pruebas que permitan evaluar el rendimiento de bases de datos en la nube.
2. Transactional Processing Performance Council (TPC) [7]: Organización encargada de desarrollar conjuntos de pruebas para evaluar el rendimiento en sistemas de bases de datos. Las pruebas de TPC son bien conocidas y difundidas en la literatura de benchmarking, sin embargo solo se orienta a la creación de pruebas en sistemas de bases de datos.
3. Standard Performance Evaluation Corporation (SPEC) [6]: Es una organización que crea, mantiene y estandariza benchmarks. SPEC ha desarrollado un SPECweb para evaluar servidores Web, incluyendo pruebas de cargas, no obstante, este proyecto no continúa en desarrollo.
4. AUToCLES [8]: Es una herramienta de automática para la generación de pruebas en sistemas elásticos. Es posible el análisis de los eventos que ocurren durante las pruebas no genera métricas que evalúen y permitan cuantificar la elasticidad.
5. JMeter [9]: Es una herramienta para realizar pruebas de carga y estrés, bastante fácil de extender, por lo que se podría extender para obtener las métricas para elasticidad.
3.2.2 Benchmarks de Tolerancia a Fallos
Tsaiet al. en [50], propone que elBenchmark de Tolerancia a Fallos se compone,
de una medida que caracteriza la tolerancia a los fallos por parte de un sistema y la especificación del proceso para obtener la métrica. Esto sugiere la creación de un mecanismo encargado de realizar las pruebas y de obtener las métricas necesarias. En el mismo artículo, se propone esta capaz de inyectar defectos en el sistema, posteriormente obtener el comportamiento del sistema y por último analizar las métricas de la tolerancia a fallos: El número de incidentes catastróficos (El sistema no se recuperó) y la degradación del sistema.
Aunque la Tolerancia a Fallos ha sido estudiada existen múltiples problemas que aún se están haciendo propuestas e investigación en el tema, no es el caso de los Benchmarks que logren cuantificar la Tolerancia a Fallos para arquitecturas Web. Como se puede evidenciar en [44] las pruebas se hacen utilizando herramientas que a la fecha se encuentran obsoletas, causando dudas al validar arquitecturas emergentes.
3.2.3 Benchmarks en Arquitecturas de microservicios y en
Arquitecturas Reactivas
Hasta la fecha, no se encuentran mediciones de ningún tipo de las diferentes tipos de arquitecturas. Cada uno de los defensores de las arquitecturas ofrecen argumentos sobre la capacidad de ser elásticos y tolerantes a fallos, no obstante, no existen pruebas que comprueben dichas características de cada una de las arquitecturas.
4
Estrategia de Solución
El propósito de este trabajo es la evaluación de dos requerimientos, elasticidad y tolerancia a fallos en dos arquitecturas de aplicaciones Web, arquitecturas reactivas y microservicios. Para esto, se proponen tres pasos, los cuales se encuentran basados en el estándar de pruebas de software de la ISO-29119, como se evidencia en la figura 4.1.
Diseño e Implementación
de Pruebas
Configuración y Mantenimiento del entorno de
pruebas
Ejecución de pruebas Especificación
de pruebas
Requerimientos del entorno de
pruebas
Reporte del entorno de
pruebas
Resultado de las pruebas
Figure 4.1 Proceso de pruebas de Software ISO-29119
El primer paso consiste el diseño e implementación de las dos pruebas, en el cual se mencionan, el objetivo, la estrategia, las métricas y las conclusiones deseadas por parte de la ejecución de las pruebas.
Posterior a la definición de las pruebas, se ejecuta el proceso de implementación del entorno de pruebas. Para esto, se construye un prototipo para cada arquitectura. Además, se selecciona el IaaS (Infrastructure as a Service) de Amazon Web Services como el entorno de despliegue para las pruebas, dado que brinda servicios de Computo virtualizado, Balanceador de Carga, de autoescalado, y al fácil acceso a la consola de administración de las máquinas virtuales; los cuales son necesarios para la ejecución, obtención de las pruebas de elasticidad y tolerancia a fallos.
Por último se ejecutan las pruebas, se recopilan las métricas y se procede a construir el análisis de los resultados. Este proceso de análisis incluye las
consideraciones para mejorar cada uno de los requerimientos en las arquitecturas y se exponen a partir de la observación y experimentación de todo el proceso.
A continuación, se presentan las herramientas y la especificación de las pruebas utilizadas como mecanismos para la construcción del análisis entre las dos arquitecturas, reactiva y microservicios. Cada especificación de las pruebas se realiza con base en los conceptos básicos descritos por el estándar ISO-29119 [51], por lo tanto se incluyen: una descripción de la estrategia de la prueba, las métricas a analizar y las herramientas usadas.
4.1 Prueba de Elasticidad
Como se menciona en el capítulo 3, se cuenta con un concepto y una metodología analítica para la observación de la elasticidad de un sistema. Klems en [47] propone una técnica y un concepto para cuantificar la elasticidad de un sistema de bases de datos relacionales. Con el fin de construir un análisis similar pero en arquitecturas de Aplicaciones Web. Primero se cambia el objetivo y el alcance de las pruebas. Luego, se abstraen los conceptos más importantes, que permitan elaborar el análisis de elasticidad. Estos son explicados como parte de la estrategia y de las métricas a recopilar de las pruebas. Por último, se menciona el nuevo objetivo de la prueba, la estrategia y técnica de la prueba.
4.1.1 Objetivo
El objetivo de la prueba es dimensionar la capacidad de elasticidad de las arquitecturas seleccionadas, para que así, se pueda concluir que arquitectura cumple de forma más efectiva con el requerimiento de elasticidad.
4.1.2 Estrategia
Para cumplir con el objetivo, se debe explicar el alcance y clasificar el tipo de prueba requerida para cuantificar la elasticidad. En ese orden de ideas, se debe realizar una prueba de carga (Cantidad de solicitudes) variable e incremental en un marco de tiempo. Esto permite obtener métricas suficientes para el análisisa
posteriori. Estas habilitan la cuantificación de los cambios de recursos necesarios
en el tiempo. Para el desarrollo de las pruebas, los recursos son el número de instancias con la capacidad para atender solicitudes. En el prototipo de la arquitectura reactiva, los recursos equivalen al número de actores dentro del sistema, distribuidos en las diferentes máquinas virtuales. En la prueba, cada máquina virtual cuenta con dos actores. Caso contrario, en microservicios, los recursos se encuentran definidos por el número de máquinas virtuales o instancias del microservicio.
Primero se realiza el proceso de elección y definición de las métricas para luego realizar la explicación del conjunto sucesivo de pasos a realizar durante la prueba.
Métricas
El proceso de abstracción de las métricas se realiza con base en las pruebas ejecutas en la propuesta de Klems. Las seleccionadas y su justificación se mencionan a continuación.
24 4.1. Prueba de Elasticidad
• Carga por unidad de tiempo: Esta prueba de elasticidad, es en esencia, una prueba de carga variable en el tiempo, por lo tanto es imperativo obtener los datos del número de solicitudes a someter en la prueba.
• Cantidad de recursos por unidad de tiempo: La prueba de elasticidad busca encontrar la relación entre la cantidad de recursos necesarios, los cambios en la carga y el tiempo. Esta métrica permite hacer el diagnóstico si el sistema es capaz de adaptarse a los cambios durante el tiempo de ejecución de la prueba.
• Tiempo requerido por nodo para el inicio de procesamiento de solicitudes: Esta métrica es una variación para calcular la métrica de sobre-aprovisionamiento e infra-aprovisionamiento planteada por Klems. La propuesta inicial considera los tiempos de respuesta de cada solicitud, sin embargo para realizar una mejor comparación entre las dos arquitecturas que permitan obtener las características y causas de las diferencias entre las arquitecturas, se obtienen los tiempos en que el sistema es capaz de abastecerse de nuevos recursos.
Luego de la definición de las métricas, se propone un algoritmo para generar los datos necesarios para el diseño de las pruebas. Además de los pasos descritos a continuación, también se muestran los datos a utilizar y por ende, el diseño de las pruebas.
1. Definir una carga base: En el contexto de este proyecto, la carga base se adopta como el número de solicitudes que el sistema es capaz de responder con un mínimo de recursos en una unidad de tiempo. Se hizo una prueba de concepto y se determinó que la carga base es de 12 solicitudes por recurso en un minuto.
2. Cálculo teórico de carga variable e incremental: Conforme a los resultados demostrados en [52] y con la carga base definida, se proyecta de forma lineal la carga en relación con el número de recursos. En la Figura 4.2 se muestra el resultado de la proyección, obteniendo los datos para realizar la prueba de carga.
0 12 24 36 48 60 72 84
0 60 120 180 240 300 360
3. Cálculo teórico de recursos necesarios: El resultado de la proyección, como se observa en la Figura 4.2, se relaciona el número de recursos esperados durante los cambios de carga en el tiempo. Así pues, se tiene como resultado el número de recursos esperados por unidad de tiempo como se evidencia en la Figura 4.3
0 1 2 3 4 5
0 12 24 36 48 60 72
0 60 120 180 240 300
Re
cu
rs
os
Pe*ci
on
es
Segundos
Pe-ciones / Tiempo Recursos / Tiempo
Figure 4.3 Cambio de Carga y de recursos en el tiempo: Número de solicitudes por unidad de tiempo
Análsis y Consideraciones
En la validación (capítulo 5) se presentan los resultados de la prueba de elasticidad, los cálculos realizados, y por último, teniendo como base la experiencia general, se incluye un listado de consideraciones necesarias para mejorar la capacidad de elasticidad en cada una de las arquitecturas. Las consideraciones están relacionadas con la curva de aprendizaje para desarrollar teniendo en cuanta cada una de las arquitecturas, la implementación de nuevos desarrollos para mejorar la elasticidad, idoneidad para requerimientos de sistemas transaccionales y restricciones de desarrollo.
4.2 Prueba de Tolerancia a Fallos
El siguiente requerimiento a ser evaluado, es la capacidad de un sistema reaccionar a la inyección de fallos. La prueba diseñada se centra en la inyección de fallos permanentes (la falla no permite la recuperación del recurso) y de tipo silentes o de detención, con la intención de revisar el comportamiento de las arquitecturas frente la presencia de este tipo de fallos y poder obtener dos resultados: En principio una arquitectura capaz de soportar fallas y las consideraciones a tener en cuenta para mejorar la tolerancia a fallos.
La especificación de la prueba de Tolerancia a Fallos se exhibe a través de la exposición del objetivo y la estrategia a ser implementada para la ejecución de la prueba.
26 4.2. Prueba de Tolerancia a Fallos
4.2.1 Objetivo
El objetivo de la prueba es definir la arquitectura con una mejor tolerancia a fallos e identificar las consideraciones necesarias para mejorarla.
4.2.2 Estrategia
Los fallos permanentes y de detención, son fallos sencillos de inyectar y comunes en los sistemas distribuidos, este tipo de fallos brindan herramientas suficientes para determinar la capacidad de tolerar los fallos de las arquitecturas, además se logra evitar variables exógenas a la arquitectura como algoritmos de validación para brindar tolerancia a fallos.
El algoritmo para el diseño de la prueba es el siguiente:
1. Determinar el tipo de fallos a inyectar: El primer paso consiste en determinar el tipo de fallos más pertinente para el diseño de la prueba. Como se menciona en el párrafo anterior, el tipo de fallos con mayor facilidad para la inyección y que permite un panorama de la reacción por parte de la arquitectura frente a los fallos, son los permanentes y de detención. Es decir, la detención permanente de un recurso brinda un panorama de cual es la solución más pertinente entre las arquitecturas presentes.
2. Determinar el número de fallos a inyectar: La prueba consiste en ir aumentando el número de fallos inyectadas durante la prueba hasta generar a un fallo total en la que el sistema no es capaz de responder a ninguna solicitud.
3. Determinar los tiempos para la inyección de cada fallo: Se deben identificar los momentos en los que se inyectan los diferentes errores. En este caso, se ha definido que los instantes de tiempo interesantes son aquellos en los que se incrementa la carga. Estos son deseados, con el propósito de observar el comportamiento de la tolerancia a fallos en un contexto elástico.
4. Determinar la cantidad solicitudes por unidad de tiempo: Un escenario interesante para determinar la reacción por parte de las arquitecturas, es aquel en el que existen cambios de carga de forma incremental, de esta manera se desea conocer la reacción en los instantes que se van incrementando el número de solicitudes. En la Figura 4.4 se evidencia los datos de la prueba: La cantidad de solicitudes por unidad de tiempo y el instante en el que se debe inyectar la falla. A partir de esta prueba se pretende observar el comportamiento y obtener las métricas para hacer el análisis pertinente.
Con el objetivo de identificar la arquitectura más pertinente sobre el requerimiento de tolerancia a fallas, se seleccionaron las siguientes métricas:
4.2.3 Métricas
• Carga por unidad de tiempo: Métrica necesaria para el cálculo del porcentaje de las solicitudes inválidas.
0 1 2 3 4 5
0 12 24 36 48 60 72
0 60 120 180 240 300
Fa
llo
s
Pe)ci
on
es
Segundos
Pe-ciones / Tiempo Fallos / Tiempo
Figure 4.4 Cambio de Carga e inyección de fallos en el tiempo
• Fallas inyectas por unidad de tiempo: Permite determinar la relación entre el número de fallas inyectadas y el porcentaje de solicitudes inválidas. Posibilita determinar si la cantidad de fallas determinan el estado general del sistema.
• Tiempo requerido para registrar fallas: Métrica que permite dimensionar el nivel de eficiencia de la arquitectura para identificar las fallas.
• Porcentaje de solicitudes inválidas por unidad de tiempo: El cálculo del porcentaje de solicitudes inválidas se determina mediante la razón entre la diferencia entre el total de solicitudes realizadas y el total de solicitudes exitosas contra el total de solicitudes realizadas.
%solicitudesinválidas =
solicitudestotal−solicitudesexitosas
solicitudestotal
Análisis y Consideraciones
Teniendo como base la experiencia y los resultados de la experimentación, se incluye un listado de consideraciones necesarias para mejorar la capacidad de tolerancia a fallos en cada una de las arquitecturas. Las consideraciones están relacionadas con la curva de aprendizaje para desarrollar teniendo en cuanta cada una de las arquitecturas, la implementación de nuevos desarrollos para mejorar la elasticidad, idoneidad para requerimientos de sistemas transaccionales y restricciones de desarrollo.
4.3 Software
Teniendo en cuenta el tipo de pruebas, basadas en pruebas de carga y estrés, la herramienta más utilizada es JMeter [9] con la configuración del plug-in:
Throughput Shaping Timer[53] el cual permite configurar el cambio en las cargas
de forma incremental.
28 4.3. Software
Solicitudes Iniciales
Solicitudes Finales
Tiempo en
Segundos
Incremento
24 24 60 0
36 36 60 12
48 48 60 12
60 60 60 12
5
Validación
Para describir la validación de este trabajo se va a dividir el capítulo en las siguientes secciones: Desarrollo de prototipos de las arquitecturas de aplicaciones Web. Selección de IaaS. Ejecución de las pruebas y por último análisis de los resultados obtenidos.
5.1 Prototipo
Los prototipos desarrollados resuelven el mismo problema el cual se describe mediante los siguientes requerimientos funcionales (Tabla 5.1 y Tabla 5.2). Con la finalidad de presentar un caso de estudio real, se han seleccionado dos requerimientos funcionales de los especificados de un producto, simulador de créditos para el sector no bancarizado, creado dentro del marco de un proyecto conjunto con la Universidad de los Andes.
Los siguientes requerimientos funcionales muestran características, tales como el uso intensivo de recursos computacionales, procesamiento de solicitudes en tiempos mayores a un segundo e.g., generación de créditos, que permiten presentar un escenario de pruebas con ciertas ventajas: 1. Un escenario controlado en el que se establece un número fijo de solicitudes. De esta manera, se prevén el número de solicitudes en el tiempo, facilitando la obtención de resultados para la comparación de la elasticidad y la tolerancia a fallos. 2. El uso intensivo de CPU y los tiempos mayores a 1 segundo, requeridos para dar respuesta a una solicitud, ofrecen 2 escenarios interesantes para evaluar las arquitecturas desde el requerimiento de tolerancia a fallos. Primero, las consecuencias de la inyección de fallos a las solicitudes enviadas previamente a la inyección de los mismos. Segundo, errores en las solicitudes posteriores a los fallos. 3. Al implementar el caso de estudio del simulador de crédito. Se cuenta con proceso de validación de los resultados del procesamiento y del servicio. Así pues, se tiene un mecanismo para validar las respuestas a las solicitudes.
Para evitar efectos no deseados e influencia por parte de la elección del lenguaje, se escoge un lenguaje y unframework específico para la construcción de los prototipos. Se identifica los posibles lenguajes de programación yframeworks