Power BI Embedded의 다중 테넌시 앱에 대한 서비스 주체 프로필

이 문서에서는 많은 고객이 있는 ISV 또는 다른 Power BI Embedded 앱 소유자가 서비스 주체 프로필을 사용하여 각 고객의 데이터를 고객 솔루션에 대한 Power BI 포함의 일부로 매핑하고 관리하는 방법을 설명합니다. 서비스 주체 프로필을 사용하면 ISV는 보다 나은 고객 데이터 격리가 가능하고 고객 간에 보다 엄격한 보안 경계를 설정할 수 있는 확장 가능한 애플리케이션을 빌드할 수 있습니다. 이 문서에서는 이 솔루션의 장점과 제한에 대해 설명합니다.

참고 항목

Power BI의 단어 테넌트는 때때로 Microsoft Entra 테넌트를 참조할 수 있습니다. 그러나 이 문서에서는 다중 테넌시라는 용어를 사용하여 소프트웨어 애플리케이션의 단일 인스턴스가 데이터의 물리적 및 논리적 분리가 필요한 여러 고객 또는 조직(테넌트)을 제공하는 솔루션을 설명합니다. 예를 들어 Power BI 앱 빌더는 아래와 같이 고객(또는 테넌트)에 대해 별도의 작업 영역을 할당할 수 있습니다. 이러한 고객은 반드시 Microsoft Entra 테넌트가 아니므로 여기서 사용하는 용어 다중 테넌트 애플리케이션을 Microsoft Entra 다중 테넌트 애플리케이션과 혼동하지 마세요.

서비스 주체 프로필은 서비스 주체가 만든 프로필입니다. ISV 앱은 이 문서에 설명된 대로 서비스 주체 프로필을 사용하여 Power BI API를 호출합니다.

ISV 애플리케이션 서비스 주체는 각 고객 또는 테넌트에 대해 서로 다른 Power BI 프로필을 만듭니다. 고객이 ISV 앱을 방문하면 이 앱은 해당 프로필을 사용하여 브라우저에서 보고서를 렌더링하는 데 사용할 포함 토큰을 생성합니다.

서비스 주체 프로필을 사용하면 ISV 앱이 단일 Power BI 테넌트에 여러 고객을 호스트할 수 있습니다. 각 프로필은 Power BI의 한 고객을 나타냅니다. 즉, 각 프로필은 특정 고객 한 명의 데이터에 대한 Power BI 콘텐츠를 만들고 관리합니다.

참고 항목

이 문서는 서비스 주체 프로필을 사용하여 다중 테넌트 앱을 설정하려는 조직을 대상으로 합니다. 조직에 다중 테넌시를 지원하는 앱이 이미 있고 서비스 주체 프로필 모델로 마이그레이션하려는 경우 서비스 주체 프로필 모델로 마이그레이션을 참조하세요.

Power BI 콘텐츠를 설정하려면 다음 단계를 수행해야 합니다.

• 프로필 만들기
• 프로필 권한 설정
• 각 고객에 대한 작업 영역 만들기
• 작업 영역으로 보고서 및 의미 체계 모델 가져오기
• 고객의 데이터에 연결하기 위한 의미 체계 모델 연결 세부 정보 설정
• 서비스 주체에서 권한 제거(선택 사항이지만 확장성에 도움이 됨)
• 애플리케이션에 보고서 포함

위의 모든 단계는 Power BI REST API를 사용하여 완전히 자동화할 수 있습니다.

필수 조건

서비스 주체 프로필을 만들려면 다음을 수행해야 합니다.

• 서비스 주체에 Power BI 콘텐츠 포함의 처음 세 단계를 수행하여 서비스 주체를 설정합니다.
• Power BI 테넌트 관리자 계정에서 서비스 주체를 만들 때 사용한 것과 동일한 보안 그룹을 사용하여 테넌트에서 프로필 만들기를 사용하도록 설정합니다.

프로필 만들기

프로필 REST API를 사용하여 프로필을 만들고, 업데이트하고, 삭제할 수 있습니다.

예를 들어 프로필을 만들려면 다음을 수행합니다.

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

