Backpressure não é um bug: é uma característica para construir sistemas resilientes

Backpressure é a negociação oculta entre produtores e consumidores. Mestre-o, e seus sistemas escala graciosamente. Ignore-o, e eles quebram sob carga de pico.

Backpressure é a negociação oculta entre produtores e consumidores. Mestre-o, e seus sistemas escala graciosamente. Ignore-o, e eles quebram sob carga de pico.

A citação acima sugere que até mesmo as barragens mais robustas e bem construídas não podem resistir às forças destrutivas de uma inundação descontrolada e descontrolada.Sistema Distribuído, um chamador descontrolado pode muitas vezes sobrecarregar todo o sistema e causar cascatafracassos.

Em AArtigo anterior, Escrevi sobre como uma tempestade de retry tem o potencial de derrubar um serviço inteiro se não estiverem em vigor as vigilâncias adequadas.Aqui, estou explorando quando um serviço deve considerar aplicar backpressure a seus chamadores, como ele pode ser aplicado e o que os chamadores podem fazer para lidar com isso.

Backpressure

Como o próprio nome sugere, backpressure é um mecanismo em sistemas distribuídos que se refere à capacidade de um sistema de gertir a velocidade com que os dados são consumidos ou produzidos para evitar a sobrecarga de si mesmo ou de seus componentes a jusante.Um sistema que aplica backpressure em seu chamador não é sempre explícito, como na forma de gertir ou derramar carga, mas às vezes também implícito, como abrandar seu próprio sistema adicionando latência às solicitações servidas sem ser explícito sobre isso.

Tanto a pressão de retorno implícita como explícita pretendem retardar o chamador, seja quando o chamador não está se comportando bem ou o próprio serviço é insalubre e precisa de tempo para se recuperar.

Need for Backpressure

Neste exemplo, estamos construindo um serviço de plano de controle com três componentes principais: um frontend onde as solicitações do cliente são recebidas, uma fila interna onde as solicitações do cliente são tamponadas e um aplicativo do consumidor que lê mensagens da fila e escreve para um banco de dados para persistência.

Producer-Consumer Mismatch

Considere um cenário em que os atores/clientes estão atingindo o front-end a uma taxa tão alta que a fila interna está cheia ou o trabalhador que escreve para a base de dados está ocupado, levando a uma fila completa.Nesse caso, as solicitações não podem ser encaminhadas, por isso, em vez de descartar as solicitações do cliente, é melhor informar os clientes com antecedência.

Resource Constraints and Cascading Failures

