クエリエディタ v2 でのクエリのスケジューリング - Amazon Redshift

クエリエディタ v2 でのクエリのスケジューリング

Amazon Redshift クエリエディタ v2 で SQL ステートメントを実行するスケジュールを作成します。ビジネスニーズに合った時間間隔で SQL ステートメントを実行するスケジュールを作成します。スケジュールされたクエリが実行される時間になると、クエリは、Amazon EventBridge によって開始され、Amazon Redshift Data API を使用します。

SQL ステートメントを実行するスケジュールを作成するには
  1. [エディタ] Editor ビューで Schedule [スケジュール] を選択して、SQL ステートメントを実行するスケジュールを作成します。

  2. スケジュールを定義する場合は、次の情報を指定します。

    • クエリの実行に必要なアクセス許可を持つ IAM ロール。この IAM ロールは、クラスターまたはワークグループにもアタッチされます。

    • クラスターまたはワークグループへのアクセスを許可する AWS Secrets Manager または一時的な認証情報の認証値。これらの認証方法は Data API でサポートされています。詳細については、「スケジュールされたクエリの認証」を参照してください。

    • データベースが存在するクラスターまたはワークグループ。

    • クエリを実行するデータを含むデータベースの名前。

    • スケジュールされたクエリの名前とその説明。クエリエディタ v2 は、指定のスケジュールされたクエリ名の先頭に「QS2-」を付けます。クエリエディタ v1 は、スケジュールされたクエリ名の先頭に「QS-」を付けます。

    • スケジュールで実行される SQL ステートメント。

    • スケジュールの頻度とリピートオプション、またはスケジュールを定義する cron 形式の値。詳細については、Amazon CloudWatch Events ユーザーガイドCron 式を参照してください。

    • オプションで、標準の Amazon SNS 通知を有効にして、スケジュールされたクエリをモニタリングできます。場合によっては、Amazon SNS 通知に提供する E メールアドレスを確認する必要があります。Amazon SNS 通知の E メールアドレスを確認するリンクが送信されるため、E メールをチェックしてください。詳細については、Amazon Simple Notification Service デベロッパーガイドの「E メール通知」を参照してください。クエリが実行されているにもかかわらず、SNS トピックにパブリッシュされているメッセージが表示されない場合は、Amazon EventBridge ユーザーガイドの「ルールは実行されるが、Amazon SNS トピックにいずれのメッセージもパブリッシュされない」を参照してください。

  3. [クエリをスケジュール] を選択してスケジュールを保存して有効にし、スケジュールを[スケジュールされたクエリ] ビューのクエリのリストに追加します。

[スケジュールされたクエリ] Scheduled queries ビューには、クラスターとワークグループのすべてのスケジュールされたクエリが一覧表示されます。このビューでは、スケジュールクエリの詳細の表示、スケジュールの有効化または無効化、スケジュールの編集、およびスケジュールされたクエリの削除を行うことができます。クエリの詳細を表示すると、スケジュールとともにクエリを実行した履歴も表示できます。

注記

スケジュールのクエリは、24 時間の [スケジュール履歴] 内でのみ実行できます。スケジュールに従って実行されるクエリは、クエリエディタ v2 の [クエリ履歴] ビューには表示されません。

クエリをスケジュールするアクセス許可の設定

クエリをスケジュールするには、スケジュールを定義する AWS Identity and Access Management (IAM) ユーザーとスケジュールに関連付けられている IAM ロールが Amazon EventBridge と Amazon Redshift Data API を使用する IAM アクセス許可で設定されている必要があります。スケジュールされたクエリから E メールを受信するには、オプションで指定する Amazon SNS 通知も設定する必要があります。

以下では、AWS マネージドポリシーを使用してアクセス許可を付与するタスクについて説明しますが、環境によっては、許可されるアクセス許可の範囲の絞り込みが必要な場合があります。

