Ein Finanzdienstleister gewährleistet die zuverlässige Bereitstellung von Daten für KI-Anwendungen

Ein führender europäischer Vermögensverwalter musste auf die harte Tour lernen, dass Objektspeicher allein die parallelen Zugriffe von KI-Workloads nicht bewältigen können. Nachdem eine Fehlkonfiguration auf Kundenseite einen Denial-of-Service-Vorfall ausgelöst hatte, implementierte das Unternehmen Lösungen von F5, um eine zuverlässige, skalierbare und leistungsstarke S3-Datenbereitstellung für das Training von KI-Modellen sicherzustellen.

Herausforderung

Ein europäischer Vermögensverwalter mit starker Präsenz im Finanzdienstleistungs- und Immobiliensektor investiert massiv in KI. Die Data-Science-Teams des Unternehmens trainieren Modelle anhand großer Datensätze, die in Dell Elastic Cloud Storage (ECS), einem S3-kompatiblen Objektspeicher, gespeichert sind. Die KI-Workloads werden dabei auf Kubernetes ausgeführt. Die Schwachstelle war die Verbindung zwischen diesen Workloads und dem Speicher selbst.

Objektspeicherplattformen sind darauf ausgelegt, ihre Kapazität zu skalieren, nicht den Datenverkehr zu kontrollieren. Jahrzehntelang griffen Anwendungen über dedizierte Protokolle in kontrollierten Netzwerken auf Speicher zu, sodass vor einem Dateiserver oder Speicher-Array kein Traffic-Management erforderlich war. S3-Speicher hat das geändert. Auf Objektspeicher greift heute jeder Client, der über einen Schlüssel verfügt, per HTTP zu. Dadurch verhält sich das Speicher-Frontend wie ein Webdienst und kann auf dieselbe Weise ausfallen. Einzelne Speicherknoten können in der Praxis nur eine begrenzte Anzahl gleichzeitiger TCP-Verbindungen verarbeiten. Wenn KI-Pipelines Tausende parallele Sitzungen öffnen, um Trainingsdaten abzurufen, können diese Grenzen schnell erreicht werden – und Speicherteams erkennen das Problem meist erst, wenn es bereits auftritt.

Bei dem Finanzdienstleistungsunternehmen öffnete ein falsch konfigurierter Client mehr gleichzeitige Verbindungen, als das Ursprungssystem bewältigen konnte, und löste damit faktisch einen Denial-of-Service-Zustand gegen den unternehmenseigenen Speicher aus. Die Aufnahme von KI-Daten kam zum Erliegen.

Der Vorfall machte den Infrastruktur- und Speicherteams zwei Dinge deutlich.

Erstens darf ein einzelner fehlerhaft agierender Client niemals eine gemeinsam genutzte Datenplattform zum Ausfall bringen können. Insbesondere im Finanzdienstleistungssektor ist Zuverlässigkeit unverzichtbar. Zeitpläne für das Modelltraining, Analysen und nachgelagerte Geschäftsentscheidungen hängen allesamt davon ab, dass die Datenplattform in Betrieb bleibt.

Zweitens würde sich das Problem angesichts der Pläne des Unternehmens, zusätzliche ECS-Knoten zur Unterstützung wachsender KI-Initiativen hinzuzufügen, nur noch verschärfen. Um voranzukommen, war technische Disziplin an der Speichergrenze erforderlich – mit einem Kontrollpunkt, der den S3-Datenverkehr steuern, ausgleichen und absichern konnte, bevor er überhaupt einen Speicherknoten erreichte.

Lösungen

Das Unternehmen prüfte mehrere mögliche Lösungen, darunter HAProxy und Angebote von Kemp Technologies, stellte jedoch fest, dass deren speziell auf das S3-Protokoll zugeschnittene Funktionen für die Anwendungsbereitstellung nur begrenzt waren.

Frühe Proof-of-Value-Demonstrationen gaben den Ausschlag, da sie zeigten, dass die F5-Lösung Herausforderungen des S3-Protokolls wie die Sitzungspersistenz bewältigen und sich zugleich nahtlos in ECS integrieren kann. Dell, ein technischer Partner sowohl des Unternehmens als auch von F5, spielte eine entscheidende Rolle, indem es die F5-Lösung auf die ECS-Infrastruktur abstimmte und sich für die gemeinsame Architektur einsetzte.

Letztendlich entschied sich das Finanzdienstleistungsunternehmen für F5 und implementierte vier F5 rSeries r5600-Appliances mit BIG-IP Local Traffic Manager (LTM) als dedizierte Bereitstellungsebene vor dem ECS-Speicher.

