다음을 통해 공유

조직 전체에 Microsoft Foundry를 롤아웃

비고

이 문서는 Microsoft Foundry(클래식) 포털을 참조합니다.

🔄새 포털을 사용하는 경우 Microsoft Foundry(새) 설명서로 전환합니다.

비고

이 문서는 Microsoft Foundry(신규) 포털을 참조합니다.

이 가이드에서는 환경 설정, 데이터 격리, 다른 Azure 서비스와의 통합, 용량 관리 및 모니터링을 포함하여 Microsoft Foundry를 롤아웃하기 위한 주요 결정에 대해 간략하게 설명합니다. 이 가이드를 시작점으로 사용하여 필요에 맞게 조정합니다. 구현 세부 정보는 추가 지침에 대한 연결된 문서를 참조하세요.

조직 예제

Contoso는 각각 고유한 요구 사항과 기술적 완성도를 가진 5개 비즈니스 그룹에서 GenAI 채택을 탐구하는 글로벌 기업입니다.

감독을 유지하면서 채택을 가속화하기 위해 Contoso Enterprise IT는 네트워킹 및 중앙 집중식 데이터 관리를 비롯한 공통 공유 리소스가 있는 모델을 사용하도록 설정하는 동시에 관리되는 안전한 환경 내의 각 팀에 대해 Foundry에 대한 셀프 서비스 액세스를 사용하도록 설정하여 사용 사례를 관리하는 것을 목표로 합니다.

롤아웃 고려사항

Foundry 리소스는 팀 환경을 구성, 보안 및 모니터링하는 범위를 정의합니다. Foundry 포털 및 Azure API를 통해 사용할 수 있습니다. 프로젝트는 이 리소스 컨텍스트 내에서 작업을 구성하는 폴더와 같습니다. 또한 프로젝트는 Foundry 개발자 API 및 도구에 대한 액세스 및 권한을 제어합니다.

Foundry 리소스를 보여 주는 다이어그램의 스크린샷

팀 전체에서 일관성, 확장성 및 거버넌스를 보장하려면 Foundry를 롤아웃할 때 다음 환경 설정 사례를 고려합니다.

  • 개발, 테스트 및 프로덕션을 위한 고유한 환경을 설정합니다. 별도의 리소스 그룹 또는 구독 및 Foundry 리소스를 사용하여 워크플로를 격리하고, 액세스를 관리하고, 제어된 릴리스로 실험을 지원합니다.

  • 각 비즈니스 그룹에 대해 별도의 Foundry 리소스를 만듭니다. 데이터 도메인 또는 비즈니스 기능과 같은 논리적 경계에 배포를 정렬하여 자율성, 거버넌스 및 비용 추적을 보장합니다.

  • 프로젝트를 사용 사례와 연결합니다. Foundry 프로젝트는 특정 사용 사례를 나타내도록 설계되었습니다. 애플리케이션에 대한 에이전트 또는 파일과 같은 구성 요소를 구성하는 컨테이너입니다. 부모 리소스에서 보안 설정을 상속하는 동안 자체 액세스 제어, 데이터 통합 및 기타 거버넌스 컨트롤을 구현할 수도 있습니다.

Foundry 환경 보호

Foundry는 Azure 플랫폼을 기반으로 하므로 조직의 요구 사항에 맞게 보안 제어를 사용자 지정할 수 있습니다. 주요 구성 영역은 다음과 같습니다.

  • ID: Microsoft Entra ID를 사용하여 사용자 및 서비스 액세스를 관리합니다. Foundry는 관리 ID를 지원하여 다른 Azure 서비스에 대한 안전하고 암호 없는 인증을 허용합니다. 세분화된 제어를 위해 Foundry 리소스 수준에서 관리 ID를 할당하고 필요에 따라 프로젝트 수준에서 관리 ID를 할당할 수 있습니다.  관리 ID에 대해 자세히 알아봅니다.

  • 네트워킹: NSG(네트워크 보안 그룹)를 사용하여 트래픽을 격리하고 액세스를 제어하기 위해 Virtual Network에 Foundry를 배포합니다.  네트워킹 보안에 대해 자세히 알아봅니다.

  • CMK(Customer-Managed 키): Azure는 미사용 데이터를 암호화하기 위한 CMK를 지원합니다. Foundry는 엄격한 규정 준수 요구 사항이 있는 고객을 위해 선택적으로 CMK를 지원합니다.  CMK에 대해 자세히 알아봅니다.

  • 인증 및 권한 부여: Foundry는 간단한 통합을 위한 API 키 기반 액세스 와 세분화된 제어를 위한 Azure RBAC 를 모두 지원합니다. Azure는 제어 평면 (리소스 관리)과 데이터 평면 (모델 및 데이터 액세스) 간에 명확한 분리를 적용합니다. 기본 제공 역할로 시작하고 필요에 따라 사용자 지정 역할을 정의합니다.  인증에 대해 자세히 알아봅니다.

  • 템플릿: ARM 템플릿 또는 Bicep을 사용하여 보안 배포를 자동화합니다. 샘플 템플릿을 탐색합니다.

  • 스토리지 리소스: Foundry에서 기본 제공 스토리지 기능을 사용하거나 사용자 고유의 스토리지 리소스를 사용하도록 선택할 수 있습니다. 에이전트 서비스의 경우 스레드 및 메시지는 필요에 따라 사용자가 관리하는 리소스에 저장할 수 있습니다.

