Redshift運用で性能課題の特定が難しい理由
Amazon Redshift を本番で運用していると、クエリが遅くなったりコストが膨らんだりといった症状は感じ取れても、その根本原因を突き止める作業は容易ではありません。ディスクスピルやコミット時間のスパイクといった現象は CloudWatch メトリクスに現れますが、それがどのテーブルのどんな設計上の問題に由来するのかは、システムビューを個別に読み解いて初めて見えてきます。インフラ側のメトリクスとアプリケーション側の症状を人手で結び付ける作業は、経験と時間を要するものです。
Redshift には統計情報やテーブル最適化を助けるシステムビューが多数用意されていますが、それらを横断的に集約し、優先順位を付けて実行可能な打ち手に落とし込むには、運用者の知見に強く依存します。データプラットフォームチームの規模が小さい場合、この分析を日次で継続することは現実的ではありません。
本記事で読み解くのは、この分析工程を自動化する AWS Samples のリファレンス実装です。これは Amazon Redshift の正式なマネージド機能ではなく、GitHub の aws-samples/sample-ai-performance-advisor-for-amazon-redshift で公開されているサンプルコードである点をおさえておきます。テレメトリの収集からレコメンデーション生成、メール通知までを AWS のサーバーレスサービスと Amazon Bedrock で組み立てた構成であり、そのアーキテクチャとシグナル設計の考え方に学ぶべき点が多くあります。
ソリューション全体のアーキテクチャと処理の流れ
このソリューションは、テレメトリ収集を担う AWS Lambda と、分析およびレコメンデーション生成を担う AWS Lambda の二段構成を軸にしています。処理の起点となるのは Amazon EventBridge のスケジュール redshift-performance-daily で、24 時間周期で収集用の Lambda を起動します。
収集用の Lambda である redshift-performance-collector は、Amazon Redshift Serverless に対して 13 個の診断 SQL クエリを実行し、WLM 構成や CloudWatch メトリクスをあわせて取得します。集めたテレメトリは JSON として Amazon S3 の telemetry/ プレフィックスへ書き込まれます。Redshift への認証情報は AWS Secrets Manager のシークレット redshift-performance-admin から取得する設計です。
収集が完了すると、分析用の Lambda である redshift-performance-analyzer が起動します。この Lambda は S3 のテレメトリを読み込んで構造化プロンプトを組み立て、Amazon Bedrock を呼び出してレコメンデーションを生成します。生成結果は S3 の recommendations/ プレフィックスへ JSON として保存され、あわせて Amazon SNS へパブリッシュされます。SNS トピック redshift-performance-recommendations にメールをサブスクライブしておくと、レコメンデーションのサマリが運用者の手元に届く流れです。
全体では、Redshift Serverless、Lambda、EventBridge、S3、SNS、CloudWatch、Bedrock、Secrets Manager、IAM を組み合わせています。各コンポーネントがサーバーレスで疎結合につながるため、日次の自動実行に適した構成です。
AWS Lambdaによるテレメトリ収集の中身
収集用 Lambda の中心的な役割は、Redshift の内部状態を余さず拾い上げることです。診断 SQL は SYS_QUERY_HISTORY や SVV_TABLE_INFO、SVV_ALTER_TABLE_RECOMMENDATIONS、SVV_MV_INFO、SYS_SERVERLESS_USAGE、SYS_AUTO_TABLE_OPTIMIZATION といったシステムビューを対象とし、クエリ履歴やテーブル情報、マテリアライズドビューの状態、サーバーレス使用状況を取得します。あわせて WLM 構成を読み取り、容量やクエリ実行、接続、ストレージに関する CloudWatch メトリクスも収集します。
収集したデータをそのまま Bedrock に渡すのではなく、収集用 Lambda 内の compute_signals() が性能上の「シグナル」をしきい値判定やブール判定で計算する点がこの実装の要になっています。生のメトリクスやテーブル統計を、行スキューや統計陳腐化といった意味のある兆候へと変換してから後段に引き渡すことで、後続のプロンプトを的確なものにしています。
収集された JSON は S3 の telemetry/ プレフィックスへ格納され、後段の分析 Lambda が参照します。テレメトリを一度 S3 に永続化することで、収集と分析の責務が分離され、再実行やデバッグもしやすくなります。以下は診断クエリが参照するシステムビューのイメージです。
SELECT * FROM SYS_QUERY_HISTORY;
SELECT * FROM SVV_TABLE_INFO;
SELECT * FROM SVV_ALTER_TABLE_RECOMMENDATIONS;
SELECT * FROM SVV_MV_INFO;
SELECT * FROM SYS_SERVERLESS_USAGE;
SELECT * FROM SYS_AUTO_TABLE_OPTIMIZATION;収集した情報を分析用 Lambda が読み込むと、そこから Amazon Bedrock を用いたレコメンデーション生成へと処理が進みます。二つの Lambda を役割で分けることで、収集の失敗と生成の失敗を切り分けやすくしている点も、実運用を意識した設計といえます。
シグナルベースのプロンプト設計パターン
このソリューションの独自性は、シグナルベースのプロンプト設計にあります。汎用的なベストプラクティスを列挙するのではなく、実際に検出されたシグナルを起点として、具体的なテーブル名やクエリ ID、メトリクス値に紐づいた提案を引き出す狙いがあります。
収集側の compute_signals() が検出するシグナルは、大きく三系統に分かれます。テーブル系のシグナルには、行スキュー（データ分布の偏り）、ゴーストロー（削除済みだが未回収の行）、統計情報の陳腐化、未ソートデータ、最適でないソートキーや分散キー、過大な VARCHAR カラムが含まれます。ランタイム系のシグナルには、ディスクスピル、小さな INSERT のバースト、DDL 実行の多さ、最適でない COPY ファイルサイズ、Amazon Redshift Spectrum のパーティションプルーニング失敗、データ共有マテリアライズドビューのフルリフレッシュがあります。WLM 系のシグナルとしては、ディスクスピルや長時間クエリを制御する Query Monitoring Rules が欠如している状態を検出します。
これらのシグナルを Bedrock に渡す際、分析側の build_correlations() が各シグナルを対応する CloudWatch メトリクスと結び付け、>> CORRELATION という注釈としてプロンプトに埋め込みます。この相関注釈があることで、インフラ側のメトリクスとアプリケーション側の症状がひとつの文脈として提示され、モデルは症状の背後にある原因へと踏み込んだ提案を返せるようになります。
プロンプトは build_prompt() によって四つのセクションで構成されます。トリガーされたシグナル一覧、相関注釈付きの CloudWatch メトリクス、シグナルを発火させた対象テーブルやクエリのフィルタ済み支援データ、そして具体的なテーブル名やクエリ ID、メトリクス値を参照させる明示的なインストラクションです。出力形式をパイプ区切りで指示することで、後段が扱いやすい構造化データを得ています。
呼び出す Amazon Bedrock のモデルは、ID 文字列として us.anthropic.claude-sonnet-4-6 が指定されています。冒頭の us. はクロスリージョン推論用のプレフィックスです。生成されるレコメンデーションは、優先度（critical、high、medium、low）とカテゴリ（query_optimization、table_design、capacity、wlm、maintenance、ingestion）を伴う構造化された出力で、シグナルソース、説明、SQL や設定のアクション、影響の見積もりを含みます。フルテレメトリの処理はおおむね 2〜4 分で完了します。
メール通知フローと実運用での活用イメージ
通知フローは自動実行を前提として組まれています。EventBridge のスケジュール redshift-performance-daily が 24 時間周期で収集 Lambda を起動し、収集が完了すると分析 Lambda が引き継ぎます。分析 Lambda が Bedrock を呼び出してレコメンデーションを生成し S3 に保存した後、SNS トピック redshift-performance-recommendations へパブリッシュすることで、サブスクライバへメールが届きます。
メールで届くサマリには、対象のワークグループ、名前空間、データベース、分析のタイムスタンプ、そして優先度順に並んだ上位 10 件のレコメンデーションが含まれます。より詳細な内容は S3 に保存されたフル JSON を参照する構成です。日次で手元にサマリが届くため、運用者は毎朝その日の優先課題を把握できます。
想定されるユースケース
実運用での活用イメージとしては、いくつかの相関パターンが挙げられます。たとえば、数百件に及ぶ小さな INSERT のバーストとコミット時間のスパイクを結び付けて、書き込みパターンの見直しを促すケースです。あるいは、高頻度のディスクスピルとコンピュート容量の不足を関連付けて、容量設計の再検討を示唆するケースもあります。さらに、テーブル統計の陳腐化や最適でないスキーマ設計がクエリ性能に及ぼす影響を検出し、統計更新や設計変更を提案するといった使い方も想定されています。
こうしたレコメンデーションは、具体的なテーブル名やクエリ ID に紐づいた実行可能な形で提示されるため、Amazon Redshift を運用するデータプラットフォームチームにとって、インフラメトリクスと症状の相関付けという難所を肩代わりしてくれる存在になります。生成された提案をそのまま鵜呑みにするのではなく、内容を吟味したうえで自環境に適用していく運用が現実的です。
まとめ
ここまで、Amazon Redshift Serverless のテレメトリを AWS Lambda で収集し、シグナルとして計算したうえで Amazon Bedrock に構造化プロンプトとして渡し、優先度付きのパフォーマンス改善レコメンデーションを自動生成する仕組みを読み解きました。二段の Lambda による疎結合な収集と分析、シグナルと CloudWatch メトリクスを >> CORRELATION で結ぶプロンプト設計、そして EventBridge と SNS による日次の通知フローが、このソリューションの骨格です。
あらためて確認しておきたいのは、これが Redshift の正式なマネージド機能ではなく AWS Samples のリファレンス実装であるという点です。料金や対応リージョン、提供区分については本記事では断定を避けますので、実際に試す際は GitHub リポジトリと公式ドキュメントで最新の情報を確認してください。汎用的なアドバイスではなく、自環境のメトリクスとテーブルに根ざした提案を引き出すというアプローチは、Redshift に限らず性能運用を自動化するうえで参考になる考え方です。
