자습서: 수동 워크로드 관리(WLM) 대기열 구성 - Amazon Redshift

자습서: 수동 워크로드 관리(WLM) 대기열 구성

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

개요

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

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

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

예상 소요 시간: 75분

예상 비용: 50센트

사전 조건

Amazon Redshift 클러스터, 샘플 TICKIT 데이터베이스 및 psql 클라이언트 도구가 필요합니다. 아직 이 세 가지가 준비되지 않았다면 Amazon Redshift 시작 안내서Amazon Redshift RSQL을 참조하세요.

Sections

단원 1: 기본적인 대기열 처리 동작에 대한 이해

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

1단계: WLM_QUEUE_STATE_VW 뷰 생성

이번 단계에서는 WLM_QUEUE_STATE_VW라는 이름의 뷰를 생성합니다. 이 뷰는 다음 시스템 테이블에서 정보를 반환합니다.

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

설명
대기열 행과 연결되어 대기열을 나타내는 번호입니다. 대기열 번호에 따라 데이터베이스의 대기열 순서가 결정됩니다.
설명 대기열을 특정 사용자 그룹 또는 특정 쿼리 그룹에게만 제공할지, 혹은 모든 유형의 쿼리에게 제공할지 설명하는 값입니다.
slots 대기열에 할당되는 슬롯 수입니다.
mem 대기열에 할당되는 슬롯당 메모리 크기(MB)입니다.
2013년 7월 15일 쿼리 종료 이전에 허용되는 실행 시간입니다.
user_* 사용자 그룹 일치를 위한 WLM 구성 시 와일드카드 문자의 허용 여부를 나타내는 값입니다.
query_* 쿼리 그룹 일치를 위한 WLM 구성 시 와일드카드 문자의 허용 여부를 나타내는 값입니다.
queued 대기열에서 처리를 기다리는 쿼리 수입니다.
executing 현재 실행 중인 쿼리 수.
executed 실행된 쿼리 수.

WLM_QUEUE_STATE_VW 뷰를 생성하려면

  1. Amazon Redshift RSQL을 열고 TICKIT 샘플 데이터베이스에 연결합니다. 이 역할이 구성되지 않은 경우 사전 조건 섹션을 참조하세요.

  2. 다음 쿼리를 실행하여 WLM_QUEUE_STATE_VW 뷰를 생성합니다.

    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;
  3. 다음 쿼리를 실행하여 뷰에 포함된 정보를 확인합니다.

    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_QUERY_STATE_VW 뷰 생성

이번 단계에서는 WLM_QUERY_STATE_VW라는 이름의 뷰를 생성합니다. 이 뷰는 STV_WLM_QUERY_STATE 시스템 테이블에서 정보를 반환합니다.

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

설명
쿼리 쿼리 ID.
대기열 대기열 번호입니다.
slot_count 쿼리에 할당되는 슬롯 수입니다.
start_time 쿼리가 시작된 시간입니다.
state 쿼리 상태(executing 등)입니다.
queue_time 쿼리가 대기열에서 대기한 시간(마이크로초)입니다.
exec_time 쿼리가 실행된 시간(마이크로초)

WLM_QUERY_STATE_VW 뷰를 생성하려면

  1. RSQL에서 다음 쿼리를 실행하여 WLM_QUERY_STATE_VW 뷰를 생성합니다.

    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;
  2. 다음 쿼리를 실행하여 뷰에 포함된 정보를 확인합니다.

    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단계: 테스트 쿼리 실행

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

이번 단계를 진행하려면 RSQL 창 2개를 열어야 합니다.

  • RSQL 창 1에서는 이번 자습서에서 이미 생성한 뷰를 사용하여 대기열과 쿼리의 상태를 모니터링하는 쿼리를 실행합니다.

  • RSQL 창 2에서는 RSQL 창 1에서 구한 결과를 변경하는 쿼리를 장시간 실행합니다.

