Amazon Redshift

Amazon Redshift は、大量のデータに対する分析クエリ（OLAP）を高速に実行するためのフルマネージド型データウェアハウスです。列指向ストレージと超並列処理を組み合わせることで、テラバイトからペタバイト級のデータを集計・分析するワークロードに最適化されています。

解決する課題

トランザクション処理を主目的とするリレーショナルデータベース（OLTP）は、1行ずつの読み書きには強い一方、数億行を横断する集計クエリには不向きです。大量のデータを多数の列にわたって集計・結合する分析処理を従来型データベースで行うと、I/O が膨らみ応答が遅くなります。

Redshift は分析専用に設計されており、次のような課題を解決します。

• 大規模なファクトテーブルに対する集計・結合クエリの高速化
• 複数のデータソースを統合した全社的な分析基盤の構築
• インフラ管理の負担を抑えつつ、需要に応じて性能と容量を拡張すること
• BI ツールやダッシュボードへの一貫した分析結果の提供

主要概念と用語

• クラスター: コンピューティングとストレージを担う実体。1台のリーダーノードと複数のコンピュートノードで構成される（プロビジョンド方式の場合）。
• リーダーノード: クライアントからのクエリを受け取り、実行計画を作成してコンピュートノードに配布し、結果を集約して返す役割を持つ。
• コンピュートノード: 実データを保持し、割り当てられた処理を並列で実行するノード。内部はさらにスライスという処理単位に分割される。
• スライス: コンピュートノード内の並列処理の最小単位。データはスライス単位で分散して格納される。
• ノードタイプ: ストレージと計算性能の比率が異なるハードウェアの種別。最新世代では計算とストレージを独立して拡張できるものがある。
• Redshift Serverless: クラスターのプロビジョニングや管理を不要にし、ワークロードに応じて自動的にキャパシティを割り当てる方式。利用したコンピューティング量に応じて課金される。
• RA3 ノード: 計算とマネージドストレージを分離し、ストレージは Amazon S3 を裏側に用いて自動でスケールする世代のノード。
• 分散キー（DISTKEY）: 行をどの基準でスライスに分散させるかを決める列の指定。結合性能に大きく影響する。
• ソートキー（SORTKEY）: テーブル内でデータを物理的に並べる順序を決める指定。範囲スキャンやフィルタを高速化する。
• Redshift Spectrum: S3 上のデータレイクに置いたファイルへ、Redshift にロードせず直接 SQL でクエリできる機能。
• マテリアライズドビュー: 集計結果などを事前計算して保持し、繰り返しのクエリを高速化する仕組み。
• ワークロード管理（WLM）: クエリをキューに振り分け、同時実行数やメモリ配分を制御する仕組み。自動運用のモードもある。

仕様・制限・クォータ

• 列指向ストレージを採用し、列単位で圧縮（エンコード）してディスク I/O とストレージを削減する。
• 標準的な SQL（PostgreSQL 互換の方言）で操作でき、多くの BI ツールや JDBC/ODBC ドライバから接続できる。
• 1つのクラスターはリージョン内の単一アベイラビリティーゾーンに配置されるのが基本だが、構成によってはマルチ AZ をサポートする。
• クラスターあたりのノード数、データベース数、同時接続数、テーブル数などにはアカウントやノードタイプごとの上限がある。具体的な数値は変動するため、最新のサービスクォータを確認すること。
• スナップショットによるバックアップ、リサイズ、ノードタイプの変更などの運用操作をマネージドに提供する。

内部の仕組み

Redshift の高速性は、主に列指向ストレージと超並列処理（MPP）という2つの設計に支えられています。

列指向ストレージでは、同じ列の値が連続して格納されます。分析クエリは多数の行の特定の列だけを参照することが多いため、必要な列のブロックだけを読み込めば済み、I/O が大幅に削減されます。さらに同種のデータが並ぶため圧縮効率が高く、データ型に応じたエンコードが適用されます。

超並列処理では、テーブルのデータが複数のコンピュートノードとスライスに分散して格納されます。クエリを受け取るとリーダーノードが実行計画を作り、各ノードが自分の担当するデータ部分を並列に処理します。各ノードの結果はリーダーノードで集約されて返されます。データの分散方法は分散キーで制御され、結合するテーブル同士を同じキーで分散させると、ノードをまたぐデータ移動が減って結合が速くなります。

ソートキーはディスク上のデータの並び順を決めます。フィルタ条件や範囲検索でソートキーが効くと、不要なブロックの読み飛ばしが進み、スキャン量が減ります。これらの物理設計がクエリ性能を大きく左右します。

RA3 世代や Serverless では計算とストレージが分離され、ストレージは S3 を裏側とするマネージドストレージへ自動的にあふれ出します。これにより、ストレージ容量に縛られずに計算性能を選べます。

設計パターン / ベストプラクティス

• 分散キーは、最も頻繁に結合する大きなテーブル同士で結合キーを共有させると効果的。小さなディメンションテーブルは全ノードに複製する分散方式も検討する。
• ソートキーは、フィルタや範囲検索で頻繁に使う列に設定する。時系列データでは日時列をソートキーにすると効果が出やすい。
• 大量データの取り込みは、1行ずつの INSERT ではなく COPY コマンドで S3 などからバルクロードする。並列に読み込まれて効率がよい。
• 列の圧縮エンコードは自動で適切なものが選ばれる仕組みを活用し、ストレージとスキャン量を抑える。
• 繰り返し実行される重い集計はマテリアライズドビューで事前計算する。
• ホットデータは Redshift 内に保持し、参照頻度の低い大量データは S3 に置いて Redshift Spectrum で必要時にクエリする、という階層化を検討する。
• 不要になった行を削除した後は、領域回収と再ソートのためのメンテナンス（VACUUM 相当）や統計情報の更新を適切に行う。自動メンテナンス機能の活用も有効。

運用・監視

• クラスターやクエリの状態は Amazon CloudWatch のメトリクスで監視できる。CPU 使用率、ディスク使用量、接続数、クエリ実行時間などが代表的な指標。
• スナップショットによる自動・手動バックアップを利用し、必要に応じて別リージョンへコピーして災害対策とする。
• ワークロード管理（WLM）でクエリをキューに分け、同時実行数やメモリ配分を制御する。自動 WLM を使うと負荷に応じて自動調整される。
• 実行が長引くクエリやリソースを過剰に消費するクエリは、システムテーブルやコンソールの監視画面から特定し、設計やキュー設定を見直す。
• ノードの追加・削除によるリサイズや、ノードタイプの変更で性能・容量を調整する。エラスティックリサイズは短時間で完了しやすい。

コスト

• プロビジョンド方式では、稼働するノードの種類と台数、稼働時間に応じて課金される。一定期間の利用を確約するリザーブドノードで割引を受けられる。
• Serverless 方式では、消費したコンピューティング量（リソースを使った時間に基づく単位）に応じて課金され、アイドル時のコストを抑えやすい。
• マネージドストレージや、Redshift Spectrum で S3 上のデータをスキャンした量に対しても費用が発生する。
• スナップショットの保存、リージョン間のデータ転送なども課金対象になり得る。
• 列指向圧縮やソートキー設計でスキャン量を減らすことは、Spectrum のスキャン課金や Serverless のコンピューティング消費の削減に直結する。

具体的な料金単価はリージョンや時期で変動するため、最新の料金ページで確認してください。

セキュリティ

• 通信は SSL/TLS で暗号化でき、保存データは AWS Key Management Service（KMS）などを用いて暗号化できる。
• クラスターは Amazon VPC 内に配置し、セキュリティグループやサブネット構成でネットワークアクセスを制御する。
• アクセス制御は AWS Identity and Access Management（IAM）と、データベース内のユーザー・グループ・権限を組み合わせて行う。
• 監査のために接続・クエリ・変更操作のログを S3 や CloudWatch Logs に出力できる。
• 他サービスへのアクセス（S3 からの COPY や Spectrum など）には IAM ロールをクラスターに関連付けて権限を与えるのが一般的。

Well-Architected の観点

• パフォーマンス効率: 列指向ストレージと超並列処理を前提に、分散キー・ソートキー・圧縮を適切に設計することで、スキャン量を抑え高いクエリ性能を引き出す。マテリアライズドビューやキャッシュも活用する。
• コスト最適化: 常時稼働の安定ワークロードはプロビジョンド＋リザーブドで、変動・断続的なワークロードは Serverless でと、特性に応じて方式を選ぶ。物理設計で読み取り量を減らすことが直接コストに効く。
• 信頼性: スナップショットによるバックアップとリージョン間コピー、マルチ AZ 構成などで可用性とリカバリ性を高める。
• セキュリティ: 暗号化、VPC によるネットワーク隔離、IAM とデータベース権限の併用で最小権限を実現する。

試験で問われるポイント

関連サービス・比較

分析用途の Redshift と、トランザクション用途の Amazon RDS はしばしば比較されます。両者は最適なワークロードが異なります。

このほか、サーバーレスなアドホック分析には Amazon Athena、データレイク連携には S3 と Redshift Spectrum、リアルタイム取り込みにはストリーミング系サービスが組み合わせて使われます。

ハンズオン / CLI例

S3 に置いた CSV をテーブルへバルクロードする基本的な流れの例です。COPY ではアクセス権を持つ IAM ロールを指定します。

# S3 上の CSV をテーブルにロードする（Redshift クラスターへ接続後に実行する SQL 例）
# psql などのクライアントから以下を実行する

# テーブル作成（ソートキーと分散キーを指定）
CREATE TABLE sales (
  sale_id      BIGINT,
  customer_id  BIGINT,
  sale_date    DATE,
  amount       DECIMAL(12,2)
)
DISTKEY (customer_id)
SORTKEY (sale_date);

# S3 から並列にバルクロード（IAM ロールで権限付与）
COPY sales
FROM 's3://my-bucket/sales/'
IAM_ROLE 'arn:aws:iam::123456789012:role/MyRedshiftRole'
FORMAT AS CSV
IGNOREHEADER 1;

# 取り込み後に統計情報を更新
ANALYZE sales;