Amazon S3 Tables による Amazon Redshift システムテーブルの長期保持

本記事は 2026 年 8 月 20 日に公開された「Long-term system tables retention in Amazon Redshift with Amazon S3 Tables」を翻訳したものです。

Amazon Redshift のシステムテーブルは、実行されたすべてのクエリ、確立されたすべての接続といった運用シグナルを継続的に記録します。収集したデータは、データウェアハウス全体の可観測性、パフォーマンス分析、コンプライアンス監査を支えます。しかしこれまで、システムテーブルがこの重要なデータを保持できる期間はわずか 7 日間で、独自の回避策なしに長期的なコンプライアンス対応や監査を行うのは困難でした。

Amazon Simple Storage Service (Amazon S3) の機能である Amazon S3 Tables と Amazon Redshift システムテーブルの統合により、システムテーブルのログデータが自動的に Amazon S3 Tables に配信され、Apache Iceberg 形式で保存されます。Amazon Redshift システムテーブルの保持期間を現在の 7 日間の上限を超えて設定でき、独自の ETL パイプラインやクラスターリソースを消費することなく、コンプライアンス対応、監査、ウェアハウス横断の可観測性を長期にわたって実現できます。データはオープンかつ堅牢で、Amazon Redshift、Amazon Athena、AWS Glue、Amazon EMR、その他の Apache Iceberg 対応エンジンからクエリできます。

本記事では、Amazon Redshift システムテーブルの統合がどのようにログデータを Amazon S3 Tables に配信するのかを解説します。本機能は、RA3 および RG のプロビジョンドクラスターと Amazon Redshift Serverless ワークグループでサポートされています。

課題

Amazon Redshift を運用していると、システムテーブルの保持期間が 7 日間に制限されていることに起因する運用上の課題によく直面します。

クエリの傾向が把握しにくい: 同じクエリの 30 日前と現在のパフォーマンスを比較したいことがあります。パフォーマンスが徐々に変化する場合、長期的なベースラインがあれば、場当たり的なトラブルシューティングではなく、データに基づいた根本原因分析が可能になります。
変更前後の比較: 新しいワークロードの追加、インスタンスタイプの変更、Workload Management (WLM) キューの調整を行う際には、その影響を正確に測定したくなります。保持期間を延長すれば、必要なベースラインデータを残しておけます。
季節性を考慮したキャパシティプランニング: 月末のスパイク、四半期末の急増、年間のピークを把握して計画するには、数か月分の履歴データが必要です。保持期間を延長すると、数か月から数年にわたる季節的なパターンが見えてきます。
独自 ETL パイプラインの負荷: 保持期間の制限を回避するため、システムテーブルのデータを 1 時間ごとまたは 1 日ごとに Amazon Redshift マネージドストレージ内の永続テーブルにコピーする独自パイプラインを構築するチームもあります。こうしたパイプラインはクラスターリソースを消費し、本番ワークロードと競合し、継続的なエンジニアリング保守を必要とします。Amazon Redshift がシステムテーブルのスキーマやデータ共有の設定を更新すると、パイプラインには手作業での対応が必要になり、記録に欠落が生じます。
コンプライアンス要件: 規制対象の業界では、数か月から数年に及ぶ監査証跡の保持が求められます。7 日間の上限のもとでこの要件を満たすには、独自のインフラが必要でした。Amazon Redshift システムテーブルと Amazon S3 Tables の統合により、この課題が解決されます。

仕組み

Amazon Redshift システムテーブルと Amazon S3 Tables の統合は、Amazon Redshift システムテーブルのデータを Apache Iceberg 形式で自動的に Amazon S3 テーブルに書き込むフルマネージド機能です。パーティショニング、圧縮、保持期間の管理は AWS が自動的に処理します。ログの書き込み処理は独立したバックグラウンドプロセスで実行され、本番ワークロードとのリソース競合を抑えます。パイプラインの管理は AWS が代行します。

