Amazon Redshift のマルチウェアハウス機能強化でアナリティクスをスケール

本記事は 2026 年 6 月 29 日 に公開された「Scale analytics with Amazon Redshift multi-warehouse enhancements」を翻訳したものです。

Amazon Redshift のリモートテーブル DDL の改善、マテリアライズドビューの機能強化、ゼロ ETL および 自動コピー向けの同時実行スケーリング拡張により、大規模なアナリティクスワークロードを効率的にオンボードできるようになりました。

組織がアナリティクス機能を拡張する際には、本番環境の運用を中断せず、単一のデータウェアハウスのリソースに制約されずにワークロードを追加できる柔軟性が求められます。本記事では、Amazon Redshift のマルチウェアハウスおよびスケーリング機能を強化する新機能として、リモートマテリアライズドビュー (MV) 操作、リモートテーブル DDL サポート、ゼロ ETL および S3 イベント統合向け同時実行スケーリングの拡張を紹介します。各機能を組み合わせることで、Amazon Redshift 上でスケーラブルかつ高パフォーマンスな分散型アナリティクスアーキテクチャを構築できます。

マルチウェアハウスの新機能で大規模アナリティクスをどのように実現できるか確認していきましょう。

リモートマテリアライズドビュー操作の新機能

• Amazon Redshift では CREATE MATERIALIZED VIEW がユーザーワークロードとして分類されるようになりました。リソース競合時に同時実行スケーリングが追加のウェアハウスで MV ロジックを実行できるため、高負荷時でもクエリが MV のパフォーマンスメリットを安定して享受できます。
• Amazon Redshift でリモートデータ共有上での MV 作成がサポートされるようになりました。Redshift ウェアハウス間でデータを共有しているお客様が、ローカルデータと共有データの両方で MV のパフォーマンスメリットを活用できます。
• コンシューマーウェアハウスで、プロデューサーで作成された MV のリフレッシュや、データ共有された MV の上に MV を作成できるようになりました。データ共有アーキテクチャのプロデューサーとコンシューマーのウェアハウス間で MV の機能が完全に同等になりました。

リモートテーブル DDL 操作の新機能

• ALTER TABLE ALTER DISTSTYLE 操作が、同時実行スケーリングとデータ共有を通じてリモートウェアハウスで動作するようになりました。分散環境全体でデータ分散を動的に最適化し、データ移行なしでクエリパフォーマンスとリソース使用率を改善できます。複数のウェアハウスにまたがるパフォーマンスチューニングを行うデータエンジニアや、変化するクエリパターンに対応する管理者にとって特に有用です。
• ALTER TABLE APPEND 操作が、同時実行スケーリングとデータ共有を通じてリモートウェアハウスに拡張されました。分散環境間でデータを統合でき、複雑なデータ移動や ETL プロセスなしで効率的にテーブルを結合できます。複数環境にまたがる動的テーブル操作を管理する組織が、運用負荷を軽減しながらデータの一貫性を維持できます。

同時実行スケーリングの改善

• Amazon Redshift の拡張された ゼロ ETL 機能が同時実行スケーリングをサポートし、アプリケーションやオペレーショナルソースからの自動データ取り込みに対応しました。
• Amazon Redshift の拡張された 自動コピー機能が同時実行スケーリングをサポートし、S3 からの自動データ取り込みに対応しました。
• Amazon Redshift の同時実行スケーリングが Amazon S3 からの COPY クエリをサポートするようになりました。バッチワークロード向けに同時実行スケーリングでデータ取り込みを自動的にスケールできます。

同時実行スケーリングの拡張により、既存のウェアハウスパフォーマンスを損なわずに一貫したデータ鮮度を維持できます。アナリティクスとデータロードのトレードオフが解消されます。同時実行スケーリングを有効にする以外に、追加の変更は不要です。

お客様のユースケース

ここでは、金融サービスとゲーム業界の 2 つのユースケースを紹介します。

金融サービスのユースケース

以下は、グローバル展開する大手金融サービスのお客様のサンプルアーキテクチャです。同社は Amazon Redshift 上にマルチウェアハウスアーキテクチャを構築しています。

ステージング (STG) ウェアハウスは、メダリオンアーキテクチャのブロンズレイヤーのように、さまざまなソースからのデータの 生データゾーンです。STG ウェアハウスは 生データのクレンジングと標準化も行い、シルバーレイヤーとして後続処理に利用可能にします。また、MV を使用して数百万件のネストされた JSON メッセージを処理し、属性をスカラーのカラム型 Amazon Redshift テーブルに抽出します。

CREATE MATERIALIZED VIEW rawdb.fsi.customer_orders_raw
distkey(c_custkey) sortkey(c_custkey) AS (
    SELECT c_custkey,
        o.o_orderstatus,
        o.o_totalprice,
        o_idx
    FROM customer_orders_lineitem c,
        c.c_orders o AT o_idx
);
REFRESH MATERIALIZED VIEW rawdb.fsi.customer_orders_raw;

DWH ウェアハウスはプライマリ Amazon Redshift インスタンスおよびゴールドレイヤーとして、Business Objects や Tableau などのコンシューマーアプリケーションにデータを提供します。ゼロ ETL 同時実行スケーリングの改善により、ゼロ ETL の取り込みスパイクと DWH の高負荷ワークロードが同時に発生しても、一貫したデータ鮮度を維持できます。DWH の MV は、Tableau エクストラクトや Business Objects のライブレポート向けに集約データへの高速アクセスを提供します。DWH ウェアハウスは、DWH インスタンス上で複数の MV をリフレッシュする必要がある場合に同時実行スケーリングを活用します。

