AI を活用した Amazon Redshift のパフォーマンスレコメンデーション

本記事は 2026 年 7 月 1 日に公開された「AI-powered performance recommendations for Amazon Redshift」を翻訳したものです。

Amazon Redshift を運用するデータプラットフォームチームは、SYS_QUERY_HISTORY、SVV_TABLE_INFO、SVV_ALTER_TABLE_RECOMMENDATIONS などのシステムビューや、キャパシティ、クエリ実行、ストレージに関する Amazon CloudWatch メトリクスからパフォーマンステレメトリを収集しています。課題はテレメトリの解釈です。QueryRuntimeBreakdown のコミット時間の急増と数百件の小規模な INSERT 文の関連性を見抜く、あるいはディスクスピルの多発とコンピュートの不足を結びつけるには、深い専門知識と数時間に及ぶ手作業の分析が必要です。

本記事では、テレメトリを収集し、パフォーマンスシグナルを事前計算し、CloudWatch と相関分析を行い、Amazon Bedrock で優先度付きの推奨事項を生成する AI ソリューションの構築方法を解説します。ソースコードは GitHub リポジトリ sample-ai-performance-advisor-for-amazon-redshift で公開しています。

シグナルベースの設計により、汎用的なアドバイスではなく的確な推奨を生成できます。システムビューの生出力をそのまま大規模言語モデル (LLM) のプロンプトに渡すのではなく、コレクターが真偽値やしきい値に基づく検出結果を事前計算し、CloudWatch との相関を付与したうえで、構造化されたコンテキストをモデルに渡します。これにより、モデルの出力で具体的なクエリ ID、テーブル名、メトリクス値を参照できます。

ソリューション概要

2 つの AWS Lambda 関数が 24 時間間隔の Amazon EventBridge スケジュールで実行されます。

コレクター Lambda は、Amazon Redshift Serverless に対して 13 の診断 SQL クエリを実行し、ワークグループの Workload Management (WLM) 設定を読み取ります。また、キャパシティ、クエリ実行、WLM、接続数、ストレージの CloudWatch メトリクスも収集します。これらの入力からパフォーマンスシグナルを計算し、テレメトリ JSON ファイルを Amazon Simple Storage Service (Amazon S3) に書き込みます。
アナライザー Lambda は Amazon S3 からテレメトリを読み取り、CloudWatch とシグナルの相関をインラインで含む構造化プロンプトを構築します。相関情報を活用して Amazon Bedrock (Anthropic Claude Sonnet 4.6) を呼び出し、生成された推奨事項 JSON を Amazon S3 に書き戻します。
Amazon Simple Notification Service (Amazon SNS) トピックが、上位の推奨事項をメールでサブスクライバーに送信します。

図 1 – アーキテクチャ図

前提条件

デプロイ前に、以下を準備してください。

データベースとクエリ履歴がある Amazon Redshift Serverless ワークグループ。
Amazon Redshift データベース管理者ユーザー (スーパーユーザー)。コレクターはスーパーユーザーのみがクエリできるビュー (SVV_TABLE_INFO、SVV_ALTER_TABLE_RECOMMENDATIONS、SVV_MV_INFO、SYS_SERVERLESS_USAGE、SYS_AUTO_TABLE_OPTIMIZATION) を読み取ります。
管理者の認証情報を AWS Secrets Manager に保存し、シークレット ARN をコレクターに渡します。
別の方法として、既存のスーパーユーザーで ALTER USER "IAMR:redshift-performance-recommendations-role" CREATEUSER;
を一度実行し、Lambda ロールにスーパーユーザー権限を付与する方法もあります。
使用するモデルの Amazon Bedrock モデルアクセス。本ソリューションでは、マルチリージョン推論用に us.anthropic.claude-* モデルを推奨しますが、特定のモデルに依存しない設計です。
AWS Command Line Interface (AWS CLI) のインストールと設定、および GitHub リポジトリのクローン。

サポートリソースの作成

Lambda 関数を実行するには、Amazon S3 バケット、Amazon SNS トピック、AWS Secrets Manager シークレット、AWS Identity and Access Management (IAM) ロールが必要です。

