Microsoft Fabric 배포 패턴 선택

Microsoft Fabric 배포하는 경우 조직 전체에서 용량, 작업 영역 및 항목을 구성하는 방법을 결정해야 합니다. 올바른 배포 패턴은 거버넌스, 보안, 성능 격리 및 비용 관리에 대한 요구 사항에 따라 달라집니다. 이 가이드는 설계자와 플랫폼 팀이 네 가지 배포 패턴을 평가하고 각 배포 패턴에 대한 고려 사항 및 장단점 이해에 도움이 됩니다.

4단계 계층 구조

다음 다이어그램에서는 모든 Fabric 배포를 정의하는 4단계 계층 구조를 보여 줍니다.

이 아키텍처의 Visio 파일을 다운로드하세요.

배포 계층 구조는 Microsoft 365 테넌트에서 개별 항목으로 이동합니다. 배포 패턴의 선택은 각 수준을 사용하는 방법을 결정합니다.

• 테넌트 레벨입니다. 맨 위에는 조직의 ID 및 관리 경계 역할을 하는 Microsoft 365 테넌트가 있습니다. Fabric 테넌트는 이 Microsoft 365 테넌트 내에 있으며 모든 Fabric 리소스는 이 단일 테넌트 경계 내에 있습니다. Microsoft Entra 조건부 액세스, 비공개 링크 및 민감도 레이블 등의 테넌트 수준 설정은 모든 작업 영역 및 수용력에 적용됩니다.

• 용량 수준 Microsoft 365 테넌트 내에서 하나 이상의 Fabric 용량을 설정합니다. 각 용량은 특정 Azure 지역에 바인딩되며 CPU(용량 단위)로 측정된 사용 가능한 컴퓨팅 리소스를 결정하는 특정 F SKU 있습니다. 용량들은 데이터 상주를 관리하고 청구 경계를 설정합니다. 단일 용량은 여러 작업 영역을 호스트할 수 있습니다.

• 작업 영역 수준입니다. 각 용량에는 하나 이상의 작업 영역이 포함됩니다. 작업 영역은 협업 및 거버넌스를 위한 기본 컨테이너입니다. 4개의 작업 영역 역할(관리자, 멤버, 참가자 및 뷰어)을 통해 액세스 제어를 정의하고, 버전 제어를 위한 Git 통합 을 지원하며, 배포 파이프라인의 범위 역할을 합니다. 작업 영역은 한 번에 하나의 용량 단위에 속합니다. 동일한 지역 용량 마이그레이션은 간단합니다. 지역 간 마이그레이션이 가능하지만 레이크하우스, 창고, Notebook 및 파이프라인을 비롯한 대부분의 Fabric 항목을 제거하고 다시 만들어야 합니다. 따라서 동일한 지역 마이그레이션을 선호합니다.

• 항목 수준 작업 영역에는 레이크하우스, 창고, 노트북, 파이프라인, 의미 모델, 보고서 및 대시보드와 같은 Fabric 항목이 포함됩니다. 항목은 기본적으로 작업 영역 권한을 상속합니다. Microsoft OneLake 보안 역할 테이블, 폴더, 열 및 행 수준에서 세분화된 액세스 제어를 제공하지만 뷰어 역할의 사용자에게만 적용됩니다. 작업 영역 관리자, 멤버 및 기여자는 OneLake 보안 역할을 무시합니다.

다음 라이선스 및 작업 영역 유형 제약 조건은 가장 실용적인 배포 패턴을 결정하는 경우가 많습니다.

• 새 작업 영역은 다시 할당하지 않는 한 공유 용량에서 시작됩니다. 모든 테넌트에는 내 작업 영역을 호스트하고 Power BI Pro 또는 PPU(사용자 단위 Premium) 작업 영역을 호스트할 수 있는 공유 용량이 있습니다. 프로덕션 워크로드에 대한 관리되는 Fabric 배포 패턴을 구현하려면 일반적으로 테넌트에서 전용 Fabric 용량에 작업 영역을 다시 할당해야 합니다.

• PPU는 Fabric 용량을 대체하는 것이 아닙니다. PPU는 사용자별로 Power BI 프리미엄 기능을 제공하지만 Fabric 용량은 포함하지 않습니다. 레이크하우스, 창고 및 노트북과 같은 Power BI Fabric 이외의 항목을 만들거나 실행하려면 F 용량이 필요합니다.

• 작업 영역 형식은 패턴이 호스트할 수 있는 내용에 영향을 줍니다. 이 문서의 Fabric 배포 패턴은 F SKU 지원 Fabric 작업 영역을 가정합니다. A 및 EM SKU는 Power BI 항목만 지원하므로 엔드 투 엔드 Fabric 배포 패턴을 지원할 수 없습니다.

• Power BI 뷰어 라이선스는 패턴의 비용을 변경할 수 있습니다. F64 및 더 큰 용량에서 뷰어 역할을 가진 사용자는 무료 라이선스를 사용하여 Power BI 콘텐츠에 액세스할 수 있습니다. 더 작은 용량에서 Power BI 소비자는 Pro, PPU 또는 평가판 라이선스가 필요합니다. 이 임계값은 대규모 판독기 모집단에 대한 중앙 집중식 패턴의 비용 효율성을 줄일 수 있습니다.

• Power BI 작성 및 공유에는 하나 이상의 Pro 또는 PPU 사용자가 필요합니다. 작업 영역에서 Fabric 용량을 사용하는 경우에도 조직에서는 Pro 또는 PPU 라이선스를 가진 사용자가 Power BI 항목을 만들고 공유해야 합니다.

구성 요소

• Microsoft 365 tenant: 조직의 ID 및 관리 경계입니다. 인증 및 권한 부여를 위해 Microsoft Entra ID(이전의 Azure Active Directory)을 호스트합니다.

