Amazon Redshift本番運用Vol1｜Serverless/RA3/zero-ETL

1. Amazon Redshift 全体像と本記事の射程・Serverless vs RA3 選定指針

1-1. 本記事のゴール

Amazon Redshift は AWS が提供するフルマネージドなペタバイト級データウェアハウス（DWH）サービスです。
列指向ストレージと MPP（Massively Parallel Processing）アーキテクチャにより、数十億行規模の集計クエリを高速に処理できます。
オンプレミス DWH の移行先として長年の実績があり、2026 年現在も AWS における代表的な DWH サービスとして機能拡張が続いています。

列指向ストレージが DWH クエリを高速化する仕組み

行指向 RDBMS（PostgreSQL・MySQL 等）が 1 行単位でデータを保存するのに対し、Redshift は同一列のデータをまとめて連続して保存します。
集計クエリ（SUM・AVG・COUNT など）は特定の列のみを参照するため、不要な列のデータを読み飛ばすことで I/O コストを大幅に削減できます。
また同一列のデータは型と値の分布が均一なため、高い圧縮率（平均 3〜10 倍）が得られ、ストレージコストと I/O 量を同時に削減できます。
MPP では複数のコンピュートノードが同一テーブルのデータを分散して保持し、クエリを並列処理します。
この並列性により、大量データへの集計クエリでも一般的な RDBMS の数十〜数百倍の速度を実現できます。

本記事は、Redshift を「分析基盤の一部品」としてではなく、DWH 単体として本番運用できる状態を到達点とします。
読者が習得できる主な成果物は次のとおりです。

• Serverless / RA3 / DC2 の選定基準: ワークロード特性・予算・管理コストから最適なデプロイ形態を選択できます。
• RPU コスト制御の手法: base capacity・max RPU-hours・usage limits を組み合わせてコスト上限を保証する設計ができます。
• WLM と SQA の実践設計: 自動 WLM・クエリ優先度・短期クエリ高速化（SQA）・同時実行スケーリングを正しく組み合わせられます。
• zero-ETL 統合の活用: Aurora/RDS/DynamoDB からの near-real-time レプリケーションを設定し、制限事項と東京リージョン対応状況を把握できます。
• Data Sharing の設計: クロスアカウント・クロスリージョンでのデータ共有を安全に設計できます。
• Spectrum によるデータ階層設計: S3 上のコールドデータを外部テーブルとして活用し、ローカルテーブルとの使い分けとコスト最適化ができます。

1-2. 読者像

本記事が想定する読者は、SQL と AWS の基礎知識を持ち、Redshift を本番環境で設計・運用したいデータエンジニアです。
次のような課題を抱えている方が特に対象です。

• Serverless と RA3 プロビジョンドのどちらを選ぶべきか判断できていない
• RPU 課金の仕組みが把握できておらず、月次コストの見通しが立たない
• WLM の設定を感覚的に行っており、クエリ優先度やキュー設計の根拠が不明確
• zero-ETL 統合を導入したいが、対応ソースや制約条件が整理できていない
• Spectrum を活用したいが、コスト構造と性能最適化の方針が明確でない
• Data Sharing を検討しているが、クロスアカウント設計の手順や課金が不透明

前提知識: SQL 基礎（SELECT・JOIN・集計関数）、DWH の基本概念（ディメンション・ファクト・スタースキーマ）、AWS マネジメントコンソールの基本操作。
Redshift に接続する際は JDBC/ODBC ドライバまたは Redshift Data API を使用します（詳細は本記事の範囲外です）。
Glue・Athena・Lake Formation など他の分析サービスとの連携設計は本記事では扱いません。

1-3. Serverless vs RA3 プロビジョンドの選定指針

Redshift は 2026 年時点で 3 種類のデプロイ形態が現役として提供されています。

廃止ノードについて: DS2 ノードは廃止済みで新規クラスターを作成できません。現役は Serverless・RA3・DC2 の 3 形態です。「DS2 は廃止・DC2 も廃止」という情報は誤りです。廃止はDS2のみです。

Serverless を選ぶ場合

Serverless は RPU（Redshift Processing Unit）単位でコンピュートリソースを自動スケールします。
1 RPU は 16 GB メモリに相当し、クエリが実行されていない時間はコンピュート課金がゼロになります。
課金は RPU-hour 単位ですが、課金計測は秒単位で行われ、最小課金時間は 60 秒です（「1 時間単位の課金」は誤りです）。

AI-driven scaling 機能により、クエリの複雑さとデータ量に応じて RPU が自動調整されます。
断続的なワークロード（日次バッチ・BI ツールの特定時間帯のみの利用）、チームがインフラ管理を極力避けたい場面、または負荷の予測が難しい開発初期フェーズに向いています。

東京リージョンの base capacity は 4 〜 512 RPU（デフォルト 128 RPU）の範囲で設定可能です。
最大 1,024 RPU に対応するのは北バージニアなど一部リージョン限定で、東京の上限は 512 RPU です。
max RPU と usage limits の設定によるコスト上限管理の詳細は §3 で解説します。

RA3 プロビジョンドを選ぶ場合

RA3 は Managed Storage（RMS）によってコンピュートとストレージを分離したプロビジョンドクラスターです。
ローカル SSD をホットデータキャッシュ、S3 を永続ストレージ層とすることで、SSD の物理容量を超えてストレージが自動拡張されます。

予算を固定したい本番 DWH・24/7 の定常ワークロード・WLM 詳細制御が必要なケース・Data Sharing を活用するケースに向いています。
圧縮後 1 TB 以上の大規模データや、コスト予算を確定させたい本番環境では RA3 がベースラインです。

DC2 プロビジョンドを選ぶ場合

DC2 は SSD ローカルストレージを持つプロビジョンドクラスターで、旧世代ながら現役です。
圧縮後データサイズが 1 TB 未満のワークロードでは新規クラスターの作成が可能で、小規模 DWH の選択肢として有効です。
ただし Managed Storage を持たないため、ストレージ拡張には Classic resize（完全再構築・長時間）が必要です。
Data Sharing や一部の Concurrency Scaling 機能は DC2 では非対応のため、これらの機能が必要な場合は RA3 を選んでください。

Graviton ベースの RG ノード（2026 年追加）

2026 年には Graviton プロセッサを採用した RG ノードが RA3 と並ぶ推奨ノードとして追加されました。
RG ノードは RA3 と同様に Managed Storage（RMS）を利用し、コンピュート性能とコスト効率が向上しています。
RA3 は廃止されておらず、RA3 と RG の両方が現行の推奨プロビジョンドノードタイプとして提供されています。
新規クラスターを作成する場合は、最新の料金ページで RG ノードの価格性能比を比較することを推奨します。

1-4. 本記事の差別化と前提知識

AWS の分析サービスを横断して解説する記事がすでに公開されており、本シリーズとの棲み分けを明示します。

• AWS データ分析 Vol1（ID:3955）: Athena・Glue・Lake Formation・Redshift を組み合わせた分析パイプライン全体を扱う記事。Redshift はパイプラインの 1 コンポーネントとして登場します。
• AWS データレイク構築（ID:3477）: Glue・Athena・Redshift を含むデータレイク横断設計を扱う記事。

本シリーズはこれら横断記事と設計意図が異なります。
Redshift 単体 DWH の本番運用に焦点を絞り、Serverless の RPU チューニング・RA3 の RMS 設計・WLM 詳細設定・zero-ETL 統合・Data Sharing・Spectrum を深掘りします。
Athena・Glue・Lake Formation など他サービスとの連携設計については上記記事へのクロスリンクで委譲し、本記事では扱いません。
本シリーズは Vol2 以降で WLM・同時実行スケーリング・Spectrum の詳細設計など、さらなる深掘りを予定しています。

