DevHwi

지난 장에서 Kubeflow를 겨우 설치하는 데 성공하였다. 아무래도 로컬 환경에서 자원을 쪼개서, Kubeflow를 돌리다 보니 조금 버벅거리는 감이 있지만, Kubeflow의 각 기능을 조금 더 자세히 알아보자. 가장 먼저 알아볼 기능은 Katlib이다. 사실, 클라우드 환경이 아니라 로컬에서 Kubeflow를 실행하다보니, Kubeflow UI에서 지원해 주는 Notebooks나 Tensorboard 기능은 사실 잘 와닿지 않았다. (로컬에서 실행하면 되기 때문에) 하지만, Katlib은 평소 네트워크 학습 과정에서 걸리던 하이퍼파리미터 튜닝등의 문제에 유용하게 사용할 수 있을 것 같아, Katlib부터 소개하기로 한다.  
 

Katlib

• Katlib은 앞선 장에서  설명했듯, 하이퍼파라미터 최적화 & 뉴럴 아키텍쳐 탐색을 지원해 주는 프레임워크이다. (개인적으로 Katlib은 머신러닝 워크플로우를 쿠버네티스 환경에서 실행하는 가장 큰 강점을 보여주는 프레임워크라고 생각한다.)
• Katlib는 각기  다른 하이퍼파라미터 설정이나, 아키텍쳐 탐색을 분산된 머신에서 동시에 실행하여, 최적의 값을 탐색한다. 
• 쉽게 말하면, Katlib은 한번에 여러 머신에서 실험 가능하고, 사용하기 쉬운 머신러닝 모델 탐색용 Cron Job이라고 생각한다.   
• Katlib은 아래와 같은 장점을 갖는다.
  • 자동화된 하이퍼 파라미터 튜닝 : 하이퍼 파라미터를 튜닝하는 일은 모델 개발자들에게는 번거로운 일이고, 서비스 제공자에게는 어느 정도 난이도가 필요한 일이다. Katlib에서 제공하는 자동화된 하이퍼 파라미터 튜닝은 머신러닝이나 Batch 프로그램에 대한 전문 지식이 없더라도 쉽게 사용 가능하다.
  • 분산 머신러닝 지원 : 머신러닝 연구자라면 가장 스트레스 받는 일 중 하나가 환경을 세팅하는 일이다. 머신 여러 개로 하이퍼파라미터를 각기 달리 실험할 때, 여러 개에 동일한 개발 환경을 세팅하는 것은 굉장히 번거롭고, 어려운 일이다. 특히, 소스 상에서 변경점이 생길 때마다, 모든 머신에서 반영이 필요하다. Katlib은 쿠버네티스를 이용하여, 클러스터 내의 여러 머신에서 모델 훈련이 실행되므로, 효율성을 높일 수 있다.  

Katlib 사용법

• Katlib을 실행하기 위해서는 "Experiment" CRD(Custom Resource Definition)을 사용하여, 작업을 정의하고, 실행해야한다. 
• 앞서 말한대로, Katlib은 Kubeflow 환경 하에서 뿐만 아니라, 그 자체로 독립적으로 실행할 수 있다. 하지만, Kubeflow하에서 사용하면 더욱 쉽게 사용할 수 있다.
• Kubeflow 환경 하에서 Katlib은 Experiments(AutoML) 메뉴에서 사용 가능하다. 
• "Experiment" CRD를 직접 작성하여 작업을 정의할 수도 있고, UI를 이용하여 쉽게 CRD를 작성 가능하다. 

• Kubeflow UI에서 Experiments(AutoML)를 실행했을때, 총 8개의 설정이 필요하다. 

• 첫 번째는, Metadata이다. 현재 수행에 대한 Job 명을 정할 수 있다.

• 두 번째는, Trial Thresholds이다. 실험에 대한 분산처리를 지정해 줄 수 있다. 각 Parameter는 다음의 의미를 갖는다.
  • Parallel Trials : 동시에 몇개의 실험을 진행할 것인지를 정해줌(H/W의 리소스를 효율적으로 사용하기 위해 정해줌, 분산처리)
  • Max Trials : 최대 몇번의 학습을 진행할지를 정해줌(과도한 H/W 리소스 사용을 방지)
  • Max failed Trials : 최대 몇 번까지 실패한 학습을 용인할지를 결정해 줌. Katlib의 수행 자동화 기능을 지원하기 위해 들어간 파라미터로, 실험 세팅의 실수 등의 이유로 정상적인 실험이 진행되지 않았지만, 인간이 바로 인지하지 못하는 경우 무의미한 실험들이 H/W를 점유하고 있을 수 있어서, 이러한 무의미한 실험등을 방지하기 위해, 최대 실패 횟수를 정해서, 이를 초과한 실험 실패가 발생했을 시, 실험을 중단함.
  • Resume Policy : 실험이 중단되었을때, 다시 시장하는 방법을 지정해 줌. ('Never' : 실험이 중단되었을 때, 재개하지 않음. 'Long Running': 실험이 종료된 뒤에서 Pod 및 리소스를 유지하여, 데이터를 유지하고 실험 결과를 확인 가능함. 'From Volume' : 실험이 종료된 후, 해당 실험에 필요한 볼륨이 자동으로 마운트 되어, 실험에서 생성된 데이터나 파일을 계속 사용하여 실험을 재개함.)

