Amazon Redshift のパフォーマンスチューニング - 分散キー・ソートキー・ WLM の最適化
Redshift の分散スタイルとソートキーの選定、ワークロード管理 (WLM) の設計、AQUA によるクエリ高速化を解説します。
分散スタイルの選定
Redshift はデータをコンピュートノードのスライスに分散して格納します。分散スタイルの選定はクエリ性能に直結する最重要の設計判断です。KEY 分散は指定したカラムの値に基づいてデータを分散し、同じキー値を持つ行が同一スライスに配置されます。JOIN で頻繁に使用されるカラムを KEY に指定すると、JOIN 時のデータ再分散 (ネットワーク転送) が不要になり、大幅な性能改善が得られます。EVEN 分散はラウンドロビンで均等に分散し、特定の JOIN パターンがないテーブルに適しています。ALL 分散はテーブル全体を全ノードにコピーし、小さなディメンションテーブルの JOIN に有効です。AUTO 分散は Redshift がテーブルサイズに基づいて自動選択し、小さいテーブルは ALL、大きいテーブルは EVEN になります。
ソートキーとゾーンマップ
ソートキーを設定すると、データがそのカラムの値順にディスク上に格納されます。Redshift はブロックごとに最小値と最大値をゾーンマップとして記録しており、WHERE 句のフィルタ条件がゾーンマップの範囲外のブロックをスキップします。日付カラムをソートキーに設定し、WHERE created_at > '2026-01-01' のようなフィルタを適用すると、該当期間のブロックのみがスキャンされ、I/O が大幅に削減されます。複合ソートキーは複数カラムの組み合わせで、最初のカラムが最も効果的にフィルタリングされます。インターリーブドソートキーは各カラムに均等な重みを付与し、どのカラムでフィルタしても効果がありますが、VACUUM の負荷が高くなります。
ワークロード管理と AQUA
自動 WLM はクエリの複雑さとリソース要件に基づいて、キューの割り当てとメモリ配分を自動的に最適化します。短時間のダッシュボードクエリが長時間の ETL クエリにブロックされる問題を解消し、優先度の高いクエリに適切なリソースを配分します。手動 WLM では最大 8 つのキューを定義し、ユーザーグループやクエリグループに基づいてクエリをルーティングできます。 AQUA は RA3 インスタンスで利用可能な機能で、フィルタリングや集約処理をストレージレイヤーのカスタムハードウェアで実行します。コンピュートノードに転送するデータ量を削減し、スキャン集約型のクエリを最大 10 倍高速化します。 データウェアハウスの活用事例を知るうえで関連書籍 (Amazon)が参考になります。
パフォーマンスチューニングのコスト影響
適切なパフォーマンスチューニングは直接的なコスト削減につながります。分散キーの最適化でノード間のデータ再分散 (Redistribution) を削減すると、クエリの実行時間が短縮され、Serverless の RPU 消費量が減少します。ソートキーの設定でゾーンマップのスキップ率を向上させると、スキャンするデータ量が減り、I/O コストが削減されます。AQUA (Advanced Query Accelerator) は RA3 ノードで追加料金なしで利用でき、LIKE 句やフィルタリングの処理をストレージレイヤーにオフロードしてクエリ性能を向上させます。
クエリの分析と実行計画
パフォーマンスチューニングの第一歩は、どのクエリが遅いのかを特定することです。Redshift は、実行されたクエリの履歴や所要時間を記録するシステムビューを備えており、ここから問題のあるクエリを見つけられます。クエリの実行計画を確認すれば、どこで時間がかかっているか、ノード間で大量のデータ移動が発生していないかが分かります。想定外のフルスキャンや、非効率な結合が起きていれば、それが改善対象です。推測でチューニングするのではなく、実測データと実行計画に基づいてボトルネックを特定することが、効果的な改善の出発点になります。
テーブルのメンテナンス
Redshift では、データの更新や削除を繰り返すと、内部的にデータの配置が乱れ、クエリ性能が徐々に低下することがあります。これを整える保守作業が重要です。データの並びを整理し、削除済み領域を回収する処理と、統計情報を最新化する処理を適切に行うことで、性能を保てます。これらは自動で実行される仕組みもありますが、大量のデータ変更を行った後は状態を確認します。テーブルの最適化を自動で調整する機能を活用すれば、運用の手間を抑えつつ良好な性能を維持できます。定期的なメンテナンスが、長期的な性能の安定につながります。
結果キャッシュとマテリアライズドビュー
同じクエリが繰り返し実行される場合、毎回ゼロから計算するのは無駄です。Redshift は、同一のクエリに対して以前の結果を再利用する仕組みを備え、繰り返しのクエリを高速に返します。頻繁に実行する集計処理は、結果をあらかじめ計算して保持するマテリアライズドビューにしておくと、その都度の重い計算を避けられます。元データが更新されたら、ビューを更新して最新の結果を保ちます。計算結果を再利用する仕組みをうまく使うことで、繰り返し発生する負荷を減らし、ダッシュボードや定型レポートの応答を大きく改善できます。
継続的な監視とチューニングサイクル
パフォーマンスチューニングは一度で終わるものではなく、継続的な取り組みです。データ量の増加や、利用パターンの変化によって、最適な設定は変わっていきます。クエリの監視ルールを設定し、極端に重いクエリや異常な実行を検知できるようにします。定期的に遅いクエリを洗い出し、実行計画を確認して改善する、というサイクルを回します。改善の効果を計測し、本当に速くなったかを確認します。監視・分析・改善・検証のサイクルを継続することで、データ規模が成長しても、安定した応答性能を保ち続けられます。
まとめ
Redshift のパフォーマンスチューニングは分散スタイルとソートキーの適切な設定が基本です。SVL_QUERY_SUMMARY でスロークエリを特定し、分散キーの見直しやソートキーの追加で改善します。自動 WLM でワークロードの優先度を管理し、AQUA でスキャン性能を向上させることで、大規模データ分析の応答時間を最適化できます。