[번역] MLOps 아키텍처 가이드

김태훈 2022년 04월 27일 #MLOps #Neptuen.ai

• 원본 기사>MLOps Architecture Guide

성공적인 머신러닝 프로젝트는 작동하는 앱을 배포하는 것만이 아닙니다. 긍정적인 비즈니스 가치를 제공하고 이를 지속적으로 유지하는 것입니다.

많은 머신 러닝 프로젝트를 수행하다 보면, 일부는 개발 중에는 잘 작동하지만 프로덕션에는 도달하지 못하는 것을 발견합니다. 다른 프로젝트는 프로덕션 단계에 있긴 하지만 사용자 요구에 맞게 확장이 안됩니다. 또 다른 프로젝트는 규모가 커진 후에는 너무 많은 비용이 들어서 수익을 창출하지 못합니다.

출처> 원본 기사

출처> 원본 기사

기존 소프트웨어에는 DevOps가 있고, 우리에게는 훨씬 더 중요한 MLOps가 있습니다. 프로젝트가 성공하려면 개발 및 프로덕션 워크로드에 적합한 최적의 MLOps 아키텍처가 필요합니다.

아래 이미지는 전체 MLOps 커뮤니티에서 가장 유명한 다이어그램일 수 있으며, 가장 많이 참조되는 ML 논문 중 하나에서 가져온 것입니다.

출처> https://dl.acm.org/doi/10.5555/2969442.2969519

출처> https://dl.acm.org/doi/10.5555/2969442.2969519

이 다이어그램은 프로덕션 레벨의 머신러닝 시스템에는 학습 알고리즘을 설계하고 코드를 작성하는 것 이상의 것이 있다는 것을 알려줍니다. 프로젝트에 가장 적합한 아키텍처를 선택하고 설계할 수 있다는 것은 종종 머신러닝 실험과 운영간의 차이를 메우는 것이며, 궁극적으로 ML 시스템의 숨겨진 기술적 부채를 갚는 것입니다.

이 기사에서는 다음을 배우게 됩니다:

이 기사 말미에는 비즈니스 문제가 주어지면 관련된 최적의 MLOps 아키텍처를 찾아내는 도전 과제도 제시합니다. 즐거운 시간을 보내시길 바라며, 바로 시작 하겠습니다!

프로덕션 레벨 머신러닝 시스템의 현실

머신러닝 프로젝트의 작업들을 생각해보면 다음과 같은 매우 상세한 워크플로우가 될 수 있습니다:

notion image

사실, 이와 같은 워크플로를 사용하여 이미 모델을 개발했으며 모델을 배포하고 성능 저하, 확장성, 속도, 유지 관리등과 같은 프로덕션 문제에 대해서만 대비하고자 할수도 있습니다.

실험과 개발을 넘어서 이후 과정을 고려하면 프로젝트를 철저히 처음부터 재검토를 해야 할 수도 있습니다. 즉, 솔루션을 현업에서 운영하기 위한 적절한 아키텍처를 선택하는 것부터 시작해야 합니다.

유명한 “Hidden Technical Debt in Machine Learning Systems” 논문에 나와 있듯이 일반적인 수준에서 머신 러닝 시스템을 운용하려면 복잡한 아키텍처가 필요합니다.

사용자에게 실시간으로 서비스를 제공하는 머신러닝 프로젝트의 경우 아키텍처는 어떤 모습이어야 한다고 생각하시나요? 무엇을 고려해야 할까요? 무엇을 설명해야 할까요?

아래는 프로젝트에 적합한 아키텍처를 찾을 때 볼 수 있는 복잡한 그림입니다 (복잡해 보이는 아키텍처이지만 지속적인 가치를 제공하는 프로덕션 등급 머신러닝 시스템을 구축하는 데 필요한 모든 것을 고려하지 않고 있습니다).

notion image

고려할 사항이 참 많네요! 보시다시피 시스템의 머신러닝(ML) 섹션과 시스템 운영(Ops) 섹션이 있습니다. 둘 다 함께 머신러닝 시스템의 아키텍처를 정의합니다.

