Amazon Redshiftでクエリパフォーマンスを最大化するベストプラクティス徹底解説

※本記事は2020年6月17日にOnica.comブログで公開された内容を基にしています。

多くの業界の企業が、業務運営や事業成功に不可欠な機能のためにデータ分析を活用しようとしています。しかし、データ量が増大するにつれて、データ管理や価値の抽出はますます複雑になります。そこで注目されているのが、AWSが提供する強力なデータウェアハウスサービス「Amazon Redshift」です。

Amazon Redshiftとは

Amazon® Redshift®は、Amazon Web Services®（AWS）が提供するデータウェアハウスサービスで、データ管理と分析を大幅に簡素化します。本記事では、Amazon Redshiftの概要と、クエリパフォーマンスを最適化するためのベストプラクティスについて詳しく解説します。

データレイクとデータウェアハウスの違い

Amazon Redshiftを理解する前に、まずデータレイクとデータウェアハウスの違いを押さえておきましょう。データレイク（例：Amazon S3）は、構造化データと非構造化データを、元の形式を変更することなくあらゆる規模・多様なソースから一元的に保存するリポジトリです。一方、データウェアハウスは、継続的な分析処理に最適化された形でデータを格納し、データレイクから分析に必要なデータのみをロードします。

Amazon Redshiftはさらに一歩進んだアプローチを採用しており、データレイクとデータウェアハウス両方の特性を融合した「レイクハウス」型を実現しています。エクサバイト規模の大規模なデータレイクに対してクエリを実行しながら、コスト効率を維持し、データの冗長性、メンテナンス負荷、運用コストを最小限に抑えることが可能です。

Amazon Redshiftのアーキテクチャ

Amazon Redshiftは、大規模データセットに対する複雑なクエリを高速に処理するために、マッシブリー パラレル プロセッシング（MPP：超並列処理）をサポートしています。MPPでは、処理を多数のコンピュートノードに分散させ、並行して実行します。

これらのノードはクラスタとしてグループ化され、各クラスタは以下の3種類のノードで構成されます。

• リーダーノード：接続の管理、SQLエンドポイントとしての役割、並列SQL処理の調整を担当します。

• コンピュートノード：「スライス」と呼ばれる単位で構成され、カラムナ形式かつ1MBのイミュータブルブロックに格納されたデータに対してクエリを並列実行します。Amazon Redshiftクラスタには1〜128台のコンピュートノードを含めることができ、各スライスはテーブルデータを保持し、ローカル処理領域として機能します。

• Amazon Redshift Spectrumノード：Amazon S3上のデータレイクに対してクエリを実行します。

クエリパフォーマンスの最適化

クラスタ内のデータの物理配置を実際のクエリパターンと一致させることで、最適なクエリ性能を引き出すことができます。もしAmazon Redshiftのパフォーマンスが期待どおりでない場合は、ワークロード管理（WLM）の再設定を検討しましょう。

ワークロード管理（WLM）の再設定

WLMはデフォルト設定のまま使われがちですが、適切にチューニングすることでパフォーマンスを大きく改善できます。WLMの設定は自動または手動で行えます。自動設定の場合、Amazon Redshiftがクラスタのリソース使用状況に基づいてメモリ使用量と同時実行数を自動的に管理し、優先度を指定したキューを最大8つまで設定できます。手動設定の場合は、同時実行クエリ数、メモリ割り当て、ターゲットなどを柔軟に調整できます。

また、以下のWLM構成パラメータを活用することでも、クエリパフォーマンスを最適化できます。

• クエリモニタリングルール：高コストなクエリや暴走クエリを管理・制御するのに役立ちます。

• ショートクエリアクセラレーション：機械学習アルゴリズムによってクエリの実行時間を予測し、短時間で完了するクエリを長時間実行クエリより優先的に処理します。

• 同時実行スケーリング：数秒で一時的なクラスタを追加でき、同時読み取りクエリの高速化を実現します。

WLMチューニングのベストプラクティス

WLMを効果的にチューニングするための主なベストプラクティスは以下のとおりです。

• ワークロードの種類ごとに異なるWLMキューを作成する。
• メインクラスタの最大合計同時実行数を15以下に制限し、スループットを最大化する。
• 同時実行スケーリングを有効にする。
• キュー内のリソース数を最小限に抑える。

データ分散の最適化

Amazon Redshiftは、テーブルの行を以下の分散スタイルに基づいて、ノードのスライスへ自動的に分散します。

• AUTO：初期状態ではALLで開始し、テーブルが成長するとEVENに自動的に切り替わります。
• ALL：小規模で結合頻度が高く、更新頻度の低いテーブル向けです。各コンピュートノードの最初のスライスに全データが配置されます。
• EVEN：大規模でスタンドアロンのファクトテーブルなど、頻繁に結合や集計されないテーブル向けです。ラウンドロビン方式でスライス全体に均等に分散されます。
• KEY：頻繁に結合されるファクトテーブルや大型ディメンションテーブル向けです。指定した列の値がハッシュ化され、同じハッシュ値を持つ行は同じスライスに配置されます。

適切な分散パターンを選択することで、JOIN、GROUP BY、INSERT INTO SELECTなどの操作のパフォーマンスを最大化できます。

データソートの最適化

ソートキーはディスク上のデータの物理的な順序を定義します。WHERE句の述語で使用されるテーブル列はソートキーとして適しており、一般的には日付や時刻に関連する列がよく使われます。また、メモリに保持され自動生成されるゾーンマップを使用すると、各データブロックの値の範囲（最小値・最大値）を定義できます。ソートキーとゾーンマップを効果的に組み合わせることで、スキャン対象を必要最小限のブロックに絞り込むことができます。

次の図は、テーブルのソートによって時間軸ベースのクエリにおけるスキャン範囲が絞り込まれ、クエリパフォーマンスが向上する仕組みを示しています。

クエリパフォーマンス最適化のための追加ベストプラクティス

前述のAmazon Redshiftの設定変更を活用することで、クエリパフォーマンスの向上とコスト・リソース効率の改善が期待できます。さらにパフォーマンスを向上させるために、以下のベストプラクティスも実践しましょう。

• WHERE句のフィルタで頻繁に使用される列にはSORTKEYを設定する。
• JOIN述語で頻繁に使用される列にはDISTKEYを設定する。
• 先頭のソートキー列を除くすべての列に圧縮を適用する。
• アクセスパターンなどのクエリフィルタに基づいて、データレイク側のデータをパーティショニングする。

さらなるベストプラクティスや、Amazon Redshiftの設定変更の詳細、詳細なクエリ分析の実例については、AWS Partner Network（APN）ブログをご覧ください。

データ活用の旅を始めたばかりで、AWSサービスを活用して迅速かつ信頼性の高い、費用対効果の高いデータプラットフォームを構築したいとお考えでしたら、ぜひ当社のData Engineering & Analyticsチームまでお気軽にお問い合わせください。

Onicaのサービスについて詳しくはこちらをご覧ください。

ご意見やご質問がある場合は、フィードバックタブをご利用ください。また、Sales Chatをクリックして、今すぐチャットで会話を始めることもできます。