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 Serverless로 쿼리 및 워크로드 모니터링 제공된 시스템 보기를 사용하여 Amazon Redshift Serverless 쿼리 및 워크로드를 모니터링할 수 있습니다. *모니터링 보기*는 쿼리 및 워크로드 사용량을 모니터링하는 데 사용되는 Amazon Redshift Serverless의 시스템 보기입니다. 이러한 보기는 `pg_catalog` 스키마에 있습니다. 사용 가능한 시스템 보기는 프로비저닝된 클러스터에 필요한 것보다 훨씬 간단한 Amazon Redshift Serverless를 모니터링하는 데 필요한 정보를 제공하도록 설계되었습니다. SYS 시스템 보기는 Amazon Redshift Serverless에서 작동하도록 설계되었습니다. 이러한 보기에서 제공하는 정보를 표시하려면 SQL SELECT 문을 실행합니다. 시스템 보기는 다음 모니터링 목표를 지원하도록 정의됩니다. **워크로드 모니터링** 시간 경과에 따른 쿼리 활동을 모니터링하여 다음을 수행할 수 있습니다. + 워크로드 패턴을 이해하여 정상(기준)과 비즈니스 서비스 수준 계약(SLA) 내에 있는 것을 알 수 있습니다. + 일시적인 문제이거나 추가 조치가 필요한 문제일 수 있는 정상과의 편차를 신속하게 식별합니다. **데이터 로드 및 언로드 모니터링** Amazon Redshift Serverless 안팎으로 데이터를 이동하는 것은 중요한 기능입니다. COPY 및 UNLOAD를 사용하여 데이터를 로드 또는 언로드하고 비즈니스 SLA 준수를 추적하기 위해 전송된 바이트/행 수 및 완료된 파일 수를 기준으로 진행 상황을 면밀히 모니터링해야 합니다. 이는 일반적으로 시스템 테이블 쿼리를 자주(즉, 매분) 실행하여 진행 상황을 추적하고 심각한 편차가 감지되는 경우 조사/수정 조치에 대한 경고를 발생시켜 수행됩니다. **실패 및 문제 진단** 쿼리 또는 런타임 실패에 대해 조치를 취해야 하는 경우가 있습니다. 개발자는 시스템 테이블에 의존하여 문제를 자가 진단하고 올바른 해결책을 결정합니다. **성능 튜닝** 처음부터 SLA 요구 사항을 충족하지 않거나 시간 경과에 따라 성능이 저하된 쿼리를 조정해야 할 수 있습니다. 튜닝하려면 실행 계획, 통계, 기간 및 리소스 소비를 비롯한 런타임 세부 정보가 있어야 합니다. 편차의 원인을 파악하고 성능 개선 방법을 안내하기 위해 잘못된 쿼리에 대한 기준 데이터가 필요합니다. **사용자 객체 이벤트 모니터링** 구체화된 보기 새로 고침, 정리 및 분석과 같은 사용자 객체에 대한 작업 및 활동을 모니터링해야 합니다. 여기에는 구체화된 뷰에 대한 자동 새로 고침과 같은 시스템 관리형 이벤트가 포함됩니다. 사용자가 시작한 경우 이벤트가 종료되는 시점을 모니터링하고 시스템이 시작한 경우 마지막으로 성공한 실행을 모니터링하려고 합니다. **청구를 위한 사용량 추적** 시간 경과에 따른 사용량 추세를 모니터링하여 다음을 수행할 수 있습니다. + 예산 계획과 비즈니스 확장 추정치를 알립니다. + 콜드 데이터 제거와 같은 잠재적인 비용 절감 기회를 식별합니다. SYS 시스템 뷰를 사용하여 Amazon Redshift Serverless를 모니터링합니다. SYS 모니터링 뷰에 관한 자세한 내용은 Amazon Redshift 데이터베이스 개발자 안내서의 [SYS 모니터링 뷰](https://docs.aws.amazon.com//redshift/latest/dg/serverless_views-monitoring.html)를 참조하시기 바랍니다. # 쿼리 모니터링 정책 추가 슈퍼 사용자는 모든 사용자에 대해 쿼리 모니터링을 수행할 수 있도록 슈퍼 사용자가 아닌 사용자에게 액세스 권한을 제공할 수 있습니다. 먼저 쿼리 모니터링 액세스를 제공하기 위해 사용자 또는 역할에 대한 정책을 추가합니다. 그런 다음 사용자 또는 역할에 쿼리 모니터링 권한을 부여합니다. **쿼리 모니터링 정책을 추가하려면** 1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)을 선택합니다. 1. **액세스 관리(Access management)**에서 **정책(Policies)**을 선택합니다. 1. **정책 생성(Create Policy)**을 선택합니다. 1. **JSON**을 선택하고 다음 정책 정의를 붙여 넣습니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "redshift-data:ExecuteStatement", "redshift-data:DescribeStatement", "redshift-data:GetStatementResult", "redshift-data:ListDatabases" ], "Resource": "*" }, { "Effect": "Allow", "Action": "redshift-serverless:GetCredentials", "Resource": "*" } ] } ``` ------ 1. **정책 검토**를 선택합니다. 1. **이름**에 정책의 이름을 입력합니다(예: `query-monitoring`). 1. [**정책 생성**]을 선택합니다. 정책을 생성한 후 적절한 권한을 부여할 수 있습니다. 액세스 권한을 제공하려면 사용자, 그룹 또는 역할에 권한을 추가하세요. + AWS IAM Identity Center의 사용자 및 그룹: 권한 세트를 생성합니다. *AWS IAM Identity Center 사용자 안내서*에서 [권한 세트 생성](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html)의 지침을 따릅니다. + ID 제공업체를 통해 IAM에서 관리되는 사용자: ID 페더레이션을 위한 역할을 생성합니다. *IAM 사용자 설명서*의 [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html)의 지침을 따릅니다. + IAM 사용자: + 사용자가 맡을 수 있는 역할을 생성합니다. *IAM 사용자 설명서*에서 [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html)의 지침을 따릅니다. + (권장되지 않음) 정책을 사용자에게 직접 연결하거나 사용자를 사용자 그룹에 추가합니다. *IAM 사용 설명서*에서 [사용자(콘솔)에 권한 추가](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)의 지침을 따릅니다. # 사용자에 대한 쿼리 모니터링 권한 부여 `sys:monitor` 권한이 있는 사용자는 모든 쿼리를 볼 수 있습니다. 또한 `sys:operator` 권한이 있는 사용자는 쿼리를 취소하고 쿼리 기록을 분석하고 vacuum 작업을 수행할 수 있습니다. **사용자에게 쿼리 모니터링 권한을 부여하려면** 1. 시스템 모니터 액세스를 제공하려면 다음 명령을 입력합니다. 여기서 *user-name*은 액세스를 제공하려는 사용자의 이름입니다. ``` grant role sys:monitor to "IAM:user-name"; ``` 1. (선택 사항) 시스템 운영 액세스를 제공하려면 다음 명령을 입력합니다. 여기서 *user-name*은 액세스를 제공하려는 사용자의 이름입니다. ``` grant role sys:operator to "IAM:user-name"; ``` # 역할에 대한 쿼리 모니터링 권한 부여 `sys:monitor` 권한이 있는 역할의 사용자는 모든 쿼리를 볼 수 있습니다. 또한 `sys:operator` 권한이 있는 역할의 사용자는 쿼리를 취소하고 쿼리 기록을 분석하고 vacuum 작업을 수행할 수 있습니다. **역할에 쿼리 모니터링 권한을 부여하려면** 1. 시스템 모니터 액세스를 제공하려면 다음 명령을 입력합니다. 여기서 *role-name*은 액세스를 제공하려는 사용자의 이름입니다. ``` grant role sys:monitor to "IAMR:role-name"; ``` 1. (선택 사항) 시스템 운영 액세스를 제공하려면 다음 명령을 입력합니다. 여기서 *role-name*은 액세스를 제공하려는 사용자의 이름입니다. ``` grant role sys:operator to "IAMR:role-name"; ``` # RPU 제한 설정을 포함한 사용 제한 설정 작업 그룹의 **한도(Limits)** 탭에서 하나 이상의 사용량 한도를 추가하여 지정된 기간 동안 사용하는 최대 RPU를 제어하거나 데이터 공유 사용량 한도를 설정할 수 있습니다. 1. **사용량 한도 관리(Manage usage limits)**를 선택합니다. 한도 섹션은 **기간별 컴퓨팅 사용량** 패널 하단에 표시됩니다. 1. 사용량 한도를 RPU 시간 단위로 설정합니다. 1. **빈도**를 **일별**, **주별** 또는 **월별** 중에서 선택합니다. 이로써 사용량 한도의 기간이 설정됩니다. 이 인스턴스에서 **일별(Daily)**을 선택하면 보다 세부적으로 제어할 수 있습니다. 1. 사용량 한도를 시간 단위로 설정합니다. 1. 작업을 설정합니다. 다음과 같은 설정이 있습니다. + **시스템 테이블에 기록** - 시스템 뷰 [SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY.html)에 레코드를 추가합니다. 이 뷰의 `usage_limit` 열을 쿼리하여 쿼리가 제한을 초과했는지 확인할 수 있습니다. + **알림(Alert)** - Amazon SNS를 사용하여 알림 구독을 설정하고 한도가 위반된 경우 알림을 전송합니다. 기존 Amazon SNS 주제를 선택하거나 새로운 주제를 생성할 수 있습니다. + **사용자 쿼리 끄기(Turn off user queries)** - 쿼리를 비활성화하여 Amazon Redshift Serverless 사용을 중지합니다. 또한 알림도 전송합니다. 처음 두 작업은 정보 제공용이지만 마지막 작업은 쿼리 처리를 해제합니다. 1. 선택적으로, 소비자가 쿼리할 수 있는, 생산자 리전에서 소비자 리전으로 전송되는 데이터의 양을 제한하는 **교차 리전 데이터 공유 사용량 한도(Cross-Region data sharing usage limit)**를 설정할 수 있습니다. 이렇게 하려면 **한도 추가(Add limit)**를 선택하고 단계를 따릅니다. 1. 페이지 하단에서 **변경 사항 저장**을 선택하여 한도를 저장합니다. 1. 필요에 따라 한도를 3개까지 더 설정합니다. RPU 및 청구에 대한 개념 정보에 대한 자세한 내용은 [Amazon Redshift Serverless에 대한 청구](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-billing.html)를 참조하세요. # 쿼리 제한 설정 작업 그룹의 **Limits**(한도) 탭에서 한도를 추가하여 성능 및 한도를 모니터링할 수 있습니다. 쿼리 모니터링 제한 사항에 대한 자세한 내용은 [WLM 쿼리 모니터링 규칙](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)을 참조하세요. 1. **쿼리 한도 관리(Manage query limits)**를 선택합니다. **Manage query limits**(쿼리 한도 관리) 대화 상자에서 **Add limit**(한도 추가)를 선택합니다. 1. 설정하려는 한도 유형을 선택하고 해당 한도 값을 입력합니다. 1. **변경 사항 저장(Save changes)**을 선택하여 한도를 저장합니다. 쿼리 한도 및 구성 파라미터를 변경하면 데이터베이스가 다시 시작됩니다. # 쿼리 대기열 설정 Amazon Redshift Serverless는 대기열 기반 쿼리 리소스 관리를 지원합니다. 다양한 워크로드에 대한 사용자 지정 모니터링 규칙을 사용하여 전용 쿼리 대기열을 생성할 수 있습니다. 이 기능으로 리소스 사용량에 대한 세부적인 제어가 가능합니다. 쿼리 모니터링 규칙(QMR)은 Redshift Serverless 작업 그룹 수준에서만 적용되며 이 작업 그룹에서 실행되는 모든 쿼리에 균일하게 영향을 미칩니다. 대기열 기반 접근 방식을 통해 고유한 모니터링 규칙을 사용하여 대기열을 생성할 수 있습니다. 이러한 대기열을 특정 사용자 역할 및 쿼리 그룹에 할당할 수 있습니다. 각 대기열은 독립적으로 작동하며, 규칙은 해당 대기열 내의 쿼리에만 영향을 미칩니다. 대기열을 사용하면 지표 기반 조건자 및 자동화된 응답을 설정할 수 있습니다. 예를 들어 시간 제한을 초과하거나 너무 많은 리소스를 소비하는 쿼리를 자동으로 중단하도록 규칙을 구성할 수 있습니다. ## 고려 사항 서버리스 쿼리를 사용할 때는 다음을 고려하세요. + Amazon Redshift 프로비저닝 클러스터에 사용되는 다음 워크로드 관리(WLM) 구성 키는 Redshift Serverless 대기열에서 지원되지 않습니다. `max_execution_time`, `short_query_queue`, `auto_wlm`, `concurrency_scaling`, `priority`, `queue_type`, `query_concurrency`, `memory_percent_to_use`, `user_group`, `user_group_wild_card`. 또한 change\$1query\$1priority 작업은 Serverless에서 지원되지 않습니다. + 홉 작업(대기열 간 쿼리 이동)은 Amazon Redshift Serverless에서 지원되지 않습니다. + 대기열 우선순위는 Amazon Redshift 프로비저닝 클러스터에서만 지원됩니다. + Amazon Redshift Serverless는 최적의 성능을 위해 조정 및 리소스 할당을 자동으로 관리하므로 대기열 우선순위를 수동으로 구성할 필요가 없습니다. ## 쿼리 대기열 설정 AWS Management Console, AWS CLI 또는 Redshift Serverless API를 사용하여 서버리스 작업 그룹의 제한 탭에서 대기열을 생성할 수 있습니다. ------ #### [ Console ] 다음 단계에 따라 서버리스 작업 그룹에 대한 대기열을 생성합니다. 1. Redshift Serverless 작업 그룹으로 이동합니다. 1. 제한 탭을 선택합니다. 1. **쿼리 대기열**에서 **대기열 활성화**를 선택합니다. **중요** 쿼리 대기열을 활성화하는 것은 영구적인 변경입니다. 활성화되면 대기열 없는 모니터링으로 되돌릴 수 없습니다. 1. 다음 파라미터를 사용하여 대기열을 구성합니다. **대기열 수준 파라미터** + `name` - 대기열 식별자(필수, 고유, 비어 있지 않음) + `user_role` - 사용자 역할 배열(선택 사항) + `query_group` - 쿼리 그룹 배열(선택 사항) + `query_group_wild_card` - 와일드카드 일치를 활성화하려면 0 또는 1(선택 사항) + `user_group_wild_card` - 와일드카드 일치를 활성화하려면 0 또는 1(선택 사항) + `rules` - 모니터링 규칙 배열(선택 사항) **규칙 수준 파라미터** + `rule_name` - 고유 식별자, 최대 32자(필수) + `predicate` - 조건 배열, 1\$13개의 조건자(필수) + `action` - "중단" 또는 "로그"(필수) **조건자 수준 파라미터** + `metric_name` - 모니터링할 지표(필수) + `operator` - "=", "<" 또는 ">"(필수) + `value` - 숫자 임계값(필수) **한도** + 최대 8개의 대기열 + 모든 대기열에서 최대 25개의 규칙 + 규칙당 최대 3개의 조건자 + 이름은 전역적으로 고유해야 합니다. **구성의 예제** 대기열 3개 예: 제한 시간이 짧은 쿼리를 대시보드로 처리하기 위한 대기열 1개, 제한 시간이 긴 ETL 쿼리와 관리자 대기열을 위한 대기열 1개: ``` [ { "name": "dashboard", "user_role": ["analyst", "viewer"], "query_group": ["reporting"], "query_group_wild_card": 1, "rules": [ { "rule_name": "short_timeout", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 60 } ], "action": "abort" } ] }, { "name": "ETL", "user_role": ["data_scientist"], "query_group": ["analytics", "ml"], "rules": [ { "rule_name": "long_timeout", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 3600 } ], "action": "log" }, { "rule_name": "memory_limit", "predicate": [ { "metric_name": "query_temp_blocks_to_disk", "operator": ">", "value": 100000 } ], "action": "abort" } ] }, { "name": "admin_queue", "user_role": ["admin"], "query_group": ["admin"] } ] ``` 이 예시는 다음과 같이 설정되어 있습니다. + 대시보드 쿼리가 60초 이상 실행되면 중단됩니다. + ETL 쿼리는 1시간 이상 실행되는 경우 로깅됩니다. + 관리자 대기열에는 리소스 제한이 없습니다. ------ #### [ CLI ] `wlm_json_configuration` 구성 파라미터와 함께 CreateWorkgroup 또는 UpdateWorkgroup APIs 사용하여 대기열을 관리하여 JSON 형식으로 대기열을 지정할 수 있습니다. ``` aws redshift-serverless create-workgroup \ --workgroup-name test-workgroup \ --namespace-name test-namespace \ --config-parameters '[{"parameterKey": "wlm_json_configuration", "parameterValue": "[{\"name\":\"dashboard\",\"user_role\":[\"analyst\",\"viewer\"],\"query_group\":[\"reporting\"],\"query_group_wild_card\":1,\"rules\":[{\"rule_name\":\"short_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":60}],\"action\":\"abort\"}]},{\"name\":\"ETL\",\"user_role\":[\"data_scientist\"],\"query_group\":[\"analytics\",\"ml\"],\"rules\":[{\"rule_name\":\"long_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":3600}],\"action\":\"log\"},{\"rule_name\":\"memory_limit\",\"predicate\":[{\"metric_name\":\"query_temp_blocks_to_disk\",\"operator\":\">\",\"value\":100000}],\"action\":\"abort\"}]},{\"name\":\"admin_queue\",\"user_role\":[\"admin\"],\"query_group\":[\"admin\"]}]"}]' ``` ------ ## 모범 사례 서버리스 대기열을 사용할 때는 다음 모범 사례를 염두에 두세요. + 고유한 제한 요구 사항(예: ETL, 보고 또는 임시 분석)이 있는 워크로드에는 별도의 대기열을 사용합니다. + 간단한 임계값으로 시작하고 쿼리 동작 및 사용 패턴에 따라 조정합니다. [쿼리 모니터링 규칙에 대해 시스템 테이블 및 뷰](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html#cm-c-wlm-qmr-tables-and-views)에 문서화된 테이블 및 뷰를 사용하여 쿼리 사용 패턴을 모니터링할 수 있습니다. # 대시보드에서 Amazon Redshift Serverless 요약 데이터 확인 Amazon Redshift Serverless 대시보드에는 작업 그룹 및 네임스페이스에 대한 지표와 정보를 한눈에 보여주는 패널 모음이 포함되어 있습니다. 다음과 같은 패널 모음이 있습니다. + **Resources summary(리소스 요약)** - 사용된 스토리지 및 기타 지표와 같은 Amazon Redshift Serverless에 대한 상위 수준 정보를 표시합니다. + **쿼리 요약(Query summary)** - 완료된 쿼리 및 실행 중인 쿼리를 포함하여 쿼리에 대한 정보를 표시합니다. **세부 정보 보기(View details)**를 선택하여 추가 필터가 있는 화면으로 이동합니다. + **사용된 RPU 용량(RPU capacity used)** - 이전 10시간과 같은 지정된 기간 동안 사용된 전체 용량을 표시합니다. + **데이터 공유** - AWS 계정과 같이 데이터 공유에 사용되는 데이터 공유 수를 표시합니다. 이 지표는 권한 부여가 필요한 Datashare 및 기타 정보를 보여줍니다. + **총 컴퓨팅 사용량** - 선택한 시간 범위(최대 지난 7일) 동안 선택한 작업 그룹에서 소비한 총 RPU 시간을 표시합니다. 대시보드에서 이러한 사용 가능한 지표를 빠르게 살펴보고 Amazon Redshift Serverless에 대한 세부 정보를 확인하거나 쿼리를 검토하거나 작업 항목을 추적할 수 있습니다.