프리미엄 용량 최적화Optimizing Premium capacities

프리미엄 용량 성능 문제가 발생할 경우 일반적인 첫 번째 방법은 솔루션을 최적화하거나 조정하여 허용되는 응답 시간을 복원하는 것입니다.When Premium capacity performance issues arise, a common first approach is to optimize or tune your solutions to restore acceptable response times. 정당화되지 않는 한, 추가 프리미엄 용량을 구매하지 않도록 하기 위한 것입니다.The rationale being to avoid purchasing additional Premium capacity unless justified.

추가 프리미엄 용량이 필요한 경우 이 문서에서 설명하는 다음 두 가지 옵션이 있습니다.When additional Premium capacity is required, there are two options described in this article:

  • 기존 프리미엄 용량 강화Scale-up an existing Premium capacity
  • 새 프리미엄 용량 추가Add a new Premium capacity

마지막으로, 이 문서의 끝 부분에서는 테스트 접근 방법 및 프리미엄 용량 크기 조정에 대해 설명합니다.Finally, testing approaches and Premium capacity sizing conclude this article.

모범 사례Best practices

최상의 사용률 및 성능을 얻으려는 경우 다음을 비롯 한 몇 가지 권장 모범 사례가 있습니다.When trying to get the best utilization and performance, there are some recommended best practices, including:

  • 개인 작업 영역 대신 작업 영역 사용Using workspaces instead of personal workspaces.

  • 중요 비즈니스용 BI와 SSBI(셀프 서비스 BI)를 각기 다른 용량으로 구분Separating business critical and Self-Service BI (SSBI) into different capacities.

    중요 비즈니스용 BI와 셀프 서비스 BI를 각기 다른 용량으로 구분

  • Power BI Pro 사용자하고만 콘텐츠를 공유하는 경우 콘텐츠를 전용 용량에 저장하지 않아도 될 수 있습니다.If sharing content only with Power BI Pro users, there may be no need to store the content in a dedicated capacity.

  • 특정 새로 고침 시간을 구현하려는 경우 또는 특정 기능이 필요한 경우 전용 용량을 사용합니다.Use dedicated capacities when looking to achieve a specific refresh time, or when specific features are required. 예를 들어 큰 데이터 세트나 페이지를 매긴 보고에 사용합니다.For example, with large datasets or paginated reporting.

일반적인 질문 해결Addressing common questions

Power BI Premium 배포 최적화는 워크로드 요구 사항, 사용 가능한 리소스 및 효과적인 사용의 이해를 수반하는 복잡한 주제입니다.Optimizing Power BI Premium deployments is a complex subject involving an understanding of workload requirements, available resources, and their effective use.

이 문서에서는 7가지 일반적인 지원 관련 질문을 해결하고 가능한 문제 및 문제를 확인하고 해결하는 방법을 설명합니다.This article addresses seven common support questions, describing possible issues and explanations, and information on how to identify and resolve them.

용량이 느린 이유와 수행할 수 있는 작업은 무엇인가요?Why is the capacity slow, and what can I do?

느린 프리미엄 용량에 영향을 주는 여러 가지 이유가 있습니다.There are many reasons that can contribute to a slow Premium capacity. 이 질문에는 느리다는 의미를 파악하기 위한 추가 정보가 필요합니다.This question requires further information to understand what is meant by slow. 보고서가 느리게 로드되나요?Are reports slow to load? 또는 보고서가 로드되지 않나요?Or are they failing to load? 사용자가 보고서를 조작할 때 보고서 시각적 개체가 느리게 로드 또는 업데이트되나요?Are report visuals slow to load or update when users interact with the report? 새로 고침이 예상보다 오래 걸리거나 이전에 경험한 적이 있나요?Are refreshed taking longer to complete than expected, or previously experienced?

이유를 이해한 후에 조사를 시작할 수 있습니다.Having gained an understanding of the reason, you can then begin to investigate. 다음 6가지 질문에 답하면 보다 구체적인 문제를 해결하는 데 도움이 됩니다.Responses to the following six questions will help you to address more specific issues.

용량을 사용하는 콘텐츠는 무엇인가요?What content is using up my capacity?

Power BI Premium 용량 메트릭 앱을 사용하여 용량을 기준으로 필터링한 다음, 작업 영역 콘텐츠의 성능 메트릭을 검토할 수 있습니다.You can use the Power BI Premium Capacity Metrics app to filter by capacity, and review performance metrics for workspace content. 프리미엄 용량에 저장된 모든 콘텐츠에 대해 지난 7일간의 시간별 성능 메트릭 및 리소스 사용량을 검토할 수 있습니다.It's possible to review the performance metrics and resource usage by hour for the past seven days for all content stored within a Premium capacity. 대체로 프리미엄 용량 성능의 일반적인 문제를 해결할 때 첫 번째로 수행해야 하는 단계가 모니터링입니다.Monitoring is often the first step to take when troubleshooting a general concern about Premium capacity performance.

모니터링할 주요 메트릭은 다음과 같습니다.Key metrics to monitor include:

  • 평균 CPU 및 높은 사용률 수Average CPU and high utilization count.
  • 평균 메모리 및 높은 사용률 수와 특정 데이터 세트, 데이터 흐름, 페이지를 매긴 보고서의 메모리 사용량Average Memory and high utilization count, and memory usage for specific datasets, dataflows, and paginated reports.
  • 메모리에 로드된 활성 데이터 세트Active datasets loaded in memory.
  • 평균 및 최대 쿼리 기간Average and maximum query durations.
  • 평균 쿼리 대기 시간Average query wait times.
  • 평균 데이터 세트 및 데이터 흐름 새로 고침 시간Average dataset and dataflow refresh times.

Power BI Premium 용량 메트릭 앱의 활성 메모리는 지난 3분 이내에 사용되었기 때문에 제거할 수 없는 보고서에 제공된 총 메모리 양을 보여 줍니다.In the Power BI Premium Capacity Metrics app, active memory shows the total amount of memory given to a report that cannot be evicted because it has been in use within the last three minutes. 새로 고침 대기 시간 급증은 큰 데이터 세트 및/또는 활성 데이터 세트와 연관 지을 수 있습니다.A high spike in refresh wait time could be correlated with a large and/or active dataset.

