실리콘밸리의 MLOps

• 본 내용은 SuperbAI에서 번역 배포한 "실리콘밸리의 MLOps" 을 요약 정리하였습니다.
• 출처) https://www.superb-ai.com/ko-ebooks/mlops-guide

1. MLOps는 왜 중요한가?

• 머신러닝: 데이터 사이언티스크가 별도로 진행하는 개별 과학 실험의 관점에서 주로 진행
• 실제 문제 해결을 위해서는 접근성이 용이하고, 재현가능해야하며, 협력할 수 있어야 함
• 데이터과학자, 머신러닝 엔지니어 대상 설문
  20%: 실험 및 학습 단계 집중
  40% 이상: 상품화 목적의 모델 배포 집중
  (응답자 대다수 모델 재학습 자동화, 모델 생산과정과 무관한 직무 종사)

• 실제 현장에서는 데이터의 끊임 없는 변화 -> Feature Drift 발생 -> 모델 재학습 & 파이프라인 재설계
• 비즈니스규제 & 요구사항의 빠른 변화 -> 잦은 모델 재배포 필요 -> MLOps 필요 및 중요성 증가

2. 머신러닝 프로젝트의 역할 체계

• 머신러닝 프로젝트 역할 구분: 데이터 수집, 전처리, 모델 학습, 테스트, 배포, 운영, 재학습
• 작은 프로젝트라 하더라도 모두의 역할이 필요함

데이터 사이언티스트

• 데이터 분석에 기반해 다양한 비즈니스의 문제 해결을 위한 솔루션 탐색
• 수학, 통계, 컴퓨터 과학, 공학 분야의 고학력자 다수
• 근본적인 비즈니스 문제 해결을 위해 데이터를 분석하고 유의미한 모델 구축
• 상당 시간을 데이터 조작 업무에 할애

데이터 엔지니어

• 데이터가 정상적으로 저장되어 데이터 사이언티스트의 접근이 가능하도록 인프라 담당
• 다양한 경로를 통해 확보한 raw data를 중앙에 저장하는 시스템 구축
• 데이터 크기 조절, 파일 형식 변경 -> 데이터 사이언티스트가 분석 업무에 집중할 수 있도록

머신러닝 엔지니어

• 현재는 초기 단계, 기업이 머신러닝으로 실질적 효과를 누릴 수 있도록 주도 -> 중요성 증대
• 데이터 사이언티스트 증명한 개념들을 실 서비스에 배포 가능한 규모의 시스템으로 구축에 집중
  cf.) 데이터 사이언티스트: 이론적 개념을 탐구하고 증명
• CI, CD와 같은 개발 영역에 밀접한 업무 수행
• 모델 배포 전 학습 및 테스트 자동화와 스케일링, 모델 배포 및 모니터링

데브옵스 엔지니어

• 소프트웨어 공학, 클라우드 인프라를 결합한 역할 담당
• 머신러닝 모델과 최종 사용자를 위한 어플리케이션의 연결 고리
  cf.) 전통소프트웨어 프로젝트: 테스트와 신규 코드 배포관련 자동화, 테스트 & 프로덕션 환경 관리
• 사용자용 어플리케이션의 확장성, 안정성, 반응성을 최우선 순위로 고려

IT

• 자원관리, 접근성 제어, 정보보안 업무 담당
• IT 운영과 프로젝트가 차질 없이 진행되도록 지원

비즈니스 책임자

• 최종 사용자 이해, 실제 사용 가치를 갖도록 팀 리딩
• 어떤 종류의 예측이 실용성 갖는지 정의, 운영과 규제 측면에서의 리스크 관리

관리자

• 머신러닝 프로젝트의 큰 복잡성와 다분야적 특성 이해 중요
• 조직의 여러 다른 파트의 자원 확보 조율, 팀 업무와 ROI의 관리

3. 머신러닝은 기존의 소프트웨어와 어떻게 구분되는가?

• S/W: 코드 변경이 최종 결과에 어떤 영향을 주는지 즉시 확인 가능
• 머신러닝: 코드 변경을 확인하려면 모델 재학습 과정 필요함
  재학습 과정: 상당한 시간 필요

