Share via


Microsoft Fabric 채택 로드맵: 시스템 감독

참고 항목

이 문서는 Microsoft Fabric 채택 로드맵 문서 시리즈의 일부입니다. 시리즈 개요는 Microsoft Fabric 채택 로드맵을 참조하세요.

시스템 감독(Fabric 관리)은 지속적이고 일상적인 관리 작업입니다. 특히 다음과 관련이 있습니다.

  • 거버넌스: 셀프 서비스, 엔터프라이즈 데이터 및 BI(비즈니스 인텔리전스) 시나리오를 지원하기 위한 거버넌스 지침과 정책을 시행합니다.
  • 사용자 역량 강화: 조직의 규정 및 요구 사항을 준수하면서 가능한 범위까지 내부 사용자 커뮤니티를 지원하는 내부 프로세스 및 시스템을 촉진하고 지원합니다.
  • 채택: 효과적인 거버넌스 및 데이터 관리 방식으로 Fabric이 조직에서 더 광범위하게 채택되도록 합니다.

Important

조직의 데이터 문화 목표는 거버넌스 결정을 위한 방향을 제시하고 이로써 누가 어떻게 Fabric을 관리할 것인지를 조정하는 것입니다.

시스템 감독은 광범위하고 깊이 있는 토픽입니다. 이 문서의 목표는 조직의 채택 목표를 달성하는 데 도움이 되는 가장 중요한 고려 사항과 조치를 소개하는 것입니다.

Fabric 관리자

Fabric 관리자 역할은 Microsoft 365에서 정의된 역할로, 관리 활동의 하위 세트에 위임됩니다. 전역 Microsoft 365 관리자는 암시적으로 Fabric 관리자입니다. Power Platform 관리자 또한 암시적으로 Fabric 관리자입니다.

누구를 Fabric 관리자로 정할 것인가는 거버넌스에서 핵심적인 결정입니다. Fabric 관리자는 전체 테넌트에 영향을 주는 중심 집중식 역할입니다. Fabric을 관리할 수 있는 사람이 조직에 두 명에서 네 명 정도 있는 것이 이상적입니다. 관리자는 COE(우수성 센터)와 긴밀하게 협력해야 합니다.

높은 권한 역할

Fabric 관리자 역할은 다음과 같은 이유로 높은 권한을 갖는 역할입니다.

  • 사용자 경험: 패브릭 관리자가 관리하는 설정은 사용자 기능과 사용자 경험에 상당한 영향을 미칩니다. 자세한 내용은 테넌트 관리 설정을 참조하세요.
  • 전체 보안 액세스: Fabric 관리자는 테넌트에서 작업 영역에 대한 액세스 권한을 업데이트할 수 있습니다. 따라서 관리자는 적절하다고 판단되는 데이터와 보고서를 보거나 다운로드할 권한을 허용할 수 있습니다. 자세한 내용은 테넌트 관리 설정을 참조하세요.
  • 개인 작업 영역 액세스: Fabric 관리자는 콘텐츠에 액세스하고 모든 사용자의 개인 작업 영역을 관리할 수 있습니다.
  • Metadata: Fabric 관리자는 Fabric 포털에서 발생하는 모든 사용자 활동을 포함하여 모든 테넌트 메타데이터를 볼 수 있습니다(아래의 감사 및 모니터링 섹션 참조).

Important

Fabric 관리자가 너무 많으면 위험합니다. 테넌트에서 승인되지 않거나, 의도하지 않거나, 일관되지 않은 관리 가능성이 높아집니다.

역할 및 책임

관리자가 일상적으로 수행하는 작업의 유형은 조직마다 다릅니다. 데이터 문화권에서 무엇이 중요하고 우선 순위가 높은지는 관리자가 비즈니스 주도 셀프 서비스, 관리형 셀프 서비스, 엔터프라이즈 데이터 및 BI 시나리오를 지원하기 위해 수행하는 작업에 큰 영향을 미칩니다. 자세한 내용은 콘텐츠 소유권 및 관리 문서를 참조하세요.

Fabric 관리자 역할을 하기에 가장 적합한 유형은 Fabric에 대한 충분한 지식을 갖추어 셀프 서비스 사용자가 수행해야 하는 작업을 이해할 수 있는 사람입니다. 이에 대한 이해를 통해 관리자는 사용자역량 강화와 거버넌스의 균형을 맞출 수 있습니다.

패브릭 관리자 외에도 다양한 역할에서 관리자라는 용어를 사용합니다. 다음 표에서는 일반적으로 정기적으로 사용되는 역할을 설명합니다.

역할 범위 설명
패브릭 관리자 테넌트 Fabric 포털에서 테넌트 설정 및 기타 설정을 관리합니다. 이 문서의 관리자에 대한 모든 일반 참조는 이러한 유형의 관리자를 나타냅니다.
용량 관리자 하나의 용량 작업 영역과 워크로드를 관리하고 Fabric 용량 상태를 모니터링합니다.
데이터 게이트웨이 관리자 하나의 게이트웨이 게이트웨이 데이터 원본 구성, 자격 증명, 사용자 할당을 관리합니다. 게이트웨이 소프트웨어 업데이트를 처리하거나 업데이트 시 인프라 팀과 협업하는 경우가 있을 수 있습니다.
작업 영역 관리자 단일 작업 영역 작업 영역 설정 및 액세스를 관리.

Fabric의 워크로드 에코시스템은 광범위하고 심층적입니다. Fabric을 다른 시스템 및 플랫폼과 통합하는 방법은 여러 가지가 있습니다. 때때로 다른 관리자나 IT 전문가와 협력해야 하는 경우가 있습니다. 자세한 내용은 다른 관리자와 공동 작업을 참조하세요.

이 문서의 나머지 부분에서는 패브릭 관리자가 수행하는 가장 일반적인 활동에 대한 개요를 제공합니다. 이 개요는 조직 채택에 대해 전략적으로 접근할 때 효과적으로 수행해야 하는 중요한 활동에 중점을 둡니다.

서비스 관리

테넌트를 감독하는 것은 모든 사용자가 Power BI에서 좋은 경험을 갖도록 하는 데 중요한 측면입니다. 다음은 패브릭 관리자의 주요 거버넌스 책임의 예시입니다.

  • 테넌트 설정: 어떤 Power BI 기능을 활성화할지와 어떤 조직의 사용자가 이 기능을 사용할지 제어합니다.
  • 도메인: 특성이 비슷한 두 개 이상의 작업 영역을 그룹화합니다.
  • 작업 영역: 테넌트의 작업 영역을 검토하고 관리합니다.
  • embed 태그: 인터넷에 공개적으로 게시한 보고서를 관리합니다.
  • 조직 시각적 개체: 조직 시각적 개체를 등록하고 관리합니다.
  • Azure 연결: Azure 서비스와 통합하여 추가 기능을 제공합니다.

