本記事は 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 からの移行時のサイジング判断に活用してください。 ノードタイプ 構成 vCPU メモリ 最大ストレージ/ノード ノード範囲 ステータス RA3 相当 RG.xlarge マルチノード 4 32 GB 16 TB 2-32 GA (05/12/2026) RA3.xlplus と直接対応 RG.4xlarge マルチノードのみ 16 128 GB 128 TB 2-64 GA (05/12/2026) RA3.4xlarge と比較して vCPU とメモリが 1.33 倍 注意 : 今後、Amazon Redshift ワークロードに最適なコストパフォーマンスを提供するため、追加のインスタンスタイプのサポートを拡大する予定です。 インスタンスタイプの詳細については、 Amazon Redshift のドキュメント を参照してください。 RA3 から RG へのノードマッピング 現在のノードタイプ ノード範囲 推奨 RG タイプ 推奨 RG ノード数 RA3.xlplus 1-32 RG.xlarge 1:1 マッピング（同じノード数） RA3.4xlarge 2 RG.4xlarge RA3.4xl 2 ノードに対して RG.4xl 2 ノード RA3.4xlarge 3-64 RG.4xlarge RA3.4xl 4 ノードに対して RG 3 ノード（偶数に切り上げ） 注意 : これらは初期の推奨値です。ワークロードによっては、ターゲット 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 はエンドポイントを新しいクラスターに向けて更新し、ソースクラスターへのすべての接続を切断します。障害が発生しても、ほとんどの場合は手動介入なしに自動ロールバックされます。 利点 平均約 10〜15 分で完了します。最初の選択肢として推奨します。 リサイズ中もクラスターが読み取り専用で利用できるため、ダウンタイムが最小限です。 クラスターエンドポイントが変わらないため、接続文字列の変更が不要です。 オンデマンドで実行するか、メンテナンスウィンドウ中にスケジュールできます。 考慮事項 プロデューサークラスターでノードタイプを変更する Elastic Resize では、接続が新しいターゲットクラスターに切り替わる間、データ共有が利用できなくなります。 ターゲットノード構成に既存データ用の十分なストレージがあることを確認してください。 Elastic Resize で対応できないターゲット構成もあります。その場合は Classic Resize または Snapshot/Restore を検討してください。 Elastic Resize 操作は開始後にキャンセルできません。 データスライスは変更されません。データや CPU のスキューが発生する可能性があります。 Elastic Resize は AWS マネジメントコンソールまたは AWS CLI で開始できます。 コンソールでクラスターをリサイズする手順 AWS マネジメントコンソールにサインインします。 https://console.aws.amazon.com/redshiftv2/ で Amazon Redshift コンソールを開きます。 左側のナビゲーションメニューで Provisioned clusters を選択します。 リサイズするクラスターを選択します。 Actions で Resize を選択します。 Resize cluster ページが表示されます。 Resize cluster ページで、リサイズタイプとして Elastic resize (recommended) を選択します。 New configuration で、ノードタイプ（例: rg.4xlarge ）を選択します。 ノード数を入力します。 選択内容に応じて、 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（クリティカルパス）: ソースクラスターからターゲットクラスターへのメタデータの移行。このステージ中、ソースクラスターは読み取り専用モードになります。通常、非常に短い時間です。その後、クラスターは読み取りと書き込みクエリで利用可能になります。KEY ディストリビューションスタイルのすべてのテーブルは一時的に EVEN ディストリビューションで保存され、ステージ 2 で KEY スタイルに再配分されます。 ステージ 2（オフクリティカルパス）: 以前のディストリビューションスタイルに従ったデータの再配分。バックグラウンドで実行されます。所要時間はデータ量、クラスターワークロード、ノードタイプによって異なります。 詳細については、「 Accelerate resizing of Amazon Redshift clusters with enhancements to classic resize 」を参照してください。 利点 すべてのターゲットノード構成をサポートします。 ソースクラスターを柔軟に再構成できます。 データスライスをノードあたりのデフォルトにリバランスし、ノード間で均等なデータ分散を実現します。 考慮事項 ソースクラスターのデータサイズが 2 PB 未満である必要があります。2 PB を超えるデータには Snapshot/Restore アプローチを使用してください。 開始前に 10 時間以内の手動スナップショットがあることを確認し、なければ新たに取得してください。 Classic Resize に使用されたスナップショットは、テーブルリストアやその他の目的には使用できません。 クラスターは Virtual Private Cloud (VPC) 内にある必要があります。 リサイズ中はクエリの完了に時間がかかる場合があります。Concurrency Scaling の有効化を検討してください。 Classic Resize の前に不要なテーブルを削除すると、データ分散が高速化されます。 Classic Resize は Elastic Resize よりも完了までに時間がかかります。 リサイズ操作をオフピーク時間帯またはメンテナンスウィンドウ中にスケジュールしてください。 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 の比較 動作 Elastic Resize Classic Resize システムテーブル Elastic Resize はシステムログデータを保持します。 Classic Resize はシステムテーブルとデータを保持しません。 ノードタイプの変更 ノードタイプが変わらない場合、Elastic Resize はインプレースリサイズとなり、ほとんどのクエリは保持されます。新しいノードタイプを選択した場合、新しいクラスターが作成され、リサイズ完了時にクエリが切断されます。 新しいクラスターが作成されます。リサイズ中にクエリが切断されます。 セッションとクエリの保持 Elastic Resize は、ソースとターゲットのノードタイプが同じ場合、セッションとクエリを保持します。新しいノードタイプを選択した場合、クエリは切断されます。 Classic Resize はセッションとクエリを保持しません。クエリが切断され、パフォーマンスの低下が予想されます。使用量の少ない時間帯にリサイズを実行してください。 リサイズ操作のキャンセル Elastic Resize はキャンセルできません。 RG または RA3 クラスターへの Classic Resize はキャンセルできません。 3. Snapshot, Restore, Resize 移行中もほぼ常時書き込みアクセスが必要な場合や、既存クラスターに影響を与えず新しい RG セットアップを検証したい場合に使用します。 手順 Amazon Redshift コンソールで Provisioned clusters dashboard を選択し、ソースクラスターを選択して Actions から Create manual snapshot を選択します。スナップショット名を指定して Create snapshot を選択します。 スナップショットを選択します。 Restore from snapshot を選択します。 クラスター ID と構成（ターゲットクラスター）を指定します。 次の手順でターゲットクラスターにデータが存在することを確認します: 新しいエンドポイントを使用してターゲットクラスターに接続します。 主要なテーブルに対して SELECT COUNT(*) FROM <table_name> を実行し、ソースクラスターとカウントを比較します。 すべてのスキーマが存在することを確認します。 ユーザー権限が正しくリストアされたことを検証します。 スナップショット取得後にソースクラスターにデータを書き込んだ場合は、手動でターゲットクラスターにデータをコピーします。 アプリケーションの接続文字列を新しいクラスターエンドポイントに更新します。 利点 既存クラスターに影響を与えずに新しい RG セットアップを検証できます。 異なるリージョンやアベイラビリティーゾーンへのリストアが柔軟に行え、追加の災害復旧オプションを提供します。 クラスターが書き込み操作で利用できない時間を最小限に抑えます。 考慮事項 クラスターのセットアップとデータリストアは Elastic Resize より時間がかかることがあります。 スナップショット後にソースクラスターへ書き込まれたデータは、手動でターゲットにコピーが必要です。 新しいエンドポイントが作成されるため、接続文字列の変更が必要です。 エンドポイントを維持するには、ターゲットクラスターがソースクラスターと同じ名前になるように 両方のクラスターの名前を変更する ことを検討してください。 フォールバック 同じ移行アプローチでいつでも 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 エンドポイント設定を新しいアドレスに更新し、タスクを再起動してください。 データ共有はクラスターの名前空間に紐づいています。リストア先は異なる名前空間になるため、既存のデータ共有は引き継がれません。プロデューサー側は、新しいデータ共有を作成してコンシューマーと再共有する必要があります。コンシューマー側は、プロデューサーが新しいクラスターから共有を再確立するまでアクセスできません。 移行のベストプラクティス 移行前に、データ共有のコンシューマー、Zero-ETL アプリケーション、BI/ETL パイプラインなど下流チームに通知してください。 本番環境への影響を軽減するため、メンテナンスウィンドウ中に移行をスケジュールしてください。 リサイズ開始前に手動スナップショットを取得し、ロールバックポイントとして確保してください。 本番環境を移行する前に、代表的なワークロードでターゲットの RG 構成をテストしてください。 完了後に下流のアプリケーションが正常に動作していることを確認してください。 クリーンアップ 不要な課金を防ぐため、テスト用の RG クラスターと移行テスト中に作成した手動スナップショットを削除してください。クラスター削除時はすべてのデータが完全に消去されます。テストクラスターのみを削除していることを確認してください。テストデータを保持する必要がある場合は、削除前に最終スナップショットの取得を検討してください。 まとめ 本記事では、Amazon Redshift RA3 インスタンスから Graviton ベースの RG インスタンスへのアップグレードに関する移行オプション、考慮事項、ベストプラクティスを説明しました。RG のパフォーマンス上のメリットの詳細については、 発表ブログ記事 を参照してください。 本記事のガイダンスを参考に、今すぐ Amazon Redshift RG インスタンス へのアップグレードを開始して、コストパフォーマンスの向上を活用してください。アーキテクチャのサポートや概念実証 (POC) の支援については、 AWS Support にお問い合わせください。 著者について Nita Shah Nita は AWS のシニアアナリティクススペシャリストソリューションアーキテクトで、ニューヨークを拠点としています。20 年以上にわたりエンタープライズデータプラットフォーム、データウェアハウジング、アナリティクスソリューションの構築に携わり、Amazon Redshift を専門としています。エンタープライズ規模の Well-Architected なアナリティクスおよび意思決定支援プラットフォームの設計・構築を支援しています。 Ankit Sahu Ankit は革新的なデータ製品とサービスの構築において 18 年以上の経験を持ちます。プロダクト戦略、Go-to-Market の実行、デジタルトランスフォーメーションなど多様な経験があります。現在は AWS のシニアプロダクトマネージャーとして、Amazon Redshift のビジョンと戦略を推進しています。 Vinayaka Gangadhar Vinayaka は Amazon Web Services（AWS）のアナリティクススペシャリストです。スケーラブルなデータプラットフォームの構築・トラブルシューティングや、AWS の分析サービスを活用した有意義なインサイトの導出を通じてお客様を支援しています。Amazon Redshift とAmazon OpenSearch に深い専門知識を持っています。複雑な分析課題に取り組んでいないときは、新しいテクノロジーの探求や家族との時間を楽しんでいます。 Ricardo Serafim Ricardo は AWS のシニアアナリティクススペシャリスト Solutions Architect です。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 7 月 2 日 に公開された「 Amazon Redshift RG: Faster and lower cost, Graviton-powered 」を翻訳したものです。 Amazon Redshift は、Graviton プロセッサを搭載した新しいインスタンス RG の一般提供を開始しました。Amazon 独自の Graviton プロセッサ上に構築された RG は、以下を実現します。 データウェアハウスワークロードで RA3 と比較して最大 2.2 倍高速なパフォーマンス 統合されたベクトル化データレイクエンジンにより、Iceberg クエリで最大 2.4 倍、Parquet クエリで 1.5 倍高速 データレイククエリに対する TB あたりのスキャン料金が不要。RA3 クラスターに適用されていた Amazon Redshift Spectrum のコストを排除 RA3 と比較して vCPU あたりのコストが 30% 低減 RG はより高速かつ低コストです。一般的にクラウドベンダーは高速なパフォーマンスや新世代ハードウェアに対してより高い料金を設定しますが、Amazon Redshift はより高いパフォーマンスをより低いコストで提供します。 本記事では、RG インスタンスが高速な理由を説明します。また、RG が他の主要データウェアハウスと比較して最大 4.2 倍優れたプライスパフォーマンスを実現するベンチマーク結果も紹介します。 RG が高速な理由 新しい RG インスタンスは、Graviton プロセッサの性能を最大限に活用するためにゼロから設計されています。Amazon Redshift のベクトル化エンジンは Graviton ベースの SIMD (Single Instruction, Multiple Data) カーネルで最適化されており、分析ワークロードに対して高速で並列化された実行を実現します。Parquet エンコーディングに対する述語評価などの操作では、Graviton のベクトル比較、テーブルルックアップ、ベクトル操作のインストリンシクス（組み込み命令）を活用しています。処理速度の向上を支えるため、RG インスタンスはカスタムビルドの Nitro SSD を使用します。高速なローカルストレージをキャッシュレイヤーとして活用し、 Amazon Redshift Managed Storage (RMS) やデータレイクスキャン、メモリに収まらない計算の中間結果セットに対応します。また、RG の JIT (Just-In-Time) Analyze 機能は、クエリの実行中にデータレイクファイルの統計情報を自動的に収集・保存するため、オプティマイザが大幅に優れたクエリプランを生成できます。ハードウェアアクセラレーション (Graviton)、ベクトル化実行 (SIMD カーネル)、高速ストレージ (Nitro SSD)、適切なクエリプランニング (JIT Analyze) と、スタック全体で最適化を実現しています。 上記の最適化と、RG 専用に構築された高性能ベクトル化データレイクエンジンの組み合わせにより、Amazon Redshift の RG インスタンスは分析ワークロードで RA3 と比較して最大 2.2 倍高速に動作し、コストも 30% 低く抑えられます。 専用の高性能ベクトル化データレイクエンジン RA3 では、データレイククエリのスキャンを Amazon Redshift Spectrum と呼ばれる別のコンピュートフリートにオフロードしていました。データレイククエリが別のコンピュートで実行されるため、RA3 クラスターと Spectrum フリート間でクエリメタデータや結果を転送する際に追加の負荷が発生していました。Amazon Redshift RG インスタンスには、データレイク向けにゼロから設計された、まったく新しい組み込みスキャンレイヤーが含まれています。新しいスキャンレイヤーには、データレイテンシーを削減するスマートプリフェッチ機能を組み込んだ専用 I/O サブシステムが含まれます。また、Iceberg で最も一般的に使用されるファイル形式である Apache Parquet の処理に最適化されており、Graviton 向けに最適化された SIMD カーネルによる高速なベクトル化スキャンを実行します。スキャンレイヤーには、パーティションレベルとファイルレベルの両方で動作する高度なデータプルーニングメカニズムが含まれており、スキャンが必要なデータ量を大幅に削減します。プルーニング機能はスマートプリフェッチシステムと連携して動作し、データ取得プロセス全体の効率を最大化します。 新しい専用ベクトル化データレイクエンジンは、Iceberg クエリで RA3 と比較して最大 2.4 倍、Parquet クエリで 1.5 倍高速です。 新しいベクトル化データレイクエンジンは Amazon Redshift のコア実行エンジンに直接統合されているため、RA3 と比較して新たなパフォーマンス最適化が可能です。この統合アーキテクチャにより、RG でのデータレイククエリは高速なローカルデータキャッシュ、改良されたブルームフィルタ、ベクトル化 Parquet スキャン、高度なフィルタリングとプルーニングの恩恵を受けられます。 RG は、データレイクのクエリでお客様が直面する一般的な問題も解決します。Amazon Simple Storage Service (Amazon S3) 上の Iceberg などのオープンフォーマットファイルには有用なメタデータや統計情報が不足していることが多く、SQL クエリを最適に実行することが困難でした。 統計情報とは、個別値の数、最小値/最大値、分布パターン、行数などのデータに関するメタデータです。クエリオプティマイザはこの情報を使用して、クエリの最も効率的な実行方法を選択します。たとえば、2 つのテーブルを結合する際、オプティマイザは適切な結合戦略を選択するために各側が生成する一意の値の数を把握する必要があります。統計情報がなければ推測に頼ることになり、多くの場合、結合が遅くなりノード間で不要なデータ移動が発生します。ここで Amazon Redshift の新機能 JIT (Just-In-Time) Analyze が役立ちます。RG インスタンスはクエリの実行中に Iceberg ファイルの統計情報を自動的に取得・保存するため、Amazon Redshift は統計情報がない場合と比較してはるかに最適化されたクエリ実行戦略を選択できます。 Iceberg や Parquet データのスキャンが RA3 よりも大幅に高速になります。Amazon Redshift Spectrum のコンピュートが不要になったことで、RG インスタンスではデータレイククエリの $5/TB のコストも排除されます。データレイククエリがより安価になり、コストの予測も容易になります。パフォーマンスの向上、コンピュートコストの低減、TB あたりのスキャンコストの撤廃という 3 つのメリットにより、データレイクのプライスパフォーマンスが大幅に改善します。 データロードの高速化によるインサイト取得の迅速化 Amazon Redshift RG の高速 I/O と Graviton 最適化エンジンにより、RA3 と比較してデータロードが高速化されています。パフォーマンス改善を測定するため、同等サイズの RA3 と RG クラスターで 10TB TPC-DS および TPC-H のデータ取り込みステップを実行しました。RG は TPC-DS データセットを 2 倍高速に、TPC-H データセットを 1.4 倍高速に取り込みました (次の図を参照)。 新しい Graviton ベースの RG インスタンスは、RA3 インスタンスと比較してデータロードが最大 2.0 倍高速です。ワークロードはより早く最新データを取得でき、ユーザーやエージェントはより迅速に最新のインサイトを得られます。RG でのデータ取り込み高速化は RA3 と比較して 30% 低いコストで実現されており、データロードのプライスパフォーマンスは RA3 インスタンスと比較して最大 2.9 倍です。 お客様の声 Amazon Redshift のお客様は、RG への切り替えによるパフォーマンスとコストのメリットをすでに実感しています。Southwest Airlines と tombola はビジネスクリティカルなワークロードでテストを行い、パフォーマンスの向上とコスト削減を確認しました。 Southwest Airlines 「Amazon Redshift RG インスタンスは、Southwest Airlines に大きなビジネスインパクトをもたらす可能性があります。開発環境での初期テストでは、データウェアハウスワークロードが 50〜60% 高速化し、データレイク分析は 45% 高速化しました。チームはより早くインサイトを得て、運用状況に迅速に対応し、低レイテンシーでデータドリブンな意思決定を行えるようになります。これらの初期結果は期待が持てるもので、本番環境での検証とスケールアップが楽しみです。さらに、TB あたりの Spectrum スキャン料金が不要になり、燃料価格が業界のマージンを圧迫し続ける中、RA3 と比較して 30% のコスト削減を実現しています！」 — Sean Lynch、Vice President, Data and Architecture、Southwest Airlines tombola 「Graviton ベースの Amazon Redshift RG インスタンスは、バッチジョブと分析ジョブの多様なセットで、RA3 と比較して 1.8〜2 倍の書き込みスループットと最大 2.2 倍の読み取り速度を実現しました。同じ時間枠で 40% 多くの処理が可能になりました。ETL サイクルが短縮され、インサイト取得までの時間が加速し、パイプラインによる意思決定のボトルネックがなくなりました。これらの改善により、アナリストやビジネスチームにより新鮮なデータがより早く届くようになりました。さらに魅力的だったのは、パフォーマンス向上と同時にコンピュート費用が 30% 削減されたことです。より少ないコストでより多くを実現するのは稀な成果であり、強調する価値があります。クエリレイテンシーとコストがスケールに伴い複合的に影響する tombola のような大量データを扱うゲーム業界では、今年最もインパクトのあるプラットフォーム決定の一つとなりました。」 — Akshay Srinivasan、Data Engineer、tombola Qoala 「Amazon Redshift クラスターを RA3 から Graviton ベースの RG インスタンスに移行した結果、BI および分析ワークロード全体でクエリ処理時間が 60〜70% 高速化しました。数百万件の保険契約トランザクションを処理する成長中のインシュアテックプラットフォームとして、インサイト取得までの時間短縮は、データチームがダッシュボードやレポートをより早くビジネスに届けられることを意味します。将来の成長に対応するためにより大きなノード構成に移行しましたが、パフォーマンスの向上は追加投資をはるかに上回り、今年最もインパクトのあるインフラストラクチャ決定の一つとなりました。」 — Umar Abdul Aziz、VP of Data、Qoala パフォーマンス結果 RG の実力を確認するため、業界標準の TPC-DS および TPC-H ベンチマークをベースとしたベンチマークを 10TB スケールで、新しい Amazon Redshift RG インスタンスおよび主要な代替データウェアハウスで実行しました。ベンチマークは、アドホック、レポーティング、反復的なオンライン分析処理 (OLAP)、データマイニングなど、さまざまな運用要件と複雑性を持つクエリを実行するよう設計されています。各データウェアハウスをほぼ同じオンデマンドコスト ($32/時間) でサイジングし、特別なチューニングやカスタマイズなしにそのままの状態で 3 回のパワーランを実行しました。結果は以下のチャートのとおりです。 新しい RG インスタンスが大差をつけてリードしています。プライスパフォーマンスが優れているということは、パフォーマンスが高く、 かつ コストが低いことを意味します。 まとめ Amazon Redshift RG インスタンスは次世代の分析エンジンであり、データウェアハウスとデータレイクワークロードに高いパフォーマンスを提供します。RG は RA3 と同じワークロードと機能をすべてサポートしているため、利用開始は簡単です。アップグレードして、より低コストでより高いパフォーマンスを得る方法については、 移行ガイド を参照してください。 ワークロードに最適なプライスパフォーマンスを見つける 本記事で使用したベンチマークは、業界標準の TPC-DS および TPC-H ベンチマークをベースとしており、以下の特徴があります。 TPC-DS および TPC-H のスキーマとデータを変更せずに使用しています。 クエリは公式の TPC-DS および TPC-H キットを使用し、キットのデフォルトのランダムシードで生成されたクエリパラメータで生成されています。デフォルトクエリの SQL ダイアレクトをサポートしていないデータウェアハウスでは、TPC 承認済みのクエリバリエーションを使用しています。 テストには TPC-DS の 99 個の SELECT クエリと TPC-H の 22 個の SELECT クエリが含まれます。メンテナンスとスループットのステップは含まれません。 3 回のパワーランを実行し、各データウェアハウスで最も良い結果を採用しています。 プライスパフォーマンスは、時間あたりのコスト (USD) を 1時間あたり 3,600 秒で割り、ベンチマークの幾何平均 (秒) を掛けて計算します。これはクエリあたりの幾何平均コストに相当します。すべてのデータウェアハウスで最新の公開オンデマンド料金を使用しています。 Cloud Data Warehouse ベンチマークと呼ばれるこのベンチマークの結果は、 GitHub リポジトリ で公開されているスクリプト、クエリ、データを使用して再現できます。本記事で説明したとおり TPC-DS ベンチマークをベースとしていますが、公式仕様に準拠していないため、公開済みの TPC-DS 結果とは比較できません。 著者について Stefan Gromoll Amazon Redshift チームのプリンシパルエンジニアで、Redshift のパフォーマンスを担当しています。プライベートでは料理、4 人の息子たちとの遊び、薪割りを楽しんでいます。 Ankit Sahu データ製品やサービスの構築に 18 年以上の経験を持ち、プロダクト戦略、Go-to-Market 実行、デジタルトランスフォーメーションの幅広い経験があります。現在は Amazon Web Services (AWS) のシニアプロダクトマネージャーとして、Amazon Redshift のビジョンと戦略を推進しています。 Mohammed Alkateb Amazon Redshift のエンジニアリングマネージャーで、クエリ最適化、データレイクアクセス、パフォーマンスエンジニアリング、新しいインスタンスの検証にわたるソフトウェアエンジニア、アプライドサイエンティスト、Amazon Scholar のチームを率いています。Amazon 入社前は Teradata のオプティマイザチームに 12 年以上在籍。バーモント大学で博士号を取得し、主要なデータベースカンファレンスでの論文発表や米国特許を多数保有しています。 Yousuf Hussain Amazon Redshift のシニアソフトウェアエンジニアで、大規模クラウドデータウェアハウスシステムの構築と運用に 11 年の経験があります。分析に情熱を持ち、Amazon Redshift のお客様に高パフォーマンスな体験を提供するためにインスタンス戦略、可用性、信頼性に注力しています。 Nita Shah ニューヨーク拠点の AWS シニアアナリティクススペシャリストソリューションアーキテクトです。20 年以上にわたりエンタープライズデータプラットフォーム、データウェアハウス、分析ソリューションを構築しており、Amazon Redshift を専門としています。エンタープライズ規模の Well-Architected な分析・意思決定支援プラットフォームの設計と構築を支援しています。 Sanket Hase Amazon Redshift チームのエンジニアリングマネージャーで、データレイク分析、ハードウェア・ソフトウェア協調設計、ベクトル化クエリ実行に焦点を当てたクエリ実行チームを率いています。カーネギーメロン大学でコンピューターサイエンス修士号を取得し、データベースシステム分野で複数の米国特許を保有しています。 Jingbo Zhang Amazon Redshift のデータエンジニアで、新しいインスタンスの検証とパフォーマンスバリデーションを担当しています。RG、r8gd、r7gd を含む複数の Graviton ベース Redshift インスタンスファミリーの検証とローンチに貢献し、ベンチマーク、パフォーマンス分析、自動化に注力しています。カーネギーメロン大学でデータアナリティクス修士号を取得しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 6 月 29 日 に公開された「 Amazon Redshift delivers faster performance for BI dashboards and real-time analytics 」を翻訳したものです。 ビジネスインテリジェンス (BI) ダッシュボードとリアルタイム分析は、迅速な意思決定に欠かせないツールです。現代のデータウェアハウスは、複雑で長時間実行される分析クエリに優れるだけでなく、インタラクティブなリアルタイム体験を支える短時間のアドホッククエリにもサブ秒のレスポンスタイムを実現する必要があります。エージェントが大量のデータから新たなインサイトを探索・導出するようになった今、低レイテンシーの要件はさらに重要になっています。朝のダッシュボードで KPI を確認する経営層から、エージェントを使ってデータセットをインタラクティブに探索するデータアナリストまで、クエリが高速かつ安定した応答を返すことへの期待は明確です。 Amazon Redshift はこうしたユースケース向けに長年最適化されてきました。BI やリアルタイム分析ワークロードのクエリパフォーマンスを向上させるため、結果キャッシュ、マテリアライズドビュー、自動ワークロード管理 (AutoWLM) など、多くの機能を導入しています。こうした機能により、数千のお客様がレスポンスの良いダッシュボードやリアルタイムアプリケーションを Amazon Redshift 上に構築してきました。しかし、インタラクティブ分析ではミリ秒単位の差が重要です。ダッシュボードの読み込み高速化と探索的クエリの応答時間短縮に引き続き注力しています。 本日、Amazon Redshift の新しいパフォーマンス最適化を発表します。リアルタイム分析アプリケーションや BI ダッシュボードが生成する低レイテンシー SQL クエリのレスポンスタイムを改善する機能です。SQL クエリの実行準備にかかる時間を短縮することで、クエリレイテンシーが改善されます。クエリの開始が速くなるため、結果もより早く返されます。 最適化の仕組み 今回の改善を理解するために、まず Amazon Redshift の既存のコアパフォーマンス機能であるコード生成について説明します。コード生成は、各 SQL クエリを分析し、クエリ固有の C++ コードを内部的に生成する最適化手法です。生成されたコードはコンパイルされ、利用可能な Amazon Redshift コンピューティングノード全体で並列実行されて結果を返します。コード生成は Amazon Redshift のクエリパフォーマンスの基盤であり、複雑な分析クエリを高い効率で実行します。 コード生成により高いクエリ実行性能を実現する一方で、新しいクエリは初回実行時に一度だけコンパイルの負荷が発生します。Amazon Redshift はすでにコンパイル済みコードをキャッシュしており、 Amazon Redshift フリート内のクエリの 99% 以上がキャッシュされた生成コードで実行され 、コンパイルの負荷は発生しません。まだキャッシュされていないクエリの場合、初回コンパイルの負荷は高速実行クエリ (ミリ秒や 1 桁秒台のクエリなど) で特に顕著で、全体の実行時間に対して大きな割合を占めることがあります。 今回の最適化により、Amazon Redshift はコンパイルの負荷を軽減します。具体的には、Amazon Redshift がクエリを受信すると、まずフリート内で過去に類似クエリを実行した際の最適化済みコンパイル済み C++ コードがキャッシュに存在するかを確認します。存在する場合は最高のパフォーマンスを得るためにそのコードを使用します。存在しない場合、Amazon Redshift は新しいクエリコンパイル最適化を適用し、コンポジションを使ってクエリを即座に処理します。コンポジションは、既存のロジックの軽量な組み合わせを生成する手法です。同時に、クエリ固有の最適化コードを作成し、利用可能なコンピューティングリソース全体でコンパイル・実行してパフォーマンスをさらに向上させます。コンポジションにより、コンパイルがクエリ実行のクリティカルパスから外れ、バックグラウンドでコンパイルが進行する間に即座に実行を開始できます。その結果、Amazon Redshift で処理される新しいクエリの開始が速くなり、2 回目以降の実行と同等のパフォーマンスが得られます。 コンポジションにより初回クエリの開始が大幅に高速化される一方、繰り返し実行されるクエリは Amazon Redshift のコード生成がもたらす優れた価格性能比の恩恵を引き続き受けられます。 重要な点として、このパフォーマンス最適化を利用するためにユーザー側の操作は不要です。Amazon Redshift が利用可能なすべての AWS リージョンにおいて、プロビジョンドクラスターまたはサーバーレスワークグループのすべてのユーザーのすべての SQL クエリにデフォルトで有効化されており、追加費用はかかりません。 実環境でのパフォーマンス結果 Amazon Redshift のお客様クラスターに対する今回の最適化の効果を分析しました。コンパイルキャッシュでキャッシュヒットせず、コンパイルが必要だった 1% のクエリセグメントのコンパイル時間を測定しました。次のグラフがその結果です。最適化前の P50 コンパイル時間は 4.3 秒でした。最適化後は 25.7 倍短縮され、170 ミリ秒になりました。 今回の最適化により、BI ダッシュボードの読み込みが速くなり、インタラクティブな探索がよりレスポンシブになり、リアルタイム分析アプリケーションがより低レイテンシーでインサイトを提供できます。 お客様の声 「FastCompile クエリパフォーマンス機能を有効にしたクラスターで、Amazon Redshift がコールドクエリ実行のパフォーマンスを大幅に改善したことを確認しました。コンパイル時間が 12 秒から 5 秒に短縮され、2.4 倍高速なクエリパフォーマンスを達成したことを受け、分析ソリューションとして Amazon Redshift を採用しました」 — Vijay Hiremath 氏 (Intuit、Group Manager、Business Platforms) 「中国の大手酒類企業のデータプラットフォームリーダーとして、エンタープライズデータウェアハウスに Amazon Redshift を活用しています。多様な分析クエリパターンがあるため、初回コンパイル時のパフォーマンスに課題がありました。Redshift の新しいコールドクエリコンパイル強化機能をテストしたところ、コールドクエリがウォームクエリとほぼ同等の速度で実行されるようになり、多様なクエリで大幅な速度改善が見られました」 — Yujie Wang 氏 (JNC、Data Platform Leader) 「約 85 GB のデータを日次で複雑な ETL パイプライン (複数テーブル、混合 DML 操作) を通じて処理し、1.7 TB の Amazon Redshift データウェアハウスに格納する中規模のお客様において、fast compile 機能の強化によりメンテナンス後の ETL パイプラインが 25% 高速化されました。データロードが早く完了し、アナリストがより迅速に意思決定できるようになりました」 — Jagan Mohan 氏 (Algonomy、Product Engineering Head) 技術の詳細については、 VLDB 2026 Boston カンファレンス に採択された論文「 FastCompose: Eliminating compilation cold starts in query execution with composition 」をご覧ください。 あらゆるワークロードに対して業界最高の価格性能比 今回の最適化の効果を示すため、業界標準の TPC-DS ベンチマークから派生したベンチマークを使用して、短時間実行の BI 型低レイテンシーワークロードをシミュレーションしました。3 ノード RG xlarge の Amazon Redshift クラスター上で、比較的小規模な 100 GB のスケールでワークロードを実行しました。このクラスターサイズとスケールでは、クエリはミリ秒から 1 桁秒台で完了し、一般的な BI ダッシュボードで期待されるレイテンシーに相当します。派生 TPC-DS ベンチマークには 99 の異なるクエリが含まれ、レポートクエリ、アドホック分析、データ探索パターンなど、現実的なビジネスインテリジェンスワークロードの組み合わせを表しています。テストでは、Amazon Redshift RG クラスターでのコールド 1 回実行と、同等の他社クラウドデータウェアハウスでの同様の実行を比較しました。ウェアハウスを起動し、データをロードし、99 クエリを 1 回実行して、合計実行時間とクエリの幾何平均を測定しました。その他のクラスターウォームアップやセットアップは行っていません。今回のクエリパフォーマンス改善はハードウェアに依存しません。Amazon Redshift でサポートされるすべてのハードウェアインスタンスタイプ (プロビジョンドクラスターの RA3 と RG、サーバーレスワークグループをサポートするハードウェア) で動作します。 結果を以下の表にまとめ、続くグラフに要約しています。今回の最適化により、Amazon Redshift は短時間クエリに対して最速の実行時間と幾何平均を最低コストで実現し、新しいクエリに対して他社の主要データウェアハウスの最大 8.3 倍の価格性能比を達成しています。 . コスト/時間 実行時間 (秒) 幾何平均 (秒) 実行時間比較 幾何平均比較 幾何平均価格性能比 Redshift 3-node RG.xlarge $2.28 235 1.7 ベースライン ベースライン ベースライン Alternative Warehouse A $3.00 327 2.3 1.4 倍遅い 1.3 倍遅い 1.7 倍高コスト Alternative Warehouse B $4.00 538 3.4 2.3 倍遅い 2 倍遅い 3.4 倍高コスト Alternative Warehouse C $6.00 907 5.5 3.9 倍遅い 3.2 倍遅い 8.3 倍高コスト まとめ Amazon Redshift の新しいクエリ起動最適化は、分析ワークロード全体にわたる高速パフォーマンスへの取り組みの一環です。コンパイルの負荷を軽減することで、BI ダッシュボードやリアルタイム分析アプリケーションのレスポンスを向上させつつ、定評のあるクエリ実行パフォーマンスを維持しています。 すべての Amazon Redshift ユーザーに自動的に有効化されているため、すぐに効果を体験できます。設定変更やクエリの書き換えは不要です。既存のクエリがそのまま高速に実行されます。 詳細については、 Amazon Redshift をご覧ください。 Amazon Redshift Serverless を使えば、データウェアハウスインフラストラクチャのセットアップや管理なしに数分でクエリを開始できます。パフォーマンスのベストプラクティスについては、 Amazon Redshift Database データベース開発者ガイド  を参照してください。 ワークロードに最適な価格性能比を見つける 本記事で使用したベンチマークは業界標準の TPC-DS ベンチマークから派生したもので、以下の特徴があります。 スキーマとデータは TPC-DS をそのまま使用しています。 クエリは TPC-DS から変更せずに使用しています。ウェアハウスがデフォルトの TPC-DS クエリの SQL 方言をサポートしていない場合は、TPC 承認済みのクエリバリエーションを使用しています。 テストには 99 の TPC-DS SELECT クエリのみが含まれます。メンテナンスとスループットのステップは含まれていません。 TPC-DS キットのデフォルトランダムシードで生成したクエリパラメーターを使用して、単一のパワーランを実行しました。単一のコールド実行の合計実行時間と幾何平均を結果として使用しています。 価格性能比は、幾何平均 (秒) を 1時間あたり 3,600 秒で除算し、ウェアハウスの時間あたりのコストを乗算して算出しています。結果はクエリあたりの幾何平均コストに相当します。すべてのデータウェアハウスで公表されているオンデマンド価格を使用しています。 Cloud Data Warehouse Benchmark と呼ぶこのベンチマークは、 GitHub で公開されているスクリプト、クエリ、データを使用して結果を再現できます。TPC-DS ベンチマークから派生したものであり、仕様に準拠していないため、公表された TPC-DS 結果とは比較できません。 ワークロードにはそれぞれ固有の特性があります。初めて検討する場合は、概念実証 (PoC) が要件に対する Amazon Redshift のパフォーマンスを理解する最良の方法です。PoC を実行する際は、適切なクラスターサイジングと適切な指標 (時間あたりのクエリ数であるクエリスループットと価格性能比) に焦点を当ててください。概念実証の 支援をリクエスト するか、 システムインテグレーションおよびコンサルティングパートナー と協力することで、データに基づいた意思決定が可能です。 Amazon Redshift の最新の開発状況を把握するには、 What’s New in Amazon Redshift の RSS フィードをご購読ください。 著者について Stefan Gromoll Amazon Redshift の Principal Engineer として、スタック全体にわたる Redshift のパフォーマンスを担当しています。余暇には料理、3 人の息子との遊び、薪割りを楽しんでいます。 Ravi Animi Redshift チームの Senior Product Management リーダーとして、Amazon Redshift クラウドデータウェアハウスサービスのパフォーマンス、クエリ処理、マテリアライズドビュー、空間分析、ストリーミング分析、移行戦略など複数の機能領域を管理しています。リレーショナルデータベース、多次元データベース、IoT テクノロジー、ストレージおよびコンピューティングインフラストラクチャサービスの豊富な経験があり、AI/ディープラーニング、コンピュータービジョン、ロボティクスを活用したスタートアップ創業者としての経験もあります。Washington Univ. St. Louis で物理学と電気工学の学士号を、Stanford で工学修士号を、Chicago Booth で MBA を取得しています。 Venkat Govindaraju Amazon Web Services (AWS Redshift) の Principal Engineer として、大規模データ管理システムの構築、最適化、スケーリングに 25 年以上の経験があります。University of Wisconsin-Madison でコンピューターサイエンスの Ph.D. を取得し、コンパイラ支援による動的ハードウェア特殊化を通じたエネルギー効率の高いコンピューティングを研究しました。分散システム、クエリエンジン、ハードウェアとソフトウェアの協調設計に精通し、VLDB、SIGMOD、MICRO、ISCA など一流会議での発表実績と複数の米国特許を保有しています。過去には Facebook、Oracle Labs、Epic Systems に在籍していました。 Kiran Chinta Amazon Redshift エンジニアリングチームの Senior Development Manager です。Amazon Redshift の主要機能を複数リードしてきた実績があります。Amazon Web Services、IBM、その他の企業でソフトウェアエンジニアリングチームをリードした豊富な経験があります。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。