Server Infrastruktur

Rahmenbedingungen der Infrastruktur

• Die Infrastruktur befindet sich in einer Virtual Private Cloud (VPC)
• Darin betrieben werden 1 Datenbankserver (DB-Server) sowie mehrere Application-Server (App-Server)

Preise und Rahmendaten der Infrastruktur

Für High-Traffic Kunden kann eine eigene Server-Infrastruktur innerhalb der VPC betrieben werden. Die Kosten werden dem Kunden dann 1:1 in Rechnung gestellt zuzüglicher einer Management- und Setup-Fee. Die im Folgenden aufgeführten Pakete enthalten großzügige Annahmen für die Kostenstruktur.

Alle oben aufgeführten Preise verstehen sich exkl. der gesetzlichen MwSt.

In der Server-Management Fee sind 3 Anpassungen der Server-Performance enthalten. Die Anpassungen werden um Mitternacht durchgeführt. Dadurch kommt es zu einer Downtime des Servers von ca. 5-10 Minuten. Die Anpassung der Server-Performance bringt große Kostenersparnisse mit sich, da kleinere Server oft die tatsächliche Systemlast bereits tragen.

Welche Leistungen sind enthalten?

• Abrechnung
  • Der Dauerbetrieb einer Server-Infrastruktur verursacht minimale monatliche Kosten von
    • Datenbank-Server: ~28,50 USD
    • Application-Server: ~10,50 USD
    • Data-Transfer: 0,00 USD
  • Einige Skalierungshebel können nicht rückgängig gemacht werden und verursachen dauerhaft höhere Kosten, wenn die Server weiter in Betrieb gehalten werden
    • Z.B. IOPS (Input/Output Operations pro Sekunde) auf dem Datenbank-Server
  • Für die Abrechnung wird ein Billing-Report eingerichtet
    • Die Einrichtung des Reports erfolgt einmalig
    • Monatlich müssen Abrechnungen zur Infrastrukturnutzung erstellt werden. Die Kosten variieren je nach Umrechnungskurs USD ↔ EUR
  • Die meisten Posten der Infrastruktur-Kosten können exakt zugeordnet, einige wenige Posten (wie z.B. Traffic) werden über einen Schlüssel (Anzahl Teilnehmer in der App) umgelegt
• Die Inbetriebnahme einer neuen App auf einer dedizierten Infrastruktur verursacht Aufwand
  • Einrichten des Deployment Prozesses
  • Einrichten der Continous Deployment Pipeline
  • Einrichten der App-Umgebung (Datenbank + Code + Server-Konfiguration)
• Die Skalierung der Infrastruktur verursacht Aufwand
  • Leistungssteigerung/-senkung der Server wird nachts manuell durch einen Mitarbeiter durchgeführt (jeweils DB- und App-Server)
  • Eine Anpassung ist erforderlich bevor mit erhöhter Last zu rechnen ist
  • Nach einer Leistungssteigerung/-senkung muss der Server umkonfiguriert werden, um größere Lasten bedienen zu können. Dies geschieht manuell und nachts nach der Änderung der Server-Performance. (Apache Konfiguration)
• Das Monitoring der Infrastruktur verursacht Aufwand
  • Die Überwachung der Server zu Last-Zeiten wird manuell durchgeführt
  • Bei Engpässen wird manuell eine Skalierung durchgeführt
• Sicherheitsupdates der Server-Infrastruktur und der Apps
  • Zum Dauer-Betrieb der Infrastruktur müssen regelmäßig Sicherheitsupdates auf den Servern eingespielt werden. Diese muss manuell durch einen System-Administrator durchgeführt werden
  • Wird ein App-Update herausgebracht, muss dieses manuell auf die Server-Infrastruktur eingespielt werden

Für App-Aktionen wie den Adventskalender werden Kunden-Server Infrastrukturen neu gestartet und mit den aktuellsten Sicherheits- und App-Versionen versorgt. Während der App Laufzeit wird die Infrastruktur durchgängig beobachtet (Monitoring) und es sind sofortige Benachrichtigungen an die Systemadministratoren eingerichtet, für den Fall einer erhöhten Last.

Skalierungsstrategie

• Kurz vor Beginn der Aktion wird die Server-Performance von DB- sowie App-Servern auf stark überhöhtes Performance Niveau angehoben.
• Nach Start der Aktion (z.B. 02.12. beim Adventskalender, Zweiter Spieltag bei einem Tippspiel) wird die Server-Performance nach unten angepasst, wenn:
  • Die CPU-Auslastung durchgängig unter 10% lag (App- und DB-Server)
  • Die Memory-Auslastung durchgängig unter 20% lag (App- und DB-Server)
• Liegen CPU/Memory Auslastung knapp über den Grenzwerten, ist ein optimales Performance Niveau erreicht und der Server wird in dieser Form beibeihalten
• Überschreiten die Performance KPIs die Grenzwerte, werden die Server nachts angepasst (mehr Memory/CPU je nach Bedarf)

Caching-Strategie

• Alle Apps sind mit HTTP-Caches ausgestattet. Neue Nutzer laden Bilder, CSS, JS Dateien nur einmalig und diese werden in den Cache gelegt. Beim zweiten Zugriff auf die App entsteht zumeist kaum noch Server-Last.

Monitoring & Störungsbehandlung

• Alle Apps werden durch eine Monitoring-Lösung minütlich beobachtet und Störungen umgehend via Push-Notifications, E-Mail und Team-Chat Nachricht an die verantwortliche IT-Abteilung versandt
• Bei zu geringen Server-Ressourcen kann die Infrastruktur innerhalb weniger Minuten nach oben skaliert werden, um Last-Spitzen abzufangen
• Die Skalierung von Servern bringt eine Downtime von ca. 5-15 Minuten ab dem Zeitpunkt der Skalierungs-Änderung mit sich

Erfahrungswerte

Adventskalender

• Bisher haben sich über 1,7M User in der App registriert
• Gestartet wurde 2015 mit folgendem Server-Setup:
  • App-Server: 32vCPUs, 244GB RAM
  • DB-Server: 32vCPUs, 244GB RAM
  • Das Server-Setup verarbeitet bis zu 4000 parallele Anfragen (<1Sekunde)
• Am 01.12.2015 war durchgängig eine Serverlast von ~3-4% gegeben, weshalb die Server in den folgenden Tagen schrittweise auf ein passendes Niveau nach unten skaliert wurden
• Die Parallelen Anfragen lagen zumeist bei 180-200 parallelen Requests pro Sekunde
• Durch den HTTP-Cache der App kann ab dem 02.12. mit einer geringeren Serverlast bei gleichbleibendem Traffic gerechnet werden. Wiederkehrende Nutzer verursachen eine deutlich geringere Last auf den App-Server.