querying-aws-redshift

AWS Redshift システムテーブルのクエリ

概要

サンドボックスでの実行と監査ログには、AWS MCP サーバーとの併用が最適です。 以下のコマンドはすべて AWS CLI を使用し、AWS 認証情報が設定されているあらゆる環境で動作します。IAM ロールまたは一時的な認証情報を使用し、長期間有効なアクセスキーは避けてください。

Redshift は、sys_query_history、sys_query_detail、sys_connection_log などの SYS_* 監視データであるシステムテーブルを、継続的に更新される Apache Iceberg テーブルとして S3 Tables に公開できます。

以下では、システムテーブルは一般に SYS_* データセットを指し、それぞれが公開された Iceberg テーブルに 1 対 1 で対応します。このスキルで SYS_ ビューと記載する場合、クラスター上で直接クエリする、クラスター内のライブオブジェクトを指します。これはビューであり、公開された S3 Tables のコピーとは別のものです。これはプロビジョニング済みクラスターとサーバーレス名前空間の両方に当てはまります。これは既存のログ記録 API を拡張するオプトイン機能です。公開されたテーブルは読み取り専用で、AWS 管理の aws-redshift テーブルバケットに保存され、Amazon Athena や Amazon Redshift 自体を含む、あらゆる Iceberg 互換エンジンからクエリできます。

履歴データや大量のシステムテーブルデータを分析する場合は、ライブのクラスター内 SYS_ ビューよりも S3 Tables のコピーをクエリすることを推奨します。理由は次のとおりです。

• クラスター内の SYS_ ビューには保持期間の制限がありますが、S3 Tables ではそれを大幅に超えて履歴が保持されます。
• S3 Tables へのクエリは、実行中の Redshift クラスターに負荷をかけません。
• ログは Iceberg テーブルなので、あらゆる Iceberg 互換エンジンから大規模にクエリでき、他のデータレイクのデータと結合できます。

判断ツリー

ユーザーの目的	このスキルを使用しますか？	代替手段
クラスターまたは名前空間の S3 Tables ログ公開を有効にする	はい	—
クラスター／名前空間が公開中か確認する／その S3 Tables 名前空間を見つける	はい	—
Redshift システムテーブルのリアルタイム以外のデータをクエリする	はい	—
Redshift の監視と監査のための日次／週次／月次ダッシュボードを作成する	はい	—
S3 Tables の公開を選択的に停止する	はい	—
公開されたシステムテーブルを Redshift からクエリする（データベース間）	はい	—
公開されたシステムテーブルを Athena からクエリする	はい	—
ライブクラスター上の現在のリアルタイムな SYS_ の状態を調べる	いいえ	クラスター上で SYS_ ビューを直接クエリする
顧客テーブル内のデータをクエリする	いいえ	クラスター上で Redshift SQL を直接実行する

サポート対象のデータソース

コンピューティングタイプ	有効化／無効化 API	ステータス API	粒度のオプション
Redshift プロビジョニング済みクラスター	redshift enable-logging / redshift disable-logging	redshift describe-logging-status	cluster（デフォルト）、account
Redshift サーバーレス名前空間	--s3-table-action Enable/Disable を指定した redshift-serverless update-namespace	redshift-serverless get-namespace	namespace（デフォルト）、account

どちらのコンピューティングタイプも、AWS 管理の同じ aws-redshift テーブルバケットに公開され、公開後のクエリ方法も同じです。異なるのは有効化／無効化 API と、ステータス応答の大文字・小文字表記だけです。共通タスクのフラグとフィールドの表を参照してください。

このスキルの対象外：S3 または CloudWatch に配信される Redshift 監査ログ（useractivitylog、userlog、connectionlog）。これらは Serverless の別の --log-exports の仕組みを使用し、SYS_* システムテーブルではありません。

共通タスク

1. 設定されているか確認する

クエリを実行する前に、クラスターまたは名前空間が S3 Tables に発行していることを確認します。

# Provisioned
aws redshift describe-logging-status --region <REGION> --cluster-identifier <CLUSTER_ID>
# Serverless
aws redshift-serverless get-namespace --region <REGION> --namespace-name <NAMESPACE_NAME>

