Amazon Redshift RGインスタンス vs RA3インスタンス - クラスタのパフォーマンス・コストを TPC-H 10GB で比較してみた

クラウド事業本部の石川です。5/14にAmazon Redshift の新世代 RG インスタンス（Graviton ベース）が発表されました。本日は、新世代 RG インスタンス（Graviton ベース）と従来の RA3 インスタンスの性能差を、TPC-H 10GB を使って実測比較してみました。

https://dev.classmethod.jp/articles/amazon-redshift-rg-instances-graviton/

2026 年 5 月、AWS は Amazon Redshift の新しいコンピュートノードとして RG インスタンス（AWS Graviton ベース、データレイククエリエンジン統合）をリリースしました。AWS 公式ブログでは、従来の RA3 インスタンスに対して以下の性能・コスト改善が公表されています。

これらは理想条件下のピーク値であり、実ワークロードでの再現性は自社で検証する必要があります。今回は、rg.xlarge × 2 ノード と ra3.xlplus × 2 ノード の両クラスタを us-east-1 に用意し、TPC-H 10GB のローカルテーブルに対する 22 クエリのレイテンシを 2 時間枠で実測しました。

https://dev.classmethod.jp/articles/20260516-amazon-redshift-benchmark-data/

最初に結論

rg.xlarge × 2 と ra3.xlplus × 2 を us-east-1 にて TPC-H 10GB で比較した結果、以下が確認できました。

• クエリレイテンシ: 22 クエリ speedup 中央値 1.51 倍（合計 7.52 秒 → 11.26 秒）
• コスト効率（東京リージョン単価で試算）: 同一ワークロードでの円 / クエリ比 0.47（rg が約 53% 安い）
• COPY ロード性能: 8 表合計 speedup 1.38 倍（83 秒 → 114 秒）

検証環境

rg.xlarge と ra3.xlplus は vCPU・メモリのスペック上は同一です。RG は AWS Graviton ベースで「データウェアハウスとデータレイクの統合クエリエンジン」を内蔵している点が大きな違いになります。

両クラスタには事前に AWS Labs CloudDataWarehouseBenchmark の TPC-H 10GB データ（8 表・約 8,659 万行）を COPY 済みです。

https://github.com/awslabs/amazon-redshift-utils/tree/master/src/CloudDataWarehouseBenchmark

やってみた

検証は次の流れで進めました。

前提条件

• 両クラスタは available 状態、TPC-H 10GB を tpch10g スキーマに COPY 済み
• リージョン: us-east-1
• 接続: Redshift Data API（batch-execute-statement / describe-statement）
• 計測 PC: MacBook

検証準備: 両クラスタの状態を揃える

クエリ性能比較で大きく結果が変わる要素として、(1) データ件数と統計情報、(2) Result Cache、(3) Concurrency Scaling、(4) search_path の差分があります。それぞれ次のように揃えました。

件数照合と統計情報の更新

両クラスタで TPC-H 8 表の件数を取得して完全一致を確認し、ANALYZE を再実行して統計情報を最新化します。結果は両クラスタ完全一致でした。

続けて、両クラスタで全 8 表に ANALYZE を実行します。execute-statement は単一 SQL しか受け付けないので、batch-execute-statement で複数文を 1 リクエストにまとめます。

for CLUSTER in rg2 xlplus2; do
  aws redshift-data batch-execute-statement \
    --cluster-identifier ${CLUSTER} --database dev --db-user awsuser \
    --region us-east-1 \
    --sqls "ANALYZE tpch10g.region" "ANALYZE tpch10g.nation" \
            "ANALYZE tpch10g.supplier" "ANALYZE tpch10g.customer" \
            "ANALYZE tpch10g.part" "ANALYZE tpch10g.partsupp" \
            "ANALYZE tpch10g.orders" "ANALYZE tpch10g.lineitem"
done

テーブル分散状況の比較

SVV_TABLE_INFO でテーブルの圧縮後サイズ・分散キー・スキューが両クラスタで揃っているか確認します。

aws redshift-data execute-statement \
  --cluster-identifier rg2 --database dev --db-user awsuser --region us-east-1 \
  --sql "SELECT \"table\", size, tbl_rows, skew_rows, sortkey1, diststyle
         FROM svv_table_info WHERE schema='tpch10g' ORDER BY \"table\""

両クラスタとも size / tbl_rows / diststyle / sortkey1 まで完全に一致しました（AUTO(ENCODE) で同じ列圧縮、KEY 分散も同一）。

Result Cache の無効化と search_path 設定

クエリ性能の素の値を比較するには Result Cache を確実に無効化する必要があります。Redshift Data API は execute-statement で SET ...; SELECT ... のような複数文を送ると先頭の SET だけを処理してしまうため、後述するベンチマークスクリプトでは batch-execute-statement で SET enable_result_cache_for_session = OFF と TPC-H クエリを 1 セッション内で続けて実行する形にしました。

また、tpch10g スキーマに修飾なしでアクセスできるよう、awsuser の search_path を両クラスタに永続設定します。

