Power BI 구현 계획: 데이터 게이트웨이

참고 항목

이 문서는 Power BI 구현 계획 시리즈의 일부를 구성합니다. 이 시리즈는 주로 Microsoft Fabric 내의 Power BI 환경에 중점을 둡니다. 시리즈에 대한 소개는 Power BI 구현 계획을 참조하세요.

이 문서는 Microsoft Fabric용 온-프레미스 데이터 게이트웨이 및 VNet(가상 네트워크) 데이터 게이트웨이를 계획하고 구현하는 데 도움이 됩니다. 주로 다음을 대상으로 합니다.

• 패브릭 관리자: 조직에서 패브릭 감독을 담당하는 관리자입니다. Fabric 관리자는 Power Platform 관리자, 데이터베이스 관리자, 정보 보안 팀, 네트워킹 팀 및 기타 관련 팀과 공동 작업해야 할 수도 있습니다.
• 게이트웨이 관리자: 게이트웨이 및 해당 데이터 원본 연결을 구현, 관리, 모니터링할 책임이 있는 개인입니다.
• 게이트웨이 기여자: 게이트웨이 데이터 원본 연결을 추가하고 관리하는 데 책임이 있는 분산된 팀과 개인입니다.
• COE(우수성 센터), IT, BI 팀: 데이터에 액세스, 연결, 새로 고침이 필요한 사용자를 지원하는 팀입니다.
• 콘텐츠 소유자 및 작성자: 게이트웨이를 사용하여 데이터 원본에 연결하고 Fabric 데이터 항목을 새로 고치는 팀과 개인입니다.

Power BI 의미 체계 모델, 데이터 흐름 및 기타 Fabric 데이터 항목의 원본 데이터에 액세스하려면 데이터 게이트웨이가 필요할 수 있습니다. 데이터 게이트웨이는 개인 네트워크 또는 온-프레미스 데이터 원본과 Fabric을 포함한 클라우드 서비스 간에 데이터를 안전하게 전송합니다.

참고 항목

이 문서는 게이트웨이의 개요를 제공합니다. Fabric 콘텐츠를 지원하기 위해 게이트웨이를 계획하고 구현하기 위한 주요 고려 사항 및 조치에 중점을 둡니다.

게이트웨이 작동 방법에 대한 자세한 내용은 다음을 참조하세요.

• 온-프레미스 데이터 게이트웨이란?
• 온-프레미스 게이트웨이 아키텍처
• VNet(가상 네트워크) 게이트웨이 아키텍처
• 중요 비즈니스용 게이트웨이 솔루션 계획, 스케일링, 유지 관리

주요 의사 결정 계획

게이트웨이는 성공적인 Power BI 및 Fabric 구현에 필수적인 경우가 많습니다. COE 또는 중앙 데이터 및 BI 팀은 일반적으로 게이트웨이를 계획하고 중앙에서 관리하지만 일부 조직에서는 분산된 팀을 사용하여 게이트웨이를 관리합니다. 향후 중단 및 거버넌스 위험 가능성을 완화하려면 게이트웨이를 사용하는 방법과 시기를 신중하게 계획하는 것이 중요합니다.

일반적으로 두 개의 고유한 단계에서 게이트웨이 구현을 계획합니다.

• 테넌트 설정: Fabric 구현 및 마이그레이션할 때 데이터 원본에 게이트웨이가 필요한지 여부를 평가해야 합니다. 게이트웨이 계획 활동은 보안, 작업 영역, 감사 및 모니터링의 테넌트 수준 계획과도 관련이 있을 수 있습니다.
• BI 솔루션 계획: 새로운 BI 솔루션을 계획할 때는 새 솔루션에 대한 기술 요구 사항을 수집하는 동시에 솔루션에 게이트웨이가 필요한지 여부를 평가해야 합니다. 기존 솔루션에 새 데이터 원본을 추가할 때 게이트웨이가 필요할 수도 있습니다.

게이트웨이 구현 계획은 게이트웨이가 필요한지 여부부터 시작하여 주요 결정을 내리는 것부터 시작합니다.

팁

먼저 데이터 원본의 인벤토리를 만듭니다. 각 데이터 원본에 대해 다음과 같은 주요 결정을 평가해야 합니다. 결과를 문서화하고 커뮤니케이션 허브 또는 중앙 집중식 포털과 같이 쉽게 액세스할 수 있는 중앙 위치에 저장하세요.

게이트웨이가 필요한지 확인

일반적으로 다음과 같은 경우 데이터 원본에 대한 게이트웨이가 필요합니다.

• 데이터 원본은 온-프레미스에 있습니다.
• 데이터 원본은 개인 네트워크에 있습니다.
• 커넥터 소프트웨어용 호스트가 필요합니다.
• 특정 커넥터 또는 기능에 대한 보안 격리가 필요합니다.

이러한 상황에서는 다음을 수행하기 위한 게이트웨이가 필요합니다.

• Fabric 포털에서 데이터를 새로 고칩니다. 이 시나리오는 콘텐츠 작성자가 게이트웨이가 필요한 데이터 원본에 대해 Power BI 서비스에서 데이터 새로 고침을 설정하는 경우에 적용됩니다.
• Fabric 포털에서 콘텐츠를 만듭니다. 이 시나리오는 콘텐츠 작성자가 게이트웨이가 필요한 Power BI 서비스에서 데이터 항목(예: 의미 체계 모델 또는 데이터 흐름)을 만들거나 수정하는 경우에 적용됩니다.
• DirectQuery 연결을 지원합니다. 이 시나리오는 콘텐츠 작성자가 DirectQuery(또는 이중) 스토리지 모드 테이블을 포함하는 의미 체계 모델을 게시하고 해당 테이블의 데이터 원본에 게이트웨이가 필요한 경우에 적용됩니다. 이 사용 시나리오에서는 데이터 원본에 정의된 사용자별 데이터 권한을 적용하는 기능도 다룹니다. 예를 들어 SQL Server 데이터베이스는 RLS(행 수준 보안)을 적용할 수 있고 Power BI는 SSO(Single Sign-On) 연결을 관리할 수 있습니다. 자세한 내용은 소비자 ID를 기반으로 데이터 보안 강화를 참조하세요.
• SQL Server Analysis Services에 실시간 연결합니다. 이 시나리오는 콘텐츠 작성자가 SSAS(SQL Server Analysis Services) 데이터베이스에 대한 라이브 연결을 사용하는 보고서를 게시하는 경우에 적용됩니다.

다음 섹션에서는 게이트웨이가 필요한 경우에 대해 설명합니다.

온-프레미스 데이터 원본

Fabric 포털에서 온-프레미스 데이터 원본에 연결하려면 게이트웨이가 필요합니다. 게이트웨이는 게이트웨이 머신에서 쿼리 식을 평가하고 온-프레미스 데이터를 클라우드로 안전하게 전송하는 브리지 역할을 합니다.

이 시나리오는 다음과 같은 경우에 연결할 때 관련됩니다.

• 온-프레미스 머신에 상주하는 데이터 원본입니다.
• 로컬 디렉터리에 저장된 파일입니다.
• 단일 쿼리에 결합된 클라우드 및 온-프레미스 데이터 원본입니다.
• 서비스 제공 인프라 또는 IaaS라고 알려진 클라우드 기반 VM(가상 머신)입니다.

개인 네트워크 데이터 원본

Azure VNet(Azure Virtual Network)과 같은 개인 네트워크에 있는 데이터 원본에 연결하려면 게이트웨이가 필요합니다. 가상 네트워크 또는 VNet은 공용 인터넷에서 트래픽을 격리하는 네트워크의 논리적으로 격리된 세그먼트입니다. VNet은 향상된 네트워크 보안을 제공합니다.

이 시나리오는 데이터 원본이 다음과 같은 경우에 관련이 있습니다.

• 조직 네트워크(또는 방화벽 뒤에 있는)와 같은 개인 네트워크 내의 데이터 센터에 상주합니다.
• VNet 내의 클라우드 기반 VM입니다(서비스 제공 인프라 또는 IaaS라고도 함).
• VNet 내의 클라우드 기반 데이터베이스 서비스입니다(Platform as a Service 또는 PaaS라고 함).

참고 항목

클라우드 데이터 원본에 대한 게이트웨이가 필요하지 않다는 것은 일반적인 오해입니다. 클라우드 데이터 원본이 프라이빗 조직 네트워크 내에 있는 경우 게이트웨이가 필요합니다.

호스트 커넥터 소프트웨어

경우에 따라 데이터 원본에 연결하는 데 필요한 지원 항목을 호스트하는 게이트웨이가 필요할 수 있습니다. 이 소프트웨어에는 게이트웨이 머신에 설치하는 사용자 지정 데이터 커넥터, 드라이버, 라이브러리가 포함될 수 있습니다. Power BI 서비스는 이 소프트웨어에 액세스할 수 없으므로 클라우드 데이터 원본에 연결하는 경우에도 게이트웨이를 사용하지 않고 이를 사용하는 데이터 원본을 새로 고칠 수 없습니다.

이 시나리오는 다음과 같은 커넥터를 사용하여 데이터 원본에 연결하는 경우에 관련이 있습니다.