MLOps의 일반적인 아키텍처 패턴에서 아키텍처 변경은 ML 단계와 Ops 단계에서 발생하며 문제와 데이터에 따라 다양한 개발 및 배포 패턴을 가질 수 있습니다. 다음 섹션에서는 ML 시스템의 일반적인 MLOps 아키텍처 패턴을 살펴보겠습니다.

일반적인 학습과 서빙 아키텍처 패턴

위의 머신러닝 시스템의 (상당히) 복잡한 표현에서 보았듯이 MLOps는 단순히 머신러닝과 운영이 혼합되어 인프라와 리소스 위에서 실행되는 것입니다.

MLOps의 아키텍처 패턴은 학습 및 서빙 설계에 관한 것입니다. 데이터 파이프라인 아키텍처는 종종 학습 및 서빙 아키텍처와 긴밀하게 결합됩니다.

머신러닝 개발/학습 아키텍처 패턴

학습 및 실험 단계에서 아키텍처 결정은 수신하는 입력 데이터와 문제 유형에 따라 결정되는 경우가 많습니다.

예를 들어, 프로덕션에서 입력 데이터가 자주 변경되는 경우 **동적 학습 아키텍처(dynamic training architecture)**를 고려할 수 있습니다. 입력 데이터가 거의 변경되지 않는 경우 **정적 학습 아키텍처(static training architecture)**를 고려할 수 있습니다.

동적 학습 아키텍처

이 경우 프로덕션에서 항상 변화하는 데이터 분포에 대해 모델을 재학습하여 모델을 지속적으로 업데이트합니다. 수신된 입력과 전반적인 문제 범위를 기반으로 하는 3가지 아키텍처가 있습니다.

1. 이벤트 기반 학습 아키텍처 (push-based)

notion image

데이터 웨어하우스로의 데이터 스트리밍와 같은 특정 이벤트로 다음과 같은 트리거 구성 요소가 켜지는 이벤트 기반 시나리오에 대한 학습 아키텍처:

스트림 분석 또는 온라인 서빙을 위해 IoT 장치의 실시간 데이터를 지속적으로 학습하도록 하려면 이 기능이 필요할 수 있습니다.

2. 오케스트레이션된 풀 기반 (pull-based) 학습 아키텍처

notion image

일정 간격으로 모델을 재학습해야 하는 시나리오에 대한 학습 아키텍처. 데이터는 웨어하우스에서 대기하고 있으며, 워크플로우 오케스트레이션 도구를 사용하여 추출 및 처리를 예약하고, 새로운 데이터에 대한 모델의 재학습을 실시합니다. 이 아키텍처는 특히 사용자가 계정에 로그인할 때 미리 계산된 추천 사항을 제공하는 콘텐츠 추천 엔진(노래 또는 기사용)과 같이 실시간 점수가 필요하지 않은 문제에 유용합니다.

3. 메시지 기반 (message-based) 학습 아키텍처

notion image

이러한 학습 아키텍처는 지속적인 모델 학습이 필요할 때 유용합니다. 예를 들어:

데이터 변환이 완료되고 데이터가 스토리지에 로드되면 메시지 브로커로 다시 메세지를 보내 데이터 스토리지에서 데이터를 로드하고 학습 작업을 시작하라는 메시지를 학습 파이프라인에 보냅니다.

기본적으로 데이터 서비스(데이터 파이프라인)와 학습 서비스(학습 파이프라인)를 단일 시스템으로 결합하여 각 작업에서 지속적으로 학습이 되도록 합니다. 예를 들어, 실시간 트랜잭션(부정 탐지 애플리케이션)에서 모델을 업데이트 하는 경우 이 학습 아키텍처가 필요할 수 있습니다.

또한 사용자가 학습 파이프라인 서비스로 요청을 전송하여 사용 가능한 데이터에 대한 학습을 시작하고 모델 데이터(학습 보고서)를 작성하는 사용자 트리거 (user-triggered) 학습 아키텍처로 사용할 수도 있습니다.

