Power BI 포함을 사용하여 스케일링 가능한 다중 테넌트 애플리케이션 개발
이 문서에서는 최고 수준의 확장성, 성능 및 보안을 달성하면서 Power BI 콘텐츠를 포함하는 다중 테넌트 애플리케이션을 개발하는 방법을 설명합니다. 서비스 주체 프로필을 사용하여 애플리케이션을 설계하고 구현하면 100,000명 이상의 사용자에게 보고서를 제공할 수 있는 수만 개의 고객 테넌트로 구성된 다중 테넌트 솔루션을 만들고 관리할 수 있습니다.
서비스 주체 프로필은 Power BI에서 조직 콘텐츠를 보다 쉽게 관리하고 용량을 더 효율적으로 사용할 수 있게 해주는 기능입니다. 그러나 서비스 주체 프로필을 사용하면 애플리케이션 디자인이 훨씬 복잡해질 수 있습니다. 따라서 상당한 규모가 필요한 경우에만 사용해야 합니다. 작업 영역이 많고 애플리케이션 사용자가 1,000명이 넘는 경우에 서비스 주체 프로필을 사용하는 것이 좋습니다.
참고 항목
확장에 대한 필요성이 증가하고 최고 수준의 보안 및 테넌트 격리를 달성해야 할 필요성이 증가함에 따라 서비스 주체 프로필을 사용할 때의 가치도 높아집니다.
조직용 임베드와 고객용 임베드의 두 가지 임베딩 시나리오를 사용하여 Power BI 임베딩을 달성할 수 있습니다.
조직용 임베드 시나리오는 애플리케이션의 대상이 내부 사용자로 구성되는 경우에 적용됩니다. 내부 사용자는 조직 계정을 가지고 있으며 Microsoft Entra ID(이전의 Azure Active Directory)로 인증해야 합니다. 이 시나리오에서 Power BI는 SaaS(Software-as-a-Service)입니다. 이 시나리오를 사용자 소유 데이터라고도 합니다.
고객용 임베드 시나리오는 애플리케이션의 대상이 외부 사용자로 구성되는 경우에 적용됩니다. 애플리케이션은 사용자 인증하는 역할을 합니다. Power BI 콘텐츠에 액세스하기 위해 애플리케이션은 포함 ID(Microsoft Entra 서비스 주체 또는 마스터 사용자 계정)를 사용하여 Microsoft Entra로 인증합니다. 이 시나리오에서 Power BI는 PaaS(Platform-as-a-Service)입니다. 이 시나리오를 앱 소유 데이터라고도 합니다.
참고 항목
서비스 주체 프로필 기능은 고객용 임베드 시나리오에서 사용하도록 설계되었다는 것을 이해하는 것이 중요합니다. 이 시나리오는 많은 수의 사용자와 고객 테넌트의 더 큰 규모로 포함할 수 있는 기능을 ISV 및 엔터프라이즈 조직에 제공하기 때문입니다.
다중 테넌트 애플리케이션 개발
Microsoft Entra에 익숙한 경우 테넌트라는 단어가 Microsoft Entra 테넌트를 생각하게 할 수 있습니다. 그러나 Power BI 콘텐츠를 포함하는 다중 테넌트 솔루션을 빌드하는 컨텍스트에서는 테넌트 개념이 다릅니다. 이 컨텍스트에서 고객 테넌트는 애플리케이션이 고객용 임베드 시나리오를 사용하여 Power BI 콘텐츠를 포함하는 각 고객을 대신하여 만들어집니다. 일반적으로 단일 Power BI 작업 영역을 만들어 각 고객 테넌트를 프로비전합니다.
확장 가능한 다중 테넌트 솔루션을 만들기 위해서는 새 고객 테넌트 만들기를 자동화할 수 있어야 합니다. 새 고객 테넌트를 프로비전하려면 일반적으로 Power BI REST API를 사용하여 새 Power BI 작업 영역을 만들고, Power BI Desktop(.pbix) 파일을 가져와 의미 체계 모델(이전에는 데이터 세트라고 함)을 만들고, 데이터 원본 매개 변수를 업데이트하고, 데이터 원본 자격 증명을 설정하고, 예약된 의미 체계 모델 새로 고침을 설정하는 코드를 작성해야 합니다. 다음 다이어그램에서는 보고서 및 의미 체계 모델과 같은 Power BI 항목을 작업 영역에 추가하여 고객 테넌트를 설정하는 방법을 보여 줍니다.
고객용 임베드 시나리오를 사용하는 애플리케이션을 개발하는 경우 마스터 사용자 계정 또는 서비스 주체인 포함 ID를 사용하여 Power BI REST API 호출을 수행할 수 있습니다. 프로덕션 애플리케이션에 서비스 주체를 사용하는 것이 좋습니다. 가장 높은 보안을 제공하며 이러한 이유로 Microsoft Entra에서 권장하는 접근 방식입니다. 또한 더 나은 자동화 및 스케일링을 지원하며 관리 오버헤드가 줄어듭니다. 그러나 설정 및 관리하려면 Power BI 관리자 권한이 필요합니다.
서비스 주체를 사용하면 사용자가 MFA(다단계 인증)를 사용하여 로그인해야 하는 환경에서 인증 오류와 같이 마스터 사용자 계정과 관련된 일반적인 문제를 방지할 수 있습니다. 또한 서비스 주체를 사용하는 것은 고객용 임베드 시나리오가 SaaS 개념이 아닌 PaaS 개념을 사용하여 Power BI 콘텐츠 포함을 기반으로 한다는 생각과도 일치합니다.
1,000개 작업 영역 제한
고객용 임베드를 구현하는 다중 테넌트 환경을 디자인할 경우 포함 ID에는 1,000개를 초과하는 작업 영역에 대한 액세스 권한을 부여할 수 없다는 점을 고려해야 합니다. Power BI 서비스는 REST API 호출을 수행할 때 높은 성능을 보장하기 위해 이 제한을 적용합니다. 이 제한을 적용하는 이유는 Power BI가 각 ID에 대한 보안 관련 메타데이터를 유지 관리하는 방법과 관련이 있습니다.
Power BI는 메타데이터를 사용하여 ID가 액세스할 수 있는 작업 영역 및 작업 영역 항목을 추적합니다. 실제로 Power BI는 권한 부여 하위 시스템에서 각 ID에 대해 별도의 ACL(액세스 제어 목록)을 유지 관리해야 합니다. ID가 작업 영역에 액세스하기 위해 REST API를 호출하는 경우 Power BI는 ID의 ACL에 대한 보안 검사를 수행하여 권한이 부여되었는지 확인해야 합니다. 작업 영역 수가 증가함에 따라 대상 작업 영역이 ACL 내에 있는지 여부를 확인하는 데 걸리는 시간이 기하급수적으로 증가합니다.
참고 항목
Power BI는 코드를 통해 1,000개 작업 영역 제한을 적용하지 않습니다. 이 방법을 시도하면 1,000개를 초과하는 작업 영역에 포함 ID가 추가되며 REST API 호출은 여전히 성공적으로 실행됩니다. 그러나 애플리케이션이 지원되지 않는 상태로 전환되는데, 이는 Microsoft 지원에서 도움을 요청하려고 할 때 영향을 미칠 수 있습니다.
두 개의 다중 테넌트 애플리케이션이 각각 단일 서비스 주체를 사용하도록 설정된 시나리오를 생각해 봅니다. 이제 첫 번째 애플리케이션이 990개의 작업 영역을 만들었으며 두 번째 애플리케이션은 1,010개의 작업 영역을 만들었다고 생각해 봅니다. 지원 관점에서 첫 번째 애플리케이션은 지원되는 경계 내에 있지만 두 번째 애플리케이션은 그렇지 않습니다.
이제 이 두 애플리케이션을 성능 관점에서만 비교해 봅니다. 두 서비스 주체의 ACL이 해당 ACL에 대한 메타데이터를 어느 정도 성능이 저하되는 지점까지 증가하도록 허용했기 때문에 그다지 큰 차이는 없습니다.
여기서 관찰할 주요 사항은 서비스 주체가 만든 작업 영역의 수가 성능 및 확장성에 직접적인 영향을 준다는 점입니다. 100개의 작업 영역 멤버인 서비스 주체는 1,000개의 작업 영역 멤버인 서비스 주체보다 더 빠르게 REST API 호출을 실행합니다. 마찬가지로 10개의 작업 영역 멤버인 서비스 주체는 100개의 작업 영역 멤버인 서비스 주체보다 더 빠르게 REST API 호출을 실행합니다.
Important
성능 및 확장성의 관점에서 서비스 주체가 멤버인 최적의 작업 영역 수는 정확히 1개입니다.
의미 체계 모델 및 데이터 원본 자격 증명에 대한 격리를 관리합니다.
다중 테넌트 애플리케이션을 디자인할 때 또 다른 중요한 측면은 고객 테넌트의 격리입니다. 한 고객 테넌트의 사용자에게 다른 고객 테넌트에 속하는 데이터가 표시되지 않도록 해야 합니다. 따라서 의미 체계 모델 소유권 및 데이터 원본 자격 증명을 관리하는 방법을 이해해야 합니다.
의미 체계 모델 소유권
각 Power BI 의미 체계 모델에는 단일 소유자가 있으며, 이 소유자는 사용자 계정 또는 서비스 주체일 수 있습니다. 예약된 새로 고침을 설정하고 의미 체계 모델 매개 변수를 설정하려면 의미 체계 모델 소유권이 필요합니다.
팁
Power BI 서비스에서는 의미 체계 모델 설정을 열어 의미 체계 모델 소유자가 누구인지 확인할 수 있습니다.
필요한 경우 의미 체계 모델의 소유권을 다른 사용자 계정 또는 서비스 주체로 이전할 수 있습니다. 이 작업은 Power BI 서비스에서 수행하거나 REST API TakeOver 작업을 사용하여 수행할 수 있습니다. 서비스 주체를 사용하여 새 의미 체계 모델을 만들기 위해 Power BI Desktop 파일을 가져오면 서비스 주체가 의미 체계 모델 소유자로 자동으로 설정됩니다.
데이터 원본 자격 증명
의미 체계 모델을 기본 데이터 원본에 연결하려면 의미 체계 모델 소유자가 데이터 원본 자격 증명을 설정해야 합니다. 데이터 원본 자격 증명은 Power BI에 의해 암호화 및 캐시됩니다. 이 시점에서 Power BI는 데이터를 새로 고칠 때(스토리지 테이블 가져오기용) 또는 통과 쿼리를 실행할 때(DirectQuery 스토리지 테이블용) 이러한 자격 증명을 사용하여 기본 데이터 원본으로 인증합니다.
새 고객 테넌트를 프로비전할 때 일반적인 디자인 패턴을 적용하는 것이 좋습니다. 다음과 같이 서비스 주체의 ID를 사용하여 일련의 REST API 호출을 실행할 수 있습니다.
- 새 작업 영역을 만듭니다.
- 새 작업 영역을 전용 용량과 연결합니다.
- Power BI Desktop 파일을 가져와 의미 체계 모델을 만듭니다.
- 해당 의미 체계 모델에 대한 의미 체계 모델 원본 자격 증명을 설정합니다.
이러한 REST API 호출이 완료되면 서비스 주체는 새 작업 영역의 관리자 및 해당 의미 체계 모델과 데이터 원본 자격 증명의 소유자가 됩니다.
Important
의미 체계 모델 데이터 원본 자격 증명이 작업 영역 수준으로 범위가 지정된다는 일반적인 오해가 있습니다. 이는 사실이 아닙니다. 데이터 원본 자격 증명은 서비스 주체(또는 사용자 계정)로 범위가 지정되며 해당 범위는 Microsoft Entra 테넌트의 모든 Power BI 작업 영역으로 확장됩니다.
다음 다이어그램과 같이 서비스 주체가 고객 테넌트의 여러 작업 영역에서 의미 체계 모델에 의해 공유되는 데이터 원본 자격 증명을 만들 수 있습니다.
다른 고객 테넌트에 속한 의미 체계 모델이 데이터 원본 자격 증명을 공유하는 경우 고객 테넌트는 완전히 격리되지 않습니다.
서비스 주체 프로필 이전의 디자인 전략
서비스 주체 프로필 기능을 사용할 수 있게 되기 전의 디자인 전략을 이해하면 이 기능의 필요성을 이해하는 데 도움이 될 수 있습니다. 이전에는 개발자가 다음 세 가지 디자인 전략 중 하나를 사용하여 다중 테넌트 애플리케이션을 빌드했습니다.
- 단일 서비스 주체
- 서비스 주체 풀링
- 작업 영역당 하나의 서비스 주체
이러한 각 디자인 전략에는 강점과 약점이 있습니다.
단일 서비스 주체 디자인 전략은 Microsoft Entra 앱 등록을 한 번만 만들어야 합니다. 따라서 더 많은 Microsoft Entra 앱 등록을 만들 필요가 없기 때문에 다른 두 디자인 전략보다 관리 오버헤드가 적습니다. 또한 이 전략은 REST API 호출을 수행할 때 서비스 주체 간에 호출 컨텍스트를 전환하는 추가 코드를 작성할 필요가 없기 때문에 가장 간단하게 설정할 수 있습니다. 그러나 이 디자인 전략의 문제는 규모를 조정할 수 없다는 것입니다. 최대 1,000개의 작업 영역까지 확장할 수 있는 다중 테넌트 환경만 지원합니다. 또한 서비스 주체에 많은 수의 작업 영역에 대한 액세스 권한이 부여되므로 성능이 저하됩니다. 단일 서비스 주체가 모든 고객 테넌트의 모든 의미 체계 모델 및 모든 데이터 자격 증명의 소유자가 되기 때문에 고객 테넌트 격리에도 문제가 있습니다.
서비스 주체 풀링 디자인 전략은 일반적으로 1,000개의 작업 영역 제한을 방지하기 위해 사용됩니다. 풀에 정확한 수의 서비스 주체를 추가하여 애플리케이션을 원하는 수의 작업 영역으로 확장할 수 있습니다. 예를 들어 5개의 서비스 주체 풀을 사용하면 최대 5,000개의 작업 영역까지 확장할 수 있습니다. 80개의 서비스 주체 풀을 사용하면 최대 80,000개의 작업 영역까지 확장할 수 있습니다. 그러나 이 전략은 많은 수의 작업 영역으로 확장할 수 있지만 몇 가지 단점이 있습니다. 먼저 REST API를 호출할 때 서비스 주체 간에 컨텍스트 전환을 허용하도록 추가 코드를 작성하고 메타데이터를 저장해야 합니다. 둘째, 풀의 서비스 주체 수를 늘려야 할 때마다 Microsoft Entra 앱 등록을 만들어야 하기 때문에 더 많은 관리 작업이 필요합니다.
게다가 서비스 주체가 수백 개의 작업 영역의 멤버가 될 수 있으므로 서비스 주체 풀링 전략은 성능에 최적화되지 않습니다. 또한 서비스 주체가 고객 테넌트 간에 공유되는 의미 체계 모델 및 데이터 자격 증명의 소유자가 될 수 있으므로 고객 테넌트 격리의 관점에서 이상적이지 않습니다.
작업 영역당 하나의 서비스 주체 디자인 전략에는 각 고객 테넌트용 서비스 주체를 만드는 것이 포함됩니다. 이론적 관점에서 이 전략은 작업 영역 수준에서 의미 체계 모델 및 데이터 원본 자격 증명에 대한 진정한 격리를 제공하면서 REST API 호출 성능을 최적화하기 때문에 최상의 솔루션을 제공합니다. 그러나 이론적으로 가장 잘 작동한다고 해서 실제로도 최상의 효과를 내는 것은 아닙니다. 이는 각 고객 테넌트의 서비스 주체를 만들기 위한 요구 사항이 많은 조직에서 비실용적이기 때문입니다. 일부 조직에는 공식적인 승인 프로세스가 있거나 Microsoft Entra 앱 등록을 만들기 위한 과도한 요식 체계가 있기 때문입니다. 이러한 이유로 인해 요청 시 그리고 솔루션에 필요한 자동화된 방식으로 Microsoft Entra 앱 등록을 만드는 데 필요한 권한을 사용자 지정 애플리케이션에 부여하는 것이 불가능할 수 있습니다.
사용자 지정 애플리케이션에 적절한 권한이 부여된 덜 일반적인 시나리오에서는 Microsoft Graph API를 사용하여 요청 시 Microsoft Entra 앱 등록을 만들 수 있습니다. 그러나 각 Microsoft Entra 앱 등록에 대한 인증 자격 증명을 어떻게든 추적해야 하므로 사용자 지정 애플리케이션의 개발 및 배포가 복잡한 경우가 많습니다. 또한 개별 서비스 주체에 대한 액세스 토큰을 인증하고 획득해야 할 때마다 해당 자격 증명에 대한 액세스 권한을 얻어야 합니다.
서비스 주체 프로필
서비스 주체 프로필 기능은 Power BI에서 조직 콘텐츠를 보다 쉽게 관리하고 용량을 더 효율적으로 사용하기 위해 디자인되었습니다. 따라서 가장 적은 개발자 작업과 오버헤드가 수반되는 세 가지 특정 문제를 해결하는 데 도움이 됩니다. 이러한 문제는 다음과 같습니다.
- 많은 수의 작업 영역으로 규모 조정.
- REST API 호출 성능 최적화.
- 고객 테넌트 수준에서 의미 체계 모델 및 데이터 원본 자격 증명 격리.
서비스 주체 프로필을 사용하면 다중 테넌트 애플리케이션을 디자인할 때 관련된 약점을 피하면서 세 가지 디자인 전략(이전 섹션에서 설명)의 장점을 활용할 수 있습니다.
서비스 주체 프로필은 Power BI의 컨텍스트 내에서 생성된 로컬 계정입니다. 서비스 주체는 Profiles REST API 작업을 사용하여 새 서비스 주체 프로필을 만들 수 있습니다. 서비스 주체는 다음 다이어그램에 나온 것처럼 사용자 지정 애플리케이션에 대한 자체 서비스 주체 프로필 집합을 만들고 관리할 수 있습니다.
서비스 주체와 해당 서비스 주체가 만드는 서비스 주체 프로필 사이에는 항상 부모-자식 관계가 있습니다. 서비스 주체 프로필을 독립 실행형 엔터티로 만들 수는 없습니다. 대신 특정 서비스 주체를 사용하여 서비스 주체 프로필을 만들고 해당 서비스 주체가 프로필의 부모 역할을 할 수 있습니다. 또한 서비스 주체 프로필은 사용자 계정 또는 다른 서비스 주체에 표시되지 않습니다. 서비스 주체 프로필은 해당 서비스 주체 프로필을 만든 서비스 주체만 보고 사용할 수 있습니다.
서비스 주체 프로필은 Microsoft Entra에서 알 수 없습니다.
서비스 주체 자체와 기본 Microsoft Entra 앱 등록은 Microsoft Entra에 알려져 있지만 Microsoft Entra ID는 서비스 주체 프로필에 대해 어떤 것도 알지 못합니다. 이는 서비스 주체 프로필이 Power BI에서 만들어지고 Power BI 보안 및 권한 부여를 제어하는 Power BI 서비스 하위 시스템에만 존재하기 때문입니다.
서비스 주체 프로필을 Microsoft Entra ID에서 알 수 없다는 사실에는 장점과 단점이 모두 있습니다. 주요 장점은 고객용 임베드 시나리오 애플리케이션이 서비스 주체 프로필을 만드는 데 특별한 Microsoft Entra 권한이 필요하지 않다는 것입니다. 또한 애플리케이션이 Microsoft Entra와 별개의 로컬 ID 세트를 만들고 관리할 수 있음을 의미합니다.
그러나 단점도 있습니다. 서비스 주체 프로필을 Microsoft Entra에서 알 수 없기 때문에 Microsoft Entra 그룹에 서비스 주체 프로필을 추가하여 작업 영역에 대한 액세스 권한을 암시적으로 부여할 수 없습니다. 또한 Azure SQL Database 또는 Azure Synapse Analytics와 같은 외부 데이터 원본이 데이터베이스에 연결할 때 서비스 주체 프로필을 ID로 인식할 수 없습니다. 따라서 각 고객 테넌트의 고유한 인증 자격 증명이 있는 별도의 서비스 주체를 사용하여 이러한 데이터 원본에 연결해야 하는 요구 사항이 있는 경우, 작업 영역당 하나의 서비스 주체 디자인 전략(각 고객 테넌트에 대해 하나의 서비스 주체 만들기)이 더 나은 선택이 될 수 있습니다.
서비스 주체 프로필은 최고 수준의 보안 주체입니다.
Microsoft Entra에서는 서비스 주체 프로필을 알 수 없지만 Power BI는 이를 최고 수준의 보안 주체로 인식합니다. 사용자 계정 또는 서비스 주체와 마찬가지로 작업 영역 역할(관리자 또는 멤버)에 서비스 주체 프로필을 추가할 수 있습니다. 의미 체계 모델 소유자 및 데이터 원본 자격 증명의 소유자로 만들 수도 있습니다. 이러한 이유로 새 고객 테넌트마다 새 서비스 주체 프로필을 만드는 것이 가장 좋습니다.
팁
서비스 주체 프로필을 사용하여 고객용 임베드 시나리오 애플리케이션용을 개발하는 경우 단일 Microsoft Entra 앱 등록을 만들어 애플리케이션에 단일 서비스 주체를 제공하면 됩니다. 이 방식은 애플리케이션이 프로덕션에 배포된 후에도 지속적으로 추가 Microsoft Entra 앱 등록을 만들어야 하는 다른 다중 테넌트 디자인 전략에 비해 관리 오버헤드를 크게 낮춥니다.
REST API 호출을 서비스 주체 프로필로 실행
애플리케이션은 서비스 주체 프로필의 ID를 사용하여 REST API 호출을 실행할 수 있습니다. 즉, 일련의 REST API 호출을 실행하여 새 고객 테넌트를 프로비전하고 설정할 수 있습니다.
- 서비스 주체 프로필이 새 작업 영역을 만들면 Power BI는 해당 프로필을 작업 영역 관리자로 자동으로 추가합니다.
- 서비스 주체 프로필이 의미 체계 모델을 만들기 위해 Power BI Desktop 파일을 가져올 때 Power BI는 해당 프로필을 의미 체계 모델 소유자로 설정합니다.
- 서비스 주체 프로필이 데이터 원본 자격 증명을 설정하면 Power BI는 해당 프로필을 데이터 원본 자격 증명의 소유자로 설정합니다.
서비스 주체는 Power BI에서 해당 프로필의 ID와 별도로 구별되는 ID를 갖는다는 것을 이해해야 합니다. 따라서 개발자에게 선택지를 제공할 수 있습니다. 서비스 주체 프로필의 ID를 사용하여 REST API 호출을 실행할 수 있습니다. 또는 프로필 없이 REST API 호출을 실행할 수 있으며, 이때는 부모 서비스 주체의 ID를 사용합니다.
서비스 주체 프로필을 만들거나 보거나 삭제할 때 REST API 호출을 부모 서비스 주체로 실행하는 것이 좋습니다. 다른 모든 REST API 호출을 실행하려면 서비스 주체 프로필을 사용해야 합니다. 이러한 다른 호출은 작업 영역을 만들고, Power BI Desktop 파일을 가져오고, 의미 체계 모델 매개 변수를 업데이트하고, 데이터 원본 자격 증명을 설정할 수 있습니다. 또한 작업 영역 항목 메타데이터를 검색하고 포함 토큰을 생성할 수도 있습니다.
Contoso라는 고객에 대한 고객 테넌트를 설정해야 하는 예제를 생각해 보세요. 첫 번째 단계에서는 REST API를 호출하여 표시 이름이 Contoso로 설정된 서비스 주체 프로필을 만듭니다. 이 호출은 서비스 주체의 ID를 사용하여 수행됩니다. 나머지 모든 설정 단계에서는 서비스 주체 프로필을 사용하여 다음과 같은 작업을 완료합니다.
- 작업 영역을 만듭니다.
- 작업 영역을 용량과 연결합니다.
- Power BI Desktop 파일을 가져옵니다.
- 의미 체계 모델 매개 변수를 설정합니다.
- 데이터 원본 자격 증명을 설정합니다.
- 예약된 데이터 새로 고침을 설정합니다.
작업 영역 및 해당 콘텐츠에 대한 액세스는 고객 테넌트를 만드는 데 사용된 서비스 주체 프로필의 ID를 사용하여 수행해야 한다는 것을 이해하는 것이 중요합니다. 또한 부모 서비스 주체가 작업 영역 또는 해당 콘텐츠에 액세스할 필요가 없다는 것을 이해하는 것이 중요합니다.
팁
기억하세요. REST API를 호출할 때 서비스 주체를 사용하여 서비스 주체 프로필을 만들고 관리하며, 서비스 주체 프로필을 사용하여 Power BI 콘텐츠를 만들고, 설정하고, 액세스합니다.
프로필 REST API 작업 사용
프로필 REST API 작업 그룹은 서비스 주체 프로필을 만들고 관리하는 작업으로 구성됩니다.
Create ProfileDelete ProfileGet ProfileGet ProfilesUpdate Profile
서비스 주체 프로필 만들기
프로필 만들기 REST API 작업을 사용하여 서비스 주체 프로필을 만듭니다. 새 테넌트의 표시 이름을 제공하려면 요청 본문에 displayName 속성을 설정해야 합니다. 값은 서비스 주체가 소유한 모든 프로필에서 고유해야 합니다. 서비스 주체에 대해 해당 표시 이름을 가진 다른 프로필이 이미 있는 경우 호출이 실패합니다.
호출이 성공하면 프로필을 나타내는 GUID인 id 속성이 반환됩니다. 서비스 주체 프로필을 사용하는 애플리케이션을 개발하는 경우 프로필 표시 이름과 해당 ID 값을 사용자 지정 데이터베이스에 저장하는 것이 좋습니다. 이렇게 하면 애플리케이션에서 ID를 쉽게 검색할 수 있습니다.
Power BI .NET SDK를 사용하여 프로그래밍하는 경우 새 프로필을 나타내는 ServicePrincipalProfile 개체를 반환하는 Profiles.CreateProfile 메서드를 사용할 수 있습니다. 이를 통해 id 속성 값을 쉽게 확인할 수 있습니다.
서비스 주체 프로필을 만들고 작업 영역 액세스 권한을 부여하는 예제는 다음과 같습니다.
// Create a service principal profile
string profileName = "Contoso";
var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);
// Retrieve the ID of the new profile
Guid profileId = profile.Id;
// Grant workspace access
var groupUser = new GroupUser {
GroupUserAccessRight = "Admin",
PrincipalType = "App",
Identifier = ServicePrincipalId,
Profile = new ServicePrincipalProfile {
Id = profileId
}
};
pbiClient.Groups.AddGroupUser(workspaceId, groupUser);
Power BI 서비스의 작업 영역 액세스 창에서 액세스 권한이 있는 ID(보안 주체 포함)를 확인할 수 있습니다.
서비스 주체 프로필 삭제
프로필 삭제 REST API 작업을 사용하여 서비스 주체 프로필을 삭제합니다. 이 작업은 부모 서비스 주체에서만 호출할 수 있습니다.
Power BI .NET SDK를 사용하여 프로그래밍하는 경우 Profiles.DeleteProfile 메서드를 사용할 수 있습니다.
모든 서비스 주체 프로필 가져오기
프로필 가져오기 REST API 작업을 사용하여 호출 서비스 주체에 속하는 서비스 주체 프로필 목록을 가져옵니다. 이 작업은 각 서비스 주체 프로필의 id 및 displayName 속성을 포함하는 JSON 페이로드를 반환합니다.
Power BI .NET SDK를 사용하여 프로그래밍하는 경우 Profiles.GetProfiles 메서드를 사용할 수 있습니다.
서비스 주체 프로필을 사용하여 REST API 호출 실행
서비스 주체 프로필을 사용하여 REST API를 호출하기 위해서는 두 가지 요구 사항이 있습니다.
- 권한 부여 헤더에서 부모 서비스 주체에 대한 액세스 토큰을 전달해야 합니다.
- 서비스 주체 프로필의 ID 값과 함께 X-PowerBI-profile-id라는 이름의 헤더를 포함해야 합니다.
Power BI .NET SDK를 사용하는 경우 서비스 주체 프로필의 ID를 전달하여 X-PowerBI-profile-id 헤더 값을 명시적으로 설정할 수 있습니다.
// Create the Power BI client
var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBIClient(uriPowerBiServiceApiRoot, tokenCredentials);
// Add X-PowerBI-profile-id header for service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
pbiClient.HttpClient.DefaultRequestHeaders.Add("X-PowerBI-profile-id", profileId);
// Retrieve workspaces by using the identity of service principal profile
var workspaces = pbiClient.Groups.GetGroups();
위의 예제와 같이 X-PowerBI-profile-id 헤더를 PowerBIClient 개체에 추가하면 Groups.GetGroups와 같은 메서드를 호출하는 것이 간단하므로 서비스 주체 프로필을 사용하여 실행됩니다.
PowerBIClient 개체에 대한 X-PowerBI-profile-id 헤더를 설정하는 더 편리한 방법이 있습니다. 프로필의 ID를 생성자에 전달하여 개체를 초기화할 수 있습니다.
// Create the Power BI client
string profileId = "11111111-1111-1111-1111-111111111111";
var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBiClient(uriPowerBiServiceApiRoot, tokenCredentials, profileId);
다중 테넌트 애플리케이션을 프로그래밍할 때 부모 서비스 주체로 호출을 실행하는 방법과 서비스 주체 프로필로 호출을 실행하는 방법 간에서 전환해야 할 수 있습니다. 컨텍스트 전환을 관리하는 유용한 방법은 PowerBIClient 개체를 저장하는 클래스 수준 변수를 선언하는 것입니다. 그런 다음, 올바른 개체로 변수를 설정하는 도우미 메서드를 만들 수 있습니다.
// Class-level variable that stores the PowerBIClient object
private PowerBIClient pbiClient;
// Helper method that sets the correct PowerBIClient object
private void SetCallingContext(string profileId = "") {
if (profileId.Equals("")) {
pbiClient = GetPowerBIClient();
}
else {
pbiClient = GetPowerBIClientForProfile(new Guid(profileId));
}
}
서비스 주체 프로필을 만들거나 관리해야 하는 경우 매개 변수 없이 SetCallingContext 메서드를 호출할 수 있습니다. 이렇게 하면 서비스 주체의 ID를 사용하여 프로필을 만들고 관리할 수 있습니다.
// Always create and manage profiles as the service principal
SetCallingContext();
// Create a service principal profile
string profileName = "Contoso";
var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);
새 고객 테넌트용 작업 영역을 만들고 설정해야 하는 경우 해당 코드를 서비스 주체 프로필로 실행할 수 있습니다. 따라서 프로필의 ID를 전달하여 SetCallingContext 메서드를 호출해야 합니다. 이렇게 하면 서비스 주체 프로필의 ID를 사용하여 작업 영역을 만들 수 있습니다.
// Always create and set up workspaces as a service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
SetCallingContext(profileId);
// Create a workspace
GroupCreationRequest request = new GroupCreationRequest(workspaceName);
Group workspace = pbiClient.Groups.CreateGroup(request);
특정 서비스 주체 프로필을 사용하여 작업 영역을 만들고 구성한 후에는 동일한 프로필을 계속 사용하여 작업 영역 콘텐츠를 만들고 설정해야 합니다. 설정을 완료하기 위해 SetCallingContext 메서드를 호출할 필요는 없습니다.
개발자 샘플
AppOwnsDataMultiTenant라는 샘플 애플리케이션을 다운로드하는 것이 좋습니다.
이 샘플 애플리케이션은 .NET 6 및 ASP.NET을 사용하여 개발되었으며 이 문서에 설명된 지침 및 권장 사항을 적용하는 방법을 보여 줍니다. 코드를 검토해 보면 서비스 주체 프로필을 사용하여 고객용 임베드 시나리오를 구현하는 다중 테넌트 애플리케이션을 개발하는 방법을 배울 수 있습니다.
관련 콘텐츠
이 문서에 대한 자세한 내용은 다음 리소스를 참조하세요.