DEAデータオペレーションとサポート
あるデータエンジニアリングチームは、Amazon Redshiftクラスター上で多数のアナリストが同時にアドホッククエリを実行しています。一部のクエリが数時間実行されてシステムリソースを占有し、他のクエリのパフォーマンスが大幅に低下することが課題になっています。長時間実行クエリを自動的に検出して終了させるための最も適切なアプローチはどれですか?
AAmazon CloudWatchのアラームでRedshiftの実行中クエリ数メトリクスを監視し、閾値超過時にLambda関数からRedshift Data APIを呼び出してクエリをキャンセルする
CloudWatchのRedshiftメトリクスはクラスター全体の集計値であり、個別クエリの実行時間を特定する機能がないため、Lambda経由での正確なキャンセル処理の実現には複雑な追加実装が必要になります。
BAmazon RedshiftのWorkload Management(WLM)でQuery Monitoring Rules(QMR)を設定し、実行時間が閾値を超えたクエリを自動的に中断またはキューへ移動させる
✓ 正解
WLMのQMRはRedshift内でクエリ単位の実行時間・スキャン行数などを継続的に監視し、閾値超過時に即座に中断・キュー変更などのアクションを自動実行できる最もシンプルで効果的な方法です。
CAWS Glue DataBrewのプロファイルジョブをスケジュール実行してRedshiftのクエリ実行統計を収集し、長時間クエリのパターンを分析してDBAが手動対応する
AWS Glue DataBrewはS3やGlueデータカタログ上のデータセットに対するプロファイリングツールであり、Redshiftクラスター上で実行中のクエリのパフォーマンス監視や自動終了には対応していません。
DAmazon EventBridgeのスケジュールルールでLambda関数を定期的に起動し、SVL_QLOGシステムビューをスキャンして実行時間超過クエリを自動でキャンセルする
EventBridge + LambdaによるSVL_QLOGポーリングは技術的に実現可能ですが、ポーリング間隔内での対応遅延が生じ、WLM QMRのリアルタイム検知と比べてリソース浪費期間が長くなります。
解説
Amazon RedshiftのWorkload Management(WLM)は、クエリキューを管理してリソース配分を制御する機能です。その中のQuery Monitoring Rules(QMR)では、クエリの実行時間(query_execution_time)・スキャン行数・メモリ使用量などの条件を閾値として設定し、超過したクエリに対して「中断(abort)」「ログ記録(log)」「キュー変更(change_query_priority)」などのアクションをリアルタイムに自動実行できます。追加のコードやインフラ構築なしにRedshift内で完結する最もシンプルで確実なアプローチです。
選択肢AのAmazon CloudWatch + Lambdaの組み合わせは、CloudWatchのRedshiftメトリクスがクエリ単位の実行時間を提供しないため、個別クエリの識別・キャンセルを正確に行うには追加実装が必要で複雑になります。
選択肢CのAWS Glue DataBrewはRedshiftのクエリパフォーマンス監視機能を持たず、このユースケースには対応していません。
選択肢DのAmazon EventBridge + LambdaによるSVL_QLOGスキャンは技術的には可能ですが、ポーリング間隔内での対応遅延が生じ、WLM QMRのリアルタイム検知・対応と比べて運用効率が低くなります。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →