Microsoft Fabric 배포 패턴

이 문서에서는 Microsoft Fabric을 배포할 때 선택할 수 있는 네 가지 배포 패턴을 설명합니다. 각 배포 패턴에 대한 고려 사항, 권장 사항 및 잠재적인 되돌릴 수 없는 결정에 대해 알아봅니다.

각 패브릭 배포 패턴에 대해 다음과 같은 디자인 영역이 설명되어 있습니다.

• 거버넌스
• 보안
• 관리
• DevOps
• 유용성
• 성능 및 크기 조정
• 청구 및 비용 관리

패브릭 배포의 수준

패브릭 배포에는 테넌트, 용량, 작업 영역 및 항목의 네 가지 수준이 있습니다. 최상위 수준에는 패브릭 테넌트가 있습니다. 각 테넌트에는 하나 이상의 용량이 있을 수 있고, 각 용량에는 하나 이상의 작업 영역이 포함될 수 있으며, 각 작업 영역에는 0개 이상의 패브릭 항목이 포함될 수 있습니다.

보안, 규모, 거버넌스 및 애플리케이션 수명 주기 영역에서 조직의 구조 또는 목표가 배포 패턴 선택에 영향을 줄 수 있습니다. 다양한 배포 패턴은 배포 수준에서 다양한 유연성과 강조를 제공합니다.

예를 들어 조직에서는 do기본s를 사용하여 Fabric의 작업 영역을 그룹화할 수 있습니다. 마찬가지로 조직에서 공동 작업하고 콘텐츠를 찾는 데 사용할 수 있는 중앙 집중식 옵션이 있어야 하는 경우 Fabric의 OneLake 데이터 허브 는 중앙 집중식 액세스 지점을 제공하며 Microsoft Teams 및 Excel과 같은 다른 친숙한 제품과 통합됩니다.

Fabric에서 사업부가 별도의 지리적 위치에 있는 대규모 조직은 용량을 사용하여 데이터가 있는 위치를 제어할 수 있습니다. 다른 지역에 있는 작업 영역에 걸쳐 기본 수 있으므로 Fabric do기본s를 사용하여 다른 지리적 위치에서 작동하는 사업부를 단일 단위로 관리할 수 있습니다.

배포 패턴을 선택하는 패브릭 수준 및 해당 역할에 대한 자세한 내용은 Microsoft Fabric 개념 및 라이선스를 참조 하세요.

패브릭 배포 패턴이 정렬되는 방식

모든 패브릭 배포 패턴:

• 패브릭 작업 영역을 규모, 거버넌스 및 보안을 위한 경계로 사용합니다.
• 위임에 Fabric do기본s를 사용하여 동일한 사업부에 속할 수 있는 여러 작업 영역을 관리하거나 비즈니스에 속한 데이터가 둘 이상의 작업 영역에 걸쳐 있는 경우기본. do기본 수준에서 데이터를 관리하고 관리하기 위한 일부 테넌트 수준 설정을 설정하고 해당 설정에 대해 do기본 관련 구성을 사용할 수 있습니다.
• 패브릭 용량을 사용하여 특정 성능 수준을 충족해야 하는 경우 작업 영역당 전용 용량을 프로비전하면서 컴퓨팅 리소스의 크기를 조정합니다.
• Fabric에서 기능을 사용할 수 없는 경우 Microsoft 클라우드(Microsoft Azure, Microsoft 365 등)의 동등한 기능을 사용하도록 확장합니다.
• OneLake 데이터 허브를 사용하여 검색 및 데이터 자산 사용을 촉진합니다.
• OneSecurity를 사용하여 데이터 자산에 대한 데이터 보안 정책을 설정합니다.

비즈니스 요구 사항에 따른 시나리오

이 문서에서는 다음 시나리오를 사용하여 각 배포 패턴이 다양한 비즈니스 요구 사항을 해결하는 방법을 설명합니다.