평균 기간별 상위 5개 차트는 용량 리소스를 사용하는 상위 5개 데이터 세트, 페이지를 매긴 보고서 및 데이터 흐름을 강조 표시합니다.The Top 5 by Average Duration chart highlights the top five datasets, paginated reports, and dataflows consuming capacity resources. 상위 5개 목록의 콘텐츠는 조사 및 가능한 최적화 후보입니다.Content in the top five lists is candidates for investigation and possible optimization.

보고서가 느리게 표시되는 이유는 무엇인가요?Why are reports slow?

다음 표에서는 가능한 문제와 이러한 문제를 확인 및 처리하는 방법을 보여 줍니다.The following tables show possible issues and ways to identify and handle them.

용량 리소스 부족Insufficient capacity resources

가능한 설명Possible Explanations 확인 방법How to Identify 해결 방법How to Resolve
총 활성 메모리가 높습니다(지난 3분 이내에 사용되었기 때문에 모델을 제거할 수 없음).High total active memory (model can't be evicted because it's in use within the last three minutes).

쿼리 대기 시간이 여러 번 급증했습니다.Multiple high spikes in query wait times.

새로 고침 대기 시간 여러 번 급증했습니다.Multiple high spikes in refresh wait times.
메모리 메트릭[1] 및 제거 횟수[2]를 모니터링합니다.Monitor memory metrics [1], and eviction counts [2]. 모델 크기를 줄이거나 DirectQuery 모드로 변환합니다.Decrease the model size, or convert to DirectQuery mode. 이 문서의 모델 최적화 섹션을 참조하세요.See the Optimizing models section in this article.

용량을 강화합니다.Scale-up the capacity.

콘텐츠를 다른 용량에 할당합니다.Assign the content to a different capacity.

비효율적인 보고서 디자인Inefficient report designs

가능한 설명Possible Explanations 확인 방법How to Identify 해결 방법How to Resolve
보고서 페이지에 너무 많은 시각적 개체가 포함되어 있습니다(대화형 필터링은 시각적 개체당 하나 이상의 쿼리를 트리거할 수 있음).Report pages contain too many visuals (interactive filtering can trigger at least one query per visual).

시각적 개체가 필요 이상의 많은 데이터를 검색합니다.Visuals retrieve more data than necessary.
보고서 디자인을 검토합니다.Review report designs.

보고서 사용자를 인터뷰하여 보고서를 조작하는 방식을 파악합니다.Interview report users to understand how they interact with the reports.

데이터 세트 쿼리 메트릭[3]을 모니터링합니다.Monitor dataset query metrics [3].
페이지당 시각적 개체 수를 줄여서 보고서를 다시 디자인합니다.Redesign reports with fewer visuals per page.

특히 보고서의 이전 성능이 높았던 경우에 데이터 세트 속도가 느림Dataset is slow, especially when reports have previously performed well

가능한 설명Possible Explanations 확인 방법How to Identify 해결 방법How to Resolve
데이터 가져오기 볼륨이 점점 커지고 있습니다.Increasingly large volumes of import data.

RLS 역할을 포함하여 계산 논리가 복잡하거나 비효율적입니다.Complex or inefficient calculation logic, including RLS roles.

모델이 완전히 최적화되지 않았습니다.Model not fully optimized.

(DQ/LC) 게이트웨이 대기 시간이 높습니다.(DQ/LC) Gateway latency.

DQ 원본 쿼리 응답 시간이 늦습니다.Slow DQ source query response times.
모델 디자인을 검토합니다.Review model designs.

게이트웨이 성능 카운터를 모니터링합니다.Monitor gateway performance counters.
이 문서의 모델 최적화 섹션을 참조하세요.See the Optimizing models section in this article.

높은 동시 보고서 사용량High concurrent report usage

가능한 설명Possible Explanations 확인 방법How to Identify 해결 방법How to Resolve
쿼리 대기 시간이 높습니다.High query wait times.

CPU가 포화 상태입니다.CPU saturation.

DQ/LC 연결 한도를 초과했습니다.DQ/LC connection limits exceeded.
CPU 사용률[4], 쿼리 대기 시간 및 DQ/LC 사용률[5] 메트릭 + 쿼리 기간을 모니터링합니다.Monitor CPU utilization [4], query wait times, and DQ/LC utilization [5] metrics + Query durations. 변동하는 경우 동시성 문제를 나타낼 수 있습니다.If fluctuating, can indicate concurrency issues. 용량을 강화하거나 콘텐츠를 다른 용량에 할당합니다.Scale-up the capacity, or assign the content to a different capacity.

페이지당 시각적 개체 수를 줄여서 보고서를 다시 디자인합니다.Redesign reports with fewer visuals per page.

참고: Notes:
[1] 평균 메모리 사용량(GB) 및 최고 메모리 사용량(GB)[1] Average Memory Usage (GB), and Highest Memory Consumption (GB).
[2] 데이터 세트 제거.[2] Dataset evictions.
[3] 데이터 세트 쿼리, 데이터 세트 평균 쿼리 기간(밀리초), 데이터 세트 대기 수, 데이터 세트 평균 대기 시간(밀리초)[3] Dataset Queries, Dataset Average Query Duration (ms), Dataset Wait Count, and Dataset Average Wait Time (ms).
[4] CPU 높은 사용률 수 및 CPU 최고 사용률 시간(지난 7일)[4] CPU High Utilization Count and CPU Time of Highest Utilization (past seven days).
[5] DQ/LC 높은 사용률 수 및 DQ/LC 최고 사용률 시간(지난 7일)[5] DQ/LC High Utilization Count and DQ/LC Time of Highest Utilization (past seven days).

보고서가 로드되지 않는 이유는 무엇인가요?Why are reports not loading?

보고서를 로드하지 못한 경우 용량에 메모리가 부족하고 과열되었음을 나타냅니다.When reports fail to load, it's a sure sign the capacity has insufficient memory and is over-heated. 이 문제는 로드된 모든 모델이 적극적으로 쿼리되고 있으므로 제거할 수 없고 새로 고침 작업이 일시 중지되었거나 지연된 경우에 발생할 수 있습니다.This can occur when all loaded models are being actively queried and so cannot be evicted, and any refresh operations have been paused or delayed. Power BI 서비스는 30초 동안 데이터 세트를 로드하려고 시도하며, 잠시 후에 다시 시도하라는 제안과 함께 사용자에게 오류를 정상적으로 알립니다.The Power BI service will attempt to load the dataset for 30 seconds, and the user is gracefully notified of the failure with a suggestion to try again shortly.