정적 학습 아키텍처

데이터 분포가 오프라인에서 훈련된 것과 크게 다르지 않은 문제에 대해 이 아키텍처를 고려하십시오. 이와 같은 문제의 예로 대출 승인 시스템을 들 수 있습니다. 대출 승인 또는 거부 여부를 결정하는 데 필요한 속성이 점진적인 분포 변경을 거치고 팬데믹과 같은 드문 경우에만 갑작스러운 변경이 발생합니다.

다음은 정적 학습을 위한 레퍼런스 아키텍처입니다. 한 번 학습하고 가끔씩 재학습합니다.

notion image

서빙 아키텍처

서빙 아키텍처는 매우 다양합니다. 프로덕션 환경에서 모델을 성공적으로 운영하려면 단순히 서비스를 제공하는 것 이상입니다. 또한 프로덕션 환경에서 모니터링, 통제(governing) 및 관리해야 합니다. 서빙 아키텍처는 다를 수 있지만 항상 이러한 측면을 고려해야 합니다.

서빙 아키텍처는 비즈니스 컨텍스트와 요구 사항에 따라 선택해야 합니다.

일반적인 운영 아키텍처 패턴

배치 아키텍처 패턴

이것은 프로덕션에서 검증된 모델을 제공하는 데 사용할 수 있는 가장 간단한 아키텍처입니다. 기본적으로 모델은 오프라인에서 추론을 수행하고 주문형(on-demand) 서비스를 제공할 수 있는 데이터 저장소에 결과를 저장합니다.

notion image

요구 사항에 몇 초 또는 몇 분 안에 클라이언트에게 추론 결과를 제공하지 않아도 되면 이러한 종류의 서빙 패턴을 사용할 수 있습니다. 일반적인 사용 사례는 콘텐츠 추천 시스템(사용자가 계정에 로그인하거나 애플리케이션을 열기 전에 추천을 미리 계산함)입니다.

온라인/실시간 아키텍처 패턴

notion image

매우 최소한의 지연(몇 초 또는 몇 분 이내)으로 사용자에게 모델 추론 결과를 제공해야 하는 시나리오가 있습니다. 사용자가 요청할 때 실시간 추론을 제공하기 위한 온라인 서빙 아키텍처를 고려할 수 있습니다.

이 패턴에 맞는 사용 사례의 예는 거래가 완전한 처리를 거치기 전에 사기를 감지하는 것입니다.

다음과 같은 서빙 아키텍처를 살펴보는 것도 시간을 할애할만한 가치가 있습니다:

일반적인 MLOps 아키텍처 패턴을 보았으므로 이제 구현해 보겠습니다!

프로젝트에 “최적의” MLOps 아키텍처를 선택하는 방법

다른 제품이나 솔루션과 마찬가지로, 설계할 때 적절한 설계를 고안하는 것은 문제에 따라 매우 다릅니다. 유사한 문제가 아키텍처에 약간의 차이만 있을 수 있다는 것을 종종 발견할 수 있습니다. 그래서 “최고”는 매우 주관적일 수 있다는 것을 저는 이 기사에서 분명히 말하고 싶습니다. 제가 “최고의” 아키텍처라고 정의하는 것은 다음과 같습니다:

또한 MLOps 성숙도 수준에 따라 이들 중 일부가 적용되거나 적용되지 않을 수 있으므로 아키텍처 선택에 있어 훨씬 더 많은 주관성을 갖게 될 것입니다. 그럼에도 불구하고, 저는 시스템 운영 비용과 MLOps 성숙도를 감안하여 프로젝트에 대한 자세한 내용을 설명하려고 했습니다.

일관성을 유지하기 위해 프로젝트 활용 사례는 MLOps의 네 가지 요소를 고려합니다.

  1. 프로덕션 모델 배포

  2. 프로덕션 모델 모니터링

  3. 프로덕션 환경에서의 모델 거버넌스

  4. 모델 라이프사이클 관리(재학습, 리모델링, 자동화된 파이프라인)

