__wf_reserved_heredar
Blog__wf_reserved_heredar
DEX gestiona 100.000 RPS: motor de escalado automático para PancakeSwap
__wf_reserved_heredar

DEX gestiona 100.000 RPS: motor de escalado automático para PancakeSwap

__wf_reserved_heredar
__wf_reserved_heredar
Daniel Yavorovych
February 29, 2024

Esta es una historia sobre cómo PancakeSwap se convirtió en uno de los mayores DEX del mundo gracias a su alta disponibilidad, su experiencia de usuario mejorada y su capacidad de escalado automático.

Acerca de PancakeSwap

PancakeSwap es un intercambio descentralizado (DEX) lanzado en Binance Smart Chain (BSC) en septiembre de 2020. Se convirtió en uno de los principales DEX del BSC y ganó un impulso significativo debido a las altas tarifas de gas de Ethereum en torno a su lanzamiento.

Esta plataforma se hizo famosa rápidamente gracias a las bajas comisiones, el rápido intercambio de transacciones, las diversas ofertas de tokens, una interfaz fácil de usar, un marketing brillante y un soporte centrado en el cliente. A medida que crecía el número de usuarios de este DEX y del fondo de liquidez, toda la plataforma se consideró más fiable, segura y estable. ¡Este es el ciclo de retroalimentación positiva de los sueños de cualquier proyecto de Defi!

Pero, ¿qué pasaba desde dentro de PancakeSwap?

La atención positiva de Binance, la celebración de eventos criptográficos como IFO e incluso la simple actividad diaria de los usuarios comenzaron a desafiar y desbordar los límites de carga de tráfico. Al mismo tiempo, el simple escalamiento de la cantidad de servidores (el sobreaprovisionamiento) no cambió mucho la situación, ya que los enormes recursos adquiridos para cubrir los picos de tráfico no se utilizaron durante los períodos regulares.

PancakeSwap debería seguir siendo confiable para sus clientes al resolver este problema.

Los comerciantes de criptomonedas no esperarán a que su servidor se recupere después de haber estado inactivo. Abren X o Reddit e inician un hilo sobre 1000 razones por las que no debe usar esta o aquella plataforma para operar. Eso es lo que cada DEX quiere evitar. La gente se preocupa por su dinero y es natural que tengan las expectativas de disponibilidad más altas para plataformas de negociación como PancakeSwap.

Para superar este desafío, el equipo de Dysnix utilizó toda su experiencia e ingenio e implementó un escalador automático predictivo de Kubernetes llamado PredictKube para soportar PancakeSwap y hacerlo más estable, disponible en cualquier momento y capaz de gestionar el tráfico. Con esta implementación, los ingenieros ayudaron a PancakeSwap usa los recursos de GCP con el máximo beneficio. PredictKube resolvió una gran cantidad de problemas que son comunes en las plataformas de negociación y otros proyectos de Web3.

Problemas de crecimiento y flexibilidad

Escalado ineficiente

PancakeSwap usó soluciones populares antes de conocer Dysnix, como puntos finales públicos, pero no funcionaban lo suficientemente bien. En primer lugar, DEX no podía controlar ni proteger por completo este tipo de conexión debido a la naturaleza de los puntos finales públicos. En segundo lugar, no resolvieron el problema que tenían con la carga de tráfico. La escalabilidad tradicional se enfrentaba a dos desafíos principales:

  • Cuando el tráfico aumente, puede que sea demasiado tarde para escalar de manera efectiva;
  • Durante los períodos de poco tráfico, los recursos pueden ser innecesariamente abundantes y subutilizados.

Es preferible asignar más recursos en previsión del aumento del tráfico en lugar de reaccionar cuando el aumento ya se produce. El período de anticipación debe tener en cuenta que cada nodo nuevo tarda unas horas en implementarse en el estado normal.

Por qué el escalado manual o los métodos simples de escalado automático no funcionan

El escalado manual y automatizado sigue siendo aplicable en muchos casos, pero no para la plataforma DEX como PancakeSwap. Y es por eso que:

  • Naturaleza reactiva: puede configurar las reglas que provocarán el escalado, pero se activarán al alcanzar algún umbral, como la utilización de la CPU. No hay forma de escalar por adelantado.
  • Ineficiencia: Establecer los umbrales no puede resolver el sobreaprovisionamiento y el subaprovisionamiento. Incluso el conjunto más avanzado de límites y reglas para aumentar y reducir la escala puede provocar una pérdida de tráfico o gastos ineficientes.
  • Sintonización manual: El escalado automático clásico requiere ajustes frecuentes, y su especialista debe tener mucho cuidado y estar atento al crecimiento de la plataforma y a los cambios del mercado que están a punto de producirse.
  • Sorpresas fuera de lo habitual: Para cualquier evento inesperado que cause una carga crítica que no se ajuste a los escenarios de escalado descritos, el escalado tradicional no servirá de nada.

