Amazon Redshift는 패치 198부터 새 Python UDF 생성을 더 이상 지원하지 않습니다. 기존 Python UDF는 2026년 6월 30일까지 계속 작동합니다. 자세한 내용은 [블로그 게시물](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)을 참조하세요.

# 워크로드 관리
<a name="cm-c-implementing-workload-management"></a>

자동 WLM 또는 수동 WLM으로 실행되도록 Amazon Redshift WLM을 구성할 수 있습니다.

Amazon Redshift를 사용하면 동시 쿼리 및 사용자 워크로드를 관리하고 우선순위를 지정하여 성능 및 리소스 사용률을 최적화할 수 있습니다. 워크로드 관리(WLM)를 사용하면 대기열, 사용자 그룹 및 기타 구문을 정의하여 다양한 유형의 쿼리 또는 사용자에게 할당된 리소스를 제어할 수 있습니다.

다음 섹션에서는 Amazon Redshift의 특정 워크로드 관리 기능을 간략하게 설명하고 구성 및 모니터링에 대해 알아봅니다.

**자동 WLM**

시스템 처리량을 극대화하고 리소스를 효율적으로 사용하려면 Amazon Redshift가 자동 WLM을 통해 동시 쿼리를 실행하기 위해 리소스를 나누는 방법을 관리하게 할 수 있습니다. *자동 WLM*는 쿼리를 실행하는 데 필요한 리소스를 관리합니다. Amazon Redshift는 동시에 실행되는 쿼리의 수와 디스패치된 각 쿼리에 할당되는 메모리의 양을 결정합니다. 동시 쿼리를 실행하기 위해 리소스가 분할되는 방식을 Amazon Redshift가 관리하도록 하려면 자동 WLM을 사용하세요. 자세한 내용은 [자동 WLM 구현](automatic-wlm.md) 섹션을 참조하세요.

 

동시성 확장과 자동 WLM을 사용하면 일관되게 빠른 쿼리 성능으로 동시 사용자 및 동시 쿼리를 사실상 무제한 지원할 수 있습니다. 자세한 내용은 [동시성 확장](concurrency-scaling.md) 섹션을 참조하세요.

