1. 발단
airflow에 대해 잘 모르던 시기에 사정상 내가 구축하지 않은 시스템을 유지보수할 일이 생겼다.
airflow를 좀 아는 팀원이랑 같이 가서 살펴보니 celery executor를 사용하는 전통적인(?) airflow 구조였음.
scheduler가 job을 배치하고, worker가 가져가서 수행한다는 전형적인 구조인데,
시스템에 문제가 생긴 이유는 RabbitMQ의 네트워크 문제.
실제로는 scheduler, worker, webserver가 동일망이었으니, 그림은 이렇게 됨.
airflow 또한 systemctl로 올라가 있었는데, systemctl retry가 안돼서인지 뭔지 worker가 모두 죽어버린 상황.
담당자는 이 사실을 모른 채로 꽤 많은 시간이 지났고...뭐 어쨌거나 근본적인 원인분석이 됐으니 차후에 다시 기동하는 등의 사건 등이 있었으나 중요한 건 이 다음에 든 의문이었다.
왜 굳이 이렇게 구성해야 하는가? 하는 의문....
2. 고민
사실 내가 airflow에 대해 무지한 면이 많았으므로 애초에 왜 메시지큐를 사용해야 했는가 하는 의문부터 출발한 것인데,
celery 기반의 airflow scheduler는 task를 job으로 만들어서 MQ에다 하나씩 던져준다.
이렇게 구성하면 장점은
1) 많은 수의 job을 병렬 처리할 수 있다.
2) 전체적인 작업 capacity가 늘어난다.
3) worker가 분산처리되므로 자원분배 측면에서 리소스를 잘 활용할 수 있다.
단점은
1) 관리포인트가 늘어난다.
2) 유지보수에서 봐야 되는 것들이 더 늘어난다. (남의 시스템이라 더 모르겠더라.. )
3) worker, scheduler, webserver 등을 다 따로 체크해야 한다.
(솔직히 관리포인트 말고는 별 차이는 없지만, 다른 아키텍쳐를 써보고 싶은 마음이 컸다. 이거 대부분 k8s 쓰면 해결은 됨.)
3. 해답
- 팀원한테 좀 징징대봤다.
- 아 우리 어차피 pipeline도 얼마없는데 관리도 힘든 MQ 꼭 써야돼요? ( 나는 MQ에 대한 슬픈 사건이 꽤 많다... )
- 이거 안쓰고 localexecutor 같은건 문제가 있겠죠? 이건 안되겠고.
이러한 질문에 팀원이 대답해줬다.
어 그거 라인인가 어딘가에서 k8s executor라고 쓰던데요.
찾아보니
1) worker=pod이라서 MQ 없어도 되고
2) k8s 환경에서 선형적으로 작업량 늘어나도 분산처리 쉽고
3) image로 소스 처리하니까 CI/CD 쓸수있어요.
대략 이런 구조가 된다.
scheduler는 task를 job으로 만들고, 해당 job 하나하나는 해당하는 소스(이미지)를 불러와서 pod으로 기동된다.
우리는 하버를 쓰기때문에 배포할 수도 있고, 나중에는 확장해서 CI/CD까지 노려볼 수 있었다. 내가 그렇게 하고 싶어하던 전체 자동화!
안 할 이유가 없다
라고 생각했고, 안이한 생각이었음을 뒤늦게 깨닫게 된다....
Top comments (0)