API REST para un balanceador de carga de un servicio cloud
Trabajo de Fin de Grado
Junio 2021
Autor: Victor Guardia Horcajada
Director: Javier de Muniategui Climente
(Ludium Lab S. L.)Ponente: Xavier Verd´ u Mul` a
(Departament d’Arquitectura de Computadors)Grado en Ingenier´ıa Inform´ atica
Especialidad en Tecnolog´ıas de la Informaci´ on Facultat d’Inform` atica de Barcelona
Universitat Polit` ecnica de Catalunya
Resumen
La mayor´ıa de servicios cloud requieren balanceadores de carga. Este proyecto parte de uno existente, dise˜nado espec´ıficamente para un producto de cloud gaming, ya que ninguna de las soluciones m´as generales se pueden aplicar a este contexto.
No obstante, su integraci´on con el resto de aplicaciones limita su usabilidad y fiabilidad. Por lo tanto, se ha decidido aprovechar el c´odigo actual, pero exponerlo a trav´es de una aplicaci´on intermediaria que solucione estos problemas sin a˜nadir complejidad a los dem´as componentes y extienda las opciones disponibles con tal de facilitar el mantenimiento de esta herramienta.
El resultado de este proyecto ha sido puesto en producci´on como parte del servicio de cloud gaming SoraStream, creado por la empresa Ludium Lab S. L., donde ha sido realizado.
Resum
La major part dels serveis cloud necessiten balancejadors de c`arrega. Aquest projecte parteix d’un existent, dissenyat espec´ıficament per a un producte de cloud gaming, ja que cap de les solucions m´es generals es poden aplicar en aquest context.
Tot i aix`o, la seva integraci´o amb la resta d’aplicacions en limita la usabilitat i la fiabilitat. Per tant, s’ha decidit aprofitar el codi actual, per`o exposar-ho a trav´es d’una aplicaci´o intermedi`aria que solucioni aquests problemes sense afegir complexitat als altres components i ampli¨ı les opcions disponibles per tal de facilitar el manteniment d’aquesta eina.
El resultat d’aquest projecte ha sigut posat en producci´o com a part del servei de cloud gaming SoraStream, creat per l’empresa Ludium Lab S. L., on ha sigut realitzat.
Abstract
Most cloud services require load balancers. This project is based on an existing one, designed specifically for a cloud gaming product, as none of the existing off- the-shelf solutions was applicable in this context.
However, its integration with other software is limiting its usability and reliabil- ity. Therefore, it was decided to reuse the current code, while exposing it through a proxy application that solves both of these issues without adding complexity to the rest of the components, as well as extending the available options to ease the maintenance of this tool.
The result of this project has been deployed in production as part of the SoraS- tream cloud gaming service, created by Ludium Lab S. L., where it has has been developed.
´ Indice
1 Contextualizaci´on 7
1.1 Introducci´on. . . 7
1.2 Estado del arte . . . 7
1.3 Estado actual . . . 9
1.4 Problema . . . 10
1.5 Actores implicados . . . 11
2 Objetivos 13 3 Estudio de arquitectura para el Selector 14 3.1 An´alisis de alternativas. . . 14
3.2 Propuesta . . . 15
3.3 Estudio de escalabilidad . . . 17
3.4 Estudio de conexiones . . . 19
4 Alcance del proyecto 20 4.1 Riesgos asociados . . . 20
4.2 Metodolog´ıa seguida . . . 21
4.3 Metodolog´ıa de validaci´on . . . 22
5 Planificaci´on 23 5.1 Recursos del proyecto . . . 23
5.2 Descripci´on de las tareas . . . 23
5.2.1 Gesti´on del proyecto . . . 23
5.2.2 An´alisis . . . 24
5.2.3 Dise˜no . . . 26
5.2.4 Desarrollo . . . 27
5.2.5 Pruebas . . . 28
5.2.6 Seguimiento . . . 30
5.2.7 Documentaci´on . . . 31
5.3 Resumen. . . 31
5.4 Gantt . . . 32
5.5 Valoraci´on de alternativas y plan de acci´on . . . 33
6 Implementaci´on 35 6.1 Actualizaciones en el Selector Core . . . 35
6.2 Control wrapper . . . 35
6.2.1 Dise˜no . . . 35
6.2.2 Desarrollo . . . 35
6.3 Management wrapper . . . 36
6.3.1 Dise˜no . . . 36
6.3.2 Desarrollo . . . 37
6.4 Portal de gesti´on . . . 37
7 Validaci´on 40 7.1 Cambios en el Selector Core . . . 40
7.2 Wrapper de control . . . 40
7.3 Wrapper de gesti´on . . . 41
7.4 Portal de gesti´on . . . 42
8 An´alisis de rendimiento 44 8.1 Descripci´on de las pruebas . . . 44
8.2 Resultados. . . 45
9 Planificaci´on final 49 9.1 Desviaciones de la planificaci´on inicial . . . 49
9.2 Tabla de tiempo . . . 49
10 Presupuesto 51 10.1 Costes humanos. . . 51
10.2 Costes materiales . . . 52
10.2.1 Costes directos de hardware . . . 52
10.2.2 Costes directos de software . . . 52
10.2.3 Costes indirectos . . . 53
10.3 Sumario . . . 53
10.4 Control de gastos . . . 54
10.5 Presupuesto final . . . 55
11 An´alisis de sostenibilidad 56 11.1 Reflexi´on . . . 56
11.2 Sostenibilidad ambiental . . . 56
11.3 Sostenibilidad econ´omica. . . 56
11.4 Sostenibilidad social . . . 57
11.5 Matriz de sostenibilidad . . . 57
12 Legalidad del proyecto 58
13 Integraci´on de conocimientos 59
14 Conclusiones 60 14.1 Observaciones . . . 60 14.2 Trabajo futuro . . . 60
´ Indice de figuras
1.1 Flujo habitual de un load balancer . . . 8
1.2 Arquitectura general del sistema . . . 9
1.3 Conexiones actuales del Selector . . . 10
3.1 Conexiones de la versi´on inicial . . . 15
3.2 Conexiones de la versi´on final . . . 17
3.3 Conexi´on de control con escalabilidad N:1 . . . 18
3.4 Conexi´on de control con escalabilidad 1:1 . . . 18
3.5 Conexi´on de control con escalabilidad N:M . . . 19
5.1 Diagrama Gantt . . . 33
6.1 Lista de servidores del Selector Core en el portal de administraci´on . . . 38
6.2 Edici´on de la lista de servidores Core en el portal de administraci´on . . . 39
6.3 Detalles acerca de una clave API en el portal de administraci´on . . . 39
7.1 Prueba de petici´on a la API de control en Postman . . . 41
7.2 Prueba de petici´on a la API de gesti´on en Postman . . . 42
8.1 Rendimiento antes de las modificaciones . . . 45
8.2 Rendimiento antes de las modificaciones (ampliado) . . . 46
8.3 Rendimiento despu´es de las modificaciones. . . 47
8.4 Rendimiento despu´es de las modificaciones (ampliado) . . . 47
8.5 Diferencia entre antes y despu´es del proyecto . . . 48
Todas las figuras son de elaboraci´on propia.
´ Indice de tablas
5.1 Resumen de horas . . . 329.1 Tiempo final . . . 50
10.1 Costes humanos. . . 51
10.2 Costes de hardware amortizados . . . 52
10.3 Costes de hardware alquilado . . . 52
10.4 Costes de software . . . 53
10.5 Costes indirectos . . . 53
10.6 Sumario de costes. . . 54
10.7 Sumario de costes final . . . 55
11.1 Matriz de sostenibilidad . . . 57
1 Contextualizaci´ on
1.1 Introducci´on
La industria de los videojuegos ha recibido, en los ´ultimos a˜nos, un gran crecimiento, tanto en n´umero de usuarios como en t´ıtulos. Como ejemplo, una de las mayores tiendas de distribuci´on de videojuegos dispone de cerca de 25 millones de usuarios simult´aneos [1] y m´as de 90.000 juegos [2]. Una de las ´ultimas tendencias en el mercado se trata de servicios de cloud gaming, que importan el modelo cloud aplicado habitualmente a otros sectores a los videojuegos, permitiendo ejecutar los juegos en servidores remotos en lugar de en los ordenadores de los usuarios, y ofreciendo los juegos como servicios que el usuario contrata, en lugar de como productos que se compran.
SoraStream es una plataforma de cloud gaming, desarrollada por Ludium Lab, que permite lanzar aplicaciones en los servidores del servicio, enviar las se˜nales de entrada (rat´on, teclado, gamepad) y recibir las de salida (v´ıdeo, audio. . . ), comport´andose como si el programa estuviera instalado en el propio dispositivo [3].
Para realizar esta funci´on, se dispone de un conjunto din´amico de servidores, inclu- yendo servidores dedicados (aquellos servidores f´ısicos de los que se dispone completa- mente) en varias ubicaciones geogr´aficamente distantes y servidores alojados en cloud (servidores virtuales provistos bajo demanda [4]).
El servicio debe poder escalar seg´un el n´umero de usuarios, pero esto requiere una administraci´on cuidadosa del conjunto de servidores: un sobredimensionado resulta muy costoso y pondr´ıa en peligro la viabilidad del producto, mientras que un aprovisiona- miento limitado impedir´ıa prestar un servicio adecuado. Por ello, es esencial disponer de un balanceador de carga que sea consciente de los detalles de las m´aquinas disponibles y sepa distribuir la carga de trabajo de forma que se obtenga una experiencia ´optima de cara al usuario de la forma m´as eficiente posible.
1.2 Estado del arte
El balanceo de cargas es un problema cl´asico en entornos de computaci´on en la nube, con el que se pretende distribuir las peticiones entre todos los servidores disponibles, generalmente tambi´en analizando su estado para evitar enviar peticiones a un servidor que ha fallado.
Al ser tan com´un, hay una gran variedad de productos disponibles que realizan esta funci´on. Algunos ejemplos son: Nginx [5], HAProxy [6], Apache HTTPD (con mod proxy) [7], Envoy [8] o Træfik [9]. Generalmente, ´estos se usan para tr´afico HTTP, y todos tienen opciones dise˜nadas para este protocolo, como permitir el enrutado de peticiones seg´un atributos del nivel de aplicaci´on (L7, seg´un el modelo OSI [10]). Sin embargo, la plataforma de ejecuci´on de juegos no usa HTTP, si no que define un proto- colo propio, sobre TCP, que se adapta a las necesidades del streaming de videojuegos.
Por lo tanto, se deber´ıa extender el software para soportar el protocolo de la plataforma o, si no fuera posible, realizar el enrutado en la capa de transporte (TCP, L4), prescin-
diendo de informaci´on de la capa de aplicaci´on, aunque esto limitar´ıa la capacidad de decisi´on del load balancer. De los mencionados, el ´unico que no soporta ninguna de las dos opciones es Apache HTTPD, que ´unicamente acepta tr´afico HTTP(S), por lo que no ser´ıa posible usarlo.
Otro punto importante es que la latencia de la conexi´on es un par´ametro de m´axima importancia para garantizar un buen funcionamiento del servicio. Adem´as, uno de los casos de uso del load balancer implica que los servidores de ejecuci´on est´an en otro centro de datos (otra regi´on u otro proveedor cloud).
Por esto, un balanceador de carga para el sistema no debe intervenir en el flujo de datos una vez elegido el servidor. Esto choca con la arquitectura de load balancers m´as com´un (Figura 1.1), que consiste en ubicar el balanceador entre el cliente y el servidor, interceptando y redirigiendo el tr´afico. Esto a˜nadir´ıa latencia que puede impactar la via- bilidad del servicio, crear´ıa un posible cuello de botella, y a˜nadir´ıa un coste significativo, al tener que pagar por la transferencia de datos (en su mayor´ıa audiovisuales, y por tanto pesados) entre el servidor y el load balancer y entre ´este y el usuario final. Sin embargo,
´esta es la ´unica opci´on soportada para TCP en los programas estudiados.
Figura 1.1: Flujo habitual de un load balancer
Para cumplir con lo anterior se podr´ıa prescindir de un software de load-balancer y hacer balanceo de carga mediante DNS, pero los algoritmos disponibles son muy b´asicos [11]. Esto nos lleva al principal problema de las soluciones existentes: el balanceo de carga para cloud gaming requiere un algoritmo de decisi´on sofisticado que tenga en cuenta las particularidades de este tipo de tr´afico:
• Una sesi´on solo puede ser atendida por un servidor, ya que una vez lanzado el juego, ´este se convierte un proceso en ese servidor, que no puede ser movido a otra m´aquina.
• Cada sesi´on consume una gran cantidad de recursos (CPU, GPU, memoria, red...).
Aunque depende mucho del juego en concreto y del tama˜no del servidor, resulta im- posible que un servidor razonablemente potente gestione m´as de una o dos decenas de sesiones.
• Cada sesi´on suele durar como m´ınimo varios minutos, y puede durar horas, durante las cu´ales el servidor le est´a dedicando recursos cont´ınuamente.
Una opci´on ser´ıa implementar la decisi´on en el lado del cliente. El servicio se presta utilizando clientes especiales, por lo que ser´ıa t´ecnicamente posible hacer que ´estos elijan el servidor al que conectarse. Sin embargo, estos programas se ejecutan en los equipos de los usuarios, y para permitir tomarles decisiones requerir´ıan un acceso amplio al resto de la plataforma que no ser´ıa prudente conceder.
Finalmente, se decidi´o desarrollar un load balancer especialmente dise˜nado para este prop´osito, que cubra los puntos mencionados anteriormente, dado que ninguna soluci´on actualmente en el mercado lo hace adecuadamente. Otros servicios en situaciones si- milares tambi´en han optado por desarrollar software propio, por ejemplo [12], tambi´en enfocada al streaming, aunque en este caso de v´ıdeo.
Antes de la realizaci´on de este proyecto, ya exist´ıa una versi´on de este componente, que fue desarrollado en base a un an´alisis similar al anterior. El componente, denominado
“Selector”, necesita ser actualizado, como se discutir´a en la Secci´on 1.4. A´un as´ı, el estudio realizado sigue vigente, y no se podr´ıa sustitu´ır con ninguna soluci´on off-the- shelf.
1.3 Estado actual
El Selector, tal y como estaba antes de la realizaci´on de este proyecto, cumple con varias funciones necesarias para el buen funcionamiento del sistema, cuya estructura se revisa en laFigura 1.2:
Figura 1.2: Arquitectura general del sistema
As´ı, conecta el Control Backend, encargado de la autenticaci´on, la autorizaci´on y otras gestiones, con el Execution Backend, donde se ejecutan los juegos. Por lo tanto, permite un balanceo de carga teniendo en cuenta par´ametros espec´ıficos del sistema, como la carga de los servidores o si la sesi´on tiene condiciones especiales que limiten los servidores elegibles.
Adem´as, permite el paso de informaci´on asociada a una sesi´on entre el Control Bac- kend y el Execution Backend, de forma segura. Sin esta funci´on, la informaci´on deber´ıa pasar por el cliente (lo que implicar´ıa tomar medidas para evitar su manipulaci´on por parte de un cliente malicioso) o con una conexi´on directa entre ambos, aumentando el acoplamiento del sistema.
Expandiendo en la parte del Selector, podemos ver las conexiones actuales en la Figura 1.3. La comunicaci´on con ambos Backends se realiza mediante protocolos ad-hoc sobre TCP. Adem´as de las conexiones mencionadas, dispone de un puerto para realizar ciertas acciones de mantenimiento, pero no se ha desarrollado ning´un programa que lo use.
Figura 1.3: Conexiones actuales del Selector
1.4 Problema
Dado su papel clave en el sistema, el Selector est´a involucrado en varias funcionalidades de la plataforma, pero su estado antes del proyecto, tanto a nivel de c´odigo interno como a nivel de interfaces externas, dificultaba el desarrollo de nuevas caracter´ısticas. Por lo tanto, se quiso revisar el dise˜no con el objetivo de agilizar futuros desarrollos, mejorando la integraci´on con los dem´as componentes, la escalabilidad, la extensibilidad y la man- tenibilidad, tanto del c´odigo como la facilidad de realizar acciones de mantenimiento y configuraci´on habituales.
En concreto, se deber´ıan abordar los siguientes puntos:
1. Los protocolos con los que los dem´as componentes del sistema se comunican con el Selector son hechos a medida, obligando a desarrollar herramientas propias para todas las interacciones, en lugar de poder aprovechar las librer´ıas y programas desarrollados para protocolos est´andar (como HTTP).
2. Estos protocolos, adem´as, no tienen provisiones para garantizar la retrocompatibi- lidad, complicando el despliegue del sistema, ya que actualizaciones que requieran cambios en los protocolos del Selector deben hacerse de forma simult´anea con los equipos que gestionan los backends, cuyo desarrollo y prioridades son independien- tes del equipo de desarrollo del Selector.
3. Los procedimientos que se exponen mediante estos protocolos se limitan a los m´ınimos requeridos para el funcionamiento habitual del servicio, pero las acciones
requeridas para el mantenimiento se realizan mediante una API1 especial para la que nunca se lleg´o a desarrollar ning´un consumidor. Parad´ojicamente, algunas de las actuaciones m´as comunes ni siquiera est´an expuestas en esta API. Como resultado, todo el mantenimiento se hace editando manualmente la base de datos, con los riesgos que ello conlleva.
4. Se deber´ıan revisar las medidas de escalabilidad y tolerancia a fallos que est´an im- plementadas actualmente en el c´odigo, para garantizar su correcto funcionamiento y que no se est´a creando un ´unico punto de fallo en el sistema, ya que si el Selector falla resulta imposible lanzar nuevas partidas.
5. El c´odigo no fue dise˜nado con la mantenibilidad en mente, y las sucesivas modi- ficaciones que ha ido sufriendo a medida que las necesidades de la empresa han ido evolucionando han derivado en un c´odigo dif´ıcil de extender y con muchas funcionalidades obsoletas.
1.5 Actores implicados
Desarrollador
El desarrollador encargado de dise˜nar e implementar lo especificado en este documento ser´a el autor, Victor Guardia Horcajada, estudiante en la Facultat d’Inform`atica de Bar- celona, empleado de Ludium Lab y actualmente ´unico miembro del equipo de desarrollo del Selector.
Tutores del proyecto
Supervisar´an este proyecto para garantizar su correcta realizaci´on:
• El director, Javier de Muniategui Climente, trabajando como Core Technology Developer en Ludium Lab.
• El ponente, Javier Verd´u Mul`a, profesor del Departament d’Arquitectura de Compu- tadors de la Universitat Polit`ecnica de Catalunya y Chief Technology Officer en Ludium Lab.
Equipo de backend development
Colaborar´a, en calidad de usuario interno, en el dise˜no de la interconexi´on con el backend de control.
1Una Application Programming Interface es una interfaz que permite a programas externo acceder a las funcionalidades p´ublicas de un servicio.
Equipo de infrastrucure management
Encargado del despliegue del software desarrollado en el sistema de SoraStream, aportar´a requisitos y sugerencias para una correcta integraci´on del proyecto en el resto de la plataforma.
2 Objetivos
Para resolver los problemas mencionados en el apartado anterior, se ha propuesto de- sarrollar una API REST2 para el Selector actual. Esto, junto con las modificaciones m´ınimas necesarias al c´odigo actual, pretende:
1. Proporcionar fiabilidad y tolerancia a fallos al sistema del Selector.
2. Dotar de escalabilidad horizontal a ´este.
3. Facilitar la integraci´on del Selector con el resto de los componentes existentes, reduciendo las dependencias entre el equipo de desarrollo del Selector y los equipos de los dem´as componentes, y permitiendo el desarrollo de herramientas de soporte.
4. Facilitar los procesos de mantenimiento habituales involucrados en el sistema, re- duciendo las interacciones manuales para evitar posibles errores.
2Representational State Transfer (REST) es un estilo de API que busca crear servicios web con una interfaz uniforme definiendo gu´ıas para crearlos siguiendo una sem´antica concreta. [13]
3 Estudio de arquitectura para el Selector
3.1 An´alisis de alternativas
Existen diversas soluciones que permitir´ıan alcanzar los objetivos propuestos en cuan- to a fiabilidad, tolerancia a fallos, escalabilidad y facilidad de uso. En esta secci´on se analizar´an las ventajas e inconvenientes de cada una de ellas.
Para solucionar el problema de la mantenibilidad, se podr´ıa hacer un refactoring del c´odigo, desacoplando los distintos componentes internos, eliminando c´odigo obsoleto y, aprovechando que se modifica, a˜nadiendo registros que faciliten el debugging del proceso de decisiones.
Sin embargo, esto no solucionar´ıa los problemas derivados del protocolo en uso ni de las operaciones de mantenimiento, y el gran acoplamiento entre los distintos segmentos (hay una fuerte interacci´on entre el c´odigo de red y el c´odigo de l´ogica, y entre el de l´ogica y el de almacenamiento, por ejemplo) har´ıa que el esfuerzo requerido para el refactoring fuera similar a una reescritura casi completa del programa.
La reescritura del programa, no obstante, ser´ıa un proyecto demasiado amplio y costoso, ya que, como se ha expuesto, este c´odigo realiza distintos roles, y crear un c´odigo con estas mismas funcionalidades presenta una complejidad demasiado elevada como para ser atajado en un solo proyecto. Adem´as, tampoco solucionar´ıa los problemas de protocolo y de las operaciones de mantenimiento, as´ı que las funcionalidades actuales tambi´en deber´ıan ser ampliadas para cubrir estos casos.
Cambiar el protocolo sin modificar el resto de las funcionalidades, aunque solucionar´ıa los problemas correspondientes, seguir´ıa sin resolver las preocupaciones sobre mantenibi- lidad y escalabilidad, que deber´ıan ser resueltas independientemente, teniendo en cuenta lo expuesto en los puntos anteriores.
Otra opci´on ser´ıa seguir usando el Selector actual, pero a˜nadiendo una capa adicional, un intermediario (o proxy, en ingl´es) que se comunique con el resto de los programas del sistema mediante una nueva API, m´as adaptable, y f´acil de consumir, y pase las peticiones al Selector actual con el protocolo actual. Si hubiera que realizar cambios incompatibles en el protocolo del Selector, al ser un detalle de implementaci´on interno, solo se requerir´ıa actualizar simult´aneamente el Selector y el proxy, pudiendo actualizar los consumidores de la API progresivamente. Este enfoque es utilizado en casos similares, como proxies que a˜naden o quitan cifrado TLS para conectar servicios que no lo soportan [14] o un proxy de transcodificaci´on para que un cliente pueda consumir una API gRPC3 como si fuera una API REST [16].
La opci´on anterior solucionar´ıa los problemas relacionados con los protocolos y la compatibilidad, pero dejar´ıa sin resolver los problemas de mantenibilidad y escalabili- dad. Sin embargo, este software podr´ıa, en lugar de limitarse a una simple traducci´on
3gRPC [15] es un protocolo para llamadas a procedimientos remotos (RPC) dise˜nado por Google con el objetivo de facilitar las llamadas entre servicios, haciendo que se asemejen a llamadas a funciones locales.
de protocolo, implementar funcionalidades sin depender del c´odigo original. Aunque co- mo punto en contra estar´ıa que la funcionalidad externamente visible del Selector est´a repartida en dos programas distintos, a favor hay que tener en cuenta que el progra- ma intermediario servir´ıa como base para una posible reescritura gradual, permitiendo mover progresivamente funcionalidades del Selector original (que, pese a sus carencias, es considerado c´odigo maduro) al nuevo programa, mientras se mantiene la compatibi- lidad de la API, considerando que la delegaci´on de ciertas funciones es un detalle de implementaci´on.
En cuanto a la tolerancia a fallos y escalabilidad de esta ´ultima opci´on, el programa intermedio se podr´ıa desarrollar desde cero para poder escalar horizontalmente, pero el c´odigo actual s´ı deber´ıa ser revisado y, de ser necesario, modificado para asegurar una ejecuci´on segura de varias instancias en paralelo, evitando as´ı un efecto “cuello de botella” y un posible punto ´unico de fallo.
Habiendo planteado las diferentes alternativas, con sus pros y sus contras, se ha optado por la ´ultima opci´on: un programa intermedio que oculte la complejidad del Selector actual y abstraiga los posibles cambios, como se explica en la secci´onSecci´on 3.2.
3.2 Propuesta
A partir del an´alisis de alternativas realizado, se ha planteado la arquitectura ilustrada en laFigura 3.1
Figura 3.1: Conexiones de la versi´on inicial De esta propuesta, cabe destacar varios puntos:
Primero, se ha reemplazado la conexi´on de control con una API HTTP REST (im- plementada en el Control wrapper) que facilita su uso por parte del backend de control
y de otras herramientas internas. Este servicio traducir´a estas peticiones de la nueva API al protocolo original (de aqu´ı lo de wrapper, porque envuelve el protocolo original y, de cara al exterior, lo presenta con una interfaz m´as f´acil de usar), minimizando as´ı las posibles incongruencias entre el comportamiento de la nueva API y el comportamiento original del Selector.
Aunque al principio se consider´o integrar ambas APIs (control y gesti´on) en un
´unico programa, se decici´o crear dos servicios separados para facilitar su administraci´on y para permitir su despliegue en condiciones separadas, ya que la interfaz de gesti´on puede interesar reservarla a redes privadas o con otros tipos de control de acceso.
Se espera que al crear una API m´as accesible y con m´as funciones, se pueda desarro- llar, si fuera necesario, herramientas internas que asistan en las tareas de mantenimiento habituales del sistema. A´un as´ı, algunas de estas tareas son espor´adicas y no merece la pena dedicar tiempo de desarrollo a ellas. Hasta ahora, se realizaban consultando direc- tamente la base de datos, pero esto es algo a evitar, al ser poco conveniente y se pueden cometer errores f´acilmente. Tambi´en se podr´ıan realizar peticiones HTTP manualmente a la API del Management wrapper, aunque tampoco es una opci´on muy conveniente.
En su lugar, se ha creado un portal de gesti´on, una interfaz web que permite acceder a las opciones implementadas, que deber´ıan cubrir las tareas de mantenimiento del sistema.
Tanto el ´ambito del portal de gesti´on como el del Management wrapper han sido ampliados, como se explica en la Secci´on 6, pero esto no afecta al dise˜no general del proyecto.
Igual de interesante que aquellos puntos que se han a˜nadido son aquellos que no se han modificado:
Por un lado, el c´odigo original del Selector se conserva pr´acticamente inalterado, formando el componente ahora llamado “Selector Core” (o simplemente “Core”). No es necesario realizar cambios para a˜nadir el Control wrapper, porque este garantiza la compatibilidad con el protocolo actual, y el Management wrapper accede directamente a la base de datos, sin necesidad de alterar su esquema. Adem´as, el algoritmo de decisi´on implementado se quiere conservar.
El Selector Core s´ı se ha modificado levemente para solucionar algunos puntos del c´odigo que podr´ıan ocasionar problemas de sincronizaci´on cuando haya varias instancias en ejecuci´on, como se explica en la Secci´on 3.3.
Por otro lado, la comunicaci´on con el Execution backend no se ha estudiado en este proyecto. Si bien los otros protocolos siguen un patr´on de request-reply y pueden ser sustituidos f´acilmente por APIs HTTP equivalente [17], la conexi´on de ejecuci´on no sigue exactamente un protocolo cliente-servidor, ya que el Selector tiene que supervisar constantemente el estado de los servidores de juego, as´ı que no se podr´ıa aplicar la misma soluci´on. Aunque la conexi´on tambi´en puede ser actualizada, requerir´ıa un desarrollo coordinado por ambos equipos y un estudio distinto de sus necesidades, por lo que se ha decidido excluirlo del proyecto actual para mantenerlo centrado en las necesidades de los dem´as puntos de conexi´on y permitir que su desarrollo se produzca en paralelo con el de los dem´as componentes del sistema, sin introducir incompatibilidades ni dependencias temporales con otros proyectos de la organizaci´on.
Finalmente, la arquitectura final es ligeramente diferente a la que se ha mostrado anteriormente, debido a cambios explicados en laSecci´on 6.3. En laFigura 3.2se puede ver la arquitectura finalmente realizada.
Figura 3.2: Conexiones de la versi´on final
3.3 Estudio de escalabilidad
Una vez decididos los componentes que formar´an el nuevo Selector, se debe estudiar c´omo se conectar´an entre ellos. Surgen entonces diversas posibilidades desde el punto de vista de la escalabilidad y la tolerancia a fallos: qu´e conexiones establecer´an varias instancias del Control wrapper a varias instancias del Selector Core.
Las conexiones del Management wrapper no se contemplan, ya que no es necesario que se conecte con ning´un otro componente, accediendo directamente a la base de datos compartida, cuyo estudio no est´a incluido en este proyecto.
Las conexiones del Management wrapper y el Management portal no se contemplan, ya que estos componentes no estar´an replicados, al no darse las condiciones de demanda ni criticidad para justificarlo. Adem´as, el Management wrapper no se conectar´a al Se- lector Core, si no directamente a su base de datos, cuyo estudio de escalabilidad queda fuera de este trabajo.
La primera opci´on es un modelo N:1, con varios wrappers conect´andose a un ´unico Selector Core (verFigura 3.3). Tambi´en existe la posibilidad inversa: un ´unico wrapper
conectado a varios Cores. Ambas opciones se han descartado porque mantendr´ıan un
´unico punto de fallo, lo que ser´ıa contrario al objetivo de fiabilidad del sistema.
Figura 3.3: Conexi´on de control con escalabilidad N:1
Otra posibilidad ser´ıa un modelo 1:1 (ilustrado en laFigura 3.4), donde cada wrapper tiene asignado un ´unico Core, replicando el conjunto tantas veces como sea necesario.
Esta configuraci´on, como todas las que tuvieran m´ultiples Cores, requerir´ıa revisar su c´odigo para evitar posibles condiciones de carrera y fallos de sincronizaci´on entre ellos.
Figura 3.4: Conexi´on de control con escalabilidad 1:1
Aunque el 1:1 es una opci´on v´alida, una ca´ıda de cualquiera de los dos componentes dejar´ıa al conjunto inoperativo. Esto es especialmente relevante porque los componentes tienen caracter´ısticas muy dispares: el wrapper est´a pensado para ser un componente ligero y r´apido que se limita a hacer, a grandes rasgos, una traducci´on de protocolo; el Selector Core es, comparativamente, lento y pesado, ya que implementa todo el proceso de decisi´on y supervisi´on de servidores.
Esto nos lleva a elegir un modelo N:M (demostrado en la Figura 3.5), donde un n´umero de wrappers llaman a un conjunto de Cores. Esto nos provee la mayor flexi-
bilidad, teniendo ambos servicios replicados y pudiendo escalarlos independientemente.
Esto requerir´ıa un c´odigo de balanceo de carga y comprobaci´on de salud en el c´odigo del wrapper.
Figura 3.5: Conexi´on de control con escalabilidad N:M
3.4 Estudio de conexiones
Una vez decidido que m´ultiples Control wrappers se podr´an conectar a m´ultiples Selector Cores, cabe preguntarse c´omo determinar´a cada Control wrapper a qu´e Core conectarse.
La forma m´as sencilla de lograr una distribuci´on equitativa es que se dirija cada petici´on a un Core elegido aleatoriamente. Esto evita tener que sincronizar estos accesos entre wrappers.
Para obtener la lista de Cores disponibles, se han considerado varios sistemas. Por ejemplo, mirando c´omo han resuelto problemas similares otras herramientas conocidas (por ejemplo, Kubernetes [18]), se pens´o en distribuirlas mediante DNS. Sin embargo, el sistema actualmente no cuenta con un servidor DNS preparado para esa funci´on, as´ı que se ha buscado otra alternativa.
El sistema s´ı cuenta con una base de datos, que recoge, por ejemplo, datos de au- tenticaci´on y autorizaci´on para la API, por lo que se ha decidido que la opci´on m´as pr´actica es listar en esta base de datos los servidores de Selector Cores instalados. Esta soluci´on tambi´en es bastante flexible, ya que cualquier sistema que se resuelva a una IP es compatible (por ejemplo, si se migra a contenedores y es necesario poner un nombre DNS no ser´ıa necesario ning´un cambio).
La lista debe ser actualizada cada vez que se a˜nada o retire un servidor, pero no necesariamente cuando un servidor falle, ya que el c´odigo del Control wrapper elegir´a un servidor alternativo si no consigue conectarse al primero.
4 Alcance del proyecto
Para aplicar la soluci´on propuesta, podemos identificar los siguientes puntos a tratar:
• Adaptaci´on del sistema actual (“Core”) para soportar varias instancias en paralelo sin que ello derive en errores de funcionamiento.
• Desarrollo de wrappers que permita una transici´on progresiva de los protocolos ori- ginales de control y gesti´on a sendas APIs REST que garanticen la compatibilidad.
• Establecer, coordinadamente con la infraestructura actual de la red, sistemas que permitan que el resto de los componentes puedan aprovechar la nueva escalabilidad y resiliencia del servicio.
• Desarrollo de un portal de gesti´on y mantenimiento que utilice las nuevas APIs para facilitar las operaciones rutinarias de mantenimiento.
• Pruebas de rendimiento y capacidad del sistema, antes y despu´es, para evaluar las posibles necesidades de escalabilidad en el futuro.
Cabe destacar tambi´en qu´e objetivos se han dejado expl´ıcitamente fuera del ´ambito del proyecto:
• La actualizaci´on del protocolo de ejecuci´on se ha descartado por los motivos ex- presados en la discusi´on de soluciones (a modo de recordatorio: este protocolo difiere mucho de los otros dos que van a ser actualizados, y requiere caracter´ısticas distintas, meritorias de un an´alisis que no tiene cabida en este proyecto) y, salvo que durante los desarrollos enumerados anteriormente se descubra que es necesario para cumplir alguno de los objetivos, no ser´a modificado.
• Modificaci´on o reestructuraci´on del c´odigo existente, m´as all´a de lo m´ınimo reque- rido para las acciones estipuladas anteriormente, en concreto:
– Las ediciones m´ınimas para asegurar la escalabilidad s´ı entran en el ´ambito del proyecto.
– El c´odigo de red de las conexiones de control y gesti´on puede ser alterado si el desarrollo de los wrappers correspondientes implican cambios en el sistema de conexi´on o en el propio protocolo.
4.1 Riesgos asociados
Con el plan anterior, se han identificado algunos riesgos, por lo que como veremos en la siguiente secci´on, se ha elegido una metodolog´ıa de trabajo que permita detectarlos y gestionarlos de forma ´agil y con un impacto reducido en la planificaci´on.
Primero, los protocolos actuales podr´ıan presentar problemas al intentar portarlos a APIs REST, o podr´ıan requerir cambios en el protocolo original. En este caso, se
desarrollar´ıa una funcionalidad en el wrapper que permitiera mantener la compatibilidad con el sistema actual y permitir que ambas formas de comunicaci´on coexistieran hasta que se completara la transici´on.
Despu´es, se prev´e que durante el estudio de escalabilidad se descubran algunas alter- nativas que podr´ıan resultar en una complejidad excesiva, pero tambi´en se espera que se redacten opciones m´as simples que permitan satisfacer los objetivos del proyecto, aunque no sea de la forma ´optima. Por lo tanto, si se decidiera que la alternativa propuesta en el estudio no se puede implementar en el tiempo dispuesto, se optar´ıa por alguna de las opciones m´as simples.
Otro riesgo deriva de la inexperiencia del desarrollador en aplicaciones web, lo que podr´ıa dificultar la implementaci´on. Si se diera el caso, se deber´ıa consultar a los res- ponsables del proyecto y otros equipos con m´as experiencia en este ´ambito, que reco- mendar´ıan la documentaci´on adicional correspondiente.
Tambi´en se podr´ıan descubrir condiciones imprevistas que comprometieran la esca- labilidad del Selector Core. Como la redundancia y la alta disponibilidad son puntos cr´ıticos de este proyecto, en ese caso habr´ıa que destinar m´as tiempo y, de ser necesa- rio, replantear el funcionamiento de las partes de c´odigo afectadas para garantizar la escalabilidad.
Finalmente, teniendo en cuenta la situaci´on actual, el proyecto puede verse afectado por imprevistos ajenos a ´este (por ejemplo, problemas m´edicos), hecho que se tendr´a en cuenta para la planificaci´on del proyecto.
4.2 Metodolog´ıa seguida
Aunque el problema a resolver puede parecer cerrado, en realidad debe mantenerse abier- to a modificaciones urgentes e imprevistos. En el caso de los protocolos, por ejemplo, se pueden a˜nadir nuevas funcionalidades al conjunto de la plataforma de cloud gaming que requieran modificaciones en su comportamiento, y habr´ıa que acomodarlas tambi´en en el nuevo protocolo. En el caso del portal de gesti´on, sus funciones podr´ıan verse modi- ficadas derivado de particularidades en la implementaci´on de otros puntos, o se podr´ıan solicitar m´as funciones derivadas de cambios en componentes externos al Selector.
Por tanto, se ha elegido usar una metodolog´ıa Scrum [19], un tipo de metodolog´ıa de desarrollo ´agil, que divide las tareas en sprints, pensada para poder adaptarse a posibles cambios. Scrum asume que no se puede conocer el proyecto completamente de antemano, ya que los requisitos pueden cambiar, hecho que es especialmente relevante en este proyecto, ya que mientras se desarrolle, el Selector deber´a seguir respondiendo a las necesidades del negocio. Adem´as, esta metodolog´ıa ya se usa con ´exito en otros equipos de desarrollo de la empresa, lo que facilita su adopci´on.
Se seguir´a un esquema similar al que se usa en otros proyectos internos: unos sprints bisemanales, con una reuni´on de planificaci´on al principio y una de seguimiento a me- diados. El director del trabajo asistir´a a estas reuniones y el ponente ´unicamente a las de planificaci´on, de forma que se establece un seguimiento y validaci´on semanales o bisemanales para garantizar el desarrollo del proyecto seg´un lo esperado.
Para facilitar el seguimiento, se utilizar´a un repositorio de c´odigo compartido con las partes interesadas, as´ı como una lista de tareas pendientes que permita verificar el cumplimiento de los plazos previstos en la planificaci´on. En concreto, se utilizar´a el servicio GitLab usado en los dem´as proyectos de la empresa.
4.3 Metodolog´ıa de validaci´on
Para comprobar que el desarrollo funciona, se desplegar´a primero en las infraestructuras de desarrollo existentes para comprobar su compatibilidad con el estado actual sin per- turbar las operaciones habituales del producto, y se ejecutar´an pruebas para certificar que funciona seg´un las nuevas especificaciones, prob´andolo con las operaciones habitua- les que se esperan del programa, as´ı como aquellos casos de error que se prevean. Si estas pruebas son exitosas, se ir´a incorporando en el workflow habitual de desarrollo in- terno de la empresa. Adem´as, el c´odigo incluir´a pruebas automatizadas para garantizar su buen funcionamiento y evitar que futuras actualizaciones introduzcan errores en el c´odigo producido.
5 Planificaci´ on
5.1 Recursos del proyecto
Todas las tareas definidas en la siguiente secci´on compartir´an algunos recursos b´asicos, que se enumeran a continuaci´on:
1. Desarrollador del proyecto
2. Acceso al GitLab interno para seguimiento de progreso y cambios en el c´odigo 3. Microsoft Teams
4. Entorno de desarrollo correspondiente al lenguaje escogido 5. Editor de c´odigo (Visual Studio Code [20])
6. Navegador web (Microsoft Edge [21]) 7. Ordenador (Lenovo Legion Y520 [22]) 8. Lugar de trabajo
9. Acceso a internet 10. Electricidad
Adem´as, las tareas de Dise˜no, Desarrollo y Pruebas necesitar´an recursos materiales adicionales, y las de Seguimiento necesitar´an recursos humanos m´as all´a del desarrolla- dor. Estos recursos ser´an descritos en las secciones correspondientes.
5.2 Descripci´on de las tareas
El proyecto comienza el 23 de febrero, y se estima su finalizaci´on el 8 de junio, para ser presentado en el turno de junio de 2021 (del 28 de junio al 2 de julio).
A continuaci´on, se detallan las tareas necesarias para realizar el proyecto, as´ı como una estimaci´on del tiempo para cada una, los recursos que requerir´an y, de tenerlas, las dependencias entre ellas.
5.2.1 Gesti´on del proyecto
Tareas relacionadas con la gesti´on del proyecto. Deber´an ser realizadas secuencialmente (G1 < G2 < G3 < G4).
G1 Definici´on En esta tarea se define el proyecto y su ´ambito.
Tiempo estimado: 24,5 horas
Recursos: Desarrollador, GitLab, Teams, navegador web, ordenador, lugar de tra- bajo, acceso a internet, electricidad.
G2 Planificaci´on En esta tarea se realiza una planificaci´on temporal y desglose de tareas a realizar.
Tiempo estimado: 8,25 horas Dependencias: G2
Recursos: Desarrollador, GitLab, Teams, navegador web, ordenador, lugar de tra- bajo, acceso a internet, electricidad
G3 Presupuesto En esta tarea se calcula el presupuesto del proyecto y se realiza un an´alisis de sostenibilidad.
Tiempo estimado: 9,25 horas Dependencias: G3
Recursos: Desarrollador, GitLab, Teams, navegador web, ordenador, lugar de tra- bajo, acceso a internet, electricidad.
G4 Entrega En esta tarea se crea de un documento que recoja lo estudiado en los documentos anteriores.
Tiempo estimado: 18,25 horas Dependencias: G3
Recursos: Desarrollador, GitLab, Teams, navegador web, ordenador, lugar de tra- bajo, acceso a internet, electricidad.
5.2.2 An´alisis
Estudios de alternativas y posibilidades a realizar antes del desarrollo de software. Todas dependen de la definici´on del proyecto (G1).
A1 Estudio de frameworks En esta tarea se analizan lenguajes y librer´ıas para el desarrollo de los wrappers.
Tiempo estimado: 8 horas
Dependencias: G1
Recursos: Desarrollador, GitLab, Teams, entornos de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
A2 Estudio de alternativas para el portal de gesti´on En esta tarea se estudian posibles dise˜nos y frameworks para su desarrollo.
Tiempo estimado: 8 horas Dependencias: G1
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
A3 Estudio de escalabilidad En esta tarea se ponderan las distintas posibilidades para escalar horizontalmente el sistema seg´un sus componentes y c´omo se relacionan entre ellos.
Tiempo estimado: 16 horas Dependencias: G1
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
A4 Estudio del c´odigo actual En esta tarea se estudia el c´odigo actual del sistema en busca de posibles problemas que impidan ejecuciones concurrentes del software.
Tiempo estimado: 24 horas Dependencias: G1
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
A5 Documentaci´on de los protocolos existentes En esta tarea se documentan los protocolos actuales, bas´andose en documentaci´on existente y en el c´odigo de los servicios que los usan.
Tiempo estimado: 16 horas
Dependencias: G1
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
A6 An´alisis de conexiones En esta tarea se eval´uan de las posibilidades para imple- mentar la arquitectura elegida en el estudio de escalabilidad (A3), tanto en las conexiones internas como en las externas.
Tiempo estimado: 16 horas Dependencias: A3
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
A7 Evaluaci´on del rendimiento actual En esta tarea se mide el rendimiento actual, para permitir comparar c´omo se ha visto afectado por el proyecto.
Tiempo estimado: 8 horas Dependencias: G1
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
5.2.3 Dise˜no
Presentaci´on de propuestas de dise˜no de las API a los usuarios internos encargados del mantenimiento de los sistemas que deber´an consumirlas. Este dise˜no estar´a basado en las acciones y campos de los protocolos actuales (A5).
Para documentar estas propuestas se ha utilizado la herramienta gratuita Swagger [23].
D1 Dise˜no de la API de control En esta tarea se realiza un dise˜no de la API de control con las operaciones que se deben implementar, la seguridad a utilizar, y su interacci´on con los otros componentes del sistema.
Tiempo estimado: 8 horas Dependencias: A5
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad
Recursos adicionales: Swagger.
D2 Dise˜no de la API de gesti´on En esta tarea se dise˜na la API de gesti´on con las operaciones que se deben implementar, la seguridad a utilizar, y su interacci´on con los otros componentes del sistema.
Tiempo estimado: 8 horas Dependencias: A5
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
Recursos adicionales: Swagger.
5.2.4 Desarrollo
Creaci´on del c´odigo que implemente lo dise˜nado en apartados anteriores.
Como recursos adicionales, los wrappers necesitar´an Swagger para tomar como refe- rencia el dise˜no realizado en las tareas anteriores, y un cliente HTTP para probar las llamadas mientras se desarrollan. Para esta tarea se ha escogido Postman [24], por su integraci´on con Swagger y su funci´on para documentar las llamadas disponibles.
P1 Actualizaci´on del c´odigo actual En esta tarea se modifica el c´odigo del Selector Core para resolver los problemas detectados en el an´alisis previo (A4) y adaptarlo a las nuevas conexiones (A6), si es necesario.
Tiempo estimado: 40 horas Dependencias: A4, A6
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
P2 Desarrollo del Control wrapper En esta tarea se programa el Control wrapper con las herramientas correspondientes (A1), implementando las conexiones adecuadas (A6) y la API acordada (D1).
Tiempo estimado: 40 horas
Dependencias: A1, A6, D1
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
Recursos adicionales: Cliente HTTP.
P3 Desarrollo del Management wrapper En esta tarea se programa el Manage- ment wrapper con las herramientas correspondientes (A1), implementando las conexiones adecuadas (A6) y la API acordada (D2).
Tiempo estimado: 40 horas Dependencias: A1, A6, D2
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
Recursos adicionales: Cliente HTTP.
P4 Desarrollo del portal de gesti´on En esta tarea se programa el Management portal, habiendo estudiado sus alternativas (A2).
Tiempo estimado: 80 horas Dependencias: A2
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
5.2.5 Pruebas
Para garantizar un correcto funcionamiento, se realizar´an pruebas del sistema desarrolla- do. Como recurso adicional, requerir´an de un servidor de pruebas en la red de la empresa, que permita comprobar que el software se podr´a integrar correctamente. Adem´as, se se- guir´a usando el cliente HTTP usado durante el desarrollo.
T1 Prueba de la API de control En esta tarea se valida la API de control despu´es de su desarrollo (P2), para comprobar que cumple lo especificado en el dise˜no.
Tiempo estimado: 8 horas
Dependencias: P2
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
Recursos adicionales: Servidor de pruebas, cliente HTTP.
T2 Prueba de la API de gesti´on En esta tarea se valida la API de gesti´on despu´es de su desarrollo (P3), para comprobar que cumple lo especificado en el dise˜no.
Tiempo estimado: 8 horas Dependencias: P3
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
Recursos adicionales: Servidor de pruebas, cliente HTTP.
T3 Prueba del portal de gesti´on En esta tarea se prueba el portal de gesti´on despu´es de su desarrollo (P4), para comprobar que cumple los requisitos exigidos.
Tiempo estimado: 8 horas Dependencias: P4
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
Recursos adicionales: Servidor de pruebas.
T4 Prueba del sistema completo En esta tarea se comprueba todo el sistema desarrollado, incluyendo su rendimiento, despu´es de las pruebas de cada componente (T1, T2, T3).
Tiempo estimado: 16 horas Dependencias: T1, T2, T3
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
Recursos adicionales: Servidor de pruebas, cliente HTTP.
T5 Prueba de compatibilidad En esta tarea se verifica que el sistema desarrollado es compatible con el sistema actual, garantizando as´ı una correcta integraci´on. Se asume que las funciones desarrolladas funcionan (T4).
Tiempo estimado: 8 horas Dependencias: T4
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
Recursos adicionales: Servidor de pruebas.
5.2.6 Seguimiento
En este apartado se incluyen las reuniones semanales de seguimiento con el director y bisemanales de planificaci´on con el ponente, teniendo en cuenta que el director tambi´en asistir´a a las de planificaci´on. Ambos se deben tener en cuenta para calcular los recursos necesarios para las tareas correspondientes.
S1 Seguimiento 8 reuniones de seguimiento con el director, con una duraci´on esti- mada de 1 hora cada una.
Tiempo estimado: 8 horas
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
Recursos adicionales: director del proyecto (Javier de Muniategui).
S2 Planificaci´on 8 reuniones de planificaci´on con el ponente y el director, con una duraci´on estimada de 1 hora y 30 minutos cada una.
Tiempo estimado: 12 horas Dependencias: T4
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
Recursos adicionales: ponente del proyecto (Xavi Verd´u), director del proyecto (Javier de Muniategui).
5.2.7 Documentaci´on
M1 Memoria En esta tarea se redacta el documento de la memoria final del proyecto, habi´endolo terminado.
Tiempo estimado: 40 horas Dependencias: G4, T5
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
M2 Defensa En esta tarea se prepara la defensa p´ublica del proyecto, despu´es de redactar la memoria (M1).
Tiempo estimado: 56 horas Dependencias: M1
Recursos: Desarrollador, GitLab, Teams, entorno de desarrollo, editor de c´odigo, navegador web, ordenador, lugar de trabajo, acceso a internet, electricidad.
5.3 Resumen
Se adjunta la Tabla 5.1, con las horas dedicadas a cada tarea y a cada bloque, donde se puede observar que la mayor parte del tiempo se dedicar´a a la parte de desarrollo, seguida del bloque de an´alisis previo, que ayudar´a a preparar el desarrollo de forma que se minimicen los riesgos de cambios imprevistos.
Tabla 5.1: Resumen de horas
5.4 Gantt
En la Figura 5.1, se incluye la planificaci´on Gantt, teniendo en cuenta las dependencias entre tareas, la prioridad de cada tarea y el uso de recursos, intentando minimizar el tiempo que se usan recursos adicionales (como en la fase de Pruebas). Vemos que los estudios de escalabilidad (A3), conexiones (A6) y frameworks (A1) son cr´ıticos. Des- pu´es se observa que el proyecto se divide en tres ramas que pueden avanzar de forma independiente (API de control, API de gesti´on y portal de gesti´on) hasta la fase de pruebas, donde para realizar las pruebas de sistema debe haber acabado el desarrollo en las tres partes. Esto hace que si el trabajo de una de las tres ramas quedara bloqueado (por ejemplo, a la espera de una decisi´on sobre la coordinaci´on entre equipos), se pueda seguir trabajando en otras partes del proyecto.
Figura 5.1: Diagrama Gantt
5.5 Valoraci´on de alternativas y plan de acci´on
Seg´un lo explicado en el apartado de Riesgos asociados al proyecto, se han tenido en cuenta posibles alternativas y se ha elaborado un plan de acci´on teniendo en cuenta los riesgos mencionados.
Durante la documentaci´on de los protocolos (A5) o el estudio de las conexiones (A6) se podr´ıan descubrir problemas u optar por soluciones que requirieran una adaptaci´on del protocolo. Para este caso, se ha dotado de m´as tiempo del m´ınimo necesario (unas 4 horas por tarea) a las tareas de desarrollo de los wrappers (P2 i P3), que permitir´ıan ampliar el c´odigo para garantizar la compatibilidad con los protocolos existentes. Tambi´en se ha hecho lo mismo con la tarea de actualizaci´on del c´odigo actual (P1), que incluir´ıa los cambios necesarios en el Selector actual.
Los posibles problemas con las conexiones entre los componentes internos se contem- plar´an en el estudio de escalabilidad (A3) y de conexiones (A6), en los que se incluir´a un plan alternativo a desarrollar si se decidiera que es demasiado costoso implementar la
soluci´on propuesta. Este plan alternativo (estimado en 8 horas m´as) estar´ıa contemplado en los tiempos de las tareas de desarrollo correspondientes (P).
Los problemas de escalabilidad que se descubran en el c´odigo actual durante su an´ali- sis (A4) se deber´an resolver en la actualizaci´on del c´odigo (P1). Como resulta dif´ıcil saber a priori qu´e problemas se encontrar´an en el c´odigo, si es que hay alguno, se ha decidido sobredimensionar la tarea (aproximadamente 16 horas m´as de la previsi´on b´asica, ya incluidas en la planificaci´on de este documento) para tener margen de actuaci´on si se descubrieran m´as de los previstos. Este tiempo se dedicar´ıa a revisar la documentaci´on actual del proyecto. Si no fuera suficiente, se considerar´a acudir a otros empleados de la empresa que trabajaron anteriormente con ese c´odigo.
El desarrollo del portal de gesti´on tambi´en cuenta con una estimaci´on del tiempo pesimista, debido a la poca familiaridad del autor con este ´ambito de desarrollo. Si necesitara m´as documentaci´on al respecto, se revisar´ıa la documentaci´on asociada a los proyectos correspondientes y se consultar´ıan otros proyectos similares. Tambi´en se podr´ıa leer un libro que tratase el tema afectado, como por ejemplo [25], que a˜nadir´ıa 42,00 € al presupuesto. 12 horas del tiempo previsto para el desarrollo del portal est´an destinadas a cubrir este riesgo.
Finalmente, se han sobredimensionado ligeramente las dem´as tareas para permitir la finalizaci´on del proyecto pese a riesgos imprevistos derivados de la situaci´on actual (por ejemplo, m´edicos).
6 Implementaci´ on
6.1 Actualizaciones en el Selector Core
Como se ha comentado en secciones anteriores, las actuaciones en el Selector Core se han limitado a las m´ınimas necesarias para que se puedan ejecutar varias instancias en paralelo. Para ello, se han revisado varias peticiones, en general relacionadas con la conexi´on al Execution Backend, que podr´ıan escribir informaci´on menos actualizada que la que ya exist´ıa en la base de datos, y se ha corregido este problema. Tambi´en se ha revisado el sistema de locks para comprobar que su comportamiento es correcto entre procesos, incluso si se ejecutan en m´aquinas distintas.
6.2 Control wrapper
6.2.1 Dise˜no
Para el dise˜no de la API se parti´o de los campos del protocolo original.
Como ´este s´olo ten´ıa una acci´on (lanzar juegos), se ha creado un ´unico endpoint, que recibe los campos en formato JSON y realiza una traducci´on directa, previa verificaci´on de que pueden ser codificados correctamente. Tambi´en se ha aprovechado para eliminar campos deprecated, usando autom´aticamente valores coherentes con el comportamiento esperado.
Tambi´en se ha a˜nadido un m´etodo de autenticaci´on mediante API key, compatible con los clientes HTTP est´andar.
Finalmente, seg´un lo decidido en la Secci´on 3.4, se ha implementado un mecanismo de balanceo de carga entre los servidores Core disponibles mediante la elecci´on aleatoria a partir de una lista obtenida de la base de datos. Se ha implementado un mecanismo basado en timeouts para decidir si un servidor est´a vivo; si no lo est´a, se elegir´a otro aleatoriamente, hasta un l´ımite configurable de reintentos.
6.2.2 Desarrollo
Antes de comenzar el desarrollo del Control wrapper, se ha tenido que escoger un lenguaje y un framework en el que basarlo. Adem´as, para facilitar su desarrollo y mantenimiento, estas elecciones se aplicar´an tambi´en al Management wrapper. Por lo tanto, en esta elecci´on se han considerado factores como:
• Facilidad para implementar una API REST, as´ı como llamar a otras APIs.
• Capacidad de utilizar el protocolo existente del Selector (TCP y tipos de datos en C).
• Interoperabilidad con el c´odigo actual del Selector Core (C++), que puede ser necesaria durante el desarrollo de este proyecto o en ampliaciones futuras.
• Facilidad para conectarse con bases de datos SQL.
• Capacidad de gestionar conexiones simult´aneas con el m´ınimo uso de recursos Antes de introducir nuevas tecnolog´ıas, con el coste de mantenimiento que ello supo- ne, se han considerado las que ya est´an en uso en otros proyectos internos, especialmente C++, Go, JavaScript (con Node.js en el lado del servidor) y Python.
C++ ha sido descartado ya que cuenta con escasas herramientas estables para la creaci´on de servicios HTTP. Entre los restantes, se ha optado por Go, que presenta una mayor facilidad de despliegue y (subjetivamente) de desarrollo y mantenimiento, a la vez que cumple de forma bastante satisfactoria con todos los requisitos. Go tambi´en est´a siendo utilizado en proyectos internos relacionados.
De entre los frameworks disponibles (Gorilla, Martini, Gin. . . ), todos presentan ca- racter´ısticas similares, ya que utilizan en gran medida las caracter´ısticas que proporciona el lenguaje en su librer´ıa est´andar. Se ha elegido Gin por ser el que presenta, al parecer del autor, una interfaz de programaci´on m´as sencilla.
Una vez realizada esta decisi´on, se ha procedido a programar el Control wrapper seg´un lo especificado en el dise˜no.
6.3 Management wrapper
6.3.1 Dise˜no
Para el dise˜no de la API tambi´en se parti´o del protocolo de gesti´on original, pero se vi´o que las opciones disponibles eran insuficientes para el mantenimiento habitual, por lo que se contact´o con los equipos responsables de estas operaciones y se recogieron las necesidades que se acabaron plasmando en el dise˜no. Tambi´en hubo que a˜nadir acciones para administrar el Control wrapper, incluyendo las claves API y la lista de servidores Core, mencionados anteriormente.
Todas estas acciones obligaron a prescindir del concepto original en el que el Manage- ment wrapper se limitaba a transcodificar las peticiones al protocolo de gesti´on original, ya que solo implementa una peque˜na fracci´on de las acciones necesarias, 3 frente a las 17 especificadas. Adem´as, una de las 3 que s´ı implementa el protocolo original no se ha a˜nadido a la nueva API porque ya no se corresponde con una necesidad del sistema. Por lo tanto, el programa trabaja directamente sobre la base de datos, sin usar el Selector Core como intermediario.
En cuanto al sistema de autenticaci´on, adem´as de las API keys, se usan tokens de tipo JWT [26], m´as f´aciles de usar para un cliente web, que se expiden a partir de un usuario y contrase˜na. Tambi´en se ha creado un sistema de autorizaci´on mediante permisos, permitiendo restringir las acciones disponibles seg´un el usuario.
6.3.2 Desarrollo
Durante las primeras fases del desarrollo, se plante´o que otros proyectos internos, uno de los cuales ten´ıa un proyecto pendiente para un sistema de gesti´on similar, se integraran en el Management wrapper del Selector, convirti´endolo en un portal centralizado para las tareas t´ecnicas del sistema.
Para ello, se ha revisado el dise˜no de la API, renombrando las rutas para asegurar que las rutas de los distintos componentes no produzcan colisiones. A nivel de c´odigo, se ha hecho m´as gen´erico el c´odigo y se han a˜nadido interfaces que faciliten la ampliaci´on e integraci´on de otros subsistemas.
6.4 Portal de gesti´on
El desarrollo del portal de gesti´on ha comenzado despu´es de la finalizaci´on del wrapper de gesti´on, por lo que el cambio de requisitos no ha afectado a esta parte del proyecto, y la interfaz y el c´odigo han podido ser dise˜nados con las ampliaciones a otros componentes en mente.
Para desarrollar el portal de gesti´on, se han considerado varias opciones:
La primera es ampliar el Management wrapper con una secci´on que exponga los datos y procese las acciones en formatos admitidos por los navegadores.
La segunda se basa en la anterior, pero separa el servicio de renderizado en otro programa, que se ejecuta de forma independiente y se comunica con el Management wrapper mediante su API.
Finalmente, se piensa en crear una Single-Page Application4, similar en concepto a la alternativa anterior, pero es el navegador del usuario el que obtiene y modifica los datos desde la API, y construye la interfaz mediante un script JavaScript, en vez de ser el servidor el que la genera. [27]
Se ha desechado la segunda opci´on, que supone un mayor coste de mantenimiento que el resto de las alternativas, sin presentar ventajas significativas.
Entre las restantes, se ha elegido la creaci´on de una Single-Page Application, ya que desacopla el desarrollo del Management wrapper y de su interfaz, y garantiza el buen funcionamiento de la API (ya que, en caso de tener errores, ser´an visibles en la interfaz).
Adem´as, otros proyectos de la empresa utilizan tambi´en esta t´ecnica, con el framework React, lo que permite aprovechar las habilidades adquiridas por el equipo para este nuevo proyecto.
En la Figura 6.1 se muestra una captura de la web en el entorno de pruebas. En concreto, se observa la lista de servidores del Selector Core. Aqu´ı, por ejemplo, se ve que se pueden deshabilitar servidores temporalmente (por ejemplo, durante operaciones de mantenimiento). La vista de edici´on de esta lista se expone en la figura Figura 6.1.
Todas las capturas corresponden a un entorno de pruebas.
4Una aplicaci´on de una ´unica p´agina (SPA) es una p´agina web que, del lado del servidor, es un solo documento. Si lo hay, el enrutado y las decisiones sobre qu´e p´agina mostrar se toman con c´odigo en el lado del cliente, en lugar del servidor.
Figura 6.1: Lista de servidores del Selector Core en el portal de administraci´on En la Figura 6.3 se puede ver que algunos recursos, como las claves API, tienen m´as detalles disponibles. En este caso, los permisos asociados a la clave. Actualmente el ´unico permiso disponible es el de lanzar juegos, aunque se prev´e que se a˜nadan m´as seg´un evolucionen las necesidades del sistema.
El c´odigo se basa en un sistema de plantillas que, partiendo de unas suposiciones sobre los recursos (por ejemplo, que se mostrar´a una lista en formato tabla, o que puede tener varias acciones comunes) permite a˜nadir f´acilmente nuevos recursos y nuevos sistemas.
Este sistema fue dise˜nado tambi´en pensando en la integraci´on de otros componentes en la aplicaci´on.
Figura 6.2: Edici´on de la lista de servidores Core en el portal de administraci´on
Figura 6.3: Detalles acerca de una clave API en el portal de administraci´on
7 Validaci´ on
Para comprobar que el desarrollo cumple con los objetivos sin introducir errores en el proceso, se ha evaluado su funcionamiento de las distintas partes del proyecto, tanto por separado como en conjunto.
7.1 Cambios en el Selector Core
Pese a que los cambios en el Selector Core han sido m´ınimos, se trata de secciones de c´odigo que pueden introducir sutiles errores que acaben causando un comportamiento incorrecto en el sistema, por lo que estos han sido probados intensivamente: primero se han probado en un servidor de pruebas, para no afectar al funcionamiento de los dem´as equipos de la empresa, y se ha comprobado el funcionamiento conforme a la especificaci´on del sistema.
Todas las pruebas se han realizado con un ´unico Selector Core, ya que el despliegue en producci´on se hace actualmente con esta configuraci´on. Cambiarlo requerir´ıa modificar el proceso de despliegue y otros componentes del sistema, por lo que la verificaci´on de una configuraci´on con varios Cores se dejar´a como trabajo futuro hasta que se den las condiciones necesarias para probarla.
Cuando ha cumplido con lo esperado, ha reemplazado a la versi´on anterior del Se- lector Core en el entorno de desarrollo, donde se ha probado con procesos de trabajo internos, similares a los que se encuentran en producci´on.
Finalmente, tras un mes en desarrollo sin incidencias, se ha actualizado tambi´en en producci´on.
7.2 Wrapper de control
El wrapper de control ha sido el componente que ha recibido mayor escrutinio, ya que gestiona las peticiones de los clientes, por lo que un error o una ca´ıda en este programa podr´ıa interrumpir el servicio de la aplicaci´on, impidiendo a los usuarios lanzar nuevos juegos.
La primera comprobaci´on consiste en pruebas unitarias autom´aticas que cubren la mayor parte del c´odigo. Estas pruebas utilizan el framework incluido en Go (go test / paquete testing [28]), y se ejecutan cada vez que se crea un commit en el repositorio de c´odigo, permitiendo detectar fallos r´apidamente.
Una vez finalizado el desarrollo, el wrapper se ha ejecutado en un entorno de prue- bas, similar al entorno de producci´on. Aqu´ı se ha verificado su correcta integraci´on con los dem´as componentes, as´ı como su compatibilidad con los sistemas que no han sido actualizados al nuevo protocolo.
Tambi´en se ha comprobado manualmente utilizando la herramienta Postman, apro- vechando para crear una colecci´on con las llamadas disponibles para documentarlas y facilitar su uso durante el desarrollo, pruebas o intervenciones ocasionales.