예: Contoso의 보안 접근 방식

Contoso는 중앙 허브 네트워크를 관리하는 엔터프라이즈 IT와 프라이빗 네트워킹을 사용하여 Foundry 배포를 보호합니다. 각 비즈니스 그룹은 스포크 가상 네트워크를 통해 연결합니다. 기본 제공 RBAC(역할 기반 액세스 제어)를 사용하여 액세스를 구분합니다.

  • 관리자는 배포, 연결 및 공유 리소스를 관리합니다.
  • 프로젝트 관리자가 특정 프로젝트를 감독합니다.
  • 사용자가 GenAI 도구와 상호 작용

대부분의 사용 사례에서 Contoso는 기본적으로 Microsoft 관리형 암호화를 사용하며 Customer-Managed 키를 사용하지 않습니다.

사용자 액세스 계획

효과적인 액세스 관리는 안전하고 확장 가능한 Foundry 설정의 기초입니다.

  • 필요한 액세스 역할 및 책임 정의
    • Foundry 환경의 다양한 측면에 액세스해야 하는 사용자 그룹을 식별합니다.
    • 다음과 같은 책임에 따라 기본 제공 또는 사용자 지정 Azure RBAC 역할을 할당합니다.
      • 계정 소유자: 보안 및 공유 리소스 연결과 같은 최상위 구성을 관리합니다.
      • 프로젝트 관리자: Foundry 프로젝트 및 해당 참가자를 만들고 관리합니다.
      • 프로젝트 사용자: 기존 프로젝트에 기여합니다.
  • 액세스 범위 확인
    • 액세스 할당에 적합한 범위를 선택합니다.
      • 구독 수준: 가장 광범위한 액세스, 일반적으로 중앙 IT 또는 플랫폼 팀 또는 소규모 조직에 적합합니다.
      • 리소스 그룹 수준: 공유 액세스 정책을 사용하여 관련 리소스를 그룹화할 때 유용합니다. 예를 들어 Foundry 환경과 동일한 애플리케이션 수명 주기를 따르는 Azure Function입니다.
      • 리소스 또는 프로젝트 수준: 특히 중요한 데이터를 처리하거나 셀프 서비스를 사용하도록 설정할 때 세분화된 제어에 적합합니다.
  • 아이덴티티 전략 정렬
    • Foundry와 통합된 데이터 원본 및 도구의 경우 다음을 사용하여 사용자가 인증해야 하는지 여부를 결정합니다.
      • 관리 ID 또는 API 키: 사용자 간에 자동화된 서비스 및 공유 액세스에 적합합니다.
      • 사용자 ID: 사용자 수준 책임 또는 감사가 필요한 경우 선호됩니다.
    • Microsoft Entra ID 그룹을 사용하여 액세스 관리를 간소화하고 환경 간 일관성을 보장합니다.

다른 Azure 서비스와의 연결 설정

Foundry는 Azure 및 비 Azure 서비스의 애플리케이션 구성 요소에 액세스할 수 있도록 하는 재사용 가능한 구성인 연결을 지원합니다. 또한 이러한 연결은 ID 브로커 역할을 하므로 Foundry는 프로젝트 사용자를 대신하여 관리 ID 또는 서비스 주체를 사용하여 외부 시스템에 인증할 수 있습니다.

Azure Storage 또는 Key Vault와 같은 공유 서비스에 대한 Foundry 리소스 수준에서 연결을 만듭니다. 중요한 통합 또는 프로젝트별 통합을 위해 특정 프로젝트에 대한 연결 범위를 지정합니다. 이러한 유연성을 통해 팀은 필요에 따라 재사용과 격리의 균형을 맞출 수 있습니다. Foundry의 연결에 대해 자세히 알아봅니다.

간소화된 관리 및 온보딩을 위해 Microsoft Entra ID 관리 ID 또는 API 키와 같은 공유 액세스 토큰 또는 중요한 데이터 원본에 액세스할 때 더 큰 제어를 제공하는 Entra ID 통과를 통한 사용자 토큰을 사용하도록 연결 인증을 구성합니다.

Foundry 프로젝트 연결 및 다른 Azure 서비스와의 통합을 보여 주는 다이어그램의 스크린샷

