airflow - task 실행 흐름

"워커는 자리를 비우고 큐에 쌓여있는 다른 중요한 태스크를 가져와서 병렬로 일하기 시작합니다. 그동안 트리거러는 백그라운드에서 아주 가볍게(비동기로) 대기 상태를 모니터링하다가, 마침내 외부 응답이 딱 도착하면 스케줄러에게 알립니다. 스케줄러는 이 태스크를 다시 큐에 넣어 비어있는 워커가 마무리를 지을 수 있도록 배치하죠. 이 효율적인 대기 방식을 가능하게 하는 핵심 컴포넌트가 바로 트리거러입니다."

강의를 듣다 보니 다음과 같은 구절이 나왔다.
여기서 triggerer가 scheduler한테 알려서 scheduler를 깨우면 scheduler는 task를 어떻게 할당할까? 이미 한 번 executor를 통해 전략이 내려진 task니까 그대로 수행하는 게 더 효율적이지 않을까라는 생각이 들었다.

결론부터 말하면, scheduler는 다시 executor를 통해 task를 queue에 넣거나 worker에 보낸다.

다시 할당하는 이유

• Airflow의 단위는 Task 코드보다 TaskInstance(특정 run의 상태) 라서, Deferred -> 재실행 시점은 사실상 새 실행으로 취급된다.
• 그 사이에 worker 수, queue state, executor의 parallelism, 우선순위, 다른 task의 대기 상태가 전부 바뀌었을 수 있기 때문에, task가 오면 가장 효율적인 worker를 다시 선택하는 것이 유연한 대처 방법이다.
• CeleryExecutor, KubernetesExecutor와 같은 분산/동적 스케일링이 있는 환경에서는 예전에 돌린 work를 고정시키는 게 비효율적이거나 불가한 경우가 많다.

Deferrable Task
기다리는 동안 잠깐 잠들었다가, 조건이 되면 다시 깨어나는 Task

• defer()라는 함수를 호출해서 알린다.
• 기다리는 동안 worker 대신 가벼운 triggerer 프로세스가 외부 조건을 계속 감시한다.

polling : 새로운 일이 생겼는지 계속 물어보는 방식

• 파일이 생겼는지
• API 작업 끝났는지
• DB가 특정 상태가 되었는지
  polling은 API 호출이 아니다. polling은 주기적으로 반복해서 호출하는 패턴이고, 그 안에서 API를 사용할 뿐이다.

webhook : 서버가 알아서 먼저 연락해주는 API

• 어떤 시스템에서 특정 이벤트가 발생했을 때, 미리 정해둔 URL로 자동으로 HTTP 요청을 보내는 방식이다.
• event 기반 push 알림
• 알림을 받는 쪽 URL : [Webhook URL / Callback URL / Endpoint] 라고 부른다.

polling은 client가 변화가 있는지 계속 물어보는 방식이라 요청이 자주 발생하고 자원을 많이 쓴다. webhook은 서버가 이벤트가 생긴 순간, 1번 알려주는 방식이라 불필요한 요청이 줄어든다.