Backoff exponencial en Azure Data Factory: paso a paso

Esta guía muestra cómo implementar un patrón de retry con backoff exponencial en Azure Data Factory para reintentar una actividad (p. ej.: Copy) sin fallar el pipeline de inmediato. El backoff exponencial ayuda a reducir la presión sobre servicios externos y mejora la resiliencia en casos de fallos temporales.

Prerequisitos

• Suscripción de Azure con una instancia de Azure Data Factory.
• Permisos para crear pipelines y linked services en el Data Factory.
• Un escenario de prueba: por ejemplo una Copy activity que puede fallar intermitentemente.

Paso 1: Crear variables del pipeline

Abra el pipeline nuevo y añada variables para controlar intentos, estado y retardo inicial. Estas variables permiten calcular el backoff y terminar el ciclo cuando alcance el máximo de intentos o cuando la actividad tenga éxito.

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

Paso 2: Añadir la actividad principal con continueOnError

Inserte la actividad que quiere reintentar (p. ej.: Copy activity). Defina continueOnError a true, para que un fallo no interrumpa inmediatamente el pipeline. Después verificaremos el resultado de esa actividad.

// Ejemplo de propiedad usada en el JSON (UI hace esto automáticamente)
"activities": [
  {
    "name": "CopyMain",
    "type": "Copy",
    "policy": { "timeout": "7.00:00:00", "retry": 0 },
    "typeProperties": { /* connection e mapeamento */ },
    "continueOnError": true
  }
]

Paso 3: Verificar éxito con If Condition

Tras el CopyMain, añada una If Condition que evalúe si la actividad tuvo éxito. La expresión usa el objeto de actividad: activity('CopyMain').Status. Si es 'Succeeded', establece la variable success a true; en caso contrario, continúa con la lógica de retry.

// Condición de la If Activity
@equals(activity('CopyMain').Status, 'Succeeded')

// Set Variable (success = true) en la rama True
// En la rama False incrementaremos intento y prepararemos el Wait

Paso 4: Incrementar intento y calcular backoff exponencial

En la rama False de la If Condition haga dos cosas: incrementar la variable attempt y calcular el nuevo delaySeconds (por ejemplo doblar). Use Set Variable con expresiones del Data Factory.

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

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

Paso 5: Esperar con Wait y encapsular en Until

Tras actualizar las variables, añada una Wait activity que use delaySeconds. Para repetir el proceso hasta éxito o hasta alcanzar maxAttempts, envuelva todo dentro de una Until activity con condición de salida adecuada.

// Condición del Until: sale cuando success = true O attempt >= maxAttempts
@or(equals(variables('success'), true), greaterOrEquals(variables('attempt'), variables('maxAttempts')))

// Propiedad del Wait (usar expresión para segundos)
"waitTimeInSeconds": "@variables('delaySeconds')"

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

Verificar el resultado

Ejecute el pipeline con un escenario donde la actividad falle algunas veces. En el panel Monitor de Azure Data Factory vea las ejecuciones del pipeline y las Runs de las actividades. Verifique las variables al final de la ejecución (en la sección Output del pipeline run) y confirme que:

• El Until repitió los intentos hasta éxito o hasta maxAttempts.
• Los tiempos de espera aumentaron (delaySeconds) según lo esperado.
• El estado final (success) es consistente con lo observado en las actividades.

Conclusión

Con este patrón se usan Until, If, Set Variable y Wait para implementar un backoff exponencial en Azure Data Factory sin depender del retry nativo. Próximos pasos: añada un límite máximo (cap) al delay, introduzca jitter (aleatoriedad) para evitar thundering herd y registre métricas en el Monitor para alertas. Consejo: prefiera usar Execute Pipeline para aislar la lógica de retry y reutilizarla — ¿quiere probar ese patrón en un pipeline separado?