서비스 주체는 프로필 가져오기 REST API를 호출하여 프로필 목록을 가져올 수도 있습니다. 예시:

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

프로필 권한

Power BI 항목에 대한 사용자 권한을 부여하는 모든 API는 Power BI 항목에 대한 프로필 권한도 부여할 수 있습니다. 예를 들어 그룹 사용자 추가 API를 사용하여 작업 영역에 대한 프로필 권한을 부여할 수 있습니다.

프로필을 사용할 때는 다음 사항을 이해해야 합니다.

• 프로필은 프로필을 만든 서비스 주체에 속하며, 해당 서비스 주체만이 사용할 수 있습니다.
• 프로필을 만든 후에는 프로필 소유자를 변경할 수 없습니다.
• 프로필은 독립 실행형 ID가 아닙니다. Power BI REST API를 호출하려면 서비스 주체 Microsoft Entra 토큰이 필요합니다.

ISV 앱은 인증 헤더에 서비스 주체 Microsoft Entra 토큰과 X-PowerBI-Profile-Id 헤더의 프로필 ID를 제공하여 Power BI REST API를 호출합니다. 예시:

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

작업 영역 만들기

Power BI 작업 영역은 보고서 및 의미 체계 모델과 같은 Power BI 항목을 호스팅하는 데 사용됩니다.

각 프로필은 다음을 수행해야 합니다.

• 하나 이상의 Power BI 작업 영역 만들기

  POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXA…ZUiIsg
  Content-Type: application/json; charset=utf-8
  X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
  
  {
    "name": "ContosoWorkspace"
  }
  

• 작업 영역에 대한 액세스 권한 부여. 서비스 주체 프로필에는 작업 영역에 대한 관리 액세스 권한이 있어야 합니다.

• 작업 영역을 용량에 할당

  POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/AssignToCapacity HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
  Content-Type: application/json; charset=utf-8
  X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
  
  {
    "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
  }
  

Power BI 작업 영역에 대해 자세히 알아보세요.

보고서 및 의미 체계 모델 가져오기

Power BI Desktop을 사용하여 고객의 데이터 또는 샘플 데이터에 연결된 보고서를 준비합니다. 그런 다음, 가져오기 API를 사용하여 콘텐츠를 생성된 작업 영역으로 가져올 수 있습니다.

POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

데이터 세트 매개 변수를 사용하여 다양한 고객의 데이터 원본에 연결할 수 있는 의미 체계 모델을 만듭니다. 그런 다음 매개 변수 업데이트 API를 사용하여 의미 체계 모델이 연결되는 고객 데이터를 정의합니다.

의미 체계 모델 연결 설정

ISV는 일반적으로 다음 두 가지 방법 중 하나로 고객의 데이터를 저장합니다.

• 각 고객에게 별도의 데이터베이스 사용
• 단일 다중 테넌트 데이터베이스

두 경우 모두 Power BI에서 단일 테넌트 의미 체계 모델(고객당 하나의 의미 체계 모델)로 끝나야 합니다.

각 고객에게 별도의 데이터베이스 사용

ISV 애플리케이션에 각 고객에 대한 별도의 데이터베이스가 있는 경우 Power BI에서 단일 테넌트 의미 체계 모델을 만듭니다. 일치하는 데이터베이스를 가리키는 연결 세부 정보를 각 의미 체계 모델에 제공합니다. 서로 다른 연결 세부 정보를 사용하여 동일한 보고서를 여러 개 만드는 일이 없도록 다음 방법 중 하나를 사용합니다.

• 의미 체계 모델 매개 변수: 연결 세부 정보(예: SQL Server 이름, SQL 데이터베이스 이름)에 매개 변수를 사용하여 의미 체계 모델을 만듭니다. 그런 다음, 보고서를 고객의 작업 영역으로 가져오고 고객의 데이터베이스 세부 정보와 일치하도록 매개 변수를 변경합니다.

• Datasource API 업데이트: 샘플 콘텐츠가 포함된 데이터 원본을 가리키는 .pbix를 만듭니다. 그런 다음, .pbix를 고객의 작업 영역으로 가져오고 데이터 원본 업데이트 API를 사용하여 연결 세부 정보를 변경합니다.