Die Bereitstellung folgte einem bewährten Referenzdesign, das Risiken reduzierte und einen Fahrplan für die Weiterentwicklung der KI-Landschaft bietet. Die daraus resultierende Aktiv/Aktiv-Architektur mit zwei Rechenzentren ist bewusst einfach gehalten. Sie nutzt dynamische Routingmechanismen, um horizontale Skalierung und Hochverfügbarkeit ohne DNS-Abhängigkeit zu ermöglichen. Jede S3-Anfrage der auf Kubernetes gehosteten KI-Workloads wird nun über BIG-IP LTM geleitet, bevor sie den Speicher erreicht. Diese eine Designentscheidung behebt die ursprüngliche Fehlerursache und schafft eine Grundlage für weiteres Wachstum.

Ergebnisse

Connection-Pooling behebt das Parallelitätsproblem direkt, sodass sich der Vorfall, der dieses Projekt ausgelöst hat, nicht wiederholen kann. BIG-IP-LTM bewältigt die Flut clientseitiger TCP-Verbindungen und bündelt sie zu einer kleineren, kontrollierten Anzahl serverseitiger Verbindungen zu den ECS-Knoten. Zudem sorgt es für eine geregelte Verbindungsnutzung, sodass ein einzelner falsch konfigurierter oder aggressiver Client die Kapazität eines Speicherknotens nicht mehr erschöpfen kann. Die ECS-Plattform bleibt für alle Teams verfügbar, selbst wenn sich ein Client fehlerhaft verhält.

Messbare Leistungssteigerungen erzielen

Konsistentes URL-Hashing sorgt für eine intelligente statt zufällige Verteilung der Anfragen. Anfragen für dieselben Objekte werden vorhersehbar über den ECS-Cluster verteilt. Dies verbessert die Cache-Auslastung, vermeidet Hotspots und hält den Durchsatz stabil, wenn weitere Speicherknoten hinzugefügt werden.

Darüber hinaus zeigten interne Leistungstests mit dem Speichertesttool Mongoose nach der Implementierung von F5-Lösungen im Datenpfad eine Leistungssteigerung von 500 % bei den verarbeiteten Ein- und Ausgaben. Durch die Optimierung von TCP-Verbindungen, das Multiplexing serverseitiger Anfragen und die Nutzung dynamischen Routings erzielte die Plattform sofortige Durchsatzsteigerungen für anspruchsvolle KI-Workloads.

KI-Initiativen skalieren, ohne die Architektur neu zu gestalten

Das Unternehmen plant, seine ECS-Umgebung mit der zunehmenden Verbreitung von KI zu erweitern. Da BIG-IP LTM die Speicherendpunkte hinter einer einzigen virtuellen Adresse abstrahiert, kann das Unternehmen Knoten hinzufügen, um die ECS-Umgebung zu skalieren, ohne Anwendungskonfigurationen ändern oder Workloads unterbrechen zu müssen. Auf diese Weise ermöglicht die Architektur, die ein Zuverlässigkeitsproblem behoben hat, zugleich weiteres Wachstum.

Speicher als durchdachten Service gestalten

Eine dedizierte Ebene für die Anwendungsbereitstellung vor dem Storage ermöglicht die Umsetzung bewährter Engineering-Praktiken. Der Datenverkehr lässt sich zentral überwachen, verteilen und steuern, anstatt ein unkontrolliertes, eng gekoppeltes Geflecht aus Clients zu bilden, die direkt auf die Knoten zugreifen. Für Storage-Architekten bedeutet dies ein vorhersehbares Knotenverhalten und eine klare Kapazitätsplanung. Für den CIO bedeutet es, dass die KI-Datenplattform ein durchdachtes System ist und keine Ansammlung von Punkt-zu-Punkt-Verbindungen.

Setzen Sie auf eine Partnerschaft für die Bereitstellung von KI-Daten

F5 und Dell entwickeln gemeinsam Lösungen für genau diese Art von Workload und kombinieren dabei das Traffic-Management von BIG-IP LTM mit S3-kompatiblem Objektspeicher für KI-Pipelines. Andere Unternehmen können daraus lernen, dass S3-Objektspeicher ein Webdienst ist und KI-Workloads ihn entsprechend stark beanspruchen. Ein dedizierter Application Delivery Controller vor dem Speicher kann einen direkt zugänglichen Ursprungsserver in die robuste Datenpipeline verwandeln, die für eine effektive KI-Implementierung erforderlich ist.