Pipeline Engine
Conheça o motor de execução dos pipelines.
A Digibee Integration Platform utiliza um motor que não somente interpreta os pipelines construídos através da interface, mas também os executa. Esse motor é chamado de Pipeline Engine.
Dê uma olhada nos conceitos e na arquitetura de operação do Pipeline Engine.
Conceitos
Tenha a visão em alto nível do Pipeline Engine em relação aos nossos demais componentes da Plataforma:
Pipeline Engine: componente responsável pela execução dos fluxos construídos na nossa Plataforma
Trigger: componente que recebe invocações que vêm de diferentes tecnologias e as encaminha para o Pipeline Engine
Mecanismo de filas: mecanismo central de gestão de filas da nossa Plataforma
Arquitetura de Operação
Cada fluxo (pipeline) criado é convertido em um container Docker, executado com a tecnologia Kubernetes - base da Digibee Integration Platform. Veja as principais garantias desse modelo de operação:
isolamento: cada container é executado na infraestrutura de maneira exclusiva (os espaços de memória e o consumo de CPU são completamente exclusivos para cada pipeline)
segurança: pipelines NÃO conversam entre si, a não ser que seja através das interfaces providas pela nossa Plataforma
escalabilidade específica: é possível aumentar o número de "réplicas" de pipelines de maneira específica, isto é, aumentar ou diminuir o que demanda maior ou menor desempenho
Tamanhos de Pipeline
Utilizamos o conceito serverless, ou seja, você não precisa se preocupar com detalhes de infraestrutura para a execução dos seus pipelines. Dessa forma, cada pipeline deve ter o seu tamanho definido durante a implantação. A Plataforma permite que os pipelines sejam utilizados em 3 tamanhos distintos:
SMALL, 10 consumers (consumidores), 20% de 1 CPU, 64 MB de memória
MEDIUM, 20 consumers (consumidores), 40% de 1 CPU, 128 MB de memória
LARGE, 40 consumers (consumidores), 80% de 1 CPU, 256 MB de memória
Consumers
Além do tamanho de cada pipeline, você define o número máximo de execuções simultâneas (ou consumidores) que o pipeline permite. Dependendo do tamanho, um número máximo de consumidores pode ser configurado para a execução.
Assim, um pipeline com 10 consumidores pode processar 10 mensagens em paralelo, enquanto um pipeline com 1 consumidor pode processar somente 1 mensagem.
Recursos (CPU e Memória)
Além do mais, o tamanho do pipeline também define o desempenho e a quantidade de memória que ele tem acesso. O desempenho é dado pela quantidade de ciclos de uma CPU a qual o pipeline tem acesso.
Por outro lado, a memória é dada pelo espaço endereçável para tratamento de mensagens e consumo de informações.
Réplicas
As mensagens são enviadas ao mecanismo de filas da Plataforma através de triggers, que são a porta de entrada para a execução dos pipelines. Existem triggers para diferentes tipos de tecnologia, assim como REST, HTTP, Scheduler, Email, etc. Assim que as mensagens chegam ao mecanismo de filas, elas ficam disponíveis para serem consumidas pelos pipelines.
Durante a implantação do pipeline, você deve definir seu o número de réplicas. Um pipeline SMALL com 2 réplicas tem o dobro do desempenho de processamento e escalabilidade, e assim por diante. Além de prover mais poder de processamento e escalabilidade, as réplicas garantem maior disponibilidade - se uma das réplicas falha, há outras para atender.
De maneira geral, as réplicas entregam escalabilidade horizontal, enquanto o tamanho do pipeline entrega escalabilidade vertical. Por isso, mesmo que 1 pipeline de tamanho LARGE seja equivalente a 4 pipelines de tamanho SMALL pela lógica da infraestrutura, não significa que eles sejam equivalentes para todos os tipos de cargas de trabalho. Em muitas situações, principalmente naquelas que envolvam o processamento de mensagens grandes, somente a utilização de pipelines "verticalmente" maiores traz o resultado esperado.
Timeouts e Expiration
Os triggers podem ser configurados com os seguintes tipos principais de controle de tempo para o processamento de mensagens:
timeout: indica o tempo máximo que o trigger espera pelo retorno do pipeline
expiration: indica o tempo máximo que uma mensagem pode ficar na fila até ser capturada por um Pipeline Engine
A configuração de timeout é possível para todos os triggers, mas apenas alguns permitem a configuração de expiration. Isso ocorre porque a característica do trigger pode ser síncrona ou assíncrona.
O trigger de eventos realiza execuções de forma assíncrona e pode manter mensagens em fila por um bom tempo até que sejam consumidas. Por essa razão, faz sentido definir o tempo de expiração das mensagens produzidas por esse tipo de trigger.
Contudo, REST Trigger depende da resposta do pipeline para dar um retorno. Nesse caso, a configuração de expiration não faz sentido. Mesmo assim, internamente, os triggers síncronos estimam o tempo de expiração, não configurável, para as mensagens. Isso garante que as mensagens não se percam no processo de enfileiramento.
Controle de Execução
O processamento de mensagens é feito de forma sequencial para cada consumidor. Logo, se um pipeline é implantado com 1 consumidor, as mensagens serão processadas 1 a 1 sequencialmente. Enquanto a mensagem é processada, ela recebe uma marca e nenhuma outra réplica de pipeline vai poder recebê-la para processamento.
Se um pipeline enfrentar qualquer problema na execução e precisar de um restart (ex.: OOM, crash, etc.), então as mensagens em execução serão devolvidas para o mecanismo de fila.
Mensagens devolvidas para a fila de processamento
Mensagens devolvidas para a fila de processamento ficam disponíveis para o consumo de outras réplicas de pipeline ou até mesmo pela mesma réplica que teve algum problema e precisou ser reiniciada.
Nesse caso, é possível configurar o pipeline para definir a abordagem em casos de reprocessamento de mensagens. Todos os triggers da Plataforma possuem uma configuração denominada "Allow Redeliveries".
Quando essa opção estiver ativada, o pipeline aceita que a mensagem seja reprocessada. Quando desativada, o pipeline recebe a mensagem, detecta que se trata de um reprocessamento e a recusa por meio de um erro.
O tempo de retentativas da mensagem será o tempo do Maximum Timeout definido no trigger do pipeline, no caso de um pipeline com Event Trigger será o tempo determinado no Expiration.
Também é possível detectar se a mensagem em execução é reprocessada ou não. Para fazer isso, basta utilizar a linguagem Double Braces acessando o escopo de metadados. Exemplo:
Last updated