§2 RA3 ノード・Managed Storage・スナップショットを読む

2. RA3 ノード・Managed Storage・スナップショット・クラスター管理

2-1. RA3ノードタイプとManaged Storage

RA3 ノードは Amazon Redshift プロビジョンドクラスターの現行推奨ノードタイプです。
Managed Storage（RMS） によってコンピュートとストレージを分離しており、ローカル SSD をホットデータキャッシュ、Amazon S3 を永続ストレージ層として活用します。
この分離アーキテクチャにより、SSD の物理容量を超えてストレージが自動拡張され、コンピュートノードのスケールアップなしに大規模データを保持できます。

RA3 ノードタイプの比較

注意: ra3.4xlarge の管理ストレージは現行 128 TB/ノードです。2020 年ローンチ時のブログに記載された「64 TB」は古い値のため、公式ドキュメントの最新値を必ず参照してください。

Managed Storage（RMS）の仕組み

RMS はコンピュートノードのローカル SSD と S3 ベースの永続ストレージ層を組み合わせたシステムです。
Redshift が自動的にホットデータを SSD にキャッシュし、アクセス頻度の低いデータを S3 永続層に移動します。
この階層化によりコスト効率を維持しながら、TB〜PB 規模のデータを保持できます。

課金はコンピュート（ノード時間）とストレージ（GB/月）が独立しており、ストレージを増やしてもコンピュートコストは変わりません。
Elastic resize はコンピュートの変更であり、RMS ストレージのデータはそのまま保持されます。

DC2 ノードの位置づけ（圧縮後 1 TB 未満）

DC2 は SSD ローカルストレージを持つプロビジョンドクラスターで、旧世代ながら現役です。
圧縮後データサイズが 1 TB 未満のワークロードでは新規クラスターの作成が可能で、小規模 DWH の選択肢として有効です。
Managed Storage を持たないためストレージはローカル SSD に限定され、主な制限事項は以下のとおりです。

• ストレージの拡張には Classic resize（完全再構築・長時間）が必要
• Data Sharing の producer / consumer どちらも非対応
• Concurrency Scaling の書込スケーリングは非対応（読取のみ）
• Multi-AZ 構成は非対応

DS2 ノードは廃止済み

DS2（Dense Storage 2）ノードは廃止されており、新規クラスターの作成はできません。
「DS2 が廃止されたので DC2 も廃止」という情報は誤りです。廃止されたのは DS2 のみで、DC2 は引き続き利用できます。
既存の DS2 クラスターをお持ちの場合は、RA3 への移行が推奨されます。

2-2. クラスター設計とノード数

クラスターのアーキテクチャ

Redshift プロビジョンドクラスターは リーダーノード と コンピュートノード で構成されます。

リーダーノードはクライアントからの SQL を受け取り、クエリ実行計画を生成してコンピュートノードへ分散します。
コンピュートノードは実際のデータを保持し、並列にクエリを実行します。
各コンピュートノードは スライス という処理単位に分割され、スライス数がデータの分散粒度と並列度を決定します。

スライスの総数（ノード数 × ノードあたりスライス数）が、テーブルのデータ分散の粒度に対応します。
例えば ra3.4xlarge を 4 ノードで構成した場合、合計 16 スライスとなり、1 テーブルのデータが 16 分割で保持されます。

ノード数の選定目安

ノード数の目安は、総データサイズ・スライス数・I/O スループット要件・同時実行クエリ数を組み合わせて算出します。
実際の選定では小さく始めて Elastic resize で拡張していくアプローチが推奨です。

選定の基本的な考え方:

• 圧縮後データサイズが ra3.4xlarge の 1 ノードあたり管理ストレージ上限（128 TB）未満であれば 2 ノードから検討できます
• ピーク時の同時実行クエリ数が多い場合は、スライス数が多くなるようにノード数を増やします
• RA3 は Elastic resize で素早くスケールアウトできるため、過大なノード数で始める必要はありません

クラスターのリサイズ方法

Redshift では用途に応じて 2 種類のリサイズ方法を選択できます。

Elastic resize（エラスティックリサイズ）

同一ノードタイプのまま、ノード数を変更する方法です。
処理時間は通常数分程度で、リサイズ中も読取クエリの実行が可能です（一時的なパフォーマンス低下あり）。
RA3 クラスターでのノード増設・削減に最適で、ピーク対応のスケールアウトや閑散期のコスト削減に活用できます。

制約事項:
– 同一ノードタイプでのノード数変更に限定されます
– 一部のノードタイプ・ノード数の組み合わせは非対応です
– 完了後はメタデータのみ更新（RMS ストレージのデータ移動なし）

Classic resize（クラシックリサイズ）

ノードタイプの変更を含む完全なクラスター再構築です。
新しいクラスターへのデータ全量移行が行われるため、クラスター規模に応じて数時間から数日かかります。
リサイズ中は既存クラスターが読取専用モードになるため、事前に十分なメンテナンス時間を確保してください。
DC2 から RA3 への移行など、ノードタイプを変更する場合はこの方法を使用します。

2-3. スナップショット（自動/手動/クロスリージョン）

Redshift のスナップショットは、クラスターデータを特定時点の状態で S3 に保存するバックアップ機能です。
変更分のみを増分で保存するため、スナップショットが増えてもストレージ効率が高く維持されます。

自動スナップショット

自動スナップショットは Redshift が自動的に作成・管理するバックアップです。
作成タイミングはデフォルトで 約 8 時間ごと または 5 GB 以上のデータ変更 があった時点です。

主な仕様:

• 保持期間: デフォルト 1 日（設定範囲: 1〜35 日）
• 無効化: RA3 および RG（Graviton 版）クラスターでは自動スナップショットを無効化できません
• DC2 クラスター: 自動スナップショットの無効化が可能（バックアップ不要な開発環境等で活用）
• ストレージ課金: 保持中のスナップショットは S3 ストレージとして別途課金されます

RA3/RG クラスターで自動スナップショットを無効化しようとすると、コンソール・CLI の両方でエラーになります。これは意図的な仕様で、Managed Storage の持続性を保証するための設計です。

手動スナップショット

手動スナップショットは任意のタイミングでコンソール・CLI・API から作成できます。

手動スナップショットの主な特徴:

• 保持期間: 無期限（明示的に削除するまで保持）
• クラスター削除後も存続: クラスターを削除してもスナップショットは残存し、後から別クラスターとして復元できます
• ストレージ課金: 保持中は S3 ストレージとして課金されます
• 活用例: リリース前のベースラインバックアップ、長期アーカイブ、クラスター複製

クロスリージョンスナップショット

クロスリージョンスナップショットは、別の AWS リージョンにスナップショットを複製する機能です。
主に ディザスタリカバリ（DR） 目的で使用します。

設定と課金:

• コンソールの「スナップショットコピー」設定からターゲットリージョンと保持期間を指定します
• 自動スナップショットを自動的に別リージョンへコピーする自動コピー設定も利用できます
• クロスリージョンへのデータ転送料金（送信リージョンの S3 アウトバウンド料金）が発生します
• コピー先リージョンでのスナップショットストレージ料金も別途課金されます

スナップショットからの復元

スナップショットからの復元は 新しいクラスターとして 行われます。
既存クラスターへの上書きリストアはできないため、新クラスターへ切り替える運用設計が必要です。

リストア時のポイント:

• 復元先は元のクラスターと同じ VPC・セキュリティグループ構成を推奨します（エンドポイント差し替えによるアプリケーション影響の最小化）
• ポイントインタイムリストアは直近 24 時間（または自動スナップショット保持期間内）で利用できます
• RA3 クラスターの場合、RMS（S3 永続層）からのデータロードが非同期で行われるため、復元後すぐにクエリの受付を開始できます
• スナップショットからのリストア時間は、データ量よりもメタデータの再構築に依存することが多く、RA3 では実データが RMS に永続化済みのため比較的短時間で完了します
• 別リージョンのスナップショットからリストアする場合は、まず対象リージョンにスナップショットをコピーしてからリストアする手順が必要です

