페이지를 매긴 보고서 용량 계획
적용 대상: 
Power BI 페이지를 매긴 보고서 Power BI 서비스 
Power BI Desktop
최소 비용으로 페이지를 매긴 보고서에서 최상의 성능을 얻기 위해 프리미엄 용량을 계획하는 방법을 알아봅니다. 다른 비즈니스 인텔리전스 도구에서 Power BI로 마이그레이션하는 경우 사용할 용량을 결정하기 전에 아래 나열된 문서를 읽어 보세요.
SQL Server Reporting Services 보고서를 Power BI로 마이그레이션 - 보고서 정의 언어(.rdl) 보고서를 SQL Server Reporting Services(SSRS)에서 Power BI로 마이그레이션하는 데 관심이 있는 보고서 작성자 및 Power BI 관리자를 대상으로 합니다.
용량 계획
필요한 용량 유형을 계산하는 것은 보고서의 시각적 개체 수, 보고서에 대한 쿼리의 복잡성 및 데이터 원본 또는 데이터 모델의 품질과 같은 여러 요소에 따라 달라집니다. 또한 페이지를 매긴 보고서를 추가하기 전에 사용량이 많은 시간에 용량의 현재 사용을 고려해야 합니다.
필요한 용량 계획을 시작하기 전에 용량 및 SKU 테이블을 검토하여 각 용량에서 제공되는 리소스를 확인합니다.
용량을 계획할 때 다음 사항을 고려합니다.
보고서 디자인의 복잡성. 중첩 테이블릭스, 여러 하위 보고서 및 여러 행 및 열 그룹이 디자인의 복잡성을 더하며 용량 리소스가 필요합니다.
보고서에서 검색한 데이터 양. 보고서에 필요한 데이터가 많을수록 용량에서 더 많은 리소스가 필요합니다.
보고서가 데이터를 검색하는 방식입니다. 커넥터, 드라이버 또는 게이트웨이를 사용하면 데이터 검색에 시간이 더 오래 걸리고 더 많은 리소스가 필요하며 결과적으로 비용이 더 많이 들 수 있습니다.
큰 보고서를 Excel 및 PDF와 같은 형식으로 내보낼 때는 모든 페이지를 읽고, 토글을 사용하고, 보고서 내에서 검색하는 것보다 더 많은 리소스가 필요합니다.
SKU는 얼마나 많은 사용자를 처리할 수 있나요?
다양한 용량에 대해 페이지를 매긴 보고서를 테스트하기 위해 서로 다른 SKU 크기에 대해 세 가지 유형의 워크로드를 실행했습니다. 각 워크로드는 크기가 다른 단일 보고서를 동시에 렌더링하는 것으로 구성되었습니다.
소형 – 데이터 집계 테이블은 Azure SQL 데이터 원본에서 100개 이상의 행을 빌드했습니다.
중간 – 데이터 집계 테이블은 Azure SQL 데이터 원본에서 100,000개 이상의 행을 빌드했습니다.
대형 – 데이터 집계 테이블은 Azure SQL 데이터 원본에서 250,000개 이상의 행을 빌드했습니다.
Power BI Premium 대한 분석에 따르면 일일 사용량이 많은 시간을 포함하여 지정된 시간에 동시 사용자 수가 전체 사용자 기반의 5%를 초과하지 않는 경향이 있음을 보여 줍니다.
다음 표에서는 5%의 동시성 비율을 기준으로 SKU가 오버로드되기 전에 처리할 수 있는 대략적인 최대 사용자 수를 설명합니다. 용량이 오버로드되면 용량에서 제한이 발생합니다. 자세한 내용은 자동 스케일링을 하지 않으면 오버로드 중에 트래픽이 어떻게 되나요?를 참조하세요.
| 작업 | F64 또는 P1 SKU | F128 또는 P2 SKU |
|---|---|---|
| 소형 | 2,500명 사용자 | 5,000명 사용자 |
| 중간 | 1,900명 사용자 | 3,800명 사용자 |
| Large | 1,300명 사용자 | 2,600명 사용자 |
테이블의 숫자는 다른 작업을 실행하지 않는 지정된 용량을 참조하는 것을 고려합니다. 용량은 다음과 같은 작업에 CPU 리소스를 이미 사용할 수 있습니다.
데이터 검색 및 처리
기타 워크로드 및 백그라운드 작업
복잡한 데이터 그룹화 및 재구성
데이터 필터링
동시 요청
페이지를 매긴 보고서 워크로드를 포함하여 용량의 각 워크로드에는 특정 시간에 최대 500개의 동시 보고서 렌더링이 있습니다. 보고서 100개를 렌더링할 수 있는 용량이고 페이지를 매긴 보고서 내보내기에 대한 요청이 200개라면 동시 보고서 렌더링 요청은 200개 남습니다.
혼잡을 방지하려면 동시 요청 로드를 미리 계획합니다. 동시 요청 한도를 초과하면 요청이 너무 많음(429) 오류가 발생합니다.
메트릭 앱 사용
Microsoft Fabric 용량 메트릭 앱을 사용하면 페이지를 매긴 보고서가 용량에 미치는 영향을 예상할 수 있습니다. 앱은 시간에 따른 CPU 사용량을 측정하여 용량의 성능을 이해할 수 있도록 합니다.
페이지를 매긴 보고서를 테스트하려면 전용 클린 용량을 사용하는 것이 좋습니다. 클린 용량은 다른 사용자 및 워크로드의 영향으로부터 결과를 격리하는 데 도움이 됩니다.
대상 테스트 시나리오(예: 평균 또는 최대 사용량 유효성 검사)에 따라 예상 리소스 사용량에 대한 보고서 담당자를 선택하거나 만들고 테스트를 위해 만든 용량의 프리미엄 작업 영역에 업로드합니다.
보고서를 여러 번 실행하고 메트릭 앱을 사용하여 보고서를 실행하는 데 소요된 평균 CPU 초를 가져옵니다. 보고서를 실행하는 데 걸린 시간을 계산할 때 다음 사항을 고려합니다.
앱은 집계 값을 표시합니다. 보고서를 실행한 횟수만큼 결과를 나누어야 할 수 있습니다.
보고서 렌더링에 포함될 수 있는 여러 Power BI 항목 및 작업이 있습니다. CPU 사용량을 합산해야 할 수도 있습니다.
렌더링에 시간이 오래 걸릴 수 있으므로 보고서 렌더링에 여러 Power BI 항목 및 작업이 포함될 수 있습니다. Timepoint 페이지에서 장기 실행 작업을 작업 목록으로 표시할 수 있으며 30초보다 긴 기간은 없습니다. 렌더링 작업 CPU 사용량을 합산해야 할 수도 있습니다. 시작 시간을 기준으로 정렬하면 렌더링의 전체 기록을 표시하는 데 도움이 될 수 있습니다.
최대 보고서 렌더링 계산
이 수식을 사용하여 용량이 오버로드되기 전에 처리할 수 있는 최대 동시 보고서 렌더링을 계산합니다. CU(용량 단위), SKU 및 Power BI v 코어에 대한 자세한 내용은 용량 개념을 참조 하세요.
$ \text {max concurrent report renders} = {\text {capacity units for your capacity} \times {3.75} \over \text {your report's CPU processing time (초)} } $
최대 사용자 수 계산
총 사용자 수와 최대 동시 렌더링 간의 상관 관계에 대해 예상되는 5%의 동시성을 사용하여 SKU에서 처리할 수 있는 총 사용자 수를 가져올 수 있습니다.
$ \text {최대 SKU 사용자} = {\text {최대 동시 보고서 렌더링} \over 0.05} $
여러 보고서에 대한 용량 리소스 계산
확장 수식을 사용하여 다양한 보고서 사용량에 필요한 용량을 예측할 수 있습니다.
매일 렌더링 수가 다른 페이지를 매긴 보고서를 여러 개 업로드하고 메트릭 앱을 사용하여 각 렌더링에 대한 평균 CPU 처리 시간을 가져옵니다. 일일 모든 보고서 렌더링의 합계는 100%와 같아야 합니다. 모든 정보가 있는 경우 이 수식을 사용합니다.
$ \text {max concurrent report renders} = {\text {capacity units for your capacity} \times {3.75} \over {\text {A renders} \times \text {A processing time}} + \text {B renders} \times \text {B processing time} + \text {...} + \text{N renders} \times \text{N processing time}}$
예제
이 섹션에는 일반 계산에 대한 예제와 고급 계산을 위한 예제가 포함되어 있습니다.
일반 계산
8개의 코어가 있는 F64 또는 P1 SKU에서 페이지를 매긴 보고서를 실행한다고 가정해 보겠습니다. 10개의 실행에 대한 총 CPU 사용량은 40초이므로 보고서당 평균 CPU 시간은 4초입니다.
$ 60 = {8 \times {30} \over 4} $
두 번째 수식을 사용하는 경우 최대 1,200명의 사용자를 얻을 수 있습니다.
$ 1,200 = {60 \over 0.05} $
F128 또는 P2의 경우 용량이 CPU 코어 수의 두 배이므로 이러한 숫자를 2로 곱할 수 있습니다.
고급 계산
아래 표에 나열된 일별 렌더링 백분율이 있는 페이지가 매겨진 보고서 3개가 있다고 가정해 보겠습니다.
| 보고서 | 하루에 렌더링된 보고서 수 | CPU 처리 시간(초) |
|---|---|---|
| A | 60% | 4 |
| b | 30% | 10 |
| C | 10% | 20 |
F64 또는 P1 SKU의 수식은 다음과 같습니다.
| 값 | 수식 |
|---|---|
| 최대 동시 보고서 렌더링 | $ ~32.4 = {8 \times {30} \over 0.6 \times{4} + 0.3 \times{10} + 0.1 \times{20}} $ |
| 총 SKU 사용자 수 | $ ~650 = {32.4 \over 0.05} $ |