本機能はリリース時点で 25 を超えるシステムビューをサポートしています。サポート対象のシステムビューについてはドキュメントを参照してください。

セットアップ

Amazon Redshift コンソールから Amazon S3 Tables とのシステムテーブル統合を有効にするには、次の手順に従います。

Amazon Redshift コンソールを開き、[System table integrations] ページに移動します。プロビジョンドクラスターまたは Serverless ワークグループの詳細ページからもアクセスできます。
Create System table integration を選択します。設定ウィザードが起動します。
本機能を有効にする Amazon Redshift プロビジョンドクラスターまたは Amazon Redshift Serverless ワークグループを選択します。

図 1: システムテーブル統合ウィザードでの Amazon Redshift データウェアハウスの選択
Available system tables リストから公開するシステムビューを選択します。個々の SYS_* ビューを選ぶか、Select all supported system tables を選択して、現在および将来サポートされるすべてのビューを公開します。すべてを選択した場合、将来追加される新しいビューは設定を変更しなくても自動的に含まれます。

図 2: [Available system tables] リストから公開するシステムビューを選択
デプロイモデルを選択します。Amazon S3 Tables でのデータの整理方法を選びます。

データウェアハウスごと・システムテーブルごとに個別の S3 テーブル: 各ウェアハウスのデータを専用のテーブル群に保持します。
データウェアハウス横断でシステムテーブルごとに共有の S3 テーブル: アカウント内の複数のウェアハウスのデータを共有のテーブル群に集約します。

必要に応じて、AWS Key Management Service (AWS KMS) のカスタマーマネージドキーで暗号化を設定します。デフォルトでは、データは Amazon S3 マネージドキー (SSE-S3) で暗号化されます。
変更を保存します。Amazon Redshift は選択したビューの Amazon S3 Tables への公開を開始し、一定の間隔で新しいレコードを追加し続けます。

統合が有効になっているかを確認するには、次のようにします。

クラスターまたはワークグループの詳細ページに移動します。
統合のステータスと、各ビューの最終取り込み時刻を確認します。
公開されたデータは Amazon S3 Tables コンソールからも確認できます。

有効化すると、Amazon Redshift は本番ワークロードとは別の独立したバックグラウンドプロセスを通じて、定期的にログデータを Amazon S3 テーブルに書き込みます。保持されたログのクエリを開始するには、AWS Glue Catalog を介して Amazon Redshift 環境と Amazon S3 Tables のデータを接続する初回セットアップが必要です。次の手順を実行します。

AWS Glue Data Catalog と Amazon S3 Tables へのアクセスに必要な権限を持つ AWS Identity and Access Management (IAM) ロールを作成し、Amazon Redshift クラスターまたは Amazon Redshift サーバーレスネームスペースに関連付けます。
AWS Glue Data Catalog で、ログが格納されている Amazon S3 Tables データベースを指すリソースリンクを作成します。

Amazon Redshift で、リソースリンクを参照する外部スキーマを作成します。

CREATE EXTERNAL SCHEMA <schema_name>
FROM DATA CATALOG
DATABASE '<resource_link_database>'
IAM_ROLE '<iam_role_arn>';

設定が完了すると、使い慣れた 2 部構成の表記法で過去のシステムテーブルデータをクエリできます。
```
SELECT * FROM <schema_name>.<table_name>;
```

Amazon S3 Tables へのアクセスは読み取り専用のため、監査証跡の整合性は本質的に保たれます。

IAM ポリシーの例を含む詳細なセットアップ手順については、S3 Tables と Data Catalog の統合の有効化を参照してください。

データは Apache Iceberg 形式で保存される

システムテーブルのデータは、オープンテーブル形式である Apache Iceberg で保存されるため、互換性のあるクエリエンジンを自由に選べます。可観測性や監査のデータを、すでに使っているツールでそのまま扱えます。

運用データは次のサービスで分析できます。