단일 다중 테넌트 데이터베이스

ISV 애플리케이션이 모든 고객에 대해 하나의 데이터베이스를 사용하는 경우 다음과 같이 Power BI에서 고객을 다양한 의미 체계 모델로 구분합니다.

관련 고객의 데이터만 검색하는 매개 변수를 사용하여 보고서를 만듭니다. 그런 다음, 보고서를 고객의 작업 영역으로 가져오고 관련 고객의 데이터만 검색하도록 매개 변수를 변경합니다.

보고서 포함

설정이 완료되면 포함 토큰을 사용하여 고객 보고서 및 기타 항목을 애플리케이션에 포함할 수 있습니다.

고객이 애플리케이션을 방문할 때 해당 프로필을 사용하여 GenerateToken API를 호출합니다. 생성된 포함 토큰을 사용하여 보고서 또는 기타 항목을 고객의 브라우저에 포함할 수 있습니다.

포함 토큰을 생성하려면 다음을 수행합니다.

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

디자인 측면

프로필 기반 다중 테넌트 솔루션을 설정하기 전에 다음 문제를 알고 있어야 합니다.

• 확장성
• 자동화 및 운영 복잡성
• 다중 지역 요구 사항
• 비용 효율성
• 행 수준 보안

확장성

데이터를 각 고객에 대한 별도의 의미 체계 모델로 분리하면 대규모 의미 체계 모델의 필요성이 최소화됩니다. 용량이 과부하되면 사용되지 않는 의미 체계 모델을 제거하여 활성 의미 체계 모델을 위한 메모리를 확보할 수 있습니다. 이 최적화는 단일 대규모 의미 체계 모델에는 불가능합니다. 여러 의미 체계 모델을 사용하면 필요한 경우 테넌트를 여러 Power BI 용량으로 분리할 수도 있습니다.

프로필이 없으면 서비스 주체는 작업 영역 1,000로 제한됩니다. 이 제한을 극복하기 위해 서비스 주체는 각 프로필이 최대 1,000개의 작업 영역에 액세스/만들 수 있는 여러 프로필을 만들 수 있습니다. 프로필을 여러 개 사용하면 ISV 앱이 고유한 논리 컨테이너를 사용하여 각 고객의 콘텐츠를 격리할 수 있습니다.

서비스 주체 프로필이 작업 영역에 액세스할 수 있으면 확장성 문제를 방지하기 위해 부모 서비스 주체의 작업 영역에 대한 액세스 권한을 제거해도 됩니다.

이러한 장점이 있더라도 애플리케이션의 확장 가능성을 고려해야 합니다. 예를 들어 프로필에서 액세스할 수 있는 작업 영역 항목의 수는 제한되어 있습니다. 현재 일반 사용자와 동일한 제한이 프로필에 적용됩니다. ISV 애플리케이션에서 최종 사용자가 포함된 보고서의 개인 설정된 복사본을 저장할 수 있도록 허용하는 경우 고객의 프로필은 모든 사용자가 만든 모든 보고서에 액세스할 수 있습니다. 이 모델은 결국 제한을 초과할 수 있습니다.

자동화 및 운영 복잡성

Power BI 프로필 기반 분리를 사용하면 수백 또는 수천 개 항목을 관리해야 할 수도 있습니다. 따라서 애플리케이션 수명 주기 관리에서 자주 발생하는 프로세스를 정의하고, 이러한 작업을 대규모로 수행하기에 적합한 도구 세트를 갖추어야 합니다. 이러한 작업은 다음과 같습니다.

• 새 테넌트 추가
• 일부 또는 모든 테넌트의 보고서 업데이트
• 일부 또는 모든 테넌트에 대한 의미 체계 모델 스키마 업데이트
• 특정 테넌트의 계획되지 않은 사용자 지정
• 의미 체계 모델 새로 고침 빈도

예를 들어 새 테넌트의 프로필 및 작업 영역을 만드는 작업은 Power BI REST API를 사용하여 완전히 자동화할 수 있는 일반적인 작업입니다.