• 시나리오 1: 데이터 사용량에 대한 제한을 낮추어 상호 공동 작업할 수 있는 팀을 구성하여 출시 시간을 더 빨라(또는 더 느리게) 원하는 조직의 경우. 이 시나리오에서 조직은 모놀리식 배포 패턴을 사용하여 이점을 얻을 수 있습니다. 조직은 단일 작업 영역에서 작동하고 관리합니다. 자세한 내용은 패턴 1: 모놀리식 배포를 참조하세요.
• 시나리오 2: 팀이 작업할 수 있는 격리된 환경을 제공하려는 조직의 경우 인프라 제공 및 관리를 담당하는 중앙 팀과 함께 합니다. 이 시나리오는 데이터 메시를 구현하려는 조직에도 적합합니다. 이 시나리오에서 조직은 공유 용량을 사용하거나 별도의 용량을 갖는 여러 작업 영역을 구현할 수 있습니다. 자세한 내용은 패턴 2: 단일 패브릭 용량으로 지원되는 여러 작업 영역 및 패턴 3: 별도의 용량으로 지원되는 여러 작업 영역을 참조하세요.
• 시나리오 3: 사업부 또는 팀에게 자체 데이터 플랫폼을 제어하고 관리할 수 있는 자유를 제공하는 완전히 분산된 모델을 원하는 조직의 경우. 이 시나리오에서 조직은 각각 전용 용량이 있거나 여러 패브릭 테넌트가 있는 별도의 작업 영역을 사용하는 배포 모델을 선택할 수 있습니다. 자세한 내용은 패턴 3: 별도의 용량으로 지원되는 여러 작업 영역 및 패턴 4: 여러 패브릭 테넌트(Multiple Fabric Tenants)를 참조하세요.
• 시나리오 4: 조직은 요구 사항을 달성하기 위해 여러 패턴을 결합하는 하이브리드 접근 방식을 사용하도록 선택할 수 있습니다. 예를 들어 조직은 다른 사업부에 대해 별도의 전용 작업 영역과 별도의 용량을 사용하는 동안 특정 사업부에 단일 작업 영역(모놀리식 배포 패턴)을 설정할 수 있습니다.

패턴 1: 모놀리식 배포

이 배포 패턴에서는 모든 사용 사례에 맞게 단일 작업 영역을 프로비전합니다. 모든 사업부는 동일한 단일 작업 영역 내에서 작동합니다.

단일 패브릭 용량을 프로비전하고 단일 작업 영역을 연결하는 경우 다음 사항이 적용됩니다.

• 모든 패브릭 항목은 동일한 프로비전된 용량을 공유합니다. 쿼리 또는 작업이 완료되는 데 걸리는 시간은 다른 워크로드에서 동일한 용량을 사용하기 때문에 달라집니다.
• 작업 영역 최대 CPU(용량 단위)는 가능한 가장 큰 F SKU 또는 P SKU로 제한됩니다. 데이터 엔지니어링 환경의 경우 별도의 Spark 풀을 프로비전하여 Fabric Spark에 필요한 컴퓨팅 용량을 프로비전된 CPU 외부로 이동할 수 있습니다.
• 작업 영역으로 범위가 지정된 기능은 해당 작업 영역을 공유하는 모든 사업부에 적용됩니다.
• 모든 작업 영역 항목 및 데이터는 한 지역에 있습니다. 다중 지역 시나리오에는 이 패턴을 사용할 수 없습니다.
• 배포 파이프라인 및 수명 주기 관리와 같은 여러 작업 영역을 사용하는 기능은 사용할 수 없습니다.
• 단일 작업 영역과 연결된 제한 사항이 적용됩니다.
• 특정 SKU와 연결된 용량 제한이 적용됩니다.

다음 이유 중 하나 이상에 대해 이 배포 패턴을 구현하도록 선택할 수 있습니다.

• 조직에 복잡한 엔지니어링 요구 사항이 없거나, 사용자 기반이 작거나, 의미 체계 모델이 작습니다.
• 조직은 단일 지역에서 작동합니다.
• 여러분은 주로 사업부 간의 조직 분리에 관심이 없습니다.
• 조직에는 Git과 코드 리포지토리 공유와 같은 작업 영역 범위 기능이 필요하지 않습니다.
• Lakehouse medallion 아키텍처를 구현하려고 합니다. 조직이 단일 작업 영역으로 제한되면 작업 영역 내에 별도의 레이크하우스를 만들어 브론즈, 실버 및 골드 레이어를 분리할 수 있습니다.
• 조직의 사업부는 역할을 공유하며 작업 영역의 사용자에 대해 동일한 작업 영역 수준 권한을 가질 수 있습니다. 예를 들어 여러 사업부에 속한 여러 사용자가 단일 작업 영역의 관리자인 경우 작업 영역의 모든 항목에 대해 동일한 권한을 가집니다.
• 조직에서 가변 작업 완료 시간을 허용할 수 있습니다. 조직에 성능 보장 요구 사항이 없는 경우(예: 작업이 특정 기간에 완료되어야 하는 경우) 사업부 간에 프로비전된 단일 용량을 공유하는 것이 허용됩니다. 용량이 공유되면 사용자는 언제든지 쿼리를 실행할 수 있습니다. 작업을 실행하는 데 사용할 수 있는 CPU 수는 용량에서 실행되는 다른 쿼리에 따라 달라집니다. 이로 인해 작업 완료 시간이 가변화될 수 있습니다.
• 조직은 단일 패브릭 용량을 사용하여 CU 관점에서 모든 비즈니스 요구 사항을 달성할 수 있습니다.

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

