IPUs verbessern die Netzwerklatenz in Microservices-basierten Anwendungen

Was sind Microservices?

Microservices beziehen sich auf einen modernen Softwareentwicklungsansatz, bei dem eine große Anwendung in kleinere, unabhängige, lose gekoppelte Dienste zerlegt wird. Anstatt Anwendungen als traditionelle monolithische Softwaresysteme zu implementieren, implementieren Cloud-Service-Provider, darunter namhafte Unternehmen wie Amazon, eBay, Netflix und Twitter, ihre Anwendungen zunehmend als Microservices und nicht als traditionelle monolithische Designs.

Zu den Vorteilen von Microservices gehören:

• Skalierbarkeit: Microservices ermöglichen eine bessere Skalierbarkeit, da einzelne Services unabhängig voneinander skaliert werden können. Das bedeutet, dass Entwickler nur die Dienste hoch- oder herunterskalieren können, die sie benötigen, ohne dass der Rest der Anwendung davon betroffen ist.

• Flexibilität: Microservices erleichtern das Vornehmen von Änderungen an einem System, da einzelne Dienste aktualisiert werden können, ohne die gesamte Anwendung zu beeinträchtigen. Dies erleichtert die Einführung neuer Technologien, das Experimentieren mit verschiedenen Programmiersprachen und das Testen neuer Funktionen.

• Fehlerisolierung: Da jeder Microservice eine unabhängige Komponente ist, wirkt sich ein Ausfall eines Dienstes nicht auf den Rest der Anwendung aus. Dies bedeutet, dass Entwickler Probleme schnell identifizieren und beheben können, ohne das gesamte System zu beeinträchtigen.

• Verbesserte Entwicklungsgeschwindigkeit: Microservices ermöglichen es kleineren, fokussierteren Entwicklungsteams, unabhängig an bestimmten Diensten zu arbeiten. Das beschleunigt den Entwicklungsprozess und erleichtert die Verwaltung großer, komplexer Systeme.

• Bessere Fehlertoleranz: Mit Microservices ist es einfacher, fehlertolerante Systeme zu erstellen, da jeder Dienst so konzipiert werden kann, dass er Fehler unabhängig behandelt. Dies bedeutet, dass das gesamte System widerstandsfähiger ist und weniger wahrscheinlich ausfällt.

• Verbessertes Testen: Da jeder Microservice unabhängig ist, ist es einfacher, einzelne Dienste zu testen. Dies bedeutet, dass Entwickler Dienste isoliert testen können, was das Auffinden und Beheben von Fehlern erleichtert.

Auf Microservices basierende Softwarearchitekturen bieten zwar wichtige Vorteile, verursachen aber auch erhebliche Netzwerk-Overheads, sodass Parameter wie die Netzwerklatenz einen großen Einfluss auf die Gesamtleistung der Anwendung und die Rechenzentrumskosten haben. Durch die Nutzung von Intel FPGA Infrastructure Processing Units (IPUs), auf denen virtualisierte Datenebenensoftware von Napatech ausgeführt wird, können Serviceanbieter die Leistung ihrer Netzwerkinfrastruktur maximieren und ein Leistungsniveau erreichen, das sonst nicht erreicht werden kann, während sie gleichzeitig die Gesamtinvestitionen und -operationen ihres Rechenzentrums minimieren.

Netzwerkherausforderungen für Microservices