다중 지역 요구 사항

Power BI Embedded에 대한 다중 지역 지원은 Power BI Embedded를 사용하여 애플리케이션을 빌드해 앱에 분석 기능을 포함하는 ISV와 조직이 이제 전 세계 여러 지역에서 데이터를 배포할 수 있음을 의미합니다. 서로 다른 지역의 서로 다른 고객을 지원하려면 고객의 작업 영역을 원하는 지역의 용량에 할당해야 합니다. 이 작업은 추가 비용이 발생하지 않는 간단한 작업입니다. 그러나 여러 지역의 데이터가 필요한 고객이 있는 경우 테넌트 프로필은 모든 항목을 다른 지역 용량에 할당된 여러 작업 영역으로 복제해야 합니다. 이러한 중복으로 인해 비용과 관리 복잡성이 모두 증가할 수 있습니다.

규정 준수를 위해 여전히 여러 지역에 여러 Power BI 테넌트를 만들기를 원할 수 있습니다. 다중 지역에 대해 자세히 알아보세요.

비용 효율성

Power BI Embedded를 사용하는 애플리케이션 개발자는 Power BI Embedded 용량을 구매해야 합니다. 프로필 기반 분리 모델은 다음과 같은 이유로 용량과 잘 맞습니다.

• 용량에 독립적으로 할당할 수 있는 가장 작은 개체는 작업 영역입니다(예를 들어 보고서를 할당할 수 없음). 고객을 프로필별로 구분하면 고객당 하나씩 다른 작업 영역을 얻을 수 있습니다. 이렇게 하면 고객의 성능 요구 사항에 따라 각 고객을 관리하고, 스케일 업 또는 다운하여 용량 사용률을 최적화할 수 있습니다. 예를 들어 볼륨이 크고 변동성이 강한 대형 중요 고객은 별도의 용량으로 관리하여 일관적인 서비스 수준을 보장하고, 작은 고객은 또 다른 용량으로 그룹화하여 비용을 최적화할 수 있습니다.

• 작업 영역을 분리한다는 것은 데이터 모델이 하나의 큰 의미 체계 모델이 아닌 더 작은 덩어리에 있도록 테넌트 간에 의미 체계 모델을 분리하는 것을 의미하기도 합니다. 이러한 작은 모델을 사용하면 용량에서 메모리 사용량을 보다 효율적으로 관리할 수 있습니다. 작고 사용되지 않는 의미 체계 모델은 좋은 성능을 유지하기 위해 일정 기간 동안 작업이 없으면 제거될 수 있습니다.

의미 체계 모델이 여러 개 있으면 새로 고침 프로세스에 추가 용량이 필요할 수도 있으므로 용량을 구매할 때 병렬 새로 고침 횟수에 대한 제한을 고려해야 합니다.

행 수준 보안

이 문서에서는 프로필을 사용하여 각 고객에 대한 별도의 의미 체계 모델을 만드는 방법을 설명합니다. 또는 ISV 애플리케이션은 모든 고객의 데이터를 하나의 대규모 의미 체계 모델에 저장하고 RLS(행 수준 보안)를 사용하여 각 고객의 데이터를 보호할 수 있습니다. 이 방식은 고객 수가 비교적 적고 의미 체계 모델이 중소 규모인 ISV에 편리할 수 있습니다. 그 이유는 다음과 같습니다.

• 유지 관리할 보고서와 의미 체계 모델은 하나뿐입니다.
• 신규 고객의 온보딩 프로세스를 간소화할 수 있습니다.

그러나 RLS를 사용하기 전에 제한 사항을 이해해야 합니다. 모든 고객의 모든 데이터는 하나의 대규모 Power BI 의미 체계 모델에 있습니다. 이 의미 체계 모델은 자체 크기 조정 및 기타 제한 사항이 있는 단일 용량에서 실행됩니다.

서비스 주체 프로필을 사용하여 고객의 데이터를 분리하는 경우에도 단일 고객의 의미 체계 모델 내에서 RLS를 사용하여 다른 그룹에 데이터의 다른 부분에 대한 액세스 권한을 부여할 수 있습니다. 예를 들어 RLS를 사용하여 한 부서의 구성원이 같은 조직의 다른 부서 데이터에 액세스하지 못하도록 할 수 있습니다.