**참고**  
대부분의 경우 자동 WLM을 사용하는 것이 좋습니다. 수동 WLM을 사용 중이고 자동 WLM으로 마이그레이션하려는 경우 [수동 WLM에서 자동 WLM으로 마이그레이션](#wlm-manual-to-automatic) 섹션을 참조하세요.

자동 WLM을 사용하면 대기열에 있는 워크로드의 쿼리 우선 순위를 정의할 수 있습니다. 쿼리 우선 순위에 대한 자세한 내용은 [쿼리 우선 순위](query-priority.md) 섹션을 참조하세요.

**수동 WLM**

다수의 세션 또는 사용자가 동시에 쿼리를 실행할 수도 있습니다. 일부 쿼리는 장기간 클러스터 리소스를 소모하여 다른 쿼리의 성능에 영향을 미칠 수 있습니다. 특수한 사용 사례의 경우 수동 WLM을 통해 이를 관리할 수 있습니다. 동시성을 보다 세밀하게 제어하려면 수동 WLM을 사용하세요.

장기 실행 쿼리와 단기 실행 쿼리를 위한 별도의 대기열을 만들도록 WLM 구성을 수정하여 시스템 성능을 관리할 수 있습니다. 실행 시간에 쿼리를 사용자 그룹 또는 쿼리 그룹에 따라 이 대기열로 라우팅할 수 있습니다.

쿼리를 특정 대기열로 라우팅하는 규칙은 쿼리를 실행하는 사용자나 지정하는 레이블을 기준으로 설정할 수 있습니다. 또한 각 대기열에 할당되는 메모리 크기도 구성이 가능합니다. 따라서 대용량 쿼리를 실행하는 대기열에는 다른 대기열보다 많은 메모리를 할당하는 것이 좋습니다. 장기 실행 쿼리를 제한하기 위해 QMR(쿼리 모니터링 규칙)을 구성할 수도 있습니다. 자세한 내용은 [수동 WLM 구현](cm-c-defining-query-queues.md) 섹션을 참조하세요.

**참고**  
총 15개 이하의 쿼리 슬롯이 있는 수동 WLM 쿼리 대기열을 구성하는 것이 좋습니다. 자세한 내용은 [동시성 레벨](cm-c-defining-query-queues.md#cm-c-defining-query-queues-concurrency-level) 섹션을 참조하세요.

수동 WLM 구성과 관련하여 대기열에 할당할 수 있는 최대 슬롯은 50개라는 점에 유의하세요. 그러나 이는 자동 WLM 구성에서 Amazon Redshift 클러스터가 항상 50개의 쿼리를 동시에 실행한다는 의미는 아닙니다. 이는 클러스터의 메모리 요구 사항이나 기타 유형의 리소스 할당에 따라 변경될 수 있습니다.

**Topics**
+ [WLM 모드 전환](#cm-c-switching-mode)
+ [WLM 구성 수정](#cm-c-modifying-wlm-configuration)
+ [자동 WLM 구현](automatic-wlm.md)
+ [수동 WLM 구현](cm-c-defining-query-queues.md)
+ [동시성 확장](concurrency-scaling.md)
+ [단기 쿼리 가속화](wlm-short-query-acceleration.md)
+ [WLM 대기열 할당 규칙](cm-c-wlm-queue-assignment-rules.md)
+ [대기열에 쿼리 할당](cm-c-executing-queries.md)
+ [WLM 동적 및 정적 구성 속성](cm-c-wlm-dynamic-properties.md)
+ [WLM 쿼리 모니터링 규칙](cm-c-wlm-query-monitoring-rules.md)
+ [WLM 시스템 테이블 및 뷰](cm-c-wlm-system-tables-and-views.md)

## WLM 모드 전환
<a name="cm-c-switching-mode"></a>

Amazon Redshift 콘솔을 사용하여 자동 또는 수동 WLM을 활성화할 수 있습니다.

1. **Switch WLM mode(WLM 모드 전환)**를 선택합니다.

1. 자동 WLM으로 설정하려면 **자동 WLM**을 선택합니다. 그러면 최대 8개의 대기열이 쿼리를 관리하는 데 사용되고, **메모리** 및 **Concurrency on main(기본의 동시성)** 필드가 모두 **Auto(자동)**로 설정됩니다. 또한 쿼리의 기본 우선 순위는 **정상**으로 설정됩니다.

1. Amazon Redshift 콘솔을 사용하여 수동 구성을 사용하려면 **수동 WLM**으로 전환합니다. 그런 다음 쿼리를 관리하는 데 사용되는 대기열과, **Memory(메모리)** 및 **Concurrency on main(기본의 동시성)** 필드 값을 지정합니다. 수동 구성에서는 쿼리 대기열을 최대 8개까지 구성하고, 각 대기열에서 동시에 실행할 수 있는 쿼리 수를 설정할 수 있습니다.

## WLM 구성 수정
<a name="cm-c-modifying-wlm-configuration"></a>

WLM 구성을 수정하는 가장 쉬운 방법은 Amazon Redshift 콘솔을 사용하는 것입니다. AWS CLI 또는 Amazon Redshift API를 사용할 수도 있습니다.

클러스터를 자동 WLM과 수동 WLM 간에 전환하면 클러스터가 `pending reboot` 상태가 됩니다. 변경 사항은 다음번 클러스터 재부팅까지 적용되지 않습니다.

WLM 구성 수정에 대한 자세한 내용은 *Amazon Redshift 관리 가이드*의 [워크로드 관리 구성](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) 섹션을 참조하세요.

### 수동 WLM에서 자동 WLM으로 마이그레이션
<a name="wlm-manual-to-automatic"></a>

시스템 처리량을 극대화하고 리소스를 최대한 효율적으로 사용하려면 해당 쿼리에 자동 WLM을 설정하는 것이 좋습니다. 수동 WLM에서 자동 WLM으로 원활하게 전환하도록 설정하려면 다음 접근 방식을 취하는 것을 고려하세요.

수동 WLM에서 자동 WLM으로 마이그레이션하고 쿼리 우선 순위를 사용하려면 새로운 파라미터 그룹을 생성한 후 이 파라미터 그룹을 해당 클러스터에 연결하는 것이 좋습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [Amazon Redshift 파라미터 그룹](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) 섹션을 참조하세요.

**중요**  
파라미터 그룹을 변경하거나 수동 WLM에서 자동 WLM으로 전환하려면 클러스터 재부팅이 필요합니다. 자세한 내용은 [WLM 동적 및 정적 구성 속성](cm-c-wlm-dynamic-properties.md) 섹션을 참조하세요.

예를 들어 세 개의 수동 WLM 대기열이 있는 경우를 살펴보겠습니다. 즉 ETL 워크로드, 분석 워크로드 및 데이터 과학 워크로드에 각각 한 개씩 있는 경우를 말합니다. ETL 워크로드는 6시간마다 실행되고, 분석 워크로드는 하루종일 실행되며, 데이터 과학 워크로드는 언제든지 급증할 수 있습니다. 수동 WLM을 사용해 비즈니스에 대한 각 워크로드의 중요도에 따라 각 워크로드 대기열이 차지할 메모리 및 동시성을 지정할 수 있습니다. 메모리 및 동시성을 지정하는 것은 까다로울 뿐만 아니라 클러스터 리소스가 통계적으로 분할되기 때문에 워크로드의 하위 집합만 실행되고 있을 때는 낭비되는 결과를 낳기도 합니다.

쿼리 우선 순위가 있는 자동 WLM을 사용하여 워크로드의 상대적 우선 순위를 나타냄으로써 이러한 문제를 피할 수 있습니다. 이와 같은 예의 경우 다음 절차를 따르세요.
+ 새로운 파라미터 그룹을 생성하고 **Auto WLM(자동 WLM)** 모드로 전환합니다.
+ 세 가지 워크로드, 즉 ETL 워크로드, 분석 워크로드 및 데이터 과학 워크로드 각각에 대기열을 추가합니다. **수동 WLM** 모드와 함께 사용된 각 워크로드에 동일한 사용자 그룹을 사용합니다.
+ ETL 워크로드는 `High`, 분석 워크로드는 `Normal`, 데이터 과학 워크로드는 `Low`로 우선 순위를 설정합니다. 이러한 우선 순위는 다양한 워크로드 또는 사용자 그룹에 대한 비즈니스 우선 순위를 반영합니다.
+ 선택적으로 ETL 워크로드가 6시간마다 실행되는 경우에도 이 대기열에 있는 쿼리가 일관된 성능을 발휘하도록 분석 또는 데이터 과학 대기열에 대해 동시성 확장을 활성화할 수 있습니다.

쿼리 우선 순위를 사용하면 분석 워크로드만 클러스터에서 실행 중인 경우 이 워크로드가 전체 시스템을 차지할 수 있습니다. 이렇게 하면 처리량이 많아지고 시스템 활용도가 향상됩니다. 그러나 ETL 워크로드가 시작하면 이 워크로드가 우선 순위가 더 높으므로 우선권을 얻습니다. ETL 워크로드의 일부로 실행되는 쿼리는 승인된 후에 우선적인 리소스 할당을 받을 뿐만 아니라 승인 중에도 우선권을 얻습니다. 결과적으로 ETL 워크로드는 시스템에서 다른 워크로드가 실행 중이어도 이와 상관없이 예상대로 성능을 발휘합니다. 우선 순위가 높은 워크로드가 예상대로 성능을 발휘하는 것은 더 오래 실행되는 더 낮은 우선 순위의 기타 워크로드로 인해 가능합니다. 이러한 워크로드의 쿼리는 더 중요한 쿼리가 완료되기를 뒤에서 기다리고 있거나 우선 순위가 더 높은 쿼리와 동시에 실행 중일 때 더 작은 리소스 조각을 얻기 때문입니다. Amazon Redshift에서 사용하는 예약 알고리즘을 통해 우선 순위가 더 낮은 쿼리가 리소스 결핍 없이 느린 속도로라도 계속 진행되도록 할 수 있습니다.

**참고**  
제한 시간 필드는 자동 WLM에서 사용할 수 없습니다. 대신에 QMR 규칙인 `query_execution_time`을 사용합니다. 자세한 내용은 [WLM 쿼리 모니터링 규칙](cm-c-wlm-query-monitoring-rules.md) 섹션을 참조하세요.
QMR 작업인 HOP는 자동 WLM에 적용할 수 없습니다. 대신에 `change priority` 작업을 사용합니다. 자세한 내용은 [WLM 쿼리 모니터링 규칙](cm-c-wlm-query-monitoring-rules.md) 섹션을 참조하세요.
클러스터는 자동 WLM과 수동 WLM 대기열을 서로 다르게 사용하므로 구성에 혼동이 발생할 수 있습니다. 예를 들어, 자동 WLM 대기열에서는 우선 순위 속성을 구성할 수 있지만 수동 WLM 대기열에서는 구성할 수 없습니다. 따라서 파라미터 그룹 내에서 자동 WLM 대기열과 수동 WLM 대기열을 섞지 마세요. 대신에 자동 WLM으로 마이그레이션할 때 새로운 파라미터 그룹을 생성하세요.

# 자동 WLM 구현
<a name="automatic-wlm"></a>

자동 워크로드 관리(WLM)를 통해 Amazon Redshift는 쿼리 동시성과 메모리 할당을 관리합니다. 서비스 클래스 식별자 100\$1107로 최대 8개의 대기열을 생성할 수 없습니다. 대기열마다 우선 순위가 있습니다. 자세한 내용은 [쿼리 우선 순위](query-priority.md) 섹션을 참조하세요.

자동 WLM을 통해 쿼리에 필요한 리소스의 양을 결정하고 워크로드에 근거하여 동시성을 조정합니다. 대량의 리소스가 필요한 쿼리가 시스템에 있는 경우(예: 큰 테이블 간 해시 조인) 동시성이 낮습니다. 더 가벼운 쿼리(예: 삽입, 삭제, 스캔 또는 간단한 집계 등)가 제출되는 경우 동시성이 높습니다.

자동 WLM은 단기 쿼리 가속화(SQA)와 분리되어 있으며 쿼리를 다른 방식으로 평가합니다. 자동 WLM 및 SQA는 함께 작동하여 장기 실행 중인 리소스 집약 쿼리가 활성화되어 있는 동안에도 단기 실행 및 경량 쿼리가 완료되게 합니다. SQA에 대한 자세한 내용은 [단기 쿼리 가속화](wlm-short-query-acceleration.md) 섹션을 참조하세요.

Amazon Redshift에서는 파라미터 그룹을 통해 자동 WLM을 사용합니다.
+ 클러스터에서 기본 파라미터 그룹을 사용하는 경우에서 Amazon Redshift는 클러스터에 대해 자동 WLM을 사용 설정합니다.
+ 클러스터에서 사용자 지정 파라미터 그룹을 사용하는 경우 자동 WLM을 활성화하도록 클러스터를 구성할 수 있습니다. 자동 WLM 구성에 대해 별도의 파라미터 그룹을 생성하는 것이 좋습니다.

WLM을 구성하려면 1개 이상의 클러스터와 연결할 수 있는 파라미터 그룹에서 `wlm_json_configuration` 파라미터를 편집합니다. 자세한 내용은 [WLM 구성 수정](cm-c-implementing-workload-management.md#cm-c-modifying-wlm-configuration) 섹션을 참조하세요.

WLM 구성 내에서 쿼리 대기열을 정의합니다. 쿼리 대기열은 기본 WLM 구성에 추가할 수 있으며, 이때 사용자 대기열의 최대 수는 8개입니다. 각 쿼리 대기열마다 다음과 같은 속성을 구성할 수 있습니다.
+ 우선순위 
+ 동시성 확장 모드 
+ 사용자 그룹 
+ 쿼리 그룹 
+ 쿼리 모니터링 규칙 

## 우선순위
<a name="wlm-auto-query-priority"></a>

우선 순위 값을 설정하여 워크로드 내에서 쿼리의 상대적 중요도를 정의할 수 있습니다. 우선 순위는 대기열에 대해 지정되고 이 대기열에 연결된 모든 쿼리에서 이 우선 순위를 상속합니다. 자세한 내용은 [쿼리 우선 순위](query-priority.md) 섹션을 참조하세요.

## 동시성 확장 모드
<a name="wlm-auto-concurrency-scaling-mode"></a>

동시성 크기 조정이 사용되면 동시 읽기 및 쓰기 쿼리의 증가를 처리하는 데 필요한 추가 클러스터 용량을 Amazon Redshift에서 자동으로 추가합니다. 쿼리가 기본 클러스터에서 실행되든 동시성 조정 클러스터에서 실행되든 사용자에게는 최신 데이터가 보입니다.

WLM 대기열을 구성하여 동시성 확장 클러스터에 보낸 쿼리를 관리합니다. 대기열에 동시성 크기 조정을 사용하면 대기열에서 기다리는 대신 적격 쿼리가 동시성 크기 조정 확장 클러스터로 전송됩니다. 자세한 내용은 [동시성 확장](concurrency-scaling.md) 섹션을 참조하세요.

## 사용자 그룹
<a name="wlm-auto-defining-query-queues-user-groups"></a>

사용자 그룹은 사용자 그룹 이름을 지정하거나 와일드카드를 사용하여 대기열에 할당할 수 있습니다. 나열된 사용자 그룹의 멤버가 쿼리를 실행할 경우에는 해당 대기열에서 실행됩니다. 대기열에 할당할 수 있는 사용자 그룹의 수는 제한이 없습니다. 자세한 내용은 [사용자 그룹을 기반으로 대기열에 쿼리 할당](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups) 섹션을 참조하세요.

## 사용자 역할
<a name="wlm-auto-defining-query-queues-user-roles"></a>

사용자 역할은 사용자 역할 이름을 지정하거나 와일드카드를 사용하여 대기열에 할당할 수 있습니다. 나열된 사용자 역할의 멤버가 쿼리를 실행할 경우에는 해당 대기열에서 실행됩니다. 대기열에 할당할 수 있는 사용자 역할의 수는 제한이 없습니다. 자세한 내용은 [사용자 역할을 기반으로 대기열에 쿼리 할당](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles) 섹션을 참조하세요.

## 쿼리 그룹
<a name="wlm-auto-defining-query-queues-query-groups"></a>

쿼리 그룹은 쿼리 그룹 이름을 지정하거나 와일드카드를 사용하여 대기열에 할당할 수 있습니다. *쿼리 그룹*이란 간단히 말해 레이블입니다. 실행 시간에 쿼리 그룹 레이블을 일련의 쿼리에 지정할 수 있습니다. 목록에 있는 쿼리 그룹에 지정된 모든 쿼리는 해당 대기열에서 실행됩니다. 대기열에 할당할 수 있는 쿼리 그룹의 수는 제한이 없습니다. 자세한 내용은 [쿼리 그룹에 쿼리 할당](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group) 섹션을 참조하세요.

## 와일드카드
<a name="wlm-auto-wildcards"></a>

WLM 대기열 구성에서 와일드카드가 사용 설정되어 있으면 사용자 그룹이나 쿼리 그룹을 개별적으로, 혹은 Unix 셸 스타일 와일드카드를 사용하여 할당할 수 있습니다. 패턴 일치는 대/소문자를 구분하지 않습니다.

예를 들어 '\$1' 와일드카드 문자는 모든 복수 문자와 일치합니다. 따라서 대기열의 사용자 그룹 목록에 `dba_*`를 추가하면 이름이 `dba_`로 시작되는 그룹에 속한 사용자 실행 쿼리는 모두 해당 대기열에 할당됩니다. `dba_admin` 또는 `DBA_primary`를 예로 들 수 있습니다. ‘?’ 와일드카드 문자는 모든 단일 문자와 일치합니다. 따라서 대기열에 `dba?1`이라는 이름의 사용자 그룹이 할당되어 있으면 `dba11`이나 `dba21` 같은 사용자 그룹은 모두 일치하지만 `dba12`는 일치하지 않습니다.

기본적으로 와일드카드는 활성화되어 있지 않습니다.

## 쿼리 모니터링 규칙
<a name="wlm-auto-query-monitoring-rules"></a>

쿼리 모니터링 규칙은 WLM 대기열의 지표 기반 성능 경계를 정의하고 쿼리가 해당 경계를 벗어날 때 실행할 작업을 지정합니다. 예를 들어 단시간 실행되는 쿼리 전용 대기열일 때는 60초 이상 실행되는 쿼리를 취소하는 규칙을 생성할 수도 있습니다. 그 밖에 잘못 설계된 쿼리를 추적할 목적으로 중첩 루프가 포함된 쿼리를 기록하는 규칙을 따로 만들 수도 있습니다. 자세한 내용은 [WLM 쿼리 모니터링 규칙](cm-c-wlm-query-monitoring-rules.md) 섹션을 참조하세요.

## 자동 WLM 확인
<a name="wlm-monitoring-automatic-wlm"></a>

자동 WLM이 활성화되었는지 확인하려면 다음 쿼리를 실행합니다. 쿼리에서 최소 1개의 행을 반환하면 자동 WLM이 활성화되어 있는 것입니다.

```
select * from stv_wlm_service_class_config 
where service_class >= 100;
```

다음 쿼리는 각 쿼리 대기열(서비스 클래스)를 통해 전송된 쿼리의 수를 보여줍니다. 또한 평균 실행 시간, 90번째 퍼센타일에 대기 시간이 있는 쿼리 수, 평균 대기 시간도 보여줍니다. 자동 WLM 쿼리는 서비스 클래스 100\$1107을 사용합니다.

```
select final_state, service_class, count(*), avg(total_exec_time), 
percentile_cont(0.9) within group (order by total_queue_time), avg(total_queue_time) 
from stl_wlm_query where userid >= 100 group by 1,2 order by 2,1;
```

자동 WLM에서 실행했고 성공적으로 완료한 쿼리를 찾으려면 다음 쿼리를 실행합니다.

```
select a.queue_start_time, a.total_exec_time, label, trim(querytxt) 
from stl_wlm_query a, stl_query b 
where a.query = b.query and a.service_class >= 100 and a.final_state = 'Completed' 
order by b.query desc limit 5;
```

# 쿼리 우선 순위
<a name="query-priority"></a>

Amazon Redshift를 사용하면 워크로드 관리(WM)를 사용하여 동시 쿼리 및 워크로드 전반에서 쿼리 우선순위 지정 및 리소스 할당을 관리할 수 있습니다. 다음 섹션에서는 WM 쿼리 대기열을 구성하고, 메모리 할당 및 동시성 규모 조정 등의 대기열 속성을 정의하고, 워크로드 요구 사항에 맞는 우선순위 규칙을 구현하는 방법을 자세히 설명합니다.

모든 쿼리의 중요도가 동등한 것은 아니며 한 가지 워크로드 또는 사용자 집합의 성능이 더 중요한 경우가 많습니다. [자동 WLM](automatic-wlm.md)을 활성화한 경우 우선 순위 값을 설정하여 워크로드 내에서 쿼리의 상대적 중요도를 정의할 수 있습니다. 우선 순위는 대기열에 대해 지정되고 이 대기열에 연결된 모든 쿼리에서 이 우선 순위를 상속합니다. 사용자 그룹 및 쿼리 그룹을 대기열에 매핑하여 쿼리를 대기열에 연결합니다. 우선 순위를 다음과 같이 설정할 수 있습니다(높은 순에서 낮은 순으로 나열됨).

1. `HIGHEST`

1. `HIGH`

1. `NORMAL`

1. `LOW`

1. `LOWEST`

동일한 리소스를 놓고 경합하는 다양한 우선 순위의 쿼리가 있을 때 관리자는 이러한 우선 순위를 사용해 워크로드의 상대적 중요도를 표시합니다. Amazon Redshift는 시스템에 쿼리를 허용할 때 우선 순위를 사용하고 쿼리에 할당된 리소스의 양을 결정합니다. 기본적으로 쿼리는 우선 순위가 `NORMAL`로 설정된 상태에서 실행됩니다.

`CRITICAL`보다 더 높은 우선 순위인 `HIGHEST`이라는 추가 우선 순위는 수퍼유저에게 제공됩니다. 이 우선 순위를 설정하려면 [CHANGE\$1QUERY\$1PRIORITY](r_CHANGE_QUERY_PRIORITY.md), [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md) 및 [CHANGE\$1USER\$1PRIORITY](r_CHANGE_USER_PRIORITY.md) 함수를 사용할 수 있습니다. 이 함수를 사용할 수 있는 권한을 데이터베이스 사용자에게 부여하려면 저장 프로시저를 생성하여 사용자에게 권한을 부여할 수 있습니다. 문제 해결 예는 [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md)을(를) 참조하세요.

**참고**  
한 번에 하나의 `CRITICAL` 쿼리만 실행할 수 있습니다.  
롤백은 항상 CRITICAL 우선순위로 실행됩니다.

ETL(추출, 변환 및 로드) 워크로드의 우선 순위가 분석 워크로드의 우선 순위보다 높은 경우를 예로 들어보겠습니다. ETL 워크로드는 6시간마다 실행되고, 분석 워크로드는 하루종일 실행됩니다. 분석 워크로드만 클러스터에서 실행 중인 경우 전체 이 워크로드는 전체 시스템을 차지함으로써 최적 시스템 사용률을 통해 높은 처리량을 산출합니다. 그러나 ETL 워크로드가 시작하면 이 워크로드가 우선 순위가 더 높으므로 우선권을 얻습니다. ETL 워크로드의 일부로 실행 중인 쿼리는 승인되는 중에, 그리고 승인된 후 기본 설정에 따른 리소스 할당 시에도 우선권을 얻습니다. 결과적으로 ETL 워크로드는 시스템에서 다른 워크로드가 실행 중이어도 이와 상관없이 예상대로 성능을 발휘합니다. 따라서 이를 통해 예측 가능한 성능을 얻을 수 있고 관리자는 비즈니스 사용자에게 SLA(서비스 수준 계약)를 제공할 수 있습니다.

특정 클러스터 내에서 우선 순위가 높은 워크로드의 예측 가능한 성능은 우선 순위가 더 낮은 기타 워크로드의 양보 덕분에 가능합니다. 우선 순위가 더 낮은 워크로드는 자체 쿼리가 중요도가 더 높은 쿼리가 완료될 때까지 뒤에서 대기하거나 우선 순위가 더 높은 쿼리와 동시에 실행 중일 때 더 작은 리소스 조각을 얻기 때문에 더 오래 실행될 수 있습니다. 우선 순위가 더 낮은 쿼리는 결핍에 시달리지 않고 더 느린 속도로 계속 진행됩니다.

앞의 예에서 관리자는 분석 워크로드에 대해 [동시성 확장](concurrency-scaling.md)을 활성화할 수 있습니다. 이렇게 하면 ETL 워크로드가 높은 우선 순위에서 실행 중인 경우에도 분석 워크로드는 처리량을 유지할 수 있습니다.

## 대기열 우선 순위 구성
<a name="concurrency-scaling-queues"></a>

자동 WLM을 활성화한 경우 각 대기열에는 우선 순위 값이 있습니다. 쿼리는 사용자 그룹 및 쿼리 그룹에 따라 대기열에 라우팅됩니다. 대기열 우선 순위를 `NORMAL`로 설정하여 시작합니다. 대기열의 사용자 그룹 및 쿼리 그룹에 연결된 워크로드에 따라 더 높거나 더 낮은 우선 순위를 설정합니다.

Amazon Redshift 콘솔에서 대기열의 우선 순위를 변경할 수 있습니다. Amazon Redshift 콘솔의 [**워크로드 관리(Workload Management)**] 페이지에는 대기열이 표시되고 이 페이지에서 [**우선 순위(Priority)**]와 같은 대기열 속성을 편집할 수 있습니다. CLI 또는 API 작업을 사용해 우선 순위를 설정하려면 `wlm_json_configuration` 파라미터를 사용하세요. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [워크로드 관리 구성](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) 섹션을 참조하세요.

다음 `wlm_json_configuration` 예제에서는 세 가지 사용자 그룹(`ingest`, `reporting` 및 `analytics`)을 정의합니다. 이 그룹 중 하나에 속한 사용자가 제출한 쿼리는 각각 `highest`, `normal` 및 `low` 우선 순위로 실행됩니다.

```
[
    {
        "user_group": [
            "ingest"
        ],
        "priority": "highest",
        "queue_type": "auto"
    },
    {
        "user_group": [
            "reporting"
        ],
        "priority": "normal",
        "queue_type": "auto"
    },
    {
        "user_group": [
            "analytics"
        ],
        "priority": "low",
        "queue_type": "auto",
        "auto_wlm": true
    }
]
```

## 쿼리 모니터링 규칙을 이용해 쿼리 우선 순위 변경
<a name="query-priority-qmr"></a>

QMR(쿼리 모니터링 규칙)을 통해 쿼리 실행 중에 쿼리의 동작에 근거하여 쿼리의 우선 순위를 변경할 수 있습니다. 이러한 변경은 QMR 조건자뿐 아니라 작업에서 우선 순위 속성을 지정하는 방식으로 수행할 수 있습니다. 자세한 내용은 [WLM 쿼리 모니터링 규칙](cm-c-wlm-query-monitoring-rules.md) 섹션을 참조하세요.

예를 들어 10분 이상 실행되는 `high` 우선순위로 분류된 모든 쿼리를 취소하도록 규칙을 정의할 수 있습니다.

```
"rules" :[
  {
    "rule_name":"rule_abort",
    "predicate":[
      {
        "metric_name":"query_cpu_time",
        "operator":">",
        "value":600
      },
      {
        "metric_name":"query_priority",
        "operator":"=",
        "value":"high"
      }
    ],
    "action":"abort"
  }
]
```

또 다른 예는 1TB 이상을 디스크에 유출하며 현재 우선 순위가 `lowest`인 모든 쿼리에 대해 쿼리 우선 순위를 `normal`로 변경할 수 있는 규칙을 정의하는 것입니다.

```
"rules":[
  {
    "rule_name":"rule_change_priority",
    "predicate":[
      {
        "metric_name":"query_temp_blocks_to_disk",
        "operator":">",
        "value":1000000
      },
      {
        "metric_name":"query_priority",
        "operator":"=",
        "value":"normal"
      }
    ],
    "action":"change_query_priority",
    "value":"lowest"
  }
]
```

## 대기열 우선 순위 모니터링
<a name="query-priority-monitoring"></a>

쿼리 대기 및 실행에 대한 우선 순위를 표시하려면 stv\$1wlm\$1query\$1state 시스템 테이블에 있는 `query_priority` 열을 확인하세요.

```
query    | service_cl | wlm_start_time             | state            | queue_time | query_priority
---------+------------+----------------------------+------------------+------------+----------------
2673299  | 102        | 2019-06-24 17:35:38.866356 | QueuedWaiting    | 265116     | Highest
2673236  | 101        | 2019-06-24 17:35:33.313854 | Running          | 0          | Highest
2673265  | 102        | 2019-06-24 17:35:33.523332 | Running          | 0          | High
2673284  | 102        | 2019-06-24 17:35:38.477366 | Running          | 0          | Highest
2673288  | 102        | 2019-06-24 17:35:38.621819 | Running          | 0          | Highest
2673310  | 103        | 2019-06-24 17:35:39.068513 | QueuedWaiting    | 62970      | High
2673303  | 102        | 2019-06-24 17:35:38.968921 | QueuedWaiting    | 162560     | Normal
2673306  | 104        | 2019-06-24 17:35:39.002733 | QueuedWaiting    | 128691     | Lowest
```

완료된 쿼리의 쿼리 우선 순위를 나열하려면 stl\$1wlm\$1query 시스템 테이블에 있는 `query_priority` 열을 확인하세요.

```
select query, service_class as svclass, service_class_start_time as starttime, query_priority 
from stl_wlm_query order by 3 desc limit 10;
```

```
  query  | svclass |         starttime          |    query_priority
---------+---------+----------------------------+----------------------
 2723254 |     100 | 2019-06-24 18:14:50.780094 | Normal
 2723251 |     102 | 2019-06-24 18:14:50.749961 | Highest  
 2723246 |     102 | 2019-06-24 18:14:50.725275 | Highest
 2723244 |     103 | 2019-06-24 18:14:50.719241 | High
 2723243 |     101 | 2019-06-24 18:14:50.699325 | Low
 2723242 |     102 | 2019-06-24 18:14:50.692573 | Highest
 2723239 |     101 | 2019-06-24 18:14:50.668535 | Low
 2723237 |     102 | 2019-06-24 18:14:50.661918 | Highest
 2723236 |     102 | 2019-06-24 18:14:50.643636 | Highest
```

워크로드의 처리량을 최적화하기 위해 Amazon Redshift는 사용자가 제출한 쿼리의 우선 순위를 수정할 수 있습니다. Amazon Redshift는 고급 기계 학습 알고리즘을 사용하여 이 최적화가 워크로드에 도움이 되는 시기를 결정하고 다음 조건이 모두 충족되면 자동으로 최적화를 적용합니다.
+ 자동 WLM이 사용됩니다.
+ 하나의 WLM 대기열만 정의됩니다.
+ 쿼리 우선 순위를 설정하는 쿼리 모니터링 규칙(QMR)을 정의하지 않았습니다. 이러한 규칙에는 QMR 지표 `query_priority` 또는 QMR 작업 `change_query_priority`가 포함됩니다. 자세한 내용은 [WLM 쿼리 모니터링 규칙](cm-c-wlm-query-monitoring-rules.md) 섹션을 참조하세요.

# 수동 WLM 구현
<a name="cm-c-defining-query-queues"></a>

수동 WLM에서는 WLM 구성을 수정하여 장시간 실행되는 쿼리와 단시간 실행되는 쿼리에 대해 별도의 대기열을 생성함으로써 시스템 성능과 사용자 경험을 관리할 수 있습니다.

사용자가 Amazon Redshift에서 쿼리를 실행할 때는 쿼리가 쿼리 대기열로 라우팅됩니다. 각 쿼리 대기열에는 다수의 쿼리 슬롯이 포함되어 있습니다. 또한 클러스터에서 사용할 수 있는 메모리가 부분적으로 할당됩니다. 이렇게 할당된 대기열의 메모리는 다시 쿼리 슬롯으로 분할됩니다. Amazon Redshift가 자동 WLM으로 쿼리 동시성을 관리하도록 할 수 있습니다. 자세한 내용은 [자동 WLM 구현](automatic-wlm.md) 섹션을 참조하세요.

또는 쿼리 대기열마다 WLM 속성을 구성할 수 있습니다. 이를 통해 메모리가 여러 슬롯에 할당되는 방식과 런타임 시 쿼리가 특정 대기열로 라우팅되는 방식을 지정할 수 있습니다. 장기 실행되는 쿼리를 취소하도록 WLM 속성을 구성할 수도 있습니다.

Amazon Redshift에는 다음 쿼리 대기열이 기본적으로 구성되어 있습니다.
+  **수퍼유저 대기열 1개** 

  수퍼유저 대기열은 수퍼유저 전용으로 예약되어 따로 구성할 수 없습니다. 시스템에 영향을 미치는 쿼리나 문제 해결이 목적인 쿼리를 실행할 때만 이 대기열을 사용합니다. 예를 들어 장시간 실행 중인 쿼리를 취소하거나 사용자에게 데이터베이스를 추가해야 할 때는 이 대기열을 사용하세요. 일반적인 쿼리를 실행하는 데는 사용하지 마세요. 대기열이 콘솔에는 표시되지 않지만 데이터베이스의 시스템 테이블에 5번째 대기열로 표시됩니다. 수퍼유저 대기열에서 쿼리를 실행하기 위해서는 사용자가 수퍼유저 권한으로 로그인한 후 사전 설정된 `superuser` 쿼리 그룹을 사용하여 쿼리를 실행해야 합니다.
+  **기본 사용자 대기열 1개** 

  기본 대기열에서는 동시에 실행할 수 있는 쿼리가 처음에 5개로 구성됩니다. 수동 WLM을 사용하면 기본 대기열의 동시성, 제한 시간 및 메모리 할당 속성을 변경할 수는 있지만 사용자 그룹이나 쿼리 그룹은 지정할 수 없습니다. 기본 대기열은 WLM 구성에서 마지막 대기열이 되어야 합니다. 다른 대기열로 라우팅되지 않는 쿼리는 모두 기본 대기열에서 실행됩니다.

쿼리 대기열은 WLM 구성에서 정의합니다. WLM 구성은 파라미터 그룹에서 편집이 가능한 파라미터(`wlm_json_configuration`)로서 클러스터 1개 이상과 연결할 수 있습니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [워크로드 관리 구성](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) 섹션을 참조하세요.

쿼리 대기열은 기본 WLM 구성에 추가할 수 있으며, 이때 사용자 대기열의 최대 수는 8개입니다. 각 쿼리 대기열마다 다음과 같은 속성을 구성할 수 있습니다.
+ 동시성 확장 모드 
+ 동시성 레벨 
+ 사용자 그룹 
+ 쿼리 그룹 
+ 사용할 WLM 메모리 비율
+ WLM 제한 시간
+ WLM 쿼리 대기열 건너뛰기
+ 쿼리 모니터링 규칙

## 동시성 확장 모드
<a name="concurrency-scaling-mode"></a>

동시성 크기 조정이 사용되면 동시 읽기 및 쓰기 쿼리의 증가를 처리하는 데 필요한 추가 클러스터 용량을 Amazon Redshift에서 자동으로 추가합니다. 쿼리가 기본 클러스터에서 실행되든 동시성 확장 클러스터에서 실행되든 사용자에게는 최신 데이터가 보입니다.

WLM 대기열을 구성하여 동시성 확장 클러스터에 보낸 쿼리를 관리합니다. 대기열에 동시성 크기 조정을 사용하면 대기열에서 기다리는 대신 적격 쿼리가 동시성 크기 조정 확장 클러스터로 전송됩니다. 자세한 내용은 [동시성 확장](concurrency-scaling.md) 섹션을 참조하세요.

## 동시성 레벨
<a name="cm-c-defining-query-queues-concurrency-level"></a>

대기열의 쿼리는 해당 대기열에 정의된 WLM 쿼리 슬롯 수 또는 *동시성* 레벨에 도달할 때까지 동시에 실행됩니다. 이후의 쿼리들은 대기열에서 대기합니다.

**참고**  
WLM 동시 실행 수준은 한 클러스터에 만들 수 있는 동시 사용자 연결 수와 다릅니다. 자세한 내용은 *Amazon Redshift 관리 가이드*의 [클러스터에 연결](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-to-cluster.html) 섹션을 참조하세요.

자동 WLM 구성(권장)에는 동시성 수준이 **자동**으로 설정되어 있습니다. Amazon Redshift는 쿼리에 메모리를 동적으로 할당하고, 쿼리는 이후에 동시에 실행할 메모리를 결정합니다. 이는 실행 중인 쿼리와 대기열에 있는 쿼리에 모두 필요한 리소스를 기반으로 합니다. 자동 WLM은 구성할 수 없습니다. 자세한 내용은 [자동 WLM 구현](automatic-wlm.md) 섹션을 참조하세요.

수동 WLM 구성에서 Amazon Redshift는 고정된 양의 메모리를 각 대기열에 정적으로 할당합니다. 큐의 메모리는 쿼리 슬롯 간에 균등하게 분할됩니다. 예를 들어, 대기열에 클러스터 메모리의 20%가 할당되고 10개의 슬롯이 있는 경우 각 쿼리에는 클러스터 메모리의 2%가 할당됩니다. 메모리 할당은 동시에 실행되는 쿼리 수에 관계없이 고정된 상태로 유지됩니다. 고정된 메모리 할당으로 인해 슬롯 수가 5일 때 메모리에서만 실행되는 쿼리는 슬롯 수가 20으로 증가될 경우 중간 결과를 디스크에 작성해야 할 수도 있습니다. 이 경우 각 쿼리의 대기열 메모리 점유율은 1/5에서 1/20로 감소합니다. 결국 디스크 I/O가 추가로 발생하여 성능이 떨어지게 됩니다.

모든 사용자 정의 대기열의 최대 슬롯 수는 50입니다. 이렇게 하면 기본 대기열을 포함한 모든 대기열의 총 슬롯이 제한됩니다. 제한이 적용되지 않는 유일한 대기열은 예약된 수퍼유저 대기열입니다.

기본적으로 수동 WLM 대기열의 동시성 레벨은 5입니다. 하지만 다음과 같은 경우에는 동시성 레벨을 높여 워크로드의 이점을 얻을 수도 있습니다.
+ 많은 수의 작은 쿼리가 장기 실행 쿼리를 대기해야 하는 경우 슬롯 수가 많은 별도의 대기열을 생성하고 작은 쿼리를 해당 대기열에 할당합니다. 동시성 레벨이 높은 대기열은 각 쿼리 슬롯에 할당되는 메모리 크기가 작기는 하지만 쿼리 용량이 낮을수록 필요한 메모리 크기 역시 작습니다.
**참고**  
단기 쿼리 가속화(SQA)를 활성화하면 WLM은 자동으로 장기 실행 쿼리보다 단기 쿼리를 우선적으로 처리하므로, 대부분의 워크플로우에서 단기 쿼리에 별도의 대기열이 필요 없습니다. 자세한 내용은 [단기 쿼리 가속화](wlm-short-query-acceleration.md) 섹션을 참조하세요.
+ 단일 조각의 데이터에 각각 액세스하는 쿼리가 여러 개인 경우 이러한 쿼리를 동시에 실행하도록 별도의 WLM 대기열을 설정합니다. Amazon Redshift는 동시 쿼리를 별도의 조각에 할당하므로 여러 쿼리를 여러 조각에서 병렬로 실행할 수 있습니다. 예를 들어 분산 키를 기준으로 조건자를 사용한 단순 집계 쿼리인 경우에는 쿼리 데이터가 단일 조각에 저장됩니다.

### 수동 WLM 예제
<a name="cm-c-defining-query-queues-concurrency-level-example"></a>

 이 예제는 슬롯과 메모리를 할당하는 방법을 보여주는 간단한 수동 WLM 시나리오입니다. 다음과 같은 세 개의 대기열로 수동 WLM을 구현합니다.
+ *data-ingestion 대기열* – 데이터 모으기를 위해 설정됩니다. 클러스터 메모리의 20%가 할당되고 5개의 슬롯이 있습니다. 이후 대기열에서 5개의 쿼리를 동시에 실행할 수 있으며 각 쿼리에는 메모리의 4% 가 할당됩니다.
+ *data-scientist 대기열* – 메모리를 많이 사용하는 쿼리를 위해 설계되었습니다. 클러스터 메모리의 40%가 할당되고 5개의 슬롯이 있습니다. 이후 5개의 쿼리를 동시에 실행할 수 있으며 각 쿼리에는 메모리의 8% 가 할당됩니다.
+ *default 대기열* – 조직 내 대다수 사용자를 위해 설계되었습니다. 여기에는 일반적으로 복잡하지 않은 단기 또는 중기 실행 쿼리를 사용하는 영업 및 회계 그룹이 포함됩니다. 클러스터 메모리의 40%가 할당되고 40개의 슬롯이 있습니다. 이 대기열에서는 40개의 쿼리를 동시에 실행할 수 있으며 각 쿼리에는 메모리의 1%가 할당됩니다. 대기열 전체의 제한은 50개이므로 이 대기열에 할당할 수 있는 최대 슬롯 수입니다.

자동 WLM을 실행 중이고 워크로드를 병렬로 실행하기 위해 15개가 넘는 쿼리가 필요한 경우 동시성 확장을 켜는 것이 좋습니다. 쿼리 슬롯 수가 15개를 초과하면 시스템 리소스에 대한 경합이 발생하여 단일 클러스터의 전체 처리량이 제한될 수 있기 때문입니다. 동시성 확장을 사용하면 동시성 확장 클러스터의 구성된 수까지 수백 개의 쿼리를 병렬로 실행할 수 있습니다. 동시성 확장 클러스터의 수는 [max\$1concurrency\$1scaling\$1clusters](r_max_concurrency_scaling_clusters.md)에서 제어합니다. 동시성 조정에 대한 자세한 내용은 [동시성 확장](concurrency-scaling.md) 섹션을 참조하세요.

자세한 내용은 [쿼리 성능 개선](query-performance-improvement-opportunities.md) 섹션을 참조하세요.

## 사용자 그룹
<a name="cm-c-defining-query-queues-user-groups"></a>

사용자 그룹은 사용자 그룹 이름을 지정하거나 와일드카드를 사용하여 대기열에 할당할 수 있습니다. 나열된 사용자 그룹의 멤버가 쿼리를 실행할 경우에는 해당 대기열에서 실행됩니다. 대기열에 할당할 수 있는 사용자 그룹의 수는 제한이 없습니다. 자세한 내용은 [사용자 그룹을 기반으로 대기열에 쿼리 할당](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups) 섹션을 참조하세요.

## 사용자 역할
<a name="cm-c-defining-query-queues-user-roles"></a>

사용자 역할은 사용자 역할 이름을 지정하거나 와일드카드를 사용하여 대기열에 할당할 수 있습니다. 나열된 사용자 역할의 멤버가 쿼리를 실행할 경우에는 해당 대기열에서 실행됩니다. 대기열에 할당할 수 있는 사용자 역할의 수는 제한이 없습니다. 자세한 내용은 [사용자 역할을 기반으로 대기열에 쿼리 할당](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles) 섹션을 참조하세요.

## 쿼리 그룹
<a name="cm-c-defining-query-queues-query-groups"></a>

쿼리 그룹은 쿼리 그룹 이름을 지정하거나 와일드카드를 사용하여 대기열에 할당할 수 있습니다. 쿼리 그룹이란 쉽게 말해서 레이블을 의미합니다. 실행 시간에 쿼리 그룹 레이블을 일련의 쿼리에 지정할 수 있습니다. 목록에 있는 쿼리 그룹에 지정된 모든 쿼리는 해당 대기열에서 실행됩니다. 대기열에 할당할 수 있는 쿼리 그룹의 수는 제한이 없습니다. 자세한 내용은 [쿼리 그룹에 쿼리 할당](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group) 섹션을 참조하세요.

## 와일드카드
<a name="wlm-wildcards"></a>

WLM 대기열 구성에서 와일드카드가 활성화되어 있으면 사용자 그룹이나 쿼리 그룹을 개별적으로, 혹은 Unix 셸 스타일 와일드카드를 사용하여 할당할 수 있습니다. 패턴 일치는 대/소문자를 구분하지 않습니다.

예를 들어 '\$1' 와일드카드 문자는 모든 복수 문자와 일치합니다. 따라서 대기열의 사용자 그룹 목록에 `dba_*`를 추가하면 이름이 `dba_`로 시작되는 그룹에 속한 사용자 실행 쿼리는 모두 해당 대기열에 할당됩니다. `dba_admin` 또는 `DBA_primary`를 예로 들 수 있습니다. ‘?’ 와일드카드 문자는 모든 단일 문자와 일치합니다. 따라서 대기열에 `dba?1`이라는 이름의 사용자 그룹이 할당되어 있으면 `dba11`이나 `dba21` 같은 사용자 그룹은 모두 일치하지만 `dba12`는 일치하지 않습니다.

와일드카드는 기본적으로 해제되어 있습니다.

## 사용할 WLM 메모리 비율
<a name="wlm-memory-percent"></a>

자동 WLM 구성에서 메모리 비율은 **auto**로 설정되어 있습니다. 자세한 내용은 [자동 WLM 구현](automatic-wlm.md) 섹션을 참조하세요.

수동 WLM 구성에서 쿼리에 할당할 수 있는 메모리 크기를 지정하려면 `WLM Memory Percent to Use` 파라미터를 설정할 수 있습니다. 기본적으로 각 사용자 정의 대기열에는 사용자 정의 쿼리에 사용할 수 있는 메모리가 균일하게 할당됩니다. 예를 들어 사용자 정의 대기열이 4개라면 각 대기열마다 사용할 수 있는 메모리가 25%씩 할당됩니다. 수퍼유저 대기열에는 메모리가 따로 할당되며, 이를 수정할 수 없습니다. 할당 비율을 변경하려면 각 대기열마다 메모리를 총 100%까지 정수 비율로 할당하면 됩니다. 할당되지 않는 메모리는 Amazon Redshift에서 관리하며, 데이터 처리를 위해 추가 메모리를 요청하는 대기열에 임시로 할당됩니다.

예를 들어 대기열을 4개 구성할 경우 20%, 30%, 15%, 15%씩 메모리를 할당할 수 있습니다. 나머지 20%가 미할당 메모리가 되며, 서비스에서 관리합니다.

## WLM 제한 시간
<a name="wlm-timeout"></a>

WLM 제한 시간(`max_execution_time`)은 더 이상 사용되지 않습니다. 대신 `query_execution_time`을 통해 QMR(쿼리 모니터링 규칙)을 생성하여 쿼리 실행 경과 시간을 제한하세요. 자세한 내용은 [WLM 쿼리 모니터링 규칙](cm-c-wlm-query-monitoring-rules.md) 섹션을 참조하세요.

임의의 WLM 대기열에서 쿼리가 사용할 수 있는 시간 크기를 제한할 때는 각 대기열마다 WLM 제한 시간 값을 설정할 수 있습니다. 시간 제한 파라미터는 Amazon Redshift가 쿼리를 취소하거나 건너뛸 때까지 쿼리 실행을 대기하는 시간(밀리초)을 지정합니다. 제한 시간은 쿼리 실행 시간에 따라 달라지며 대기열에서 대기하는 시간은 포함되지 않습니다.

WLM은 [CREATE TABLE AS](r_CREATE_TABLE_AS.md)(CTAS) 문과 읽기 전용 쿼리(예: SELECT 문)만 건너뛰려고 합니다. 건너뛸 수 없는 쿼리는 취소됩니다. 자세한 내용은 [WLM 쿼리 대기열 건너뛰기](wlm-queue-hopping.md) 섹션을 참조하세요.

WLM 제한 시간은 returning 상태에 도달한 쿼리에는 적용되지 않습니다. 커서의 상태를 보려면 [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) 시스템 테이블을 참조하세요. COPY 문과 유지 관리 작업(예: ALTER, ANALYZE 및 VACUUM)에는 WLM 제한 시간이 적용되지 않습니다.

WLM 제한 시간 함수는 [statement\$1timeout](r_statement_timeout.md) 구성 파라미터와 비슷합니다. `statement_timeout` 구성 파라미터가 전체 클러스터에 적용되는 반면 WLM 제한 시간은 WLM 구성에 속한 단일 대기열에만 적용된다는 점이 다릅니다.

[statement\$1timeout](r_statement_timeout.md)도 지정하는 경우에는 statement\$1timeout과 WLM 제한 시간(max\$1execution\$1time) 중에서 더 낮은 값이 사용됩니다.

## 쿼리 모니터링 규칙
<a name="wlm-query-monitoring-rules"></a>

쿼리 모니터링 규칙은 WLM 대기열의 지표 기반 성능 경계를 정의하고 쿼리가 해당 경계를 벗어날 때 실행할 작업을 지정합니다. 예를 들어 단시간 실행되는 쿼리 전용 대기열일 때는 60초 이상 실행되는 쿼리를 취소하는 규칙을 생성할 수도 있습니다. 그 밖에 잘못 설계된 쿼리를 추적할 목적으로 중첩 루프가 포함된 쿼리를 기록하는 규칙을 따로 만들 수도 있습니다. 자세한 내용은 [WLM 쿼리 모니터링 규칙](cm-c-wlm-query-monitoring-rules.md) 섹션을 참조하세요.

# WLM 쿼리 대기열 건너뛰기
<a name="wlm-queue-hopping"></a>

Amazon Redshift를 사용하면 WLM(워크로드 관리) 쿼리 대기열 호핑을 사용하여 워크로드 동시성과 리소스 할당을 관리할 수 있습니다. 이 기능을 사용하면 리소스 사용이 가능할 때 쿼리가 할당된 대기열에서 우선순위가 더 높은 대기열로 일시적으로 '호핑'할 수 있으므로 전반적인 쿼리 성능과 시스템 사용률이 향상됩니다. 다음 섹션에서는 Amazon Redshift에서 WLM 쿼리 대기열 호핑 구성 및 활용에 관한 자세한 가이드를 제공합니다.

[WLM 시간 제한](cm-c-defining-query-queues.md#wlm-timeout) 또는 [쿼리 모니터링 규칙(QMR) 건너뛰기 작업](cm-c-wlm-query-monitoring-rules.md#cm-c-wlm-defining-query-monitoring-rules)으로 인해 쿼리를 건너뛸 수 있습니다. 수동 WLM 구성에서는 쿼리를 건너뛸 수만 있습니다.

쿼리를 건너뛰면 WLM은 [WLM 대기열 할당 규칙](cm-c-wlm-queue-assignment-rules.md)을 기반으로 다음에 일치하는 대기열에 쿼리를 라우팅하려고 합니다. 쿼리가 다른 어떤 대기열 정의와도 일치하지 않는 경우, 쿼리가 취소됩니다. 쿼리는 기본 대기열에 할당되지 않습니다.

## WLM 제한 시간 작업
<a name="wlm-queue-hopping-summary"></a>

다음 표에는 다양한 유형의 쿼리 동작과 WLM 제한 시간이 요약되어 있습니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/wlm-queue-hopping.html)

## WLM 제한 시간 대기열 건너뛰기
<a name="wlm-timeout-queue-hopping"></a>

WLM은 시간이 초과될 때 다음 유형의 쿼리를 건너뜁니다.
+ WLM 상태가 `running`인 읽기 전용 쿼리(예: SELECT 문). 쿼리의 WLM 상태를 알고 싶다면 [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) 시스템 테이블에서 STATE 열을 확인하세요.
+ CREATE TABLE AS(CTAS) 문. WLM 대기열 건너뛰기는 사용자 정의 CTAS 문과 시스템 생성 CTAS 문을 모두 지원합니다.
+ SELECT INTO 문

WLM 제한 시간이 적용되지 않는 쿼리는 완료될 때까지 원래 대기열에서 계속 실행됩니다. 다음 유형의 쿼리에는 WLM 제한 시간이 적용되지 않습니다.
+ COPY 문
+ 유지 관리 작업(예: ALTER, ANALYZE 및 VACUUM)
+ `returning` WLM 상태에 도달한 읽기 전용 쿼리(예: SELECT 문). 쿼리의 WLM 상태를 알고 싶다면 [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) 시스템 테이블에서 STATE 열을 확인하세요.

WLM 시간 제한에 따른 건너뛰기를 사용할 수 없는 쿼리는 시간이 초과될 때 취소됩니다. 다음 유형의 쿼리는 WLM 제한 시간에 따른 건너뛰기를 사용할 수 없습니다.
+ INSERT, UPDATE 및 DELETE 문
+ UNLOAD 문
+ 사용자 정의 함수(UDF)

## WLM 제한 시간 다시 할당 및 다시 시작 쿼리
<a name="wlm-timeout-reassigned-and-restarted-queries"></a>

쿼리를 건너뛰고 일치하는 대기열을 찾을 수 없으면 쿼리가 취소됩니다.

쿼리를 건너뛰고 일치하는 대기열을 찾으면 WLM은 쿼리를 새 대기열에 다시 할당하려고 합니다. 쿼리를 다시 할당할 수 없으면 다음 설명과 같이 쿼리가 새 대기열에서 다시 시작됩니다.

다음이 모두 참인 경우에만 쿼리가 다시 할당됩니다.
+ 일치하는 대기열이 발견되었습니다.
+ 새로운 대기열에 쿼리를 실행할 수 있는 빈 슬롯이 있습니다. [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) 파라미터를 1보다 큰 값으로 설정한 경우 한 쿼리에 여러 슬롯이 필요할 수 있습니다.
+ 새 대기열에서 최소한 쿼리가 현재 사용하는 것과 같은 양의 메모리를 사용할 수 있습니다.

쿼리를 다시 할당하면 쿼리는 새 대기열에서 실행을 계속합니다. 중간 결과가 보존되므로, 총 실행 시간에 대한 효과는 최소화됩니다.

쿼리를 다시 할당할 수 없으면 쿼리가 취소되고 새 대기열에서 다시 시작됩니다. 중가나 결과는 삭제됩니다. 쿼리는 대기열에서 대기한 다음 충분한 슬롯을 사용할 수 있을 때 실행을 시작합니다.

## QMR 건너뛰기 작업
<a name="qmr-hop-action-queue-hopping"></a>

다음 표에는 다양한 유형의 쿼리 동작과 QMR 건너뛰기 작업이 요약되어 있습니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/wlm-queue-hopping.html)

QMR에서 건너뛴 쿼리가 다시 할당되었는지, 다시 시작되었는지 또는 취소되었는지 알아보려면 [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md) 시스템 로그 테이블을 쿼리합니다.

## QMR 건너뛰기 작업 다시 할당 및 다시 시작 쿼리
<a name="qmr-hop-action-reassigned-and-restarted-queries"></a>

쿼리를 건너뛰고 일치하는 대기열을 찾을 수 없으면 쿼리가 취소됩니다.

쿼리를 건너뛰고 일치하는 대기열을 찾으면 WLM은 쿼리를 새 대기열에 다시 할당하려고 합니다. 쿼리를 다시 할당할 수 없으면 다음 설명과 같이 쿼리가 새 대기열에서 다시 시작되거나 원래 대기열에서 실행을 계속합니다.

다음이 모두 참인 경우에만 쿼리가 다시 할당됩니다.
+ 일치하는 대기열이 발견되었습니다.
+ 새로운 대기열에 쿼리를 실행할 수 있는 빈 슬롯이 있습니다. [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) 파라미터를 1보다 큰 값으로 설정한 경우 한 쿼리에 여러 슬롯이 필요할 수 있습니다.
+ 새 대기열에서 최소한 쿼리가 현재 사용하는 것과 같은 양의 메모리를 사용할 수 있습니다.

쿼리를 다시 할당하면 쿼리는 새 대기열에서 실행을 계속합니다. 중간 결과가 보존되므로, 총 실행 시간에 대한 효과는 최소화됩니다.

쿼리를 다시 할당할 수 없으면 쿼리가 다시 시작되거나 원래 대기열에서 실행을 계속합니다. 쿼리를 다시 시작하면 쿼리가 취소되고 새 대기열에서 다시 시작됩니다. 중가나 결과는 삭제됩니다. 쿼리는 대기열에서 대기한 다음 충분한 슬롯을 사용할 수 있을 때 실행을 시작합니다.

# 자습서: 수동 워크로드 관리(WLM) 대기열 구성
<a name="tutorial-configuring-workload-management"></a>

Amazon Redshift를 사용하면 수동 워크로드 관리(WLM) 대기열을 구성하여 다양한 유형의 쿼리 및 사용자에 대한 리소스의 우선순위를 지정하고 할당할 수 있습니다. 수동 WLM 대기열을 사용하면 특정 대기열에 대한 메모리 및 동시성 설정을 제어할 수 있으므로 중요한 워크로드가 필요한 리소스를 수신하면서 우선순위가 낮은 쿼리가 시스템을 독점하는 것을 방지할 수 있습니다. 다음 섹션에서는 워크로드 관리 요구 사항을 충족하기 위해 Amazon Redshift에서 수동 WLM 대기열을 생성하고 구성하는 프로세스를 안내합니다.

## 개요
<a name="tutorial-wlm-overview"></a>

Amazon Redshift에서 자동 워크로드 관리(WLM)를 구성하는 것이 좋습니다. 자동 WLM에 대한 자세한 내용은 [워크로드 관리](cm-c-implementing-workload-management.md) 섹션을 참조하세요. 그러나 WLM 대기열이 여러 개 필요한 경우 이 튜토리얼에서는 Amazon Redshift에서 수동 워크로드 관리(WLM)를 구성하는 과정을 안내합니다. 수동 WLM을 구성하면 클러스터의 쿼리 성능과 리소스 할당을 개선할 수 있습니다.

Amazon Redshift는 사용자 쿼리를 처리할 수 있도록 대기열로 라우팅합니다. 이러한 쿼리의 대기열 라우팅 방식을 정의하는 것이 바로 WLM입니다. 기본적으로 Amazon Redshift에는 슈퍼 사용자용 대기열, 사용자용 대기열 등 쿼리에 사용할 수 있는 대기열이 2개 있습니다. 수퍼유저 대기열은 따로 구성할 수 없으며 한 번에 처리할 수 있는 쿼리의 수도 1개로 제한됩니다. 이 대기열은 문제 해결 목적으로만 예약해야 합니다. 사용자 대기열은 한 번에 5개까지 쿼리를 처리할 수 있지만 필요하다면 대기열의 동시성 레벨을 변경하여 다르게 구성할 수도 있습니다.

데이터베이스에서 다수의 사용자가 쿼리를 실행하고 있다면 더욱 효율적인 구성이 있는지 찾아보세요. 예를 들어 일부 사용자가 VACUUM 같이 리소스 집약적인 작업을 실행할 경우에는 보고서 같이 리소스를 덜 사용하는 쿼리는 부정적인 영향을 받을 수 있습니다. 이때는 대기열을 추가하여 다른 워크로드에 구성하는 것이 좋습니다.

**예상 소요 시간:** 75분

**예상 비용:** 50센트

### 사전 조건
<a name="tutorial-wlm-prereq"></a>

Amazon Redshift 클러스터, 샘플 TICKIT 데이터베이스 및 psql 클라이언트 도구가 필요합니다. 아직 이 세 가지가 준비되지 않았다면 [Amazon Redshift 시작 안내서](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html)와 [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html)을 참조하세요.

### 섹션
<a name="tutorial-wlm-steps"></a>
+ [섹션 1: 기본적인 대기열 처리 동작에 대한 이해](#tutorial-wlm-understanding-default-processing)
+ [섹션 2: WLM 쿼리 대기열 구성의 수정](#tutorial-wlm-modifying-wlm-configuration)
+ [섹션 3: 사용자 그룹 및 쿼리 그룹을 기반으로 쿼리를 대기열로 라우팅](#tutorial-wlm-routing-queries-to-queues)
+ [섹션 4: wlm\$1query\$1slot\$1count를 사용하여 대기열에서 동시성 레벨을 임시로 재정의](#tutorial-wlm-query-slot-count)
+ [섹션 5: 리소스 정리](#tutorial-wlm-cleaning-up-resources)

## 섹션 1: 기본적인 대기열 처리 동작에 대한 이해
<a name="tutorial-wlm-understanding-default-processing"></a>

수동 WLM 구성을 시작하기 전에 먼저 Amazon Redshift의 기본적인 대기열 처리 동작에 대해서 알아두는 것이 좋습니다. 이번 섹션에서는 몇 가지 시스템 테이블에서 정보를 반환하는 데이터베이스 뷰 2개를 생성합니다. 그런 다음 테스트 쿼리를 몇 차례 실행하여 기본적으로 쿼리가 라우팅되는 방식을 알아봅니다. 시스템 테이블에 대한 자세한 내용은 [시스템 테이블 및 뷰 참조](cm_chap_system-tables.md) 섹션을 참조하세요.

### 1단계: WLM\$1QUEUE\$1STATE\$1VW 뷰 생성
<a name="tutorial-wlm-create-queue-state-view"></a>

이번 단계에서는 WLM\$1QUEUE\$1STATE\$1VW라는 이름의 뷰를 생성합니다. 이 뷰는 다음 시스템 테이블에서 정보를 반환합니다.
+ [STV\$1WLM\$1CLASSIFICATION\$1CONFIG](r_STV_WLM_CLASSIFICATION_CONFIG.md)
+ [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md)
+ [STV\$1WLM\$1SERVICE\$1CLASS\$1STATE](r_STV_WLM_SERVICE_CLASS_STATE.md)

이 뷰는 자습서 전체에서 WLM 구성 변경 후 대기열을 모니터링하는 데 사용됩니다. 다음 표는 WLM\$1QUEUE\$1STATE\$1VW 뷰가 반환하는 데이터에 대해 설명한 것입니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/tutorial-configuring-workload-management.html)

#### WLM\$1QUEUE\$1STATE\$1VW 뷰를 생성하려면
<a name="how-to-wlm-create-queue-state-view"></a>

1. [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html)을 열고 TICKIT 샘플 데이터베이스에 연결합니다. 이 역할이 구성되지 않은 경우 [사전 조건](#tutorial-wlm-prereq) 섹션을 참조하세요.

1. 다음 쿼리를 실행하여 WLM\$1QUEUE\$1STATE\$1VW 뷰를 생성합니다.

   ```
   create view WLM_QUEUE_STATE_VW as
   select (config.service_class-5) as queue
   , trim (class.condition) as description
   , config.num_query_tasks as slots
   , config.query_working_mem as mem
   , config.max_execution_time as max_time
   , config.user_group_wild_card as "user_*"
   , config.query_group_wild_card as "query_*"
   , state.num_queued_queries queued
   , state.num_executing_queries executing
   , state.num_executed_queries executed
   from
   STV_WLM_CLASSIFICATION_CONFIG class,
   STV_WLM_SERVICE_CLASS_CONFIG config,
   STV_WLM_SERVICE_CLASS_STATE state
   where
   class.action_service_class = config.service_class 
   and class.action_service_class = state.service_class 
   and config.service_class > 4
   order by config.service_class;
   ```

1. 다음 쿼리를 실행하여 뷰에 포함된 정보를 확인합니다.

   ```
   select * from wlm_queue_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (querytype:any)                           |     5 | 836 |        0 |  false | false   |      0 |         1 |      160
   ```

### 2단계: WLM\$1QUERY\$1STATE\$1VW 뷰 생성
<a name="tutorial-wlm-create-query-state-view"></a>

이번 단계에서는 WLM\$1QUERY\$1STATE\$1VW라는 이름의 뷰를 생성합니다. 이 뷰는 [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) 시스템 테이블에서 정보를 반환합니다.

이 뷰는 자습서 전체에서 실행 중인 쿼리를 모니터링하는 데 사용됩니다. 다음 표는 WLM\$1QUERY\$1STATE\$1VW 뷰가 반환하는 데이터에 대해 설명한 것입니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/tutorial-configuring-workload-management.html)

#### WLM\$1QUERY\$1STATE\$1VW 뷰를 생성하려면
<a name="how-to-wlm-create-query-state-view"></a>

1. RSQL에서 다음 쿼리를 실행하여 WLM\$1QUERY\$1STATE\$1VW 뷰를 생성합니다.

   ```
   create view WLM_QUERY_STATE_VW as
   select query, (service_class-5) as queue, slot_count, trim(wlm_start_time) as start_time, trim(state) as state, trim(queue_time) as queue_time, trim(exec_time) as exec_time
   from stv_wlm_query_state;
   ```

1. 다음 쿼리를 실행하여 뷰에 포함된 정보를 확인합니다.

   ```
   select * from wlm_query_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    1249 |     1 |          1 | 2014-09-24 22:19:16 | Executing | 0          | 516
   ```

### 3단계: 테스트 쿼리 실행
<a name="tutorial-wlm-run-test-queries"></a>

이번 단계에서는 RSQL에서 다중 연결을 통해 쿼리를 실행한 후 시스템 테이블을 살펴보면서 쿼리가 처리를 위해 어떻게 라우팅되었는지 확인합니다.

이번 단계를 진행하려면 RSQL 창 2개를 열어야 합니다.
+ RSQL 창 1에서는 이번 자습서에서 이미 생성한 뷰를 사용하여 대기열과 쿼리의 상태를 모니터링하는 쿼리를 실행합니다.
+ RSQL 창 2에서는 RSQL 창 1에서 구한 결과를 변경하는 쿼리를 장시간 실행합니다.

#### 테스트 쿼리를 실행하려면
<a name="how-to-wlm-run-test-queries"></a>

1. RSQL 창 2개를 엽니다. 이미 창을 1개 열었다면 두 번째 창만 열면 됩니다. 두 창을 모두 연결하는 데 동일한 사용자 계정을 사용할 수 있습니다.

1. RSQL 창 1에서는 다음 쿼리를 실행합니다.

   ```
   select * from wlm_query_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    1258 |     1 |          1 | 2014-09-24 22:21:03 | Executing | 0          | 549
   ```

   이 쿼리는 자기 참조적 결과를 반환합니다. 현재 실행 중인 쿼리는 이 보기의 SELECT 문입니다. 이 뷰에 대한 쿼리는 항상 1개 이상의 결과를 반환합니다. 이 결과를 다음 단계에서 장시간 실행 쿼리를 시작하여 나타나는 결과와 서로 비교합니다.

1. RSQL 창 2에서는 TICKIT 샘플 데이터베이스에서 쿼리를 실행합니다. 이 쿼리는 앞에서 생성한 WLM\$1QUEUE\$1STATE\$1VW 뷰와 WLM\$1QUERY\$1STATE\$1VW 뷰의 결과를 충분히 살펴볼 수 있도록 약 1분 동안 실행해야 합니다. 경우에 따라 두 뷰에 대한 쿼리를 실행할 수 있을 정도로 쿼리 실행 시간이 충분히 길지 않을 수 있습니다. 이러한 경우 `l.listid `에 대한 필터 값을 높여서 실행 시간을 연장할 수 있습니다.
**참고**  
쿼리 실행 시간을 줄이고 시스템 성능을 향상시키기 위해 Amazon Redshift는 특정 형식의 쿼리 결과를 리더 노드의 메모리에 캐시합니다. 결과 캐싱이 활성화되어 있으면 이후 쿼리의 실행 속도가 훨씬 빨라집니다. 쿼리가 빠르게 실행되는 것을 방지하려면 현재 세션에 대해 결과 캐싱을 비활성화합니다.

   현재 세션에 대해 결과 캐싱을 해제하려면 다음과 같이 [enable\$1result\$1cache\$1for\$1session](r_enable_result_cache_for_session.md) 파라미터를 `off`로 설정합니다.

   ```
   set enable_result_cache_for_session to off;
   ```

   RSQL 창 2에서는 다음 쿼리를 실행합니다.

   ```
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid < 100000;
   ```

1. RSQL 창 1에서 WLM\$1QUEUE\$1STATE\$1VW 및 WLM\$1QUERY\$1STATE\$1VW에 대한 쿼리를 실행하여 결과를 앞선 결과와 비교합니다.

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (querytype:any)                           |     5 | 836 |        0 |  false | false   |      0 |         2 |      163
                           
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    1267 |     1 |          1 | 2014-09-24 22:22:30 | Executing | 0          | 684
    1265 |     1 |          1 | 2014-09-24 22:22:36 | Executing | 0          | 4080859
   ```

이전 쿼리와 이번 단계의 결과가 다음과 같이 다른 점을 확인하세요.
+ 이제 WLM\$1QUERY\$1STATE\$1VW에는 행이 2개 있습니다. 결과 하나는 이 뷰에 대한 SELECT 작업을 실행하는 데 필요한 자기 참조적 쿼리입니다. 두 번째 결과는 이전 단계의 장기 실행 쿼리입니다.
+ WLM\$1QUEUE\$1STATE\$1VW에서 executing 열이 1에서 2로 증가했습니다. 이 열의 입력 항목은 대기열에서 실행 중인 쿼리가 2개라는 것을 의미합니다.
+ executed 열은 대기열에서 쿼리를 실행할 때마다 일정하게 증가합니다.

WLM\$1QUEUE\$1STATE\$1VW 뷰는 대기열을 비롯해 각 대기열에서 처리 중인 쿼리 수를 전체적으로 살펴보는 데 유용합니다. WLM\$1QUERY\$1STATE\$1VW 뷰는 현재 실행 중인 개별 쿼리를 더욱 자세히 살펴보는 데 유용합니다.

## 섹션 2: WLM 쿼리 대기열 구성의 수정
<a name="tutorial-wlm-modifying-wlm-configuration"></a>

대기열의 기본적인 동작에 대해 이해하였므로 이제 수동 WLM을 사용하여 쿼리 대기열을 구성하는 방법에 대해 알아봅니다. 이번 섹션에서는 새로운 파라미터 그룹을 생성하여 클러스터에 구성합니다. 또한 사용자 대기열을 2개 더 생성한 후 쿼리의 사용자 그룹 또는 쿼리 그룹 레이블에 따라 쿼리를 허용하도록 구성합니다. 이 두 대기열 중 하나로 라우팅되지 않는 쿼리는 실행 시간에 기본 대기열로 라우팅됩니다.

**파라미터 그룹의 수동 WLM 구성을 생성하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)에서 Amazon Redshift 콘솔을 엽니다.

1. 탐색 메뉴에서 **구성(Configurations)** 및 **워크로드 관리(Workload management)**를 차례로 선택하여 **워크로드 관리(Workload management)** 페이지를 표시합니다.

1. **생성**을 선택하여 **파라미터 그룹 생성** 창을 표시합니다.

1. **파라미터 그룹 이름**과 **설명** 모두에 대해 **WLMTutorial**을 입력한 다음 **생성**을 선택하여 파라미터 그룹을 생성합니다.
**참고**  
**파라미터 그룹 이름**은 생성 시 모두 소문자 형식으로 변환됩니다.

1. **워크로드 관리** 페이지에서 파라미터 그룹 **wlmtutorial**을 선택하여 **파라미터** 및 **워크로드 관리** 탭이 있는 세부 정보 페이지를 표시합니다.

1. **워크로드 관리** 탭에 있는지 확인한 후 **Switch WLM mode(WLM 모드 전환)**를 선택하여 **Concurrency settings(동시성 설정)** 창을 표시합니다.

1. **Manual WLM(수동 WLM)**을 선택한 다음 **저장**을 선택하여 수동 WLM으로 전환합니다.

1. **Edit workload queues(워크로드 대기열 편집)**를 선택합니다.

1. **대기열 추가**를 두 번 선택하여 대기열을 두 개 추가합니다. 이제 **대기열 1**, **대기열 2** 및 **기본 대기열**이 있습니다.

1. 다음과 같이 각 대기열에 대한 정보를 입력합니다.
   + [**대기열 1(Queue 1)**]의 경우 [**메모리(%)Memory (%)**]에 대해 **30**, [**기본의 동시성(Concurrency on main)**]에 대해 **2**, [**쿼리 그룹(Query groups)**]에 대해 **test**를 입력합니다. 기타 설정은 기본값을 유지합니다.
   + [**대기열 2(Queue 2)**]의 경우 [**메모리(%)Memory (%)**]에 대해 **40**, [**기본의 동시성(Concurrency on main)**]에 대해 **3**, [**사용자 그룹(User groups)**]에 대해 **admin**를 입력합니다. 기타 설정은 기본값을 유지합니다.
   + 기본 대기열의 **기본 값에 대한 동시성**을 1보다 크거나 같은 값으로 설정합니다. **기본 대기열**은 그 외에 아무것도 바꾸지 마세요. WLM은 기본 대기열에 미할당 메모리를 할당합니다.

1. 설정을 저장하려면 **저장**을 선택합니다.

그런 다음 수동 WLM 구성이 있는 파라미터 그룹을 클러스터와 연결합니다.

**수동 WLM 구성이 있는 파라미터 그룹을 클러스터와 연결하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)에서 Amazon Redshift 콘솔을 엽니다.

1. 탐색 메뉴에서 **클러스터(Clusters)**를 선택하고 **클러스터(Clusters)**를 선택하여 클러스터 목록을 표시합니다.

1. `examplecluster`와 같은 클러스터를 선택하여 클러스터의 세부 정보를 표시합니다. 그런 다음 [**속성(Properties)**] 탭을 선택하여 해당 클러스터의 속성을 표시합니다.

1. [**데이터베이스 구성(Database configurations)**] 섹션에서 [**편집(Edit)**], [**파라미터 그룹 편집(Edit parameter group)**]을 클릭하여 파라미터 그룹 창을 표시합니다.

1. [**파라미터 그룹 수(Parameter groups)**]에 대해 이전에 생성한 **wlmtutorial** 파라미터 그룹을 선택합니다.

1. [**변경 사항 저장(Save changes)**]을 선택하여 파라미터 그룹을 연결합니다.

   변경된 파라미터 그룹으로 클러스터가 수정됩니다. 그러나 데이터베이스에 변경 사항을 적용하려면 클러스터를 재부팅해야 합니다.

1. 클러스터를 선택한 [**작업(Actions)**]에 대해 [**재부팅(Reboot)**]을 선택합니다.

클러스터가 재부팅되면 상태가 **사용 가능**으로 돌아옵니다.

## 섹션 3: 사용자 그룹 및 쿼리 그룹을 기반으로 쿼리를 대기열로 라우팅
<a name="tutorial-wlm-routing-queries-to-queues"></a>

이제 클러스터를 새로운 파라미터 그룹과 연결했고 WLM을 구성했습니다. 다음으로 몇 가지 쿼리를 실행하여 Amazon Redshift가 처리를 위해 쿼리를 대기열로 라우팅하는 방법에 대해 알아봅니다.

### 1단계: 데이터베이스에서 쿼리 대기열 구성 보기
<a name="tutorial-wlm-view-query-config"></a>

먼저 데이터베이스에 원하는 WLM 구성이 있는지 확인합니다.

#### 쿼리 대기열 구성을 보려면
<a name="how-to-wlm-view-query-config"></a>

1. RSQL을 열고 다음 쿼리를 실행합니다. 쿼리는 [1단계: WLM\$1QUEUE\$1STATE\$1VW 뷰 생성](#tutorial-wlm-create-queue-state-view)에서 생성한 WLM\$1QUEUE\$1STATE\$1VW 뷰를 사용합니다. 클러스터 재부팅 이전에 세션이 이미 데이터베이스에 연결되어 있다면 다시 연결해야 합니다.

   ```
   select * from wlm_queue_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        0
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        0
   ```

   위 결과를 [1단계: WLM\$1QUEUE\$1STATE\$1VW 뷰 생성](#tutorial-wlm-create-queue-state-view)에서 나온 결과와 비교합니다. 여기에서는 대기열 2개가 추가된 것을 알 수 있습니다. 대기열 1은 테스트 쿼리 그룹을 위한 대기열이고, 대기열 2는 관리자 사용자 그룹을 위한 대기열입니다.

   대기열 3은 이제 기본 대기열입니다. 목록에서 마지막 대기열은 항상 기본 대기열입니다. 즉 쿼리에서 사용자 그룹 또는 쿼리 그룹을 따로 지정하지 않으면 쿼리가 기본적으로 라우팅되는 대기열을 말합니다.

1. 다음 쿼리를 실행하여 쿼리가 대기열 3에서 실행되는지 확인합니다.

   ```
   select * from wlm_query_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2144 |     3 |          1 | 2014-09-24 23:49:59 | Executing | 0          | 550430
   ```

### 2단계: 쿼리 그룹 대기열을 사용하여 쿼리 실행
<a name="tutorial-wlm-query-group"></a>

#### 쿼리 그룹 대기열을 사용하여 쿼리를 실행하려면
<a name="how-to-wlm-query-group"></a>

1. 다음 쿼리를 실행하여 `test` 쿼리 그룹으로 라우팅합니다.

   ```
   set query_group to test;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. 나머지 RSQL 창에서 다음 쿼리를 실행합니다.

   ```
   select * from wlm_query_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2168 |     1 |          1 | 2014-09-24 23:54:18 | Executing | 0          | 6343309
    2170 |     3 |          1 | 2014-09-24 23:54:24 | Executing | 0          | 847
   ```

   쿼리가 테스트 쿼리 그룹인 대기열 1로 라우팅되었습니다.

1. 대기열 상태 뷰에서 모두 선택합니다.

   ```
   select * from wlm_queue_state_vw;
   ```

   다음과 같은 결과가 출력됩니다.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         1 |        0
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        0
   ```

1. 이제 쿼리 그룹을 재설정한 후 장기(long) 쿼리를 다시 실행합니다.

   ```
   reset query_group;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. 두 뷰에 대한 쿼리를 실행하여 결과를 확인합니다.

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        1
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         2 |        5
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2186 |     3 |          1 | 2014-09-24 23:57:52 | Executing | 0          | 649
    2184 |     3 |          1 | 2014-09-24 23:57:48 | Executing | 0          | 4137349
   ```

   결과는 위와 같이 쿼리가 다시 대기열 3에서 실행되고 있는 모습이어야 합니다.

### 3단계: 데이터베이스 사용자 및 그룹 생성
<a name="tutorial-wlm-create-db-user-and-group"></a>

이 대기열에서 쿼리를 실행하려면 먼저 사용자 그룹을 데이터베이스에 생성한 후 사용자를 그룹에 추가해야 합니다. 그런 다음 새로운 사용자의 자격 증명을 사용해 RSQL에 로그인하여 쿼리를 실행합니다. 데이터베이스 사용자를 생성하려면 관리자와 같은 슈퍼 사용자 권한으로 쿼리를 실행해야 합니다.

#### 새로운 데이터베이스 사용자와 사용자 그룹을 생성하려면
<a name="how-to-wlm-create-db-user-and-group"></a>

1. RSQL 창에서 다음 명령을 실행하여 `adminwlm`이라는 이름의 새로운 데이터베이스 사용자를 데이터베이스에 생성합니다.

   ```
   create user adminwlm createuser password '123Admin';
   ```

1. 그러고 나서 다음 명령을 실행하여 새로운 사용자 그룹을 생성한 후 새로운 `adminwlm` 사용자를 그룹에 추가합니다.

   ```
   create group admin;
   alter group admin add user adminwlm;
   ```

### 4단계: 사용자 그룹 대기열을 사용하여 쿼리 실행
<a name="tutorial-wlm-user-group-query"></a>

다음으로 쿼리를 실행하여 사용자 그룹 대기열에 라우팅합니다. 이는 실행할 쿼리 유형을 처리하도록 구성된 대기열에 쿼리를 라우팅할 때 필요합니다.

#### 사용자 그룹 대기열을 사용하여 쿼리를 실행하려면
<a name="how-to-wlm-user-group-query"></a>

1. RSQL 창 2에서 다음 쿼리를 실행하여 `adminwlm` 계정으로 전환한 후 해당 사용자 권한으로 쿼리를 실행합니다.

   ```
   set session authorization 'adminwlm';
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. RSQL 창 1에서 다음 쿼리를 실행하여 쿼리가 라우팅되는 대기열을 확인합니다.

   ```
   select * from wlm_query_state_vw;
   select * from wlm_queue_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        1
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        8
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2202 |     2 |          1 | 2014-09-25 00:01:38 | Executing | 0          | 4885796
    2204 |     3 |          1 | 2014-09-25 00:01:43 | Executing | 0          | 650
   ```

   이 쿼리가 실행된 대기열은 2번인 `admin` 사용자 대기열입니다. 이제 앞으로 이 사용자 권한으로 로그인하여 쿼리를 실행할 때마다 다른 쿼리 그룹을 지정하지 않는 한 대기열 2에서 쿼리가 실행됩니다. 선택한 대기열은 대기열 할당 규칙에 따라 달라집니다. 자세한 내용은 [WLM 대기열 할당 규칙](cm-c-wlm-queue-assignment-rules.md) 섹션을 참조하세요.

1. 이제 RSQL 창 2에서 다음 쿼리를 실행합니다.

   ```
   set query_group to test;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. RSQL 창 1에서 다음 쿼리를 실행하여 쿼리가 라우팅되는 대기열을 확인합니다.

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         1 |        1
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        1
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       10
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2218 |     1 |          1 | 2014-09-25 00:04:30 | Executing | 0          | 4819666
    2220 |     3 |          1 | 2014-09-25 00:04:35 | Executing | 0          | 685
   ```

1. 모두 마친 후에는 쿼리 그룹을 재설정합니다.

   ```
   reset query_group;
   ```

## 섹션 4: wlm\$1query\$1slot\$1count를 사용하여 대기열에서 동시성 레벨을 임시로 재정의
<a name="tutorial-wlm-query-slot-count"></a>

간혹 사용자들은 특정 쿼리에서 일시적으로 리소스가 더 필요한 경우도 있습니다. 이때는 wlm\$1query\$1slot\$1count 구성 설정을 사용하여 쿼리 대기열에 대한 슬롯 할당 방식을 일시적으로 재정의할 수 있습니다. 여기에서 *슬롯*이란 쿼리를 처리하는 데 사용되는 메모리 단위이자 CPU를 말합니다. 간혹 데이터베이스의 VACUUM 작업처럼 클러스터에서 많은 리소스가 필요한 쿼리를 실행할 때는 슬롯 수를 재정의할 수 있습니다.

간혹 특정 쿼리 유형에 맞춰 wlm\$1query\$1slot\$1count를 설정해야 하는 사용자가 있을 수 있습니다. 그런 경우 WLM 구성을 조정하여 해당 사용자의 쿼리 요건에 더욱 적합한 대기열을 제공할 수 있습니다. 슬롯 수를 사용하여 동시성 수준을 일시적으로 재정의하는 방법에 대한 자세한 내용은 [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) 섹션을 참조하세요.

### 1단계: wlm\$1query\$1slot\$1count를 사용하여 동시성 레벨 재정의
<a name="tutorial-wlm-override-slot-count"></a>

본 자습서의 목적에 따라 이번에도 장기간 실행되는 SELECT 쿼리를 실행합니다. `adminwlm` 사용자 권한으로 이 쿼리를 실행하면서 wlm\$1query\$1slot\$1count를 사용해 쿼리에 사용할 수 있는 슬롯 수를 늘릴 것입니다.

#### wlm\$1query\$1slot\$1count를 사용하여 동시성 레벨을 재정의하려면
<a name="how-to-wlm-override-slot-count"></a>

1. WLM\$1QUERY\$1STATE\$1VW 뷰에 대한 쿼리를 실행하여 결과까지 충분히 볼 수 있도록 쿼리에 대한 제한을 높입니다.

   ```
   set wlm_query_slot_count to 3; 
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. 이제 관리자 계정을 사용하여 WLM\$1QUERY\$1STATE\$1VW에 대한 쿼리를 실행하고 쿼리가 어떻게 실행되고 있는지 확인합니다.

   ```
   select * from wlm_query_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2240 |     2 |          1 | 2014-09-25 00:08:45 | Executing | 0          | 3731414
    2242 |     3 |          1 | 2014-09-25 00:08:49 | Executing | 0          | 596
   ```

   쿼리의 슬롯 수는 현재 3개입니다. 이 수는 쿼리가 슬롯 3개를 모두 사용하여 쿼리를 처리하면서 대기열의 모든 리소스를 해당 쿼리에 할당하고 있다는 것을 의미합니다.

1. 이제 다음 쿼리를 실행합니다.

   ```
   select * from WLM_QUEUE_STATE_VW;
   ```

   다음은 예 결과입니다.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        4
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        3
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       25
   ```

   wlm\$1query\$1slot\$1count 구성 설정은 현재 세션에서만 유효합니다. 이 세션이 종료되거나 다른 사용자가 쿼리를 실행할 경우에는 WLM 구성이 사용됩니다.

1. 슬롯 수를 재설정한 후 테스트를 다시 실행합니다.

   ```
   reset wlm_query_slot_count;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

   다음은 예 결과입니다.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        2
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        2
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       14
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2260 |     2 |          1 | 2014-09-25 00:12:11 | Executing | 0          | 4042618
    2262 |     3 |          1 | 2014-09-25 00:12:15 | Executing | 0          | 680
   ```

### 2단계: 다른 세션에서 쿼리 실행
<a name="tutorial-wlm-run-queries-from-different-sessions"></a>

이제는 다른 세션에서 쿼리를 실행합니다.

#### 다른 세션에서 쿼리를 실행하려면
<a name="how-to-wlm-run-queries-from-different-sessions"></a>

1. RSQL 창 1 및 2에서 다음과 같이 실행하여 테스트 쿼리 그룹을 사용합니다.

   ```
   set query_group to test;
   ```

1. RSQL 창 1에서 다음 장기(long-running) 쿼리를 실행합니다.

   ```
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. 장기 쿼리가 여전히 RSQL 창 1에서 실행되고 있을 때 다음을 실행합니다. 이러한 명령은 대기열의 슬롯을 모두 사용할 수 있도록 슬롯 수를 높인 다음 장기 쿼리를 시작합니다.

   ```
   set wlm_query_slot_count to 2;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. 세 번째 RSQL 창을 열고 뷰에 대한 쿼리를 실행하여 결과를 확인합니다.

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   다음은 예 결과입니다.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      1 |         1 |        2
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        3
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       18
    
   query | queue | slot_count | start_time          | state         | queue_time | exec_time
   ------+-------+------------+---------------------+---------------+------------+-----------
    2286 |     1 |          2 | 2014-09-25 00:16:48 | QueuedWaiting | 3758950    | 0
    2282 |     1 |          1 | 2014-09-25 00:16:33 | Executing     | 0          | 19335850
    2288 |     3 |          1 | 2014-09-25 00:16:52 | Executing     | 0          | 666
   ```

   첫 번째 쿼리는 대기열 1에 할당된 슬롯 중 하나를 사용하여 쿼리를 실행합니다. 또한 대기열에서 대기 중인 쿼리가 하나 있습니다(여기에서 `queued`는 `1`이고 `state`는 `QueuedWaiting`임). 첫 번째 쿼리가 실행을 마치면 두 번째 쿼리가 실행을 시작합니다. 이렇게 실행되는 이유는 두 쿼리가 모두 `test` 쿼리 그룹으로 라우팅되었기 때문이며, 두 번째 쿼리는 처리를 시작할 정도로 충분한 수의 슬롯이 나올 때까지 대기해야 합니다.

## 섹션 5: 리소스 정리
<a name="tutorial-wlm-cleaning-up-resources"></a>

클러스터는 실행하는 동안 계속해서 요금이 발생합니다. 이 튜토리얼을 마치면 *Amazon Redshift 시작 안내서*의 [추가 리소스 찾기 및 환경 재설정](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html) 단계에 따라 환경을 이전 상태로 되돌립니다.

WLM에 대한 자세한 내용은 [워크로드 관리](cm-c-implementing-workload-management.md) 섹션을 참조하세요.

# 동시성 확장
<a name="concurrency-scaling"></a>

동시성 확장 기능을 사용하면 일관성 있게 빠른 쿼리 성능으로 수많은 동시 사용자 및 동시 쿼리를 지원할 수 있습니다. 동시성 크기 조정을 설정하면 Amazon Redshift가 자동으로 클러스터 용량을 추가하여 읽기 및 쓰기 쿼리의 증가를 처리합니다. 쿼리가 기본 클러스터에서 실행되든 동시성 조정 클러스터에서 실행되든 사용자에게는 최신 데이터가 보입니다.

WLM 대기열을 구성하여 동시성 조정 클러스터에 보낸 쿼리를 관리할 수 있습니다. 동시성 조정을 설정하면 대기열에서 기다리는 대신 적합한 쿼리가 동시성 조정 클러스터로 전송됩니다.

동시성 조정 클러스터가 쿼리를 활발하게 실행하는 시간에 대해서만 요금이 부과됩니다. 요금이 부과되는 방식 및 최소 요금 등 요금에 대한 자세한 내용은 [동시성 크기 조정 요금](https://aws.amazon.com/redshift/pricing/#Concurrency_Scaling_pricing)을 참조하세요.

**Topics**
+ [동시성 조정 기능](#concurrency-scaling-capabilities)
+ [동시성 조정에 대한 제한 사항](#concurrency-scaling-limitations)
+ [AWS 리전동시성 조정 지원](#concurrency-scaling-regions)
+ [동시성 확장 대상](#concurrency-scaling-candidates)
+ [동시성 확장 대기열 구성](#concurrency-scaling-queues)
+ [동시성 확장 모니터링](#concurrency-scaling-monitoring)
+ [동시성 확장 시스템 뷰](#concurrency-scaling-monitoring-system-views)

## 동시성 조정 기능
<a name="concurrency-scaling-capabilities"></a>

WLM 대기열에 대한 동시성 조정을 설정하면 대시보드 쿼리와 같은 읽기 작업에 사용할 수 있습니다. 또한 데이터 수집 및 처리를 위한 문과 같이 일반적으로 사용되는 쓰기 작업에도 사용할 수 있습니다.

### 쓰기 작업에 대한 동시성 조정 기능
<a name="concurrency-scaling-capabilities-write-operations"></a>

동시성 조정은 추출, 변환 및 로드(ETL) 문과 같이 자주 사용하는 쓰기 작업을 지원합니다. 쓰기 작업에 대한 동시성 조정은 클러스터가 많은 수의 요청을 수신할 때 일관된 응답 시간을 유지하려는 경우 특히 유용합니다. 기본 클러스터의 리소스를 놓고 경합하는 쓰기 작업의 처리량을 향상시킵니다.

동시성 규모 조정은 COPY, INSERT, DELETE, UPDATE, CREATE TABLE AS(CTAS) 및 VACUUM 문을 지원합니다. 또한 동시성 규모 조정은 구체화된 뷰(MV)의 수동 새로 고침과 자동 정리 작업을 지원합니다. 다른 데이터 조작 언어(DML) 문 및 데이터 정의 언어(DDL) 문은 지원되지 않습니다. TABLE AS가 없는 CREATE와 같이 지원되지 않는 쓰기 문이 지원되는 쓰기 문보다 먼저 명시적 트랜잭션에 포함되면 동시성 조정 클러스터에서는 쓰기 문이 아무것도 실행되지 않습니다.

동시성 조정을 위해 크레딧을 누적하면 이 크레딧 누적은 읽기 및 쓰기 작업 모두에 적용됩니다.

## 동시성 조정에 대한 제한 사항
<a name="concurrency-scaling-limitations"></a>

 다음은 Amazon Redshift 동시성 조정 사용에 대한 제한 사항입니다.
+ 인터리브 정렬 키를 사용하는 테이블에 대한 쿼리를 지원하지 않습니다.
+ 임시 테이블에 대한 쿼리를 지원하지 않습니다.
+ 제한적인 네트워크 또는 Virtual Private Cloud(VPC) 구성으로 보호되는 외부 리소스에 액세스하는 쿼리를 지원하지 않습니다.
+ Python 사용자 정의 함수(UDF) 및 람다 UDF가 포함된 쿼리를 지원하지 않습니다.
+ 시스템 테이블, PostgreSQL 카탈로그 테이블 또는 비백업 테이블에 액세스하는 쿼리를 지원하지 않습니다.
+ 제한적인 IAM 정책 권한이 있는 경우 외부 리소스에 액세스하는 COPY 또는 UNLOAD 쿼리는 지원하지 않습니다. 여기에는 Amazon S3 버킷 또는 DynamoDB 테이블과 같은 리소스 또는 소스에 적용되는 권한이 포함됩니다. IAM 소스에는 다음이 포함될 수 있습니다.
  + `aws:sourceVpc` – 소스 VPC입니다.
  + `aws:sourceVpce` - 소스 VPC 엔드포인트입니다.
  + `aws:sourceIp` - 소스 IP 주소입니다.

  경우에 따라 리소스에 액세스하는 COPY 및 UNLOAD 쿼리가 동시성 조정 클러스터로 전송되도록 리소스 또는 소스를 제한하는 권한을 제거해야 할 수 있습니다.

   리소스 정책에 대한 자세한 내용은 AWS Identity and Access Management 사용 설명서의 [정책 유형](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policy-types) 및 [버킷 정책을 사용하여 VPC 엔드포인트에서 액세스 제어](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html)를 참조하세요.
+ 쓰기 작업에 대한 Amazon Redshift Concurrency Scaling은 CREATE TABLE 같은 대부분의 DDL 작업에 대해 지원되지 않습니다.
+ COPY 명령에 대해 ANALYZE를 지원하지 않습니다.
+ DISTSTYLE이 ALL로 설정된 대상 테이블에 대한 쓰기 작업을 지원하지 않습니다.
+ 다음 파일 형식에서 COPY는 지원하지 않습니다.
  + Parquet
  + ORC
+ 자격 증명 열이 있는 테이블에 대한 쓰기 작업을 지원하지 않습니다.
+ Amazon Redshift는 Amazon Redshift RA3 노드에서만 쓰기 작업에 대한 동시성 규모 조정을 지원합니다. 쓰기 작업에 대한 동시성 조정은 다른 노드 유형에서 지원되지 않습니다.

## AWS 리전동시성 조정 지원
<a name="concurrency-scaling-regions"></a>

Amazon Redshift를 사용하면 동시성 규모 조정을 사용하여 Redshift 클러스터 전반에서 동시 워크로드 수요를 관리할 수 있습니다. 이 주제에서는 Amazon Redshift로 동시성 규모 조정을 사용할 수 있는 리전에 대해 자세히 설명합니다.

다음 AWS 리전에서 동시성 크기 조정을 사용할 수 있습니다.
+ 미국 동부(버지니아 북부) 리전(us-east-1)
+ 미국 동부(오하이오) 리전(us-east-2)
+ 미국 서부(캘리포니아 북부) 리전(us-west-1)
+ 미국 서부(오레곤) 리전(us-west-2) 
+ 아프리카(케이프타운) 리전(af-south-1)
+ 아시아 태평양(뭄바이) 리전(ap-south-1)
+ 아시아 태평양(하이데라바드) 리전(ap-south-2)
+ 아시아 태평양(서울) 리전(ap-northeast-2)
+ 아시아 태평양(오사카) 리전(ap-northeast-3)
+ 아시아 태평양(싱가포르) 리전(ap-southeast-1)
+ 아시아 태평양(시드니) 리전(ap-southeast-2)
+ 아시아 태평양(자카르타) 리전(ap-southeast-3)
+ 아시아 태평양(말레이시아) 리전(ap-southeast-5)
+ 아시아 태평양(뉴질랜드) 리전(ap-southeast-6)
+ 아시아 태평양(태국) 리전(ap-southeast-7)
+ 아시아 태평양(홍콩) 리전(ap-east-1)
+ 아시아 태평양(타이베이) 리전(ap-east-2)
+ 아시아 태평양(도쿄) 리전(ap-northeast-1)
+ 캐나다(중부) 리전(ca-central-1)
+ 캐나다 서부(캘거리) 리전(ca-west-1)
+ 중국(베이징) 리전(cn-north-1)
+ 중국(닝샤) 리전(cn-northwest-1)
+ 유럽(프랑크푸르트) 리전(eu-central-1)
+ 유럽(아일랜드) 리전(eu-west-1)
+ 유럽(런던) 리전(eu-west-2)
+ 유럽(파리) 리전(eu-west-3)
+ 유럽(스톡홀름) 리전(eu-north-1) 
+ 유럽(취리히) 리전(eu-central-2) 
+ 유럽(밀라노) 리전(eu-south-1) 
+ 유럽(스페인) 리전(eu-south-2) 
+ 이스라엘(텔아비브) 리전(il-central-1) 
+ 중동(바레인) 리전(me-south-1) 
+ 멕시코(중부) 리전(mx-central-1)
+ 남아메리카(상파울루) 리전(sa-east-1)
+ AWS GovCloud(미국 동부)
+ AWS GovCloud(미국 서부)

## 동시성 확장 대상
<a name="concurrency-scaling-candidates"></a>

Amazon Redshift를 사용하면 쿼리 처리를 스케일 아웃하여 동시 쿼리 실행을 가속화할 수 있습니다. 다음 주제에서는 Amazon Redshift가 동시성 규모 조정으로 라우팅할 쿼리를 결정하는 데 사용하는 기준에 대해 알아봅니다.

기본 클러스터가 다음 요구 사항을 충족하는 경우에만 쿼리가 동시성 확장 클러스터로 라우팅됩니다.
+ EC2-VPC 플랫폼 
+ 노드 유형은 dc2.8xlarge, dc2.large, ra3.large, ra3.xlplus, ra3.4xlarge, ra3.16xlarge이어야 합니다. 쓰기 작업용 동시성 규모 조정은 Amazon Redshift RA3 노드에서만 지원됩니다.
+ 노드 유형이 ra3.xlplus, ra3.4xlarge 또는 ra3.16xlarge인 클러스터의 경우 최대 32개의 컴퓨팅 노드가 허용됩니다. 또한 클러스터를 처음 생성할 때 기본 클러스터의 노드 수는 32개를 초과할 수 없습니다. 예를 들어 현재 클러스터에 20개의 노드가 있지만 원래 40개로 생성된 경우에도 동시성 확장에 대한 요구 사항을 충족하지 않습니다. 반대로 현재 DC2 클러스터에 40개의 노드가 있지만 원래 20개로 생성된 경우 동시성 확장에 대한 요구 사항을 충족합니다.
+ 단일 노드 클러스터가 아닙니다.

## 동시성 확장 대기열 구성
<a name="concurrency-scaling-queues"></a>

Amazon Redshift를 사용하면 동시성 규모 조정을 구성하여 동시성 및 시스템 리소스를 관리할 수 있습니다. 동시성 규모 조정 대기열을 통해 동시에 실행할 수 있는 쿼리 또는 사용자 세션 수에 대해 제한을 설정하는 것이 가능합니다. 다음 섹션에서는 Amazon Redshift에서 동시성 규모 조정 대기열을 사용하여 동시 쿼리 및 사용자 세션을 효과적으로 처리할 수 있는 방법에 대한 설명을 제공합니다.

워크로드 관리자(WLM) 대기열에서 동시성 확장을 사용하도록 설정하여 쿼리를 동시성 확장 클러스터로 라우팅합니다. 대기열에 대해 동시성 조정을 설정하려면 [**동시성 조정 모드(Concurrency Scaling mode)**] 값을 [**자동(auto)**]으로 설정합니다.

동시성 확장이 활성화된 대기열로 라우팅되는 쿼리 수가 대기열의 동시성 용량을 초과하면, 용량이 수동으로 구성되었든 자동으로 결정되었든 상관없이 적격 쿼리가 동시성 확장 클러스터로 전송됩니다. 기본 클러스터에서 대기열 슬롯을 사용할 수 있게 되면 쿼리가 기본 클러스터로 라우팅되어 실행됩니다. 다른 WLM 대기열과 마찬가지로 사용자 그룹을 기준으로 또는 쿼리 그룹 레이블을 사용하여 쿼리에 레이블을 지정하거나 [쿼리를 대기열에 할당](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-executing-queries.html)에서 정의한 일치 조건에 따라 쿼리를 동시성 확장 대기열로 라우팅합니다. 또한 [WLM 쿼리 모니터링 규칙](cm-c-wlm-query-monitoring-rules.md)을 정의하여 쿼리를 라우팅할 수 있습니다. 예를 들어 5초보다 오래 걸리는 모든 쿼리를 동시성 확장 대기열로 라우팅할 수 있습니다. 대기열 동작은 자동 WLM을 사용하는지 수동 WLM을 사용하는지에 따라 달라질 수 있다는 점에 유의하세요. 자세한 내용은 [자동 WLM 구현](https://docs.aws.amazon.com/redshift/latest/dg/automatic-wlm.html) 또는 [수동 WLM 구현](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-defining-query-queues.html)을 참조하세요.

동시성 확장 클러스터의 기본 수는 1입니다. 사용할 수 있는 동시성 확장 클러스터 수는 [max\$1concurrency\$1scaling\$1clusters](r_max_concurrency_scaling_clusters.md)에서 제어합니다.

## 동시성 확장 모니터링
<a name="concurrency-scaling-monitoring"></a>

Amazon Redshift를 사용하면 동시성 규모 조정을 모니터링하고 관리하여 데이터 웨어하우징 워크로드의 성능과 비용 효율성을 최적화할 수 있습니다. 동시성 규모 조정을 통해 Amazon Redshift는 워크로드 수요가 증가할 경우 클러스터 용량을 자동으로 추가하고 수요가 줄어들 경우 해당 용량을 제거할 수 있습니다. 다음 섹션에서는 Amazon Redshift 클러스터의 동시성 규모 조정 모니터링에 대한 가이드를 제공합니다.

쿼리가 기본 클러스터에서 실행 중인지 아니면 동시성 조정 클러스터에서 실행 중인지 확인하려면 Amazon Redshift 콘솔에서 **클러스터**로 이동한 후 클러스터를 선택합니다. 그런 다음 **쿼리 모니터링** 탭과 **워크로드 동시성**을 선택하여 실행 중인 쿼리와 대기 중인 쿼리에 대한 정보를 확인합니다.

실행 시간을 찾으려면 `concurrency_scaling_status` 열에서 STL\$1QUERY 테이블 및 필터를 쿼리합니다. 다음 쿼리는 동시성 확장 클러스터에서 실행한 쿼리 및 기본 클러스터에서 실행한 쿼리에 대한 대기열 시간 및 실행 시간을 비교합니다.

```
SELECT w.service_class AS queue
, CASE WHEN q.concurrency_scaling_status = 1 THEN 'concurrency scaling cluster' ELSE 'main cluster' END as concurrency_scaling_status
, COUNT( * ) AS queries
, SUM( q.aborted ) AS aborted
, SUM( ROUND( total_queue_time::NUMERIC / 1000000,2) ) AS queue_secs
, SUM( ROUND( total_exec_time::NUMERIC / 1000000,2) ) AS exec_secs
FROM stl_query q
JOIN stl_wlm_query w
USING (userid,query)
WHERE q.userid > 1
AND q.starttime > '2019-01-04 16:38:00'
AND q.endtime < '2019-01-04 17:40:00'
GROUP BY 1,2
ORDER BY 1,2;
```

요구 사항에 따라 `starttime` 및 `endtime` 값을 조정합니다.

## 동시성 확장 시스템 뷰
<a name="concurrency-scaling-monitoring-system-views"></a>

Amazon Redshift를 사용하면 동시성 규모 조정 시스템 뷰 기능으로 클러스터의 동시성 규모 조정 활동을 모니터링 및 관리할 수 있습니다. 다음 섹션에서는 이러한 시스템 뷰를 쿼리하고 결과를 해석하여 Amazon Redshift 환경에서 동시성 스케일 인을 효과적으로 활용하는 방법에 대해 설명합니다.

접두사가 SVCS인 시스템 뷰 집합은 기본 클러스터와 동시성 확장 클러스터 모두의 쿼리에 대한 시스템 로그 테이블의 세부 정보를 제공합니다.

다음 뷰의 정보는 해당되는 STL 뷰 또는 SVL 뷰의 정보와 유사합니다.
+ [SVCS\$1ALERT\$1EVENT\$1LOG](r_SVCS_ALERT_EVENT_LOG.md) 
+ [SVCS\$1COMPILE](r_SVCS_COMPILE.md) 
+ [SVCS\$1EXPLAIN](r_SVCS_EXPLAIN.md) 
+ [SVCS\$1PLAN\$1INFO](r_SVCS_PLAN_INFO.md) 
+ [SVCS\$1QUERY\$1SUMMARY](r_SVCS_QUERY_SUMMARY.md) 
+ [SVCS\$1STREAM\$1SEGS](r_SVCS_STREAM_SEGS.md) 

다음 뷰는 동시성 확장에 고유한 뷰입니다.
+ [SVCS\$1CONCURRENCY\$1SCALING\$1USAGE](r_SVCS_CONCURRENCY_SCALING_USAGE.md) 

동시성 조정에 대한 자세한 내용은 *Amazon Redshift 관리 가이드*의 다음 주제를 참조하세요.
+ [동시성 확장 데이터 보기](https://docs.aws.amazon.com/redshift/latest/mgmt/performance-metrics-concurrency-scaling.html) 
+ [쿼리 실행 중 클러스터 성능 보기](https://docs.aws.amazon.com/redshift/latest/mgmt/performance-metrics-query-cluster.html) 
+ [쿼리 세부 정보 보기](https://docs.aws.amazon.com/redshift/latest/mgmt/performance-metrics-query-execution-details.html) 

# 단기 쿼리 가속화
<a name="wlm-short-query-acceleration"></a>

단기 쿼리 가속화(SQA)는 선택한 단기 실행 쿼리를 장기 실행 쿼리보다 우선적으로 적용합니다. SQA 쿼리가 대기열에서 장기 쿼리 뒤에서 대기해야 하지 않도록 SQA는 전용 공간에서 단기 실행 쿼리를 실행합니다. SQA는 단기 실행되고 사용자 정의 대기열에 있는 쿼리에만 우선순위를 부여합니다. SQA가 있으면 단기 실행 쿼리가 더 빠르게 실행하기 시작하며 사용자가 더 빨리 결과를 확인합니다.

SQA를 활성화하면 단기 쿼리 실행에 전용되는 워크로드 관리(WLM) 대기열을 축소할 수 있습니다. 또한 장기 실행 쿼리가 단기 실행 쿼리와 대기열의 슬롯에 대해 경합할 필요가 없으므로, 더 적은 쿼리 슬롯을 사용하도록 WLM 대기열을 구성할 수 있습니다. 더 적은 동시성을 사용하면 대부분의 워크로드에 대해 쿼리 처리량이 증가되고 전체 시스템 성능이 향상됩니다.

 [CREATE TABLE AS](r_CREATE_TABLE_AS.md)(CTAS) 문과 읽기 전용 쿼리(예: [SELECT](r_SELECT_synopsis.md) 문)는 SQA를 사용할 수 있습니다.

Amazon Redshift는 기계 학습 알고리즘으로 사용 가능한 각 쿼리를 분석하고 쿼리의 실행 시간을 예측합니다. 기본적으로 WLM은 클러스터의 워크로드를 분석한 정보에 근거하여 SQA 최대 실행 시간에 대한 값을 동적으로 지정합니다. 또는 1\$120초의 고정값을 지정할 수 있습니다. 쿼리의 예측 실행 시간이 정의되거나 동적으로 할당된 SQA의 최대 런타임보다 짧고 쿼리가 WLM 대기열에서 대기 중인 경우 SQA는 WLM 대기열에서 쿼리를 분리하고 우선 실행되도록 예약합니다. 쿼리가 SQA 최대 실행 시간보다 오래 실행되면 [WLM 대기열 할당 규칙](cm-c-wlm-queue-assignment-rules.md)에 따라 WLM은 쿼리를 첫 번째로 일치하는 WLM 대기열로 이동합니다. 시간이 지나면서 SQA가 쿼리 패턴에서 학습하면 예측이 향상합니다.

SQA는 기본 파라미터 그룹과 모든 새 파라미터 그룹에 대해 기본적으로 활성화되어 있습니다. Amazon Redshift 콘솔에서 SQA를 사용 중지하려면 파라미터 그룹에 맞게 WLM 구성을 편집하고 [**단기 쿼리 가속화 사용(Enable short query acceleration)**]을 선택 해제합니다. 모범 사례로, 최적의 전체 시스템 성능을 유지하려면 15개 이하의 WLM 쿼리 슬롯 수를 사용하는 것이 좋습니다. WLM 구성 수정에 대한 자세한 내용은 *Amazon Redshift 관리 가이드*의 [워크로드 관리 구성](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) 섹션을 참조하세요.

## 단기 쿼리의 최대 실행 시간
<a name="wlm-sqa-max-run-time"></a>

SQA를 활성화하면 WLM이 단기 쿼리에 대한 최대 실행 시간을 ‘동적(dynamic)’으로 기본 설정합니다. SQA 최대 실행 시간에 대해서는 동적 설정을 유지하는 것이 좋습니다. 1\$120초의 고정값을 지정하여 기본 설정을 재정의할 수 있습니다.

경우에 따라 시스템 성능을 개선하기 위해 SQA 최대 실행 시간에 다양한 값을 사용하는 방안을 고려할 수 있습니다. 이 경우 워크로드를 분석하여 대부분의 단기 실행 쿼리에 대한 최대 실행 시간을 확인하세요. 다음 쿼리는 약 70 백분위수에서 쿼리의 최대 실행 시간을 반환합니다.

```
select least(greatest(percentile_cont(0.7) 
within group (order by total_exec_time / 1000000) + 2, 2), 20) 
from stl_wlm_query 
where userid >= 100
and final_state = 'Completed';
```

워크로드에 효과적으로 작동하는 최대 실행 시간 값을 식별한 후에는 워크로드가 크게 변경되지 않는 한 값을 변경할 필요가 없습니다.

## SQA 모니터링
<a name="wlm-monitoring-sqa"></a>

SQA가 활성화되었는지 확인하려면 다음 쿼리를 실행합니다. 쿼리가 행을 반환하면 SQA가 활성화된 것입니다.

```
select * from stv_wlm_service_class_config 
where service_class = 14;
```

다음 쿼리는 각 쿼리 대기열(서비스 클래스)를 통해 전송된 쿼리의 수를 보여줍니다. 또한 평균 실행 시간, 90번째 퍼센타일에 대기 시간이 있는 쿼리 수, 평균 대기 시간도 보여줍니다. SQA 쿼리는 서비스 중 클래스 14를 사용합니다.

```
select final_state, service_class, count(*), avg(total_exec_time), 
percentile_cont(0.9) within group (order by total_queue_time), avg(total_queue_time) 
from stl_wlm_query where userid >= 100 group by 1,2 order by 2,1;
```

SQA에서 선택되고 성공적으로 완료된 쿼리를 찾으려면 다음 쿼리를 실행합니다.

```
select a.queue_start_time, a.total_exec_time, label, trim(querytxt) 
from stl_wlm_query a, stl_query b 
where a.query = b.query and a.service_class = 14 and a.final_state = 'Completed' 
order by b.query desc limit 5;
```

SQA에서 가져왔지만 시간이 초과된 쿼리를 확인하려면 다음 쿼리를 실행합니다.

```
select a.queue_start_time, a.total_exec_time, label, trim(querytxt) 
from stl_wlm_query a, stl_query b 
where a.query = b.query and a.service_class = 14 and a.final_state = 'Evicted' 
order by b.query desc limit 5;
```

제거된 쿼리 및 일반적으로 쿼리에 대해 수행할 수 있는 규칙 기반 작업에 대한 자세한 내용은 [WLM 쿼리 모니터링 규칙](cm-c-wlm-query-monitoring-rules.md) 섹션을 참조하세요.

# WLM 대기열 할당 규칙
<a name="cm-c-wlm-queue-assignment-rules"></a>

Amazon Redshift를 사용하면 워크로드 관리(WLM) 구성에서 대기열 할당 규칙을 정의하여 사용자 쿼리에 대한 메모리 및 CPU 리소스 할당을 제어할 수 있습니다. 다음 섹션에서는 효율적인 리소스 할당을 달성하고 Amazon Redshift의 다양한 워크로드에 대한 서비스 수준 계약을 충족하기 위해 WLM 대기열 할당 규칙을 생성 및 관리하는 방법을 설명합니다.

사용자가 쿼리를 실행하면 아래와 같이 WLM이 WLM 대기열 할당 규칙에 따라 쿼리를 첫 번째로 일치하는 대기열에 할당합니다.

1. 사용자가 수퍼유저로 로그인하여 레이블이 수퍼유저인 쿼리 그룹에서 쿼리를 실행할 경우에는 쿼리가 수퍼유저 대기열로 할당됩니다.

1. 사용자가 역할의 일부이거나, 나열된 사용자 그룹에 속하거나, 나열된 쿼리 그룹에 속한 쿼리를 실행하는 경우에는 쿼리가 첫 번째 일치하는 대기열에 할당됩니다.

1. 쿼리가 어떠한 기준과도 일치하지 않으면 WLM 구성에서 마지막에 정의되어 있는 대기열인 기본 대기열에 할당됩니다.

다음 다이어그램은 이 규칙이 작동하는 방식을 나타낸 것입니다.

![\[WLM이 대기열에 쿼리를 할당하는 데 사용하는 규칙을 보여 주는 흐름도입니다.\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/images/queue-assignment-rules-with-rbac.png)


## 쿼리 할당 예
<a name="cm-c-wlm-queue-assignment-rules-queue-assignments-example"></a>

다음 표는 수퍼유저 대기열과 사용자 정의 대기열 4개가 포함된 WLM 구성을 나타낸 것입니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/cm-c-wlm-queue-assignment-rules.html)

아래 도해는 사용자 그룹 및 쿼리 그룹에 따라 쿼리가 위 표의 대기열에 할당되는 방식을 나타낸 것입니다. 런타임에 쿼리를 사용자 그룹과 쿼리 그룹에 할당하는 방법에 대한 자세한 내용은 본 섹션 후반부의 [대기열에 쿼리 할당](cm-c-executing-queries.md) 섹션을 참조하세요.

![\[사용자 그룹 및 쿼리 그룹에 따라 대기열에 할당되는 쿼리 샘플 목록입니다.\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/images/queues-assignment-2.png)


위의 예에서 WLM의 할당 방식은 다음과 같습니다.

1. 첫 번째 문 집합은 사용자를 사용자 그룹에 할당하는 세 가지 방법을 나타냅니다. 여기에 있는 문들을 실행하는 사용자는 `adminuser`이며, WLM 대기열에 나열된 사용자 그룹의 멤버가 아닙니다. 또한 쿼리 그룹도 설정되어 있지 않기 때문에 문들이 모두 기본 대기열로 라우팅됩니다.

1. 사용자 `adminuser`가 수퍼유저이고, 쿼리 그룹이 `'superuser'`로 설정되어 있기 때문에 쿼리가 수퍼유저 대기열로 할당됩니다.

1. `test_user` 사용자가 대기열 1에 나열된 `test_db_rw` 역할에 할당되었으므로 쿼리가 대기열 1로 할당됩니다.

1. 사용자 `admin1`이 대기열 1에 나열된 사용자 그룹의 멤버이므로 쿼리가 대기열 1로 할당됩니다.

1. 사용자 `vp1`은 나열된 사용자 그룹의 멤버가 아닙니다. 또한 쿼리 그룹이 `'QG_B'`로 설정되어 있으므로 쿼리가 대기열 2로 할당됩니다.

1. 사용자 `analyst1`이 대기열 3에 나열된 사용자 그룹의 멤버이지만 `'QG_B'`가 대기열 2와 일치하므로 쿼리가 대기열 2로 할당됩니다.

1. 사용자 `ralph`가 나열된 사용자 그룹의 멤버가 아니고, 쿼리 그룹이 재설정되었으므로 일치하는 대기열이 없습니다. 따라서 쿼리는 기본 대기열로 할당됩니다.

# 대기열에 쿼리 할당
<a name="cm-c-executing-queries"></a>

Amazon Redshift를 사용하면 워크로드 동시성을 관리하고 대기열에 할당하여 쿼리의 우선순위를 지정할 수 있습니다. 대기열을 사용하면 메모리 및 CPU 등의 리소스를 다양한 유형의 쿼리 또는 사용자에 할당하여 중요도가 덜한 쿼리에 비해 중요한 쿼리에 우선순위를 지정할 수 있습니다. 다음 섹션에서는 대기열을 생성하고, 해당 속성을 구성하고, 정의한 기준에 따라 유입되는 쿼리를 할당하는 방법을 설명합니다.

다음은 사용자 역할, 사용자 그룹 및 쿼리 그룹에 따라 쿼리를 대기열에 할당하는 예입니다.

## 사용자 역할을 기반으로 대기열에 쿼리 할당
<a name="cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles"></a>

 사용자에게 역할이 할당되고 해당 역할이 큐에 연결되어 있는 경우 해당 사용자가 실행하는 쿼리가 해당 큐에 할당됩니다. 다음 예에서는 `sales_rw`라는 사용자 역할을 만들고 해당 역할에 `test_user` 사용자를 할당합니다.

```
create role sales_rw;
grant role sales_rw to test_user;
```

한 역할을 다른 역할에 명시적으로 부여하여 두 역할의 권한을 결합할 수도 있습니다. 사용자에게 중첩된 역할을 할당하면 사용자에게 두 역할의 권한이 모두 부여됩니다.

```
create role sales_rw;
create role sales_ro;
grant role sales_ro to role sales_rw;
grant role sales_rw to test_user;
```

클러스터에서 역할이 부여된 사용자 목록을 보려면 SVV\$1USER\$1GRANTS 테이블을 쿼리하세요. 클러스터에서 역할이 부여된 역할 목록을 보려면 SVV\$1ROLE\$1GRANTS 테이블을 쿼리하세요.

```
select * from svv_user_grants;
select * from svv_role_grants;
```

## 사용자 그룹을 기반으로 대기열에 쿼리 할당
<a name="cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups"></a>

사용자 그룹 이름이 대기열 정의에 나열되어 있으면 나열된 사용자 그룹의 멤버가 실행하는 쿼리는 해당 대기열에 할당됩니다. 다음은 SQL 명령([CREATE USER](r_CREATE_USER.md), [create group](r_CREATE_GROUP.md) 및 [ALTER GROUP](r_ALTER_GROUP.md))을 사용하여 사용자 그룹을 생성한 후 사용자를 그룹에 추가하는 예입니다.

```
create group admin_group with user admin246, admin135, sec555;
create user vp1234 in group ad_hoc_group password 'vpPass1234';
alter group admin_group add user analyst44, analyst45, analyst46;
```

## 쿼리 그룹에 쿼리 할당
<a name="cm-c-executing-queries-assigning-a-query-to-a-query-group"></a>

적절한 쿼리 그룹에 쿼리를 할당하여 실행 시간에 쿼리를 대기열에 할당할 수 있습니다. SET 명령을 사용하여 쿼리 그룹을 시작합니다.

```
SET query_group TO group_label             
```

여기서 *`group_label`*은 WLM 구성에 나열된 쿼리 그룹 레이블입니다.

`SET query_group` 명령 이후에 실행하는 쿼리는 모두 쿼리 그룹을 재설정하거나, 혹은 현재 로그인 세션을 종료할 때까지는 지정된 쿼리 그룹의 멤버로서 실행됩니다. Amazon Redshift 객체의 설정 및 재설정에 대한 자세한 내용은 SQL 명령 참조의 [SET](r_SET.md) 및 [reset](r_RESET.md) 섹션을 참조하세요.

지정하는 쿼리 그룹 레이블은 WLM 구성에도 포함되어야 합니다. 그렇지 않으면 *SET query\$1group* 명령을 실행해도 쿼리 대기열에 아무런 영향도 미치지 못합니다.

TO 절에서 정의하는 레이블은 쿼리 로그에도 수집되기 때문에 레이블을 문제 해결에도 사용할 수 있습니다. query\$1group 구성 파라미터에 대한 자세한 내용은 구성 참조에서 [query\$1group](r_query_group.md) 섹션을 참조하세요.

다음은 쿼리 그룹 'priority'에 속한 쿼리 2개를 실행한 후 쿼리 그룹을 재설정하는 예입니다.

```
set query_group to 'priority';
select count(*)from stv_blocklist;
select query, elapsed, substring from svl_qlog order by query desc limit 5; 
reset query_group;
```

## 수퍼유저 대기열에 쿼리 할당
<a name="cm-c-executing-queries-assigning-superuser-queue"></a>

슈퍼 사용자 대기열에 쿼리를 할당하려면 먼저 슈퍼 사용자 권한으로 Amazon Redshift에 로그온한 후 슈퍼 사용자 그룹에서 쿼리를 실행합니다. 쿼리 실행을 모두 마치고 나면 이후 쿼리부터는 수퍼유저 대기열에서 실행되지 않도록 쿼리 그룹을 재설정해야 합니다.

다음은 실행할 명령 2개를 수퍼유저 대기열에서 할당하는 것을 보여주는 예입니다.

```
set query_group to 'superuser';

analyze;
vacuum; 
reset query_group;
```

수퍼유저 목록을 보려면 PG\$1USER 시스템 카탈로그 테이블에 대해 쿼리합니다.

```
select * from pg_user where usesuper = 'true';
```

# WLM 동적 및 정적 구성 속성
<a name="cm-c-wlm-dynamic-properties"></a>

WLM 구성 속성은 동적이거나 정적입니다. 동적 속성은 클러스터 재부팅 없이도 데이터베이스에 적용할 수 있지만 정적 속성의 경우 변경 사항이 적용되려면 클러스터를 재부팅해야 합니다. 하지만 동적 속성과 정적 속성을 동시에 변경할 경우 속성 변경 사항을 모두 적용하려면 클러스터를 재부팅해야 합니다. 이는 변경된 속성이 동적이든 정적이든 상관없습니다.

동적 속성을 적용하는 동안 클러스터 상태는 `modifying`입니다. 자동 WLM과 수동 WLM 간의 전환은 정적 변경이기 때문에 적용하려면 클러스터를 재부팅해야 합니다.

다음 표에서는 자동 WLM 또는 수동 WLM 사용 시 어떤 WLM 속성이 동적이고 정적인지 알려줍니다.


****  

| WLM 속성 | 자동 WLM | 수동 WLM | 
| --- | --- | --- | 
| 쿼리 그룹 | 동적 | 정적 | 
| 쿼리 그룹 와일드카드 | 동적 | 정적 | 
| 사용자 그룹 | 동적 | 정적 | 
| 사용자 그룹 와일드카드 | 동적 | 정적 | 
| 사용자 역할 | 동적 | 정적 | 
| 사용자 역할 와일드카드 | 동적 | 정적 | 
| 기본 클러스터의 동시성 | 해당 사항 없음 | 동적 | 
| 동시성 확장 모드 | 동적 | 동적 | 
| 단기 쿼리 가속화 활성화 | 해당 사항 없음 | 동적 | 
| 단기 쿼리의 최대 실행 시간 | 동적 | 동적 | 
| 사용할 메모리 비율 | 해당 사항 없음 | 동적 | 
| 제한 시간 | 해당 사항 없음 | 동적 | 
| 우선순위 | 동적 | 해당 사항 없음 | 
| 대기열 추가 또는 제거 | 동적  | 정적 | 

쿼리 모니터링 규칙(QMR)을 추가하거나 기존 QMR을 수정 또는 삭제하면 클러스터를 다시 시작할 필요 없이 자동으로 변경됩니다.

**참고**  
수동 WLM 사용 시 제한 시간 값이 변경되면 값이 변경된 후 실행이 시작되는 모든 쿼리에 새로운 값이 적용됩니다. 동시성 또는 사용할 메모리 비율이 변경되면 Amazon Redshift가 동적으로 새 구성으로 변경됩니다. 단, 현재 실행 중인 쿼리는 변경의 영향을 받지 않습니다. 자세한 내용은 [WLM 동적 메모리 할당](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-dynamic-memory-allocation.html) 섹션을 참조하세요.

**Topics**
+ [WLM 동적 메모리 할당](cm-c-wlm-dynamic-memory-allocation.md)
+ [동적 WLM 예제](cm-c-wlm-dynamic-example.md)

# WLM 동적 메모리 할당
<a name="cm-c-wlm-dynamic-memory-allocation"></a>

WLM은 각 대기열마다 동시성 레벨에 맞춰 다수의 쿼리 슬롯을 생성합니다. 쿼리 슬롯에 할당되는 메모리 크기는 슬롯 수를 기준으로 분할된 대기열에 할당되는 메모리 비율과 동일합니다. 메모리 할당 또는 동시성을 변경하면 Amazon Redshift가 새로운 WLM 구성으로의 전환을 동적으로 관리합니다. 따라서 활성 쿼리가 현재 할당된 메모리 양을 사용하여 완료될 때까지 실행될 수 있습니다. 동시에 Amazon Redshift는 총 메모리 사용량이 사용 가능한 메모리의 100%를 초과하지 않도록 합니다.

워크로드 관리자는 다음과 같은 프로세스에 따라 구성 전환을 관리합니다.

1. WLM이 새로운 쿼리 슬롯마다 메모리 할당을 재계산합니다.

1. 실행 중인 쿼리에서 사용하지 않는 쿼리 슬롯이 있으면 WLM이 슬롯을 제거하여 새로운 슬롯에서 해당 메모리를 사용할 수 있게 합니다.

1. 쿼리 슬롯이 현재 사용 중일 경우에는 쿼리가 끝날 때까지 WLM이 대기합니다.

1. 현재 실행 중인 쿼리가 종료되면 빈 슬롯은 제거되고 할당된 메모리도 해제됩니다.

1. 슬롯을 하나 이상 추가할 정도로 메모리가 충분하다면 새로운 슬롯이 추가됩니다.

1. 변경 시점에 실행 중이던 쿼리가 모두 종료되면 슬롯 수가 새로운 동시성 레벨과 동일해지면서 새로운 WLM 구성 전환이 완료됩니다.

실제로 변경 시 실행 중인 쿼리는 계속해서 원래 메모리 할당을 사용합니다. 변경 시 대기열에서 대기 중인 쿼리는 실행할 때가 되면 새로운 슬롯으로 라우팅됩니다.

전환 프로세스 도중 WLM 동적 속성이 변경되면 WLM이 현재 상태부터 즉시 새로운 구성 전환을 시작합니다. 전환 상태를 보려면 [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md) 시스템 테이블에 대한 쿼리를 실행하세요.

# 동적 WLM 예제
<a name="cm-c-wlm-dynamic-example"></a>

Amazon Redshift를 사용하면 동적 WLM(워크로드 관리)을 사용하여 Amazon Redshift 클러스터 전반에서 워크로드 배포 및 리소스 할당을 자동으로 관리할 수 있습니다. 동적 WLM은 워크로드 요구 사항에 따라 메모리 할당을 동적으로 조정하여 최적의 동시성과 성능을 제공하는 워크로드 관리(WLM) 구성의 예제입니다. 다음 섹션에서는 Amazon Redshift 클러스터에서 동적 WLM을 구현하고 구성하는 방법에 대한 세부 정보를 제공합니다.

클러스터 WLM이 다음과 같은 동적 속성을 사용하여 2개의 대기열로 구성되어 있다고 가정하겠습니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/cm-c-wlm-dynamic-example.html)

이번에는 클러스터에 쿼리 처리에 사용할 수 있는 메모리가 200GB 있다고 가정하겠습니다. 이 수치는 임의적인 것으로 이해를 돕기 위해 사용되었습니다. 다음 방정식과 같이 각 슬롯에 할당되는 메모리는 25GB입니다.

```
(200 GB * 50% ) / 4 slots  = 25 GB
```

이번에는 다음과 같은 동적 속성을 사용하도록 WLM을 변경합니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/cm-c-wlm-dynamic-example.html)

다음 방정식과 같이 대기열 1에서는 각 슬롯마다 새롭게 할당되는 메모리는 50GB입니다.

```
(200 GB * 75% ) / 3 slots = 50 GB 
```

새로운 구성을 적용할 때 쿼리 A1, A2, A3 및 A4가 실행 중이고, 쿼리 B1, B2, B3 및 B4가 대기 중이라고 가정하겠습니다. WLM이 쿼리 슬롯을 다음과 같이 동적으로 재구성합니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/cm-c-wlm-dynamic-example.html)

1. WLM이 쿼리 슬롯마다 메모리 할당을 재계산합니다. 처음에 대기열 1에 할당된 메모리는 100GB였습니다. 하지만 새로운 대기열에 할당되는 총 메모리는 150GB이기 때문에 50GB를 즉시 사용할 수 있습니다. 현재 대기열 1에서 사용하는 슬롯 수는 4개이고, 새로운 동시성 레벨은 3슬롯이므로 새로운 슬롯이 추가되지는 않습니다.

1. 하나의 쿼리가 종료되면 슬롯이 제거되고 25GB가 비워집니다. 대기열 1은 이제 슬롯이 3개이며, 75GB의 메모리를 사용할 수 있습니다. 새로운 구성에서는 각 슬롯마다 50GB가 필요하지만 동시성 레벨이 3슬롯이기 때문에 슬롯이 새롭게 추가되지는 않습니다.

1. 두 번째 쿼리가 종료되면 슬롯이 제거되고 25GB가 비워집니다. 대기열 1은 이제 슬롯이 2개이며, 100GB가 사용할 수 있는 여유 메모리입니다.

1. 여유 메모리 50GB를 사용하여 새로운 슬롯이 추가됩니다. 대기열 1은 이제 슬롯이 3개이며, 50GB가 사용할 수 있는 여유 메모리입니다. 이제 대기열에서 대기 중이던 쿼리가 새로운 슬롯으로 라우팅될 수 있습니다.

1. 세 번째 쿼리가 종료되면 슬롯이 제거되고 25GB가 비워집니다. 대기열 1은 이제 슬롯이 2개이며, 75GB가 사용할 수 있는 여유 메모리입니다.

1. 여유 메모리 50GB를 사용하여 새로운 슬롯이 추가됩니다. 대기열 1은 이제 슬롯이 3개이며, 25GB가 사용할 수 있는 여유 메모리입니다. 이제 대기열에서 대기 중이던 쿼리가 새로운 슬롯으로 라우팅될 수 있습니다.

1. 네 번째 쿼리가 종료되면 슬롯이 제거되고 25GB가 비워집니다. 대기열 1은 이제 슬롯이 2개이며, 50GB가 사용할 수 있는 여유 메모리입니다.

1. 여유 메모리 50GB를 사용하여 새로운 슬롯이 추가됩니다. 대기열 1은 이제 슬롯이 3개이며 각각 50GB씩 사용할 수 있는 메모리가 모두 할당되었습니다.

전환이 완료되어 대기 중이던 쿼리가 모든 쿼리 슬롯을 사용할 수 있습니다.

# WLM 쿼리 모니터링 규칙
<a name="cm-c-wlm-query-monitoring-rules"></a>

Amazon Redshift 워크로드 관리(WLM)에서는 쿼리 모니터링 규칙에 따라 지표를 기준으로 WLM 대기열의 성능 경계를 정의한 후 쿼리가 이 경계를 벗어났을 때 필요한 작업을 지정합니다. 예를 들어 단시간 실행되는 쿼리 전용 대기열일 때는 60초 이상 실행되는 쿼리를 취소하는 규칙을 생성할 수도 있습니다. 그 밖에 잘못 설계된 쿼리를 추적할 목적으로 중첩 루프가 포함된 쿼리를 기록하는 규칙을 따로 만들 수도 있습니다.

쿼리 모니터링 규칙은 워크로드 관리(WLM) 구성 시 정의합니다. 대기열 1개에 최대 25개까지 규칙을 정의할 수 있으며 모든 대기열의 규칙 수도 25개로 제한됩니다. 각 규칙은 세 가지 조건, 즉 조건자와 한 가지 작업이 포함됩니다. *조건자*는 지표와 비교 조건(=, <, >) 그리고 값으로 구성됩니다. 임의 규칙에서 모든 조건자가 충족되면 해당 규칙의 작업이 트리거됩니다. 가능한 규칙 작업으로는 아래에서도 설명하겠지만 log, hop 및 abort가 있습니다.

임의 대기열에 적용되는 규칙은 해당 대기열에서 실행되는 쿼리에만 적용됩니다. 규칙끼리는 서로 독립되어 있습니다.

WLM은 10초마다 지표를 평가합니다. Amazon Redshift는 쿼리가 자동으로 다시 작성될 때 하위 쿼리 수준에서 쿼리 모니터링 규칙을 적용합니다. 같은 기간 동안 2개 이상의 규칙이 트리거된 경우 WLM은 가장 심각한 작업이 연결되어 있는 규칙을 선택합니다. 두 규칙에 대한 작업의 심각도가 동일한 경우 WLM은 규칙 이름을 기준으로 규칙을 알파벳 순서로 실행합니다. 작업이 건너뛰기나 중단인 경우에는 작업을 기록한 후 쿼리가 대기열에서 제거됩니다. 기록 작업인 경우 쿼리가 대기열에서 계속 실행됩니다. WLM은 규칙에 따라 쿼리 1개마다 시작할 수 있는 기록 작업이 1개로 제한됩니다. 대기열에 다른 규칙이 포함되어 있으면 다른 규칙들도 계속해서 적용됩니다. 작업이 건너뛰기이고 쿼리가 다른 대기열로 라우팅된다면 새로운 대기열의 규칙이 적용됩니다. 쿼리 모니터링 및 특정 쿼리에 대해 수행된 작업 추적에 대한 자세한 내용은 [단기 쿼리 가속화](wlm-short-query-acceleration.md)의 샘플 컬렉션을 참조하세요.

규칙의 조건자가 모두 충족되면 WLM이 한 행을 [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md) 시스템 테이블에 작성합니다. 또한 Amazon Redshift가 현재 실행 중인 쿼리의 지표를 [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md)에 기록합니다. 완료된 쿼리의 지표는 [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md)에 저장됩니다.

**참고**  
Amazon Redshift Serverless의 경우 `wlm_json_configuration` 파라미터를 사용하여 쿼리 대기열 및 모니터링 규칙을 구성할 수 있습니다. 이를 통해 사용자 역할, 쿼리 그룹 및 모니터링 규칙이 서로 다른 여러 대기열을 생성할 수 있습니다. 서버리스 쿼리 대기열 구성에 대한 자세한 내용은 *Amazon Redshift 관리 안내서*의 [쿼리 대기열 설정](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-query-queues.html)을 참조하세요.

## 쿼리 모니터링 규칙 정의
<a name="cm-c-wlm-defining-query-monitoring-rules"></a>

쿼리 모니터링 규칙은 WLM 구성, 즉 클러스터의 파라미터 그룹을 정의할 때 함께 정의합니다.

AWS Management Console을 사용하거나 프로그래밍 방식으로 JSON을 사용하여 규칙을 생성할 수 있습니다.

**참고**  
프로그래밍 방식으로 규칙을 생성하려면 콘솔을 사용하여 파라미터 그룹 정의에 추가할 JSON을 생성하는 것이 가장 좋습니다. 자세한 내용은 *Amazon Redshift 관리 설명서*의 [쿼리 모니터링 규칙 생성](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html) 또는 수정 및 [AWS CLI을 사용하여 파라미터 값 구성](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html#configure-parameters-using-the-cli) 섹션을 참조하세요.

쿼리 모니터링 규칙을 정의하려면 다음 요소를 지정합니다.
+ 규칙 이름 - 규칙 이름은 WLM 구성 내에서 고유해야 합니다. 최대 32자의 영숫자 또는 밑줄로 구성되며, 공백이나 인용 부호는 포함될 수 없습니다. 대기열 1개당 규칙 수는 최대 25개까지 가능하며 모든 대기열의 총 규칙 수도 25개로 제한됩니다.
+ 1개 이상의 조건자 - 규칙 1개당 최대 3개의 조건자를 가질 수 있습니다. 임의 규칙에서 모든 조건자가 충족되면 연결되어 있는 작업이 트리거됩니다. 조건자는 지표 이름과 연산자( =, <, >) 그리고 값으로 정의됩니다. 예를 들면, `query_cpu_time > 100000`입니다. 지표 목록과 지표에 따른 값의 예는 이번 섹션에서 아래 [프로비저닝된 Amazon Redshift에 대한 쿼리 모니터링 지표](#cm-c-wlm-query-monitoring-metrics)를 참조하세요.
+ 작업 - 다수의 규칙이 트리거되면 WLM이 가장 심각한 작업이 연결되어 있는 규칙을 선택합니다. 가능한 작업은 심각도의 오름차순에 따라 다음과 같습니다.
  + 로그 - 쿼리에 대한 정보를 STL\$1WLM\$1RULE\$1ACTION 시스템 테이블에 기록합니다. 기록하기 작업은 로그 레코드만 작성하려고 할 때 사용합니다. WLM은 규칙에 따라 쿼리 1개마다 기록하기 작업이 1개로 제한되어 있습니다. 기록하기 작업을 마치면 다른 규칙이 적용되고 WLM이 계속해서 쿼리를 모니터링합니다.
  + 건너뛰기(수동 WLM에서만 사용할 수 있음) - 작업을 기록하고 쿼리를 건너뛰어 일치하는 그다음 대기열로 이동합니다. 일치하는 대기열이 더 이상 없으면 쿼리가 취소됩니다. QMR은 [CREATE TABLE AS](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_AS.html)(CTAS) 문과 읽기 전용 쿼리(예: SELECT 문)만 건너뜁니다. 자세한 내용은 [WLM 쿼리 대기열 건너뛰기](wlm-queue-hopping.md) 섹션을 참조하세요.
  + 중단 - 작업을 로그하고 쿼리를 취소합니다. QMR은 COPY 문과 유지 관리 작업(예: ALTER, ANALYZE 및 VACUUM)을 중지하지 않습니다.
  + 우선 순위 변경(자동 WLM에서만 사용할 수 있음) - 쿼리의 우선 순위를 변경합니다.

쿼리 실행 시간을 제한하려면 WLM 제한 시간 대신 쿼리 모니터링 규칙을 생성하는 것이 좋습니다. 예를 들어 다음 JSON 코드 조각과 같이 `max_execution_time`을 50,000밀리초로 설정할 수 있습니다.

```
"max_execution_time": 50000
```

하지만 대신 동등한 쿼리 모니터링 규칙을 정의하는 것이 좋습니다. 다음 예제에서는 `query_execution_time`을 50초로 설정하는 쿼리 모니터링 규칙을 보여 줍니다.

```
"rules": 
[
    {
        "rule_name": "rule_query_execution",
        "predicate": [
            {
                "metric_name": "query_execution_time",
                "operator": ">",
                "value": 50
            }
        ],
        "action": "abort"
    }            
]
```

쿼리 모니터링 규칙을 생성하거나 수정하는 단계는 *Amazon Redshift 관리 설명서*의 [쿼리 모니터링 규칙 생성](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html) 및 [wlm\$1json\$1configuration 파라미터의 속성](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html#wlm-json-config-properties) 섹션을 참조하세요.

쿼리 모니터링 규칙에 대한 자세한 내용은 다음 주제에서 찾아볼 수 있습니다.
+  [프로비저닝된 Amazon Redshift에 대한 쿼리 모니터링 지표](#cm-c-wlm-query-monitoring-metrics) 
+  [쿼리 모니터링 규칙 템플릿](#cm-c-wlm-query-monitoring-templates) 
+  [쿼리 모니터링 규칙 생성](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html) 
+  [워크로드 관리 구성](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) 
+  [쿼리 모니터링 규칙에 대한 시스템 테이블 및 뷰](#cm-c-wlm-qmr-tables-and-views) 

## 프로비저닝된 Amazon Redshift에 대한 쿼리 모니터링 지표
<a name="cm-c-wlm-query-monitoring-metrics"></a>

다음 표는 쿼리 모니터링 규칙에서 사용하는 지표를 설명한 것입니다. 아래 지표는 [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md) 및 [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md) 시스템 테이블에 저장되는 지표와 다릅니다.

임의 지표의 성능 임계값은 쿼리 수준에서 또는 세그먼트 수준에서 추적됩니다. 세그먼트 및 단계에 대한 자세한 내용은 [쿼리 계획 및 실행 워크플로우](c-query-planning.md) 섹션을 참조하세요.

**참고**  
[WLM 제한 시간](cm-c-defining-query-queues.md#wlm-timeout) 파라미터는 쿼리 모니터링 규칙과 다릅니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)

**참고**  
건너뛰기 작업은 `query_queue_time` 조건자에서 지원되지 않습니다. 즉, `query_queue_time` 조건자가 충족될 때 건너뛰도록 정의된 규칙은 무시됩니다.
세그먼트 실행 시간이 짧으면 `io_skew`, `query_cpu_usage_percent` 같은 일부 지표에서 샘플링 오류가 발생할 수 있습니다. 이러한 샘플링 오류를 피하거나 줄이려면 규칙에 세그먼트 실행 시간을 추가하세요. 처음에는 `segment_execution_time > 10`으로 시작하는 것이 좋습니다.

[SVL\$1QUERY\$1METRICS](r_SVL_QUERY_METRICS.md) 뷰에는 완료된 쿼리의 지표가 표시됩니다. 그리고 [SVL\$1QUERY\$1METRICS\$1SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) 뷰에는 완료된 쿼리의 최대 지표 값이 표시됩니다. 쿼리 모니터링 규칙을 정의하기 위한 임계값을 결정할 때는 이 두 가지 뷰의 값들을 사용하세요.

## Amazon Redshift Serverless에 대한 쿼리 모니터링 지표
<a name="cm-c-wlm-query-monitoring-metrics-serverless"></a>

다음 테이블은 Amazon Redshift Serverless의 쿼리 모니터링 규칙에서 사용하는 지표를 설명한 것입니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)

**참고**  
건너뛰기 작업은 `max_query_queue_time` 조건자에서 지원되지 않습니다. 즉, `max_query_queue_time` 조건자가 충족될 때 건너뛰도록 정의된 규칙은 무시됩니다.
세그먼트 실행 시간이 짧으면 `max_io_skew`, `max_query_cpu_usage_percent` 같은 일부 지표에서 샘플링 오류가 발생할 수 있습니다.

Amazon Redshift Serverless의 경우 `wlm_json_configuration` 파라미터를 사용하여 쿼리 대기열 및 모니터링 규칙을 구성할 수 있습니다. 이렇게 하면 위에 나열된 지표를 사용하여 사용자 역할, 쿼리 그룹 및 모니터링 규칙이 서로 다른 여러 대기열을 생성할 수 있습니다. 서버리스 쿼리 대기열 구성에 대한 자세한 내용은 *Amazon Redshift 관리 안내서*의 [WLM JSON 구성 구조](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-query-queues.html#serverless-wlm-json-configuration)를 참조하세요.

## 쿼리 모니터링 규칙 템플릿
<a name="cm-c-wlm-query-monitoring-templates"></a>

Amazon Redshift 콘솔을 사용하여 규칙을 추가할 때 사전 정의된 템플릿에서 규칙을 생성하도록 선택할 수 있습니다. Amazon Redshift는 일련의 조건자로 새 규칙을 생성하고 조건자를 기본값으로 채웁니다. 이때 기본 작업은 기록하기입니다. 조건자와 작업은 사용 사례에 따라 수정할 수 있습니다.

다음 표는 사용할 수 있는 템플릿을 모아놓은 목록입니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)

## 쿼리 모니터링 규칙에 대한 시스템 테이블 및 뷰
<a name="cm-c-wlm-qmr-tables-and-views"></a>

규칙의 조건자가 모두 충족되면 WLM이 한 행을 [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md) 시스템 테이블에 작성합니다. 이 행에는 규칙을 트리거한 쿼리와 결과 작업에 대한 세부 정보가 포함되어 있습니다.

또한 Amazon Redshift는 쿼리 지표를 다음 시스템 테이블 및 뷰에 기록합니다.
+ [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md) 테이블에는 현재 실행 중인 쿼리의 지표가 표시됩니다.
+ [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md) 테이블에는 완료된 쿼리의 지표가 기록됩니다.
+ [SVL\$1QUERY\$1METRICS](r_SVL_QUERY_METRICS.md) 뷰에는 완료된 쿼리의 지표가 표시됩니다.
+ 그리고 [SVL\$1QUERY\$1METRICS\$1SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) 뷰에는 완료된 쿼리의 최대 지표 값이 표시됩니다.

# WLM 시스템 테이블 및 뷰
<a name="cm-c-wlm-system-tables-and-views"></a>

WLM은 내부적으로 정의된 WLM 서비스 클래스에 따라 쿼리 대기열을 구성합니다. Amazon Redshift는 WLM 구성에 정의된 대기열과 함께 이러한 서비스 클래스에 따라 여러 내부 대기열을 생성합니다. *대기열*과 *서비스 클래스*라는 용어는 시스템 테이블에서 서로 통용되기도 합니다. 수퍼유저 대기열은 서비스 클래스 5를 사용합니다. 사용자 정의 대기열은 서비스 클래스 6 이상을 사용합니다.

쿼리, 대기열 및 서비스 클래스의 상태는 WLM 시스템 테이블을 사용하여 확인할 수 있습니다. 다음은 쿼리를 통해서 아래와 같은 작업이 가능한 시스템 테이블입니다.
+ 추적 중인 쿼리와 워크로드 관리자에서 할당하는 리소스를 확인합니다.
+ 쿼리가 할당된 대기열을 확인합니다.
+ 현재 워크로드 관리자에서 추적 중인 쿼리의 상태를 확인합니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/cm-c-wlm-system-tables-and-views.html)

 시스템 테이블에서 쿼리를 추적하려면 작업 ID를 사용하면 됩니다. 다음은 가장 최근에 제출된 사용자 쿼리의 작업 ID를 가져오는 예입니다.

```
select task from stl_wlm_query where exec_start_time =(select max(exec_start_time) from stl_wlm_query); 

task 
------ 
137 
(1 row)
```

 다음은 현재 실행 중이거나 여러 서비스 클래스(대기열)에서 대기 중인 쿼리를 표시하는 예입니다. 다음 쿼리는 Amazon Redshift에서 동시에 실행 중인 전체 워크로드를 추적하는 데 유용합니다.

```
select * from stv_wlm_query_state order by query;


xid |task|query|service_| wlm_start_  |  state  |queue_ | exec_
    |    |     |class   | time        |         |time   | time
----+----+-----+--------+-------------+---------+-------+--------
2645| 84 | 98  | 3      | 2010-10-... |Returning|   0   | 3438369
2650| 85 | 100 | 3      | 2010-10-... |Waiting  |   0   | 1645879
2660| 87 | 101 | 2      | 2010-10-... |Executing|   0   | 916046
2661| 88 | 102 | 1      | 2010-10-... |Executing|   0   | 13291
(4 rows)
```

## WLM 서비스 클래스 ID
<a name="wlm-service-class-ids"></a>

다음 표에 서비스 클래스에 할당된 ID가 나와 있습니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/cm-c-wlm-system-tables-and-views.html)