Review/도서 리뷰

[도서 리뷰] Introducing MLOps, MLOps 도입가이드 part1

어쩌다통계 2022. 10. 27. 22:55
728x90

이 글이 도움되셨다면 광고 클릭 부탁드립니다 : )

 

ML모델 관련 구글링을 하다 보면 DevOps와 비슷한 MLOps라는 용어를 손쉽게 접할 수 있습니다.

저는 처음에는 당장 필요하지 않아 보여 관심을 두지 않았는데, 회사에서 모델을 배포/서빙을 하거나 개인 프로젝트를 하더라도 API를 만들어 서비스가 가능한 모델을 만들려면 MLOps에 대한 배경지식이 필요하게 됩니다.

본 포스팅은 Introducing MLOps, MLOps 도입 가이드를 읽으며 MLOps를 구상하는데 도움이 되는 부분을 정리하였습니다.

 

https://product.kyobobook.co.kr/detail/S000001810502

 

MLOps 도입 가이드 | 데이터이쿠 - 교보문고

MLOps 도입 가이드 | MLOps의 개념부터 도입과 활용까지, 성공적인 머신러닝 운영화를 위한 실용 가이드!오늘날 데이터 사이언스와 AI는 IT 분야뿐 아니라 제조, 구매, 유통, 마케팅, 반도체, 자동차,

product.kyobobook.co.kr

2022.10.27 - [Data Science] - [도서 리뷰] Introducing MLOps, MLOps 도입가이드 part2

 

[도서 리뷰] Introducing MLOps, MLOps 도입가이드 part2

아래 part1에 이어 MLOps 도입 가이드 도서 정리하였습니다. 본 포스팅에서는 상용 배포, 모니터링과 피드백 루프 챕터에 대한 내용을 다룹니다. 2022.10.27 - [Review/도서 리뷰] - [도서 리뷰] Introducing ML

slowsteadystat.tistory.com


Ch1. MLOps 개념과 필요성

MLOps란?

  • 데이터 관리 및 머신러닝 시스템 개발과 서비스 운영을 통합해 안정적으로 서비스를 제공하면서도 신속하고 유연한 개발을 추구하는 방식과 문화
  • 핵심은 머신러닝 모델 생애주기 관리의 표준화 및 간소화
  • 상용 배포한 모델이 하나라도 지속적인 성능 모니터링과 조정이 운영에 필수

머신러닝 생애주기 관리가 어려운 이유

  1. 많은 의존성 : 데이터/ 비즈니스 요구사항이 지속적으로 변화 -> 그에 맞춰 지속적인 모델 관리 필요
  2. 동일한 언어를 사용하지 않는 이해관계자들
  3. 소프트웨어 개발을 모르는 데이터 과학자
전통적인 소프트웨어 개발 관점에서 보자면, 머신러닝 모델은 사람이 직접 작성하지 않고 기계가 작성하기 때문에 버그가 있을 가능성이 현저히 떨어진다. 대신 모델들을 다수의 오픈소스 소프트웨어를 기반으로 개발하기 때문에, 버전을 모델이 작동할 상용 환경 및 모델을 검증한 환경과 동일하게 맞추는 작업이 대단히 중요하다.
원칙
  • 버전을 추적하고, 특히 설계 단계에서는 실험을 함께 수행하라
  • 다시 학습한 모델이 이전 버전보다 나은지 여부를 확인하라. 그리고 더 나은 모델을 상용에 배포하라
  • 모델 성능이 상용 환경에서 저하되지 않도록 하라. 매일 혹은 정기적으로 확인하라

 

Ch2. MLOps 이해관계자들

  • 직무 전문가 : 머신러닝 모델이 다뤄야 하는 비즈니스 질의, 목표 혹은 KPI 제안
  • 데이터 과학자 : 직무 전문가가 제기한 비즈니스 요구사항을 해결하는 모델 구축
  • 데이터 엔지니어 : 머신러닝 모델에 공급하는 데이터의 취합 및 사용 최적화
  • 소프트웨어 엔지니어 : 머신러닝 모델을 회사의 애플리케이션 및 시스템에 통합
  • DevOps : 운영체제를 관리하고 개발하며, 보안/성능/가용성 관련 테스트 수행
  • 모델 리스크 관리자 : 상용 배포한 머신러닝 모델들에 의한 전체 리스크 최소화
  • 머신러닝 아키텍트 : 살계부터 개발 및 모니터링까지 포함하는 확장 가능하고 유연한 머신러닝 모델 파이프라인 환경 확보

 

