SQL Server Analysis Services 데이터 원본 관리

온-프레미스 데이터 게이트웨이를 설치한 후 게이트웨이와 함께 사용할 데이터 원본을 추가할 수 있습니다. 이 문서에서는 예약된 새로 고침 또는 라이브 연결에 사용할 온-프레미스 게이트웨이에 SSAS(SQL Server Analysis Services) 데이터 원본을 추가하는 방법을 설명합니다.

SSAS에 대한 라이브 연결을 설정하는 방법에 대해 자세히 알아보려면 이 Power BI 연습: Analysis Services Live Connect 비디오를 시청하세요.

데이터 소스 추가

다차원 또는 테이블 형식 Analysis Services 데이터 원본에 연결하려면 다음을 수행합니다.

1. 온-프레미스 데이터 게이트웨이에 대한 새 연결 화면에서 연결 형식으로 Analysis Services를 선택합니다. 데이터 원본을 추가하는 방법에 대한 자세한 내용은 데이터 원본 추가를 참조하세요.

   

2. 서버 및 데이터베이스를 포함하는 데이터 원본에 대한 정보를 입력합니다. 게이트웨이는 사용자 이름 및 암호에 대해 입력한 정보를 사용하여 Analysis Services 인스턴스에 연결합니다.

   

   참고 항목

   입력하는 Windows 계정은 연결 중인 Analysis Services 인스턴스에서 서버 관리자 역할의 멤버여야 합니다. 이 계정의 암호가 만료되도록 설정되면 데이터 원본에 대한 암호를 업데이트하지 않으면 연결 오류가 발생합니다. 자격 증명을 저장하는 방법에 대한 자세한 내용은 클라우드에 암호화된 자격 증명 저장을 참조하세요.

3. 데이터 원본에 대한 개인 정보 수준을 구성합니다. 이 설정은 예약된 새로 고침에 대해 데이터를 결합할 수 있는 방법을 제어합니다. 개인 정보 수준 설정은 라이브 연결에 적용되지 않습니다. 데이터 원본의 프라이버시 수준에 대한 자세한 내용은 프라이버시 수준(Power Query) 설정을 참조하세요.

   

4. 필요에 따라 지금 사용자 이름 매핑을 구성할 수 있습니다. 자세한 내용은 수동 사용자 이름 다시 매핑을 참조하세요.

5. 모든 필드에 정보를 입력한 후 만들기를 선택합니다.

이제 온-프레미스 Analysis Services 인스턴스에 대한 예약된 새로 고침 또는 라이브 연결에 이 데이터 원본을 사용할 수 있습니다.

Analysis Services용 사용자 이름

사용자가 Analysis Services에 연결된 보고서를 조작할 때마다 유효한 사용자 이름은 게이트웨이에 전달된 다음 온-프레미스 Analysis Services 서버에 전달됩니다. Power BI 로그인하는 데 사용하는 전자 메일 주소는 EffectiveUserName 연결 속성의 유효 사용자로 Analysis Services에 전달합니다.

이메일 주소는 로컬 AD(Active Directory) 도메인 내에서 정의된 UPN(사용자 계정 이름)과 일치해야 합니다. UPN은 AD 계정의 속성입니다. 해당 Windows 계정은 Analysis Services 역할에 있어야 합니다. AD에서 일치 항목을 찾을 수 없는 경우 로그인이 실패합니다. AD 및 사용자 이름 지정에 대한 자세한 내용은 사용자 이름 지정 특성을 참조하세요.

Analysis Services 데이터 원본의 사용자 이름 매핑

Power BI에서는 Analysis Services 데이터 원본의 사용자 이름 매핑이 허용됩니다. Power BI 로그인 사용자 이름을 Analysis Services 연결에 전달하는 EffectiveUserName에 매핑하는 규칙을 구성할 수 있습니다. 이 기능은 Azure Microsoft Entra 사용자 이름이 로컬 Active Directory 인스턴스의 UPN과 일치하지 않는 경우 유용한 해결 방법입니다. 예를 들어 이메일 주소가 meganb@contoso.onmicrosoft.com인 경우 meganb@contoso.com에 매핑할 수 있으며 이 값을 게이트웨이에 전달합니다.

Analysis Services의 사용자 이름은 다음과 같은 별도의 두 가지 방법으로 매핑할 수 있습니다.

