전통적인 머신러닝(ML) 개발은 각 산업에서 생성형 AI만큼이나 주목받는 분야이다.
산업 현장에서 AI 활용의 접근성을 늘리려면 범용적인 생성형 AI에만 의존하지 않고 가볍고 빠르게 동작하는 ML 모델도 충분히 고려해야 한다고 생각한다. (물론 데이터 정의와 수집도 중요하다.)
Aiden’s Lab에서 전통적인 ML 모델 개발과 MLOps를 꾸준히 다루는 것도 이러한 이유 때문이다. AI 활용의 다양한 접근법은 여러분들에게 분명 도움이 될 것이라 생각한다.
ML 모델 개발의 라이프사이클을 관리하는 MLOps는 데이터 과학자나 ML 엔지니어만의 분야가 아니다. 각 산업 현장에서 ML 모델 개발 수요는 꾸준히 증가하고 있으므로 DevOps와 AI에 관심이 있다면 MLOps에 대해 관심을 가져두는 것을 추천한다.
그래서 이번 아티클에서는 MLOps 종합 플랫폼이라는 평가를 받는 Kubeflow에 대해 알아보려 한다. Kubeflow를 왜 사용하는지, 주요 구성요소는 무엇이고 어떤 가치를 주는지 살펴보겠다.
이름에서 알 수 있듯이 Kubeflow는 Kubernetes 클러스터 위에서 구축하는 플랫폼이다.
1. Kubeflow를 사용하는 이유
ML 모델을 학습하고 관리하는 것만으로도 벅찬데 Kubernetes라니? 라고 생각할 수도 있다. 틀린 말은 아니다. Kubernetes가 사실상 표준에 가까운 컨테이너 오케스트레이션 시스템이라고 해도 운영 부담 요인이 될 수 있는 것은 사실이다.
그럼에도 불구하고 MLOps를 Kubernetes 위에서 수행할 때 얻을 수 있는 이점에 대해 먼저 살펴보자. 상황에 따라 그 이점들이 Kubernetes 클러스터 운영 부담을 넘어설 수도 있는 법이니까.
Kubernetes 클러스터 위에서 서비스를 운영할 때의 장점으로 가장 많이 꼽는 것으로 3가지가 있다.
- 일관성 (개발 환경과 배포 환경 일치)
- 가용성 (자가 치유 및 무중단 배포)
- 확장성 (오토스케일링)
이들은 MLOps에도 그대로 적용된다. 정리하면 아래와 같다.
- 일관성: ML 개발자의 개발 환경을 컨테이너로 통일시켜 모델 학습 환경과 운영 환경 간의 오차 제거
- 가용성: 장시간 모델 학습의 안정성과 배포된 추론 서버의 연속성 보장 가능
- 확장성: HPA(Horizontal Pod Autoscaler) 기능을 통해 실시간 트래픽이나 자원 사용량에 따라 추론 서비스의 Pod 개수 자동 조정 가능
모델 개발부터 학습, 추론 서버 배포까지 모두 Kubernetes 클러스터 위에서 안정적으로 수행할 수 있는 것이다.
그렇다면 왜 Kubeflow를 사용하는가? 크게 2가지 관점에서 살펴보겠다.
먼저 플랫폼 관점이다. 모델 실험과 파이프라인, 서빙, 모니터링 등 MLOps가 다뤄야 할 작업은 다양하다. 이런 작업들을 수행하기 위해 개별 툴들을 사용한다면 각 툴을 설치하고 연동해서 운영해야 하므로 운영 비용이 증가하고, 일관되지 않은 환경으로 팀의 생산성은 저하될 수 있다.
반면 Kubeflow는 MLOps의 전과정을 아우르는 종합 플랫폼이다. ML 모델 개발부터 모델 서빙까지 모든 작업을 Kubernetes 네이티브하게 수행할 수 있으며, 하나의 플랫폼 안에서 일관된 사용자 경험을 제공한다. 또한 Kubeflow는 여러 프로젝트가 모듈처럼 구성되어 있어 운영 환경에 따라 필요한 프로젝트만 채택해서 운영할 수 도 있다. 유연한 MLOps 운영이 가능한 것이다.
두 번째로 주도권 관점이다. ML 모델 개발에 필요한 환경과 툴은 AWS나 GCP에서도 이미 제공하고 있다. 접근성도 좋다. 하지만 벤더 종속(Lock-in)이라는 위험이 존재한다.
반면 Kubeflow는 Kubernetes 클러스터 위라면 어디든 똑같이 구동될 수 있는 오픈소스 플랫폼이다. 온프레미스든 클라우드 환경이든 상관없이 안정적인 운영이 가능한 것이다. 인프라의 주도권을 조직이 직접 가져갈 수 있다는 뜻이므로 장기적인 운영을 고려했을 때 매력적인 장점이 아닐 수 없다.
지금까지 Kubeflow를 왜 써야 하는지 알아봤으니 이제 Kubeflow를 구성하는 핵심 프로젝트 3가지를 살펴보자.
2. Kubeflow의 핵심 프로젝트
이제부터 소개할 3가지 프로젝트는 MLOps 관점에서 중요한 3가지 작업(모델 개발, 작업 파이프라인 구축, 모델 서빙)을 다루지만 반드시 설치해야 하는 것은 아니다. 위에서도 언급했듯이 조직의 상황에 따라 필요한 프로젝트를 채택할 수 있는 것이 Kubeflow의 장점임을 잊지 말자.
Kubeflow Notebooks
Kubeflow Notebooks는 ML 모델 개발이나 데이터 관련 작업을 수행할 통합 개발 환경(IDE)을 제공하는 프로젝트이다.
ML 개발하면 떠오르는 대표적인 IDE인 Jupyter Lab부터 R Studio, Visual Studio Code 중 하나를 컨테이너 형태로 Kubernetes 클러스터에 띄워 개발자가 접근할 수 있도록 한다.
개발자는 Kubeflow 웹 대시보드에서 원하는 타입의 IDE를 선택해 Notebook을 생성할 수 있는데, 개발 환경에 필요한 CPU와 RAM도 지정해서 할당받을 수 있다. 클릭 몇 번으로 자신이 원하는 IDE 서버를 새로 만들고 웹으로 접근할 수 있어 생산성에 유리하다.
(출처: Kubeflow Notebooks 공식 문서)
관리자는 Notebook 컨테이너에 사용될 베이스 이미지들을 직접 설정할 수 있다. 개발자들이 사용할 IDE의 환경을 미리 고정할 수 있으므로 모두가 동일한 환경에서 개발할 수 있게 되는 것이다.
Kubeflow Pipelines
Kubeflow Pipelines는 ML 개발 전체 워크플로우를 파이프라인으로 엮어주는 프로젝트이다.
데이터 전처리와 모델 학습, 모델 평가, 모델 배포 등 ML 개발 워크플로우의 각 단계를 Kubeflow Pipelines에서는 컴포넌트라고 한다.
보통 작업에 필요한 Input과 수행할 작업, 작업 결과 Output이 컴포넌트에 포함되며 Python 코드로 정의할 수 있다.
이러한 컴포넌트들을 파이프라인 형태로 엮어 실행하는 것이 Kubeflow Pipelines의 주된 역할이다. 이 파이프라인 역시 Python 코드로 정의 가능하다. Jenkins의 Scripted Pipeline을 생각하면 이해가 쉬울 것이다.
(출처: Kubeflow Pipelines 공식 문서)
Kubeflow의 파이프라인은 Experiment라고 하는 단위 하에서 관리되며, 각 파이프라인의 실행 단위는 Run이라고 칭한다. 파이프라인의 실행 단위가 존재하는 이유는 무엇일까?
ML 모델을 학습시킬 때 가장 보편적인 방법이 학습 파라미터를 조정하며 반복 수행하는 것이다. 모델 학습 후 평가에서 높은 스코어를 얻기 위해서이다.
Kubeflow의 파이프라인에 포함되는 컴포넌트도 이런 하이퍼파라미터 조정과 반복 실행이 필요하다. 즉, 파이프라인을 실행할 때마다 달라지는 컴포넌트의 Input과 작업 로그, Output을 추적할 수 있어야 하기 때문에 Kubeflow 파이프라인은 Run이라는 실행 단위가 매번 기록되는 것이다.
Kubeflow Pipelines에서는 미리 정의한 각 컴포넌트를 파이프라인에 재사용할 수 있어 개발 생산성을 높여준다는 장점이 있다.
Experiment와 Run이라는 용어는 또다른 MLOps 플랫폼인 MLflow에서도 유사하게 사용된다. MLflow를 로컬 환경에서 직접 배포하고 사용해본 후기가 궁금하다면 링크된 각 아티클을 참고해보자.
KServe
Notebooks로 개발자들이 ML 모델을 개발하고, Pipelines로 데이터 전처리와 모델 학습 및 평가 후 배포까지 마쳤다면 이제 최종 생성된 모델을 서빙해야 한다. 그리고 이 역할을 수행하는 툴이 KServe다.
KServe는 TensorFlow나 PyTorch, Scikit-learn 등 다양한 프레임워크로 만들어진 모델을 API 서버 형태로 배포할 수 있으며, Kubernetes의 일반적인 Deployment 리소스가 아닌 KServe 전용 CRD InferenceService 리소스로 배포된다.
InferenceService 리소스는 오토스케일링 기능과 트래픽 현황에 따라 사용하지 않는 리소스를 반납하는 Scale-to-Zero 기능을 지원한다. 안정적인 추론 서버 운영과 리소스 절약이 가능한 것이다.
KServe는 Aiden’s Lab에서 이미 몇 차례 다룬 적이 있다. 로컬 환경에서 KServe를 배포하고 사용해본 후기가 궁금하다면 링크된 각 아티클을 참고해보자.
마무리
Kubeflow 설치와 운영 난이도는 여전히 진입장벽으로 작용한다. 본 아티클에서는 Kubeflow 자체에 대해서만 다뤘지만, 실제 Kubernetes 클러스터에서 Kubeflow를 제대로 배포하고 사용하려면 Kustomize부터 인증 및 권한 설정 등 Kubernetes에 대한 이해가 어느 정도 필요하다.
그래서 무작정 Kubeflow를 도입하기보다는 어떤 조직에게 적합한지 먼저 아는 것이 중요하다. 만약 조직이 아래와 같은 상황이라면 Kubeflow 도입을 고려해 볼 만하겠다.
- 관리해야 할 ML 모델이 10개 이상이고 주기적인 재학습이 필수인 경우
- 데이터 과학자와 ML 엔지니어 역할이 나눠져있어 표준화된 파이프라인이 필요한 경우
- 이미 조직 내에서 Kubernetes를 인프라로 사용 중인 경우
- 보안상 퍼블릭 클라우드의 MLOps 서비스를 사용할 수 없어 자체 서버에 플랫폼을 구축해야 하는 경우
Kubeflow는 종합 MLOps 플랫폼인 만큼 그 범위가 방대해서 정말 필수적인 요소만 엄선해 다뤄봤다. 이번 아티클을 통해 MLOps와 Kubeflow라는 키워드에 더욱 익숙해졌길 바란다.
만약 본 아티클에 대한 반응이 좋다면 Kubernetes 환경에 직접 Kubeflow를 배포해서 사용해보는 실습 가이드도 구성해보도록 하겠다.