• 세 번째는, Objective이다. 모델 학습을 최적화하기 위한 최종목표를 정의 가능하다. Metric을 통해서, 여러개 Objective를 설정할 수 있고, 각 Metics에 대해, "Maximaze"와 "Minimize"를 정해, 탐색 목표를 정할 수 있다. 

• 네 번째는, Search Algorithm이다. 모델 탐색 과정의 알고리즘을 선택할 수 있다. 크게 Hyper Parameter tuning과 neural Architecture Search에 대한 알고리즘을 제공한다.
• Hyper Parameter tuning은 총 9개의 알고리즘을 제공한다. 그중 많이 사용하는 알고리즘은 아래와 같다.  
  • Grid : Grid Search(가능한 모든 조합 시도)
  • Random : Random Search(임의로 Hyper parameter 선택)
  • Bayesian Optimization : 후보 모델을 사용하여, Hyper parameter 조합을 평가하고, 그 Hyper parameter로 후보 모델을 업데이트하는 과정을 반복. 
• Neural Artchitecture Search는 크게 2가지의 알고리즘을 제공한다.
  • Efficient Neural Architecture Search(ENAS) : 하나의 모델을 학습시켜, 새로운 모델을 생성하는 방식을 사용함. 파라미터 공유 및 Weight Sharing 기술을 사용해서, 여러 작업을 수행하고 구성요소를 동시에 학습 및 업데이트함.
  • Differentiable Architecture Search(DARTS) : 아키텍쳐 검색과 학습을 동시에 수행하는 end-to-end 학습 방법. 알고리즘이 다양한 아키텍처를 조합하는 데 사용되는 가중치를 학습함. 

• 다섯 번째는, Neural Architecture Graph는 네트워크의 구성을 정의하기 위한, Input, Output 사이즈 및 Layer 갯수등을 지정한다. 

• 여섯 번째는, Neural Architecture Operations이다. NAS에서 사용되는 기본 연산을 위한, 네트워크 구조 생성 및 변경에 사용된다. 모델의 구조를 생성하기 위한 파라미터등의 가능한 후보를 정의해서, NAS에서 모델을 찾는데 활용할 수 있다.  

• 일곱 번째는, Metrics Collector이다. Metrics Collector는 각 실험들의 결과를 어떻게 수집하고, 측정할 것인지를 정의한다. Stdout처럼 단순 출력으로 받을 수도 있고, File이나, Prometheus 등을 통해서 수집 가능하다. 

• 마지막으로, trial의 환경을 정해줄 수 있는 Trial Template이다. 이 메뉴를 활용하여, Trial에서 사용할 수 있는 도커 이미지나 하이퍼파라미터 설정, 리소스 제한 등을 정의할 수 있다. Template를 제공하기 때문에 해당 Template을 수정하는 구조로 실험을 진행할 수도 있다. 

• 마지막 옵션까지 모두 설정하고, 아래 Edit 버튼을 누르면, 1~8까지 설정한 내용을 기반으로 "Experiment" CRD가 작성되어 있는 것을 확인할 수 있다. 
• 설정이 제대로 들어가있는지 확인하고, 변경도 가능하다. 설정이 제대로 진행되었으면, CREATE를 통해 실험을 실행한다. 

• 실험 결과는 아래와 같이 보인다. (로컬에서는 H/W 리소스 문제로 실행이 정상적으로 되지 않아서, Kubeflow 홈페이지의 이미지 활용)
• Experiments에서 생성한 실험들에 대한 성공 횟수와 진행 중인 횟수, 실패한 횟수를 확인할 수 있다. 

• 각 실험을 클릭해보면, Hyper Paramter 조합과 가장 최적의 Hyper Parameter 조합에 대한 정보를 얻을 수 있다. 