현재, 보고서 로드 실패를 모니터링할 메트릭은 없습니다.Currently there is no metric to monitor for report loading failures. 시스템 메모리, 특히 최고 사용률과 최고 사용률 시간을 모니터링하여 이 문제의 발생 가능성을 확인할 수 있습니다.You can identify the potential for this issue by monitoring system memory, specifically highest utilization and time of highest utilization. 높은 데이터 세트 제거 및 긴 데이터 세트 새로 고침 평균 대기 시간도 이 문제가 발생할 것을 나타낼 수 있습니다.High dataset evictions and long dataset refresh average wait time could suggest that this issue is occurring.

이 문제가 매우 가끔씩만 발생하는 경우 우선 순위 문제로 간주되지 않을 수 있습니다.If this happens only very occasionally, this may not be considered a priority issue. 보고서 사용자는 서비스가 사용 중이며 잠시 후 다시 시도하라는 알림을 받습니다.Report users are informed that the service is busy and that they should retry after a short time. 이 문제가 자주 발생하는 경우 프리미엄 용량을 확장하거나 콘텐츠를 다른 용량에 할당하여 문제를 해결할 수 있습니다.If this happens too frequently, the issue can be resolved by scaling up the Premium capacity or by assigning the content to a different capacity.

용량 관리자(및 Power BI 서비스 관리자)는 쿼리 실패 메트릭을 모니터링하여 이 문제가 발생하는 경우를 확인할 수 있습니다.Capacity Admins (and Power BI service administrators) can monitor the Query Failures metric to determine when this happens. 시스템 오버로드의 경우 용량을 다시 시작하여 모든 작업을 다시 설정할 수도 있습니다.They can also restart the capacity, resetting all operations in case of system overload.

새로 고침이 일정에 따라 시작되지 않는 이유는 무엇인가요?Why are refreshes not starting on schedule?

예약된 새로 고침 시작 시간은 보장되지 않습니다.Scheduled refresh start times are not guaranteed. Power BI 서비스는 항상 백그라운드 작업보다 대화형 작업을 우선한다는 점을 기억하세요.Recall that the Power BI service will always prioritize interactive operations over background operations. 새로 고침은 다음 두 조건이 충족될 때 발생할 수 있는 백그라운드 작업입니다.Refresh is a background operation that can occur when two conditions are met:

  • 메모리가 충분합니다.There is sufficient memory
  • 프리미엄 용량에 대해 지원되는 동시 새로 고침 수를 초과하지 않았습니다.The number of supported concurrent refreshes for the Premium capacity is not exceeded

조건이 충족되지 않으면 조건이 개선될 때까지 새로 고침이 큐에 대기됩니다.When the conditions are not met, the refresh is queued until the conditions are favorable.

전체 새로 고침을 수행하려면 현재 데이터 세트 메모리 크기의 두 배 이상이 필요하다는 점을 기억하세요.For a full refresh, recall that at least double the current dataset memory size is required. 충분한 메모리를 사용할 수 없는 경우 모델 제거를 통해 메모리가 확보될 때까지 새로 고침을 시작할 수 없습니다. 즉, 하나 이상의 데이터 세트가 비활성화되어 제거할 수 있을 때까지 지연됩니다.If sufficient memory is not available, then the refresh cannot commence until model eviction frees up memory - this means delays until one or more datasets becomes inactive and can be evicted.

지원되는 최대 동시 새로 고침 수는 백 엔드 v 코어 수의 1.5배를 올림한 값으로 설정된다는 점을 기억하세요.Recall that the supported number of maximum concurrent refreshes is set to 1.5 times the backend v-cores, rounded up.

다음 예약된 새로 고침의 시작 시간 전에 예약된 새로 고침을 시작할 수 없으면 실패합니다.A scheduled refresh will fail when it cannot commence before the next scheduled refresh is due to commence. UI에서 수동으로 트리거된 주문형 새로 고침은 실패하기까지 최대 3번 실행을 시도합니다.An on-demand refresh triggered manually from the UI will attempt to run up to three times before failing.

용량 관리자(및 Power BI 서비스 관리자)는 평균 새로 고침 대기 시간(분) 메트릭을 모니터링하여 예약된 시간과 작업 시작 사이의 평균 지연을 확인할 수 있습니다.Capacity Admins (and Power BI service administrators) can monitor the Average Refresh Wait Time (minutes) metric to determine average lag between the scheduled time and the start of the operation.

일반적으로 관리 우선 순위는 아니지만, 정시 데이터 새로 고침을 위해 충분한 메모리를 사용할 수 있도록 합니다.While not usually an administrative priority, to influence on-time data refreshes, ensure that sufficient memory is available. 여 목적을 위해 데이터 세트를 알려진 충분한 리소스가 있는 용량으로 격리할 수도 있습니다.This may involve isolating datasets to capacities with known sufficient resources. 또한 관리자가 데이터 세트 소유자와 협력하여 충돌을 최소화하기 위해 예약된 데이터 새로 고침 시간을 겹치지 않도록 조정하거나 줄일 수 있습니다.It's also possible that admins could coordinate with dataset owners to help stagger or reduce scheduled data refresh times to minimize collisions. 관리자가 새로 고침 큐를 보거나 데이터 세트 일정을 검색할 수는 없습니다.Note that it's not possible for an administrator to view the refresh queue, or to retrieve dataset schedules.

새로 고침이 느린 이유는 무엇인가요?Why are refreshes slow?

이전의 일반적인 질문처럼 새로 고침은 느리거나 느리게 인식될 수 있습니다.Refreshes can be slow - or perceived to be slow (as the previous common question addresses).

새로 고침이 실제로 느린 경우 다음과 같은 몇 가지 이유 때문일 수 있습니다.When the refresh is in fact slow, it can be due to several reasons:

  • CPU 부족(새로 고침은 CPU를 많이 사용할 수 있음)Insufficient CPU (refresh can be very CPU-intensive).
  • 메모리가 부족하여 새로 고침이 일시 중지됨(이 경우 조건이 개선되어 다시 시작할 수 있을 때 새로 고침을 처음부터 시작해야 함)Insufficient memory, resulting in refresh pausing (which requires the refresh to start over when conditions are favorable to recommence).
  • 데이터 원본 시스템 응답성, 네트워크 대기 시간, 잘못된 사용 권한 또는 게이트웨이 처리량을 포함하는 용량 이외의 이유Non-capacity reasons, including datasource system responsiveness, network latency, invalid permissions or gateway throughput.
  • 데이터 볼륨 - 아래에 설명된 대로 증분 새로 고침을 구성하는 것이 좋음Data volume - a good reason to configure incremental refresh, as discussed below.

