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/)을 참조하세요.
# 쿼리 우선 순위
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 워크로드가 높은 우선 순위에서 실행 중인 경우에도 분석 워크로드는 처리량을 유지할 수 있습니다.
## 대기열 우선 순위 구성
자동 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
}
]
```
## 쿼리 모니터링 규칙을 이용해 쿼리 우선 순위 변경
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"
}
]
```
## 대기열 우선 순위 모니터링
쿼리 대기 및 실행에 대한 우선 순위를 표시하려면 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) 섹션을 참조하세요.