테스트 쿼리를 실행하려면

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

  2. 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개 이상의 결과를 반환합니다. 이 결과를 다음 단계에서 장시간 실행 쿼리를 시작하여 나타나는 결과와 서로 비교합니다.

  3. RSQL 창 2에서는 TICKIT 샘플 데이터베이스에서 쿼리를 실행합니다. 이 쿼리는 앞에서 생성한 WLM_QUEUE_STATE_VW 뷰와 WLM_QUERY_STATE_VW 뷰의 결과를 충분히 살펴볼 수 있도록 약 1분 동안 실행해야 합니다. 경우에 따라 두 뷰에 대한 쿼리를 실행할 수 있을 정도로 쿼리 실행 시간이 충분히 길지 않을 수 있습니다. 이러한 경우 l.listid 에 대한 필터 값을 높여서 실행 시간을 연장할 수 있습니다.

    참고

    쿼리 실행 시간을 줄이고 시스템 성능을 향상시키기 위해 Amazon Redshift는 특정 형식의 쿼리 결과를 리더 노드의 메모리에 캐시합니다. 결과 캐싱이 활성화되어 있으면 이후 쿼리의 실행 속도가 훨씬 빨라집니다. 쿼리가 빠르게 실행되는 것을 방지하려면 현재 세션에 대해 결과 캐싱을 비활성화합니다.

    현재 세션에 대해 결과 캐싱을 해제하려면 다음과 같이 enable_result_cache_for_session 파라미터를 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;
  4. RSQL 창 1에서 WLM_QUEUE_STATE_VW 및 WLM_QUERY_STATE_VW에 대한 쿼리를 실행하여 결과를 앞선 결과와 비교합니다.

    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_QUERY_STATE_VW에는 행이 2개 있습니다. 결과 하나는 이 뷰에 대한 SELECT 작업을 실행하는 데 필요한 자기 참조적 쿼리입니다. 두 번째 결과는 이전 단계의 장기 실행 쿼리입니다.

  • WLM_QUEUE_STATE_VW에서 executing 열이 1에서 2로 증가했습니다. 이 열의 입력 항목은 대기열에서 실행 중인 쿼리가 2개라는 것을 의미합니다.

  • executed 열은 대기열에서 쿼리를 실행할 때마다 일정하게 증가합니다.

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

단원 2: WLM 쿼리 대기열 구성의 수정

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

파라미터 그룹의 수동 WLM 구성을 생성하려면
  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/redshiftv2/에서 Amazon Redshift 콘솔을 엽니다.

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

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

  4. Parameter group name(파라미터 그룹 이름)Description(설명) 모두에 대해 WLMTutorial을 입력한 다음 Create(생성)를 선택하여 파라미터 그룹을 생성합니다.

    참고

    파라미터 그룹 이름은 생성 시 모두 소문자 형식으로 변환됩니다.

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

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

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

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

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

  10. 다음과 같이 각 대기열에 대한 정보를 입력합니다.

    • [대기열 1(Queue 1)]의 경우 [메모리(%)Memory (%)]에 대해 30, [기본의 동시성(Concurrency on main)]에 대해 2, [쿼리 그룹(Query groups)]에 대해 test를 입력합니다. 기타 설정은 기본값을 유지합니다.

    • [대기열 2(Queue 2)]의 경우 [메모리(%)Memory (%)]에 대해 40, [기본의 동시성(Concurrency on main)]에 대해 3, [사용자 그룹(User groups)]에 대해 admin를 입력합니다. 기타 설정은 기본값을 유지합니다.

    • 기본 대기열은 아무것도 바꾸지 마십시오. WLM은 기본 대기열에 미할당 메모리를 할당합니다.

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

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

수동 WLM 구성이 있는 파라미터 그룹을 클러스터와 연결하려면
  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/redshiftv2/에서 Amazon Redshift 콘솔을 엽니다.

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

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

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

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

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

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

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

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

단원 3: 사용자 그룹 및 쿼리 그룹을 기반으로 쿼리를 대기열로 라우팅

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

1단계: 데이터베이스에서 쿼리 대기열 구성 보기

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

