Audience Response Systems (ARS) require a radio network, either its own or a public one. Private radio networks offer a number of advantages over Wi-Fi in lecture halls, above all stability and freedom from distractions. What they all have in common is the limited load capacity of the radio network and the ARS server due to the number of simultaneous users. The paper is aimed at ARS development teams as well as ARS operators. It shows strategies how an audience-response system can be provided reliably and in line with demand. Clickers are the first choice when it comes to ensuring that students do not use any online services other than the ARS service. If the purchase costs and logistics of the clickers are to be avoided, the mobile devices of the students must be used, "Bring Your Own Device", BYOD. If the use of the smartphone browser in the WiFi is to be restricted to the ARS service, a separate mobile Wi-Fi router is required. An ARS router has only limited scalability; the number of simultaneous users is limited to a few hundred for cost reasons. The paper outlines a deployment strategy for a highly scalable ARS. A micro-service architecture, implemented in software containers, and the orchestration of the containers in a cloud enable a high-performance and highly available audience response service.
Carsten Ullrich, Martin Wessner (Eds.): Proceedings of DeLFI and GMW Workshops 2017
Daniel Gerhardt1, Tom Käsler2, Hermann Sutter3 und Klaus Quibeldey-Cirkel4 1
ARS-Router oder „Bring Your Own Network“ Clicker und webbasierte Audience-Response-Systeme (ARS) bauen auf unterschiedlichen Netztechnologien auf. Während Clicker in einem eigenen Funknetz betrieben werden, nutzen webbasierte ARS das Hörsaal-WLAN. Wegen der Beschränkungen der verwendeten Netztechnologie und der mobilen Endgeräte – Handsender oder Smartphones – lassen sich die funktionalen und nicht-funktionalen Anforderungen an Audience-Response-Systeme nicht vollständig realisieren, siehe Tabelle 1. Die Strategie „Bring Your Own Device“ (BYOD) löst das Kosten-, Verteilungs- und Wartungsproblem der Clicker. Die Strategie „Bring Your Own Network“ (BYON) reduziert das Ablenkungsrisiko der browserbasierten ARS und bietet die Stabilität und Zuverlässigkeit eines Clicker-Funknetzes.
Bereitstellungskosten ≈ 10.000 € entfällt Verteilungsaufwand hoch (200 Clicker) entfällt (BYOD) Wartungsaufwand Batteriewechsel entfällt Netzstabilität hoch < 50 User pro AP stabil Ablenkungsrisiko nicht gegeben hoch (WhatsApp & Co) Anzahl Frageformate gering abhängig vom ARS Live-Rückkanal nein abhängig vom ARS Fragetext auf Endgerät nein abhängig vom ARS Datenschutz hoch (Server intern) kritisch (Server extern) ARS-Router ≈ 1.000 € entfällt (BYOD) gering (Updates) hoch gering abhängig vom ARS abhängig vom ARS abhängig vom ARS hoch (Server intern) Der Internetzugang im Hörsaal erweist sich oft als Nadelöhr, verstopft durch WhatsApp & Co. Das liegt nicht selten an der Installation von Access Points (AP), die eigentlich für Heimnetzwerke bestimmt und nur für etwa 50 gleichzeitige Verbindungen ausgelegt sind, es sei denn, die IT-Verantwortlichen wissen um diese Einschränkung und investieren in die Enterprise-Version der Access Points, die 500 bis 1.000 gleichzeitige Verbindungen ermöglichen, aber auch 10 bis 20 Mal teurer sind. Einsatz-Szenarien mit mehr als 200 gleichzeitigen Usern, deren Abstimmungen und Feedback in Echtzeit übertragen werden, sind die Ausnahme. Sie setzen die Optimierung der WLAN-Infrastruktur und ein Performance-Tuning des ARS-Servers durch IT-Experten voraus. Ein Erfolgsbeispiel für einen Hörsaal mit 800 Sitzplätzen zeigt Abb. 1. Hier wurden 7 Access Points mit einer Übertragungsrate von 450 Mbps (2,4 GHz) und 450 Mbps (5 GHz) installiert [Da17]. An der Justus-Liebig-Universität Gießen wurden in einer umfangreichen ARS-Vergleichs- und Einsatzstudie neben den technischen auch von Studierenden verursachten Störquellen vor Ort ausgemacht, die selbst ein leistungsfähiges Hörsaal-WLAN stark beeinträchtigen können: „Zu Problemen kann es im WLAN-Netz kommen, wenn beispielsweise mobile private WLAN-Hotspots eingerichtet werden. Dies kann unbeabsichtigt durch Unkenntnis der Studierenden passieren, kann aber auch absichtlich zur Störung des WLAN-Netzes beitragen. Ebenfalls können große Downloads zu Störungen führen. Sollten sich mehrere Studierende im Hörsaal befinden, die beispielsweise im Hintergrund unbemerkt große Updates herunterladen, kann dies die Abstimmung erheblich stören.“ [FB15, S. 23]
Abb. 2: ARS-Ausstattung mit eigenem Funknetz: WLAN-Router & Mini-PC vs. Clicker-Koffer Aufgrund mehrjähriger ARS-Erfahrungen [Qu17] in Hörsälen mit stark unterschiedlicher WLAN-Qualität wurde im Open-Source-Projekt ARSnova5 der THM eine DeploymentStrategie entwickelt, die die Vorteile eines eigenen Funknetzes mit den Vorteilen browserbasierter ARS vereint: der ARSnova-Router.6 Die im Abschnitt 2 beschriebenen Deployment-Verfahren werden auf einen mobilen Rechner mit WLAN-Router angewendet. Ein WLAN-Router für etwa 200 gleichzeitige Verbindungen, der mehrere Clicker-Koffer ersetzt, kostet ca. 250 €. Ein Mini-PC in Bierdeckelgröße, auf dem der ARS-Server installiert ist, kostet 50 € für einen Raspberry Pi oder 750 € für einen Intel® NUC (Abb. 2). Technisch einfache Systeme, z. B. die gamifizierte Quiz-App arsnova.click7, passen in den Arbeitsspeicher des Raspberry Pi. Komplexe Systeme mit einem Java-Backend und Datenbankserver wie arsnova.voting8 benötigen deutlich mehr RAM. In diesem Fall könnte der teurere Mini-PC auch als Präsentationsrechner fungieren und den Laptop der Lehrkraft ersetzen. arsnova.voting und die Ansteuerung des WLAN-Routers lassen sich 5 https://arsnova.thm.de/blog/ 6 https://github.com/thm-projects/arsnova-router/ 7 https://arsnova.click/ 8 https://arsnova.voting/ auch auf jedem handelsüblichen Laptop mit einem GNU/Linux-Betriebssystem oder in einer Docker-Umgebung installieren.
Ein Clicker-Funknetz oder ein ARS-Router sind deutlich besser vor unabsichtlichen und mutwilligen Störungen im Hörsaal gefeit, da nur der lokale Audience-Response-Dienst verfügbar ist. Die Ablenkung der Studierenden durch Nutzung vorlesungsfremder OnlineDienste ist weitgehend ausgeschlossen.9 Beide Funknetz-Implementierungen machen den ARS-Einsatz unabhängig von der Verfügbarkeit eines externen ARS-Dienstes. 2
Server-Deployment: Servlet- und Docker-Container Das ARSnova-System arsnova.voting besteht aus zwei obligatorischen Softwarekomponenten: dem Java-Backend und einem Webclient. Eine lose Kopplung zwischen den Komponenten wurde über die Definition einer REST-API erreicht. Zusätzlich zur REST-API wird das Websocket-Protokoll für Echtzeitkommunikation eingesetzt. Die öffentliche Schnittstelle ermöglicht die unabhängige Entwicklung weiterer Clients, beispielsweise des PowerPoint-Add-ins10 oder des CRAN-Package exams11. Umgekehrt ist es auch möglich, eine alternative Backend-Implementierung mit dem Webclient zu verwenden [Kä17]. Das Backend von arsnova.voting wurde als Java-Servlet-Applikation implementiert und wird als Webarchiv (WAR-Datei) ausgeliefert.12 Das Webarchiv kann in Servlet-Containern, welche die Servlet-3.0-Spezifikation erfüllen, z. B. Apache Tomcat, deployt werden. Um ein einheitliches Deployment-Verfahren zu ermöglichen, ist der Webclient ebenfalls als Webarchiv verfügbar.13 Sofern eine Hochschule spezifische Anpassungen benötigt, kann sie eigene Webarchive aus dem Open-Source-Code erzeugen. Die hierfür notwendigen Build-Definitionen und -Skripte sind auf GitHub verfügbar.14 15 Neben dem Servlet-Container benötigt arsnova.voting für die Datenhaltung das dokumentenbasierte Datenbanksystem Apache CouchDB. Darüber hinaus muss ein Webserver, z. B. Nginx, als Reverse-Proxy eingerichtet werden, der die Aufnahme von HTTP- und Websocket-Verbindungen unter einem einzigen Port ermöglicht und Verbindungen mittels TLS absichert. Abb. 3 zeigt diese Funktionen eines Reverse-Proxys am Beispiel der Meteor-App arsnova.click. 9 Das Risiko der Ablenkung durch Nutzung anderer Netze (Mobilfunk oder WLAN) bleibt bestehen. Prinzipiell ist dem Ablenkungsrisiko didaktisch zu begegnen [Qu17], z. B. durch Gruppenarbeit bei der Abstimmung, wie es die Peer-Instruction-Methode vorsieht. Dieser Beitrag beschränkt sich aber auf die technischen Optionen. 10 https://github.com/thm-projects/arsnova-ppt-integration 11 https://cran.r-project.org/web/packages/exams/exams.pdf 12 https://github.com/thm-projects/arsnova-backend/releases 13 https://github.com/thm-projects/arsnova-mobile/releases 14 https://github.com/thm-projects/arsnova-mobile/blob/master/src/site/markdown/development.md 15 https://github.com/thm-projects/arsnova-backend/blob/master/src/site/markdown/development.md Eine vorkonfigurierte Serverumgebung wird in Form von Docker-Container-Images16 bereitgestellt. Diese vereinfachen erheblich die Installation und Upgrades von ARSnovaProdukten, da die benötigten Serverdienste bereits aufeinander abgestimmt sind. Abb. 3: Typische Server-Infrastruktur für die Full-Stack-JavaScript-Implementierung eines ARS 3
Cloud-Deployment: Microservices und Container-Orchestrierung Soll ein Audience-Response-System hochschulweit zum Einsatz kommen, so ist die vorgestellte monolithische Lösung gut geeignet. Soll aber ein Response-System hochschulübergreifend installiert werden, müssen Software-Architektur und Server-Infrastruktur des ARS auf die gleichzeitige Nutzung durch zehntausende Studierende ausgelegt sein. Das Lastprofil einer flächendeckenden ARS-Installation wird während der Vorlesungszeiten extreme Schwankungen aufweisen und in der vorlesungsfreien Zeit gegen Null gehen. Aus Kostengründen müssen das ARS-Backend und die Server-Infrastruktur flexibel und eigenständig Lastspitzen bewältigen und in Ruhezeiten Hardware-Ressourcen wieder freigeben können.
Abb. 4: Fachliche Bestandteile des aktuell monolithischen Backends von arsnova.voting 16 https://hub.docker.com/u/arsnova/
Bei einer monolithischen Architektur (Abb. 4) wird die gesamte Anwendungslogik gebündelt und durch eine einzige Serverinstanz ausgeliefert. Entsteht nun ein hohes Nutzungsaufkommen, kann die Anwendung vertikal skaliert werden, indem man dem Server mehr Ressourcen zur Verfügung stellt [Be14]. Der limitierende Faktor ist hierbei die Hardware. Des Weiteren steigt bei einem monolithischen Backend mit der Funktionalität auch die Komplexität der Software, sodass die Entwicklung träge wird: Der Programmcode wird schwer verständlich und ist nur noch aufwändig erweiterbar. Bonér vergleicht solche Legacy Software mit einem Kartenhaus und verdeutlicht damit die Fragilität einer monolithischen Architektur [Bo16]. Neue Funktionalität kann nicht losgelöst von der bestehenden entwickelt, sondern muss in diese eingewoben werden.
Eine Microservice-Architektur reduziert diese Schwierigkeiten erheblich. Jeder Microservice implementiert eine einzige Geschäftsfunktion und entspricht einem Bounded Context im Domain-Driven Design [Fo14]. Microservices sind zudem voneinander isoliert, daher verwaltet jeder Service seine Daten selbst und stellt eine API bereit, über die andere Services auf diese zugreifen können. Es entsteht ein Netz von in sich abgeschlossenen, vergleichsweise schlanken Services.
Für eine auf Microservices basierende Architektur müssen die Bounded Contexts bestimmt und isoliert werden. Im Falle der Funktionalität von arsnova.voting lassen sich neun Kontexte abgrenzen (Tab. 2). Durch die Kopplung von Datenhaltung und Service kann je nach Anforderungen durch die Anwendungslogik eine geeignete Datenspeicherung eingesetzt werden. So kommen für Ressourcen wie Sessions, Fragen und Antworten relationale Datenbanken zum Einsatz. Für Services wie den Feedback Service, die lediglich temporäre Daten verwalten, kann auf eine eigene Datenhaltung verzichtet werden; für Services, die Daten von anderen Services aggregieren, ist ebenfalls keine eigene Datenhaltung notwendig. Auch kann bei Bedarf ein Cache zum Einsatz kommen. Daraus ergibt sich eine Architektur, wie sie Abb. 5 zeigt.
Erstellung, Bearbeitung, Freigabe und Sperrung von Sitzungen
Import und Export von Sessions, Fragen und Antworten Statistiken über die Sitzung, z. B. Anzahl Antworten und Zwischenfragen Lernstandsberechnung individuell und für die Gruppe Eine Stärke der Aufteilung in Microservices liegt in der Erweiterbarkeit: Wenn ein neues Feature, z. B. global verfügbare Pools mit fachbezogenen Konzeptfragen für die Lehrmethode Peer Instruction, implementiert werden soll, wird dieses Feature in einem neuen Bounded Context mit eventuell eigener Datenhaltung umgesetzt. Es ist nicht erforderlich, andere Services anzupassen, sodass sich die Entwicklung auf die neue Funktionalität fokussiert. Auch bleiben die einzelnen Bestandteile übersichtlicher als in einem monolithischen Ansatz.
Ein weiterer wichtiger Aspekt bei der Umsetzung mit Microservices ist das Deployment. Jeder Service wird mit seiner Datenhaltung in einem replizierbaren Docker-Container gebündelt und hat eine eigene interne IP-Adresse (Abb. 5). Zusammen mit einer Orchestrierungslösung wie Kubernetes ist das Backend für die horizontale Skalierung in der Cloud vorbereitet. Neue Instanzen von Microservices können bei hoher Last flexibel zugeschaltet werden; verebbt die Auslastung, werden diese automatisch wieder entfernt.
Abb. 5: Das zukünftige Backend von arsnova.voting, aufgeteilt in Microservices 4
Zusammenfassung und Ausblick
Der Beitrag beschreibt drei Bereitstellungsstrategien für Audience-Response-Systeme:
(1) den mobilen ARS-Router, (2) das Server-Deployment in Servlet- oder
Docker-Containern und (3) ein Cloud-Deployment mit Container-Orchestrierung. Damit wird ein
Spektrum aufgespannt von einer mobilen Vor-Ort-Lösung im Hörsaal über einen dezentralen
hochschuleigenen Dienst bis zu einer zentralen hochschulübergreifenden Lösung. Im
Open-Source-Projekt ARSnova der THM wurden die ersten beiden Bereitstellungsstrategien
realisiert: Der ARSnova-Router befindet sich in der praktischen Erprobung. Das
ServerDeployment von arsnova.voting wird an mehreren Universitäten und Hochschulen
praktiziert, flächendeckend in Sachsen-Anhalt17 und Hessen18. Die Implementierung als
hochskalierbare Microservice-Architektur soll zum ARS-Wor
Literaturverzeichnis [Be14] [Bo16] [Da17] [FB15] [Fo14] [Kä17] [Qu17] 17 https://arsnova.uni-halle.de/ 18 https://arsnova.hessen.de/ 19 https://github.com/thm-projects/arsnova-microservices