Sobreaprovisionamiento

Este es un estado típico de muchos proyectos basados en la nube. «¿Cuánto espacio en el servidor necesitaré el mes siguiente? Si uso demasiado, no hay garantía de devolución del dinero que me salve de cometer este error. Si no tomo lo suficiente, perderé el tráfico...», es posible que conozcas estas ideas.

La estrategia de sobreaprovisionamiento lo obliga a comprar lotes y muchos más para cubrir cualquier caso de tráfico, incluso si tiene un pico al mes. Como en la imagen de abajo, siempre pagas Nodos reales (líneas rojas), mientras que la mayoría de las veces necesitas 5 veces menos.

Esta imagen también es un spoiler de una función de predicción de tráfico de PredictKube para que puedas ver RPC actual vs. RPC pronosticado en comparación.

Picas de latencia

Cuando el RPS crece rápidamente y los recursos disponibles no pueden hacer frente a ello, se producen picos de latencia.

Durante estos episodios, el sistema se congestiona y no está disponible, las transacciones pueden perderse y la experiencia del usuario disminuye. Para resolver este problema, es necesario disponer de recursos suficientes y distribuir los flujos de tráfico para evitar cualquier signo de retraso en la interfaz y en el sistema en general. Si la congestión es demasiado intensa, el tiempo de inactividad ya está aquí; todo debería volver a ponerse en marcha.

Efectos en las empresas: pérdida de tráfico y nivel de servicio indefinido

Estos desafíos estaban en camino al desarrollo de PancakeSwap. La mala experiencia de usuario, incluso los tiempos de inactividad periódicos, y la alta latencia no pueden ser la base de un DEX confiable para miles de operadores. La pérdida de tráfico provoca transacciones incompletas, retrasadas o canceladas. Un nivel de servicio borroso es una promesa vaga que nunca atrae el dinero de las personas.

Y todos estos desafíos se podían resolver con PredictKube.

Implementación de PredictKube

PredictKube, el escalador automático proactivo para Kubernetes creado por Dysnix, funciona en un modelo de IA y es compatible con GCP, Azure y AWS. Ayuda a evitar el sobreaprovisionamiento al predecir la tendencia del tráfico y equilibrar los recursos con antelación. Es fácil, personalizable, de aprendizaje rápido y adaptable.

La predicción de PredictKube en acción

Básicamente, amplía por completo las posibilidades de GKE al incorporar las funciones de Kubeflow, TensorFlow y ElasticSearch.

Componentes de la solución PredictKube

  • Predicción de carga para una escala proactiva

Esta predicción de carga se basa en dos tipos de datos.

En primer lugar, los datos históricos nos permiten predecir la tendencia habitual del tráfico. En segundo lugar, los datos de métricas empresariales (fuentes múltiples) nos permiten adivinar los eventos impredecibles teniendo en cuenta los indicadores no relacionados con el tráfico.

Por lo tanto, el escalado predictivo y el escalado basado en eventos cubren todos los casos que deben rastrearse y cubrirse para reaccionar de manera proactiva ante el cambio de carga.

El ejemplo de las métricas empresariales que provocan la carga de tráfico
  • Optimización continua del tamaño del clúster para la carga actual

Este proceso se basa en el equilibrio constante de los recursos para la carga actual y futura. El nodo completo necesita tiempo para lanzarse, por lo que, según la predicción, la configuración comienza con mucha antelación. El cierre requiere menos tiempo, pero debe hacerse justo a tiempo. Además, el sistema rastrea los indicadores de estado de cada nodo. Si el nodo se ralentiza porque está demasiado sobrecargado o desordenado, el tráfico cambia automáticamente a uno en buen estado y se limpia el nodo lento.

  • Selección del tipo óptimo de instancias

Los tipos óptimos de instancias influyen en la velocidad del procesamiento del tráfico y en la productividad general. Según la situación del tráfico, la naturaleza de la carga y el patrón previsto, las instancias se pueden cambiar fácilmente de un tipo a otro para que sean óptimas (las que mejor se adapten y sean más baratas al mismo tiempo). Este también es un proceso automatizado

Problema solucionado: conejito criptográfico feliz con la menor latencia posible

Resultados de la implementación de PredictKube para PancakeSwap en cifras:

  • La latencia se redujo de ~400-500 mseg a ~80 mseg. Permanece igual para cualquier carga, durante cualquier IFO u otros eventos.
  • Hicimos que la infraestructura estuviera siempre disponible, capaz de soportar hasta 100 000 RPS.
  • El costo de la factura de la nube se redujo en más de un 50%.
