Seite 4: Zukunft & Fazit

Inhaltsverzeichnis

Pläne für die Zukunft

Für die kommende Saison sind einige inhaltliche Erweiterungen der neuen Webanwendung angedacht, zum Beispiel die Integration des Livetickers, über den Journalisten das Renngeschehen dokumentieren. Er nutzt derzeit noch die alte Technik.

Der Zeitnahmeserver versendet auch von der Rennleitung ausgehende Hinweise, zum Beispiel zu welcher Uhrzeit die Boxenampel auf Grün geschaltet wird oder wenn das Safetycar auf die Strecke geht oder Strafen ausgesprochen werden. Diese Daten wären in die Livetiming-Anwendung zu integrieren und entsprechend zu visualisieren.

Die Livetiming-Anwendung besitzt Informationen über das Ergebnis vorhergegangener Rennen der Saison und somit auch über die Meisterschaftstabelle. Kombiniert mit den Platzierungen der Piloten im aktuellen Rennen ließe sich daraus eine Live-Meisterschaftstabelle berechnen und anzeigen und somit ein weiteres Spannungselement erzeugen.

Die Positionsdaten eines Fahrzeugs lassen sich mit GPS-Empfänger ermitteln, an die Zeitnahme übertragen und der Livetiming-Anwendung zur grafischen Anzeige auf einer Streckenkarte zur Verfügung stellen (Livetracking). In einer solchen Übersicht sind mögliche Positionskämpfe (auch anstehende Überrundungen) und Boxenstopp-Situationen schneller zu erkennen.

Eine Zeitnahme wird grundsätzlich von jeder Rennserie und jedem Wettbewerb benötigt, der Zeiten zur Klassifizierung nutzt. Insofern könnte die Livetiming-Anwendung darüber hinaus nicht nur für weitere Rennserien, sondern auch für andere Sportveranstaltungen mit Zeitnahme zum Einsatz kommen.

Auch im Bereich der Softwarearchitektur gibt es noch Pläne. Das Fehlen einer Ausfallsicherheit im Bereich des Hauptservers und der Datenbanken birgt derzeit noch die große Gefahr eines Totalausfalls der Anwendung. Die Überlegung geht in die Richtung, MongoDB Replicaset (also ein spezielles Cluster
für MongoDB), zu verwenden, also die Spiegelung der Daten auf einen zweiten Server. Neben einer erhöhten Ausfallsicherheit brächte das weitere positive Aspekte mit sich: Die Daten ließen sich von zwei Servern lesen (Performance), und als logische Konsequenz wäre zur optimalen Ressourcennutzung auch eine Lastverteilung (Loadbalancing) möglich.

Alternativ zu Redis ist RabbitMQ angedacht. Echtes Messaging auf Basis des AMPQ-Standards (Advanced Message Queuing Protocol), Subscribe/Publish inklusive Routing durch eines der beiden Kommunikationsverfahren (Topic Exchange bzw. Fan-out) wären die wichtigsten Vorteile. Außerdem bietet RabbitMQ eine höhere Performanz im Bereich Subscribe/Publish und benötigt keine Punkt-zu-Punkt-Verbindung. Letzteres würde eine gute Integration eines Tracing/Logging ermöglichen, ohne eine Änderung des Anwendungs-Codes zu bedingen. Die Daten für die Archivierung ließen sich dann über Nachrichten austauschen.

Das Deployment für die eingesetzten Server (zehn Appserver und ein Hauptserver) findet zurzeit manuell statt. Eine Umstellung auf das skriptbasierte Webdeployment-Werkzeug Capristano würde diesen Prozess vollständig automatisierbar und weniger fehleranfällig werden lassen. Die von Capristano durchgeführten Schritte sind:

• Check-out des aktuellen Codes in ein neues Verzeichnis
• Herunterfahren der Server
• Umschaltung auf eine neue Codebasis
• Start der Server

Im Fehlerfall erfolgt ein Fallback auf den vorherigen Code. Weitere Server werden durch simple Aufnahme in die Liste der Server hinzukonfiguriert.

Eine Meisterschaft besteht aus einer festgelegten Anzahl Rennen, die allesamt zeitlich abgegrenzte Veranstaltungen von definierten Zeitdauern sind. Konkret bedeutet das: Nur an zehn Wochenenden im Jahr besteht der Bedarf nach solcher Rechenleistung. Es ist also unwirtschaftlich, eine für die Spitzenzeiten der Rennwochenenden abgestimmte teure Hardwarekonfiguration zu kaufen oder zu mieten. Die Betriebskosten wären durch den Einsatz einer Platform as a Service zu minimieren. Mit Skalierung der Anzahl eingesetzter Appserver lässt sich der sich ändernden Anzahl Clients effektiv begegnen. Denkbare Produkte sind Heroku und Windows Azure, weil beide sowohl Node.js als auch den Betrieb einer MongoDB-Datenbank unterstützen.

Fazit

Das beschriebene Projekt der Livetiming-Website bewies eindrucksvoll, dass die eingesetzten, auf JavaScript zentrierten Techniken und Bibliotheken trotz ihres jungen Alters einen guten Reifegrad erreicht haben und selbst zeit- und ressourcenkritische Anwendungen in einem ansprechenden Zeitraum realisierbar sind. Ferner zeigt es, dass sich die Technik auch für die Verarbeitung von Massendaten und die Versorgung vieler Clients durch die Möglichkeiten von Skalierung (Verteilung auf mehrere Appserver) eignet. Dass die Wahl der richtigen und passenden Techniken wichtig ist, wird bei Betrachtung der relativ kurzen Realisierungszeit für das Projekt von 30 Manntagen deutlich. Daher wurde auch viel Augenmerk darauf gelegt, sowohl auf Client- als auch auf Server- und Datenbankseite dieselbe Programmiersprache (JavaScript) einsetzen zu können. Etwaige Interoperabilitätsprobleme wurden so von vornherein minimiert.

Thomas Suer, Martin Möllenbeck und Dr. Holger Schwichtenberg
entwickeln hochskalierbare Enterprise-Anwendungen mit .NET und modernen Webtechniken bei der 5minds IT-Solutions GmbH & Co. KG. (ane)