• 코드와 더불어 데이터 또한 변화하며, 데이터 변화로 인해 동작 결과가 달라짐
• 전통적 소프트웨어: 하나의 코드 버전 -> 하나의 소프트웨어
• 머신러닝: 하나의 코드 버전 + 데이터셋 버전 -> 하나의 머신러닝 모델
• 데이터는 개발 프로세스에서 고려해야 할 새로운 변수

4. MLOps 워크플로우

4.1. MLOps의 목적

• 모델의 Life Cycle
  

• 실제로 많은 조직의 모델 개발과 운영 사이의 업무 연계가 복잡 & 비효율적인 사이클안에서 운영
  

MLOps의 목표는 가장 빠른 시간내에, 가장 적은 위험을 부담하며 아이디어 단계부터 상용화 단계까지 ML 프로젝트를 진행할 수 있도록 기술적 마찰을 줄이는 것이다.

• 출시까지 소요시간 단축, 위험 부담 감소
• 데이터 사이언티스트와 비즈니스 관계자가 동일 선상의 입장에서 소통
• 사업 관점에서 MLOps를 필수 요소로 인식하도록 유도

4.2. 머신러닝의 위험 요인

• MLOps 목표
  : 가장 빠른 시간내에, 가장 적은 위험을 부담하며 아이디어 단계부터 상용화 단계까지 ML프로젝트를 진행할 수 있도록 기술적 마찰을 최소화

• 주요 위험 유형
  1) 지식상실위험
  

• 버스지수
  - 핵심인력이 버스 교통사고 같은 갑자스러운 원인으로 프로젝트에서 제외되면서 발생하는 위험요인
  - 머신러닝 분야에서 버스 지수는 극대화
• 코드 이외에 데이터라는 요소가 존재하기 때문
• 데이터셋에는 수집 경로와 추출된 특징값(feature)등 많은 양의 정보 존재
• 데이터 가공을 위한 다양한 버전의 스크립트 존재

• 머신러닝모델: 코드, 데이터, 매개변수, 학습환경을 조합한 개념
• Raw Data부터 코드, 환경, 구성, 매개변수, 모델까지 포함한
  전체 파이프라인 추적이 가능한 버전 관리 시스템 도입 권장

2) 상용화 실패

• 배포 후 실패 요인은 간단한 문법 오류부터 데이터 변경, 예상치 못한 모델 성능 변경 등 다양함
• 모델 학습용 데이터가 의도한 형태와 동일한지 확인
• 학습 환경뿐 아니라 실제 환경에서도 모델의 정상 여부 확인
• 인프라가 일관되게 작동하도록 확인, 입력값이 같다면 항상 동일한 결과 출력, 언제든 roll back 가능

3) 규제와 윤리

• 누군가 프로덕션 모델 예측에 의문을 제기하면, 모델이 학습된 과정으로 언제든 역추적 가능(ex.이루다)
• 머신러닝 파이프라인에서 편향성 및 기타 윤리 문제 방지를 위한 테스트를 포함하도록 고려
• 비즈니스 도메인에 따른 윤리적 문제를 구분

4.3. 출시기간

• 지속 발전할 수 있는 머신러닝 역량 구축이 중요함
• 한 버전의 모델이 장기간 동안 작동하는 경우는 드물며 정기적인 재학습 필요
• 하지만 다른 버전의 코드와 데이터 세트로 재학습 되고 있을 가능성 존재
• 임시방편적인 워크플로우로 인한 혼란과 고객 불만족
• 파이프라인 전체를 바라보는 넓은 시야가 필요함

• 성공적인 기업들의 체계
  

• MLOps의 머신러닝 출시기간 단축 방법 제공
  1) 다양한 이해 관계자들의 공용어 역할
  - 팀 단위의 데이터 전처리, 모델학습, 테스트 등 세부 업무별로 분담 작업 가능
  - 모델 복잡도 증가 -> 파이프라인에서의 공동 작업 방식 이점 증가

  2) 수작업 자동화
  - 데이터 수집, 학습 모델 평가 업무 자동화 -> 리소스 부족 문제 해결
  - 신규 모델 개발 시 부분별 재활용 가능
  

4.4. MLOps 워크플로우 모범 사례