자세한 내용은 테넌트 관리를 참조하세요.

사용자 머신 및 디바이스

Fabric의 채택은 콘텐츠 작성자와 소비자가 필요한 도구와 애플리케이션을 보유하고 있는지에 직접적으로 달려 있습니다. 다음은 고려해야 할 몇 가지 중요한 질문입니다.

  • 사용자가 새 도구에 대한 액세스를 요청하려면 어떻게 해야 하나요? 사용자가 도구를 효과적으로 사용할 수 있도록 라이선스, 데이터 및 교육에 액세스할 수 있나요?
  • 콘텐츠 소비자는 다른 사용자가 게시한 콘텐츠를 어떻게 볼 수 있나요?
  • 콘텐츠 작성자는 어떻게 콘텐츠를 개발, 관리 및 게시하나요? 각 사용 사례에 적합한 도구 및 애플리케이션을 결정하기 위한 기준은 무엇인가요?
  • 도구를 설치하고 설정하려면 어떻게 해야 하나요? 여기에는 관련 필수 구성 요소 및 데이터 연결 구성 요소가 포함되어 있나요?
  • 도구 및 애플리케이션에 대한 지속적인 업데이트는 어떻게 관리하나요?

자세한 내용은 사용자 도구 및 디바이스를 참조하세요.

아키텍처

Fabric의 컨텍스트에서 아키텍처는 데이터 아키텍처, 용량 관리, 데이터 게이트웨이 아키텍처 및 관리와 관련됩니다.

데이터 아키텍처

데이터 아키텍처는 수집되는 데이터와 이를 수집, 저장, 관리, 통합, 모델링, 사용하는 방법을 관리하고 정의하는 원칙, 방식, 방법론을 의미합니다.

결정해야 하는 데이터 아키텍처가 많이 있습니다. 데이터 아키텍처 디자인 및 계획에서 COE가 자주 참여합니다. 특히 데이터베이스 또는 Azure 인프라를 관리하는 경우에도 관리자가 참여하는 경우가 많습니다.

Important

데이터 아키텍처 결정은 Fabric 채택, 사용자 만족도 및 개별 프로젝트 성공률에 중요한 영향을 미칩니다.

채택에 영향을 미치는 몇 가지 데이터 아키텍처 고려 사항은 다음과 같습니다.

  • Fabric은 조직의 전체 데이터 아키텍처의 어디에 적합한가요? 계획에서 고려해야 하는 EDW(엔터프라이즈 데이터 웨어하우스) 또는 데이터 레이크와 같은 다른 기존 구성 요소가 있나요?
  • Fabric은 데이터 준비, 데이터 모델링 및 데이터 프레젠테이션에 엔드투엔드로 사용되나요? 아니면 이러한 기능 중 일부에만 사용되나요?
  • 데이터 재사용 가능성과 보고서 작성자 유연성 간에 최상의 균형을 찾기 위해 관리형 셀프 서비스 패턴을 따르고 있나요?
  • 사용자는 콘텐츠를 어디에서 소비하나요? 일반적으로 콘텐츠를 배달하는 세 가지 주요 방법으로는 Fabric 포털, Power BI Report Server 및 사용자 지정 애플리케이션에 포함하는 방법이 있습니다. 또한 Microsoft Teams는 Teams에서 많은 시간을 보내는 사용자에게 편리한 대안입니다.
  • 데이터 아키텍처를 관리하고 유지 관리하는 책임은 누구에게 있나요? 중앙 집중식 팀인가요? 아니면 탈중앙화 팀인가요? 이러한 팀에서 COE는 어떻게 대표되나요? 특정 기술 세트가 필요한가요?
  • 어떤 데이터 원본이 가장 중요한가요? 어떤 유형의 데이터를 얻게 되나요?
  • 사용 사례에 가장 적합한 의미 체계 모델 연결 모드스토리지 모드 선택(예: Direct Lake, 가져오기, 실시간 연결, DirectQuery 또는 복합 모델 프레임워크)은 무엇인가요?
  • 레이크하우스, 웨어하우스공유 의미 체계 모델을 사용하여 데이터 재사용성을 어느 정도까지 장려하나요?
  • 데이터 파이프라인, Notebooks데이터 흐름을 사용하면 데이터 준비 논리와 고급 데이터 준비의 재사용성이 어느 정도 향상되나요?

관리자가 아키텍처 결정을 내리기 전에 Fabric의 기술 기능은 물론 관련자의 요구 사항과 목표도 완전히 파악해야 합니다.

기술적 POC(개념 증명)를 완료하여 가정과 아이디어를 테스트하는 것이 좋습니다. 일부 조직에서는 소규모 작업 단위를 제공하는 것이 목표일 때 이를 마이크로 프로젝트라고도 합니다. POC의 목표는 알려지지 않은 문제를 해결하고 가능한 한 신속하게 위험을 줄이는 것입니다. POC가 버리는 작업이 되어야 할 필요는 없지만 범위가 좁아야 합니다. 멘토링 및 사용자 지원 문서에서 설명한 대로 모범 사례 검토는 중요한 아키텍처 결정을 통해 콘텐츠 작성자를 지원하는 또 다른 유용한 방법입니다.

용량 관리

용량에는 대규모 분석 솔루션을 제공하는 기능과 특성이 포함되어 있습니다. Fabric 조직 라이선스에는 PPU(사용자 단위 프리미엄)과 용량, 두 가지 유형이 있습니다. 용량 라이선스에는 다양한 유형이 있습니다. 용량 라이선스 형식에 따라 지원되는 Fabric 워크로드가 결정됩니다.

Important

때때로 이 문서는 Power BI Premium 또는 P SKU(용량 구독)를 참조합니다. Microsoft는 현재 구매 옵션을 통합하고 용량 SKU당 Power BI Premium을 사용 중지하고 있습니다. 신규 및 기존 고객은 F SKU(패브릭 용량 구독)를 대신 구매하는 것을 고려해야 합니다.

자세한 내용은 Power BI Premium 라이선스Power BI Premium FAQ에 제공되는 중요 업데이트를 참조하세요.

용량 사용은 콘텐츠를 생성, 관리, 게시 및 배포하는 전략에서 중요한 역할을 할 수 있습니다. 용량에 투자해야 하는 몇 가지 주요 이유는 다음과 같습니다.

  • 다수의 읽기 전용 사용자에게 무제한 Power BI 콘텐츠 배포 무료 Power BI 라이선스가 있는 사용자는 PPU가 아닌 프리미엄 용량에서만 콘텐츠를 소비할 수 있습니다. 무료 사용자는 F64 Fabric 용량 라이선스 이상에서도 콘텐츠를 소비할 수 있습니다.
  • 엔드투엔드 분석을 생성할 수 있는 Fabric 환경에 대한 액세스.
  • 개발, 테스트, 프로덕션 작업 영역에 대한 콘텐츠 게시를 관리하는 배포 파이프라인. 릴리스 안정성을 개선하기 위해 중요한 콘텐츠에서 매우 권장됩니다.
  • XMLA 엔드포인트는 의미 체계 모델을 관리 및 게시하거나 XMLA 호환 도구에서 의미 체계 모델을 쿼리하기 위한 업계 표준 프로토콜입니다.
  • 큰 의미 체계 모델 지원을 포함하여 모델 크기 제한이 증가했습니다.
  • 데이터 새로 고침을 더 자주 수행.
  • 홈 지역이 아닌 특정 지리적 영역에 데이터 저장.

