あるデータエンジニアリングチームは、Amazon Redshift クラスターで複数の ETL クエリが突然遅くなったという報告を受けました。 調査のために、以下の 3 点を確認する必要があります。 1. 過去 24 時間で実行時間が最も長かったクエリの特定 2. テーブルスキャンの I/O 負荷が高いクエリの特定 3. WLM（Workload Management）キューでの待機時間が発生しているかどうかの確認 これらすべての情報を収集するために最も適切な方法はどれですか？
Amazon Redshift のシステムテーブル（STL/SVL）はクエリレベルの詳細な実行情報を保持します。STL_QUERY にはクエリごとの実行時間・ユーザー・開始終了時刻が記録され、SVL_QUERY_SUMMARY にはステップ別のスキャン行数や I/O 情報が含まれます。STL_WLM_QUERY を参照すれば WLM キューへの投入時刻と実行開始時刻から待機時間を算出でき、3 点すべてを1か所で調査できます。 選択肢AのCloudTrail は管理プレーンの API コールを記録するものであり、SQL クエリの実行詳細は記録されません。 選択肢BのCloudWatch メトリクスはクラスター全体の集計値であり、個別クエリの実行時間・スキャン行数・WLM 待機時間は取得できません。 選択肢DのRedshift Advisor は将来の最適化提案（圧縮・分散キー等）を提供するツールであり、過去クエリの詳細な診断情報は提供しません。