Benchmarking von API-Management-Lösungen von NGINX, Kong und Amazon: Liefern sie APIs in Echtzeit?

Geschwindigkeit – sie ist in der heutigen digitalen Landschaft von entscheidender Bedeutung, da Verbraucher leicht zur Konkurrenz wechseln können, wenn die Leistung Ihrer App zu langsam ist. Die App-Geschwindigkeit wird letztendlich durch reaktionsfähige, stabile und anpassungsfähige APIs bestimmt, und einer der entscheidenden Faktoren für die API-Reaktionsfähigkeit ist die durch Ihr API-Gateway verursachte Latenz. Allerdings weisen nicht alle API-Gateways die gleiche Leistung auf.

Dies wurde uns im vergangenen Herbst klar, als uns ein NGINX-Kunde – ein bedeutender Akteur in der Verbraucherkreditbranche – von der zunehmenden Bedeutung der API-Leistung in „Echtzeit“ berichtete, da immer mehr Apps und andere Komponenten kommunizieren müssen, um das von den Benutzern erwartete digitale Erlebnis zu bieten. Wir waren hocherfreut, als wir erfuhren, dass NGINX Plus das einzige API-Gateway war, das die vom Kunden benötigten superschnellen API-Latenzen – bis zu 10 Millisekunden (ms) – erreichte. Viele andere Kunden , beispielsweise Capital One , haben uns ebenfalls mitgeteilt, wie sie mit NGINX Open Source oder NGINX Plus als API-Gateway die Latenz reduziert und den Durchsatz verbessert haben.

Wir haben uns entschieden, tiefer in das API-Ökosystem einzutauchen und herauszufinden, was eine API „Echtzeit-API“ macht. Anhand einer Reihe von Faktoren haben wir ermittelt, dass eine Echtzeit-API API-Aufrufe in jedem Perzentil bis zum 99. Perzentil in weniger als 30 ms durchgängig verarbeiten muss (was bedeutet, dass im Durchschnitt nur 1 von 100 Aufrufen länger als 30 ms dauert).

Vergleich von API-Management-Lösungen

Unsere eigenen Tests zeigen immer wieder, dass sich mit unserer API-Verwaltungslösung problemlos eine API-Leistung in Echtzeit erzielen lässt. Diese Lösung kombiniert NGINX Plus als API-Gateway zur Verarbeitung von API-Aufrufen und das API-Verwaltungsmodul NGINX Controller zur Verwaltung von NGINX Plus-Instanzen und Ihren APIs, während Sie diese über ihren gesamten Lebenszyklus hinweg definieren, veröffentlichen, verwalten und überwachen.

Wir verstehen jedoch, dass Sie sich möglicherweise nicht auf unser Wort verlassen möchten. Deshalb haben wir GigaOm , ein unabhängiges technisches Forschungs- und Analyseunternehmen, mit einem objektiven und transparenten Benchmarking unserer API-Management-Lösung und anderer beliebter Lösungen auf dem Markt beauftragt: zwei Lösungen, die wie NGINX vor Ort oder in der Cloud bereitgestellt werden können, Apigee und Kong Enterprise , sowie zwei vollständig verwaltete Cloud-Angebote, Amazon API Gateway und Kong Cloud.

In diesem Blog fassen wir die Ergebnisse der Tests von GigaOm zusammen (Spoiler: NGINX Plus lieferte APIs in allen getesteten Bedingungen in Echtzeit, die anderen Lösungen taten dies nicht). Um alle Einzelheiten zu den Lösungen, der Testmethodik und den Ergebnissen zu erfahren, wenden Sie sich an ein Mitglied unseres Teams .

Notiz: Die Endbenutzer-Lizenzvereinbarung (EULA) von Apigee untersagt die Veröffentlichung von Testergebnissen ohne die ausdrückliche Genehmigung von Google. Daher enthalten weder der Bericht noch dieses Blog leider Informationen zu Apigee.

Benchmark-Übersicht

GigaOm verwendete das HTTP-Lasttesttool Vegeta zum Generieren von Anfragen (API-Aufrufen) und maß die Latenz – die Zeit, die zum Zurücksenden der Antwort auf einen API-Aufruf benötigt wurde – die das API-Gateway bei verschiedenen Anzahlen von Anfragen pro Sekunde (RPS) einführte, was GigaOm als „Angriffsraten“ bezeichnet. GigaOm führte Testläufe mit Angriffsraten von beginnend 1.000 RPS und hochskalierend auf 5.000, 10.000, 20.000 usw. durch, bis Vegeta Fehlerstatuscodes meldete. Jeder Testlauf dauerte 60 Sekunden und wurde dreimal wiederholt. Wie in den folgenden Diagrammen gezeigt, hat GigaOm die Latenzen beim 50., 90., 95., 99., 99,9. und 99,99. Perzentil erfasst und auch die längste während des Testlaufs beobachtete Latenz aufgezeichnet ( Max in den Diagrammen).

