Estudio de rendimiento de una plataforma IoT en escenarios sanitarios

i Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Equation Chapter 1 Section 1 Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Autor: Ignacio Gómez Gómez Tutor: Jorge Calvillo Arbizu Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 ii iii Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Autor: Ignacio Gómez Gómez Tutor: Jorge Calvillo Arbizu Departamento de Ingeniería Telemática Dpto. Ingeniería Telématica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 iv v Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Trabajo de Fin de Grado: Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Autor: Ignacio Gómez Gómez Tutor: Jorge Calvillo Arbizu El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2021 El Secretario del Tribunal vi vii Estudio de rendimiento de una plataforma IoT en escenarios sanitarios A mi familia A mis maestros viii ix Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Agradecimientos A pesar de que en un comienzo decidí cursar una ingeniería por curiosidad e interés de conocer un mundo nuevo, finalmente estoy orgulloso de la decisión que tomé, ya que el mundo de la ingeniería y las telecomunicaciones me ha resultado realmente apasionante. Por ello estoy plenamente agradecido de tener la oportunidad de conocerlo y haber abierto la puerta a semejante fuente de conocimiento y posibilidades en mi vida. Agradecer a todas las personas que me han apoyado durante este duro pero bello trayecto, tanto familia, como amigos, anteriores y nuevos, que han surgido a lo largo de esta aventura y me han ayudado cuando el camino se hacía denso. Gracias a Jorge Calvillo, tutor que me ha guiado en este trabajo de fin de carrera, aportando respuesta a cualquier duda y estando atento en todo momento para buscar una solución o referencia, lo cual se agradece bastante. Ignacio Gómez Gómez Sevilla, 2021 xvi ÍNDICE DE TABLAS Tabla 1. Consulta de información. 2 Tabla 2. Trabajo inicial de los componentes. 2 Tabla 3. Conocimiento de Wilma y Authzforce. 3 Tabla 4. Estudio de herramientas de testing. 3 Tabla 5. Implementación de los escenarios. 3 Tabla 6. Pruebas y validación. 3 Tabla 7. Documentación. 4 Tabla 8. Tiempo total. 4 Tabla 9. Resumen Resultados. Peticiones de token a Keyrock 41 Tabla 10. Resumen resultados. Base de datos MySQL 45 Tabla 11. Resumen resultados. Base de datos MongoDB 49 Tabla 12. Política base para pruebas. Políticas de Authzforce 50 Tabla 13. Resultados de pruebas para diferente número de usuarios paralelos. Pruebas de Tensión 53 Tabla 14. Tiempos 200 Usuarios. Pruebas de Tensión 53 Tabla 15. Tiempos 300 Usuarios. Pruebas de Tensión 54 Tabla 16. Resumen de los resultados. Límites del sistema. 56 xvii Estudio de rendimiento de una plataforma IoT en escenarios sanitarios xviii ÍNDICE DE FIGURAS Figura 1. Esquema del sistema 5 Figura 2. Logo de Fiware 7 Figura 3. Logo OCB 8 Figura 4. Esquema Context Element 8 Figura 5. Logo de Keyrock 9 Figura 6. Logo Authzforce 10 Figura 7. Logo Ubuntu 20.04 LTS 10 Figura 8. WMware Workstation Player 16 11 Figura 9. Logo de Postman 11 Figura 10. Logo Docker 12 Figura 11. Logo Docker-Compose 12 Figura 12. Logo MongoDB 12 Figura 13. Logo MySQL 12 Figura 14. Logo Wireshark 13 Figura 15. Logo Jmeter 14 Figura 16. Esquema de la plataforma a testear 15 Figura 17. Diagrama funcionamiento plataforma. Ejemplo GET 16 Figura 18. Ejemplo de entidad de tipo "ActividadFisica" 17 Figura 19. Petición de token a Keyrock por parte de agente o usuario 17 Figura 20. Respuesta de Keyrock con token tras validación 18 Figura 21. Petición POST a Wilma por parte de agente IoT 20 Figura 22. Wilma pregunta a Keyrock para que autorice a un usuario con un token 20 Figura 23. Respuesta de Keyrock a Wilma con los datos del usuario o agente 21 Figura 24. Wilma consulta a Authzfoce la validez de la acción demandada 22 Figura 25. Respuesta afirmativa de Authzforce. 25 Figura 26. Wilma redirige la petición a Orion Context Broker 25 Figura 27. Información de la entidad a crear con el POST que viaja a Orion Context Broker 26 Figura 28. Respuesta de Orion Context Broker a Wilma 27 Figura 29. Reenvío del mensaje por parte de Wilma al agente o usuario demandante 27 Figura 30. Ejemplo de política básica de Authzforce 28 Figura 31. Petición de token a Keyrock 29 Figura 32. Conexión MySQL JMeter 30 Figura 33. INSERT de users 31 xix Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Figura 34. INSERT de roles de los usuarios 31 Figura 35. Carga MongoDB 31 Figura 36. Ejemplo de añadir Política a Authzforce 32 Figura 37. Configuración JMeter 2.000. Peticiones de token a Keyrock 33 Figura 38. Transacciones JMeter 2000. Peticiones de token a Keyrock 33 Figura 39. Hilos JMeter 2000. Peticiones de token a Keyrock 34 Figura 40. Tiempos JMeter 2000. Peticiones de token a Keyrock 34 Figura 41. Tabla JMeter 2000. Peticiones de token a Keyrock 34 Figura 42. Configuración JMeter 5000. Peticiones de token a KeyrockJMeter 35 Figura 43. Transacciones JMeter 5000. Peticiones de token a KeyrockJMeter 35 Figura 44. Hilos JMeter 5000. Peticiones de token a Keyrock.JMeter 36 Figura 45. Tiempos JMeter 5000. Peticiones de token a Keyrock 36 Figura 46. Tabla JMeter 5000. Peticiones de token a Keyrock 36 Figura 47. Configuración JMeter 8500. Peticiones de token a Keyrock 37 Figura 48. Transacciones JMeter 8500. Peticiones de token a Keyrock 37 Figura 49. Hilos JMeter 8500. Peticiones de token a Keyrock 38 Figura 50. Tiempos JMeter 8500. Peticiones de token a Keyrock 38 Figura 51. Tabla JMeter 8500. Peticiones de token a Keyrock 38 Figura 52. Configuración JMeter 10000. Peticiones de token a Keyrock 39 Figura 53. Transacciones JMeter 10000. Peticiones de token a Keyrock 39 Figura 54. Hilos JMeter 10000. Peticiones de token a Keyrock 39 Figura 55. Tiempo JMeter 10000. Peticiones de token a Keyrock 40 Figura 56. Tiempo JMeter 10000. Peticiones de token a Keyrock 40 Figura 57. Errores JMeter 10000. Peticiones de token a Keyrock 40 Figura 58. Peticiones lineales. Peticiones de token a Keyrock 41 Figura 59. Esquema JMeter 1 Usuario. Base de datos MySQL 42 Figura 60. Hilos JMeter 1 Usuario. Base de datos MySQL 42 Figura 61. Tiempos JMeter 1 Usuario. Base de datos MySQL 43 Figura 62. Tabla JMeter 1 Usuario. Base de datos MySQL 43 Figura 63. Esquema JMeter 10000 Usuarios. Base de datos MySQL 43 Figura 64. Hilos JMeter 10000 Usuarios. Base de datos MySQL 44 Figura 65. Tiempos JMeter 10000 Usuarios. Base de datos MySQL 44 Figura 66. Tabla JMeter 10000 Usuarios. Base de datos MySQL 44 Figura 67. Errores JMeter 10000 Usuarios. Base de datos MySQL 45 Figura 68. Esquema JMeter 10000 Entidades. Base de datos MongoDB 46 Figura 69. Hilos JMeter 10000 Entidades. Base de datos MongoDB 46 Figura 70. Tiempos JMeter 10000 Entidades. Base de datos MongoDB 47 Figura 71. Tabla JMeter 10000 Entidades. Base de datos MongoDB 47 Figura 72. Esquema JMeter 50000 Entidades. Base de datos MongoDB 47 xx Figura 73. Hilos JMeter 50000 Entidades. Base de datos MongoDB 48 Figura 74. Tiempos JMeter 50000 Entidades. Base de datos MongoDB 48 Figura 75. Tabla JMeter 50000 Entidades. Base de datos MongoDB 48 Figura 76. Tiempos 1 Usuario. Política Básica. Políticas de Authzforce 50 Figura 77. Tiempos 200 Usuarios. Política Básica. Políticas de Authzforce 51 Figura 78. Tiempos 1 Usuario. Política Compleja. Políticas de Authzforce 51 Figura 79. Tiempos 200 Usuarios. Política Compleja. Políticas de Authzforce 52 Figura 80. Tiempos 400 Usuarios. Pruebas de Tensión 54 Figura 81. Tiempos 500 Usuarios. Pruebas de Tensión 55 Figura 82. Error User Token not authorized 55 Figura 83. Evolución tiempos con carga de POST directa a MongoDB 57 Figura 84. Tiempos GET ORION con MongoDB cargado 57 Figura 85. Tiempos petición POST aislada 58 Figura 86. Distribución directorios y ficheros del sistema 62 Figura 87. Opciones script services.sh 63 Figura 88. Docker-compose. Orion Context Broker 63 Figura 89. Docker-compose. Keyrock 64 Figura 90. Docker-compose. Authzforce 65 Figura 91. Docker-compose. MongoDB y MySQL 65 Figura 92. Interfaz de Postman 67 Figura 93. Acceso directo JMeter 68 Figura 94. Interfaz JMeter 69 Figura 95. Botones Interfaz JMeter 69 Figura 96. Grupo de Hilos JMeter 70 Figura 97. Añadir grupo de hilos JMeter 70 Figura 98. Añadir elementos JMeter 71 Figura 99. Pestaña Plugins Manger JMeter 71 Figura 100. Plugins Manager Menu JMeter 72 Figura 101. Conector mysql JMeter. Carpeta de plugins 73 Figura 102. Script conexión base de datos MySQL 73 xxi Estudio de rendimiento de una plataforma IoT en escenarios sanitarios 1 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios 1 INTRODUCCIÓN 1.1 Motivación Actualmente, la mayoría de dispositivos electrónicos de nuestro entorno son capaces de conectarse a internet y formar parte de lo que se conoce como “Internet of Things”, o más conocido por sus siglas “IoT”, conectándose a otros y siendo capaces de interactuar entre ellos. Esta tecnología la cual se encuentra en pleno auge, será probablemente una de las principales que nos acompañarán en el futuro. Términos relacionados con IoT pueden ser las “Smart Cities” o “Industria 4.0” donde se utiliza esta tecnología en dispositivos que permiten el control del tráfico, control de la electricidad, suministros de agua… además de las fábricas donde los diferentes instrumentos empleados en los procesos de producción se conectan entre ellos e interactúan sin necesidad de la acción humana. En nuestro caso, trataremos la aplicación en el ámbito sanitario, en el que las diferentes tecnologías existentes se apoyan en el uso de dispositivos IoT. El IoT en sanidad supone la integración de forma inteligente de los datos recogidos por los sensores de los dispositivos médicos y tecnologías de comunicación móviles que se utilizan en la asistencia sanitaria. En este caso se estudiará el uso de sensores que recopilan información útil de las constantes vitales de los pacientes y la envían a una base de datos donde estos datos convergen, permitiendo el estudio de la salud de los pacientes. Como en cualquier sistema, en las plataformas IoT el testeo es un proceso fundamental para garantizar su calidad y funcionamiento óptimo. En un sistema IoT que recibe información constante de dispositivos, existiendo un flujo de datos importante, es necesario comprobar de qué forma se ve afectado el rendimiento cuando se aumenta el número de elementos conectados, y con ello el flujo de información y peticiones. Por ello, en este trabajo se van a llevar a cabo una serie de pruebas de rendimiento sobre una plataforma IoT para estudiar aquellos módulos del sistema que soportan menor carga, y que, por lo tanto, limitan al sistema en cuestión. Como caso de uso se utilizará un dispositivo sensor integrado en una camiseta inteligente que obtiene datos de la actividad física de los pacientes que la visten. Este dispositivo ha sido desarrollado por el Grupo de Ingeniería Biomédica de la ETSI. La información obtenida por las camisetas es publicada por agentes IoT y, mediante los componentes FIWARE, se asegura la integridad de la información y la seguridad del sistema. Este sistema almacena una gran cantidad de información (de autenticación de pacientes y médicos, de constantes vitales de los pacientes…) y mediante pruebas de cargas aumentaremos esta información y flujo de datos para comprobar cómo rinde el sistema bajo determinadas circunstancias. Una motivación añadida para llevar a cabo este trabajo es el interés personal por conocer nuevas herramientas relacionadas con “QA tester”, o “quality assurance tester”, un puesto de trabajo que abarca el estudio de calidad y rendimiento de sistemas, y que es muy importante y valorado hoy en día. Añadiendo que previamente he recibido una oferta para un empleo en una empresa como Ingeniero de Rendimiento, en cuyo puesto se requiere el uso de JMeter para testear el rendimiento de determinados sistemas. 1.2 Objetivos del Proyecto El objetivo principal del proyecto es el diseño y ejecución de baterías de pruebas de carga usando JMeter para comprobar el rendimiento del sistema bajo determinadas circunstancias y localizar los puntos críticos del mismo también conocidos como cuellos de botella. Para poder diseñar y lanzar las diferentes pruebas de carga con JMeter, primero tenemos que hacer un estudio del sistema, para conocer el funcionamiento de los componentes del mismo y cómo se relacionan entre ellos. Esto se debe principalmente a que nuestro sistema (y cualquier otro) estará formado por varios componentes, ya sean bases de datos, proxys, servidores, clientes, sistemas de seguridad… y cada uno de ellos funcionará de una manera diferente, aportando ciertas limitaciones al sistema. 2 Una vez analizado el sistema componente a componente nos dispondremos a crear diferentes escenarios, en cada uno de los cuales colocaremos bajo carga un componente del sistema para comprobar cómo afecta al funcionamiento global, y encontrar los factores que resultan más limitantes lanzando pruebas con una herramienta de pruebas de carga, en este caso y tras el estudio de varias herramientas, he escogido JMeter. 1.3 Plan de trabajo En este apartado se van a detallar las tareas que se han realizado para llevar a cabo el proyecto, y una comparación del tiempo estimado y el tiempo real dedicado a cada una de ellas. Estas tareas son las siguientes: • Tarea 1: Búsqueda y obtención de la información. En esta actividad inicial se estudiará la documentación de los diferentes componentes de la plataforma IoT, tanto los componentes funcionales como los de seguridad. Consulta de información Tiempo estimado Tiempo real Investigación de componentes del sistema. 35 horas 48 horas Total 35 horas 48 horas Tabla 1. Consulta de información • Tarea 2: Instalación de los diferentes componentes. En esta tarea también se ha tenido en cuenta la comprobación de la conexión entre todos los componentes y el tiempo invertido en la solución de los errores que se han obtenido en la instalación de estos. Trabajo inicial de los componentes Tiempo estimado Tiempo real Instalación de los componentes y comprobación de la conexión entre ellos 25 horas 45 horas Total 25 horas 45 horas Tabla 2. Trabajo inicial de los componentes • Tarea 3: Esta tarea va a consistir en tratar de entender los diferentes archivos de configuración de Wilma y de conocer un lenguaje nuevo, XACML, que es usado en Authzforce para establecer diferentes políticas con el fin de autorizar a diferentes usuarios. Conocimiento de Wilma y Authzforce Tiempo estimado Tiempo real Conocimiento de los archivos de configuración de Wilma 10 horas 10 horas Búsqueda de información sobre el lenguaje XACML 12 horas 15 horas 3 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Total 22 horas 25 horas Tabla 3. Conocimiento de Wilma y Authzforce • Tarea 4: El propósito de esta tarea es investigar herramientas de testing como SoapUI, o JMeter, para decidir cuál usar, en nuestro caso, JMeter. Estudio de herramientas de Testing Tiempo estimado Tiempo real Recolección de información sobre herramientas de testing. 10 horas 15 horas Elección de la mejor para nuestro caso, JMeter, y estudio de la misma para hacer uso de ella 100 horas 120 horas Total 110 horas 135 horas Tabla 4. Estudio de herramientas de testing • Tarea 5: Esta tarea va a tratar sobre el diseño y desarrollo de los posibles escenarios que se pueden implementar y el tiempo dedicado sobre los mismos • Tarea 6: Pruebas y validación de los diferentes escenarios planteados Pruebas y validación Tiempo estimado Tiempo real Pruebas de cada escenario 5 horas 8 horas Corrección de errores en la puesta en marcha de los escenarios 5 horas 10 horas Total 10 horas 18 horas Tabla 6. Pruebas y validación Tabla 5. Implementación de los escenarios. Implementación de los escenarios Tiempo estimado Tiempo real Planteamiento de los posibles escenarios 10 horas 15 horas Desarrollo de los escenarios 70 horas 90 horas Total 80 horas 105 horas 10 2.4.4 Authzforce AuthzForce [5]es un componente FIWARE que proporciona un marco de control de acceso basado en atributos (ABAC), facilitando una API para obtener decisiones de autorización basadas en políticas de autorización y solicitudes de autorización desde un PEP. Authzforce evalúa decisiones de autorización basadas en políticas XACML y atributos relacionados con una solicitud de acceso determinada (por ejemplo, identidad del solicitante, recurso solicitado, acción solicitada), siguiendo la lógica de evaluación de políticas definida en XACML. Authzforce además de actuar como PDP, puede actuar como punto de administración de políticas (PAP), esto significa que los PolicySets se pueden crear y modificar utilizando llamadas API directamente a Authzforce. Sin embargo, no existe una GUI para crear o modificar una <PolicySet>. Por tanto, utilizaremos Postman para modificar las políticas ya que aporta cierta simplicidad al proceso, en vez de usar la consola de comandos que resulta más problemático dada la magnitud de algunas políticas. 2.5 Tecnologías y recursos software utilizados. Para realizar el proyecto, ha sido necesario utilizar diferentes herramientas software, tanto para el despliegue de la plataforma, para el despliegue del entorno en el que se va a instalar y desarrollar las pruebas, para la realización de las propias pruebas y para la propia plataforma. 2.4.5 Máquina Virtual Ubuntu 20.04.0 LTS Tanto la plataforma como la herramienta de pruebas de carga han sido desplegados en una máquina virtual Ubuntu 20.04.0 LTS [6], sistema operativo Linux. Este sistema operativo ha sido escogido ya que la administración y despliegue de aplicaciones es más sencillo en este entorno que en Windows, y es un sistema operativo con el que hemos trabajado a lo largo de la carrera por lo que el conocimiento sobre este es de gran ayuda para llevar a cabo el trabajo. Figura 7. Logo Ubuntu 20.04 LTS Figura 6. Logo Authzforce 11 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios 2.4.6 VMware Workstation Player 16 VMware Workstation Player 16 [7]es una herramienta que permite ejecutar una máquina virtual con un sistema operativo diferente al que se use en el PC. He escogido esta herramienta ya que es la que hemos estado utilizando a lo largo de la carrera y el conocimiento previo es de ayuda. Figura 8. WMware Workstation Player 16 2.4.7 Postman Postman [8] es un servicio que permite simular peticiones REST a una API, cuenta con una interfaz gráfica bastante detallada e intuitiva por lo que su manejo resulta sencillo. Con Postman podemos hacer todo tipo de peticiones como POST, GET, PUT, PATCH … Ha sido utilizado para comprobar el correcto funcionamiento de la plataforma IoT en las pruebas unitarias, haciendo peticiones a la API de cada módulo por separado, y luego para comprobar el funcionamiento en conjunto, haciendo peticiones de GET para recoger entidades de Orion Context Broker, almacenadas en MongoDB, para almacenar nuevas entidades con POST, para actualizarlas con PATCH u otras de POST para que un usuario se subscriba a una entidad y reciba información sobre el cambio cuando esta sea actualizada. También ha sido de gran ayuda para el manejo de políticas de Authforce ya que hacerlo por la terminal era bastante farragoso pero con la interfaz gráfica de Postman se ha solucionado ese problema. 2.4.8 Docker y Docker-Compose Docker [9]es un Proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contendores software a partir de imágenes previamente creadas, proporcionando una capa adicional de abstracción y permitiendo la virtualización de aplicaciones en múltiples sistemas operativos. Docker consta de imágenes y contenedores: Figura 9. Logo de Postman 12 • Una imagen es la especificación inerte, inmutable, una foto del estado y de unas piezas de software que incluyen desde la aplicación que queremos ejecutar hasta las librerías y todo lo necesario para que se ejecute encima del sistema operativo que lo contiene. • Un contenedor es un entorno aislado con la instanciación de una imagen, el cual se puede configurar. Docker permite la independencia de las aplicaciones que desplegamos en los contenedores, del sistema operativo. Esto se usa cuando por ejemplo queremos desplegar una plataforma en una gran cantidad de equipos, cada uno con un entorno diferente, si tratamos de instalarlos directamente en el sistema, en cada equipo requeriremos ciertos complementos que serán diferentes a los requeridos en otro. Con Docker aislamos las imágenes del sistema pudiendo replicar la plataforma en diferentes entornos sin problemas de compatibilidad. También será necesario el uso de la herramienta Docker-Compose [10] para poder desplegar aplicaciones formadas por diferentes contenedores que se relacionan e interactúan entre ellos. Por ejemplo, en este proyecto, Orion Context Broker y MongoDB están relacionados, al igual que Keyrock con MySQL y Authforce. 2.4.9 MongoDB y MySQL MongoDB [11]es una base de datos orientada a documentos. Esto quiere decir que, en lugar de guardar los datos en registros, guarda los datos en documentos. Estos documentos son almacenados en BSON, que es una representación binaria de JSON. Orion Context Broker va a utilizar MongoDB para almacenar toda la información relativa a las entidades. MySQL [12]es un sistema de gestión de bases de datos relacional desarrollado bajo licencia dual: Licencia pública general/Licencia comercial por Oracle Corporation y está considerada como la base de datos de código abierto más popular del mundo Figura 10. Logo Docker Figura 11. Logo Docker-Compose Figura 12. Logo MongoDB Figura 13. Logo MySQL 13 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios 2.4.10 Wireshark Wireshark [13]ha sido utilizado para capturar los mensajes que viajan entre los diferentes módulos del sistema, para comprobar el funcionamiento de este y analizar el contenido de los mensajes, entendiendo así el comportamiento interno de la plataforma, como veremos en el siguiente apartado. Figura 14. Logo Wireshark 2.4.11 Herramientas de Testing Existen diferentes herramientas para el estudio del rendimiento en un sistema o aplicación, y con ellas se puede, desde lanzar diversas peticiones para poner aprueba una API hasta cargar una red de o una base de datos para el posterior estudio del rendimiento, siendo esto lo que más nos interesa. 2.4.11.1 Análisis de herramientas existentes Existen diferentes herramientas para el estudio del rendimiento en un sistema o aplicación, y con ellas se puede, desde lanzar diversas peticiones para poner aprueba una API hasta cargar una red de o una base de datos para el posterior estudio del rendimiento, siendo esto lo que más nos interesa. Las principales herramientas estudiadas son: JMeter: Sin duda la herramienta más recomendable para realizar pruebas de carga y estudiar el rendimiento, contando con una gran cantidad de complementos para llevarlas a cabo y dibujar los resultados en gráficas o mostrar tablas con los mismos. Lleva bastante tiempo siendo utilizada en el mundo laboral. • SoapUI: Potente herramienta de testeo de API bastante utilizada en el mundo laboral. Pese a que es capaz de realizar pruebas de carga, son bastante específicas, no tan flexibles ni diversas como en JMeter. • LoadRunner: Sin duda una de las mejores herramientas para pruebas de rendimiento en plataformas y sistemas. Es una herramienta de pago, por lo que he priorizado JMeter al ser de código abierto. A pesar de ser bastante potente, JMeter es más fácil de utilizar, siendo bastante sencillo añadir complementos, guardar variables, se puede realizar scripting sin necesidad de conocimientos previos, además de mostrar los resultados en gráficas de manera bastante intuitiva, con una fácil interpretación de los resultados. Todo esto hace que muchas empresas prefieran JMeter en vez de LoadRunner. • Blazemeter: Orientado principalmente a aplicaciones móviles, aplicaciones web o testeo de API en continuo desarrollo, es decir, agrupando los resultados y comprobando la evolución del proyecto. No sería mala idea utilizarlo para comprobar mejorías en el desarrollo de la plataforma, pero dado que nuestro objetivo es evaluarla en su forma actual y conocer sus límites de rendimiento actuales con el fin de mejorarlos en caso de ser necesario, o de tenerlos en cuenta para no sobrepasarlos (monitorizar el sistema), es más preferible utilizar JMeter. Finalmente, tras evaluar las ventajas y desventajas de cada una, la elegida es JMeter, la cual es bastante potente, cuenta con una gran cantidad de recursos y oportunidades de pruebas, cumpliendo sobradamente con lo que necesitamos para nuestro caso. 14 2.4.11.2 JMeter JMeter [14]es un software de código abierto utilizado en la realización de test de carga para comprobar el comportamiento y medir el rendimiento de aplicaciones y sistemas. Con JMeter se pueden realizar pruebas de aplicaciones web, mandado peticiones HTTP/HTTPS, también se pueden testear webservices basados en SOAP/REST, establecer conexión a una base de datos y llevar a cabo acciones en la misma como cargarla con un elevado número de entidades o solicitudes y así comprobar el comportamiento, pudiendo mostrar gráficas de cómo el sistema evoluciona en cuanto a velocidad en las respuestas, errores, número de hilos… Figura 15. Logo Jmeter 15 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios 3 ESTUDIO DEL SISTEMA no de los pasos más importantes que se debe dar a la hora de resolver un problema es el correcto análisis del mismo. Esta sección refleja el trabajo previo que se realizó para nuestro trabajo y que debería de servir de ejemplo para cualquier proceso de testing de un sistema. Analizar cada módulo y su funcionamiento es vital para diseñar las diferentes pruebas y sus limitaciones de rendimiento. En la siguiente imagen se muestra el sistema y cómo los diferentes módulos se relacionan entre sí: Figura 16. Esquema de la plataforma a testear A grandes rasgos, los agentes IoT o usuarios, que son emulados por una herramienta de pruebas, en este caso JMeter, dirigirá las peticiones a Wilma PEP Proxy, en estas peticiones irá el token de acceso que previamente Keyrock debe haber otorgado a los usuarios previamente registrados, cuya información se almacena en la base de datos MySQL. Wilma validará este token de acceso preguntando a Keyrock. En caso de ser válido, consultará con Authforce si el usuario o agente está autorizado para realizar determinada acción demandada en la petición y, en caso afirmativo, redirigirá la petición al Orion context Broker, quien procesará la petición y responderá de una forma u otra dependiendo de la acción que se requiera, consultando la base de datos MongoDB donde se encuentran las entidades, ya sea para actualizar una (PATCH), añadir una nueva (POST), obtener una entidad (GET) o establecer una relación de subscripción de un usuario a una entidad (SUBSCRIBE). A continuación se muestra un diagrama con las interacciones entre los diferentes módulos en el caso de un usuario enviando una petición GET para obtener la información de un sensor. U 16 Figura 17. Diagrama funcionamiento plataforma. Ejemplo GET A continuación, se describirá cada componente de manera individual. 3.1 Orion Context Broker Orion Context Broker será el manejador de las solicitudes de obtención, publicación, actualización y subscripción que los agentes o usuarios lanzarán. Orion estará protegido frente a vulnerabilidades gracias a Keyrock y Authforce, encargados de autenticar a los usuarios y agentes que desean acceder al sistema, y de validar sus peticiones, ya que las políticas de Authforce se diseñan para limitar las acciones que un usuario puede realizar y proteger el sistema. Para este proyecto se va a trabajar con entidades que contienen datos de la actividad física de un paciente, a partir de la información recogida y enviada a un agente IoT gracias a los sensores de las camisetas inteligentes. Esta información puede ser consultada, actualizada por un usuario (médico) que puede subscribirse a los cambios que experimente una entidad. Las entidades cuentan con una serie de atributos: • “id”: Representa el identificador de cada entidad • “type”: En este caso serán todos de “ActividadFisica” • “publisher”: Es el agente IoT que publica la entidad. • “id_patient”: Es el usuario que utiliza la camiseta. • “timestamp”: Indica la hora a la que se realizó la prueba. • “id_device”: Identifica la camiseta usada. • “organization”: Organización a la que pertenece el paciente y la camiseta. • “accumulates_metabolic_expenditure”. Se trata del gasto calórico total del paciente. • “instant_metabolic_expenditure”. Es el gasto calórico instantáneo en el momento en el que se envía el mensaje. 17 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Figura 18. Ejemplo de entidad de tipo "ActividadFisica" Orion Context Broker será un punto que cargaremos, llenando de entidades la base de datos MongoDB donde almacena la información de las entidades y acumulando una serie de usuarios de manera paralela que manden peticiones, de este modo comprobaremos cómo afecta la carga de este módulo al rendimiento del sistema. 3.2 Keyrock Keyrock se ha configurado para escuchar peticiones en el puerto 3005, y su función consiste en garantizar la identidad de todo aquel usuario o agente IoT que quiera acceder al sistema para lo cual tendrá que estar registrado previamente. El registro de los usuarios, organizaciones, PEP Proxy, roles, etc., lo puede realizar el administrador del sistema mediante la interfaz gráfica de Keyrock. Pero se ha optado a crear un estado inicial de la base de datos MySQL donde ya se configura todo el registro. El estado inicial se explica en el Anexo B. Wilma acudirá a Keyrock para autenticar al usuario o agente IoT. Cuando un agente envía a Keyrock sus credenciales (Figura 19), este verifica al usuario buscando en su base de datos MySQL las credenciales, y responde, en caso afirmativo, con el token que el usuario debe utilizar para acceder al sistema en sus peticiones (Figura 20). Figura 19. Petición de token a Keyrock por parte de agente o usuario 18 Figura 20. Respuesta de Keyrock con token tras validación 3.3 MySQL En la base de datos MySQL se almacenará la información relativa a los usuarios y agentes registrados en el sistema, la cual será utilizada por Keyrock para validar la identidad de los usuarios que tratan de acceder al sistema. Contaremos con diferentes tablas dentro de esta base de datos, las cuales aumentarán su tamaño conforme más usuarios o agentes IoT estén registrados, debido a esto, el elemento crítico en este módulo del sistema será la cantidad de usuarios registrados, tanto agentes (camisetas con sensores IoT) como médicos registrados en la plataforma. 3.4 MongoDB MongoDB será la base de datos que utilizará Orion Context Broker para almacenar la información de las diferentes entidades existentes, y sobre la cual llevará a cabo las operaciones de consulta e inserción de nuevas entidades, por lo que esta base de datos será un punto importante en el estudio del sistema para comprobar si su carga afecta o no al rendimiento del sistema, debido a la posibilidad de que se lleve de una gran cantidad de datos. MongoDB presenta un esquema libre, es decir, cada entrada o registro almacenado en la base de datos puede tener un esquema de datos diferente. Estos registros pueden cambiar en cualquier momento siendo actualizados. A cada registro se le denomina documento. Los documentos se componen de pares clave-valor, con una composición similar a una estructura JSON (Figura 18). En MongoDB los documentos son almacenados en formato BSON, una versión binaria de JSON que acelera la búsqueda de datos ya que guarda información como longitudes o índices que facilitan el trabajo posterior de búsqueda de entidades. En este punto del sistema, para MongoDB el parámetro que afectará al rendimiento será la cantidad de entidades 19 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios que existan, es decir, la cantidad de información recolectada por los sensores de las camisetas y almacenadas en esta base de datos. Se presumen que a medida que MongoDB esté más cargado, se ralentizará la búsqueda de entidades. 3.5 PEP Proxy Wilma Wilma está configurado para escuchar peticiones en el puerto 1027. Cuando intercepte una petición, Wilma comprobará la autenticación del usuario consultando a Keyrock, proporcionándole a este componente el token de acceso indicado por el usuario. Si el usuario está registrado, Wilma enviará a Authzforce una solicitud de decisión de autorización para comprobar si el usuario puede realizar una consulta, publicación o suscripción de una entidad. En dicha solicitud, Wilma indicará una serie de parámetros de gran importancia para Authzforce: • El rol que tiene el usuario que está intentando acceder. Wilma obtiene este valor a partir de la respuesta que le da Keyrock al ser autenticado correctamente. • El id de la aplicación donde está registrado el usuario. • La acción que pretende realizar, por ejemplo, POST, GET, DELETE, PATCH. • El recurso que pretende acceder el usuario, en nuestro proyecto será /v2/entities o /v2/subscriptions • Se enviarán atributos que tratan el tiempo y aspectos dinámicos del escenario de control de acceso, como por ejemplo los atributos expuestos en la publicación de una entidad. Siendo Wilma el punto central del sistema por el que pasa toda la información, se describirá aquí un ejemplo básico del sistema con los mensajes filtrados por Wireshark donde vemos el funcionamiento de Wilma y del sistema completo. En la Figura 21 se muestra un ejemplo de una petición POST, creada con JMeter, de una nueva entidad, formulada por un supuesto agente IoT previamente registrado en Keyrock. Esta petición el agente IoT la dirige al proxy Wilma, [Full request URI: http://localhost:1027/v2/entities?options=keyValues], que con estos parámetros y el X-Auth-Token, validará al usuario preguntando a Keyrock, y posteriormente a Authforce para validar la acción, en función del valor de los parámetros en cuestión. 26 Figura 27. Información de la entidad a crear con el POST que viaja a Orion Context Broker Finalmente, Orion Context Broker responde con el resultado de la operación, en este caso “created” (Figura 28) y Wilma termina su función reenviando este mensaje al usuario o agente que realizó la petición (Figura 29). 27 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Figura 28. Respuesta de Orion Context Broker a Wilma Figura 29. Reenvío del mensaje por parte de Wilma al agente o usuario demandante Todo este es el trabajo de Wilma, actuar como Proxy para distribuir los mensajes por la aplicación. Dependiendo de la acción este proceso puede variar en algún mensaje, pero ese es el funcionamiento básico. Este estudio del intercambio de mensajes y de la información que viaja en ellos ha sido útil para el diseño de políticas para poner a prueba Authzforce y así saber qué campos e información estaba siendo tenida en cuenta y así confeccionar políticas más complejas y tediosas, que veremos si afecta o no al rendimiento del sistema. 28 3.6 Authzforce Authzforce se encargará de verificar si el usuario puede realizar determinada acción, basándose en la información recibida por Wilma en el mensaje (Figura 24) X Su decisión estará supeditada a una serie de políticas. Authzforce poseerá un dominio de políticas con una serie de PolicySets y de VariableDefinitions. Estas políticas se escriben en el lenguaje XACML. Un ejemplo sería la política siguiente, en la que se verifica el recurso es escenario_sanitario, que la acción será PATCH y la url a la que va dirigida sea /v2/entities, gracias al método de MatchId string-equal: Figura 30. Ejemplo de política básica de Authzforce La política debe ser activada para que funcione, no obstante, en nuestro caso, introduciremos en la base de datos el dominio que se encontrará activo y la política, y lo que haremos será añadir diferentes versiones de la misma con Postman. De este modo actualizaremos las políticas para las diferentes pruebas de manera sencilla y sin tener que añadir diferentes dominios o políticas que deban ser activadas. 29 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios 4 RESULTADOS 4.1 Puntos de carga Una vez hemos analizado el funcionamiento del sistema, estamos preparados para preparar nuestras pruebas de carga que van a analizar el rendimiento del mismo. Para someter nuestro sistema bajo carga vamos a utilizar la ya nombrada herramienta: JMeter. Postman será utilizada para cambiar las políticas del sistema y así poner a prueba el módulo Authzforce. Tanto la carga del sistema de datos para su posterior análisis de rendimiento, como las propias pruebas de rendimiento, han sido lanzadas con JMeter. Por ejemplo, si queremos saber cómo se comporta la base de datos cuando posee 1000 usuarios registrados, con JMeter conectaremos con la base de datos, introduciremos la información de los 1000 usuarios y posteriormente, también con JMeter trataremos de poner a funcionar la base de datos con peticiones para comprobar cómo rinde. Se han identificado 5 parámetros en nuestro sistema cuya carga puede afectar al rendimiento: • Petición de token a Keyrock. • Base de datos MySQL. • Base de datos MongoDB. • Políticas de Authzforce. • Pruebas de tensión, con el fin de encontrar el límite de peticiones simultáneas que se soporta. Realizaremos diferentes tipos de pruebas para cada parámetro, tanto lineales, con peticiones que llegan una detrás de otra, y paralelas, con usuarios que envían sus peticiones a la vez. Centraremos el estudio principalmente en ver cómo varía el retraso de la respuesta del sistema y el porcentaje de errores. 4.1.1 Petición de token a Keyrock El paso previo a cualquier petición que un agente o usuario realice al sistema es pedir un token a Keyrock. Así, se estudiará el caso en el que una gran cantidad de usuarios pidan su token a la vez a Keyrock para comprobar cómo afecta al rendimiento. Esta prueba no afecta al sistema completo ya que son peticiones que se realizan previamente al envío de cualquier petición a Wilma, ya que se requiere para ello el token previo que entrega Keyrock como se explicó previamente. Para realizar estas peticiones hemos utilizado una HTTP Request al puerto 3005 que contiene el usuario y contraseña de los agentes o usuarios registrados en el sistema que desean obtener su token de acceso. Estos usuarios deben haber sido previamente registrado en la base de datos MySQL para que Keyrock les otorgue su token. Figura 31. Petición de token a Keyrock Se realizarán pruebas de carga tanto lineales como en paralelo para comprobar el rendimiento. 30 4.1.2 Base de datos MySQL Cada vez que un usuario accede al sistema con su token, Wilma necesita preguntarle a Keyrock si el token es válido y Keyrock consulta la base de datos MySQL para verificarlo. Cargaremos esta base de datos con grandes cantidades de usuarios para ver si esto afecta al rendimiento del sistema. Para cargar la base de datos de MySQL nos conectamos con JMeter gracias al conector JDBC Connection Configuration. Para usar este conector hacen falta algunos pasos previos que serán explicados en el Anexo D, Figura 32. Conexión MySQL JMeter Con este complemento de JMeter nos conectamos a la base de datos con un Username y Password que previamente hemos introducido con un script y hemos habilitado para que JMeter pueda acceder (el Anexo D). Una vez establecida la conexión con la base de datos, introducimos las sentencias que deseamos, utilizando el 31 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios nombre de la Pool que hemos creado, en este caso “Cloud”: Figura 33. INSERT de users Figura 34. INSERT de roles de los usuarios Introduciremos diferentes cantidades de usuarios en MySQL para comprobar el rendimiento. Para cargarlo con usuarios válidos que puedan ser utilizados en las pruebas de login posteriormente, se ha creado un fichero de formato CSV que contiene cerca de 10.000 nombres y emails, de este modo podemos utilizar el mismo fichero para el registro y la posterior obtención de token para una gran cantidad de usuarios. 4.1.3 Base de datos MongoDB Orion Context Broker utiliza esta base de datos para almacenar la información de los sensores de cada agente IoT. Así que querremos también conocer cómo afecta al rendimiento la cantidad de entidades almacenadas en esta base de datos. Para llenar de entidades MongoDB hemos utilizado una petición HTTP con el método POST dirigida directamente al puerto 1026, con el JSON en el cuerpo del mensaje: Figura 35. Carga MongoDB Este JSON se rellena con los datos de un fichero CSV que contiene una gran cantidad de Agentes con diferente DNI. Además de un contador que va creciendo para que cada POST sea de un sensor diferente. 32 4.1.4 Políticas de Authzforce Authzforce debe evaluar en función de las políticas previamente declaradas si la realización de determinada actividad es posible o no para determinado agente o usuario. Añadiendo políticas de gran longitud comprobaremos si esto afecta al rendimiento del sistema. Compararemos el rendimiento del sistema cuando no hay carga de políticas, y cuando tenemos una política de casi 50.000 líneas, para comprobar si la lectura de esta política afecta o no. Las políticas serán añadidas utilizando Postman ya que su interfaz facilita la tarea además de mostrarlas de manera visualmente sencillo (Figura 35). Figura 36. Ejemplo de añadir Política a Authzforce 4.1.5 Pruebas de tensión También analizaremos cómo afecta al sistema la simultaneidad de peticiones, es decir, una gran cantidad de usuarios o agentes emitiendo peticiones a la vez. Así comprobaremos cuánta carga simultánea es capaz de soportar nuestro sistema, y de este modo comprobaremos si el Proxy Wilma es capaz de soportar todo ese manejo de peticiones, o si es otro componente el que se satura antes. Para esta labor utilizaremos un complemento que añadimos a JMeter, explicado en el Anexo D, con el que se pueden hacer pruebas de carga ascendentes, donde el número de usuarios que envía peticiones al sistema aumenta gradualmente, en este caso hacemos la prueba con todos los módulos descargados, ya que el objetivo es comprobar si Wilma es capaz de manejar altas cantidades de peticiones (o quizá es otro módulo el que satura antes excepto la base de datos de usuarios MySQL, ya que para poder hacer peticiones válidas que sean procesadas por el sistema los usuarios deben estar previamente registrados). 33 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios 4.2 Prueba 1: Petición de token a Keyrock El paso previo a toda petición que un usuario o agente realiza es pedir un token de acceso a Keyrock. Vamos a comprobar cómo afecta al rendimiento la cantidad de usuarios que piden un token a Keyrock en un corto intervalo de tiempo. Para ello vamos a evaluar la velocidad de respuesta del sistema en función de la cantidad de usuarios emitiendo peticiones, comprobando en qué punto comienzan a aparecer errores. El número de usuarios en cada escenario será de 2000, 5000, 8500 y 10000. Con 2K usuarios pidiendo un token: Configuración JMeter: Figura 37. Configuración JMeter 2.000. Peticiones de token a Keyrock Transacciones por segundo: Figura 38. Transacciones JMeter 2000. Peticiones de token a Keyrock 34 Hilos activos: Figura 39. Hilos JMeter 2000. Peticiones de token a Keyrock Tiempos: Figura 40. Tiempos JMeter 2000. Peticiones de token a Keyrock Tabla de resultados: Figura 41. Tabla JMeter 2000. Peticiones de token a Keyrock Como se puede apreciar en los resultados, conforme se van acumulando las peticiones de los usuarios los tiempos de respuesta aumentan notablemente, despachando las 2000 peticiones concurrentes de los 2000 usuarios sin que ocurra ningún error. Con 5k usuarios pidiendo un token: Configuración JMeter: 35 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Figura 42. Configuración JMeter 5000. Peticiones de token a KeyrockJMeter Transacciones por segundo: Figura 43. Transacciones JMeter 5000. Peticiones de token a KeyrockJMeter 42 Vamos a comparar el funcionamiento del sistema cuando un solo usuario está registrado, frente a cuando tenemos 10.000 usuarios registrados. Se va a utilizar una batería de prueba llamada Ultimate Thread Group. Este tipo de prueba de carga nos permite definir una escalera ascendente de usuarios que con el tiempo va incrementando la cantidad de usuarios que emiten peticiones al sistema repetidamente. Así, por ejemplo, podemos emular que al principio hay 5 usuarios emitiendo peticiones constantemente, tras 10 segundos asciende a 20 usuarios, luego cuando alcanzamos un minuto, asciende a 200 usuarios, y así sucesivamente. De este modo comprobamos el comportamiento del sistema en diferentes puntos de carga. Para esta prueba hemos realizado dos acciones, primero los usuarios piden su token a Keyrock, y luego hacen un GET de un sensor concreto al que todos tienen acceso. Un usuario en MySQL: Esquema de carga: Figura 59. Esquema JMeter 1 Usuario. Base de datos MySQL Número de hilos en el tiempo: Figura 60. Hilos JMeter 1 Usuario. Base de datos MySQL 43 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Retardo en las peticiones: Figura 61. Tiempos JMeter 1 Usuario. Base de datos MySQL Tabla de resultados: Figura 62. Tabla JMeter 1 Usuario. Base de datos MySQL Podemos apreciar cómo el retardo del sistema aumenta proporcionalmente con el número de usuarios que envían peticiones. 10.000 usuarios en MySQL: Esquema de carga: Figura 63. Esquema JMeter 10000 Usuarios. Base de datos MySQL Número de hilos en el tiempo: 44 Figura 64. Hilos JMeter 10000 Usuarios. Base de datos MySQL Retardo en las peticiones: Figura 65. Tiempos JMeter 10000 Usuarios. Base de datos MySQL Tabla de resultados: Figura 66. Tabla JMeter 10000 Usuarios. Base de datos MySQL Errores: 45 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Figura 67. Errores JMeter 10000 Usuarios. Base de datos MySQL RESUMEN DE RESULTADOS: Nº Users Av Delay Max Delay Error Throughput Received kb/sec Sent Kb/sec 1 9982 ms 27192 ms 0.00 % 85,4/sec 89.25 21.04 10.000 9743 ms 27533 ms 3.42 % 84.1/sec 86.12 20.63 Tabla 10. Resumen resultados. Base de datos MySQL Como podemos observar, el hecho de que la base de datos MySQL este más cargada de datos o menos, apenas afecta al rendimiento, obteniendo valores muy similares para ambos casos, de un usuario, y de 10.000 usuarios. No obstante, las oscilaciones en el caso de 10.000 usuarios en cuanto a tiempos de respuesta, son mayores, y encontramos un 3.42 % de paquetes erróneos, debido a que el token que utilizan es inválido. Esto se debe a que el token expira, ya que cuando un usuario pide un token en el primer instante de la simulación, seguirá utilizando este mismo token durante el resto de tiempo debido al módulo “Once Only Controller” utilizado. Este módulo se utiliza para que la acción de pedir un token solo se realice una vez al principio por cada usuario, y no una vez por cada petición consecutiva, lo cual no tendría sentido, ya que el token es un “login” que dura un intervalo de tiempo durante el cual el usuario realiza determinadas acciones. En el caso de un solo usuario no sucede, ya que el usuario que accede es siempre el mismo. Como conclusión, la carga de la base de datos MySQL no afecta al rendimiento del sistema, dentro del rango de valores que estamos manejando y de las limitaciones de nuestro entorno virtual. Cabe detallar que en otro entorno más potente podríamos llegar a cargas mucho mayores de la base de datos que seguramente llegarían a afectar al rendimiento del sistema, pero trabajando en el rango de valores de 0 a 10.000 usuarios, obtendremos, a menor escala, cuáles son los componentes del sistema cuya carga afecta en mayor medida, sin necesidad de utilizar un servidor de pruebas con mayor potencia. 46 4.4 Prueba 3: Base de datos MongoDB La base de datos donde se encuentra almacenada la información correspondiente a cada sensor es un punto de interés que conviene ponerlo a prueba debido a que su carga puede afectar al rendimiento en cuestiones de retraso en la respuesta del sistema ante una petición. Se van a realizar pruebas con la base de datos cargada con 10.000 entidades, simulando la existencia de 10.000 camisetas con sensor, y con 50.000 sensores, para comprobar cómo evoluciona el rendimiento del sistema. 10.000 entidades almacenadas: Esquema: Figura 68. Esquema JMeter 10000 Entidades. Base de datos MongoDB Hilos: Figura 69. Hilos JMeter 10000 Entidades. Base de datos MongoDB 47 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Tiempos del sistema: Figura 70. Tiempos JMeter 10000 Entidades. Base de datos MongoDB Tabla de resultados: Figura 71. Tabla JMeter 10000 Entidades. Base de datos MongoDB En este caso el retardo no continúa aumentando, permanece en torno a cierto valor, sin ocurrir errores. 50.000 entidades almacenadas: Esquema: Figura 72. Esquema JMeter 50000 Entidades. Base de datos MongoDB 48 Hilos: Figura 73. Hilos JMeter 50000 Entidades. Base de datos MongoDB Tiempos: Figura 74. Tiempos JMeter 50000 Entidades. Base de datos MongoDB Tabla de resultados: Figura 75. Tabla JMeter 50000 Entidades. Base de datos MongoDB Ahora el tiempo, como antes, permanece en torno a cierto valor sin continuar aumentando, no obstante, son bastante elevados. 49 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios RESUMEN RESULTADOS: Nº Entities Av Delay Max Delay Error Throughput Received kb/sec Sent Kb/sec 10.000. 8253 ms 34665 ms 0.00 % 54.0/sec 55.45 13.68 50.000 21437 ms 84464 ms 0.00 % 19.4/sec 18.02 5.52 Tabla 11. Resumen resultados. Base de datos MongoDB En este caso podemos comprobar cómo la carga de la base de datos MongoDB afecta directamente al rendimiento del sistema. Las peticiones GET lanzadas para obtener la información de un sensor se ralentizan drásticamente cuando existen una gran cantidad de entidades almacenadas. Cuando tenemos 5 veces más entidades almacenadas tenemos 2.6 veces mayor tiempo de retardo, empeorando el caudal de datos de la aplicación y haciendo que su rendimiento disminuya, ocasionando un funcionamiento ciertamente lento, ya que una media de 21437 ms de retardo de media en servir una respuesta a una petición es demasiado tiempo para un sistema IoT que maneja una gran cantidad de operaciones por segundo. 4.5 Prueba 4: Políticas de Authzforce Para comprobar cómo afecta la carga de Authzforce al rendimiento del sistema, se van a utilizar políticas de diferentes longitudes. Así comprobaremos si la existencia de políticas largas, de miles de líneas, afecta al sistema ocasionando un mayor retardo en el proceso de solicitudes, o incluso errores. Vamos a comparar el funcionamiento del sistema, cuando la política en uso de Authzforce es una política básica de 635 líneas, en la que se evalúan diferentes parámetros en función de la acción a realizar: Acción URL Organiza tion Curren t-time DNI Agente Role GET /v2/entities Hospital Central 09:00 a 23:00 10 primeros DNI del fichero CSV Agente 0-9 No POST /v2/entities Hospital Central 09:00 a 23:00 10 segundos DNI del fichero CSV Agente10-19 No PATCH (médicos de mañana) /v2/entities Hospital Central 09:00 a 23:00 No No Medicos_Hosp_ Central_turno_m añana PATCH (médicos de tarde) /v2/entities Hospital Central 15:00 a 15:00 No No Medicos_Hosp_ Central_turno_ta rde 50 Esta política básica que consta de 1 Política con 1 Regla para cada acción (GET, PUT, PATCH y Suscripción) separando turno de mañana del turno de tarde, pero siendo la misma regla, será multiplicada por 10 Políticas de 10 Reglas cada una para cada acción. Obteniendo una política como la de la Tabla 12 pero 100 veces más grande, evaluando hasta 2000 usuarios registrados. Con este grosor de políticas se espera comparar el rendimiento y ver si afecta a la respuesta del sistema o es despreciable. Para realizar estas pruebas se han emitido peticiones de dos formas diferentes, primero de manera linear un solo usuario, y luego con 200 usuarios emitiendo peticiones POST, POST para subscribirse, y PATCH. RESULTADOS DE LAS PRUEBAS: Política Básica: 1-User Figura 76. Tiempos 1 Usuario. Política Básica. Políticas de Authzforce POST de subscripción (mañana) http://172.18.1.[13]:1028/subscriptions Hospital Central 09:00 a 15:00 No No Medicos_Hosp_ Central_turno_m añana POST de subscripción (tarde) http://172.18.1.[13]:1028/subscriptions Hospital Central 15:00 a 23:00 No No Medicos_Hosp_ Central_turno_ta rde Tabla 12. Política base para pruebas. Políticas de Authzforce 51 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios 200-Users Figura 77. Tiempos 200 Usuarios. Política Básica. Políticas de Authzforce Política Compleja: 1-User Figura 78. Tiempos 1 Usuario. Política Compleja. Políticas de Authzforce 58 5.2 Posibles mejoras para el proyecto. Pensando en un caso real, por ejemplo, en el Hospital Universitario Virgen Macarena de Sevilla, si tenemos 100 médicos encargados de las constantes vitales recogidas a 50 pacientes para cada médico, tendremos 5000 pacientes registrados como agentes IoT y 100 médicos registrados que consultarán la información de estos pacientes mediante una aplicación que muestra la información actualizada para las constantes de cada paciente, haciendo un GET cada 60 segundos. Los Agentes IoT actualizarán con un PATCH cada uno su información cada 30 segundos para asegurar que se recoge la información actualizada en los GET de los médicos. En este caso tendremos 3 peticiones por minuto por cada usuario del sistema (paciente + médicos) por lo que llegarán 15300 peticiones por minuto. Suponiendo que el 50% de las peticiones PATCH llegan con 30 segundos entre ellas y que esto es tiempo suficiente para ser procesadas, no supondrán un problema, por lo que realmente confluyen una media de 5000 peticiones. Esto, pese a ser un número mucho menor que 15.300, sigue siendo insoportable para el sistema ya que muchas de estas peticiones, si se lanzan a la vez, serán rechazadas, por lo que habría que proponer una solución para este problema. Por otro lado, si consideramos un despliegue para varios hospitales simultáneamente, probablemente se superen las 50.000 entidades registradas, por lo que habría que optimizar el sistema de alguna forma para que sea capaz de mantener su rendimiento pese a la amplia cantidad de sensores. En el siguiente apartado se proponen soluciones para superar estas limitaciones y poder hacer que el sistema sea escalable manteniendo su rendimiento. 5.2.1 Separación de Peticiones Según podemos apreciar en la Figura 85, una petición aislada al sistema de POST de una entidad tarda entre 1000 y 1200 ms en ser completada. Figura 85. Tiempos petición POST aislada No obstante, como se aprecia en el apartado 4.4 con 10.000 entidades almacenadas, la media por petición es de 8253 ms para una media de 300 usuarios emitiendo peticiones dado que cada 10 segundos se lanzan 100,150,200… usuarios de manera ascendente. Esto se debe a que la carga del sistema es fundamentalmente afectada por la existencia de peticiones que llegan a la vez, ya que, de manera lineal con una mínima separación entre peticiones, el sistema no se satura. Por lo que, separando las peticiones para que se realicen una detrás de otra, programando los agentes IoT con un pequeño retardo cada uno y cuadrando los tiempos, podríamos hacer que el sistema mejorara en cuanto a tiempos de respuesta y errores por peticiones paralelas, pudiendo recoger los datos para los médicos cada 2 minutos por ejemplo tendríamos un amplio intervalo para añadir retardos para las peticiones, sacrificando velocidad en la obtención de la información para la aplicación de los médicos. 59 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios 5.2.2 Duplicación base de datos MongoDB Ahora trataremos de proponer una solución al problema de carga de MongoDB que hace que se retrase la respuesta a las peticiones. Por suerte, las bases de datos MongoDB basadas en el modelo NoSQL, presentan soluciones que las hacen altamente escalables, como por ejemplo la duplicación de la base de datos, técnica mediante la cual se pueden crear copias de una base de datos. Entre estas réplicas la carga se distribuye y hace que mejore el rendimiento, aumentando la capacidad del sistema en cuanto a entidades almacenadas y velocidades de respuesta. Las bases de datos con capacidad de distribución suelen ser caras, por ello conviene buscar soluciones que no supongan un alto coste. Escalando horizontalmente nuestro sistema, es decir, duplicando instancias del mismo, en este caso MongoDB, y distribuyendo la carga, se puede alcanzar la escalabilidad que deseamos para mejorar el sistema. Esta escalabilidad estaría basada en un sistema de nodos comunicados entre ellos ampliando con ello la cantidad de puntos que pueden verse afectados por algún error. MongoDB no solo es NoSQL, tecnología que facilita la creación de réplicas y la cooperación entre estas, sino que además es de código abierto, por lo que simplifica la tarea en cuestión. 5.2.3 Cola de Peticiones En caso de necesitar abarcar una cantidad mayor de peticiones simultáneas por motivo de un aumento en la masa de agentes IoT que envían información, una solución, para que las peticiones no sean rechazadas por sobrecarga del sistema, sería añadir un proxy que actúe como cola suplementaria, que sea capaz de acumular peticiones con un timer, el cual expire en caso de sobrepasar determinado límite de espera, y así no manchar los datos en caso de sobrecarga, pero haciendo que el sistema sea capaz de soportar una mayor cantidad de peticiones paralelas. Este proxy podría ser un servicio de colas con reintentos, en caso de que el sistema se cargue demasiado y las peticiones permanezcan demasiado tiempo en la cola, llegando a expirar, se pediría a los agentes IoT que reenvíen las últimas muestras de nuevo, las cuales se almacenarían y quedarían todos los datos registrados sin pérdidas. En caso de que las pérdidas no sean realmente importantes en determinado caso, con el timer sería suficiente, dando mayor fluidez a la cola y no permitiendo que se llene. 60 ANEXO A: INSTALACIÓN Y CONFIGURACIÓN DE DOCKER Y DOCKER-COMPOSE Siendo Docker la herramienta utilizada para desplegar esta plataforma, se muestran a continuación los pasos para su instalación, configuración y solución de algunos problemas que pueden aparecer: Lo primero es actualizar la máquina: Ahora procedemos a instalar el protocolo seguro https junto con ciertas dependencias: Ahora debemos importar el comando mientras usamos la clave GPG correcta con el comando Curl. Para esto solo debemos escribir el siguiente comando: Ahora procedemos a añadir el repositorio Docker APT a nuestro sistema de repositorios: A continuación instalamos Docker en la versión docker-ce: Es necesaria la instalación de Docker-compose para componer nuestra aplicación completa (cuidado con las comillas y guiones al copiar y pegar): sudo apt-get update sudo apt-get upgrade sudo apt-get install apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" sudo apt-get install docker-ce sudo curl -L https://github.com/docker/compose/releases/download/1.21.2/docker-compose-‘uname -s’ ‘uname -m’ -o /usr/local/bin/docker-compose 61 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Para terminar la instalación de docker-compose otorgamos permisos de ejecución al binario. A continuación comprobamos las versiones de ambos servicios instalados ejecutando: Para lo que obtendremos la última versión disponible en el repositorio, que es la que hemos instalado. Es habitual encontrar problemas de memoria utilizando Docker y más aún en un proyecto de pruebas en el cual cargamos de información las bases de datos, mandamos un gran volumen de peticiones, etc. Hay que tener en cuenta que en Docker por más que borremos el contenedor tras la ejecución, los datos quedan almacenados igualmente en el disco. Por ello cabe tener cuidado con la memoria disponible ya que de lo contrario nos veremos envueltos en un problema. Añado este apartado debido a que mi máquina virtual se saturó debido a las pruebas de carga y al funcionamiento de Docker, quedando inutilizada y perdiendo bastante tiempo en recuperarla. Para ello reinstalaremos Docker, eliminando la carpeta en la que almacena todos los datos de cada ejecución: Otra opción, para liberar memoria sin borrar Docker, sino a través de los comandos ofrecidos por Docker: Primero mostramos los volúmenes existentes: Para borrarlos todos los inactivos, o uno por uno: Lo mismo se puede hacer para listar las imágenes y posteriormente borrarlas: Y para listar y borrar contenedores, lo mismo: sudo chmod +x /usr/local/bin/docker-compose docker-compose –version docker --version sudo apt-get remove docker-ce sudo rm -rf /var/lib/docker sudo apt-get install docker-ce docker volume ls -f dangling=true docker volume rm $(docker volume ls -f dangling=true -q) ó docker volume rm [ Identificador del volumen a borrar] docker images -f dangling=true docker rmi [ Identificador de la imagen a borrar] docker ps -a docker rm [Id del contenedor] 62 ANEXO B: INSTALACIÓN Y CONFIGURACIÓN DE LOS COMPONENTES DE LA PLATAFORMA Para entender el funcionamiento de la plataforma y el estado inicial de esta, y así preparar la carga de los diferentes módulos para las posteriores pruebas, ha sido necesario el estudio de diferentes ficheros de configuración del sistema, que se exponen a continuación. Figura 86. Distribución directorios y ficheros del sistema La carpeta authzforce contiene los ficheros necesarios para el funcionamiento de dicho servicio. Dentro se encuentra la carpeta domains, que contiene los diferentes dominios de políticas. En este caso solo se ha utilizado uno, ya que a Wilma se le debe indicar cuál va a ser utilizado, por lo que en la base de datos existirá este identificador de dominio que se indica en la imagen: ffsR-txyEeqvSwJCrBIBDA. Dentro del dominio en cuestión, se encuentra el fichero pdp.xml que indica el número de PolicySets y VariableDefinition que pueden existir en una política, luego en el fichero properties.xml se indican el máximo de políticas por dominio y máximo de versiones por política. Para las pruebas del escenario y las de carga posteriores se han utilizado diversas versiones de política para ir cambiándola de manera sencilla. Cuando se añade una versión de número mayor que la anterior, es esta última la que se tiene en cuenta. En el directorio fiware-pop-proxy encontramos los archivos de configuración del proxy, como config.js y server.js. También encontramos el controlador, llamado root.js que define el funcionamiento de Authzforce. Este fichero ha sido utilizado para evaluar la posibilidad de introducir nuevos parámetros a evaluar en las políticas. El fichero azf.js contiene las funciones a las que Wilma llamará para interactuar con Authzforce. En mysql-data encontramos el fichero de base de datos backup.sql que contiene la situación inicial que tendrá la base de datos, tanto las tablas como valores iniciales. En nuestro caso, hemos cargado la base de datos partiendo de esta situación inicial, utilizando JMeter para conectarnos a las bases de datos y llenarlas con peticiones, utilizando ficheros CSV para rellenar las peticiones con ciertos datos (nombres, DNI, email…) generados a partir de scripts en Python. 63 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios Como parte del estudio del despliegue de la plataforma, cabe destacar el papel del fichero services.sh y docker-compose.yml. El fichero services.sh es el que se utiliza para iniciar los diferentes servicios que se despliegan en contenedores de Docker. Este script puede ser lanzado en diferentes modos, en “create” para hacer pull de las imágenes, en “start” para iniciar los containers, o en “stop” siendo este último modo el encargado de parar los containers. Figura 87. Opciones script services.sh En el fichero Docker-compose.yml se especifica el despliegue de cada contenedor: • Orion Context Broker: - image: se indica la imagen Docker a descargar junto con la versión requerida. - hostname: define el nombre dentro de la red creada. - depends_on: indica las dependencias de arranque de servicios. Antes de poner en marcha este contenedor, se iniciarán las dependencias. Para cerrar los contenedores, se cierran antes los que dependen de otros. - networks: establece la subred donde se encontrará el contenedor. - expose: establece puertos que solo estarán disponibles dentro de los servicios definidos, no en la máquina donde se ejecuta. - ports: puertos que se van a abrir de cara al exterior, para que sean accesibles desde fuera - healthcheck: establece un comando para determinar si el contenedor está correctamente desplegado Figura 88. Docker-compose. Orion Context Broker 64 Keyrock - image: se utiliza la versión del contenedor 7.8.1 - depends_on: depende de MySQL, para almacenar información sobre credenciales, aplicaciones registradas, usuarios registrados, etc. - ports: Keyrock está disponible a través del puerto 3005, tanto para la conexión con el PEP Proxy para solicitar tokens de acceso. - IDM_DB_USER: especifica el usuario con acceso a la base de datos. - IDM_ADMIN_USER: nombre del administrador de Keyrock. - IDM_ADMIN_EMAIL: email con el que acceder a la configuración de Keyrock - IDM_ADMIN_PASS: contraseña definida para acceder a la configuración de Keyrock junto con el email. - IDM_PDP_LEVEL: especifica qué tipo de nivel va a ser el PDP, con “advanced” indicamos que Authzforce va a actuar como PDP, y no Keyrock. - IDM_AUTHZFORCE_ENABLED: Indicamos si la conexión Keyrock y Authzforce está o no habilitada. Figura 89. Docker-compose. Keyrock 65 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios • Authzforce: - Volumes: En el primer argumento indicamos la ruta donde queremos que se almacenen las políticas, el segundo argumento es la ruta donde se monta el archivo o directorio en el contenedor. - MongoDB y MySQL: - volumes (en MySQL): se especifica el fichero que va a exponer el estado inicial de la base de datos. Se explicará con detalle dicho estado inicial en el siguiente apartado - ports: Importante en este caso consultar este fichero para saber a dónde dirigir las peticiones para cargar las bases de datos. - Environment: Indicamos password y host para así permitir el acceso directo de Keyrock. Figura 90. Docker-compose. Authzforce Figura 91. Docker-compose. MongoDB y MySQL 66 • PEP Proxy Wilma: Este componente no será desplegado con Docker, lo instalaremos por código fuente. Para ello lo primero que se debe hacer es instalar nodejs y npm: En caso de obtener el error: ‘Cannot find module xmlhttprequest’: Al igual que anteriormente, comprobamos que se ha instalado mirando la versión: Para iniciar el servidor, ejecutamos: curl -sL https:// deb.nodesource.com/setup_13.x | sudo -E bash – sudo apt-get install nodejs sudo apt install npm npm install xmlhttprequest node -v npm -v sudo node server 67 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios ANEXO C: INSTALACIÓN DE POSTMAN Tanto para las primeras pruebas realizadas en la plataforma, comprobando las respuestas de las llamadas a las funciones de la API de cada servicio y corroborando su funcionamiento, como para el cambio entre políticas para las pruebas de carga posteriores, se ha utilizado Postman. Para instalar este servicio es conveniente tener previamente instalado snapd: Y a continuación instalaremos postman con dicho servicio: Figura 92. Interfaz de Postman 1. Aquí se selecciona la acción a llevar a cabo. 2. Indicamos la url a la que mandamos la petición y pulsamos en send. 3. El token viaja en la petición, en el apartado Auth. 4. La respuesta se muestra en este recuadro. 5. En este apartado se muestran las peticiones previamente guardadas. sudo apt-get install snapd sudo snap install postman 74 REFERENCIAS [1] «Página web oficial de FIWARE,» [En línea]. Available: https://www.fiware.org. [2] «Orion Context Broker,» [En línea]. Available: https://fiware-training.readthedocs.io/es_MX/latest/ecosistemaFIWARE/ocb/. [3] «Identity Manager - Keyrock,» [En línea]. Available: https://fiware-idm.readthedocs.io/en/latest/. [4] «PEP Proxy - Wilma,» [En línea]. Available: https://fiware-pep-proxy.readthedocs.io/en/latest/. [5] «Authzforce,» [En línea]. Available: https://authzforce-ce-fiware.readthedocs.io/en/latest/. [6] «Ubuntu 20.04.0 LTS,» [En línea]. Available: https://releases.ubuntu.com/20.04/. [7] «VMware Workstation Player 16,» [En línea]. Available: https://www.vmware.com/es/products/workstation-player/workstation-player-evaluation.html. [8] «Postman,» [En línea]. Available: https://www.postman.com/. [9] «Docker,» [En línea]. Available: https://www.docker.com/. [10] «Docker-Compose,» [En línea]. Available: https://docs.docker.com/compose/. [11] «MongoDB,» [En línea]. Available: https://www.mongodb.com/es. [12] «MySQL,» [En línea]. Available: https://www.mysql.com. [13] «Wireshark,» [En línea]. Available: https://www.wireshark.org/. [14] «JMeter,» [En línea]. Available: https://jmeter.apache.org/. [15] «Plugins JMeter,» [En línea]. Available: https://jmeter-plugins.org/wiki/Start/. 75 Estudio de rendimiento de una plataforma IoT en escenarios sanitarios 76