Amazon Redshift のモダナイゼーション: RA3 から RG への移行ベストプラクティス

本記事は 2026 年 6 月 16 日 に公開された「Modernize Amazon Redshift: RA3 to RG Migration best practices」を翻訳したものです。

Amazon Redshift は、フルマネージドで AI を活用したクラウドデータウェアハウスです。数万のお客様がエクサバイト規模のデータを業界最高水準のコストパフォーマンスで分析しています。Amazon Redshift は Amazon SageMaker Unified Studio でレイクハウス全体にわたる SQL 分析を提供し、複数のソースからのデータを統合します。Zero-ETL 統合により、ストリーミング、データベース、エンタープライズアプリケーションを接続して複雑なパイプラインを排除し、ほぼリアルタイムのインサイトを得られます。

2026 年 5 月 12 日、Amazon Redshift はプロビジョンドノードの新世代である Graviton ベースの RG インスタンスをリリースしました。RG インスタンスは、RA3 インスタンスと比較して、データウェアハウスワークロードで最大 2.2 倍、データレイクワークロードで最大 2.4 倍高速で、vCPU あたりの価格は 30% 低くなっています。RG インスタンスは RA3 がサポートするすべてのデータレイクフォーマットをサポートし、Amazon Redshift Spectrum の TB あたりのスキャン料金が不要になります。

本記事では、Amazon Redshift RA3 クラスターを Graviton ベースの RG インスタンスに移行する方法を説明します。Elastic Resize、Classic Resize、Snapshot/Restore の 3 つの移行戦略を比較し、スムーズな移行に向けた考慮事項とベストプラクティスを紹介します。また、RA3 から RG へのノードマッピングガイダンスも紹介します。

RG への移行対象

すべての RA3 のお客様に、コストパフォーマンスを最大化するため RG への移行を推奨します。RG は RA3 と比較して、コンピューティング集約型と I/O 集約型の両方のワークロードでパフォーマンスが向上するよう設計されており、ワークロードパターンを問わず性能向上が期待できます。Amazon Redshift Graviton RG インスタンスは前世代の RA3 インスタンスと機能パリティを維持しており、機能を失わず移行できます。

RG ノードタイプ

RG インスタンスファミリーには現在 2 つのノードタイプがあります。次の表に RG インスタンスタイプ、ハードウェア仕様、対応する RA3 ノードタイプを示します。RA3 からの移行時のサイジング判断に活用してください。

注意: 今後、Amazon Redshift ワークロードに最適なコストパフォーマンスを提供するため、追加のインスタンスタイプのサポートを拡大する予定です。

インスタンスタイプの詳細については、Amazon Redshift のドキュメントを参照してください。

RA3 から RG へのノードマッピング

注意: これらは初期の推奨値です。ワークロードによっては、ターゲット RG ノード構成の調整が必要です。ターゲット構成を確定する前に、下位環境でワークロードをテストしてパフォーマンスを検証してください。本番ワークロード全体をテストするには、Amazon Redshift Test Drive ユーティリティも使用できます。

マッピングの考慮事項: RG ファミリー内では、RG.4xlarge 1 ノードは RG.xlarge 4 ノードに相当します。

RG ノードタイプの選択: Amazon Redshift クラスターのサイジングでは、少数の大きなノードと多数の小さなノードのどちらを使うかが重要な判断ポイントです。RG ノードタイプ間の主な差別化要因はローカル SSD キャッシュ容量です。大きなノードはノードあたりのローカルキャッシュが多く、マネージドストレージからのデータ読み込みが減り、I/O 集約型クエリの性能が向上します。

次のようなワークロードでは、大きなノードタイプを検討してください:

• 大量のディスクスピル – メモリを超える中間結果セットが生じる複雑なクエリ。
• リーダーノード負荷の高い処理 – 多数の同時クライアント接続、多数の結合やサブクエリを含む複雑なクエリコンパイル、または負荷の大きい最終段階の集約処理。
• 大量の頻繁にアクセスされるデータ – ローカル SSD キャッシュの活用でマネージドストレージからの読み込みを抑えたいホットデータセット。
• 大きな結果セット – クライアントアプリケーションに大量のデータを返すクエリ。
• 頻繁なメタデータ操作 – カタログルックアップの多いワークロードや、多数の小バッチでの CURSOR ベースのフェッチ。