예: Contoso의 연결 전략

  • Contoso는 모든 비즈니스 그룹에 대해 Foundry 리소스를 만들어 유사한 데이터가 필요한 프로젝트가 동일한 연결된 리소스를 공유하도록 합니다.
  • 기본적으로 연결된 리소스는 공유 인증 토큰을 사용하며 모든 프로젝트에서 공유됩니다.
  • 중요한 데이터 워크로드를 사용하는 프로젝트는 프로젝트 범위 연결 및 Microsoft Entra ID 통과 인증을 사용하여 데이터 원본에 연결합니다.

거버넌스

Foundry의 효과적인 거버넌스는 비즈니스 그룹 전체에서 안전하고 규정을 준수하며 비용 효율적인 운영을 보장합니다.

  • Azure Policy를 사용하여 모델 액세스 제어 Azure Policy는 Azure 리소스에 규칙을 적용합니다. Foundry에서 정책을 사용하여 특정 비즈니스 그룹이 액세스할 수 있는 모델 또는 모델 패밀리를 제한합니다. 예: Contoso의 재무 및 위험 그룹은 비즈니스 그룹의 구독 수준에서 정책을 적용하여 미리 보기 또는 비규격 모델을 사용할 수 없습니다.
  • 비즈니스 그룹별 Cost Management Contoso는 비즈니스 그룹별로 Foundry를 배포하여 비용을 독립적으로 추적하고 관리할 수 있습니다. Microsoft Cost Management를 사용하여 Foundry 배포 또는 프로젝트당 자세한 사용량 및 지출을 볼 수 있습니다.
  • Azure Monitor를 사용하여 사용량 추적 Azure Monitor는 Foundry 리소스의 사용 패턴, 성능 및 상태를 추적하는 메트릭 및 대시보드를 제공합니다.
  • Azure Log Analytics를 사용한 상세 로깅 Azure Log Analytics를 활용하면 운영 인사이트를 얻기 위해 로그를 깊이 검사할 수 있습니다. 예를 들어 감사 및 최적화를 지원하기 위한 로그 요청 사용, 토큰 사용량 및 대기 시간이 있습니다.

모델 배포 구성 및 최적화

Foundry에서 모델을 배포할 때 팀은 표준 배포 유형과 프로비전된 배포 유형 중에서 선택할 수 있습니다. 표준 배포는 개발 및 실험에 적합하며 유연성과 설정의 용이성을 제공합니다. 프로비전된 배포는 예측 가능한 성능, 비용 제어 및 모델 버전 고정이 필요한 프로덕션 시나리오에 권장됩니다.

지역 간 시나리오를 지원하고 기존 모델 배포에 액세스할 수 있도록 Foundry는 다른 Foundry 또는 Azure OpenAI 인스턴스에서 호스트되는 모델 배포에 대한 연결을 허용합니다. 팀은 연결을 사용하여 배포를 실험용으로 중앙 집중화하면서 분산 프로젝트에서 액세스를 사용하도록 설정할 수 있습니다. 프로덕션 워크로드의 경우 사용 사례가 자체 배포를 관리하여 모델 수명 주기, 버전 관리 및 롤백 전략을 보다 엄격하게 제어하도록 하는 것이 좋습니다.

과용을 방지하고 공정한 리소스 할당을 보장하기 위해 배포 수준에서 TPM(분당 토큰) 제한을 적용할 수 있습니다. TPM 제한은 사용량을 제어하고, 우발적인 급증으로부터 보호하고, 프로젝트 예산 또는 할당량에 맞게 사용량을 조정하는 데 도움이 됩니다. 공유 배포에 대한 보수적 제한을 설정하고 중요한 프로덕션 서비스에 대한 임계값을 높이는 것이 좋습니다.

Azure AI Hub를 사용하여 확장 기능 액세스

Foundry 리소스만으로도 대부분의 Foundry 기능에 액세스할 수 있지만, 선택 기능은 현재 Azure Machine Learning에서 제공하는 Azure AI 허브 리소스와 함께만 사용할 수 있습니다. 이러한 기능은 AI 개발 스택에서 더 낮으며 모델 사용자 지정에 초점을 맞춥니다.

허브 리소스에는 Azure Machine Learning Studio, SDK 또는 CLI를 사용하여 액세스할 수 있는 자체 프로젝트 형식이 필요합니다. 배포를 계획하는 데 도움이 되도록 이 표를 참조하고 지원되는 기능에 대한 개요에 대한 리소스 유형을 선택합니다 .

Foundry 리소스와 함께 허브 리소스를 배포합니다. 허브 리소스는 Foundry 리소스에 대한 종속성을 사용하여 선택한 도구 및 모델에 대한 액세스를 제공합니다.

더 알아보세요

  • Last updated on