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 要件を満たしていないクエリに対しては、使用開始当初から、あるいは時間の経過とともに性能が低下した際に調整を行う必要があります。調整のためには、実行計画、統計、有効期間、リソース消費量など、ランタイムに関する詳細事項を決定する必要があります。逸脱を起こした原因を特定し、パフォーマンスの改善の方法を探るには、問題のあるクエリにおける基準のデータが必要となります。 **ユーザーオブジェクトでのイベントのモニタリング** ユーザーオブジェクトでは、マテリアライズドビューのリフレッシュ、バキュームおよび分析など、アクションやアクティビティをモニタリングする必要があります。これには、マテリアライズドビューの自動更新など、システムが管理するイベントも含まれます。ユーザーが開始したイベントについてはその終了タイミングを、また、システムが開始した場合には最後に正常に実行されたイベントを、それぞれモニタリングします。 **課金のための使用状況の追跡** 以下の目的のために、時間の経過に伴う使用状況の傾向変化をモニタリングします。 + 予算計画ならびに事業の拡大見通しの報告。 + コールドデータの削除など、潜在的なコスト削減機会の特定。 Amazon Redshift Serverless をモニタリングするには、SYS システムビューを使用します。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. **[Review policy]** (ポリシーの確認) を選択します。 1. **[Name]** (名前) にポリシーの名前を入力します (例: `query-monitoring`)。 1. [**Create policy**] (ポリシーの作成) を選択します。 ポリシーを作成したら、適切なアクセス許可を付与できます。 アクセス権限を付与するにはユーザー、グループ、またはロールにアクセス許可を追加します。 + AWS IAM アイデンティティセンター のユーザーとグループ: アクセス許可セットを作成します。「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[アクセス許可セットを作成する](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html)」の手順に従ってください。 + IAM 内で、ID プロバイダーによって管理されているユーザー: ID フェデレーションのロールを作成します。詳細については *IAM ユーザーガイド* の [サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成する](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) を参照してください。 + IAM ユーザー: + ユーザーが担当できるロールを作成します。手順については *IAM ユーザーガイド* の [IAM ユーザーのロールの作成](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`許可を持つユーザーは、クエリのキャンセル、クエリ履歴の分析、およびバキューム操作を実行することができます。 **ユーザーにクエリモニタリング許可を付与する** 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`許可を持つロールが設定されたユーザーは、クエリのキャンセル、クエリ履歴の分析、およびバキューム操作を実行することができます。 **ロールにクエリモニタリング許可を付与する** 1. 以下のコマンドを入力して、システムモニタリングのアクセス権を提供します。*role-name* は、アクセス権を提供するロールの名前です。 ``` grant role sys:monitor to "IAMR:role-name"; ``` 1. (オプション) 以下のコマンドを入力して、システムオペレーターのアクセス権を提供します。*role-name* は、アクセス権を提供するロールの名前です。 ``` grant role sys:operator to "IAMR:role-name"; ``` # RPU 制限の設定を含む使用制限の設定 ワークグループの **[Limits]** (制限) タブでは、1 つ以上の使用制限を追加して、特定の期間に使用する最大 RPU を管理したり、データ共有の使用制限を設定できます。 1. **[Manage usage limits]** (使用制限の管理) を選択します。[制限] セクションは、**[Compute usage by period]** パネルの下部に表示されます。 1. 使用制限の期間を設定します。 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 の使用を停止します。また、通知を送信します。 最初の 2 つのアクションは情報提供ですが、最後のアクションはクエリ処理をオフにします。 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 new limit]** (新しい制限の追加) を選択します。 1. 設定する制限タイプを選択し、対応する制限の値を入力します。 1. **[Save changes]** (変更の保存) を選択して設定を保存します。 クエリ制限と構成パラメータを変更すると、データベースが再起動します。 # クエリキューの設定 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)に記載されているテーブルとビューを使用して、クエリの使用パターンをモニタリングできます。 # ダッシュボードを使用して Amazon Redshift Serverless 概要データをチェックする Amazon Redshift Serverless ダッシュボードには、ワークグループと名前空間に関するメトリクスやその他の情報が一目でわかるようにパネルが集められています。これには次のようなものがあります。 + **[Resources summary]** (リソースの概要) - 使用されているストレージ、その他のメトリックなど、Amazon Redshift Serverless に関する情報の概要を表示します。 + **クエリの概要** - 完了したクエリや実行中のクエリなど、クエリに関する情報を表示します。**[View details]** (詳細を表示) をクリックして、追加のフィルターがある画面に移動します。 + **RPU 容量** - 例えば、過去 10 時間など、特定の期間に使用された全体の容量を表示します。 + **データ共有** - データ共有数を表示します。データ共有は、例えば AWS アカウントのデータの共有に使用されます。メトリクスは、認可が必要なデータ共有やその他の情報を示します。 + **Total compute usage** - 選択した期間にわたって、選択したワークグループで利用された合計 RPU 時間を最大過去 7 日間まで表示します。 これらの利用できるメトリクスの詳細をダッシュボードからすばやく調べることで、Amazon Redshift Serverless に関する詳細の確認、クエリの調査、作業項目の追跡などが可能となります。