2-4. クラスターの可用性・メンテナンス

シングル AZ 構成（プロビジョンドのデフォルト）

Redshift プロビジョンドクラスターはデフォルトで単一 AZ に配置されます。

RA3 クラスターでノード障害が発生した場合、Redshift は自動的に置き換えノードをプロビジョニングし、RMS の S3 永続層からデータを復旧します。
RMS にデータが永続化されているため、ノード置き換え後に数分以内でクエリの受付が再開されます。
DC2 クラスターの場合はローカル SSD のデータが失われるため、スナップショットからの復元が必要になり、復旧に時間がかかります。

マルチ AZ 構成（RA3 高可用性オプション）

RA3.4xlarge および RA3.16xlarge クラスターでは Multi-AZ 構成が利用できます。
スタンバイクラスターを別 AZ に配置することで、AZ レベルの障害（電源断・ネットワーク断）が発生してもクエリが継続実行できます。

Multi-AZ の主な特性:

• プライマリとスタンバイの 2 セットのコンピュートが常時稼働（コストはシングル AZ の約 2 倍）
• RMS（Managed Storage）はプライマリ・スタンバイ間で共有されます
• フェイルオーバー時間は数十秒〜数分程度（クラスターの規模による）
• SLA 要件が厳しい本番 DWH や、ダウンタイムを許容できないビジネスクリティカルな処理に適しています

メンテナンスウィンドウ

Redshift はマイナーバージョンアップデートや OS パッチを定期的なメンテナンスウィンドウ内に適用します。

デフォルトでは Redshift がランダムに 30 分のメンテナンスウィンドウを週次で設定しますが、コンソールからカスタム設定に変更できます。
本番環境では、業務影響が最小となる時間帯（例: 月曜早朝 03:00 UTC など）に変更することを推奨します。

メンテナンス中の挙動と対策:

• メンテナンス中はクラスターが一時的に利用不可になります（通常数分から最大 30 分程度）
• 接続中のクエリは中断されるため、アプリケーション側では再接続とリトライのロジック実装が推奨されます
• メンテナンスの完了後はクラスターが自動的に再開し、通常の接続受付を再開します
• Multi-AZ 構成の場合はフェイルオーバーを活用して、メンテナンス中もクエリ実行を継続できます

スナップショットとバックアップの連携

メンテナンスウィンドウの前後に手動スナップショットを取得しておくことで、アップデートによって問題が発生した場合のロールバック手段を確保できます。
本番環境では「メンテナンス前の手動スナップショット取得 → 24 時間後に問題がなければ古いスナップショットを削除」という運用を検討してください。

3. Redshift Serverless：RPU・コスト最適化・自動スケーリング

Redshift Serverlessは、サーバーのプロビジョニングや管理が不要なサーバーレス型のデータウェアハウスサービスです。クエリを実行したときだけ compute リソースが起動し、アイドル時は課金が発生しないモデルにより、断続的なワークロードや開発・テスト環境での利用に特に適しています。

3-1. Serverless のアーキテクチャ：namespace と workgroup

Redshift Serverlessは namespace（名前空間） と workgroup（ワークグループ） の2層コンポーネントで構成されています。

namespace（名前空間） が管理するリソース：

• データベース・スキーマ・テーブル・ユーザー定義関数（UDF）などのデータオブジェクト
• 管理ストレージ（データの永続化領域）
• IAMロール・KMS 暗号化の設定
• 手動スナップショット

workgroup（ワークグループ） が管理するリソース：

• base capacity（最小 RPU）と max capacity（スケール上限 RPU）の設定
• VPC・サブネット・セキュリティグループなどのネットワーク設定
• クエリエンドポイント（接続 URI）
• クエリタイムアウト・usage limit（Max RPU-hours）などの制限設定

1 つの workgroup は必ず 1 つの namespace に関連付けられます。複数の workgroup が同じ namespace を共有する構成も可能で、同一データセットに対して異なるネットワーク設定や容量設定を使い分けるシナリオに対応できます。

3-2. RPU（Redshift Processing Unit）と AI 駆動の自動スケーリング

RPU（Redshift Processing Unit）の概念

Redshift Serverlessの計算能力は RPU（Redshift Processing Unit） という単位で表現されます。

• 1 RPU = 16 GB のメモリ に相当する計算能力の単位です
• RPU 数が増えると、CPU・メモリ・ネットワーク帯域がそれぞれ比例してスケールします

AI 駆動の自動スケーリング

Redshift Serverlessは、クエリの複雑度と処理データ量をリアルタイムに評価し、必要な RPU 数を自動調整する AI 駆動のスケーリング機能を搭載しています。2026年4月より、新規 workgroup ではこの機能がデフォルト有効となっています。

スケーリングの最適化方向は workgroup の price-performance target 設定で制御できます。

クエリのないアイドル状態では compute リソースが解放されるため、アイドル時の compute 課金はゼロ になります。

3-3. base capacity と max capacity（東京リージョンの上限に注意）

base capacity（最小 RPU）の設定

workgroup が常時確保する最小 RPU 数を base capacity と呼びます。

• 設定範囲：4 RPU ～ 512 RPU（東京リージョン ap-northeast-1）
• デフォルト値：128 RPU

⚠️ 東京リージョンの上限は 512 RPU
北バージニア（us-east-1）など一部のリージョンでは base capacity の上限が最大 1,024 RPU まで設定できます。しかし 東京リージョン（ap-northeast-1）の上限は 512 RPU です。他リージョンのドキュメントや事例を参照する際は、必ず東京リージョンの仕様を確認してください。

4 RPU 設定時の制限事項

base capacity を 4 RPU に設定すると、以下の制限が生じます。

• 管理ストレージ 32 TB を超えるデータの管理不可
• クロスAZ 機能の利用不可

また、一度 4 RPU より高い値にスケールアップした後は 4 RPU に戻すことが困難になる場合があります。本番環境では 32 RPU 以上を起点とした設計が推奨されます。

max capacity（スケール上限 RPU）の設定

AI 駆動スケーリングの RPU 上限値が max capacity です。base capacity 以上の値を設定します。予期しない大規模クエリや暴走クエリによるコスト急増を防止するために、ワークロードの最大需要を踏まえた適切な上限設定が重要です。

3-4. 課金モデル：RPU-hr と最小課金 60 秒

課金の仕組み

Redshift Serverlessの compute 課金は RPU-hr（RPU 時間） 単位で計算されます。

⚠️ 精度の罠①：最小課金は「60 秒（1分）」です

「RPU-hour 課金」という表現から「1時間単位の課金」と誤解されることがありますが、実際は 秒単位で計測し、最小課金時間は 60 秒 です。

計算例：128 RPU で 10 秒のクエリを実行した場合
→ 最小 60 秒として換算
→ 課金 = 128 RPU × (60 ÷ 3,600) hr = 128 × 1/60 RPU-hr

課金が発生するケース

キャンセルしたクエリやヘルスチェッククエリも課金対象になる点は見落とされやすいため、注意が必要です。

3-5. コスト最適化：usage limit と CloudWatch モニタリング

コスト制御の 2 軸

Serverlessのコストを上限管理する方法は主に 2 つあります。

軸①：max capacity（スケール上限 RPU）

workgroup の自動スケーリング RPU 上限を制限します。price-performance target の設定に関係なく、max capacity は 常に強制適用 されます（公式ドキュメント明言）。これにより予期しないコスト急増を防止できます。

軸②：Max RPU-hours（usage limit）

