다음을 통해 공유

Microsoft Fabric 용량 평가 및 최적화

  • 아티클

이 문서에서는 Microsoft Fabric 용량의 부하를 평가하고 최적화하는 방법을 설명합니다. 또한 오버로드 상황을 해결하기 위한 전략을 설명하고 각 패브릭 환경에 대한 컴퓨팅을 최적화하는 데 도움이 되는 지침을 제공합니다.

패브릭 용량 모델은 설정을 간소화하고 공동 작업을 가능하게 하지만 용량의 공유 컴퓨팅 리소스를 고갈시킬 가능성이 높습니다. 필요한 것보다 더 많은 리소스에 대한 비용을 지불하는 경우도 있을 수 있습니다. 이러한 상황은 일부 패브릭 환경의 디자인이 모범 사례를 따르지 않는 경우에 발생할 수 있습니다.

공유 리소스가 고갈될 위험을 줄이는 것이 중요합니다. 패브릭은 관리되는 서비스로서 이러한 상황을 두 가지 방법을 사용하여 자동으로 해결합니다.

  • 버스팅 및 스무딩을 사용하면 더 높은 SKU 없이도 CPU 집약적인 작업이 신속하게 완료됩니다(하루 중 언제든지 실행할 수 있습니다).
  • 용량이 CPU에 대한 지속적인 높은 수요(SKU 제한 초과)를 경험하는 경우 제한은 작업을 지연하거나 거부합니다.

스무딩은 제한 가능성을 줄입니다(제한은 여전히 발생할 수 있음). 스무딩은 제한에 대해 사용량을 할당하는 방법이지만 작업 실행과는 독립적입니다. 스무딩은 성능을 변경하지 않고, 소비된 컴퓨팅에 대한 계산을 더 긴 기간 동안 분산하므로 최대 컴퓨팅을 처리하는 데 더 큰 SKU가 필요하지 않습니다.

패브릭 용량에 대한 자세한 내용은 Microsoft Fabric 개념 및 라이선스 및 패브릭 용량 – 새로운 기능과 향후 기능에 대해 알아야 할 모든 것을 참조하세요.

계획 및 예산 도구

용량 크기를 계획하는 것은 어려울 수 있습니다. 이는 수행된 작업, 실행 상태(예: DAX 쿼리 또는 Notebook의 Python 코드 효율성) 또는 동시성 수준으로 인해 필요한 컴퓨팅이 크게 달라질 수 있기 때문입니다.

적절한 용량 크기를 결정하는 데 도움이 되도록 평가판 용량 또는 종량제 F SKU를 프로비전하여 F SKU 예약 인스턴스를 구매하기 전에 필요한 실제 용량 크기를 측정할 수 있습니다.

팁

작게 시작한 다음 필요에 따라 용량의 크기를 점진적으로 늘리는 것이 항상 좋은 전략입니다.

용량 모니터링

사용률을 모니터링하여 용량을 최대한 활용해야 합니다. 패브릭 작업이 대화형 또는 백그라운드라는 것을 이해하는 것이 중요합니다. 예를 들어 Power BI 보고서의 DAX 쿼리는 대화형 작업인 주문형 요청이지만 의미 체계 모델 새로 고침은 백그라운드 작업입니다. 작업 및 패브릭 내에서 리소스를 사용하는 방법에 대한 자세한 내용은 패브릭 작업을 참조하세요.

모니터링을 통해 제한이 진행되고 있음을 알 수 있습니다. 제한은 다수의 또는 장기 실행 대화형 작업이 있을 때 발생할 수 있습니다. 일반적으로 SQL 및 Spark 환경과 관련된 백그라운드 작업이 원활하게 진행되므로 24시간 동안 분산됩니다.

패브릭 용량 메트릭 앱은 최근 사용률을 모니터링하고 시각화하는 가장 좋은 방법입니다. 앱은 항목 유형(의미 체계 모델, Notebook, 파이프라인 등)으로 분류되며, 높은 수준의 컴퓨팅을 사용하는 항목 또는 작업을 식별하는 데 도움이 됩니다(최적화할 수 있도록).

관리자는 관리자 모니터링 작업 영역을 사용하여 자주 사용되는 항목(및 전체 채택)에 대해 알아볼 수 있습니다. 모니터링 허브를 사용하여 테넌트에서 현재 및 최근 활동을 볼 수도 있습니다. 일부 작업에 대한 자세한 내용은 로그 분석 또는 온-프레미스 데이터 게이트웨이 로그에서도 확인할 수 있습니다.

높은 컴퓨팅 사용량 관리