쿼리 대기열 구성을 보려면

  1. RSQL을 열고 다음 쿼리를 실행합니다. 쿼리는 1단계: WLM_QUEUE_STATE_VW 뷰 생성에서 생성한 WLM_QUEUE_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 | 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_QUEUE_STATE_VW 뷰 생성에서 나온 결과와 비교합니다. 여기에서는 대기열 2개가 추가된 것을 알 수 있습니다. 대기열 1은 테스트 쿼리 그룹을 위한 대기열이고, 대기열 2는 관리자 사용자 그룹을 위한 대기열입니다.

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

  2. 다음 쿼리를 실행하여 쿼리가 대기열 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단계: 쿼리 그룹 대기열을 사용하여 쿼리 실행

쿼리 그룹 대기열을 사용하여 쿼리를 실행하려면

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

    set query_group to test; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
  2. 나머지 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로 라우팅되었습니다.

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

    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
  4. 이제 쿼리 그룹을 재설정한 후 장기(long) 쿼리를 다시 실행합니다.

    reset query_group; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
  5. 두 뷰에 대한 쿼리를 실행하여 결과를 확인합니다.

    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단계: 데이터베이스 사용자 및 그룹 생성

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

새로운 데이터베이스 사용자와 사용자 그룹을 생성하려면

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

    create user adminwlm createuser password '123Admin';
  2. 그러고 나서 다음 명령을 실행하여 새로운 사용자 그룹을 생성한 후 새로운 adminwlm 사용자를 그룹에 추가합니다.

    create group admin; alter group admin add user adminwlm;

4단계: 사용자 그룹 대기열을 사용하여 쿼리 실행

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

사용자 그룹 대기열을 사용하여 쿼리를 실행하려면

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

    set session authorization 'adminwlm'; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
  2. 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 대기열 할당 규칙 단원을 참조하십시오.

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

    set query_group to test; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
  4. 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
  5. 모두 마친 후에는 쿼리 그룹을 재설정합니다.

    reset query_group;

단원 4: wlm_query_slot_count를 사용하여 대기열에서 동시성 레벨을 임시로 재정의

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

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

1단계: wlm_query_slot_count를 사용하여 동시성 레벨 재정의

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

wlm_query_slot_count를 사용하여 동시성 레벨을 재정의하려면

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

    set wlm_query_slot_count to 3; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
  2. 이제 관리자 계정을 사용하여 WLM_QUERY_STATE_VW에 대한 쿼리를 실행하고 쿼리가 어떻게 실행되고 있는지 확인합니다.

    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개를 모두 사용하여 쿼리를 처리하면서 대기열의 모든 리소스를 해당 쿼리에 할당하고 있다는 것을 의미합니다.

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

    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_query_slot_count 구성 설정은 현재 세션에서만 유효합니다. 이 세션이 종료되거나 다른 사용자가 쿼리를 실행할 경우에는 WLM 구성이 사용됩니다.

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

    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단계: 다른 세션에서 쿼리 실행

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

다른 세션에서 쿼리를 실행하려면

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

    set query_group to test;
  2. RSQL 창 1에서 다음 장기(long-running) 쿼리를 실행합니다.

    select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
  3. 장기 쿼리가 여전히 RSQL 창 1에서 실행되고 있을 때 다음을 실행합니다. 이러한 명령은 대기열의 슬롯을 모두 사용할 수 있도록 슬롯 수를 높인 다음 장기 쿼리를 시작합니다.

    set wlm_query_slot_count to 2; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
  4. 세 번째 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에 할당된 슬롯 중 하나를 사용하여 쿼리를 실행합니다. 또한 대기열에서 대기 중인 쿼리가 하나 있습니다(여기에서 queued1이고 stateQueuedWaiting임). 첫 번째 쿼리가 실행을 마치면 두 번째 쿼리가 실행을 시작합니다. 이렇게 실행되는 이유는 두 쿼리가 모두 test 쿼리 그룹으로 라우팅되었기 때문이며, 두 번째 쿼리는 처리를 시작할 정도로 충분한 수의 슬롯이 나올 때까지 대기해야 합니다.

단원 5: 리소스 정리

클러스터는 실행하는 동안 계속해서 요금이 발생합니다. 이 튜토리얼을 마치면 Amazon Redshift 시작 안내서추가 리소스 찾기 및 환경 재설정 단계에 따라 환경을 이전 상태로 되돌립니다.

WLM에 대한 자세한 내용은 워크로드 관리 섹션을 참조하세요.