Backpressure no es un bug: es una característica para construir sistemas resilientes

Backpressure es la negociación oculta entre productores y consumidores. dominarlo, y sus sistemas a escala graciosamente.

Backpressure es la negociación oculta entre productores y consumidores. dominarlo, y sus sistemas a escala graciosamente.

La cita anterior sugiere que incluso las barricadas más robustas y bien diseñadas no pueden soportar las fuerzas destructivas de una inundación descontrolada y descontrolada.Sistema distribuido, un llamador no controlado a menudo puede abrumar todo el sistema y causar cascadasfracasos.

En AArtículo anterior, I wrote about how a retry storm has the potential to take down an entire service if proper guardrails are not in place. Here, I'm exploring when a service should consider applying backpressure to its callers, how it can be applied, and what callers can do to deal with it.

Backpressure

Como el nombre mismo sugiere, la retropresión es un mecanismo en los sistemas distribuidos que se refiere a la capacidad de un sistema de refrescar la velocidad a la que se consumen o producen los datos para evitar la sobrecarga de sí mismo o de sus componentes descendentes.Un sistema que aplica la retropresión a su llamador no siempre es explícito, como en forma de refrescar o derramar carga, pero a veces también implícito, como ralentizar su propio sistema añadiendo latencia a las solicitudes servidas sin ser explícito acerca de ello.

Tanto la presión de retroceso implícita como explícita tienen la intención de ralentizar el llamador, ya sea cuando el llamador no se comporta bien o el servicio en sí es poco saludable y necesita tiempo para recuperarse.

Need for Backpressure

En este ejemplo, estamos construyendo un servicio de planos de control con tres componentes principales: un frontend donde se reciben las solicitudes de los clientes, una cola interna donde se bufferan las solicitudes de los clientes y una aplicación de consumidores que lee los mensajes de la cola y escribe a una base de datos para persistencia.

Producer-Consumer Mismatch

Considere un escenario donde los actores/clientes están golpeando el front end a una tasa tan alta que ya sea la cola interna está llena o el trabajador que escribe a la base de datos está ocupado, lo que conduce a una cola completa. En ese caso, las solicitudes no se pueden enquiar, por lo que en lugar de bajar las solicitudes de los clientes, es mejor informar a los clientes de antemano.

Resource Constraints and Cascading Failures

Imagínese un escenario en el que su cola se acerque al 100% de su capacidad, pero normalmente está en el 50%. Para coincidir con este aumento en la tasa de entrada, aumenta la escala de su aplicación de consumo y comienza a escribir en la base de datos a una tasa más alta. Sin embargo, la base de datos no puede manejar este aumento (por ejemplo, debido a los límites de escritos / segundos) y se rompe.MTTRLa aplicación de la presión de retroceso en los lugares adecuados se vuelve crítica en tales escenarios.

Missed SLAs

Considere un escenario en el que los datos escritos a la base de datos se procesan cada 5 minutos, y otra aplicación escucha para mantenerse actualizada.Ahora, si el sistema no es capaz de cumplir ese SLA por cualquier razón, como la cola está 90% llena y potencialmente toma hasta 10 minutos para borrar todos los mensajes, es mejor recurrir a técnicas de backpressure.

Puede informar a los clientes de que va a perder el SLA y pedirles que lo intenten de nuevo más tarde, o aplicar la presión de retroceso al dejar de lado las solicitudes no urgentes de la cola para cumplir con el SLA para eventos / solicitudes críticas.

Backpressure Challenges

Basándose en lo descrito anteriormente, parece que siempre debemos aplicar la presión de retroceso, y no debería haber ningún debate al respecto.Sideberíamos aplicar la presión de retroceso, pero principalmente en torno aCómoIdentificar los puntos adecuados para aplicar la presión de retroalimentación y los mecanismos para aplicarla que satisfagan las necesidades específicas de servicio / negocio.

La backpressure obliga a un equilibrio entre el rendimiento y la estabilidad, hecho más complejo por el desafío de la predicción de la carga.

Identifying the Backpressure Points

Find Bottlenecks/Weak Links

Algunos pueden soportar y protegerse a sí mismos, y algunos no pueden.Piense en un sistema donde una gran flota de planos de datos (miles de anfitriones) depende de una pequeña flota de planos de control (menos de 5 anfitriones) para recibir configuraciones persistentes en la base de datos, como se destaca en el diagrama anterior.

En este caso, para protegerse, la pequeña flota debe tener mecanismos para aplicar presión de retroceso en el llamador. Otro enlace débil común en la arquitectura son los componentes centralizados que toman decisiones sobre todo el sistema, como los escáneres antientropía. Si fallan, el sistema nunca puede alcanzar un estado estable y puede reducir todo el servicio.

Use System Dynamics: Monitors/Metrics

Otra forma común de encontrar puntos de retroceso para su sistema es tener monitores / métricas adecuadas en su lugar. monitorear continuamente el comportamiento del sistema, incluyendo profundidades de cola, utilización de CPU / memoria y rendimiento de red. Use estos datos en tiempo real para identificar los obstáculos emergentes y ajustar los puntos de retroceso en consecuencia.

