엔터프라이즈 비즈니스가 조직 전체에서 머신 러닝(ML)을 수용함에 따라 ML 모델을 구축, 교육 및 배포하기 위한 수동 워크플로가 혁신의 병목 현상이 되는 경향이 있습니다. 이를 극복하기 위해 기업은 데이터 과학자, 데이터 엔지니어, ML 엔지니어, IT 및 비즈니스 이해 관계자와 같은 여러 인물이 협력하고 상호 작용해야 하는 방법을 정의하는 명확한 운영 모델을 형성해야 합니다. 관심사, 책임 및 기술을 분리하는 방법; AWS 서비스를 최적으로 사용하는 방법. ML과 운영(MLOps)의 이러한 조합은 기업이 종단 간 ML 수명 주기를 간소화하고 데이터 과학자의 생산성을 높이는 동시에 높은 모델 정확도를 유지하고 보안 및 규정 준수를 강화하는 데 도움이 됩니다.
이 게시물에서는 MLOps 기반 구축의 주요 단계, 이 기반에서 여러 페르소나가 함께 작동하는 방법 및 아마존 세이지 메이커 엔터프라이즈 비즈니스 전반에 걸쳐 ML 채택을 가속화할 수 있는 다른 AWS 서비스와의 특수 목적 도구 및 기본 제공 통합.
MLOps 성숙도 모델
기업 고객의 운영, 인력 및 기술 요구 사항을 포괄할 수 있는 MLOps 기반을 구축하는 것은 어려운 일입니다. 따라서 우리는 XNUMX가지 주요 단계에서 MLOps의 필수 기능을 정의하는 다음과 같은 성숙도 모델을 정의합니다.
- 초기 단계: 이 단계에서 데이터 과학자는 SageMaker 서비스를 사용하여 AWS에서 모델을 실험하고 구축, 교육 및 배포할 수 있습니다. 제안하는 개발 환경은 아마존 세이지 메이커 스튜디오, 데이터 과학자는 Studio 노트북을 기반으로 실험하고 협업할 수 있습니다.
- 반복 가능한 단계 – AWS에서 실험할 수 있는 다음 단계는 데이터를 사전 처리하고 모델(ML 파이프라인)을 구축 및 교육하는 자동 워크플로를 생성하는 것입니다. 데이터 과학자는 별도의 환경에서 ML 엔지니어와 협력하여 Amazon SageMaker 파이프 라인. 생성된 모델은 Amazon SageMaker 모델 레지스트리에 저장되고 벤치마킹됩니다.
- 신뢰할 수 있는 단계 – 모델이 ML 파이프라인을 통해 생성된 경우에도 프로덕션으로 승격되기 전에 테스트해야 합니다. 따라서 이 단계에서는 프로덕션을 시뮬레이션하는 격리된 스테이징(사전 프로덕션) 환경에서 모델 및 트리거링 인프라 모두에 대해 자동 테스트 방법론이 도입됩니다. 테스트를 성공적으로 실행한 후 모델은 프로덕션의 격리된 환경에 배포됩니다. 여러 환경에서 모델을 승격하려면 수동 평가 및 승인이 필요합니다.
- 확장 가능한 단계 – 첫 번째 ML 솔루션을 생산한 후 수십 또는 수백 개의 ML 사용 사례를 협업하고 생산하기 위해 여러 데이터 과학 팀을 지원하기 위해 MLOps 기반을 확장해야 합니다. 이 단계에서는 새로운 프로덕션 솔루션의 개발 시간을 몇 주에서 며칠로 단축하여 가치를 실현하는 솔루션의 템플릿화를 도입합니다. 또한 보안 MLOps 환경의 인스턴스화를 자동화하여 여러 팀이 IT에 대한 종속성과 오버헤드를 줄이는 데이터 작업을 수행할 수 있도록 합니다.
다음 섹션에서는 이전 성숙도 모델과 다음 신조를 기반으로 MLOps 기반을 구축하는 방법을 보여줍니다.
- 유연성 – 데이터 과학자는 모든 프레임워크(예: TensorFlow 또는 PyTorch)를 수용할 수 있습니다.
- 재현성 – 데이터 과학자는 과거 실험(코드, 데이터 및 결과)을 재현하거나 관찰할 수 있습니다.
- 재사용 성 – 데이터 과학자와 ML 엔지니어는 소스 코드와 ML 파이프라인을 재사용하여 불일치와 비용을 피할 수 있습니다.
- 확장성 – 데이터 과학자 및 ML 엔지니어는 필요에 따라 리소스와 서비스를 확장할 수 있습니다.
- 감사 성 – 데이터 과학자, IT 및 법무 부서는 아티팩트 및 데이터의 로그, 버전 및 종속성을 감사할 수 있습니다.
- 일관성 – MLOps는 여러 환경으로 구성되기 때문에 기반은 환경 간의 편차를 제거해야 합니다.
초기 단계
초기 단계에서 목표는 데이터 과학자가 SageMaker 노트북을 사용하여 ML이 특정 비즈니스 문제를 해결할 수 있음을 증명하는 데이터 및 실험의 스냅샷을 수신하는 안전한 실험 환경을 만드는 것입니다. 이를 위해서는 VPC 엔드포인트를 통해 서비스에 맞춤형으로 액세스할 수 있는 Studio 환경이 권장됩니다. 참조 아키텍처의 소스 코드는 SageMaker 팀에서 제공한 예제에서 사용할 수 있습니다. Amazon SageMaker Studio 참조 아키텍처를 통한 보안 데이터 과학 GitHub 레포.
SageMaker 서비스 외에도 데이터 과학자는 다음과 같은 다른 서비스를 사용하여 데이터를 처리할 수 있습니다. 아마존 EMR, 아마존 아테나및 AWS 접착제, 노트북이 에 저장되고 버전 관리됨 AWS 코드 커밋 리포지토리(다음 그림 참조).
반복 가능한 단계
데이터 과학자가 ML이 비즈니스 문제를 해결할 수 있음을 입증하고 SageMaker 실험, 교육 및 모델 배포에 익숙해지면 다음 단계는 ML 솔루션 생산을 시작하는 것입니다. 다음 그림은 이 아키텍처를 보여줍니다.
이 단계에서 관심의 분리가 필요합니다. 환경을 여러 AWS 계정으로 분할합니다.
- 데이터 레이크 – 온프레미스(또는 기타 시스템)에서 수집된 모든 데이터를 클라우드에 저장합니다. 데이터 엔지니어는 여러 데이터 소스를 결합하는 ETL(추출, 변환 및 로드) 파이프라인을 생성하고 ML 사용 사례에 필요한 데이터 세트를 준비할 수 있습니다. 데이터는 AWS Glue 데이터 카탈로그를 통해 분류되고 다음을 통해 다른 사용자 및 계정과 공유됩니다. AWS Lake 형성 (데이터 거버넌스 계층). 같은 계정에서 Amazon SageMaker 기능 스토어 호스팅할 수 있지만 이 게시물에서는 다루지 않습니다. 자세한 내용은 다음을 참조하십시오. Amazon SageMaker Feature Store를 사용하여 계정 및 팀간에 기능 재사용 활성화.
- 실험 – 데이터 과학자가 연구를 수행할 수 있습니다. 유일한 차이점은 데이터 스냅샷의 출처가 데이터 레이크라는 점입니다. 데이터 과학자는 특정 데이터 세트에만 액세스할 수 있으며 GDPR 또는 기타 데이터 개인 정보 보호 제약이 있는 경우 익명화될 수 있습니다. 또한 실험 계정은 데이터 과학자가 새로운 데이터 과학 프레임워크 또는 타사 오픈 소스 라이브러리를 사용할 수 있도록 인터넷에 액세스할 수 있습니다. 따라서 실험 계정은 비프로덕션 환경의 일부로 간주됩니다.
- 개발(dev) – 프로덕션 환경의 첫 번째 단계. 데이터 과학자는 노트북에서 자동 워크플로 및 SageMaker 파이프라인의 세계로 이동합니다. 그들은 코드를 추상화하고 테스트, 오류 처리 및 코드 품질을 보장하기 위해 ML 엔지니어와 협력해야 합니다. 목표는 모델을 사전 처리, 훈련, 평가 및 SageMaker 모델 레지스트리에 등록하는 자동 워크플로인 ML 파이프라인을 개발하는 것입니다. ML 파이프라인의 배포는 CI/CD 파이프라인을 통해서만 이루어지며 AWS 관리 콘솔 제한됩니다. ML 파이프라인이 데이터 레이크의 프로덕션 데이터에 액세스할 수 있으므로(읽기 전용) 인터넷 연결이 허용되지 않습니다.
- 툴링(또는 자동화) – CodeCommit 리포지토리를 호스팅합니다. AWS 코드 파이프라인 CI/CD 파이프라인, SageMaker 모델 레지스트리 및 사용자 지정 컨테이너를 호스팅하는 Amazon ECR. 데이터 레이크는 데이터에 대한 단일 정보이므로 도구 계정은 코드, 컨테이너 및 생성된 아티팩트에 대한 것입니다.
이 계정 명명 규칙과 다중 계정 전략은 비즈니스 요구 사항에 따라 다를 수 있지만 이 구조는 권장되는 격리 수준을 보여주기 위한 것입니다. 예를 들어 개발 계정의 이름을 모델 학습 또는 빌드 계정으로 변경할 수 있습니다.
자동 배포를 수행하려면 노트북에서 ML 파이프라인으로 이동하고 코드 리포지토리와 데이터 구조를 표준화하는 방법을 이해하는 것이 중요합니다. 이에 대해서는 다음 섹션에서 설명합니다.
노트북에서 ML 파이프라인으로
개발 환경의 목표는 노트북의 코드를 재구성, 확장, 개선 및 확장하고 이를 ML 파이프라인으로 이동하는 것입니다. ML 파이프라인은 데이터 전처리, 모델 학습 또는 사용, 결과 후처리를 담당하는 일련의 단계입니다. 각 단계는 정확히 하나의 작업(특정 변환)을 수행하고 재사용이 가능하도록 충분히 추상화되어야 합니다(예: 열 이름을 입력 매개변수로 전달). 다음 다이어그램은 예시 파이프라인을 보여줍니다.
ML 파이프라인을 구현하기 위해 데이터 과학자(또는 ML 엔지니어)는 SageMaker Pipelines를 사용합니다. SageMaker 파이프라인은 Python SDK를 사용하는 JSON 파이프라인 정의에 의해 정의되는 일련의 상호 연결된 단계(SageMaker 처리 작업, 교육, HPO)입니다. 이 파이프라인 정의는 DAG(방향성 비순환 그래프)를 사용하여 파이프라인을 인코딩합니다. 이 DAG는 ML 파이프라인의 각 단계에 대한 요구 사항 및 관계에 대한 정보를 제공합니다.
사용 사례에 따라 ML 파이프라인을 학습 및 배치 추론의 두 가지 주요 유형으로 분리할 수 있습니다.
다음 그림은 학습 ML 파이프라인 흐름을 보여줍니다.
전처리 단계는 여러 단계로 구성될 수 있습니다. 일반적인 데이터 과학 변환에는 데이터 분할 및 샘플링(트레인, 유효성 검사, 테스트 세트), 원-핫 인코딩 또는 벡터화, 비닝 및 스케일링이 있습니다. 모델 교육 단계는 데이터 과학자가 최상의 모델 구성을 알고 있는 경우 하나의 교육 작업이거나 AWS가 모델에 대한 최상의 하이퍼파라미터를 정의하고(베이지안 방법) 해당하는 모델을 생성하는 HPO(초매개변수 최적화) 작업일 수 있습니다. 모델 아티팩트. 평가 단계에서는 생성된 모델 아티팩트를 사용하여 검증 데이터 세트에 대한 추론을 수행합니다. 그런 다음 ML 파이프라인은 생성된 정확도 메트릭(예: F1, 정밀도 및 이득 십분위수)이 필요한 임계값을 통과하는지 확인합니다. 이 단계가 성공하면 모델 아티팩트와 메타데이터가 프로덕션화를 위해 모델 레지스트리로 이동됩니다. 내보내기 기준 단계는 Amazon SageMaker 모델 모니터 나중에 모델 드리프트 감지에 사용되며 SageMaker 모델 레지스트리에서 모델 메타데이터로 호스팅될 수 있는 통계로 JSON 개체를 생성합니다.
배치 추론의 경우 데이터 과학자는 다음 그림과 같이 유사한 파이프라인을 생성할 수 있습니다.
배치 추론의 전처리 단계는 데이터 샘플링과 정답 열을 제외하여 훈련과 동일한 경우가 많습니다. 배치 추론은 추론을 위해 데이터를 일괄적으로 해당 엔드포인트로 보내는 단계로, 다음을 사용하여 구현할 수 있습니다. 일괄 변환. 후처리 단계는 결과 분포와 같은 추가 통계를 생성하거나 결과를 외부 ID와 결합합니다. 그런 다음 모델 모니터 단계는 학습에 사용된 데이터(모델 레지스트리의 모델 JSON 메타데이터)의 기준 통계를 추론을 위해 새로 들어오는 데이터와 비교할 수 있습니다.
데이터 과학자가 SageMaker 모델 레지스트리에 저장할 수 있는 파이프라인 모델을 생성하는 경우 전처리 단계를 건너뛸 수 있습니다. 자세한 내용은 하나의 끝점 뒤에 직렬 추론 파이프라인으로 사전 처리 논리와 함께 호스트 모델.
리포지토리 표준화
데이터 과학자와 ML 엔지니어 간의 협업을 가능하게 하려면 코드 저장소 구조의 표준화가 필요합니다. 또한 표준화는 CI/CD 파이프라인 구조에 유용하므로 자동 검증, 구축(예: 맞춤형 컨테이너 구축) 및 테스트 단계를 통합할 수 있습니다.
다음 예는 ML 솔루션을 두 개의 리포지토리로 분리하는 방법을 보여줍니다. 하나는 교육용 건물 및 교육 리포지토리(및 선택적으로 파이프라인 모델)이고, 다른 하나는 배치 추론 파이프라인 모델을 승격하거나 실시간 엔드포인트를 인스턴스화하기 위한 배포입니다.
건물/교육 저장소
배포 저장소
건물 및 교육 저장소는 세 가지 주요 폴더로 나뉩니다.
- 알고리즘 – 데이터 과학자는 알고리즘 루트 폴더에서 ML 파이프라인의 각 단계에 대한 코드를 개발합니다. 단계는 전처리, 훈련, 일괄 추론 및 후처리(평가)로 그룹화할 수 있습니다. 각 그룹에서 단위 테스트(선택적 입력 및 출력 포함), 기본 기능, 추가 정보 및 사용자 정의 컨테이너가 필요한 경우 Docker 파일을 위한 폴더가 포함된 해당 하위 폴더에 여러 단계를 정의할 수 있습니다. 기본 외에도 여러 코드 파일을 동일한 폴더에 호스팅할 수 있습니다. 모든 단계에 대한 공통 도우미 라이브러리는 공유 라이브러리 폴더에서 호스팅할 수 있습니다. 데이터 과학자는 단계의 논리를 소유하기 때문에 단위 테스트 개발을 담당하고 ML 엔지니어는 오류 처리 향상 및 테스트 커버리지 권장 사항을 담당합니다. CI/CD 파이프라인은 테스트 실행, 컨테이너 자동 빌드(필요한 경우), 여러 소스 코드 파일 패키징을 담당합니다.
- ML 파이프라인 – 각 단계의 소스 코드와 테스트를 개발한 후 다음 단계는 다른 루트 폴더에 SageMaker 파이프라인을 정의하는 것입니다. 각 ML 파이프라인 정의는 초매개변수 범위와 같은 입력 매개변수에 대한 .py 파일과 JSON 또는 .yaml 파일이 포함된 하위 폴더에 배치됩니다. ML 파이프라인을 설명하는 추가 정보 파일이 필요합니다.
- 노트북 – 이 폴더는 데이터 과학자가 실험 중에 사용한 원본 노트북을 호스팅합니다.
배포 리포지토리는 세 가지 주요 부분으로 구성됩니다.
- 추론 구성 – 인스턴스 유형과 같은 개발 환경별 실시간 엔드포인트 구성 또는 일괄 추론을 포함합니다.
- 애플리케이션 인프라 – 필요한 경우 추론을 실행하는 데 필요한 인프라의 소스 코드를 호스팅합니다. 이것은 다음을 통한 트리거 메커니즘일 수 있습니다. 아마존 이벤트 브리지, 아마존 API 게이트웨이, AWS 람다 함수 또는 SageMaker 파이프라인.
- 테스트 – 고객 테스트 방법에 따라 여러 하위 폴더로 구성됩니다. 테스트의 최소 집합으로 통합 테스트(애플리케이션 인프라를 포함한 추론의 엔드 투 엔드 실행), 스트레스 테스트(에지 케이스 검사) 및 ML 테스트(신뢰 점수 또는 확률 분포 등)를 제안합니다.
CI/CD 파이프라인은 건물 및 교육 리포지토리에 대한 변경 사항을 커밋하여 리포지토리 구조를 검증하고, 테스트를 수행하고, ML 파이프라인을 배포 및 실행하는 일을 담당합니다. 다른 CI/CD 파이프라인은 다음 섹션에서 검토하는 모델 승격을 담당합니다.
저장소 분기 및 CI/CD 표준화
dev 계정에서 ML 파이프라인의 견고성을 보장하기 위해 다중 분기 저장소 전략이 제안되지만 배포는 CI/CD 파이프라인을 통해서만 수행됩니다. 데이터 과학자는 기능 분기를 활용하여 새로운 기능(소스 코드)을 개발해야 합니다. 해당 ML 파이프라인을 배포할 준비가 되면 이를 개발 분기로 푸시할 수 있습니다. 이 접근 방식의 대안은 기능 분기별로 ML 파이프라인 배포를 허용하는 것입니다. 자세한 내용은 다음을 참조하십시오. AWS를 사용하는 다중 분기 교육 MLOps 파이프라인으로 데이터 과학 워크플로 개선.
다음 그림은 ML 파이프라인 및 모델 구축을 위해 개발 환경에서 실행하는 분기 전략과 필요한 CI/CD 파이프라인 단계를 보여줍니다.
다중 분기 접근 방식의 코드 예제는 다음에서 사용할 수 있습니다. 다중 분기 MLOps 교육 파이프라인. 기능 분기 기반 ML 파이프라인에서 생성된 모델을 별도의 기능 모델 그룹에 저장하고 메인 분기와의 병합 요청 중에 해제할 수 있습니다. 기본 모델 그룹의 모델은 프로덕션으로 승격된 모델입니다.
데이터 구조 표준화
소스 코드 표준화에 똑같이 중요한 것은 데이터의 구조 표준화로, 이를 통해 데이터 과학자와 ML 엔지니어는 모델 및 ML 파이프라인의 출처와 기록을 디버그, 감사 및 모니터링할 수 있습니다. 다음 다이어그램은 그러한 예를 보여줍니다.
간단하게 하기 위해 입력 기록 데이터가 입력 하위 키 아래의 개발 계정 버킷에 있다고 가정하겠습니다(일반적으로 데이터 레이크에 있음). 각 ML 사용 사례에 대해 별도의 하위 키를 생성해야 합니다. 실행할 새 ML 파이프라인을 트리거하려면 데이터 과학자가 CI/CD 파이프라인을 트리거하는 git 커밋 및 푸시를 수행해야 합니다. 그런 다음 CI/CD 파이프라인은 코드 아티팩트( code
하위 키) 및 입력 데이터( input
하위 키) 빌드 ID의 하위 파티션 아래. 예를 들어 빌드 ID는 c날짜-시간 및 git 해시의 조합 또는 SageMaker 파이프라인 실행 ID일 수 있습니다. 이 구조를 통해 데이터 과학자는 과거 배포 및 실행을 감사하고 쿼리할 수 있습니다. 그런 다음 CI/CD 파이프라인이 ML 파이프라인을 배포하고 트리거합니다. ML 파이프라인이 실행되는 동안 각 단계는 중간 결과를 다음으로 내보냅니다. ml-pipeline-outputs
. 서로 다른 기능 분기가 ML 파이프라인의 새 인스턴스를 배포 및 실행하고 각각이 중간 결과를 새 하위 키 및/또는 다음을 포함하는 표준화된 접두사 또는 접미사가 있는 다른 하위 폴더로 내보내야 한다는 점을 명심하는 것이 중요합니다. 기능 분기 ID.
이 접근 방식은 모든 실험의 완전한 감사 가능성을 지원합니다. 그러나 개발 전략의 다중 분기 접근 방식은 많은 양의 데이터를 생성합니다. 따라서 데이터 수명 주기 전략이 필요합니다. 모든 성공적인 pull/merge 요청에서 최소한 각 기능 분기 ML 파이프라인의 데이터를 삭제하는 것이 좋습니다. 그러나 이는 운영 모델과 비즈니스에서 지원해야 하는 감사 세분성에 따라 다릅니다. 일괄 추론 ML 파이프라인에서 유사한 접근 방식을 사용할 수 있습니다.
신뢰할 수 있는 단계
여러 계정을 사용하여 데이터 과학자, ML 엔지니어 및 데이터 엔지니어 간의 초기 관심사 분리 후 다음 단계는 생성된 모델을 모델 레지스트리에서 격리된 환경으로 승격하여 추론을 수행하는 것입니다. 그러나 배포된 모델의 견고성을 보장해야 합니다. 따라서 프로덕션의 미러 환경, 즉 사전 프로덕션(또는 스테이징)에 배포된 모델의 시뮬레이션이 필수입니다.
다음 그림은 이 아키텍처를 보여줍니다.
사전 프로덕션 환경에서 모델 및 엔드포인트 배포의 승격은 EventBridge 이벤트를 사용하여 별도의 CI/CD 파이프라인을 트리거하는 모델 레지스트리 상태 업데이트 이벤트(또는 배포 리포지토리의 git push)를 사용하여 수행됩니다. CI/CD 파이프라인의 첫 번째 단계는 수석 데이터 과학자(및 선택적으로 제품 소유자, 비즈니스 분석가 또는 기타 수석 데이터 과학자)의 수동 승인을 요청합니다. 승인자는 배포 리포지토리에 있는 코드의 QA 및 모델의 성능 KPI를 검증해야 합니다. 승인 후 CI/CD 파이프라인은 테스트 코드를 배포 저장소(통합 테스트, 스트레스 테스트, ML 테스트)로 실행합니다. 모델 엔드포인트 외에도 CI/CD는 EventBridge, Lambda 함수 또는 API 게이트웨이와 같은 트리거 인프라도 테스트합니다. 다음 다이어그램은 이 업데이트된 아키텍처를 보여줍니다.
테스트를 성공적으로 실행한 후 CI/CD 파이프라인은 새(또는 동일한) 승인자에게 모델이 프로덕션으로 승격될 준비가 되었음을 알립니다. 이 단계에서 비즈니스 분석가는 모델의 결과에 대해 몇 가지 추가 통계 가설 테스트를 수행할 수 있습니다. 승인 후 모델과 트리거 인프라가 프로덕션 환경에 배포됩니다. Blue/Green, Canary 및 A/B 테스트와 같은 여러 배포 방법이 SageMaker에서 지원됩니다(자세한 내용은 배포 가드레일). CI/CD 파이프라인이 실패하면 롤백 메커니즘이 시스템을 강력한 최신 상태로 되돌립니다.
다음 다이어그램은 API Gateway, Lambda 함수 및 EventBridge와 같은 모델 엔드포인트를 트리거하는 인프라와 모델을 승격하는 CI/CD 파이프라인의 주요 단계를 보여줍니다.
데이터 레이크 및 MLOps 통합
이 시점에서 개발 단계 또는 계정별 데이터 요구 사항과 MLOps를 중앙 집중식 데이터 레이크와 통합하는 방법을 이해하는 것이 중요합니다. 다음 다이어그램은 MLOps 및 데이터 레이크 계층을 보여줍니다.
데이터 레이크에서 데이터 엔지니어는 ETL을 구축하여 ML 사용 사례에 대해 여러 데이터 소스를 결합하고 해당 데이터 세트(예: 구조 데이터의 단일 테이블 또는 PDF 파일 또는 이미지가 있는 단일 폴더)를 생성하는 일을 담당합니다. 데이터 과학자가 정의한 파이프라인(탐색 데이터 분석 단계 중). 이러한 데이터 세트는 추론 및 테스트를 위해 기록 데이터와 데이터로 분할할 수 있습니다. 모든 데이터는 카탈로그화되며(예: AWS Glue 데이터 카탈로그 사용) Lake Formation을 데이터 거버넌스 계층으로 사용하여(구조화된 데이터의 경우) 다른 계정 및 사용자와 공유할 수 있습니다. 이 글을 쓰는 시점에서 Lake Formation은 Athena 쿼리, AWS Glue 작업 및 Amazon EMR과만 호환됩니다.
반면에 MLOps 환경은 dev, pre-prod 및 prod의 로컬 버킷에 있는 특정 데이터 세트로 ML 파이프라인을 관개해야 합니다. 개발 환경은 데이터 레이크에서 데이터를 가져오는 SageMaker 파이프라인을 사용하여 온디맨드 방식으로 모델을 구축하고 교육하는 역할을 합니다. 따라서 파이프라인의 첫 번째 단계로 데이터 샘플링 및 쿼리만 필요한 Athena 단계나 더 복잡한 변환이 필요한 경우 Amazon EMR 단계를 사용하는 것이 좋습니다. 또는 콜백 단계를 통해 AWS Glue 작업을 사용할 수 있지만 SageMaker Pipelines에서는 아직 기본 단계로 사용할 수 없습니다.
Pre-prod 및 prod는 실시간 및 배치 추론을 테스트하거나 수행하는 책임이 있습니다. 실시간 추론의 경우 추론을 위한 입력이 API Gateway 요청의 페이로드에 피기백할 수 있기 때문에 MLOps 사전 프로덕션 및 프로덕션 계정으로 데이터를 보낼 필요가 없습니다. 배치 추론(또는 대규모 입력 데이터)의 경우 테스트 데이터 또는 추론용 데이터와 같은 필요한 데이터 세트는 로컬 ML 데이터 버킷(프로덕트 전 또는 프로덕션)에 있어야 합니다. 데이터를 사전 프로덕션 및 프로덕션으로 이동하는 두 가지 옵션이 있습니다. Athena 또는 Amazon EMR을 트리거하고 데이터 레이크에서 데이터를 가져오거나 데이터 레이크에서 해당 MLOps 계정으로 데이터를 푸시하는 것입니다. 첫 번째 옵션은 MLOps 계정에서 추가 메커니즘의 개발이 필요합니다. 예를 들어 예약된 EventBridge 이벤트 생성(데이터 레이크의 데이터가 업데이트되었는지 여부를 알지 못함) 또는 데이터 레이크의 S3 EventBridge 이벤트에서 온 데이터 도착(예: 자세한 내용은 참조 Amazon EventBridge 리소스 정책으로 교차 계정 액세스 간소화). MLOps 측에서 이벤트를 포착한 후 Athena 쿼리 또는 Amazon EMR이 로컬에서 데이터를 가져와 트리거할 수 있습니다. 비동기 추론 or 일괄 변환. 이것은 단순성을 위해 SageMaker 파이프라인으로 래핑될 수 있습니다. 두 번째 옵션은 ETL 파이프라인의 마지막 단계에서 데이터를 MLOps 버킷으로 푸시하는 기능을 추가하는 것입니다. 그러나 이 접근 방식은 책임(데이터 레이크가 추론을 트리거함)을 혼합하고 MLOps 버킷에 쓰기 위해 데이터 레이크에 대한 액세스를 제공하기 위해 Lake Formation이 필요합니다.
마지막 단계는 추론 결과를 데이터 레이크로 다시 이동하는 것입니다. 데이터를 카탈로그화하고 다른 사용자가 사용할 수 있도록 하려면 데이터가 새 데이터 원본으로 다시 방문 버킷으로 반환되어야 합니다.
확장 가능한 단계
MLOps 기반 개발 및 첫 번째 ML 사용 사례의 종단 간 생산화 후 dev, pre-prod, prod 및 저장소의 인프라, CI/CD 파이프라인 및 데이터 구조가 테스트되고 완료되었습니다. . 다음 단계는 새로운 ML 사용 사례와 팀을 플랫폼에 온보딩하는 것입니다. 가치 실현 속도를 보장하기 위해 SageMaker를 사용하면 템플릿 리포지토리 및 CI/CD 파이프라인을 자동으로 인스턴스화하는 데 사용할 수 있는 사용자 지정 SageMaker 프로젝트 템플릿을 생성할 수 있습니다. 이러한 SageMaker 프로젝트 템플릿을 사용하면 수석 데이터 과학자가 새 프로젝트를 인스턴스화하고 새 ML 사용 사례별로 전담 팀을 할당하는 일을 담당합니다.
다음 다이어그램은 이 프로세스를 보여줍니다.
여러 데이터 과학자 팀(또는 ML을 생산해야 하는 여러 사업부)이 서로 다른 기밀 데이터에 액세스할 수 있고 여러 제품 소유자가 모델의 교육, 배포 및 실행에 대해 별도의 청구서를 지불해야 하는 경우 문제가 더 복잡해집니다. . 따라서 팀별로 별도의 MLOps 계정 집합(실험, 개발, 사전 생산 및 생산)이 필요합니다. 새로운 MLOps 계정을 쉽게 생성할 수 있도록 IT 구성원이 액세스할 수 있고 요청 시 MLOps 계정을 카탈로그화, 인스턴스화 또는 폐기할 수 있는 또 다른 계정인 고급 분석 거버넌스 계정을 도입했습니다. 특히 이 계정은 MLOps 계정(VPC, 서브넷, 엔드포인트, 버킷, AWS 자격 증명 및 액세스 관리 (IAM) 역할 및 정책, AWS 클라우드 포메이션 스택), AWS 서비스 카탈로그 한 번의 클릭으로 인프라의 CloudFormation 스택을 여러 계정에 자동으로 배포하는 제품 및 아마존 DynamoDB 각 계정 집합을 담당하는 팀과 같은 메타데이터를 카탈로그화하는 테이블입니다. 이 기능을 통해 IT 팀은 요청 시 MLOps 계정을 인스턴스화하고 필요한 사용자, 계정당 데이터 액세스 및 일관된 보안 제약을 할당합니다.
이 시나리오를 기반으로 계정을 임시 계정과 영구 계정으로 구분합니다. 데이터 레이크와 도구는 내구성 계정이며 각각 데이터 및 소스 코드에 대한 단일 진실 지점의 역할을 합니다. MLOps 계정은 대부분 상태 비저장이며 요청에 따라 인스턴스화되거나 폐기되므로 임시 계정이 됩니다. MLOps 계정 집합이 폐기되더라도 사용자 또는 감사자는 내구성 있는 환경에 저장되기 때문에 과거 실험 및 결과를 확인할 수 있습니다.
MLOps에 Studio UI를 사용하려는 경우 도구 계정은 다음 그림과 같이 dev 계정의 일부입니다.
사용자가 MLOps용 Sagemaker Studio UI를 사용하려는 경우 도구 계정은 dev의 일부입니다.
위 그림과 같이 계정을 만듭니다. 이 MLOPs 기초의 예제 소스 코드는 다음에서 찾을 수 있습니다.
CDK 기반의 안전한 다중 계정 MLOps 기반.
Sagemaker는 GitHub 및 Jenkins와 같은 다른 타사 개발 도구로 CodeCommit 및 CodePipeline을 대체할 수 있는 기능을 제공합니다(자세한 내용은 Amazon SageMaker 프로젝트 생성 타사 소스 제어 및 Jenkins 사용 및 Amazon SageMaker 프로젝트 MLOps GitLab 및 GitLab 파이프라인이 있는 템플릿).
페르소나, 운영 및 기술 요약
MLOps 성숙도 모델을 사용하여 명확한 아키텍처 설계 및 제공 로드맵을 정의할 수 있습니다. 그러나 각 페르소나는 상호 작용할 주요 AWS 계정 및 서비스와 수행할 작업에 대한 명확한 보기가 필요합니다. 다음 다이어그램은 이러한 범주를 요약합니다.
결론
여러 페르소나와 기술 간의 상호 작용을 명확하게 정의하는 강력한 MLOps 기반은 가치 실현 속도를 높이고 비용을 절감하며 데이터 과학자가 혁신에 집중할 수 있도록 합니다. 이 게시물에서 우리는 이러한 기반을 단계적으로 구축하여 비즈니스를 위한 원활한 MLOps 성숙 모델과 프로덕션에서 여러 데이터 과학 팀 및 ML 사용 사례를 지원하는 기능으로 이어지는 방법을 보여주었습니다. 우리는 여러 기술과 책임을 가진 여러 페르소나로 구성된 운영 모델을 정의했습니다. 마지막으로 코드 개발(리포지토리 및 CI/CD 파이프라인), 데이터 저장 및 공유, 엔터프라이즈 환경을 위한 MLOps 보안 인프라 프로비저닝을 표준화하는 방법에 대한 예를 공유했습니다. 많은 기업 고객이 이 접근 방식을 채택했으며 몇 개월이 아닌 며칠 만에 ML 솔루션을 생산할 수 있습니다.
의견이나 질문이 있으면 의견란에 남겨주세요.
저자에 관하여
소크라티스 카르타키스 박사 Amazon Web Services의 수석 기계 학습 전문가 솔루션 설계자입니다. Sokratis는 AWS 서비스를 활용하고 운영 모델, 즉 MLOps 기반 및 모범 개발 사례를 활용하는 변환 로드맵을 형성하여 기업 고객이 기계 학습(ML) 솔루션을 산업화할 수 있도록 하는 데 중점을 둡니다. 그는 에너지, 소매, 건강, 금융/은행, 모터스포츠 등의 영역에서 혁신적인 종단 간 생산 수준 ML 및 사물 인터넷(IoT) 솔루션을 발명, 설계, 선도 및 구현하는 데 15년 이상을 보냈습니다. Sokratis는 여가 시간을 가족 및 친구와 함께 보내거나 오토바이를 타는 것을 좋아합니다.
게오르기오스 쉬나스 EMEA 지역의 AI/ML 전문 솔루션 설계자입니다. 그는 런던에 기반을 두고 있으며 영국 및 아일랜드의 고객과 긴밀하게 협력하고 있습니다. Georgios는 고객이 MLOps 사례에 특히 관심을 갖고 AWS의 프로덕션 환경에서 기계 학습 애플리케이션을 설계 및 배포하고 고객이 대규모로 기계 학습을 수행할 수 있도록 지원합니다. 여가 시간에는 여행, 요리, 친구 및 가족과 함께 시간을 보내는 것을 즐깁니다.
주세페 안젤로 포첼리 Amazon Web Services의 주요 기계 학습 전문가 솔루션 설계자입니다. 수년 간의 소프트웨어 엔지니어링 ML 배경을 가진 그는 모든 규모의 고객과 협력하여 비즈니스 및 기술 요구 사항을 깊이 이해하고 AWS 클라우드 및 Amazon Machine Learning 스택을 최대한 활용하는 AI 및 기계 학습 솔루션을 설계합니다. 그는 MLOps, Computer Vision, NLP를 비롯한 다양한 도메인에서 다양한 AWS 서비스와 관련된 프로젝트에 참여했습니다. 여가 시간에 Giuseppe는 축구를 즐깁니다.
쉘비 아이겐브로드 Amazon Web Services(AWS)의 수석 AI 및 기계 학습 전문가 솔루션 아키텍트입니다. 그녀는 24년 동안 다양한 산업, 기술 및 역할에 걸쳐 기술 분야에서 일해 왔습니다. 그녀는 현재 DevOps 및 ML 배경을 MLOps 도메인에 결합하여 고객이 ML 워크로드를 대규모로 제공하고 관리할 수 있도록 하는 데 집중하고 있습니다. 다양한 기술 영역에 걸쳐 35개 이상의 특허를 부여받은 그녀는 지속적인 혁신과 데이터 사용에 대한 열정을 갖고 있습니다. Shelbee는 Coursera의 Practical Data Science 전문 분야의 공동 창시자이자 강사입니다. 그녀는 또한 덴버 챕터의 WiBD(Women In Big Data) 공동 이사이기도 합니다. 여가 시간에는 가족, 친구, 활동적인 개와 시간을 보내는 것을 좋아합니다.
- "
- 100
- a
- 능력
- 소개
- 추상
- 가속
- ACCESS
- 얻기 쉬운
- 수용하다
- 계정
- 달성
- 가로질러
- 또한
- 추가
- 양자
- 많은
- 반대
- AI
- 알고리즘
- All
- 수
- 대안
- 아마존
- Amazon Web Services
- 중
- 양
- 분석
- 분석자
- 분석
- 다른
- API를
- 어플리케이션
- 어플리케이션
- 접근
- 아키텍처
- 회계 감사
- 자동화
- Automatic
- 자동적으로
- 자동화
- 가능
- 피하고
- AWS
- 배경
- 기준
- 때문에
- 가
- 전에
- 뒤에
- 유익한
- BEST
- 사이에
- 빅 데이터
- 지폐
- 후원
- 빌드
- 건물
- 내장
- 사업
- 사업
- 기능
- 케이스
- 가지 경우
- 중앙
- 도전
- 장
- 확인하는 것이 좋다.
- 고전적인
- 클라우드
- 암호
- 협력
- 협동
- 단
- 결합
- 댓글
- 범하다
- 공통의
- 기업
- 호환
- 완전한
- 복잡한
- compliance
- 컴퓨터
- 행위
- 전도
- 자신
- 구성
- 연결
- 일관된
- 컨테이너
- 용기
- 이 포함되어 있습니다
- 제어
- 사자
- 동
- 수
- 엄호
- 만들
- 만든
- 생성
- 만들기
- 창조
- 현재
- 관습
- 고객
- 고객
- 데이터
- 데이터 액세스
- 데이터 분석
- 데이터 프라이버시
- 데이터 과학
- 데이터 과학자
- 데이터 저장
- 일
- 전용
- 배달
- 수요
- 덴버
- 의존
- 따라
- 배포
- 배포
- 배치
- 전개
- 배포
- 배치하다
- 설명
- 디자인
- 설계
- 세부설명
- Detection System
- 데브
- 개발
- 개발
- 개발 도구
- 차이
- 다른
- 토론
- 분포
- 도커
- 도메인
- 도메인
- 드라이브
- 구동
- ...동안
- 마다
- Edge
- 제거
- 포옹
- 가능
- 수
- 가능
- 끝으로 종료
- 종점
- 에너지
- 엔지니어링
- 엔지니어
- Enterprise
- 기업
- 환경
- 등
- 평가
- 평가
- 이벤트
- 이벤트
- 정확하게
- 예
- 예
- ...을 제외한
- 실험
- 공격
- 탐구
- 가족
- 특색
- 그림
- 최종적으로
- 먼저,
- 흐름
- 초점
- 집중
- 초점
- 수행원
- 축구
- 형성
- 발견
- Foundation
- 기초
- 뼈대
- 프레임 워크
- 무료
- 에
- 기능
- 기능
- 게다가
- 게이트웨이
- GDPR
- 생성
- 힘내
- GitHub의
- 골
- 통치
- 부여
- 그룹
- 처리
- 해시
- 건강
- 도움
- 도움이
- 도움이
- 높은
- 역사적인
- history
- 호스팅
- 방법
- How To
- 그러나
- HTTPS
- 수백
- 통합 인증
- 형상
- 구현
- 구현
- 구현
- 중대한
- 개선
- 포함
- 포함
- 증가
- 산업
- 정보
- 인프라
- 혁신
- 혁신
- 혁신적인
- 입력
- 예
- 완성
- 통합
- 상호 작용
- 관심
- 인터페이스
- 인터넷
- 사물의 인터넷
- IOT
- 아일랜드
- 격리
- IT
- 일
- 작업
- 가입
- 조인
- 유지
- 키
- 지식
- 넓은
- 최근
- 층
- 리드
- 지도
- 배우다
- 배우기
- 휴가
- 이용약관
- 레벨
- 레버리지
- 도서관
- 하중
- 지방의
- 장소 상에서
- 런던
- 기계
- 기계 학습
- 확인
- 유튜브 영상을 만드는 것은
- 관리
- 구축
- 필수
- 조작
- 만기
- 기구
- 회원
- 병합
- 방법론
- 방법
- 통계
- 수도
- 신경
- 최저한의
- 거울
- ML
- 모델
- 모델
- 모니터
- 개월
- 배우기
- 모터 스포츠
- 움직임
- 움직이는
- 여러
- 즉
- 이름
- 명명
- 필요한
- 요구
- 다음 것
- 일반적으로
- 운영
- 운영
- 행정부
- 최적화
- 선택권
- 옵션
- 주문
- 조직
- 실물
- 기타
- 자신의
- 소유자
- 소유자
- 부품
- 특별한
- 파티
- 열정
- 특허
- 사람들
- 성능
- 실행할 수 있는
- 상
- 플랫폼
- 연극
- 연주
- 부디
- 포인트 적립
- 정책
- Prepare
- 교장
- 개인 정보 보호
- 문제
- 방법
- 처리
- 생산
- 프로덕트
- 생산
- 생산력
- 프로젝트
- 프로젝트
- 홍보
- 승진
- 제공
- 제공
- 제공
- 당기
- 품질
- RE
- 실시간
- 감소
- 감소
- 지방
- 회원가입
- 관계
- 신뢰할 수있는
- 저장소
- 의뢰
- 요청
- 필수
- 요구조건 니즈
- 필요
- 연구
- 의지
- 제품 자료
- 책임
- 책임
- 결과
- 소매
- return
- 반품
- 로드맵
- 견고성
- 직위별
- 뿌리
- 달리기
- 달리는
- 같은
- 확장성
- 규모
- 스케일링
- 예약
- 과학
- 과학자
- 과학자
- SDK
- 안전해야합니다.
- 보안
- 일련의
- 연속
- 서비스
- 서비스
- 세트
- 설치
- 몇몇의
- 셰이프
- 공유
- 공유
- 표시
- 비슷한
- 시뮬레이션
- 단일
- 크기
- 기술
- 소프트웨어
- 소프트웨어 공학
- 해결책
- 솔루션
- 풀다
- 일부
- 소스 코드
- 전문가
- 구체적인
- 구체적으로
- 속도
- 지출
- 지출
- 분열
- 스택
- 단계
- 단계
- 스타트
- 주 정부
- 통계적인
- 통계
- Status
- 저장
- 저장
- 상점
- 전략
- 유선
- 스트레스
- 구조화
- 스튜디오
- 성공한
- SUPPORT
- 지원
- 지원
- 체계
- 시스템은
- 팀
- 팀
- 테크니컬
- 기술
- Technology
- 템플릿
- test
- 지원
- 테스트
- XNUMXD덴탈의
- 소스
- 세계
- 따라서
- 일
- 타사
- 세
- 시간
- 함께
- 검색을
- Train
- 트레이닝
- 변환
- 변환
- 변환
- 여행
- 유형
- ui
- Uk
- 아래에
- 이해
- 단위
- 업데이트
- 사용
- 사용자
- 활용
- 확인
- 가치
- 여러
- 관측
- 시력
- 웹
- 웹 서비스
- 동안
- 이내
- 없이
- 여성 컬렉션
- 작업
- 일
- 워크 플로우
- 일
- 세계
- 쓰기
- 년
- 너의