for CLUSTER in rg2 xlplus2; do
  aws redshift-data execute-statement \
    --cluster-identifier ${CLUSTER} --database dev --db-user awsuser \
    --region us-east-1 \
    --sql "ALTER USER awsuser SET search_path = tpch10g, public"
done

シナリオ①: COPY ロード性能

クラスタ作成時に取得済みの 2 件の evidence/<run_id>/copy_durations.tsv を引用し、テーブル別のロード時間を比較します。duration_ms は aws redshift-data describe-statement --query Duration が返す値（ナノ秒）を ms に換算したものです。

8 表の合計ロード時間は rg2 が約 83 秒、xlplus2 が約 114 秒で、RG が 約 1.38 倍速く ロードを完了しました。特に最大テーブルの lineitem（約 6,000 万行 / 2.7GB）は 54.6 秒 vs 76.4 秒で、Graviton + 統合 I/O エンジンが大きなテーブルでも安定して効いている印象です。

小さい region / nation は speedup 倍率が大きく見えますが、絶対値が ms オーダーなので解釈には注意が必要です。

シナリオ②: TPC-H 22 クエリのレイテンシ計測

対象クエリ（TPC-H 22 クエリ全本）

TPC-H 10GB はサイズが小さく、22 クエリ × 3 回 × 2 クラスタ = 132 実行でも 60 分以内に収まる見込みのため、標準 22 クエリを全本対象とする。短/中/長の時間レンジ・JOIN/集約/サブクエリ/Window/CASE のすべての特性をカバーできる。

https://github.com/awslabs/amazon-redshift-utils/blob/master/src/CloudDataWarehouseBenchmark/Cloud-DWB-Derived-from-TPCH/10GB/queries/query_0.sql

ベンチマークスクリプト

AWS Labs CloudDataWarehouseBenchmark 配下の Cloud-DWB-Derived-from-TPCH/10GB/queries/query_0.sql には 22 クエリが 1 ファイルに連結されています。これを Python で 22 ファイルに分割し、Q15 だけ revenue ビューが必要だったので WITH 句に書き換えた上で、Bash 製の run_benchmark.sh から batch-execute-statement で順次投入しました。

# run_benchmark.sh の主要部
run_sql() {
  local sql_raw="$1"
  local label="$2"
  local batch_id
  batch_id=$(aws redshift-data batch-execute-statement \
    --cluster-identifier "${CLUSTER}" \
    --database "${DATABASE}" \
    --db-user "${DB_USER}" \
    --region "${REGION}" \
    --statement-name "${TARGET}-${label}" \
    --sqls "SET enable_result_cache_for_session = OFF" "${sql_raw}" \
    --query 'Id' --output text)
  # 完了待ち + 結果 SubStatement[1] の Duration を採用
}

計測方針は以下の通りです。

各 execute-statement は新しいセッションで実行されるため、batch-execute-statement で SET 文と本体クエリを同セッションに同梱することで Result Cache を確実に切ります。先行ウォームアップで Q01 を 3 回回すと dur=604/615/615 ms と安定しており、Result Cache が効いていないことを実測でも確認できました。

計測結果（median ms）

# rg2 / xlplus2 を別端末から同時起動
./scripts/run_benchmark.sh --target rg2 --cluster-identifier rg2 \
  --database dev --db-user awsuser --region us-east-1 --iterations 3
./scripts/run_benchmark.sh --target xlplus2 --cluster-identifier xlplus2 \
  --database dev --db-user awsuser --region us-east-1 --iterations 3

ウォームアップ 1 回 + 本計測 3 回（合計 88 実行 × 2 クラスタ = 176 実行）が両クラスタとも全クエリ FINISHED で完了しました。median 値と speedup を以下にまとめます。

22 クエリの speedup を集計すると以下になりました。

• speedup 中央値: 1.51 倍
• speedup 平均: 1.48 倍
• speedup 最大: 1.69 倍（Q20: 階層サブクエリ + 半結合）
• speedup 最小: 1.20 倍（Q06: 単表 lineitem + 範囲述語、もともと 64ms と短い）

公称値の「最大 2.2 倍」は届きませんでしたが、これはピーク値であり、22 クエリ平均で 1.5 倍前後が出ているのは妥当な水準だと考えられます。Q13・Q20 のような結合や半結合が多いクエリ、Q01・Q21 の重い集計クエリで 1.5〜1.7 倍が出ていて、ワークロードが厳しいほど効きが大きい印象です。

シナリオ③: コスト効率（円 / クエリ・東京リージョン前提）

レイテンシ計測自体は us-east-1 で実施しましたが、実運用を想定して 東京リージョン (ap-northeast-1) のオンデマンド単価で円 / クエリを試算します。単価は検証日 (2026-05-17) の aws pricing get-products で取得した値、為替は 1 USD = ¥150 の概算 TTM を使い、以下の式で算定します。

aws pricing get-products --service-code AmazonRedshift --region us-east-1 \
  --filters "Type=TERM_MATCH,Field=instanceType,Value=rg.xlarge" \
            "Type=TERM_MATCH,Field=location,Value=Asia Pacific (Tokyo)" \
            "Type=TERM_MATCH,Field=productFamily,Value=Compute Instance"