前提条件

本記事の手順には、以下が必要です。

• RA3 ノードタイプで稼働中の Amazon Redshift クラスター。
• リサイズ操作に必要な AWS Identity and Access Management (IAM) アクセス許可（redshift:ResizeCluster、redshift:DescribeClusters）。
• AWS CLI のインストールと設定（CLI ベースの移行の場合）。
• Classic Resize を使用する場合、10 時間以内の最新の手動スナップショット。
• 既存データに対するターゲット RG 構成の十分なストレージ容量。

移行方法

次の図は、3 つの移行アプローチを比較したものです。

1. Elastic Resize（推奨）

Elastic Resize は、ターゲットの RG ノード構成が Elastic Resize のサポート範囲内にある場合に、ノードアップグレードの推奨方法です。ノードタイプの変更（例: RA3 から RG）やノードの追加・削除に使用できます。

Elastic Resize を実行すると、Amazon Redshift はまずソースクラスターのスナップショットを作成します。スナップショットの最新データを使用して新しいターゲットクラスターがプロビジョニングされ、バックグラウンドでデータが新しいクラスターに転送されます。この間、データは読み取り専用になります。リサイズが完了に近づくと、Amazon Redshift はエンドポイントを新しいクラスターに向けて更新し、ソースクラスターへのすべての接続を切断します。障害が発生しても、ほとんどの場合は手動介入なしに自動ロールバックされます。

利点

1. 平均約 10〜15 分で完了します。最初の選択肢として推奨します。
2. リサイズ中もクラスターが読み取り専用で利用できるため、ダウンタイムが最小限です。
3. クラスターエンドポイントが変わらないため、接続文字列の変更が不要です。
4. オンデマンドで実行するか、メンテナンスウィンドウ中にスケジュールできます。

考慮事項

1. プロデューサークラスターでノードタイプを変更する Elastic Resize では、接続が新しいターゲットクラスターに切り替わる間、データ共有が利用できなくなります。
2. ターゲットノード構成に既存データ用の十分なストレージがあることを確認してください。
3. Elastic Resize で対応できないターゲット構成もあります。その場合は Classic Resize または Snapshot/Restore を検討してください。
4. Elastic Resize 操作は開始後にキャンセルできません。
5. データスライスは変更されません。データや CPU のスキューが発生する可能性があります。

Elastic Resize は AWS マネジメントコンソールまたは AWS CLI で開始できます。

コンソールでクラスターをリサイズする手順

1. AWS マネジメントコンソールにサインインします。
2. https://console.aws.amazon.com/redshiftv2/ で Amazon Redshift コンソールを開きます。
3. 左側のナビゲーションメニューで Provisioned clusters を選択します。
4. リサイズするクラスターを選択します。
5. Actions で Resize を選択します。Resize cluster ページが表示されます。
6. Resize cluster ページで、リサイズタイプとして Elastic resize (recommended) を選択します。
7. New configuration で、ノードタイプ（例: rg.4xlarge）を選択します。
8. ノード数を入力します。
9. 選択内容に応じて、Resize now または Schedule resize を選択します。

AWS CLI でクラスターをリサイズする手順

# Initiate an Elastic Resize to upgrade from RA3 to RG node type
aws redshift resize-cluster \
    --cluster-identifier <my-RA3-cluster> \  # Source cluster ID
    --node-type rg.4xlarge \                 # Target RG node type
    --number-of-nodes <#nodes> \             # Target node count
    --no-classic                            # false = Elastic Resize

2. Classic Resize

Classic Resize は、クラスターサイズやノードタイプの変更が Elastic Resize でサポートされていない場合に推奨されます。シングルノードからマルチノードへの変換にも必要です。

Classic Resize を実行すると、Amazon Redshift はターゲットクラスターを作成し、バックアップとリストアでソースクラスターからデータとメタデータを移行します。データベーススキーマやユーザー設定を含むすべてのデータが正確に転送されます。ソースクラスターは最初に再起動され、数分間利用できなくなります。その後、クラスターは読み書き可能な状態になり、リサイズはバックグラウンドで続行されます。