위 목록이 다가 아닙니다. 전체 목록은 Power BI Premium 기능을 참조하세요.

Fabric 용량 관리

Fabric 용량 상태를 감독하는 것은 관리자에게 필수적인 지속적인 작업입니다. 각 용량 SKU에는 리소스 집합이 포함됩니다. CPU(용량 단위)는 각 SKU의 컴퓨팅 리소스를 측정하는 데 사용됩니다.

주의

관리 부족 및 Premium 용량의 한도 초과는 종종 성능 문제와 사용자 환경 문제를 초래할 수 있습니다. 두 가지 문제 모두 올바르게 관리되지 않으면 채택 노력에 부정적인 영향을 미칠 수 있습니다.

Fabric 용량 관리를 위한 제안:

  • 용량 관리를 담당할 사용자를 정의합니다. 어떤 조치를 누가, 언제, 왜 취해야 하는지가 명확할 수 있도록 역할과 책임을 확인합니다.
  • 용량에 맞게 게시할 콘텐츠에 대한 특정 기준 집합을 만듭니다. 용량이 잘 관리되지 않는 경우 다른 사용자에게 방해가 될 가능성이 있으므로 여러 사업부에서 단일 용량을 사용하는 경우 특히 관련성이 높습니다. 프로덕션 용량에 새 콘텐츠를 게시하기 전에 모범 사례 검토(예: 합리적인 의미 체계 모델 크기 및 효율적인 계산)를 요구하는 것이 좋습니다.
  • 정기적으로 Fabric 용량 측정 앱을 사용하여 리소스 사용률과 용량 패턴을 파악합니다. 가장 중요한 것은 사용자 중단에 영향을 미칠 수 있는 일관된 초과 사용 패턴을 찾는 것입니다. 사용 패턴을 분석하면 용량을 덜 사용하고 있는지 파악할 수 있습니다. 이는 투자로부터 더 많은 가치를 얻을 수 있음을 나타냅니다.
  • 테넌트 설정을 설정하면 용량이 과부하되거나 중단 또는 인시던트가 발생하는 경우 Fabric에서 알림을 받을 수 있습니다.

자동 크기 조정

자동 크기 조정은 용량 사용량 수준에서 가끔 또는 예기치 않게 발생하는 버스트를 처리하기 위한 것입니다. 자동 크기 조정은 증가한 워크로드를 지원하기 위해 CPU 리소스를 자동으로 늘려 이러한 버스트에 대응할 수 있습니다.

자동화된 스케일 업은 재무에 영향을 미치지만 성능 및 사용자 환경 문제의 위험은 줄입니다. 용량이 잘 관리되지 않으면 자동 크기 조정이 예상보다 자주 트리거될 수 있습니다. 이 경우 메트릭 앱을 사용하면 근본적인 문제를 파악하고 용량 계획을 세울 수 있습니다.

탈중앙화된 용량 관리

용량 관리자는 특정 용량에 작업 영역을 할당할 책임이 있습니다.

작업 영역 관리자가 PPU 라이선스를 소유하는 경우 작업 영역 관리자도 PPU에 작업 영역을 할당할 수 있습니다. 그러나 작업 영역에서 Power BI 콘텐츠를 공동 작업하거나 보려면 다른 모든 작업 영역 사용자도 PPU 라이선스가 있어야 합니다. 다른 Fabric 워크로드는 PPU에 할당된 작업 영역에 포함될 수 없습니다.

여러 사업부에서 간편하게 분산형 관리를 할 수 있도록 여러 용량을 설정할 수 있습니다. Fabric의 특정 측면에 대한 관리를 분산시키는 것은 민첩성과 제어의 균형을 맞추는 좋은 방법입니다.

다음 예는 용량을 관리할 수 있는 한 가지 방법을 설명합니다.

  • Microsoft 365에서 P3 용량 노드를 구매합니다. 여기에는 32개의 V 코어(가상 코어)가 포함되어 있습니다.
  • 16개의 V 코어를 사용하여 첫 번째 용량을 만듭니다. 이 용량은 영업 팀에서 사용합니다.
  • 8개의 V 코어를 사용하여 두 번째 용량을 만듭니다. 이 용량은 운영 팀에서 사용합니다.
  • 나머지 8개의 V 코어를 사용하여 세 번째 용량을 만듭니다. 이 용량은 일반 사용을 지원합니다.

이전 예에는 몇 가지 이점이 있습니다.

  • 각 용량에 대해 별도의 용량 관리자를 설정할 수 있습니다. 따라서 분산형 관리 상황이 간편해집니다.
  • 용량이 잘 관리되지 않는 경우 효과는 해당 용량으로만 제한됩니다. 다른 용량은 영향을 받지 않습니다.
  • 다른 사업부에 대한 청구와 차지백은 간단합니다.
  • 다양한 작업 영역을 별도의 용량에 쉽게 할당할 수 있습니다.

그러나 이전 예에는 단점도 있습니다.

  • 용량 당 한도가 더 낮습니다. 구매한 전체 P3 용량 노드 크기는 의미 체계 모델에 허용되는 최대 메모리 크기가 아닙니다. 의미 체계 모델이 호스트되는 할당된 용량 크기입니다.
  • 특정 시점에서 작은 용량 중 하나를 확장해야 할 가능성이 높습니다.
  • 테넌트에서 관리할 수 있는 용량은 더 많이 있습니다.

참고 항목

용량당 Power BI Premium 리소스를 V 코어라고 합니다. 그러나 Fabric 용량은 이를 CPU(용량 단위)라고 합니다. CPU 및 V 코어의 크기는 SKU마다 다릅니다. 자세한 내용은 Fabric 라이선스 설명서를 참조하세요.

데이터 게이트웨이 아키텍처 및 관리

데이터 게이트웨이는 조직 데이터 원본과 Fabric 서비스 간에 안전하고 효율적인 데이터 전송을 지원합니다. 데이터 원본이 다음과 같은 경우 온-프레미스 또는 클라우드 서비스에 대한 데이터 연결에 데이터 게이트웨이가 필요합니다.

  • 엔터프라이즈 데이터 센터 내에 있음.
  • 방화벽 뒤에서 구성됨.
  • 가상 네트워크 내.
  • 가상 머신 내.