一定期間（日次・週次・月次）の RPU-hr 消費量に上限を設けます。上限到達時のアクションを 3 段階で設定可能です。

CloudWatch によるモニタリング

Amazon CloudWatch では AWS/Redshift-Serverless 名前空間のメトリクスを使って使用量をリアルタイム監視できます。

月次の usage limit を CloudWatch アラームと組み合わせることで、予算超過を自動検知して適切なアクションをとる運用が実現できます。

クエリ最適化による RPU 削減

RPU 消費量はクエリの複雑度と処理データ量に直接依存します。以下の最適化が有効です。

• WHERE 句による絞り込みを徹底し、不要なフルスキャンを回避する
• EXPLAIN コマンドで実行計画を確認し、コストの高い HASH JOIN を最適化する
• ソートキー・DISTKEY の設計でスキャン対象データを最小化する
• VACUUM / ANALYZE を定期実行し、統計情報を最新の状態に保つ

3-6. Serverless の制限事項

Serverlessはシンプルな運用が魅力ですが、プロビジョンドクラスターが提供する一部の機能が利用できません。

スナップショット

• 自動スナップショットは非対応 です（プロビジョンドRA3ではデフォルト有効）
• 手動スナップショットのみ取得可能です
• 重要なデータは定期的な手動スナップショット運用での保護が必要です

マルチAZ（Multi-AZ）

• ServerlessはシングルAZ稼働が基本です（プロビジョンドRA3/RGのマルチAZ構成とは異なります）
• AZ 障害に対する高可用性を優先する場合は、プロビジョンドの Multi-AZ 構成を検討してください

WLM（Workload Management）

• Serverlessは 常に自動WLM で動作します
• 手動WLM（キュー設定・メモリ割り当ての精密な制御）はプロビジョンドのみ利用可能です
• Serverlessのワークロード制御は max capacity・Max RPU-hours・クエリタイムアウトの組み合わせで実現します

RA3 専用機能との違い

• Concurrency Scaling：プロビジョンドRA3/RGの専用機能です。Serverlessでは自動スケーリング自体が同等の役割を担います
• クロスリージョン自動スナップショット：自動スナップショット自体が非対応のため利用不可です（手動スナップショットは可能）
• Data Sharing：Serverlessはコンシューマー側として参加可能ですが、一部の機能に制限があります

3-7. Serverless vs プロビジョンドのコスト判断

ワークロードの特性によって、ServerlessとプロビジョンドRA3のどちらが適切かが変わります。

Serverless が向くケース

• クエリ実行が断続的・時間帯で偏りがある（深夜無人・日中集中型）
• 開発・テスト・PoC 環境でアイドル時間が長い
• BI ツールや ad hoc クエリが主体で同時実行数の波が大きい
• サーバー管理・パッチ適用・ノードリサイズの運用工数を削減したい

プロビジョンドRA3 が向くケース

• 24 時間 365 日、常時高負荷なバッチ処理が走るDWH
• 大規模データセット（数百TB以上）の大量並列処理
• 手動WLMによるキュー優先度・メモリ配分の精密な制御が必要
• 自動スナップショット + マルチAZ 構成による高可用性が要件に含まれる

コスト試算の目安

正確なコスト計算には東京リージョン（ap-northeast-1）の最新単価（AWS 公式 Pricing ページ）での確認を推奨します。一般的な傾向として、月間 compute 稼働率が 60 ～ 70% を超える場合はプロビジョンドの方が総コストで優位になるケースが多くなります。稼働率が低いほど Serverlessの「アイドル課金ゼロ」のメリットが効いてきます。

4. WLM・同時実行スケーリング・クエリ優先度

4-1. WLM（自動 vs 手動）

Redshiftのワークロード管理（WLM）は、複数クエリが同時実行される環境でメモリ・同時実行数・優先度を制御する仕組みです。WLMには自動WLMと手動WLMの2モードがあり、公式ドキュメントは「In most cases we recommend automatic WLM」と明言しています。

自動WLM（推奨）

自動WLMでは、Redshiftがクラスターの状態をリアルタイムで監視し、メモリ割当・同時実行数・キュー優先度を動的に調整します。

• キュー数: 最大8キューを設定できます（スーパーユーザーキューは変更不可で別途存在します）
• 優先度設定: LOWEST / LOW / NORMAL（デフォルト）/ HIGH / HIGHEST / CRITICAL の6段階
• メモリ管理: Redshiftが自動配分するため、memory_percent_to_use の手動設定は不要です
• SQA: 短時間クエリを優先処理するSQA（Short Query Acceleration）と組み合わせて効果を発揮します
• QMRルール: 自動WLMキューでもLOG/ABORTルールは設定できます

自動WLMが向くケース：
– BIツール・ETL・アドホッククエリが混在する混合ワークロード環境
– WLMチューニングコストを抑えながら安定運用したい場合

手動WLM（上級者向け）

手動WLMでは、各キューのメモリ割当・同時実行数・タイムアウトを明示的に設定します。細かい制御が可能な一方、チューニングコストが高くなります。

手動WLM固有の制約（重要）：
– クエリ優先度（priority）は自動WLMでのみ有効です。手動WLMでは使用できません。
– QMRの HOP（別キューへの転送アクション）は手動WLMでのみ有効です。自動WLMでは使用できません。

自動 vs 手動 WLM 比較

4-2. クエリ優先度とSQA

クエリ優先度（自動WLM限定）

自動WLMでは、セッションやクエリグループにクエリ優先度を設定することで、Redshiftがリソース配分を動的に調整します。優先度は以下の6段階です（デフォルトは NORMAL）。

設定方法は、Redshift コンソールのWLMキュー設定でグループを作成し、SET query_group TO 'グループ名' でルーティングします。

-- セッション単位でキューをルーティングする例
SET query_group TO 'etl_high';
-- この後に実行するクエリは priority=HIGH のキューへ転送されます

SQA（Short Query Acceleration）

SQA（Short Query Acceleration）は、実行時間が短いと予測されるクエリを専用の高速レーンで優先処理する機能です。

• 有効化: default parameter group および全ての新規 parameter group でデフォルト有効（enable_short_query_acceleration = true）。既存のカスタム parameter group では設定を確認してください。
• 対象クエリ: SELECT（読取クエリ）および CTAS（CREATE TABLE AS SELECT）が対象です
• 対象外: INSERT / UPDATE / DELETE はSQAの対象外です
• 最大実行時間: max_query_execution_time でSQAキューの最大秒数を設定します（auto 推奨）

SQAが効果的なケース：
– BIツール（QuickSight等）からの小規模 SELECT クエリが、ETLの大規模スキャンによって待たされている環境
– 数行の集計クエリとフルテーブルスキャンETLが同一クラスターで混在している場合

クエリモニタリングルール（QMR）

QMRは、実行中クエリをルールベースで監視・制御します。クエリの実行時間・スキャン行数・返却行数などのメトリクスに基づいてアクションをトリガーできます。

手動WLMでのABORTルール設定例：

-- parameter group で設定（コンソール/CLI/CloudFormation）
-- ルール: 実行時間 3600秒超のクエリを強制終了
-- metric: query_execution_time, value: 3600, action: abort

4-3. 同時実行スケーリング（Concurrency Scaling）

同時実行スケーリング（Concurrency Scaling）は、クエリ負荷が高まったときに追加クラスターを自動起動してクエリを分散処理する機能です。メインクラスターのキューがビジー状態になると、Redshiftが数秒以内に追加クラスターを立ち上げてクエリを自動ルーティングします。

仕組み

1. WLMキューの同時実行スケーリングモードが auto に設定されている状態で、クエリが待機状態になります。
2. Redshiftが追加クラスターを自動起動します（数秒以内）。
3. 追加クラスターはメインクラスターと同じデータにアクセスし、クエリを並列処理します。
4. 負荷が低下すると、追加クラスターは自動シャットダウンされます。

