Backoff exponencial em Azure Data Factory: passo a passo

Este guia mostra como implementar um padrão de retry com backoff exponencial em Azure Data Factory para retentar uma actividade (ex.: Copy) sem falhar o pipeline de imediato. O backoff exponencial ajuda a reduzir a pressão sobre serviços externos e melhora a resiliência em casos de falhas temporárias.

Pré-requisitos

• Assinatura Azure com uma instância de Azure Data Factory.
• Permissões para criar pipelines e linked services no Data Factory.
• Um cenário de teste: por exemplo uma Copy activity que pode falhar intermitentemente.

Passo 1: Criar variáveis do pipeline

Abra o pipeline novo e adicione variáveis para controlar tentativas, estado e atraso inicial. Estas variáveis permitem calcular o backoff e terminar o ciclo quando atingir o máximo de tentativas ou quando a actividade tiver sucesso.

{
  "variables": {
    "attempt": { "type": "Int", "defaultValue": 1 },
    "maxAttempts": { "type": "Int", "defaultValue": 5 },
    "delaySeconds": { "type": "Int", "defaultValue": 5 },
    "success": { "type": "Bool", "defaultValue": false }
  }
}

Passo 2: Adicionar a actividade principal com continueOnError

Insira a actividade que quer retentar (ex.: Copy activity). Defina continueOnError para true, para que uma falha não interrompa imediatamente o pipeline. Depois verificaremos o resultado dessa actividade.

// Exemplo de propriedade usada no JSON (UI faz isto automaticamente)
"activities": [
  {
    "name": "CopyMain",
    "type": "Copy",
    "policy": { "timeout": "7.00:00:00", "retry": 0 },
    "typeProperties": { /* connection e mapeamento */ },
    "continueOnError": true
  }
]

Passo 3: Verificar sucesso com If Condition

Após a CopyMain, adicione uma If Condition que avalia se a actividade teve sucesso. A expressão usa o objecto de actividade: activity('CopyMain').Status. Se for 'Succeeded', define a variável success para true; caso contrário, segue para a lógica de retry.

// Condição da If Activity
@equals(activity('CopyMain').Status, 'Succeeded')

// Set Variable (success = true) no ramo True
// No ramo False iremos incrementar tentativa e preparar o Wait

Passo 4: Incrementar tentativa e calcular backoff exponencial

No ramo False da If Condition faça duas coisas: incrementar a variável attempt e calcular o novo delaySeconds (por exemplo dobrar). Use Set Variable com expressões do Data Factory.

// Incrementar attempt
Set Variable 'attempt' -> @add(variables('attempt'), 1)

// Calcular novo delaySeconds (exponencial)
Set Variable 'delaySeconds' -> @mul(variables('delaySeconds'), 2)

Passo 5: Esperar com Wait e encapsular em Until

Após actualizar as variáveis, adicione uma Wait activity que use delaySeconds. Para repetir o processo até sucesso ou até atingir maxAttempts, envolva tudo dentro de uma Until activity com condição de saída adequada.

// Condição do Until: sai quando success = true OU attempt >= maxAttempts
@or(equals(variables('success'), true), greaterOrEquals(variables('attempt'), variables('maxAttempts')))

// Propriedade do Wait (usar expressão para segundos)
"waitTimeInSeconds": "@variables('delaySeconds')"

Estrutura lógica do pipeline (simplificada): Until -> [ CopyMain (continueOnError:true) -> If Condition { True: Set success=true; False: Set attempt++, Set delaySeconds*=2, Wait } ]

Verificar o resultado

Execute o pipeline com um cenário onde a actividade falha algumas vezes. No painel Monitor do Azure Data Factory veja as execuções do pipeline e as Runs das actividades. Verifique as variáveis no final da execução (na secção Output do pipeline run) e confirme que:

• O Until repetiu as tentativas até sucesso ou até maxAttempts.
• Os tempos de espera aumentaram (delaySeconds) conforme o esperado.
• O estado final (success) está consistente com o que observou nas actividades.

Conclusão

Com este padrão usa Until, If, Set Variable e Wait para implementar um backoff exponencial em Azure Data Factory sem depender do retry nativo. Próximos passos: adicione um limite máximo (cap) ao delay, introduza jitter (aleatoriedade) para evitar thundering herd e registe métricas no Monitor para alertas. Dica: prefira usar Execute Pipeline para isolar a lógica de retry e reutilizá‑la — quer experimentar esse padrão numa pipeline separada?