In einer Microservices-Architektur stellt die Netzwerklatenz eine große Herausforderung dar, da virtualisierte Dienste, die in Containern oder virtuellen Maschinen (VMs) implementiert sind, über ein virtualisiertes Netzwerk miteinander kommunizieren. Beispielsweise kommunizieren Microservices häufig miteinander, was zu einem großen Netzwerkverkehr führen kann. Dieser erhöhte Netzwerkverkehr kann zu Netzwerküberlastungen und erhöhter Latenz führen, was sich negativ auf die Leistung des Systems auswirken kann. In ähnlicher Weise müssen Dienste in einer Microservices-Architektur häufig andere Dienste aufrufen, um eine Aufgabe abzuschließen, und jeder Netzwerkaufruf fügt dem System zusätzliche Latenz hinzu. Mit zunehmender Anzahl der Dienste und der Komplexität des Systems steigt auch die Anzahl der Netzwerkanrufe, was zu erheblichen Latenzproblemen führen kann. Schließlich können verschiedene Microservices unterschiedliche Netzwerkprotokolle für die Kommunikation verwenden. Beispielsweise kann ein Dienst REST (REpresentational State Transfer) verwenden, während ein anderer Dienst gRPC (Google Remote Procedure Call) verwenden kann. Die Übersetzung zwischen verschiedenen Netzwerkprotokollen kann zu einer zusätzlichen Latenz des Systems führen.

Traditionell wird eine virtualisierte Datenebene vollständig in Software implementiert, und viele ihrer Rechenzyklen werden durch die Ausführung eines virtuellen Switches (vSwitch) verbraucht, der den Netzwerkverkehr zwischen VMs leitet. Da jeder vSwitch-Vorgang eine beträchtliche Anzahl von CPU-Zyklen erfordert, kann diese Architektur zu inakzeptabler Latenz im System führen und auch verhindern, dass das System die erforderliche Gesamtleistung oder den erforderlichen Durchsatz erreicht. Gleichzeitig stehen einer CPU, die auf der virtuellen Datenebene ausgeführt wird, weniger Kerne für die Ausführung von Anwendungen und Diensten zur Verfügung, wodurch die Anzahl der Server erhöht wird, die zur Unterstützung der Arbeitslast im Rechenzentrum erforderlich sind, und sowohl die Investitions- als auch die Betriebskosten (OPEX) steigen. Siehe Abbildung 1.

Nutzung einer Intel® FPGA IPU-basierten Architektur

Eine effizientere und kostengünstigere Architektur auf Systemebene nutzt eine Intel FPGA IPU, um den vSwitch von der Server-CPU zu entlasten und die Server-CPU für die Ausführung von Anwendungen und Diensten freizugeben.

Die IPU, die die standardmäßige Netzwerkkarte (NIC) im Rechenzentrumsserver ersetzt, implementiert den vSwitch in Hardware und verwendet ein programmierbares FPGA (Field Programmable Gate Array), um die Datenebene in Verbindung mit einer Allzweck-CPU auszuführen, die die Steuerungsebene ausführt. Der vSwitch stellt den VMs eine branchenübliche API (Application Programming Interface) zur Verfügung, die sicherstellt, dass keine Änderungen an den VMs selbst vorgenommen werden müssen, wenn diese Architektur genutzt wird. Siehe Abbildung 2.

Die IPU-basierte Architektur bietet drei wesentliche Vorteile für Rechenzentren, in denen Anwendungen auf Microservices-Basis ausgeführt werden:

• Ultra-niedrige Latenz, die den Verzögerungsverkehr zwischen den Microservices minimiert;

• Hohe Leistung, die den Gesamtdurchsatz des Systems und der Anwendung maximiert;

• Optimale Server-CPU-Auslastung ohne Server-CPU-Kerne, die von der vSwitch-Datenebene verbraucht werden, wodurch die Gesamtzahl der für die Gesamtarbeitslast erforderlichen Server minimiert und auch die Investitions- und Betriebskosten des Rechenzentrums minimiert werden.

MIT-Analyse

