[MLOps] MLOps의 아키텍처와 워크플로우

앞선 게시글에서는 MLOps의 원칙과 구성요소를 살펴보았습니다. 이번 게시글에서는 MLOps의 원칙과 구성요소, 역할을 기반으로 MLOps ends-to-end 아키텍처를 도출합니다.

※ Machine Learning Operations (MLOps):Overview, Definition, and Architecture (2022) 에서 소개한 아키텍처를 번역하고 있습니다.

MLOps의 원칙과 구성요소, 역할을 기반으로 MLOps ends-to-end 아키텍처를 도출합니다. 이 아키텍처는 기술에 구애받지 않도록 설계되었으며, ML 연구원, 실무자는 자신의 요구사항에 적합한 기술과 프레임워크를 선택할 수 있습니다.
아키텍처는 크게 네개의 부분으로 구성되어있습니다.

• (A) MLOps 프로젝트 시작단계
• (B) feature store에 대한 데이터 수집을 포함한 feature engineering 파이프라인
• (C) 실험
• (D) 모델 배포까지 자동화된 파이프라인

각각의 부분에 대한 단계를 살펴봅니다.

(A) MLOps Project Initiation

(1) 비즈니스 이해관계자(R1): 비즈니스를 분석하고 ML을 사용하여 해결할 수 있는 잠재적인 비즈니스 문제를 식별합니다.
(2) 솔루션 아키텍트(R2): ML 시스템 전체에 대한 아키텍처 설계를 정의하고, 철저한 평가를 거쳐 사용할 기술을 결정합니다.
(3) 데이터 과학자(R3): 비즈니스 목표에서 회귀 또는 분류를 사용해야 하는지와 같은 ML 문제를 도출합니다.
(4) 데이터 엔지니어(R4)와 데이터 과학자(R3): 문제를 해결하는 데 어떤 데이터가 필요한지 이해하기 위해 협력합니다.
(5) 데이터 엔지니어(R4)와 데이터 과학자(R3): 답변이 명확해지면 협력하여 초기 데이터 분석을 위한 원시 데이터를 찾습니다. 그들은 데이터의 분포와 품질을 확인하고 유효성 검사를 수행합니다. 또한 데이터 소스에서 들어오는 데이터에 라벨이 지정되어 있는지 확인합니다.(지도학습의 필수 요구 사항)

(B1) Requirements for feature engineering pipeline.

feature는 모델 학습에 필요한 속성입니다. feature engineering pipeline의 기본 요구사항은 아래와 같이 정의됩니다.
(6) 데이터 엔지니어(R4): 데이터 변환 규칙(정규화, 집계) 및 cleaning 규칙을 정의하여 데이터를 사용 가능한 형식으로 만듭니다.
(7) 데이터 과학자(R3)와 데이터 엔지니어(R4): 다른 feature를 기반으로 새로운 변수, 개선된 feature를 계산하는 것과 같은 feature engineering 규칙을 함께 정의합니다. 초기에 정의된 규칙은 모델의 피드백이나 성능을 관찰하는 모니터링에서 나오는 피드백을 기반으로 데이터 과학자가 반복적으로 조정해야 합니다.

(B2) Feature Engineering Pipeline

(8) 우선 feature engineering pipeline은 스트리밍 데이터, 배치 데이터, 클라우드 저장소 등의 원시 데이터에 연결됩니다.
(9) 데이터는 data sources 에서 추출됩니다.
(10) 데이터 전처리는 데이터 변환 및 정제(cleansing) 작업으로 시작됩니다. 요구 사항 수집 단계(A) 에서 정의된 산출물을 활용하여 데이터를 사용 가능한 형식으로 만듭니다. 피드백을 기반으로 지속적으로 개선되는 작업입니다.
(11) feature engineering 작업은 새로운 feature, 다른 feature들을 기반으로한 feature를 계산합니다. 사전에 정의된 규칙을 사용하며, 피드백을 기반으로 지속적으로 개선됩니다.
(12) 마지막으로 데이터 수집 작업은 feature store system (C4)에 배치 또는 스트리밍 데이터를 불러옵니다. 불러오는 데이터는 오프라인/온라인 데이터베이스(모든 종류의 데이터 저장소)일 수 있습니다.

(C) Experimentation