無料クレジット枠（精度注意）

具体例：
– クラスターが1台の場合、最大で 30時間 × 1台 = 30時間 が上限クレジット量です。
– クラスターが2台の場合、それぞれが独立して最大30時間まで蓄積できます。
– 24時間以上クエリがゼロでも、アクティブなクラスターには毎日1時間分が付与されます。

使用量の確認には STL_CONCURRENCY_SCALING_USAGE システムビューを活用してください。

対応クエリの範囲

対応範囲はノード種別によって異なります。

RA3 / RG ノード（プロビジョンド）:

DC2 ノード（旧世代プロビジョンド）:
– 読取クエリのスケーリングのみ対応します。
– 書込スケーリングは DC2 では利用できません。RA3 / RG ノードへの移行が推奨されます。

WLMキューでの有効化

同時実行スケーリングはキュー単位で有効・無効を設定します。

-- Redshift コンソール → Workload Management → キュー設定
-- "Concurrency scaling mode" を "auto" に設定します
-- 特定キューのみスケーリング対象にすることで課金を制御できます

4-4. Serverlessにおけるワークロード管理

Redshift Serverlessでは、WLMのモードは常に自動WLMです。プロビジョンドクラスターのように手動WLMへ切り替えることはできません。代わりに、RPU自動スケーリング・workgroup単位のQMR・usage limitsという3つのメカニズムでワークロードを管理します。

RPU自動スケーリング

Serverlessは、クエリ負荷に応じてRPU（Redshift Processing Unit）を自動的にスケールアップ・ダウンします。

• Base capacity: workgroupごとに設定します（東京: 4〜512 RPU・デフォルト128 RPU）
• スケーリング動作: ベース容量を超える負荷ではRPUが自動増加し、負荷低下後は縮退します
• 課金: クエリ実行時のRPU-秒単位（最低60秒）・アイドル時はcompute課金ゼロです

プロビジョンドの Concurrency Scaling に相当する追加クラスター起動は Serverless では不要です。Serverless自身がRPU増減で対応します。

workgroup単位のQMR（クエリモニタリングルール）

Serverlessでは、workgroupにQMRを設定してクエリを監視・制御できます。

Serverless QMR 設定例：

-- コンソール / CloudFormation / API で設定します
-- metric: query_execution_time, value: 7200, action: abort
-- → 2時間超のクエリを自動強制終了します

usage limits（コスト上限設定）

Serverlessでは、RPU使用量に対して上限（usage limits）を設定することでコストを制御できます。

usage limitsはコスト予算の安全弁として機能します。上限に達してもデータは失われませんが、設定したアクションに従って新規クエリを制限できます。

5. zero-ETL 統合（Aurora/RDS → Redshift）

5-1. zero-ETLとは

zero-ETL 統合は、ソースデータベースの変更を ETL パイプラインを介さずに Redshift へ自動的にレプリケートする AWS の仕組みです。
Glue ジョブや Lambda 関数を構築・管理する必要がなく、ソース側での更新が Redshift のテーブルへほぼリアルタイムに反映されます。

ただし「ほぼリアルタイム」の実態は ソースによって大きく異なります。この点が最大の精度の罠です。

DynamoDB を zero-ETL の対象にする場合は「最小 15 分の遅延」が存在します。
Aurora/RDS は数秒〜数十秒のレイテンシですが、DynamoDB は最小 15 分です。レイテンシの特性が異なるため、一律に「ほぼリアルタイム」と表現しないよう注意してください。

動作の流れは次のとおりです。

1. 初回フルロード（seed）: 統合作成時にソーステーブルの全データを Redshift へ一括ロード
2. 増分レプリケーション（CDC）: その後はソース側の変更（INSERT / UPDATE / DELETE）を継続的に適用

Redshift 側では統合に対応した専用データベースとスキーマが自動生成されます。
アナリストはそのテーブルに SELECT するだけで、常に最新に近い状態のデータを参照できます。

5-2. 対応ソースと前提

東京リージョン（ap-northeast-1）で GA 済みの主要ソース

東京リージョン以外では Oracle Database@AWS や Salesforce 等の SaaS ソースにも対応が拡大していますが、サービスのライフサイクルやリージョン展開状況は定期的に公式ドキュメントで確認してください。

Redshift 側の前提条件

zero-ETL を利用できる Redshift の構成は限定されています。

• 対応クラスタータイプ: Serverless ワークグループ または RA3（ra3.xlplus / ra3.4xlarge / ra3.16xlarge）
• DC2 / DS2 クラスターは ターゲットとして使用不可
• ターゲットデータベースへの 書き込み（CREATE TABLE / CREATE VIEW 等）は不可（読み取り専用）
• 1 ターゲットあたり最大 50 統合まで
• ターゲット Redshift クラスター / ワークグループの 暗号化が必須

ソース側の前提条件

主キーのないテーブルはレプリケーション対象外となるため、既存スキーマを棚卸しして主キーの有無を事前確認しておきましょう。

5-3. 統合の作成と制限事項

Aurora / RDS の場合の設定手順

ステップ 1 — ソース DB の binlog 設定

Aurora MySQL 互換の場合、パラメータグループで次の値を設定します。

-- Aurora MySQL 互換のパラメータグループ確認
SHOW VARIABLES LIKE 'binlog_format';
-- ROW であることを確認

-- binlog retention 設定（最低 24 時間推奨）
CALL mysql.rds_set_configuration('binlog retention hours', 24);

Aurora PostgreSQL 互換の場合はパラメータグループで rds.logical_replication = 1 を有効にします。

ステップ 2 — Redshift 側で統合を作成

AWS マネジメントコンソールまたは CLI から零 ETL 統合を作成します。

# AWS CLI での zero-ETL 統合作成（Aurora → Redshift Serverless の例）
aws redshift create-integration \
  --source-arn arn:aws:rds:ap-northeast-1:123456789012:cluster:my-aurora-cluster \
  --target-arn arn:aws:redshift-serverless:ap-northeast-1:123456789012:workgroup/my-workgroup \
  --integration-name my-zero-etl-integration \
  --region ap-northeast-1

統合を作成すると Redshift 側に専用データベースが自動生成され、初回フルロード（seed）が開始されます。
seed 完了後は増分レプリケーション（CDC）に切り替わり、ソース側の変更が継続的に反映されます。

ステップ 3 — Redshift 側でデータを参照

-- 自動生成されたデータベースへ接続して確認
SELECT table_schema, table_name, table_type
FROM information_schema.tables
WHERE table_schema NOT IN ('information_schema', 'pg_catalog')
ORDER BY table_schema, table_name;

-- レプリケーション状態の確認
SELECT * FROM SYS_INTEGRATION_TABLE_STATE;

DynamoDB の場合の設定手順

DynamoDB の場合、DynamoDB Streams の有効化に加え、IAM リソースポリシーで Redshift からのアクセスを許可する必要があります。

# DynamoDB Streams 有効化
aws dynamodb update-table \
  --table-name my-table \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
  --region ap-northeast-1

DynamoDB の zero-ETL では REFRESH_INTERVAL パラメータを調整することで、15 分〜最大 24 時間の取り込み間隔を設定できます。
デフォルトの 15 分が最小値であり、これより短くできません。

制限事項まとめ

レプリケーション状態のモニタリング

統合が正常に動作しているかどうかは、Redshift の管理ビューで確認できます。

-- 統合全体のステータス確認
SELECT integration_id, status, error_message, last_sync_time
FROM SYS_INTEGRATION_STATUS
ORDER BY last_sync_time DESC;