応答を解釈します。 2 つのコンピューティングタイプは、フィールド名と大文字・小文字の表記が異なるだけで、同じ情報を返します。Provisioned では S3Tables の下に PascalCase で、Serverless では namespace.s3TablePublishStatus の下に camelCase で表示されます。

意味	Provisioned（describe-logging-status）	Serverless（get-namespace）
有効になっていない	LoggingEnabled: false または S3Tables ブロックがない	s3TablePublishStatus ブロックがない
出力先に S3 Tables が含まれる	LogDestinationType に s3table が含まれる	logDestinationType に s3table が含まれる
発行済み SYS_* テーブルの一覧	S3Tables.S3Tables	namespace.s3TablePublishStatus.s3Tables
正確な S3 Tables 名前空間（クエリに必要）	S3Tables.S3TableNamespace	namespace.s3TablePublishStatus.s3TableNamespace
詳細度	S3Tables.S3TableGranularity（cluster／account）	namespace.s3TablePublishStatus.s3TableGranularity（namespace／account）
テーブルごとの最終取り込み時刻	S3Tables.LastIngestionTimes	namespace.s3TablePublishStatus.lastIngestionTimes
利用可能なすべてのシステムテーブルが発行済み	S3Tables.EnabledAll	namespace.s3TablePublishStatus.enabledAll

注意事項：

• 有効な出力先が複数ある場合、LogDestinationType は カンマ区切りのリストになります（例："cloudwatch,s3table"）。s3table との完全一致ではなく、部分文字列の一致で確認してください。
• LastIngestionTimes／lastIngestionTimes マップが空の場合、または発行済みとして一覧にあるテーブルがマップにない場合、そのテーブルのデータはまだ処理中の可能性があります。値を続けて比較し、新しいデータが取り込まれていることを確認してください。
• Serverless では、この機能についてトップレベルの logExports フィールドを参照しないでください。このフィールドには CloudWatch／S3 監査ログ（useractivitylog、userlog、connectionlog）が含まれ、SYS_* の S3 Tables 発行とは関係ありません。

2. 有効にする（未設定の場合）

# Provisioned
aws redshift enable-logging --region <REGION> --cluster-identifier <CLUSTER_ID> --log-destination-type s3table --log-exports <SYS_TABLE>... --s3-table-granularity <cluster|account> --s3-table-kms-key-id <KMS_KEY_ARN>
# Serverless
aws redshift-serverless update-namespace --region <REGION> --namespace-name <NAMESPACE_NAME> --log-destination-type s3table --s3-table-names <SYS_TABLE>... --s3-table-action Enable --s3-table-granularity <namespace|account> --s3-table-kms-key-id <KMS_KEY_ARN>

--s3-table-kms-key-id は、どちらのコマンドでも意図的に指定されており、任意の追加オプションではありません。省略してもエラーにはなりませんが、テーブルでは監査やポリシーによる制限、失効ができない AWS 所有のキーが代わりに使用されます。SYS_* テーブルには query_text、user_name、remote_host が含まれるため、カスタマー管理キーをデフォルトとして扱い、一時的な環境でのみこのフラグを省略してください。

AWS コンソールから有効にする場合は、Amazon Redshift コンソール > クラスター > 対象のクラスターを選択 > タブ > 統合 / システムテーブル統合の順に進みます。

同じ機能でも、コンピューティングタイプによってフラグが異なります。 Provisioned のフラグ名を Serverless にそのまま使わないでください。

目的	Provisioned（enable-logging）	Serverless（update-namespace）
公開するシステムテーブル	--log-exports	--s3-table-names
有効化と無効化	enable-logging / disable-logging の個別の操作	--s3-table-action Enable | Disable
粒度	--s3-table-granularity cluster | account	--s3-table-granularity namespace | account
カスタマー管理の KMS キー	--s3-table-kms-key-id	--s3-table-kms-key-id
適用せずに検証	--dry-run	--dry-run

補足：