• 모델, 코드, 매개변수, 환경 등 모든 요소의 버전 관리 -> 누구나 모델 제작 과정 추적 가능하게
• 모델 제작 과정을 단계별로 부품화해 하나의 파이프라인으로 구축, 단일 노트북은 파이프라인 X
• 테스트 과정 시스템화, 체크 포인트와 안정장치로 모델의 준수사항 표준화
• 업무 자동화를 통한 개발 업무 시간 확보

5. MLOps 프로젝트 성과 측정 방법

"프로덕션에서 실행되는 모델만이 가치를 제공합니다."

• 모든 이해관계자와 함께 목적을 정의하고 구체적이고 측정 가능한 평가지표 설정
• 최종 결과뿐 아니라 프로젝트의 각 진행 단계별 성과 측정
• 역할과 책임이 명확한 종합 팀 구성

1) 공통 언어로 소통하라

• 데이터 사이언티스트 워크플로우: 내부 데이터베이스에서 데이터 추출
• 데이터를 탐색하고 모델을 개발할 수 있도록 클라우드 공간에 모든 업무를 저장
• 모델 성능 기준은 비즈니스 책임자의 최초 요구에서 시작

2) 모든 프로젝트를 구성원에게 머신러닝 교육을 시킬 수있는 기회로 삼아라

• 머신러닝 프로젝트를 통해 배운 점을 전사회의, 타운홀, 티타임 등에서 조직 전체에 공유
• 추상적인 주제부터 세부 디데일까지 포괄하여 공유
• MLOps 프로젝트에서는 조직 내 다양한 전문가의 지속적 참여 요구

3) 공동 목표와 평가 지표를 명확히 하라

6. MLOps 툴체인

6.1. 데이터 플랫폼

• 반복적인 데이터 확보와 재학습 사이클을 위한 데이터 플랫폼
  - 머신러닝 개발 과정에서 데이터 작업이 차지하는 비중은 약 80%(by Cognylitica)
  - 학습용 데이터의 품질은 출시된 서비스의 성능에도 직접적인 영향
  - “쓰레기를 넣으면, 쓰레기가 나온다(Garbage In, Garbage Out)”
  - 34%의 머신러닝 프로젝트 사례에서 데이터 확보와 재학습이 월단위로 필요(McKinsey)
  - 사이클을 관리하는 머신러닝 데이터 플랫폼을 도입함으로 제품 개발까지의 비용 최소화
• 동적인 데이터 관리
• Change Tracking(변화추적)
  - 원본 데이터만 추가된 것인지, 어노테이션을 업데이트한 것 인지 등 변경 이력을 상세 추적
  - 모든 이해 관계자가 동일한 선상에 있을 수 있게 데이터 전달 과정이 최대한 투명
• Versioning(버전관리)
  - 데이터셋이 진화함에 -> 데이터는 동적 변화 -> 모델 학습/실험이 지속적 반복
  - 예전의 데이터나 어노테이션 버전으로 회귀하는 경우도 있음
  - 데이터 플랫폼은 코드 전체 + 데이터의 출처를 제공 -> 모든 머신러닝 데이터셋의 진화과정추적
• Flexible Manipulation(유연한 조작)
  - 데이터셋의 역동적인 변화를 관리할 수 있는 다양한 기능 제공
  - 어노테이션 유형, 라벨, 데이터 작업의 어느 단계에 현재 데이터가 위치하는지
  (어떤 모델 학습에 사용, 어노테이션 완료 여부, 어노테이션 검수 완료 여부)
  - 머신러닝 데이터의 고유 특성 때문에 기존 파일 관리 도구만으로 유연한 조작 어려움
  
• 인공지능 활용한 데이터 라벨링
• Auto Labeling with AI
  - 자사의 AI 모델을 불러와 라벨링 자동화에 활용하는 경우는 콜드 스타트 문제

• 데이터 플랫폼은 다음과 같은 진보된 머신러닝 기술들을 적극적으로 활용
  
  