사실, Katlib은 매우 유용한 툴이지만, H/W 리소스가 분산 처리를 할 수 있을 정도로 많은 양이 필요하기 때문에, 사용이 제한적이다. 아무래도 개인의 경우에는 많은 자원을 동시에 활용하는 일이 적기 때문에, Katlib보다는 Bash를 이용한 Batch Job 등을 이용하는 게 좋을 것 같다. 하지만, 사내등의 하드웨어 환경이 풍부한 상황에서는 요긴하게 활용할 수 있을 것 같다. 

AI가 연구의 영역에서 실용 영역으로 침투하기 시작하면서, AI로 구성된 서비스를 어떻게 잘 제공할 것인지에 대한 수요가 높아지고 있다. 특히, chat-gpt로 AI 영역에서 엔지니어링의 중요성이 대두된 만큼, AI 서비스의 수집부터, 제공까지의 워크플로우를 어떻게 관리할 것인지에 대한 관심이 높아졌다. Kubeflow는 이런 상황 속에서 등장하고 발전했다. (처음 등장한 지는 조금 오래됐다 - 2018년)

ML workflow 란?

• Kubeflow를 알기 위해서는 ML workflow를 이해할 필요가 있다. ML workflow는 머신러닝 알고리즘을 개발하고, 이를 통해 만든 서비스를 배포하기까지의 일련의 과정들을 모두 포함한다. (사실, 머신러닝 & 딥러닝을 구분해야하지만, 해당 글에서는 머신러닝으로 줄여서 이야기한다.)
•  일반적으로 ML workflow는 다음과 같은 단계로 나뉜다. 
  1. 데이터 수집 : DB or Online 등에서 데이터를 수집한다.
  2. 데이터 검증 : 수집한 데이터를 검증한다.
  3. 데이터 전처리 : 수집한 데이터에서 노이즈 제거 & 결측치 대체 & 스케일링, Normalization & Augmentation 등을 수행한다.
  4. 모델 학습 : 머신러닝 알고리즘을 선택하고, 전처리된 데이터를 사용하여 모델을 학습한다. 
  5. 배포 : 모델을 실제 운영 환경에 배포하고 사용한다.

Kubeflow 란?

• Kubeflow의 시작은 구글에서 머신러닝에 사용되는 리소스를 효율적으로 관리하기 위해, Tensorflow Extended(TFX)을 사용하면서 처음으로 시작되었다. 후에 여러 개발자들이 모여서, 오픈소스 프로젝트로 공개되었다. 
• Kubeflow는 이름에서 알 수 있듯, Kubernetes에서 동작하는 ML 워크플로우 툴이다. Kubernetes는 머신러닝 Job에 굉장히 적합한 플랫폼인데, 이유는 다음과 같다.  
  • 머신러닝의 학습 및 배포에는 다른 서비스에 비해, 리소스 자원의 활용이 크다. 따라서, 리소스를 어떻게 잘 컨트롤하여, 학습하고 배포할 것인지가 중요하다. → Kubernetes의 유연성 컨트롤
  • 머신러닝 & 딥러닝은 환경 구축이 H/W나 OS, 라이브러리 버전 등에 따라 다 다르다. (머신러닝, 딥러닝 학습을 해본 사람들이면, 환경 구축에 정말 많은 시간이 소요된다는 것을 알 수 있을 것이다.) → Kubernetes의 장점인 확장성 & 유연성
• Kubeflow는 그 자체가 새로운 서비스라기보다는, Kubernetes 플랫폼 위에서 동작하기 위한, ML workflow에 필요한 여러 오픈소스 툴들을 모아놓은 것이다.
• 내가 생각하는 Kubeflow의 가장 큰 장점은, 서비스 구성 및 엔지니어링등에 상대적으로 약한 AI researcher들의 부담을 줄여주는 것이라고 생각한다. (운영단에 제공하는 서비스가 아니라면, Kubeflow의 필요성은 조금 약하다고 생각한다. 다만, Kubernetes 환경에서 모델을 학습하는 경우에는 쓰지 않을 이유가 없다.)

Kubeflow의 구조

• 아래 그림은 Kuberflow 홈페이지에 있는 Kuberflow 아키텍처에 대한 Conceptual Overview이다. 
• 맨 아래, 어떤 플랫폼에서든 Kubernetes를 활용할 수 있다는 것을 강조하고, 그 위에 Kubeflow가 올라가 있다는 것을 보여준다.
• 즉, Kubernetes 환경 위에서 여러 ML workflow component 들을 묶어서, Kubeflow로 제공해 주고, 그 위에 Pytorch나 Tensorflow등 다양한 언어를 활용해서 Kubeflow를 운영할 수 있다는 것을 강조하고 있다.
• 그림의 우측에 Istio(트래픽 관리, 보안 등), Argo(워크플로우 관리), Prometheus(모니터링), Spartakus(사용자 데이터 수집) 등을 함께 활용하여, 운영 환경의 안정성을 높일 수 있다는 것을 보여준다.

