조직은 인수 합병, 회사 매각, 데이터 보존 요구 사항 또는 지역 규정 준수 요구 사항에 따라 Power BI 다양한 테넌트 마이그레이션 시나리오에 직면합니다. 테넌트 마이그레이션은 신중한 계획, 포괄적인 백업 전략 및 체계적인 실행이 필요한 복잡한 작업입니다. 이 문서에서는 마이그레이션이 필요한지 여부를 결정하는 데 도움이 되는 의사 결정 프레임워크와 다양한 마이그레이션 패턴에 대한 자세한 구현 방법론을 포함하여 엔터프라이즈 규모 Power BI 테넌트 마이그레이션에 대한 지침을 제공합니다.
Important
테넌트 마이그레이션은 상당한 위험을 수반하며 광범위한 수동 작업이 필요합니다. Microsoft 지역 재배치 중에 테넌트 간 또는 동일한 테넌트 내에서 콘텐츠를 마이그레이션하는 데 직접적인 지원을 제공하지 않습니다. 마이그레이션을 진행하기 전에 전체 테넌트 마이그레이션의 복잡성과 위험 없이 많은 시나리오를 해결할 수 있는 다중 지리적 용량과 같은 대안을 신중하게 평가합니다.
테넌트 마이그레이션 시나리오
Power BI 테넌트 마이그레이션은 세 가지 시나리오를 다룹니다. 마이그레이션을 계획하기 전에 상황에 적용되는 항목을 식별합니다.
| 시나리오 | Description | 일반적인 트리거 |
|---|---|---|
| 병렬(테넌트 간) 마이그레이션 | 두 개의 개별 Microsoft 365 테넌트가 병렬로 작동합니다. 아티팩트는 원본 테넌트에서 대상 테넌트로 개별적으로 이동됩니다. | 두 조직을 단일 테넌트에 통합하는 인수 합병. |
| 테넌트 분할 | 단일 Power BI 테넌트는 두 개의 독립 테넌트로 구분됩니다. 분리되는 사업체에 속한 아티팩트, 작업 영역 및 사용자는 선택적으로 분리됩니다. | 매각 및 스핀오프. |
| 테넌트 다시 매핑(테넌트 재배치) | Power BI 테넌트는 삭제되고 동일한 Microsoft 365 테넌트 내의 새 홈 지역에서 다시 만들어집니다. Microsoft 365 테넌트 ID, 도메인 및 사용자 ID가 유지됩니다. 자세한 내용은 지리 지역 간 Power BI 제거 참조하세요. | 테넌트 홈 지역을 특정 국가/지역으로 강제 적용하는 데이터 상주 요구 사항입니다. |
병렬 마이그레이션 및 테넌트 분할은 테넌트 간 작업입니다. 테넌트 재매핑은 동일한 Microsoft 365 테넌트 내에서 지역 이전입니다.
메모
Microsoft 지원을 통한 테넌트 재매핑(지역 재배치)에 대한 고려 사항 및 제한 사항은 Power BI 테넌트를 다른 지역으로 이동을 참조하세요. Microsoft 지원 지원은 이전 테넌트를 삭제하고 새 테넌트를 지정된 지역에 다시 매핑하는 것으로 제한됩니다. 마이그레이션 지원이 제공되지 않습니다. 스크립팅된 백업 및 복원, 수동 작업 또는 레크리에이션 및 다시 로드 프로세스를 통해 데이터와 메타데이터 모두에 대한 리하일레이션 계획이 있어야 합니다. 이 절차는 백업이 불완전하거나 아티팩트가 생략된 경우 잠재적인 데이터 또는 아티팩트 손실을 포함하여 상당한 위험을 수반합니다. 테넌트 다시 매핑 중 가동 중지 시간은 3~24시간이 될 수 있으며 아티팩트 복원에 더 많은 가동 중지 시간이 필요합니다.
마이그레이션하기 전에 대안 평가
테넌트 마이그레이션에는 상당한 위험과 노력이 수반됩니다. 계속하기 전에 대체 옵션을 탐색합니다. 다음 전략은 테넌트 마이그레이션 또는 재배치를 방지하는 데 도움이 될 수 있습니다.
다중 지역 배포
multi-geo 배포를 사용하면 테넌트 홈 지역을 변경하지 않고도 선택한 지역에 Power BI 및 Fabric 용량을 배포할 수 있습니다. 이러한 용량 내의 데이터는 최종 사용자와 가깝게 유지되며 동일한 테넌트 아래에 있는 여러 지역에 여러 용량을 가질 수 있습니다.
아티팩트를 다른 지역의 용량으로 마이그레이션하는 것은 테넌트 자체를 마이그레이션하는 것보다 간단합니다. 작업 영역을 다른 지역으로 이동하려면 작업 영역을 한 용량에서 다른 용량으로 다시 할당합니다. 재할당은 Power BI 항목에 대해 원활하게 진행됩니다.
Important
Fabric 항목은 서로 다른 지역에 있는 용량 간에 작업 영역을 재할당할 때 유지되지 않습니다. 작업 영역을 다시 할당하기 전에 Fabric 항목을 삭제하고 나중에 다시 만들거나 Git 통합을 사용하여 Fabric 항목을 백업 및 복원합니다.
다음 요구 사항에 대해 다중 지역 배포를 고려합니다.
- 데이터 대기 시간. 해당 지역에 용량을 배포하여 데이터를 배치하고 최종 사용자에게 더 가깝게 컴퓨팅합니다.
- 데이터 거주지. 데이터와 컴퓨팅 리소스는 테넌트 지역이 아니라 용량 지역에 종속됩니다. 다중 지역 배포는 대부분의 워크로드에 대한 데이터 상주 경계 내에 데이터를 유지합니다.
테넌트 메타데이터(작업 영역 정의, 의미 체계 모델 메타데이터, 시각적 메타데이터, 설정, 정책) 및 Microsoft 365 사용자 정보가 데이터 상주 경계 내에 남아 있어야 할 정도로 데이터 상주 요구 사항이 엄격한 경우에만 테넌트 다시 매핑을 고려합니다.
Dataflow Gen1에 대한 사용자 고유의 스토리지 계정 가져오기
Dataflow Gen1 기본적으로 Power BI 테넌트의 홈 지역에 있는 ADLS(Azure Data Lake Storage) Gen2 계정에 출력을 씁니다. Dataflow Gen1 스토리지 위치가 유일한 상주 문제인 경우 테넌트를 재배치하는 대신 원하는 지역에서 사용자 고유의 ADLS Gen2 계정을 구성합니다.
게이트웨이 지역 불일치에 대한 사용자 지정 Azure 릴레이
용량이 테넌트 홈 지역과 다른 지역에 배포된 경우 기본 온-프레미스 데이터 게이트웨이 엔드포인트는 트래픽을 홈 지역으로 다시 라우팅합니다. 게이트웨이 트래픽이 용량 지역 내에 유지되도록 하려면 사용자 지정 Azure 릴레이를 구성하세요. 게이트웨이 지역 불일치만으로는 테넌트 마이그레이션을 트리거하면 안 됩니다.
비즈니스 사례 검토
테넌트 마이그레이션이 비즈니스 요구(예: 청구 통합)에 의해 구동되는 경우 결과에 대한 노력과 위험을 가중합니다. 작은 테넌트는 마이그레이션이 간단할 수 있습니다. 상당한 Fabric 콘텐츠가 있는 대규모 테넌트는 계속하기 전에 비즈니스 필요성을 다시 확인해야 할 수 있습니다.
마이그레이션에 지원되는 기능
대부분의 Power BI 항목은 Power BI 관리 API 또는 Workspace Scanner API 통해 정의 내보내기를 지원하며 스크립쳐할 수 있습니다. 대부분의 Fabric 항목은 정의 내보내기가 지원되지 않으며 수동으로 다시 만들어야 합니다.
다음 표에서는 각 아티팩트 형식에 대한 마이그레이션 경로를 요약합니다.
| 순서 | 유물 | 마이그레이션 경로 |
|---|---|---|
| 1 | Gateways | 마이그레이션 경로가 없습니다. Power BI 관리자가 대상 테넌트에서 다시 구성해야 합니다. |
| 2 | 작업 영역 | 마이그레이션 경로가 없습니다. 대상 테넌트에서 다시 생성해야 합니다. Power BI Admin API를 사용하여 대량 생성이 가능합니다. |
| 3 | 패브릭 항목 | Git 통합을 지원하는 항목은 Git에 커밋하고, 원본 작업 영역에서 연결을 해제하고, 대상 테넌트의 새 작업 영역으로 다시 연결하여 백업할 수 있습니다. 정의만 백업됩니다. 데이터가 포함되지 않습니다. Git 통합을 지원하지 않는 항목은 수동으로 다시 만들어야 합니다. Lakehouse의 경우 메타데이터만 유지됩니다. 델타 테이블 및 스키마는 전송되지 않습니다. |
| 4 | Dataflows | 정의 JSON을 다운로드하고 대상 테넌트에 다시 가져옵니다. 관리자 API를 사용하여 스크립팅할 수 있습니다. |
| 5 | 의미 체계 모델/데이터 세트 | 백업을 사용하고 ADLS Gen2 스토리지 계정으로 복원하거나 정의를 다운로드하고 다시 가져옵니다. 관리자 API를 사용하여 스크립팅할 수 있습니다. |
| 6 | 보고서 | 소유자 또는 관리자는 .pbix를 다운로드 하고 대상 테넌트에 다시 게시합니다. 또는 JSON 정의를 내보냅니다. 관리자 API를 사용하여 스크립팅할 수 있습니다. |
| 7 | Dashboards | 마이그레이션 경로가 없습니다. 수동으로 다시 만들어야 합니다. |
| 8 | 앱 Power BI | 마이그레이션 경로가 없습니다. 수동으로 다시 만들어야 합니다. |
| 9 | 페이지별 보고서 | 소유자 또는 관리자는 RDL 파일을 다운로드하고 대상 테넌트에 게시 합니다. |
Important
항상 이 순서대로 아티팩트 다시 만듭니다. 다운스트림 아티팩트는 업스트림 아티팩트에 의존하며, 순서를 건너뛰면 실행 중에 참조가 끊어질 수 있습니다. Git 동기화를 수행하면 리포지토리에 없는 작업 영역의 모든 항목이 초기화됩니다.
마이그레이션 방법론
다음 참조 활동을 고려합니다. 대부분의 단계는 세 가지 시나리오 모두에 적용됩니다. 시나리오와 관련된 단계는 제목에서 호출됩니다.
1단계: 검색 및 인벤토리 평가
아티팩트 및 종속성의 전체 인벤토리를 빌드하고 마이그레이션할 수 있거나 마이그레이션할 수 없거나 마이그레이션할 수 없는 항목을 식별합니다.
활동
- 다음의 조합을 사용하여 테넌트 전체 검색을 실행합니다.
- Power BI 관리자 API
- Fabric 관리 API
- 활동 로그(작업 영역, 보고서, 데이터 세트, 새로 고침)
- API에서 노출되지 않는 항목에 대한 수동 설명서
- 캡처:
- 작업 영역(형식, 용량, 지역)
- 보고서, 의미 체계 모델(특히 큰 스토리지 형식), 데이터 흐름
- Fabric 항목(Lakehouse, Warehouse, Eventhouse, Notebooks)
- 게이트웨이, 데이터 원본, 자격 증명
- RLS(행 수준 보안) 역할, 작업 영역 권한, 링크 공유
- 포함된 아티팩트 및 종속성에 따라 마이그레이션 복잡성(낮음, 중간, 높음)을 기준으로 각 작업 영역을 분류합니다.
출력
- 기본 인벤토리 스프레드시트입니다.
- 모든 작업 영역에 대한 마이그레이션 복잡성 분류입니다.
2단계: 사용자 및 보안 검색
사용자 ID, 라이선스 및 권한을 캡처하고 필요한 경우 테넌트 간에 매핑합니다.
테넌트 다시 매핑에서 사용자 개체 ID는 유지됩니다. 병렬 마이그레이션 또는 테넌트 분할의 경우 대상 테넌트에 다른 개체 ID가 있습니다. 각 원본 테넌트 ID를 대상 테넌트 ID에 매핑합니다. Power BI 라이선스 할당(무료, Pro, PPU)을 다시 할당합니다. 새 Microsoft 365 테넌트에서 보안 그룹을 미러링합니다.
활동
식별 및 기록:
- Power BI 라이선스 할당(Microsoft Graph에서 공급)
- 원본 테넌트의 사용자 개체 ID
- 대상 테넌트의 사용자 개체 ID(나란히 또는 분할만 해당)
- 사용자 권한 및 작업 영역 액세스 수준
- 현재 테넌트 수준 설정(관리 포털을 통해 수동으로 캡처)
- 현재 거버넌스 구성(민감도 레이블, 보증 정책)
Power BI 관리 API 및 Workspace 스캐너 API 사용하여 작업 영역 및 아티팩트 권한을 추출할 수 있습니다.
3단계: 관련자 커뮤니케이션 및 변경 관리
마이그레이션 계획을 초기에 공유하여 반발과 지원 업무 부담을 줄이세요.
주요 관련자 그룹
- 임원 스폰서
- 작업 영역 소유자 및 보고서 작성자
- 최종 사용자
- IT, 보안 및 ID 팀
활동
- 다음을 다루는 통신 계획을 개발합니다.
- 마이그레이션 개요 및 근거.
- 마이그레이션 대상 및 마이그레이션되지 않음(예: 개인 작업 영역, 유휴 작업 영역).
- 변경 내용(URL, 액세스, 새로 고침 타이밍). Power BI URL을 참조하는 다운스트림 Power Apps 및 SharePoint 링크도 영향을 받습니다.
- 변경되지 않는 항목(데이터 의미 체계, 시각적 개체, 비즈니스 논리).
- 주요 날짜 전달:
- 창을 고정합니다(일반적으로 최종 백업 중에 원본 테넌트에 변경 내용이 없는 약 1주일).
- 예상 가동 중지 시간(테넌트 다시 매핑 시나리오의 경우).
- 관련자가 대상 테넌트에서 자신의 보고서를 확인하기 위한 유효성 검사 기간입니다.
- 소스 테넌트의 컷오버 이정표 및 서비스 중단 날짜(병행 시나리오).
출력
- 이해 관계자 브리핑 데크.
- 최종 사용자 FAQ입니다.
4단계: 테넌트 다시 매핑 요청 제출(테넌트 다시 매핑만 해당)
마이그레이션 날짜가 확정된 경우 지원 티켓을 제출한 후 테넌트 재매핑 옵션을 선택하세요. Microsoft 지원 엔지니어가 요청을 받습니다.
활동
- 지원 티켓을 제출합니다.
- Microsoft 제공하는 준비 검사 목록을 완료합니다.
- 예비 시간대도 포함하여 마이그레이션 날짜와 시간대에 합의하세요.
- 테넌트 다시 매핑이 발생하기 전에 기존 용량을 삭제합니다.
예상 결과
- 일반적인 다시 매핑에는 약 3시간이 걸리지만 합병증이 발생할 경우 최대 24시간의 지연이 가능합니다.
- 다시 매핑이 완료되면 새 테넌트는 동일한 테넌트 ID를 가지며 요청된 지역에 있습니다.
5단계: 대상 테넌트 준비
새로 만들거나 새로 매핑된 테넌트는 콘텐츠를 즉시 받을 준비가 되지 않았습니다. 먼저 구성합니다.
활동
- Power BI 테넌트 설정을 구성합니다.
- 작업 영역 만들기 컨트롤
- 공유 및 외부 액세스 정책
- 사용자 지정 시각화 거버넌스
- 민감도 레이블 및 정보 보호
- 감사 로그 및 모니터링 활성화
- 원본보다 같거나 높은 SKU의 Fabric 용량을 구매합니다.
- 게이트웨이, 게이트웨이 클러스터 및 데이터 연결을 구성하고 유효성을 검사합니다.
- 병렬 또는 테넌트 분할 시나리오의 경우:
- 원본 테넌트에 있는 모든 사용자에 대한 대상 테넌트에 사용자를 만들고 사용자 매핑을 기록합니다.
- 원본 테넌트에서 사용자 그룹을 다시 만듭니다.
- 대상 테넌트에 Power BI 라이선스를 할당합니다.
- 거버넌스 조정: 민감도 레이블, Microsoft Purview 통합 및 인증 정책
6단계: 마이그레이션 파일럿
프로덕션 마이그레이션 전에 대표적인 샘플 작업 영역에서 테스트 마이그레이션을 실행합니다.
병렬 마이그레이션의 경우 원본 테넌트는 다시 시도에 대한 대체로 사용할 수 있습니다. 테넌트 다시 매핑의 경우 다시 매핑하기 전에 올바르게 백업되지 않은 콘텐츠를 복구할 수 없습니다. 성공적인 파일럿은 리매핑 경로의 위험을 줄이는 가장 중요한 방법입니다.
파일럿 작업 영역 선택 조건
- 보고서, 의미 체계 모델, 데이터 흐름 및 Fabric 항목과 같은 아티팩트가 혼합되어 있습니다.
- 실제 데이터 원본 및 새로 고침 일정을 사용합니다.
- 작업 영역 수준 권한이 있고, 가능하면 RLS도 지원합니다.
- 적극적으로 사용되지만 중요 업무용은 아닙니다.
7단계: 마이그레이션 실행
마이그레이션을 실행합니다. 지원되는 항목이 먼저 스크립트됩니다. 지원되지 않는 항목은 수동으로 다시 만들어집니다.
대규모 테넌트에서는 Power BI Admin API를 래핑하여 아티팩트를 대량 내보내고 대량 다시 만드는 스크립트를 작성합니다.
마이그레이션에 지원되는 내용에 정의된 순서대로 아티팩트 다시 만듭니다. 순서를 건너뛰면 종속성이 중단됩니다.
8단계: 유효성 검사 및 테스트
콘텐츠가 성공적으로 마이그레이션되고 올바르게 작동하는지 확인합니다.
내보낸 의미 체계 모델 정의에는 기본 데이터가 포함되지 않습니다. 가져온 모든 의미 체계 모델은 대상 테넌트에서 하나 이상의 수동 새로 고침이 필요합니다.
Tip
유효성 검사 중에 일시적으로 더 높은 용량 SKU로 확장하는 것이 좋습니다. 많은 수의 동시 새로 고침이 그렇지 않으면 대상 용량을 포화시킬 수 있습니다.
활동
- 데이터 유효성 검사: 행 수, 키 집계, 새로 고침 성공.
- 보안 유효성 검사: RLS 규칙, 작업 영역 액세스, 공유 범위.
- 성능 유효성 검사: 보고서 로드 시간, 쿼리 응답성, 용량 헤드룸.
9단계: 사용자 전환 및 도입
사용자를 대상 테넌트로 이동하고 다운스트림 애플리케이션을 업데이트합니다.
활동
- 대상 테넌트에서 작업 영역 및 아티팩트에 대한 액세스 권한을 사용자에게 부여합니다.
- 포함된 보고서 URL, SharePoint 링크, Power Apps 연결 및 Power BI 콘텐츠를 참조하는 Power Automate 흐름을 업데이트합니다.
- 최종 서비스 해제 전에 원본 테넌트(읽기 전용 단계)에서 편집을 사용하지 않도록 설정합니다.
- 변경된 내용과 콘텐츠를 찾을 수 있는 위치를 다루는 짧은 사용 세션을 실행합니다.