용량 관리자(및 Power BI 서비스 관리자)는 평균 새로 고침 기간(분) 메트릭을 모니터링하여 시간별 비교를 위한 벤치마크를 확인하고, 평균 새로 고침 대기 시간(분) 메트릭을 모니터링하여 예약된 시간과 작업 시작 사이의 평균 지연을 확인할 수 있습니다.Capacity Admins (and Power BI service administrators) can monitor the Average Refresh Duration (minutes) metric to determine a benchmark for comparison over time, and the Average Refresh Wait Time (minutes) metrics to determine average lag between average lag between the scheduled time and the start of the operation.

증분 새로 고침은 특히 큰 모델 테이블의 데이터 새로 고침 기간을 크게 줄일 수 있습니다.Incremental refresh can significantly reduce data refresh duration, especially for large model tables. 증분 새로 고침과 관련된 네 가지 혜택은 다음과 같습니다.There are four benefits associated with incremental refresh:

  • 새로 고침이 더 빠르게 수행됨 - 테이블 하위 집합만 로드하면 되기 때문에 CPU 및 메모리 사용량이 줄어들고, 여러 파티션을 새로 고치는 경우 병렬 처리 수준이 더 높을 수 있습니다.Refreshes are faster - Only a subset of a table needs loading, reducing CPU and memory usage, and parallelism can be higher when refreshing multiple partitions.
  • 필요한 경우에만 새로 고침이 발생함 - 데이터가 변경된 경우에만 로드되도록 증분 새로 고침 정책을 구성할 수 있습니다.Refreshes occur only when required - Incremental refresh policies can be configured to load only when data has changed.
  • 새로 고침이 더 안정적임 - 휘발성 데이터 원본 시스템에 대한 연결 실행이 짧아지면서 연결이 끊어질 위험이 줄어듭니다.Refreshes are more reliable - Shorter running connections to volatile datasource systems are less susceptible to disconnection.
  • 모델이 잘린 상태로 유지됨 - 시간 슬라이딩 윈도우가 지나면 기록을 자동으로 제거하도록 증분 새로 고침 정책을 구성할 수 있습니다.Models remain trim - Incremental refresh policies can be configured to automatically remove history beyond a sliding window of time.

자세한 내용은 Power BI Premium의 증분 새로 고침을 참조하세요.To learn more, see Incremental refresh in Power BI Premium.

데이터 새로 고침이 완료되지 않는 이유는 무엇인가요?Why are data refreshes not completing?

데이터 새로 고침이 시작되지만 완료되지 않는 경우 다음과 같은 몇 가지 이유 때문일 수 있습니다.When the data refresh commences but fails to complete, it can be due to several reasons:

  • 프리미엄 용량에 모델이 하나뿐인 경우에도 메모리가 부족합니다. 즉, 모델 크기가 매우 큽니다.Insufficient memory, even if there is only one model in the Premium capacity, i.e. the model size is very large.
  • 데이터 원본 시스템 연결 끊김, 잘못된 사용 권한 또는 게이트웨이 오류를 포함하는 용량 이외의 이유Non-capacity reasons, including datasource system disconnection, invalid permissions or gateway error.

용량 관리자(및 Power BI 서비스 관리자)는 메모리 부족으로 인한 새로 고침 실패 메트릭을 모니터링할 수 있습니다.Capacity Admins (and Power BI service administrators) can monitor the Refresh Failures due to out of Memory metric.

모델 최적화Optimizing models

최적의 모델 디자인은 효율적이고 확장 가능한 솔루션을 제공하는 데 매우 중요합니다.Optimal model design is crucial to delivering an efficient and scalable solution. 그러나 자세한 설명은 이 문서의 범위를 벗어납니다.However, it's beyond the scope of this article to provide a complete discussion. 대신, 이 섹션에서는 모델을 최적화할 때 고려해야 할 주요 영역을 살펴보겠습니다.Instead, this section will provide key areas for consideration when optimizing models.

Power BI 호스트된 모델 최적화Optimizing Power BI hosted models

프리미엄 용량에 호스트된 모델 최적화는 데이터 원본 및 모델 계층에서 수행할 수 있습니다.Optimizing models hosted in a Premium capacity can be achieved at the datasource(s) and model layers.

가져오기 모델의 최적화 가능성을 고려합니다.Consider the optimization possibilities for an Import model:

가져오기 모델의 최적화 가능성

데이터 원본 계층:At the datasource layer:

  • 관계형 데이터 원본을 최적화하면 데이터 미리 통합, 적절한 인덱스 적용, 증분 새로 고침 기간에 맞는 테이블 파티션 정의 및 계산 모델 테이블과 열 대신 계산 구체화 또는 뷰에 계산 논리 추가를 통해 가능한 가장 빠른 새로 고침을 보장할 수 있습니다.Relational data sources can be optimized to ensure the fastest possible refresh by pre-integrating data, applying appropriate indexes, defining table partitions that align to incremental refresh periods, and materializing calculations (in place of calculated model tables and columns) or adding calculation logic to views.
  • 비관계형 데이터 원본을 관계형 저장소와 미리 통합할 수 있습니다.Non-relational data sources can be pre-integrated with relational stores.
  • 게이트웨이가 가급적 전용 머신에서 충분한 리소스를 사용할 수 있고 네트워크 대역폭이 충분하며 데이터 원본에 근접한 곳에 있는지 확인합니다.Ensure that gateways have enough resources, preferably on dedicated machines, with sufficient network bandwidth and in close proximity to the data sources.