Kubeflow의 Component

• Kubeflow는 여러 ML workflow 툴들의 집합이라고 위에서 소개했다. 어떤 것이 있는지 알아보자.
• 우선, ML workflow를 크게 2개로 분류할 수 있다. 알맞는 모델을 찾기 위한 실험 단계와, 선택된 모델을 가지고 서비스를 운영하는 단계이다.
• 실험 단계에서는 다음과 같은 Component 들을 제공한다.
  • Jupyter Notebook : Kubernetes 위에서 Jupyter Notebook을 사용해서, 모델을 개발 & 실험해볼 수 있게 해준다. 
  • Fairing : 모델의 생성 & 학습 & 배포등을 Kubernetes Cluster로 쉽게 요청할 수 있게 해준다. (즉, 모델을 Docker Image 형태로 Kubernetes에 뿌려준다.)
  • Katlib : 하이퍼파라미터 최적화 & 뉴럴 아키텍쳐 탐색을 지원함. (각기 다른, 하이퍼파라미터와 아키텍쳐를 설정해서, 원하는 결과가 나올때까지 실험해 볼 수 있음)
• 운영 단계에서는 다음과 같은 Component들을 제한다.
  • Pipelines : ML workflow(수집 & 검증 & 전처리 & 학습 & 배포)를 end-to-end로 만들어 주는 툴 (Argo를 사용한다.)
  • Metadata : Kubeflow Pipelines에서 실행되는 ML workflow에 대한 metadata를 관리하는 서비스
  • KFServing : Kubernetes 위에서 머신러닝 서빙(Serving)을 위해 사용하는 툴
  • TensorRT : 미리 학습된 모델의 정확도를 유지하면서, Inference 속도를 최적화해주는 툴
  • Pytorch : 파이토치
  • TFServing : Tensorflow 모델의 서빙(Serving)을 위해 사용하는 툴
  • Seldon : 머신러닝 모델의 배포 및 관리를 위한 툴
  • Tensorboard : 머신러닝 모델 디버깅 & 시각화 툴

Kubeflow의 UI

• Kubeflow는 Command 명령어로 구동 가능하다. 하지만, Command 명령어로 Kubeflow 내에 있는 기능을 각각 사용할 것이라면, Kubeflow를 사용하는 의미(통합성 & 편의성 등...)가 덜하다고 생각한다.
• Kubeflow의 UI는 편하면서, 불편하다. 메뉴에 있는 각 Component들을 각각 사용하기에는 편한데, 그 사이에 어떠한 연관성이 있는지 등등은 드러나지 않는다. (어느 메뉴들은 같이 사용해야하고, 어느 메뉴는 독립적이고...)
• Kuberflow는 "Central Dashboard"라는 UI를 통해, 각 component를 쉽게 접근 할 수 있도록 해준다.  
  • Home: Home이다. 
  • Notebook Servers: Jupyter Notebook 서버를 사용할 수 있게 해준다. 
  • TensorBoards: Tensorboard를 쉽게 사용 할 수 있게해준다.
  • Models: 배포된 KFServing 모델들을 관리한다.
  • Volumes: Cluster의 저장소를 관리한다.
  • Experiments (AutoML): Katlib(하이퍼파라미터 튜닝 등)을 사용할 수 있게 해준다. 
  • Experiments (KFP): 실험용 Kuberflow Pipeline(KFP)을 사용할 수 있게 해준다. 
  • Pipelines: end-to-end Kuberflow Pipeline(KFP)을 사용할 수 있게 해준다. 
  • Runs: Kuberflow Pipeline(KFP)의 실행을 관리한다.
  • Recurring Runs: Kuberflow Pipeline(KFP)의 반복적 실행을 관리한다. 
  • Artifacts: Metadata를 확인 할 수 있게 해준다. 

Kubeflow를 보면서, 느낀 것은 아직은 ML workflow의 end-to-end를 책임지기에는 역부족이지만, 앞으로 발전해 간다면 정말 유용하게 사용될 것 같다. 아무래도, 각 Component가 독립적으로 개발되어서, Component 간에 연결이 완벽하지 않다는 느낌을 자주 받았다. Component 간의 연결성이나, kubeflow 자체의 서비스 등을 제공한다면 더 좋을 것 같다. 우선, 다음 장부터 Kubeflow를 설치해 보기로 한다.