• Fabric 용량: 이는 미국 동부 또는 서유럽과 같은 특정 Azure 지역에서 사용되는 컴퓨팅과 청구 리소스입니다. 비용을 줄이기 위해 사용하지 않을 때 용량을 일시 중지할 수 있습니다.

• Fabric 작업 영역: Fabric 항목에 대한 공동 작업 컨테이너입니다. RBAC(역할 기반 액세스 제어), Git 통합 및 배포 파이프라인을 지원합니다. 논리적 그룹화의 경우 Fabric 도메인에 작업 영역을 할당할 수 있습니다.

• Fabric 항목: 레이크하우스, 데이터 웨어하우스, 노트북, 파이프라인, 데이터플로우, 시맨틱 모델, 보고서 및 대시보드와 같은 데이터 및 분석 아티팩트입니다.

• Fabric 도메인: 사업부 또는 주체 영역별로 작업 영역을 구성하는 논리 그룹화입니다. 도메인은 위임된 거버넌스를 지원하며 검색 및 감독을 위해 OneLake 카탈로그에 표시됩니다.

• OneLake: 통합된 계층적 데이터 레이크로, 테넌트가 작업 영역을 포함하고, 작업 영역이 항목을 포함합니다. Fabric OneLake에 데이터를 저장합니다. OneLake는 Azure Data Lake Storage API, 외부 스토리지에 대한 바로 가기, Azure Storage Explorer 및 AzCopy 같은 Data Lake Storage 도구와의 통합을 지원합니다.

• OneLake 카탈로그: 테넌트 전체에서 Fabric 데이터를 찾고, 관리하고, 보호하는 중앙 집중식 인터페이스입니다. 사용자는 Microsoft Teams, Excel 및 Microsoft Copilot Studio 같은 도구를 사용하여 카탈로그에 액세스할 수 있습니다.

Fabric 배포 수준 이해

조직의 구조, 목표, 보안 요구 사항, 규모, 거버넌스 모델 및 애플리케이션 수명 주기는 각 배포 수준의 결정에 영향을 줍니다. 각 수준에 대한 자세한 내용은 4단계 계층 구조를 참조하세요.

• 용량은 데이터 상주 및 지리적 배포를 제어합니다. 여러 지리적 위치에서 작동하는 조직은 여러 Azure 지역의 용량을 사용하여 데이터가 저장되는 위치를 제어할 수 있습니다. 각 용량은 지역 간 다중 지리적 배포를 지원하는 특정 Azure 지역에 바인딩됩니다. 중앙 집중식 거버넌스를 지원하기 위해 Fabric 도메인은 지역 간에 작업 영역 및 관련 용량을 그룹화할 수 있습니다.

• 작업 영역은 기본 거버넌스 및 보안 경계 역할을 합니다. 각 작업 영역은 네 가지 역할을 통해 액세스 제어를 정의하고, Git 통합을 통한 버전 제어를 지원하며, 배포 파이프라인의 범위 역할을 합니다. 공동 작업 및 콘텐츠 검색을 중앙 집중화하려면 OneLake 카탈로그를 사용하여 테넌트의 OneLake 데이터에 대한 통합 검색 및 거버넌스 환경을 구현합니다. 사용자는 Teams 및 Excel과 같은 도구의 콘텐츠를 이 카탈로그를 통해 찾아서 상호 작용할 수 있습니다.

• 각 수준은 애플리케이션 수명 주기 선택에 영향을 줍니다. 배포 파이프라인 및 수명 주기 관리 와 같은 기능은 별도의 작업 영역이 필요하기 때문에 단일 작업 영역 패턴에서 사용할 수 없습니다. 도메인을 사용하여 작업 영역을 그룹화한 조직은 테넌트 관리자 권한 없이 도메인 수준 관리를 위임할 수 있으며, 이는 팀이 사업부 전체에서 릴리스 및 거버넌스를 관리하는 방법에 영향을 줍니다.

모든 배포의 일반적인 패턴

모든 Fabric 배포 패턴은 다음과 같은 기본 특성을 공유합니다.

• 규모, 거버넌스 및 보안을 위한 경계로서의 작업 영역. 배포 패턴은 Fabric 작업 영역을 항목 조직, 권한 및 DevOps 기능 범위의 기본 단위로 사용합니다. 선택한 패턴에 관계없이 작업 영역은 공동 작업 및 액세스 제어에 대한 경계를 정의합니다.

• 여러 작업 영역 및 사업부에서의 위임을 위한 패브릭 도메인. 위임에 Fabric 도메인을 사용합니다. 동일한 사업부에 속할 수 있는 여러 작업 영역을 관리하거나 비즈니스 도메인에 속하고 둘 이상의 작업 영역에 걸쳐 있는 데이터를 관리할 수 있습니다. 도메인 수준에서 데이터를 관리하고 관리하려면 테넌트 수준 설정을 조정하고 해당 설정에 대한 도메인별 구성을 사용할 수 있습니다.

• 성능 보장을 위해 작업 영역당 전용 용량을 사용하여 컴퓨팅 크기 조정을 위한 용량입니다. 특정 성능 수준을 충족해야 하는 경우 Fabric 용량을 사용하여 컴퓨팅 리소스를 확장하고 작업 영역당 전용 용량을 제공합니다. 성능에 민감한 작업에 워크로드 격리가 필요한 조직은 CU 할당이 보장된 별도의 용량에 해당 작업 영역을 할당할 수 있습니다.

• 자산 검색을 위한 OneLake 카탈로그 및 데이터 보안 정책의 보안 탭 테넌트 전체에서 검색 및 데이터 자산 사용을 촉진하려면 OneLake 카탈로그를 사용합니다. 작업 영역 및 항목에서 보안 역할을 보고, 모니터링하고, 구성하려면 OneLake 카탈로그의 보안 탭을 사용합니다.