クラスタ稼働コスト(円/秒) = ノード単価(USD/h) × ノード数 × 為替(JPY/USD) ÷ 3600
1 クエリあたりコスト(円) = median レイテンシ(秒) × クラスタ稼働コスト(円/秒)

ノード単価だけで見ると rg.xlarge は ra3.xlplus 比で約 30% 安く、22 クエリの median 合計と単価を掛け合わせると、次のようになります。

コスト比 (rg2 / xlplus2) は 0.47、つまり同じ 22 クエリを東京リージョンで実行するのに rg2 のほうが約 53% 安く済む 結果になりました。「vCPU 単価 30% 削減」と「レイテンシ 1.5 倍速」が掛け合わさり、コスト効率では 2 倍近い差が出る形です。

レイテンシは us-east-1 の実測値、コストは東京リージョン単価で試算しています。リージョン間のレイテンシ差は本検証では考慮していません。並列実行下のスループットも計測しておらず、単発レイテンシ × 単価で算出した値であるため、実運用の同時実行性能を反映するものではありません。

考察

検証して感じたポイントを整理します。

• ローカルテーブル対象、22 クエリ平均で 1.5 倍のレイテンシ高速化が安定して出る: 短クエリ（Q06: 64ms / Q14: 132ms）でも 1.2〜1.3 倍、重いクエリ（Q01・Q13・Q18・Q21 など 500ms 以上）で 1.5〜1.7 倍と、レンジを問わず一定の改善が確認できました。公称の「最大 2.2 倍」はピーク値で、ワークロード全体ではこれより低い倍率が現実的だと感じます。
• コスト効率は約 53% 削減（東京リージョン換算）: rg.xlarge は ra3.xlplus に対してノード単価が約 30% 安く（東京: $0.8946/h vs $1.278/h）、その上でレイテンシも 1.5 倍速なので、円 / クエリで見ると半分以下になります。同じワークロードを 1 / 2 のコストで動かせる計算で、ノード単価表だけ眺めるよりインパクトが大きい結果でした。
• COPY ロードも約 1.38 倍速い: クエリ性能ほどではないですが、TPC-H 10GB の 8 表合計で 83 秒 vs 114 秒。Graviton と統合 I/O の効果は単発クエリだけでなく書き込み系にも出ています。dev 環境のリストアやサンプルデータ投入が早く済むメリットは小さくないと思います。
• Redshift Data API で正しく Result Cache を切るには batch-execute-statement が必要: execute-statement で SET ...; SELECT ... を送ると先頭の SET だけ実行されて結果セットが空のまま FINISHED になります。今回は SET enable_result_cache_for_session = OFF と本体クエリを batch-execute-statement の 2 SQL として同セッションで投げ、SubStatements[1].Duration を採用する形にしました。
• 公平性を担保するには default.redshift-2.0 パラメータグループの揃え方も要確認: 今回は両クラスタとも default.redshift-2.0 を使用しており、AutoMV や analyze_threshold_percent 等もデフォルトのまま揃えています。本気で再現性を求める場合はカスタムパラメータグループを切る方が安全ですが、defaults 同士の比較でもデータ・統計情報・search_path・Result Cache を揃えれば 1.5 倍前後の差は安定して観測できます。
• 同時実行スループットは別途検証が必要: 単発レイテンシしか測っていないため、複数ユーザー / 複数クエリ並列下の挙動（Concurrency Scaling、WLM スロット争奪）は別の検証で追う必要があります。BI ツールからの実 E2E や、大規模 ETL での挙動評価は本検証のスコープ外です。

最後に

rg.xlarge × 2 と ra3.xlplus × 2 を us-east-1 にて TPC-H 10GB で比較した結果、以下が確認できました。

• クエリレイテンシ: 22 クエリ speedup 中央値 1.51 倍（合計 7.52 秒 → 11.26 秒）
• コスト効率（東京リージョン単価で試算）: 同一ワークロードでの円 / クエリ比 0.47（rg2 が約 53% 安い）
• COPY ロード性能: 8 表合計 speedup 1.38 倍（83 秒 → 114 秒）

公称値（最大 2.2 倍）はあくまでピーク値ですが、TPC-H 10GB という比較的軽量なワークロードでも 1.5 倍前後・コスト半減という成果が、決定論的・再現性の高い手順で得られました。RA3 を本番運用していて RG への移行を検討している方の判断材料の一助になれば幸いです。

並列スループットや Iceberg 外部テーブルに対する性能差、より大きいデータセット（100GB・1TB）での比較はクレジットがもらえたら別の検証で追っていきます。

合わせて読みたい

https://aws.amazon.com/jp/blogs/aws/amazon-redshift-introduces-aws-graviton-based-rg-instances-with-an-integrated-data-lake-query-engine/

https://aws.amazon.com/jp/about-aws/whats-new/2026/05/amazon-redshift-rg-instances-powered-by-graviton/

https://github.com/awslabs/amazon-redshift-utils/tree/master/src/CloudDataWarehouseBenchmark