Blog
DEX verarbeitet 100.000 RPS: Autoscaling-Engine für PancakeSwap

DEX verarbeitet 100.000 RPS: Autoscaling-Engine für PancakeSwap

Daniel Yavorovych
February 29, 2024

Dies ist eine Geschichte darüber, wie PancakeSwap dank seiner hohen Verfügbarkeit, verbesserten UX und seines Autoscaling-Herzens zu einem der größten DEX-Unternehmen der Welt wurde.

Über PancakeSwap

PancakeSwap ist eine dezentrale Börse (DEX), die im September 2020 auf der Binance Smart Chain (BSC) eingeführt wurde. Sie wurde zu einem der führenden DEXs auf der BSC und gewann aufgrund der hohen Gasgebühren für Ethereum, die im Zusammenhang mit ihrer Markteinführung anfielen, erheblich an Bedeutung.

Diese Plattform wurde schnell berühmt dank niedriger Gebühren, schnellem Transaktionsaustausch, vielfältigen Token-Angeboten, einer benutzerfreundlichen Oberfläche, intelligentem Marketing und kundenorientiertem Support. Als die Anzahl der Benutzer dieses DEX und der Liquiditätspool zunahmen, wurde die gesamte Plattform als zuverlässiger, sicherer und stabiler angesehen. Hier ist die positive Feedback-Schleife der Träume eines jeden DeFi-Projekts!

Aber was ging im Inneren von PancakeSwap vor sich?

Die positive Aufmerksamkeit von Binance, das Abhalten von Krypto-Events wie IFO und sogar einfache alltägliche Benutzeraktivitäten begannen, die Belastungsgrenzen des Datenverkehrs herauszufordern und zu überschreiten. Gleichzeitig änderte die einfache Skalierung der Servermenge — die Überversorgung — nicht viel an der Situation, da die gigantischen Ressourcen, die gekauft wurden, um die Verkehrsspitzen abzudecken, in den regulären Perioden ungenutzt blieben.

PancakeSwap sollte für seine Kunden zuverlässig bleiben, indem es dieses Problem löst.

Kryptohändler werden nicht warten, bis Ihr Server nach einem Ausfall wieder auf die Beine kommt. Sie öffnen X oder Reddit und starten einen Thread über 1000 Gründe, warum Sie diese oder jene Plattform nicht für den Handel nutzen sollten. Das will jeder DEX vermeiden. Die Leute machen sich Sorgen um ihr Geld, und es ist natürlich, dass sie die höchsten Verfügbarkeitserwartungen für Handelsplattformen wie PancakeSwap haben.

Um diese Herausforderung zu meistern, nutzte das Dysnix-Team all seine Erfahrung und seinen Verstand und implementierte einen prädiktiven Kubernetes-Autoscaler namens PredictKube, um PancakeSwap zu unterstützen und es stabiler zu machen, jederzeit verfügbar zu sein und den Verkehr abzuwickeln. Bei dieser Implementierung halfen die Ingenieure PancakeSwap GCP-Ressourcen mit maximalem Gewinn nutzen. PredictKube hat eine Vielzahl von Problemen gelöst, die bei Handelsplattformen und anderen Web3-Projekten häufig auftreten.

Probleme des Wachstums und der Flexibilität

Ineffiziente Skalierung

PancakeSwap verwendete vor dem Treffen mit Dysnix beliebte Lösungen, wie öffentliche Endgeräte, aber sie schnitten nicht gut genug ab. Erstens konnte DEX diese Art von Verbindung aufgrund der Natur der öffentlichen Endpunkte nicht vollständig kontrollieren und sichern. Zweitens haben sie das Problem, das sie mit der Verkehrsbelastung hatten, nicht gelöst. Bei der herkömmlichen Skalierung standen zwei große Herausforderungen an:

  • Wenn der Verkehr stark ansteigt, könnte es für eine effektive Skalierung zu spät sein;
  • In Zeiten mit geringem Verkehr sind Ressourcen möglicherweise unnötig reichlich vorhanden und werden nicht ausreichend genutzt.

Es ist besser, in Erwartung eines erhöhten Datenverkehrs mehr Ressourcen bereitzustellen, als zu reagieren, wenn der Anstieg bereits eintritt. In der Vorbereitungsphase sollte berücksichtigt werden, dass die Bereitstellung jedes neuen Knotens im Normalzustand einige Stunden in Anspruch nimmt.

Warum manuelles Skalieren oder einfache Autoscaling-Methoden nicht ausreichen

