Kubeflow
Machine Learning Toolkit for Kubernetes.
Training Operators
Training Operators는 텐서플로우(TensorFlow), PyTorch, MXNet 등 다양한 딥러닝 프레임워크에 대해 분산 학습을 지원합니다. 쿠버네티스 상에서 머신러닝 모델을 분산 학습하여 학습에 드는 시간을 줄일 수 있습니다. 사용자가 분산 학습 명세서를 작성하여 쿠버네티스에 배포하면 쿠브플로우 Training Operator는 명세서에 따라 워크로드를 실행합니다. 명세서에는 머신러닝 모델 코드를 담고 있는 도커 이미지 경로와 분산 학습 클러스터 정보 등을 정의합니다.
Experiments (AutoML)
AutoML은 머신러닝 모델의 예측 정확도와 성능을 높이기 위한 반복 실험을 자동화하는 도구입니다. 쿠브플로우에서는 카티브(Katib)를 사용하여 AutoML 기능을 제공합니다. 카티브는 하이퍼 파라미터 튜닝(Hyper Parameter Tuning), 뉴럴 아키텍처 탐색(Neural Architecture Search, NAS) 기능이 있습니다. 하이퍼 파라미터 튜닝은 모델의 하이퍼 파라미터를 최적화하는 작업이고 NAS는 모델의 구조, 노드 가중치 등 뉴럴 네트워크 아키텍처를 최적화하는 작업입니다.
카티브를 이용하면 학습률(Learning rate) 하이퍼 파라미터가 0.1, 0.05 중 어느 값이 모델의 예측 정확도를 높이는 값인지 찾는 실험을 자동화할 수 있습니다. 먼저 Experiment (AutoML) 명세서를 작성한 후 쿠버네티스에 배포하면 카티브가 명세서에 정의한 하이퍼 파라미터와 병렬 처리 설정에 따라 실험을 동시에 수행하여 가장 성능이 좋은 하이퍼 파라미터를 찾습니다.
KServe
쿠브플로우는 KServe를 통해 쿠버네티스에 머신러닝 모델을 배포하고 추론 기능을 제공합니다. KServe는 Endpoint, Transformer, Predictor, Explainer로 이루어져 있습니다. Endpoint가 Predictor에 데이터를 전달하면 Predictor는 데이터를 예측하거나 분류합니다. Endpoint는 데이터의 가중치 비율을 조절하여 Predictor에 전달할 수 있어서 A/B테스트도 가능합니다.
Transformer나 Explainer는 필요에 따라 추가 가능한데 Predictor 와 연결하여 사용합니다. Explainer는 데이터를 예측하거나 분류한 결과에 대해 판단 이유를 제시하는 설명 가능한 인공지능(eXplainable Artificial Intelligence, XAI) 역할을 하며, Transformer는 데이터 전처리, 후처리 기능을 제공합니다.
Kubeflow Pipelines (KFP)
Kubeflow Pipelines(KFP)은 머신러닝 워크플로우를 구축하고 배포하기 위한 ML Workflow Orchestration 도구입니다. KFP의 목표는 Pipelines과 Pipeline Components를 재사용하여 다양한 실험을 빠르고 쉽게 수행하는 것입니다. Pipelines은 Pipeline Components을 연결해서 DAG (Directed Acyclic Graph) 형태로 Workflow를 구성할 수 있으며, Workflow Engine으로 Argo Workflow를 사용합니다.
API Deployment
대표적으로 다음과 같은 오픈소스 추론 엔진들이 개발되었습니다.
- Tensorflow : Tensorflow Serving
- PyTorch : Torchserve
- Onnx : Onnx Runtime
Serving Framework
쿠버네티스 환경에서 이러한 추론 엔진들을 사용하여 API Deployment를 한다면 어떤 작업이 필요할까요? 추론 엔진을 배포하기 위한 Deployment, 추론 요청을 보낼 Endpoint를 생성하기 위한 Service, 외부에서의 추론 요청을 추론 엔진으로 보내기 위한 Ingress 등 많은 쿠버네티스 리소스를 배포해 주어야 합니다. 이것 이외에도, 많은 추론 요청이 들어왔을 경우의 스케일 아웃(scale-out), 추론 엔진 상태에 대한 모니터링, 개선된 모델이 나왔을 경우 버전 업데이트 등 추론 엔진을 운영할 때의 요구사항은 한두 가지가 아닙니다.
이러한 많은 요구사항을 처리하기 위해 추론 엔진들을 쿠버네티스 환경 위에서 한 번 더 추상화한 Serving Framework들이 개발되었습니다.
개발된 Serving Framework들은 다음과 같은 오픈소스들이 있습니다
- Seldon Core
- Kserve
- BentoML
단점
- Kubeflow: Not ready for production?
- Is Kubeflow Dead?. This is a thread taken from our MLops… | by Demetrios Brinkmann | MLOps.community | Medium
불행하게도 Kubeflow는 설정이 까다롭고, 신뢰할 수 없으며, 구성하기 어려운 것으로 나타났습니다. 또한 많은 오래된 구성 요소와 라이브러리에 의존했습니다.
많은 문서가 손상되었거나 오래되어 일부 해킹된 해결 방법에 의존하지 않고는 AWS 및 GitHub와 원활하게 통합할 수 없었습니다.
초기 설치 문제
Kubeflow를 채택하기 전에도 우리는 가파른 학습 곡선이 있을 것이라는 것을 이미 알고 있었습니다. 하지만 우리 팀은 Kubernetes 경험이 풍부했기 때문에 초기 설치를 상당히 빠르게 완료하고 실행할 수 있다고 생각했습니다.
처음 시도한 지 며칠이 지났지만 KFDef 및 Kustomize 매니페스트와 관련된 버그로 인해 여전히 어려움을 겪고 있었습니다. 제공된 매니페스트는 명확한 오류 메시지 없이 여러 번 실패했기 때문에 모든 설치 구성 요소를 수동으로 확인하고 어떤 구성 요소가 손상되었는지 파악해야 했습니다.
우리의 목표는 Kubeflow를 GitHub 인증과 통합하는 것이었지만 AWS 및 OpenID Connect(OIDC)에 제공된 매니페스트에도 Kubeflow 수신 지점과 관련된 버그가 포함되어 있었습니다. 이 문제를 해결하려면 필수 OIDC 정보를 사용하도록 수신을 수동으로 업데이트해야 했습니다.
전반적으로 Kubeflow는 Kubernetes 위에서 실행되고 클라우드에 구애받지 않지만 AWS에서 Kubeflow를 실행하는 데 많은 문제가 발생했습니다. 대신 GCP를 사용했다면 이 프로세스가 더 원활했을 것입니다. Kubeflow는 Google에서 구축했기 때문에 기본값이 GCP인 경우가 많으며 특히 인증 및 권한 관리와 관련하여 아직 다른 클라우드 제공업체와 원활하게 작동하지 않습니다.
구성 요소 통합 문제
Kubeflow는 느슨하게 결합된 다양한 구성요소로 구성됩니다. 이 느슨한 결합은 이론적으로 사용할 구성요소를 선택할 수 있게 해주기 때문에 좋습니다.
그러나 단점도 있습니다. 서로 다른 구성 요소는 동일한 종속성의 서로 다른 버전에 의존하므로 더 많은 문제가 발생합니다.
테스트를 실행하는 동안 한 구성 요소를 업그레이드하면 다른 구성 요소가 중단되는 경우가 많다는 사실을 발견했습니다. 예를 들어 KFServing 구성 요소를 업그레이드하려면 Kubernetes 서비스가 서로 데이터를 공유하는 데 사용하는 메시 서비스 플랫폼인 Istio를 업그레이드해야 합니다. 최신 Istio 버전이 AWS 인증과 호환되지 않았기 때문에 이 업그레이드로 대시보드에 대한 액세스가 중단되었습니다.
그 결과 호환되지 않는 버전 세트가 생겼고, 복구할 수 있는 유일한 방법은 Kubeflow를 처음부터 다시 설치하는 것이었습니다.
또한 노트북에서 직접 파이프라인을 생성해야 했지만 몇 가지 해킹된 해결 방법을 사용한 후에도 이는 불가능한 것으로 나타났습니다. Kubeflow에는 여전히 해결되지 않은 문제가 있었습니다. 한 AWS 엔지니어가 GitHub에서 말했듯 이 "이 단계에서는 노트북에서 Kubeflow Pipeline으로의 클러스터 내 통신이 지원되지 않습니다."
문서 관련 문제
Jupyter 노트북과 같은 중요한 Kubeflow 구성요소에 대한 페이지를 포함하여 많은 문서 페이지에 '오래됨' (Out of date) 이라는 라벨이 붙어 있습니다.
더 나쁜 것은 이전 버전의 Kubeflow용으로 작성된 일부 문서 페이지에는 '오래됨'이라는 라벨이 표시되지 않는다는 것입니다. 따라서 우리가 디버깅하는 동안 언제 문서를 신뢰할지 알기가 어려웠습니다. 문제가 오래된 문서인 경우와 우리가 뭔가 잘못한 경우를 파악하려고 노력하는 것이었습니다. 이로 인해 모든 것이 느려졌습니다.
문서에 있는 링크 중 상당수는 "페이지를 찾을 수 없음" 또는 "이 페이지가 아직 존재하지 않습니다." 오류를 반환하여 전체적으로 실망스러운 경험을 선사했습니다.
Kubeflow User Survey 2023
주요 시사점:
- 사용자의 84%가 두 개 이상의 Kubeflow 구성요소를 배포합니다.
- 상위 3개 Kubeflow 구성요소는 파이프라인(90%), 노트북(76%), Katib(47%)입니다.
- 사용자가 사용한 최고 기여 구성 요소는 KServe(62%)입니다.
- 문서(55%)가 Kubeflow에서 가장 큰 격차를 보였고, 튜토리얼(50%)이 뒤를 이어 공동 3위, 설치(39%), 업그레이드(39%)를 차지했습니다.
- 사용자의 ML 수명주기에서 모니터링 모델(45%)이 가장 큰 격차를 보이며, 모델 등록(44%)과 초기 설정(39%)이 그 뒤를 따릅니다.
- 사용자의 52%가 원시 매니페스트 설치를 사용하여 Kubeflow를 설치합니다.
- Kubeflow를 설치하는 데 사용된 상위 배포판은 AWS(28%)이고 Google Cloud(17%)가 그 뒤를 따릅니다.
- 사용자의 74%가 Kubeflow를 클라우드에 배포하고 45%는 온프레미스에 배포합니다.
- 사용자의 49%가 프로덕션 환경에서 Kubeflow를 실행하고 있습니다.
- 사용자의 17%가 Kubeflow에 다시 기여하고 있습니다.
- 사용자의 49%가 최신 Kubeflow 1.7 릴리스를 유지하고 있으며 43%는 Kubeflow 1.6 이후 버전을 실행하고 있습니다.
Kubeflow Alternatives
Data and pipeline versioning
- DVC - https://dvc.org/
- Pachyderm - https://www.pachyderm.com/
Experiment tracking and meta ML
Training run orchestration
Hyperparameter tuning
- Optuna - https://optuna.org/
- SigOpt - https://sigopt.com/
Model serving
자세한 내용은 MLops 항목 참조.
See also
- Deep learning
- Kubernetes
- MLops
- k3s
- Workflow management system (WfMS or WFMS)
- Kubeflow
- Airflow
- JupyterFlow
- Argo Workflows
- Seldon Core - 수천 개의 프로덕션 기계 학습 모델을 패키징, 배포, 모니터링 및 관리하는 MLOps 프레임워크