Sensors — 외부 이벤트를 기다리는 Operator
Apache Airflow Official Documentation (in-repo snapshot) — Apache Software Foundation core-concepts/sensors.rst
이 모듈을 다 읽으면
- poke 모드와 reschedule 모드가 워커 슬롯 점유 방식에서 어떻게 다른지 설명할 수 있다
- BaseSensorOperator의 공통 파라미터(poke_interval, timeout, mode, soft_fail, exponential_backoff, max_wait)의 역할을 설명할 수 있다
- soft_fail=True가 타임아웃 시 태스크 상태에 미치는 영향을 설명할 수 있다
Sensor는 무언가가 일어날 때까지 기다리는 것만을 목적으로 하는 특수한 Operator다. 이 모듈은 poke/reschedule 두 실행 모드의 차이, BaseSensorOperator가 제공하는 공통 파라미터, 그리고 표준 provider가 제공하는 대표적인 센서들을 다룬다.
Sensor의 목적과 두 가지 모드
Sensor는 정확히 한 가지 일 — 무언가가 일어나기를 기다리는 것 — 을 하도록 설계된 특수한 Operator다. 시간 기반일 수도, 파일이나 외부 이벤트를 기다리는 것일 수도 있지만, 결국 하는 일은 무언가가 일어날 때까지 기다렸다가 *성공*해서 다운스트림 태스크가 실행되게 하거나, 설정된 타임아웃 안에 그 일이 일어나지 않으면 *실패*해서 평소의 알림 메커니즘으로 실패를 알릴 수 있게 하는 것이다.
Sensor는 대부분의 시간을 유휴 상태로 보내기 때문에, 이를 좀 더 효율적으로 쓸 수 있도록 두 가지 실행 모드를 제공한다. ``poke``(기본값) 모드에서는 센서가 자신의 전체 런타임 동안 워커 슬롯을 계속 점유한다. ``reschedule`` 모드에서는 센서가 확인하는 순간에만 워커 슬롯을 점유하고, 확인 사이에는 정해진 시간만큼 잠들어(sleep) 슬롯을 반납한다. 이 두 모드는 센서를 인스턴스화할 때 직접 설정할 수 있으며, 일반적인 트레이드오프는 지연(latency)이다 — 매초 확인해야 하는 것은 poke 모드가 적합하고, 매분 정도로 확인해도 되는 것은 reschedule 모드가 적합하다.
핵심 포인트
- poke 모드는 센서 런타임 내내 워커 슬롯을 점유하고, reschedule 모드는 확인하는 순간에만 슬롯을 점유하고 그 사이엔 반납한다
- poke 모드는 짧은 확인 주기(예: 매초)에, reschedule 모드는 긴 확인 주기(예: 매분)에 적합하다는 지연-자원 트레이드오프가 있다
BaseSensorOperator 공통 파라미터
Airflow의 모든 센서는 (직접 또는 간접적으로) ``BaseSensorOperator``를 상속하며, 이 기반 클래스가 센서가 어떻게 대기하고 재시도하고 워커 자원을 관리하는지를 정의하는 공통 동작과 파라미터를 제공한다. Task SDK 리팩터링 이후 ``BaseSensorOperator``는 Task SDK 안에 구현되어 있으며, provider 문서가 별도로 생성되기 때문에 이 파라미터들이 개별 provider 센서 API 페이지에 항상 명시적으로 보이지는 않을 수 있지만, 모든 센서에 공통으로 적용된다.
주요 공통 파라미터는 다음과 같다. ``poke_interval``은 연속된 확인 사이의 시간(초)으로, poke 모드에서는 워커 슬롯을 점유한 채 이 시간만큼 sleep하고, reschedule 모드에서는 태스크가 지연(defer)되었다가 이 간격 후 재스케줄된다. ``timeout``은 센서가 실패하기 전까지 실행이 허용되는 최대 시간(초)이며, 첫 실행 시도부터 측정되지 poke 한 번마다 적용되는 것이 아니다. ``mode``는 poke(기본, 전체 기간 워커 슬롯 점유)와 reschedule(확인 사이 슬롯 반납) 중 워커 자원을 어떻게 점유할지를 결정한다. ``soft_fail``이 True면 타임아웃에 도달했을 때 태스크가 FAILED 대신 SKIPPED로 표시된다. ``exponential_backoff``를 켜면 확인 사이의 간격이 ``max_wait``까지 지수적으로 증가하는데, 이는 가용성이 들쭉날쭉한 외부 시스템을 폴링할 때 유용하다. ``max_wait``는 ``exponential_backoff``가 켜졌을 때 확인 간 지연의 상한이다.
핵심 포인트
- poke_interval은 연속 확인 사이 간격, timeout은 첫 시도부터 측정되는 전체 허용 시간(포크 단위가 아님)이다
- soft_fail=True면 타임아웃 시 FAILED 대신 SKIPPED로 표시되며, exponential_backoff+max_wait 조합으로 폴링 간격을 지수적으로 늘릴 수 있다
대표적인 표준 센서
예를 들어 파일 존재를 확인하는 센서는 다음과 같이 구성할 수 있다: ``BashSensor(task_id="wait_for_file", bash_command="test -f /data/input.csv", poke_interval=60, timeout=60*60, mode="reschedule")``. 파일 대기에 특화된 용도로는 로컬 파일시스템에서 파일 탐지를 위해 설계되고 deferrable 모드도 지원하는 ``FileSensor``(standard provider)를 쓰는 것이 권장된다.
표준 provider가 제공하는 대표적인 센서로는 파일시스템에서 파일 등장을 기다리는 ``FileSensor``, bash 명령이 true를 반환하기를 기다리는 ``BashSensor``, Python 콜러블이 true를 반환하기를 기다리는 ``PythonSensor``, 특정 시각까지 기다리는 ``TimeSensor``, 특정 시간 길이만큼 기다리는 ``TimeDeltaSensor``, 다른 Dag의 태스크가 완료되기를 기다리는 ``ExternalTaskSensor``가 있다. 전체 센서 목록은 provider 문서에서 확인할 수 있다.
핵심 포인트
- FileSensor, BashSensor, PythonSensor, TimeSensor, TimeDeltaSensor, ExternalTaskSensor가 standard provider의 대표적인 센서다
- 로컬 파일시스템 파일 대기에는 범용 BashSensor보다 목적에 맞게 설계되고 deferrable 모드를 지원하는 FileSensor가 권장된다