Manuelle und automatisierte Skalierung sind in vielen Fällen immer noch anwendbar, jedoch nicht für die DEX-Plattform wie PancakeSwap. Und das ist der Grund:

  • Reaktive Natur: Sie können die Regeln einrichten, die die Skalierung bewirken, aber sie werden ausgelöst, wenn ein bestimmter Schwellenwert erreicht wird, z. B. die CPU-Auslastung. Es gibt keine Möglichkeit, im Voraus zu skalieren.
  • Nichteffizienz: Die Festlegung der Schwellenwerte kann die Über- und Unterversorgung nicht lösen. Selbst die meisterhaftesten Grenzwerte und Regeln für das Hoch- und Herunterskalieren können zum Verlust von Traffic oder zu ineffizienten Ausgaben führen.
  • Manuelles Tuning: Klassisches Autoscaling erfordert häufige Anpassungen, und Ihr Spezialist muss äußerst vorsichtig und aufmerksam darauf achten, wie die Plattform wächst und welche Marktveränderungen bevorstehen.
  • Überraschungen, die nicht den Mustern entsprechen: Bei jedem unerwarteten Ereignis, das eine kritische Last verursacht und nicht in die beschriebenen Skalierungsszenarien fällt, ist die herkömmliche Skalierung hilflos.

Überversorgung

Dies ist ein typischer Zustand vieler Cloud-basierter Projekte. „Wie viel Serverplatz benötige ich im Folgemonat? Wenn ich zu viel nehme, gibt es keine Geld-zurück-Garantie, die mich vor diesem Fehler bewahrt. Wenn ich nicht genug nehme, verliere ich den Verkehr... „— diese Gedanken kommen Ihnen vielleicht bekannt vor.

Die Strategie der Überversorgung zwingt Sie dazu, viele und viele weitere zu kaufen, um jeden Verkehrsfall abzudecken, selbst wenn Sie einen Anstieg pro Monat haben. Wie auf dem Bild unten zahlen Sie immer für Tatsächliche Knoten (rote Linien), während Sie die meiste Zeit fünfmal weniger benötigen.

Dieses Bild ist auch ein Spoiler einer Verkehrsvorhersagefunktion von PredictKube, sodass Sie sehen können RPC aktuell vs. RPC vorhergesagt im Vergleich.

Latenzspitzen

Wenn RPS schnell wächst und die verfügbaren Ressourcen dem nicht gewachsen sind, kommt es zu Latenzspitzen.

Während solcher Episoden ist das System überlastet und nicht verfügbar, Transaktionen können verloren gehen und die Benutzererfahrung sinkt. Um dieses Problem zu lösen, müssen Sie über genügend Ressourcen verfügen und den Datenverkehr so verteilen, dass keine Anzeichen von Verzögerungen in der Schnittstelle und im System insgesamt auftreten. Wenn die Überlastung zu groß ist, ist die Ausfallzeit da; alles sollte neu gestartet werden.

Auswirkungen auf das Geschäft: Verkehrsverlust und unbefristetes Serviceniveau

Diese Herausforderungen standen auf dem Weg zur Entwicklung des PancakeSwap. Die schlechte Benutzererfahrung, sogar die regelmäßigen Ausfallzeiten und die hohe Latenz können für Tausende von Händlern keine Grundlage für den zuverlässigen DEX sein. Der Verlust von Traffic führt zu unvollendeten, verzögerten oder stornierten Transaktionen. Ein verschwommenes Serviceniveau ist ein vages Versprechen, das niemals das Geld der Leute anzieht.

Und all diese Herausforderungen waren mit PredictKube lösbar.

PredictKube-Implementierung

PredictKube, der proaktive Autoscaler für Kubernetes von Dysnix, arbeitet nach einem KI-Modell und ist mit GCP, Azure und AWS kompatibel. Es hilft, eine Überversorgung zu vermeiden, indem es den Verkehrstrend vorhersagt und die Ressourcen im Voraus ausgleicht. Es ist einfach, anpassbar, schnell erlernbar und anpassungsfähig.

PredictKube Prediction in Aktion

Im Kern erweitert es die GKE-Möglichkeiten vollständig und umfasst Kubeflow-, TensorFlow- und ElasticSearch-Funktionen.

Komponenten der PredictKube-Lösung

  • Lastprognose für proaktive Skalierung

Diese Lastprognose basiert auf zwei Arten von Daten.

Erstens ermöglichen uns historische Daten, den üblichen Verkehrstrend vorherzusagen. Zweitens können wir anhand von Geschäftskennzahlen (aus mehreren Quellen) unvorhersehbare Ereignisse erraten, indem wir Indikatoren berücksichtigen, die nichts mit dem Verkehr zu tun haben.