PredictKube se implementó en febrero

Gracias a los problemas resueltos de aprovisionamiento excesivo o insuficiente, escalamiento justo a tiempo, rotación automática de los nodos y selección automática de los nodos que mejor se ajustaban, la factura de la nube se redujo hasta que pasó a ser óptima.

Otra buena ventaja es que PredictKube no es un servicio de terceros. Es más bien un implante que amplía todas las posibilidades de escalado. Una vez establecido, el modelo de inteligencia artificial interno continúa aprendiendo de los datos permitidos y se vuelve aún más preciso. En función del estado del mercado y de la plataforma y de la aparición de nuevas tecnologías, PredictKube también recibirá otra actualización.

Efectos adicionales del escalador automático predictivo implementado

La implementación de la herramienta de escalado automático predictivo es una recompensa por el trabajo cauteloso y meticuloso con flujos de datos de todo tipo dentro y fuera de la infraestructura. Solo si dispones de suficientes datos sobre tu tráfico y una recopilación atenta de cada visita y solicitud, puedes ofrecer suficiente «información» para que el modelo sea eficaz y realmente útil. Sin datos, seguirá adaptándose a los datos principales con los que lo entrenamos.

Por lo tanto, mantener sus datos nítidos y organizados es un requisito previo para reforzar su infraestructura de TI con una herramienta de escalado automático.

El equipo técnico detrás de la solución: discurso directo del CTO

La idea de una herramienta de este tipo apareció en nuestras cabezas mientras Dysnix trabajaba en proyectos como ZKSync. A veces, los algoritmos simples no ayudaban a escalar correctamente, así que tuvimos que inventar algo diferente. Por supuesto, hay proyectos en los que no se necesita ningún escalamiento predictivo; basta con añadir unas cuantas reglas de escalado e indicar al sistema qué hacer en caso de que se produzca un pico de tráfico.

Empezamos a reunir un equipo de expertos para crear una solución que diera un resultado fiable en circunstancias de incertidumbre.

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.

Además de nuestros clientes, trabajamos en estrecha colaboración con Comunidad KEDA, recopilando sus comentarios y ajustando PredictKube en consecuencia. Por lo tanto, estos productos nunca son el logro personal de una empresa, sino más bien la creación mutua de una comunidad solidaria.

Impactos a largo plazo y retrasados del escalado automático para proyectos Web3

Ahora, el escalado automático es una parte inevitable del futuro proyecto vial Web3. Desde la disminución del consumo de energía y la huella de carbono hasta la simple reducción de costos, cada motivo motiva la creación de la escalabilidad. Algunos efectos de la ampliación de estos proyectos van más allá del futuro próximo, pero deben mencionarse.

Posibles impactos a largo plazo del escalado automático implementado

  • Aumento de la adopción
    Una solución de escalado eficiente ayudará a gestionar más usuarios y transacciones sin un gran crecimiento técnico.
  • Conciencia del ecosistema
    Las plataformas escalables son más fáciles de integrar y entrelazar con otros servicios. La flexibilidad y el uso de los recursos básicos de estos proyectos pueden ser las características más atractivas para los socios, a la vez que crean un panorama técnico mutuo.
  • Mejor seguridad
    Las soluciones de escalado adecuadas, especialmente las soluciones de capa 2, requieren mecanismos de seguridad sólidos. Con el escalado automático, se reducen las causas de los errores humanos. Por lo tanto, la seguridad general es mucho mejor.
  • Ventaja competitiva
    Como los proyectos pueden escalar bien, superan a los competidores que tienen problemas de escalabilidad.
  • Eficiencia de costes
    Los proyectos optimizados no gastan ni un centavo en recursos distribuidos de manera ineficiente.

Efectos retardados que cabe esperar tras implementar el escalado automático

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.

Con el escalado automático convirtiéndose en una función imprescindible, cualquier aventura de Web3 será más viable, estable y esperada. Probar soluciones como PredictKube te ayudará a descubrir qué es lo que mejor se adapta a tu caso.

__wf_reserved_heredar
Daniel Yavorovych
CTO and Co-founder at Dysnix
Brainpower and problem-solver, meditating and mountain hiking.
Tabla de contenido
Artículos relacionados
Suscríbete al blog
La mejor fuente de información para el servicio al cliente, consejos de ventas, guías y mejores prácticas de la industria. Únase a nosotros.
Gracias por suscribirte al blog de Dysnix
Ahora serás el primero en enterarte cuando publiquemos un nuevo post
Lo tengo
¡Uy! Algo salió mal al enviar el formulario.
__wf_reserved_heredar
Copiado al portapapeles
Pégalo donde quieras