Ergebnisse: NGINX im Vergleich Kong-Unternehmen

GigaOm hat zwei Benchmarks durchgeführt, bei denen NGINX Plus (bereitgestellt mit NGINX Controller) und Kong Node (bereitgestellt mit Kong Enterprise) verglichen wurden. Im ersten Benchmark gab es einen einzelnen Worker-Knoten (eine Instanz von NGINX Plus oder Kong Node). Im zweiten gab es drei Arbeitsknoten, deren Last durch NGINX Open Source im Round-Robin-Modus ausgeglichen wurde. (GigaOm betont, dass die Verwendung von NGINX Open Source als Lastenausgleich keinen Vorteil für NGINX Plus gebracht hat, und sogar Kong empfiehlt es als Lastenausgleich für geclusterte Kong Node-Instanzen.)

Wie die folgenden Grafiken zeigen, ist der Latenzunterschied zwischen NGINX und Kong bis zum 99. Perzentil vernachlässigbar; ab diesem Punkt beginnt die Latenz von Kong exponentiell zu steigen. Beim 99,99. Perzentil beträgt die Latenz von Kong in den beiden Benchmarks jeweils das Dreifache bzw. Doppelte von NGINX.

Das 99. Perzentil ist ein guter Mindestwert, um eine API als Echtzeit-API zu definieren, GigaOm weist jedoch darauf hin, dass es bei realen Bereitstellungen „extrem wichtig“ ist, bei höheren Perzentilen wie dem 99,9. und 99,99. eine niedrige Latenz aufrechtzuerhalten. Im Bericht heißt es:

Die Latenzergebnisse neigen dazu, im Laufe der Zeit multimodal zu sein, wobei die Spitzen der Spitzen „Probleme“ bei den Reaktionszeiten darstellen.

Diese Schluckaufe sind wichtig. Wenn die mittlere Reaktionszeit oder Latenz weniger als 30 ms beträgt, es aber zu Unterbrechungen mit einer Latenz von einer Sekunde oder mehr kommt, hat dies tatsächlich einen kumulativen Effekt auf das nachfolgende Benutzererlebnis. Wenn Sie beispielsweise einen Fast-Food-Drive-In besuchen, wo die durchschnittliche Wartezeit für das Essen 1 Minute beträgt, würden Sie wahrscheinlich denken, dass dies ein gutes Kundenerlebnis ist. Was aber, wenn der Kunde vor Ihnen ein Problem mit seiner Bestellung hat und die Lösung 10 Minuten dauert? Ihre Wartezeit würde tatsächlich 11 Minuten betragen. Da Ihre Anfrage erst nach dem Problem eintraf, kann die Verzögerung des verzögerten 99,99. Perzentils auch zu Ihrer Verzögerung werden.

Die negativen Auswirkungen ungewöhnlich großer Latenzen bei hohen Perzentilen werden bei verteilten Anwendungen noch deutlicher, da eine einzelne Client-Anforderung tatsächlich mehrere nachgelagerte API-Aufrufe auslösen kann. Angenommen, eine Client-Anforderung erzeugt 10 API-Aufrufe an ein Subsystem mit einer Wahrscheinlichkeit von 1 %, dass es langsam reagiert. Es lässt sich mathematisch zeigen, dass daher eine Wahrscheinlichkeit von fast 10 % besteht, dass die eine Client-Anforderung von einer langsamen Antwort betroffen ist. Ausführliche Informationen zur Berechnung finden Sie unter „Wer hat meine Latenz des 99. Perzentils verschoben?“

Abbildung 1 zeigt die Ergebnisse für die Angriffsrate von 30.000 RPS mit einem einzelnen Arbeitsknoten. Beim 99,99. Perzentil ist die Latenz von Kong mehr als dreimal so hoch wie die von NGINX und überschreitet den Schwellenwert von 30 ms für Echtzeit-APIs. Im Gegensatz dazu erreicht NGINX Plus bei jedem Perzentil Echtzeitlatenz – selbst die höchste aufgezeichnete ( maximale ) Latenz von 13 ms liegt bei weniger als der Hälfte des Echtzeitschwellenwerts.