Ch3. MLOps의 핵심 기능

핵심기능은 개발-배포-모니터링-반복-거너번스로 구성

개발

  • 비즈니스 목표 수립
  • 데이터 소스 및 EDA
  • 피처 엔지니어링 및 선택
  • 학습 및 평가

배포

  • 모델 배포 유형
    1. Model-as-a-service/ 실시간-스코어링 모델 : REST API Endpoint(API 요청을 받으면 작업을 수행하는 자원에 접속하는 수단)을 제공하는 간단한 프레임워크에 모델을 배포하고, 실시간으로 요청이 응답
    2. 임베디드 모델 : 모델을 애플리케이션 내에 패키징하여 publish
  • 상용 환경에서 의존성을 축소하기 위한 방법 중 하나는 이동이 용이한 portable 포맷을 사용하는 것
    • PMML, PFA, ONNX, POJO
    • 단, 각 포맷이 지원하는 알고리즘에 한계가 있고, 모델이 다소 다르게 작동하는 경우도 존재
  • 컨테이너화
    • 머신러닝 모델 배포 시 발생하는 의존도 해결 방법으로 점점 더 선호도가 높아지고 있음(a.k.a. 도커)
    • 애플리케이션이 독립적이고 독자적인 환경에 배포되도록 하고 각 모델의 정확한 요구사항을 만족시킴
    • 여러 컨테이너를 탄력적으로 이용하여 컴퓨팅 자원 확장
    • 여러 개의 컨테이너에 대한 오케스트레이션은 쿠버네티스와 같은 기술들을 활용하여 수행하는데, 클라우드와
    • 프레미스 양쪽 모두에서 활용 가능

모니터링

  • 모델을 상용 배포한 뒤에는 계속 잘 작동하는지 확인해야 함
  • DevOps – 모델이 충분히 빠르게 처리하는지, 적절한 용량의 메모리와 CPU 처리시간을 사용하는 있는지
  • 데이터과학자 – 변화하는 현실 데이터에 맞춰 재학습
  • 비즈니스 – 모델이 기업에 가치가 있는지, 모델로 얻을 수 있는 이점이 모델을 개발하고 배포할 때 필요한 비용을 넘어서는지

반복 및 생애주기

  • 모델의 개선된 버전을 개발하고 배포

거버넌스

  • 비즈니스에 대한 일련의 통제로서 주주, 직원, 국가 정부 등 모든 이해 관계자에 대한 의무 사항을 수행
    금융, 법률, 윤리적 의무

 

Ch4. 모델 개발

데이터 탐색

  • 데이터를 어떻게 수집했는지, 어떤 가정을 포함하는지를 문서화
  • 데이터의 분포를 상세히 확인함

피처 선택

  • 모델에 필요한 컴퓨팅 비용이 증가
  • 피처가 많을수록 유지보수가 더 많이 필요하고 안정성이 떨어질 수 있음

 

Ch5. 상용화 준비

  • 일반적으로 상용환경은 개발 환경과 크게 다를 뿐만 아니라, 모델이 상용 환경에서 작동할 때 발생할 수 있는 상업적 리스크도 매우 큼
  • 상용 배포하는 전환 과정의 복잡함을 이해하고 테스트해야 하고 잠재적 리스크를 적절히 경감해야 함
  • 상용 배포, 보안 대응, 리스크 경감 관련 요구사항을 모델 개발 단계에서부터 고려해야 함