용량이 많이 활용되고 제한 또는 거부를 표시하기 시작하면 이를 해결하기 위한 세 가지 전략인 최적화, 강화, 스케일 아웃이 있습니다.

용량 사용률이 설정된 임계값을 초과하는 경우를 알아보도록 알림을 설정하는 것이 좋습니다. 또한 워크로드별 설정을 사용하여 작업 크기를 제한하는 것이 좋습니다(예: Power BI 쿼리 시간 제한 또는 행 제한 또는 Spark 작업 영역 설정).

Optimize

콘텐츠 작성자는 항상 패브릭 항목의 디자인을 최적화하여 효율적이고 가능한 최소한의 컴퓨팅 리소스를 사용해야 합니다. 각 패브릭 환경에 대한 구체적인 지침은 이 문서의 뒷부분에 나와 있습니다.

강화

용량을 스케일 업하여 SKU 크기를 일시적으로 또는 영구적으로 늘입니다(더 많은 컴퓨팅 용량 포함). 확장하면 용량의 모든 항목에 사용할 수 있는 컴퓨팅 리소스가 충분하고 제한을 방지할 수 있습니다.

패브릭 F SKU의 크기를 조정, 일시 중지 및 다시 시작하여 소비 패턴에 맞게 조정할 수도 있습니다.

규모 확장

워크로드를 분산하기 위해 작업 영역 또는 항목 중 일부를 다른 패브릭 용량으로 이동하여 스케일 아웃합니다. 다양한 용량 전략, 설정 또는 관리자가 필요한 경우 좋은 옵션이 될 수 있습니다. 여러 용량을 프로비전하는 것은 우선 순위가 높은 항목과 셀프 서비스 또는 개발 콘텐츠에 대한 컴퓨팅을 격리하는 데 도움이 되는 좋은 전략이기도 합니다. 예를 들어 조직의 경영진은 응답성이 뛰어난 보고서와 대시보드를 기대합니다. 이러한 보고서 및 대시보드는 임원 보고 전용으로 별도의 용량에 상주할 수 있습니다.

소비자가 콘텐츠에 계속 액세스할 수 있는 Power BI Pro 라이선스가 있는 경우 Power BI 작업 영역을 공유 용량으로 이동하는 것도 고려할 수 있습니다.

패브릭 환경별 컴퓨팅 최적화

패브릭의 환경과 항목은 다르게 작동하므로 반드시 같은 방식으로 최적화하지는 않습니다. 이 섹션에서는 환경에 따라 패브릭 항목을 나열하고 최적화하기 위해 수행할 수 있는 작업을 나열합니다.

Fabric Data Warehouse

데이터 웨어하우스는 서버리스 아키텍처를 사용하며 해당 노드는 서비스에서 자동으로 관리됩니다. 용량 사용량은 프런트 엔드 및 백 엔드 노드가 프로비전되는 시간이 아니라 쿼리당 활성 용량 단위 초를 기준으로 계산됩니다.

모든 데이터 웨어하우스 작업은 백그라운드 작업이며 24시간 동안 원활하게 진행됩니다.

SQL 분석 엔드포인트는 기본적으로 성능을 제공하는 것을 목표로 합니다. 이를 위해 SQL Server 또는 Azure Synapse Analytics 전용 SQL 풀에 비해 사용 가능한 쿼리 튜닝 옵션이 더 적습니다.