CREATE MATERIALIZED VIEW bodb.final.customer_churn_tbl
AS (
    SELECT state,
        account_length,
        area_code,
        total_charge/account_length AS average_daily_spend,
        cust_serv_calls/account_length AS average_daily_cases,
        churn
    FROM custdb.final.customer_activity_all
);
REFRESH MATERIALIZED VIEW bodb.final.customer_churn_tbl;

ETL01/02 ウェアハウスはプロジェクト固有の ETL ジョブを実行する専用コンピュート環境として、USR01/02 ウェアハウスは dbt からのアドホック分析やモデル構築などのユーザーワークロードを処理します。ユーザーワークロードに新しいオブジェクトが必要な場合、リモートのプロデューサーウェアハウス (DWH) 上で作成・管理されます。

ALTER TABLE salesdb.final.sales_report_all
ALTER DISTKEY sales_id;

ALTER TABLE APPEND salesdb.final.sales_report_all
FROM stagingdb.sales.sales_2026_02;

ゲーム業界のユースケース

大手ゲーム会社は、アナリティクスインフラ全体を AWS 上に構築しており、アナリティクスチームがゲームからのデータストリーミング、データウェアハウジング、BI ツールを管理しています。同社は Amazon EC2 上で稼働していた Vertica から移行し、Amazon Redshift を組織全体で標準化しました。クラスターリサイズ操作に関する初期の課題を克服した後、チームは Amazon Redshift の強力な推進者となり、現在は 32 ノードの ra3.16xlarge でプライマリ本番クラスターを運用しています。

データ取り込みパイプラインの成長に伴い、クエリワークロードがデータ取り込みプロセスと競合し、パフォーマンスのボトルネックが発生しました。プライマリクラスターをスケールアップするのではなく、Amazon Redshift データ共有を使用したワークロード分離戦略を実装しました。プライマリクラスターをプロデューサーとして、16 ノードの ra3.4xlarge クラスターをデータ共有コンシューマーとして起動しました。データ共有アーキテクチャにより、コンシューマークラスターにコンシューマーワークロードを移行し、プロデューサーはデータ取り込みに集中することで、プライマリクラスターのサイズを増やすことなく成長に対応できました。

分散アーキテクチャの利点を認識した同社は、ワークロードを Amazon Redshift Serverless に移行してアプローチを拡大し、ワークロード分離のためにデータ共有モデルをさらに活用しました。Amazon Redshift のリモートマテリアライズドビュー機能により、プロデューサークラスターが共有するデータ上に直接マテリアライズドビューを作成できるようになりました。各コンシューマークラスターが、固有のワークロードパターンに最適化されたマテリアライズドビューを構築できます。事前集約データセット、カスタム結合戦略、ワークロード固有のデータ分散を、プロデューサークラスターのパフォーマンスに影響を与えずデータの重複も不要で実現できました。プロデューサーウェアハウスは汎用的なエンタープライズニーズ向けに設計されたデータ分散とソート戦略を維持し、すべてのコンシューマーに対して一貫したデータ品質を提供します。一方、コンシューマーウェアハウスはリモートマテリアライズドビューを使用して、リアルタイムのプレイヤーアナリティクス、BI ダッシュボード、アドホックなデータサイエンスワークロードなど、固有の分析要件に合わせてクエリパフォーマンスを最適化しました。データ消費を最適化する分散アプローチは同社にとって不可欠でした。プロデューサークラスターを信頼できる唯一の情報源 (Single Source of Truth) として維持し、冗長なデータコピーの管理負荷を回避しながら、多様な分析ワークロード全体で高速なクエリパフォーマンスを実現しました。

ベストプラクティス

新機能を最大限に活用するために、以下のベストプラクティスを検討してください。

• Amazon Redshift クラスターおよび Serverless ワークグループで同時実行スケーリングを有効にし、ETL やユーザークエリの実行をさらに高速化して、レポートやダッシュボードのパフォーマンスを安定させましょう。
• Amazon Redshift プロビジョンドクラスターおよび Serverless ワークグループの両方で、適切な MaxRPU 設定により同時実行スケーリングの使用制限を設定しましょう。予期しない追加コストの発生を防げます。詳細については、Amazon Redshift の使用制限に関するドキュメントを参照してください。
• リモート MV を使用して、リソース集約型の MV 作成やリフレッシュ操作をプライマリウェアハウスからリモートデータ共有クラスターにオフロードしましょう。

まとめ

本記事では、MV リフレッシュの新機能、リモートテーブル DDL 機能、ゼロ ETL および S3 自動コピー向けの同時実行スケーリングサポートの拡張について紹介しました。各機能により、単一ウェアハウスの制約を超えることができます。複数環境にまたがる動的テーブル管理を必要とし、データの一貫性を維持しながら変化するワークロードに迅速に適応する分散データアーキテクチャを管理する組織にとって特に価値があります。利用を開始するには、最新の Amazon Redshift バージョンを実行していることを確認してください。続いて Amazon Redshift のドキュメントで同時実行スケーリング、データ共有、マテリアライズドビューの詳細をご覧ください。

著者について

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