• 粒度：Provisioned では cluster（デフォルト）または account、Serverless では namespace（デフォルト）または account がサポートされています。
• cluster / namespace の粒度では、クラスターまたは名前空間ごとに 1 つの S3 テーブルが作成されます。account では、リージョンごとにアカウント内のすべてのクラスターまたは名前空間で共有するテーブルが 1 つ作成されます。
• 利用可能なすべての SYS_* テーブルを公開するには、Provisioned では --log-exports all、Serverless では --s3-table-names all のように all を使用します。
• 本番環境では、保存時の暗号化を強く推奨します。 --s3-table-kms-key-id を指定しない場合、公開されるテーブルは、監査やポリシーによる制限、失効ができない AWS 所有のキーで暗号化されます。SYS_* テーブルには query_text、user_name、remote_host が含まれるため（セキュリティに関する考慮事項を参照）、カスタマー管理キーを指定してください。キーへのアクセス権を付与するには、簡略化したアクション一覧ではなく、${SKILL_DIR}/references/security.md にある完全なキーポリシーを使用してください。公開用の systemtables.redshift.amazonaws.com と、テーブルのメンテナンス／コンパクション用の maintenance.s3tables.amazonaws.com という 2 つのサービスプリンシパルが必要です。公開用のプリンシパルのみを設定すると、書き込みは成功してもコンパクションがひそかに失敗します。
• どちらの操作でも、何も変更せずにリクエストを検証するために --dry-run を指定できます。Provisioned では、成功時に DryRunOperation エラー（「Request would have succeeded, but DryRun flag is set」）が返されます。Serverless では、空の本文と終了コード 0 が返されます。なお、Serverless のドライランで検証されるのはリクエストの 形式 のみで、パラメータ値は検証されません。そのため、ドライランが成功しても値が受け入れられるとは限りません。

対象を選んで無効にする：

# Provisioned
aws redshift disable-logging --region <REGION> --cluster-identifier <CLUSTER_ID> --log-destination-type s3table --log-exports <SYS_TABLE>...
# Serverless
aws redshift-serverless update-namespace --region <REGION> --namespace-name <NAMESPACE_NAME> --log-destination-type s3table --s3-table-names <SYS_TABLE>... --s3-table-action Disable

3. 権限を確認する

両方の方法のセットアップコマンドの全容は、${SKILL_DIR}/references/permissions-setup.md を参照してください。ロールを作成したりリソースを登録したりする前に、このファイルを読み込んでください。

Athena の方法 — Glue に s3tablescatalog/aws-redshift カタログを登録し、出力先が設定されたワークグループと、S3 Tables の読み取り権限が必要です。カタログにクエリできることを確認します。

aws glue get-databases --region <REGION> \
  --catalog-id "<ACCOUNT>:s3tablescatalog/aws-redshift"

名前空間が返されれば、登録済みでクエリ可能です。EntityNotFoundException／CATALOG_NOT_FOUND が返される場合、S3 Tables 統合が有効になっていません（S3 コンソール > Table buckets > Enable integration）。ワークグループの出力先は暗号化してください — Athena は query_text や user_name を含むクエリ結果一式を S3 に書き込みます。

Redshift の自動マウント方法 — Provisioned RA3 クラスターと、4 段階のセットアップが必要です。query_s3_tables ロールを作成し（信頼ポリシーには redshift.amazonaws.com と lakeformation.amazonaws.com の両方を指定し、後者には sts:AssumeRole、sts:SetContext、sts:SetSourceIdentity、sts:TagSession の 4 つすべてを指定します）、クラスターにアタッチし、Lake Formation にテーブルバケットを登録して、Redshift のサービスリンクロールを ReadOnlyAdmins に追加します。失敗の主な原因となる制約は次のとおりです。

• 両方の信頼ステートメントに aws:SourceAccount の条件を設定してください — サービスプリンシパルだけを指定すると、混乱した代理人のリスクが生じます。
• クラスターのクエリロールに AWSLakeFormationDataAdmin をアタッチしないでください。 これはセットアップを実行するプリンシパルが、セットアップ中に限って必要とするロールです。クラスターのロールには読み取りアクセスだけが必要です。
• 自動マウントはコールバックではなくポーリングです — カタログが pg_database に表示されるまで、最大 300 秒かかることがあります。クラスターを再起動すると、検出が直ちに実行されます。

