가짜연구소 9기 “AI를 잘 활용하는 개발자로 성장하기” 프로젝트에 참여하여 Datacamp의 “Machine Learning Engineer” 강의를 수강하고 해당 내용을 정리한 게시글입니다. Datacamp Machine Learning 코스 페이지

1. MLOps 소개

MLOps란

• 모델 설계부터 배포 및 운영까지 머신러닝의 전체 생명주기를 책임지는 일련의 과정
• 어플리케이션의 전체 생명주기를 관리하는 DevOps가 머신러닝으로 확장된 개념

MLOps가 필요한 이유

• 모델의 성능을 높이기 위해서는 고품질의 데이터를 수집 및 정제하는 것이 중요한데, 여기에 많은 시간이 필요
• In production 상황에서, 모델의 성능 하락을 방지하기 위해서는 끊임없이 최신 데이터 수집 및 재학습이 필요함
• 이러한 일련의 과정이 효율적으로 수행되어야 하는데, 이를 위해서는 모델 운영과의 긴밀한 협업이 필요

MLOps는 이를 위해 머신러닝 연구자와 운영팀 사이의 협업을 강화하고, 데이터 수집 및 모델 배포를 자동화하여 머신러닝의 전체 생명주기에 걸쳐 업무를 지원한다.

MLOps의 세가지 단계

각 단계는 기본적으로 순차적이지만, 필요에 의해 얼마든지 되돌아가거나 반복될 수 있다.

Design phase (설계 단계)

• 문제 정의
• 문제를 해결하는 머신 러닝 모델의 가치 평가 (Added Value)
• 요구사항 파악
• 핵심 평가 지표 마련
• 고품질 데이터 획득

  Development phase (개발 단계)

• 모델 연구 및 개발
• 학습 데이터 가공
• 데이터, 알고리즘, 하이퍼파라미터 등을 갖고 실험 진행
• 배포 가능한 모델 준비

  Deployment phase (배포 단계)

• 비즈니스에 머신 러닝 모델 적용
• 모델 배포 (production)
• 모델 성능의 지속 모니터링

Roles in MLOps

MLOps에 각 단계에 따라 여러 role의 사람이 참여한다. 크게 비즈니스 역할과 기술 역할로 구분할 수 있다.

Business roles

• Business stakeholder : 이해관계자 (비즈니스를 하는 주체, 모델로 실제 이익을 얻는 사람)
  • 설계 : 예산 설정, 비젼 설정, 비즈니스 요구사항 정의
  • 개발 : 개발 단계의 모델 성능 평가, 결과물 검증
  • 배포 : 결과물 검증
• Subject matter expert : 도메인 지식이 풍부한 실무진
  • 라이프사이클 전체에 걸쳐 도메인 지식 제공 (데이터 해석, 평가 결과 해석)

    Technical roles

• Data scientist
  • 데이터 분석
  • 모델 학습 및 평가
  • 배포 후 예측 결과 포함
• Data Engineer
  • 학습 데이터 수집
  • 데이터 처리
  • 배포 후 데이터 파이프라인 마련
• ML Engineer
  • 머신 러닝 생명주기 완성의 전반을 담당 (다재다능한 역할)
  • 다른 기술 역할의 업무를 함께 수행하거나 직접 담당

    그 외 다양한 roles

• 데이터 분석가
• 소프트웨어 개발자
• 그 외 다양한 유관부서 관계자 등

2. Design and Development

MLOps design phase

Added value (모델 가치 평가)

• 머신 러닝 모델의 가치를 평가하는 단계
• 자주 비용과 시간으로 지표가 평가됨
• 예시) 고객이 우리 서비스를 떠날 것인지 예측
  • 현재 1만명의 고객이 월 10달러로 서비스 구독 중
  • 가정 : 곧 떠날 것으로 예측 되는 고객에게 50% 할인을 제공하면 절반이 구독 유지
  • 모델이 80%의 정확도로 1,000명이 떠날 것으로 예측했다면, 대략 계산해서 예측 결과로 약 3,200달러의 이득을 볼 수 있음

모델의 가설을 정확히 세우는 것이 중요하고, 이를 바탕으로 모델의 목표 성능을 대략적으로 파악할 수 있다.

비즈니스 요구사항 파악

• 머신 러닝 모델의 최종 사용자를 가장 중요하게 고려해야 함
  • 예측 속도
  • 예측 정확성
  • 모델의 결과가 얼마나 사용자가 이해하기 쉬운 형태로 제공되는지
  • 모델의 예측 알고리즘의 투명성 (왜 이런 예측이 나온 것인지)
