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/de 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 deploy pipeline
- Diminuir a quantidade de execuções simultâneas (a memória do deploy é utilizada pelas execuções simultâneas, se uso 40 execuções em um deploy Large, a memória é dividida pelas 40, se eu uso 30, a mesma quantidade de memória será dividida pelas 30, o que significa que as 30 serão mais "fortes" que comparado com as 40. tendo visto que a divisão da memória foi por um número menor)
- 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.