1. Flyte와 MLOps
크래프트 테크놀로지스에서는 리서치 엔지니어들의 원활한 작업 환경 구성과 컴퓨팅 리소스의 동적인 관리를 위해 쿠버네티스와 Flyte라는 Workflow Orchestration을 도입하여 운영하고 있다. (쿠버네티스와 flyte 관련 내용은 하단 reference 참고)
다만, Ops의 관점에서 flyte 사용법을 익히고 도입하는 것은 어느 정도 시간을 들여 사용해보고, 작업을 flyte에 올려보면 되지만, 사내의 모든 리서치 엔지니어가 똑같은 과정을 통해 flyte를 사용하는 것은 무척 비효율적이다.
빠르게 배우고 사용하면 좋지만, ML 리서치 업무와 소프트웨어 엔지니어링 업무 양쪽을 모두 이해하지 못하고 있는 분들도 상당하기 때문에 이러한 관점에서 Workflow Orchestration에 보다 쉽게 접근해주는 과정이 필요했다.
특히 Flyte를 사용하면서 리서치 엔지니어들이 굳이 알필요가 없는 부분들이 어딜까?
팀 내에서 여러 차례 논의를 한 결과, “flyte의 거의 대부분”을 리서치 엔지니어가 알 필요가 없었다.
음?
flyte의 거의 대부분을 알 필요가 없다면, 우리가 기껏 쿠버네티스에 배포해놓은 flyte를 쓸 일이 없다는 것인가?
아니다.
리서치 엔지니어들이 원하는 것은 아래와 같은 순서일 것이다. (사실 모든 소프트웨어 엔지니어링이 동일할 것이다)
- 작업한 코드를 실행한다.
- 실행한 코드가 성공하고, 결과를 얻는다.
- 실행한 코드가 실패할 경우, 코드를 분석한다.
- 결과에 따라 2 또는 3번을 다시 실행한다.
MLOps 레벨에서 무엇을 도입하더라도 위의 4가지 단계의 실행은 자동화가 될 뿐, 변함이 없으며 Flyte를 사용하더라도 위의 네 단계는 불변이다.
따라서, Flyte를 도입함으로써 발생하는 다음의 사항들은 진입 장벽으로 다가오기 때문에 알 필요가 없다는 것이다.
- Flyte의 실행을 위한 관련 커맨드
- Flyte 프로젝트 관리 및 도메인 관리 (생성, 삭제, 수정 등 — flyte project & flyte domain이라 구글에 검색하면 flyte에서 프로젝트 단계에 따라 관리하기 위해 도입해 사용하는 개념이라는 것을 바로 알 수 있다.)
- 도커 사용법 (flyte로 workflow를 실행하기 위해서는 pod를 띄워야하는데, 이 때 docker로 이미지를 빌드하는 과정이 포함된다.)
- 쿠버네티스 사용법 (특히 k8s를 통한 workflow logging과 관련한 사항)
위의 네 가지 내용은 flyte 사용과 관련하여 필수적으로 알아야하는 요소 같은데, 이 과정들에 대한 이해 없이 어떻게 flyte를 이용해 기존과 동일한 작업 환경을 유지할 수 있을까?
2. Github Action과 MLOps
우리가 정확히 원하는 사항을 반영하면서, 리서치 엔지니어들의 flyte 진입 장벽을 해소는 방법으로 CI를 도입하게 되었다.
특히 보편적으로 잘 알려져 있는 Github Action을 사용하게 되었는데, 그 이유는 팀 레포를 깃헙 엔터프라이즈로 관리하고 있을 뿐더러 리서치 엔지니어들도 프로젝트 관리를 위해서는 git에 대해 이해가 있기 때문에 수용하기 쉽다는 점 때문이었다.
그리고 이 예상은 정확히 들어 맞았다.
우리가 생성한 아래의 절차에 따라 github action은 충실하게 동작했다.
- 사용자가 설정한 branch에 따라 해당 branch에 이벤트가 발생하면 (commit) CI가 실행된다.
- CI 가 실행되면 아래의 두 단계가 절차적으로 실행된다.
- commit 된 코드의 내용과 함께 docker image가 빌드된다.
- 빌드된 이미지로 flyte project에 작업을 올리기 위한 절차가 실행된다.
- flyte project에 올리기 위해서는 flytectl과 같은 커맨드 사용, flyte project & domain 지정 및 serialize 가 포함되어 있으며 k8s 의 로깅은 EFK(Elastic Search, Fluent bit, Kibana)로 flyte console에서 확인할 수 있다.
3. 프로세스를 종료한다. (이후 생성된 이미지와 코드는 flyte에 pod로 배포되어 실행 결과를 flyte console 에서 볼 수 있다.)
따라서, github action을 실행하면 위와 같이 정상적으로 도커 이미지 빌드와 푸시, flyte 실행을 확인할 수 있으며 실행 결과를 flyte console에서 볼 수 있다.
잘 실행되면, 아래와 같이 의도한 workflow의 DAG가 그려진 것을 함께 확인 가능하다.
CI를 실행하는 스크립트의 경우, 쉘 스크립트와 무척 비슷하다.
다만, github action 내에서 제공하는 docker plugin 등을 추가로 연결해 줄 필요가 있고, 관리하는 방식에 따라 custom action나 self-hosted runner 등을 연결해 사용할 수 있다.
3. 남은 문제점과 풀어나갈 방향
위와 같이 github action을 사용하니, 사실상 유저가 터미널 상에서 flyte를 직접적으로 접근하여 사용하는 과정을 생략할 수 있게 되었다.
무엇보다, 현재 몇 몇 리서치 팀이 production side에서 사용하면서 우리에게 여러 usecase를 제공하고 있기 때문에, 사용 방식을 점점 개선해 나갈 수 있으리라 믿는다.
다만, 최근에 한 가지 변화와 두 가지 이슈가 있었다.
한 가지 변화는 CI를 각 팀 별 레포에 적용하여 사용하기 위해 template repo를 생성하여 fork 해 사용할 수 있게 만들어뒀는데, fork 한 시점에서부터 CI의 최신 버전 업데이트를 바로 반영하기가 어려웠던 점이고, 이를 개선한 점이다.
이를 custom action으로 변경하여 운영을 하게 되었고, 이제는 MLOps 팀에서 버전을 업데이트하면, 팀 별로 action 내 버전만 변경함으로써 언제든 사용하고 싶은 버전을 사용하는 것이 가능해졌다.
또한 Flyte 접근성이 향상되니, 좀 더 많은 리서치 엔지니어분들이 flyte를 사용하게 되면서, 기존의 jupyterhub를 사용할 때, 리소스 수거가 잘 안되던 부분 (인스턴스가 떠 있으면, 컴퓨팅 리소스 — GPU 등 — 를 계속 붙잡고 있어, 다른 사용자들의 필요한 리소스 사용이 조금 어려운 부분이 있었다)을 함께 조금씩 해결해 나갈 수 있을 것으로 보인다.
그리고 RBAC과 Self-hosted runner 사용에 대한 이슈가 있다.
flyte, mlflow와 같은 MLOps 프레임워크가 오픈소스로 배포 되어 있지만, 코어만 오픈되어 있고 유저 및 그룹 관리 등과 같은 핵심 기능들이 빠져 있어서, 현재는 팀에서 이 부분을 어떻게 해결할지 논의 중이다.
마지막으로 컨테이너 이미지 파일 용량이 커지면 CI 인스턴스 실행 시간이 길어지는 것을 고려해 self-hosted runner 사용을 고민하고 있다.
아무래도 github 클라우드 내에서 실행되는 도커 이미지 생성 시간이 길어서 캐싱 등도 고민하고 있으나, 전반적으로 빌드 시간을 향상시키려면 사내 서버로 빌드하는 게 더 빠르다는 생각이 든다.
회사 업무를 하면서 MLOps와 다양한 개발 상황에 대한 대응 방법을 배우고 있어 뿌듯하다.
4. Reference
- k8s QoS 관리하기
- k8s 위에 띄워진 애플리케이션에서 Nvidia Multi Instance GPU (MIG) 사용량 체크하기
- ML Pipeline에 Flyte 도입하기
- Flyte ML Pipeline 특징 정리하기
Ryan