• 드라이버 공식 커넥터에는 필수 구성 요소 드라이버를 설치해야 할 수 있습니다. 예를 들어 Oracle 데이터베이스에 연결할 때 Oracle Data Access Client 소프트웨어가 필요할 수 있습니다.
• 사용자 지정 커넥터 일부 데이터 원본에는 사용자 지정 또는 타사 커넥터가 필요할 수 있습니다. 예를 들어 레거시 또는 독점 시스템에 연결하기 위해 사용자 지정 커넥터가 필요할 수 있습니다.
• 클라이언트 라이브러리 일부 데이터 원본에는 클라이언트 도구가 연결할 수 있도록 지원하는 라이브러리가 필요할 수 있습니다. 예를 들어 Analysis Services 데이터베이스에 연결할 때 클라이언트 라이브러리를 설치해야 합니다.
• ODBC 또는 OLE DB 커넥터 공식 커넥터에는 ODBC 드라이버 또는 OLE DB 공급자가 필요할 수 있습니다. 예를 들어 SAP HANA에 연결하기 위해 ODBC 드라이버가 필요합니다.

Important

콘텐츠 작성자가 Power BI Desktop과 같은 클라이언트 도구를 사용하고 해당 솔루션이 드라이버, 커넥터 또는 공급자를 사용하는 경우 콘텐츠 작성자 머신에 설치된 것과 동일한 구성 요소를 게이트웨이 머신에 설치해야 합니다. 작성자 머신과 데이터 게이트웨이 간에 누락되거나 일치하지 않는 구성 요소는 게시된 콘텐츠의 데이터 새로 고침이 실패하는 일반적인 이유입니다. 자세한 내용은 사용자 도구 및 디바이스를 참조하세요.

보안 격리

웹 커넥터 또는 Web.BrowserContents 함수와 같은 특정 쿼리 커넥터 또는 함수를 사용하려면 게이트웨이가 필요합니다. 이러한 커넥터 및 함수에는 보안 격리를 비롯한 여러 가지 이유로 게이트웨이가 필요합니다.

팁

웹 페이지 데이터 원본에 연결할 때는 다음과 같은 대안을 고려합니다.

• Web.Contents 함수: 브라우저를 통해 액세스할 필요가 없는 웹 콘텐츠에 연결하는 경우 Web.Contents 함수를 사용하는 것이 좋습니다. 이 함수는 브라우저 컨트롤을 사용하지 않으므로 게이트웨이가 필요하지 않습니다.
• Notebooks: Fabric 용량이 있는 경우 Fabric 노트북을 사용하여 데이터를 변환하는 것이 좋습니다. Notebooks에는 웹 페이지 데이터에 대한 게이트웨이가 필요하지 않으며 Power Query에 비해 웹 페이지 정보를 검색할 때 더 나은 성능을 발휘할 수 있습니다.

이 시나리오는 다음과 같은 커넥터 및 드라이버를 사용하여 데이터 원본에 연결하는 경우에 관련이 있습니다.

• 웹 커넥터를 사용하는 쿼리입니다.
• Web.Page 또는 Web.BrowserContents 함수를 사용하는 쿼리입니다.
• ACE(Access 데이터베이스 엔진) 드라이버를 사용하는 연결입니다.

필요한 게이트웨이 유형 결정

게이트웨이가 필요하다는 것을 확인한 후에는 설치할 게이트웨이 유형을 결정해야 합니다. 게이트웨이에는 세 가지 유형이 있습니다.

• 온-프레미스 데이터 게이트웨이(표준 모드)
• 개인 게이트웨이로 알려진 온-프레미스 데이터 게이트웨이(개인 모드)
• VNet(가상 네트워크) 게이트웨이 서비스

선택하는 게이트웨이 유형은 요구 사항 및 데이터 원본에 따라 달라집니다. 다음 섹션에서는 세 가지 게이트웨이 유형을 각각 설명합니다.

온-프레미스 데이터 게이트웨이(표준 모드)

온-프레미스 데이터 게이트웨이(표준 모드)를 사용하면 여러 사용자가 단일 공유 게이트웨이를 통해 데이터 원본에 연결할 수 있습니다. 일반적으로 Always-On VM에 표준 모드 게이트웨이를 중앙에서 설치하고 관리합니다. 표준 모드 게이트웨이를 사용하면 Fabric, Power BI, 기타 Power Platform 서비스와 같은 여러 서비스의 데이터에 연결할 수 있습니다.

다음 다이어그램에서는 표준 모드 게이트웨이의 개요를 보여 줍니다.

Important

이 다이어그램에서는 온-프레미스 데이터 게이트웨이의 아키텍처를 표시하지는 않습니다.

다이어그램은 다음과 같은 개념을 보여 줍니다.

Item	설명
	온-프레미스 데이터 게이트웨이(표준 모드)는 온-프레미스 데이터 원본에서 클라우드 서비스로 데이터를 안전하게 전송합니다.
	특정 시나리오의 클라우드 데이터 원본에는 표준 모드 데이터 게이트웨이가 필요합니다(이전 섹션에서 설명).
	표준 모드 데이터 게이트웨이는 Always-On VM에 설치됩니다. 관리자는 VM 및 데이터 게이트웨이를 중앙에서 관리합니다. 필요한 경우 게이트웨이 관리자는 데이터 원본 연결에 필요한 소프트웨어를 설치합니다.
	여러 사용자가 데이터 게이트웨이 데이터 원본에 연결할 수 있습니다.
	사용자는 의미 체계 모델, 데이터 흐름, 파이프라인 또는 페이지를 매긴 보고서와 같은 Fabric 작업 영역에 게시된 항목에 데이터 게이트웨이를 사용할 수 있습니다.
	사용자는 Power Platform 데이터 흐름과 같은 다른 Power Platform 클라우드 서비스에 데이터 게이트웨이를 사용할 수 있습니다.

다음과 같은 특정 상황에서는 표준 모드 게이트웨이가 필요합니다.

• 다양한 Microsoft 클라우드 서비스(예: Power Apps 및 Fabric)와 Fabric 데이터 항목(예: 데이터 흐름)은 온-프레미스 데이터 원본(또는 게이트웨이가 필요한 클라우드 데이터 원본)을 쿼리해야 합니다.
• 페이지를 매긴 보고서는 온-프레미스 데이터 원본(또는 게이트웨이가 필요한 클라우드 데이터 원본)을 쿼리해야 합니다.
• 의미 체계 모델은 온-프레미스 데이터 원본(또는 게이트웨이가 필요한 클라우드 데이터 원본)에 연결해야 하는 DirectQuery 스토리지 모드를 사용합니다.
• SSAS 라이브 연결입니다.
• 데이터 원본은 사용자 지정 데이터 커넥터, 드라이버 또는 라이브러리에 따라 달라집니다.
• 게이트웨이를 재배치하거나 마이그레이션해야 할 필요성이 예상되는 경우입니다.

개인 게이트웨이

일반적으로 개인 게이트웨이라고 알려진 온-프레미스 게이트웨이(개인 모드)를 사용하면 사용자가 동일한 머신에 있는 온-프레미스 데이터 원본에 연결할 수 있습니다. 사용자는 일반적으로 자신의 머신에서 개인 게이트웨이를 설치하고 관리합니다. 개인 게이트웨이를 사용하면 사용자가 다른 Power Platform 서비스의 데이터에 연결할 수 없습니다. 또한 게이트웨이 또는 연결을 다른 사용자와 공유할 수도 없습니다.

개인 게이트웨이는 한 개인이 제한적으로 개인 용도로 사용합니다. 일반적으로 콘텐츠 작성자는 이러한 게이트웨이를 설치하고 사용하여 개인 BI를 수행합니다. 이러한 게이트웨이는 공유할 수 없으므로 개인 BI로 제한됩니다. 또한 개인 게이트웨이를 사용하려면 사용자에게 개인 게이트웨이 소프트웨어를 다운로드하고 설치하기 위한 머신 권한 및 정책 승인이 있어야 합니다.

팁

팀, 부서 또는 엔터프라이즈 BI 솔루션에 개인 게이트웨이를 사용하지 않아야 합니다.

온-프레미스 데이터에 연결하는 대부분의 시나리오에서는 표준 모드에서 게이트웨이를 사용해야 합니다(이전 섹션에서 설명). 이는 여러 사용자와 표준 모드 게이트웨이를 공유할 수 있고 DirectQuery 쿼리 및 라이브 연결을 지원하며 게이트웨이 거버넌스 및 관리를 중앙 집중화하는 더 많은 옵션이 있기 때문입니다.

주의

개인 게이트웨이는 일반적으로 사용자 머신에 설치되므로 관리 및 통제하기가 더 어렵습니다. 개인 게이트웨이를 사용해야 하는 경우 서비스 계정을 사용하는 중앙에서 관리되는 VM으로 이동하는 것이 좋습니다. 이 접근 방식을 사용하면 게이트웨이 가용성이 사용자 머신에 종속되지 않고(꺼질 수 있습니다) 게이트웨이 거버넌스 및 관리가 향상됩니다.

다음 다이어그램에서는 개인 게이트웨이의 개요를 보여 줍니다.

Important

이 다이어그램에서는 온-프레미스 데이터 게이트웨이의 아키텍처를 표시하지는 않습니다.

다이어그램은 다음과 같은 개념을 보여 줍니다.

Item	설명
	개인 게이트웨이는 일반적으로 사용자 머신에 설치됩니다.
	개인 게이트웨이는 사용자 머신의 로컬 데이터 원본에서 클라우드 서비스로 데이터를 안전하게 전송합니다.
	개인 게이트웨이는 일반적으로 개인 게이트웨이를 설치한 사용자가 관리합니다.
	단일 사용자는 제한적인 개인 용도로 개인 게이트웨이를 사용합니다. 개인 모드 게이트웨이는 공유할 수 없습니다.
	개인 게이트웨이는 의미 체계 모델 또는 Power BI 데이터 흐름과 같은 Power BI 작업 영역에 게시된 항목에만 사용할 수 있습니다.

