Amazon Redshift はデータ共有とコンカレンシースケーリングを軸に、単一ウェアハウスの制約を越えるマルチウェアハウス構成へと機能を拡張しています。従来のデータウェアハウス運用では、ETL処理・重いダッシュボードクエリ・ニアリアルタイムな取り込みが一つのクラスタに集中し、互いに性能を奪い合うという課題がつきまといました。今回の一連の機能強化は、こうした重い処理をリモートウェアハウスやコンカレンシースケーリングにオフロードし、プライマリの応答性能を守るという設計思想を強く打ち出しています。

本記事では、AWSを活用するデータエンジニア・クラウドアーキテクト・インフラエンジニアの皆さまに向けて、リモートテーブルDDLの改善、マテリアライズドビューのクロスウェアハウス対応、zero-ETLとauto-copy向けコンカレンシースケーリングの拡張を整理します。あわせて、ある金融サービス企業とあるゲーム企業の実例から、設計と運用のベストプラクティスを解説します。

マルチウェアハウスがアナリティクス基盤にもたらす転換

単一のRedshiftクラスタをひたすらスケールアップする運用は、ワークロードの多様化とともに限界を迎えます。BIダッシュボードの参照、プロジェクト固有のETL、アドホック分析、そして継続的なデータ取り込みが同じコンピュートを共有すると、ピーク時に処理が競合し、本来守りたい対話型クエリの応答性能が犠牲になりがちです。

マルチウェアハウス構成では、データ共有によってデータを複製せずに複数のウェアハウスから同じ実体を参照し、用途ごとにコンピュートを分離します。さらにコンカレンシースケーリングを組み合わせることで、負荷スパイクに応じてコンピュートを自動的に追加できます。これにより、プライマリウェアハウスを重い書き込み系処理から守りつつ、アナリティクス全体を柔軟にスケールさせられます。今回の機能強化は、この「非集中型アナリティクス基盤」を実務で組みやすくするものだと言えます。

リモートテーブルDDLの改善でプライマリの負荷を抑える

今回強化されたリモートテーブルDDLは、コンカレンシースケーリングとデータ共有を通じてリモートウェアハウス上で動作するようになった2つのコマンドが中心です。いずれも、データ整備の処理をメインウェアハウスの外側で回せる点が本質的な改善です。

• ALTER TABLE APPEND はリモートウェアハウスへ拡張され、分散環境をまたいでデータを統合できるようになりました。複雑なデータ移動や追加のETL処理なしに、テーブルを効率的に結合・統合できます。
• ALTER TABLE ALTER DISTSTYLE もリモートウェアハウス上で動作し、分散環境をまたいでデータ分散を動的に最適化できます。データ移行を伴わずに分散方式を変更でき、複数ウェアハウス間でのクエリ性能とリソース利用効率を改善できます。

データエンジニアにとっての実務メリットは明快です。DDL操作をリモート側で実行できるため、プライマリの負荷を上げずにデータの統合や分散最適化を進められます。結果として、ETLパイプラインの複雑さを減らしながら、対話型クエリの応答性能を守れます。以下は、リモートウェアハウス上でステージング済みデータをターゲットへ追記する例です。

ALTER TABLE gold.fact_sales APPEND
FROM staging.fact_sales_delta;

ALTER TABLE gold.fact_sales
ALTER DISTSTYLE KEY DISTKEY (customer_id);

マテリアライズドビュー機能強化とクロスウェアハウス参照

マテリアライズドビュー（MV）の強化は、What's New では2025年12月23日に一般提供として案内された4つの新機能として整理されています。マルチウェアハウス構成での使い勝手を大きく高める内容です。

まず、CREATE MATERIALIZED VIEW がユーザーワークロードとして分類されるようになりました。これによりコンカレンシースケーリングが CREATE MV のDDLにも効くようになり、リソース競合や枯渇が起きても追加ウェアハウス上でMVのロジックを実行できます。高負荷時でもMVの作成をスケールさせられる点が実務上の大きな利点です。