-- テーブルごとのレプリケーション状態確認
SELECT schema_name, table_name, status, rows_loaded, last_updated_at
FROM SYS_INTEGRATION_TABLE_STATE
ORDER BY schema_name, table_name;

status カラムが Syncing であれば正常なレプリケーション中です。Failed や Suspended が表示された場合は error_message を確認し、ソース DB の設定や IAM 権限を見直してください。

CloudWatch メトリクスでも IntegrationStatus や IntegrationLatency を監視できます。
DynamoDB の場合は IntegrationLatency が常に 15 分前後であることが正常な動作です。
Aurora/RDS の場合に数分を超えるレイテンシが継続する場合は、binlog の遅延やネットワーク帯域の問題を疑いましょう。

5-4. zero-ETL vs 従来ETLの判断

zero-ETL の採用が適切なケースと、Glue 等の従来 ETL が引き続き必要なケースを整理します。

zero-ETL が向くケース

従来 ETL（Glue 等）が引き続き必要なケース

Glue を使ったデータ変換や DMS を使った移行設計については、他記事（AWS データ分析基盤系シリーズ）への委譲を推奨します（差別化維持）。

AWS 公式: zero-ETL 統合の使用方法

6. Data Sharing（クロスアカウント/クロスリージョン）

6-1. Data Sharing の仕組み

Amazon Redshift Data Sharing は、複数の Redshift クラスターまたは Serverless workgroup 間で、データをコピーや移動させることなくライブデータを共有できる機能です。プロデューサー側のクラスターがデータを所有・管理し、コンシューマー側のクラスターがそのデータを参照するという構成をとります。

datashare とは何か

datashare は、共有するデータの論理的なコンテナです。プロデューサー側のクラスター（または Serverless workgroup）が datashare を作成し、共有対象のデータベースオブジェクトを追加します。コンシューマー側はこの datashare をもとに外部データベースを作成し、通常の SQL で参照できます。

Data Sharing の最大の特徴は ライブ共有 です。プロデューサー側でデータが更新されると、コンシューマー側は次のクエリで最新データを参照できます。データのコピーや転送が不要なため、ストレージコストの重複が生じません。ETL パイプラインを別途構築することなく、リアルタイムに近い形でデータ参照が可能です。

datashare に追加できるオブジェクト

datashare に追加できるオブジェクトは次のとおりです。

• データベース内の特定スキーマ
• スキーマ内のテーブル（内部テーブル）
• ビュー（通常ビュー・レイトバインドビュー）
• マテリアライズドビュー（MV）
• UDF（ユーザー定義関数）

外部テーブル（Spectrum）や一時テーブルは datashare に追加できません。また、コンシューマー側は外部データベース内にテーブルやビューを作成できません。

共有タイプの分類

Data Sharing には次の 4 つの共有タイプがあります。

6-2. RA3/Serverless 前提（DC2/DS2 非対応）

Data Sharing を利用するには、プロデューサー・コンシューマーの双方に RA3 ノードまたは Serverless が必須です。旧世代ノードの DC2・DS2 は、プロデューサー側・コンシューマー側のいずれにも使用できません。

対応ノードタイプ

Data Sharing を目的として新規クラスターを作成する場合は、最初から RA3 または Serverless を選択してください。既存の DC2 クラスターから Data Sharing に移行するには、RA3 クラスターリサイズまたは Serverless への移行が前提となります。

暗号化の要件

クロスアカウント共有およびクロスリージョン共有では、プロデューサーとコンシューマーの 両クラスターで暗号化が必須 です。AWS KMS による暗号化を有効化していない状態では、クロスアカウント / クロスリージョンの datashare を承認・関連付けできません。同一アカウント・同一リージョン（クロスクラスター）内の共有に暗号化必須要件はありませんが、本番環境での有効化を推奨します。

プロデューサー側の datashare 作成手順

-- 1. datashare を作成する
CREATE DATASHARE salesdata_share;

-- 2. スキーマを追加する
ALTER DATASHARE salesdata_share ADD SCHEMA sales;

-- 3. テーブルを個別追加する
ALTER DATASHARE salesdata_share ADD TABLE sales.orders;
ALTER DATASHARE salesdata_share ADD TABLE sales.customers;

-- スキーマ以下の全テーブルを一括追加する場合
ALTER DATASHARE salesdata_share ADD ALL TABLES IN SCHEMA sales;

6-3. クロスアカウント/クロスリージョン共有

クロスアカウント共有の手順（2-way ハンドシェイク）

クロスアカウント共有は、プロデューサーとコンシューマーの 2 段階の承認が必要です。プロデューサー側が datashare を作成してコンシューマーアカウントへ利用権限を付与し、コンシューマー側がインバウンドシェアを受諾して外部データベースを作成することで共有が完成します。

プロデューサー側: コンシューマーへの承認

-- コンシューマーの AWS アカウント ID を指定して利用権限を付与する
GRANT USAGE ON DATASHARE salesdata_share TO ACCOUNT '123456789012';

GRANT USAGE ON DATASHARE を実行すると、指定した AWS アカウントに datashare の利用権限が付与されます。AWS Management Console の「Manage datashares」→「Grant access to specific AWS accounts」からも設定できます。

コンシューマー側: インバウンドシェアの受諾と外部データベースの作成

-- 1. インバウンドシェアを一覧表示して namespace を確認する
SELECT share_name, producer_account, producer_namespace
FROM SVV_DATASHARES
WHERE share_type = 'INBOUND';

-- 2. 外部データベースを作成してシェアを関連付ける
CREATE DATABASE salesdata_db
  FROM DATASHARE salesdata_share
  OF ACCOUNT '111122223333'
  NAMESPACE 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx';

-- 3. 参照クエリを実行する（外部DB名.スキーマ名.テーブル名 の形式）
SELECT COUNT(*) FROM salesdata_db.sales.orders;

CREATE DATABASE ... FROM DATASHARE 実行時は、プロデューサーのクラスター namespace（一意識別子）を正確に指定します。SVV_DATASHARES ビューで producer_namespace を確認してください。外部データベースを作成した後は、通常の SQL で SELECT 文を実行するだけで、プロデューサー側のライブデータを参照できます。

クロスリージョン共有

クロスリージョン共有は、異なる AWS リージョン間でデータを読み取り共有する機能です。たとえば東京リージョンのプロデューサークラスターから大阪リージョンのコンシューマークラスターへ datashare を提供できます。

設定手順はクロスアカウント共有と基本的に同様です。コンシューマー側では CREATE DATABASE ... FROM DATASHARE にプロデューサーのアカウント ID と namespace を指定するだけで、リージョン間の接続が確立されます。

クロスリージョン共有では追加のネットワークレイテンシが発生します。東京〜大阪間でもリージョン間通信が必要なため、リアルタイムダッシュボードのような低レイテンシが求められる用途には不向きです。BCP / DR 目的でのリードレプリカ的活用や、地理的に分散したチームへの分析データ共有に適した機能です。

クロスアカウント/クロスリージョン共有のコスト

同一リージョン内の共有ではデータ転送課金は発生しません。プロデューサーはストレージコストを、コンシューマーはクエリ実行時のコンピュートコストをそれぞれ負担します。

クロスリージョン共有では、コンシューマー側がデータ転送料を負担します。転送料の課金はスキャンしたバイト数単位で、1 クエリあたり最小 10 MB の切り上げが適用されます。大量データをスキャンするクエリを頻繁に実行する場合はコストが蓄積しやすいため、必要なカラムのみを取得する SELECT 文を心がけてください。

6-4. データメッシュ的な活用

Data Sharing は、データメッシュアーキテクチャの実装基盤として活用できます。データメッシュとは、組織内の各ドメイン（部門・チーム）がデータの所有権と提供責任を持ち、他ドメインへデータを提供する分散型データ管理手法です。