Enhanced Classic Resize は 2 つのステージで構成されます:

1. ステージ 1（クリティカルパス）: ソースクラスターからターゲットクラスターへのメタデータの移行。このステージ中、ソースクラスターは読み取り専用モードになります。通常、非常に短い時間です。その後、クラスターは読み取りと書き込みクエリで利用可能になります。KEY ディストリビューションスタイルのすべてのテーブルは一時的に EVEN ディストリビューションで保存され、ステージ 2 で KEY スタイルに再配分されます。
2. ステージ 2（オフクリティカルパス）: 以前のディストリビューションスタイルに従ったデータの再配分。バックグラウンドで実行されます。所要時間はデータ量、クラスターワークロード、ノードタイプによって異なります。

詳細については、「Accelerate resizing of Amazon Redshift clusters with enhancements to classic resize」を参照してください。

利点

1. すべてのターゲットノード構成をサポートします。
2. ソースクラスターを柔軟に再構成できます。
3. データスライスをノードあたりのデフォルトにリバランスし、ノード間で均等なデータ分散を実現します。

考慮事項

1. ソースクラスターのデータサイズが 2 PB 未満である必要があります。2 PB を超えるデータには Snapshot/Restore アプローチを使用してください。
2. 開始前に 10 時間以内の手動スナップショットがあることを確認し、なければ新たに取得してください。
3. Classic Resize に使用されたスナップショットは、テーブルリストアやその他の目的には使用できません。
4. クラスターは Virtual Private Cloud (VPC) 内にある必要があります。
5. リサイズ中はクエリの完了に時間がかかる場合があります。Concurrency Scaling の有効化を検討してください。
6. Classic Resize の前に不要なテーブルを削除すると、データ分散が高速化されます。
7. Classic Resize は Elastic Resize よりも完了までに時間がかかります。
8. リサイズ操作をオフピーク時間帯またはメンテナンスウィンドウ中にスケジュールしてください。

Classic Resize はコンソールまたは次の AWS CLI コマンドで開始できます。

コンソールで Classic Resize を実行するには、前述のリサイズ手順で次のスクリーンショットのように Classic resize を選択します。

AWS CLI による Classic Resize

# Initiate Classic Resize via AWS CLI
aws redshift resize-cluster \
    --cluster-identifier <my-ra3-cluster> \  # Source cluster ID
    --node-type rg.4xlarge \                 # Target RG node type
    --number-of-nodes <#nodes> \             # Target node count
    --classic                                # true = Classic Resize

プロビジョンドクラスターの Classic Resize（KEY ディストリビューションを含む）の進捗を監視するには、SYS_RESTORE_STATE を使用します。変換中のテーブルの完了パーセンテージが表示されます。アクセスにはスーパーユーザー権限が必要です。

Elastic Resize と Classic Resize の比較

3. Snapshot, Restore, Resize

移行中もほぼ常時書き込みアクセスが必要な場合や、既存クラスターに影響を与えず新しい RG セットアップを検証したい場合に使用します。

手順

1. Amazon Redshift コンソールで Provisioned clusters dashboard を選択し、ソースクラスターを選択して Actions から Create manual snapshot を選択します。スナップショット名を指定して Create snapshot を選択します。
2. スナップショットを選択します。
3. Restore from snapshot を選択します。
4. クラスター ID と構成（ターゲットクラスター）を指定します。
5. 次の手順でターゲットクラスターにデータが存在することを確認します:
   1. 新しいエンドポイントを使用してターゲットクラスターに接続します。
   2. 主要なテーブルに対して SELECT COUNT(*) FROM <table_name> を実行し、ソースクラスターとカウントを比較します。
   3. すべてのスキーマが存在することを確認します。
   4. ユーザー権限が正しくリストアされたことを検証します。
6. スナップショット取得後にソースクラスターにデータを書き込んだ場合は、手動でターゲットクラスターにデータをコピーします。
7. アプリケーションの接続文字列を新しいクラスターエンドポイントに更新します。

利点

1. 既存クラスターに影響を与えずに新しい RG セットアップを検証できます。
2. 異なるリージョンやアベイラビリティーゾーンへのリストアが柔軟に行え、追加の災害復旧オプションを提供します。
3. クラスターが書き込み操作で利用できない時間を最小限に抑えます。