견고한 MLOps 시스템 구축을 위한 고려 사항

  1. 실행환경
    • 상용/배포하는 환경은 다양한 형태로 존재(요구사항에 맞춰 구축된 서비스, 데이터 사이언스 플랫폼, 텐서플로 서빙, 쿠버네티스 클러스터, …)하고 모델 개발 환경이 동일하게 작동하지 않을 수 있음
    • 완전히 다를 경우, 모델을 처음부터 구현해야 할 수도 있음(수개월 소요), 현실적으로 많은 조직에서 이러한 방법으로 적용
    • 성능에 대한 고려 필요
      • 일반적으로 C++로 변환한 모델이 python 모델보다 빠름, 반대의 케이스도 존재하기 때문에 모델 변환 시 고려해야 함
      • 모델 최적화하여 적은 메모리 사용으로 지연 없이 결과 반환 필요
  2. 모델 리스크 평가
    • MLOps 시스템의 검증 이전에, 검증 목표 고려 필요, 복잡한 시스템에서는 중요해 보이지 않는 톱니바퀴도 엄
    • 난 영향을 끼칠 수 있음
    • 상용 환경에서 모델이 끼칠 리스크를 예측하여 최소화하는 방향으로 설계하고 검증해야 함
    • 배포 전 확인 사항
      • 상상할 수 있는 가장 나쁜 쪽으로 모델이 작동한다면 어떤 일이 일어날까?
      • 사용자가 내부 로직을 뽑아내면 어떻게 될까?
      • 재무, 사업, 법률, 보안 , 명성 등과 관련된 리스크는 어떤 게 있을까?
  3. 머신러닝에 대한 품질 검증
    • 사실 머신러닝에 대한 QA는 마지막 검증 단계에서만 진행되는 것이 아니라 모델 개발과 관련된 모든 단계에서 필요
    • QA의 목표는 프로세스 준수뿐만 아니라 머신러닝 및 성능 요구사항에 대한 준수도 포함
    • QA에서 세밀함의 정도는 위험 수준에 비례
  4. 테스트에 대한 핵심 고려사항
    • 현실의 데이터가 테스트 데이터와 다를 수 있기 때문에 여러 시나리오를 준비(일부러 문제가 될 것 같은 상황)
    • 지표 : 통계적 관점(정확도/정밀도/재현율)과 컴퓨팅 관점(평균 지연 시간, 백분위상 95번째 지연시간)
    • 안정성 테스트도 필요(불안정한 모델의 경우, 특징 하나를 살짝 변경해도 출력이 변화가 생길 수 있음), 보통 간단하고 정규화된 모델일수록 안정성이 높음
  5. 재현 가능성과 감사 가능성
    • 재현 가능성 : 완전히 동일한 실험을 쉽게 재실행 가능해야 함
      • 모델과 함께 상세 문서, 학습/테스트에 사용된 데이터, 모델의 구현체 및 실행 환경에 대한 상세한 사양 제공
    • 감사 가능성(auditability) : 신뢰할 만한 중앙 저장소에서 머신러닝 파이프라인의 이력 전체에 접근 가능해야 하고 모델의 모든 버전에 대한 메타 데이터를 쉽게 얻을 수 있어야 함
      • 완전한 문서화, 정확한 초기 환경에서 모델을 돌릴 수 있는 수준의 아티팩트(artifact), 모델 설명 및 공정성 보고 자료를 포함하는 테스트 결과
      • 상세한 모델 로그와 모니터링 관련 메타 데이터
  6. 머신러닝 보안
    • 모델을 서비스할 때, 저수준의 결함부터 사회 공학적 문제에 이르기까지 다양한 보안 이슈를 일으킬 수 있음
    • 공격자가 시스템에 대해 잘 이해할수록, 혼란을 일으킬 방법을 찾을 가능성이 높음
  7. 모델 리스크 경감
    • 모델의 배포 범위가 넓어질수록 리스크도 커짐
    • 점진적 방식 혹은 카나리(canary) 방식으로 출시해야 하며, 적은 범위의 고객에게 모델의 새 버전을 배포해야 함
    • 빠르게 변화하는 환경으로 인해 리스크를 통제하기 위해 MLOps 기반 모니터링이 충분히 기민하게 반응하고 절차 내에 대응에 필요한 기간을 고려하고 있어야 함

 

반응형