Share via

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

  • 아티클

참고 항목

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

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

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

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

참고 항목

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

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

주요 의사 결정 계획

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

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

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

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

팁

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

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

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

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

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

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

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

온-프레미스 데이터 원본

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

이 시나리오는 연결할 때 관련이 있습니다.

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

프라이빗 네트워크 데이터 원본

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

이 시나리오는 데이터 원본과 관련이 있습니다.

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

참고 항목

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

호스트 커넥터 소프트웨어

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

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

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

Important

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

보안 격리

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

팁

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

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

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

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

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

  • 온-프레미스 데이터 게이트웨이(표준 모드)
  • 개인 게이트웨이라고 하는 온-프레미스 데이터 게이트웨이(개인 모드)
  • VNet(가상 네트워크) 게이트웨이 서비스

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

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

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

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

다이어그램은 온-프레미스 데이터 게이트웨이(표준 모드)를 보여 줍니다. 다이어그램의 항목은 다음 표에 설명되어 있습니다.

Important

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

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

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

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

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

개인 게이트웨이

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

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

팁

팀, 부서 또는 엔터프라이즈 BI 솔루션에서 개인 게이트웨이를 사용하지 마세요.

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

주의

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

다음 다이어그램은 개인 게이트웨이의 개략적인 개요를 보여 줍니다.

다이어그램은 개인 게이트웨이를 보여 줍니다. 다이어그램의 항목은 다음 표에 설명되어 있습니다.

Important

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

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

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

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

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

팁

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

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

VNet 게이트웨이

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

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

Important

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

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

Important

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

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

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

다이어그램은 VNet(가상 네트워크) 게이트웨이를 보여 줍니다. 다이어그램의 항목은 다음 표에 설명되어 있습니다.

Important

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

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

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

Warning

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

게이트웨이 수 확인

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

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

가용성 및 성능

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

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

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

Important

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

게이트웨이 클러스터 설정에 대한 자세한 내용 및 지침은 비즈니스에 중요한 게이트웨이 솔루션 계획, 크기 조정 및 기본을 참조하세요.

환경

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

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

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

Important

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

지역

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

주의

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

Important

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

검사 목록 - 게이트웨이 구현을 계획할 때 주요 의사 결정 및 작업에는 다음이 포함됩니다.

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

게이트웨이 설치

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

참고 항목

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

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

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

게이트웨이 소유자

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

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

Important

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

팁

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

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

게이트웨이 설치 관리자

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

Warning

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

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

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

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

Important

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

게이트웨이 설치 준비

게이트웨이를 설치하고 소유할 사용자를 확인한 경우 게이트웨이 설치를 준비해야 합니다. 다음을 수행해야 합니다.

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

다음 섹션에서는 게이트웨이 설치를 계획하기 위한 이러한 주요 고려 사항에 대해 설명합니다.

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

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

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

  • 위치: 일반적으로 대기 시간을 최소화하려면 게이트웨이 머신을 데이터 원본 가까이에 배치해야 합니다. 일반적으로 표준 게이트웨이는 기본 데이터 영역에 설치해야 합니다. 그러나 프리미엄 용량 위치가 테넌트에 대한 기본 데이터 지역과 다른 경우 데이터 상주 요구 사항을 충족하는 옵션으로 Azure Relay를 사용하여 조사합니다.
  • 지원 항목: 게이트웨이 컴퓨터에 설치해야 하는 커넥터, 드라이버 또는 라이브러리를 결정합니다.
  • do기본: 대상과 게이트웨이 머신의 관계가 무엇인지 확인합니다기본. VM은 대상 do기본 트러스트 관계가 있는 do기본 조인된 컴퓨터여야 합니다. 그것은 할 수 없습니다기본 컨트롤러.

팁

리소스 경합을 방지하려면 게이트웨이 컴퓨터에 관련 없는 소프트웨어를 설치하지 마세요. 게이트웨이 컴퓨터는 온-프레미스 데이터 게이트웨이를 호스트하는 데 전적으로 전용이어야 합니다.

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

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

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

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

팁

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

명명 규칙에 동의

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

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

  • 감사, 로깅 및 문제 해결을 위해 게이트웨이를 식별하기 위해 이름에 게이트웨이 또는 DataGW의 변형을 포함합니다.
  • 특정 패브릭 항목, 작업, 지역 또는 비즈니스 영역을 지원하는 경우 게이트웨이의 특정 용도를 포함합니다.
  • 게이트웨이가 특정 환경을 지원할 때 이름에 개발, 테스트 또는 Prod 변형을 사용합니다.
  • 게이트웨이에 속한 클러스터의 이름과 일치하는 이름을 지정합니다. 예를 들어 클러스터 내의 각 게이트웨이 컴퓨터에 Node1, Node2 등과 같은 고유한 이름을 지정합니다.

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

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