모델 계층:At the model layer:

  • 파워 쿼리의 쿼리 디자인은 복잡한 변환과 특히 여러 데이터 원본을 병합하는 변환을 최소화하거나 제거할 수 있습니다(데이터 웨어하우스는 추출-변환-로드 단계를 통해 이 작업을 수행함).Power Query query designs can minimize or remove complex transformations and especially those that merge different data sources (data warehouses achieve this during their Extract-Transform-Load stage). 또한 적절한 데이터 원본 개인 정보 수준이 설정되었는지 확인하여 Power BI에서 쿼리 간의 결합된 결과를 생성하기 위해 전체 결과를 로드해야 하는 경우를 방지할 수 있습니다.Also, ensuring that appropriate datasource privacy levels are set, this can avoid requiring Power BI to load full results to produce a combined result across queries.
  • 모델 구조는 로드할 데이터를 결정하며 모델 크기에 직접적인 영향을 줍니다.The model structure determines the data to load and has a direct impact on the model size. 열을 제거하거나, 행(특히 기록 데이터)을 제거하거나, 자세한 데이터를 로드하는 대신 요약 데이터를 로드하여 불필요한 데이터 로드를 방지하도록 디자인할 수 있습니다.It can be designed to avoid loading unnecessary data by removing columns, removing rows (especially historic data) or by loading summarized data (at the expense of loading detailed data). 매우 효율적으로 저장하거나 압축하지 않는 높은 카디널리티 열(특히 텍스트 열)을 제거하면 크기를 대폭 줄일 수 있습니다.Dramatic size reduction can be achieved by removing high cardinality columns (especially text columns) which do not store or compress very efficiently.
  • 양방향 필터링을 허용해야 하는 타당한 이유가 없을 경우 단방향 관계를 구성하면 모델 쿼리 성능을 향상할 수 있습니다.Model query performance can be improved by configuring single direction relationships unless there is a compelling reason to allow bi-directional filtering. 양방향 필터링 대신 CROSSFILTER 함수를 사용할 수도 있습니다.Consider also using the CROSSFILTER function instead of bi-directional filtering.
  • 집계 테이블은 미리 요약된 데이터를 로드하여 빠른 쿼리 응답을 구현할 수 있지만, 이로 인해 모델 크기가 증가하고 새로 고침 시간이 길어집니다.Aggregation tables can achieve fast query responses by loading pre-summarized data, however this will increase the size of the model and result in longer refresh times. 일반적으로 집계 테이블은 매우 큰 모델이나 복합 모델 디자인에만 사용해야 합니다.Generally, aggregation tables should be reserved for very large models or Composite model designs.
  • 계산 테이블 및 열을 사용하면 모델 크기가 증가하고 새로 고침 시간이 길어집니다.Calculated tables and columns increase the model size and result in longer refresh times. 일반적으로 데이터 원본의 데이터가 구체화되었거나 계산된 경우 더 작은 스토리지 크기와 빠른 새로 고침 시간을 얻을 수 있습니다.Generally, a smaller storage size and faster refresh time can be achieved when the data is materialized or calculated in the datasource. 이 조건이 불가능하면, 파워 쿼리 사용자 지정 열을 사용하여 향상된 스토리지 압축을 제공할 수 있습니다.If this is not possible, using Power Query custom columns can offer improved storage compression.
  • 측정값과 RLS 규칙의 DAX 식을 조정할 수 있습니다. 예를 들어 논리를 다시 작성하여 비용이 많이 드는 수식을 방지할 수 있습니다.There may be opportunity to tune DAX expressions for measures and RLS rules, perhaps rewriting logic to avoid expensive formulas
  • 증분 새로 고침은 새로 고침 시간을 대폭 줄이고 메모리와 CPU를 절약할 수 있습니다.Incremental refresh can dramatically reduce refresh time and conserve memory and CPU. 또한 기록 데이터를 제거하여 모델 크기 자르기를 유지하도록 증분 새로 고침을 구성할 수 있습니다.The incremental refresh can also be configured to remove historic data keeping model sizes trim.
  • 서로 다르고 충돌하는 쿼리 패턴이 있는 경우 모델을 두 개의 모델로 다시 디자인할 수 있습니다.A model could be redesigned as two models when there are different and conflicting query patterns. 예를 들어 일부 보고서는 모든 기록의 개략적인 집계를 제공하며, 24시간의 대기 시간을 허용할 수 있습니다.For example, some reports present high-level aggregates over all history, and can tolerate 24 hours' latency. 다른 보고서는 오늘 데이터가 중요하며 개별 트랜잭션에 대한 세분화된 액세스가 필요합니다.Other reports are concerned with today's data and need granular access to individual transactions. 모든 보고서를 충족하는 단일 모델을 디자인하는 대신 각 요구 사항에 최적화된 두 개의 모델을 만듭니다.Rather than design a single model to satisfy all reports, create two models optimized for each requirement.

DirectQuery 모델의 최적화 가능성을 고려합니다.Consider the optimization possibilities for a DirectQuery model. 모델은 기본 데이터 원본에 쿼리 요청을 실행하므로 응답성이 뛰어난 모델 쿼리를 제공하려면 데이터 원본 최적화가 중요합니다.As the model issues query requests to the underlying datasource, datasource optimization is critical to delivering responsive model queries.

DirectQuery 모델의 최적화 가능성

데이터 원본 계층:At the datasource layer:

  • 데이터 원본을 최적화하면 데이터 미리 통합(모델 계층에서는 불가능함), 적절한 인덱스 적용, 테이블 파티션 정의, 요약 데이터 구체화(인덱싱된 뷰 포함), 계산 양 최소화를 통해 가능한 가장 빠른 쿼리를 보장할 수 있습니다.The datasource can be optimized to ensure the fastest possible querying by pre-integrating data (which is not possible at the model layer), applying appropriate indexes, defining table partitions, materializing summarized data (with indexed views), and minimizing the amount of calculation. 통과 쿼리에 필터만 필요하고 인덱싱된 테이블 또는 뷰 간에 내부 조인을 수행하는 경우 최상의 경험을 얻을 수 있습니다.The best experience is achieved when pass-through queries need only filter and perform inner joins between indexed tables or views.
  • 게이트웨이가 가급적 전용 머신에서 충분한 리소스를 사용할 수 있고 네트워크 대역폭이 충분하며 데이터 원본에 근접한 곳에 있는지 확인합니다.Ensure that gateways have enough resources, preferably on dedicated machines, with sufficient network bandwidth and in close proximity to the datasource.