• ML구성 요소와 연동
  - 머신러닝 관련 대부분 기업은 데이터 라벨링, 모델 학습 & 배포, 시각화 등 특정 전문 영역에 집중
  - 머신러닝 생애주기
  
  - 데이터가 원본 데이터를 라벨링하는 팀에서 부터 모델을 학습시키고 배포하는 팀까지 원할하게 연결

• 주요시사점
  - 머신러닝 데이터 플랫폼은 데이터 확보와 재학습의 사이클을 구축하는 것을 돕는다.
  - 데이터 플랫폼은 동적인 데이터 관리 가능하고 라벨링 작업에 인공지능 활용
  - 데이터가 머신러닝 개발을 위한 다양한 하위 작업과 데이터셋 연동, 협업을 도와줌

6.2. 모델과 데이터 탐색

• 탐색은 머신러닝 프로젝트에서 가장 먼저 하게되는 구체적이고 실무적인 단계
• 데이터 탐색
  - 데이터가 없으면 모델도 존재할 수 없기에 모델 탐색 전, 데이터 탐색이 반드시 선행
  - 데이터 탐색의 목적: 데이터 이해
  - 반복적으로 빠르게 데이터 탐색하고, 시각화 등을 통한 피드백을 받는 것이 데이터 탐색의 핵심 요소
  - Notebook: 코드, 시각화 기능, 빠르고 반복적인 개발 사이클에 최적화된 환경 지원
  - but, 많은 Notebook은 일회용으로 사용되고 폐기
  
• 모델 탐색
  - 모델 탐색 단계에서 데이터 사이언티스트는 문제 해결에 적합한 여러 모델을 두고 탐색
  - 모델 탐색은 데이터 탐색 단계보다 더 높은 요구 사항 존재
  - Notebook이외로 라이브러리 종속성, 재현성, 확장 가능한 인프라 환경이 더 중요함
  - 효율적인 업무를 위해 자동으로 확장 가능한 클라우드 환경은 필수
  - 모델 탐색은 시간/돈 비용이 들어가는 단계로 각 실험의 버전 관리, 재현성이 그 무엇보다 중요
  

• 주요 시사점
  - 데이터 탐색은 데이터를 시각화해 이해하기 쉽게 만든 가벼운 오프라인 작업
  - 모델 탐색은 컴퓨팅 연산 능력과 버전 관리 차원에서 더 높은 기준을 요구
  - 탐색 단계와 ML옵스를 분리: 데이터 사이언티스트와 엔지니어를 멀어지도록 만드는 지름길

6.3. 평가 지표와 모델 최적화

• 평가 지표는 모델의 성공 여부를 정의하는 수치
• 데이터 사이언티스트는 주요 평가 지표에서 충분한 성능을 낼 수 있는 모델을 찾아야 함
• 최적화의 의미
  - 데이터 사이언스분야에서 함수 최적화: 입력값을 변경해 출력값을 최소화(또는 최대화)
  - 손실 함수(loss function): 모델의 오차를 구하기 위한 수식, 손실 함수를 최적화한다는 건 해당 모델의 오차를 최소화
• 학습/검증/테스트용 데이터 세트

• 튜닝과 프로덕션을 위한 검증 지표
  - 검증 지표는 말 그대로 모델의 프로덕션 성능을 검증하는 지표
  - 모델 실사용 시 성능을 반영하는 지표여야 하고, 일반적인 머신러닝 강좌 내용을 따라가
  거나 구체적인 비즈니스 사례에 특화되기도 함

• 평가 지표 최적화와 의사결정
  - 각종 모델이 알맞은 때에 배포될 수 있도록 hyperparameter 최적화 과정이 효율적으로 진행되어야 함
  - hyper-parameter 변경 -> 모델 재학습 -> 최적화 비용 증가
  - 프로덕션 환경에서는 여러 평가 지표로 성공 여부를 정의
  ex) 정확도, 추론시간(빠른응답요구), 고수익률 & 리스크감소 & 유동성의 적절한 균형(금융분야)
  - 하나 혹은 다수의 평가 지표로 모델 최적화 완료 후 프로덕션용으로 검토 중인 지표를 재평가
  - 상용화 하기 이전에 모델의 일반화 가능성을 확인 가능
  