• 법령 준수 및 제약 조건
• 모델 개발 및 배포에 필요한 비용
• 프로젝트 팀 규모

  Key metrics

• MLOps과정은 여러 분야에 걸쳐 있기 때문에 이에 따라 평가 지표도 여러 종류로 나뉨
  • Data scientist 관점 : 모델 정확도
  • Subject matter expert 관점 : 고객만족도
  • Business stakeholder 관점 : 모델로 인한 이익

    데이터 품질 확인 및 수집

• 데이터 수집에는 데이터 품질에 대한 조사와, 요구되는 데이터를 어떻게 추출할 것인지 판단하는 과정이 포함됨
• 데이터는 모델의 성능에 직접적 영향을 미치기 때문에 매우 중요

  데이터 품질의 종류

  데이터 품질은 4개의 측면으로 정의 될 수 있다.

• accuracy - 데이터의 정확성
  • 실제 고객의 나이는 32세인데, 데이터 상으로 18세로 되어있다
• completeness - 데이터의 누락이 적은지
  • 고객의 80%는 last name이 데이터에 없다
• consistency - 데이터의 일관성
  • 데이터 동기화가 제대로 되어있지 않아, 같은 데이터가 사업부 별로 조금씩 다르다
• timeliness - 데이터가 최신인지, 실시간 수집이 가능한지 등
  • 데이터가 자정에 집계되기 때문에 실시간으로 볼 수 없다.

이 4가지 중 품질이 떨어지는 부분이 있어도, 프로젝트가 반드시 실패하는 것은 아니다. 하지만 프로젝트 성공확률을 높이기 위해, 가능한 만큼 데이터 처리 및 보강을 통해 품질을 높여야 한다.

Data ingestion

• Raw data로 부터 DB에 저장할 데이터를 추출하는 방법을 설계하는 단계
• 일반적으로 ETL 단계에 따라 데이터가 처리되어 저장
  • Extract : Source로부터 Raw Data를 가져옴
  • Transform : DB에 저장하기 위한 적절한 형태로 변환
  • Load : DB에 저장
  • ETL 단계에는 데이터가 유효한지 검증하는 과정 역시 포함

    Development Phase

    Feature engineering

• raw data를 feature로 만들기 위해 데이터를 선택, 조작, 변환하는 것
• 여기서 feature는 말그대로 데이터의 ‘특징’으로 머신 러닝이 패턴을 찾는데 도움이 되는 형태의 정보를 말한다. 일반적으로 데이터 테이블의 column으로 표현된다.
• raw 데이터를 그대로 쓰는 것 뿐만 아니라, raw 데이터로부터 새로운 feature를 만들어 낼 수 있다.
  • ex) 주문 수, 총 가격 (raw data) -> 주문 당 평균 가격 (feature)

    Feature engineering weigh-off

    무조건 Feature engineeing를 하는 것이 좋은 것은 아니다. 계속 엔지니어링을 할 것인지, 적절한 선에서 멈출 것인지 결정하는 것도 중요한 요소이다.

• feature가 늘어날 수록
  • 정확한 모델을 제작 가능
  • 안정성이 뛰어남
  • 데이터 처리 비용이 증가
  • 유지보수 비용이 증가
  • 노이즈 또는 over-engineering의 위험 증가

핵심은 적절한 feature만을 정확히 선별 하는것이다. 이를 위해 MLOps에서는 feature store라는 개념을 도입하여 사용한다.

Feature Store

• 머신러닝에 사용될 수 있는 feature들을 모아 둔 저장소
• 전처리 된 stream data, batch data가 저장되며, 각 프로젝트에서 원하는 데이터만 가져가 사용할 수 있음
• 데이터 사이언티스트는 적절한 feature를 선택하여 자유롭게 실험에 사용 가능
• Feature store는 모니터링 및 모델 버전 관리도 제공

  언제 feature store를 써야 하는가?

  Feature store를 구축하는 과정 역시 비용이므로, 무작정 구축하는 것이 좋은건 아니다.

• 실험 별로 feature를 변환하는 비용이 비싸질수록 고려 필요
• 동일한 feature 집합을 사용하는 ML 프로젝트가 많아 질수록 고려 필요

  Experiment tracking

  모델의 성능을 높이기 위해서는 많은 실험이 진행되어야 하는데, 이전에 했던 실험을 불필요하게 반복하지 않기 위해서는 이를 적절히 추적하고 저장하는 것이 중요하다.

  experiment tracking이 중요한 이유