게이트웨이에는 세 가지 유형이 있습니다.

  • 온-프레미스 데이터 게이트웨이(표준 모드)는 많은 사용자가 사용할 수 있도록 등록된 데이터 원본에 대한 연결을 지원하는 게이트웨이 서비스입니다. 게이트웨이 소프트웨어 설치 및 업데이트는 고객이 관리하는 머신에 설치됩니다.
  • 온-프레미스 데이터 게이트웨이(개인 모드)는 데이터 새로 고침만을 지원하는 게이트웨이 서비스입니다. 이 게이트웨이 모드는 일반적으로 콘텐츠 작성자의 PC에 설치됩니다. 한 명의 사용자만 사용할 수 있습니다. 라이브 연결 또는 DirectQuery 연결을 지원하지 않습니다.
  • 가상 네트워크 데이터 게이트웨이는 많은 사용자에 대한 연결을 지원하는 Microsoft 관리형 서비스입니다. 특히 프리미엄 용량 또는 사용자 단위 Premium에 할당된 작업 영역에 저장된 의미 체계 모델 및 데이터 흐름에 대한 연결을 지원합니다.

게이트웨이 소프트웨어를 설치할 수 있는 사람에 대한 결정은 거버넌스 결정입니다. 대부분의 조직은 표준 모드의 데이터 게이트웨이 또는 가상 네트워크 데이터 게이트웨이를 사용하는 것이 좋습니다. 개인 모드의 데이터 게이트웨이보다 훨씬 확장성 있고 관리 가능하며 감사 가능합니다.

분산형 게이트웨이 관리

온-프레미스 데이터 게이트웨이(표준 모드) 및 가상 네트워크 데이터 게이트웨이는 연결 세부 정보 및 자격 증명 저장 방법과 함께 등록할 수 있는 특정 데이터 원본 유형을 지원합니다. 새로 고침을 예약하거나 DirectQuery 쿼리를 실행할 수 있도록 사용자에게 게이트웨이 데이터 원본을 사용할 권한을 부여할 수 있습니다.

게이트웨이 관리의 특정 측면은 민첩성과 제어의 균형을 맞추기 위해 분산형을 기반으로 효과적으로 수행할 수 있습니다. 예를 들어 운영 그룹에는 셀프 서비스 콘텐츠 작성자 및 데이터 소유자 팀 전용 게이트웨이가 있을 수 있습니다.

분산형 게이트웨이 관리는 다음과 같이 협업인 경우 가장 잘 작동합니다.

분산형 데이터 소유자가 관리:

중앙 집중식 데이터 소유자가 관리(조직 전반에 걸쳐 광범위하게 사용되는 데이터 원본 포함, 중복된 데이터 원본을 방지하기 위해 관리가 중앙 집중화됨):

IT에서 관리:

  • 게이트웨이 소프트웨어 업데이트(게이트웨이 업데이트는 일반적으로 매월 릴리스됨).
  • 드라이버 및 사용자 지정 커넥터 설치(사용자 머신에 설치된 것과 동일).
  • 게이트웨이 클러스터 관리(고가용성을 위한 게이트웨이 클러스터의 머신 수, 재해 복구, 심각한 사용자 중단을 일으킬 수 있는 단일 실패 지점 제거).
  • 서버 관리(예: 운영 체제, RAM, CPU 또는 네트워킹 연결).
  • 게이트웨이 암호화 키 관리 및 백업.
  • 스케일 업 또는 스케일 아웃이 필요한 경우를 평가하기 위한 게이트웨이 로그 모니터링.
  • 게이트웨이 머신의 가동 중지 시간 또는 지속적인 리소스 부족 경고.

탈중앙화 팀이 게이트웨이의 특정 측면을 관리할 수 있도록 허용하면 더 빠른 이동이 가능합니다. 분산형 게이트웨이 관리의 절충은 조직의 특정 영역에 전용될 수 있도록 더 많은 게이트웨이 서버를 실행하는 것을 의미합니다. IT에서 전적으로 게이트웨이 관리를 처리하는 경우 데이터 원본을 추가하고 사용자 업데이트를 적용하기 위한 요청을 신속하게 처리할 수 있는 좋은 프로세스를 수립해야 합니다.

사용자 라이선스

모든 사용자에게 Microsoft Entra ID와 통합된 상용 라이선스가 필요합니다. 사용자 라이선스는 무료, Pro 또는 PPU(Premium Per User)일 수 있습니다.

사용자 라이선스는 시작 및 종료 날짜로 특정 개수의 라이선스에 권한을 부여하는 구독을 통해 취득합니다.

참고 항목

각 사용자에게는 라이선스가 필요하지만 Pro 또는 PPU 라이선스는 Power BI 콘텐츠를 공유하는 데에만 필요합니다. 무료 라이선스가 있는 사용자는 Power BI 항목 이외의 Fabric 콘텐츠를 만들고 공유할 수 있습니다.

구독을 조달하는 방식은 두 가지가 있습니다.

  • 중앙 집중식: Microsoft 365 청구 관리자가 Pro 또는 PPU 구독을 구매합니다. 구독을 관리하고 라이선스를 할당하는 가장 일반적인 방법입니다.
  • 탈중앙화: 개별 부서는 셀프 서비스 구매를 통해 구독을 구매합니다.

셀프 서비스 구매

중요한 거버넌스 결정은 셀프 서비스 구매가 허용되거나 권장되는 범위와 관련이 있습니다.

셀프 서비스 구매는 다음과 같은 경우에 유용합니다.

  • 구매 권한이 있고 신용 카드로 직접 대금을 처리하려는 탈중앙화 사업부가 있는 대규모 조직.
  • 월별 약정으로 구독을 최대한 간편하게 구매하려는 조직.

다음과 같은 경우에는 셀프 서비스 구매를 사용하지 않도록 설정하는 것이 좋습니다.

  • 규제, 보안, 거버넌스 요구 사항을 충족하기 위한 중앙 집중식 조달 프로세스가 있음.
  • EA(기업계약)를 통해 할인된 가격을 받음.
  • 회사 간 차지백을 처리하기 위한 기존 프로세스가 있음.
  • 그룹 기반 라이선스 할당을 처리하기 위한 기존 프로세스가 있음.
  • 승인, 근거, 교육 또는 거버넌스 정책 요구 사항 등의 라이선스를 얻기 위해 필수 조건이 필요함.
  • 액세스를 긴밀하게 제어하기 위한 유효한 요구 사항(예: 규정 요구 사항)이 있습니다.

사용자 라이선스 평가판

또 다른 중요한 거버넌스 결정은 사용자 라이선스 평가판 허용 여부에 대한 것입니다. 기본적으로 평가판은 사용하도록 설정됩니다. 즉, 콘텐츠를 동료와 공유할 때 수신자에게 Pro 또는 PPU 라이선스가 없으면 콘텐츠를 보기 위해 평가판을 시작하라는 메시지가 표시됩니다(콘텐츠가 용량이 지원되는 작업 영역 내에 있지 않은 경우). 평가판 환경은 간편하게 고안되어 사용자가 정상적인 워크플로를 계속 진행할 수 있도록 허용합니다.