4. 対象テーブルを特定する

名前空間 — API から取得してください。自分で組み立てないでください。

• describe-logging-status（Provisioned）から S3Tables.S3TableNamespace を、または get-namespace（Serverless）から s3TablePublishStatus.s3TableNamespace を読み取り、そのまま使用します。
• 任意の簡易確認のみ：API の値は通常、粒度が cluster／namespace の場合は <namespace_arn_id>_sys、account の場合は <account>_sys の形式になります。値が正しいように見えるかの確認にのみ使用してください。API レスポンスが取得できない場合に、名前空間を生成するために使用してはいけません。

テーブル — 公開可能なシステムテーブルはそれぞれ、aws-redshift テーブルバケット内のテーブルに 1 対 1 で対応します。記憶した一覧を使って作業しないでください。実行時に、次の順序で特定します。

1. このクラスター／名前空間で公開されているテーブルのセット — 上記のステータス呼び出しから取得する S3Tables.S3Tables（Provisioned）または s3TablePublishStatus.s3Tables（Serverless）。例：sys_query_history。これが「現時点で何をクエリできるか」に対する唯一の信頼できる答えです。
2. この API が受け付けるテーブルのセット — aws redshift enable-logging help（受け付ける --log-exports 値）または aws redshift-serverless update-namespace help（受け付ける --s3-table-names 値）。
3. 各テーブルの内容 — 公開されている Redshift SYS 監視ビューのリファレンスには、すべての SYS_* ビューとその列が記載されています。AWS はビューを随時追加するため、1 つに固定した一覧ではなく、最新の一覧としてドキュメントを参照してください。

列名と型は、同じ公開リファレンスまたはライブテーブルから取得します。

aws glue get-table --region <REGION> \
  --catalog-id "<ACCOUNT>:s3tablescatalog/aws-redshift" \
  --database-name "<NAMESPACE>" --name "<SYS_TABLE>"

公開ドキュメントと公開済みテーブルを照らし合わせる際は、次の 2 点に注意してください。列挙値を取る列（query_type、status、event）の値は随時増えるため、想定した値だけで絞り込まず、SELECT DISTINCT で確認してください。また、公開される Iceberg テーブルには、ウェアハウスの識別情報を示す列（warehouse_name、warehouse_namespace_arn など）が先頭に追加されます。これらの列はクラスター内の SYS_ ビューにはなく、粒度が account の場合に公開している複数のクラスターを見分けるために使います。

5. クエリを実行する

Athena からクエリを実行する

クエリ構文：

"s3tablescatalog/aws-redshift"."<NAMESPACE>"."<SYS_TABLE>"

Redshift からクエリを実行する（自動マウントされたカタログ）

自動マウントされたカタログのセットアップが完了したら（${SKILL_DIR}/references/permissions-setup.md を参照）、クロスデータベース表記を使用してクエリします。

"aws-redshift@s3tablescatalog"."<NAMESPACE>".<SYS_TABLE>

Redshift からのクエリ（外部スキーマ）

または、S3 Tables カタログを参照する外部スキーマを作成します。

CREATE EXTERNAL SCHEMA <schema_name>
FROM DATA CATALOG
DATABASE '<NAMESPACE>'
CATALOG_ID '<ACCOUNT>:s3tablescatalog/aws-redshift'
IAM_ROLE 'arn:aws:iam::<ACCOUNT>:role/query_s3_tables'
REGION '<REGION>';

SELECT * FROM <schema_name>.<SYS_TABLE> LIMIT 10;

制約

• SQL クエリを作成する前に、必ず describe-logging-status または get-namespace を実行して名前空間を取得してください。手動で構成しないでください。
• Athena クエリの場合は、実行前に必ずワークグループと出力先を確認してください。
• 時間列の単位はマイクロ秒です。 秒に換算するには 1000000.0 で割ってください。
• テーブルは読み取り専用です。INSERT／UPDATE／DELETE は使用できません。
• ユーザーが指定していない場合は、必ず LIMIT を追加してください。可能な場合は start_time／record_time でフィルタリングしてください。

例