패턴 2: 단일 패브릭 용량에서 백업되는 여러 작업 영역

이 배포 패턴에서는 별도의 작업 영역을 사용합니다. 단일 용량은 작업 영역에서 공유되므로 언제든지 동시에 실행되는 워크로드는 작업 및 대화형 쿼리의 성능에 영향을 줄 수 있습니다.

단일 패브릭 용량을 프로비전하고 여러 작업 영역을 연결하는 경우 다음 사항이 적용됩니다.

• 모든 패브릭 항목은 동일한 프로비전된 용량을 공유합니다. 쿼리 또는 작업이 완료되는 데 걸리는 시간은 다른 워크로드에서 동일한 용량을 사용하기 때문에 달라집니다.
• 작업 영역에서 사용할 수 있는 최대 CPU는 가능한 가장 큰 F SKU 또는 P SKU로 제한됩니다. 데이터 엔지니어링 환경의 경우 별도의 Spark 풀을 프로비전하여 Fabric Spark에 필요한 컴퓨팅 용량을 프로비전된 CPU 외부로 이동할 수 있습니다.
• 작업 영역으로 범위가 지정된 기능은 해당 작업 영역을 공유하는 모든 사업부에 적용됩니다.
• 모든 작업 영역 항목 및 데이터는 한 지역에 있습니다. 다중 지역 시나리오에는 이 패턴을 사용할 수 없습니다.
• 배포 파이프라인 및 수명 주기 관리와 같이 별도의 작업 영역이 필요한 DevOps 기능을 사용할 수 있습니다.
• 단일 작업 영역과 연결된 제한 사항이 적용됩니다.
• 특정 SKU와 연결된 용량 제한이 적용됩니다.

다음 이유 중 하나 이상에 대해 이 배포 패턴을 구현하도록 선택할 수 있습니다.

• 조직에서 분석 환경 운영의 일부 측면을 중앙 집중화하고 다른 측면을 분산하는 허브 및 스포크 아키텍처를 원합니다.
• 운영 및 관리 측면에서 분산을 원하지만 다양한 각도로 분산하려고 합니다. 예를 들어 medallion 아키텍처의 브론즈 및 실버 레이어를 하나의 작업 영역에 배포하고 골드 계층을 다른 작업 영역에 배포하도록 선택할 수 있습니다. 여러분의 근거는 한 팀이 브론즈와 실버 레이어를 담당하고 다른 팀이 골드 레이어를 운영하고 관리하는 책임이 있다는 것입니다.
• 성능 관리 및 성능 관점에서 워크로드 격리에 대해서는 주로 신경 쓰지 않습니다.
• 레이크하우스 medallion 아키텍처의 관점에서 조직은 별도의 작업 영역을 만들어 브론즈, 실버 및 골드 레이어를 구현할 수 있습니다.
• 조직은 여러 지리적 지역에 워크로드를 배포할 필요가 없습니다(모든 데이터는 한 지역에 있어야 합니다).
• 조직에서 다음 이유 중 하나 이상을 위해 작업 영역을 분리해야 할 수 있습니다.
  • 워크로드를 담당하는 팀의 구성원은 서로 다른 작업 영역에 있습니다.
  • 각 워크로드 유형에 대해 별도의 작업 영역을 만들려고 합니다. 예를 들어 데이터 수집을 위한 작업 영역(데이터 파이프라인, 데이터 흐름 Gen2 또는 데이터 엔지니어링)을 만들고 데이터 웨어하우스를 통해 사용할 별도의 작업 영역을 만들 수 있습니다. 이 디자인은 개별 팀이 각 워크로드를 담당할 때 잘 작동합니다.
  • 하나 이상의 작업 영역이 Fabric에서 함께 그룹화되는 데이터 메시 아키텍처를 구현하려고 합니다기본.