다시 말하지만, 개인 게이트웨이는 한 개인이 제한적으로 개인 용도로 사용하도록 의도되었습니다. 그러나 개인 게이트웨이를 사용해야 하는 두 가지 특정 시나리오가 있습니다.

• 셀프 서비스 콘텐츠 작성자는 머신 또는 다른 온-프레미스 데이터 원본의 로컬 데이터 원본에 연결된 게시된 콘텐츠를 새로 고쳐야 합니다.
• 의미 체계 모델은 Power Query에서 Python 또는 R 코드를 사용합니다.

팁

가능하면 개인 게이트웨이를 사용하지 마세요. 대신 다음과 같은 대체 방법을 사용해 보세요.

• SharePoint: 로컬 파일에 연결해야 하는 경우 대신 해당 파일을 SharePoint나 회사 또는 학교용 OneDrive에 업로드하는 것이 좋습니다. 게이트웨이가 필요하지 않은 SharePoint 폴더 커넥터를 사용하여 이러한 파일에 연결할 수 있습니다.
• OneLake: 로컬 파일에 연결해야 하고 Fabric 용량이 있는 경우 OneLake 파일 탐색기를 사용하여 레이크하우스와 파일을 업로드하고 동기화할 수도 있습니다. Fabric 레이크하우스에 연결하는 데에는 게이트웨이가 필요하지 않습니다.
• Notebooks: Python 또는 R을 사용하여 데이터를 변환해야 하고 Fabric 노트북을 사용하여 데이터를 변환하고 OneLake에 저장된 테이블에 쓰는 것이 좋습니다. Notebook에는 Python 또는 R 코드를 실행하는 게이트웨이가 필요하지 않습니다. 또한 Notebook에서 사용할 수 있는 향상된 성능 및 추가 기능을 활용할 수 있습니다.

VNet 게이트웨이

VNet 게이트웨이를 사용하면 여러 사용자가 프라이빗 엔드포인트를 사용하는 데이터 원본을 포함하여 프라이빗 네트워크로 보호되는 데이터 원본에 연결할 수 있습니다. VNet 게이트웨이를 사용하면 여러 서비스를 사용하여 데이터에 연결할 수 있으며 게이트웨이 또는 연결을 여러 사용자와 공유할 수 있습니다.

VNet 게이트웨이는 Microsoft 관리되는 서비스입니다. 조직에서 개인 네트워크를 사용하는 경우 VNet 게이트웨이가 필요합니다.

Important

VNet 게이트웨이 서비스를 사용하려는 경우 네트워킹 및 보안을 처리하는 IT 팀과 논의합니다. 이러한 팀은 프라이빗 엔드포인트(해당하는 경우) 및 게이트웨이 통신과 같은 모든 것이 설정되었는지 확인하는 데 도움이 될 수 있습니다.

VNet 게이트웨이는 Power BI Fabric 또는 Premium 용량에만 지원됩니다. VNet 게이트웨이는 해당 용량에 추가 프리미엄 인프라 요금이 청구됩니다.

Important

때때로 이 문서는 Power BI Premium 또는 P SKU(프리미엄 용량 구독)를 언급합니다. Microsoft는 현재 구매 옵션을 통합하고 용량당 Power BI Premium SKU를 사용 중지하고 있습니다. 신규 및 기존 고객은 대신 F SKU(Fabric 용량 구독)로 구매를 고려해야 합니다.

자세한 내용은 Power BI Premium 라이선스 관련 중요 업데이트 및 Power BI Premium FAQ를 참조하세요.

다음 다이어그램에서는 VNet 게이트웨이의 개요를 보여 줍니다.

Important

이 다이어그램에서는 VNet 데이터 게이트웨이의 아키텍처를 표시하지는 않습니다.

다이어그램은 다음과 같은 개념을 보여 줍니다.

Item	설명
	VNet(가상 네트워크) 게이트웨이를 사용하면 Azure VNet과 같은 개인 네트워크의 데이터 원본에 연결할 수 있습니다.
	VNet 데이터 게이트웨이는 Microsoft 관리되는 서비스입니다. Azure Portal 및 Power Platform 관리 포털에서 VNet 데이터 게이트웨이를 중앙에서 관리합니다.
	여러 사용자가 VNet 데이터 게이트웨이를 사용할 수 있습니다.
	사용자는 의미 체계 모델과 같은 Fabric 작업 영역에 게시된 항목에 대해 VNet 데이터 게이트웨이를 사용할 수 있습니다.
	사용자는 Power Platform 데이터 흐름과 같은 다른 Power Platform 서비스에 VNet 데이터 게이트웨이를 사용할 수 있습니다.

Warning

VNet 게이트웨이에는 몇 가지 제한 사항이 있으며 모든 데이터 원본 또는 시나리오를 지원하지는 않습니다. VNet 게이트웨이 구현 및 솔루션 계획을 진행하기 전에 데이터 원본 및 시나리오가 지원되는지 확인하고 자주 묻는 질문을 참조하세요.

게이트웨이 수 결정

게이트웨이가 필요하고 어떤 유형의 게이트웨이가 필요한지 결정한 후에는 필요한 게이트웨이 수를 결정해야 합니다.

필요에 따라 여러 게이트웨이가 필요할 수 있습니다. 설치하고 사용할 게이트웨이 수를 결정할 때 다음 요소를 고려합니다.

가용성 및 성능

새로 고침 또는 쿼리 지연으로 인한 중단을 방지하기 위해 게이트웨이에 고가용성이 있어야 합니다. 게이트웨이 가용성을 보장하는 한 가지 방법은 고가용성 게이트웨이 클러스터에 여러 게이트웨이를 설치하는 것입니다. 게이트웨이 클러스터는 서로 다른 VM에 설치하고 논리적으로 단일 기능 단위(클러스터)로 연결된 게이트웨이 컬렉션입니다. 각 게이트웨이 머신을 노드라고도 합니다.

게이트웨이 클러스터 사용의 이점은 다음과 같습니다.

• 단일 실패 지점 방지:장애 조치(Failover)는 기본 게이트웨이 머신을 사용할 수 없게 되는 경우에 단일 실패 지점을 방지합니다. 사용할 수 없게 되면 쿼리가 클러스터의 다른 노드로 전송됩니다. 여러 머신의 클러스터를 사용하면 위험이 줄어듭니다. 또한 가동 시간이 늘어나 고가용성 및 재해 복구 요구 사항을 충족하는 데 도움이 됩니다.
• 성능 향상:부하 분산은 동시 사용량이 많을 때 성능을 향상시킵니다. 부하 분산은 클러스터의 다른 노드에 쿼리를 전송하여 워크로드를 분산합니다. 이는 기본 게이트웨이가 사용 중이거나 단일 작업(예: 긴 데이터 새로 고침)이 많은 리소스를 사용하는 경우에 유용합니다.
• 가동 중지 시간 방지: 게이트웨이 소프트웨어 업데이트를 설치할 때 클러스터의 한 노드에서 한 번에 설치를 수행할 수 있습니다. 이렇게 하면 전체 클러스터를 오프라인으로 전환할 수 없습니다.

Important

업무상 중요한 워크로드에 게이트웨이 클러스터를 사용하는 것이 좋습니다.

게이트웨이 클러스터 설정에 대한 자세한 내용 및 지침은 업무상 중요한 게이트웨이 솔루션 계획, 스케일링, 유지 관리를 참조하세요.

환경

콘텐츠 작성자는 일반적으로 별도의 환경을 사용하여 개발, 테스트, 프로덕션과 같은 업무상 중요한 솔루션을 개발하고 관리합니다. 사용하는 환경 수와 사용 방법에 따라 각 환경에 대해 별도의 게이트웨이 클러스터를 사용할 수 있습니다.

게이트웨이 클러스터를 서로 다른 환경으로 분리하면 다음을 수행할 수 있습니다.

• 개발 및 테스트 활동으로 인한 중단을 분리하고 최소화합니다.
• 프로덕션 워크로드의 가용성 및 성능을 향상시킵니다.
• 게이트웨이 소프트웨어 업데이트를 설치하고 테스트할 수 있는 안전한 환경을 제공합니다.

Important

프로덕션 워크로드에 대해 별도의 게이트웨이 클러스터를 사용하는 것이 좋습니다. 모든 환경에 하나의 게이트웨이 클러스터가 있는 경우 이는 추가적인 위험을 나타낼 수 있습니다. 비용 및 관리 노력을 최소화하기 위해 개발 게이트웨이 클러스터에 더 적은 리소스(예: 메모리 및 CPU)를 할당하는 것이 일반적입니다.

지역

데이터 새로 고침의 성능을 향상시키려면 데이터 원본, 게이트웨이의 위치 및 사용자가 있는 위치를 고려하는 것이 중요합니다. 대기 시간을 줄이려면 가능한 한 데이터 원본에 가깝게 게이트웨이를 설치해야 합니다. 이러한 이유로 다양한 지역 또는 테넌트를 지원하려면 여러 게이트웨이 클러스터를 설치해야 할 수 있습니다.

주의

게이트웨이 설치가 조직의 모든 데이터 상주 요구 사항을 준수하는지 확인합니다.

Important

대기 시간을 최소화하려면 데이터 원본과 동일한 지역에 있는 머신에 게이트웨이를 설치하는 것이 좋습니다. 또한 VNet 게이트웨이의 경우 게이트웨이와 데이터 원본은 동일한 서브넷에 있어야 합니다.

