A plataforma Digibee foi projetada para garantir o funcionamento contínuo das integrações através de estratégias de alta disponibilidade. No entanto, é necessário aplicar configurações adequadas a cada publicação (deployment) para evitar que execuções acima da capacidade do pipeline o tornem indisponível ainda que por um breve período de tempo.
Neste artigo iremos abordar como proceder caso o seu fluxo esteja apresentando o erro abaixo na aba Monitor => Execuções Concluídas:
This pipeline execution was aborted and cannot be automatically retried because it was configured to disallow redeliveries.
(Resposta de execução abortada com código 500)
Cenários de alerta e como solucionar
Este erro ocorre principalmente quando há uma requisição excessiva de memória e/ou CPU. Deve-se ter em mente que até mesmo o tamanho large possui uma capacidade limitada a que consegue atender. Então, para solucionar, será preciso seguir os passos abaixo:
1. Abrir a aba Monitor => Métricas e filtrar pelo período do erro em questão. Atenção: quanto menor o período selecionado, mais precisos serão os valores nos gráficos (artigo).
2. Verificar se houve estouro de memória ou CPU. Atenção: o limite de memória é 100%, porém o de CPU é 20% para small, 40% para medium e 80% para large (artigo).
3. Verificar se o tamanho dos payloads de entrada ou de saída atingiu 5 MB ou o limite configurado na trigger.
4. Abrir a aba Monitor => Execuções Concluídas ou Pipeline Logs e verificar quais foram os últimos passos antes da interrupção.
5. Abrir o pipeline na aba Build e analisar se ele se encaixa em algum dos seguintes cenários de alerta:
- Carregamento de arquivo grande (por exemplo, acima de 7 MB ou acima do limite configurado no conector de arquivo)
- Carregamento de muitos dados via conector DB
- REST ou SOAP onerosos ao processamento
- Grande quantidade de conectores com interação externa (REST/SOAP/DB/Script/arquivo)
- Blocos em loop contendo conectores externos e rodando em paralelo ou não
- Parallel Execution seguido por múltiplos conectores externos
- Logs em excesso ou muito extensos
6. Solução: feito o diagnóstico, recomenda-se aplicar uma ou mais das estratégias a seguir:
- Aumentar o tamanho do deployment to pipeline
- Diminuir a quantidade de execuções simultâneas (ATENÇÃO: A memória alocada para o deployment é compartilhada entre as execuções simultâneas. Por exemplo, em um deployment large com 40 execuções, a memória será dividida por 40. Já com 30 execuções, a mesma quantidade de memória será dividida por 30, resultando em uma maior capacidade de processamento para cada execução, já que a divisão da memória ocorre entre um número menor de chamadas concorrentes.)
- Diminuir a quantidade de dados na entrada ou saída do pipeline
- Controlar a carga de dados no corpo do pipeline com limites, filtros e paginação
- Aumentar a frequência do pipeline para assim fazer processamentos mais leves
- Remover ou diminuir logs com payloads muito grandes
- Limpar a memória de componentes session management com a operação DELETE
- Preferir execuções sequenciais ao invés de paralelas
- Dividir o processamento em múltiplos pipelines
Otimizando o deployment
Para uma configuração de deployment otimizada e livre de falhas, é necessário primeiramente publicar o pipeline e observar o seu desempenho para determinar se irá precisar de refinamento.
Além da alocação adequada dos recursos computacionais (escala vertical), deve-se ajustar o número de execuções simultâneas (escala horizontal) de maneira equilibrada, conferindo um ritmo regular aos processamentos.
Outros fatores a se considerar são o tamanho de fila tolerado e a taxa de vazão desejada, que é a relação entre execuções por segundo (EPS) e tempo de resposta do pipeline.