고려 사항 및 제한 사항

• 서비스 주체 프로필은 Power BI REST API 및 Power BI .NET SDK를 통해서만 지원됩니다. 서비스 주체 프로필은 XMLA 엔드포인트 또는 TOM(테이블 형식 개체 모델)을 통해 Power BI에서 지원되지 않습니다.
• 서비스 주체 프로필은 라이브 연결 모드의 AAS(Azure Analysis Services)에서 지원되지 않습니다.

Power BI 용량 제한

• 각 용량은 구매한 SKU에 따라 할당된 메모리 및 V 코어만 사용할 수 있습니다. 각 SKU에 권장되는 의미 체계 모델 크기는 프리미엄 대형 의미 체계 모델을 참조하세요.
• 10GB보다 큰 의미 체계 모델을 사용하려면 프리미엄 용량을 사용하고 대형 의미 체계 모델 설정을 사용하도록 설정합니다.
• 용량에서 동시에 실행될 수 있는 새로 고침 횟수는 리소스 관리 및 최적화를 참조하세요.

서비스 주체 관리

서비스 주체 변경

Power BI에서 프로필은 프로필을 만든 서비스 주체에 속합니다. 즉, 프로필을 다른 보안 주체와 공유할 수 없습니다. 이러한 제한이 있으므로, 어떤 이유로 서비스 주체를 변경하려면 모든 프로필을 다시 만들고 관련 작업 영역에 대한 액세스 권한을 새 프로필에 제공해야 합니다. ISV 애플리케이션은 필요할 때 올바른 프로필을 선택하기 위해 프로필 ID와 고객 ID 간의 매핑을 저장해야 하는 경우가 많습니다. 서비스 주체를 변경하고 프로필을 다시 만드는 경우 ID도 변경되며, ISV 애플리케이션 데이터베이스에서 매핑을 업데이트해야 할 수도 있습니다.

서비스 주체 삭제

Warning

서비스 주체를 삭제할 때는 매우 주의해야 합니다. 연결된 모든 프로필의 데이터가 실수로 손실되지 않도록 주의해야 합니다.

Active Directory에서 서비스 주체를 삭제하면 Power BI의 모든 해당 프로필이 삭제됩니다. 그러나 Power BI는 콘텐츠를 즉시 삭제하지 않으므로, 테넌트 관리자는 작업 영역에 계속 액세스할 수 있습니다. 프로덕션 시스템에서 사용되는 서비스 주체를 삭제할 때, 특히 Power BI에서 이 서비스 주체를 사용하여 프로필을 만든 경우에는 주의해야 합니다. 프로필을 만든 서비스 주체를 삭제하는 경우 모든 프로필을 다시 만들고, 관련 작업 영역에 대한 액세스 권한을 새 프로필에 제공하고, ISV 애플리케이션 데이터베이스에서 프로필 ID를 업데이트해야 합니다.

데이터 분리

데이터를 서비스 주체 프로필로 구분하면 프로필과 고객 간의 간단한 매핑으로 인해 한 고객이 다른 고객의 콘텐츠를 볼 수 없습니다. 단일 서비스 주체를 사용하려면 서비스 주체가 모든 프로필의 모든 다른 작업 영역에 액세스할 수 있어야 합니다.

분리를 추가하려면 단일 서비스 주체가 다른 프로필을 사용하여 여러 작업 영역에 액세스하도록 하는 대신 각 테넌트에게 별도의 서비스 주체를 할당하면 됩니다. 별도의 서비스 주체를 할당하면 다음을 비롯한 몇 가지 이점이 있습니다.

• 사용자 오류 또는 자격 증명 누출로 인해 여러 테넌트의 데이터가 노출되지 않습니다.
• 인증서 회전을 각 테넌트에 대해 개별적으로 수행할 수 있습니다.