검사 목록 - 게이트웨이 구현을 계획하고 관리하는 경우 주요 의사 결정 및 작업에는 다음이 포함됩니다.

• 데이터 원본의 인벤토리 만들기: 데이터 원본의 인벤토리를 사용하면 게이트웨이가 필요한 데이터 원본을 확인하고 문서화할 수 있습니다.
• 게이트웨이가 필요한 상황 결정: 콘텐츠 작성자와 소비자의 작업 방식을 고려합니다. 게이트웨이가 필요한 시기를 잘 알고 있는지 확인합니다. 사용자 커뮤니티를 위한 문서 및 학습을 만듭니다.
• 필요한 게이트웨이 유형 결정: 선택한 게이트웨이 유형이 요구 사항을 충족하는지 확신할 수 있도록 모든 가정의 유효성을 검사하고 가능한 제한 사항을 평가해야 합니다.
• 개인 게이트웨이 방지: 대신 표준 모드에서 게이트웨이를 사용하는 것이 좋습니다. 표준 모드 게이트웨이를 사용하도록 리디렉션할 수 있는 개인 게이트웨이 데이터 원본이 있는지 확인합니다(단일 개인의 사용으로 제한되지 않도록).
• 게이트웨이 클러스터가 필요한지 여부 결정: 업무상 중요한 솔루션에는 게이트웨이 클러스터를 사용합니다. 게이트웨이 클러스터는 고가용성 및 부하 분산 기능을 제공합니다. 또한 단일 실패 지점을 방지하고 동시 사용량이 많은 기간 동안 성능을 향상시키는 데 도움이 됩니다.
• 필요한 게이트웨이 수 결정: 중단을 방지하려면 다양한 환경에 대해 별도의 게이트웨이 클러스터를 고려합니다. 사용 현황이나 지역과 같은 다른 요인을 고려합니다.

게이트웨이 설치

이 시점에서 필요한 게이트웨이 유형과 개수를 알 수 있습니다. 다음으로 게이트웨이 설치를 계획해야 합니다. 일반적으로 게이트웨이는 이 용도 전용으로 사용되는 VM(경우에 따라 게이트웨이 머신이라고 함)에 설치됩니다. 사용자 활동 및 데이터 새로 고침 작업을 지속적으로 지원하기 위해 게이트웨이 클러스터의 각 머신이 항상 켜져 있어야 합니다.

참고 항목

VNet 게이트웨이는 관리 서비스이므로 다운로드하여 설치하지 않습니다. 대신 Azure Portal에서 VNet 게이트웨이를 프로비전하고 설정한 다음, Fabric 또는 Power BI Premium 용량에 바인딩합니다. 자세한 내용은 가상 네트워크 데이터 게이트웨이 만들기를 참조하세요.

게이트웨이 소유자 및 설치 관리자 식별

게이트웨이를 설치하기 전에 게이트웨이를 설치하고 소유할 사용자를 식별합니다.

게이트웨이 소유자

일반적으로 게이트웨이 소유자는 게이트웨이를 설치, 소유, 관리하는 기술 담당자입니다. 게이트웨이 소유자는 다양한 활동을 담당합니다.

• 계획: 앞에서 설명한 대로 주요 결정을 내리고 초기 시스템 리소스를 포함하여 게이트웨이 머신에 대한 기술 사양을 정의합니다. 또한 게이트웨이 소유자는 지원 계획이 마련되어 있는지 확인해야 합니다.
• 설치: 게이트웨이 소프트웨어를 설치하고 처음 설치 및 설정을 수행할 적절한 머신을 선택합니다.
• 관리: 최적화를 위한 게이트웨이 설정 또는 기본 설정(예: 데이터 스풀링 대신 스트리밍 구성) 또는 모니터링 목적(예: 성능 로깅 구성)을 변경합니다. 또한 게이트웨이 소유자는 스케일 업(게이트웨이 머신에 더 많은 리소스 추가) 또는 스케일 아웃(클러스터에 더 많은 게이트웨이 설치) 시기를 결정합니다.
• 테스트: 최초 설정하는 동안 게이트웨이 사용의 유효성을 검사하여 게이트웨이 머신에 충분한 리소스를 사용할 수 있는지 확인합니다. 또한 게이트웨이 소유자는 설치하기 전에 월별 업데이트를 테스트해야 합니다.
• 업데이트: 게이트웨이 소프트웨어 및 지원 항목(예: 커넥터 소프트웨어)을 적시에 업데이트하고 설치합니다.
• 모니터링: 문제 및 비정상적인 활동을 모니터링할 수 있는 게이트웨이 로그 파일의 컬렉션을 포함한 게이트웨이 가동 시간 및 상태를 모니터링합니다.
• 마이그레이션: 더 많은 팀에서 액세스할 수 있는 안전한 장소에 복구 키를 저장합니다. 또한 게이트웨이 소유자는 필요한 경우 이러한 키를 사용하여 게이트웨이를 마이그레이션, 복원 또는 재배치할 수 있어야 합니다.

Important

게이트웨이 소유자가 이러한 책임을 인식하고 이에 동의하는지 확인합니다. 게이트웨이 소유자가 게이트웨이를 관리할 준비가 되어 있지 않은 경우 콘텐츠 소유자와 작성자를 차단하는 종속성이 빠르게 될 수 있습니다. 또한 게이트웨이 소유자가 게이트웨이를 설치 및 관리하는 방법을 이해하고 있는지 파악하고 그렇지 않은 경우 이를 수행하도록 학습할 방법을 식별합니다.

팁

일부 조직에서는 사업부 및 부서 내에서 게이트웨이 소유권을 성공적으로 허용하는 반면, 다른 조직에서는 중앙 집중식 팀(예: IT)에 대한 게이트웨이 소유권을 예약합니다. 이를 처리하는 한 가지 방법은 IT가 게이트웨이 클러스터 노드를 관리하고 사업부에서 데이터 원본 연결을 관리하는 파트너 관계를 형성하는 것입니다.

게이트웨이 소유권은 중요한 책임이기 때문에 조직에 게이트웨이를 설치할 수 있는 사용자를 명확하게 정의해야 합니다.

게이트웨이 설치 관리자

관리 오버헤드를 줄이고 거버넌스 위험을 완화하려면 조직의 활성 게이트웨이 수를 제한하는 것이 중요합니다. 이를 위해 게이트웨이를 설치할 수 있는 사용자 수를 제한하는 것이 좋습니다.

Warning

게이트웨이 소유자는 관리하는 게이트웨이를 완전히 제어할 수 있습니다. 이는 악의적인 게이트웨이 소유자가 온-프레미스 데이터 게이트웨이를 통해 정보를 전송할 때 잠재적으로 정보를 가로챌 수 있음을 의미합니다. 이러한 이유로 신뢰할 수 있는 사용자에게 게이트웨이를 설치하는 기능을 제한하는 것이 중요합니다.

표준 모드 게이트웨이의 경우 Fabric 포털 또는 Power Platform 관리 센터에서 게이트웨이 설치 관리자를 관리합니다. 또한 게이트웨이 설치 관리자 설정을 사용하여 VNet 데이터 게이트웨이를 만들 수 있는 사용자를 관리합니다.

• Fabric 연결 및 게이트웨이 페이지: Fabric 포털의 연결 및 게이트웨이 페이지 내에서 게이트웨이 설치 관리자를 관리할 수 있습니다.
• Power Platform 관리 센터: Power Platform 관리 센터에서 게이트웨이 설치 관리자를 관리할 수도 있습니다. 여기서 변경한 설정은 Fabric에서 사용하는 게이트웨이에 영향을 줍니다.

온-프레미스 게이트웨이 관리용 PowerShell cmdlet을 사용하여 프로그래밍 방식으로 게이트웨이 설치 관리자를 관리할 수도 있습니다. 개인 게이트웨이 및 표준 모드 게이트웨이의 경우 이러한 cmdlet을 사용하여 게이트웨이 테넌트 정책을 설정할 수 있습니다. PowerShell을 사용하여 게이트웨이 테넌트 정책을 설정하는 것은 테넌트에 개인 게이트웨이를 설치할 수 있는 사용자를 관리하는 유일한 방법입니다.

Important

개인 게이트웨이를 설치할 수 있는 사용자를 엄격하게 규제하여 유효하고 승인된 비즈니스 사례에 대한 설치 및 사용을 제한하는 것이 좋습니다.

게이트웨이 설치 준비

게이트웨이를 설치하고 소유할 사용자를 식별하면 게이트웨이 설치를 준비해야 합니다. 다음을 수행해야 합니다.

• 게이트웨이를 설치할 위치를 식별합니다.
• 게이트웨이 머신에 필요한 리소스를 결정합니다.
• 게이트웨이가 설치될 때 게이트웨이 이름을 지정하는 방법에 동의하세요.

다음 섹션에서는 게이트웨이 설치를 계획할 때 고려해야 할 주요 사항을 설명합니다.

게이트웨이를 설치할 위치 식별

일반적으로 Always-On VM(게이트웨이 머신이라고도 함)에 게이트웨이를 설치합니다. 머신에 각 유형(개인 모드 또는 표준 모드)의 게이트웨이를 하나만 설치할 수 있습니다.

게이트웨이를 설치할 위치를 결정하는 주요 요소는 다음과 같습니다.