모델 계층:At the model layer:

  • 파워 쿼리의 쿼리 디자인에서 변환을 적용하지 않는 것이 좋습니다. 또는 변환을 최소한으로 유지합니다.Power Query query designs should preferably apply no transformations - otherwise attempt to keep transformations to an absolute minimum.
  • 양방향 필터링을 허용해야 하는 타당한 이유가 없을 경우 단방향 관계를 구성하면 모델 쿼리 성능을 향상할 수 있습니다.Model query performance can be improved by configuring single direction relationships unless there is a compelling reason to allow bi-directional filtering. 또한 해당하는 경우 참조 무결성이 적용된다고 가정하도록 모델 관계를 구성해야 하며, 외부 조인 대신 더 효율적인 내부 조인을 사용하는 데이터 원본 쿼리가 생성됩니다.Also, model relationships should be configured to assume referential integrity is enforced (when this is the case) and will result in datasource queries using more efficient inner joins (instead of outer joins).
  • 파워 쿼리의 쿼리 사용자 지정 열 또는 모델 계산 열을 생성하지 않습니다. 가능한 경우 데이터 원본에서 이러한 열을 구체화합니다.Avoid creating Power Query query custom columns or model calculated column - materialize these in the datasource, when possible.
  • 측정값과 RLS 규칙의 DAX 식을 조정할 수 있습니다. 예를 들어 논리를 다시 작성하여 비용이 많이 드는 수식을 방지할 수 있습니다.There may be opportunity to tune DAX expressions for measures and RLS rules, perhaps rewriting logic to avoid expensive formulas.

복합 모델의 최적화 가능성을 고려합니다.Consider the optimization possibilities for a Composite model. 복합 모델에서는 가져오기 및 DirectQuery 테이블을 함께 사용할 수 있습니다.Recall that a Composite model enables a mix of import and DirectQuery tables.

복합 모델의 최적화 가능성

  • 일반적으로 가져오기 및 DirectQuery 모델의 최적화는 이러한 스토리지 모드를 사용하는 복합 모델 테이블에도 적용됩니다.Generally, the optimization for Import and DirectQuery models apply to Composite model tables that use these storage modes.
  • 대체로, 차원 유형 테이블(비즈니스 엔터티를 나타냄)을 이중 스토리지 모드로 구성하고, 팩트 유형 테이블(종종 작업 팩트를 나타내는 큰 테이블)을 DirectQuery 스토리지 모드로 구성하여 균형 있는 디자인을 구현합니다.Typically, strive to achieve a balanced design by configuring dimension-type tables (representing business entities) as Dual storage mode and fact-type tables (often large tables, representing operational facts) as DirectQuery storage mode. 이중 스토리지 모드는 가져오기 및 DirectQuery 스토리지 모드를 모두 의미하며,이 모드에서는 Power BI 서비스가 통과를 위해 네이티브 쿼리를 생성할 때 사용할 가장 효율적인 스토리지 모드를 결정할 수 있습니다.Dual storage mode means both Import and DirectQuery storage modes, and this allows the Power BI service to determine the most efficient storage mode to use when generating a native query for pass-through.
  • 게이트웨이가 가급적 전용 머신에서 충분한 리소스를 사용할 수 있고 네트워크 대역폭이 충분하며 데이터 원본에 근접한 곳에 있는지 확인합니다.Ensure that gateways have enough resources, preferably on dedicated machines, with sufficient network bandwidth and in close proximity to the data sources
  • 가져오기 스토리지 모드로 구성된 집계 테이블은 DirectQuery 스토리지 모드 팩트 유형 테이블을 요약하는 데 사용될 때 뛰어난 쿼리 성능 향상을 제공할 수 있습니다.Aggregations tables configured as Import storage mode can deliver dramatic query performance enhancements when used to summarize DirectQuery storage mode fact-type tables. 이 경우 집계 테이블로 인해 모델 크기가 증가하고 새로 고침 시간이 길어지지만 빠른 쿼리를 위한 댓가로 허용되는 경우가 많습니다.In this case, aggregation tables will increase the size of the model and increase refresh time, and often this is an acceptable tradeoff for faster queries.

외부에 호스트된 모델 최적화Optimizing externally hosted models

Power BI 호스트된 모델 최적화 섹션에서 설명한 대부분의 최적화 가능성이 Azure Analysis Services 및 SQL Server Analysis Services를 사용하여 개발된 모델에도 적용됩니다.Many optimization possibilities discussed in the Optimizing Power BI hosted models section apply also to models developed with Azure Analysis Services and SQL Server Analysis Services. 명백한 예외는 복합 모델과 집계 테이블을 포함하여 현재 지원되지 않는 특정 기능입니다.Clear exceptions are certain features which are not currently supported, including Composite models and aggregation tables.

외부에 호스트된 데이터 세트와 관련해서 추가로 고려할 사항은 Power BI 서비스와 관련된 데이터베이스 호스팅입니다.An additional consideration for externally-hosted datasets is the database hosting in relation to the Power BI service. Azure Analysis Services의 경우 Power BI 테넌트(홈 지역)와 동일한 지역에 Azure 리소스를 만들어야 함을 의미합니다.For Azure Analysis Services, this means creating the Azure resource in the same region as the Power BI tenant (home region). SQL Server Analysis Services에서 IaaS의 경우 동일한 지역에 VM을 호스트해야 함을 의미하고, 온-프레미스의 경우 효율적인 게이트웨이 설정을 의미합니다.For SQL Server Analysis Services, for IaaS, this means hosting the VM in the same region, and for on-premises, it means ensuring an efficient gateway setup.

그 밖에도 Azure Analysis Services 데이터베이스와 SQL Server Analysis Services 테이블 형식 데이터베이스를 사용하려면 해당 모델이 메모리에 완전히 로드되어야 하고, 쿼리를 지원하기 위해 항상 메모리에 유지되어야 한다는 점에 유의합니다.As an aside, it may be of interest to note that Azure Analysis Services databases and SQL Server Analysis Services tabular databases require that their models be loaded fully into memory and that they remain there at all times to support querying. Power BI 서비스와 마찬가지로 새로 고치는 동안 모델이 온라인 상태로 유지되어야 하는 경우 새로 고침을 위한 충분한 메모리가 필요합니다.Like the Power BI service, there needs to be sufficient memory for refreshing if the model must remain online during the refresh. Power BI 서비스와 달리 모델이 사용량에 따라 메모리 내부 및 외부에서 자동으로 에이징되는 개념이 없습니다.Unlike the Power BI service, there is no concept that models are automatically aged in and out of memory according to usage. 따라서 Power BI Premium을 사용하면 낮은 메모리 사용량으로 모델 쿼리를 보다 효율적으로 최대화할 수 있습니다.Power BI Premium, therefore, offers a more efficient approach to maximize model querying with lower memory usage.