Um die Vorteile des vSwitch-Offloads in realen Szenarien zu quantifizieren, analysierte das Massachusetts Institute of Technology (MIT) die Leistung von zwei auf Mikrodiensten basierenden Anwendungsfällen und verglich die Ergebnisse der Verwendung eines herkömmlichen softwarebasierten vSwitch mit denen, die mit einem Intel IPU erzielt wurden, auf dem virtualisierte Datenebenensoftware von Napatech, einem führenden Anbieter von SmartNIC- und IPU-Lösungen, ausgeführt wurde. Bei diesen beiden Anwendungsfällen handelte es sich um eine "Pub-Sub"-Anwendung mit Publish-Subscribe-Funktion, die die Nachrichtenübergabe für Datenübertragungen über mehrere Ebenen hinweg verwendet, und eine dreistufige TCP-Anwendung, die einen Webserver, einen In-Memory-Cache und eine Back-End-Datenbank umfasst. Die Ergebnisse dieser Benchmarking-Initiative sind in dem vom MIT veröffentlichten Paper "Microservice Benchmarking on Intel IPUs running Napatech Software" .

Leistungsanalyse der Pub-Sub-Anwendung

Eine Pub-Sub-Anwendung, kurz für "Publish-Subscribe-Anwendung", ist ein Messaging-Muster, das häufig in verteilten Systemen verwendet wird, um die Kommunikation und Koordination zwischen verschiedenen Komponenten oder Diensten zu erleichtern. Das pub-sub-Muster ermöglicht eine asynchrone und entkoppelte Kommunikation, bei der Absender von Nachrichten, die als Herausgeber bezeichnet werden, die spezifischen Empfänger, die als Abonnenten bezeichnet werden, nicht kennen müssen. Pub-Sub-Anwendungen eignen sich für Anwendungsfälle wie:

• Sitzplatzreservierungssysteme , die einen Grundriss erstellen, ihm Sitzplätze zuweisen und dann die Live-Sitzplatzbuchungsveranstaltungen verwalten. Wenn Kunden Tickets kaufen, aktualisiert das Pub-Sub-System den Grundriss überall in Echtzeit und hält das verteilte Cache-System synchron. Kunden fordern nie einen Sitzplatz an, nur um herauszufinden, dass jemand ihn gekauft hat, während sie sich noch in der Browsing-/Shopping-Phase befanden.

• Lerntools , die es Schülern ermöglichen, über eine webbasierte App an einem Klassenzimmer teilzunehmen, wenn Clients häufig auf Probleme wie unzuverlässiges WLAN oder unvorhersehbare Mobilfunknetze stoßen. Das pub-sub-System stellt seine Verbindung wieder her, wenn es sich wieder dem Netzwerk anschließt, und ist in der Lage, schnelle Änderungen in der Anzahl der Online-Teilnehmer zu bewältigen.

• Finanzanwendungen wie die Verteilung von Marktdaten, einschließlich Aktienkursen, Marktindizes, Handelsdaten und Aktualisierungen des Orderbuchs an Abonnenten innerhalb einer Organisation.

• Internet of Things (IoT)-Systeme, bei denen pub-sub die Kommunikation zwischen zahlreichen IoT-Geräten erleichtert und eine effiziente Datenverbreitung ermöglicht. Sensoren veröffentlichen Daten, und Abonnenten können diese Daten in Echtzeit empfangen und verarbeiten.

Für diese Analyse evaluierte das MIT eine fünfstufige Kettentopologie, die mit einem Pub-Sub-Kommunikationsmodell von Daprwurde, einer portablen, ereignisgesteuerten Laufzeitumgebung, die es Entwicklern ermöglicht, robuste, zustandslose und zustandsbehaftete Anwendungen zu erstellen, die sowohl in der Cloud als auch am Edge ausgeführt werden und gleichzeitig eine Vielzahl von Sprachen und Entwickler-Frameworks unterstützen. Jede Ebene führt für eine benutzerdefinierte Zeitspanne CPU-intensive Berechnungen durch, bevor die Ausgabe an die Downstream-Ebene gesendet wird. Siehe Abbildung 3.

Innerhalb der fünfstufigen Pub-Sub-Anwendung wird durch die Platzierung von Diensten auf den beiden OVS-fähigen Servern sichergestellt, dass abhängige Dienste auf verschiedenen physischen Rechnern ausgeführt werden, sodass der gesamte Datenverkehr zwischen den Ebenen über die IPUs geleitet wird, sofern aktiviert.