• 위치: 일반적으로 대기 시간을 최소화하려면 게이트웨이 머신을 데이터 원본 가까이에 배치해야 합니다. 일반적으로 표준 게이트웨이는 기본 데이터 영역에 설치되어야 합니다. 그러나 Premium 용량 위치가 테넌트의 기본 데이터 영역과 다른 경우 데이터 보존 요구 사항을 충족하는 옵션으로 Azure Relay를 사용하는 방법을 조사합니다.
• 지원 항목: 게이트웨이 머신에 설치해야 하는 커넥터, 드라이버 또는 라이브러리를 결정합니다.
• 도메인: 게이트웨이 머신과 대상 도메인의 관계를 결정합니다. VM은 대상 도메인과 트러스트 관계가 있는 도메인에 가입된 머신이어야 합니다. 도메인 컨트롤러가 될 수 없습니다.

팁

리소스 경합을 방지하려면 게이트웨이 머신에 관련 없는 소프트웨어를 설치하면 안 됩니다. 게이트웨이 머신은 온-프레미스 데이터 게이트웨이 호스팅 전용이어야 합니다.

게이트웨이 머신 리소스 결정

게이트웨이 머신에는 예상된 쿼리 워크로드를 처리할 수 있는 충분한 리소스가 있어야 합니다.

게이트웨이 머신 리소스를 결정하는 주요 요소는 다음과 같습니다.

• 사용: 게이트웨이를 사용할 항목의 수와 유형 및 쿼리 동시성(많은 사용자)을 결정합니다. 사용량이 많을수록 더 많은 리소스를 갖춘 게이트웨이 머신이 필요합니다.
• 연결 유형: Power BI 의미 체계 모델이 데이터를 가져오는지, DirectQuery를 사용하는지 또는 라이브 연결을 사용하는지 여부를 결정합니다. 의미 체계 모델 가져오기의 경우 데이터 새로 고침 횟수를 확인하여 게이트웨이 리소스 요구 사항(예: RAM)을 예측하는 것이 중요합니다. DirectQuery 또는 라이브 연결의 경우 리소스 요구 사항(예: CPU)을 예측하는 보고서 소비자 수를 평가해야 합니다.

팁

부하 테스트를 수행하여 게이트웨이 머신 리소스의 유효성을 검사합니다. 데이터 세트 새로 고침을 수행할 때 게이트웨이 머신 상태를 모니터링하고 DirectQuery 또는 라이브 연결 보고서의 높은 동시 사용량을 시뮬레이션하여 이러한 유형의 테스트를 수행할 수 있습니다.

명명 규칙에 동의

게이트웨이 및 해당 데이터 원본 연결의 이름을 지정하는 방법이 중요합니다. 이 이름은 콘텐츠 작성자가 연결할 대상을 쉽게 알 수 있도록 해야 합니다. 게이트웨이 및 데이터 원본 연결에 명확한 이름이 있는지 확인하려면 논리적 명명 규칙을 사용해야 합니다.

명명 규칙을 정의할 때 다음 사항을 고려합니다.

• 감사, 로깅, 문제 해결을 목적으로 게이트웨이를 식별하려면 이름에 Gateway 또는 DataGW의 변형을 포함합니다.
• 특정 Fabric 항목, 작업, 지역 또는 비즈니스 영역을 지원하는 경우 게이트웨이의 특정 용도를 포함합니다.
• 게이트웨이가 특정 환경을 지원하는 경우 이름에 Dev, Test, Prod 변형을 사용하세요.
• 게이트웨이에 속한 클러스터의 이름과 일치하는 이름을 지정합니다. 예를 들어 클러스터 내의 게이트웨이 머신에Node1, Node2 등과 같은 고유한 이름을 지정합니다.

다음은 논리적 게이트웨이 이름의 몇 가지 예입니다.

• DataGW-Prod-Node1
• Gateway-DevTest-Node1
• Gateway-FinanceTeam-Prod-Node1

게이트웨이 설치 및 설정

주요 의사 결정 및 준비를 수행한 후 게이트웨이 소유자는 게이트웨이를 설치하고 최초 설정을 수행합니다.

참고 항목

게이트웨이를 다운로드하고 설치하는 방법에 대한 자세한 내용은 다음을 참조하세요.

• 표준 모드 게이트웨이 다운로드 및 설치
• 개인 모드 게이트웨이 다운로드 및 설치

게이트웨이를 설치하고 설정할 때 다음 요소를 고려합니다.

• 설치 위치: 기본 설치 경로 이외의 위치에 게이트웨이를 설치하려는 경우 설치 위치를 변경할 수 있습니다.
• 복구 키: 기존 게이트웨이를 마이그레이션, 복원 또는 인수하려는 경우 게이트웨이의 복구 키를 사용해야 합니다. 다른 게이트웨이 관리자가 액세스할 수 있는 안전한 보안 장소에 복구 키를 보관해야 합니다.
• 데이터 센터 지역: 등록된 서비스의 테넌트와 지역이 달라지도록 하려면 데이터 센터 지역을 변경할 수 있습니다.
• Azure Relay: 기본값 대신 고유한 릴레이를 사용하려는 경우 고유한 릴레이 세부 정보를 제공할 수 있습니다.
• 프록시 설정: 작업 환경에서 게이트웨이가 Fabric 포털에 연결하기 위해 프록시 서버를 통과해야 하는 경우 프록시 설정을 설정해야 합니다.
• 게이트웨이 서비스 계정: 명시적 도메인 계정을 사용하려는 경우 기본값인 PBIEgwService에서 게이트웨이 서비스 계정 변경을 수행할 수 있습니다.
• 통신 설정: 방화벽이 아웃바운드 연결을 차단하는 경우 보안 및 네트워킹 팀은 게이트웨이에서 연결된 Azure 지역으로의 아웃바운드 연결을 허용하도록 방화벽을 설정할 수 있습니다.
• 테넌트 등록: 데이터 반출을 방지하기 위해 온-프레미스 데이터 게이트웨이 애플리케이션을 등록할 수 있는 테넌트를 제한하려는 경우입니다.
• 통합 테넌트 설정: 게이트웨이가 의도한 대로 SSO(Single Sign-On)(예: Microsoft Entra ID 기반 인증)로 작동하는지 확인하려는 경우입니다.

Important

테넌트 등록을 조직 내의 테넌트로만 제한하는 것이 좋습니다. 기본 설정에는 테넌트 등록에 대한 제한이 없으므로 이 단계는 게이트웨이 보안을 개선하는 데 도움이 됩니다.

검사 목록 - 게이트웨이를 준비하고 설치할 때 주요 결정 및 작업에는 다음이 포함됩니다.

• 게이트웨이 소유자 및 설치 관리자 식별: 게이트웨이 소유자가 책임을 인지하고 있는지 확인합니다. 게이트웨이 설치를 적절한 사용자로 제한합니다.
• 교육 수행: 필요한 경우 게이트웨이 소유자 및 설치 관리자를 교육하여 게이트웨이를 효과적으로 설치, 관리, 지원할 수 있도록 합니다. 필요한 경우 백업을 위한 교차 학습을 수행합니다.
• 명명 규칙 만들기: 용도, 환경, 클러스터 노드, 지원하는 사용 사례 또는 수행하는 작업에 해당하는 게이트웨이 명명 규칙을 만듭니다.
• 리소스 요구 사항 고려: 초기 리소스(예: 메모리 및 CPU)를 결정하는 데 필요한 워크로드 및 사용을 결정합니다.
• 통합 테넌트 설정 지정: 통합 테넌트 설정을 검토하고 설정하여 게이트웨이가 의도한 대로 SSO(Single Sign-On)로 작동하는지 확인합니다.
• 게이트웨이 머신 프로비전: 게이트웨이 작업을 지원하기에 충분한 리소스를 사용하여 Always-On VM을 설정합니다.
• 게이트웨이 설치: 게이트웨이 머신에서 게이트웨이를 최초 설정을 수행합니다.
• 지원 항목 설치: 시나리오를 지원하기 위해 사용자 지정 데이터 커넥터 또는 종속 소프트웨어를 설치합니다.

게이트웨이 관리

게이트웨이를 설치한 후 데이터 원본 연결을 추가해야 합니다. 이러한 연결을 추가할 때 게이트웨이 및 해당 연결에 대한 액세스를 관리하는 방법도 계획해야 합니다.

데이터 원본 연결 추가

게이트웨이를 사용하려면 먼저 초기 데이터 원본 연결을 추가해야 합니다. Power BI 서비스 또는 Power Platform 관리 센터에서 수동으로 연결을 추가하거나 또는 Power BI REST API를 사용하여 프로그래밍 방식으로 연결을 추가할 수 있습니다.

연결을 추가할 때 다음 사항을 고려합니다.

• 저장된 자격 증명: 데이터 원본에 연결하는 데 사용할 자격 증명을 고려합니다. 연결을 추가할 때 익명 인증을 지원하지 않는 한 해당 데이터 원본에 대한 자격 증명을 제공해야 합니다. 데이터 게이트웨이에 Microsoft Entra SSO(Single Sign-On)를 사용하지 않는 한 데이터 원본에 대한 모든 쿼리는 이러한 자격 증명을 사용하여 실행되기 때문에 이는 중요한 결정입니다.
• 명명 규칙: 게이트웨이와 마찬가지로 연결에는 논리적이고 일관된 명명 규칙을 사용해야 합니다. 연결 이름이 데이터 원본 이름에 해당하는지 확인합니다. 예를 들어 FinanceDB-Prod는 데이터 원본을 나타내는 논리적 이름입니다.
• Single Sign-on: Fabric 관리자 설정에서 DirectQuery를 통해 SSO(Single Sign-On)를 사용하려는 경우 게이트웨이용 Microsoft Entra SSO(Single Sign-On) 옵션을 사용하도록 설정해야 합니다(Active Directory SSO 또는 Microsoft Entra SSO). 보고서 사용자 ID를 기반으로 데이터 원본 시스템에서 데이터 보안을 적용하려는 경우 SSO를 사용해야 합니다.
• 개인 정보 수준: 데이터 원본 연결 가져오기의 경우 개인 정보 수준을 설정해야 합니다. 필요한 경우 적절한 개인 정보 수준을 선택하여 데이터 원본을 적절하게 격리해야 합니다. Power BI Desktop에서 설정된 개인 정보 수준은 게이트웨이에서 적용되지 않는다는 것을 이해하는 것이 중요합니다.

