Amazon Redshift RG インスタンスへ Snapshot Restore で Blue-Green 移行してみた
クラウド事業本部の石川です。Amazon Redshift から AWS Graviton ベースの RG インスタンスがリリースされました。 ra3.xlplus 2 ノードクラスタから rg.xlarge 2 ノードクラスタへのスナップショット復元方式（Blue-Green）での移行を、us-east-1 で実際に試してみました。
Amazon Redshift で Graviton プロセッサを搭載した RG インスタンスが 2026 年 5 月 12 日に一般提供開始されました。RA3 と同様に Redshift Managed Storage を使う一方、コンピュートを Graviton 化したうえで、データレイククエリ用の統合エンジンをクラスタ内に持つのが特徴です。RA3 比で vCPU 当たり 30% 低価格、Apache Iceberg で最大 2.4 倍、Apache Parquet で最大 1.5 倍の高速化が公表されています。
今回は先日の検証ブログのクラスタ ra3.xlplus 2 ノードクラスタ xlplus2 から、RG 系の rg.xlarge 2 ノードクラスタ（プロジェクト内呼称: dg インスタンスの dgm）への移行要件に従い、方式 B（スナップショット復元 + 識別子切替の Blue-Green）を軽量データで実測する目的で検証しました。
RG インスタンスとは
公式ドキュメントの内容を簡単に要約します。
RG インスタンスは以下 2 サイズが提供されています。
| ノードタイプ | vCPU | RAM (GiB) | Slices / Node | Managed Storage / Node | ノード範囲 |
|---|---|---|---|---|---|
| rg.xlarge | 4 | 32 | 2 | 32 TB | 2〜16 (Elastic Resize で最大 32) |
| rg.4xlarge | 16 | 128 | 8 | 128 TB | 2〜32 (Elastic Resize で最大 64) |
rg.xlarge は ra3.xlplus と同じ 4 vCPU / 32 GiB の組み合わせで、AWS の公式推奨マッピングも ra3.xlplus 1 ノードに対して rg.xlarge 1 ノードと案内されています。今回の xlplus2 (2 ノード) → dgm (2 ノード) はこの推奨に従った構成です。
RA3 と RG の最大の差は、データレイククエリの実行方式です。RA3 では Redshift Spectrum という別フリートを経由し、$5/TB のスキャン課金が発生します。一方 RG では「統合データレイクエンジン」がクラスタ自身のコンピュート上で動作するため、VPC 境界の中で完結し、Spectrum のスキャン課金は発生しません。
なお、RA3 / DC2 から RG への移行には、ソースクラスタが Patch 201 以降である必要があります。本検証ではこの条件を満たしていることを事前確認しています。
やってみた
前提条件
- AWS リージョン: us-east-1 (N. Virginia)
- 移行元クラスタ:
xlplus2(ra3.xlplus× 2 ノード、databasedev、master userawsuser) - 移行先クラスタ:
dgm-verify(rg.xlarge× 2 ノードを新規作成) - ベンチマークデータ: TPC-H 10GB scale の Iceberg テーブル (
s3://rg2-iceberg-517444948157-us-east-1/tpch10g_iceberg/、Glue Data Catalog のtpch10g_icebergデータベースに登録済み) - 検証日: 2026-05-17
- 検証クエリ: TPC-H Q1 風の集計 (
lineitem5,900 万行に対するGROUP BY集計)
移行方式の比較と選定
RA3 から RG へ移行する公式の方法は、大きく以下の 3 つに整理できます。
| 方式 | 概要 | ダウンタイム | ロールバック容易性 | 検証期間 | 主な適用ケース |
|---|---|---|---|---|---|
| A. Elastic Resize | スライスを維持したまま in-place でノードを差し替える | 10〜15 分 | 低 (再度 Elastic Resize で戻す) | 取れない | 短時間で in-place 移行したい、ノード数同一・対応サイズ間の移行 |
| B. Snapshot Restore + 識別子切替 (Blue-Green) | スナップショットから新規クラスタを別途構築し、識別子を切り替える | 数分〜10 分 | 高 (旧クラスタを温存可能) | 十分 (旧新並行運用) | 検証期間を確保したい、ロールバック容易性を重視したい |
| C. Classic Resize | データ再分散を伴うリサイズ | 数時間 | 低 | 取れない | ノード数を変更する、Elastic Resize が選べない構成 |
今回のユースケースは以下の特性を持ちます。
- ノード数は 2 → 2 、スライス数は 4 → 4 、で変更なし（C は不要）
- データレイク・クエリ性能の改善を本番投入前に Iceberg の実測で確認したい（検証期間を確保したい）
- 既存
xlplus2を温存して、問題があれば即時ロールバックできる構成にしたい - IAM ロールや WLM 等の継承差分を本番切替前に洗い出したい
これらの条件を最もよく満たすのは 方式 B (Snapshot Restore + 識別子切替の Blue-Green) です。Elastic Resize は所要時間こそ短いものの、旧クラスタが残らずロールバックが困難で、IAM ロール継承差分を切替前に確認できません。今回は方式 B を本命としており、本検証ではその事前準備〜検証フェーズまでを実演します（実運用での識別子スワップは別途実施する想定）。
移行手順の全体像
本検証で実施するステップを図で示します。
ステップ 1: スナップショットから dgm-verify を復元
xlplus2 の自動スナップショットを rg.xlarge 2 ノード構成で dgm-verify として復元します。--node-type rg.xlarge を指定するだけで、ノードタイプを変えての復元が可能です。
aws redshift restore-from-cluster-snapshot \
--region us-east-1 \
--cluster-identifier dgm-verify \
--snapshot-identifier "rs:xlplus2-2026-05-17-05-53-51-821" \
--node-type rg.xlarge \
--number-of-nodes 2 \
--cluster-subnet-group-name default \
--no-publicly-accessible
{
"Id": "dgm-verify",
"Status": "creating",
"NodeType": "rg.xlarge",
"Nodes": 2,
"VpcId": "vpc-7814de1d"
}
10GB scale という比較的小規模なデータセットだったこともあり、creating から available までは約 3 分で完了しました。
ステップ 2: IAM ロールの再付与
describe-clusters で復元直後の dgm-verify を確認すると、IamRoles が空配列でした。スナップショット復元時に IAM ロールは継承されないため、明示的に再付与する必要があります。
aws redshift describe-clusters \
--region us-east-1 \
--cluster-identifier dgm-verify \
--query 'Clusters[0].IamRoles'
外部スキーマで S3 上の Iceberg テーブルを参照するため、xlplus2 用に作成済みの IAM ロール xlplus2-s3-read を dgm-verify にも追加します。
aws redshift modify-cluster-iam-roles \
--region us-east-1 \
--cluster-identifier dgm-verify \
--add-iam-roles arn:aws:iam::517444948157:role/xlplus2-s3-read
{
"Id": "dgm-verify",
"Roles": [
"arn:aws:iam::517444948157:role/xlplus2-s3-read"
],
"Status": "modifying"
}
in-sync になるのを polling したところ、こちらも 30 秒程度で反映が完了しました。
ステップ 3: 外部スキーマの作成
両クラスタで同一の Glue データベース tpch10g_iceberg を参照する外部スキーマを作成します。Redshift Data API 経由で実行します。
xlplus2 側:
CREATE EXTERNAL SCHEMA IF NOT EXISTS tpch_iceberg
FROM DATA CATALOG
DATABASE 'tpch10g_iceberg'
IAM_ROLE 'arn:aws:iam::517444948157:role/xlplus2-s3-read';
dgm-verify 側も同一の DDL で問題なく作成できました。RA3 でも RG でも CREATE EXTERNAL SCHEMA の構文は変わらず、外部スキーマや既存 Spectrum クエリはそのまま再利用できます。
ステップ 4: ベンチマーククエリ実行
TPC-H Q1 風の集計クエリを両クラスタで 3 回ずつ実行しました。クエリは lineitem (Iceberg, 5,900 万行、約 2.9 GB) に対する GROUP BY 集計です。
SELECT
l_returnflag,
l_linestatus,
SUM(l_quantity) AS sum_qty,
SUM(l_extendedprice) AS sum_base_price,
SUM(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
AVG(l_quantity) AS avg_qty,
AVG(l_extendedprice) AS avg_price,
AVG(l_discount) AS avg_disc,
COUNT(*) AS count_order
FROM tpch_iceberg.lineitem
WHERE l_shipdate <= DATE '1998-09-02'
GROUP BY l_returnflag, l_linestatus
ORDER BY l_returnflag, l_linestatus;
Redshift Data API の describe-statement から取得した実行時間 (Duration、ナノ秒) を秒に換算した結果が以下です。
| クラスタ | エンジン | Run 1 | Run 2 | Run 3 | 平均 |
|---|---|---|---|---|---|
| xlplus2 (ra3.xlplus × 2) | Redshift Spectrum | 16.50 秒 | 16.23 秒 | 15.26 秒 | 15.99 秒 |
| dgm-verify (rg.xlarge × 2) | 統合データレイクエンジン | 5.70 秒 | 4.35 秒 | 3.87 秒 | 4.64 秒 |
3 回平均で 約 3.45 倍、3 回目（warm 状態）で比較すると 約 3.95 倍の高速化となりました。AWS が公表している「Iceberg 最大 2.4 倍」を上回る結果が観測できています。
ステップ 5: データ整合性の検証
性能だけでなく、両クラスタで同一の結果が得られているかを検証します。
SELECT l_returnflag, l_linestatus, COUNT(*) AS cnt
FROM tpch_iceberg.lineitem
WHERE l_shipdate <= DATE '1998-09-02'
GROUP BY 1,2
ORDER BY 1,2;
xlplus2 側の結果:
l_returnflag | l_linestatus | cnt
-------------+--------------+-----------
A | F | 14804077
N | F | 385998
N | O | 29144351
R | F | 14808183
dgm-verify 側の結果:
l_returnflag | l_linestatus | cnt
-------------+--------------+-----------
A | F | 14804077
N | F | 385998
N | O | 29144351
R | F | 14808183
合計 59,142,609 行で、4 グループすべてのカウントが完全一致しました。スナップショット復元によるデータの欠落・重複は発生していません。
考察
検証から得られた知見を整理します。
- 同等構成でも顕著な高速化が得られる: 4 vCPU × 2 ノードの同等構成にもかかわらず、Iceberg クエリで平均 3.45 倍、ウォームアップでは約 3.95 倍と公表値を上回る差が観測できました。Spectrum を経由しない統合データレイクエンジンの効果が大きいと考えられます。
- Snapshot Restore で異なるノードタイプへ移行できる:
restore-from-cluster-snapshot --node-type rg.xlargeを指定するだけで、10GB scale のクラスタを約 3 分で構築できました。Blue-Green 方式での移行リハーサルとして十分実用的な所要時間です。 - IAM ロールはスナップショット復元で継承されない: 検証中、最大の落とし穴は IAM ロールの未継承でした。外部スキーマ作成や Glue Data Catalog アクセスのために、
modify-cluster-iam-rolesで再付与が必要です。要件定義書のロールバック計画やリスク表に、この項目を明示する価値があります。 - 外部スキーマの DDL に変更は不要:
CREATE EXTERNAL SCHEMAの構文は RA3 と RG で同一で、Glue データベースを指定するだけで Iceberg / Parquet 双方を扱えました。SQL 側のアプリケーション改修は今回の構成では発生しません。 - Spectrum スキャン課金が発生しない: dgm-verify 側のクエリは RG クラスタ自身のコンピュート上で動作し、Spectrum の $5/TB 課金は発生しません。データレイク中心のワークロードでは、コスト改善のインパクトが最も大きい部分です。
一方で、本検証ではカバーできなかった点もあります。
- 大規模データ・大規模ワークロードでのスナップショット復元時間: 10GB scale では約 3 分で完了しましたが、TB スケールでは復元時間と挙動が変わる可能性があります。実際の本番データ量で別途実測する必要があります。
- 同時実行スケーリングの挙動差: 単一クエリの実行時間は測定しましたが、同時実行下での WLM / Concurrency Scaling の挙動はワークロード再現テストが別途必要です。
- Spectrum を多用するワークロードの注意点: 公式ドキュメントでは「Spectrum を多用するクエリは RG 移行後に遅くなる場合があり、ノード数や
rg.4xlargeへの拡大を検討するように」と記載されています。今回は逆に高速化しましたが、ワークロード特性で結果が変わり得ることは留意が必要です。
最後に
本手順書では、マイグレーションの実施手順をマネジメントコンソールではなく、AWS CLI（AWSコマンド）を用いた方法で解説しています。検証済みのマイグレーション手順を齟齬なく正確に再現するには、コマンドによる実行が最適であるためです。
方式 B（Snapshot Restore + Blue-Green）を us-east-1 上の ra3.xlplus 2 ノード → rg.xlarge 2 ノードで実証したところ、約 3 分でクラスタを復元でき、TPC-H Q1 風クエリで平均 3.45 倍の高速化と完全なデータ整合性が確認できました。アプリケーション側の SQL 改修は不要で、外部スキーマ DDL もそのまま動作します。
一方で、IAM ロールがスナップショット復元で継承されない点は、移行手順書に明示すべき重要な実用情報です。modify-cluster-iam-roles での再付与ステップを必ず組み込んでおくと安全です。
データレイクを併用しているワークロードを ra3.xlplus で運用している方は、Snapshot Restore でまず軽量な検証用クラスタを rg.xlarge で立ち上げ、本記事と同じ流れで自分のワークロード固有のクエリを実測してみることをおすすめします。本記事がどなたかのお役に立てば幸いです。
参考リンク