部門別データ共有の設計例

大規模組織では、部門ごとに独立した Redshift クラスターを持ちつつ、必要なデータを相互に共有するアーキテクチャが有効です。

[Sales クラスター]──datashare──▶ [Analytics クラスター]
[HR クラスター]──datashare──▶ [Analytics クラスター]
[Finance クラスター] ──datashare──▶ [Analytics クラスター]

各部門クラスターがプロデューサーとなり、分析専用の Analytics クラスターがコンシューマーとして各データを参照します。部門クラスターは自部門のデータを自律的に管理し、アクセス制御も部門単位で完結します。分析チームは複数の datashare を組み合わせることで、組織横断分析を単一クラスターから実行できます。ETL パイプラインを別途構築することなく、部門間のデータ連携を実現できます。

マルチテナント SaaS での活用

SaaS サービスを提供する場合、テナントごとに独立した Redshift namespace（Serverless workgroup）を持ちつつ、共通の分析データをテナントへ提供するパターンも有用です。GRANT USAGE ON DATASHARE ... TO ACCOUNT でテナントの AWS アカウント ID を指定することで、テナント分離を維持しながら datashare でデータを提供できます。テナントは自身の Redshift クラスターから外部データベースとして参照でき、データの複製も不要です。

コンシューマー側のアクセス制御

コンシューマー側で外部データベースを作成した後は、通常の Redshift ユーザー / ロール管理でアクセス制御を行えます。外部データベース内のオブジェクトに対して GRANT SELECT を適用できるため、コンシューマークラスター内でも細粒度の権限管理が可能です。

-- コンシューマー側でのロール権限付与例
GRANT SELECT ON ALL TABLES IN SCHEMA salesdata_db.sales TO ROLE analyst_role;

Managed Data Sharing（AWS Data Exchange 連携）

AWS Data Exchange と連携した Managed Data Sharing を利用すると、外部のサードパーティへデータを提供するマーケットプレイスを構築できます。自社の分析データを外部企業へ販売・提供する際に活用できます。プロデューサーは AWS Data Exchange でデータセットを公開し、サブスクライバーである外部企業がコンシューマーとしてデータを参照する形になります。

Data Sharing 運用上の注意点

プロデューサー側でテーブルのカラムを削除・リネームすると、コンシューマー側のクエリが失敗します。スキーマを変更する際は、事前にコンシューマー側への影響確認と調整が必要です。API のバージョン管理と同様に、変更管理プロセスを整備することを推奨します。

また、1 つのクラスターが持てる datashare 数や、1 クラスターへの関連付け数には上限があります。大規模なデータメッシュ展開を計画する場合は、公式ドキュメントの制限値を事前に確認してください。

7. Spectrum（S3外部テーブル・コスト設計）

7-1. Spectrumの仕組み

Redshift Spectrumは、Amazon S3に保存されたデータをRedshiftクラスターやServerlessワークグループから直接クエリできる機能です。データをRedshiftにロードする前処理が不要で、S3上のデータを外部テーブルとして定義するだけで、ローカルテーブルと同様のSQLでアクセスできます。大規模なS3データレイクとRedshift DWH機能を組み合わせる際の中核となる機能です。

外部テーブルを使うにはまず外部スキーマを作成します。外部スキーマは以下3種類のカタログを参照できます。

外部スキーマの作成はCREATE EXTERNAL SCHEMA文で行います。

-- Glue Data Catalogを参照する外部スキーマの作成例
CREATE EXTERNAL SCHEMA spectrum_schema
FROM DATA CATALOG
DATABASE 'my_glue_database'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftSpectrumRole'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

外部スキーマを作成すると、Glue Data Catalog内のテーブル定義がRedshiftから参照可能になります。Glue Crawlerで自動検出したテーブルもそのままクエリ対象となるため、S3データレイクとRedshift DWHの橋渡し役として機能します。

外部テーブルを個別に定義する場合はCREATE EXTERNAL TABLE文を使用します。

-- Parquet形式・パーティション付き外部テーブルの定義例
CREATE EXTERNAL TABLE spectrum_schema.sales (
 order_id BIGINT,
 customer_id BIGINT,
 amountDECIMAL(10,2)
)
PARTITIONED BY (order_year INT, order_month INT)
STORED AS PARQUET
LOCATION 's3://my-datalake-bucket/sales/';

Spectrumの主な制約は以下のとおりです。

• 書き込み不可（読み取り専用）: 外部テーブルへのINSERT/UPDATE/DELETEはできません
• DDL制限: テーブル定義の変更はGlue Data Catalogを通じて行う必要があります
• 同一リージョン必須: RedshiftクラスターまたはServerlessワークグループとS3バケットは同じリージョンに配置してください

クエリ実行の内部動作についても押さえておきましょう。RA3/DC2プロビジョンドクラスターの場合、SpectrumはRedshiftとは独立した専用データレイクサーバーフリートでS3データを処理します。一方、Serverless/RG（Graviton版）クラスターでは自前コンピュートリソース上の統合データレイクエンジンが実行します。「Spectrumは常に別サーバーで動く」と一般化すると誤りになるため注意が必要です。

7-2. コスト構造（RA3とServerlessの違い）

Spectrumのコスト構造はクラスター種別によって根本的に異なります。この点は誤解が多いため、整理して押さえておきましょう。

RA3プロビジョンドクラスターの場合

スキャンデータ量に応じた別途課金（$5/TB・東京リージョン、2026年時点の参考単価。正確な最新単価はAWS公式料金ページでご確認ください） が発生します。

RA3でのSpectrumコスト最適化は、いかにスキャン量を減らすかが直接的な削減策になります。

① パーティション設計でスキャン対象ファイルを限定する

日付・地域・カテゴリなどのカラムでS3オブジェクトをパーティション分割しておくと、WHERE句によるパーティションプルーニングで読み取るファイルが限定されます。

-- パーティションキーをWHERE句に含めることでスキャン範囲を絞り込む例
SELECT order_id, amount
FROM spectrum_schema.sales
WHERE order_year = 2024 AND order_month = 1;
-- → 2024年1月分のS3ファイルのみスキャン（他月はスキップ）

WHERE句にパーティションキーを含めなかった場合は全パーティションのフルスキャンになります。パーティションキーの設計はクエリのアクセスパターンに合わせることが重要です。

② 列指向フォーマット（Parquet/ORC）でスキャン列を最小化する

Parquet・ORCは列指向フォーマットです。SELECT句に指定したカラムのデータブロックのみを読み取るため、全カラムを含むCSV/JSONと比較して大幅にスキャン量を削減できます。

GzipはCSVの圧縮率は高いものの、ファイルが1つのスプリットとして扱われるため並列読み取り効率が低下します。ParquetはRowGroup単位でスプリット可能なため、大規模データでも並列度を維持できます。

③ 述語プッシュダウン（Predicate Pushdown）を活かす

Parquet/ORCはファイル内にカラムごとの統計情報（最大値・最小値・null数）を持つメタデータブロックを含みます。SpectrumはこのRow Group統計を参照し、WHERE条件を満たす可能性のないRow Groupをスキップします。これにより同じParquetファイル内でも不要なデータブロックの読み取りを省略でき、実際のスキャンバイト数がさらに減少します。

Serverlessワークグループの場合

ServerlessでSpectrumを使う場合、$5/TBのスキャン課金は発生しません。 S3外部テーブルへのクエリもRPU-hrの課金に内包されます。

Serverlessであっても、スキャン量が少ないほどクエリ処理時間が短縮され、結果としてRPU消費量が減ります。「ServerlessだからSpectrumのスキャン量を気にしなくてよい」は誤りで、Parquet化とパーティション設計は引き続き有効なコスト最適化手段です。

7-3. パフォーマンス最適化