이러한 아키텍처에 대해 생각하는 방법을 보여드리기 위해 다음과 같은 템플릿을 사용합니다:

AWS Well-Architected Framework (Machine Learning Lens)의 우수한 설계 원칙 적용

AWS에서 개발한 Well-Architected 솔루션의 5대 요소를 채택합니다. 우수한 설계 원칙 및 모범 사례의 표준 프레임워크를 사용하여 최적의 비즈니스 가치를 가진 솔루션을 구축하는 데 도움이 됩니다:

  1. 운영 효율성: 비즈니스 가치를 제공하고 지원 프로세스 및 절차를 지속적으로 개선하기 위해 프로덕션에서 모델을 운영하고, 모니터링하고, ML 시스템에 대한 통찰력을 얻는 기능에 중점을 둡니다.

  2. 보안: 리스크 평가 및 완화 전략을 통해 비즈니스 가치를 제공하는 동시에 정보, 시스템 및 자산(데이터)을 보호하는 기능에 초점을 맞춥니다.

  3. 신뢰성: 인프라 또는 서비스 중단으로부터 복구하고, 수요를 충족하기 위해 컴퓨팅 리소스를 동적으로 확보하며, 잘못된 구성 또는 일시적인 네트워크 문제와 같은 운영 중단을 완화하는 시스템의 기능에 초점을 맞춥니다.

  4. 성능 효율성: 요구사항을 충족하기 위해 컴퓨팅 리소스를 효율적으로 사용하고 수요 변화와 기술의 발전에 따라 효율성을 유지하는 방법에 초점을 맞춥니다.

  5. 비용 최적화: 비즈니스의 투자 수익률을 극대화하기 위해 비즈니스 성과를 달성하고 비용을 최소화하는 비용 인식(cost-aware) ML 시스템을 구축 및 운영할 수 있는 기능에 초점을 맞춥니다.

머신러닝을 위한 Well-Architected Framework 아키텍처 설계 원칙 요약

아키텍처를 계획할 때 유의해야 할 5가지 주요 설계 원칙을 바탕으로 요약 표를 작성했습니다.
Well-Architected 기준ML 시스템의 설계 원칙
운영 효율성- 교차 기능(cross-functional) 팀을 구성합니다. - ML 워크플로 초기에 종단간 아키텍처 및 운영 모델을 식별합니다. – ML 워크로드를 지속적으로 모니터링하고 측정합니다. – 모델 재학습 전략 수립: 자동화? 인간의 개입? - 머신러닝 입력 및 아티팩트의 버전을 지정합니다. - 머신러닝 배포 파이프라인을 자동화합니다.
보안– ML 시스템에 대한 액세스를 제한합니다. – 데이터 거버넌스를 보장합니다. – 데이터 계보를 적용합니다. – 규정 준수를 시행합니다.
신뢰성– 자동화를 통해 모델 입력에 대한 변경 사항을 관리합니다. – 한 번 학습하고 여러 환경에 배포합니다.
성능 효율성– ML 워크로드에 맞게 컴퓨팅을 최적화합니다. – 모델의 지연 시간 및 네트워크 대역폭 성능 요구사항을 정의합니다. – 시스템 성능을 지속적으로 모니터링하고 측정합니다.
비용 최적화– 관리형 서비스를 사용하여 소유 비용을 절감합니다. – 작은 데이터 세트로 실험합니다. – 적절한 규모의 학습 및 모델 호스팅 인스턴스.

정의된 프로젝트에 대한 최적의 MLOps 아키텍처

우리는 각 프로젝트에 대한 아키텍처를 선택하는 과정을 통해 생각해 볼만한 아래와 같은 프로젝트를 선정했습니다. 시작해 보겠습니다.

프로젝트: 뉴스 기사 추천 시스템

notion image

컨텐츠 추천 시스템은 사용자가 플랫폼에 더 많은 비용을 지출하도록 기업이 관련 컨텐츠에 계속 관여할 수 있도록 도움을 줍니다. 특히 항상 고객 참여를 높이는 것이 목표였던 미디어에서는 더욱 그렇습니다.