그러나 여러 서비스 주체를 사용하면 높은 관리 비용이 발생합니다. 추가 분리가 필요한 경우에만 이 경로를 선택하세요. 최종 사용자를 표시할 데이터의 구성은 최종 사용자가 보거나 변경할 수 없는 백 엔드 전용 프로세스인 포함 토큰 생성 중에 정의됩니다. 테넌트별 프로필을 사용하여 포함 토큰을 요청하면 해당 프로필에 대한 포함 토큰이 생성되므로, 사용 시 고객이 분리됩니다.

하나의 보고서, 다중 의미 체계 모델

일반적으로 테넌트당 하나의 보고서와 하나의 의미 체계 모델이 있습니다. 수백 개의 보고서가 있으면 수백 개의 의미 체계 모델을 갖게 됩니다. 때로는 다른 의미 체계 모델(예: 다른 매개 변수 또는 연결 세부 정보)이 포함된 하나의 보고서 형식이 있을 수 있습니다. 새 버전의 보고서가 있을 때마다 모든 테넌트에 대한 모든 보고서를 업데이트해야 합니다. 이 작업을 자동화할 수 있지만, 보고서의 복사본이 하나만 있으면 관리하기가 더 쉽습니다. 포함할 보고서가 들어 있는 작업 영역 만들기 세션 런타임 중에 보고서를 테넌트별 의미 체계 모델에 바인딩합니다. 자세한 내용은 동적 바인딩을 읽어보세요.

콘텐츠 사용자 지정 및 제작

콘텐츠를 만들 때 콘텐츠를 편집할 수 있는 권한을 가지고 있는 사용자를 신중하게 고민해야 합니다. 각 테넌트의 여러 사용자가 편집할 수 있도록 허용하면 의미 체계 모델 제한 사항을 초과하기 쉽습니다. 사용자에게 편집 기능을 제공하기로 결정하는 경우 사용자의 콘텐츠 생성을 긴밀하게 모니터링하고 필요에 따라 스케일 업합니다. 같은 이유로, 각 사용자가 직접 보고서를 약간 변경하고 저장할 수 있는 콘텐츠 개인 설정에는 이 기능을 사용하지 않는 것이 좋습니다. ISV 애플리케이션에서 콘텐츠 개인 설정을 허용하는 경우 사용자별 콘텐츠에 대한 작업 영역 보존 정책을 도입하는 것이 좋습니다. 보존 정책을 사용하면 사용자가 새 직위로 이동하거나, 퇴사하거나, 플랫폼 사용을 중지할 때 콘텐츠를 더 쉽게 삭제할 수 있습니다.

시스템 관리 ID

서비스 주체 대신 사용자가 할당한 또는 시스템이 할당한 관리 ID를 사용하여 프로필을 만들 수 있습니다. 관리 ID를 사용하면 비밀과 인증서의 필요성이 감소합니다.

시스템이 할당한 관리 ID를 사용할 때는 다음과 같은 이유로 주의해야 합니다.

• 시스템이 할당한 관리 ID가 실수로 꺼지면 프로필에 대한 액세스 권한이 손실됩니다. 이 상황은 서비스 주체가 삭제되는 경우와 비슷합니다.
• 시스템이 할당한 관리 ID는 Azure의 리소스(웹앱)에 연결됩니다. 리소스를 삭제하면 ID가 삭제됩니다.
• 여러 리소스(다른 지역의 다른 웹앱)를 사용하면 여러 ID를 개별적으로 관리해야 합니다(ID마다 자체 프로필이 있음).

위의 고려 사항으로 인해 사용자가 할당한 관리 ID를 사용하는 것이 좋습니다.

예시

서비스 주체 프로필을 사용하여 Power BI 및 앱 소유 데이터 포함으로 다중 테넌트 환경을 관리하는 방법에 대한 예제를 보려면 Power BI 개발자 캠프(타사 사이트)에서 앱 소유 데이터 다중 테넌트 리포지토리를 다운로드하세요.

관련 콘텐츠

• 서비스 주체와 함께 Power BI SDK 사용
• 다중 테넌시 앱을 서비스 주체 프로필 모델로 마이그레이션
• Power BI 포함을 사용하여 스케일링 가능한 다중 테넌트 애플리케이션 개발