Das MIT analysierte die Leistung des Pub-Subsystems sowohl mit als auch ohne IPU-basiertes Offload und maß die Messaging-Latenz über verschiedene Lasten hinweg, die als Tausende von Abfragen pro Sekunde (kQPS) ausgedrückt werden. Siehe Abbildung 4.

Wenn die Entlastung deaktiviert ist und die Latenz im schlimmsten Fall (im schlimmsten Fall) berücksichtigt wird, beginnt die Anwendung bei 90 kQPS zu sättigen, wie durch den Wendepunkt im Diagramm angezeigt. Jenseits dieser Auslastungsebene kann das System nicht mehr effizient mit Anforderungen Schritt halten, höchstwahrscheinlich aufgrund von Paketverlusten, die zu TCP-Neuübertragungen führen. Wenn Offload aktiviert ist, kann das System jedoch immer noch mit Anforderungen bei einer Last von 140kQPS Schritt halten, der maximalen Rate, die in diesem Test verwendet wurde, was darauf hinweist, dass die IPU eine 50%ige Steigerung des Durchsatzes ermöglicht, während eine akzeptable Tail-Latenz beibehalten wird. Dies stellt eine erhebliche Verbesserung der Systemkapazität dar, was zu Einsparungen von 30-40% sowohl bei den Gesamtserverkosten als auch beim Energieverbrauch führt.

Leistungsanalyse der dreistufigen TCP-Anwendung

Eine dreistufige TCP-Anwendung (Transmission Control Protocol) bezieht sich auf eine Softwarearchitektur, die eine Anwendung in drei logische Schichten oder Ebenen unterteilt, die jeweils für bestimmte Funktionen verantwortlich sind. Diese Ebenen werden in der Regel als Darstellungsebene, Anwendungsebene und Datenebene bezeichnet. Das TCP-Protokoll wird für die Kommunikation zwischen diesen Ebenen verwendet:

• Präsentationsebene: Diese Schicht, die auch als Benutzeroberfläche (UI) bezeichnet wird, ist dafür verantwortlich, den Benutzern die Informationen der Anwendung zu präsentieren und ihre Eingaben zu empfangen. Es befasst sich mit Komponenten der grafischen Benutzeroberfläche (GUI) wie Webseiten, Formularen oder Desktopoberflächen. Die Darstellungsebene kommuniziert mit der Anwendungsebene, um bei Bedarf Daten abzurufen oder zu aktualisieren.

• Anwendungsebene: Die Anwendungsebene enthält die Geschäftslogik und Verarbeitungslogik der Anwendung. Sie verwaltet die Kernfunktionalität und führt Aufgaben wie Datenvalidierung, Durchsetzung von Geschäftsregeln und anwendungsspezifische Vorgänge aus. Diese Ebene verarbeitet die Anforderungen von der Präsentationsebene und kommuniziert mit der Datenebene, um Daten abzurufen oder zu speichern.

• Datenebene: Die Datenebene, die auch als Datenzugriffsschicht oder Datenbankebene bezeichnet wird, ist für die Verwaltung des Speicherns und Abrufens von Daten verantwortlich. Es übernimmt die Interaktionen mit den Datenbanksystemen, wie z. B. das Abfragen und Aktualisieren von Daten. Die Datenebene empfängt Anforderungen von der Anwendungsebene und gibt die angeforderten Daten zurück oder führt die erforderlichen Datenänderungen durch.