실험 단계의 대부분의 작업은 데이터 과학자(R3)가 주도합니다. 데이터 과학자는 소프트웨어 엔지니어(R5)의 지원을 받습니다.
(13) 데이터 과학자(R3): 데이터 분석을 위해 feature store system(C4)(또는 원 데이터)에 연결합니다. 데이터 조정이 추가로 필요한경우 데이터 엔지니어링 영역에 피드백을 보고합니다.
(14) feature store system에서 나오는 데이터의 준비와 검증이 필요합니다. 이 작업에는 학습 및 테스트 분할 데이터 생성도 포함됩니다.
(15) 데이터 과학자(R3)는 최고 성능의 알고리즘과 하이퍼파라미터를 추정하고, 그런 다음 훈련 데이터(C5)를 사용하여 모델 학습을 시작합니다. 소프트웨어 엔지니어(R5)는 잘 설계된 모델 학습 코드를 생성하기 위해 데이터 과학자(R3)를 지원합니다.
(16) 다양한 모델 매개변수가 테스트되고 검증됩니다. 성능 지표가 좋은 결과를 보이면 반복 학습은 중지됩니다. 모델 학습과 모델 검증 작업은 반복적으로 진행되며 이러한 작업을 통틀어 '모델 엔지니어링' 이라고 부를 수 있습니다. 모델 엔지니어링 목표는 가장 좋은 성능을 가진 알고리즘과 하이퍼파라미터를 식별하는 것입니다.
(17) 데이터 과학자(R3)는 모델을 내보내고 코드를 저장소에 커밋합니다.
DevOps 엔지니어(R6) 또는 ML 엔지니어(R7)는 자동화된 ML 워크플로 파이프라인에 대한 코드를 정의하고 이를 리포지토리에 커밋합니다. 새로운 ML 워크플로 파이프라인 코드가 리포지토리에 커밋되면 CI/CD 구성 요소(C1)가 업데이트된 코드를 감지하고 CI/CD 파이프라인을 자동으로 트리거합니다.
빌드 단계에서는 ML 모델과 ML 워크플로 파이프라인의 작업이 포함된 아티팩트를 생성합니다. 테스트 단계에서는 ML 모델 및 ML 워크플로 파이프라인 코드를 검증합니다. 전달 단계에서는 버전이 지정된 아티팩트를 아티팩트 저장소(예: 이미지 레지스트리)에 푸시합니다.

(D) Automated ML workflow pipeline