참고 항목

데이터 원본 이름은 나중에 수정할 수 있지만 서버 및 데이터베이스 이름은 설정 후에는 변경할 수 없습니다. 오류를 방지하려면 데이터 원본 정보가 Power BI Desktop에서 사용되는 정보와 일치하는지 확인합니다.

팁

효율성과 정확도를 향상하려면 Power BI REST API를 사용하여 데이터 원본 연결 만들기를 자동화하는 것이 좋습니다. 이 경우 연결을 만들거나 업데이트하는 각 요청을 자동으로 처리하는 대신 검토 및 승인 프로세스를 포함하는 것이 좋습니다.

게이트웨이 액세스 프로비전

초기 데이터 원본 연결을 추가한 후 게이트웨이 및 해당 연결 모두에 대한 액세스를 관리하는 방법을 결정해야 합니다.

콘텐츠 작성자가 데이터 원본에 성공적으로 연결하려면 게이트웨이 연결에 액세스해야 합니다. 게이트웨이 연결에 대한 사용자 액세스는 각 연결에 대해 수행되므로 각 게이트웨이 연결에 액세스해야 하는 사용자와 해당 액세스를 관리하는 방법을 고려합니다. 게이트웨이 및 연결 모두에 보안 역할을 사용하여 액세스를 관리해야 합니다.

게이트웨이 역할

게이트웨이 역할을 사용하면 게이트웨이 및 해당 데이터 원본 연결을 관리할 수 있는 사용자를 제어할 수 있습니다. 이러한 역할은 작업 영역 역할과 유사하게 작동하므로 역할에 따라 다른 권한을 허용합니다. 역할을 사용하면 게이트웨이 액세스를 보다 효과적으로 관리할 수 있습니다.

팁

개별 계정 대신 역할 멤버십을 관리하려면 보안 그룹을 사용하는 것이 좋습니다. 이렇게 하면 특히 여러 게이트웨이에서 사용자를 더 쉽게 관리할 수 있습니다. 동일한 보안 그룹을 사용하여 행 수준 보안 역할 멤버십 및 앱 대상 그룹 멤버십과 같은 다른 액세스 제어를 관리할 수 있습니다.

Important

데이터 원본에 연결하기 위해 게이트웨이를 사용해야 하는 사용자는 게이트웨이 역할에 속할 필요가 없습니다. 이 경우 사용자 연결 역할만 갖게 됩니다.

온-프레미스 표준 게이트웨이를 관리하기 위한 세 가지 게이트웨이 역할이 있습니다.

• 관리자: 이 역할의 구성원은 게이트웨이를 관리하고 업데이트할 수 있습니다. 게이트웨이 관리자는 일반적으로 게이트웨이 소유자이지만 게이트웨이에 여러 관리자가 있을 수도 있습니다. 게이트웨이 관리자는 Fabric 관리자이거나 COE 또는 중앙 BI 팀의 구성원이어야 합니다. 관리자의 책임은 게이트웨이 소유자와 동일합니다.
• 공유를 통한 연결 작성자: 이 역할의 구성원은 게이트웨이 연결을 만들고, 게이트웨이 상태를 테스트하고, 게이트웨이를 다른 사용자와 공유할 수 있습니다. 이 역할은 게이트웨이에서 사용자를 제거할 수 없습니다. 사업부의 분산된 팀과 같은 분석 솔루션의 하위 집합을 담당하는 경우 이 역할에 다른 사용자를 추가하는 것이 좋습니다. 이 역할을 맡은 사람의 책임은 다음과 같습니다.
  • 새 연결을 설정하고 테스트합니다.
  • 자격 증명 설정과 같이 소유한 연결을 관리합니다.
  • 게이트웨이를 필요로 하는 다른 사용자와 공유합니다.
  • 게이트웨이에 액세스할 수 있는 사용자를 정기적으로 검토하고, 게이트웨이가 여전히 필요한지 여부를 확인하고, 필요하지 않으면 제거합니다.
• 연결 작성자: 이 역할의 구성원은 게이트웨이에서 연결을 만들고 해당 상태를 테스트할 수 있습니다. 연결 작성자는 게이트웨이를 사용하기 위해 올바른 연결을 적절하게 설정할 수 있는 콘텐츠 소유자여야 합니다. 연결 작성자 역할의 책임은 게이트웨이에 대한 액세스를 공유할 수 없다는 점을 제외하면 공유하는 역할 작성자 역할과 동일합니다.

참고 항목

VNet 게이트웨이는 관리자 게이트웨이 역할만 지원합니다.

데이터 원본 연결 역할

데이터 원본 연결 역할을 사용하면 연결을 사용, 관리, 공유할 수 있는 사용자를 제어할 수 있습니다. 연결 역할이 있는 사용자는 게이트웨이 역할에 속할 필요가 없습니다.

세 가지 데이터 원본 연결 역할이 있습니다.

• 소유자: 이 역할의 구성원은 연결을 관리하거나 더 이상 필요하지 않은 경우 연결을 삭제할 수 있습니다. 소유자는 다른 연결 소유자 추가를 포함하여 연결 역할을 관리할 수 있습니다. 소유자는 일반적으로 연결 작성자이기도 합니다. 해당 데이터 원본의 관리자(steward) 또는 관리자(administrator)이거나 데이터 원본 및 해당 콘텐츠에 대한 상당한 지식을 가진 사용자를 연결 소유자로 만드는 것이 좋습니다. 소유자의 책임은 다음과 같습니다.
  • 필요한 경우 자격 증명 업데이트 등의 연결을 관리합니다.
  • 더 이상 필요하지 않은 경우 연결을 삭제합니다.
  • Power Platform 관리 센터에서 연결 역할 관리를 수행합니다.
• 공유가 있는 사용자: 이 역할의 구성원은 다른 사용자를 추가하여 데이터 원본을 사용하고 공유할 수 있습니다. 사용자 커뮤니티에서 중요한 역할을 수행할 때 이 역할에 다른 사용자를 추가하는 것이 좋습니다. 챔피언은 이 역할에 적합한 후보가 될 수 있습니다. 이 역할을 맡은 사람의 책임은 다음과 같습니다.
  • 연결을 필요로 하는 다른 사용자와 공유합니다.
  • 연결에 액세스할 수 있는 사용자를 정기적으로 검토하고, 게이트웨이가 여전히 필요한지 여부를 확인하고, 필요하지 않으면 제거합니다.
• 사용자: 이 역할의 구성원은 Power BI 보고서 및 Power BI 데이터 흐름에서 데이터 원본을 사용할 수 있습니다. 사용자는 워크로드 및 클라이언트 도구에서 데이터를 쿼리할 일만 담당합니다.

팁

거버넌스 위험이 과도하게 공유되는 것을 방지하려면 게이트웨이와 연결을 공유할 수 있는 사용자를 이 작업을 효과적이고 책임감 있게 수행할 수 있는 특정 개인으로 제한해야 합니다.

게이트웨이 및 연결 문서화

게이트웨이 클러스터를 설정한 후에는 이를 문서화해야 합니다. 콘텐츠 작성자가 쉽게 찾을 수 있고 게이트웨이 관리자가 쉽게 유지 관리할 수 있도록 게이트웨이를 문서화해야 합니다. 관련 실무 커뮤니티의 중앙 집중식 포털과 같이 액세스 가능한 위치에 게이트웨이 문서를 저장하는 것이 좋습니다.

다음 정보를 문서화하는 것이 좋습니다.

• 게이트웨이 이름 및 GUID
• 게이트웨이 머신 이름(및 해당 식별자)
• 게이트웨이 소유자
• 마지막 소프트웨어 업데이트 날짜(게이트웨이 버전)
• 게이트웨이 클러스터의 용도(예: 환경, 지역, 비즈니스 영역)
• 이 게이트웨이에서 유지 관리해야 하는 데이터 원본 연결
• 게이트웨이에서 사용자 ID 또는 저장된 자격 증명을 사용하는지 여부
• 액세스 관리 정책(게이트웨이 역할 및 연결 역할을 사용하려는 방법)

Important

표준 모드 게이트웨이에 대한 게이트웨이 복구 키를 문서화해야 합니다. 게이트웨이를 복구하거나 재배치해야 하는 경우 이러한 복구 키가 필요합니다. 중앙 팀의 신뢰할 수 있는 여러 사용자가 액세스할 수 있는 안전한 장소에 이 정보를 보관합니다. 조직 암호 자격 증명 모음이 있는 경우 그곳이 이상적인 위치입니다.

게이트웨이 업데이트

게이트웨이가 계속 작동하고 제대로 수행되도록 하려면 몇 가지 작업을 수행해야 합니다.

• Windows 업데이트를 설치하고 다른 서버 유지 관리를 수행합니다.
• 게이트웨이 소프트웨어를 업데이트합니다. 게이트웨이 소프트웨어는 매월 업데이트되며 Microsoft는 온-프레미스 게이트웨이의 최신 6개 릴리스만 지원합니다.
• 필요한 경우 사용자 지정 데이터 커넥터, 드라이버, 라이브러리를 업데이트합니다.

