Kubeflow, Airflow와 비교해보는 Flyte 특징 분석과 Use Case 소개
Flyte 를 업무적으로 도입하면서 자료가 많이 없는 상황임에도 여전히 우리 팀은 고군분투하고 있다.
국내에는 Flyte 도입에 대한 자료가 없다고 보면 되서 (첫번째 Flyte 포스팅에 이 부분에 대한 내용을 잘 설명해 놓았다.) 사실상 실제로 업무적으로 사용하고 있는 회사는 Qraft Technologies가 이 플랫폼에 대한 개척자와 같은 역할을 하고 있다고 믿는다.
이번 포스팅에서는 Flyte Pipeline이 어떤 특징을 갖고 있는지 비슷한 특징들을 갖고 있으면서 잘 알려진 Kubeflow와 Airflow를 비교하면서 분석을 해보고자 한다.
또한 금주에 AI 리서치 엔지니어분들과 협업하면서 발생했던 Use Case를 간략하게나마 정리해보고자한다.
(매번 느끼지만, 프로젝트 & 업무적으로 배운 것은 틈틈이 메모해놨다가 블로그로 정리해두면, Problem을 직면했을 때, Solution을 어떻게 찾아가는지에 대해 회상하기 쉽다.)
1. 왜 Kubeflow & Airflow와 비교하죠?
Kubeflow는 Flyte와 마찬가지로 ML Workflow의 오케스트레이션을 위해 도입하는 플랫폼이고, k8s 기반으로 실행하는 것이 가능하다.
k8s와 함께 구글에서 제작했고, 해당 오픈 소스를 빅테크 기업에서 지원하다보니 커뮤니티 규모와 사용에 관한 많은 Use Case를 인터넷에서 쉽게 찾아볼 수 있다.
Kubeflow와 Flyte를 비교하는 이유는 Kubeflow가 Flyte 와 많은 부분에서 기능이 겹치고, 기본적으로 더 많은 기능을 쿠버네티스 기반으로 제공한다.
그리고 Airflow를 비교 대상에 포함시킨 것은 Lyft(Flyte 배포한 스타트업)에서 airflow를 사용하다가 문제점을 발견하고, 발전시켜 출시한 것이 Flyte라고 이 글에서 언급하기 때문이다.
flyte 측에서 제공하는 Customer Success Stories 에서 기업들의 도입 사례를 안내하고는 있으나 아직 구글에서 활발하게 검색되고 있는 것으로 보이지는 않으며, “Workflow Orchestration”이라는 관점에서 Airflow와 kubeflow가 자주 비교되고 있는 것을 알 수 있다.
회사에서도 기존에는 Data Process를 처리하기 위해 Airflow를 k8s에 올려 사용하고 있었고, Kubeflow && Airflow && Flyte를 비교하는 것은 각 플랫폼의 목적이 “Workflow 오케스트레이션” 이라는 점에 초점을 맞추고 있기 때문에 적절해 보인다.
즉, Workflow Orchestration을 해주는데, 무엇에 초점을 맞추고 있는지를 명확하게 이해하고 넘어가는 글이라 생각하면 될 것 같다.
2. Kubeflow && Airflow && Flyte
설명하고자 하는 내용을 한 페이지로 설명한다면 아마 다음 표와 같을 것이다.
앞서 언급한 것처럼 Lyft 에서 Flyte를 제작하기 전 사용했던 워크 플로우 관리 플랫폼은 Airflow다.
때문에 Airflow에서 제공하는 거의 대부분의 기능은 Flyte에서 동일하게 지원된다고 보면 되며, 몇 가지 차이가 있다면
- 동일한 워크 플로우를 실행하더라도, Versioning을 수행할 수 있다.
- 하나의 task에서 사용할 수 있는 리소스의 사용량을 제한할 수 있다. (k8s service qos 참고)
- Flyte에 올릴 Workflow의 목적에 따라 분리해서 DAG를 관리하는 것이 가능하다. (Development, Staging, Production)
이 정도를 언급할 수 있을 것이다.
그리고 문서에 언급된 것 말고, 팀 내에서 얘기가 잠깐 나왔던 것은, Airflow에서는 Data-Batch 단위로 task를 다루는데, Flyte는 조금 더 이벤트 기반으로 Task를 다룬다는 느낌이 강하다는 느낌을 줬다.
그 이유는, Airflow에서는 일정기간의 데이터를 일괄 처리하기 때문에 실시간으로 데이터를 처리하기 어려웠다면, Flyte에서는 배치 단위에 구애받지 않고 AI 부서별 작업을 Task로 올려줄 수 있었기 때문이다.
(즉, Flyte는 Scheduling을 통한 배치 처리와 매일의 event 발생에 따른 task 처리를 동시에 지원해준다.)
Flyte에서 Kubeflow를 직접적으로 언급하며 비교하는 글은 아직 본 적은 없는데, 아마 Workflow에 버전 관리 기능을 제공하는 것과 Task 단위 리소스 사용량 관리는 ml workflow 관리를 위해 kubeflow와 같은 플랫폼을 참고하지 않았나 싶다.
3. The Critical Point of Flyte
개인적으로 다음과 같은 상황에서 Flyte는 Workflow 관리 플랫폼을 도입하기 위해 고려할만한 중요한 포인트가 될 수 있다고 생각한다.
3.1) Airflow +a 의 목적으로 리소스 & 버전 관리가 필요할 때
Flyte에서는 launchplan이라는 스케줄링 기능을 제공하고 있으며, DAG로 workflow를 airflow와 거의 비슷하게 관리하는 것이 가능하다.
여기에 추가로 Task 의 자원 사용량을 확실하게 제한하여 관리하고자 할 때, 그리고 동일한 workflow라 하더라도 버전관리가 필요할 때, Flyte를 고려해 볼 만하다.
3.2) 타입 검사가 필수적으로 포함되고자 할때
Flyte는 자체적으로 Task에 올라가기 전 타입 검사를 실행한다.
여기서 말하는 타입은 Flyte에서 자체적으로 사용하고 있는 Type이 있고, Python의 type hinting 모두를 의미한다.
(Flyte에서 컴파일 할 때, 별도의 타입을 지정해주지 않으면 FlytePickle이라는 타입을 기본 값으로 사용한다)
기본적으로 덕 타이핑 자체를 강하게 피하고 있어서, Flyte server로 올라가기 전 타입 관련 에러를 사전에 파악할 수 있다.
3.3) k8s 외의 환경에서도 사용이 필요로할 때
이 부분이 Kubeflow와 명확하게 갈리는데, Flyte에서는 다음 커맨드를 통해 로컬에서 flyte를 실행하더라도 미리 flyte가 배포된 서버에 작업을 올리는 것이 가능하다.
flytectl config init - -host <host name>
재택 근무를 수행하는 리서치 엔지니어 분들의 경우, 위의 커맨드 설정으로 회사 서버에 배포되어 있는 호스트로 Flyte 작업을 올리는 것이 가능하며, k8s 환경에서만 사용가능한 kubeflow의 환경 제약에 비교적 유연하게 대처할 수 있다고 볼 수 있다.
3.4) 작업 목적에 따라 명확하게 Workflow를 나눠 버전관리를 하고 싶을 때
Development, Staging, Production은 Flyte에서 제공하는 기본 도메인이며, 각 workflow는 이 3개의 도메인 내에서 실행된다.
새롭게 수행하는 데이터 프로세스나 ML 작업이라면 development에서 실행하고 관리하는 것이 가능하기 때문에, 이러한 목적에 따라 나눠 사용하는 기능을 제공하는 것도 Flyte를 Pipeline 플랫폼으로 도입할 때 고려하는 요소로 포함될 수 있다.
4. MLOps를 차근 차근 도입 중, 그리고 Use Case
Flyte 하나 도입하고 버그 정리하는 것만으로 한 달이 빠르게 지나갔는데, 우리 팀은 2021년 상반기에 다음과 같은 스택들을 배포하고 관리하고 있다.
아키텍처는 아직 도식화 중이라 포함되지 않았지만, MLOps 프로세스를 자동화하여 생산성을 극도로 높이는 것을 올해의 목표로 잡고 있다.
물론 스타트업이기에 시행 착오는 분명히 있을 것이지만, 주어진 문제를 조금씩 해결해 나가다 보면 서비스는 고도화 되어 있을 것이 분명하다.
현재 회사 내의 AI 부서 중 한 곳에서 AI 포트폴리오 관리 목적의 일환으로 주식, 채권 데이터를 가공하여, Snowflake에 배포된 DB로 저장하는 Workflow를 실행하고 있다.
이 작업은 매일 1회 수행되어야하며, 동일한 작업이지만, 매일 받는 데이터와 가공한 값이 다르다 보니, 별도의 버전 관리가 필요한 작업이었다.
Flyte에서 개별 Task를 다룰 때, Task 단위로 별도의 컨테이너로 작업을 다룰 수 있기 때문에, 실행 환경을 하나로 통합해야하는 걱정을 전혀할 필요가 없다. (상대적으로 Task 별로 의존성 관리하기가 쉽다.)
또한 Task 마다 설정된 리소스 사용량이 있기 때문에, 여러 리서치 엔지니어들이 workflow를 올리면서, 서버 전체의 리소스를 마구잡이로 사용할 염려도 거의 할 필요가 없기 때문에 사내 서버가 터지거나 OOM 에러가 발생할 일이 거의 없다고 생각해도 될 것 같다.
입사한지 이 포스팅을 올리는 날을 기점으로 정확히 2달이 되었는데, 배우고 익히는 것들이 매일 매일이 새롭고 좋은 동료들 덕분에 다양한 상황들을 배워 나갈 수 있는 것 같다.
전 세계 Software Engineer 상위 1%가 되는 그 날까지!
Ryan