Amazon S3 バケットの作成

Amazon S3 バケットに出力レポートを保存します。

Amazon S3 コンソールを開き、バケットを作成を選択します。
グローバルに一意の名前 (例: amzn-s3-demo-bucket) を入力し、デフォルト設定のままバケットを作成を選択します。

コレクターは telemetry/ プレフィックス配下にテレメトリ JSON を書き込み、アナライザーは recommendations/ プレフィックス配下に推奨事項を書き込みます。

Amazon SNS トピックとサブスクリプションの作成

レポート作成後の通知に Amazon SNS を使用します。

Amazon SNS コンソールを開き、トピック、トピックの作成の順に選択します。
スタンダードを選択し、名前に redshift-performance-recommendations と入力します。
トピックの作成を選択します。
トピック詳細ページでサブスクリプションの作成を選択します。
プロトコルとしてE メールを選択し、メールアドレスを入力してサブスクリプションの作成を選択します。
AWS Notifications からの確認メールを開き、サブスクリプションの確認を選択します。

図 2 – SNS トピックの作成

管理者の認証情報を AWS Secrets Manager に保存

ハードコードされた認証情報を避けるため、AWS Secrets Manager シークレットを作成して Amazon Redshift に接続します。

AWS Secrets Manager コンソールを開き、新しいシークレットを保存するを選択します。
その他のシークレットのタイプを選択し、プレーンテキストタブを選択して以下を貼り付けます。<ADMIN_PASSWORD> はワークグループの管理者パスワードに置き換えてください。
```
{"username":"admin","password":"<ADMIN_PASSWORD>"}
```
次へを選択し、シークレット名に redshift-performance-admin と入力して、次へ、次へ、保存を選択します。
シークレット詳細ページからシークレットの Amazon Resource Name (ARN) をコピーします。後のステップでコレクターに渡します。

図 3 – シークレットの作成

IAM ロールの作成とポリシーのアタッチ

リポジトリには、iam/trust-policy.json に信頼ポリシー (lambda.amazonaws.com がロールを引き受けることを許可) と、iam/lambda-role-policy.json に最小権限のアクセス許可ポリシーが含まれています。アクセス許可ポリシーの <ACCOUNT_ID>、<REGION>、<YOUR_BUCKET>、SNS トピック ARN のプレースホルダーを自身の値に置き換えてから、AWS マネジメントコンソールまたは以下の AWS CLI コマンドでロールを作成します。

aws iam create-role --role-name redshift-performance-recommendations-role \
    --assume-role-policy-document file://iam/trust-policy.json

aws iam put-role-policy --role-name redshift-performance-recommendations-role \
    --policy-name redshift-performance-policy \
    --policy-document file://iam/lambda-role-policy.json

アクセス許可ポリシーは、両方の Lambda 関数に必要な Amazon Redshift Data API、Amazon S3、Amazon SNS、Amazon Bedrock、AWS Lambda 呼び出し、AWS Secrets Manager、Amazon CloudWatch Logs の権限を付与します。

Lambda 関数のデプロイ

コレクターのソースは lambda/collector.py にあり、実行時に sql/ 配下の SQL ファイルを読み込みます。デプロイパッケージには両方を含める必要があります。

コレクターのパッケージング

ターミナルまたはシェルを開き、コレクターのコードと SQL をフォルダにコピーしてアーカイブを作成します。