• Power BI에서 수동 사용자 다시 매핑
• 온-프레미스 AD 속성 조회를 사용하여 Microsoft Entra UPN을 온-프레미스 AD 사용자에게 다시 매핑하는 Active Directory 조회 매핑입니다.

온-프레미스 AD 속성 조회를 사용한 수동 매핑은 가능하지만, 특히 패턴 일치가 충분하지 않은 경우 시간이 오래 걸리고 유지 관리하기가 어렵습니다. 예를 들어 도메인 이름 또는 사용자 계정 이름은 Microsoft Entra ID와 온-프레미스 AD 간에 다를 수 있습니다. 따라서 두 번째 방법을 사용한 수동 매핑은 권장되지 않습니다.

다음 섹션에서는 두 가지 매핑 방법을 설명합니다.

Power BI에서 수동 사용자 다시 매핑

Power BI에서 Analysis Services 데이터 원본에 대한 사용자 지정 UPN 규칙을 구성할 수 있습니다. 사용자 지정 규칙은 Power BI 서비스 로그인 이름이 로컬 디렉터리 UPN과 일치하지 않는 경우 도움이 됩니다. 예를 들어 meganb@contoso.com으로 Power BI에 로그인하지만 로컬 디렉터리 UPN이 meganb@contoso.local이 아닌 경우 meganb@contoso.local을 Analysis Services에 전달하도록 매핑 규칙을 구성할 수 있습니다.

수동 UPN 매핑을 수행하려면 다음 단계를 수행합니다.

1. Power BI 기어 아이콘에서 게이트웨이 및 연결 관리를 선택합니다.

2. 데이터 원본을 선택한 다음, 위쪽 메뉴에서 설정을 선택합니다.

3. 설정 화면의 사용자 이름 매핑 상자에서 EffectiveUserName이 선택되어 있는지 확인한 다음 새 규칙 추가를 선택합니다.

   

4. 사용자 이름 매핑에서 매핑할 각 사용자 이름에 대해 원래 이름 및 새 이름 값을 입력하고 새 규칙 추가를 선택합니다. 대체 값은 Power BI에 대한 로그인 주소이고 와(과) 값은 바꿀 값입니다. 대체는 Analysis Services 연결에 대한 EffectiveUserName 속성으로 전달됩니다.

   

   참고 항목

   변경하지 않으려는 사용자를 변경하지 마세요. 예를 들어 의 contoso.com을 의 @contoso.local으로 바꾸면 @contoso.com을 포함하는 모든 사용자 로그인이 @contoso.local로 바뀝니다. 또한 의 meganb@contoso.com을 의 meganb@contoso.local으로 바꾸면 v-meganb@contoso.com의 로그인이 v-meganb@contoso.local로 전송됩니다.

   목록에서 항목을 선택하고 끌어서 놓아 다시 정렬하거나 쓰레기통 아이콘을 선택하여 항목을 삭제할 수 있습니다.

와일드카드 사용

대체(원래 이름) 문자열에서 와일드카드(*)를 사용할 수 있습니다. 와일드카드는 다른 문자열 부분과 함께 사용할 수 없으며 자체적으로만 사용할 수 있습니다. 모든 사용자를 데이터 원본에 전달할 단일 값으로 바꾸려면 와일드카드를 사용합니다. 이 접근 방식은 로컬 환경에서 동일한 사용자를 사용하는 조직에서 모든 사용자를 원하는 경우에 유용합니다.

매핑 규칙 테스트

이름 바꾸기의 유효성을 검사하려면 원래 이름값을 입력하고 테스트 규칙을 선택합니다.

Active Directory 조회 매핑

이 섹션에서는 온-프레미스 Active Directory 속성 조회를 수행하여 Microsoft Entra UPN을 AD 사용자에게 다시 매핑하는 방법을 설명합니다. 먼저 이 다시 매핑의 작동 방식을 검토합니다.

온-프레미스 SSAS 서버에 대한 Power BI Microsoft Entra 사용자의 각 쿼리는 UPN 문자열(예: firstName.lastName@contoso.com)을 전달합니다.

구성 가능한 사용자 지정 사용자 매핑을 사용하여 온-프레미스 데이터 게이트웨이의 조회 매핑은 다음 단계를 따릅니다.