일반적으로 평가판을 사용하지 않도록 설정하는 것은 권장되지 않습니다. 사용자에게 데이터를 내보내거나 지원되는 도구 및 프로세스 외부에서 작업하는 것과 같은 해결 방법을 찾도록 장려할 수 있습니다.

다음과 같은 경우에만 평가판을 사용하지 않도록 하는 것이 좋습니다.

  • 평가판 기간이 끝날 때 정식 라이선스를 부여하지 못할 정도로 심각한 비용 문제가 있는 경우.
  • 라이선스를 취득하기 위해 필수 조건이 필요합니다(예: 승인, 근거 또는 교육 요구 사항). 평가판 사용 기간 동안 이 요구 사항을 충족하는 것으로는 충분하지 않습니다.
  • Fabric 서비스에 대한 액세스를 면밀히 제어하기 위한 규정 요구 사항과 같은 유효한 요구 사항이 있습니다.

Fabric 라이선스를 취득하는 데 너무 많은 조건을 만들지 마세요. 작업을 완료해야 하는 사용자는 방법을 찾게 되며 여기에는 이상적이지 못한 해결 방법이 포함될 수도 있습니다. 예를 들어, Fabric을 사용할 수 있는 라이선스가 없으면 사람들은 훨씬 더 나은 방식을 사용할 수 있을 때 파일 시스템이나 이메일을 통해 파일을 공유하는 데 너무 많이 의존할 수 있습니다.

원가 관리

Fabric과 같은 클라우드 서비스의 비용을 관리하고 최적화하는 것은 중요한 작업입니다. 고려할 수 있는 몇 가지 작업은 다음과 같습니다.

  • 할당된 Fabric 라이선스를 사용하고 있는 사용자, 더 정확하게는 사용하지 않는 사용자를 분석하고 필요한 조정을 수행합니다. Fabric 사용량은 활동 로그를 사용하여 분석됩니다.
  • 용량 또는 사용자 단위 Premium의 비용 효율성을 분석합니다. 추가 기능뿐만 아니라, 비용 및 혜택을 분석하여 소비자의 수가 많은 경우 용량 라이선스가 더 비용 효율적인지 확인합니다.
  • 신중하게 Fabric 용량을 모니터링하고 관리합니다. 시간에 따른 사용량 패턴을 이해하면 더 많은 용량을 구매할 시기를 예측할 수 있습니다. 예를 들어 단일 용량을 P1에서 P2로 확장하거나 하나의 P1 용량에서 두 개의 P1 용량으로 스케일 업하도록 선택할 수 있습니다.
  • 가끔 사용량이 급증하는 경우 사용자 환경이 중단되지 않도록 Fabric과 함께 자동 크기 조정을 사용하는 것이 좋습니다. 자동 크기 조정은 24시간 동안 용량 리소스를 스케일 업한 다음, 정상 수준으로 다시 스케일 다운합니다(지속적인 활동이 없는 경우). 최대 가상 코어 수를 제한하거나 Azure에 설정된 지출 한도를 사용하여 자동 크기 조정 비용을 관리합니다. 가격 책정 모델로 인해 자동스케일링은 가끔 계획되지 않은 사용량 증가를 처리하는 데 가장 적합합니다.
  • Azure 데이터 원본의 경우 가능하면 Fabric 테넌트와 동일한 지역에 공동 배치합니다. Azure 송신 요금이 발생하지 않습니다. 데이터 송신 요금은 최소화되지만, 규모에 따라서는 계획되지 않은 상당한 비용이 추가될 수 있습니다.

보안, 정보 보호 및 데이터 손실 방지

보안, 정보 보호 및 DLP(데이터 손실 방지)는 모든 콘텐츠 작성자, 소비자 및 관리자의 공동 책임입니다. 개인 데이터, 고객 데이터 또는 고객 작성 데이터, 민감 건강 정보, 지적 재산, 독점적 조직 정보와 같은 중요한 정보는 어디에나 있으므로 보안 및 데이터 보호는 중요한 작업입니다. 정부, 업계, 계약 규정은 보안과 관련하여 세우는 거버넌스 지침 및 정책에 큰 영향을 미칠 수 있습니다.

Power BI 보안 백서에서는 Microsoft에서 관리하는 측면을 포함하여 다양한 고려 사항을 이해할 수 있는 좋은 리소스입니다. 이 섹션에서는 고객이 관리해야 하는 몇 가지 항목을 소개합니다.

사용자의 책임

일부 조직에서는 Fabric 사용자에게 셀프 서비스 사용자 승인을 수락하도록 요청합니다. 이것은 조직 데이터 보호에 대한 사용자의 책임과 기대치를 설명하는 문서입니다.

구현을 자동화하는 한 가지 방법은 Microsoft Entra 사용 약관 정책을 사용하는 것입니다. 사용자는 처음으로 Fabric 포털을 방문하기 전에 정책을 보고 동의해야 합니다. 또한 연간 갱신과 같이 반복적으로 동의하도록 요구할 수도 있습니다.

데이터 보안

클라우드 공유 책임 모델에서 데이터를 보호하는 것은 항상 고객의 책임입니다. 셀프 서비스 데이터 플랫폼을 통해 셀프 서비스 콘텐츠 작성자는 동료와 공유하는 콘텐츠를 적절하게 보호해야 할 책임이 있습니다.

COE는 콘텐츠 작성자에게 모범 사례(특히 매우 중요한 데이터 처리 상황)를 사용하여 지원하는 데 관련된 설명서 및 교육을 제공해야 합니다.

관리 작성자는 모범 사례 자체를 따라 도움을 줄 수 있습니다. 관리자는 작업 영역을 관리하거나 사용자 활동을 감사하거나 게이트웨이 자격 증명 및 사용자를 관리할 때 발견될 수 있는 문제가 있는 경우 우려를 제기할 수도 있습니다. 또한 몇몇 사용자를 제외하고 일반적으로 제한되는 여러 테넌트 설정도 있습니다(예: 웹에 게시하는 기능 또는 전체 조직에 앱을 게시하는 기능).

외부 게스트 사용자

파트너, 고객, 공급업체, 컨설턴트와 같은 외부 사용자가 흔한 조직도 있고 드문 조직도 있습니다. 외부 사용자를 처리하는 방법은 거버넌스에 의해 결정됩니다.

외부 사용자 액세스는 테넌트 설정과 특정 Microsoft Entra ID 설정에 의해 제어됩니다. 외부 사용자 고려 사항에 대한 자세한 내용은 Microsoft Entra B2B를 사용하여 외부 게스트 사용자에게 Power BI 콘텐츠 배포 백서를 검토하세요.