컴퓨팅을 최소화하기 위해 고려해야 할 몇 가지 사항은 다음과 같습니다.

  • 가능한 가장 최적의 T-SQL을 사용하여 쿼리를 작성합니다. 가능하면 쿼리 리소스 사용량을 불필요하게 늘릴 수 있는 열, 계산, 집계 및 기타 작업의 수를 제한합니다.
  • 가능한 가장 작은 데이터 형식을 사용하도록 테이블을 디자인합니다. 데이터 형식을 선택하면 SQL 엔진에서 생성된 쿼리 계획에 큰 영향을 줄 수 있습니다. 예를 들어 VARCHAR 필드를 길이 500에서 25로 줄이거나 DECIMAL(32, 8)에서 DECIMAL(10, 2)로 변경하면 쿼리에 할당된 리소스가 크게 감소할 수 있습니다.
  • 별모양 스키마 디자인을 사용하여 읽은 행 수를 줄이고 쿼리 조인을 최소화합니다.
  • 통계가 존재하며 최신 상태인지 확인합니다. 통계는 가장 최적의 실행 계획을 생성하는 데 중요한 역할을 합니다. 런타임에 자동으로 만들어지지만, 특히 데이터가 로드되거나 업데이트된 후에 수동으로 업데이트해야 할 수 있습니다. 샘플링을 사용하는 자동 생성된 통계에 의존하지 않고 FULLSCAN 옵션을 사용하여 통계를 만드는 것이 좋습니다.
  • 특히 문제 해결 시 기본 제공 보기를 사용하여 쿼리 및 사용량을 모니터링합니다.
    • sys.dm_exec_requests DMV(동적 관리 뷰)는 현재 실행 중인 모든 쿼리에 대한 정보를 제공하지만 기록 정보는 저장하지 않습니다. 패브릭 도구 상자는 이 DMV를 사용하는 쿼리를 제공하고 쿼리 텍스트와 같은 세부 정보를 제공하기 위해 다른 보기에 조인하여 쿼리 결과 사용자를 친숙하게 만듭니다.
    • 패브릭 데이터 웨어하우징의 기능인 쿼리 인사이트는 SQL 분석 엔드포인트에서 기록 쿼리 작업의 전체적인 보기를 제공합니다. 특히 queryinsights.exec_requests_history 보기는 각 전체 SQL 요청에 대한 정보를 제공합니다. 용량 메트릭 앱에 있는 작업 ID와 상관 관계를 지정할 수 있는 각 쿼리 실행에 대한 모든 관련 세부 정보를 제공합니다. 용량 사용량을 모니터링하는 데 가장 중요한 열은 distributed_statement_id, command(쿼리 텍스트), start_time, end_time입니다.

패브릭 데이터 엔지니어 및 패브릭 데이터 과학

데이터 엔지니어 및 데이터 과학 환경은 Spark 컴퓨팅을 사용하여 패브릭 레이크하우스에서 데이터를 처리, 분석 및 저장합니다. Spark 컴퓨팅은 vCore 측면에서 설정 및 측정됩니다. 그러나 패브릭은 Spark Notebook, Spark 작업 정의, 레이크하우스 작업을 비롯한 다양한 항목에서 사용하는 컴퓨팅의 측정값으로 CU를 사용합니다.

Spark에서 하나의 CU는 컴퓨팅의 두 Spark vCore로 변환됩니다. 예를 들어 고객이 F64 SKU를 구매하면 Spark 환경에 128개의 Spark v 코어를 사용할 수 있습니다.

모든 Spark 작업은 백그라운드 작업이며 24시간 동안 원활하게 진행됩니다.

자세한 내용은 패브릭 Spark의 청구 및 사용률 보고를 참조하세요.

컴퓨팅을 최소화하기 위해 고려해야 할 몇 가지 사항은 다음과 같습니다.

  • 항상 효율적인 Spark 코드를 작성하려고 노력합니다. 자세한 내용은 Azure Synapse Analytics 에서 Apache Spark 작업 최적화 및 Apache Spark에서 쓰기 최적화의 필요성을 참조하세요.
  • 다른 Spark 작업 또는 워크로드에 대한 리소스를 확보하려면 Spark 작업에 필요한 실행기를 예약합니다. 그렇지 않으면 HTTP 430 상태로 Spark 작업이 실패할 가능성이 높아지는데, 이는 용량에 대한 요청이 너무 많다는 것을 의미합니다. 패브릭 모니터링 허브에서 Notebook에 할당된 실행기 수를 볼 수 있으며, 여기서 Notebook에서 사용하는 실행기의 실제 수를 확인할 수도 있습니다. Spark 작업은 필요한 노드만 예약하고 SKU 제한 내에서 병렬 제출을 허용합니다.
  • Spark 풀은 SKU에서 지원하는 최대 vCore 수를 사용하도록 구성할 수 있습니다. 그러나 SKU 제한 내에서 병렬 Spark 작업을 수락하여 데이터 엔지니어링 워크로드를 확장할 수 있습니다. 이 방법은 일반적으로 버스트 팩터라고 하며 용량 수준에서 Spark 워크로드에 대해 기본적으로 사용하도록 설정됩니다. 자세한 내용은 동시성 제한 및 큐를 참조하세요.
  • 활성 Spark 세션은 용량에서 CU 사용이 발생할 수 있습니다. 이러한 이유로 사용하지 않을 때 활성 Spark 세션을 중지해야 합니다. 기본 Spark 세션 만료 시간은 20분으로 설정됩니다. 사용자는 Notebook 또는 Spark 작업 정의에서 세션 시간 제한을 변경할 수 있습니다.

실시간 인텔리전스