• 네이티브 Fabric 기능을 사용할 수 없는 경우 Microsoft Cloud 기능 확장 네이티브 기능을 사용할 수 없는 경우 배포 패턴은 Azure 및 Microsoft 365 같은 Microsoft Cloud 동일한 기능을 사용하도록 확장할 수 있습니다. 예를 들어 조직에서는 Fabric 배포 파이프라인이 작업 영역 간 자동화 요구 사항을 충족하지 않는 경우 ci/CD(연속 통합 및 지속적인 업데이트) 오케스트레이션에 Azure Pipelines 또는 GitHub Actions을 사용할 수 있습니다. 조직은 Fabric 및 비 Fabric 데이터 원본에 걸쳐 있는 엔터프라이즈 차원의 데이터 거버넌스에 Microsoft Purview 사용할 수도 있습니다.

배포 패턴 선택

다음 시나리오에서는 일반적인 비즈니스 요구 사항 및 이를 해결하는 배포 패턴을 설명합니다. 이러한 시나리오를 사용하여 조직에 가장 적합한 패턴을 식별할 수 있습니다.

• 시나리오 1: 팀 간 협업을 통해 출시하는 더 빠른 시간입니다. 조직에서 더 빠른 시장 출시 시간, 팀 간 공동 작업 및 데이터 사용 제한 낮추기를 원하는 경우 모놀리식 배포 패턴을 구현할 수 있습니다. 이 시나리오에서 조직은 단일 작업 영역에서 작동하고 관리합니다.

  패턴 1 사용: 일체형 배포.

• 시나리오 2: 중앙 인프라 관리를 사용하는 격리된 팀 환경. 조직에서 격리된 팀 환경과 중앙 인프라 관리 팀을 제공하려는 경우 공유 용량 또는 별도의 용량을 사용하는 여러 작업 영역을 구현할 수 있습니다. 이 시나리오는 데이터 메시 아키텍처를 구현하려는 조직에도 적합합니다.

  패턴 2 사용: 여러 작업 영역, 단일 용량 또는 패턴 3: 여러 작업 영역, 별도의 용량.

• 시나리오 3: 데이터 플랫폼에 대한 전체 비즈니스 단위 자율성. 조직에서 사업부 또는 팀이 자체 데이터 플랫폼을 제어하고 관리할 수 있는 자유를 제공하는 완전히 분산된 모델을 원하는 경우 전용 용량 또는 여러 Fabric 테넌트에서 분할 작업 영역을 사용하는 배포 모델을 구현할 수 있습니다.

  패턴 3: 여러 작업 영역, 별도의 용량 사용 또는 패턴 4: 여러 Fabric 테넌트.

• 시나리오 4: 여러 패턴을 결합하는 하이브리드 접근 방식입니다. 조직에서 요구 사항을 충족하기 위해 여러 패턴을 사용하는 하이브리드 솔루션을 원하는 경우 하이브리드 접근 방식을 구현할 수 있습니다. 예를 들어 모놀리식 배포 패턴과 같이 특정 사업부에 대해 단일 작업 영역을 설정하고 다른 사업부에 대해 별도의 전용 작업 영역과 별도의 용량을 설정할 수 있습니다.

패턴 1: 모놀리식 배포

이 배포 패턴에서는 모든 사용 사례에 대해 하나의 작업 영역을 할당합니다. 모든 사업부는 동일한 작업 영역 내에서 작동합니다.

다음 특성이 이 패턴에 적용됩니다.

• 패브릭 항목은 동일한 용량을 공유합니다. 쿼리 또는 작업에 걸리는 시간은 동일한 용량을 사용하는 다른 워크로드에 따라 달라집니다.

• 작업 영역 최대 CPU는 가능한 가장 큰 F SKU로 제한됩니다. 데이터 엔지니어링 및 데이터 과학 환경의 경우 용량 관리자는 Apache Spark에 대한 자동 크기 조정 청구를 구성하여 Spark 엔진이 할당된 CPU 외부에서 사용하는 컴퓨팅 용량을 이동할 수 있습니다.

• 작업 영역으로 범위가 지정된 기능은 작업 영역을 공유하는 모든 사업부에 적용됩니다.

• 모든 작업 영역 항목 및 데이터는 한 지역에 있습니다. 다중 지리적 시나리오에는 이 패턴을 사용할 수 없습니다.

• 여러 작업 영역을 사용하는 기능은 사용할 수 없습니다(예: 배포 파이프라인 및 수명 주기 관리).

• 단일 작업 영역 제한 사항이 적용됩니다 .

• 특정 SKU 용량 제한이 적용됩니다.

이 패턴을 사용하는 경우

다음과 같은 경우 이 배포 패턴을 구현할 수 있습니다.

• 조직에는 복잡한 엔지니어링 요구 사항이 없거나, 사용자 기반이 작거나, 작은 의미 체계 모델이 있습니다.

• 조직은 단일 지역에서 작동합니다.

• 여러분은 주로 사업부 간의 조직 분리에 관심이 없습니다.

• 조직에는 Git과 코드 리포지토리 공유와 같은 작업 영역 범위 기능이 필요하지 않습니다.

• 레이크하우스 메달리온 아키텍처를 구현하려고 합니다. 조직에서 단일 작업 영역을 사용하는 경우 작업 영역 내에 별도의 레이크하우스를 만들어 브론즈, 실버 및 골드 레이어를 관리할 수 있습니다.

• 조직의 사업부는 역할을 공유하며 작업 영역의 사용자에 대해 동일한 작업 영역 수준 권한을 가질 수 있습니다. 예를 들어 여러 사업부의 여러 사용자가 단일 작업 영역의 관리자인 경우 작업 영역의 모든 항목에 대해 동일한 권한을 가집니다.

