[MLOpsKR 커뮤니티 발표 2021] Kubeflow + KRSH vs Airflow

0. Intro

MLOpsKR 커뮤니티 발표 영상들을 유튜브에서 시청 중, 메모해두면 나중에 편할 것 같다 라는 생각이 들었다.

현 직장에서 공부하고 개발중인 MLOps, ML pipeline 에 대한 내용들이 많이 나와서 정리해본다.

 

그리고 내가 알고있는 ML workflow 구축 도구인 Airflow 와 비교해보았다.

(정확하지 않은 정보가 있다면 언제든지 피드백 부탁드립니다)

 

주 내용: Kubeflow Pipeline + KRSH

 

유튜브 영상 원본: MLOps KR 커뮤니티 06 KRSH : 선언형 Kubeflow, Terraform처럼 파이프라인 관리하기, 김완수 Riiid

 

1. Kubeflow 

Kubernetes 위에서 container 기반으로 ML workflow 를 구축하고 배포하기 위한 도구이다.
Argo 라는 Kubernetes 기반 workflow 구축 도구를 기반으로 개발이 되었다.

단순히 워크플로우만을 구축하는 도구가 아니라 Kubernetes 에서 AutoML 을 구축하는 Katib, 혹은 서빙서버로 사용할 수 있는 KFServing, 혹은 다수의 사용자들이 Kubernetes node 에 리소스를 Jupyter notebook 에서 할당받아서 실험을 공유하고 자원관리를 편하게 하면서 실험할 수 있는 Jupyter server 같은 여러가지 컴포넌트들이 존재합니다.

From Hidden technical debt in machine learning systems

• 실제 ML 시스템에서 ML code 의 비중은 매우 작다. 반면에 주변 인프라는 방대하고 복잡하다.
• 컨테이너 기반으로, 빠르고 일관된 배포가 가능하다.
• Kubernetes 를 사용의 장점.
  • 컨테이너의 배포, 확장, 관리를 자동으로 해준다.
  •  머신러닝 단계에 따라서 다른 환경 설정이 가능하다.
  • 클라우드 환경일 경우, (리소스의 사용이 유연함으로) 비용절감 가능하다.
• Jupyter server component 의 장점
  • Machine Learning Life Cycle 은 항상 데이터 탐색 (pre-processing) 과 시작한다.
  • Kubeflow 에서 Jupyter notebooks 는 Fairing 을 통해 Kubernetes 에 training jobs 를 제출할 수 있다.
• KFServing 의 장점
  • 통함 데이터 플레인 및 사전 구축 된 모델 서버를 사용하여 조직 전체에서 모델 서비스를 표준화 하도록 지원
  • 추론 서비스 / 서버를 배포, 모니터링하고 추론 워크로드를 확장하는 단일 방법
  • 데이터 과학자가 모델을 프로덕션에 배포하는 데 걸리는 시간을 크게 단축
  • KFServing 이란?
    • Serverless Inferencing on Kubernetes
    • delivers high performance and abstraction interfaces for machine learning frameworks like TensorFlow
• Apache Spark 지원
• TensorFlow Transform 지원 
• 이외의 여러 ML/DL 을 위한 다양한 도구들을 지원한다.

1-1. Kubeflow Pipeline

From Kubeflow

이미지 설명

• 박스 => Component => 하나의 역할을 수행한다.
• 컴포넌트들이 상호연결되어 순차적으로 실행되면서 특정 역할을 수행하게 된다.
  • Airflow 로 치자면, 각 태스크가 순차적으로 진행 되는 것.
• 각 컴포넌트는 컨테이너 기반으로 동작하기 때문에 환경이 분리되어있다.
• Kubernetes 에 자원할당기능을 위임시켜 가장 안정적인 쿠버네티스 노드 위치에서 파이프라인 동작할 수 있게 한다.
• 환경이 이미지화 되어있다. -> 다른 환경에서 시험하고 성공적일 시 그 환경을 쉽게 배포 가능하다 (컨테이너 특성)

1-2. Kubeflow pipeline 의 특성

Kubeflow platform overview from Kubeflow documentation

1-2-1. 조합가능성

Kubeflow 의 components 들은 기본적으로 도커이미지를 기반으로 구축된다. 그 이미지를 기반으로 수정해야 될 명령이나 코드를 구현하고 인풋 아웃풋에 대한 인터페이스를 정희해서 사용하게 된다.

각 컴포넌트는 결코 하나의 컴포넌트를 위해서 개발된 게 아니라 여러 파이프라인에 걸쳐서 사용 가능하다.

• 만약 Airflow 에서 하나의 Component 가 Task 라면, Airflow 의 Task 들은 Dag 에 걸쳐서 사용 불가하다면, Kubeflow 는 가능하다.

이것은, 소프트웨어 엔지니어링의 "중복을 최소화" 하는 개념을 지킬 수 있다.

컴포넌트의 재사용을 통해 End-to-End 파이프라인을 빠르게 구축할 수 있다.

1-2-1. 이식성

Kubeflow 는 클라우드 네이티브 아키텍처로 개발 되었다.

=> Azure 든 AWS 든 GCP 든 환경에 구애받지 않고 설치하고 개발할 수 있다.

 

Kubernetes 를 환경에 설치하고 그 위에 Kubeflow 를 올리기만 하면 All Good.

1-2-1. 확장성

리소스 스케줄링의 자유로움 => Kubernetes 의 리소스 스케줄링 기능 그대로 활용 가능

• Airflow 는 지원하지 않는다.
• 대부분의 ML workflow 구축 도구들은 지원하지 않는다.

클라우드 서비스에서 파이프라인을 구축할 경우, 자원을 효율적으로 사용 가능하다. => 비용절감

