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/)을 참조하세요.

# 수동 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) 섹션을 참조하세요.