Amazon Redshift入門――AWSのDWHサービスの選び方と最適化

Amazon Redshiftは、AWSがネイティブに提供するクラウドDWHサービスで、S3・Glue・IAMといったAWSエコシステムとの深い統合が最大の強みです。2013年の登場時はリーダーノードとコンピュートノードから成る伝統的なMPPアーキテクチャでしたが、その後RA3インスタンスによるコンピュート・ストレージ分離、そしてRedshift Serverlessのリリースで選択肢が大幅に広がりました。本記事ではRedshiftのアーキテクチャ、主要機能、ProvisionedとServerlessの料金モデル、そして実務で効く最適化テクニックを整理します。AWS中心のデータ基盤を設計する方に向けて、Redshiftを選ぶべきか・どう使うべきかの判断材料を提供します。

Amazon Redshiftとは何か――AWSネイティブのクラウドDWH

Amazon Redshiftは、2013年にAmazon Web Servicesが提供開始したクラウドDWHサービスです。ParAccelというPostgreSQL系のMPP DWHをベースに開発されたため、PostgreSQL互換のSQL方言で操作できます。発売当時は「オンプレDWHをクラウドに持ち込む」という文脈で画期的な存在でしたが、その後SnowflakeやBigQueryが登場し、競争の焦点は「コンピュート/ストレージの分離」と「サーバーレス」に移りました。

Redshiftはこの流れに合わせて進化を続けており、RA3インスタンスで「Managed Storage」というコンピュートとストレージを分離した構成を導入、2021年にはRedshift Serverlessをリリースしました。現在はProvisionedモードとServerlessモードの2択から選ぶ設計です。AWS中心のデータ基盤では、S3連携・IAM・Glue・Lake Formationとの統合がシームレスな点で今も第一候補になり得ます。

Redshiftのアーキテクチャ

Redshiftのアーキテクチャを理解するには、Provisionedモードから見るのが分かりやすいです。リーダーノードが1台、コンピュートノードが複数台集まって1つのクラスターを構成します。リーダーノードはクエリを受け付けてプランを立て、コンピュートノードに処理を分散します。

【Redshiftクラスタ構成(Provisioned)】

      [Client / BI Tool]
              |
              v
      +----------------+
      | Leader Node    |
      |  (Plan/Coord)  |
      +----------------+
         |    |    |
         v    v    v
  [Compute] [Compute] [Compute]
   Node 1    Node 2    Node 3
         \    |    /
          v   v   v
      [Managed Storage (RA3)]
          (S3ベースの共有層)

※ RA3ではストレージが分離し、
  ノード追加時もデータ再配置が不要

一方Redshift Serverlessでは、ノード概念がユーザーから隠蔽され、「ワークグループ」と「ネームスペース」という抽象的な単位でクエリを実行します。RPU(Redshift Processing Unit)が自動スケールするため、運用者はサイズ見積もりから解放されます。

aws redshift-serverless create-namespace --namespace-name analytics-ns
aws redshift-serverless create-workgroup \
  --workgroup-name analytics-wg --namespace-name analytics-ns \
  --base-capacity 32

Redshiftの主な機能

Redshiftを支える5つの主要機能を紹介します。

1. Redshift Spectrum：S3上のデータをクラスタにロードせずに直接クエリできる機能です。データレイクとの連携で威力を発揮します。

2. AQUA(Advanced Query Accelerator)：FPGAベースのハードウェア高速化機能で、集計・スキャン系クエリを加速します(対応インスタンスが限定される点に注意)。

3. Materialized View：マテリアライズドビューとして事前計算結果を保持し、更新は自動的に反映可能です。複雑なBIクエリの高速化に有効です。

4. データシェアリング：複数クラスター間で同一データを物理コピーなしに共有できる機能です(RA3限定)。

5. Amazon SageMaker連携：Redshift ML機能でSQL内からSageMakerモデルの学習・推論が呼び出せ、MLをSQLに統合できます。

-- Redshift Spectrumの外部テーブル作成
create external schema spectrum_sales
from data catalog
database 'analytics_db'
iam_role 'arn:aws:iam::123456789012:role/RedshiftSpectrumRole';

create external table spectrum_sales.orders (
  id bigint, user_id bigint, amount numeric(10,2), order_date date
)
stored as parquet
location 's3://my-bucket/orders/';