• 조직에서 가변 작업 완료 시간을 허용합니다. 용량이 공유되면 사용자는 언제든지 쿼리를 실행할 수 있습니다. 작업을 실행하는 데 사용할 수 있는 CPU 수는 용량에서 실행되는 다른 쿼리에 따라 달라지며, 이로 인해 작업 완료 시간이 달라질 수 있습니다.

• 조직은 하나의 패브릭 용량을 사용하여 CU 비즈니스 요건을 충족할 수 있습니다.

디자인 영역 고려 사항

다음 표에서는 이 배포 패턴을 사용하기로 결정하는 데 영향을 줄 수 있는 고려 사항을 제공합니다.

패턴 2: 여러 작업 영역, 단일 용량

이 배포 패턴에서는 단일 공유 용량에 여러 작업 영역을 할당합니다. 작업 영역은 해당 용량을 공유하므로 동시 워크로드는 작업 및 대화형 쿼리의 성능에 영향을 줄 수 있습니다.

다음 특성이 이 패턴에 적용됩니다.

• 패브릭 항목은 동일한 용량을 공유합니다. 쿼리 또는 작업에 걸리는 시간은 동일한 용량을 사용하는 다른 워크로드에 따라 달라집니다.

• 작업 영역 최대 CPU는 가능한 가장 큰 F SKU로 제한됩니다. 데이터 엔지니어링 및 데이터 과학 환경의 경우 용량 관리자는 Spark 엔진에서 사용하는 컴퓨팅 용량을 할당된 CPU 외부로 이동하도록 Spark에 대한 자동 크기 조정 청구를 구성할 수 있습니다.

• 작업 영역으로 범위가 지정된 기능은 해당 작업 영역을 공유하는 모든 사업부에 적용됩니다.

• 모든 작업 영역 항목 및 데이터는 한 지역에 있습니다. 다중 지리적 시나리오에는 이 패턴을 사용할 수 없습니다.

• 배포 파이프라인 및 라이프 사이클 관리와 같이 별도의 작업 영역이 필요한 DevOps 기능을 사용할 수 있습니다.

• 단일 작업 영역 제한 사항이 적용됩니다.

• 특정 SKU 용량 제한이 적용됩니다.

이 패턴을 사용하는 경우

다음과 같은 경우 이 배포 패턴을 구현할 수 있습니다.

• 분석 환경 작업의 일부 측면을 중앙 집중화하고 다른 측면을 분산하는 허브-스포크 아키텍처를 원합니다.

• 가변 운영 및 관리 분산을 원합니다. 예를 들어 조직은 한 작업 영역에서 medallion 아키텍처의 브론즈 및 실버 레이어를 호스트하고 별도의 작업 영역에서 골드 계층을 호스트할 수 있습니다. 이러한 분리는 한 팀이 브론즈와 실버 레이어를 관리하고 다른 팀이 골드 레이어를 관리하는 경우와 같은 고유한 운영 책임을 반영하는 경우가 많습니다.

• 성능 관리 및 워크로드 격리에 대해서는 크게 신경 쓰지 않습니다.

• 조직은 여러 지리적 지역에 워크로드를 배포할 필요가 없습니다. 모든 데이터는 한 지역에 있어야 합니다.

• 조직에는 다음과 같은 이유로 별도의 작업 영역이 필요할 수 있습니다.

  • 워크로드를 담당하는 팀의 구성원은 서로 다른 작업 영역에 있습니다.

  • 각 워크로드 유형에 대해 별도의 작업 영역을 만들려고 합니다. 예를 들어 데이터 파이프라인, 데이터 흐름 또는 데이터 엔지니어링과 같은 데이터 수집을 위한 작업 영역과 데이터 웨어하우스를 통해 사용할 별도의 작업 영역을 만들 수 있습니다. 이 디자인은 개별 팀이 각 워크로드를 담당하는 경우 잘 작동합니다.

  • 하나 이상의 작업 영역을 Fabric 도메인 그룹화하는 데이터 메시 아키텍처를 구현하려고 합니다.

• 조직에서 데이터 분류에 따라 별도의 작업 영역을 배포할 수 있습니다.

디자인 영역 고려 사항

다음 표에서는 이 배포 패턴을 사용하기로 결정하는 데 영향을 줄 수 있는 고려 사항을 제공합니다.

패턴 3: 여러 작업 영역, 별도의 용량

이 배포 패턴에서는 사업부 간에 거버넌스 및 성능 격리를 제공하는 별도의 Fabric 용량에 여러 작업 영역을 할당합니다.

첫 번째 용량에는 두 개의 작업 영역이 있고 두 번째 용량에는 하나의 작업 영역이 있는 두 개의 용량으로 구성된 단일 Fabric 테넌트를 보여 주는 다이어그램입니다.

다음 특성이 이 패턴에 적용됩니다.

• 작업 영역에 연결된 가능한 가장 큰 F SKU 또는 P SKU는 작업 영역에서 사용할 수 있는 최대 CPU 수를 결정합니다.

• 별도의 작업 영역은 조직 및 관리 분산을 만듭니다.

• 조직은 여러 지리적 지역의 용량 및 작업 영역을 사용하여 한 지역을 넘어 확장할 수 있습니다.

• 사업부에는 여러 작업 영역이 별도의 용량으로 있고 Fabric 도메인을 통해 그룹화될 수 있으므로 Fabric 전체 기능을 사용할 수 있습니다.

• 단일 작업 영역에 대한 작업 영역 제한 사항이 적용되지만 이러한 제한을 초과하여 확장할 새 작업 영역을 만들 수 있습니다.