1. 검색할 Active Directory를 찾습니다. 자동 또는 구성 가능을 사용할 수 있습니다.
2. Power BI 서비스에서 Active Directory 사용자의 특성(예: 이메일)을 조회합니다. 특성은 firstName.lastName@contoso.com과 같은 수신 UPN 문자열을 기반으로 합니다.
3. Active Directory 조회가 실패하면 UPN을 SSAS에 EffectiveUserName으로 전달하려고 시도합니다.
4. Active Directory 조회에 성공하면 해당 Active Directory 사용자의 UserPrincipalName을 검색합니다.
5. 매핑은 UserPrincipalName과 같은 Alias@corp.on-prem.contoso 이메일을 EffectiveUserName으로 SSAS에 전달합니다.

Active Directory 조회가 런타임에 제대로 작동하려면 로컬 서비스 계정 대신 도메인 계정으로 실행되도록 온-프레미스 데이터 게이트웨이 서비스를 변경해야 합니다.

1. 최신 게이트웨이를 다운로드하여 설치해야 합니다.

2. 컴퓨터의 온-프레미스 데이터 게이트웨이 앱에서 서비스 설정>서비스 계정 변경으로 이동합니다. 새 게이트웨이를 만들려는 경우가 아니라면 동일한 시스템에서 복구 키를 복원해야 하므로 게이트웨이에 대한 복구 키가 있는지 확인합니다. 변경 내용을 적용하려면 게이트웨이 서비스를 다시 시작해야 합니다.

3. 쓰기 권한이 있는지 확인하려면 관리자로서 게이트웨이의 설치 폴더인 C:\Program Files\On-premises data gateway로 이동합니다. Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config 파일을 엽니다.

4. AD 사용자에 대한 AD 특성 구성에 따라 ADUserNameLookupProperty 및 ADUserNameReplacementProperty 값을 편집합니다. 다음 이미지의 값은 예입니다. 이 구성은 대/소문자를 구분하므로 AD의 값과 일치하는지 확인합니다.

   

   파일이 ADServerPath 구성에 대한 값을 제공하지 않으면 게이트웨이는 기본 글로벌 카탈로그를 사용합니다. ADServerPath에 값을 여러 개 지정할 수 있습니다. 값은 다음 예제와 같이 세미콜론으로 구분해야 합니다.

   <setting name="ADServerPath" serializeAs="String">
       <value> GC://serverpath1; GC://serverpath2;GC://serverpath3</value>
   </setting>
   

   게이트웨이는 일치 항목을 찾을 때까지 ADServerPath의 값을 왼쪽에서 오른쪽으로 구문 분석합니다. 게이트웨이가 일치하는 항목을 찾지 못하면 원래 UPN을 사용합니다. 게이트웨이 서비스(PBIEgwService)를 실행하는 계정에 ADServerPath에 지정한 모든 AD 서버에 대한 쿼리 권한이 있는지 확인합니다.

   게이트웨이는 두 가지 유형의 ADServerPath를 지원합니다.

   • WinNT의 경우: <value="WinNT://usa.domain.corp.contoso.com,computer"/>
   • GC(글로벌 카탈로그)의 경우: <value> GC://USA.domain.com </value>

5. 온-프레미스 데이터 게이트웨이 서비스를 다시 시작하여 구성 변경 내용을 적용합니다.

라이브 Analysis Services 데이터 원본에 대한 인증

사용자가 Analysis Services와 상호 작용할 때마다 유효한 사용자 이름은 게이트웨이에 전달된 다음 온-프레미스 Analysis Services 서버에 전달됩니다. 일반적으로 클라우드에 로그인하는 데 사용하는 메일 주소인 UPN은 EffectiveUserName 연결 속성의 유효한 사용자로 Analysis Services에 전달됩니다.

데이터 세트가 가져오기 모드에 있으면 게이트웨이는 데이터 세트 소유자의 UPN의 EffectiveUserName을 보냅니다. 즉, 데이터 세트 소유자의 UPN이 EffectiveUserName 연결 속성의 유효 사용자로 Analysis Services에 전달됩니다.

이 전자 메일 주소는 로컬 Active Directory 도메인 내에서 정의된 UPN과 일치해야 합니다. UPN은 AD 계정의 속성입니다. 그런 다음 해당 Windows 계정은 서버에 액세스할 수 있도록 Analysis Services 역할에 있어야 합니다. Active Directory에 일치하는 항목이 없으면 로그인에 성공하지 않습니다.