Amazon Redshift: S3 テーブルバケットを AWS Glue Data Catalog と統合したうえで、Amazon Redshift でリソースリンクを指す外部スキーマを作成し、保持されたテーブルをクエリします。
Amazon Athena: インフラのプロビジョニングなしで、過去のログに対してサーバーレスの SQL クエリを実行します。
AWS Glue: 運用データを基盤に、自動化されたデータ処理・変換ジョブを構築します。
Amazon EMR: 複雑なウェアハウス横断分析のために、Spark ベースの分析を大規模に実行します。

データは Amazon S3 Tables にオープンな Apache Iceberg 形式で保存されるため、Amazon Redshift、Amazon Athena、自然言語クエリ用の AI エージェントスキル、Amazon SageMaker Unified Studio、Iceberg 対応エンジン、ビジネスインテリジェンス (BI) ツール、可観測性システムなど、さまざまな手段でクエリできます。

コスト効率

Amazon Redshift から Amazon S3 Tables へのログ配信に追加費用はかかりません。料金が発生するのは、Amazon S3 Tables のストレージ、メンテナンス、および選択したエンジンでのデータのクエリに対してのみです。

ソリューションの概要

以下のシナリオでは、Amazon Redshift システムテーブルと Amazon S3 Tables の統合が、Amazon Redshift 環境全体でよくある運用・コンプライアンス・可観測性の課題をどのように解決するかを紹介します。また、本機能のために専用のスキル querying-aws-redshift を用意し、AWS MCP Server に組み込みました。これにより、Amazon S3 Tables から Amazon Redshift システムテーブルをクエリできます。

シナリオ 1: クエリの傾向を長期的に追跡する

数か月から数年分の SYS_QUERY_HISTORY データを保持しておけば、個々のクエリのパフォーマンスを長期間にわたって追跡できます。あるクエリの実行時間、キュー時間、リソース消費量を、日単位・週単位・月単位で比較できます。

パフォーマンスが劣化し始めた時期を正確に特定し、新しいスキーマ、データ量の急増、同時実行ワークロードの追加といった変更と関連付けられます。保持期間を延長することで、トラブルシューティングは事後対応から、先を見据えたデータドリブンな根本原因分析へと変わります。

シナリオ 2: 変更前後のワークロードへの影響を評価する

新しい ETL パイプライン、インスタンスタイプの変更、Workload Management (WLM) キューの調整、アドホッククエリを実行するアナリストチームの追加など、ワークロードの変更はいずれもシステムに影響します。問われるのはいつも、その変更がパフォーマンスにどう影響したかです。

Amazon Redshift システムテーブルと Amazon S3 Tables の統合により、自信を持ってデータに基づいた意思決定ができます。SYS_QUERY_HISTORY をクエリして、変更前の数週間と変更後の数週間で、実行時間、キューでの待機時間、同時実行スケーリングのイベントを比較します。2 週間前に新しいレポートワークロードを導入し、既存のクエリへの影響を把握したい場合、それを確認するためのデータはすでに揃っており、独自パイプラインは一切不要です。

シナリオ 3: 可観測性ダッシュボードを構築する

システムテーブルのデータは Apache Iceberg で保存され、AWS Glue でカタログ化されます。つまり、Apache Iceberg を読み取れる可観測性ツールやビジネスインテリジェンス (BI) ツールから直接接続できます。経営層向けのレポートとして、ワークロードの分散傾向を Amazon Quick Sight で可視化できます。より深い分析や、運用データからの AI 主導のインサイト生成には、Amazon SageMaker Unified Studio を利用します。AWS のサービスにとどまらず、使い慣れたサードパーティの可観測性システムや BI ツールを接続して、クエリ量の追跡、接続パターンの監視、異常検知のアラート設定、あるいは Amazon Redshift の運用データとアプリケーションレベルのログの相関分析も行えます。

可観測性や監査のデータを、すでに使っているツールでそのまま活用できます。堅牢で構造化された運用データに、好みのツールから直接アクセスできます。