용량 계획Capacity planning

프리미엄 용량 크기에 따라 사용 가능한 메모리 및 프로세서 리소스와 용량에 적용되는 한도가 결정됩니다.The size of a Premium capacity determines its available memory and processor resources and limits imposed on the capacity. 여러 개의 프리미엄 용량을 만들면 워크로드를 서로 격리하는 데 도움이 될 수 있으므로 프리미엄 용량 수도 고려해야 합니다.The number of Premium capacities is also a consideration, as creating multiple Premium capacities can help isolate workloads from each other. 스토리지는 용량 노드당 100TB이며, 모든 워크로드에 충분한 수준 이상일 것입니다.Note that storage is 100 TB per capacity node, and this is likely to be more than sufficient for any workload.

특히 만드는 초기 용량과 관련해서 프리미엄 용량 크기와 개수를 결정하는 것은 어려울 수 있습니다.Determining the size and number of Premium capacities can be challenging, especially for the initial capacities you create. 용량 크기를 조정할 때 첫 번째 단계는 예상 일일 사용량을 나타내는 평균 워크로드를 파악하는 것입니다.The first step when capacity sizing is to understand the average workload representing expected day-to-day usage. 모든 워크로드가 동일하지는 않는다는 것을 이해해야 합니다.It's important to understand that not all workloads are equal. 예를 들어 한쪽 극단에서는 단일 시각적 개체를 포함하는 단일 보고서 페이지에 액세스하는 동시 사용자 100명은 쉽게 지원할 수 있습니다.For example - at one end of a spectrum - 100 concurrent users accessing a single report page that contains a single visual is easily achievable. 하지만 반대쪽 극단에서는 각각 보고서 페이지에 시각적 개체 100개를 포함하는 서로 다른 보고서 100개에 액세스하는 동시 사용자 100명을 지원하기 위해 막대한 용량 리소스가 필요합니다.Yet - at the other end of the spectrum - 100 concurrent users accessing 100 different reports, each with 100 visuals on the report page, is going to make very different demands of capacity resources.

따라서 용량 관리자는 환경, 콘텐츠 및 예상 사용량과 관련하여 여러 가지 요인을 고려해야 합니다.Capacity Admins will therefore need to consider many factors specific to your environment, content and expected usage. 재정의 목표는 일관성 있는 쿼리 시간, 허용되는 대기 시간 및 제거 비율을 제공하면서 용량 사용률을 최대화하는 것입니다.The overriding objective is to maximize capacity utilization while delivering consistent query times, acceptable wait times, and eviction rates. 고려해야 할 요인은 다음과 같습니다.Factors for consideration can include:

  • 모델 크기 및 데이터 특성 - 쿼리 또는 새로 고침을 허용하려면 가져오기 모델을 메모리에 완전히 로드해야 합니다.Model size and data characteristics - Import models must be fully loaded into memory to allow querying or refreshing. LC/DQ 데이터 세트는 복잡한 측정값 또는 RLS 규칙을 평가하는 데 상당한 프로세서 시간과 많은 메모리가 필요할 수 있습니다.LC/DQ datasets can require significant processor time and possibly significant memory to evaluate complex measures or RLS rules. 메모리 및 프로세서 크기와 LC/DQ 쿼리 처리량은 용량 크기로 제한됩니다.Memory and processor size, and LC/DQ query throughput are constrained by the capacity size.
  • 동시 활성 모델 - 여러 가져오기 모델의 동시 쿼리는 메모리에 유지될 때 최상의 응답성과 성능을 제공합니다.Concurrent active models - The concurrent querying of different import models will deliver best responsiveness and performance when they remain in memory. 자주 쿼리되는 모든 모델을 호스트하는 데 충분한 메모리와 새로 고침에 사용할 추가 메모리가 있어야 합니다.There should be sufficient memory to host all heavily-queried models, with additional memory to allow for their refresh.
  • 가져오기 모델 새로 고침 - 계산 테이블/열 논리와 파워 쿼리의 쿼리 새로 고침 유형(전체 또는 증분), 기간 및 복잡성은 메모리 및 특히 프로세서 사용량에 영향을 줄 수 있습니다.Import model refresh - The refresh type (full or incremental), duration and complexity of Power Query queries and calculated table/column logic can impact on memory and especially processor usage. 동시 새로 고침은 용량 크기(1.5 x 백 엔드 v 코어 수, 올림)로 제한됩니다.Concurrent refreshes are constrained by the capacity size (1.5 x backend v-cores, rounded up).
  • 동시 쿼리 - 많은 동시 쿼리로 인해 프로세서 또는 LC/DQ 연결이 용량 한도를 초과할 경우 응답하지 않는 보고서가 발생할 수 있습니다.Concurrent queries - Many concurrent queries can result in unresponsive reports when processor or LC/DQ connections exceeds the capacity limit. 이 문제는 특히 많은 시각적 개체를 포함하는 보고서 페이지에서 발생합니다.This is especially the case for report pages that include many visuals.
  • 데이터 흐름 및 페이지를 매긴 보고서 - 각각 구성 가능한 최대 백분율의 용량 메모리를 요구하는 데이터 흐름 및 페이지를 매긴 보고서를 지원하도록 용량을 구성할 수 있습니다.Dataflows and paginated reports - The capacity can be configured to support dataflows and paginated reports, with each requiring a configurable maximum percentage of capacity memory. 메모리는 데이터 흐름에는 동적으로 할당되지만 페이지를 매긴 보고서에는 정적으로 할당됩니다.Memory is dynamically allocated to dataflows, but is statically allocated to paginated reports.