정보 보호 및 데이터 손실 방지

Fabric은 다음과 같은 방법으로 정보 보호 및 DLP(데이터 손실 방지) 기능을 지원합니다.

데이터 보존

지리적 지역 내에 데이터를 저장해야 하는 조직의 경우 Fabric 용량은 Fabric 테넌트의 홈 지역과 다른 특정 지역에 대해 설정될 수 있습니다.

암호화 키

Microsoft는 투명한 서버 쪽 암호화 및 인증서 자동 회전을 사용하여 Microsoft 데이터 센터에서 미사용 데이터 암호화를 처리합니다. Premium 암호화 키 자체를 관리하기 위한 규정 요구 사항이 있는 고객의 경우 Azure Key Vault를 사용하도록 Premium 용량을 구성할 수 있습니다. 고객 관리형 키(Bring Your Own Key 또는 BYOK라고도 함)를 사용하는 것은 서비스 운영자에 의해 사용자 오류가 발생할 경우 고객 데이터가 노출되지 않도록 하기 위한 예방 조치입니다.

PPU(사용자 단위 Premium)는 전체 Fabric 테넌트에 대해 사용하도록 설정된 경우에만 BYOK를 지원한다는 점에 유의해야 합니다.

감사 및 모니터링

감사 데이터를 사용하여 채택 활동을 분석하고, 사용 패턴을 이해하고, 사용자를 교육하고, 사용자를 지원하고, 위험을 완화하고, 규정 준수를 개선하고, 라이선스 비용을 관리하고, 성능을 모니터링하는 것이 중요합니다. 데이터 감사가 중요한 이유에 대한 자세한 내용은 감사 및 모니터링 개요를 참조하세요.

역할과 목표에 따라 감사 및 모니터링에 접근하는 방법에는 여러 가지가 있습니다. 다음 문서에서는 다양한 고려 사항과 계획 활동에 대해 설명합니다.

  • 보고서 수준 감사: 보고서 작성자가 만들고, 게시하고, 공유하는 보고서를 사용하는 사용자를 이해하는 데 사용할 수 있는 기술입니다.
  • 데이터 수준 감사: 데이터 작성자가 만들고, 게시하고, 공유하는 데이터 자산의 성능 및 사용 패턴을 추적하는 데 사용할 수 있는 메서드입니다.
  • 테넌트 수준 감사: 관리자가 엔드투엔드 감사 솔루션을 만들기 위해 수행할 수 있는 주요 결정 및 작업입니다.
  • 테넌트 수준 모니터링: 업데이트 및 공지 사항을 포함하여 관리자가 Power BI 서비스를 모니터링하기 위해 수행할 수 있는 전술 작업입니다.

REST API

Power BI REST APIFabric REST API는 Fabric 테넌트에 대한 다양한 정보를 제공합니다. REST API를 사용하여 데이터를 검색하는 것은 Fabric 구현을 관리하고 통제하는 데 중요한 역할을 해야 합니다. 감사를 위해 REST API를 사용하는 계획에 대한 자세한 내용은 테넌트 수준 감사를 참조하세요.

감사 데이터를 검색하여 감사 솔루션을 빌드하거나, 프로그래밍 방식으로 콘텐츠를 관리하거나, 일상적인 작업의 효율성을 높일 수 있습니다. 다음 표에서는 REST API를 사용하여 수행할 수 있는 몇 가지 작업을 제공합니다.

동작 설명서 리소스
사용자 활동 감사 활동 이벤트를 가져올 REST API
작업 영역, 항목 및 사용 권한 감사 REST API를 검색하여 테넌트 인벤토리를 가져오는 비동기 메타데이터 컬렉션
전체 조직에 공유된 콘텐츠 감사 널리 공유되는 링크의 사용을 확인하는 REST API
테넌트 설정 감사 테넌트 설정을 확인하는 REST API
콘텐츠 게시 배포 파이프라인에서 항목을 배포하기 위한 REST API 또는 보고서를 다른 작업 영역에 복제
콘텐츠 관리 의미 체계 모델을 새로 고치는 REST API 또는 의미 체계 모델의 소유권을 인수
게이트웨이 데이터 원본 관리 게이트웨이 데이터 원본에 대한 자격 증명을 업데이트하는 REST API
콘텐츠 내보내기 보고서를 내보내는 REST API
작업 영역 만들기 새 작업 영역을 만드는 REST API
작업 영역 권한 관리 작업 영역에 사용자 권한을 할당하는 REST API
작업 영역 이름 또는 설명 업데이트 작업 영역 특성을 업데이트하는 REST API
작업 영역 복원 삭제된 작업 영역을 복원하는 REST API
의미 체계 모델에서 쿼리 결과를 프로그래밍 방식으로 검색 의미 체계 모델에 대해 DAX 쿼리를 실행할 REST API
용량에 작업 영역 할당 작업 영역을 용량에 할당하는 REST API
프로그래밍 방식으로 데이터 모델 변경 TOM(테이블 형식 개체 모델) API
사용자 지정 애플리케이션에 Power BI 콘텐츠 포함 Power BI 임베디드 분석 클라이언트 API

그 외 다양한 Power BI REST API가 있습니다. 전체 목록은 Power BI REST API 사용을 참조하세요.

변경 계획

Microsoft는 매월 새로운 Fabric 기능을 릴리스합니다. 효과적으로 사용하려면 시스템 감독과 관련된 모든 사람이 최신 상태를 유지하는 것이 중요합니다. 자세한 내용은 테넌트 수준 모니터링을 참조하세요.

Important

최신 상태를 유지하는 것의 중요성을 과소평가하지 마세요. 발표가 몇 개월 늦어지면 Fabric을 적절하게 관리하고 사용자를 지원하는 것이 어려워질 수 있습니다.

고려 사항 및 주요 조치

검사 목록 - 시스템 감독을 위한 고려 사항 및 수행할 수 있는 주요 행동을 따릅니다.

시스템 감독 개선:

  • Fabric 관리자로 허용할 수 있는 사용자 확인: Fabric 관리자 역할이 부여된 사용자 수가 여러 명인 경우 가능하면 그 수를 줄입니다.
  • 임시 관리자용 PIM 사용: Fabric 관리자 권한이 가끔 필요한 사용자가 있다면 Microsoft Entra ID에서 PIM(Privileged Identity Management)을 구현하는 것이 좋습니다. 몇 시간 후에 만료되는 Just-In-Time 역할 권한을 할당하도록 디자인되었습니다.
  • 관리자 교육: Fabric 관리 책임을 다루기 위해 준비한 교차 학습 상태와 설명서를 확인합니다. 백업 담당자는 일관된 방식으로 요구 사항을 적시에 충족할 수 있도록 훈련되어야 합니다.

Fabric 서비스 관리 개선:

  • 테넌트 설정 검토: 모든 테넌트 설정을 검토하여 데이터 문화 목표와 거버넌스 지침 및 정책에 부합하는지 확인합니다. 각 설정에 대해 할당된 그룹을 확인합니다.
  • 테넌트 설정 문서화: 내부 Fabric 커뮤니티에 대한 테넌트 설정 관련 문서를 작성하고 중앙 집중식 포털에 게시합니다. 기능을 사용하기 위해 사용자가 요청해야 하는 그룹을 포함합니다. 테넌트 설정 REST API 가져오기를 사용하여 프로세스를 더 효율적으로 만들고 정기적으로 설정 스냅샷을 만듭니다.
  • 도움말 보기 링크 사용자 지정: 사용자 리소스를 설정하는 경우 멘토링 및 사용자 지원 문서에 설명된 대로 테넌트 설정을 업데이트하여 도움말 보기 메뉴 옵션 아래의 링크를 사용자 지정합니다. 사용자에게 설명서, 커뮤니티, 도움말을 안내합니다.

사용자 컴퓨터 및 디바이스 관리 개선:

  • 일관된 온보딩 프로세스 만들기: 새로운 콘텐츠 제작자의 온보딩이 어떻게 처리되는지 프로세스를 검토합니다. Power BI Desktop과 같은 소프트웨어에 대한 새로운 요청과 사용자 라이선스(무료, Pro 또는 PPU)를 함께 처리할 수 있는지 확인합니다. 새 콘텐츠 작성자가 요청할 항목을 알지 못할 수도 있으므로 온보딩을 간소화할 수 있습니다.
  • 사용자 컴퓨터 업데이트 처리: 모든 사용자가 동일한 버전을 사용하도록 소프트웨어, 드라이버, 설정을 설치 및 업데이트하는 자동화된 프로세스가 있는지 확인합니다.

데이터 아키텍처 계획:

  • 엔드투엔드 데이터 아키텍처의 형태 평가:
    • 조직의 다른 사업부에서 Fabric을 사용하는 방법과 원하는 Fabric 사용 방법을 비교합니다. 차이가 있는지 확인합니다.
    • 해결해야 하는 위험이 있는지 여부.
    • 높은 유지 관리 상황에 대한 대응 여부.
    • Fabric 사용자에게 중요한 데이터 원본은 무엇이며 이를 문서화하고 검색하는 방법입니다.
  • 기존 데이터 게이트웨이 검토: 조직 전체에서 어떤 게이트웨이가 사용되는지 확인합니다. 게이트웨이 관리자와 사용자가 올바르게 설정되었는지 확인합니다. 각 게이트웨이를 지원하는 사용자를 확인하고 게이트웨이 서버를 최신 상태로 유지하기 위한 안정적인 프로세스가 있는지 확인합니다.
  • 개인 게이트웨이 사용 확인: 사용 중인 개인 게이트웨이의 수와 누가 사용하고 있는지를 확인합니다. 사용량이 많은 경우 표준 모드 게이트웨이의 사용으로 이동하기 위한 단계를 수행합니다.

사용자 라이선스 관리 개선:

  • 사용자 라이선스를 요청하는 프로세스 검토: 사용자가 라이선스를 취득하기 위한 필수 조건을 포함한 프로세스를 명확히 합니다. 프로세스를 개선해야 하는지 여부를 확인합니다.
  • 셀프 서비스 라이선스 구매를 처리하는 방법 결정: 셀프 서비스 라이선스를 구매할 수 있도록 설정할지 여부를 명확히 합니다. 라이선스를 구매할 수 있는 방법에 대해 사용자의 의도와 일치하지 않는 경우 설정을 업데이트합니다.
  • 사용자 평가판 처리 방법 확인: 사용자 라이선스 평가판이 사용하도록 설정되었는지 또는 사용하지 않도록 설정되었는지 확인합니다. 모든 사용자 평가판은 사용자 단위 Premium입니다. 이는 평가판에 등록하는 무료 라이선스 사용자와 사용자 단위 Premium 평가판에 등록하는 Pro 사용자에게 적용됩니다.

비용 관리 개선:

  • 비용 관리 목표 확인: 비용, 기능, 사용 패턴, 리소스의 효과적인 활용 간의 균형을 유지하는 방법을 고려합니다. 적어도 매년 비용을 평가하는 정기적인 프로세스를 예약합니다.
  • 활동 로그 데이터 획득: 비용 분석을 지원하기 위해 활동 로그 데이터에 대한 액세스 권한이 있는지 확인합니다. 할당된 라이선스를 사용 중인 사람과 그렇지 않은 사람을 파악하는 데 사용할 수 있습니다.

보안 및 데이터 보호 개선:

  • 데이터 보호에 대한 기대치를 정확하게 파악: 데이터 보호에 대한 기대치(예: 민감도 레이블 사용 방법)를 문서화하고 사용자에게 전달해야 합니다.
  • 외부 사용자를 처리하는 방법 결정: Fabric 콘텐츠를 외부 사용자와 공유하는 방법에 대한 조직 정책을 이해하고 문서화합니다. Fabric의 설정이 외부 사용자에 대한 정책을 지원하는지 확인합니다.
  • 모니터링 설정: Fabric에서 사용자 동작과 작업을 모니터링하기 위해 클라우드용 Microsoft Defender Apps 사용을 조사합니다.

감사 및 모니터링 개선:

  • 감사 요구 사항 계획: 감사 솔루션에 대한 주요 비즈니스 요구 사항을 수집하고 문서화합니다. 감사 및 모니터링의 우선 순위를 고려합니다. 감사 솔루션 유형, 사용 권한, 사용할 기술 및 데이터 요구 사항과 관련된 주요 결정을 내립니다. IT 팀과 상의하여 현재 존재하는 감사 프로세스와 새 솔루션 빌드를 위한 요구 사항의 기본 설정을 명확히 합니다.
  • 역할 및 책임 고려: 감사 솔루션 빌드와 감사 데이터의 지속적인 분석에 참여할 팀을 식별합니다.
  • 사용자 활동 데이터 추출 및 저장: 현재 원시 데이터를 추출하고 저장하지 않는 경우 사용자 활동 데이터 검색을 시작합니다.
  • 테넌트 인벤토리 데이터의 스냅샷 추출 및 저장: 모든 작업 영역 및 항목을 설명하는 테넌트 인벤토리를 빌드하기 위한 메타데이터 검색을 시작합니다.
  • 사용자 및 그룹 데이터의 스냅샷 추출 및 저장:사용자, 그룹 및 서비스 주체에 대한 메타데이터 검색을 시작합니다.
  • 큐레이팅된 데이터 모델 만들기: 원시 데이터의 데이터 정리 및 변환을 수행하여 감사 솔루션에 대한 분석 보고를 지원하는 큐레이팅된 데이터 모델을 만듭니다.
  • 감사 데이터를 분석하고 결과에 따라 작업: 분석 보고서를 만들어 큐레이팅된 감사 데이터를 분석합니다. 수행해야 하는 작업, 대상 및 시기를 명확히 합니다.
  • 추가 감사 데이터 포함: 시간이 지남에 따라 다른 감사 데이터가 보안 데이터와 같은 활동 로그 데이터를 보완하는 데 도움이 되는지 여부를 결정합니다.