Imagine um cenário em que sua fila está se aproximando de 100% de sua capacidade, mas normalmente é de 50%. Para combinar esse aumento na taxa de entrada, você escala seu aplicativo de consumo e começa a escrever para o banco de dados em uma taxa maior. No entanto, o banco de dados não pode lidar com esse aumento (por exemplo, devido a limites em letras/segundo) e quebra. Esta quebra levará todo o sistema com ele e aumentará o Mean Time To Recover (MTTRA aplicação de backpressure em lugares apropriados torna-se crítica em tais cenários.

Missed SLAs

Considere um cenário em que os dados escritos para o banco de dados são processados a cada 5 minutos, e outro aplicativo escuta para se manter atualizado.Agora, se o sistema não for capaz de atender a esse SLA por qualquer motivo, como a fila sendo 90% cheia e potencialmente levando até 10 minutos para limpar todas as mensagens, é melhor recorrer a técnicas de backpressure.

Você pode informar os clientes que você vai perder o SLA e pedir-lhes para tentar novamente mais tarde, ou aplicar pressão de volta, deixando as solicitações não urgentes da fila para atender ao SLA para eventos / solicitações críticas.

Backpressure Challenges

Com base no que foi descrito acima, parece que devemos sempre aplicar pressão de volta, e não deve haver qualquer debate sobre isso.Se oA pressão deve ser exercida, mas principalmente em tornoComoidentificar os pontos certos para aplicar a pressão de retorno e os mecanismos para aplicá-la que atendam às necessidades específicas do serviço/negócio.

A backpressure força um compromisso entre a capacidade e a estabilidade, tornado mais complexo pelo desafio da previsão de carga.

Identifying the Backpressure Points

Find Bottlenecks/Weak Links

Pense em um sistema onde uma grande frota de planos de dados (milhares de hosts) depende de uma pequena frota de planos de controle (menos de 5 hosts) para receber configurações persistentes no banco de dados, como evidenciado no diagrama acima.

A grande frota pode facilmente sobrecarregar a pequena frota. Neste caso, para se proteger, a pequena frota deve ter mecanismos para aplicar pressão de volta no chamador. Outro elo fraco comum na arquitetura são componentes centralizados que tomam decisões sobre todo o sistema, como scanners antientropia. Se eles falharem, o sistema nunca pode atingir um estado estável e pode derrubar todo o serviço.

Use System Dynamics: Monitors/Metrics

Outra maneira comum de encontrar pontos de backpressure para o seu sistema é ter monitores / métricas apropriadas no lugar. Monitorar continuamente o comportamento do sistema, incluindo profundidades de fila, utilização de CPU / memória e capacidade de rede. Use esses dados em tempo real para identificar entraves emergentes e ajustar os pontos de backpressure em conformidade.

Criar uma visão agregada através de métricas ou observadores como canários de desempenho em diferentes componentes do sistema é outra maneira de saber que seu sistema está sob estresse e deve afirmar pressão de volta em seus usuários / chamadores. Esses canários de desempenho podem ser isolados para diferentes aspectos do sistema para encontrar os pontos de choque.

Boundaries: The Principle of Least Astonishment

As coisas mais óbvias para os clientes são as áreas de superfície de serviço com as quais eles interagem. Estas são tipicamente APIs que os clientes usam para obter suas solicitações atendidas. Este é também o lugar onde os clientes serão menos surpreendidos em caso de pressão de volta, pois destaca claramente que o sistema está sob estresse.

O mesmo princípio pode ser aplicado dentro do próprio serviço em diferentes subcomponentes e interfaces através das quais eles interagem uns com os outros. Essas superfícies são os melhores lugares para exercer pressão de volta. Isto pode ajudar a minimizar a confusão e tornar o comportamento do sistema mais previsível.

How to Apply Backpressure in Distributed Systems

Na última seção, falamos sobre como encontrar os pontos de interesse certos para afirmar a backpressure.Uma vez que conhecemos esses pontos, aqui estão algumas maneiras que podemos afirmar essa backpressure na prática:

Controle de fluxo explícito

A ideia é tornar o tamanho da fila visível para seus chamadores e deixá-los controlar a taxa de chamada com base nisso. Conhecendo o tamanho da fila (ou qualquer recurso que seja uma barreira de garrafas), eles podem aumentar ou diminuir a taxa de chamada para evitar sobrecarregar o sistema. Este tipo de técnica é particularmente útil onde múltiplos componentes internos trabalham juntos e se comportam tão bem quanto podem sem impactar um ao outro. A equação abaixo pode ser usada a qualquer momento para calcular a taxa de chamada. Nota: A taxa de chamada real dependerá de vários outros fatores, mas a equação abaixo deve dar uma boa ideia.

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

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

Invert Responsibilities

Em alguns sistemas, é possível alterar a ordem em que os chamadores não enviam explicitamente solicitações para o serviço, mas deixam o pedido de serviço funcionar sozinho quando estiver pronto para servir.Este tipo de técnica dá ao serviço receptor controle total sobre quanto pode fazer e pode alterar dinamicamente o tamanho do pedido com base no seu último estado.Título Bucketestratégia onde o serviço receptor preenche o token, e que diz ao chamador quando e quanto eles podem enviar para o 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

Às vezes, você sabe de antemão que seu sistema vai ficar sobrecarregado em breve, e você toma medidas proativas, como pedir ao chamador para diminuir o volume de chamadas e aumentá-lo lentamente.

Durante esse período, você aguardava todo o trabalho e agora está pronto para esvaziá-lo para atender a suaSelaQuando você esvaziá-lo mais rápido do que a taxa normal, você corre o risco de acabar com os serviços a jusante.Para resolver isso, você proativamente limita os limites do chamador ou envolve o chamador para reduzir seu volume de chamadas e lentamente abre as portas de inundação.

Throttling

Restringir o número de solicitações que um serviço pode atender e descartar solicitações além disso. O Throttling pode ser aplicado no nível do serviço ou no nível da API. Este throttling é um indicador direto de pressão de volta para o chamador para retardar o volume de chamadas. Você pode levar isso mais longe e fazer o throttling de prioridade ou o throttling de equidade para garantir que o menor impacto seja visto pelos clientes.

Load Shedding

Throttling aponta para descartar pedidos quando você quebra alguns limites predefinidos. pedidos de clientes ainda podem ser descartados se o serviço enfrenta estresse e decide descartar proativamente pedidos que já prometeu atender.

Conclusion

A backpressure é um desafio crítico em sistemas distribuídos que pode afetar significativamente o desempenho e a estabilidade. Entender as causas e os efeitos da backpressure, juntamente com técnicas de gerenciamento eficazes, é crucial para construir sistemas distribuídos robustos e de alto desempenho.

No entanto, se mal tratado, pode erodir a confiança do cliente e até contribuir para a instabilidade do sistema. Resolver proativamente a pressão de volta através de um design e monitoramento cuidadosos do sistema é a chave para manter a saúde do sistema.Enquanto a implementação da pressão de volta pode envolver compromissos, como potencialmente afetando a capacidade de passagem, os benefícios em termos de resiliência geral do sistema e satisfação do usuário são substanciais.