„Jede Latenzzeit von mehr als fünf oder sechs Millisekunden beeinträchtigt die Leistung.“

Im Interview spricht der Senior Trading Infrastructure Change Lead bei Centrica Energy darüber, wie der globale Energiehandelszweig der britischen Centrica-Gruppe seine latenzempfindlichsten Anwendungen in die Cloud migriert hat.

Angesichts wachsender Datenmengen, komplexer regulatorischer Anforderungen und extrem niedriger Latenzzeiten hat Centrica Energy seine latenzempfindlichsten Anwendungen in die Cloud migriert und damit eine leistungsstarke Handelsplattform, vereinfachte Abläufe und eine Grundlage für globale Automatisierung und Ausfallsicherheit geschaffen.

Centrica Energy ist Teil der Centrica Group und ein globales Energiehandelsunternehmen mit Niederlassungen an acht Standorten in Europa, Asien und Nordamerika. Das Unternehmen handelt mit Strom, Gas, Flüssigerdgas (LNG) und Zertifikaten für erneuerbare Energien auf hochgradig vernetzten globalen Energiemärkten.
Diese Märkte sind von Natur aus dynamisch und oft volatil, was hohe Anforderungen an die Technologieplattformen stellt, die die Handelsaktivitäten unterstützen. Die Systeme müssen enorme Kapazitäten mit extremer Leistung und Agilität vereinen. Als Patrick Babic 2021 die Position des Senior Trading Infrastructure Change Leads übernahm, hatte Centrica Energy mit den Einschränkungen einer veralteten lokalen Infrastruktur sowie mit immer komplexeren regulatorischen und Compliance-Anforderungen zu kämpfen.
„Centrica verfolgt als Konzern seit 2017 eine Cloud-First-Strategie“, erklärt Babic. „Wir haben diese Strategie umgesetzt, aber unsere Handelssysteme brauchten mehr Zeit, um für die Migration bereit zu sein.“

Er erläutert den Hintergrund: “Zu diesem Zeitpunkt hatten wir noch drei Kernhandelssysteme, die in einem einzigen lokalen Rechenzentrum liefen. Die Speicherung wurde zu einem kritischen Schwerpunkt, da Handelsanwendungen so nah wie möglich an der Speicherung sein müssen, um Latenz- und Leistungsprobleme zu vermeiden.“

100 Millionen Dateien pro Stunde

Centrica Energy stützt sich in hohem Maße auf seine ETRM-Plattform (Energy Trading and Risk Management), die den gesamten Handelslebenszyklus abdeckt. Das System ist mit Live-Marktdatenfeeds verbunden und unterstützt Risikomanagement, Compliance, Berichterstattung und Analysen in Echtzeit.
„Jede Latenz von mehr als fünf oder sechs Millisekunden beeinträchtigt die Leistung“, sagt Babic. „Die Umgebung ist extrem latenzempfindlich. Handelssysteme schreiben eine Vielzahl von Audit-Protokollen und tauschen ständig Daten aus. Fast jede Aktivität in einem Handelsunternehmen wird nahezu sofort verfolgt, geprüft und gespeichert. Wir sprechen hier von Tausenden von Protokollen pro Sekunde.“
Als Centrica Energy nach Nordamerika expandierte, verschärfte sich die Herausforderung. „Der nordamerikanische Markt hat noch strengere Anforderungen“, fügt Babic hinzu. „Es gibt deutlich mehr Daten zu speichern und zu prüfen.“
AWS wurde als strategische Anwendungsplattform ausgewählt, aber die Wahl des Speichers war ebenso entscheidend. Das Team von Babic entschied sich für Amazon FSx für NetApp® ONTAP®, einen vollständig verwalteten, cloud-nativen Speicherservice. Die Lösung nutzt außerdem NetApp® FlexCache®, um Daten näher an latenzempfindliche Anwendungen zu positionieren und Dateien an strategischen Orten zwischenzuspeichern, um die Leistung zu optimieren.
Der Umfang der Migration war beträchtlich: 150 TB an Handelsdaten und etwa 800 Millionen Dateien mussten innerhalb eines engen Zeitfensters von acht Stunden migriert werden. Es war auch eine der ersten FSx for NetApp® ONTAP®-Bereitstellungen dieser Größe in Europa.
Die Migration dateibasierter Workloads von lokalen Systemen in die Cloud ist eine Herausforderung“, räumt Babic ein.