• 특정 SKU 용량 제한이 적용되지만 별도의 용량을 사용하여 CPU 크기를 조정할 수 있습니다.

• OneLake 카탈로그를 사용하여 Fabric 항목 및 해당 인증 상태를 검색할 수 있습니다.

• 도메인은 단일 사업부가 여러 작업 영역을 작동하고 관리할 수 있도록 작업 영역을 함께 그룹화할 수 있습니다.

• OneLake 바로 가기는 데이터의 실제 복사본을 제거하여 데이터 이동을 줄입니다. 또한 OneLake 바로 가기는 OneLake를 통해 제어된 작업 영역 간 액세스를 제공하며 기본 데이터의 소유권을 이전하지 않습니다.

이 패턴을 사용하는 경우

다음과 같은 경우 이 배포 패턴을 구현할 수 있습니다.

• 조직에서 데이터 메시 또는 데이터 패브릭과 같은 아키텍처 프레임워크를 배포하려고 합니다.

• 용량 및 작업 영역을 구성하는 방법에 유연성의 우선 순위를 지정하려고 합니다.

• 다양한 지리적 지역에서 운영합니다. 이 경우 별도의 용량과 작업 영역을 만들어 다중 공간 및 다중 작업 영역 배포 패턴으로 이동합니다.

• 대규모로 운영하며 단일 용량 SKU 또는 단일 작업 영역의 제한을 초과하여 확장해야 하는 요구 사항이 있습니다.

• 특정 시간 내에 항상 완료해야 하거나 성능 기반 SLO를 충족해야 하는 워크로드가 있습니다. 이러한 워크로드에 대한 SLO를 충족하도록 Fabric 용량 지원 작업 영역을 별도로 설정할 수 있습니다.

디자인 영역 고려 사항

다음 표에서는 이 배포 패턴을 사용하기로 결정하는 데 영향을 줄 수 있는 고려 사항을 제공합니다.

패턴 4: 여러 Fabric 테넌트

이 배포 패턴에서 Fabric 모든 인스턴스는 거버넌스, 관리, 관리, 규모 및 스토리지와 관련하여 별도의 엔터티입니다.

다음 특성이 이 패턴에 적용됩니다.

• 테넌트 리소스는 엄격하게 분리됩니다.

• 테넌트 간의 관리 평면은 별개입니다.

• 테넌트는 각각 자체 거버넌스 및 관리 프로세스를 가지며 각각 독립적으로 관리되는 별도의 엔터티입니다.

• 데이터 파이프라인 또는 데이터 엔지니어링 기능을 사용하여 Fabric 테넌트 간에 데이터를 공유하거나 액세스할 수 있습니다.

이 패턴을 사용하는 경우

다음과 같은 경우 이 배포 패턴을 구현할 수 있습니다.

• 조직에는 사업 인수로 인해 여러 Fabric 테넌트가 있습니다.

• 조직에서 특히 사업부 또는 소규모 자회사에 대해 Fabric 테넌트를 설정하려고 합니다.

대체 플랫폼 평가

조직의 요구 사항이 Fabric 기반 배포 모델과 일치하지 않는 경우 다음과 같은 제한된 대안을 고려하세요.

• Azure Data Factory 하이브리드 Data Factory 및 Fabric 아키텍처를 포함하여 Data Lake Storage 또는 OneLake를 사용합니다

  명시적 오케스트레이션 제어 또는 단계적 현대화가 필요한 조직은 데이터 팩터리를 수집 및 파이프라인 오케스트레이션에 사용하고 Data Lake Storage 스토리지 기반으로 사용할 수 있습니다. 하이브리드 모델에서 Data Factory 관리형 데이터 파이프라인은 데이터를 OneLake에 로드할 수 있으며 Fabric 분석 데이터 자산 생성을 관리할 수 있습니다. 이 방법은 Fabric 증분 채택을 지원하고 설정된 통합 패턴을 유지합니다.

• Data Lake Storage, Azure Databricks 및 Power BI

  SaaS(통합 소프트웨어 서비스) 플랫폼 대신 PaaS(Platform as a Service) 기반 아키텍처를 선호하는 조직은 스토리지용 Data Lake Storage, 데이터 엔지니어링 및 분석용 Azure Databricks, 의미 체계 모델링 및 보고를 위해 Power BI 사용하여 데이터 자산을 빌드할 수 있습니다. 이 방법은 최대 제어 및 유연성을 제공하지만 통합 노력이 증가하고 운영 복잡성 및 거버넌스 오버헤드가 증가합니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 개선하는 데 사용할 수 있는 지침 원칙 집합인 Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Well-Architected Framework를 참조하세요.

이 문서의 앞부분에 있는 패턴별 테이블은 거버넌스, 보안, 관리, DevOps, 유용성, 성능 및 청구와 같은 Fabric 배포 결정과 관련된 디자인 영역을 사용합니다. 다음 하위 섹션에서는 Well-Architected Framework 핵심 요소로 구성된 보완 지침을 제공합니다. 패턴별 테이블을 사용하여 패턴을 비교합니다. 선택한 패턴에 관계없이 적용되는 교차 절단 아키텍처 지침에 이러한 하위 섹션을 사용합니다.

신뢰도

안정성은 애플리케이션이 고객에 대한 약정을 충족할 수 있도록 하는 데 도움이 됩니다. 자세한 내용은 안정성을 위한 디자인 리뷰 체크리스트를 확인하세요.

• 내장된 지역 복원력. Fabric는 지원되는 경우 가용성 영역을 통해 기본 제공 지역 복원력을 제공합니다. Fabric 고객 구성 없이 여러 영역에 리소스를 자동으로 배포합니다. 가용성 영역 지원은 Azure 지역에 따라 다릅니다. 대상 지역이 Fabric 가용성 영역을 지원하는지 확인하려면 Fabric 지역 가용성 참조하세요.

