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 は、キューベースのクエリリソース管理をサポートしています。ワークロードごとにカスタマイズされたモニタリングルールを使用して、専用のクエリキューを作成できます。この機能により、リソースの使用状況をきめ細かく制御できます。
クエリのモニタリングルール (QMR) は Redshift Serverless ワークグループレベルでのみ適用され、このワークグループで実行されるすべてのクエリに均一に影響します。キューベースのアプローチでは、個別のモニタリングルールを使用してキューを作成できます。これらのキューは、特定のユーザーロールとクエリグループに割り当てることができます。各キューは独立して動作し、ルールはそのキュー内のクエリにのみ影響します。
キューを使用して、メトリクスベースの述語と自動応答を設定できます。例えば、時間制限を超えた、またはリソースを大量に消費するクエリを自動的に中止するようにルールを設定できます。
## 考慮事項
サーバーレスキューを使用する場合、次の点を考慮してください。
+ Amazon Redshift でプロビジョニングされたクラスターで使用されるワークロード管理 (WLM) 設定キーの、`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` は、Redshift Serverless キューではサポートされていません。
さらにホップすると、change\$1query\$1priority アクションは Serverless ではサポートされていません。
+ ホップアクション (キュー間のクエリの移動) は、Amazon Redshift Serverless ではサポートされていません。
+ キューの優先順位は、Amazon Redshift でプロビジョニングされたクラスターでのみサポートされます。
+ Amazon Redshift Serverless は、パフォーマンスが最適になるようにスケーリングとリソース割り当てを自動的に管理するため、キューの優先順位を手動で設定する必要はありません。
## クエリキューの設定
AWS マネジメントコンソール、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～3 述語 (必須)
+ `action` - 「中止」または「ログ」 (必須)
**述語レベルのパラメータ**
+ `metric_name` - モニタリングするメトリクス (必須)
+ `operator` - 「=」、「<」、または「>」(必須)
+ `value` - 数値のしきい値 (必須)
**制限**
+ 最大 8 キュー
+ すべてのキューで最大 25 個のルール
+ ルールあたり最大 3 つの述語
+ ルール名はグローバルで一意である必要があります。
**構成例**
3 つのキューの例: 1 つは短いタイムアウトのダッシュボードクエリ用、もう 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 ]
CreateWorkgroup API または UpdateWorkgroup API と `wlm_json_configuration` 設定パラメータを使用してキューを管理し、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)に記載されているテーブルとビューを使用して、クエリの使用パターンをモニタリングできます。