참고 항목

게이트웨이 소유자는 각 게이트웨이에 게이트웨이 업데이트를 수동으로 적용해야 합니다. 이러한 이유로 게이트웨이를 주기적으로 업데이트하는 프로세스를 계획하는 것이 중요합니다.

팁

Power Query 온라인 환경으로 작업하는 경우 Power Query 엔진은 사용 가능한 최신 버전의 Power Query를 사용합니다. 그러나 게이트웨이를 사용하여 변환을 적용하는 경우 게이트웨이 머신에 설치된 버전을 사용합니다. 일관된 사용자 환경을 보장하려면 게이트웨이 머신을 최신 상태로 유지하는 것이 중요합니다.

이 섹션의 나머지 부분에서는 게이트웨이 소프트웨어를 업데이트하는 방법을 설명합니다.

개발 또는 테스트 게이트웨이에 업데이트 설치

예기치 않은 중단을 방지하고 최신 개선 사항을 활용하려면 게이트웨이를 최신 상태로 유지하는 것이 중요합니다. 그럼에도 불구하고 업데이트는 게이트웨이 성능 및 기능에 예기치 않은 결과를 초래할 수 있습니다. 업무상 중요한 솔루션에 영향을 주지 않으려면 먼저 개발 또는 테스트 게이트웨이에 게이트웨이 소프트웨어 업데이트를 설치해야 합니다(프로덕션 환경을 지원하는 게이트웨이에 적용되기 전에).

업데이트 유효성 검사

먼저 개발 및 테스트 환경을 지원하는 게이트웨이에 업데이트를 적용하여 게이트웨이를 테스트할 수 있습니다.

게이트웨이 업데이트의 유효성을 검사할 때 다음 사항을 고려합니다.

• 반복 가능한 테스트 조건 정의: 모든 관련 게이트웨이 작업 및 데이터 원본을 테스트할 수 있도록 반복 가능한 테스트 조건 목록을 정의해야 합니다. 예를 들어 어떤 보고서와 의미 체계 모델이 중요하다고 간주되고 유효성 검사가 필요한지 식별할 수 있습니다. 또한 반복 가능한 테스트 조건으로 인정되는 몇 가지 규정 준수 요구 사항이 있을 수도 있습니다.
• 테스트 보고서 집합 사용: 게이트웨이가 업데이트 될 때마다 기능 테스트에 사용할 보고서 집합을 유지합니다. 이러한 보고서는 반복 가능한 테스트 조건의 유효성을 신속하게 검사하는 데 도움이 됩니다. 이러한 테스트 보고서에는 합계와 개수만 표시되는 경우가 많습니다. 목표는 다음을 위해 액세스, 렌더링, 새로 고침을 테스트하도록 하는 것입니다.
  • 일반적으로 사용되는 각 데이터 원본입니다.
  • 가장 중요한 의미 체계 모델과 같은 데이터 항목의 각 주요 형식입니다.
  • 가져오기 및 DirectQuery와 같은 다양한 스토리지 모드입니다.
• 업무상 중요한 보고서 식별: 새 업데이트를 테스트할 수 있는 업무상 중요한 보고서에 대한 액세스(또는 복사본)입니다. 이러한 보고서는 데이터가 새로 고쳐지고 DirectQuery 보고서가 예상대로 작동하는지 확인하는 데 도움이 될 수 있습니다.
• 프로세스 테스트 자동화: Power BI REST API를 사용하여 데이터 항복 가져오기의 데이터 새로 고침을 테스트하고 DAX 쿼리 평가를 수행합니다. 새로 고침 실패 또는 쿼리 오류를 포착하고 기록할 수 있는지 확인합니다.

Important

프로덕션 환경에 적용하기 전에 개발 및 테스트 클러스터에서 게이트웨이 업데이트를 테스트하는 것이 좋습니다. 롤백 프로세스가 없으므로 업데이트 테스트가 중요합니다. 대안으로 업데이트를 시작하기 전에 파일 시스템 구조 및 머신에 있는 데이터의 전체 복사본인 VM 이미지를 만들 수 있습니다.

프로덕션에 업데이트 설치

게이트웨이 업데이트의 유효성을 검사한 후 프로덕션 환경을 지원하는 모든 게이트웨이에 업데이트를 적용해야 합니다. 업데이트하는 동안에는 게이트웨이를 사용할 수 없으므로 게이트웨이를 업데이트하는 시기와 방법을 일관되게 유지해야 합니다.

게이트웨이 업데이트에 대해 다음 사항을 고려합니다.

• 중앙 집중식 포털에서 게이트웨이의 현재 버전을 문서화합니다.
• 지금까지 게이트웨이 사용량이 적은 기간 동안 업데이트를 적용합니다.
• 업데이트를 테스트하고 적용할 때 일관된 일정을 사용합니다. 월별 업데이트가 너무 자주 발생하는 경우 게이트웨이가 적어도 분기별로 업데이트되는지 확인합니다.
• 한 번에 하나의 게이트웨이 클러스터 머신을 업데이트합니다. 각 머신을 순환하면서 가동 중지 시간을 방지할 수 있습니다.

자격 증명 업데이트

저장된 자격 증명이 필요한 데이터 원본 연결의 경우 자격 증명을 정기적으로 순환해야 할 수 있습니다. 예를 들어 조직에는 암호를 자주 재설정해야 하는 정책이 있을 수 있습니다. 이 방법은 주요 팀 구성원이 조직을 떠날 때에도 유용합니다. 효율성을 높이기 위해 Power BI REST API를 사용하여 자격 증명을 업데이트할 수 있습니다.

검사 목록 - 데이터 게이트웨이 관리 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

• 데이터 원본 연결 만들기: 일반적인 조직 데이터 원본에 대한 데이터 원본 연결을 설정합니다. 연결이 명확하고 일관된 명명 규칙을 따르는지 확인합니다.
• 게이트웨이 및 데이터 원본 문서화: 게이트웨이 및 연결에 대한 간결한 문서를 만듭니다. 게이트웨이 소유자 및 관리자가 중앙 집중식 포털에서 이 문서에 쉽게 액세스할 수 있는지 확인합니다.
• 연결 요청 처리: 연결 요청을 수집하고 관리하는 프로세스를 만듭니다. 연결 요청에 승인 프로세스가 필요한지 여부를 결정합니다. Power BI REST API를 사용하여 프로세스를 자동화하는 것이 좋습니다.
• 게이트웨이 역할 프로비전: 최소 권한 원칙을 사용하여 게이트웨이 역할에 개인을 할당합니다. 연결 관리에 기여할 수 있도록 연결 작성자 또는 공유하는 연결 작성자 역할에 데이터 원본 관리자를 추가하는 것이 좋습니다.
• 연결 역할 프로비전: 게이트웨이를 사용할 수 있도록 콘텐츠 작성자(및 해당하는 경우 소비자)를 연결 역할에 할당합니다. 공유할 수 있는 사용자를 책임감 있게 연결을 공유하고 정기적으로 액세스를 검토하고 관리하는 데 도움이 되는 사용자로 제한합니다.
• 간결한 사용자 문서 만들기: 콘텐츠 작성자가 게이트웨이 및 해당 연결을 찾고 사용하는 데 중요한 주요 항목을 문서화합니다. 중앙 집중식 포털 또는 SharePoint 지원 사이트 등 사용자 커뮤니티에서 쉽게 액세스할 수 있는 중앙 위치에 문서를 배치합니다.
• 복구 키를 주의 깊게 문서화 및 저장: 복구 키를 둘 이상의 팀 구성원이 액세스할 수 있는 안전하고 안전한 위치에 저장합니다. 게이트웨이를 복구해야 하는 경우 쉽게 찾을 수 있는지 확인합니다.
• 업데이트 설치 프로세스 만들기: 게이트웨이 소프트웨어 업데이트를 설치하는 빈도와 따라야 할 프로세스를 결정합니다. 업데이트 릴리스 후 1~3개월 이내에 게이트웨이를 업데이트하는 것을 목표로 합니다.
• 개발 및 테스트에 먼저 게이트웨이 업데이트 설치: 개발 및 테스트 게이트웨이가 프로덕션 전에 업데이트되고 초기 테스트에 사용되는지 확인합니다.
• 프로덕션 게이트웨이에 적용되기 전에 게이트웨이 업데이트 테스트: 반복 가능한 테스트 조건 및 항목을 사용하여 월별 게이트웨이 업데이트를 테스트하는 프로세스를 설정합니다.
• 프로덕션에 게이트웨이 업데이트를 신속하고 정기적으로 설치: 프로덕션 게이트웨이가 최신 상태로 유지되는지 확인합니다.
• 연결 자격 증명 업데이트: 필요에 따라 연결에서 저장된 자격 증명 사용을 업데이트합니다.

게이트웨이 모니터링, 감사, 최적화

게이트웨이는 Fabric 데이터 통합의 중요한 부분입니다. 중단을 방지하고 위험을 완화하려면 테넌트의 게이트웨이를 모니터링하고 정기적으로 감사해야 합니다.

게이트웨이를 모니터링하면 다음을 수행할 수 있습니다.

• 거버넌스 위험을 완화합니다.
• 문제를 방지합니다.
• 성능 문제 또는 데이터 새로 고침 실패와 같은 인시던트를 조사합니다.

다음 표에서는 데이터 게이트웨이 클러스터를 관리할 때 발생할 수 있는 일반적인 문제와 문제를 모니터링하거나 조사하는 방법에 대한 개요를 제공합니다.