考慮事項

1. クラスターのセットアップとデータリストアは Elastic Resize より時間がかかることがあります。
2. スナップショット後にソースクラスターへ書き込まれたデータは、手動でターゲットにコピーが必要です。
3. 新しいエンドポイントが作成されるため、接続文字列の変更が必要です。
4. エンドポイントを維持するには、ターゲットクラスターがソースクラスターと同じ名前になるように両方のクラスターの名前を変更することを検討してください。

フォールバック

同じ移行アプローチでいつでも RA3 に戻せます。

移行時の DMS、Zero-ETL、データ共有に関する考慮事項

Amazon Redshift クラスターが AWS Database Migration Service (AWS DMS) のターゲット、Zero-ETL 統合のターゲット、またはデータ共有のプロデューサーとして使用されている場合、RA3 から RG へのリサイズ時に以下の点に留意してください。

AWS DMS の変更データキャプチャ (CDC) タスクはリサイズの影響を受けません。レプリケーションインスタンスは独立して動作し、クラスター復帰後に書き込みを再開します。タスクの再起動は不要です。

Zero-ETL テーブルはリサイズ中に一時的に利用できなくなり、再同期状態になります。再同期にかかる時間はデータ量に依存します。svv_integration_table_state を使用して、すべてのテーブルが Synced に戻ったことを確認してください。詳細については、「Zero-ETL considerations」を参照してください。

プロデューサークラスターをリサイズすると、接続が新しいクラスターに転送される間、データ共有が一時的に利用できなくなります。通常、数分間です。この間、コンシューマークラスターは共有データにアクセスできません。リサイズ完了後、データ共有は再設定不要で自動的に再開します。リサイズ対象のプロデューサーに依存するコンシューマーワークロードには、短いメンテナンスウィンドウを計画してください。

Snapshot/Restore が DMS、Zero-ETL、データ共有に与える影響

Zero-ETL 統合は元のクラスターに紐づいています。リストア先は新しいクラスターとして扱われるため、レプリケーションは自動再開されません。リストア後、新しいクラスターを指す Zero-ETL 統合を再作成する必要があります。初回同期が実行され、データが最新の状態になります。

AWS DMS 接続はエンドポイントベースです。リストア先は新しいエンドポイントになるため、AWS DMS タスクは自動接続しません。リストア後、AWS DMS エンドポイント設定を新しいアドレスに更新し、タスクを再起動してください。

データ共有はクラスターの名前空間に紐づいています。リストア先は異なる名前空間になるため、既存のデータ共有は引き継がれません。プロデューサー側は、新しいデータ共有を作成してコンシューマーと再共有する必要があります。コンシューマー側は、プロデューサーが新しいクラスターから共有を再確立するまでアクセスできません。

移行のベストプラクティス

1. 移行前に、データ共有のコンシューマー、Zero-ETL アプリケーション、BI/ETL パイプラインなど下流チームに通知してください。
2. 本番環境への影響を軽減するため、メンテナンスウィンドウ中に移行をスケジュールしてください。
3. リサイズ開始前に手動スナップショットを取得し、ロールバックポイントとして確保してください。
4. 本番環境を移行する前に、代表的なワークロードでターゲットの RG 構成をテストしてください。
5. 完了後に下流のアプリケーションが正常に動作していることを確認してください。

クリーンアップ

不要な課金を防ぐため、テスト用の RG クラスターと移行テスト中に作成した手動スナップショットを削除してください。クラスター削除時はすべてのデータが完全に消去されます。テストクラスターのみを削除していることを確認してください。テストデータを保持する必要がある場合は、削除前に最終スナップショットの取得を検討してください。

まとめ

本記事では、Amazon Redshift RA3 インスタンスから Graviton ベースの RG インスタンスへのアップグレードに関する移行オプション、考慮事項、ベストプラクティスを説明しました。RG のパフォーマンス上のメリットの詳細については、発表ブログ記事を参照してください。

本記事のガイダンスを参考に、今すぐ Amazon Redshift RG インスタンスへのアップグレードを開始して、コストパフォーマンスの向上を活用してください。アーキテクチャのサポートや概念実証 (POC) の支援については、AWS Support にお問い合わせください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。