• 결과의 직접 비교 가능
• 앞선 실험의 결과를 재현하기 쉬움
• 결과를 stakeholders와 공유하거나, 빠르게 특정 버전을 서빙하여 테스트하는 등 협업 용이성이 증가

  How to track experiments

• 스프레드시트 : 가장 빠르고 간단하지만, 많은 수동 동작 필요 (실수 가능성도 있음)
• platform 개발 : 가장 원하는 형태의 tracking이 가능하지만, 개발 비용이 많이 듬
• tracking tool : 비교적 쉽고 정확한 tracking이 가능하지만, 소프트웨어 사용 비용이 발생

이것 역시 프로젝트의 규모를 고려하여 규모에 맞게 확장하는 것이 좋다.

각 실험의 절차

1. 가설 수립
   • 변경할 조건과 이에 대한 기대 결과를 사전 정의
2. 데이터 확보 및 실험 진행
3. experiment tracking 설정
4. 모델 학습 진행
   • 학습에 대한 진행 과정 및 결과 tracking platform에 저장됨
5. 모델 테스트 진행
6. 가장 적합한 모델을 결정
7. 관련자에게 결과를 보고하고 다음 단계 진행

   3. Deploying Machine Learning into Production

   모델을 한번 배포한다고 끝이 아니고, 재학습 및 재배포가 빈번히 이루어지기 때문에 이를 자동화하여 개발 경험을 최적화하고, 불필요한 비용을 줄이는 것이 목표이다.

Deployment Cycle의 4가지 요소

• Runtime Environmetns
• Microservices architecture
• CI/CD Pipeline
• Mongitoring & retarining

  배포 준비 (환경 설정)

  일반적으로 개발 완료된 ML model을 모델을 돌릴 수 있는 배포 환경에 띄워서, API 등의 형식으로 모델을 제공한다. 하지만 개발 환경과 배포 환경은 서로 다르기 때문에 이를 맞추는 것에 어려움이 있을 수 있다. 이를 완화하기 위해 Container를 주로 사용한다.

  Container

• 하나의 Container engine에서 컨테이너간 격리를 통해 환경 구분 가능
  • 유지보수가 쉬움
  • 컨테이너 단위의 배포를 통해, 다른 물리적 머신에서도 쉽게 배포 가능
  • 배포가 빠름

    배포 아키텍처 설계

    Microservice architecture

• 모놀리식 아키텍처와 대비되는 개념의 아키텍처
• 모놀리식 아키텍처
  • 모든 서비스를 하나의 어플리케이션에서 제공
  • 하나의 서비스가 망가지면 모든 서비스에 동시에 장애가 발생할 수 있다는 위험 존재
  • 개발이 쉽지만, 한번 개발이 완료된 후에는 구조 변경이 어려움
• Microservice architecture
  • 각 서비스를 별도의 어플리케이션에서 제공
  • 하나의 서비스가 망가져도 다른 서비스에 영향을 미치지 않음
  • 첫 개발 시 많은 비용이 필요하지만, 확장 및 변경이 쉬움

ML 모델을 배포하는 것은 일반적으로 Microservice 방식을 사용한다. 동시의 여러개의 모델을 서빙하고, 다른 모델의 중단 없이 필요한 모델만 재배포를 해야하기 때문이다.

Inferencing

• Inferencing : 머신러닝 모델에 input을 전송해 사용자가 결과를 받는 과정
• 사용자와 데이터를 주고 받기 위해 일반적으로 API를 사용함

  Integration

• 모델을 비즈니스 프로세스에 적용하는 과정
• API를 비즈니스 시스템에 연결하는 과정을 포함

  CI/CD

• Continuous Integration/Continuous Deployment
• DevOps에서 코드 배포를 자동화하기 이해 제시한 개념
  • 개발 -> 빌드 -> 테스트 -> 배포로 구성
• MLOps에서는 모델을 Production 환경으로 배포하는 과정을 자동화하는 것을 말함

  CI: Continuous Integration

• 코드의 어느 부분이 변경되었는지 파악하여, 변경된 코드에 대한 테스트를 진행하고 커밋 및 병합 진행

  CD: Continuous Deployment

• CI단계를 통해 검증된 코드를 Production 환경에 자동으로 배포
• 코드가 항상 pruduction ready 상태가 되게 하는 것을 목표로 함

  배포 전략