역할 기반 및 행 수준 보안

Analysis Services Active Directory 계정을 기반으로 필터링을 제공할 수도 있습니다. 필터링은 역할 기반 보안 또는 행 수준 보안을 사용할 수 있습니다. 모델 데이터를 쿼리하고 보는 사용자의 기능은 Windows 사용자 계정이 속한 역할과 구성된 경우 동적 행 수준 보안에 따라 달라집니다.

• 역할 기반 보안. 모델은 사용자 역할 기반 보안을 제공합니다. SQL Server Data Tools 비즈니스 인텔리전스 도구에서 작성하는 동안 특정 모델 프로젝트에 대한 역할을 정의할 수 있습니다. 모델을 배포한 후 SQL Server Management Studio를 사용하여 역할을 정의할 수 있습니다. 역할에는 Windows 사용자 이름 또는 Windows 그룹별로 할당된 멤버가 포함됩니다.

  역할은 사용자가 모델에서 쿼리하거나 작업을 수행하는 데 필요한 권한을 정의합니다. 대부분의 사용자는 읽기 권한을 가진 역할에 속합니다. 다른 역할은 관리자에게 항목을 처리하고, 데이터베이스 함수를 관리하고, 다른 역할을 관리할 수 있는 권한을 부여합니다.

• 행 수준 보안. 모델은 동적 행 수준 보안을 제공할 수 있습니다. 정의된 모든 행 수준 보안은 Analysis Services와 관련됩니다. 역할 기반 보안의 경우 모든 사용자에게는 하나 이상의 역할이 있어야 하지만 테이블 형식 모델에는 동적 행 수준 보안이 필요하지 않습니다.

  높은 수준에서 동적 보안은 특정 테이블의 특정 행에 있는 데이터에 대한 사용자의 읽기 액세스를 정의합니다. 역할과 마찬가지로 동적 행 수준 보안에서는 사용자의 Windows 사용자 이름을 사용합니다.

모델에서 역할 및 동적 행 수준 보안을 구현하는 작업은 이 문서의 범위를 벗어납니다. 자세한 내용은 테이블 형식 모델의 역할 및 보안 역할(Analysis Services - 다차원 데이터)을 참조하세요. 테이블 형식 모델 보안을 가장 깊이 있게 이해하려면 Securing the Tabular BI Semantic Model(테이블 형식 BI 의미 체계 모델 보안 설정) 백서를 다운로드하세요.

Microsoft Entra 인증

Microsoft 클라우드 서비스는 Microsoft Entra ID를 사용하여 사용자를 인증합니다. Microsoft Entra ID는 사용자 이름 및 보안 그룹을 포함하는 테넌트입니다. 일반적으로 사용자가 로그인하는 전자 메일 주소는 계정의 UPN과 같습니다.

로컬 Active Directory 인스턴스의 역할

Analysis Services에서 연결되어 있는 사용자가 데이터 읽기 권한이 있는 역할에 속하는지 확인하려면 서버가 Microsoft Entra ID에서 전달된 유효한 사용자 이름을 게이트웨이로 변환한 다음 Analysis Services 서버로 변환해야 합니다. Analysis Services 서버는 유효한 사용자 이름을 Windows Active Directory 도메인 컨트롤러(DC)에 전달합니다. 그런 다음 Active Directory DC에서 유효한 사용자 이름이 로컬 계정에서 유효한 UPN 인지 확인합니다. DC는 사용자의 Windows 사용자 이름을 Analysis Services 서버에 다시 반환합니다.

도메인에 가입되지 않은 Analysis Services 서버에서는 EffectiveUserName을 사용할 수 없습니다. 로그인 오류를 방지하려면 Analysis Services 서버가 도메인에 가입해야 합니다.

UPN 식별

사용자 UPN이 무엇인지 알 수 없으며 도메인 관리자가 되지 못할 수도 있습니다. 워크스테이션에서 다음 명령을 사용하여 계정에 대한 UPN을 알아볼 수 있습니다.

whoami /upn

결과는 메일 주소와 유사하지만 도메인 계정에 있는 UPN입니다. 라이브 연결에 대해 Analysis Services 데이터 원본을 사용하고 이 UPN이 Power BI에 로그인하는 이메일 주소와 일치하지 않는 경우 사용자 이름을 매핑해야 할 수 있습니다.

Microsoft Entra ID와 온-프레미스 AD 동기화

