UnLimitedParallelism
1 |
|
프로세스가 들어오면 들어오는대로 하나씩 하나씩 실행시킨다는 docstring이 있습니다. 조금 길고 귀찮긴 하지만 포스팅의 목적에 맞게 init 메서드를 제외한 모든 메서드를 까서 살펴보겠습니다.
def start
1 |
|
executor가 시작되면 변수 2개가 초기화됩니다. 사용된 worker와 실행중인 worker의 상태를 체크하기 위한 용도인것 같습니다.
def execute_async
1 |
|
이름만 봐도 비동기로 task를 실행시키는, 즉 subprocess를 만드는 메서드임을 알 수 있습니다.
위의 LocalExecutor 설명에서는 언급하지 않았지만 하나의 process는 하나의 task만을 실행시키고, 각각 독립적인 process이기 때문에 queue나 pipe와 같은 IPC 기법이 없는 이상 task간의 통신은 원칙적으로 불가능합니다.
단, airflow는 전역 저장소 형태의 xcom을 이용해 task 간에도 데이터를 주고받을 수 있는 IPC 기법을 제공하고 있습니다.
제일 먼저 result_queue가 없다면 Exception을 일으킵니다. result_queue는 LocalExecutor의 start 메서드에서 생성되기 때문에 당연히 없다면 오류입니다.
그 다음에는 local_worker를 생성합니다. queue와 task의 고유 key, 그리고 task를 실행할 command를 전달합니다. executor.workers_used와 executor.workers_active에 각각 1을 더해줍니다.
local_worker의 start 메서드는 파이썬 빌트인 라이브러리인 Process의 start입니다. LocalWorker <- LocalWorkerBase <- Process 순으로 상속관계를 가지고 있습니다. 여기서 인자로 주어진 Key와 command를 기반으로 task 프로세스가 실행되는 것을 확인할 수 있습니다. Worker Process를 메인 프로세스로 하고, Task를 자식 프로세스로 할당합니다.
def sync
1 |
|
heartbeat에 의해 주기적으로 호출되는 메서드라고 docstring에 명시되어 있습니다. result_queue가 없다면 LocalExecutor의 start 메서드가 아직 실행되지 않은것이기 때문에 Exception을 일으킵니다.
result_queue가 완전히 빌 때까지 queue에 담겨있는 프로세스 상태를 가져와서 상태를 변경합니다. change_state()
메서드는 BaseExecutor 클래스에 있는데, 주어진 Task 정보에 따라 executor에서 실행중인 task를 없애거나 상태를 변경합니다. 이에 대한 건 BaseExecutor의 코드를 보면 이해에 도움이 될 것입니다.
https://github.com/apache/airflow/blob/main/airflow/executors/base_executor.py
def end
1 |
|
self.executor.workers_active
가 0 이하가 될 때까지 sync 메서드를 호출합니다. sync 메서드의 while문에서 self.executor.workers_active
를 1씩 깎는 것을 확인할 수 있습니다.
여기까지 UnLimitedParallelism 클래스의 모든 메서드를 봤습니다. 그런데 가장 중요한 기능이 전혀 보이지 않습니다. Task Process를 실행시키는 메서드입니다. UnLimitedParallelism 클래스의 메서드들은 Worker 프로세스를 띄우고 상태를 확인하는 메서드들뿐입니다. task process가 실행되어야 result_queue에도 task 정보가 찰텐데 그런 것도 코드에서 전혀 보이지 않습니다.
이를 확인하기 위해서는 LocalWorker와 그 부모 클래스 LocalWorkerBase를 볼 필요가 있습니다.
LocalWorker
1 |
|
여긴 별게 없습니다. 부모 클래스 상속받아서 부모 메서드 execute_work를 실행하는 것 말고는 별다른 기능이 없네요. UnlimitedParallelism.execute_async()
에 있는 local_worker.start()
의 start()
메서드도 LocalWorker 클래스에서는 찾아볼 수 없습니다.
부모 클래스인 LocalWorkerBase를 봐야겠습니다.
LocalWorkerBase
1 |
|
airflow 커맨드를 실행하기 위한 클래스입니다. 파이썬 빌트인 클래스인 Process를 상속하고 있네요. target을 do_work로 지정했습니다. LocalWorker의 do_work는 execute_work를 실행시키기 때문에, 이 부분이 프로세스 실행과 연관이 있는 것은 맞아보입니다.
target은 BaseProcess 클래스의 초기화 변수입니다. BaseProcess.run()
에서 target이 존재할 경우 실행됩니다.
1 |
|
LocalWorkerBase의 run이 실행되면, super().run()에 의해 BaseProcess.run()이 실행되고 결국 do_work가 실행됩니다. LocalWorker가 초기화되면 LocalWorkerBase가 초기화되고, target이 지정되어 있기 때문에 BaseProcess.run()
에 의해 target이 실행되는 구간이 내부에 있을거라 추측합니다. (이 부분은 코드 내부에서 찾을 수 없었습니다. ㅜㅜ)
어쨌든 LocalWorkerBase 클래스가 초기화되면 자동으로 do_work()를 실행하고, 이를 상속받고 있는 LocalWorker 클래스의 do_work()
는 execute_work()를 실행하기 때문에, 결국 LocalWorker 클래스가 초기화되면 LocalWorkerBase 클래스의 execute_work가 실행됩니다.
execute_work()와 그 내부 메서드만 보면 result_queue와 OS 단계에서 프로세스를 생성하는 코드도 있습니다. 이 부분만 보면 LocalExecutor 내부는 다 본것 같습니다.
그런데 쓰다보니 너무 길어져서, LocalExecutor는 다음 포스팅에서 마무리하도록 하겠습니다.