In einer dreistufigen TCP-Anwendung wird die Kommunikation zwischen diesen Ebenen mithilfe des TCP-Protokolls erleichtert. TCP sorgt für eine zuverlässige und geordnete Bereitstellung von Daten zwischen den Ebenen und bietet einen verbindungsorientierten und strombasierten Kommunikationsmechanismus. Durch die Aufteilung der Anwendung in diese drei Ebenen ermöglicht die dreistufige TCP-Architektur Modularität, Skalierbarkeit und eine einfachere Wartung der Anwendung. Jede Stufe kann unabhängig voneinander entwickelt und skaliert werden, was die Flexibilität und Wiederverwendbarkeit von Komponenten erleichtert.

Für diese Analyse evaluierte das MIT eine dreistufige Anwendung mit NGINX als Front-End-Webserver, Memcached als In-Memory-Caching-Ebene und MongoDB als Back-End-Datenbank mit persistentem Speicher. Clients interagieren mit NGINX, das prüft, ob ein Schlüssel-Wert-Paar in Memcached zwischengespeichert ist, und wenn dies der Fall ist, gibt es den Wert an den Client zurück. Wenn nicht, ist NGINX mit MongoDB verbunden, um die Ausgabe abzurufen und zusätzlich in Memcached zwischenzuspeichern. Siehe Abbildung 5.

Das MIT analysierte die Leistung der dreistufigen TCP-Anwendung sowohl mit als auch ohne IPU-basiertes Offload, wobei die Messaging-Latenz über unterschiedliche Lasten hinweg gemessen wurde, die, wie im vorherigen Beispiel, als Tausende von Abfragen pro Sekunde (kQPS) ausgedrückt werden. Siehe Abbildung 6.

Wenn die Auslagerung deaktiviert ist und die Latenz im schlimmsten Fall (d. h. im schlimmsten Fall) berücksichtigt wird, beginnt die Anwendung bei etwa 17 kQPS zu sättigen, wie durch den Wendepunkt im Diagramm angezeigt. Jenseits dieser Auslastungsebene kann das System nicht mehr effizient mit Anforderungen Schritt halten, höchstwahrscheinlich aufgrund von Paketverlusten, die zu TCP-Neuübertragungen führen. Wenn Offload aktiviert ist, beginnt die Sättigung jedoch erst bei einer Last von 26 kQPS, was darauf hinweist, dass die IPU eine Steigerung des Durchsatzes um 53 % bei gleichzeitiger Beibehaltung einer akzeptablen Tail-Latenz ermöglicht. Wie im vorherigen Beispiel stellt dies eine signifikante Verbesserung der Systemkapazität dar, was zu Einsparungen von 30-40% sowohl bei den Gesamtserverkosten als auch beim Energieverbrauch führt.

Systemkonfiguration

Die vom MIT für das Benchmarking von Microservices verwendete Systemkonfiguration sah wie folgt aus:

• Zwei Inspur-Dual-Socket-Server mit jeweils einem Intel® Xeon® Gold 6338 Prozessor mit 48 MB Cache, der mit 2,0 GHz und 3,2 GHz Turbo-Geschwindigkeit läuft. Jeder Server wurde mit 512 GB Speicher, einem 480-GB-Bootlaufwerk, zwei 1,6 TB P6410 NVMe-Speichermodulen und einem 10G Intel® Ethernet-Controller XL710 NIC konfiguriert.

• Zusätzlich zur Standard-Netzwerkkarte wurde jeder Server mit einem Intel IPU C5000X-Adapter mit zwei 10/25G-SFP28-Ports und einer PCIe 3.0-Hostschnittstelle konfiguriert, die auf einem Intel® Stratix® FPGA und einem Intel® Xeon® D System-on-Chip (SoC) basiert. Siehe Abbildung 7.

• Jede IPU führte die Link-Virtualization 4.3.3-Software von Napatech aus, die eine entladene und beschleunigte virtualisierte Datenebene mit Funktionen wie Open vSwitch (OVS), VirtIO-Unterstützung, Live-Migration, VM-zu-VM-Spiegelung, VLAN/VxLAN-Kapselung/-Entkapselung, Q-in-Q, RSS-Lastausgleich, Link-Aggregation und Quality of Service (QoS) bereitstellte.