Azure에서 AI 워크로드 작업
AI 워크로드를 빌드하고 프로덕션으로 전환하는 경우 운영 팀이 다른 프로덕션 워크로드와 마찬가지로 이러한 워크로드를 지원할 수 있도록 완벽하게 갖추어야 합니다. 운영 팀은 AI 기술에 대한 경험이 제한적일 수 있으므로 이러한 기술을 학습시키고 AI 워크로드를 프로세스 초기에 워크플로에 통합하는 것이 중요합니다. AI 워크로드 개발 초기에 운영 및 데이터 팀을 통합하여 각 팀의 프로세스에 대한 상호 이해를 촉진합니다. 이 초기 협업은 두 팀이 AI 워크로드를 효과적으로 지원하기 위해 긴밀히 협력해야 하기 때문에 매우 중요합니다. 데이터 팀은 신뢰할 수 있는 상태 신호 및 실행 가능한 경고를 제공하기 위해 운영 팀에 의존합니다. 운영 팀은 잠재적인 문제를 진단하고 운영 표준에 따라 실제 문제를 해결하는 데 도움이 되도록 데이터 팀에 의존합니다. 이 파트너 관계를 통해 원활하고 효율적인 시스템 성능을 보장할 수 있습니다.
이 가이드에서는 AI 워크로드에 대한 지원을 개선하기 위한 운영 메커니즘 및 사례를 개발하는 방법에 대한 권장 사항을 제공합니다. 운영 팀과 데이터 팀 간의 효율적인 협업을 강조합니다.
권장 사항
다음은 이 문서에 제공된 권장 사항의 요약입니다.
| 추천 | 설명 |
|---|---|
| 워크로드의 모든 측면을 모니터링합니다. | 많은 일반적인 모니터링 및 관찰 가능성 문제가 AI 워크로드에도 적용되지만 워크로드 전체가 항상 적절하게 모니터링되도록 하기 위해 수행해야 하는 구체적인 고려 사항이 있습니다. 모니터링 및 관찰성 전략을 구축하려면 서로 다른 팀에서 작업하여 올바른 전문 지식을 얻고 모든 관련 모드 및 메트릭을 처리해야 할 수 있습니다. ▪ 관찰성 플랫폼 확장 |
| AI 워크로드에 안전한 배포 사례를 적용합니다. | 중요한 프로덕션 데이터에 대한 최고 수준의 안전을 보장하고 가동 중지 시간 요구 사항이 없는 배포 방법을 조정하는 단계를 수행합니다. 필요한 경우 적절한 도구를 사용하고, 이미 존재하는 도구와 프로세스를 재창조하지 않는 것에 중점을 둡다. 종종 설정된 서비스를 사용하여 높은 수준의 효율성을 달성하는 동시에 안전한 배포를 가능하게 할 수 있습니다. ▪ 안전한 배포 사례에 AI 워크로드 구성 요소 포함 |
| 테스트 및 자동화에 대한 DevOps 사례를 수용합니다. | 프로덕션 환경에서 AI 워크로드를 빌드, 배포 및 운영할 때 DevOps 사례를 적용합니다. 워크로드는 프로덕션 환경에서 실제 사용자 입력을 사용하여 관찰 가능성과 테스트를 허용해야 합니다. 강력한 DevOps 프로세스와 간소화된 자동화를 통해 신속한 배포, 오류 수정 및 A/B 테스트를 허용하는 경우에만 안전한 방식으로 제공할 수 있습니다. ▪ 프로덕션 환경에서 테스트 지원 ▪ 가능한 경우 운영 사례 자동화 ▪ DevOps 사례 수용 |
| 진행 상황을 문서화합니다. | 워크로드에서 사용하는 데이터에 대한 전략적 결정, 변경 기록 및 주요 정보를 캡처할 수 있도록 처음부터 좋은 설명서 습관을 작성합니다. ▪ 좋은 설명서 사례 채택 |
관찰성 플랫폼 확장
운영 우수성을 달성하기 위해서는 강력한 관찰성이 필수적입니다. 조직에서 AI 기술을 채택할 때는 워크로드 상태를 포괄적으로 모니터링할 수 있도록 관찰성 플랫폼을 향상시키는 것이 중요합니다. AI를 접하는 조직에는 운영 팀 내에서 빅 데이터, 데이터 과학 및 DataOps 전문 지식이 부족할 수 있습니다. 따라서 운영 모범 사례에 대한 교육은 관찰성 플랫폼을 개선하기 위한 중요한 첫 번째 단계입니다. 이러한 이유로 작업 및 데이터 팀은 캡처 및 분석할 모니터링 및 메트릭의 올바른 모드를 결정하기 위해 공동 작업해야 합니다.
모델의 상태를 평가하려면 특정 품질 메트릭에 대한 포괄적인 개요가 필요합니다. 품질 측정에는 일반적으로 모델 새로 고침, 출력 정확성 및 응답 대기 시간과 같은 메트릭이 포함됩니다. 그러나 데이터 과학자 및 엔지니어와 협력하여 워크로드의 품질을 정의하는 특정 메트릭을 설정해야 합니다. AI 워크로드의 비결정적 특성으로 인해 품질에 대한 경계 모니터링이 특히 중요합니다. 이러한 측정값은 배포 후 언제든지 예기치 않게 변경될 수 있기 때문입니다. 관찰 가능성을 위한 권장 사항은 다음과 같습니다.
데이터 과학자 및 엔지니어와 협력하여 품질 메트릭을 확인합니다.
대시보드를 빌드하거나 확장하여 워크로드의 전반적인 상태를 평가합니다. 이 방법은 구성 요소 가용성 메트릭 및 품질 메트릭을 포함해야 합니다.
운영 팀이 이해하고 조치를 취할 수 있는 잘 설계된 가용성 및 품질 경고를 구현합니다.
데이터 팀과 협력하여 잠재적인 오작동을 조사하고 수정하는 등 운영 팀이 품질 경고에 대응하는 방법을 정의하는 표준 운영 절차를 코딩합니다.
AI 워크로드를 실행하는 데 비용이 많이 들 수 있으므로 사용률 메트릭에 주의해야 합니다. 워크로드 팀이 사용하지 않을 때 리소스를 종료, 축소 또는 할당 취소하지 않으면 비용이 빠르게 증가할 수 있습니다. 작업은 사용률을 모니터링하여 비용이 예상 매개 변수 내에서 유지되도록 하는 데 도움이 될 수 있습니다.
안전한 배포 사례에 AI 워크로드 구성 요소 포함
AI 워크로드는 종종 중요한 정보를 포함하는 프로덕션 데이터에 따라 달라집니다. 따라서 이러한 워크로드를 중심으로 최고 수준의 안전을 유지하는 것이 중요합니다. 데이터를 보호하려면 워크로드의 AI 구성 요소와 관련된 모든 코드를 포함하도록 안전한 배포 사례를 확장합니다. 워크로드에 대한 가동 중지 시간이 0인 경우 그에 따라 AI 구성 요소에 대한 배포 접근 방식을 디자인합니다.
추론 엔드포인트의 경우 배포 모델에 따라 트래픽 미러링을 사용하거나 사용하지 않고 파란색-녹색 또는 카나리아 배포를 사용합니다.
인덱스 제공의 경우 별칭 업데이트와 함께 배포 모델을 사용하여 트래픽을 줄입니다.
오케스트레이션 코드의 경우 기능 플래그 또는 파란색-녹색 배포를 사용합니다.
애플리케이션, 데이터 플랫폼 및 특정 네트워크 토폴로지에 따라 Azure 애플리케이션 Gateway 또는 Azure Front Door와 같은 게이트웨이 솔루션을 사용해야 할 수 있습니다.
도구
Azure Machine Learning은 기본적으로 기본 제공 트래픽 분할을 사용하여 청록색 배포를 지원합니다.
쓸데없이 시간을 낭비하지 마십시오!
온라인 추론 엔드포인트는 본질적으로 마이크로 서비스이므로 워크플로의 특정 기능을 제공하는 자체 데이터 및 코드를 사용하여 완전히 자체 포함된 워크로드 구성 요소로 작동합니다. 이러한 이유로 온라인 유추 엔드포인트를 고유한 수명 주기가 있는 다른 중요한 마이크로 서비스와 같이 처리합니다. 온라인 추론 엔드포인트를 개별적으로 업데이트할 수 있습니다. 그러나 더 큰 워크로드의 다른 마이크로 서비스와 마찬가지로 원활하게 함께 작동해야 합니다. 따라서 업데이트를 배포할 때 통합 테스트의 우선 순위를 지정해야 합니다. 배포가 모델 서비스 및 오케스트레이터와 같은 다른 서비스에 부정적인 영향을 주지 않도록 합니다. 또는 일괄 처리 추론 엔드포인트가 작업 처리 컴퓨팅과 밀접하게 결합되는 경우가 많으며 데이터 파이프라인에 포함됩니다. 이러한 경우 마이크로 서비스 대신 더 큰 솔루션의 일부로 처리합니다.
프로덕션 환경에서 테스트 지원
운영 팀은 AI 워크로드 테스트를 설계하거나 수행하지 않을 가능성이 높습니다. 그러나 프로덕션 환경에서 테스트가 필요하기 때문에 모니터링, 경고 및 조사를 통해 AI 워크로드 테스트를 지원해야 합니다. AI의 비결정적 특성 때문에 시간이 지남에 따라 워크로드가 예상대로 수행되도록 하기 위해 프로덕션에서 테스트가 필요합니다. 운영 팀은 운영 표준에 따라 비정상적인 테스트 결과를 효율적으로 캡처하고 진단하기 위해 워크로드 팀과 긴밀히 협력해야 합니다. 운영에서 테스트를 지원할 수 있고 워크로드 팀이 테스트를 수행할 수 있도록 하려면 두 팀이 함께 작동하도록 프로세스를 조정해야 합니다. 비프로덕션 환경에서의 작업 테스트에 대한 교육은 작업 순서를 팀에 숙지하는 데 도움이 됩니다.
가능한 경우 운영 사례 자동화
모니터링, 경고 및 테스트 프로세스를 포함하여 모든 워크로드 관련 운영 사례를 자동화합니다. 자동화는 프로세스를 반복 가능하고 효율적이며 일관성 있게 유지하기 위한 기본 전략입니다. 자동화 전략을 설계할 때 모델 불일치 및 기타 품질 신호를 적절하게 진단하는 것과 같은 활동에 대한 사람의 감독이 필요합니다. 이는 초기 릴리스에서 특히 그렇습니다. 모델 유지 관리와 관련된 프로세스는 운영 팀의 새로운 프로세스이므로 이 단계에서 품질 신호에 대한 부적절한 응답의 위험이 더 높습니다. 워크로드가 성숙함에 따라 자동화를 사용하여 잘 설계된 품질 게이트로 거짓 경보를 식별할 수 있지만, 이 시점에 도달하는 것은 길고 복잡한 과정이 될 수 있습니다.
가능하면 기존 자동화 도구를 다시 사용하여 AI 워크로드에 대한 새 자동화 작업을 수행합니다. 예를 들어 이미 Azure Pipelines 또는 GitHub 워크플로를 사용하는 경우 별도의 도구를 사용하는 대신 오케스트레이션 코드를 배포하는 데 계속 사용합니다. 그러나 자동화 도구를 하나만 사용하려면 과도하게 엔지니어링하지 마십시오. 특정 작업 또는 작업이 선택한 도구에 적합하지 않은 경우 불필요한 복잡성을 더하는 사용자 지정 솔루션을 빌드하는 대신 더 적절한 도구를 선택합니다.
참고 항목
워크로드를 완벽하게 지원하려면 많은 교차 역할 및 기술이 필요합니다. 데이터, 인프라, 보안 및 운영 팀은 모두 어느 정도 자동화에 의존합니다. 가능한 가장 적은 도구를 사용하고 표준화하여 자동화 전략을 관리하기 쉽고 쉽게 학습할 수 있도록 합니다.
DevOps 사례 수용
워크로드 개발 초기에 개발 프로세스에서 DevOps 사례를 표준 화합니다 . 샌드박스 환경 외에 모든 환경의 경우 엄격하게 정의되고 적용되는 표준이 전체 개발 수명 주기를 제어해야 합니다. 수동 배포 작업을 엄격히 금지하여 이러한 표준을 적용합니다. 업데이트, 패치 또는 새 리소스 배포에 관계없이 모든 배포는 안전한 배포 사례를 준수하는 지속적인 통합 및 지속적인 배포 파이프라인을 통해 수행해야 합니다. 좋은 DevOps 위생 사례에는 다음이 포함되어야 합니다.
버전 제어: 가능한 한 모든 코드 자산에 버전 제어를 사용합니다. 버전 제어는 DevOps의 초석이자 좋은 변경 관리 사례이며 원활한 협업에 매우 중요합니다. SDK 및 컨테이너 이미지를 포함하여 라이브러리 패키지에 버전 제어를 적용합니다. SDLC(소프트웨어 개발 수명 주기)에서 특정 버전의 라이브러리 패키지를 일관되게 사용해야 합니다. 다양한 개발 환경에서 XGBoost 또는 scikit-learn과 같은 다양한 버전의 라이브러리는 워크로드 동작에 변화를 일으킬 수 있습니다. 모델 버전 관리도 마찬가지입니다. 사전 프로덕션 환경에서 모델의 한 버전을 테스트하고 프로덕션 환경에서 다른 버전을 릴리스하지 않도록 모델 버전이 SDLC 전체에서 일관되는지 확인합니다.
간단한 버전 명명 체계: 간단한 버전 명명 체계를 사용하여 지정된 자산의 가장 최근에 승인된 버전을 항상 사용할 수 있도록 합니다. AI 관련 자산에는 다음이 포함될 수 있습니다.
- Notebook 코드입니다.
- 오케스트레이터 코드입니다.
- 데이터 처리 작업 코드입니다.
- Machine Learning 작업 코드입니다.
- 모델
조작할 수 있는 도구: 일부 도구는 실험에 적합하지만 운영화를 위해 설계되지 않았습니다. 이러한 제한으로 인해 운영 자동화에 통합하기가 어렵거나 불가능할 수 있습니다. 예를 들어 Notebook은 실험 및 예비 데이터 분석 작업에 적합한 도구이지만 프로덕션 파이프라인 개발 작업에 적합한 도구는 아닙니다. 실험을 완료하면 해당 도구에서 논리를 가져와 작업 코드에 사용할 수 있는 Python 패키지에 넣습니다.
좋은 설명서 사례 채택
좋은 설명서 습관은 모든 유형의 워크로드에 중요합니다. AI 워크로드의 복잡성으로 인해 이러한 습관이 더욱 중요해집니다. 문서가 안전하게 저장되고 버전이 제어되는 워크로드 팀과 관련된 리포지토리가 있는지 확인합니다. 다른 워크로드와 마찬가지로 표준 정보를 문서화해야 합니다. 이 표준 정보에는 워크로드, 보안 구성, 네트워크 디자인 및 설정 가이드에 사용되는 모든 도구가 포함됩니다. 다음 AI 관련 워크로드 정보를 문서화하는 것이 좋습니다.
모델 학습 및 접지 데이터 인덱스 관리 정보: 데이터 원본, 데이터 원본 소유자, 새로 고침 빈도 및 바이어스 제거 프로세스를 문서화하여 모델을 학습하는 방법과 접지 데이터를 처리하는 방법을 설정합니다.
학습 프로세스의 기록: 특정 하이퍼 매개 변수, 온도, 가중치 및 기타 매개 변수를 선택한 이유를 문서화하여 현재 승인된 구성에 도착한 방법을 자세히 설명합니다. 테스트한 다른 구성과 학습 프로세스 전체에서 관찰한 동작 변경 내용을 포함합니다. 이 정보는 실패하거나 비효율적인 구성의 반복을 방지하는 데 도움이 됩니다.
기능 저장소 정보: 예측 능력이 가장 뛰어난 기능과 해당 결정을 내린 방법을 문서화합니다.
데이터 과학자 워크스테이션 구성: 워크스테이션 구성을 철저히 문서화하여 데이터 과학자를 위한 온보딩 프로세스를 간소화합니다. conda 환경을 사용하는 데 필요한 라이브러리 및 종속성을 지정합니다.
데이터 변환 정보: 데이터 변환이 발생할 때 처음부터 끝까지 전체 프로세스를 문서화합니다. 수집 시 데이터가 표시되는 방식과 변환 후에 데이터가 표시되는 방식을 문서화합니다.
도구
MLFlow 및 Machine Learning을 통해 캡처되는 자동화된 구성 및 기록을 활용합니다.