• DR(재해 복구)에는 옵트인(opt-in)이 필요하며 주의해야 합니다. 지역 간 복구는 용량 설정 페이지의 옵트인 DR 설정을 통해 사용할 수 있습니다. 비동기 복제를 사용하여 Azure 쌍을 이루는 지역에서 OneLake 데이터를 복제하도록 DR 용량 설정을 사용하도록 설정합니다.

  중요합니다

  일부 Azure 지역은 Fabric 지원하는 지역과 쌍을 이뤄지지 않으므로 데이터가 복제되더라도 DR 기능이 손상될 수 있습니다. 데이터 복제는 비동기이므로 지역 재해 직전에 작성된 데이터가 손실될 수 있습니다. 자세한 내용은 Fabric의 신뢰성을 확인하세요.

• 단일 용량 패턴은 한 지역에 위험을 집중합니다. 패턴 1과 2에서 워크로드는 한 Azure 지역에 있습니다. 지역에서 중단이 발생하면 모든 작업 영역이 동시에 영향을 받습니다. 지역 오류로부터 보호하려면 OneLake 데이터를 쌍을 이루는 지역에 복제하도록 용량 설정을 구성합니다. 페어링된 지역에서 서비스를 복원하는 데 필요한 복구 시간을 계획하십시오.

• 다중 용량 패턴은 자연스러운 지역적 격리를 구현합니다. 패턴 3 및 4에서, 다른 지역들의 용량은 지역별 중단이 해당 지역의 용량에만 영향을 미칩니다. 다른 지역의 워크로드는 계속 작동합니다. 이러한 패턴은 데이터 상주 요구 사항을 지원하고 활성-수동 또는 활성-활성 지역 전략의 토대를 제공합니다.

• 용량 일시 중지는 안정성에 영향을 줍니다. 비용을 줄이기 위해 Fabric 용량을 일시 중지하면 해당 용량의 모든 워크로드를 사용할 수 없게 됩니다. 프로덕션 워크로드를 지원하는 용량을 일시 중지하기 전에 안정성 효과를 고려합니다.

• OneLake 바로 가기는 외부 종속성을 도입합니다. 외부 데이터 원본에 대한 바로 가기는 원본 가용성에 종속됩니다. 외부 원본을 사용할 수 없는 경우 바로 가기를 사용하는 항목이 실패할 수 있습니다. 외부 데이터 소스의 상태를 모니터링하고 점진적 성능 저하를 계획합니다.

보안

보안은 의도적인 공격 및 중요한 데이터 및 시스템의 오용에 대한 보증을 제공합니다. 자세한 내용은 보안을 위한 디자인 검토 체크리스트를 참조하세요.

• 계층화된 보안 모델은 세 가지 수준에 걸쳐 있습니다. Fabric 테넌트, 작업 영역 및 항목 수준에 걸쳐 있는 계층화된 보안 모델을 구현합니다. 배포 패턴의 선택은 보안 경계를 분할하는 방법을 결정합니다. 패턴 1과 같은 단일 작업 영역 패턴은 균일한 액세스를 적용합니다. 패턴 2, 3 및 4와 같은 다중 작업 영역 패턴은 팀별 또는 사업부별 보안 경계를 지원합니다.

ID 및 액세스

• 조건부 액세스를 사용하여 테넌트 수준 인증 정책을 적용합니다. 조건부 액세스를 사용하여 다단계 인증, 디바이스 준수 및 위치 기반 제한과 같은 테넌트 수준 인증 정책을 적용합니다. 조건부 액세스에는 Microsoft Entra ID P1 라이선스 필요합니다.

• 작업 영역 역할을 사용하여 항목 액세스를 제어합니다. 작업 영역 역할을 할당하여 작업 영역 내에서 항목을 만들고 편집하고 사용할 수 있는 사용자를 제어합니다. 패턴 2, 3 및 4와 같은 다중 작업 영역 패턴에서는 별도의 작업 영역을 사용하여 사업부 간에 역할 경계를 적용합니다.

• OneLake 보안 역할을 사용하여 세분화된 데이터 수준 액세스를 적용합니다. OneLake 보안 역할을 사용하여 뷰어 역할의 사용자에 대해 테이블, 폴더, 열 및 행 수준에서 세분화된 액세스 제어를 적용합니다. 작업 영역 관리자, 멤버 및 기여자는 이러한 역할을 무시합니다.

네트워크 보안

• 인바운드 트래픽에 프라이빗 링크를 사용합니다. 프라이빗 링크를 사용하여 공용 인터넷 대신 Microsoft 백본 네트워크를 통해 인바운드 트래픽을 라우팅하십시오. 테넌트 수준 프라이빗 링크는 모든 작업 영역에 적용됩니다. 작업 영역 수준 프라이빗 링크는 작업 영역별 세분성을 제공합니다.

