쿼리 우선 순위

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

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

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

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

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는 고급 기계 학습 알고리즘을 사용하여 이 최적화가 워크로드에 도움이 되는 시기를 결정하고 다음 조건이 모두 충족되면 자동으로 최적화를 적용합니다.