DevOps 엔지니어(R6)와 ML 엔지니어(R7)는 자동화된 ML workflow pipeline 관리를 담당합니다. 또한 Kubernetes(C5)와 같은 컴퓨팅을 지원하는 프레임워크 및 하드웨어 리소스 형태로 모델 학습 인프라를 관리합니다. workflow orchestration component(C3)는 자동화된 ML 워크플로 파이프라인의 작업을 조정합니다. 각 작업에 대해 필요한 아티팩트는 아티팩트 저장소에서 가져옵니다. 각 작업은 격리된 환경(예: 컨테이너)을 통해 실행될 수 있습니다. 마지막으로 workflow orchestration componen(C3)는 로그, 완료 시간 등의 형태로 각 작업에 대한 메타데이터를 수집합니다. 자동화된 ML workflow pipeline이 트리거되면 다음 작업들이 자동으로 관리됩니다.
(18) feature store 시스템에서 버전이 지정된 피처를 자동으로 가져옵니다(데이터 추출). 오프라인/온라인 데이터베이스(또는 모든 종류의 데이터 저장소)에서 피처를 추출합니다.
(19) 자동화된 데이터 준비 및 검증. 또한 학습 및 테스트 분할이 자동으로 정의됩니다.
(20) 새로운 데이터(버전이 지정된 피처)에 대한 자동회된 모델 학습을 수행합니다. 알고리즘과 하이퍼 파라미터는 이전 실험 단계의 설정을 기반으로 사용합니다.
(21) 필요한 경우 자동 모델 평가 및 하이퍼파라미터의 반복 조정이 실행됩니다. 성능 지표가 좋은 결과를 나타내면 자동화된 반복 훈련이 중지됩니다. 자동화된 모델 훈련 작업과 자동화된 모델 검증 작업은 좋은 결과를 얻을 때까지 반복됩니다.
(22) 훈련된 모델은 내보내집니다.
(23) 모델 레지스트리(C6)로 푸시됩니다. 여기서 모델 레지스트리(C6)는 관련 구성 및 환경 파일과 함께 코드로 저장되거나 컨테이너화됩니다.
반복되는 학습 작업에 대해 ML 메타데이터 저장소(C7)는 모델 학습을 위한 매개변수 및 결과 성능 지표와 같은 메타데이터를 기록합니다. 여기에는 훈련 작업 ID, 훈련 날짜 및 시간, 기간, 아티팩트 소스에 대한 추적 및 로깅도 포함됩니다. (model lineage: 모델을 훈련하는데 사용되는 feature와 훈련 코드의 소스와 버전, 상태(예: 준비 또는 생산 준비)도 기록)
성능이 좋은 모델의 상태가 스테이징에서 프로덕션으로 전환되면 모델 배포를 위해 DevOps 엔지니어 또는 ML 엔지니어에게 자동으로 넘겨집니다.
(24) CI/CD 구성 요소(C1)가 지속적인 배포 파이프라인을 트리거합니다. 프로덕션 준비가 완료된 ML 모델과 모델 배포 코드를 가져옵니다. 지속적 배포 파이프라인(continuous deployment pipeline)은 ML 모델과 제공 코드의 빌드 및 테스트 단계를 수행하고 프로덕션 제공을 위해 모델을 배포합니다.
(25) 모델 배포 구성 요소(C8)는 feature store 시스템(C4)에서 나오는 새로운, 보이지 않는 데이터에 대해 예측을 수행합니다. 소프트웨어 엔지니어(R5)는 실시간 예측을 위한 온라인 추론 또는 대량의 입력 데이터에 관한 예측을 위한 일괄 추론으로 설계할 수 있습니다. 실시간 예측의 경우 기능은 온라인 데이터베이스(낮은 대기 시간)에서 가져와야 하는 반면, 일괄 예측의 경우 기능은 오프라인 데이터베이스(일반 대기 시간)에서 제공될 수 있습니다. 모델 배포 애플리케이션은 컨테이너 내에서 구성되는 경우가 많으며 예측 요청은 REST API를 통해 처리됩니다. ML 엔지니어(R7)는 모델 배포 컴퓨팅 인프라를 관리합니다.
(26) 모니터링 구성 요소(C9)는 모델 배포 성능과 인프라를 실시간으로 지속적으로 관찰합니다. 낮은 예측 정확도 감지와 같은 특정 임계값에 도달하면 정보가 피드백 루프를 통해 전달됩니다.
(27) 피드백 루프는 모니터링 구성 요소(C9)에 연결되어 빠르고 직접적인 피드백을 보장하여 보다 향상된 예측을 가능하게 합니다. 이를 통해 지속적인 학습, 재학습 및 개선이 가능합니다. 피드백 루프의 정보는 모델 모니터링 구성 요소로부터 여러 단계로 전송됩니다. 실험 단계에 대한 피드백은 추가 모델 개선을 위해 데이터 과학자가 전달합니다.
(28) 지속적인 학습. 모델 모니터링 구성 요소(C9)가 데이터에서 concept drifts를 감지하면 정보가 스케줄러로 전달되고, 스케줄러는 재학습(지속적인 학습)을 위해 자동화된 ML 워크플로 파이프라인을 트리거합니다. 분포의 비교를 통해 배포된 모델의 적절성 변화를 감지하여 drift를 감지할 수 있습니다. 재학습은 통계적 임계값에 도달했을때 자동으로 트리거 되거나, 새로운 feature 데이터를 사용할 수 있을 때, 또는 주기적으로 트리거할 수 있습니다.
지금까지 살펴본 전체 아키텍처를 한 그림으로 살펴보면 아래와 같습니다.

이번 페이퍼를 통해서 MLOps를 구축하기 위해서는 다양한 역할과 기능이 필요함을 알 수 있습니다. MLOps를 도입하기 위해서 처음부터 모든 구성요소를 도입하기에는 어려움이 따릅니다. 구글 클라우드의 MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인 문서에는 단계별로 MLOps를 적용해나가는 가이드라인을 제공하고 있습니다.
지금까지 MLOps가 어떠한 구성요소와 원칙, 역할들을 가지고 있는지 알아보고 전체적인 아키텍처도 살펴보았습니다. MLOps에 어떠한 구성요소가 있는지 알아보고, 큰 그림을 볼 수 있게 된 좋은 기회였습니다.

---

reference
Dominik Kreuzberger and Niklas Kühl and Sebastian Hirschl (2022) Machine Learning Operations (MLOps): Overview, Definition, and Architecture