[Airflow] 실패한 테스크를 자동으로 복구하는 Retry 전략
데이터 파이프라인 운영에서 가장 피곤한 일은 새벽에 날아오는 ‘태스크 실패’ 알림입니다. 하지만 모든 실패가 치명적인 결함은 아닙니다. 네트워크 일시 오류, API 레이트 리밋, 일시적인 리소스 부족 등은 자동 재시도만으로도 충분히 해결될 수 있습니다.
Airflow에서 태스크 실패시 복구하는 Retry 전략 3가지와 구체적인 코드 예시를 소개합니다.
1. 기본 Retry 설정 (Default Args)
가장 먼저 익혀야 할 것은 DAG 전체나 개별 태스크에 적용하는 기본 재시도 설정입니다.
핵심 파라미터
- retries: 실패 시 최대 재시도 횟수
- retry_delay: 재시도 사이의 대기 시간
- retry_exponential_backoff: 재시도 간격을 점진적으로 늘릴지 여부
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime, timedelta
default_args = {
'owner': 'data_team',
'depends_on_past': False,
'start_date': datetime(2025, 1, 1),
# 1. 실패 시 3번까지 재시도
'retries': 3,
# 2. 재시도 간격은 5분
'retry_delay': timedelta(minutes=5),
}
with DAG('retry_basic_strategy', default_args=default_args, schedule_interval='@daily') as dag:
# 이 태스크는 5분 간격으로 총 3번 재시도
simple_task = PythonOperator(
task_id='simple_task',
python_callable=lambda: print("Executing task...")
)
2. 지수 백오프 전략 (Exponential Backoff)
네트워크 부하나 API 서버의 일시적 장애의 경우, 짧은 간격으로 계속 재시도하는 것은 오히려 서버에 더 큰 부담을 줄 수 있습니다. 이때 사용하는 것이 지수 백오프입니다.
핵심 파라미터
- retry_exponential_backoff: True로 설정
- max_retry_delay: 백오프가 적용되더라도 최대 대기 시간이 이 값을 넘지 않게 제한
# 지수 백오프 적용 예시
backoff_task = PythonOperator(
task_id='backoff_task',
python_callable=lambda: 1/0, # 의도적 에러 발생
retries=5,
retry_delay=timedelta(seconds=10),
# 재시도마다 대기 시간이 2배씩 증가
retry_exponential_backoff=True,
# 아무리 늘어나도 10분을 넘기지 않도록 설정
max_retry_delay=timedelta(minutes=10)
)
3. 특정 조건에 따른 콜백 활용 (on_retry_callback)
단순히 다시 실행하는 것을 넘어, 재시도가 발생할 때마다 알림을 보내거나 특정 로직을 실행하고 싶을 때 콜백 함수를 사용합니다.
import logging
def alert_on_retry(context):
"""재시도가 발생할 때 실행되는 콜백 함수"""
task_instance = context['task_instance']
retry_count = task_instance.try_number - 1 # 현재 시도 횟수
logging.info(f"⚠️ [Retry Alert] {task_instance.task_id} 재시도 중... (시도 횟수: {retry_count})")
with DAG('retry_callback_strategy', default_args=default_args) as dag:
task_with_alert = PythonOperator(
task_id='task_with_alert',
python_callable=lambda: 1/0,
retries=2,
retry_delay=timedelta(minutes=1),
# 재시도 시마다 커스텀 함수 실행
on_retry_callback=alert_on_retry
)
실무에서의 팁
멱등성(Idempotency) 확인: 재시도 전략을 세우기 전에 반드시 해당 태스크가 다시 실행되어도 데이터가 중복되지 않는지(멱등성)를 먼저 체크해야 합니다.
전역 설정 vs 개별 설정: 외부 API 호출처럼 불안정한 작업은 개별 태스크에 더 높은
retries를 부여하고, 내부 DB 작업 등은 기본 설정을 따르는 것이 좋습니다.지연 시간 고려: 전체 파이프라인의 SLA(완료 목표 시간)가 중요하다면 너무 긴
retry_delay는 전체 일정을 늦출 수 있으니 주의해야 합니다.
자동 재시도는 완벽한 해결책은 아니지만, 운영자의 개입 없이 파이프라인의 **가용성(Availability)**을 높여주는 강력한 도구입니다. 오늘 소개한 3가지 전략을 여러분의 DAG에 적용해 보세요. 새벽 알람 횟수가 눈에 띄게 줄어들 것입니다!