• 기존 모델을 새 모델로 교체하는 방법에 따라 여러 전략으로 나뉨
  • Basic deployment : 단순 교체 방식, old model에서 보내던 데이터를 new로 바꿈
  • Shadow deployment : 데이터를 old, new 양쪽에 모두 전송, new 모델의 대한 결과가 예상대로 인지 테스트 후에 new model로 완전히 변경함
  • Canary deployment : 기존 모델에 보내던 데이터의 일부(일반적으로 더 적은 양)를 새 모델로 보냄, 소수의 사용자만 새로운 모델을 사용하게 됨
• 장단점 비교
  • Basic : 가장 쉽지만, 새 모델이 예상대로 동작하지 않을 때 위험이 높음
  • Shadow : 구현이 쉽고 리스크가 없음, 단 두 모델을 동시에 띄워야 하므로 자원이 2배로 필요
  • Canary : 구현이 다소 어렵지만, 리소스가 비교적 적게 필요, 리스크를 완전히 제거하지는 못함

    Automation and scaling

    ML의 생명주기 사이클에서 언제든지 필요에 의해 같은 단계를 반복하거나, 이전 단계로 돌아갈 수 있으므로, 자동화하는 것이 생명주기를 빠르게 돌리는데 큰 도움이 된다. 또한, 예상치 못한 사용량에 대비하여 확장 가능한 시스템을 만드는 것도 중요하다.

즉 자동화와 스케일링은 MLOps에서 매우 중요한 요소이다.

설계 단계의 자동화

• 프로젝트 설계 단계에서는 매 단계마다 참여하는 인원이 다양하기 때문에 자동화가 어려움
  • 그러나, 머신 러닝 가치 평가(added value), 요구사항 설정, 키 매트릭 설정 등을 템플릿화하면 빠르게 이를 수행할 수 있음
• 데이터 획득 단계는 자동화를 시도할 수 있음

  개발 단계의 자동화

• Feature store : 스케일링 가능하게 만드는 것이 큰 도움이 됨
• Experiment tracking : 추적의 자동화와 더불어, 이전 버전의 모델을 언제든지 불러올 수 있게 하는 것이 중요

  배포 단계의 자동화

• Containerization : 컨테이너화는 그 자체로 자동화와 스케일링에 도움이 됨
• CI/CD pipeline : 자동화에 필수
• Microservices arcitecture : 모델 단위로 스케일링을 용이하게 함

  Chatper 4. Maintaining Machine Learning in Production

  Moniotring machine learining models

• 배포 단계의 마지막 단계이자 가장 긴 단계
• 모델이 새로운 데이터에 대해 기대한대로 동작하는지 확인하기 위해 지속적인 모니터링 필요

  모니터링의 종류

• 통계적 모니터링 : 예측에 대한 정확도 확인 등
  • 모델의 성능 모니터링
• 기술적 모니터링 : 자원의 사용 정도, 요청 횟수 및 예측 횟수, 가용도 등
  • 모델의 효율성 모니터링

    Feedback loop

• 통계적 모니터링을 위해서는 모델의 예측과 실제 결과를 매칭하는 Feedback loop가 필요
  • 결과가 있으므로 모델이 왜 틀렸는지 알기 위해, 모델의 투명성이 중요함

    모델 재학습

• 시간이 흐르면서 세상은 변하므로, 이러한 변화는 모델에도 영향을 끼침
• 변한 데이터에 적응하기 위해 모델은 재학습이 필요
• 시간에 따라 현실의 데이터 분포가 변하는 현상을 drift라고 한다.

  Data drift

• 시간이 지남에 따라 input 데이터 분포가 변화하는 현상
  • ex) 물가 상승으로 수요 예측 모델 input의 가격 평균이 증가함
• 모델의 성능에 영향을 끼칠 정도로 입력 데이터가 크게 변한다면 조치가 필요

  Concept drift

• 시간이 지남에 따라 target의 통계적 특성이 변화하는 현상
  • ex) 고객 이탈 예측에서 과거엔 구독료가 비싼것이 이탈과 가장 큰 상관이 있었는데, 경쟁 서비스로의 이동이 가장 큰 상관관계를 갖는 것으로 변화
• 이전 학습한 패턴이 소용없어지기 때문에 모델의 성능을 악화시킬 우려가 높음

  Retrain 주기

  drift로 인한 모델 성능 저하 문제를 완화하기 위해 주기적인 재학습이 필요

• 다음과 같은 것들을 고려하여 학습 주기 설정
  • 비즈니스 환경의 변화 정도
  • 재학습 비용
  • 비즈니스 요구사항 (높은 성능이 요구될 수록 변화하는 데이터에 맞추어 빈번한 재학습이 필요)

    Retraining 방법

