BentoML Data Drift Detection데이터 드리프트는 훈련에 사용된 데이터와 실제로 모델이 적용되는 시점의 데이터 간 분포 차이가 발생하는 현상을 말합니다.이러한 분포의 차이는 모델 성능을 저하시킬 수 있습니다. 이에 데이터 드리프트를 감지하고 대응하는 것은 중요합니다.아젠다데이터 드리프트를 감지하는 방법BentoML로 인퍼런스 데이터 로깅Fluent Bit으로 로그 수집Kafka에 수집된 로그 전달Evidently AI로 데이터 드리프트 감지1. 데이터 드리프트를 감지하는 방법데이터 드리프트를 감지하는 데에는 여러 가지 방법이 존재합니다. 주요 접근 방식은 위 사진에서 알 수 있듯이 훈련 데이터(기준 데이터)와 인퍼런스 시점의 실시간 데이터를 비교하여 데이터 분포의 차이를 감지하는 것입니..

블로그에서 필요한 코드들은 https://github.com/Ssuwani/bentoml_prometheus 에 정리해두었습니다.0. 들어가며BentoML은 모델을 쉽게 패키징하고 배포할 수 있는 오픈소스 라이브러리입니다. 또한, 배포된 모델에 대한 온라인 모니터링을 지원합니다.이 글에서 수행할 과정을 간단히 그림으로 나타내면 아래와 같습니다.PyTorch로 모델 학습하고 평가하기BentoML로 모델 패키징하여 Containerize 한 뒤 배포하기Prometheus로 모델 모니터링하기1. PyTorch로 Fashion MNIST 모델을 학습하고 평가하기이 글에서 데이터 & 모델은 중요한 부분은 아니라 PyTorch 공식 문서의 Quickstart 예제를 따라 데이터를 가져오고 모델을 학습한 뒤 평가해보..

참고한 블로그 - https://medium.com/dkatalis/kubeflow-with-mlflow-702cf2ebf3bf 앞선 포스팅에서 Kubeflow를 설치했다. 그리고 MLflow도 설치했다. 이번 포스팅의 목적은 Kubeflow 대시보드에 MLFlow가 하나의 탭으로 추가하는 것이다. Kubeflow의 Central Dashboard에서 하나의 탭을 클릭할 때 다양한 엔드포인트로 라우팅 하기 위해 VirtualService를 사용한다. (주피터, Katib, pipeline 등) 우리의 목적은 mlflow 버튼을 클릭하면 mlflow tracker UI로 라우팅 해야 하므로 추가로 virtual service를 생성해야 한다. 아래 yaml을 배포하자. kubectl apply -f mlf..

kubeflow는 ML 프로젝트를 위한 End-to-End 플랫폼이다. 그러니까 A to Z까지 다 할 수 있다는 의미이다. 그럼에도 ML 프로젝트에서 중요한 머신러닝 모델 라이프사이클 관리 측면에선 MLFlow를 통해 쉽고 잘할 수 있다. 내가 생각하는 MLOps를 위한 최소한의 컴포넌트들은 아래와 같다. Model Registry를 위해 MLflow 를 사용할 것이고 그 외 모든 컴포넌트를 위해 Kubeflow를 사용할 것이다. 이를 위해 다음과 같은 포스팅을 이어 나갈까한다. 1. 로컬환경의 K8s에 Kubeflow와 MLflow 설치 2. Data Engineering 3. ML Engineering 4. ML Serving

1. Why mlflow 이 그림을 엄청 많이 봤다. 이 그림을 통해 보통 하고자 하는 말은 ML 시스템을 운영하기 위해 ML Code 이외에도 다양한 컴포넌트가 많다는 것이다. 하지만, 머신러닝 애플리케이션에서 가장 핵심적인 컴포넌트는 모델이라고 생각한다. 이 핵심적인 "모델"이 어떻게 학습되었고 어떻게 저장되었으며 어떻게 배포되어 있는지 이를 제일 잘할 수 있도록 설계된 툴이 MLflow가 아닐까. 2. What we need mlflow의 설명을 보자, "An open source platform for the machine learning lifecycle". 모델의 모든 생애주기 관리하기 위한 플랫폼으로서 mlflow는 발전하고 있다. 그렇게 된다면 유지관리가 엄청 편해지겠지만 그렇기엔 아직 성..

Github Actions는 Github에서 제공하는 CI / CD를 위한 툴이다. CI : Continous Integration(지속적 통합) CD: Continous Delivery or Continous Deploy(지속적 배포) 사용자의 피드백을 빠르게 적용하기 위해서 많은 수의 배포가 빠르게 진행되어야 한다. 이는 곧 서비스의 경쟁력이 되기 때문이다. 한 번의 코드 변화로부터 사용자에게 전달되기까지 모든 과정이 수동으로 이루어진다면 많은 시간이 걸릴 것이다. CI / CD는 그 과정을 자동화하는 것이라고 생각한다. 쉽게 예를 들어 CI / CD를 구분해보자. CI : 소스코드의 변경에 따른 도커 이미지의 빌드 및 푸시 CD : 변경된 도커 이미지를 바탕으로 쿠버네티스의 리소스 업데이트 위 그림..

안녕하세요~~ 오늘 작성해볼 내용은 머신러닝 모델을 위한 CI / CD 파이프라인입니다. CI는 Continous Integration CD는 Continous Deploy 혹은 Continuous Delivery 이는 사람마다 해석이 조금씩 다른 거 같습니다. 뭐 굳이 나누나 싶긴 한데 저는 CI는 배포 전까지의 모든 단계를 이야기하고 CD는 배포하는 단계로 정의하고 글을 작성하겠습니다.. 그리고 CI / CD가 뭐야?라고 누군가 저에게 물어보면 저는 "자동화하는 거요..."라고 대답할 거 같습니다. 머신러닝 관점에서 CI / CD를 한다는 것은 모델러가 코드를 Github에 업로드했을 때 모든 과정이 자동화되어 사용자에게 전달되게 끔 하는 것이라고 생각합니다. 이는 비즈니스의 성격과 모델의 성격에 따..

GCP의 Free Tier는 90일간 300불을 사용할 수 있다. 300불은 GKE를 구성한다면 한 20일 정도면 크레딧을 모두 사용하게된다. 따라서 구글 게정을 새로 생성하고 GKE를 구성하는 것은 공부하는 입장에서 반복적인 일이 되곤한다.. 따라서 Terraform을 이용해 이 과정을 자동화하였다. 아래의 자료는 복잡하고 길지만 실제로 GKE 클러스터를 생성하고 클러스터에 ArgoCD를 설치하기 까지의 과정은 간단하다. Quick Start 1. 1단계 수행 - GCP 프로젝트 생성 2. 레포지토리 clone git clone https://github.com/Ssuwani/provision-gke-with-terraform 3. project_id 입력 in terraform-provision-gk..