시나리오

뉴스 기사 추천 회사인 우리 회사의 비즈니스 분석가는 최근 고객 이탈이 많다는 것을 깨달았습니다. 상황을 분석한 결과, 사용자가 플랫폼에 참여하지 않는다고 느껴 구독을 유지하지 않거나 다른 미디어 플랫폼으로 넘어간다는 결론을 내렸습니다. 우리는 비즈니스 분석 팀 및 일부 충성 고객과 긴밀히 협력했으며, 사용자를 위해 플랫폼을 개인화할 수 있을 때까지 사용자가 이탈하거나 더 심하게는 완전히 이탈하는 것이 지속된다는 사실을 알게 되었습니다.

이를 위한 첫 번째 단계는 독자가 로그인할 때 읽고 이메일로 보낼 가능성이 높은 뉴스 기사를 추천하는 기존 제품과 통합되는 기능을 구축하는 것입니다.

경영진은 범위를 늘리기 전에 시스템을 구축하고 선택된 수의 사용자를 대상으로 테스트해야 한다는 조건에 동의합니다.

…그렇게 여기까지 왔습니다. 이제 무엇을 할까요? 자, 아키텍처링을 시작하겠습니다!

문제 분석

비즈니스 이해

사업 목표는 무엇입니까? 구독자가 계속 서비스를 구독할 수 있도록 주어진 로그인 세션에 대해 가장 관련성이 높은 기사를 추천하여 구독자의 참여를 개선합니다.

비즈니스 지표는 무엇입니까? 사용자가 기사에 소비하는 시간(분)의 증가입니다. 클릭수보다 이 매트릭을 사용한 이유는 사용자가 기사를 클릭하는지 여부에 영향을 줄 수 있는 많은 외부 요인이 있기 때문입니다. 헤드라인에서 표지 사진 또는 하위 헤드라인, UI 디자인 등.

프로젝트의 범위는 무엇입니까?

기술적 고려사항

데이터 이해

요구사항 고려

시스템 요구 사항을 고려할 때 다음과 같은 몇 가지 사항을 이해해야 합니다:

프로젝트에 대한 요구 사항을 마련하기 위해 Voleere의 요구 사항 스펙 템플릿을 필요에 맞게 조정할 수 있습니다. 저는 Michael Perlin이 만든 Github의 이 체크리스트의 질문을 요구 사항으로 사용했습니다.

요구 사항: 이 서비스는 모바일 애플리케이션이나 웹사이트 홈페이지를 통해 로그인 세션에 대한 관심도에 따라 사용자가 읽을 수 있는 상위 10개의 기사를 추천해야 합니다.

이제 ML 시스템의 각 구성 요소에 대한 요구사항 스펙를 자세히 살펴보겠습니다.

데이터 수집 및 기능 관리 스펙

실험 관리 및 모델 개발 스펙

프로덕션 모델 관리 스펙

  1. 배포 및 서빙 스펙
  1. 모델 모니터링 스펙
  1. 모델 관리 스펙
  1. 모델 거버넌스 스펙

시스템 운영 (Ops) 스펙

시스템 구조 정의

위에 나열된 목표, 요구사항 및 스펙을 기반으로 시스템에 대한 아래 구조를 만들 수 있습니다. 도구 또는 구현에 대한 언급이 전혀 없다는 것을 알 수 있습니다. 그렇습니다! 이것은 비즈니스 목표와 최종 사용자를 염두에 둔 시스템 설계에 관한 것입니다. 아키텍처를 설계할 때는 가능한 한 기술에 구애받지 않고 요구사항과 스펙에만 집중해야 합니다.

notion image

시스템의 구조는 비즈니스 목표에 기반한 요구사항과 스펙을 기반으로 합니다. 시스템 구조를 제대로 잡을 수 있게 되면, 이제 구현할 도구와 기술을 선택할 수 있습니다.