• 이전 데이터와 새로운 데이터를 모두 사용해 학습하는 방법을 일반적으로 사용
• 특정 조건을 설정해 조건 달성 시 재학습을 하도록 자동화하기도 함
  • ex) 고객의 평균나이가 1이상 변했을 경우 재학습 진행

    MLOps의 성숙도(maturity) 레벨

• maturity : 성숙도
• MLOps 성숙도란 자동화, 협업, 모니터링의 정도의 수준을 나타낸다고 할 수 있음
• 반드시 MLOps의 수준이 높다고 모델이 좋아지는 것은 아니지만, 모델을 개선할 여지를 많이 만들 수 있음
• 개발 및 배포 단계에만 적용 (설계 단계에 적용은 어려움)
• 3개 수준으로 구분할 수 있음
  • Automation : 수동 -> CI -> Full automation
  • Collaboration : 개인이 학습 및 동작 -> 개발자 간 인수인계 가능 -> 밀접한 협업
  • Monitoring : 모니터링 없음 -> 개발 단계에서 추적(실험 결과 및 feature store) -> Full 모니터링

    Level 1 : Manual

• 개발 및 학습이 모두 수동으로 이루어짐
• ML과 운영팀 사이에 협업이 없음
• 팀 단위 협업이 이루어지지 않음
• tracking 시스템이 없음
• 배포후 모니터링이 없음 이 경우 각 단계에서 문제가 발생했을 경우 수정 및 개선에 많은 노력이필요

  Level 2

• 파이프라인의 자동 배포 적용 (CI)
• 여전히 배포 단계는 수동
• 운영 팀이 모델 배포 후 협업을 시작함
• ML 실험과 feature에 대한 추적이 이루어짐
• 개발 후 약간의 모니터링 수행

  Level 3

• Full CI/CD 파이프라인 적용
• 서로 다른 책임을 가진 팀 간 협업이 긴밀하게 진행
• 개발, 배포 단계에서 모두 모니터링 진행
• 잠재적으로 재학습을 자동으로 시작할 트리거를 마련

MLOps tools

각 단계에서 MLOps를 지원하는 다양한 tool을 알아보자

Feature store

• FEAST : 오픈소스
  • 보다 많은 수동 설정을 필요로 하지만 유연성이 뛰어남
• HOPSWORKS : 오픈소스
  • Hopsworks가 제공하는 더 큰 플랫폼의 일부
  • 어느정도 ready to use 형태로 제공됨

    Experimnet tracking

• MLFlow, ClearML : 머신 러닝 전체 생명주기에 대한 툴
• Weights and Biases : 실험 추적과 시각화에 특화

  Containerization

• Docker : 어플리케이션의 컨테이너화 담당
• Kubernetes : 컨테이너 오케스트레이션
• Cloud providers : Kubernetes와 유사한 컨테이너 관리 툴을 각자 클라우드 환경에서 제공

  CI/CD pipeline

• Jenkins : 오픈 소스 CI/CD 툴
• GitLab : 저장소 단위로 코드 공유 및 버전 관리 제공 (오픈 소스 아님)

  Monitoring

  둘 다 통계적 모니터링 제공

• fiddler : 모델의 성능에 중점 (예측 정확도)
• great_expectations : 입력된 데이터에 중점 (특정 컬럼이 누락되었는지 여부 등)

  MLOps platforms

  전체 생명주기를 담당하는 큰 플랫폼도 있음 보통 cloud provider가 제공

• AWS Sagemaker
• Azure Machine Learning
• Google Cloud AI Platform

학습 소감

알게 된 것

데이터 엔지니어와 데이터 사이언티스트의 역할 차이를 명확히 알게 되었습니다. 모델을 직접 배포하거나 운영해본 경험이 없어서 잘 몰랐는데, MLOps의 개념과 운영의 중요성을 알게 되었습니다.

느낀점

실험 추적 부분에서, 최근에 결과를 일일히 수동으로 기록하다보니 재현이 필요할 때 낭패를 겪는 경우가 많아 많이 공감이 되었습니다. 앞으로는 무작정 실험부터 시작하지 않고 배운 것들을 고려하면서 철저히 설계를 해두고 해야할 것 같습니다.

더 학습하고 싶은 것

모델 배포 후 입력되는 데이터를 실시간으로 처리하는 일련의 데이터 파이프라인을 직접 개발해보고 싶습니다.