<div id="readability-page-1" class="page"><div id="post-body-1013148334320856843" itemprop="articleBody">
다수의 모델을 트레이닝 및 전/후 처리하기 위한 상황을 가정하였다. (최소 100개이상)대부분의 스케쥴러가 muti cluster를 통해 worker를 옆으로 확장시킬 수 있는 구조이다.airflow 역시 celery excutor를 통해 손쉽게 확장이 가능한 구조이다.고사양의 서버 1대라면 문제없이 local excutor로 한 대의 서버에서 모든 작업을 처리할 수 있겠지만 그렇지 않을 경우에는 celery excutor를 통해 다중 서버에서 worker가 작업을 처리할 수 있다.&nbsp;포스팅을 위해 집 컴퓨터로 vm을 띄워서 3대 클러스터로 구성을 했는데 큰 문제없이 잘 수행이 되었다.&nbsp;node 1: postgresql, redis, airflow webserver, airflow scheduler, airflow flower, airflow worker(queue1)node 2: airflow worker(queue2)node 3: airflow worker(queue3)celery excutor를 활용하기 위해 airflow meta db는 postgresql.queue 역할은 redis.그리고 queue ui를 위한 airflow flower.그리고 queue 이름을 q1, q2, q3으로하여 구동했다.airflow worker -q -q1 -Dairflow worker -q -q2 -Dairflow worker -q -q3 -D이렇게 구성 후 가장 기본인 dag 파일에서 bash operator를 사용하여 q1, q2, q3에 분배 테스트를 진행했는데 잘 되었다. 하지만 실무에서는 dag가 훨씬 복잡할 것이다.첫번째로 고려해야할 부분은 가령 subdag이 수십~수백개가 될 수 있고 subdag 내에서도 여러 task가 병렬로 수행되는 구조일 수 있다. 이 때 설정 파라메터를 상황에 맞게 잘 구성해야한다.dag 내에 subdag이 수행이 되면 일단 2개의 running 이 발생하는데 worker의 갯수와 concurrency 및 active run task등의 파라메터를 조절하지않는다면 리소스가 남음에도 불구하고 사용하지 못하거나 hang이 걸린다. 안그래도 트레이닝 작업은 오랜 시간이 발생할 것인데 작업을 바로바로 queue에서 빼와서 수행되어야한다.두번째로 각 worker node에 동일한 task를 똑같이 날려야할 경우이다. 이 부분은 크게 이해가 안갈 수도 있지만 가령 task가 해당 노드에 data join을 통해 데이터를 받아오는 상황이라면 1번서버-&gt;2번서버-&gt;3번서버 순으로 순차처리를 해야할 수도 있다. 이유는 동일한 task id로 dag를 구성하지 못하기 때문이다. 그냥 단순하게 생각하면 동일한 task id를 여러 queue에 날릴 수 없다는 것이다.

</div></div>

ParkSuSeong

다수의 모델을 트레이닝 및 전/후 처리하기 위한 상황을 가정하였다. (최소 100개이상)
대부분의 스케쥴러가 muti cluster를 통해 worker를 옆으로 확장시킬 수 있는 구조이다.
airflow 역시 celery excutor를 통해 손쉽게 확장이 가능한 구조이다.
고사양의 서버 1대라면 문제없이 local excutor로 한 대의 서버에서 모든 작업을 처리할 수 있겠지만 그렇지 않을 경우에는 celery excutor를 통해 다중 서버에서 worker가 작업을 처리할 수 있다. 
포스팅을 위해 집 컴퓨터로 vm을 띄워서 3대 클러스터로 구성을 했는데 큰 문제없이 잘 수행이 되었다. 
node 1: postgresql, redis, airflow webserver, airflow scheduler, airflow flower, airflow worker(queue1)
node 2: airflow worker(queue2)
node 3: airflow worker(queue3)
celery excutor를 활용하기 위해 airflow meta db는 postgresql.
queue 역할은 redis.
그리고 queue ui를 위한 airflow flower.
그리고 queue 이름을 q1, q2, q3으로하여 구동했다.
airflow worker -q -q1 -D
airflow worker -q -q2 -D
airflow worker -q -q3 -D
이렇게 구성 후 가장 기본인 dag 파일에서 bash operator를 사용하여 q1, q2, q3에 분배 테스트를 진행했는데 잘 되었다. 하지만 실무에서는 dag가 훨씬 복잡할 것이다.
첫번째로 고려해야할 부분은 가령 subdag이 수십~수백개가 될 수 있고 subdag 내에서도 여러 task가 병렬로 수행되는 구조일 수 있다. 이 때 설정 파라메터를 상황에 맞게 잘 구성해야한다.
dag 내에 subdag이 수행이 되면 일단 2개의 running 이 발생하는데 worker의 갯수와 concurrency 및 active run task등의 파라메터를 조절하지않는다면 리소스가 남음에도 불구하고 사용하지 못하거나 hang이 걸린다. 안그래도 트레이닝 작업은 오랜 시간이 발생할 것인데 작업을 바로바로 queue에서 빼와서 수행되어야한다.
두번째로 각 worker node에 동일한 task를 똑같이 날려야할 경우이다. 이 부분은 크게 이해가 안갈 수도 있지만 가령 task가 해당 노드에 data join을 통해 데이터를 받아오는 상황이라면 1번서버->2번서버->3번서버 순으로 순차처리를 해야할 수도 있다. 이유는 동일한 task id로 dag를 구성하지 못하기 때문이다. 그냥 단순하게 생각하면 동일한 task id를 여러 queue에 날릴 수 없다는 것이다.

airflow multi cluster 구축 및 고려할 점

댓글