KQL 데이터베이스 CU 사용량은 데이터베이스가 활성 상태인 시간(초)과 사용된 vCore 수를 기준으로 계산됩니다. 예를 들어 데이터베이스에서 4개의 vCore를 사용하고 10분 동안 활성화된 경우 2,400초(4 x 10 x 60)의 CU를 사용합니다.

모든 KQL 데이터베이스 작업은 대화형 작업입니다.

자동 크기 조정 메커니즘을 사용하여 KQL 데이터베이스의 크기를 확인합니다. 사용 패턴에 따라 가장 비용 최적화되고 최상의 성능을 달성할 수 있습니다.

다른 패브릭 엔진에서 데이터를 사용할 수 있도록 KQL 데이터베이스는 OneLake와 동기화됩니다. KQL 데이터베이스가 수행하는 읽기 및 쓰기 트랜잭션 수에 따라 CU는 용량에서 사용됩니다. ADLS(Azure Data Lake Storage) Gen2 계정의 읽기 및 쓰기 작업과 동일한 OneLake 읽기 및 쓰기 미터를 활용합니다.

Data Factory

이 섹션은 Data Factory의 데이터 흐름 및 데이터 파이프라인에 대한 최적화와 관련이 있습니다.

모든 작업은 백그라운드 작업이며 24시간 동안 원활하게 진행됩니다.

컴퓨팅을 최소화하기 위해 고려해야 할 몇 가지 사항은 다음과 같습니다.

  • 병합 및 정렬과 같이 비용이 많이 드는 데이터 변환을 최소화하고 최적화하려면 비효율적인 Power Query 논리를 사용하지 마세요.
  • 가능하면 쿼리 폴딩을 달성하기 위해 노력합니다. 데이터 원본과 대상 간에 전송해야 하는 데이터의 양을 줄여 데이터 흐름의 성능을 향상시킬 수 있습니다. 쿼리 폴딩이 발생하지 않으면 파워 쿼리는 데이터 원본에서 모든 데이터를 검색하고 로컬로 변환을 수행하므로 비효율적이고 느릴 수 있습니다.
  • 작은 데이터 볼륨으로 작업하거나 간단한 변환을 수행할 때 스테이징을 사용하지 않도록 설정합니다. 데이터 웨어하우스를 로드하는 등의 경우에 스테이징이 필요할 수 있습니다.
  • 데이터 원본에 필요한 것보다 더 자주 데이터를 새로 고치지 마세요. 예를 들어 데이터 원본이 24시간마다 한 번만 업데이트되는 경우 매시간 데이터를 새로 고치면 더 이상 값이 제공되지 않습니다. 대신 데이터를 적절한 빈도로 새로 고쳐 최신 상태이고 정확한지 확인하는 것이 좋습니다.

Power BI

Power BI 작업은 대화형 또는 백그라운드입니다.

다음 대화형 작업은 일반적으로 컴퓨팅 사용량이 높습니다.

  • 모범 사례를 따르지 않는 의미 체계 모델입니다. 예를 들어 일 대 다 관계로 별모양 스키마 디자인을 채택하지 않을 수 있습니다. 또는 복잡하고 비용이 많이 드는 RLS(행 수준 보안) 필터를 포함할 수 있습니다. 테이블 형식 편집기 및 모범 사례 분석기를 사용하여 모범 사례를 따르는지 여부를 확인하는 것이 좋습니다.
  • DAX 측정값은 비효율적입니다.
  • 보고서 페이지에 너무 많은 시각적 개체가 포함되어 있어 시각적 개체 새로 고침이 느려질 수 있습니다.
  • 보고서 시각적 개체는 높은 카디널리티 결과(행 또는 열이 너무 많음)를 표시하거나 너무 많은 측정값을 포함합니다.
  • 용량 크기에 비해 사용자가 너무 많기 때문에 용량이 높은 동시성이 발생합니다. 높은 동시성 의미 체계 모델에 대한 사용자 환경을 개선하기 위해 쿼리 스케일 아웃을 사용하도록 설정하는 것이 좋습니다(하지만 더 많은 총 컴퓨팅을 생성하지는 않음).

다음 백그라운드 작업은 일반적으로 컴퓨팅 사용량이 높습니다.

  • Power Query 논리의 비효율적이거나 지나치게 복잡한 데이터 변환입니다.
  • 큰 팩트 테이블에 대한 쿼리 폴딩 또는 증분 새로 고침이 없습니다.
  • 높은 수의 Power BI 보고서 또는 페이지를 매긴 보고서가 동시에 생성되는 경우의 보고서 버스트입니다.

관련 콘텐츠

추가 질문이 있으신가요? 패브릭 커뮤니티에 문의해 보세요.