GPU 사용이라던지, Memory 사용이라던지, 유연한 resource scaling 가능.

1-3. Kubeflow pipeline 의 구성요소

1-3-1. Pipeline

• 일반적인 하나의 함수처럼 동작합니다 => [ 인풋 > 파이프라인 > 아웃풋(Artifact) ]
• 파이프라인의 아웃풋은 MiniO 라는 Artifact 스토어에 저장된다.
• 다수의 컴포넌트라는 요소들로 구성되어있다.
• 하나의 python 함수에 kfp.dsl.pipeline 데코레이터 붙이면 그게 파이프라인.
  • Airflow 의 Dag 과 비슷하다. (@dag 데코레이터)

1-3-2. Component

하나의 컴포넌트는 하나의 도커 이미지처럼 동작한다.

• BaseOp
  • parent class
• ContainerOp
  • 컨테이너를 기반으로 실행되는 특정한 동작을 수행하기 위한 컴포넌트
  • e.g. 어떤 모델을 학습 > 실제 컴퓨팅 리소스를 이용하여 연산을 수행
• VolumeOp
  • Kubernetes 상에 있는 persistent volume claim 이라는 리소스를 기반으로 구현
  • ContainerOp 들 사이에 마운트 되어서 데이터를 서로간에 공유할 수 있는 공유 볼륨으로 주로 사용됨
    • Airflow 로 치자면 Xcom 과 비슷하다. (동작 원리는 다름)
• ResourceOp
  • Kubernetes 의 어떤 자원도 생성하고 활용할 수 있음

1-4. Kubeflow pipeline 배포

1-4-1. 배포과정

1. 파이프라인 작성
2. DSL 컴파일러를 통해 컴파일
   • .yaml
3. 파이프라인 메타 데이터 추가
4. KF UI 에서 업로드 -> 단점으로 적용됨.

1-4-2. 단점

• 형상관리가 어려움
  • Kubeflow 는 UI 로 관리되지만 파이프라인 자체는 code 로 관리되기 때문에 배포된 파이프라인의 버전과 로컬 혹은 github 에 있는 파이프라인의 버전의 싱크가 맞는지 헷갈림.
  • 예를들어, 깃헙의 코드가 배포 된건지, 혹은 제거되어야 하는건지, 혹은 제거된 파이프라인인지.
• 업로드 과정이 불편함
  • 작은 업데이트가 있어도, 코드 작성하고 컴파일하고, 버전 작성하고, UI 접속해서 업로드하고...
  • 복잡하다! 파이프라인 업데이트가 소극적으로 변한다!
• CI/CD 자동화 하는게 불편함
  • Kubeflow api 까지 까면서 직접 수행해서 만들어야 함.. 귀찮다!

2. KRSH

KRSH 는 Kubeflow pipeline 을 선언적으로 관리하며, pipeline 의 개발, 배포 주기를 단축시킬 수 있다.

1-4-2 에서 기술된 단점들을 극복하고자, 개발자들이 파이프라인 개발에만 몰두할 수 있도록 설계되었다.
레포지토리를 기반으로 파이프라인을 관리한다. CI/CD 를 쉽게 가능하게 한다.

• 선언적
  • 파이프라인을 선언하고 레포와 파이프라인의 코드가 항상 동일한 상태로 유지됩니다.
• Write - Plan - Apply
  • 세개의 사이클로 배포가 된다.
  • write -> 파이프라인 작성
  • plan -> 어떤 변화를 줄 지 확인
  • apply -> 적용

2-1. 사용법

1. command: pip install krsh
2. command: krsh create project 
   • krsh 의 기본베이스라인 베이스 DIR 생성
     • components/
     • dockerfiles/
     • pipelines/
3. command: krsh configure
   • 설정 - kubeflow-application 이라고 설정했다고 가정함.
4. krsh create pipeline "파이프라인명" -ns kubeflow-application
   • name space 생성
   • 실제 kubeflow 에 pipeline 생성이 아니라 템플릿을 생성하는 명령어
5. pipelines/ 안에 "파이프라인명"/ 이 생성된 것을 확인할 수 있다.
6. pipeline.py
   • 파이프라인의 코드를 작성
7. pipeline.yaml
   • 파이프라인을 싱킹하기위해 configuration 
   • 오토세팅이 되어있음
   • namespace 추가 등의 수정 가능
8. krsh plan
   • pipleline.py 에서 write 한 내용이 kubeflow 에 어떤 변화를 일으킬지 확인할 수 있다.
     • git status 와 비슷한 것 같다.
9. krsh apply
   • 플랜을 보여주고, yes 입력 시, apply 된다.
   • 단, apply 되는 파이프라인이 많아지게 되면 속도가 느려진다.
     • apply-mkey 옵션을 주면 멀티프로세싱으로 진행되며 훨씬 빠르게 진행된다.

3. Scheduling

3-1. Kubeflow

3-1-1. Kubeflow

Kubeflow 자체에서 스케줄링을 하고싶을 경우, 간단하게 UI 로 설정할 수 있다.

1. New Experiment
   •  a workspace where you can try different configurations of your pipelines 
     
   •  it's unnecessary to create new if more than one exists
     

     

     
     
2. Start a recurring run -> Run Type
   
   • Periodic: 특정 기간마다 experiment 실행
   • Cron: cron job 실행

Periodic from https://lsjsj92.tistory.com/593

cron from https://lsjsj92.tistory.com/593

3-1-2. API versions

airflow 에서 지원되지 않아서 골머리를 앓았던, create new run, create new experiment, greate new job, create new pipeline 등등 전부 제공한다.

 

https://www.kubeflow.org/docs/components/pipelines/reference/api/kubeflow-pipeline-api-spec/