• 아웃바운드 Spark 연결에 관리되는 프라이빗 엔드포인트를 사용합니다. 관리형 프라이빗 엔드포인트를 사용하여 Spark 워크로드에서 방화벽으로 보호되는 데이터 원본(예: Data Lake Storage 및 Azure SQL Database으로 아웃바운드 연결을 보호합니다.

• 테넌트 수준 프라이빗 링크가 온-프레미스 게이트웨이를 차단하는 경우 가상 네트워크 데이터 게이트웨이를 사용합니다. 테넌트 수준 프라이빗 링크를 사용하도록 설정하면 온-프레미스 데이터 게이트웨이가 등록할 수 없습니다. 온-프레미스 또는 가상 네트워크 로 보호되는 데이터 원본을 연결하는 브리지 대신 가상 네트워크 데이터 게이트웨이를 사용합니다.

데이터 보호

• 엔드 투 엔드 데이터 분류에 민감도 레이블을 적용합니다. 데이터 분류 및 보호의 경우 Microsoft Purview Information Protection의 민감도 레이블>을 Fabric 통과하는 데이터에 적용합니다. 레이블은 데이터와 함께 원본에서 보고서까지 이동합니다.

• 정책 적용을 위해 감사 로그 및 규정 준수 도구를 사용합니다. 정책 위반을 감지하고 대응하려면 감사 로그를 검토하고 Microsoft Purview 준수 관리자 사용합니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 개선하는 방법에 중점을 둡니다. 자세한 내용은 비용 최적화를 위한 디자인 검토 목록을 참조하세요.

• 배포하기 전에 비용을 모델링합니다. 배포 패턴은 비용 구조에 영향을 줍니다. Fabric 가격 책정 및 Fabric 용량 추정기 사용하여 시나리오에 대한 비용을 모델링합니다.

• 용량 SKU를 적정 크기로 조정합니다. 워크로드 수요에 따라 F SKU 권한을 부여합니다. 더 작은 SKU로 시작하고 필요에 따라 강화합니다. Fabric 용량 메트릭 앱 사용하여 사용량을 모니터링하고 과도하게 프로비전되거나 프로비저닝되지 않은 용량을 식별합니다.

• 비프로덕션 환경에 대한 용량 일시 중지를 자동화합니다. 사용하지 않을 때 F SKU 용량을 일시 중지하여 비용을 절감합니다. 개발/테스트 환경에서는 작업 시간 외에 용량을 일시 중지합니다. 일시 중지하면 모든 워크로드를 사용할 수 없으므로 Azure Resource Manager Fabric API 또는 예약된 파이프라인을 통한 자동화를 고려합니다.

• 패턴 1 및 2와 같은 단일 용량 패턴은 청구를 중앙 집중화하지만 차지백을 제한합니다. 하나의 용량은 하나의 청구서를 의미합니다. 비용 관리는 중앙 집중식이지만 모든 워크로드가 동일한 용량을 공유하기 때문에 개별 사업부에 대한 차지백은 불가능합니다.

• 패턴 3 및 4와 같은 다중 용량 패턴은 팀별 차지백을 지원합니다. 각 용량은 자체 Azure 청구 측정기를 생성합니다. 각 용량을 담당하는 사업부에 비용을 청구할 수 있습니다. 대응하는 워크로드에 따라 각 용량을 독립적으로 조정하거나 일시 중지할 수 있습니다.

• OneLake 스토리지 비용을 독립적으로 관리합니다. OneLake 스토리지는 GB당 종량제 요금으로 청구되며 CPU를 사용하지 않습니다. 일시 삭제된 데이터를 포함하여 사용하지 않는 데이터를 정기적으로 삭제하고 Fabric 용량 메트릭 앱을 통해 스토리지를 모니터링합니다.

• Spark 컴퓨팅을 별도로 모니터링합니다. 데이터 엔지니어링 워크로드의 경우 별도의 Spark 풀을 사용하여 컴퓨팅을 CU 예산 외부로 이동할 수 있습니다. 예기치 않은 비용을 방지하려면 Spark CU 사용을 모니터링합니다.

운영 효율성

운영 우수성은 애플리케이션을 배포하고 프로덕션 환경에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 설계 검토 체크리스트를 참조하세요.

• 단계적 승격을 위해 배포 파이프라인을 사용합니다. Fabric 배포 파이프라인 사용하여 개발/테스트 및 프로덕션 단계를 통해 콘텐츠를 승격합니다. 배포 파이프라인에는 별도의 작업 영역이 필요하므로 패턴 1에서 사용할 수 없습니다. 패턴 2, 3 및 4에서 각 DTAP 단계에 대한 전용 작업 영역을 만듭니다. 용량 전략은 패턴에 따라 다릅니다.

  • 패턴 2에서 모든 DTAP 작업 영역은 동일한 용량을 공유하므로 비용 효율적이지만 환경 간에 성능 격리를 제공하지는 않습니다.

  • 패턴 3에서는 전체 격리를 위해 환경당 전용 용량을 사용하거나 별도의 프로덕션 용량으로 개발/테스트용 공유 용량을 사용하여 비용과 격리의 균형을 맞출 수 있습니다.

• 작업 영역 수준 디자인 결정으로 사전 프로덕션 환경을 계획합니다. 패턴 1은 프로덕션 작업 영역에서 개발/테스트가 발생하므로 사전 프로덕션 분리를 제공하지 않습니다. 패턴 2는 하나의 공유 용량에서 별도의 개발, 테스트 및 프로덕션 작업 영역을 지원하며, 이는 기능 유효성 검사에 적합하지만 프로덕션과 유사한 성능 또는 복원력 테스트에는 적합하지 않습니다. 패턴 3은 환경에 맞게 정렬된 작업 공간과 용량 수준의 격리를 통해 프로덕션과 유사한 사전 프로덕션 유효성 검사를 지원합니다. 패턴 4에는 작업 영역 수준 결정이 아닌 별도의 테넌트가 포함됩니다. 각 테넌트는 다른 테넌트와 일치할 필요 없이 자체 환경 토폴로지를 독립적으로 선택할 수 있습니다.

• 소스 제어를 위해 작업 영역을 Git 리포지토리 에 연결합니다. 패턴 2와 3에서는 팀 또는 워크로드별로 별도의 작업 영역이 표준 분기 전략에 부합합니다. 패턴 1에서 모든 팀은 병합 경합을 만들 수 있는 단일 리포지토리를 공유합니다.

• 용량 및 워크로드 상태를 모니터링합니다. Fabric 용량 메트릭 앱을 사용하여 CU 사용량, 제한 및 초과분과 같은 용량 소비를 모니터링합니다. 작업 영역 모니터링을 사용하여 개별 워크로드에 대한 자세한 원격 분석에 액세스할 수 있습니다. 패턴 3 및 4와 같은 다중 용량 패턴에서는 각 용량을 담당하는 팀에 모니터링을 위임할 수 있습니다.

• Fabric 도메인을 통해 관리를 위임합니다. 패턴 2와 3에서는 Fabric 도메인 사용하여 테넌트 관리자 권한이 없는 도메인 수준 관리자에게 테넌트 설정 및 작업 영역 관리를 위임합니다. 패턴 1은 모든 항목이 하나의 작업 영역에 있으므로 도메인을 사용할 수 없습니다.

• IaC(Infrastructure as Code)를 사용하여 용량을 관리합니다. Bicep 또는 Terraform 사용하여 Fabric 용량을 만들고 관리합니다. 애플리케이션 코드와 함께 소스 제어에 인프라 정의를 저장합니다.

성능 효율성

성능 효율성은 사용자 요구를 효율적으로 충족하기 위해 워크로드의 크기를 조정하는 기능을 의미합니다. 자세한 내용은 성능 효율성에 대한 디자인 검토 검사 목록을 참조하세요.

• 용량 크기 조정 및 제한 동작을 이해합니다. 각 용량에는 SKU에 의해 결정되는 고정 CU 할당이 있습니다. 요청이 사용 가능한 컴퓨팅 유닛(CU)을 초과하면, Fabric은 제한을 적용하고 요청을 큐에 저장합니다. Fabric 용량 메트릭 앱을 사용하여 스로틀링 이벤트를 모니터링하고 필요에 따라 SKU를 확장하거나 여러 용량에 워크로드를 분산합니다.

• 전용 용량에서 성능에 민감한 워크로드를 격리합니다. 패턴 1과 2에서 모든 워크로드는 동일한 CPU에 대해 경쟁합니다. 비용이 많이 드는 쿼리 또는 데이터 파이프라인은 다른 사용자의 대화형 쿼리 성능을 저하시킬 수 있습니다. 패턴 3 및 4에서는 CU 할당이 보장된 전용 용량에서 성능에 민감한 워크로드를 격리할 수 있습니다.

• 데이터 엔지니어링 워크로드에 대한 Spark 풀을 구성합니다. 데이터 엔지니어링 워크로드의 경우 사용자 지정 Spark 풀을 사용하여 최소 및 최대 노드 수를 제어하고 자동 크기 조정을 지원합니다. 관리형 가상 네트워크는 시작 풀 또는 미리 설치된 공유 클러스터를 사용하지 않도록 설정하여 세션 시작 시간을 초에서 3분에서 5분 사이로 늘림

• 용량을 데이터 생산자 및 소비자에 가깝게 배치합니다. 패턴 3에서는 데이터 생산자 또는 소비자와 가까운 지역에서 용량을 사용하여 지역 간 대기 시간을 줄일 수 있습니다. OneLake 바로 가기는 다른 지역의 데이터를 참조할 수 있지만, 지역 간 데이터 읽기는 대기 시간과 전송 비용을 초래합니다.

• 워크로드별 최적화 기술을 적용합니다. 레이크하우스에 Z-Ordering 및 V-Ordering을 활용하여 스캔 성능을 향상시킵니다. 창고에서는 쿼리 패턴을 최적화하여 더 작은 데이터를 읽을 수 있도록 합니다. Power BI 보고서에 Direct Lake 모드를 사용하여 가져오기 모드에 비해 용량 부하를 줄입니다.

기능 매트릭스

다음 표에서는 각 패턴의 기능에서 주요 차이점을 요약합니다.

거버넌스 및 관리

¹ 작업 영역은 약간의 격리를 제공하지만 모든 작업 영역은 단일 용량을 공유하므로 사용량 추적 및 관리의 세분성이 제한됩니다.

² 패턴 4에서는 도메인이 아닌 별도의 테넌트가 사용됩니다. 각 테넌트에는 고유한 관리 모델이 있습니다.

보안

DevOps 및 수명 주기 관리

³ 배포 파이프라인에는 모놀리식 단일 작업 영역 패턴에서 사용할 수 없는 별도의 작업 영역이 필요합니다.

⁴ Git 통합을 사용할 수 있지만 모든 팀은 단일 리포지토리를 공유하므로 병합 경합이 발생할 수 있습니다.

성능과 규모

⁵ 워크로드가 전용 용량에 있는 경우 제한 위험이 낮지만 수요가 사용 가능한 CPU를 초과하는 경우 단일 용량 내에서 제한이 발생할 수 있습니다.

청구 및 비용 관리

⁶ 각 용량은 자체 청구 미터를 생성하므로 청구는 중앙 집중식이 아닌 용량에 분산됩니다.

기여자

Microsoft 이 문서를 유지 관리합니다. 이 문서를 작성한 기여자는 다음과 같습니다.

대표 저자:

• Amanjeet Singh | 주 프로그램 관리자

기타 기여자:

• 로린 페르디난드 | 수석 컨설턴트
• 홀리 켈리 | 주 프로그램 관리자
• Gabi Muenster | 선임 프로그램 관리자
• 사라 사시다란 | 선임 프로그램 관리자

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하십시오.

다음 단계

• Fabric 개념 및 라이선스
• Fabric 작업 영역
• Fabric 도메인
• OneLake란?
• Fabric 배포 파이프라인
• Fabric의 신뢰성
• Fabric 보안 개요

관련 리소스

• 기술 선택 개요
• Fabric으로 종단 간 분석
• Fabric을 사용한 기업 비즈니스 인텔리전스
• Fabric을 사용하여 그린필드 레이크하우스를 구축합니다.