구성 요소 기반(component-based) 아키텍처라고도 하는 위와 같은 아키텍처 다이어그램 외에도 다이어그램의 각 섹션을 더 깊이 파고들어 중요한 것을 놓치지 않도록 않도록 해야 합니다. 또한 다음과 같은 다른 다이어그램도 고려해 보세요:

짐작하셨겠지만, 이 아키텍처는 MLOps 성숙도 레벨 1에 있습니다.

그나저나, 이 구조는 여러분이 해결하려는 ML 문제와 전혀 무관합니다. 즉, 컴퓨터 비전 프로젝트를 수행하든 자연어 처리 작업을 수행하든 상관 없이 작동할 수 있음을 의미합니다. 여기에는 명백히 명시되어 있지만 일부 데이터 관리 스펙이 변경될 수도 있습니다.

구현 결정

구현 결정시 고려 사항

MLOps는 여전히 매우 초기 단계이기 때문에 앞서 언급드린것 처럼 효율적인 ML 시스템을 구축하려면 템플릿화된 모범 사례를 따르고 견고한 도구를 사용해야 합니다(오리지날 아이디어에 대해 Raghav Ramesh의 공로). 즉, 요구 사항 및 스펙에 따라 구조의 다양한 구성 요소를 구현하는 데 사용할 도구를 결정하는 동안 신중하게 결정해야 합니다.

현재로서는 구현하려는 구성 요소에 대해 충분히 견고한 도구를 찾는 것이 좋습니다. 수평 스택(데이터, 실험 및 모델 관리)을 포괄하고 기존 에코시스템과 통합이 용이하고 다른 환경 간에 쉽게 마이그레이션할 수 있는 단일 플랫폼이 바람직합니다. 고맙게도 MLOps 커뮤니티는 훌륭하며 이 웹사이트에서 MLOps용으로 선별된 전체 도구 목록을 찾을 수 있습니다.

MLOps 아키텍처를 구현하기 위한 도구(또는 “장난감” 😉)을 결정할 때 다음 사항을 고려해야 합니다:

기본적으로 구현을 결정할 때 범위, 요구 사항, 위험 및 제약 조건(예: 비용, 이해관계자 회의론 등)을 기반으로 프로젝트에 가장 적합한 것을 선택하려고 합니다.

프로젝트로 돌아가서, 이 프로젝트는 다양한 견고한 도구를 사용하여 구성요소를 구현합니다. 현재 예산 제약과 프로젝트 범위 때문에 오픈 소스 솔루션도 고려해 보겠습니다. 인프라 고려사항에서 좀 더 발전해 나가겠습니다.

인프라 도구

주의: 머신러닝에 k8s(Kubernetes)를 사용한다는 Kubeflow를 알고 있지만 지금은 모르는 척 합시다. 결국, 이것이 아키텍처의 최종 형태는 아니겠죠? 우리는 확실한 교훈을 얻고 나중에 아키텍처를 다시 볼 것입니다!

데이터 수집 및 피처 관리 도구

실험 관리 및 모델 개발 도구

더보기

👉 기사 읽기: ML 실험 추적: 정의, 중요한 이유 및 구현 방법

👉 Neptune의 문서 살펴보기

프로덕션 모델 관리

1. 배포와 서빙 도구

2. 모니터링 도구

3. 모델 관리 도구

4. 모델 거버넌스 도구

구현 선택은 여기까지입니다. 이 솔루션은 시스템 구조를 기반으로 구축되었으며 계획 단계에서 정의한 요구사항과 범위에 부합한다는 것을 알 수 있습니다. 이제 앞에서 살펴본 AWS Well-Architected Framework(머신 러닝 렌즈)를 사용해 보겠습니다.

Well-Architected Framework에 따른 아키텍처 검토

운영 효율성

보안

신뢰성

성능 효율성

비용 최적화

도전 과제

도입부에서 도전 과제를 드린다고 했었습니다. 자, 여기 있습니다:

익일 주문 처리를 보장하는 비즈니스를 위해 주문 관리 서비스와 통합해야 하는 사기 탐지 시스템을 어떻게 구축하시겠습니까?