実行時間が最長のクエリ、エラー分析、接続監査、キュー待機時間の傾向、テーブル間の結合など、よくある依頼に対応する SQL の例は ${SKILL_DIR}/references/example-queries.md にあります。これらすべてに適用されるルールは次の 2 つです。

• 時間列の単位はマイクロ秒です。 秒に換算するには 1,000,000 で割ってください。elapsed_time をそのまま報告すると、所要時間を 10^6 倍に過大評価します。
• タイムスタンプ条件に加えて、Iceberg のパーティション列（year／month／day、またはテーブル独自のパーティション列）でフィルタリングしてください。そうしないと、エンジンは全履歴をスキャンします。

使い分け：Athena と Redshift と SYS_ への直接アクセス

シナリオ	使用するもの
クラスターに負荷をかけずに行う、履歴データまたは大量ログの分析	S3 Tables 上の Athena または Redshift
Redshift クラスターにすでに接続しており、S3 Tables のログをクエリしたい場合	Redshift のクロスデータベースクエリまたは外部スキーマ
システムテーブルのログを他のレイクデータと結合する場合	Athena または Redshift Spectrum
クラスターのリアルタイムの現在状態	クラスター上の SYS_ ビューへの直接アクセス
Redshift クラスターにアクセスせず、手軽にアドホッククエリを実行する場合	Athena

主な動作

• バックフィルなし — 有効化後に記録されたイベントのみが S3 Tables に配信されます。
• API から名前空間を取得 — 必ず describe-logging-status（S3Tables.S3TableNamespace）または get-namespace（s3TablePublishStatus.s3TableNamespace）から名前空間を取得してください。手動で構成しないでください。
• マイクロ秒単位の時間 — すべての所要時間列の単位はマイクロ秒です。秒に換算するには 1000000.0 で割ってください。
• 読み取り専用 — 公開されたテーブルには書き込めません。
• Provisioned と Serverless の両方に対応 — テーブルバケットは同じ（aws-redshift）ですが、有効化 API は異なります。
• Iceberg 互換エンジンで利用可能 — Athena、Redshift、または Iceberg を読み取れる任意のエンジンからクエリできます。

トラブルシューティング

エラー	原因	修正方法
aws-redshift バケットが見つからない	S3 Tables 統合が有効になっていない、またはログ記録が開始されていない	enable-logging（Provisioned）または update-namespace（Serverless）を --log-destination-type s3table とともに実行します
Athena で CATALOG_NOT_FOUND が発生する	S3 Tables が Glue に登録されていない	統合を有効にします：S3 コンソール > テーブルバケット > 統合を有効にする
有効化後も Athena テーブルが空	取り込みがまだ進行中	LastIngestionTimes（Provisioned）／lastIngestionTimes（Serverless）を確認し、待ってから再クエリします
名前空間に SYS_* テーブルがない	有効化時にシステムテーブルが含まれていなかった	そのテーブルを含めて有効化を再実行するか、all を使用します — --log-exports（Provisioned）、--s3-table-names（Serverless）
名前空間が正しくない／空	API から読み取らず、名前空間を組み立てている	describe/get のレスポンスから名前空間を使用します — S3Tables.S3TableNamespace（Provisioned）または s3TablePublishStatus.s3TableNamespace（Serverless）
パブリッシュが有効なのに、ステータスのレスポンスに S3Tables／s3TablePublishStatus フィールドがまったくない	AWS CLI／SDK が古い。このフィールドはエラーを発生させず黙って省略されるため、機能が無効になっている場合と同じように見える	CLI／SDK をアップグレードしてから再実行します。不在を根拠に対処する前に、パブリッシュが実際に無効か確認してください — 名前空間の aws-redshift テーブルバケット、または LogDestinationType に s3table が含まれているかを確認します
Serverless で Unknown options: --log-exports, --log-export-action が発生する	Provisioned 用のフラグ名を update-namespace に使用している	--s3-table-names と --s3-table-action を使用します — 「有効化」セクションのフラグ表を参照してください
テーブルのクエリで AccessDenied が発生する	s3tables:GetTable または GetTableData が不足している	references/security.md を参照してください
sys_connection_log の結果が空	クエリを実行する ID に必要な可視性がない	スーパーユーザーレベルのアクセス権を持つ ID を使用します
pg_database にカタログが表示されない	LF リソースが登録されていない、または SLR が ReadOnlyAdmins ではない	references/permissions-setup.md の Lake Formation の手順を完了し、5 分待つか再起動します
Glue から「Unable to assume role」が発生する	信頼ポリシーに sts:SetContext／sts:SetSourceIdentity がない、または AWSLakeFormationDataAdmin が不足している	信頼ポリシーを修正し、AWSLakeFormationDataAdmin をアタッチします
VerificationStatus: NOT_VERIFIED	Lake Formation 登録後は正常です	クエリが動作していれば対処は不要です
Redshift で「does not exist」と表示され、クエリが失敗する	カタログがまだ自動マウントされていない（ポーリングの遅延）	最大 300s 待つか、クラスターを再起動します