• 주요 시사점
  - 보유하고 있는 데이터를 학습, 검증, 테스트 데이터 세트로 분류
  - 학습 단계 뿐 아니라 프로덕션의 성공을 나타낼 수 있는 평가 지표를 정의하고 탐구
  - 가능한 최소한의 튜닝 비용을 들여 최상의 hyper-parameter를 찾아낸다.
  

6.4. 프로덕션 준비: End-to-End Pipeline

• 데이터 사이언티스트는 컴퓨터 한 대와 정적인 데이터 세트 하나를 갖고 문제 해결 시작함
• Notebook(Jupyter notebook 등)으로 데이터 정제, 피처 변환, 라이브러리 설치, 코드 작성, 다양한 모델 적용 시도 그리고 hyper-parameter 교체 등 일련의 작업 진행
• 머신러닝의 프로덕션 준비 과정: 데이터 사이언티스트가 작업하고 있는 컴퓨터 한 대에 국한된 문제 해결 역량을 더 큰 접근과 확장이 가능한 시스템으로 다듬는 일
• 확장된 뒤에도 가치를 제공할 수 있어야하고, 이후 수년간 업데이트하고 개선하고 관리할 수 있어야
• 수동 사이클
  - 모델 자체가 제품이다
  - 수동형이거나 스크립트 기반의 프로세스
  - 데이터 사이언티스트와 엔지니어 사이의 간극
  - 느리게 반복되는 사이클
  - 테스트 자동화와 성능 모니터링의 부재
  - 버전 관리의 부재
  

• 자동 파이프라인
  - 파이프라인 자체가 제품이다
  - 완전히 자동화된 프로세스
  - 데이터 사이언티스트와 엔지니어의 협력
  - 빠른 반복 사이클
  - 테스트, 성능 모니터링 자동화
  - 버전 관리 용이성

• 주요 시사점
  - 모델이 아니라 파이프라인을 제품으로 인정. 모델을 배포가 아닌 파이프라인을 배포
  - 파이프라인을 구축하려면 시스템을 명확히 정의된 작은 요소로 나눈다
  - 세상이 변하면서 결국 모델의 정확도는 불가피하게 떨어질 것이고, 이에 대비해야함

6.5. 프로덕션 준비: Feature Store

• 피처(feature)는 프로덕션용 머신러닝에 또 다른 핵심 요소이고, 모델만큼 관리하기 복잡
• 머신러닝 기반 애플리케이션을 개발하려고 하면, 모델과 피처까지 프로덕션으로 내보내야 함
• MLOps 플랫폼은 모델 학습, 실험, 모델 검증, 프로덕션 배포까지 support
• Feature 위해 제공되는 도구는 불완전함
• Feature 배포는 feature 변환(or pipleline)까지 함께 배포, 일괄된 feature 값을 보장해야함
• Data Scientist: feature 변환 결과물을 데이터엔지니어에게 전달, 데이터엔지니어는 프로덕션용 버전으로 전환, 많은 개발 시간 필요함

• Feature Store
  - 미가공 데이터를 feature 값으로 변환하고 저장하며, 모델 학습과 온라인 예측을 위해 제공
  - 빠른 시간내에 feature를 구축하고 배포할 수 있도록 해줌
  - feature 정의의 일관성을 향상시키고, 새로운 피처를 사용하여 협업
  - feature를 프로덕션으로 즉시 배포, feature 변환 자동화 및 조정
  - feature를 공유하거나 발견하고 재사용, 연관된 메타 데이터, 변환 로직과 값 모두 관리

• Feature MileStone(별도추가)
  

• Ref.) https://www.featurestore.org/

• 주요 시사점
  - 피처를 구축하고 프로덕션으로 내보내는 과정은 머신러닝 프로덕션 준비 과정 중 가장 어려운 부분
  - 피처 스토어는 데이터 사이언티스트가 피처를 빠르고 쉽게 구축, 배포, 공유할 수 있도록 도와줌
  - 피처 스토어는 기존의 머신러닝 인프라를 보완해 피처 라이프 사이클에 DevOps 같은 역량을 갖추도록 함

6.6. 테스트

