솔루션 아키텍처 살펴보기
달성하려는 목적을 이해하기 위해 MLOps(기계 학습 작업) 아키텍처를 수정해 보겠습니다.
데이터 과학 및 소프트웨어 개발 팀과 함께 당뇨병 분류 모델을 학습, 테스트 및 배포하는 다음 아키텍처에 동의한다고 상상해보세요.
참고 항목
다이어그램은 MLOps 아키텍처의 간소화된 표현입니다. 더 자세한 아키텍처를 보려면 MLOps(v2) 솔루션 가속기에서 다양한 사용 사례를 살펴봅니다.
아키텍처에는 다음이 포함됩니다.
- 설치: 솔루션에 필요한 모든 Azure 리소스를 만듭니다.
- 모델 개발(내부 루프): 모델을 학습하고 평가하기 위해 데이터를 탐색하고 처리합니다.
- 연속 통합: 모델을 패키지하고 등록합니다.
- 모델 배포(외부 루프): 모델을 배포합니다.
- 지속적인 배포: 모델을 테스트하고 프로덕션 환경으로 승격합니다.
- 모니터링: 모델 및 엔드포인트 성능을 모니터링합니다.
데이터 과학 팀은 모델 개발을 담당합니다. 소프트웨어 개발 팀은 환자가 당뇨병을 앓고 있는지 여부를 평가하기 위해 실무자가 사용하는 웹앱과 배포된 모델을 통합할 책임이 있습니다. 모델 개발에서 모델 배포로 모델을 가져올 책임이 있습니다.
데이터 과학 팀은 모델을 학습시키는 데 사용되는 스크립트에 대한 변경 내용을 지속적으로 제안할 것을 기대하고 있습니다. 학습 스크립트가 변경될 때마다 모델을 다시 학습시키고 기존 엔드포인트에 모델을 다시 배포해야 합니다.
프로덕션 준비가 된 코드를 건드리지 않고 데이터 과학 팀이 실험할 수 있도록 허용하려고 합니다. 또한 새 코드 또는 업데이트된 코드가 품질 검사에 합의된 대로 자동으로 통과되도록 하려고 합니다. 모델을 학습시키는 코드를 확인한 후에는 업데이트된 학습 스크립트를 사용하여 새 모델을 학습시키고 배포합니다.
변경 내용을 추적하고 프로덕션 코드를 업데이트하기 전에 코드를 확인하려면 분기를 사용할 필요가 있습니다. 데이터 과학 팀에서 변경하려고 할 때마다 기능 분기를 만들어 코드의 복사본을 만들고 복사본을 변경하기로 데이터 과학 팀과 합의했습니다.
모든 데이터 과학자는 기능 분기를 만들고 해당 분기에서 작업할 수 있습니다. 코드를 업데이트하고 해당 코드를 새 프로덕션 코드로 설정하려면 끌어오기 요청을 만들어야 합니다. 끌어오기 요청에서, 제안된 변경 내용이 다른 사용자에게 표시되어 다른 사용자가 변경 내용을 검토하고 논의할 기회를 제공합니다.
끌어오기 요청을 만들 때마다 코드가 작동하는지 여부와 코드 품질이 조직의 표준에 맞는지 자동으로 확인하려고 합니다. 코드가 품질 검사를 통과하면 리드 데이터 과학자는 끌어오기 요청을 병합하기 전에 변경 내용을 검토하고 업데이트를 승인해야 하며 주 분기의 코드를 그에 따라 업데이트할 수 있습니다.
중요
아무도주 분기에 변경 내용을 푸시할 수 없어야 합니다. 코드, 특히 프로덕션 코드를 보호하려면 승인이 필요한 끌어오기 요청을 통해서만 주 분기를 업데이트할 수 있도록 적용해야 합니다.