セキュリティに関する考慮事項

完全なポリシー、キーポリシー、検出の設定については ${SKILL_DIR}/references/security.md を参照してください。アクセスを許可する前に必ず読んでください。必須事項は次のとおりです。

• IAM の範囲はワイルドカードではなく、S3 Tables カタログに限定します。 Glue のデータベース／テーブル ARN は s3tablescatalog/aws-redshift の下にネストされます — 単独の database/* 形式では、アカウント全体のメタデータ読み取りが許可されます。lakeformation:GetDataAccess は "Resource": "*" を指定する必要がある唯一のアクションです。aws:ResourceAccount の StringEquals 条件で制限してください。
• KMS キーポリシーには、1 つではなく 2 つのプリンシパルが必要です： systemtables.redshift.amazonaws.com（パブリッシャー）と maintenance.s3tables.amazonaws.com（コンパクション）。パブリッシャーのみを許可すると書き込みは成功しますが、コンパクションは警告なしに失敗します。
• query_text にはスキーマだけでなく、認証情報が含まれることがあります。 補間された SQL や CREATE USER ... PASSWORD はそのまま sys_query_history に記録されます。このテーブルへの広範なアクセスは、シークレットの露出に関わる判断として扱い、Lake Formation で列へのアクセスを制限してください。
• パブリッシュ自体が監査可能であり、アラートを設定する価値があります。 s3tables.amazonaws.com の AccessDenied の急増と sys_connection_log の認証失敗数は、アラート対象とすべき 2 つのシグナルです。アラートトピックはカスタマーマネージドキーで暗号化してください。

参照ファイル

${SKILL_DIR} は、この SKILL.md を含むディレクトリの絶対パスです。必要に応じて読み込んでください。最初にすべてを読み込まないでください。

ファイル	内容	読み込むタイミング
${SKILL_DIR}/references/permissions-setup.md	Athena の前提条件とワークグループの暗号化、Redshift の自動マウントの全手順 — IAM ロールの信頼ポリシーとインラインポリシー、Lake Formation の register-resource、put-data-lake-settings、SLR の ReadOnlyAdmins 手順、自動マウントの 300s ポーリング	IAM または Lake Formation のセットアップを実行する前
${SKILL_DIR}/references/example-queries.md	実行時間が最長のクエリ、エラー分析、接続の監査、キュー時間の傾向、sys_* テーブルをまたぐ結合の SQL の例	公開済みのテーブルに対するクエリを作成するとき
${SKILL_DIR}/references/security.md	最小権限ポリシーの全容、両方のサービスプリンシパルを含む KMS キーポリシー、query_text の機密性、CloudTrail／メトリクスフィルターによる検出	アクセスを許可する前、または既存のセットアップを強化するとき

その他のリソース

• S3 Tables と AWS 分析サービスの統合
• Redshift システムテーブル
• Lake Formation のアクセス許可

セキュリティのベストプラクティス：

• Amazon Redshift のセキュリティのベストプラクティス
• S3 Tables のセキュリティ と S3 Tables のアクセス管理
• IAM のセキュリティのベストプラクティス
• Lake Formation の基盤データアクセス制御 — lakeformation:GetDataAccess で "Resource": "*" が必要な理由