Abbildung 2 zeigt sehr ähnliche Ergebnisse für den Benchmark mit drei Worker-Knoten, ebenfalls bei einer Angriffsrate von 30.000 RPS. Interessanterweise übertrifft Kong NGINX beim 99. und 99,9. Perzentil, erleidet jedoch erneut einen enormen Latenzanstieg beim 99,99. Perzentil und erreicht diesmal eine Latenz, die etwa doppelt so hoch ist wie die von NGINX. Wie im ersten Benchmark bleibt NGINX bei allen Perzentilen unter der Echtzeitschwelle von 30 ms.

Eine weitere Möglichkeit, die Leistung eines API-Gateways zu messen, besteht darin, die maximale RPS zu bestimmen, die es mit 100 % Erfolg verarbeiten kann (keine 5xx oder429 [Zu viele Anfragen] -Fehler) und eine Latenz von unter 30 ms bei allen Perzentilen, sowohl bei der Einzelknoten- als auch bei der Dreiknotenkonfiguration. Abbildung 3 zeigt, wie NGINX durch diese Maßnahme 50 % höhere RPS als Kong aufrechterhält: 30.000 gegenüber 20.000.

Ergebnisse: NGINX im Vergleich Kong Cloud und Amazon API Gateway

Im dritten Satz von Benchmarks verglich GigaOm NGINX Plus mit Kong Cloud und Amazon API Gateway. GigaOm betont, dass ein direkter Vergleich höchst problematisch ist, da Kong Cloud und Amazon API Gateway vollständig verwaltete SaaS-Angebote sind, während NGINX Controller ein PaaS-Angebot ist und derzeit nicht als SaaS verfügbar ist. Insbesondere werden bei keinem der SaaS-Angebote der Instanztyp, die Rechenleistung, der Speicher oder die Netzwerkfunktionen angegeben, die es nutzt. Daher musste GigaOm die für NGINX Plus vorzunehmenden vergleichbaren Einstellungen so gut wie möglich schätzen.

Selbst wenn man den Vergleich mit NGINX Plus außer Acht lässt, wird sofort klar, dass die SaaS-Angebote in keinem der getesteten Perzentilen APIs in Echtzeit bereitstellen können, nicht einmal bei der zweitniedrigsten Angriffsrate (5.000 RPS), die in Abbildung 4 dargestellt ist. Beim 50. Perzentil beträgt die Latenz der SaaS-Angebote bereits mehr als das Siebenfache des Grenzwertes von 30 ms. Beim 99,99. Perzentil überschreitet sie diesen Grenzwert um mehr als 8.000 %. Die offensichtliche Schlussfolgerung ist, dass es keine Bedingungen gibt, unter denen Kong Cloud oder Amazon API Gateway eine 100-prozentige Erfolgsquote mit einer Latenz von unter 30 ms erzielen.

Validierung von NGINX als einzige Echtzeit-API-Lösung

Zusammenfassend ist NGINX die einzige von GigaOm getestete Lösung, die die Standards der Echtzeit-API-Verarbeitung erfüllt und bei jedem Perzentil eine Latenz von weniger als 30 ms erreicht. Kong Enterprise erreicht eine Echtzeitleistung im 99. Perzentil, seine Latenz steigt bei höheren Perzentilen jedoch erheblich an, sodass es für Produktionsumgebungen, die auch nur ein moderates Volumen an Echtzeit-API-Verarbeitung erfordern, ungeeignet ist. Keine der getesteten SaaS-Lösungen kann als Echtzeitlösung eingestuft werden.

Der GigaOm-Bericht bestätigt sowohl unsere bisherigen Benchmarks als auch das, was wir von unseren Kunden hören. NGINX Plus ist das schnellste API-Gateway auf dem Markt und die einzige API-Lösung, die in allen Perzentilen eine Latenz von weniger als 30 ms aufrechterhalten kann. Und wenn Sie es mit dem NGINX-Controller koppeln, erhalten Sie Zugriff auf eine API-Verwaltungslösung mit einzigartigem Aufbau, bei der aufgrund der sorgfältigen Entkopplung keinerlei Auswirkungen auf die Leistung der API-Gateway-Datenebene (NGINX-Plus) von der API-Verwaltungssteuerungsebene (NGINX-Controller) auftreten.

Sie können Ihre eigene API-Leistung mit unserem Latenzmesstool rtapi testen. Probieren Sie es aus und setzen Sie sich mit uns in Verbindung, um zu besprechen, wie wir Ihnen dabei helfen können, Ihre APIs in Echtzeit bereitzustellen.