クエリエディタ v2 にログインしている IAM ユーザーの場合は、IAM コンソール (https://console.aws.amazon.com/iam/) を使用して IAM ユーザーを編集します。

  • Amazon Redshift とクエリエディタ v2 のオペレーションを実行するアクセス許可に加えて、IAM ユーザーに AmazonEventBridgeFullAccess および AmazonRedshiftDataFullAccess AWS マネージドポリシーをアタッチします。

  • または、ロールにアクセス許可を割り当て、そのロールをユーザーに割り当てます。

    スケジュールされたクエリを定義するときに指定する IAM ロールのリソース ARN に sts:AssumeRole アクセス許可を与えるポリシーをアタッチします。ロールの引き受けについての詳細は、IAM ユーザーガイドの「ロールを切り替えるアクセス許可をユーザーに付与する」を参照してください。

    次の例では、アカウント 123456789012 で IAM ロール myRedshiftRole を引き受けるアクセス許可ポリシーを示します。IAM ロール myRedshiftRole は、スケジュールされたクエリを実行するクラスターまたはワークグループにアタッチする IAM ロールでもあります。

    { "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeIAMRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::123456789012:role/myRedshiftRole" ] } ] }

    クエリのスケジュールに使用する IAM ロールの信頼ポリシーを更新して、IAM ユーザーがロールを引き受けられるようにします。

    { "Sid": "AssumeRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/myIAMusername" }, "Action": "sts:AssumeRole" } ] }

スケジュールされたクエリの実行を許可するように指定した IAM ロールについては、IAM コンソール (https://console.aws.amazon.com/iam/) を使用して IAM ロールを編集します。

  • AmazonRedshiftDataFullAccess および AmazonEventBridgeFullAccess AWS マネージドポリシーを IAM ロールにアタッチします。AmazonRedshiftDataFullAccess マネージドポリシーは、キー RedshiftDataFullAccess でタグ付けされた Redshift Serverless ワークグループに対してのみ redshift-serverless:GetCredentials アクセス許可を付与します。

スケジュールされたクエリの認証

クエリをスケジュールする場合は、SQL の実行時に、次のいずれかの認証方法を使用します。各メソッドでは、クエリエディタ v2 の入力の異なる組み合わせが必要です。これらの認証方法は、SQL ステートメントの実行に使用される Data API によってサポートされています。

クエリを実行するために使用されるデータベースユーザーまたはロールには、適切なデータベース権限が必要です。例えば、テーブル mytable に IAMR:MyRedshiftQEv2Scheduler 権限を付与するには、次の SQL コマンドを実行します。

GRANT all ON TABLE mytable TO "IAMR:MyRedshiftQEv2Scheduler";

クラスターまたはワークグループ内のデータベースユーザーのリストを表示するには、システムビュー PG_USER_INFO にクエリを実行します。

注記

クエリをスケジュールする対象のすべての Redshift Serverless ワークグループに、キー RedshiftDataFullAccess でタグ付けする必要があります。詳細については、「Amazon Redshift Data API へのアクセスの認可」を参照してください。

ワークグループにタグを付ける代わりに、redshift-serverless:GetCredentials を許可するインラインポリシーを (スケジュールと一緒に指定する) IAMロールに追加できます。例:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "UseTemporaryCredentialsForAllServerlessWorkgroups", "Effect": "Allow", "Action": "redshift-serverless:GetCredentials", "Resource": [ "arn:aws:redshift-serverless:*:*:workgroup/*" ] } ] }
AWS Secrets Manager

この方法を使用して、AWS Secrets Manager に保存されている secret-arn のシークレット値を指定します。このシークレットには、データベースに接続するための認証情報が含まれます。クラスターまたはワークグループの作成時に、適切な認証情報を使用してシークレットを作成したとします。シークレットにはキー RedshiftDataFullAccess のタグを付ける必要があります。タグキーがない場合は、AWS Secrets Manager コンソールを使用して追加します。シークレットの作成方法の詳細については、「データベース接続認証情報のシークレットの作成」を参照してください。

最小のアクセス許可についての詳細は、AWS Secrets Manager ユーザーガイドの「AWS Secrets Manager を使用したシークレットの作成と管理」を参照してください。

一時認証情報

このメソッドでは、クラスター内のデータベースに接続するときに、データベース名データベースユーザーの値を指定します。データベース名は、ワークグループ内のデータベースに接続するときだけに指定する必要があります。