„In der Spitze haben wir fast eine Million Dateien pro Tag migriert. Eine Migration auf Blockebene wäre mit Replikation und Spiegelung einfacher gewesen, aber eine Migration auf Dateiebene ist von Natur aus komplexer.“
Das Team verfolgte einen stark strukturierten Ansatz. „Wir mussten alles im Voraus vorbereiten und eng mit den Handelsteams zusammenarbeiten, um die Cutover-Fenster zu sichern“, erklärt Babic. „Das bedeutete, dass wir eine speziell auf unsere Umgebung zugeschnittene Migrationslösung entwickeln mussten.“

Der größte Teil des Aufwands floss in die Vorbereitung, nicht in die Ausführung. „Sorgfältige Vorbereitung ist alles“, sagt er. „Man muss seine Anforderungen im Detail verstehen und die Plattform von Anfang an richtig einrichten. Ich verbringe in der Regel drei bis vier Monate nur mit der Vorbereitung, bevor ich mit der eigentlichen Migration beginne.“
Nach der Konfiguration ist die NetApp-Plattform laut Babic einfach zu bedienen. „Sie funktioniert im Wesentlichen nach dem Plug-and-Play-Prinzip.

Man muss nur die Konfiguration an die spezifischen Anforderungen anpassen. Der Großteil der Arbeit besteht darin, den Migrationsansatz zu definieren und vor allem zu testen. Testen, testen und nochmals testen, um sicherzustellen, dass alles genau wie erwartet funktioniert.“

Automatisierung der Ausfallsicherheit

Nach Abschluss der Migration kann sich das Team nun auf das konzentrieren, was Babic als „die eigentliche Arbeit“ bezeichnet: die Leistungsoptimierung und die Verbesserung der Anwendungslandschaft.
„Wir haben mehrere Anwendungsstacks, die sich auf Optimierung, Handel und Handelsübermittlung konzentrieren“, sagt er. „Etwa 80 % dieser Anwendungen speisen nun Daten direkt in die FSx-Plattform ein.“
Durch diesen Schritt wurde auch eine erhebliche operative Belastung beseitigt. „Wir replizieren weiterhin auf sekundäre Cloud-Plattformen, müssen uns aber nicht mehr um die Verwaltung der virtuellen Hardware kümmern“, bemerkt Babic.

„Dadurch entfällt ein großer Teil des Overheads. Wartung, Sicherheit und Patching werden komplett übernommen.“
Für die Zukunft plant Babic, die FSx for NetApp-Umgebung auf weitere Standorte auszuweiten, darunter Singapur und Dänemark. Sein Fokus verlagert sich nun auf Optimierung und Automatisierung.
„Wir sind in ganz Europa stark vertreten“, sagt er. „Meine nächste Priorität ist die Automatisierung von Failover und Disaster Recovery.

Die Verwaltung von Failover in dieser Größenordnung ist komplex; daher verwenden wir Ansible, um das regionale Failover zwischen Standorten wie London und Frankfurt zu automatisieren. Das Ziel ist es, mit einem einzigen Knopfdruck ein Failover von Speicher und Infrastruktur zwischen Regionen durchzuführen.“
Für Centrica Energy ist das Ergebnis eine Cloud-native-Handelsplattform, die auf die Größe, Geschwindigkeit und regulatorischen Anforderungen der modernen globalen Energiemärkte ausgelegt ist, ohne die betrieblichen Einschränkungen der alten Infrastruktur.

Dieser Artikel erschien ursprünglich auf unserer Schwester-Website MES Computing / CRN / Computing.