• 전통 소프트웨어는 분명하고 정적인 가정들 위에 일정한 고정 규칙을 부여하면서 구축
• 지속해서 변하는 데이터에서 동적으로 규칙을 찾는 일을 의미하며 그렇기 때문에 머신러닝의 테스트는 훨씬 더 복잡
• 데이터 테스트
  - 머신러닝 프로젝트에선 데이터가 코드만큼 중요
  - 데이터 검증 테스트는 학습과 인퍼런스에 사용되는 데이터 입력에 대해서 같은 역할을 해야함
  - 피처들의 상관관계도 테스트, 두 개 이상의 피처에서 높은 수준의 상관관계가 발견된다면, 모델의 성능과 정확도에 부정적인 영향
• 모델 데스트
  - 학습 단계: 각각의 hyper-parameter 영향 테스트
  - 모델 배포 시: 오프라인 평가 지표와 상용화 모델의 실제 영향도 사이의 상관관계 테스트
• 인프라 테스트
  - 머신러닝 파이프라인은 하루 단위로 최대한 재현 가능해야
  - 우선 두 개 이상의 모델에 같은 데이터를 적용해 학습시킨 뒤, 평가 지표별로 격차를 측정
  - 인적 과실이 발생했을 때 안정적인 모델로 롤백하는 일도 중요
  
• 주요 시사점
  - 머신러닝의 동적 특성 때문에, 테스트는 더욱더 중요
  - 코드 테스트는 당연한 과정이며 데이터 테스트는 가장 중요
  - 파이프라인 재현 가능성은 안전한 배포 과정의 핵심

6.7. 배포와 인퍼런스

• 배포: API, 애플리케이션으로 또는 다른 방법으로 머신러닝 모델을 외부에 제공하는 행위
• 배치 인퍼런스(batch inference)
  
  - 여러 요청 사항을 배치(batch)로 묶어서 한번에 같이 추론(inference)하는 일
  - latency 문제가 되지 않는 모든 시나리오에 적합 (ex. 잠재 고객들의 적합도 점수 계산 모델)

• 온라인 인퍼런스(online inference)
  
  - 실시간으로 추론을 실행하는 절차, 모든 요청은 모델에서 즉시 처리
  (ex. 현 시점의 최적경로예측, 주식 시장 변동성 예측)
  - 예측 오류가 고객에게 바로 노출되기 때문에 더 많은 것이 요구
  - 과부화에 대비한 시스템의 자동 확장 가능해야하고, 모니터링 또한 높은 수준 필요

• 엣지 인퍼런스
  
  - 고객의 하드웨어 활용하여 서비스
  - 비용을 들이지 않고도 완벽한 확장 가능함, 클라우드 등 인프라 운영비용 불필요
  - 각각의 디바이스에 탑재된 수많은 버전을 관리하기 어려움
  - 디바이스를 통한 모델의 성능 등 피드백 어려움
  - 학습된 모델을 외부로 전송 -> 역 추적을 통한 학습 데이터를 추적할 수도 있음

• 주요 시사점
  - 가능한 한 배치 인퍼런스를 사용한다. 온라인 인퍼런스는 최후의 수단
  - 가능한 한 엣지 인퍼런스를 사용한다. 비용을 들이지 않고도 완벽한 확장성 달성
  - 복잡한 셋업은 강력한 모니터링을 요구
  
  

7. 결론

• 머신러닝에 투자를 한다면, 기존에 해결할 수 없었던 비즈니스 상황들을 해결 가능
• 머신러닝은 화물 운송에 가까우며 MLOps는 컨테이너화(containerization)에 가까운 개념
• MLOps는 하나의 프로세스인 동시에 인프라
• MLOps 도입 시 아래 네 가지 핵심 모범사례 도입 권장
  - 모델의 재현 가능성을 갖추기 위한 버전화(versioning)
  - 더 나은 시스템 구축 협업을 위한 파이프라인 도입
  - 프로덕션 모델의 기준을 확립하기 위한 테스트
  - 시간 절약하고 최대한 자동복구가 가능한 시스템을 위한 자동화
• MLOps 궁극적 목적
  - 최대한 짧은 기간 안에 아이디어 단계의 모델을 프로덕션까지 배포
  - 최소한의 위험 부담으로 시장에 출시할 수 있도록 기술적 마찰을 줄이는 것