クラスターに接続する場合、AmazonRedshiftDataFullAccess ポリシーは、redshift_data_api_user という名前のデータベースユーザーに redshift:GetClusterCredentials へのアクセス許可を付与します。別のデータベースユーザーを使用して SQL ステートメントを実行する場合は、クラスターにアタッチされた IAM ロールにポリシーを追加して redshift:GetClusterCredentials を許可します。次のポリシー例では、データベースユーザー awsusermyuser を許可しています。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "UseTemporaryCredentialsForAllDbUsers", "Effect": "Allow", "Action": "redshift:GetClusterCredentials", "Resource": [ "arn:aws:redshift:*:*:dbuser:*/awsuser", "arn:aws:redshift:*:*:dbuser:*/myuser" ] } ] }

スケジュールクエリ履歴を表示するアクセス許可の設定

ユーザーにスケジュールクエリ履歴の表示を許可するには、スケジュールと一緒に指定する IAM ロールの信頼関係を編集してアクセス許可を追加します。

次に示すのは、IAM ユーザー myIAMusername にスケジュールクエリの履歴を表示できるようにする IAM ロールの信頼ポリシーの例です。IAM ユーザーに sts:AssumeRole アクセス許可を付与する代わりに、このアクセス許可を IAM ロールに付与するように選択できます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "redshift.amazonaws.com", "redshift-serverless.amazonaws.com" ] }, "Action": "sts:AssumeRole" }, { "Effect": "Allow", "Principal": { "Service": "events.amazonaws.com" }, "Action": "sts:AssumeRole" }, { "Sid": "AssumeRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/myIAMusername" }, "Action": "sts:AssumeRole" } ] }

スケジュールされたクエリのモニタリング

E メール通知を送信するように指定した Amazon SNS トピックについては、クエリエディタ v2 を使用して Amazon SNS トピックを作成します。これを行うには、[SNS 通知] セクションに移動し、モニタリングを [オンにする] を選択して、[SNS トピックの作成] でトピックを作成します。クエリエディタ v2 は Amazon SNS トピックを作成し、Amazon EventBridge のアクセスポリシーにサービスプリンシパルを追加します。次に示すのは、Amazon SNS トピックで作成したアクセスポリシーの例です。この例では、AWS リージョン us-west-2、AWS アカウント 123456789012、および Amazon SNS トピックselect-version-pdx-testunload を使用しています。

{ "Version": "2008-10-17", "Id": "__default_policy_ID", "Statement": [ { "Sid": "Allow_Publish_Events", "Effect": "Allow", "Principal": { "Service": "events.amazonaws.com" }, "Action": "sns:Publish", "Resource": "arn:aws:sns:us-west-2:123456789012:select-version-pdx-testunload" } ] }

スケジュールされたクエリが実行されると、Amazon SNS は AWS 通知 E メールを送信します。次は、Amazon SNS 通知トピック may25a-SNS を使って AWS アカウント 123456789012 の AWS リージョン eu-north-1 で実行された、スケジュールされたクエリ QS2-may25a について、myemail@example.com に送信された E メールの例です。

{"version":"0","id":"8e4323ec-5258-7138-181b-91290e30ff9b","detail-type":"Scheduled Event","source":"aws.events","account":"123456789012","time":"2023-05-25T15:22:00Z", "region":"eu-north-1","resources":["arn:aws:events:eu-north-1:123456789012:rule/QS2-may25a"],"detail":{}} -- If you wish to stop receiving notifications from this topic, please click or visit the link below to unsubscribe: https://sns.eu-north-1.amazonaws.com/unsubscribe.html?SubscriptionArn=arn:aws:sns:eu-north-1:123456789012:may25a-SNS:0c1a3d05-39c2-4507-bc3d-47250513d7b0&Endpoint=myemail@example.com Please do not reply directly to this email. If you have any questions or comments regarding this email, please contact us at https://aws.amazon.com/support

クエリのスケジュールのセットアップに関するトラブルシューティング

クエリのスケジュールに問題がある場合は、次の点を考慮してください。

クエリが実行していない

スケジュールで使用している IAM ロールに、一時的なクラスター認証情報を取得するアクセス許可があるかどうかを確認します。プロビジョニングされたクラスターのアクセス許可は redshift:GetClusterCredentialsWithIAM です。Redshift Serverless ワークグループのアクセス許可は redshift-serverless:GetCredentials です。

スケジュールされた履歴が表示されない

AWS コンソールへのログインに使用する IAM ユーザーまたは IAM ロールが、クエリのスケジュールに使用された IAM ロールの信頼ポリシーに追加されていませんでした。

スケジュールされたクエリに AWS Secrets Manager を使用し、接続する場合は、シークレットがキー RedshiftDataFullAccess でタグ付けされていることを確認します。

スケジュールされたクエリが AWS Secrets Manager 接続を使用している場合、クエリのスケジュールに使用される IAM ロールには、SecretsManagerReadWrite 管理ポリシーと同等のものがロールにアタッチされている必要があります。

クエリ履歴のステータスが Failed である

クエリが失敗した理由の詳細については、SYS_QUERY_HISTORY システムビューを参照してください。よくある問題は、クエリの実行に使用したデータベースユーザーまたはロールに SQL の実行に必要な権限がないことです。詳細については、「スケジュールされたクエリの認証」を参照してください。

次の SQL は、SYS_QUERY_HISTORY ビューにクエリを実行して、失敗したクエリを返します。

SELECT user_id, query_id, transaction_id, session_id, database_name, query_type, status, error_message, query_text FROM sys_query_history WHERE status = 'failed';

失敗した特定のスケジュールされたクエリの詳細を確認するには、「スケジュールされたクエリの詳細を AWS CloudShell で確認する」を参照してください。

スケジュールされたクエリの詳細を AWS CloudShell で確認する

AWS CloudShell を使用してスケジュールクエリの詳細を確認できます。次の手順に示す、AWS CLI コマンドを実行するための適切なアクセス許可を持っている必要があります。

スケジュールされたクエリの結果を表示するには
  1. AWS コンソールで、AWS CloudShell コマンドプロンプトを開きます。AWS CloudShell の詳細については、「AWS CloudShell ユーザーガイド」の「AWS CloudShell とは」を参照してください。

  2. スケジュールされたクエリの IAM ロールを引き受けます。ロールを引き受けるには、スケジュールされたクエリに関連付けられた IAM ロールをクエリエディタ v2 で見つけて、AWS CLI コマンドを AWS CloudShell で使用します。例えば、ロール scheduler の場合は、AWS STS コマンドを入力して、スケジュールされたクエリで使用されているロールを引き受けます。

    aws sts assume-role —role-arn "arn:aws:iam::123456789012:role/scheduler" —role-session-name "scheduler-test"

    返される認証情報は次のようになります。

    "Credentials": { "AccessKeyId": "AKIAIOSFODNN7EXAMPLE", "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY", "SessionToken": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY...", "Expiration": "2023-08-18T18:19:44+00:00" }, "AssumedRoleUser": { "AssumedRoleId": "AROA35B2NH6WBTP7ONL4E:scheduler-test", "Arn": "arn:aws:sts::123456789012:assumed-role/scheduler/scheduler-test" } }
  3. IAM ロールを引き受けたときに表示される認証情報を使用して、AWS CLI で環境変数を作成します。これらのトークンは、有効期限が切れる前に使用する必要があります。例えば、AWS CloudShell に次の内容を入力します。

    export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY export AWS_SESSION_TOKEN=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY...
  4. 失敗したクエリのエラーを表示するには、ステートメントを記述する AWS CLI コマンドを実行します。SQL ステートメントの ID は、クエリエディタ v2 でスケジュールされたクエリの [スケジュール履歴] セクションに表示される [ID] からのものです。

    aws redshift-data describe-statement —id 130d2620-05d2-439c-b7cf-815d9767f513

    この例の場合、スケジュールされた SQL select * from users limit 100 は、users テーブルが存在しないという SQL エラーになります。

    { "CreatedAt": "2023-08-18T17:39:15.563000+00:00", "Duration": -1, "Error": "ERROR: relation \"users\" does not exist", "HasResultSet": false, "Id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "QueryString": "select * from users limit 100\n—RequestID=a1b2c3d4-5678-90ab-cdef-EXAMPLE22222; TraceID=1-633c5642-4039308d03f3a0ba53dbdf6f", "RedshiftPid": 1073766651, "RedshiftQueryId": 0, "ResultRows": -1, "ResultSize": -1, "Status": "FAILED", "UpdatedAt": "2023-08-18T17:39:16.116000+00:00", "WorkgroupName": "default" }

クエリのスケジュールのデモ

クエリのスケジューリングのデモについては、次の動画をご覧ください。