Operações de limitação no Barramento de Serviço do Azure
As soluções nativas da nuvem dão uma noção de recursos ilimitados que podem ser dimensionados de acordo com a sua carga de trabalho. Embora essa noção seja mais verdadeira na nuvem do que em sistemas locais, ainda existem limitações na nuvem. Essas limitações podem causar a limitação de solicitações de aplicativos clientes nas camadas padrão e premium, conforme discutido neste artigo.
Limitação no nível padrão
A camada padrão do Service Bus opera como uma configuração multilocatária com um modelo de preços pré-pago. Aqui, vários namespaces no mesmo cluster compartilham os recursos alocados. A camada padrão é a escolha recomendada para ambientes de desenvolvedores, ambientes de controle de qualidade e sistemas de produção de baixo rendimento.
No passado, o Service Bus tinha limites de limitação grosseiros estritamente dependentes da utilização de recursos. No entanto, há uma oportunidade de refinar a lógica de limitação e fornecer comportamento de limitação previsível para todos os namespaces que estão compartilhando esses recursos.
Em uma tentativa de garantir o uso justo e a distribuição de recursos em todos os namespaces padrão do Service Bus que usam os mesmos recursos, o padrão do Service Bus atualmente usa a lógica de limitação baseada em crédito.
Nota
É importante observar que a limitação não é nova no Barramento de Serviço do Azure ou em qualquer serviço nativo da nuvem.
A limitação baseada em crédito é simplesmente refinar a maneira como vários namespaces compartilham recursos em um ambiente de camada padrão multilocatário e, assim, permitir o uso justo por todos os namespaces que compartilham os recursos.
O que é a limitação baseada no crédito?
A limitação baseada em crédito limita o número de operações que podem ser executadas em um determinado namespace em um período de tempo específico. Aqui está o fluxo de trabalho para limitação baseada em crédito.
- No início de cada período de tempo, o Service Bus fornece alguns créditos para cada namespace.
- Quaisquer operações realizadas pelas aplicações do cliente emissor ou destinatário são contabilizadas contra estes créditos (e subtraídas dos créditos disponíveis).
- Se os créditos se esgotarem, as operações subsequentes serão limitadas até ao início do período de tempo seguinte.
- Os créditos são repostos no início do período de tempo seguinte.
Quais são os limites de crédito?
Os limites de crédito estão atualmente definidos para 1000 créditos a cada segundo (por namespace). Nem todas as operações são criadas da mesma forma. Aqui estão os custos de crédito de cada uma das operações.
| Operação | Custo do crédito |
|---|---|
Operações de dados (Send, SendAsync, Receive, PeekReceiveAsync, ) |
1 crédito por mensagem |
Operações de gerenciamento (Create, Read, Update, Delete em filas, tópicos, assinaturas, filtros) |
10 créditos |
Nota
Ao enviar para um tópico, cada mensagem é avaliada em relação a filtros antes de ser disponibilizada na assinatura. Cada avaliação de filtro também conta para o limite de crédito (ou seja, 1 crédito por avaliação de filtro).
Como sei que estou sendo estrangulado?
Quando as solicitações de aplicativo cliente estão sendo limitadas, o aplicativo cliente recebe a seguinte resposta do servidor.
The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.
Como posso evitar ser limitado?
Com recursos compartilhados, é importante impor algum tipo de uso justo em vários namespaces do Service Bus que compartilham esses recursos. A limitação garante que qualquer pico em uma única carga de trabalho não faça com que outras cargas de trabalho nos mesmos recursos sejam limitadas. Conforme mencionado posteriormente no artigo, não há risco de ser limitado porque os SDKs (kits de desenvolvimento de software) cliente e outras ofertas de PaaS do Azure têm a política de repetição padrão incorporada neles. Quaisquer solicitações limitadas são repetidas com recuo exponencial e, eventualmente, passam quando os créditos são reabastecidos.
Compreensivelmente, alguns aplicativos podem ser sensíveis a serem limitados. Nesse caso, recomendamos que você migre seu namespace padrão atual do Service Bus para premium. Na migração, você pode alocar recursos dedicados ao namespace do Service Bus e dimensionar adequadamente os recursos se houver um pico na carga de trabalho e reduzir a probabilidade de ser limitado. Além disso, quando sua carga de trabalho é reduzida para níveis normais, você pode reduzir os recursos alocados para seu namespace.
Limitação no nível premium
A camada premium do Service Bus aloca recursos dedicados, em termos de unidades de mensagens, a cada configuração de namespace pelo cliente. Esses recursos dedicados fornecem taxa de transferência e latência previsíveis e são recomendados para sistemas de alto rendimento ou sensíveis de nível de produção. Além disso, o nível premium também permite que os clientes aumentem sua capacidade de taxa de transferência quando tiverem picos na carga de trabalho. Para obter mais informações, consulte Atualizar automaticamente unidades de mensagens de um namespace do Barramento de Serviço do Azure.
Como funciona a limitação no Service Bus Premium?
Com a alocação exclusiva de recursos para a camada premium, a limitação é puramente impulsionada pelas limitações dos recursos alocados ao namespace. Se o número de solicitações for maior do que os recursos atuais podem atender, as solicitações serão limitadas.
Como sei que estou sendo estrangulado?
Há várias maneiras de identificar a limitação na camada premium do Service Bus.
- As Solicitações Limitadas aparecem nas métricas de Solicitação do Azure Monitor para identificar quantas solicitações foram limitadas.
- Alto uso da CPU indica que a alocação de recursos atual é alta e as solicitações podem ser limitadas se a carga de trabalho atual não reduzir.
- Alto uso de memória indica que a alocação de recursos atual é alta e as solicitações podem ser limitadas se a carga de trabalho atual não reduzir.
Como posso evitar ser limitado?
Como o namespace premium do Service Bus já tem recursos dedicados, você pode reduzir a possibilidade de ser limitado aumentando o número de unidades de mensagens alocadas ao seu namespace no caso (ou antecipação) de um pico na carga de trabalho. Para obter mais informações, consulte Atualizar automaticamente unidades de mensagens de um namespace do Barramento de Serviço do Azure.
FAQs
Como é que a limitação afeta a minha aplicação?
Quando uma solicitação é limitada, isso implica que o serviço está ocupado porque está enfrentando mais solicitações do que os recursos permitem. Se a mesma operação for tentada novamente depois de alguns momentos, uma vez que o serviço tenha trabalhado com sua carga de trabalho atual, a solicitação pode ser honrada.
Como a limitação é o comportamento esperado de qualquer serviço nativo da nuvem, a lógica de repetição é incorporada ao próprio SDK do Service Bus. O padrão é definido como repetição automática com um back-off exponencial para garantir que não tenhamos a mesma solicitação sendo limitada todas as vezes. A lógica de repetição padrão se aplica a todas as operações.
Nota
O código de processamento de mensagens que chama outros serviços de terceiros também pode ser limitado por esses outros serviços. Para obter mais informações sobre como lidar com esses cenários, consulte a documentação sobre o padrão de limitação.
A limitação resulta em perda de dados?
O Barramento de Serviço do Azure é otimizado para persistência. Garantimos que todos os dados enviados para o Service Bus sejam comprometidos com o armazenamento antes que o serviço reconheça o sucesso da solicitação.
Uma vez que a solicitação é reconhecida com êxito pelo Service Bus, isso implica que o Service Bus processou a solicitação com êxito. Se o Barramento de Serviço retornar uma falha, isso implica que o Barramento de Serviço não foi capaz de processar a solicitação e o aplicativo cliente deve tentar novamente a solicitação.
No entanto, quando uma solicitação é limitada, o serviço está implicando que não pode aceitar e processar a solicitação agora devido a limitações de recursos. Isso não implica qualquer tipo de perda de dados porque o Service Bus simplesmente não analisou a solicitação. Nesse caso, confiar na política de repetição padrão do SDK do Service Bus garante que a solicitação seja processada eventualmente.
Conteúdos relacionados
Para obter mais informações e exemplos de uso de mensagens do Service Bus, consulte os seguintes tópicos avançados: