AWS 기술 블로그

AWS를 이용한 MLOps 구축 사례 살펴보기

기업 내 Machine Learning (ML) 모델들이 점차 늘어나면서 Machine Learning Operations (MLOps)에 대한 관심을 넘어, 많은 기업에서 실제 업무에 MLOps를 활용하고 있습니다. MLOps는 양질의 데이터를 확보하는 활동부터, 데이터 과학자를 위한 학습 환경을 제공하는 활동, 여러 모델들을 신뢰성 있게 학습하는 활동, 학습된 ML 모델을 실제 업무에 배포하는 활동 등에서 생산성 높이기 위해 자동화하고, 이를 통해 전체적인 운영과 관리 자원을 줄이는 방향으로 활용되고 있습니다. MLOps를 활용하는 기업들은 각 기업의 성숙도에 따라 전체 ML 프로세스 중 일부분에 대해 MLOps의 일부를 적용해 보거나, 하나의 모델에 대해 MLOps를 적용한 후 전체로 확장하는 방향으로 진행하면서, ML 프로세스의 자동화 단계를 점점 확대하고 있습니다.

이런 과정에서 많은 기업들은 이미 AWS에서 기업의 환경에 적합한 MLOps 환경을 구축하고자 AWS의 다양한 서비스들을 활용하여 만들어가고 있으며, 그중에서 공개된 주요 구축 사례들을 정리하여 공유합니다.

1. NatWest Group의 MLOps 구현 사례

영국의 4대 은행 중 하나인 낫웨스트 (NatWest)는 1,900만 고객과 3,000개 이하의 모델, 500명 정도의 데이터 과학자와 데이터 엔지니어를 보유하고 있는 은행입니다. 이들은 MLOps를 도입하기 전 인력, 프로세스, 데이터, 기술 등 4가지 분야의 문제점 (pain points)을 가지고 있었습니다.

MLOps의 구축 동기

  • 인력 (People) : 다양한 재능을 가진 직원들이 있었지만, 클라우드를 사용하는데 올바른 학습 지원과 소프트웨어 개발 마인드셋으로 일하는 것이 부족했습니다.
  • 프로세스 (Process) : 시간이 지나면서 조직이 커지고, 이에 따라 내부의 프로세스들이 계속 늘어나면서, 모델을 개발한 데이터 과학자와 이를 실제 활용하기 위해 모델을 배포하는 데이터 엔지니어들 모두가 힘들어하는 상황이 발생하게 되었습니다.
  • 데이터 (Data) : 조직별로 silo되어 관리되고 있기에, 데이터에 대한 탐색과 접근이 어려웠습니다.
  • 기술 (Technology) : 조직별로 파편화되어 있고, 이전 기술 환경에서 벗어나기 어려운 상황이 되었습니다.

이에 따라, 낫웨스트는 MLOps 비전을 수립하여, 낫웨스트의 고객들에게 인사이트를 빠르게 전달할 수 있는 기반을 확립하고자 하였습니다.

MLOps의 구현 목표

  • 인프라스트럭처를 생성하는데 자동화되고 표준화된 패턴으로 수행합니다.
  • 복잡한 MLOps 프로세스를 단순화할 수 있도록 최적화된 거버넌스를 수행합니다.
  • 데이터 접근이 용이하도록 진행합니다.
  • 통합된 운영 모델을 지원할 수 있는 modern tech 스택을 제공하여, 데이터 과학자 팀과 데이터 엔지니어 팀 모두가 오너십을 가질 수 있도록 제공합니다.

이를 위해 낫웨스트는 여러 지표 (metrics)들을 지정해서 이를 개선하는 방향으로 진행하고자 했으며, 그 중 몇가지 지표들은 아래와 같습니다.

MLOps의 주요 개선 지표

  • End-to-end 솔루션의 배포 속도 향상 (기존 : 최대 12 개월 소요)
  • 데이터 탐색 및 접근의 단순화 (기존 : 최대 5일 소요)
  • ML 모델의 실사용 경로 단순화 (기존 : 3 ~  6개월)
  • 최종 사용자의 self-service 환경 생성 (기존 : 30일 이상)

과거 낫웨스트에 데이터 과학자가 입사하게 되면, 기본적인 Python 환경을 제공받기 위해 몇 주가 소요되며, 데이터를 얻기 위해서는 10개의 다른 팀들과 논의를 하면서 10개의 다른 위키 페이지를 보는 일이 필요했습니다.

MLOps 아키텍처

플랫폼 엔지니어링 팀은 shared service 계정에서 다양한 활용 사례를 통해 사용이 가능한 공통 자원의 산출물들을 제공하는 역할을 합니다.

  • 아키텍처의 흰색 영역 : 공통 Docker 이미지, SageMaker Pipelines스텝, 모델 파이프라인과 관련된 산출물들, 공통의 인프라 스트럭처들을 Amazon ECR (Elastic Container Registry), Service Catalog, Amazon S3를 통해 관리합니다.

  • 아키텍처의 주황색 영역 : 테크 리드 팀에서 필요한 자원을 요청하면, 플랫폼 팀에서는 개발, 테스팅, 실환경 등 3개의 계정을 제공하게 되며, 모든 계정은 데이터 레이크와 안전한 연결을 가지게 됩니다. 또한, 테크 리드 팀에서는 Service Catalog를 통해 사전 정의한 사용자 Role, SageMaker Studio domain과 계정들에 필요한 다른 서비스들을 함께 배포하게 됩니다.

  • 아키텍처의 하늘색 영역 : 모델 승인자는 SageMaker Studio 인터페이스를 통해 모델의 성능 지표와 비즈니스 요구사항에 맞게 수행되고 있는지를 살펴볼 수 있으며, 데이터의 Bias와 explainability를 확인할 수 있습니다. 이를 통해 테스팅과 실환경 계정에 모델들과 파이프라인을 개선할 수 있습니다.

MLOps Pipelines 구성

SageMaker workflow를 사용하면서 팀들이 비즈니스 문제를 푸는데 집중할 수 있도록 여러 서비스들을 추가적으로 제공하고 있습니다. 특히, 은행에 의무적으로 필요한 Data Quality 체크와 Bias 모니터링, Explainability 등의 단계를 각 팀이 소유한 템플릿을 이용하여 Pipelines에 빠르게 수정하여 적용할 수 있도록 할 수 있다는 점은 SageMaker Pipelines의 장점 중에 하나입니다.

MLOps적용 결과

  • End-to-end 솔루션의 배포 속도 향상 (기존 : 최대 12 개월 소요 → 현재 : 3개월 미만)
  • 데이터 탐색 및 접근의 단순화 (기존 : 최대 5일 소요 → 현재 : 1일 미만)
  • ML 모델의 실사용 경로 단순화 (기존 : 3 ~  6개월 → 현재 : 2주 이내)
  • 최종 사용자의 self-service 환경 생성 (기존 : 30일 이상 → 현재 : 2시간 이내)

특히, 데이터 과학자의 ML 환경 설정 시간은 아래와 같이 개선되었습니다.

  • 기존은 40 ~ 50일 소요가 되었으나, 현재는 1 ~ 2일 정도로 단축되었습니다. 특히, 계정이 제공된 다음에는 SageMaker Studio ML 프로젝트의 경우 2시간 내로 생성이 가능합니다.
  • 2022년에는 13개 팀에서 30개 정도의 Use case들에 대해, 300개 이상 SageMaker Project와 Pipelines, 1만 개이상의 SageMaker Processing jobs을 수행하고 있으며, 개발 계정에서 1,000개의 모델을 학습하고 있습니다.

참조 링크

2. Thomson Reuters의 AI Platform 구현 사례

톰슨 로이터 (Thomson Reuters)는 1990년 초 첫번째 ML 모델을 생성한 이후, 오랜 역사를 가지고 ML을 수행해 오고 있습니다. 특히, 검색과 자연어 처리 분야 중심으로 진화하고 있으며, 200명 이상의 데이터 과학자를 보유하고 있습니다.

AI Platform 구축 동기

  • AI 활용 사례가 증가하고 있으며, 팀들 간의 다른 기술과 툴셋을 사용하는 경우도 점차 증가하고 있습니다.
  • 모델의 Explainability 등과 같은 규제 관련 요구사항이 늘어나고 있습니다.
  • 뿐만 아니라, 재생산성과 협업에 대한 요구 또한 필요하게 되었습니다.

AI Platform구현 목표

  • 데이터를 다루기 때문에 환경에 대한 안전한 접근이 제공되어야 합니다.
  • 속도 측면에서도 확장이 가능한 클라우드 리소스를 이용하고자 합니다.
  • 추가적으로 모델 거버넌스가 필요하며, 이를 위해 데이터 과학자가 많은 시간을 소요하지 않도록 합니다.
  • 마지막으로는, 이 Platform을 통해 협업할 수 있는 환경을 제공하고자 합니다.

SageMaker 의 선택 사유

  • 초기에는 다양한 서비스를 고려했으나, 인공 지능을 사용하는 관점에서 함께 성장할 수 있는 서비스를 선택하고자 했습니다.
  • 또한, 확장성 있게 ML을 할 수 있는 환경이 필요했고, 환경에 맞게 유연성 있도록 적용할 수 있다는 장점도 있었습니다.
  • 마지막으로는 AWS의 파트너십이 만족스러웠습니다.

AI Platform의 아키텍처

AI Platform은 확장이 가능해야 하며, 데이터 과학자가 데이터를 가져온 다음, 모델을 생성하고 배포하게 되며, 이후 모니터링을 하는 것이 가능하도록 설계하였습니다. 또한, 다양한 페르소나에 맞도록 특정 페르소나는 모델 배포가 가능하지만 모델 모니터링은 불가능한 옵션을 제공하여 플랫폼에서 동작하도록 설계하였습니다.

  • Data Service : Snowflake, S3, 데이터 과학자들의 데이터 저장소 등에서 데이터를 가져오며, 필요한 거버넌스 계층을 추가합니다.
  • Experimentation Account : 실험을 위한 환경을 제공하며, 데이터 과학자들을 위해 실험용 Account를 만드는 것입니다. 이 개발 환경은 매우 중요하다고 생각되며, 데이터 과학자들이 데이터 분석과 처리, 모델 학습을 하면서, 그들이 클라우드에 안전하게 접근할 수 있고, 필요한 역할이 설정될 수 있도록 제공합니다. 또한, 다른 사람들과의 협업이 가능하면서, 필요한 다른 AWS 서비스들과 쉽게 연계할 수 있도록 합니다.
  • Central Model Registry : 모델을 생성하고 실 환경으로 배포되면, 거버넌스 팀이 이 모델이 무엇에 관한 것이고, 모델이 무엇을 할 것인지에 대해 이해하며, 어떻게 모니터링을 고려하고 있는지, 모델에 대한 bias는 고려했는지 등 파악하게 됩니다. 모델이 폭발적으로 증가하는 것에 대해 SageMaker Model Registry를 활용하면서, 거버넌스 계층과 거버넌스 워크플로우를 제공하고 있으며, 이 과정이 톰슨 로이터에서 매우 중요한 과정입니다.
  • Inference Deployment : 모델과 파라미터를 선택하고, 모델을 배포하는 것에 대해 내부적으로 어떻게 동작하는지에 대해 생각하지 않아도 되는 SageMaker Inference를 활용하여 제공합니다.
  • Data/Model Drift and Bias Evaluation : Ops 기능이 포함된 서비스를 제공하는데, 실 환경에서 모델들이 여전히 성능을 발휘하고 있는지 확인할 수 있는 모델 모니터링을 제공합니다. 또한, 모델의 투명성을 확보하며, 공평한 결과를 낼 수 있도록 하는 것이 중요하기에 SageMaker Clarify를 활용합니다.

Model monitoring에 대한 아키텍처

구현 시에 사용자들은 Snowflake 또는 S3에서 데이터를 선택할 수 있는 방식으로 모델 모니터링을 구성하였고, 모니터링할 모델, 모델을 모니터링할 빈도, 필요한 매개 변수, 알림을 받는 빈도 등을 지정할 수 있게 하였습니다. 그리고 이런 모든 동작을 하나의 Account에서 수행하는 것보다는 Central Account에서 조정을 하여, 각 Account에서 모델 모니터링을 수행하는 방식으로 Cross Account를 구성하였습니다. 이를 통해, 사용자들이 원하는 Account를 선택할 수 있으며, Central AI Platform 팀에서는 서비스를 배포하는 것과 함께 모든 활동을 모니터링하고, 통합할 수 있습니다.

  • Central Account : 대상이 되는 Business Account에 SageMaker를 배포하고, Business Account의 결과를 시각화하거나, 최종 사용자들 대상으로 경고 메시지를 생성할 수 있습니다.
  • Business Account : Snowflake 또는 S3에서 데이터를 가지고 와서, 모델 모니터링의 지표를 기반으로 많은 메트릭을 계산합니다. 다음으로, 이러한 모든 결과를 Central Account의 Central Model Registry로 다시 push합니다.

기본적인 모델 평가는 SageMaker Model monitoring을 사용하면서, 이를 잘 customizing해서 사용합니다. 현재 사용하는 모델은 요약 (summary)을 하는 NLP모델들이며, 이 경우 특정 지표를 이용하기 어려움이 있습니다. 이 부분에 대해, 사용 시 수정이 가능하도록 하여 원하는 유연성을 얻을 수 있습니다.

AI Platform의 모델 모니터링 화면 예시

사용자들은 화면에서 모델을 선택하고 지표를 선택한 다음, 지표에 대한 모니터링 스케쥴링을 선택하여 모니터링을 수행합니다. 또한, 특정 값을 기준으로 알람을 주는 것도 가능합니다.

AI 플랫폼의 향후 계획

  • Bias와 Explainability와 관련하여 SageMaker Clarify를 통해 모델을 이해하는 역량을 얻고자 합니다.
  • 이를 이용하여, 모델의 재학습이 필요한지 여부와 재학습에 대한 주기, 모델의 공정성 (Fairness), 투명성 등을 확보하려고 합니다.

참조 링크

3. Fidelity의 Feature Store 구축 사례

Fidelity Investments는 데이터 과학자와 협력하는 데이터 및 기계학습 엔지니어 팀을 보유하고 있으며, 기술 플랫폼에 연간 25억 달러를 투자하는 금융 회사입니다. 17,000명 이상의 기술 인력을 가지고 있습니다. Fidelity는 데이터 준비 과정에서Amazon SageMaker의 Feature Store를 활용하여 Feature들을 저장과 관리하고 있습니다.

Feature Store의 도입 배경

  • 데이터 준비 과정은 데이터 과학자들이 하는 작업들 중 80% 정도의 리소스가 투입되는 힘든 일로, 데이터 정제, 데이터 세트 구성 및 데이터 수집 등의 작업들이 필요합니다.
  • 이 작업들을 공통된 데이터 준비 작업들로 구성합니다.

Batch 방식의 데이터 저장/관리 아키텍처

Fidelity는 계좌 (accounts), 잔고 (balances) 또는 거래 (transactions)등의 SA (Subject Area) 별로 Feature를 병렬 처리하기 위해  Amazon SQS와 AWS Lambda를 활용하고 있으며, 최종 Feature는 SageMaker Feature Store에서 저장과 관리를 하고 있습니다.

데이터를 batch로 ingest (put_record)하는 아키텍처를 좀 더 살펴보면,

  • 데이터 소스로 부터 각 SA (Subject Area) 별로 데이터를 가져오고, 이 데이터의 메타 정보를 Manifest 파일로 구성합니다. 각 SA 별로는 대략 100 개 이상의 feature들이 있습니다.
  • SA가 저장된 S3의 위치 정보로 Manifest 파일을 생성한 다음 이를 S3에 저장하면, 저장 이벤트를 통해 SNS와 SQS를 거쳐서 Lambda에서 manifest 파일을 읽습니다.
  • Lambda에서는 각 SA별로 이벤트를 생성하여 병렬 작업으로 진행하게 됩니다.
  • 각 SA 별로 구성된 Queue에서는 AWS Step Functions를 실행하는 Lambda 호출하게 됩니다.
  • Step functions는 단계적으로 먼저 FeatureGroup(DB의 테이블 단위와 유사 개념) 을 구성합니다. 요청되는 feature의 스키마와 기존 FeatureGroup의 스키마가 다른 경우 FeatureGroup의 버전은 증가하게 됩니다. Fidelity의 경우는 배치 모드에서 use case별로 대략 17개의 FeatureGroup을 사용하고 있습니다.
  • AWS Glue 서비스는 상호 참조ID의 표준화 등 몇 가지 전처리 작업을 수행하며, 이후 SageMaker Processing jobs을 통해 S3에 저장된 feature 데이터를 읽어서, Online Feature Store에 ingest 하게 됩니다.

스트림 방식의 데이터 저장/관리 아키텍처

실시간으로 사용하는 경우, 다양한 디지털 채널을 통해 들어오는 데이터 스트림에 대해 수백 여개의 feature들을 ingest 합니다.

예를 들어 클릭과 같은 스트림 등이 이에 속하게 되는데, 이런 클릭들은 Amazon Kinesis stream을 통해 데이터를 얻을 수 있으며, Apache Flink 와 Amazon EMR을 사용하여 1시간 단위의 time window에 대해 이 features들을 집계하여 제공합니다. Features들은 클릭 스트림 데이터와 페이지에 임베딩되어 있는 값들을 기반으로 생성됩니다. 이 features들은 이벤트를 통해 SQS로 전달되고, Lambda는 이 이벤트를 읽어서 Feature Store에 업데이트를 합니다.

실시간 추론 아키텍처

실시간 Ingestion이 완료되면 발생하는 이벤트를 이용하여 SageMaker endpoint에 추론을 요청합니다.

  • 추론 시에 모델에서 특정 구성 파일을 읽을 수 있는 Feature Set Library를 Fidelity에서 개발하였는데, 구성 파일은 모델이 예측하는데 필요한 관련된 FeatureGroups들과 features들을 매핑하는 정보가 포함되어 있습니다.
  • 이 Feature Set Library는 BatchGetRecord API를 이용하여 각 FeatureGroups 내의 features들을 가져오게 됩니다. 예를 들어, 기존 Batch를 통해 구성된 FeatureGroup 1에서 4개의 features를, FeatureGroup 2에서 2개의 features를 가져오고, 다른 FeatureGroup에서 8개의 features를 가져올 수 있습니다.
  • Event Router가 SageMaker Endpoint의 예측 값을 응답 받으면, Prediction/Store DB에 저장하고, 어플리케이션은 이 결과를 최종 사용자가 활용하는 Applications로 전달 됩니다.

데이터 저장/관리에 대한 향후 계획

현재 600 여개의 Subject Areas를 생성하여 사용하고 있으며, batch inference에서 백여개의 모델을 활용하고 있습니다. 향후 이 중 몇개는 real-time 모델들로 배포할 계획이라고 합니다.

참조 링크

4. Vanguard의 ML Platform 구현 사례

Vanguard는 1975년에 설립된 미국 펜실베니아에 위치한 투자 관리 회사이며, 내부 데이터 과학자를 위해 4가지 목표를 가지고 ML Platform을 구성하기 시작했습니다.

ML Platform의 목표

  • 24시간 내에 데이터 과학자가 사용할 수 있는 환경이 포함된 플랫폼을 제공합니다.
  • 모델 배포를 100% 자동화합니다.
  • 위험을 줄이기 위해 데이터 과학자가 준수해야 하는 것들과 관련된 유효성 검사를 자동화합니다.
  • ML 플랫폼에 대한 사용자 만족도를 매년 10% 향상하도록 합니다.

MDLC (Model Development Life Cycle) 기반으로 각 단계별 capabilities

문제 정의와 데이터 준비:

특정 모델에 대한 책임자 또는 제품 책임자와 데이터 과학자, MLOps 엔지니어, 그리고 모델 개발에 관련된 다른 페르소나들의 full stack 팀을 구성하면서 문제 정의를 진행합니다. 다음으로 데이터를 이해하거나, 데이터 식별 또는 데이터의 차이를 확인하거나, 모델 개발을 위한 데이터 접근 설정 등을 진행합니다. Vanguard에서는 데이터 과학자들과 팀들의 상호 소통을 Chatbot 기술을 이용하여 자동화하였습니다.

  • “나는 새로운 문제가 있어”, 또는 “나는 새로운 팀이야” 을 남기면, Chatbot은 직접 IAM role을 설정하게 되며, 실험, 디버깅 및 Bias와 Explanable한 정보를 얻을 수 있는 SageMaker 기능, Model registry, 필요한 다양한 서비스 등을 포함해서 이를 수행하는 팀 대상으로 MLOps capabilities를 제공합니다.
  • 이후 Chatbot을 통해 Datalake 내의 S3 버킷에 대한 IAM role을 자동으로 업데이트합니다.
  • SageMaker Studio의 Project 환경을 구성하면서, 자동으로 MLOps의 파이프 라인을 구성하게 됩니다. 이 때 2가지 타입의 코드 저장소를 설정했습니다. 하나는 데이터 과학자들이 개발한 노트북과 학습 스크립트 코드이고, 다른 하나는 ML 엔지니어가 이후 단계에서 Endpoint 또는 batch inferences를 구성하는데 제공할 수 있는 configuration 저장소 입니다.
  • Project에 참여하는 팀원들 대상으로 Project의 Role을 업데이트합니다.

모델 개발:

데이터 준비와 모델 개발 단계는 반복적인 프로세스로 생각하면 됩니다. 경우에 따라 문제가 명확해지면서 추가 데이터를 활용해야 할 수도 있고, 문제가 명확하게 하기 위해 문제 정의 단계로도 갈 수 있습니다.

  • 데이터 과학자는 SageMaker Sutdio Notebook을 사용하고, SageMaker Processing를 이용하여 Amazon EMR 또는 Amazon Athena 등을 통해 다른 데이터 저장소에 접근하기도 하는데 워크플로우는SageMaker Pipelines을 이용합니다. 반복적인 실험에 대한 관리는 SageMaker Experiments에서 활용하며 모든 실험을 완료된 다음, Model Registry에 모델을 등록하게 됩니다. Model Registry에서는 모델을 버전별로 관리하면서 사용할 수 있습니다.
  • 또한, 데이터 과학자는 계속해서 학습 스크립트 등을 code 저장소에 push할 수 있습니다.

제어, 배포 및 모니터링

모델에 대한 리스크 정도를 수립하여, 모델에 따라 리스크를 low/medium/high/extremely high로 분류할 수 있도록 식별하였고, 모델 배포 시에 단계별로 제어들을 어떻게 할 것인지를 구성하였습니다.

  • 모델 책임자는 Chatbot을 통해 모델을 을 개발하는 다양한 관점에서 질문과 답변을 하게 됩니다. 이 질문은 모델 책임자가 모델의 리스크  분류를 결정하는데 도움을 줍니다. Chatbot은 이를 기반으로 리스크 분류를 자동으로 선택하고, 생성한 SageMaker Project, Model Registry 등에 Model의 리스크 분류 결과를 태그합니다. 질문에 대한 답변 결과는 향후 분석을 위해 S3에 저장합니다.
  • 또한, 코드를 검증하고 코드가 조직 내 보안 규정에 만족해야 했으며, 코드는 사람이 배포하기 보다는 CI/CD 파이프라인을 이용하여 자동으로 배포하는데, 코드의 보안 취약성, 코드의 품질 점검, 리스크 분류 별 제어 확인 후에 컨테이너를 생성하여 Amazon ECR (Elastic Container Registry)로 push 합니다.
  • 이후 모델 배포를 한 다음, 모델 모니터링을 설정하는데, 파이프라인의 일부로서 어떤 이상 상황, 데이터/feature drift, 모델 품질, bias를  감지할 수 있도록 모델의 모니터링을 구성합니다.

ML플랫폼의 향후 계획

  • Feature Store 개선과 Feature 관리를 위해 CI/CD 파이프라인을 확장할 계획입니다.
  • 그리고 모니터링에 대해 실시간 endpoint외에도 batch로 확장할 계획이며, endpoint의 모니터링에서 메모리/ CPU / GPU 사용량 관점으로 운영 영역을 고려할 계획입니다.

참조 링크

5. 카카오페이의 MLOps 적용 사례

카카오 페이는 개인신용평가, 이상거래탐지, 유저프로파일을 위한 ML 모델을 가지고 있습니다. 시간이 지남에 따라 결제 데이터가 증가하고 결제 양상이 다양해지면서 데이터 변화가 있게 되었고, 이런 상황은 모델의 성능에 영향을 주게 되었습니다. 이에 따라, 지속적인 모델 업데이트를 위해 MLOps의 도입이 필요하게 되었습니다.

MLOps아키텍처

  • 모델 학습의 workflow는 AWS Step Function을 활용하고 있으며, 모델 관리 서비스는 운영이 용이한  Amazon SageMaker Model Registry를 활용하고 있습니다.
  • 또한, feature store는 오픈 소스인 Feast를 활용하면서, Offline feature  store의 물리 저장소로는 Athena 와 S3를 사용하고 있으며, Online feature store는 Redis 와 함께, 카카오페이에서 자체 개발한 Athena Connector를 사용하고 있습니다.

MLOps의 적용 효과

카카오페이는 MLOps를 도입하여 기존 14주 걸린 모델 개발에 필요한 리소스를 7주로 50% 정도 절감할 수 있었습니다.

아키텍처를 포함하여 카카오 페이에서 진행하신 경험담을 자세히 알고자 하시는 분들은 참조 링크를 확인하시기 바랍니다. 해당 아키텍처는 AWS 팀과 긴밀하게 협력하여 고객의 상황에 맞게 구축한 것입니다. 컨퍼런스 발표와 관련해서는 AWS의 감수는 없었으며, AWS의 입장과 다를 수 있습니다.

참조 링크

6. GI VITA의 MLOps 구현 사례

GI VITA는 개인 생애 건강 관리 서비스를 제공하는 것을 목표로, 스마트 디바이스를 기반으로 사용자의 걸음 정보, 수면 정보, 체성분 정보 등의 라이프 로그를 실시간으로 수집하여,  사용자가 지속적으로 라이프 로그를 발생할 수 있도록, 경제적인 리워드를 제공하여 건강 습관을 형성하는 것을 지원하는 서비스를 제공합니다.

MLOps의 도입 배경

  • 개인 맞춤형 생활 습관을 제공해 줄 수 있는 AI 엔진을 생성했는데, 버전 관리, 모델 서빙, 자동화, 모니터링을 수행할 전문 인력이 부족합니다.
  • 이에 따라, AI 서비스 개발이나 고도화가 지연되고 있습니다.
  • 또한, 지속성이나 안정성 측면에서도 어려움이 있습니다.
  • 장애 대응을 위한 리소스가 제한적이고, 모니터링 기능도 부족합니다.

MLOps 아키텍처

  • Model Build Pipeline : SageMaker와 EventBridge를 기반으로 소스 코드 저장소인 github와 빌드 서버인 Jenkins를 이용해서 MLOps를 구현합니다.
  • Model Deploy Pipeline : 학습된 모델이 승인되고 나면 모델 deploy 단계가 자동으로 수행되도록 구축합니다.
  • Data Pipeline : 서비스 앱에서 수집되고 있는 정보가 S3에 저장이 될 수 있도록, Embulk를 통해 구축을 하였습니다.
  • 마지막으로 모델 서빙을 위해 API Gateway를 통해 서비스 단에서 모델의 예측 및 해석 정보를 받을 수 있도록 하였습니다. 추가적으로 생성된 Endpoint에 대해 CPU 사용량 정책을 설정해서 autoscaling 기능을 설정하여 안정적으로 모델 서빙이 가능하도록 구현하였습니다.

자세한 설명과 데모는 아래 참조 링크에서 확인이 가능하며, 상세 데모 설명 또한 확인할 수 있습니다.

참조 링크

결론

지금까지 국내외 다양한 기업들이 AWS에서 진행하고 있는 MLOps 프로젝트의 진행 사항을 소개해 드렸습니다. AWS와 협의 하에 공개된 MLOps 사용 사례 외에도 금융, 하이테크, 제조, 리테일 등의 다양한 산업 분야에서 AWS와 함께 MLOps를 구축하여 사용하고 있거나, 현재 구축 중에 있으며,이러한 사례들에서 얻은 공통적인 베스트 프랙티스 (Best Practice)들은 AWS백서, AWS Summit, AWS re:Invent 등을 통해 접할 수 있으며, 구축과 관련하여 PoC 또는 컨설팅이 필요한 경우 AWS 솔루션즈 아키텍트와의 미팅을 통해 다양한 지원을 받으시기 바랍니다.

Youngjoon Choi

Youngjoon Choi

최영준 Principal AI/ML Expert SA는 제조, 하이테크, 금융 등의 다양한 산업에서 엔터프라이즈 IT를 경험하면서 개발자로, 아키텍트로, 데이터 과학자로 다양한 활동을 하였습니다. 기계학습과 딥러닝 연구를 진행하였고, 구체적으로 Hyperparameter optimization과Domain adaptation등을 주제로 알고리즘 연구와 논문 발표를 진행하였습니다. AWS에서는 AI/ML를 전문 분야로 다양한 산업군에서 분산학습/초거대 모델 개발과 ML 파이프라인 구축 등에 대해 AWS 서비스를 이용한 기술 검증 지원, 아키텍처 제안 및 검토 등을 수행하고 있으며, AI/ML 생태계가 더욱 확장할 수 있도록 다양한 기여를 하고자 합니다.