원하는 대로 비즈니스를 자유롭게 정의할 수 있지만 이전 프로젝트보다 더 큰 범위를 생각하고 싶을 수도 있습니다.

이 과제를 해결하려면 이 기사 끝에 있는 “프로젝트에 가장 적합한 MLOps 아키텍처를 선택하기 위한 리소스” 섹션에서 제시한 아키텍처를 참조하십시오. 행운을 빕니다!

이제 여러분의 차례입니다. 프로젝트에 가장 적합한 MLOps 아키텍처를 어떻게 선택해야 할까요?

프로젝트에 가장 적합한 아키텍처를 선택하려면 다음을 수행하는 것이 좋습니다:

  1. 프로젝트에 필요한 요구사항, 범위 및 제약조건을 명확하게 이해하고 명확하게 설명하십시오. 시작하는 데 도움이 되는 Michael Perlin의 3부작 비디오 시리즈가 있습니다. 다른 리소스는 참고문헌 및 리소스 섹션에서 찾을 수 있습니다. 요구 사항에는 비즈니스 목표와 좋은 사용자 경험을 구성하는 요소가 명확하게 명시되어 있어야 합니다.

  2. 요구 사항에 따라 시스템 구조를 설계하고 이 시점에는 시스템 구조에 맞는 구현이나 기술을 생각하지 마십시오. 주요 목표는 이전 단계의 요구 사항에 따라 시스템 구조를 정의하는 것입니다. 저는 다른 사람들이 이 시점에서 어떤 일을 해왔는지, 어떤 일을 하고 있는지 자신의 시스템 구조/아키텍처 측면에서 살펴보는 것을 추천합니다. (이 문서의 끝부분에 있는 리소스 섹션에서 배울 수 있는 아키텍처 센터에 링크했습니다.)

  3. 이제 구현을 결정할 때입니다! 도구와 기술을 선택할 때 사용할 ML 파이프라인의 모든 단계에 대해 충분히 견고한지 확인하십시오. 모니터링 도구인 경우 확장 가능하고 필요한 모든 기능이 있는지 확인하십시오.

  4. 마지막으로, AWS의Machine Learning Well-Architected Framework설계 원칙과 모범 사례 또는 다른 좋은 템플릿을 사용하여 아키텍처 타당성을 보여주십시오.

아키텍처는 기반만 형성하고 ML 시스템이 구축되어야 하는 방법에 대한 경로를 제공합니다. 구현 상자에 갇혀서는 안 되며, ML 시스템을 반복적으로 구축할 때 수정할 수 있다는 점을 이해해야 합니다.

이것이 애자일 ML 소프트웨어 구축이 필요한 이유입니다. 따라서 문제를 신속하게 발견하거나 구현을 지원하고 필요한 기간 동안 가장 최적의 ML 시스템을 제공하는 데 도움이 될 수 있는 더 나은 도구 또는 플랫폼을 확인할 수 있습니다.

유용할 수 있는 몇 가지 팁…

  1. 확립된 모범 사례 준수 + 견고한 도구 및 구현 + 최적의 솔루션을 반복적으로 구축하기 위해 최대한 빨리 MVP를 공개합니다.

  2. 머신러닝 프로젝트 라이프사이클 초기에 MLOps 아키텍처를 고려하고 계획해야 합니다. 이렇게 하면 활동을 조정하고 개발 및 운영의 사각지대를 찾을 수 있습니다.

  3. 다른 사람들에게 아키텍처를 “볶을(roast)” 기회를 주십시오. MLOps 커뮤니티 슬랙 채널에서 자주 발생하는 일은 다른 사람들이 아키텍처의 공개 버전을 업로드하여 다른 사람들이 이를 비판하고 유용한 피드백을 제공할 수 있는 기회를 제공하는 것입니다. 그러한 커뮤니티에 가입하고 다른 실무자들과 상호 작용하고 시스템이 어떤 모습이어야 한다고 생각하는지 디자인할 수 있습니다. 필요한 요구사항과 함께 공개 버전을 공유하여 다른 실무자가 이를 비판할 수 있도록 합니다.

  4. 또한 멀티 클라우드 또는 멀티 플랫폼 솔루션이 포함된 하이브리드 ML 시스템과 임베디드 시스템 MLOps 아키텍처에 대해서도 살펴볼 수 있습니다. 한 플랫폼에서 모델을 학습하고 다른 플랫폼(온프레미스, 다른 클라우드 벤더 또는 마이크로컨트롤러/엣지 장치)에서 모델을 서빙해야 하는 경우입니다.