シナリオ 4: 季節性を踏まえてキャパシティを計画する

ワークロードの需要は 1 年を通じて変動します。月次決算、四半期末のレポート、年間の計画サイクル、プロモーションイベントはいずれも予測可能な使用量のスパイクを生みますが、それはパターンを見て取れるだけの履歴データがあってこそです。

保持期間を延長すれば、複数のビジネスサイクルにまたがる使用状況の傾向を分析できます。キャパシティの上限に常に近づくのはいつかを特定し、需要が四半期ごとにどう変化するかを測定し、プロビジョニング済みのリソースが実際の使用量と見合っているかを検証できます。

シナリオ 5: コンプライアンスの監査証跡を維持する

規制対象の業界にとって、保持期間の延長は、整合性を標準で備えたフルマネージドの監査証跡をもたらします。

SYS_CONNECTION_LOG はすべての認証試行を記録します。SYS_USERLOG はユーザーアカウントの変更を記録します。SYS_QUERY_HISTORY はウェアハウスに対して実行されたすべてのクエリを記録します。

保持期間は、90 日、1 年、あるいは数年など、組織のデータ保持ポリシーに合わせて設定します。読み取り専用のアクセスポリシーにより、書き込み後のレコードが管理者を含む誰かによって改変されるのを防げます。

シナリオ 6: ウェアハウス群全体で運用の可観測性を一元化する

複数の Amazon Redshift ウェアハウスを運用している場合、運用データを統合的に把握できるメリットがあります。本機能は、組織構造に合わせて 2 つのデプロイパターンをサポートします。

ウェアハウスごとの個別テーブル: 各ウェアハウスが専用の Amazon S3 テーブルに書き込むため、コンプライアンス上の配慮が必要な環境向けに完全なデータ分離を実現します。複数のウェアハウスをまとめてクエリするには、UNION 操作が必要です。
共有テーブル: 同じアカウント・同じ AWS リージョン内のウェアハウスが、共有された 1 組の Amazon S3 テーブルに書き込み、データは warehouse_name 列で区別されます。ウェアハウスで絞り込めば、クラスター横断の分析をすぐに行えます。

ベストプラクティス

プライバシー上の理由でログの分離が必要なウェアハウスを特定し、それらにはウェアハウスごとの個別テーブルオプションを選択します。残りのウェアハウスには、管理を簡素化するために共有テーブル (集約)オプションを使用します。
保持期間はコンプライアンス要件に合わせます。ストレージコストを抑えるため、コンプライアンス要件を満たす最小限の保持期間を設定します。
保持されたシステムテーブルをクエリする際は、warehouse_account_id、warehouse_region_name、warehouse_namespace_arn、warehouse_name、s3_tables_ingestion_time などのメタデータ列で絞り込み、スキャン範囲を減らしてパフォーマンスを高めます。複数のウェアハウスにまたがる大量の履歴データをクエリする場合は、特に重要です。
監査証跡の整合性は、標準で備わる読み取り専用アクセスに任せます。保持期間や暗号化の設定は、Amazon S3 Tables の設定 API で管理します。
暗号化の方針は早い段階で計画します。設定後の変更には統合の再作成が必要になるため、暗号化キーはセットアップ時に慎重に選びます。将来的にウェアハウスを集約する見込みがあるなら、最初から共有の AWS KMS キーを選んでおきます。

まとめ

Amazon Redshift システムテーブルと Amazon S3 Tables の統合は、独自の ETL パイプラインをフルマネージドのソリューションに置き換え、Amazon Redshift の運用データを保持します。Apache Iceberg ベースのストレージへの自動保存、オープン形式でのクエリ、標準で備わる監査整合性により、数か月から数年分の可観測性データをフルマネージドで得られます。AWS Management Console、AWS Command Line Interface (AWS CLI)、AWS SDK から有効にできます。

詳しくは、Amazon Redshift システムテーブルのドキュメントを参照してください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

Amazon Web Services ブログ