Somit decken die prädiktive Skalierung und die ereignisbasierte Skalierung alle Fälle ab, die verfolgt und abgedeckt werden müssen, um proaktiv auf die Laständerung reagieren zu können.

Das Beispiel für Geschäftskennzahlen, die zu einer Verkehrsbelastung führen
  • Kontinuierliche Größenoptimierung des Clusters für die aktuelle Last

Dieser Prozess basiert auf einem ständigen Ausgleich der Ressourcen für die aktuelle und bevorstehende Last. Der gesamte Knoten benötigt Zeit, um gestartet zu werden. Je nach Prognose beginnt das Setup also ernsthaft im Voraus. Das Herunterfahren nimmt weniger Zeit in Anspruch, muss aber pünktlich erfolgen. Außerdem verfolgt das System die Gesundheitsindikatoren für jeden Knoten. Wenn der Knoten langsamer wird, weil er zu überlastet oder überladen ist, wechselt der Verkehr automatisch zu einem fehlerfreien Knoten, und der langsame Knoten wird bereinigt.

  • Auswahl des optimalen Instanztyps

Optimale Instanztypen beeinflussen die Geschwindigkeit der Verkehrsverarbeitung und die Gesamtproduktivität. Abhängig von der Verkehrssituation, der Art der Belastung und dem vorhergesagten Muster können die Instanzen leicht von einem Typ auf einen anderen umgestellt werden, um den optimalen Typ zu wählen (der am besten geeignete und gleichzeitig kostengünstigste). Dies ist ebenfalls ein automatisierter Prozess

Problem behoben: Happy Crypto Bunny mit der niedrigstmöglichen Latenz

Ergebnisse der PredictKube-Implementierung für PancakeSwap in Zahlen:

  • Die Latenz wurde von ~400-500 ms auf ~80 ms verringert. Es bleibt bei jedem Ladevorgang, bei jedem IFO oder bei anderen Ereignissen gleich.
  • Wir haben die Infrastruktur immer verfügbar gemacht und sogar 100.000 RPS bewältigt.
  • Die Kosten für die Cloud-Rechnung wurden um mehr als 50% gesenkt.
PredictKube wurde im Februar implementiert

Dank der gelösten Probleme wie Über- und Unterversorgung, termingerechte Skalierung, Autorotation von Knoten und automatische Auswahl der am besten geeigneten Knoten schmolz die Cloud-Rechnung dahin, bis sie optimal war.

Ein weiterer netter Bonus ist, dass PredictKube kein Drittanbieterdienst ist. Es ist eher ein Implantat, das alle Skalierungsmöglichkeiten erweitert. Einmal eingerichtet, lernt das KI-Modell weiter aus den erlaubten Daten und wird noch präziser. Je nach Markt- und Plattformstatus und dem Erscheinen neuer Technologien wird PredictKube auch ein weiteres Update erhalten.

Bonuseffekte des implementierten prädiktiven Autoscalers

Die Implementierung des Tools zur prädiktiven Autoskalierung ist eine Belohnung für die vorsichtige und akribische Arbeit mit Datenströmen aller Art innerhalb und außerhalb der Infrastruktur. Nur wenn Sie über genügend Daten über Ihre verkehrsorientierte Erfassung aller Treffer und Anfragen verfügen, können Sie dem Modell genügend „Nahrung“ geben, damit es effizient und wirklich hilfreich wird. Ohne Daten wird es immer noch an die Primärdaten angepasst, mit denen wir es trainiert haben.

Daher ist es eine Grundvoraussetzung für die Durchsetzung Ihrer IT-Infrastruktur mit einem Autoscaling-Tool, Ihre Daten kristallklar und übersichtlich zu halten.

Das technische Team hinter der Lösung: Die direkte Rede von CTO

Die Idee eines solchen Tools kam uns in den Köpfen, als Dysnix an Projekten arbeitete wie zkSync. Manchmal halfen einfache Algorithmen nicht bei der korrekten Skalierung, also mussten wir etwas anderes erfinden. Sicher, es gibt Projekte, bei denen Sie keine prädiktive Skalierung benötigen. Es reicht aus, ein paar Skalierungsregeln hinzuzufügen und dem System mitzuteilen, was im Falle einer Verkehrsspitze zu tun ist.

Wir haben begonnen, ein Expertenteam zusammenzustellen, um eine Lösung zu finden, die unter unsicheren Umständen ein zuverlässiges Ergebnis liefert.