Spectrumクエリのパフォーマンス最適化は、以下の3つの観点から段階的に進めます。

S3データのフォーマット最適化

最優先で取り組むべきはParquetへの変換です。既存のCSVデータをAWS Glue ETLジョブやAmazon EMRでParquet変換するだけで、クエリ速度が数倍改善するケースも珍しくありません。

Parquet変換時の推奨設定は以下のとおりです。

パーティション管理

S3プレフィックス階層とRedshift外部テーブルのパーティション定義を一致させた後、パーティション情報をカタログに登録する必要があります。Glue Crawlerを使用している場合は定期スケジュール実行でパーティションが自動検出・登録されます。手動登録する場合はALTER TABLE文を使用します。

-- パーティションの手動追加例
ALTER TABLE spectrum_schema.sales
ADD PARTITION (order_year=2024, order_month=3)
LOCATION 's3://my-datalake-bucket/sales/order_year=2024/order_month=3/';

Glue Crawlerのスケジュールを新しいS3データのパーティション追加頻度に合わせておくと、手動追加の手間を省けます。

クエリの書き方

• パーティションキーを必ずWHERE句に含める: 含まれない場合は全パーティションスキャンになります。クエリテンプレートにパーティションキーが欠落していないか定期確認が有効です
• SELECT句のカラム絞り込み: SELECT * を避け、必要なカラムのみ指定します。Parquet/ORCの列指向の恩恵を最大化できます
• LIMIT節の注意: LIMIT n はSpectrumのS3スキャン段階では適用されないため、LIMIT指定だけではスキャン量が減りません。WHERE句での絞り込みが必要です

小ファイル問題への対処

S3上のファイルが極端に小さい（数KB〜数十KB）と、メタデータオペレーションのオーバーヘッドがデータ読み取り時間を上回るようになります。目安として1ファイル128MB以上に統合することを推奨します。Glue ETLの定期統合ジョブを組み合わせると効果的です。

7-4. SpectrumとRedshiftローカルテーブルの使い分け

Spectrumが最も威力を発揮するのは「S3上の大量データをRedshiftへのロードなしにクエリしたい」ケースです。一方でクエリ頻度が高いホットデータはRedshiftローカルテーブルに保持し、アクセス頻度が低いコールドデータをS3 Spectrumで参照するホット/コールドデータ階層設計が典型的なパターンです。

アーカイブ自動化の例: 直近3ヶ月をRedshiftローカルテーブルで保持し、それ以前のデータをUNLOAD（Parquet形式でS3へエクスポート）→ローカルテーブルから削除する定期バッチを組み合わせると、ストレージコストを抑えながら過去データへのクエリ能力を維持できます。

-- 古いデータをS3にアンロードする例（Parquet形式・パーティション付き）
UNLOAD ('SELECT * FROM sales WHERE order_date < ''2024-01-01''')
TO 's3://my-datalake-bucket/archive/sales/'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftRole'
FORMAT AS PARQUET
PARTITION BY (order_year, order_month);

SpectrumとRedshiftローカルテーブルは同一SQLクエリ内でJOINできます。ローカルテーブルのディメンション（顧客マスター・商品マスター等）とS3上のファクト（過去の売上ログ等）をJOINする構成が典型的です。この場合、SpectrumのS3スキャン部分と、ローカルテーブルのスキャン部分は並列実行されます。

8. まとめ・コスト最適化・運用ベストプラクティス

8-1. Redshift DWH本番運用の全体像（再掲）

本記事ではAmazon Redshiftをデータウェアハウス単体として本番運用するための主要技術を体系的に解説しました。各章の要点を振り返ります。

これらの機能はそれぞれ独立して使えますが、組み合わせることでRedshiftの本領が発揮されます。例えばzero-ETL統合でOLTPデータをServerlessに取り込み、Spectrumで過去のS3アーカイブと結合しながら、Data Sharingで分析チームに安全にデータを提供する、という構成が現実的なユースケースとして成立します。

8-2. コストの考え方

Redshiftの課金は複数の要素から構成されており、それぞれの最適化ポイントが異なります。

ワークロード別コスト戦略の概要は以下のとおりです。

• 断続的・バースト型のワークロード: Serverlessが適しています。非実行時のコンピュート課金がゼロになり、usage limitsで月次予算の上限も設定できます。
• 定常的・24/7高負荷なワークロード: RA3プロビジョンドが適しています。Reserved Instanceの適用でさらにコストを下げられます。
• 過去データのアドホッククエリ: Spectrumを活用しS3上のParquetデータを直接クエリすることで、ローカルテーブルへの移行コストを削減できます。

Python UDFに関する重要な注記: Python UDFの新規作成は2026年6月30日で終了となっています（サービス全体の廃止ではなく、既存のPython UDFは引き続き利用可能です）。新規のカスタム処理はLambda UDF（Node.js/Java/Go等）への移行を検討してください。

8-3. 運用ベストプラクティスまとめ

本記事で取り上げた運用上の重要ポイントをまとめます。

ノード選定・容量設計
– 新規構築でプロビジョンドを選ぶ場合はRA3一択です。DC2は1TB未満の小規模構成では依然現役ですが、新規の大規模構成には不向きです。DS2は新規クラスター作成不可（廃止）です。
– Serverlessのbase capacityはデフォルト128 RPUです。ワークロードの実態に合わせて適切な値に調整し、Max capacityで上限を設定してください。

WLMとクエリ管理
– 自動WLMが公式推奨です。手動WLMは詳細制御が必要な上級者向けです。
– SQA（Short Query Acceleration）は新規パラメータグループでデフォルト有効です。短いクエリの応答時間改善に効果があります。
– Serverlessでは手動WLM選択不可です。QMR（最大25ルール）とusage limitsで管理してください。

データ設計
– 分散スタイルは大規模ファクトテーブルにはDIST KEY、小規模ディメンションはALL分散、中間規模はAUTO（自動選択）を基準にします。
– ソートキーはrange scanが多いカラム（日付等）を設定します。Compound / Interleaved ソートキーはアクセスパターンに応じて使い分けます。

VACUUM/ANALYZE
– Redshiftの自動VACUUM（Auto Vacuum）および自動ANALYZE（Auto Analyze）はデフォルトで有効です。大量のDELETE/UPDATE後は手動でVACUUMを実行することも検討してください。
– Spectrumのアーカイブ対象データはUNLOADでS3へ退避後にローカルテーブルからDELETEし、VACUUMで領域を回収します。

スナップショットとバックアップ
– 自動スナップショットはRA3/RGで無効化できません。デフォルト保持期間は1日ですが、RPO要件に応じて最大35日まで延長できます。
– DR要件がある場合はクロスリージョンスナップショットを設定します。

モニタリング
– CloudWatchメトリクス（DatabaseConnections / CPUUtilization / ReadIOPS等）とAmazon Redshift ConsoleのQuery Insightsを組み合わせて、クエリ性能とコストの双方を定期的に確認します。

8-4. 次巻予告・関連記事

本記事ではRedshift単体DWHの本番運用に必要な主要機能を網羅しました。Vol2以降では以下のような発展テーマを扱う予定です。

• マテリアライズドビュー（MV）の設計と自動リフレッシュ
• ML統合（Redshift ML / Amazon SageMaker連携）
• データ品質管理とスキーマ変更戦略
• 大規模マイグレーション（オンプレDWHからRedshiftへ）

分析パイプライン全体（Athena・Glue・Lake Formation・Redshiftの連携）については、以下の関連記事で体系的に解説しています。

AWS Data Analytics Vol1本番運用 — Athena × Glue × Lake Formation × Redshift

AWS Analytics/Data Lake本番運用Vol1 — Glue・Athena・Redshift

データレイク本番運用 Vol1 — Glue / Athena / Redshift