Flyte에서 Argo Workflow로 이전한 이유와 Argo Stack 사용하기
Part.1 다시 보기: https://medium.com/p/9d986c0bdc2e
2021년부터 2023년 말까지 크래프트 테크놀로지스에서는 전사적인 데이터 파이프라인으로 Flyte를 사용했다.
Flyte는 Lyft라는 업체에서 만들어 배포했으며, 그 과정을 담은 글은 이 글에서 확인할 수 있다.
또한 팀에서 당시 Flyte를 도입할 때 고려했던 여러가지 사항들이 있었지만 결과적으로 사용하면서 몇 가지 문제 사항에 직면했다.
첫번째, Flyte의 RBAC (Role Base Access Control, 즉 권한 관리)가 오픈소스에서 전혀 제공되지 않는다.
이건 나름대로 큰 문제였는데 각 팀별로 프로젝트 단위의 작업은 가능하지만, Namespace를 분리해서 팀별 작업 환경을 분리하는 것은 사실상 안되었기 때문이다.
즉, 각 팀의 작업환경이 다른 팀에게 그대로 보이는 상황이 존재했고, 각 팀에서 작업 환경이 서로 격리 되었으면 좋겠다는 얘기가 지속적으로 있었으나 오픈소스를 사용하는 입장에서 기능 추가를 하기가 쉽지 않았다.
무엇보다 Flyte 팀의 Release plan을 확인해봤으나 RBAC에 관한 사항은 찾아볼 수 없었고 (Union ML 이라는 별도의 클라우드 솔루션을 운영하는 관리자 입장에서 오픈소스에 RBAC을 추가하기는 쉽지 않았으리라…), 나를 비롯한 여러 사용자가 문의해봤으나 원하면 직접 구현해서 PR을 보내라는 답변만을 받았다.
이 과정에서 Union ML 사용 관련 문의도 운영진에 해봤으나, PoC 이후 비용이 만만치 않았고, PoC 이후 사용 금액이 꽤 비싸서 (Union ML 홈페이지에 별도 비용은 없고, PoC 이후 비용 청구 사항에 대해 별도 안내를 해준다) 결국 포기했던 기억이 있다.
그러나 전사적으로 Workflow 파이프라인은 필요했고, Flyte를 코어로 삼아서 작업 환경을 관리하는 모듈로 Priming(마중물이라는 뜻으로, 기본적인 의미는 펌프를 사용할 때 미리 펌프에 부어주는 물을 의미한다. 보통 (큰 결과를 이끌어내는) ‘첫 계기' 또는 ‘초석'으로 비유하곤한다.)라는 사내 파이썬 SDK를 개발해 배포했다.
Priming 은 Flyte에서 사용하는 CLI인 FlyteKit를 Wrapping하여 빌드한 SDK로 리서치 엔지니어들이 Flyte와 Flytekit 등 본인들의 메인 비즈니스 작업을 수행하는데 전혀 필요 없는 러닝 커브가 존재했기 때문에 이 부분에 대한 추상화 작업이 필요했다.
데이터 파이프라인을 사용하는데 있어 리서치 엔지니어에게 필요한 최소한의 학습 사항은 2가지만 있으면 된다고 생각했다.
- 팀 작업이 실행되기 위한 도커 환경
- Flyte GUI 사용 방법
실제로 Priming을 구축하면서 필요로하는 사내 인증 (Keycloak, harbor), k8s 리소스 지정 방법, 기타 다른 애플리케이션 연동(mlflow, 사내 스토리지 서버 등), 알림 기능 등을 추상화 시켰고, 가이드 문서를 제작할 때 어떤 문자열을 매개변수로 주면 되는지 정도만 간단하게 작업해서 추가할 수 있게 SDK를 빌드했다.
Flyte에 작업을 올리는 과정도 Github Action으로 CI를 팀에서 구성해 올렸기 때문에 Priming을 사용한 스크립트를 github에 업로드만 하면 도커 빌드 → flyte 업로드 과정은 모두 Action으로 올라갔기 때문에 나름 복잡한 flyte 실행 프로세스를 잘 추상화 시켰다고 생각한다.
그리고 Flyte를 한참 사용하다가 RBAC 문제를 해결할 수 없다보니, 팀에서 한 번 논의가 나왔던 것은 팀 별로 DNS를 별도로 Flyte 애플리케이션을 쿠버네티스에 배포해서 사용하자는 얘기가 나왔고, 내가 담당자로 배정되서 팀 단위로 flyte를 배포해주는 작업을 맡게 되었다.
단순히 DNS 바꿔서 배포만 여러개 해주는 작업이라 생각했는데 (실제 MLFlow도 RBAC이 오픈소스 버전에서는 안되어서 이렇게 사용 중이다), Flyte에서는 한 가지 치명적인 문제가 있었다.
CRD가 Flyte 클러스터 당 하나밖에 배포가 안된다는 점이다.
그리고 RBAC 외에도 간단한 코드 수정에도 도커 이미지 변경이 꼭 필요하다는 점이 무척 번거로운 요소 중 하나였다.
이건 사실 쿠버네티스 아키텍처를 생각해보면 Flyte에서 왜 이런 선택을 했는지 이해가 되는데 쿠버네티스에서 작업의 최소 실행 단위는 Pod 이므로 하나의 Pod에서 실행된 작업을 다음 Pod로 전달하는 행위는 하나의 프로세스에서 다음 프로세스로 결과 값을 전달하는 행위인데, 각 Pod에서 결과값의 타입과 값을 보전하는 방법 중 하나로 도커 이미지의 값을 그대로 가져와 사용하는 것을 고려했으리라 생각한다.
이 과정에서 데이터를 온전하게 전달하기 위해 Flyte에서는 각 함수의 타입 관리가 무척 엄격하다.
(파이썬에서 Type hint를 사용하는 환경을 Flyte에서는 강제한다. Type Hint가 없으면 타입 정의가 안되어 있다고 바로 에러를 발생시킨다.)
다음 편에서 얘기하겠지만, Argo workflow에서는 도커 이미지의 값을 그대로 가져와 사용하지 않고, 각 Pod의 결과 값을 바이너리 파일로 구성해서 다음 Pod로 전달하는 방법을 선택했다.
그래서 이러한 3가지 문제점으로 인해 종종 팀에서 Workflow 파이프라인 변경에 대해 논의가 지속적으로 이뤄졌고, 결과적으로 Argo workflow를 선택하게 된 것이다.
Argo Workflow는 flyte를 사용하면서 발생했던 모든 단점들에 대한 대책이 있고, 무엇보다 Argo Event, Argo CD 등 Argo Project에서 제공하는 오픈소스들과 호환이 된다는 점이다.
Argo Workflow를 도입하기까지 시간이 좀 소요되었지만, 이미 사용 중인 Flyte라는 애플리케이션을 거둬내기란 쉽지 않는 선택이었고, 새로운 애플리케이션으로 대체하기 위해 필요한 가이드 작성과 새로운 SDK 개발, 그리고 각 팀 별 서포트 등 추가적으로 필요한 리소스가 많이 있었으므로 업무적으로 여러 많은 선택과 고려사항이 반영되어야 했다고 생각한다.
이제 3번째 파트에서는 Argo workflow 소개와 도입 과정에서 필요했던 나의 발품 팔이, 그리고 사내 SDK인 Qworkflow 도입 과정을 안내하고자 하며, 현재 각 팀별 usecase를 어떻게 접목하는지, 그리고 사용 과정에서 발생하는 문제들에 대한 설명이 포함될 것이다.
Ryan
