Análisis de la infraestructura del componente de evaluación de un MOOC

An´alisis de la infraestructura del componente de evaluaci´on de un MOOC Trabajo de fin de grado en Ingenier´ıa Inform´atica Enero del 2016 Autor/a: Mario Cavero Cahis Director/a: Llu´ıs Talavera M´endez, Antoni Soto i Riera Ponente: Marc Alier i Soler ii Resumen Las TIC han favorecido la aparici´on, en los ´ultimos a˜nos, de cursos online con un gran n´umero de participantes (MOOC) que responden a las necesidades de formaci´on de la sociedad actual. Esta masividad replantea la manera de presentar los materiales y c´omo evaluar a los estudiantes sin que estos denoten una falta de feedback en el proceso de aprendizaje, inexistente en los cursos presenciales. En este proyecto se presenta una plataforma de evaluaci´on de programas python basada en doctest y se utiliza para moldear un MOOC de programaci´on python instalado en una plataforma Moodle con permisos limitados, a trav´es de LTI. Se analiza el rendimiento de esta plataforma a trav´es de pruebas de carga y se proponen optimizaciones software para mejorarlo. Resum Les TIC han afavorit, als ultims anys, l’aparici´o de cursos online amb un gran nombre de participants (MOOC) que responen a les necessitats de formaci´o de la societat actual. Aquesta massivitat replanteja la manera de presentar els materials i com avaluar als estudiants sense que aquests denotin una falta de feedback en el proc`es d’aprenentatge, inexistent als cursos presencials. En aquest projecte es presenta una plataforma d’avaluaci´o de programes python basada en doctest y s’utilitza per a modelar un MOOC de programaci´o python instal·lat a una plataforma Moodle amb permisos limitats, mitjan¸cant LTI. S’analitza el rendiment d’aquesta plataforma a trav´es de proves de c`arrega i es proposen optimitzacions software per a millorar-la-hi. Abstract ICT has played an important role within the last years and it has brought new type of online courses that manage a huge number of students, the so-called MOOCs, that respond to the training needs’ of society. This massivity forces the educators to rethink the way they present materials and evaluate students, not to cause them a lack of feedback, compared to in-class courses. This project presents an assessment platform to evaluate python programs based on doctest, and uses it to complete a MOOC of python programming installed on a Moodle system with limited permissions, by using LTI. The performance of this system is proven by load testing it and some software modifications are proposed in order to improve this performance. iii ´ Indice general Lista de Tablas v Lista de Figuras vii 1 Introducci´on 1 1.1 Contexto ..................................... 1 1.2 Alcance del proyecto ............................... 2 1.2.1 Requisitos ................................. 2 1.2.2 Objetivos ................................. 2 2 Estado del Arte 4 2.1 ¿Qu´e es un MOOC? ............................... 4 2.2 Plataformas MOOC ............................... 5 2.3 Evaluaci´on de estudiantes en un MOOC .................... 6 2.4 LTI ......................................... 8 2.5 Selecci´on de la herramienta de correcci´on ................... 8 3 Adecuaci´on de las herramientas 11 3.1 Preparaci´on del entorno ............................. 11 3.2 Adecuaci´on VPL ................................. 11 3.3 Modificaci´on y extensi´on de doctest ...................... 12 4 Pruebas de carga 15 4.1 Materiales y m´etodos ............................... 15 4.1.1 Material .................................. 15 4.1.2 Metodolog´ıa ................................ 17 4.2 An´alisis de resultados .............................. 18 4.2.1 Primera fase ............................... 18 4.2.2 Segunda fase ............................... 21 iv 5 Instalaci´on del sistema 27 5.1 Seguridad ..................................... 30 6 Gesti´on del proyecto 31 6.1 Metodolog´ıa y rigor ............................... 31 6.1.1 M´etodo de trabajo ............................ 31 6.1.2 Partes implicadas ............................. 31 6.1.3 Seguimiento del proyecto ........................ 31 6.1.4 Validaci´on del proyecto ......................... 32 6.2 Planificaci´on temporal .............................. 32 6.2.1 Descripci´on de las tareas ......................... 33 6.2.2 Recursos .................................. 33 6.2.3 An´alisis riesgos .............................. 34 6.2.4 Valoraci´on de alternativas ........................ 35 6.3 Estimaci´on de costes ............................... 35 6.3.1 Costes recursos humanos ........................ 35 6.3.2 Costes recursos materiales ........................ 36 6.3.3 Costes imprevistos ............................ 38 6.3.4 Coste total ................................ 39 6.3.5 Control de gesti´on ............................ 39 6.4 Resultado planificaci´on .............................. 39 6.5 Sostenibilidad ................................... 40 6.5.1 Viabilidad econ´omica .......................... 40 6.5.2 Evaluaci´on del impacto ......................... 40 6.6 Leyes y regulaciones ............................... 42 7 Conclusi´on 43 7.1 Trabajo futuro .................................. 43 7.2 Integraci´on de los conocimientos ........................ 44 Bibliograf´ıa 45 A Manual de doctest mod 46 v ´ Indice de cuadros 2.1 Listado de jueces y otros sistemas de evaluaci´on. ............... 9 4.1 Porcentajes de uso de memoria m´aximo y de uso de CPU medio de entre todas las pruebas de 300 y 600 segundos con una relaci´on de 2 nuevos usuarios por segundo. .............................. 21 6.1 Planificaci´on de las tareas del proyecto ..................... 32 6.2 Estimaci´on salarial de los roles del proyecto. .................. 35 6.3 Estimaci´on desglosada del coste de los recursos humanos del proyecto. . . . 36 6.4 Estimaci´on del coste de los recursos humanos del proyecto. ......... 36 6.5 Estimaci´on de los costes hardware del proyecto. ................ 37 6.6 Material software utilizado. ........................... 37 6.7 Estimaci´on de los costes indirectos del proyecto. ................ 38 6.8 Dedicaci´on extra al proyecto fruto de desviaciones temporales. ....... 38 6.9 Coste extra de los recursos humanos fruto de desviaciones temporales. . . . 38 6.10 Estimaci´on de los costes totales del proyecto. ................. 39 6.11 Matriz de sostenibilidad. ............................. 42 vi ´ Indice de figuras 2.1 Ejemplo de ´arbol de sintaxis y el c´odigo que representa. ........... 8 2.2 Esquema de funcionamiento de LTI. ...................... 8 3.1 Evaluaci´on de un programa con doctest. .................... 12 3.2 Nueva directiva de pesos en doctest mod. ................... 13 4.1 Esquema de paso de mensajes entre los diferentes componentes web. . . . . 16 4.2 Diagrama de peticiones generadas por n usuarios en una ventana de tiempo t. 18 4.3 Tiempos de respuesta medio por usuario y env´ıo para un n´umero de usuarios y una configuraci´on determinadas, durante una ventana de 60 segundos. . . 19 4.4 Tiempos de respuesta medio por usuario y env´ıo para un n´umero de usuarios y una configuraci´on determinadas, durante una ventana de 300 segundos. . 20 4.5 Tiempos de respuesta medio por usuario y env´ıo para un n´umero de usuarios y una configuraci´on determinadas, durante una ventana de 300 segundos. . 22 4.6 Porcentaje de uso de CPU, memoria y del espacio de intercambio (swap) de disco, durante una prueba con 600 usuarios en una ventana de 300 segundos, utilizando la optimizaci´on PHP3. ........................ 23 4.7 N´umero de lecturas a disco por fallo en el InnoDB buffer durante una prueba de 300 segundos y 600 usuarios, con la configuraci´on SQL3 y SQL2. . . . . 23 4.8 N´umero de Kilobytes le´ıdos a por el proceso mysql durante una prueba de 300 segundos con 600 usuarios y la configuraci´on SQL3. ........... 24 4.9 N´umero de Kilobytes le´ıdos a por el proceso mysql durante una prueba de 300 segundos con 600 usuarios y la configuraci´on SQL2. ........... 24 4.10 Tiempos de respuesta medio por env´ıo y usuario para 1200 usuarios y la configuraci´on predeterminada, durante 600 segundos. ............. 25 4.11 Tiempos de respuesta medio por env´ıo y usuario para 1200 usuarios y la configuraci´on NGX2, durante 600 segundos. .................. 26 vii 5.1 Esquema de sistema centralizado, con un solo nodo. ............. 28 5.2 Esquema de sistema distribu´ıdo, con varios nodos. .............. 29 6.1 Diagrama de Gantt correspondiente a la planificaci´on del proyecto. ..... 33 1 Cap´ıtulo 1 Introducci´on Las nuevas tecnolog´ıas han favorecido la creaci´on de nuevas aplicaciones y su puesta en marcha en distintos ´ambitos de la sociedad: informarse a trav´es de peri´odicos digitales, realizar la compra a golpe de click o realizar una videollamada a la otra punta del mundo soy hoy en d´ıa tareas cotidianas para la mayor´ıa de habitantes en un pa´ıs avanzado. La educaci´on tambi´en se ha adaptado a estos cambios. En las universidades resultar´ıa extra˜no no disponer, hoy en d´ıa, de una plataforma que ayude a los alumnos a planificar el curso: horarios, avisos del profesor/a de una asignatura, material did´actico; en el mundo laboral, cada vez m´as empresas dedicadas a la formaci´on de personal y servicios p´ublicos a la formaci´on de parados desarrollan su actividad de manera online. La mayor´ıa de estas actividades no sustituyen formas de ense˜nanza tradicional, sin´o que las complementan: los estudiantes y trabajadores deben seguir asistiendo a clases presenciales. En los ´ultimos a˜nos ha aparecido el t´ermino MOOC (Massive Online Open Course) para referirse a cursos dirigidos a un amplio n´umero de usuarios (masivo) y cuyo ´unico requisito para acceder es disponer de acceso a internet (online y abierto). 1.1 Contexto Este trabajo se enmarca dentro de un proyecto de desarrollo de un MOOC de programaci´on de python. El gran n´umero de estudiantes en un MOOC hace dif´ıcil cualquier forma de evaluaci´on manual de los estudiantes. Es por ello que el proyecto precisa una plataforma, basada en doctest, que permita evaluar autom´aticamente programas escritos en python. Esta plataforma, adem´as, se debe poder invocar desde un Moodle con administraci´on 2 limitada, a trav´es de LTI. En este proyecto se buscan las herramientas para poder crear esta plataforma y se modifica el m´odulo doctest para mejorar la calidad de la evaluaci´on, minimizando as´ı la falta de feedback que causa la ausencia de un corrector humano hacia el estudiante. Se analiza esta plataforma y se le aplican modificaciones para mejorar el rendimiento; se estima la carga m´axima de usuarios que puede soportar para un escenario determinado. Por ´ultimo, se instala y se prepara el sistema para su puesta en marcha. 1.2 Alcance del proyecto 1.2.1 Requisitos Este proyecto debe respetar los siguientes requisitos: •La plataforma de correcci´on debe admitir LTI para poder interactuar no s´olo con el propio curso en Moodle donde ser´a alojado, sin´o con cualquier otra plataforma que soporte LTI. •La plataforma de correcci´on debe ser capaz de evaluar programas escritos en el lenguaje de programaci´on python a trav´es de la herramienta doctest. •Todo el software utilizado debe ser open source. Asimismo, todo el material ´util que pueda ser utilizado en un futuro por terceros se publicar´a bajo una licencia de software libre. 1.2.2 Objetivos Este proyecto tiene como objetivos principales: •Dise˜nar e implementar una plataforma para llevar a cabo de forma autom´atica las tareas de evaluaci´on y calificaci´on de los estudiantes de un MOOC de introducci´on a la programaci´on. M´as concretamente: –Estudiar software disponible para la correcci´on autom´atica a trav´es de LTI y seleccionar el m´as adecuado, o crearlo si fuera necesario. –Modificar el m´odulo doctest para mejorar su uso como herramienta de evaluaci´on. –Analizar el rendimiento de la plataforma de correcci´on y proponer mejoras a nivel de software; definir la infraestructura hardware necesaria para que la plataforma funcione correctamente. 9 minada y la salida correcta (previamente definida). Si estas salidas difieren, el ejercicio se marca como incorrecto. Pueden existir algunas variaciones como considerar un programa correcto si no sobrepasa un tiempo de CPU fijado o comparar varias salidas con la ejecuci´on del mismo programa ante varias entradas. En cualquier caso, nos encontramos con unos resultados que poco ayudan al estudiante a detectar y corregir sus fallos de manera aut´onoma. Los jueces no se han creado para ense˜nar un lenguaje de programaci´on sin´o permitir que alumnos ya iniciados o que est´an aprendiendo por otros medios practiquen. De hecho, los jueces acostumbran a ser plataformas ad-hoc, adaptadas a requisitos muy espec´ıficos y poco orientados al auto-aprendizaje. Mart (2013) muestra algunos ejemplos de jueces; es obligado mencionar la plataforma Jutge.org, desarrollada por Jordi Petit y Salvador Roura, utilizada en algunos concursos y asignaturas de programaci´on de la FIB. Julio C. Caiza (2013) muestra algunos m´odulos open source que implementan la funcionalidad de los jueces y que pueden ser integrados en LMS. De esta manera se combinan las funcionalidades de ambos y se supera el problema anterior (cuadro 2.1). Las caracter´ısticas y requisitos del proyecto determinan: Primero Se dispone de acceso limitado al MOOC al que queremos dotar de la herramienta de correcci´on de programas; esto obliga a utilizar una herramienta que soporte LTI. Segundo Esta herramienta debe soportar la correcci´on de programas escritos en el lenguaje de programaci´on python. Tercero Esta herramienta debe estar basada en el m´odulo doctest; ser´a necesario, por tanto, seleccionar una herramienta que permita integrar este m´odulo. Cuarto La herramienta debe estar cubierta por una licencia de software libre. Cuadro 2.1: Listado de jueces y otros sistemas de evaluaci´on. Herramienta Licencia C´odigo p´ublico Correcci´on programas python Soporte LTI Integraci´on m´odulo doctest CourseMarker ? no no no no Marmoset apache 2.0 s´ı si no potencial WebCat GNU GPL s´ı potencial no potencial VPL GNU GPL s´ı s´ı s´ı (Moodle) potencial Grading Tool ? no s´ı no potencial Autograder ? s´ı s´ı1s´ı potencial Jutge ? no s´ı no potencial 10 A partir del an´alisis anterior hemos seleccionado VPL (Virtual Programming Lab) porque satisface los requisitos anteriores. Esta herramienta, constantemente actualizada, es un plugin de Moodle que permite la gesti´on de actividades de programaci´on y que soporta la correcci´on de programas python. Entre otros, permite crear entregas de ejercicios de programaci´on; corregir estas entregas autom´aticamente (despu´es de que los estudiantes env´ıen los ficheros) y detectar copias entre los alumnos. Moodle por defecto ya permite a˜nadir (invocar) actividades LTI-compliant a (desde) un curso. Esto quiere decir que para poder utilizar nuestros ejercicios de programaci´on VPL desde el MOOC externo (en el que disponemos de permisos limitados) debemos conseguir que estas actividades VPL sean tambi´en LTI-compliant. Precisamente ser un plugin de Moodle hace que la plataforma VPL pueda ser LTIcompliant sin tener que extenderla utilizando la especificaci´on LTI gracias al m´odulo LTI Provider, un plugin de Moodle que convierte cualquier tipo de actividad o recurso en una aplicaci´on LTI-compliant. Por tanto, una vez instalado junto al m´odulo VPL en un Moodle que controlamos al 100 %, el MOOC externo ya podr´a invocar nuestras actividades VPL. Notemos que el hecho de utilizar el est´andar LTI permite invocar una aplicaci´on determinada desde cualquier tipo de LMS, no s´olo Moodle. 1Utiliza Skulpt, una implementaci´on de python en javascript. 11 Cap´ıtulo 3 Adecuaci´on de las herramientas 3.1 Preparaci´on del entorno La selecci´on de VPL como herramienta de correcci´on nos lleva a utilizar Moodle. Necesitaremos, por tanto, un entorno web que nos permita alojar este LMS. Para ello optamos por el grupo de software LEMP que hace referencia a una instalaci´on sobre un SO Linux con los paquetes nginx y PHP y MySQL como gestor de bases de datos, ambos open source. Despu´es de instalar y configurar m´ınimamente Moodle, el plugin VPL y el plugin LTI Provider ya tenemos un entorno web capaz de servir actividades de programaci´on VPL a trav´es de LTI. 3.2 Adecuaci´on VPL VPL consta de dos grandes partes: •El propio plugin de Moodle que ´unicamente gestiona datos. No ejecuta ning´un programa entregado en actividades VPL sin´o que se comunica con un servidor de ejecuci´on para que lo haga por ´el. •Un servidor de ejecuci´on encargado de compilar, ejecutar y devolver el resultado de los programas enviados por una actividad VPL. Esta separaci´on responde a motivos de seguridad; para minimizar el efecto de cualquier intento de ataque se separa la parte que gestiona los datos con la parte encargada de ejecutar unos programas cuyo contenido es desconocido. Si hubiera alguna vulnerabilidad en el servidor de ejecuci´on no se comprometer´ıa el entorno Moodle. 12 T´ecnicamente, VPL utiliza peque˜nos scripts que dictan los pasos a seguir para corregir programas en cada uno de los lenguajes que soporta. Estos scripts se env´ıan, junto al c´odigo del programa, al servidor de ejecuci´on, donde se procesan. Para cumplir con los requisitos del proyecto, debemos modificar este comportamiento por defecto de VPL y utilizar el m´odulo doctest para corregir los programas python. La flexibilidad de VPL permite definir nuestro propio script de correcci´on, para una actividad determinada. Si no se define ninguno, se utilizan los scripts por defecto. No ser´a necesario, por tanto, modificar la implementaci´on de VPL para integrar el m´odulo doctest; si ser´a necesario instalar este m´odulo en el servidor de ejecuci´on. 3.3 Modificaci´on y extensi´on de doctest Doctest es un m´odulo de python para realizar pruebas unitarias sobre programas escritos en el mismo lenguaje; este m´odulo extrae el c´odigo interactivo definido dentro del mismo programa o en un archivo de texto, lo ejecuta y compara el output con el esperado, previamente definido. El hecho de trabajar con docstrings permite utilizar cualquier lenguaje de marcado (LaTeX, reStructuredText...), pudiendo acompa˜nar los resultados con informaci´on ´util y bien estructurada que aumente el feedback hacia el estudiante que ha entregado el programa. Figura 3.1: Evaluaci´on de un programa con doctest. # ejemplo_doctest.py def suma(a,b): """ >>> suma(0,0) 0 """ return a+b $ python -m doctest ejemplo_doctest.py -v Trying: suma(0,0) Expecting: 0 ok El funcionamiento de VPL requiere que el mecanismo de correcci´on proponga una nota, que es la que se asignar´a al alumno en esa actividad. Si nuestro mecanismo de correcci´on es doctest, debemos adaptarlo primero para que sea capaz de generar esta nota. 13 En este caso, imitaremos el comportamiento por defecto de VPL; la nota vendr´a determinada por el n´umero de pruebas (tambi´en llamadas ejemplos) cuya ejecuci´on difiera o coincida con la salida definida como correcta en el doctest. Corregir no es suficiente Hemos visto que un buen proceso de evaluaci´on consiste en dar el mayor feedback posible al estudiante, no s´olo corregirle. Que el MOOC en el que se enmarca este proyecto est´e basado en el auto-aprendizaje obliga a adaptar nuestro mecanismo de correcci´on para que de la mayor retroalimentaci´on posible. En ese sentido, se expanden las funcionalidades de doctest a˜nadiendo dos nuevas directivas (flags): peso, que permite ponderar el peso de las pruebas dentro de un mismo doctest; bloque, que permite agrupar un conjunto de pruebas y determinar su peso dentro del doctest. La primera modificaci´on no s´olo ayudar´a a los estudiantes a saber qu´e nota tiene sin´o a los propios profesores del curso: podr´an decidir cu´anto cuenta cada ejemplo dentro de un doctest, aumentando la flexibilidad de la plataforma. El segundo cambio ayudar´a sobretodo a los alumnos a concentrarse y asimilar los errores de un grupo determinado de pruebas en lugar de distraerse con el resto de resultados del doctest. Este cambio va acompa˜nado de peque˜nos cambios en el formato de salida de los resultados de doctest; entre otros, se a˜naden cabeceras al inicio de cada bloque y se muestra un cuadro al final con la nota del ejercicio, desglosada por bloques. Para acabar, esta nueva versi´on del m´odulo, llamada doctest mod, se instala en el servidor de ejecuci´on de VPL. Figura 3.2: Nueva directiva de pesos en doctest mod. # ejemplo_doctest_mod.py def suma(a,b): """ >>> suma(0,0) # doctest_mod: +PES=0.75 0 >>> suma(-1,-1) # doctest_mod: +PES=0.25 -2 """ return a+b 14 Estrategia de dise˜no El m´etodo testfile en el m´odulo doctest original es la encargada de procesar los archivos doctest. Este m´etodo utiliza la clase DocTestParser para extraer las directivas de cada ejemplo del archivo doctest y DocTestRunner para ejecutar y verificarlos estos ejemplos. Una vez recorridas todas las pruebas, testfile devuelve informaci´on del n´umero de pruebas totales y cu´antas han fallado. Para implementar las funcionalidades de doctest mod, la estrategia utilizada ha sido: •Modificar la clase DocTestParser, que se encarga de buscar todas las directivas del fichero doctest, para que reconozca los nuevos flags peso ybloque. •Modificar la clase DocTestRunner, para que anote la relaci´on de ejemplos que han fallado. •Crear un nuevo m´etodo obtePesosDoctest que recorre todas las pruebas de un doctest, extrae el valor de las directivas a˜nadidas y genera una estructura que contiene, entre otros, informaci´on sobre el bloque (peso, n´umero de ejemplos) y los pesos de los ejemplos que contiene. •Crear un nuevo m´etodo calculaNotaFinal que, dado el resultado de la ejecuci´on de un doctest (clase DocTestParser) y una relaci´on de los ejemplos con sus respectivos pesos, calcula una nota. •Modificar el m´etodo testfile para que utilice obtePesosDoctest, ejecute los ejemplos del doctest a trav´es de la clase modificada DocTestRunner, ejecute la funci´on calculaNotaFinal y devuelva el n´umero de pruebas totales, falladas y la nota correspondiente. 15 Cap´ıtulo 4 Pruebas de carga 4.1 Materiales y m´etodos 4.1.1 Material Las pruebas se realizan sobre una m´aquina virtual. La configuraci´on de este equipo son 2 CPU cores @ 3.00 Ghz, 1024 MB de memoria RAM, 10 GB de disco y un enlace de 100 Mbps. El SO utilizado durante las pruebas es Debian Jessie, el servidor web Nginx 1.6, PHP 5.6 y el sistema de gesti´on de bases de datos MariaDB 14.14. La versi´on de Moodle es la 2.9. La figura 4.1 muestra, a grandes rasgos, c´omo interaccionan entre s´ı los componentes web que alojan nuestra plataforma Moodle. 16 Figura 4.1: Esquema de paso de mensajes entre los diferentes componentes web. Disponemos de un servidor web escuchando sobre el puerto 80 (HTTP). Cuando llega una nueva conexi´on, un proceso (worker) de nginx responde con el contenido del archivo solicitado. Cuando la petici´on es una p´agina din´amica (archivo PHP), nginx solicita a PHPFPM (PHP FastCGI Process Manager) realizar los c´alculos necesarios antes de responder al cliente. PHP-FPM mantiene activos un conjunto (pool) de procesos encargados de procesar estas peticiones PHP, interaccionando si cabe con la base de datos y finalmente respondiendo al worker nginx solicitante. Se utiliza Apache JMeter como generador de pruebas de carga; iotop y dstat como herramientas de monitorizaje de recursos. Lanzar las pruebas y recoger manualmente los resultados cuando estas hayan terminado tiene sus riesgos y problemas: •Por una parte, el factor humano puede llevar a errores y a no respetar la misma metodolog´ıa para cada una de las pruebas. Por ejemplo, lanzar una prueba antes que los componentes encargados de recabar los datos (m´etricas) que despu´es analizaremos no est´en listos. •Por otro lado, dada la cantidad de experimentos a realizar, el tiempo que se dedicar´ıa a esta fase del proyecto resultar´ıa inasumible y no se garantizar´ıa cumplir los plazos del proyecto. Para evitar estos problemas, se decide crear una herramienta que automatize el proceso 17 de lanzamiento de pruebas de carga. Esta herramienta, escrita en python y con el apoyo de la librer´ıa Fabric, permite aplicar configuraciones sobre una m´aquina, sincronizar el inicio de las pruebas de carga con el monitoraje de recursos en esta y, en acabar, obtener los resultados, etiquetarlos y almacenarlos. El formato de los resultados que devuelven las herramientas de monitorizaje no son interpretables por un humano y deben procesarse para poder ser analizados. Este proceso se repetir´a para cada una de las pruebas. Para no repetirse durante esta fase de an´alisis de los resultados se crea un entorno web, basado en el framework de python Pyramid, que permite acceder a los resultados, debidamente presentados en formato utilizando la librer´ıa Matplotlib, para su posterior an´alisis. 4.1.2 Metodolog´ıa Nuestra plataforma Moodle act´ua de contenedor de ejercicios del MOOC de programaci´on python. Por tanto, la ´unica parte en la que analizaremos el rendimiento ser´an las actividades VPL. M´as concretamente, nos interesa saber cu´antos usuarios accediendo e interactuando con este tipo de actividades puede soportar la plataforma dando unos tiempos de respuesta aceptables. El mayor impacto en rendimiento sobre una aplicaci´on VPL se produce cuando se realiza el env´ıo de ficheros. Por ello, el plan de pruebas consiste en un n´umero determinado de usuarios (n) que durante un tiempo determinado (ventana de tiempo, t) acceden a una misma actividad VPL y realizan el env´ıo de 3 ficheros python, generados pseudoaleatoriamente. Estos usuarios se lanzan uniformemente en el tiempo (figura 4.2) y no repiten el ciclo de peticiones cuando acaban. Si durante una prueba de carga hay una o m´as peticiones que no se satisfacen, la prueba se interrumpte y queda marcada como fallida. 18 Figura 4.2: Diagrama de peticiones generadas por n usuarios en una ventana de tiempo t. Las pruebas se realizan en ventanas de tiempo de 1, 5 y 10 minutos. Para cada ventana de tiempo se realizan 10 pruebas. En cada prueba se aumenta progresivamente el n´umero de usuarios, tal y como determina la f´ormula de la figura 4.1. Notemos que la relaci´on de usuarios lanzados por unidad de tiempo en la prueba i-´esima se mantiene independientemente de la ventana de tiempo. Consideraremos un tiempo de respuesta aceptable si es menor de 2 segundos, tal y como sugiere Fiona Fui-Hoon (2004). Aplic´andolo a este escenario, ser´an consideradas aceptables aquellas pruebas que consigan un tiempo de respuesta medio por usuario y env´ıo de 2 segundos. usuariosi(t) = t·i 2(1 ≤i≤10) (4.1) Mediante estas pruebas de carga se prueban diferentes combinaciones de configuraciones de los paquetes de software involucrados en la plataforma Moodle y por tanto los que m´as condicionan el rendimiento de la plataforma: nginx, encargado de gestionar las conexiones de los clientes; PHP, encargado de procesas las p´aginas o scripts de Moodle y MySQL, la base de datos del sistema. 4.2 An´alisis de resultados 4.2.1 Primera fase Necesitamos obtener un baseline para determinar si optimizacines futuras en la configuraci´on de los paquetes resultar´a en una mejora de rendimiento. En esta primera fase, realizamos pruebas de carga aplicando optimizaciones gen´ericas sobre nginx, PHP y MySQL. 25 •La combinaci´on NGX2+PHP2+SQL2 se ajusta a los niveles de respuesta de NGX2+PHP3. Analizado todo lo anterior (inclu´ıdos los resultados la primera fase), m´as que una mejora de rendimiento lo que hace la configuraci´on NGX2 es convertir el componente nginx en un lastre. El hecho de que un worker de nginx atienda a m´as de un cliente a la vez no est´a dando buenos resultados en nuestro escenario. Al recibir un flujo constante de clientes en el tiempo los procesos nginx pueden saturarse con un n´umero de peticiones que no pueden servir al mismo ritmo que llegan. Si el tiempo de resoluci´on de las peticiones PHP (de las que se encarga PHP-FPM) fuera menor, estos procesos de nginx tendr´ıan la capacidad de soportar este flujo y por tanto los tiempos de respuesta mejorar´ıan. El problema tambi´en se resolver´ıa si el flujo fuera menor; observemos este caso en las figuras 4.10 y4.11. La primera usa la configuraci´on PRED, mientras que la segunda aplica la optimizaci´on NGX2. Las pruebas se dan en la misma ventana de tiempo y el mismo n´umero de usuarios. La variabilidad en los tiempos de respuesta disminuye notablemente (sd = 2.7 a 1.49). Notemos tambi´en que el tiempo de respuesta disminuye. Figura 4.10: Tiempos de respuesta medio por env´ıo y usuario para 1200 usuarios y la configuraci´on predeterminada, durante 600 segundos. 26 Figura 4.11: Tiempos de respuesta medio por env´ıo y usuario para 1200 usuarios y la configuraci´on NGX2, durante 600 segundos. 27 Cap´ıtulo 5 Instalaci´on del sistema Creamos una m´aquina virtual con las mismas caracter´ısticas y la misma versi´on de software utilizado durante el desarrollo del sistema y posteriores pruebas de carga. Necesitamos una direcci´on IP fija asignada a la m´aquina, que resuelva a un nombre de dominio a trav´es del servidor DNS autoritativo correspondiente. Supongamos asignada una direcci´on IP 147.83.92.13 y el nombre ’taronger.cs.upc.edu’ asignado a ´esta. Seguidamente configuramos los paquetes de software Nginx, PHP, MariaDB/MySQL y realizamos la instalaci´on de Moodle. Instalamos y configuramos el plugin VPL, el plugin LTI Provider y preparamos el servidor de ejecuci´on y correcci´on de los programas (que forma parte del paquete VPL). La figura 5.1 muestra una aproximaci´on del esquema de la red y la distribuci´on de los equipos. 28 Figura 5.1: Esquema de sistema centralizado, con un solo nodo. Las pruebas de carga se generaron en una m´aquina que formaba parte de la misma red que la m´aquina donde estaba Moodle. No olvidemos que en el MOOC que planteamos acceder´an usuarios de Internet y por tanto el tiempo real medio de respuesta por env´ıo se ver´a incrementado por esta latencia. En caso de ser necesario absorber una mayor carga de usuarios podr´ıa optarse por aumentar el n´umero de m´aquinas virtuales con las mismas caracter´ısticas. Una topolog´ıa v´alida para conseguirlo se muestra en la figura 5.2. 29 Figura 5.2: Esquema de sistema distribu´ıdo, con varios nodos. Esta configuraci´on contar´ıa con un reverse HTTP proxy que se encargar´ıa de interactuar con los clientes y atender sus peticiones. Estas peticiones las encaminar´ıa por una de las n m´aquinas virtuales, que son las que realmente atender´ıan la petici´on, har´ıan los c´alculos necesarios y responder´ıan al proxy, que trasladar´ıa la respuesta al cliente. Notemos que ahora la instalaci´on de Moodle est´a distribuida; estas n m´aquinas deben ser capaces de atender las consultas que anteriormente (figura 5.1) atend´ıa el ´unico nodo virtual; este nodo ten´ıa la base de datos y utilizaba su propio sistema de ficheros para dar cabida a los archivos que maneja Moodle (por defecto, directorio moodledata). Por tanto ser´a necesario disponer de un sistema de bases de datos y un sistema de ficheros compartido por todas las n m´aquinas, que garantice que todos los nodos dispongan de los datos que sus semejantes hayan realizado con anterioridad. Tambi´en es necesario compartir las sesiones de los usuarios entre los diferentes nodos; si las peticiones de un cliente las encamina el proxy a un nodo A y m´as tarde a un nodo B, ´este ´ultimo debe poder recuperar el estado de la sesi´on tal y como la dej´o A. Esto puede conseguirse de varias formas: •Trasladando la gesti´on de sesiones de Moodle a la base de datos. •Almacen´andolas en un directorio compartido (sistema de ficheros compartido). 30 •Utilizando una instancia de memcached. Notar que dificilmente esta topolog´ıa multiplicar´ıa el rendimiento de la primera por las n m´aquinas virtuales. 5.1 Seguridad Seguridad A continuaci´on se analizan elementos externos que pueden afectar la disponibilidad del servicio y c´omo podr´ıan resolverse, as´ı como algunas consideraciones de seguridad. •Red el´ectrica: el sistema se conecta a tomas de corriente de un SAI (sistema alimentaci´on ininterrumpida). Este sistema corrige todas las deficiencias de la red el´ectrica. Ante bajadas o subidas de tensi´on o cortes de corriente el sistema se mantendr´ıa funcionando, en el ´ultimo caso durante un tiempo determinado. •Fallo en el nodo: notemos que la figura 5.1 procesa todas las peticiones a trav´es de un s´olo nodo. Si en este nodo se produce un fallo hardware, el servicio quedar´a interrumpido. Esto podr´ıa solventarse a gracias a la figura del proxy (ver figura 5.2): ante un nodo que no respondiera a una petici´on, ´esta podr´ıa enviarse a cualquiera de los n-1 nodos restantes. •Control de accesos: por defecto, el servidor de ejecuci´on VPL acepta peticiones de cualquier m´aquina. Es deseable (y configurable) limitarlo para que s´olo atienda a los nodos de nuestro sistema. De la misma manera, en el segundo escenario, los nodos virtuales deber´ıan aceptar peticiones HTTP(S) ´unicamente del proxy. 31 Cap´ıtulo 6 Gesti´on del proyecto 6.1 Metodolog´ıa y rigor 6.1.1 M´etodo de trabajo La forma de trabajar se basa en la metodolog´ıa Scrum; cada semana se definen una serie de objetivos que deben estar listos para la siguiente. Dependiendo si los objetivos se han cumplido o no, se definen nuevos. 6.1.2 Partes implicadas En este proyecto participan directamente los siguientes actores: •Autor: encargado de resolver el problema formulado en el proyecto, alcanzando los objetivos y respetando los requisitos de ´este. •Directores: encargados de monitorizar el proyecto y asesorar al autor en todo aquello relativo a las competencias t´ecnicas. •Estudiantes: futuros alumnos del MOOC de programaci´on planteado en el proyecto. 6.1.3 Seguimiento del proyecto Se realizan reuniones semanales con los directores del proyecto, donde se plantean problemas, se repasan los avances y se definen los siguientes pasos a seguir. Los directores pueden consultar el estado del proyecto en cualquier momento a trav´es de un repositorio git al que tienen acceso y donde el autor introduce todos los cambios que va efectuando. 32 6.1.4 Validaci´on del proyecto Se considera que el proyecto es v´alido si lo es el objetivo de ´este, dividido en tres partes. Los directores son los encargados de determinar si se cumplen o no cada una de estas partes: •En el caso de los dos primeros sub-objetivos, se muestra un MOOC, de prueba pero funcional, que cumple los requisitos del proyecto. •En el caso del tercer objetivo, se define un escenario sobre el cual realizar pruebas de rendimiento; se muestran las mejoras y qu´e cambios software se han adoptado para conseguirlo. •En el ´ultimo objetivo, se instala y se deja preparado el sistema en el escenario anterior. 6.2 Planificaci´on temporal Es necesario definir qu´e tareas van a realizarse durante el proyecto, estimar su duraci´on y ubicarlas en el tiempo (cuadro 6.1). Esta planificaci´on permite tener m´as margen de maniobra frente a posibles imprevistos. En las reuniones semanales con los directores, que no se incluyen en el listado de tareas, se controla que los plazos acordados se cumplen. Cuadro 6.1: Planificaci´on de las tareas del proyecto ID Tarea Duraci´on (horas) Inicio Final Precedida por 1B´usqueda de herramientas existentes 30 07/09/2015 11/09/2015 2Prueba y selecci´on de herramientas existentes 60 14/09/2015 25/09/2015 1 3Adecuaci´on de herramientas seleccionadas 90 28/09/2015 16/10/2015 2 4Pruebas de carga y optimizaci´on 150 19/10/2015 20/11/2015 3 5 Prueba piloto 66 23/11/2015 07/12/2015 4 6 Documentaci´on 72 08/12/2015 23/12/2015 5 Total 313 horas 107 horas El proyecto se inicia el 7 de septiembre del 2015 y est´a previsto que finalice el 23 de diciembre de 2015. La duraci´on estimada es de 468 horas de trabajo (repartidas en 3 meses y 16 d´ıas). 33 6.2.1 Descripci´on de las tareas Sigue una breve descripci´on de las diferentes tareas del proyecto: •B´usqueda de herramientas existentes: buscar herramientas que puedan servir para realizar un curso online de introducci´on a la programaci´on: recopilar MOOCs, LMS y sistemas de evaluaci´on ya creados. •Prueba y selecci´on de herramientas existentes: probar las herramientas encontradas y analizarlas; seleccionar aquellas que mejor se ajusten a los requisitos del proyecto. •Adecuaci´on de herramientas seleccionadas: agrupar e interconectar las herramientas de forma que resuelvan uno de los objetivos principales de este proyecto: disponer de una plataforma que permita crear un MOOC de introducci´on a la programaci´on; modificar estas herramientas, si cabe. •Pruebas de carga y optimizaci´on: crear un entorno espec´ıfico, de pruebas, a partir de herramientas propias y/o ya existentes, que permita analizar el rendimiento de esta plataforma. Adoptar cambios que mejoren su rendimiento. •Prueba piloto: crear un entorno de producci´on donde poder instalar la plataforma; utilizarla con usuarios reales y confirmar su correcto funcionamiento. •Documentaci´on: escribir la memoria del proyecto, as´ı como gu´ıas y manuales destinados a las partes interesadas de ´este. Todas las fases, excepto la primera, tienen como dependencia de precedencia su fase inmediatamente anterior. La figura 6.1 muestra las tareas mencionadas anteriormente en un diagrama de Gantt. Figura 6.1: Diagrama de Gantt correspondiente a la planificaci´on del proyecto. 6.2.2 Recursos Se necesitan los siguientes recursos para el proyecto: 34 •Recursos materiales: –Hardware: ∗Servidores web: m´aquinas f´ısicas sobre la que funcionar´a el MOOC. ∗Ordenador: para desarrollar el proyecto. –Software ∗Sistemas operativos: sistema base sobre el que funcionan todas las aplicaciones involucradas en el proyecto. ∗Sistema de control de versiones: programa que organiza todo el material del proyecto. ∗Generadores de carga: software que realiza pruebas de rendimiento. ∗Otros: frameworks para agilizar el desarrollo, herramientas para recopilar datos durante las pruebas de carga. –Consumo: (luz y) electricidad. •Recursos humanos: una persona que pueda dedicar al proyecto entre 30 y 35 horas semanales. 6.2.3 An´alisis riesgos Los principales escollos que pueden aparecer durante el desarrollo del proyecto y que podr´ıan producir desviaciones temporales en la planificaci´on del proyecto son: •La limitada experiencia del autor en cuanto a pruebas de carga: saber interpretar los resultados correctamente es esencial para no dar palos de ciego en el proyecto. Sumado a esto, debido al gran n´umero de pruebas de carga a las que puede someterse un MOOC, es vital descartar aquellas que no reproduzcan el comportamiento real de los usuarios de un curso de programaci´on online. Esto podr´ıa retrasar la fase 4 (Pruebas de carga y optimizaci´on). Dado que la propia metodolog´ıa de trabajo del proyecto ya controla este tipo de desviaciones, la etapa podr´ıa demorarse no m´as de 2 jornadas laborales. •Una dedicaci´on no-exclusiva: el autor compagina el desarrollo del proyecto con la asistencia a un curso universitario; las entregas y/o ex´amenes de este curso puede causar retrasos en la planificaci´on del proyecto. 41 Impacto social Como se acaba de ver, este proyecto no solo repercute econ´omicamente en las personas que lo utilizan, sino que adem´as les proporciona una fuente de conocimiento libre, accesible sin ning´un tipo de restricci´on. El factor social, por tanto, est´a altamente integrado en el proyecto. Sumado a esto, s´olo se adquieren para el proyecto aquellos componentes el proceso de fabricaci´on del cual haya sido respetuoso con sus trabajadores (condiciones dignas y sin ninguna forma de explotaci´on). Para acabar, todo el material utilizado en el documento (software, documentaci´on, manuales) ser´a liberado bajo licencia GNU GPL para que cualquier persona pueda usar, estudiar, copiar y modificar el software de manera libre. Impacto ambiental Uno de los puntos del proyecto es optimizar el rendimiento de la plataforma, esto es, conseguir la m´axima capacidad de procesado con el m´ınimo uso de recursos posible. Esta mejora se aplica durante la etapa de pruebas de carga y optimizaci´on. Tambi´en hay que destacar que los ordenadores y especialmente los procesadores actuales auto-regulan su velocidad y por tanto su consumo en base a la carga que soportan; cuanto m´as baja es, menos recursos consumen. Se priorizan dentro del proyecto los componentes de bajo consumo y aquellos cuyo proceso de fabricaci´on deje la menor huella ecol´ogica posible. Por ´ultimo, y no menos importante, se adoptan medidas que contribuyen a cuidar el medio ambiente: •Uso de papel reciclado; imprimir documentos s´olo cuando sea imprescindible. •Desconectar equipos inform´aticos cuando no se vayan a utilizar (apagar monitor del ordenador; poner el equipo en suspensi´on; apagarlo al finalizar la jornada laboral). •Abrir las ventanas para aclimatar el lugar de trabajo; si es necesario, encender el aire acondicionado con una temperatura entre 23 y 25 grados. 42 Cuadro 6.11: Matriz de sostenibilidad. ¿Sostenible? Econ´omica Social Ambiental Planificaci´on Viabilidad econ´omica Mejora en calidad de vida An´alisis de recursos Valoraci´on 7 6 8 Resultados Desviaci´on en previsi´on Impacto en entorno social Consumo de recursos Valoraci´on 9 6 8 Riesgos Cambios de escenario Da˜nos sociales Da˜nos ambientales Puntuaci´on 0 0 0 6.6 Leyes y regulaciones Se tienen en cuenta y se respetan todas las condiciones de uso de todo el software utilizado en este proyecto. Notar que todo el software no propio utilizado es libre (tabla 6). De igual manera, todo el material propio creado para este proyecto (software, documentaci´on, manuales) ser´a liberado bajo licencia GNU GPL para que cualquier persona pueda usar, estudiar, copiar y realizar modificaciones de manera libre. Dado que este proyecto no ha trabajado con datos personales, las regulaciones que pudieran aplicarse en materia de protecci´on de datos (Ley Org´anica 15/1999) quedan fuera del ´ambito del proyecto. 43 Cap´ıtulo 7 Conclusi´on En este proyecto se repasa la problem´atica de la masividad en los MOOC a la hora de corregir y evaluar a los estudiantes, m´as concretamente en cursos de programaci´on. Primeramente hemos buscado herramientas que permitieran crear una plataforma para evalaur y calificar de forma autom´atica a los estudiantes de un MOOC de programaci´on python, utilizando el m´odulo doctest, para minimizar la problem´atica del feedback. Se selecciona el m´odulo VPL, integrable facilmente en Moodle como plugin. Se ha analizado la posibilidad de poder incluir actividades VPL en plataformas externas en las que no se tienen permisos especiales, a trav´es de LTI. Esto es posible con el m´odulo LTI Provider de Moodle. Hemos mejorado doctest y lo hemos integrado en el m´odulo VPL como mecanismo de correcci´on de programas python. Seguidamente se buscan los l´ımites de esta plataforma; el flujo de usuarios capaz de atender con demoras no superiores a los 2 segundos. A trav´es de pruebas de carga consistentes en enviar archivos a una actividad VPL, se estresa la plataforma. Se aplican modificaciones en la configuraci´on del software que sirve esta plataforma y se analiza si suponen una mejora de rendimiento. Se determinan las configuraciones m´as apropiadas y las que m´as perjudican el rendimiento de la plataforma. Por ´ultimo, se instala y prepara el sistema en un ambiente de producci´on. Se propone un esquema de sistema distribuido para aumentar la capacidad multiplicando el n´umero de nodos. 7.1 Trabajo futuro Ser´ıa interesante explotar la red distribu´ıda planteada en la figura 5.2 y cuantificar la penalizaci´on al a˜nadir los elementos comunes (sistema de ficheros, bases de datos) respecto 44 al primer esquema. Tambi´en ser´ıa interesante analizar la conveniencia de extraer la funcionalidad de VPL y convertirla en una herramienta independiente de Moodle, LTI-compliant. Esta herramienta podr´ıa utilizarse para casos como el que nos ocupa, en que no estamos aprovechando las funcionalidades principales de Moodle (el curso se desarrolla en un LMS externo). 7.2 Integraci´on de los conocimientos Un gran n´umero de conocimientos adquiridos durante el grado se ponen en pr´actica en este proyecto. Son necesarios conocimientos de programaci´on para interpretar y escribir c´odigo; las asignaturas de programaci´on juegan, por tanto, un papel fundamental en este proyecto (etapas Adecuaci´on de herramientas seleccionadas y Pruebas de Carga y Optimizaci´on). En la etapa de Pruebas de Carga y Optimizaci´on se desarrolla una interfaz para poder analizar y comparar el resultado de los experimentos (etapa Pruebas de Carga y Optimizaci´on) con m´as facilidad. El an´alisis estad´ıstico es necesario para interpretar correctamente los resultados. No menos importante son los conocimientos adquiridos en asignaturas de arquitectura y sistemas operativos; conocer c´omo se organiza un computador es crucial para saber qu´e partes/procesos del sistema son susceptibles de ser mejorados y qu´e optimizaciones se deben aplicar en cada momento. Por ´ultimo, un conocimiento b´asico de redes y administraci´on de sistemas inform´aticos garantizar´a un correcto despliegue del sistema y un nivel de seguridad de los servicios que presta ´optimos. 45 Bibliograf´ıa A. Mani, D. Venkataramani, J. P. and Roura, S. (2014). Better feedback for educational online judges. 8 Debiasi L., A. S. (2013). Automated assessment in massive open online courses. 7 Fiona Fui-Hoon, N. (2004). A study on tolerable waiting time: how long are web users willing to wait? 18 Julio C. Caiza, J. M. D. A. (2013). Programming assignments automatic grading: Review of tools and implementations. 9 Mart, J. (2013). Juez autom´atico para la evaluaci´o de problemas de programaci´on en los primeros cursos de estudios de inform´atica. [Online; consultado el 12-Dic-2015]. 9 Moodle (2015). Moodle statistics. https://moodle.net/stats/. [Online; consultado el 20-Sep-2015]. 6 Siemens, G. (2012a). Moocs are really a platform. http://www.elearnspace.org/blog/ ?p=5659. [Online]. 4 Siemens, G. (2012b). What is the theory that underpins our moocs? http://www. elearnspace.org/blog/?p=5603. [Online]. 4 46 Ap´endice A Manual de doctest mod