• 조직에서 데이터 분류에 따라 별도의 작업 영역을 배포하도록 선택할 수 있습니다.

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

패턴 3: 별도의 용량으로 백업되는 여러 작업 영역

이 배포 패턴에서는 거버넌스와 성능을 위해 사업부를 분리합니다.

고유한 작업 영역으로 여러 패브릭 용량을 프로비전하는 경우 다음 사항을 확인합니다.

• 작업 영역에 연결된 가능한 가장 큰 F SKU 또는 P SKU는 작업 영역에서 사용할 수 있는 최대 CPU를 결정합니다.
• 조직 및 관리 분산은 별도의 작업 영역을 프로비전하여 수행됩니다.
• 조직은 여러 지리적 지역에 용량 및 작업 영역을 프로비전하여 한 지역을 넘어 확장할 수 있습니다.
• 사업부에는 별도의 용량에 있고 Fabric do기본를 통해 그룹화된 하나 이상의 작업 영역이 있을 수 있으므로 Fabric의 전체 기능을 사용할 수 있습니다.
• 단일 작업 영역과 연결된 제한 사항이 적용되지만 새 작업 영역을 만들어 이러한 제한을 초과하여 확장할 수 있습니다.
• 특정 SKU와 연결된 용량 제한이 적용되지만 별도의 용량을 프로비전하여 CPU 크기를 조정할 수 있습니다.
• 테넌트에 있는 모든 작업 영역의 모든 패브릭 항목과 해당 인증 상태 OneLake 데이터 허브를 사용하여 검색할 수 있습니다.
• Do기본는 단일 사업부가 여러 작업 영역을 작동하고 관리할 수 있도록 작업 영역을 그룹화할 수 있습니다.
• OneLake 바로 가기는 데이터 이동을 줄이고 작업 영역 전체에서 데이터 유용성을 줄입니다.

다음 이유 중 하나 이상에 대해 이 배포 패턴을 구현하도록 선택할 수 있습니다.

• 조직에서 데이터 메시 또는 데이터 패브릭과 같은 아키텍처 프레임워크를 배포하려고 합니다.
• 용량 및 작업 영역을 구성하는 방법에 유연성의 우선 순위를 지정하려고 합니다.
• 다른 지역에서 작동합니다. 이 경우 별도의 용량과 작업 영역을 프로비전하는 것이 이 다중 용량 및 다중 작업 영역 배포 패턴으로 이동하는 원동력입니다.
• 대규모로 작동하며 단일 용량 SKU 또는 단일 작업 영역의 제한을 초과하여 확장해야 하는 요구 사항이 있습니다.
• 특정 시간 내에 항상 완료되거나 특정 성능 SLA를 충족해야 하는 워크로드가 있습니다. 패브릭 용량으로 지원되는 별도의 작업 영역을 프로비전하여 해당 워크로드에 대한 성능 보장을 충족할 수 있습니다.

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

패턴 4: 여러 패브릭 테넌트

별도의 패브릭 테넌트가 배포되면 패브릭의 모든 인스턴스는 거버넌스, 관리, 관리, 규모 및 스토리지와 관련하여 별도의 엔터티입니다.

다음 점은 여러 패브릭 테넌트 사용 시 true입니다.

• 테넌트 리소스는 엄격하게 분리됩니다.
• 테넌트 간의 관리 평면은 별개입니다.
• 테넌트는 별도의 엔터티이며 거버넌스 및 관리를 위한 자체 프로세스를 가질 수 있지만 별도로 관리할 수 있습니다.
• 데이터 파이프라인 또는 데이터 엔지니어링 기능을 사용하여 패브릭 테넌트 간에 데이터를 공유하거나 액세스할 수 있습니다.

다음과 같은 이유로 이 배포 패턴을 구현하도록 선택할 수 있습니다.

• 조직은 비즈니스 획득으로 인해 여러 패브릭 테넌트를 사용할 수 있습니다.
• 조직은 특히 사업부 또는 소규모 자회사에 대해 패브릭 테넌트를 설정하도록 선택할 수 있습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

• 홀리 켈리 | 주 프로그램 관리자
• Gabi Muenster | 선임 프로그램 관리자
• 사라스 사시다란 | 선임 프로그램 관리자
• Amanjeet Singh | 보안 주체 프로그램 관리자