자세한 내용은 테넌트 수준 감사를 참조하세요.

REST API 사용:

  • REST API 사용 계획: Power BI REST API 및 Fabric REST API에서 검색하는 데 가장 유용한 데이터를 고려합니다.
  • 개념 증명 수행: 간단한 개념 증명을 수행하여 데이터 요구 사항, 기술 선택 사항 및 권한의 유효성을 검사합니다.

질문

아래와 같은 질문을 사용하여 시스템 감독을 평가합니다.

  • 사용하는 또는 사용하지 않는 비정형 관리 설정이 있나요? 예를 들면, 조직 전체에서 웹에 게시하도록 허용하나요(이 기능은 제한하는 것이 좋습니다)?
  • 관리 설정 및 정책이 사용자의 비즈니스 운형 방식과 일치하나요, 아니면 이를 억제하나요?
  • 새 설정을 엄격하게 평가하고 이를 설정하는 방법을 결정하는 프로세스가 마련되어 있나요? 아니면 가장 제한적인 설정만 예방 조치로 설정되어 있나요?
  • Microsoft Entra 보안 그룹은 누가 무엇을 할 수 있는지 관리하는 데 사용됩니까?
  • 중앙 팀에서 효과적인 감사 및 모니터링 도구를 볼 수 있나요?
  • 모니터링 솔루션이 데이터 자산이나 사용자 활동 또는 둘 다에 대한 정보를 표시하나요?
  • 감사 및 모니터링 도구가 실행 가능한가요? 명확한 임계값과 작업이 설정되어 있나요? 또는 모니터링 보고서에서 데이터 자산 내용을 간단히 설명하나요?
  • Azure Log Analytics가 패브릭 용량에 대한 자세한 모니터링에 사용되고 있거나 사용될 계획이 있나요? Azure Log Analytics의 잠재적 혜택과 비용을 의사 결정자가 명확히 알고 있나요?
  • 민감도 레이블 및 데이터 손실 방지 정책을 사용하나요? 이에 대한 잠재적 혜택과 비용을 의사 결정자가 명확히 알고 있나요?
  • 관리자가 현재 라이선스 수와 라이선스 비용을 알고 있나요? 총 BI 지출 중 Fabric 용량, Pro 및 PPU 라이선스에 사용되는 비율은 얼마나 되나요? 조직이 Power BI 콘텐츠에 Pro 라이선스만 사용하는 경우 사용자 수와 사용 패턴을 고려하여 Power BI Premium 또는 Fabric 용량으로의 비용 효율적인 전환을 보장할 수 있나요?

성숙도 수준

다음 성숙도는 Power BI 시스템 감독의 현재 상태를 평가하는 데 도움이 됩니다.

수준 시스템 감독 상태
100: 초기 • 테넌트 설정이 최상의 판단에 따라 한 명 이상의 관리자에 의해 독립적으로 구성됩니다.

• 게이트웨이 및 용량과 같은 아키텍처 요구 사항이 필요에 따라 충족됩니다. 그러나 전략적 계획은 없습니다.

• Fabric 활동 로그는 사용되지 않거나 전술적 목적으로 선택적으로 사용됩니다.
200: 반복 가능 • 테넌트 설정은 수립된 거버넌스 지침 및 정책에 부합하도록 의도적으로 조정됩니다. 또한 모든 테넌트 설정은 정기적으로 검토됩니다.

• 소수의 특정 관리자가 선택됩니다. 모든 관리자는 Fabric에서 사용자가 수행하려는 작업을 잘 이해하고 있으므로 사용자를 지원할 수 있는 좋은 위치에 있습니다.

• 사용자가 라이선스 및 소프트웨어를 요청할 수 있는 잘 정의된 프로세스가 있습니다. 요청 양식은 사용자가 쉽게 찾을 수 있습니다. 셀프 서비스 구매 설정이 지정됩니다.

• 민감도 레이블은 Microsoft 365에서 구성됩니다. 그러나 레이블 사용은 일관성이 없습니다. 데이터 보호의 장점에 대해 사용자가 쉽게 이해하기 어렵습니다.
300: 정의됨 • 테넌트 설정은 올바른 그룹에 대한 액세스를 요청하는 방법을 포함하여 사용자가 참조할 수 있도록 중앙 포털에 완전히 문서화되어 있습니다.

• 연속성, 안정성 및 일관성을 보장하기 위해 관리자를 위한 교차 교육 및 설명서가 있습니다.

• 민감도 레이블이 콘텐츠에 일관되게 할당됩니다. 데이터 보호를 위해 민감도 레이블을 사용할 경우의 장점을 사용자가 알 수 있습니다.

• 보고 및 감사를 위해 Fabric 활동 로그 및 API 데이터를 안전한 위치로 내보내는 자동화된 프로세스가 마련되어 있습니다.
400: 가능 • 관리자가 COE 및 거버넌스 팀과 긴밀하게 협력하여 Fabric을 감독합니다. 사용자 역량 강화와 거버넌스의 균형이 성공적으로 이루어집니다.

• 데이터 아키텍처의 분산 관리(예: 게이트웨이 또는 용량 관리)가 민첩성 및 제어의 균형을 위해 효과적으로 처리됩니다.

• 데이터 손실 방지를 위해 클라우드용 Microsoft Defender에서 자동화된 정책을 설정하고 적극적으로 모니터링합니다.

• 활동 로그 및 API 데이터를 적극적으로 분석하여 Fabric 작업을 모니터링하고 감사를 수행합니다. 데이터를 기반으로 사전 작업을 수행합니다.
500: 효율 • Fabric 관리자가 COE와 긴밀하게 협력하여 현재 상태를 적극적으로 유지합니다. Fabric 제품 팀의 블로그 게시물과 릴리스 계획은 자주 검토되어 예정된 변경 내용을 계획합니다.

• 정기적인 비용 관리 분석을 통해 사용자 요구 사항을 비용 효율적인 방식으로 충족할 수 있습니다.

• Fabric REST API를 사용하여 테넌트 설정 값을 정기적으로 검색합니다.

• 채택 및 거버넌스 노력을 알리고 개선하기 위해 활동 로그와 API 데이터를 적극적으로 사용합니다.

시스템 감독 및 Fabric 관리에 대한 자세한 내용은 다음 리소스를 참조하세요.

Microsoft Fabric 채택 로드맵 시리즈의 다음 문서에서 효과적인 변경 관리에 대해 알아봅니다.