대기열 우선 순위 구성 QMR을 이용해 쿼리 우선 순위 변경 대기열 우선 순위 모니터링

쿼리 우선 순위

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

HIGHEST
HIGH
NORMAL
LOW
LOWEST

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

HIGHEST보다 더 높은 우선 순위인 CRITICAL이라는 추가 우선 순위는 수퍼유저에게 제공됩니다. 이 우선 순위를 설정하려면 CHANGE_QUERY_PRIORITY, CHANGE_SESSION_PRIORITY 및 CHANGE_USER_PRIORITY 함수를 사용할 수 있습니다. 이 함수를 사용할 수 있는 권한을 데이터베이스 사용자에게 부여하려면 저장 프로시저를 생성하여 사용자에게 권한을 부여할 수 있습니다. 예시는 CHANGE_SESSION_PRIORITY 섹션을 참조하세요.

참고

한 번에 하나의 CRITICAL 쿼리만 실행할 수 있습니다.

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

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

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

대기열 우선 순위 구성

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

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

다음 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 쿼리 모니터링 규칙 단원을 참조하십시오.

예를 들어 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 이상을 디스크에 유출하며 현재 우선 순위가 normal인 모든 쿼리에 대해 쿼리 우선 순위를 lowest로 변경할 수 있는 규칙을 정의하는 것입니다.


"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_wlm_query_state 시스템 테이블에 있는 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_wlm_query 시스템 테이블에 있는 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 쿼리 모니터링 규칙 단원을 참조하십시오.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

자동 WLM

수동 WLM