게이트웨이 설치 및 설정

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

참고 항목

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

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

  • 설치 위치: 기본 설치 경로 이외의 위치에 게이트웨이를 설치하려는 경우 설치 위치를 변경할 수 있습니다.
  • 복구 키: 기존 게이트웨이를 마이그레이션, 복원 또는 인수하려는 경우 게이트웨이의 복구 키를 사용해야 합니다. 복구 키를 다른 게이트웨이 관리자가 액세스할 수 있는 안전하고 안전한 장소에 보관해야 합니다.
  • 데이터 센터 지역: 지역이 등록된 서비스의 테넌트와 달라지도록 하려면 데이터 센터 지역을 변경할 수 있습니다.
  • Azure Relay: 기본값 대신 고유한 릴레이를 사용하려는 경우 고유한 릴레이 세부 정보를 제공할 수 있습니다.
  • 프록시 설정: 작업 환경에서 게이트웨이가 패브릭 포털에 연결하기 위해 프록시 서버를 통과해야 하는 경우 프록시 설정을 설정해야 합니다.
  • 게이트웨이 서비스 계정: 명시적 do기본 계정을 사용하려는 경우 게이트웨이 서비스 계정을 기본값인 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를 사용하여 프로그래밍 방식으로 연결을 추가할 수 있습니다.

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

참고 항목

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

팁

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

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

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

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

게이트웨이 역할

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

팁

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

Important

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

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

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

참고 항목

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

데이터 원본 연결 역할

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

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

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

팁

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

게이트웨이 및 연결 문서화

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

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

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

Important

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

게이트웨이 업데이트

게이트웨이가 다시 작동하고 기본 잘 수행되도록 하려면 여러 작업을 수행해야 합니다.

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

참고 항목

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

팁

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

이 섹션의 re기본der는 게이트웨이 소프트웨어를 업데이트하는 방법을 설명합니다.

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

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

업데이트 유효성 검사

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

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

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

Important

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

프로덕션에 업데이트 설치

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

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

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

자격 증명 업데이트

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

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

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

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

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

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

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

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

잠재적인 문제 문제 유형 문제를 모니터링하거나 조사하는 방법
게이트웨이가 너무 많습니다. 거버넌스 • Power Platform 관리 센터

• 게이트웨이 PowerShell cmdlet

• Power BI REST API
게이트웨이 오버쉐어링 거버넌스 • Power Platform 관리 센터

• 게이트웨이 PowerShell cmdlet

• Power BI REST API

• Power BI 활동 로그
게이트웨이가 오프라인 상태입니다. 성능 및 가용성 • Power Platform 관리 센터

• 게이트웨이 컴퓨터 모니터링

• 게이트웨이 로그
게이트웨이 오류 성능 및 가용성 • 게이트웨이 로그
쿼리 실패 성능 및 가용성 • 게이트웨이 로그

• 게이트웨이 로그(추가 로깅)
느린 새로 고침 또는 쿼리 성능 및 가용성 • 게이트웨이 컴퓨터 모니터링

• Windows 이벤트 로그

• Windows 성능 카운터

• 게이트웨이 로그

• 게이트웨이 로그(추가 로깅)

• 서버 모니터링 도구

참고 항목

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

팁

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

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

게이트웨이 모니터링

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

참고 항목

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

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

게이트웨이 보급을 모니터링할 때는 다음 메트릭에 집중합니다.

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

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

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

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

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

팁

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

게이트웨이 컴퓨터 상태 모니터링

게이트웨이의 상태는 서버의 상태에 따라 달라집니다. 중단을 방지하려면 게이트웨이 머신을 모니터링하여 컴퓨터가 성능이 좋지 않거나 오프라인 상태일 때를 감지해야 합니다.

팁

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

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

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

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

Important

VNet 게이트웨이에는 크기를 조정하거나 변경할 수 없는 단일 하드웨어 구성이 있습니다.

참고 항목

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

검사 목록 – 게이트웨이를 모니터링할 때 주요 의사 결정 및 작업에는 다음이 포함됩니다.

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

관련 콘텐츠

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