Amazon Redshift の Graviton ベース RG インスタンスは、RA3 と比べてデータウェアハウスワークロードで最大2.2倍、データレイクワークロードで最大2.4倍の性能を、vCPU あたり30%低い価格で提供します。本記事では本番運用中の RA3 クラスターを RG へ移行するための3つの戦略（Elastic Resize・Classic Resize・Snapshot/Restore）の違いと選択基準、移行前後のコスト最適化、実際の移行手順と注意点を、データエンジニア・インフラエンジニア・DBA 向けに整理します。
RGインスタンスとは何か 移行で得られる性能とコストの利点
RG インスタンスは2026年5月12日にリリースされた、AWS Graviton プロセッサをベースとする Amazon Redshift の新しいノードタイプです。既存の RA3 と同じマネージドストレージのアーキテクチャを踏襲しながら、コンピュートを刷新することで価格性能比を大きく引き上げています。
AWS が公表している数値では、データウェアハウスワークロードで最大2.2倍、データレイクワークロードで最大2.4倍の性能向上が示されています。データレイク側の最大2.4倍は Apache Iceberg のケースを含む代表値であり、ファイル形式やクエリ特性によって効果は変動しますので、常時この倍率が出るわけではない点は押さえておいてください。加えて vCPU あたりの価格が30%低く、同じ処理を従来より低コストで実行できます。
もうひとつの重要な利点が、統合データレイククエリエンジンによる料金体系の変化です。RG では Redshift Spectrum のスキャンデータ量に応じた課金が不要になり、Iceberg や Parquet のスキャンをクラスターのノード上で処理します。外部テーブルを多用する分析基盤ほど、コスト予測がしやすくなります。
ノード仕様は用途に応じて2種類が用意されています。
- RG.xlarge は 4 vCPU と 32 GiB メモリを備え、小〜中規模のワークロードに適します。
- RG.4xlarge は 16 vCPU と 128 GiB メモリを備え、大規模な並列処理や高い同時実行に向きます。
ノード数のレンジには注意が必要です。クラスター作成時に指定できるのは RG.xlarge が最大16ノード、RG.4xlarge が最大32ノードまでです。これに対し、Elastic Resize による拡張ではそれぞれ最大32ノード、最大64ノードまで到達できます。作成時の上限と拡張時の上限を混同しないようにしてください。ストレージは RA3 と同様に大容量のマネージドストレージを利用でき、コンピュートとは独立してスケールします。
3つの移行戦略の全体像と選択基準
RA3 から RG への移行手段は大きく3つあります。それぞれダウンタイム、エンドポイントの扱い、対応構成が異なりますので、ワークロードの制約に合わせて選びます。
Elastic Resize は第一の選択肢です。平均10〜15分で完了し、リサイズ中は読み取り専用となるものの最小限のダウンタイムで済みます。クラスターエンドポイントが変わらないため接続設定の変更が不要です。ただし対応する構成に制約があり、開始後はキャンセルできません。
Classic Resize はすべてのターゲット構成に対応します。処理はメタデータ移行とデータ再配分の2段階で進み、前段のメタデータ移行がクリティカルパスとなります。データ量2PB未満が条件で、開始前に10時間以内に取得した手動スナップショットが必須です。実行にはクラスターが VPC 内にあることが求められます。RG への移行文脈では、いったん開始すると Classic Resize はキャンセルできませんので、事前検証を丁寧に行ってください。
Snapshot/Restore はスナップショットから新しい RG クラスターを起動する方式です。新しいエンドポイントが作成されるため接続文字列の変更が必要になりますが、リージョンやアベイラビリティーゾーンを跨いだ移行が可能で、既存クラスターに影響を与えずに新構成を検証できます。移行中もほぼ常時書き込みを継続したい場合に有効です。
観点 | Elastic Resize | Classic Resize | Snapshot/Restore |
|---|---|---|---|
所要時間の目安 | 平均10〜15分 | データ量に依存し長め | 復元時間に依存 |
エンドポイント | 不変 | 不変 | 新規（変更必須） |
対応構成 | 制約あり | 全構成 | 全構成 |
キャンセル | 不可 | 不可（RG移行時） | 元クラスターは無停止 |
向くケース | 短時間・接続維持 | 大幅な再構成 | リージョン跨ぎ・検証 |
選択の基本は、対応構成に収まるなら Elastic Resize、全構成対応やスライス再配分が必要なら Classic Resize、無停止での検証やリージョン跨ぎが要件なら Snapshot/Restore という順で検討することです。
移行前の準備とノードマッピングの考え方
移行を始める前に前提条件を確認します。稼働中の RA3 クラスターに対し、リサイズを実行する IAM 権限（ResizeCluster と DescribeClusters 相当）を用意します。CLI を使う場合は AWS CLI を準備し、Classic Resize では10時間以内の手動スナップショットを取得しておきます。いずれの方式でもターゲット構成に十分なストレージがあることを確認してください。
ノードマッピングの初期指針
ノードタイプの対応づけには初期指針があります。RA3.xlplus は RG.xlarge へ1対1を目安に、RA3.4xlarge は RG.4xlarge へ対応させます。これはあくまで出発点であり、実際のノード数やタイプは下位環境で代表的なワークロードを流して調整します。
クエリの並列度が高い、同時実行が多い、あるいは大きなソート・集計を伴うワークロードでは、ノード数を増やすよりも RG.4xlarge のような大きいノードタイプを選ぶ方が効率的なことがあります。逆に軽量なワークロードでは RG.xlarge で十分な場合もあります。
検証には Amazon Redshift Test Drive の活用が有効です。本番相当のクエリを異なる構成に対して再生し、性能とコストを比較したうえで最終的なノード構成を決めると、移行後の想定外を減らせます。
実際の移行手順 コンソールとAWS CLI
Elastic Resize はマネジメントコンソールから実行できます。対象クラスターを開き、リサイズ操作からノードタイプに RG を選び、ノード数を指定して Elastic Resize を選択します。確認後に実行すると読み取り専用の状態で処理が進み、完了するとエンドポイントを変えずに RG 構成へ切り替わります。
AWS CLI ではリサイズコマンドを使います。Elastic Resize はデフォルトのため --no-classic を指定します。
aws redshift resize-cluster --cluster-identifier my-ra3-cluster --node-type rg.4xlarge --number-of-nodes 6 --no-classicClassic Resize を行う場合は同じコマンドで --classic を指定します。全構成対応が必要なときや大幅な再配分を伴うときに使います。
aws redshift resize-cluster --cluster-identifier my-ra3-cluster --node-type rg.4xlarge --number-of-nodes 6 --classicSnapshot/Restore では、まず対象クラスターの手動スナップショットを取得し、そのスナップショットから RG のノードタイプを指定して新しいクラスターを復元します。復元後は検証が重要です。主要テーブルの行数が一致するか、スキーマとオブジェクトが揃っているか、ユーザーやロールの権限が正しく引き継がれているかを確認します。問題がなければアプリケーションや BI・ETL の接続文字列を新しいエンドポイントに更新し、旧クラスターは動作確認後に停止します。
移行後のコスト最適化と連携サービスの注意点
移行が完了したら、コストの無駄を残さないよう後片付けを行います。検証に使ったテストクラスターや、移行のために作成した手動スナップショットは不要になった時点で削除します。RG では vCPU あたりの価格が30%低いため、同じ処理をより低コストで運用できる状態になっており、余分なリソースを整理することで効果を最大化できます。
連携サービスの挙動は移行方式によって変わります。Elastic Resize や Classic Resize のようにエンドポイントが変わらないケースでは、リサイズ中の各サービスは次のように振る舞います。
- Zero-ETL 統合 はリサイズ中は一時的に利用できず resync 状態となり、完了後に同期が再開します。
- AWS DMS の CDC は影響を受けず、再起動も不要です。
- データ共有 のプロデューサー側は数分間だけ一時停止し、完了後に自動で再開します。
一方、Snapshot/Restore では新しいクラスターとして名前空間が変わるため、これらの連携はそのまま引き継がれません。Zero-ETL は新しい統合として作成し初回同期を行い、DMS は新しいエンドポイントに更新して再構成し、データ共有も新しい名前空間に対して設定し直す必要があります。移行方式を選ぶ段階で、連携サービスの再構成コストも含めて判断してください。
最後に、RG への移行後も安心できるよう、同じ移行手法を使えばいつでも RA3 へ戻せるフォールバックが可能です。まずは下位環境と代表ワークロードで十分に検証し、下流の通知とメンテナンスウィンドウの調整を行ったうえで本番移行に臨むことをおすすめします。段階を踏めば、性能とコストの両面で RG のメリットを安全に享受できます。