機能	概要	ユースケース	競合比較
Redshift Spectrum	S3データを直接SQL	データレイク統合、長期保存の分析	Athenaとの競合だが既存Redshiftと一貫
AQUA	ハードウェア加速	集計・スキャン中心ワークロード	競合DWHには同等機能なし
Materialized View	事前計算結果を保持	BIダッシュボード高速化	Snowflake/BigQueryも類似機能あり
データシェアリング	クラスター間共有	本番/開発の分離、取引先共有	Snowflake比で機能成熟度はやや劣る
Redshift ML	SageMakerとの統合	予測モデル、推論のSQL化	BigQuery MLに類似

料金モデルと最適化

Redshiftの料金モデルは、ProvisionedとServerlessの2系統があります。

Provisioned：ノードインスタンスを時間単位で課金するモデルです。オンデマンド・1年予約・3年予約があり、予約購入で最大75%のコスト削減が可能です。安定した本番ワークロード向けです。

Serverless：RPU(Redshift Processing Unit)の使用量に応じた従量課金です。使っていない時間は課金されないため、断続的なワークロードに向きます。新規導入ならServerlessからスタートするのが推奨されます。

課金方式	コスト特性	適するワークロード	最小コストの目安
Provisioned(オンデマンド)	ノード時間課金	常時稼働・大規模本番	dc2.large時間約$0.25〜
Provisioned(1/3年予約)	前払いで最大75%削減	中長期確定ワークロード	要見積もり
Serverless	RPU秒課金	不定期・検証・初期導入	$0.36/RPU時間〜

Redshiftの最適化テクニック

Redshiftのパフォーマンスを引き出すには、MPPアーキテクチャ特有のチューニングが効きます。以下の5つは押さえておきたい定番です。

1. ソートキーと分散キーの設計：ソートキーはWHERE/JOINで頻出するカラムを指定し、ゾーンマップによるスキャンスキップを狙います。分散キーはJOINキーを指定し、ネットワーク越しのデータ移動を減らします。

2. VACUUM / ANALYZE：削除・更新の多いテーブルは定期的にVACUUMで再整列、ANALYZEで統計情報を更新します。RA3/Serverlessでは自動化機能があります。

3. WLM(Workload Management)：重いETLとインタラクティブクエリのキューを分離し、同時実行制御を行います。

4. 短期クラスタリサイズ：繁忙期だけノードを増やし、終わったら戻すといった運用が可能です。

5. Concurrency Scaling：同時実行クエリが増えたときに、一時的に追加クラスタを自動起動する機能です。

create table analytics.orders (
  order_id    bigint not null,
  customer_id bigint not null,
  order_date  date   not null,
  amount      numeric(10,2)
)
distkey(customer_id)
sortkey(order_date);

Redshiftが向くケース・向かないケース

向くケース	向かないケース
AWSを主戦場にしている	マルチクラウド戦略が必須
S3データレイクとDWHを併用したい	完全サーバーレス思考でDremel系の自動化を求める
既存のRedshift資産を活かしつつ最適化したい	新規プロジェクトでコンピュート/ストレージ分離を最優先
PostgreSQL互換のSQL知見を活用したい	Snowflake級のタイムトラベルやゼロコピークローンが必須

まとめ

本記事の要点を振り返ります。

RedshiftはAWSネイティブのクラウドDWHで、S3/IAM連携が強み
ProvisionedとServerlessの2モードから選択可能
ソートキー・分散キー設計が性能を左右する
新規導入はServerlessから始めるのが推奨
Spectrumによるデータレイク連携が独自の強み

次に読むべき記事は、クラウドDWH3大サービス比較、dbt入門、そしてマイグレーション戦略の実践編です。DE-STKではRedshiftの設計レビュー・既存クラスタのパフォーマンスチューニング・他DWHへの移行戦略策定まで幅広く支援しています。お気軽にご相談ください。

よくある質問(FAQ)

Q. Redshift ProvisionedとServerlessのどちらを選ぶべきですか?

A. ワークロードが予測可能で常時稼働ならProvisioned、変動が大きく使った分だけ課金したいならServerlessが適しています。新規導入ならServerlessから始めるのが推奨です。

Q. RedshiftからSnowflakeやBigQueryへの移行は簡単ですか?

A. SQL互換性は高いため基本的なクエリはそのまま移行できますが、Redshift固有の機能(ソートキー、分散キー等)は再設計が必要です。dbtを使っている場合はアダプタの切り替えで比較的容易です。

Q. Redshift Spectrumとは何ですか?

A. S3上のデータをRedshiftクラスタにロードせずに直接SQLでクエリできる機能です。データレイクとDWHをシームレスに連携させ、コストを抑えながら大規模データの分析が可能になります。