次に、データ共有された共有データ上にMVを作成できるようになりました。ローカルデータと共有データの双方でMVの性能メリットを享受できます。さらにコンシューマ側では、プロデューサが作成したMVをリフレッシュでき、共有MVの上にさらにMVを重ねて作成することも可能です。これにより、データ共有アーキテクチャにおいてプロデューサとコンシューマの間でMV機能のパリティが達成されました。以下は共有データ上でネストしたJSONメッセージからスカラー列を抽出するMVの例です。

CREATE MATERIALIZED VIEW silver.mv_events
AUTO REFRESH YES AS
SELECT
  event_id,
  json_extract_path_text(payload, 'user_id') AS user_id,
  json_extract_path_text(payload, 'amount') AS amount
FROM shared_stg.raw_events;

クロスウェアハウス参照とリモートMVを組み合わせると、リソース集約的なMVの作成やリフレッシュをプライマリの外側で回せます。プライマリはあくまで真実源として安定させ、消費側のワークロードは分離したウェアハウスで最適化するという構成を、データを複製せずに実現できます。

zero-ETLとauto-copyを支えるコンカレンシースケーリングの拡張

取り込み系の強化として、auto-copy と zero-ETL の双方にコンカレンシースケーリングが対応しました。この拡張は What's New で2026年5月1日に一般提供として発表されています。

• auto-copy は Amazon S3 からの COPY クエリをサポートするよう拡張され、バッチ取り込みを自動でスケールできます。既存ウェアハウスの性能を損なうことなくデータ鮮度を維持できます。
• zero-ETL では、取り込みスパイクが重いデータウェアハウスワークロードと同時に発生しても、データ鮮度を一貫して維持できます。読み取り・書き込みクエリの増加に対して自動でコンピュートが追加されます。

対応範囲も広く、Amazon Redshift Serverless と RA3 プロビジョンドデータウェアハウスの両デプロイで利用できます。対応リージョンは、Amazon Redshift が利用可能な全AWS商用リージョンおよびAWS GovCloud (US) リージョンです。ニアリアルタイムな取り込みのスパイクと、ダッシュボードによる高負荷が重なるという運用者にとって身近な状況でも、鮮度と応答性能を両立しやすくなります。

金融とゲームの実例に学ぶ設計と運用のベストプラクティス

ある金融サービス企業は、メダリオンアーキテクチャ的なレイヤ分割と用途別ウェアハウスを組み合わせて運用しています。ステージングを担うSTGは各種ソースの生データを受けるブロンズ層に相当し、クレンジングと標準化を経てシルバー層へと磨き込みます。ネストしたJSONメッセージはMVで処理します。プライマリインスタンスであるDWHはゴールド層に相当し、Business Objects や Tableau といった消費側アプリケーションへデータを提供します。zero-ETLの取り込みスパイクが重なっても高いデータ鮮度を維持できます。加えて、プロジェクト固有のETLジョブ用にETL01・ETL02、アドホック分析やdbtによるモデル構築などのユーザーワークロード用にUSR01・USR02を分離しています。

あるゲーム企業は、Amazon EC2上で稼働していた Vertica からの移行を進めました。プロデューサとなるプライマリクラスターは32ノードのra3.16xlarge、コンシューマクラスターは16ノードのra3.4xlargeという構成です。データ共有によるワークロード分離で、クエリと取り込みの性能競合を解消しました。その後 Amazon Redshift Serverless へと拡張し、コンシューマ側のMVを分析パターンごとに最適化しています。データを複製せず、単一の信頼できる情報源を維持できている点が特徴です。

これらの実例を踏まえた運用のベストプラクティスを、以下に整理します。

とりわけコスト面では、コンカレンシースケーリングの導入時に「青天井の課金にならないか」という懸念がつきものです。MaxRPUによる使用量上限は、この懸念に対する実務的な回答となります。推奨値は用途やワークロードによって変わるため、環境に応じて適切に設定してください。重い書き込み系処理をリモートやコンカレンシースケーリングに逃がしつつ、MaxRPUでコストの天井を守るという運用を徹底すれば、プライマリの応答性能とコストの両方を安定させながら、アナリティクス基盤をスケールさせていけます。導入にあたっては、各機能のGA区分を個別に確認し、最新バージョン前提であることを運用チェックリストに加えておくと安心です。