잠재적인 문제	문제 유형	문제를 모니터링하거나 조사하는 방법
너무 많은 게이트웨이	거버넌스	• Power Platform 관리 센터 • 게이트웨이 PowerShell cmdlet • Power BI REST API
게이트웨이 오버쉐어링	거버넌스	• Power Platform 관리 센터 • 게이트웨이 PowerShell cmdlet • Power BI REST API • Power BI 활동 로그
게이트웨이 오프라인	성능 및 가용성	• Power Platform 관리 센터 • 게이트웨이 머신 모니터링 • 게이트웨이 로그
게이트웨이 오류	성능 및 가용성	• 게이트웨이 로그
쿼리 실패	성능 및 가용성	• 게이트웨이 로그 • 게이트웨이 로그(추가 로깅)
느린 새로 고침 또는 쿼리	성능 및 가용성	• 게이트웨이 머신 모니터링 • Windows 이벤트 로그 • Windows 성능 카운터 • 게이트웨이 로그 • 게이트웨이 로그(추가 로깅) • 서버 모니터링 도구

참고 항목

게이트웨이 감사 및 모니터링에 대한 자세한 내용은 다음을 참조하세요.

• 온-프레미스 데이터 게이트웨이 성능 모니터링 및 최적화
• Power BI 구현 계획: 데이터 수준 감사
• Power BI 구현 계획: 테넌트 수준 감사

팁

Fabric 용량을 사용하는 경우 Fabric의 도구는 조직 게이트웨이 모니터링 솔루션을 구축하고 오케스트레이션하는 데 이상적인 구성 요소를 제공할 수 있습니다. 예를 들어 다음을 수행할 수 있습니다.

• Data Factory를 사용하여 게이트웨이 로그를 복사하고 OneLake에 배치합니다.
• Notebook을 사용하여 Power BI REST API를 사용하여 프로그래밍 방식으로 게이트웨이 정보를 수집하고 게이트웨이 로그 파일을 테이블로 변환합니다.
• Power BI를 사용하여 의미 체계 모델을 만들고 게이트웨이 상태에 대해 보고합니다.
• 패브릭 활성화기를 사용하여 변칙 또는 중단이 있을 때 게이트웨이 소유자 및 관리자에게 경고를 보냅니다.

게이트웨이 모니터링

테넌트에 설치된 게이트웨이 수와 이를 설치한 사용자를 정기적으로 검토해야 합니다. Fabric 포털의 연결 및 게이트웨이 페이지와 Power Platform 관리 센터에서 보급률을 모니터링할 수 있습니다. 두 보기 모두 액세스 권한이 있는 모든 게이트웨이에 대한 간결하고 기능적인 개요를 제공합니다. 관리자는 이 정보를 정기적으로 검토해야 합니다.

참고 항목

PowerShell cmdlet 또는 Power BI REST API를 사용하여 게이트웨이 목록을 프로그래밍 방식으로 검색할 수도 있습니다. 활동 로그를 사용하여 게이트웨이 설치 이벤트를 식별할 수도 있습니다.

이 정보를 게이트웨이 데이터 원본의 수 및 유형에 대한 집계 분석과 결합하는 것이 좋습니다. 통합된 테넌트 차원의 거버넌스 또는 감사 및 모니터링 보고에서 이 정보를 표시할 수 있습니다.

게이트웨이 보급을 모니터링할 때는 다음 메트릭에 주의를 기울이세요.

• 게이트웨이 또는 설치 관리자 수 증가: 예기치 않은 새 게이트웨이 또는 설치 관리자를 조사해야 합니다.
• 게이트웨이 간 연결 중복도: 게이트웨이의 추가 유지 관리 노력을 피하기 위해 연결을 통합하려고 합니다.
• 예기치 않은 설치 관리자 또는 게이트웨이: 새 설치 관리자 또는 게이트웨이가 설치되기 전에 승인 프로세스를 거쳤는지 확인합니다.
• 예기치 않은 게이트웨이 머신, 연결 또는 구성: 사용자 머신에 설치된 게이트웨이 또는 로컬 파일에 대한 연결과 같은 비정상적인 게이트웨이 속성을 식별해야 합니다. 또한 개인 정보 수준을 무시하는 것과 같이 위험을 초래하는 설정을 식별합니다.

게이트웨이 로그 수집 및 분석

각 게이트웨이 머신은 문제를 식별하고 해결하는 데 사용할 수 있는 자세한 로그를 생성합니다. 이러한 로그는 게이트웨이 머신에 저장된 자세한 기술 파일의 컬렉션입니다. 또한 온-프레미스 게이트웨이 앱에서 추가 로그를 일시적으로 사용하도록 설정하여 쿼리 및 해당 타이밍에 대한 자세한 정보를 수집할 수도 있습니다.

네트워킹 지연이 발생하지 않도록 하려면 게이트웨이 로그를 로컬 게이트웨이 머신에 쓸 수 있도록 하는 것이 좋습니다. 그러나 게이트웨이 구성 파일을 사용하여 로그가 기록되는 경로를 변경하도록 선택할 수 있습니다. 로그가 보존되는 기간을 업데이트할 수도 있습니다. 편집하기 전에 항상 구성 파일의 복사본을 만듭니다.

데이터를 분석할 수 있도록 각 게이트웨이 머신에서 로그 파일을 수집하고 통합하는 데이터 통합 솔루션을 만듭니다. 모든 게이트웨이를 쉽게 보고 변칙을 식별할 수 있도록 이 프로세스를 자동화하고 분석 보고서로 출력하는 것이 가장 좋습니다.

팁

데이터 경고를 사용하여 게이트웨이 관리자와 데이터 원본 연결 작성자에게 게이트웨이 및 연결의 비정상적인 활동에 대해 각각 알리는 것이 좋습니다. 이렇게 하면 즉각적인 시정 조치를 취할 수 있습니다.

게이트웨이 머신 상태 모니터링

게이트웨이의 상태는 서버의 상태에 따라 달라집니다. 중단을 방지하려면 머신이 제대로 작동하지 않거나 오프라인 상태일 경우 게이트웨이 머신을 모니터링해야 합니다.

팁

게이트웨이 머신이 조직에서 서버를 모니터링하는 데 사용하는 엔터프라이즈 모니터링 도구에 추가되었는지 확인합니다.

게이트웨이 최적화 및 문제 해결

게이트웨이에 문제가 발생하면 문제를 조사하고 식별해야 합니다. 일반적으로 문제 해결에는 이전 섹션에서 설명한 게이트웨이 로그를 조사하고 다양한 최적화를 테스트하여 문제를 해결하는지 여부를 확인하는 작업이 포함됩니다.

다음은 몇 가지 일반적인 게이트웨이 최적화입니다.

• 스풀링에서 스트리밍으로 변경: 기본적으로 게이트웨이는 쿼리를 평가할 때 데이터를 게이트웨이 머신으로 스풀링합니다. 데이터가 클라우드로 전송되기 전에 데이터가 임시 스토리지에 저장됩니다. 스풀링은 데이터가 직접 전송되는 스트리밍 보다 느려질 수 있습니다. 게이트웨이 구성 파일에서 이 설정을 변경할 수 있습니다.
• 바이러스 백신 검사: 게이트웨이 머신의 바이러스 백신 검사에서 특정 폴더를 제외하면 파일 수준 바이러스 백신 소프트웨어를 사용할 때 성능이 향상될 수 있습니다.
• 스케일 업 또는 스케일 아웃 계획: 게이트웨이 머신에 리소스를 더 추가하여 게이트웨이 클러스터를 스케일 업하거나 다른 머신에 다른 게이트웨이를 추가하여 클러스터 스케일 아웃할 시기를 고려합니다.

Important

VNet 게이트웨이에는 스케일링할 수 없거나 변경할 수 없는 단일 하드웨어 구성이 있습니다.

참고 항목

게이트웨이 최적화 및 문제 해결에 대한 자세한 내용은 다음을 참조하세요.

• 온-프레미스 데이터 게이트웨이 문제 해결
• VNet 네트워크 게이트웨이 문제 해결
• 중요 비즈니스용 게이트웨이 솔루션 계획, 스케일링, 유지 관리

검사 목록 - 게이트웨이 모니터링 시 주요 결정 사항 및 작업에는 다음이 포함됩니다.

• 게이트웨이 머신 모니터링: 엔터프라이즈 모니터링 솔루션에서 모니터링하는 머신에 게이트웨이가 설치되어 있는지 확인합니다. 그렇지 않으면 이러한 머신이 제대로 수행되지 않는 시기를 감지할 수 있는지 확인합니다.
• 게이트웨이 보급률 측정: 시간이 지남에 따라 테넌트에 설치된 게이트웨이 수의 변화를 모니터링합니다.
• 게이트웨이 로그 수집 및 분석: 다양한 게이트웨이 머신에서 로그 파일을 자동으로 수집하고 결합하는 솔루션을 만듭니다. 이러한 파일을 분석하여 의미 있는 정보를 추출합니다. 두 가지 유형의 분석 모니터링 솔루션을 설정하는 것이 좋습니다. 하나는 경고 및 작업용이고 다른 하나는 문제 발생 시 예비 근본 원인 분석용입니다.
• 역할 및 책임 확인: 모니터링, 최적화, 문제 해결을 위해 역할 및 책임이 정의되어 있는지 확인합니다.

관련 콘텐츠

Power BI 구현 결정에 도움이 되는 더 많은 고려 사항, 작업, 의사 결정 기준 및 권장 사항은 Power BI 구현 계획을 참조하세요.