Sin embargo, no era un equipo grande: un arquitecto, dos ingenieros líderes de DevOps, un ingeniero senior de DevOps, un desarrollador líder de IA y dos de sus asistentes. Juntos, logramos crear y enseñar el modelo central de IA que se volvió fácilmente ajustable y omnívoro para los datos sobre el volumen de tráfico y las métricas comerciales. Planeamos hacer de PredictKube una solución independiente para que el proyecto la instalara y configurara de una vez por todas, manteniéndonos independientes de nosotros como creadores.

Neben unseren Kunden arbeiteten wir eng mit den KEDA-Gemeinschaft, sammelt Feedback von ihnen und passt PredictKube entsprechend an. Solche Produkte sind also niemals die persönliche Leistung eines Unternehmens, sondern eher die gemeinsame Schaffung einer fürsorglichen Gemeinschaft.

Langfristige und verzögerte Auswirkungen von Autoscaling für Web3-Projekte

Jetzt ist Autoscaling ein unvermeidlicher Bestandteil des zukünftigen Vial-Web3-Projekts. Von der Senkung des Energieverbrauchs und des CO2-Fußabdrucks bis hin zu einfachen Kostensenkungen — jeder Grund motiviert zur Einrichtung einer Skalierung. Einige Auswirkungen der Skalierung solcher Projekte reichen über die nächste Zukunft hinaus, sollten aber erwähnt werden.

Mögliche langfristige Auswirkungen der implementierten Autoskalierung

  • Verstärkte Akzeptanz
    Eine effiziente Skalierungslösung wird dazu beitragen, mehr Benutzer und Transaktionen ohne umfangreiches technisches Wachstum abzuwickeln.
  • Bewusstsein für Ökosysteme
    Skalierbare Plattformen lassen sich einfacher integrieren und mit anderen Diensten verknüpfen. Die Flexibilität und der ressourcenschonende Kern solcher Projekte können für die Partner am attraktivsten sein, während gleichzeitig eine gemeinsame technische Landschaft aufgebaut wird.
  • Bessere Sicherheit
    Richtige Skalierungslösungen, insbesondere Layer-2-Lösungen, erfordern robuste Sicherheitsmechanismen. Durch die automatische Skalierung werden die Gründe für menschliches Versagen verringert. Somit ist die allgemeine Sicherheit viel besser.
  • Wettbewerbsvorteil
    Da die Projekte gut skalierbar sind, übertreffen sie Wettbewerber, die mit Skalierbarkeitsproblemen zu kämpfen haben.
  • Kosteneffizienz
    Optimierte Projekte geben keinen Cent für ineffizient verteilte Ressourcen aus.

Späte Effekte, die Sie nach der Implementierung von Autoscaling erwarten können

Creciente descentralización: la optimización completa de los recursos podría afectar la distribución de roles en la cadena de bloques. Por ejemplo, los proyectos dependen de un conjunto más pequeño de validadores o nodos para lograr eficiencia, que pueden centralizar el control. Sin embargo, como blockchain demuestra características de autorregulación, este efecto se puede evitar.

La deuda técnica apareció debido a una implementación rápida y descuidada: la implementación de soluciones rápidas para la escalabilidad puede generar deuda técnica. Las soluciones listas para usar funcionan para el proyecto sin necesidad de modificaciones ni personalización. El aumento de la deuda técnica siempre genera gastos adicionales y una pérdida de enfoque en la dirección principal del crecimiento.

Desafíos de interoperabilidad para proyectos con múltiples conexiones externas: a medida que los proyectos implementan su solución de escalamiento personalizada, la interoperabilidad entre plataformas o cadenas de bloques puede convertirse en un desafío.

Dependencia de soluciones de terceros: Cada vez que delegas una parte vital de tu arquitectura al proveedor de servicios, a la larga te llevas un dolor de cabeza. No puede estar seguro de la estabilidad y disponibilidad del 100% de cualquier solución que no esté totalmente bajo su control.

Por eso es más seguro mantener todas las soluciones de escalado automático implementadas en el núcleo de su proyecto.

Da Autoscaling zu einem unverzichtbaren Feature wird, wird jedes Web3-Abenteuer realisierbarer, stabiler und erwartungsvoller. Wenn Sie Lösungen wie PredictKube ausprobieren, können Sie herausfinden, was für Ihren Fall am besten geeignet ist.

Daniel Yavorovych
CTO and Co-founder at Dysnix
Brainpower and problem-solver, meditating and mountain hiking.
Table of content
Related articles
Subscribe to the blog
The best source of information for customer service, sales tips, guides, and industry best practices. Join us.
Thanks for subscribing to the Dysnix blog
Now you’ll be the first to know when we publish a new post
Got it
Oops! Something went wrong while submitting the form.
In die Zwischenablage kopiert
Fügen Sie es ein, wo immer Sie möchten