mkdir -p build/collector/sql
cp lambda/collector.py build/collector/
cp sql/*.sql build/collector/sql/
(cd build/collector && zip -qr ../collector.zip .)

コレクター関数の作成

AWS マネジメントコンソールで AWS Lambda に移動します。

関数の作成を選択します。

図 4 – AWS Lambda 関数の作成
一から作成を選択し、名前に redshift-performance-collector と入力して、Python 3.14 を選択します。
カスタム設定を展開し、カスタム実行ロールを切り替えて、既存のロールを選択し、redshift-performance-recommendations-role を選択して保存を選択します。
関数ページでアップロード元、.zip ファイルを選択し、build/collector.zip をアップロードします。
ランタイム設定で編集を選択し、ハンドラを collector.lambda_handler に設定します。

図 5 – AWS Lambda ハンドラの設定
設定、編集を選択し、タイムアウトを 5 分、メモリを 256 MB に設定します。

図 6 – AWS Lambda のタイムアウトとメモリの設定
設定で環境変数を選択し、以下のキーを追加します。
- WORKGROUP: Amazon Redshift Serverless ワークグループ名。
- NAMESPACE_NAME: ワークグループが属する名前空間。
- DATABASE: dev (または対象のデータベース)。
- BUCKET: 先ほど作成した Amazon S3 バケット名。
- SECRET_ARN: 先ほどコピーした AWS Secrets Manager シークレット ARN。
- ANALYZER_FN: redshift-performance-analyzer。

アナライザーのパッケージングと作成

lambda/analyzer.py を使用して、アナライザーも同様の手順で作成します。タイムアウトは 15 分です。

(cd lambda && zip -q ../build/analyzer.zip analyzer.py)

Lambda コンソールで redshift-performance-analyzer を作成し、ハンドラを analyzer.lambda_handler、タイムアウトを 15 分、メモリを 256 MB、同じ実行ロールを設定して、以下の環境変数を追加します。

BUCKET: 同じ Amazon S3 バケット。
SNS_TOPIC: SNS トピック ARN。
MODEL_ID: us.anthropic.claude-sonnet-4-6。

アナライザーは read_timeout=600 と max_tokens=16384 を指定して Amazon Bedrock クライアントを作成し、大規模なプロンプトと長い応答に対応します。フルテレメトリペイロードでの Anthropic Claude 推論は通常 2〜4 分かかります。

シグナルとプロンプトの仕組み

シグナル計算やプロンプト構築のカスタムコードを書く必要はありません。どちらもリポジトリに含まれています。

lambda/collector.py の compute_signals() 関数は、テレメトリをスキャンして真偽値としきい値に基づくアンチパターンを検出します。テーブルレベルでは、行の偏り (skew)、ゴースト行（論理削除行）、統計情報の陳腐化、未ソートデータ、最適でないソートキーや分散キー、過大な VARCHAR カラムを検出します。ランタイムとワークロードの問題として、ディスクスピル（中間データのディスク書き出し）、小規模 INSERT のバースト、DDL (データ定義言語) の多発、最適化されていない COPY ファイルサイズも検出します。さらに、パーティションプルーニングに失敗した Amazon Redshift Spectrum クエリや、フルリフレッシュを行うデータ共有マテリアライズドビューも検出します。また、ディスクスピルブロック数やクエリ実行時間の制限など、Query Monitoring Rules (QMR) が欠如している WLM 設定も検出します。シグナルとしきい値の全セットは関数内にインラインで定義されています。しきい値の調整やカスタムシグナルの追加は、この関数を編集して再デプロイするだけで対応できます。

lambda/analyzer.py の build_prompt() 関数は、Amazon Bedrock プロンプトを 4 つのセクションで構築します。第 1 セクションはトリガーされたシグナルの一覧です。第 2 セクションは CloudWatch メトリクスを追加し、各シグナルとそのサポートメトリクスを対にする >> CORRELATION 行で注釈をつけます。第 3 セクションはフィルタリングされたサポートデータで、シグナルをトリガーしたテーブル行とクエリ行に限定されています。第 4 セクションは、すべての推奨事項で特定のテーブル名、クエリ ID、メトリクス値を参照するパイプ区切りテキストを返すよう明示的に指示します。この構造により、モデルは汎用的なベストプラクティスではなく具体的な出力を生成します。

日次実行のスケジュール設定

Amazon EventBridge コンソールでコレクターを 24 時間ごとにトリガーします。

EventBridge コンソールを開き、Scheduler のスケジュール、スケジュールを作成を選択します。
スケジュール名に redshift-performance-daily と入力し、定期スケジュールとレートベースのスケジュールを切り替えます。
レート式に 24 と入力し、時間を選択します。
フレキシブルタイムウィンドウでオフを選択し、次へを選択します。

図 7 – Amazon EventBridge スケジュールの作成
ターゲットを選択ページで、AWS Lambda を選択し、redshift-performance-collector 関数を選択して次へを選択します。

図 8 – Amazon EventBridge スケジュールターゲットの選択
設定のデフォルトを受け入れて次へを選択します。EventBridge は Lambda 関数にリソースベースのアクセス許可を自動的に追加し、ルールが関数を呼び出せるようにします。
スケジュールを作成を選択します。

実行して出力を確認する

コレクターを手動で呼び出し、パイプライン全体が動作することを確認します。

Lambda コンソールで redshift-performance-collector 関数を開き、テストを選択します。テストイベント名に manual、本文に {} と入力してテストを選択します。

図 9 – エンドツーエンドワークフローのテスト
関数は 1 分以内に完了します。モニタリングタブの CloudWatch ライブログリンクで呼び出しログを確認します。
Amazon S3 コンソールでバケットを開きます。telemetry/ プレフィックスに現在のタイムスタンプの JSON ファイルがあることを確認します。
2〜4 分以内にアナライザーが SNS トピックにメッセージを発行します。登録したメールアドレスで上位 10 件の推奨事項サマリーを確認します。Amazon S3 の recommendations/ プレフィックスに完全な JSON があることも確認します。

各推奨事項には、優先度 (critical、high、medium、low) とカテゴリ (query_optimization、table_design、capacity、wlm、maintenance、ingestion) があります。また、推奨をトリガーしたシグナルと CloudWatch メトリクスを示す signal_source、平易な言葉での説明、具体的な SQL または設定アクション、想定される影響の見積もりも含まれます。

図 10 – アナライザーのメール出力サンプル

ベストプラクティス

しきい値をワークロードに合わせて調整する。 compute_signals() のデフォルトしきい値は Amazon Redshift 運用レビュープレイブックに基づいています。高速取り込みや小規模クラスター環境では、小規模 INSERT のしきい値を下げる、統計情報の陳腐化ウィンドウを広げる、テーブル固有のカスタムシグナルを追加するなどの調整を検討してください。
シグナルとメトリクスの相関を最新に保つ。 シグナルを追加する場合は、build_correlations() に対応する相関も追加してください。インラインの >> CORRELATION 行が、インフラストラクチャメトリクスとアプリケーションレベルの症状を結びつけます。
推奨事項は実行前にレビューする。 アナライザーは優先度付きの提案を生成しますが、VACUUM、ANALYZE、ALTER TABLE はテーブルの状態を変更します。各推奨事項の説明とアクションを確認し、スキーマに対して SQL を検証してから、メンテナンスウィンドウ中に実行してください。

クリーンアップ

不要な課金を避けるため、本ソリューション用に作成したリソースを削除してください。

2 つの AWS Lambda 関数: redshift-performance-collector と redshift-performance-analyzer。
Amazon EventBridge ルール: redshift-performance-daily。
Amazon SNS トピックとメールサブスクリプション: redshift-performance-recommendations。
Amazon S3 バケット (telemetry/ と recommendations/ のオブジェクトを含む)。
AWS Secrets Manager シークレット: redshift-performance-admin。
IAM ロールとインラインポリシー: redshift-performance-recommendations-role。

まとめ

Amazon Redshift Serverless の日次パフォーマンスレビューを AWS Lambda で実行し、結果を Amazon S3 に保存し、優先度付きの推奨事項をメールで配信する仕組みが完成しました。シグナルベースのプロンプトパターンにより、Amazon Bedrock のコストを抑えつつ、ワークロード固有の推奨を生成できます。

詳細については、以下のリソースを参照してください。

ソースコード: GitHub の sample-ai-performance-advisor-for-amazon-redshift。
Amazon Redshift のシステムテーブルとビュー。
Amazon Bedrock ユーザーガイド。
Amazon CloudWatch での Amazon Redshift Serverless のモニタリング。

著者について

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

Amazon Web Services ブログ