Crear una vista agregada a través de métricas o observadores como canarios de rendimiento en diferentes componentes del sistema es otra forma de saber que su sistema está bajo estrés y debe afirmar la presión de retroceso en sus usuarios / llamadores. Estos canarios de rendimiento pueden ser aislados para diferentes aspectos del sistema para encontrar los puntos de estrés. Además, tener un dashboard en tiempo real sobre el uso de recursos internos es otra gran manera de usar la dinámica del sistema para encontrar los puntos de interés y ser más proactivos.

Boundaries: The Principle of Least Astonishment

Las cosas más obvias para los clientes son las áreas de superficie de servicio con las que interactúan. Estas son típicamente APIs que los clientes utilizan para conseguir que sus solicitudes sean atendidas. Este es también el lugar donde los clientes serán menos sorprendidos en caso de retropresión, ya que destaca claramente que el sistema está bajo estrés. Puede ser en forma de throttling o descarga de carga.

El mismo principio se puede aplicar dentro del servicio mismo a través de diferentes subcomponentes e interfaces a través de las cuales interactúan entre sí.Estas superficies son los mejores lugares para ejercer presión de retroalimentación.Esto puede ayudar a minimizar la confusión y hacer que el comportamiento del sistema sea más previsible.

How to Apply Backpressure in Distributed Systems

En la última sección, hablamos de cómo encontrar los puntos de interés adecuados para afirmar la presión de retroceso.Una vez que conocemos esos puntos, aquí están algunas maneras en que podemos afirmar esta presión de retroceso en la práctica:

Configurar un control de flujo explícito

La idea es hacer que el tamaño de la cola sea visible a sus llamantes y permitir que controlen la tasa de llamada basándose en ello. Conociendo el tamaño de la cola (o cualquier recurso que sea una barrera de botella), pueden aumentar o disminuir la tasa de llamada para evitar abrumar el sistema. Este tipo de técnica es especialmente útil cuando varios componentes internos trabajan juntos y se comportan así como pueden sin impactarse mutuamente. La ecuación a continuación se puede utilizar en cualquier momento para calcular la tasa de llamada. Nota: La tasa de llamada real dependerá de varios otros factores, pero la ecuación a continuación debe dar una buena idea.

CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize))

CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize))

Invert Responsibilities

En algunos sistemas, es posible cambiar el orden en el que los llamados no envían explícitamente solicitudes al servicio, pero dejan que la solicitud de servicio funcione por sí misma cuando está lista para servir.Este tipo de técnica da al servicio receptor el control total sobre cuánto puede hacer y puede cambiar dinámicamente el tamaño de la solicitud en función de su último estado.Título Bucketestrategia en la que el servicio receptor llena el token, y que le dice al llamador cuándo y cuánto pueden enviar al servidor.

  # Service requests work if it has capacity

 if Tokens_available > 0: 

             Work_request_size = min (Tokens_available, Work_request_size _max) # Request work, up to a maximum limit 

             send_request_to_caller(Work_request_size) # Caller sends work if it has enough tokens

 

if Tokens_available >= Work_request_size: 

send_work_to_service(Work_request_size)

             Tokens_available = Tokens_available – Work_request_size

# Tokens are replenished at a certain rate

Tokens_available = min (Tokens_available + Token_Refresh_Rate, Token_Bucket_size)

Proactive Adjustments

A veces, sabes de antemano que tu sistema se va a abrumar pronto, y tomas medidas proactivas como pedir al llamante que ralentice el volumen de llamadas y lo aumente lentamente.

Durante ese período, has dejado la cola de todo el trabajo y ahora estás listo para drenarlo para cumplir con tu misión.SLACuando lo drene más rápido que la tasa normal, corre el riesgo de perder los servicios a continuación.Para abordar esto, proactivamente limita los límites del llamador o involucra al llamador para reducir su volumen de llamadas y abrir lentamente las puertas de inundación.

Throttling

Limitar el número de solicitudes que un servicio puede atender y descartar las solicitudes más allá de eso. El Throttling se puede aplicar en el nivel del servicio o en el nivel de la API. Este throttling es un indicador directo de la presión de retroceso para que el llamador ralentice el volumen de llamadas. Puede tomar esto más adelante y hacer el throttling de prioridad o el throttling de equidad para asegurarse de que el menor impacto sea visto por los clientes.

Load Shedding

Throttling apunta a descartar las solicitudes cuando se violen algunos límites predefinidos. Las solicitudes de los clientes todavía pueden descartarse si el servicio se enfrenta al estrés y decide descartar proactivamente las solicitudes que ya ha prometido servir.

Conclusion

La backpressure es un desafío crítico en los sistemas distribuidos que puede afectar significativamente el rendimiento y la estabilidad.Comprender las causas y efectos de la backpressure, junto con técnicas de gestión eficaces, es crucial para construir sistemas distribuidos robustos y de alto rendimiento.Cuando se implementa correctamente, la backpressure puede mejorar la estabilidad, la fiabilidad y la escalabilidad de un sistema, lo que lleva a una mejor experiencia del usuario.

Sin embargo, si se manipula mal, puede erosionar la confianza del cliente e incluso contribuir a la inestabilidad del sistema. Abordar proactivamente la presión de retroalimentación a través de un diseño y monitoreo cuidadosos del sistema es clave para mantener la salud del sistema. Mientras que la implementación de la presión de retroalimentación puede implicar compromisos, como el potencial impacto en la capacidad de paso, los beneficios en términos de la resiliencia general del sistema y la satisfacción del usuario son sustanciales.