Analysis Services 라이브 연결을 사용하려는 경우 로컬 AD 계정이 Microsoft Entra ID와 일치해야 합니다. UPN은 계정 간에 일치해야 합니다.

클라우드 서비스는 Microsoft Entra ID 내의 계정만 사용합니다. Microsoft Entra ID에 없는 로컬 AD 인스턴스에 계정을 추가하는 경우 계정을 사용할 수 없습니다. 로컬 AD 계정을 Microsoft Entra ID와 일치시킬 수 있는 여러 가지 방법이 있습니다.

• Microsoft Entra ID에 계정을 수동으로 추가합니다.

  Azure Portal 또는 Microsoft 365 관리 센터 내에서 로컬 AD 계정의 UPN과 일치하는 계정 이름을 사용하여 계정을 만듭니다.

• Microsoft Entra Connect 동기화를 사용하여 로컬 계정을 Microsoft Entra 테넌트에 동기화합니다.

  Microsoft Entra Connect를 사용하면 UPN이 Microsoft Entra ID와 로컬 AD 인스턴스 간에 일치하게 할 수 있습니다. Microsoft Entra Connect 도구는 디렉터리 동기화 및 인증 설정에 대한 옵션을 제공합니다. 옵션에는 암호 해시 동기화, 통과 인증 및 페더레이션이 포함됩니다. 관리자 또는 로컬 도메인 관리자가 아닌 경우 IT 관리자에게 이 구성에 관해 문의하세요.

  참고 항목

  계정을 Microsoft Entra Connect 동기화와 동기화하면 Microsoft Entra 테넌트 내에 새 계정이 만들어집니다.

데이터 원본 사용

SSAS 데이터 원본을 추가한 후에는 라이브 연결 또는 예약된 새로 고침을 통해 사용할 수 있습니다.

게이트웨이 내에서 데이터 세트 및 데이터 원본 간의 링크는 서버 이름 및 데이터베이스 이름을 기반으로 합니다. 해당 이름은 서로 일치해야 합니다. 예를 들어 Power BI Desktop 내에서 서버 이름에 대한 IP 주소를 제공하는 경우 게이트웨이 구성 내에서 데이터 원본에 대한 IP 주소를 사용해야 합니다. Power BI Desktop에서 SERVER\INSTANCE를 사용하는 경우 게이트웨이에 대해 구성된 데이터 원본에서 SERVER\INSTANCE를 사용해야 합니다. 이 요구 사항은 라이브 연결 및 예약된 새로 고침 모두에 적용됩니다.

라이브 연결로 데이터 원본 사용

테이블 형식 또는 다차원 인스턴스에 대해 라이브 연결을 사용할 수 있습니다. 데이터에 처음 연결할 때 Power BI Desktop에서 라이브 연결을 선택합니다. 서버 및 데이터베이스 이름이 Power BI Desktop 및 게이트웨이에 대해 구성된 데이터 원본 간과 일치하는지 확인합니다. 또한 라이브 연결 데이터 세트를 게시하려면 사용자가 데이터 원본 목록의 사용자 아래에 표시되어야 합니다.

Power BI Desktop에서 또는 Power BI 서비스에서 데이터를 가져와 보고서를 게시한 후에는 데이터 연결이 작동하기 시작해야 합니다. 연결을 사용하기 전에 게이트웨이에서 데이터 원본을 만든 후 몇 분 정도 걸릴 수 있습니다.

예약된 새로 고침으로 데이터 원본 사용

게이트웨이 내에서 구성된 데이터 원본의 사용자 탭에 나열되고 서버 및 데이터베이스 이름이 일치하는 경우 예약된 새로 고침으로 사용하기 위한 옵션으로 게이트웨이가 표시됩니다.

Analysis Services 라이브 연결의 제한 사항

• 셀 수준 형식 지정 및 변환 기능은 지원되지 않습니다.

• 작업 및 명명된 집합은 Power BI에 노출되지 않습니다. 작업 또는 명명된 집합을 포함하는 다차원 큐브에 연결하여 시각적 개체 및 보고서를 만들 수 있습니다.

SKU 요구 사항

관련 콘텐츠

• 온-프레미스 데이터 게이트웨이 문제 해결
• 게이트웨이 문제 해결 - Power BI

추가 질문이 있으신가요? Power BI 커뮤니티를 사용해 보세요.