Trabajo Fin de Grado Sistema de orquestación de ejecución de modelos de predicción oceanográficos Orchestration system for execution of ...
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Trabajo Fin de Grado
Sistema de orquestación de ejecución de
modelos de predicción oceanográficos
Orchestration system for execution of
oceanographic prediction models
Autor/es
Alberto Calvo Rubió
Director/es
Luis Ripollés Hernández
Ponente/s
Francisco Javier López Pellicer
Escuela de Ingeniería y Arquitectura
2021
Repositorio de la Universidad de Zaragoza – Zaguan
http://zaguan.unizar.es
Resumen Nologin es una consultoría tecnológica especializada en IT. En uno de sus departa- mentos, NOW Systems, se trabaja para desarrollar soluciones y servicios para una gestión más sostenible y rentable de las actividades desarrolladas en el medio marino. Una de las tareas que se lleva a cabo es la ejecución de modelos de predicción oceanográficos. Estos se ejecutan periódicamente para la obtención de datos como vientos y oleajes, que son utilizados por organismos como Puertos del Estado en puertos y costas de España. El principal problema se encuentra en las ejecuciones de estos modelos. Cada uno de estos procesos se diseña individualmente formando operativas distintas para cada combinación de tipo de modelo de predicción y entorno de ejecución. Actualmente, se ejecutan en distintos entornos para computación de alto rendimiento (HPC). La existencia de una operativa distinta por cada combinación de modelo y entorno de ejecución requiere de un gran esfuerzo. Además, resulta complejo tener una visión global de todas las operativas que se están gestionando y su estado. Esto supone un problema tanto económicamente como en complejidad. La solución desarrollada en este TFG para este problema consiste en un prototipo de sistema escalable y modular que permite orquestar y monitorizar operativas actuales e incorporar otras nuevas fácilmente. El prototipo desarrollado elimina la repetición del diseño e implementación de procesos comunes en todas ellas y facilita el conocimiento global de las operativas existentes. Expone una API RESTful, que permite la interacción con el sistema para planificar y ejecutar operativas. Este sis- tema es monitorizado con métricas y logs que son mostrados en paneles gráficos. Su diseño es modular a través de componentes que manejan la lógica de cada mo- delo pero siguiendo una interfaz común. Estos se incorporan mediante un bróker de mensajes que permite desacoplar su interacción de forma asíncrona con el uso de colas de tareas. Además, el sistema es desplegado en un entorno de orquestación de contenedores, Kubernetes, permitiendo escalar horizontalmente y tener una mayor resistencia a fallos. Esta solución ha sido validada por Nologin a nivel de componentes y a nivel de sistema en un entorno relevante. Este proyecto deja como continuación la finalización de los sistemas de autenticación, autorización, alertas, asignación de prioridades, el soporte al resto de entornos de computación y la validación en un entorno de producción.
Dedicatoria
A mi padre y mi abuela, que me han apoyado siempre en todo lo que hago y que
siempre me han llevado por el camino del esfuerzo y la dedicación.
A mi madre, que nunca la he olvidado y cada momento de dificultad recuerdo sus
palabras que me ayudan a seguir adelante para conseguir todo lo que me proponga.
A Javier, ya que sin él este trabajo no sería lo mismo y por todo lo que me ha
enseñado tanto en la carrera como en este TFG.
A Luis y José María, por su ayuda y acogida dentro de Nologin.
A mi hermano y amigos, que me han ayudado con tantas preguntas y me han
aguantado en momentos complicados.
A Elaia, que ha sido testigo de cada uno de los momentos de este trabajo y me ha
apoyado siempre a seguir adelante.
ii
Índice general
Índice de figuras v
Índice de cuadros vi
Índice de código vii
Glosario viii
1 Introducción 1
1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Obstáculos y riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Contenido de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Análisis y diseño del sistema 6
2.1 Análisis del problema a resolver . . . . . . . . . . . . . . . . . . . . . 6
2.2 Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Diseño de alto nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Implementación y pruebas 11
3.1 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Despliegue en desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Pruebas en desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Despliegue en pre-producción y validación 15
5 Organización y gestión 17
6 Impacto 19
6.1 Ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2 Económico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3 Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7 Conclusiones 22
7.1 Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2 Trabajo a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.3 Valoración personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Bibliografía 24
A Requisitos 26
B Brókers de mensajes: análisis de alternativas 28
B.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.2 Apache Kafka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.2.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
iii
ÍNDICE GENERAL
B.2.2 Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
B.2.3 Ejemplo práctico . . . . . . . . . . . . . . . . . . . . . . . . . 32
B.3 Apache Pulsar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
B.3.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
B.4 RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
B.4.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
B.4.2 Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.4.3 Ejemplo práctico . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.4.4 Ejemplo práctico . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.5 Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.5.1 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.5.2 Facilidad de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.5.3 Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
C Diseño detallado del sistema 44
C.1 Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.2 Diseño de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.2.1 Broker de mensajes . . . . . . . . . . . . . . . . . . . . . . . . 45
C.2.2 API RESTful . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.2.3 Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.2.4 Database Worker . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.2.5 Cron worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C.2.6 Operation worker . . . . . . . . . . . . . . . . . . . . . . . . . 47
C.2.7 Monitorización . . . . . . . . . . . . . . . . . . . . . . . . . . 48
D Implementación detallada del sistema 49
D.1 Broker de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
D.2 API RESTful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
D.3 Base de datos y modelo de datos . . . . . . . . . . . . . . . . . . . . 50
D.4 Database Worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.5 Cron Worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.6 Operation Worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.7 Monitorización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.7.1 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.7.2 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.7.3 Visualización . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
E Manuales 56
E.1 Desarrollo local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
E.2 Pruebas unitarias y de integración . . . . . . . . . . . . . . . . . . . . 57
E.3 Pruebas extremo-a-extremo y validación . . . . . . . . . . . . . . . . 57
F API RESTful 59
F.1 Especificaciones de operativas . . . . . . . . . . . . . . . . . . . . . . 59
F.2 Ejecuciones de operativas . . . . . . . . . . . . . . . . . . . . . . . . . 63
F.3 Programaciones de operativas . . . . . . . . . . . . . . . . . . . . . . 66
F.4 Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
iv
Índice de figuras
2.1 Diagrama BPMN de creación de operativa . . . . . . . . . . . . . . . 8
2.2 Diagrama BPMN de ejecución de operativa . . . . . . . . . . . . . . . 8
2.3 Diagrama de arquitectura de alto nivel . . . . . . . . . . . . . . . . . 9
4.1 Despliegue en Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1 Hoja de cálculo de seguimiento y organización personal . . . . . . . . 18
5.2 Dedicación temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.1 Apache Kafka. Topics y particiones . . . . . . . . . . . . . . . . . . . 29
B.2 Ejemplo de Kafka Cluster y Consumer Groups . . . . . . . . . . . . . 30
B.3 Eliminación de ZooKeeper . . . . . . . . . . . . . . . . . . . . . . . . 30
B.4 Arquitectura Apache Pulsar . . . . . . . . . . . . . . . . . . . . . . . 34
B.5 Arquitectura RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.6 Interfaz gráfica de monitorización built-in . . . . . . . . . . . . . . . . 39
B.7 Comparativa de rendimiento . . . . . . . . . . . . . . . . . . . . . . . 40
B.8 Comparativa de latencia . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.9 Comparativa de facilidad de uso . . . . . . . . . . . . . . . . . . . . . 42
B.10 Comparativa de casos de uso . . . . . . . . . . . . . . . . . . . . . . . 42
C.1 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 44
C.2 Diagrama de colas del bróker . . . . . . . . . . . . . . . . . . . . . . 45
C.3 Diagrama de funcionamiento del Database Worker . . . . . . . . . . . 47
D.1 Documentación automática de la API con Swagger . . . . . . . . . . 50
D.2 Documentación de operación GET sobre ejecuciones de operativas . . 50
D.3 Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
D.4 Dashboard de RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . 54
D.5 Dashboard de monitorización de una operativa de OilSpill . . . . . . 55
v
Índice de cuadros
6.1 Impacto ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2 Impacto económico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3 Impacto social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.1 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.2 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 27
vi
Índice de código
B.1 Despliegue bare metal Apache Kafka . . . . . . . . . . . . . . . . . . 31
B.2 docker-compose.yml Apache Kafka . . . . . . . . . . . . . . . . . . . 32
B.3 Apache Kafka consumer.py . . . . . . . . . . . . . . . . . . . . . . . . 32
B.4 Apache Kafka producer.py . . . . . . . . . . . . . . . . . . . . . . . . 32
B.5 Apache Pulsar consumer.py . . . . . . . . . . . . . . . . . . . . . . . 35
B.6 Apache Pulsar producer.py . . . . . . . . . . . . . . . . . . . . . . . . 35
B.7 RabbitMQ consumer.py . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.8 Despliegue RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.9 RabbitMQ consumer.py . . . . . . . . . . . . . . . . . . . . . . . . . 39
E.1 Actualizar despliegue Kubernetes . . . . . . . . . . . . . . . . . . . . 57
E.2 port-forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
vii
Glosario
API Application Programming Interface. 3, 7, 9–12, 15, 22, 27, 31, 33, 34, 36–38,
46, 47, 49, 50, 52
BPMN Business Process Model and Notation. 7, 8
CESGA Centro de Supercomputación de Galicia. 1, 47
HPC High performance computing. 2, 6, 7, 9, 15, 20, 27, 45, 47, 48
OilSpill Modelo de predicción de la trayectoria de vertidos en el agua basado en el
modelo MEDSLIK II. 1, 2, 12, 14, 15, 52, 55, 57
ORM Object–Relational Mapper. 11, 12, 50
RPC Remote Procedure Call. 7, 45
TFG Trabajo Final de Grado. 1, 2, 4, 5, 17–23, 28, 48, 49, 53
TRL Technology Readiness Levels. 2, 13, 22
viii
1 | Introducción
La evolución de la tecnología ha permitido el desarrollo de herramientas que per-
miten conocer y entender mejor la naturaleza. Algunas de estas herramientas son
los modelos de predicción, que en un contexto oceanográfico permiten conocer datos
muy útiles como la velocidad del viento o la trayectoria de un vertido de aceite en
el mar en un periodo de tiempo concreto. Estos modelos necesitan ser ejecutados
y gestionados por equipos profesionales en una infraestructura preparada para ello.
Con el desarrollo de este TFG se busca mejorar la sostenibilidad y rentabilidad de
estas tareas.
1.1. Contexto
Nologin es una consultoría tecnológica especializada en IT, datacenters y desarrollos
a medida. Dentro de esta empresa, se encuentra el departamento NOW Systems [1],
el cual tiene como objetivo ser un proveedor de soluciones, conocimiento y servicios
para una gestión más sostenible y rentable de las actividades desarrolladas en el
medio marino. Una de las tareas que se lleva a cabo es la ejecución de modelos
de predicción oceanográficos. Algunos de estos requieren gran capacidad de
computación para que su ejecución finalice dentro de los requerimientos establecidos
por la naturaleza del problema que resuelven. Un ejemplo, consiste en el modelo
de OilSpill [2], el cuál se debe ejecutar en ocasiones en los que se ha producido un
vertido de aceites o petróleo (como el accidente del Prestige [3] en el año 2002).
De esta forma, se predice la dirección y posición del vertido en el mar durante el
tiempo, facilitando la extracción del mismo y la evacuación de playas. Por tanto, se
requiere de una infraestructura que permita planificar en el tiempo o ejecutar en un
momento puntual estos modelos a través de distintos sistemas de una forma eficaz
y automatizada.
Actualmente, la orquestación de los modelos se realiza de forma individual e indepen-
diente con sistemas distintos para cada uno de ellos. Algunas de las infraestructuras
en las que se ejecutan están basadas en herramientas de gestión de trabajos de
computación (workload managers) como Slurm [4] (concretamente en el centro de
Súper Computación CESGA en Galicia) y entornos basados en Kubernetes. Esto su-
pone un problema en cuanto a complejidad de administración, conocimiento
de alto nivel de los sistemas y un alto coste de mantenimiento debido que
para cada modelo es necesario definir la operativa, configurar el despliegue en una
1CAPÍTULO 1. INTRODUCCIÓN
infraestructura y disponer de un equipo específico encargado. Por tanto, cada vez
que se quiere añadir un nuevo sistema o modelo para ejecutar, se realiza un esfuerzo
que se repite en cada uno de ellos, en general, la orquestación: definición, ejecución,
control y monitorización.
1.2. Objetivos y alcance
El objetivo de este TFG es desarrollar un sistema que sirva como base para un futu-
ro producto que sea capaz de resolver el problema completamente. En definitiva, se
busca el desarrollo de un prototipo de sistema que permita centralizar la orquesta-
ción de los distintos modelos que actualmente funcionan de forma independiente y la
adición de otros nuevos. Para ello, es necesario crear un sistema flexible en cuanto a
su forma de comunicación e integración con otros componentes, y se debe desacoplar
lo máximo posible respecto a un lenguaje de programación, tecnología o sistema de
comunicación concretos.
El alcance del TFG no solo se limita al desarrollo del sistema, sino que también
existe un fuerte componente de despliegue en entornos de contenedores, en concreto,
Docker y Kubernetes. Por tanto, se cubre tanto el área de desarrollo como el de
despliegue e infraestructura. Se tiene como objetivo que el sistema alcance un nivel
de madurez tecnológica o TRL [5] entre TRL-5 (validación de tecnología en un
entorno relevante) y TRL-7 (demostración de prototipo en un entorno operativo).
En cuanto a una interfaz gráfica, se busca la creación de los paneles de visualización
de métricas y logs, pero se descarta una interfaz gráfica que permita crear y ejecutar
operativas, añadiéndose como trabajo a futuro.
Dada la cantidad de funcionalidades que podría tener el sistema, este TFG se cen-
tra en los apartados de definición, planificación, exposición de recursos,
comunicación interna, monitorización de componentes y despliegue de los
mismos, dejando de lado la ejecución de todos los modelos disponibles actualmente.
Nologin toma esta decisión, ya que la complejidad de las actuales operativas y sus
entornos de computación supondrían un trabajo de migración que podría conside-
rarse como otro TFG por su duración y carga de trabajo. Además, para comprobar
el funcionamiento del ciclo completo del sistema se debe realizar uno de los
componentes externos que soporte un entorno de computación concreto,
en este caso Kubernetes, pudiendo ejecutar la operativa de OilSpill con unos datos
predefinidos en este entorno.
1.3. Requisitos
El sistema debe permitir a un administrador registrar plantillas de modelos para ser
ejecutados en sistemas HPC. A través de estas plantillas, los usuarios o clientes del
sistema podrán ejecutar operativas puntuales o planificarlas en el tiempo, indicando
parámetros como el nivel de prioridad. Además, las operativas podrán ser canceladas
2CAPÍTULO 1. INTRODUCCIÓN
por el usuario. Por último, el sistema deberá monitorizar su ejecución, mostrando
métricas y logs a través de una interfaz gráfica. A nivel de implementación, el sistema
debe usar las tecnologías FastAPI (API web) y RabbitMQ (broker de mensajes).
En total se han identificado 19 requisitos funcionales y 5 no funcionales que se han
clasificado a nivel de prioridad aplicando la técnica MoSCoW [6], explicada más
adelante. Para más detalles, las tablas de requisitos se encuentran en el apéndice A.
1.4. Obstáculos y riesgos
Se trata de un proyecto ambicioso y complejo que busca unificar muchas de las
operativas de Nologin. En él se encuentran distintos obstáculos, los cuales se sabía
que iban a ser un problema desde el principio:
Proyecto exploratorio para Nologin. Al ser un proyecto exploratorio, des-
de el principio se asume que los requisitos pueden cambiar conforme se conoce
mejor el dominio del problema.
Kubernetes y contenedores con la correspondiente complejidad que conlle-
van [7]. Establecidas como tecnologías en los requisitos (para el despliegue del
sistema desarrollado, independientemente si los modelos se ejecutan también
en Kubernetes o en otros entornos distintos no basados en contenedores). Al-
gunas de sus ventajas son la facilidad de despliegue en distintas máquinas y la
capacidad de empaquetar una aplicación y sus dependencias en un contenedor.
Sin embargo, también aumenta la complejidad si no se conoce perfectamente
algunos detalles de los contenedores y su orquestador.
Sistema distribuido en el que los distintos componentes deben intercambiar
mensajes. Esto dificulta el desarrollo y pruebas debido a los problemas que
pueden surgir como la pérdida de mensajes, errores en la conexión, latencia,
mensajes duplicados, caída de nodos y particiones de red. Como dice Leslie
Lamport, “Un sistema distribuido es aquel en el que el fallo de una máquina
que ni siquiera sabías que existía puede inutilizar tu propia máquina" [8]. Para
solucionar esto, cobran gran importancia las pruebas de integración, extremo
a extremo y validación.
Además, desde el principio del proyecto, también se conocían problemas que se
podían dar o no (riesgos):
Clúster privado: cuando se comenzó el TFG, Nologin planeaba tener un
clúster privado de Kubernetes. Al ver retrasos en su implementación y como
mitigación de este riesgo se ha realizado un despliegue local, utilizando una
tecnología que permite el despliegue de un entorno de Kubernetes para de-
sarrollo local (Minikube1 ). El riesgo derivado es que al ser un equipo local
1
https://minikube.sigs.k8s.io
3CAPÍTULO 1. INTRODUCCIÓN
de desarrollo, los resultados de las pruebas de sobrecarga no se pueden ex-
trapolar por ser limitante y se tienen que realizar a futuro en un equipo de
pre-producción.
Complejidad de la solución: una vez desarrollada la solución y puesta
en marcha en producción, puede darse que conforme se añadan modelos al
sistema, aumente demasiado la complejidad y no sea viable.
1.5. Metodología
En cuanto a la organización y gestión del proyecto, se han utilizado distintas tecno-
logías y metodologías:
Scrum [9]: metodología ágil con iteraciones de 1-2 semanas dependiendo de
los requisitos a desarrollar, reuniones con el director al final de cada una pa-
ra revisión y planificación. Se ha intentado ser fiel a esta metodología pero
finalmente se ha aproximado más a un desarrollo iterativo.
MoSCoW [6]: desde un comienzo se plantean los requisitos que todo el pro-
yecto para Nologin debería tener como producto final, pero sin tener el objetivo
de que se cubra completamente en el trascurso del TFG. Para diferenciar los
requisitos y clasificarlos según el nivel de importancia para el cumplimiento de
objetivos del TFG se ha utilizado esta técnica, en la que se dividen en “Debe
tener (Must have)”, “Debería tener (Should have)”, “Podría tener (Could have)”
y “No tendrá esta vez (Won’t have)”.
Seguimiento: se ha utilizado una herramienta que permita gestionar y visua-
lizar las tareas del TFG. Se ha elegido Jira2 debido a que ha sido utilizada en
otros proyectos dentro de Nologin. Se trata de una herramienta de Atlassian
que permite registrar una estimación de cada tarea, su progreso y finalización
en proyectos de forma ágil.
Supervisión: se han llevado a cabo reuniones periódicas con el director, es-
tablecidas por la metodología Scrum, y reuniones con el ponente para indica-
ciones de carácter académico.
Documentación: durante el transcurso del TFG se ha ido documentando la
información del sistema de cara a Nologin y como ayuda al desarrollo de la
memoria. La herramienta utilizada ha sido Confluence3 , también desarrollada
por Atlassian, como wiki de la empresa. La elaboración de la memoria se ha
realizado con LATEX.
2
https://www.atlassian.com/es/software/jira
3
https://www.atlassian.com/es/software/confluencejira
4CAPÍTULO 1. INTRODUCCIÓN
1.6. Contenido de la memoria
A continuación, en el Capítulo 2 se va a explicar el análisis y diseño del sistema
con las decisiones más importantes sin tener en cuenta la implementación específica,
aunque hay aspectos que pueden ser influenciados por alguno de los requisitos no
funcionales que establecen determinadas tecnologías. Posteriormente, en los Capí-
tulos 3 y 4 se indicarán estos detalles de implementación, las pruebas realizadas
y el despliegue del sistema. Se cubren los aspectos más importantes, junto con las
pruebas realizadas para validar el sistema y el despliegue del mismo en los distintos
entornos que se han utilizado, indicando sus ventajas e inconvenientes. Finalmente,
en los Capítulos 5 y 6 se tratan temas de gestión como la planificación temporal,
computo de horas y el impacto del proyecto tanto en sostenibilidad ambiental y eco-
nómico como de compromiso social entre otros temas. Para concluir, en el Capítulo
7 se lleva a cabo unas conclusiones con las valoraciones del TFG, su completitud y
trabajo a futuro.
Como anexos a la memoria se incluyen: los requisitos del sistema (Anexo A), un
estudio inicial acerca de los sistemas de mensajes que elegir para el proyecto (Anexo
B), diseño detallado del sistema (Anexo C), implementación detallada del sistema
(Anexo D), manuales sobre el despliegue y ejecución de pruebas (Anexo E) y des-
cripción detalla de la API RESTful (Anexo F).
52 | Análisis y diseño del sistema
De forma previa a la implementación es necesario realizar un análisis del problema
que se quiere solucionar, identificando las necesidades de la solución y los diferentes
casos de uso. Una vez realizado este estudio se lleva a cabo el diseño del sistema
utilizando distintos patrones propuestos.
2.1. Análisis del problema a resolver
El problema consiste en la orquestación de procesos distribuidos. Se puede
destacar la naturaleza distribuida y asíncrona de estas ejecuciones, requiriendo
un sistema que permita su correcta comunicación, coordinación y ejecución. Además,
el sistema debe ser resiliente, capaz de permitir fallos entre las operativas, tanto
por caídas, cortes de red o errores propios de las ejecuciones. Por tanto, debe ser
capaz de reiniciar la ejecución o capturar de forma adecuada estos errores y obtener
su información mediante los sistemas de monitorización, permitiendo una respuesta
ante estos fallos. Otro problema consiste en la heterogeneidad de las tecnologías
HPC, pudiéndose ejecutar las operativas en distintos entornos. Por todos estos
requisitos, se han valorado distintos patrones que permiten la creación de este tipo
de sistema.
El primero es el uso de un sistema de mensajes (bróker). Se trata de una de
las decisiones con más peso dentro del sistema. Esta fundamentada en el libro En-
terprise Integration Patterns [10]. Principalmente, se busca la comunicación entre
componentes a través de mensajes de forma asíncrona (Messaging). Los patrones de
integración descartados han sido “Transferencia de ficheros (File transfer )", “Base
de datos compartida (Shared Database)", e “ Invocación de Procedimientos Remotos
(Remote Procedure Invocation), ya que siguen una aproximación más acoplada de co-
municación en comparación con el envío de mensajes. Los mensajes utilizados siguen
el patrón Command Message. Estos se envían para notificar de forma asíncrona
a otros componentes que deben ejecutar una tarea determinada. Concretamente,
en este sistema: ejecutar, cancelar la ejecución, actualizar el estado y programar la
ejecución de operativas. El uso de un sistema de mensajes permite coordinar los
distintos componentes sin establecer un lenguaje de programación concreto. Nor-
malmente, disponen de numerosas bibliotecas que permiten la interacción con ellos
en casi todos los lenguajes de programación, por lo que permite ser más flexible en
cuanto a la implementación de los componentes que se comunican con el bróker.
6CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
Dada la heterogeneidad de las tecnologías HPC a las que se enfrenta Nologin, el
patrón de solución más adecuado es la aplicación del patrón adaptador. Se expone
una interfaz común pero se debe implementar un trabajador especializado para cada
una de las operativas. Este mantiene la lógica específica de esa operativa, mientras
que el resto de componentes comunes sí que son compartidos.
Otro de los elementos más relevantes en el diseño es la exposición de una interfaz
externa a través de una API, intentando seguir el estilo arquitectural REST [11] en
la medida de lo posible. Actualmente, es uno de los estilos arquitecturales más uti-
lizados dado que aprovecha al máximo las ventajas de la Web y que no depende de
soluciones comerciales. Este tipo de API permite definir recursos del sistema como
son las especificaciones de operativas, diferenciándolas de las ejecuciones de opera-
tivas, y operativas planificadas. Los endpoint hacia los usuarios deben seguir este
estilo, ya que permite un intercambio de representaciones a través de paso por valor
sin interactuar directamente con los recursos, un uso de formatos estandarizados
y una representación auto-descriptiva. Aporta una interfaz universal, simple y sin
estado, a través de los verbos HTTP. Atendiendo al criterio de Leonard Richardson
de madurez de interfaces REST [12], que va desde RPC o L0 a REST o L3, el nivel
buscado es en el que se usan verbos HTTP de forma adecuada, se realiza negociación
de contenidos y se devuelven códigos de error de HTTP (nivel de madurez L2), con
la inclusión de algún elemento como el descubrimiento de contenido que es de nivel
L3.
Finalmente, el último patrón aplicado se trata del maestro-trabajador (master-
worker ), dividiendo la carga de trabajo entre distintos trabajadores. Este patrón se
beneficia del bróker de mensajes. A través de este se pueden comunicar unos con
otros sin tener que conocer su identidad, utilizando un sistema basado en colas de
tareas, en las que se encolan ejecuciones de operativas y otros trabajos. De esta
forma, permite escalar el sistema horizontalmente añadiendo más trabajadores.
2.2. Casos de uso
En la fase de diseño es imprescindible tener en cuenta los distintos casos de uso
que puede tener un sistema para identificar y entender mejor sus requisitos. Los
casos de uso de este sistema se pueden categorizar según si están relacionados con
las plantillas, las ejecuciones, las programaciones o la monitorización de operativas.
Dentro del modelo de negocio de la empresa, se pueden diferenciar dos actores en los
casos de uso: cliente (usuario con los permisos restringidos) y operador (empleado de
Nologin con permisos de administrador). En el Anexo C se encuentran más detalles
acerca de los casos de uso.
Otro aspecto determinante para entender el funcionamiento del sistema son los pro-
cesos de negocio. A continuación se describen dos de los más importantes con ayuda
de diagramas BPMN: dar de alta una operativa (Figura 2.1) y ejecución de una
operativa (Figura 2.2).
En el primero, un cliente solicita a la empresa el deseo de poder ejecutar modelos
7CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
Figura 2.1: Diagrama BPMN de creación de operativa
Figura 2.2: Diagrama BPMN de ejecución de operativa
8CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
Figura 2.3: Diagrama de arquitectura de alto nivel
en los sistemas de Nologin. Un operador o varios son los encargados de configurar el
entorno de computación requerido (HPC). Una vez el modelo se encuentra configu-
rado para ser ejecutado, se da de alta en el sistema Model-Executor y es accesible a
través de la API RESTful.
El segundo caso de uso destacado comienza donde termina el anterior, una vez el
modelo se encuentra disponible para ser ejecutado, el cliente desea ejecutar una ope-
rativa en un momento puntual. Este interacciona con la API RESTful para ordenar
la ejecución. El sistema Model-Executor comprueba que la petición es correcta, lan-
za la ejecución y devuelve al cliente la información necesaria para poder consultar
la ejecución de la operativa mientras se lleva a cabo. Una vez finalizada se podrá
observar los datos de salida y el estado de la operativa actualizados.
2.3. Diseño de alto nivel
El sistema tiene la arquitectura mostrada en la Figura 2.3 donde se aplican los
patrones analizados en la Sección 2.1. Los detalles de diseño de cada uno de los
componentes se encuentran en el Anexo C.2.
El sistema diseñado esta dividido en distintos componentes con una responsabi-
lidad única para que estos puedan escalar o ser sustituidos por otra imple-
mentación más fácilmente. El sistema se divide en dos subsistemas, uno encargado
de la lógica de ejecución de modelos y otro de la monitorización.
El sistema de ejecución de modelos esta formado por: Sistema de mensajes, API
9CAPÍTULO 2. ANÁLISIS Y DISEÑO DEL SISTEMA
RESTful, Base de datos, Operation Worker, Cron Worker y Database Worker. El
sistema de mensajes permite la comunicación entre el resto de componentes de forma
desacoplada y escalable, sin tener que conocer directamente las direcciones del resto.
Se utilizan colas de trabajo aplicando el patrón maestro-trabajador o enviando men-
sajes a modo de notificación. La API RESTful sirve para exponer las funcionalidades
al exterior a través de una interfaz, comunicándose con el resto de componentes de
forma interna. Los encargados de ejecutar las operativas en los entornos de compu-
tación (HPC) son los Operation Workers. Estos son capaces de ejecutar un modelo
determinado en un entorno de computación concreto. De esta forma, se pueden di-
señar distintos Operation Worker especializados y acoplarlos al sistema a través del
bróker de mensajes. La base de datos almacena la información acerca de los usua-
rios y las operativas. El resto de componentes tienen una funcionalidad que se ha
separado de la API RESTful de forma que exista un componente que mantenga
esa parte de la lógica separada. Por una parte, el Cron Worker es el encargado de
la programación de operativas, y por otro lado el Database Worker lleva a cabo
actualizaciones en la base de datos sobre las ejecuciones de las operativas.
El sistema de monitorización esta compuesto por 3 componentes: sistema de métri-
cas, sistema de logs y sistema de visualización. Los dos primeros son los encargados
de recolectar un tipo de dato concreto para posteriormente enviarlo al sistema de
visualización, el cual muestra todos los datos de forma compacta a través de paneles
gráficos.
103 | Implementación y pruebas
La mayor parte de la implementación se ha llevado a cabo con un lenguaje de progra-
mación genérico, Python. Esto se debe a su facilidad de uso, legibilidad, compatibili-
dad con la mayor parte de sistemas (existiendo bibliotecas que permiten interactuar
con ellos), la capacidad de interactuar con otros lenguajes de programación y el
entorno del proyecto (Nologin).
3.1. Componentes
Se va a realizar una pequeña descripción de la implementación de los componentes
con las tecnologías que utilizan. Para más detalles, se exponen en el anexo D.
Broker de mensajes. Se eligió tras una comparativa entre distintos brokers (ane-
xo B), decantándose finalmente por RabbitMQ. Permite el intercambio de mensajes
a través de colas con o sin persistencia, con replicación y con distintas opciones de
enrutamiento. Además, dispone de varias bibliotecas en una gran cantidad de lengua-
jes de programación, permitiendo que el resto de componentes se puedan sustituir
por otras implementaciones en distintos lenguajes.
API RESTful. Implementado con el framework web FastAPI. A pesar de ser
relativamente joven, es utilizado en sistemas de producción y dispone de una am-
plia comunidad. FastAPI permite generar documentación automática a través de
OpenAPI [13] y expone un endpoint de forma automática con una interfaz gráfica
de toda la API, pudiendo visualizar fácilmente el resto de endpoints y probarlos a
través de esta interfaz. También, permite validación de modelos y respuestas auto-
máticas con ayuda de una biblioteca basada en las anotaciones de tipos de Python.
A pesar del lenguaje de implementación, tiene un rendimiento superior al resto de
frameworks web en su mismo lenguaje [14]. Para facilitar la interacción con la base
de datos, la API RESTful utiliza un ORM, SQLAlchemy 1 .
Base de datos y modelo de datos. Dado que no existía ninguna limitación en
cuanto a su elección, la experiencia de uso, su madurez, la cantidad de herramientas
1
https://www.sqlalchemy.org/
11CAPÍTULO 3. IMPLEMENTACIÓN Y PRUEBAS
compatibles y el posible alojamiento dentro de la infraestructura de Nologin, se ha
utilizado PostgreSQL. El modelo de datos se encuentra detallado en el Anexo D.3.
Database Worker. Worker encargado de actualizar la información sobre las eje-
cuciones de las operativas conforme se van produciendo eventos y actualizaciones
de estado en ellas como su inicio o la finalización de la ejecución. Estos eventos se
encolan en el sistema de mensajes en una cola específica a la cual está suscrito el
trabajador. Para evitar inconsistencias en la base de datos, cada trabajador está
suscrito a una cola de una operativa concreta. La tecnología de acceso a la base de
datos es la misma que la utilizada por la API RESTful, el ORM SQLAlchemy.
Cron Worker. A pesar del despliegue en Kubernetes, pudiendo elegir la imple-
mentación usando CronJobs (herramientas propias de Kubernetes), se ha implemen-
tado en Python a través de la biblioteca APScheduler permitiendo mayor libertad
de interacción con los recursos de la base de datos. Ha sido necesario crear una tabla
a modo de “envoltorio"sobre la creada por esta biblioteca para poder gestionar la
información de la programación de operativas más fácilmente.
Operation Worker. Para la demostración de ejecución de operativas se ha im-
plementado el trabajador capaz de ejecutar el modelo de OilSpill en los entornos
de computación basados en contenedores: Kubernetes y docker-compose2 . Este
modelo se ha empaquetado en un contenedor capaz de ejecutar el modelo de OilSpill
en fortran, de forma que solo sea necesario desplegarlo y establecer los parámetros
recibidos a través de la API RESTful. Para la interacción con Kubernetes, se ha
utilizado la biblioteca oficial de Kubernetes para Python.
Monitorización de métricas. Se ha utilizado Prometheus, siendo casi el es-
tándar defacto en cuanto a monitorización de métricas en Kubernetes. A través
de su modelo de recolección tipo pull, se recogen las métricas de los demás com-
ponentes. Existen numerosas bibliotecas que facilitan exponer las métricas de los
componentes que no lo hacen de forma automática, o incluso hay sistemas diseña-
dos específicamente para recolectar las métricas de sistemas legados y exponerlas de
forma compatible para Prometheus.
Monitorización de logs. Dada su similitud con Prometheus y con el objetivo de
recolectar logs de forma simple y eficaz, se ha utilizado Loki. Se barajó la opción de
utilizar Elasticsearch3 pero se eligió Loki por su simplicidad y compatibilidad con
el stack de Prometheus. Al contrario que Prometheus, su modelo de recolección de
datos es de tipo push, por lo que es necesario instalar un agente (Promtail4 ) que se
encarga de recolectar los logs y enviarlos a Loki.
2
https://docs.docker.com/compose/
3
https://www.elastic.co/es/what-is/elasticsearch
4
https://grafana.com/docs/loki/latest/clients/promtail/
12CAPÍTULO 3. IMPLEMENTACIÓN Y PRUEBAS
Visualización de la monitorización. Para poder consultar y observar a través
de una interfaz gráfica las métricas y logs, se ha utilizado la herramienta Grafana.
Permite visualizar estos datos a través de paneles gráficos. Estos se pueden configurar
manualmente o utilizar plantillas que distribuye la comunidad para componentes
utilizados masivamente como RabbitMQ y PostgreSQL. En este sistema se han
utilizado plantillas para estos dos componentes y se ha creado un panel plantilla
para cada operativa distinta. De esta forma, cuando se ejecuta una operativa se
interactúa con Grafana para crear un panel de la operativa correspondiente de forma
dinámica.
3.2. Despliegue en desarrollo
Para el despliegue en desarrollo se ha usado una tecnología centrada en un desarrollo
rápido y eficiente: docker-compose. Esta tecnología permite levantar el sistema de
una forma simple y rápida. Además, a pesar del uso de contenedores, se pueden
utilizar volúmenes para que estos compartan los mismos ficheros que el sistema de
ficheros local, permitiendo realizar cambios en el código sin tener que reconstruir los
contenedores cada vez.
En cuanto a la máquina utilizada, se trata de un equipo portátil con las siguientes
características: modelo de procesador Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
con con 8 núcleos, 16GB de memoria RAM y un disco SSD de 256 GB.
3.3. Pruebas en desarrollo
En cuanto a la distribución y diseño de las pruebas se ha tomado como referencia
la guía de pruebas de Martin Fowler [15] y el artículo The Practical Test
Pyramid [16] de Ham Vocke. Dada la naturaleza distribuida y asíncrona del sistema,
se ha valorado que las pruebas más importantes son las de integración, extremo-a-
extremo y validación. A pesar de que también es importante la creación de otras
pruebas como las unitarias, estas no se han llegado a desarrollar ampliamente, ya que
se requería de una cantidad de tiempo fuera del presupuesto y se han llevado a cabo
las más importantes para alcanzar un TRL-5 y la aprobación como prototipo por la
empresa Nologin. Otro tipo de pruebas pendientes de realizar serían las que evalúen
la resistencia a fallos del sistema como caídas de conexión y fallos en máquinas.
Pruebas de integración. En este tipo de pruebas se busca determinar si las pie-
zas de software funcionan correctamente cuando interactúan unas con otras. Con
estas pruebas se ha cubierto la mayor parte de código, alcanzando un 78 % de co-
bertura del código producido por la herramienta de pruebas, pytest 5 .
Se han llevado a cabo pruebas que comprueben el correcto funcionamiento de todos
5
https://docs.pytest.org/en/6.2.x/
13CAPÍTULO 3. IMPLEMENTACIÓN Y PRUEBAS
los componentes que interactúan con la base de datos, el correcto envío y recepción
de mensajes entre componentes cuando actúan como emisor y receptor a través del
bróker y los distintos caminos que puede tomar la lógica del sistema comunicándose
unos componentes con otros. De esta forma a pesar de no disponer de una gran can-
tidad de pruebas unitarias, se comprueban las distintas funcionalidades del sistema
a la vez que se comprueba una correcta comunicación entre ellos.
Pruebas de sobrecarga. Este tipo de pruebas no se han podido llevar a cabo
dados los recursos disponibles. Este sistema necesita ya de por sí una gran cantidad
de recursos, junto con el modelo de OilSpill que también requiere bastantes. Esto
combinado con uno de los riesgos del proyecto, la escasez de recursos en cuanto
a infraestructura (el entorno de despliegue ha sido un clúster de Kubernetes en
una máquina de desarrollo local), ha supuesto que simplemente con mantener todo
el sistema activo y la ejecución de dos operativas a la vez, se alcanzase el límite de
recursos. Una vez se alcanzaba este límite, el sistema eliminaba los procesos de las
operativas por falta de memoria RAM.
Queda como trabajo a futuro, la validación en entornos de pre-producción con la eje-
cución de pruebas de sobrecarga que permitan validar la arquitectura desarrollada,
la cual debe permitir escalar horizontalmente.
144 | Despliegue en pre-producción y
validación
El despliegue de pre-producción ha sido utilizado para la validación de su funciona-
miento por Nologin. En este se deben validar los requisitos. La tecnología seleccio-
nada ha sido Kubernetes, con ayuda de Minikube para disponer de un clúster propio
en el entorno de desarrollo. El despliegue de componentes dentro de este entorno se
muestra en la Figura 4.1.
En el entorno de Kubernetes, se han llevado a cabo las pruebas de validación y
extremo-a-extremo con todo el sistema en funcionamiento. Estas comprueban que
los requisitos se cumplen y son aprobados por Nologin (siendo ejecutadas
por la empresa). En cada uno de ellas se ha seguido la filosofía de ser pruebas
independientes, limpiando el estado de la base de datos y bróker, y reseteando
los datos tras la ejecución de cada una de ellos. Esto se ha llevado a cabo con la
ayuda de Fixtures de la biblioteca de pruebas en python Pytest 1 que permiten con-
figurar objetos como parámetros que son inyectados por el framework para cada
prueba, propios de la etapa Arrange (preparar los recursos para ejecutar la prueba).
A continuación, se ejecutan las acciones las cuales se quiere comprobar su correcto
funcionamiento, en la etapa Act. Finalmente, en la etapa Assert se realizan las aser-
ciones sobre los resultados anteriores. Una vez terminadas estas etapas, se produce la
limpieza de datos. En la implementación de este último paso se utilizan generadores
de python, permitiendo un código limpio, minimalista e interpretable. Las pruebas
de aceptación con mayor peso consisten en:
Se comprueba el caso de uso más común e importante sobre la creación y
ejecución de una operativa. Se crea una especificación de operativa con el
modelo de OilSpill, se solicita la ejecución puntual de esa operativa con unos
parámetros y con entorno HPC Kubernetes. El sistema devuelve una URI
accesible para ese usuario en la que puede observar un panel de Grafana con
los logs en tiempo real de la ejecución. Se comprueba que la ejecución finaliza
con éxito y se ha actualizado correctamente su información de finalización.
Se repiten los pasos de la anterior prueba pero en esta ocasión se solicita la
cancelación de la operativa ejecutada a través de la API REST. Tras un tiempo
de espera preestablecido para una correcta finalización, la operativa se aborta
y se actualiza su estado correctamente.
1
https://docs.pytest.org/en/6.2.x/fixture.html
15CAPÍTULO 4. DESPLIEGUE EN PRE-PRODUCCIÓN Y VALIDACIÓN
Figura 4.1: Despliegue en Kubernetes
Se programa la ejecución de una operativa en el tiempo, comprobándose que los
componentes involucrados reciben los mensajes correspondientes y se almacena
la programación de la operativa en la base de datos.
165 | Organización y gestión
La metodología de trabajo y las herramientas de gestión utilizadas han sido las
siguientes:
Metodología ágil: Scrum [9], con iteraciones de 1-2 semanas dependiendo de
los requisitos a desarrollar, reuniones con el director al final de cada una para
revisión y planificación.
Seguimiento: creación de proyecto y tickets en Jira1 , en donde se registra
una estimación de cada tarea, su progreso y finalización.
Supervisión: reuniones puntuales con el profesor ponente para comprobar el
buen desarrollo del TFG (además de las establecidas con el director planifica-
das con Scrum)
Documentación: Confluence2 como wiki de la empresa.
Además se ha decidido de forma personal por parte del alumno y para recoger los
datos más específicos del TFG (como por ejemplo la dedicación a la memoria) se ha
utilizado una hoja de cálculo (Figura 5.1) a modo de seguimiento para el profesor
tutor, un listado de tareas y tiempo dedicado a modo de diario para el alumno y
creación de gráficos a modo de dashboard )
A pesar de intentar seguir una metodología como Scrum, el proyecto se ha llevado a
cabo con una metodología más iterativa pudiendo diferenciar las siguientes etapas:
análisis y estudio del problema, diseño del sistema, implementación con contenedores
sin Kubernetes, detalles de implementación y despliegue con Kubernetes, validación
del sistema y, finalmente, elaboración de la memoria.
Dentro de estas etapas hay periodos en los que se ha vuelto a repetir pequeñas
fases de análisis, diseño e implementación dado que hay bastantes tecnologías que
se desconocían, se cambiaba algún detalle técnico o se arreglaban ciertos errores
que requerían de estas fases para su corrección. Esto representa un caso real de
desarrollo, ya que resulta idílico que un sistema de este tipo se pueda desarrollar
con una única iteración de las anteriores etapas, además de no haber trabajado en
un proyecto similar con anterioridad.
1
https://www.atlassian.com/es/software/jira
2
https://www.atlassian.com/es/software/confluencejira
17CAPÍTULO 5. ORGANIZACIÓN Y GESTIÓN
Figura 5.1: Hoja de cálculo de seguimiento y organización personal
Análisis y estudio del problema
Diseño del sistema
9.7 %
Memoria
16.4 %
17.2 %
28.4 % 13.5 %
Implementación sin K8s Validación del sistema
14.8 %
Implementación con K8s
Figura 5.2: Dedicación temporal
El TFG dispone desde un principio un presupuesto mínimo medido en 300 horas,
equivalente a los 12 ECTS que le corresponden. Como se podía esperar, este tiempo
ha aumentado, llegando hasta 390 horas sobrepasando el presupuesto inicial. De
todas formas, se estimaba como gasto total de horas hasta 400 totales, las cuales no
se han alcanzado. Se ha llevado a cabo una aproximación de la dedicación temporal
(Figura 5.2) a las anteriores etapas con los datos recogidos de la hoja de cálculo
de seguimiento. Cabe destacar que una parte del tiempo de implementación se ha
contabilizado mezclado con las horas de estudio de tecnologías concretas y ha sido
difícil separar completamente estos datos a la hora de exponerlos en la gráfica.
186 | Impacto
Todo desarrollo tiene un impacto. Este se puede valorar según aspectos en sosteni-
bilidad o de compromiso social. Para este análisis se ha tomado como referencia
recomendaciones que actualmente están siendo aplicadas en la Facultad de Infor-
mática de Barcelona [17]. Los tres ámbitos a valorar son: ambiental, económico y
social. Dentro de estos ámbitos se valoran los siguientes elementos:
Proyecto puesto en producción (PPP): incluye la planificación, el desa-
rrollo y la implantación del proyecto.
Vida útil: empieza una vez implantado y termina con su desmantelamiento.
Riesgos: problemas que se pueden dar o no durante la construcción del siste-
ma, su vida útil y desmantelamiento.
6.1. Ambiental
El impacto ambiental estudia las consecuencias sobre el medioambiente durante la
realización del TFG, la huella ecológica producida durante su existencia (vida útil)
y los riesgos que podrían darse aumentando el impacto ambiental aún más de lo
previsto.
Elemento Comentario
PPP A lo largo de la realización del TFG se ha utilizado un equipo de
desarrollo portátil, cedido por la empresa, con un consumo no muy
elevado si se compara con el gasto de recursos que tienen servidores
que deben disponer de una fuente de alimentación en todo momen-
to, control térmico y otros requerimientos de mantenimiento.
Vida útil Una vez se ponga en marcha en producción, sí que se producirá un
consumo mayor, ya que se desplegará en servidores. Se desconoce
si se realizará en cloud privado o público por lo que no se puede
valorar su consumo, más allá de un gasto mayor que en PPP.
Riesgos No existen riesgos sobre el impacto ambiental.
Cuadro 6.1: Impacto ambiental
19CAPÍTULO 6. IMPACTO
El impacto ambiental producido por este TFG es reducido debido a que el sistema
no requiere de una gran capacidad de computación, siendo el mayor consumidor de
recursos los entornos HPC donde se ejecutan los modelos.
6.2. Económico
El impacto económico estudia el consumo de recursos (materiales y humanos) duran-
te la realización del TFG y durante su vida útil, el plan de viabilidad del proyecto
y las eventualidades que podrían causar que el proyecto tardase más tiempo del
previsto en alcanzar la viabilidad o no llegase a ser rentable.
Elemento Comentario
PPP En cuanto a recursos humanos, requiere de una persona que desa-
rrolle el sistema (el alumno) con un presupuesto desde 300 a 400
horas, el director de TFG que colabora en el diseño del proyecto
para la empresa y el ponente de la universidad que colabora con una
correcta realización del TFG desde el punto de vista académico.
Vida útil De forma simplificada y estimada se considera que debería existir
un equipo contratado de más de 2 personas a jornada completa que
se encargase de completar las partes restantes, además de algún
responsable de operaciones.
Riesgos Durante la construcción del sistema se dan los riesgos de falta de
disponibilidad de un clúster privado de Nologin y su riesgo derivado
de recursos limitados para el desligue de forma local. A futuro, el
proyecto podría no ser viable si se comprueba que intentar orques-
tar la ejecución de operativas desde un mismo lugar es demasiado
complejo y se necesitan soluciones ad-hoc para cada una de ellas.
Cuadro 6.2: Impacto económico
El impacto económico durante la etapa de desarrollo es mínimo dado que no se
requiere de una gran cantidad de recursos económicos ni humanos. Durante su vida
útil puede ser más elevado en cuanto al número de modelos que deba soportar el
sistema y el aumento de complejidad. Siendo estos dos los principales riesgos.
6.3. Social
El impacto social estudia las consecuencias sobre las personas que han trabajado en
el proyecto o que van a participar en él durante su vida útil. También se valoran
las eventualidades que podrían causar que el impacto social del proyecto sobre las
personas relacionadas con él sea más negativo del previsto.
20CAPÍTULO 6. IMPACTO
Elemento Comentario
PPP En el desarrollo del TFG se ha podido reflexionar sobre el coste
y dificultad de un sistema en un entorno de producción. Además,
se ha tenido en cuenta su viabilidad y puesta en marcha, ya que
al comienzo del TFG se tuvo que afinar la idea que se tenía para
llegar al objetivo que se quería conseguir.
Vida útil Se espera que con este proyecto se facilite la labor de puesta en
marcha de operativas de modelos de predicción oceanográficos o
que sirva para la ejecución de otros procesos similares.
Riesgos El impacto social del proyecto podría ser más negativo del previsto
si la puesta en marcha del sistema es mucho más complejo que la
mecánica que se utiliza actualmente para la ejecución de operativas.
Cuadro 6.3: Impacto social
El impacto social busca ser positivo sobre las personas que actualmente trabajan
con los modelos de predicción de forma separada, facilitando sus labores. En cambio,
puede resultar negativo si los riesgos se materializan, añadiendo más trabajo a las
personas relacionadas con el sistema.
217 | Conclusiones
Para finalizar se realiza una serie de conclusiones centrándose en el progreso alcan-
zado del prototipo, el trabajo a futuro que se debe realizar para mejorar o terminar
algunas características del sistema, y por último, una valoración personal del TFG.
7.1. Alcance
Este trabajo tenía como objetivo una idea muy concreta pero a la vez compleja de
acertar con el diseño, buscando una solución muy ambiciosa. Desde el comienzo se
requirió de varias reuniones y tiempo de análisis para concretar algunos conceptos
y qué dirección debía tomar el proyecto. Tras estos ajustes iniciales, se establecie-
ron los requisitos de un proyecto completo categorizándolos según su alcance de
implementación en el TFG o como tareas en el futuro. De esta forma, se tenía una
perspectiva de todo el sistema al completo pero se diferenciaba de lo que correspon-
día a desarrollar en el TFG.
Inicialmente se buscaba un TRL 5-7, lo que finalmente se ha conseguido llegar hasta
el nivel de TRL 6 validando a nivel de componentes y a nivel de sistema en
un entorno relevante, el cual es Kubernetes. No se ha alcanzado el nivel 7 dado que
no se ha validado en un entorno real, sin cubrir un despliegue en pre-producción con
máquinas con suficiente capacidad de recursos para realizar pruebas de sobrecarga.
Se han cubierto todos los requisitos categorizados como Must have, la mayoría de
los Should have y alguno de los Could have. Además, se ha tenido en cuenta el resto
de requisitos para el diseño y elección de tecnologías facilitando el desarrollo en el
futuro de los requisitos que no entraban en el alcance del TFG. En cuanto al nivel
de madurez de la interfaz REST, se ha alcanzado el objetivo propuesto utilizando
los verbos HTTP de forma correcta y añadiendo algún elemento como la inserción
de hypermedia sobre las operaciones que se pueden realizar sobre un recurso en la
respuesta de una petición. Por ejemplo, si se consulta las plantillas de operativas,
se devuelve un listado de ellas junto con un campo “links” con la relación “self”
al propio recurso. Si se hace una petición sobre este “link” de la relación “self” se
devuelve la representación del recurso y además se muestra el resto de “links” con
más operaciones disponibles: DELETE, PUT. Esta pequeña implementación de una
Hypermedia Compliant API se basa en la guía de estilo de Paypal [18]. De esta
forma, se considera que se ha alcanzado los objetivos propuestos en la Sección 1.3.
22También puede leer