용량 관리자는 이러한 요인 외에도 여러 개의 용량 생성을 고려할 수 있습니다.In addition to these factors, Capacity Admins can consider creating multiple capacities. 여러 개의 용량을 사용하면 워크로드를 격리할 수 있으며, 우선 순위 워크로드에 리소스가 보장되도록 구성할 수 있습니다.Multiple capacities allow for the isolation of workloads and can be configured to ensure priority workloads have guaranteed resources. 예를 들어 두 개의 용량을 만들어 중요 비즈니스용 워크로드와 SSBI(셀프 서비스 BI) 워크로드를 구분할 수 있습니다.For example, two capacities can be created to separate business-critical workloads from self-service BI (SSBI) workloads. 중요 비즈니스용 용량은 큰 회사 모델을 격리하여 보장된 리소스를 제공하고 IT 부서에만 작성 권한을 부여하는 데 사용할 수 있습니다.The business-critical capacity can be used to isolate large corporate models providing them with guaranteed resources, with authoring access granted only to the IT department. SSBI 용량은 증가하는 개수의 작은 모델을 호스트하고 비즈니스 분석가에게 액세스 권한을 부여하는 데 사용할 수 있습니다.The SSBI capacity can be used to host a growing number of smaller models, with access granted to business analysts. SSBI 용량에서는 때때로 허용되는 수준의 쿼리 또는 새로 고침 대기가 발생할 수 있습니다.The SSBI capacity may at times experience query or refresh waits that are tolerable.

시간이 지남에 따라 용량 관리자는 작업 영역 간에 콘텐츠를 이동하거나 용량 간에 작업 영역을 이동하고 용량을 확장 또는 축소하여 용량의 작업 영역 균형을 맞출 수 있습니다.Over time, Capacity Admins can balance workspaces across capacities by moving content between workspaces, or workspaces between capacities, and by scaling capacities up or down. 일반적으로 대규모 모델을 호스트하려면 강화하고, 동시성을 높이려면 확장합니다.Generally, to host larger models you scale-up and for higher concurrency you scale out.

라이선스를 구매하면 테넌트에 v 코어가 제공됩니다.Recall that purchasing a license provides the tenant with v-cores. P3 구독을 구매하면 프리미엄 용량 1~4개(즉, 1 x P3, 2 x P2 또는 4 x P1)를 만들 수 있습니다.The purchase of a P3 subscription can be used to create one, or up to four Premium capacities, i.e. 1 x P3, or 2 x P2, or 4 x P1. 또한 P2 용량을 P3 용량으로 업사이징하기 전에 v 코어를 분할하여 두 개의 P1 용량을 만드는 것이 좋습니다.Also, before upsizing a P2 capacity to a P3 capacity, consideration can be given to splitting the v-cores to create two P1 capacities.

테스트 방법Testing approaches

용량 크기를 결정한 후 제어된 환경을 만들어 테스트할 수 있습니다.Once a capacity size is decided, testing can be performed by creating a controlled environment. 실용적이고 경제적인 옵션은 Azure(A SKU) 용량을 만들어 P1 용량이 A4 용량과 동일한 크기이고, P2 및 P3 용량이 각각 A5 및 A6 용량과 동일한 크기인지 확인하는 것입니다.A practical and economic option is to create an Azure (A SKUs) capacity, noting that a P1 capacity is the same size as an A4 capacity, with the P2 and P3 capacities the same size as the A5 and A6 capacities, respectively. Azure 용량은 빠르게 만들 수 있으며 시간 단위로 요금이 청구됩니다.Azure capacities can be created quickly and are billed on an hourly basis. 따라서 테스트가 완료되면 비용 발생을 중지하기 위해 쉽게 삭제할 수 있습니다.So, once testing is complete, they can be easily deleted to stop accruing costs.

Azure 용량에 생성된 작업 영역에 테스트 콘텐츠를 추가하고, 단일 사용자로 보고서를 실행하여 현실적인 대표 쿼리 워크로드를 생성할 수 있습니다.The test content can be added to the workspaces created on the Azure capacity, and then as a single user can run reports to generate a realistic and representative workload of queries. 가져오기 모델이 있는 경우 각 모델의 새로 고침도 수행해야 합니다.If there are import models, a refresh for each model should be performed also. 그런 다음, 모니터링 도구를 통해 모든 메트릭을 검토하여 리소스 사용률을 파악할 수 있습니다.Monitoring tools can then be used to review all metrics to understand resource utilization.

테스트는 반복 가능해야 합니다.It's important that the tests are repeatable. 테스트를 여러 번 실행해야 하며, 매번 거의 동일한 결과를 제공해야 합니다.Tests should be run several times and they should deliver approximately the same result each time. 이러한 결과의 평균을 사용하여 실제 프로덕션 조건에서의 워크로드를 추정하고 예측할 수 있습니다.An average of these results can be used to extrapolate and estimate a workload under true production conditions.

부하 테스트를 수행하려는 보고서와 용량이 이미 있는 경우 PowerShell 부하 생성 도구를 사용하여 부하 테스트를 빠르게 생성합니다.If you already have a capacity and the reports you want to load test for, use the PowerShell load generating tool to quickly generate a load test. 이 도구를 사용하면 용량에서 시간당 실행할 수 있는 각 보고서의 인스턴스 수를 예측할 수 있습니다.The tool enables you to estimate how many instances of each report your capacity can run in an hour. 이 도구를 사용하여 용량의 개별 보고서 렌더링 기능이나 여러 다른 보고서의 병렬 렌더링 기능을 평가할 수 있습니다.You can use the tool to evaluate your capacity's ability for individual report rendering or for rendering several different reports in parallel. 자세한 내용은 Microsoft Power BI: 프리미엄 용량 동영상을 참조하세요.For more information, see the video Microsoft Power BI: Premium capacity.

더 복잡한 테스트를 생성하려면 실제 워크로드를 시뮬레이트하는 부하 테스트 애플리케이션을 개발하는 것이 좋습니다.To generate a more complex test, consider developing a load testing application that simulates a realistic workload. 자세한 내용은 웨비나 Load Testing Power BI Applications with Visual Studio Load Test(Visual Studio 부하 테스트를 사용하여 Power BI 애플리케이션 부하 테스트)를 참조하세요.For more information, see the webinar Load Testing Power BI Applications with Visual Studio Load Test.

승인Acknowledgements

이 문서는 데이터 플랫폼 MVP이자 Bitwise Solutions의 독립 BI 전문가인 Peter Myers가 작성한 것입니다.This article was written by Peter Myers, Data Platform MVP and independent BI expert with Bitwise Solutions.

다음 단계Next steps

궁금한 점이 더 있나요?More questions? Power BI 커뮤니티에 질문합니다.Try asking the Power BI Community