결론

이 기사에서 다음을 배웠습니다:

notion image

읽어주셔서 감사합니다!

프로젝트에 가장 적합한 MLOps 아키텍처를 선택하기 위한 리소스

  1. 데이터 과학에 대한 비즈니스 요구 사항 분석에 대해 자세히 알아보려면 Pluralsight에서 이 과정을 확인하십시오.

  2. 아키텍처 템플릿은 다음에서 확인하십시오:

  1. MLOps 구현을 위한 강력한 도구 선택에 대해 생각하고 계십니까? Neptune.ai의 블로그에서 이 카테고리의 기사를 확인하세요.

  2. 실제 구현을 보고 싶으신가요? 다음에서 확인하세요:

  3. LinkedIn 학습에서 Kumaran Ponnambalam의 “빅 데이터 응용 프로그램 설계: 실시간 응용 프로그램 엔지니어링” 및 “빅 데이터 응용 프로그램 설계: 배치 모드 응용 프로그램 엔지니어링“에 대한 과정을 들을 수 있습니다.

  4. 다시 말하지만, ML 시스템을 더 잘 설계할 수 있는 또 다른 방법은 다른 사람들이 무엇을 하는지 보는 것입니다. Quora, Uber, Netflix, DoorDash, Spotify 또는 잘 알려지지 않은 다른 회사들이 어떻게 그들만의 시스템을 설계하고 있는지에 대한 웹 세미나 및 블로그 게시물이 몇 개 있습니다. 다음에서 확인하세요:

  5. Youtube의 MLconf 좋은 세션 영상

  6. Databricks Youtube 영상

  7. 최근 8개 기업이 어떻게 MLOps를 구현하고 있는지에 대한 기사를 작성했는데, 여기에서 확인하실 수 있습니다.

  8. 유용하다고 생각되는 ML 플랫폼을 처음부터 구축하는 방법에 대한 최근 릴리스입니다.

  9. 모든 타사 도구에서 자신과 팀을 추상화하고 각 구성 요소에 대해 별도의 도구를 사용하려는 경우, 몇 가지 우수한 MLOps 플랫폼을 사용하는 것을 고려하십시오: 머신러닝 라이프사이클을 관리하는 최적의 MLOps 플랫폼

  10. 주어진 과제에 대한 저의 해결책.

참고문헌

저자Stephen Oladele, 번역 김태훈

목록
프로덕션 레벨 머신러닝 시스템의 현실
일반적인 학습과 서빙 아키텍처 패턴
머신러닝 개발/학습 아키텍처 패턴
동적 학습 아키텍처
정적 학습 아키텍처
서빙 아키텍처
일반적인 운영 아키텍처 패턴
프로젝트에 “최적의” MLOps 아키텍처를 선택하는 방법
AWS Well-Architected Framework (Machine Learning Lens)의 우수한 설계 원칙 적용
머신러닝을 위한 Well-Architected Framework 아키텍처 설계 원칙 요약
정의된 프로젝트에 대한 최적의 MLOps 아키텍처
문제 분석
요구사항 고려
시스템 구조 정의
구현 결정
Well-Architected Framework에 따른 아키텍처 검토
도전 과제
이제 여러분의 차례입니다. 프로젝트에 가장 적합한 MLOps 아키텍처를 어떻게 선택해야 할까요?
결론
프로젝트에 가장 적합한 MLOps 아키텍처를 선택하기 위한 리소스
참고문헌