DEAデータオペレーションとサポート
あるデータエンジニアリングチームは、Amazon Redshiftクラスターで毎朝ETLパイプラインを実行するとともに、複数のアナリストチームがアドホックなBIクエリを実行しています。一部のアドホッククエリが1時間以上実行され、ETLキューを圧迫する問題が繰り返し発生しています。チームは以下を実現したいと考えています：
・実行時間が60分を超えるクエリを自動的にキャンセルする
・スキャンするデータ量が2TBを超えるクエリを低優先度キューへ自動的に転送する
・Redshiftクラスター以外の追加サービスを最小化する
最も適切なアプローチはどれですか？
AAmazon Redshiftのワークロード管理（WLM）でクエリモニタリングルール（QMR）を設定し、実行時間超過はABORT、スキャン量超過はHOPアクションを構成する
✓ 正解
WLMのQMR機能はクラスター設定のみで実行時間・スキャン量などのメトリクスを監視し、ABORT（強制終了）やHOP（別キューへ転送）アクションを自動実行できます。追加サービスなしで要件をすべて満たす最も適切なアプローチです。
BAmazon CloudWatchのRedshiftメトリクスを監視し、閾値超過時にAWS Lambda関数でSTL_QUERY_METRICSテーブルを参照してクエリをキャンセルするスクリプトを実行する
Lambda関数によるカスタム実装は技術的に可能ですが、定期ポーリングによる検出遅延、Redshiftへの接続管理、クエリキャンセルロジックをすべて自前実装する必要があり、追加サービスの最小化という要件にも反します。
CAmazon Redshift Serverlessに移行し、RPU（Redshift Processing Unit）の最大容量を設定してクエリのリソース使用量を自動制限する
RPU上限はクラスター全体のスケーリング制御であり、特定クエリの実行時間制限や別キューへの転送といった個別クエリ制御とは異なります。またServerlessへの移行自体が大規模な構成変更となり、現実的な短期解決策ではありません。
DAmazon Athenaをアドホッククエリ専用環境として分離し、Athenaのワークグループでスキャン上限を設定することでRedshiftへの負荷集中を回避する
Athenaは別のクエリサービスであり、既存Redshiftデータの移行・ETLパイプラインの再設計が必要な大規模変更です。追加サービスの最小化という要件に反し、Redshiftのキュー圧迫問題を根本的に解決するものでもありません。
解説
Amazon RedshiftのWLM（ワークロード管理）にはクエリモニタリングルール（QMR: Query Monitoring Rules）機能があります。QMRでは以下のようなルールをクラスター設定内で定義できます：
・query_execution_time > 3600（秒）：実行時間が60分を超えたクエリを検知
・scan_row_count / scan_size > N：スキャン量が閾値を超えたクエリを検知
違反時のアクションとして「ABORT（強制終了）」「HOP（別キューへ転送）」「LOG（ログのみ）」を設定でき、Redshiftクラスター設定のみで実現できるため追加サービスが不要です。
選択肢BのCloudWatch + Lambdaは実現可能ですが、Lambda定期実行・Redshiftへの接続・クエリキャンセルロジックを自前実装する必要があり、ポーリング間隔による検出遅延も生じます。
選択肢CのRedshift Serverlessへの移行は大規模な構成変更を伴います。またRPU上限はクラスター全体のスケーリング制御であり、個別クエリの実行時間制限・キュー転送制御とは異なります。
選択肢DのAthenaへの分離は、Redshiftのデータ・接続・クエリの移行を必要とする大きな構成変更であり、現実的な解決策ではありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →