ある企業が AWS 上で Amazon Redshift クラスターを運用しており、毎日数十のバッチクエリが実行されています。最近、特定の大規模クエリの実行時間が急増しており、クエリのキューイングが発生してダッシュボードの更新が遅延しています。ワークロードを調査したところ、ETL バッチクエリ（長時間・大量データスキャン）とダッシュボードクエリ（短時間・低レイテンシー要件）が同じキューで競合していることが判明しました。最もコスト効率よくパフォーマンスを改善するには、どの方法が適切ですか？
- A. Redshift の WLM（ワークロード管理）を設定し、ETL バッチクエリ用のキューとダッシュボード用の低レイテンシークエリキューを分離する。Redshift Serverless または Concurrency Scaling を有効化して、ピーク時のクエリコンカレンシーを自動スケールで処理する
- B. ダッシュボードクエリを Amazon Athena に移行し、S3 のデータに直接クエリする
- C. Redshift クラスターのノード数を増加させてコンピューティングキャパシティを追加する
- D. Redshift クラスターを Amazon EMR Spark クラスターに移行し、Spark SQL でクエリを処理する
解答と解説を見る
正解: A
Redshift WLM のキュー分離は、ETL バッチ（高スロット数・低優先度）とダッシュボード（低スロット数・高優先度）を別キューに配置し、リソース競合を排除します。Concurrency Scaling は同時実行数が増加した際に追加のクラスターキャパシティを一時的に提供し、コストはクレジット単位で課金されます（毎日 1 時間のクレジットが無料で付与）。 C: ノード数増加はキャパシティを増やしますが、キュー競合の根本原因を解決せず、常時コストが増加します。WLM の設定変更はコスト増加なしで実現できます。 B: ダッシュボードクエリを Athena に移行することは有効ですが、Redshift に最適化されたデータを再度 S3 に移行するか、Redshift Spectrum を使う設計変更が必要で、アーキテクチャの複雑性が増します。 D: EMR Spark への全移行は大規模なアーキテクチャ変更と移行コストが生じ、「コスト効率よく改善」の要件には過剰な対応です。
📚 関連サービスの解説: Amazon Redshift