Amazon Redshift本番運用Vol2｜ML・マテリアライズドビュー・WLM・ストリーミング・マスキング

1. Vol2の全体像と差別化 — 分析高度化フェーズへ

本連載のVol2では、Vol1で構築したAmazon Redshiftの基盤（Serverless/RA3・zero-ETL・データ共有・Spectrum）の上に、データウェアハウスを「分析プラットフォーム」へと高度化する機能を積み上げます。
本記事が扱うのは、Vol1では触れなかった分析高度化の5機能——Redshift MLによるDWH内機械学習、マテリアライズドビューによる集計最適化、新しいワークロードのためのWLM設計、Kinesis/MSKからのストリーミング取込、そして動的データマスキング（DDM）による列レベルのアクセス制御です。
Vol1で築いた基盤の上にこれらの機能を段階的に積み上げることで、Redshiftはデータウェアハウスを超えた総合的な分析プラットフォームへと進化します。

本記事はVol1の続編（continuation）として位置づけられます。
Vol1で解説したServerless/RA3/WLM基礎/zero-ETL/データ共有/Spectrumの知識を前提とし、それらの機能説明は本記事では行いません。
Vol1との境界を明確にした上で、Vol2固有の5機能を詳解します。

1-1. Vol1の基盤——本記事が委譲する範囲

Vol1では次の機能を詳解しました。
これらは本記事では再説明せず、必要に応じてVol1を参照してください。

• Serverless/RA3ノードの基盤設計
  RPUオートスケール（Serverless）、Managed Storage（RA3）、ノード選定指針とコスト比較
• zero-ETL
  Aurora PostgreSQL/MySQL・RDS MySQL→Redshiftへのキャプチャとレプリケーション（DBからのCDC）
• データ共有（Data Sharing）
  クラスター間・AWSアカウント間のライブデータ共有とAWS Clean Rooms連携
• Redshift Spectrum
  RedshiftクラスターからS3上の外部テーブルへ直接クエリを発行するスキームとパフォーマンス設計
• WLMの基礎
  自動WLM/手動WLM・キューの概念・クエリ優先度・SQA（Short Query Acceleration）・Concurrency Scalingの基本動作・Serverlessのワークロード管理

本記事でこれらに言及する場面があっても、詳細説明はVol1へのリンクにとどめ、重複を避けます。

1-2. なぜ今、分析高度化が必要になるのか

Redshiftの基盤を整えた後、多くのチームは次のような要件に直面します。

• 「集計クエリが重くてダッシュボードのレスポンスが遅い。BI利用が増えるほど悪化している」
  → マテリアライズドビュー & auto-refresh（§3）で集計を事前計算し、クエリコストを削減します
• 「IoT機器やアプリのクリックストリームをリアルタイムで分析したい。バッチETLでは遅延が大きすぎる」
  → ストリーミング取込（§5）でKinesis/MSKからRedshiftに直接データを取り込みます
• 「DWHに蓄積されたデータでチャーン予測や需要予測を動かしたい。SageMakerを使うためにデータを都度S3に出し入れするのが煩雑だ」
  → Redshift ML（§2）でDWH内のSQLから直接モデルを学習・推論します
• 「PII（個人情報）を含む列を、分析者ロールには部分マスクして参照させたい。ETL段階でマスクすると元データが失われる」
  → 動的データマスキング（DDM）（§6）で列レベルのアクセス制御を実現します

これらはいずれも、Redshift単体の標準機能だけでは解決が難しく、分析高度化レイヤーの機能が必要になる典型的なシナリオです。
Vol2で扱う5機能はこれらのシナリオに対応するための設計手段を提供します。

1-3. ノードタイプの前提——DC2は2025年4月に非推奨化

本記事は全ての設計・操作をRA3ノードまたはServerlessを前提として記述します。

2025年4月、AWSはDC2ノードタイプを非推奨（deprecated）としました。
DC2は引き続き既存の運用環境では稼働しますが、新規に構築・拡張するシステムではRA3またはServerlessへの移行が強く推奨されます。
RA3はManaged Storageによるストレージとコンピュートの分離、Serverlessは使った分だけRPUを消費するオートスケール課金が特徴です。
本記事で登場するRedshift ML・ストリーミング取込・動的データマスキングなどの機能は、RA3/Serverless環境での利用を前提とした説明になっています。
既存のDC2環境をお持ちの方は、各機能を試みる前にノードタイプの移行計画を並行して進めることをお勧めします。

1-4. Vol2の5機能マップ

以下の表でVol2の5機能の位置づけと、Vol1との関係を整理します。

§4（WLM）について補足します。
Vol1§4ではWLMの基礎（自動WLM/手動WLM・キュー・クエリ優先度・Concurrency Scaling）を詳解しました。
Vol2§4では基礎を繰り返しません。
Redshift ML推論クエリ・マテリアライズドビューのauto-refresh・ストリーミング取込という「Vol2で登場した新ワークロード」を、WLMでどのように分離・優先制御するかという応用設計のみを扱います。
WLMの基礎に不安がある場合は先にVol1§4を参照してください。

§5（ストリーミング取込）とzero-ETLの違いについて補足します。
Vol1§5のzero-ETLは、RDS/Auroraなどのトランザクショナルデータベースの変更をRedshiftにキャプチャして複製する仕組みです。
一方、Vol2§5のストリーミング取込はKinesis Data StreamsやAmazon MSK（Managed Streaming for Apache Kafka）から流れてくるイベントストリームをRedshiftに直接取り込む仕組みです。
データソース（DBのCDC vs イベントストリーム）も取込経路も異なる別機能です。
混同しやすいため、本記事では随所で両者の違いを明示します。

1-5. 想定読者と持ち帰れる設計判断軸

本記事の主な読者層：

• Amazon RedshiftをデータウェアハウスまたはSQLエンジンとして本番運用しているデータエンジニア
• Redshift上でBI/分析基盤を設計・運用するアナリティクス基盤担当者
• 既存のRedshiftクラスターに機械学習・リアルタイム分析・アクセス制御の要件が加わってきた方
• AWS認定データアナリティクス（DAS）やAWS認定データエンジニア（DEA）の試験対策をされている方

本記事を読み終えた後に持ち帰れる主な設計判断軸を示します。

1. Redshift MLの使いどころ
   SQLで完結したい場合とSageMaker直接利用の境界線、コスト構造（SageMaker学習費用の発生条件）、モデル再学習の運用サイクル設計
2. マテリアライズドビューのauto-refreshが使える条件
   増分更新（incremental refresh）に対応するクエリパターンと、フルリフレッシュにフォールバックする条件、手動REFRESHとの使い分け
3. 新ワークロードのWLMキュー設計
   ML推論・MVリフレッシュ・ストリーミング取込をどのキューに分離し、Concurrency Scalingをどう活用するか
4. ストリーミング取込のアーキテクチャ選択
   KinesisとMSKの選択基準、streaming MVの設計パターンと鮮度・コストのトレードオフ
5. DDMの適用方針
   列レベルマスキングをRBACおよびRLS（行レベルセキュリティ）とどう組み合わせ、PII管理と監査をどう設計するか

1-6. 本記事の読み方

各§は基本的に独立して読める構成になっています。
特定の機能だけを確認したい場合は、§1-4の機能マップを参照して対応§に直接進んでください。

ただし、機能間には次の依存関係があります。

• §4（WLM応用）：§2（ML）・§3（MV）・§5（ストリーミング取込）で登場する新ワークロードを前提として扱います
• §5（ストリーミング取込）と§3（マテリアライズドビュー）：streaming MVで連携します。双方を合わせて読むと理解が深まります
• §7（統合設計）：§2〜§6を読み終えた後に読むと、5機能の組み合わせ方の全体像が把握できます

本番導入の段階的ロードマップと運用BPチェックリストは§8に集約しています。
まとめから逆引きする読み方も有効です。§8の運用チェックリストを確認してから、詳細が必要な§に戻る流れも効率的です。

コードブロックを含む操作例（CREATE MODEL文・マテリアライズドビューDDL・WLM設定・外部スキーマ定義・DDMポリシー定義）はそれぞれの§に集約しています。
実装に取り掛かる際は、各§のコード例を参考に環境に合わせて調整してください。

なお、本記事はVol1で扱ったServerless/RA3/WLM基礎/zero-ETL/データ共有/Spectrumの基礎知識を前提としています。
これらに不安がある場合は、先にVol1を参照されることをお勧めします。

2. Redshift ML — CREATE MODEL によるDWH内機械学習

2-1. Redshift ML とは — SQL で完結する機械学習の仕組み

Redshift ML は、Amazon Redshift 上の SQL から機械学習モデルを学習・推論できる機能です。データエンジニアや SQL に習熟したアナリストが、Python や SageMaker の専門知識なしに機械学習を本番ワークロードに組み込める点が最大の価値です。

仕組みは次の 3 段階で構成されます。

① 学習フェーズ（Redshift 外で実行）

CREATE MODEL 文を実行すると、Redshift は指定した学習データを Amazon S3 に自動エクスポートします。その後、Amazon SageMaker Autopilot がそのデータを受け取り、複数のアルゴリズムを試してハイパーパラメータを最適化し、最良モデルを選択します。学習はバックグラウンドで進み、完了まで数十分〜数時間かかります。

② モデル登録（Redshift 内に SQL 関数として配置）

SageMaker Autopilot での学習が完了すると、モデルは Redshift に SQL 関数として自動登録されます。登録後は SELECT 文の中から関数名を呼び出すだけで推論を実行できます。

③ 推論フェーズ（Redshift 内でローカル実行）

推論は Redshift クラスター内部で完結します（ローカル推論）。追加の SageMaker エンドポイント呼び出しは発生しないため、レイテンシが低く、並列クエリの中でも高スループットで動作します。

この設計により、学習コストは SageMaker 側で支払い、推論はウェアハウス内に閉じるという分離が実現されています。SageMaker 本体の詳細な設定は不要で、Redshift ML の API がすべて抽象化します。

2-2. 前提条件 — IAM ロールと S3 バケット

CREATE MODEL を実行するには、次の 2 つのリソースが事前に必要です。

IAM ロール

Redshift クラスター（またはServerlessワークグループ）に、SageMaker と S3 へのアクセス権を持つ IAM ロールをアタッチします。このロールには少なくとも以下のポリシーが必要です。

{
  "Effect": "Allow",
  "Action": [
 "sagemaker:CreateAutoMLJob",
 "sagemaker:DescribeAutoMLJob",
 "sagemaker:CreateCompilationJob",
 "sagemaker:DescribeCompilationJob",
 "iam:PassRole"
  ],
  "Resource": "*"
}

加えて、S3 への s3:GetObject・s3:PutObject・s3:ListBucket も必要です。IAM_ROLE DEFAULT と指定すると、クラスターにアタッチされたデフォルトロールが使用されます。

S3 バケット

学習データの中間保存と SageMaker が出力するモデルアーティファクトの置き場所として、同一リージョンの S3 バケットが必要です。CREATE MODEL の SETTINGS 句で S3_BUCKET を明示するか、クラスターのデフォルト S3 パスが使用されます。

2-3. CREATE MODEL 構文と主要パラメータ

基本的な CREATE MODEL 文の構造は次のとおりです。

CREATE MODEL schema_name.model_name
FROM { table_name | (SELECT ...) }
TARGET target_column
FUNCTION predict_function_name
IAM_ROLE { 'arn:aws:iam::123456789012:role/RedshiftMLRole' | DEFAULT }
[AUTO ON | OFF]
[MODEL_TYPE { AUTO | XGBOOST | MLP | LINEAR_LEARNER | KMEANS }]
[PROBLEM_TYPE { REGRESSION | BINARY_CLASSIFICATION | MULTICLASS_CLASSIFICATION }]
[OBJECTIVE { 'MSE' | 'F1' | 'Accuracy' | 'AUC' | ... }]
[SETTINGS (
 S3_BUCKET 'my-redshift-ml-bucket',
 S3_GARBAGE_COLLECT ON,
 KMS_KEY_ID 'kms-key-arn',
 MAX_CELLS 1000000,
 MAX_RUNTIME 5400
)];

各パラメータの意味は次のとおりです。

CREATE MODEL 文を実行すると、Redshift は即座に処理をバックグラウンドに委ねます。学習の進捗は STV_ML_MODEL_INFO システムテーブルや SVV_ML_MODEL_INFO ビューで確認できます。

SELECT schema_name, model_name, model_state, training_job_name
FROM SVV_ML_MODEL_INFO
ORDER BY create_time DESC;

model_state が Model is Ready になれば、推論関数を利用できます。

2-4. モデルタイプと AUTO による自動選択

AUTO ON（デフォルト）の場合、SageMaker Autopilot が学習データを分析して問題タイプを自動判定し、以下のアルゴリズムから最適なものを選択します。

AUTO ON の場合は PROBLEM_TYPE を省略すると Autopilot が自動判定します。ただし、ドメイン知識から問題タイプが明確な場合は PROBLEM_TYPE を明示することで学習時間を短縮できます。

AUTO OFF かつ MODEL_TYPE XGBOOST のように指定すると、ハイパーパラメータのチューニング範囲を絞り込めるため、学習費用と時間を削減できます。本番運用では、まず AUTO ON で試して有望なアルゴリズムを特定し、本番モデルは AUTO OFF でアルゴリズムを固定するというフローを推奨します。

2-5. PREDICT 関数による推論の実行

学習が完了すると、FUNCTION パラメータで指定した名前の SQL 関数が自動生成されます。推論は通常の SELECT 文の中で関数を呼び出すだけです。

二値分類（チャーン予測）の例

-- チャーン予測モデルの作成
CREATE MODEL ml.predict_churn
FROM (
 SELECT
  tenure_months,
  monthly_charges,
  total_charges,
  contract_type,
  payment_method,
  churn_flag
 FROM customer_data
 WHERE snapshot_date < '2024-01-01'
)
TARGET churn_flag
FUNCTION ml.f_predict_churn
IAM_ROLE DEFAULT
SETTINGS (S3_BUCKET 'my-redshift-ml-bucket');

-- 推論の実行（学習完了後）
SELECT
 customer_id,
 ml.f_predict_churn(
  tenure_months,
  monthly_charges,
  total_charges,
  contract_type,
  payment_method
 ) AS churn_probability
FROM customer_features
WHERE snapshot_date = CURRENT_DATE;

関数の引数は FROM 句で指定した特徴量列と同じ順序・型で渡します。TARGET 列は引数に含めません。

回帰（売上予測）の例

CREATE MODEL ml.predict_sales
FROM (
 SELECT
  product_category,
  region,
  day_of_week,
  promo_flag,
  weather_index,
  sales_amount
 FROM sales_history
 WHERE year < 2024
)
TARGET sales_amount
FUNCTION ml.f_predict_sales
IAM_ROLE DEFAULT
PROBLEM_TYPE REGRESSION
SETTINGS (S3_BUCKET 'my-redshift-ml-bucket');

-- 翌日の売上予測
SELECT
 store_id,
 product_category,
 ml.f_predict_sales(
  product_category,
  region,
  day_of_week,
  promo_flag,
  weather_index
 ) AS predicted_sales
FROM store_forecast_input
WHERE target_date = CURRENT_DATE + 1;

在庫最適化（クラスタリング）

MODEL_TYPE KMEANS を指定すると、教師なし学習による需要パターンのクラスタリングが可能です。商品を平均日次需要・需要分散・リードタイム・季節性指数などの特徴量でグループ化し、発注グループの自動分類に活用できます。K-Means の場合は TARGET 列の指定が不要で、生成された SQL 関数がクラスター番号を返します。

2-6. コスト・制約・運用上の注意点

コスト構造

Redshift ML の費用は主に 2 つに分かれます。

• SageMaker Autopilot 学習費用: CREATE MODEL を実行するたびに、SageMaker のトレーニングインスタンス費用が発生します。MAX_RUNTIME を短く設定するほど費用を抑えられますが、モデル精度はトレードオフになります。学習は 1 回あたり数ドル〜数十ドルの範囲が一般的です。
• S3 ストレージ費用: 学習データのエクスポートとモデルアーティファクトの保存に S3 費用が発生します。S3_GARBAGE_COLLECT ON（デフォルト）を維持することで、不要な中間ファイルは自動削除されます。

推論自体は Redshift クラスターの通常クエリとして実行されるため、推論ごとの追加課金はありません。

主な制約

運用上の注意点

モデルは学習時点のデータ分布を学習しているため、データのドリフト（入力データの分布変化）が生じると予測精度が低下します。本番運用では、定期的な再学習スケジュール（例: 月次）を設計してください。再学習は CREATE MODEL を同じ関数名で再実行するか、新しいバージョンを別名で作成して切り替えます。

また、CREATE MODEL には SageMaker へのアクセスが必要なため、VPC 内クラスターを使用する場合は SageMaker API エンドポイントへの通信経路（NAT ゲートウェイまたは VPC エンドポイント）を事前に確認してください。

3. マテリアライズドビュー & auto-refresh — 集計コスト削減と鮮度設計

3-1. マテリアライズドビューとは — 集計クエリの事前計算によるコスト削減

Amazon Redshiftのマテリアライズドビュー（Materialized View、以下MV）は、SELECT文の実行結果をRedshift内部に物理的に保持するオブジェクトです。通常のビューがクエリ実行のたびにベーステーブルを再計算するのに対し、MVは事前計算済みの結果セットを直接返すため、集計やJOINを含む重いクエリのレスポンスタイムを大幅に短縮できます。

特に次のユースケースで効果を発揮します。

• 日次・時間帯別の集計: SUM・COUNT・AVGなどの集計関数を毎回再計算せず、事前集計済みの行を返します。
• 複数テーブルのJOIN結果: 大規模なファクト×ディメンションJOINを事前に結合した状態で保持し、BI/ダッシュボードの初期表示を高速化します。
• Concurrency Scalingとの併用: MV参照クエリは読み取りのみのため、バースト時にConcurrency Scalingクラスターへオフロードしやすくなります。

MVは「ベーステーブルが更新されると自動的に反映される」わけではなく、リフレッシュ（REFRESH）を明示的に行うか、auto-refresh機能を有効化する必要があります。この鮮度管理がMV設計の核心です。

また、Redshiftのクエリオプティマイザーは、ユーザーが直接MVを指定しなくてもベーステーブルへのクエリを自動的にMV参照へ書き換える「クエリリライト」機能を持っています。これにより既存のBIクエリをそのままにしつつ、MVの高速化メリットを享受できます。この仕組みの詳細は3-5節で解説します。

3-2. CREATE MATERIALIZED VIEW 構文と AUTO REFRESH 設定

MVを作成する基本構文は次のとおりです。

CREATE MATERIALIZED VIEW mv_daily_sales
AUTO REFRESH YES
AS
SELECT
 sale_date,
 product_id,
 SUM(amount)  AS total_amount,
 COUNT(*)  AS tx_count
FROM sales
WHERE sale_date >= '2024-01-01'
GROUP BY sale_date, product_id;

主要なオプションを整理します。

AUTO REFRESH YES を指定しても、auto-refreshが実際に動作するかどうかはMVの定義内容（クエリ）によって決まります。次の節でその制約を詳しく解説します。

手動リフレッシュは次のコマンドです。

REFRESH MATERIALIZED VIEW mv_daily_sales;

実行後、STL_MV_REFRESH_STATUS システムビューでリフレッシュ履歴と所要時間を確認できます。

SELECT
 mv_name,
 status,
 start_time,
 end_time
FROM STL_MV_REFRESH_STATUS
ORDER BY start_time DESC
LIMIT 20;

3-3. auto-refresh — バックグラウンド自動更新のタイミングと頻度設計

AUTO REFRESH YES を設定したMVは、ベーステーブルへの更新（INSERT・UPDATE・DELETE・COPYなど）が発生した後、Redshiftのバックグラウンドプロセスが非同期でリフレッシュを実行します。ユーザーがリフレッシュのスケジュールを明示的に指定する必要はありません。

auto-refreshのタイミングはRedshiftが内部的に制御します。取込ジョブが高頻度に実行されていれば、それに追随してMVも短い間隔で更新されます。逆にベーステーブルの更新頻度が低い場合は、リフレッシュ間隔も自然に広がります。

設計上の注意点は次のとおりです。

1. 遅延の存在: auto-refreshはベーステーブル更新と同期（同一トランザクション）ではなく、非同期で実行されます。更新直後はMVに古いデータが残る可能性があり、準リアルタイム（秒〜分オーダーの遅延）を前提とした設計が必要です。
2. クラスターリソースへの影響: リフレッシュはクラスターのコンピューティングリソースを消費します。ETL取込ピーク時に大規模なMVリフレッシュが重なるとWLMキューを圧迫するため、§4で解説するWLMキュー設計でMVリフレッシュ用の専用キューを設けることを推奨します。
3. auto-refreshが動作しないケース: 後述のincremental refresh非対応条件に当てはまる場合、auto-refreshがトリガーされないか、フルリフレッシュ相当のコストが発生します。

3-4. incremental refresh vs full refresh — 差分更新の適用条件と制約

MVのリフレッシュには incremental refresh（増分更新） と full refresh（完全再構築） の2種類があります。この違いはコストと鮮度に直結するため、設計段階での把握が必須です。

incremental refresh（増分更新）

ベーステーブルへの追加・変更分のみをMVに反映する方式です。変更量に比例したコストで済むため、高頻度更新のシナリオに適しています。

incremental refreshが適用される主な条件（いずれも満たす場合）:

• MVの定義が GROUP BY + 集計関数（SUM・COUNT・MIN・MAX・AVGなど）で構成されている
• サブクエリ・ウィンドウ関数・DISTINCT・UNIONを含まない
• 参照するテーブルが外部テーブル（Spectrum/外部スキーマ）でない
• ベーステーブルに対するDISTKEY/SORTKEYの定義がMVの集計構造と矛盾しない

full refresh（完全再構築）

MVの定義全体を再実行してデータを再構築する方式です。incremental refreshの条件を満たさない場合、手動リフレッシュ・auto-refreshともにfull refreshになります。

full refreshが発生するパターン（代表例）:

• JOINを含むMV（特に複数テーブル結合）
• ウィンドウ関数（ROW_NUMBER・RANKなど）を含むMV
• 外部テーブル（Spectrumの外部スキーマ）を参照するMV
• DISTINCT・UNION・サブクエリを含むMV
• ベーステーブルのSORTKEYやDISTKEYの物理再構築が必要な更新後（VACUUM実行後など）

full refreshはデータ量に比例したコストが発生するため、大規模テーブルのMVを高頻度でfull refreshすることは避ける必要があります。この場合はAUTO REFRESH NOにしておき、手動リフレッシュとAWS EventBridgeによるスケジューリングを組み合わせた設計が現実的です。

適用状況の確認

MVが正常にauto-refresh対象として管理されているかどうかは、SVV_MV_INFO ビューで確認できます。

SELECT
 mv_name,
 schema_name,
 autorefresh,
 state
FROM SVV_MV_INFO
ORDER BY mv_name;

autorefresh = 1（有効）かつ state = 'Active' であれば、auto-refresh対象として管理されています。incremental/fullの区別は STL_MV_REFRESH_STATUS の実行時間の変化やrefresh_type列（バージョンによる）で判断できます。

3-5. クエリリライトによる MV の自動活用

Redshiftには、ユーザーが直接MVを指定しなくても、オプティマイザーがベーステーブルへのクエリを自動的にMV参照へ書き換える（クエリリライト） 機能があります。これにより、既存のBIツールやアドホッククエリを変更せずに、MVの高速化の恩恵を受けられます。

クエリリライトの有効化条件:

1. セッションパラメーター enable_result_cache_for_session = ON（デフォルトON）が設定されていること
2. MVが AUTO REFRESH YES で定義されていること（古すぎるMVへのリライトは抑制される場合があります）
3. ユーザーのクエリがMVの定義と意味的に等価（同じ集計列・フィルタ・グループキー）であること

クエリリライトが機能しているかどうかは、EXPLAIN でクエリプランを確認します。

EXPLAIN
SELECT sale_date, product_id, SUM(amount)
FROM sales
WHERE sale_date >= '2024-01-01'
GROUP BY sale_date, product_id;

プラン内に materialized view scan またはMV名が現れる場合、リライトが有効です。

注意点: enable_result_cache_for_session はRedshiftのクエリ結果キャッシュも制御するパラメーターです。このパラメーターをOFFにすると、クエリリライトも無効になります。パフォーマンスデバッグで一時的にOFFにした場合は、本番環境では必ずONに戻してください。

3-6. ユースケース — BI/ダッシュボード用集計と本番設計パターン

BI/ダッシュボードの初期表示高速化

QuickSight・Tableau・Lookerなどのダッシュボードは、起動時や画面遷移時に大量の集計クエリを同時発行します。MVを活用することでクエリがMV参照にリライトされ、初期表示のレスポンスタイムを数秒から数百ミリ秒に短縮できます。

推奨設計パターン（incremental refreshが有効に機能する構成）:

CREATE MATERIALIZED VIEW mv_daily_revenue
AUTO REFRESH YES
AS
SELECT
 DATE_TRUNC('day', created_at) AS sale_day,
 region,
 product_category,
 SUM(revenue)AS total_revenue,
 COUNT(*) AS order_count,
 AVG(revenue)AS avg_revenue
FROM orders
GROUP BY 1, 2, 3;

このMVは集計関数のみで構成され、外部テーブル参照もないため、auto-refresh + incremental refreshが有効に機能します。

定期バッチレポートとの組み合わせ

月次・週次のレポートバッチが大量のJOINや集計を含む場合、あえて AUTO REFRESH NO にして手動リフレッシュのみにし、バッチ実行直前に REFRESH MATERIALIZED VIEW を明示的に呼び出すパターンが有効です。これにより、バッチ実行タイミングに合わせた確実な鮮度保証が可能です。

ストリーミング取込との連携

§5で解説するKinesis Data StreamsやAmazon MSKからのストリーミング取込では、外部スキーマ上にstreaming MVを定義することで、ストリームデータの準リアルタイム集計を実現します。streaming MVはauto-refreshと組み合わせることで、ストリームへの新規データ到着後、数秒〜数十秒でMVに反映される設計が可能です。この連携の詳細は§5で説明します。

MV 運用時の注意事項

• 依存関係の管理: MVがベーステーブルのDDL変更（列追加・削除・型変更）に依存している場合、MVの自動再構築か手動DROPが必要になります。スキーマ変更時はMV依存関係を SVV_MV_DEPS で事前確認してください。
• VACUUMとの競合: VACUUMがベーステーブルの物理ソートを変更すると、MVのfull refreshがトリガーされる場合があります。VACUUMスケジュールとMVリフレッシュのWLM優先度を§4の設計で整合させてください。
• 権限管理: MVへのアクセス権限は GRANT SELECT ON mv_daily_revenue TO GROUP bi_readers; で管理します。ベーステーブルへの直接アクセスをMVに限定することで、§6の動的データマスキング（DDM）と組み合わせた列レベルの保護設計が可能です。

4. WLMによる高度ワークロード分離 — ML/MV/ストリーミングのキュー設計

WLMの基本設計（自動WLM・手動WLM・クエリ優先度・Concurrency Scalingの仕組み）については前編（Vol1）の §4で詳しく解説しています。本節では、Vol2で新たに登場するML推論・マテリアライズドビュー（MV）リフレッシュ・ストリーミング取込という3種のワークロードを、既存のDWHキューとどう共存させるかという応用設計に絞って解説します。

4-1. 新ワークロードの負荷特性

Vol2の3機能は、従来の分析クエリやバッチETLとは異なる負荷特性を持ちます。この差異を把握することが、WLMキュー設計の出発点です。

ML推論クエリ（PREDICT関数）の特性

PREDICT(<モデル名>, ...)による推論クエリは、モデルがRedshiftノード上にキャッシュされているかどうかで応答特性が大きく変わります。モデルキャッシュ済みのローカル推論では、通常のSQLと同等の低レイテンシで実行されます。一方、CREATE MODELの学習フェーズはSageMaker Autopilotへのオフロードであり、RedshiftのWLMスロット消費はエクスポート処理を除いて最小限です。

推論バッチで注意が必要なのはメモリ消費の予測しにくさです。数百万行に対してバッチ推論を実行すると、通常の集計クエリより多くのメモリを要求することがあります。専用キューでメモリ上限を設けることで、他のワークロードへの影響を遮断できます。

MVリフレッシュ（auto-refresh）の特性

マテリアライズドビューのauto-refreshはバックグラウンドプロセスとして実行されます。ベーステーブルの更新後にRedshiftが自動でリフレッシュをトリガーするため、業務ピーク時間帯に重なるとBI・分析クエリの応答時間を圧迫します。

増分リフレッシュ（インクリメンタル更新）が可能なMVは軽量ですが、フルリフレッシュが必要なMV（集計条件が複雑・JOINの階層が深いなど）はテーブルスキャンを伴い、ETLバッチ相当の負荷を生じさせます。この2種類を区別してキューを設計することが重要です。

ストリーミング取込の特性

Kinesis Data StreamsやAmazon MSKからのストリーミング取込は、24時間継続する低〜中レイテンシの書き込みワークロードです。ETLバッチのように短時間に集中するのではなく、常時スロットを占有し続けます。シャード数・パーティション数に比例してスループットが増加するため、放置するとBI・ETL向けスロットを徐々に圧迫します。

4-2. 推奨5キュー構成

3種の新ワークロードは既存のETL・BIとは負荷特性が異なるため、それぞれ専用キューに隔離することを推奨します。以下にRA3クラスターでの5キュー構成例を示します。

メモリ合計は100%以内に収め、デフォルトキューにも最低5%を残します。スロット数はRA3ノードのスライス数を超えないよう設計します（例: ra3.4xlargeは1ノードあたり8スライス）。

手動WLMではユーザーグループまたはクエリグループでルーティングを制御します。自動WLMではpriorityフィールド（highest/high/normal/low/lowest）で優先度を指定し、クエリグループや接続ユーザーで対象キューを特定します。

手動WLM設定JSON例（パラメータグループ用）

以下は5キュー構成を手動WLMで設定する場合のJSON抜粋です。Redshiftコンソールのパラメータグループ→wlm_json_configurationに適用します。

[
  {
 "name": "streaming-ingest",
 "query_group": ["streaming-ingest"],
 "query_concurrency": 3,
 "memory_percent_to_use": 12
  },
  {
 "name": "ml-inference",
 "query_group": ["ml-inference"],
 "user_group": ["ml_users"],
 "query_concurrency": 2,
 "memory_percent_to_use": 18
  },
  {
 "name": "mv-refresh",
 "query_group": ["mv-refresh"],
 "query_concurrency": 2,
 "memory_percent_to_use": 12
  },
  {
 "name": "bi-adhoc",
 "query_group": ["bi-adhoc"],
 "user_group": ["bi_users"],
 "query_concurrency": 6,
 "memory_percent_to_use": 33,
 "concurrency_scaling": "auto"
  },
  {
 "name": "etl-batch",
 "query_group": ["etl-batch"],
 "user_group": ["etl_users"],
 "query_concurrency": 4,
 "memory_percent_to_use": 20
  },
  {
 "auto_wlm": false,
 "short_query_acceleration": true,
 "max_execution_time": 5
  }
]

short_query_acceleration（SQA）を有効にすることで、5秒以内に完了する短時間クエリをWLMキューをバイパスして即時実行できます。BIダッシュボードのサムネイル取得など、ピーク時の軽量クエリのレイテンシを下げる効果があります。

4-3. MLワークロード用キュー分離設計

CREATE MODEL（学習フェーズ）とPREDICT（推論フェーズ）で負荷の性質が異なる点が設計の鍵です。

モデル学習中、Redshiftはローカルで学習データをS3へエクスポートしSageMaker Autopilotに学習ジョブを発行します。S3エクスポートはRedshiftのI/Oを使いますが、学習本体はSageMaker側で実行されるため、WLMスロット消費はエクスポート処理のみです。そのため、モデル学習はETLバッチキューで実行し、学習完了後の推論バッチ（PREDICT）をML推論専用キューに振り分ける設計が有効です。

-- 学習フェーズ（ETLバッチキューで実行・スロット消費は少ない）
SET query_group TO 'etl-batch';
CREATE MODEL customer_churn_model
FROM customer_features
TARGET churn_flag
FUNCTION predict_churn
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftMLRole'
SETTINGS (
  S3_BUCKET 'my-redshift-ml-bucket'
);
RESET query_group;

-- 推論バッチ（ML推論専用キューで実行）
SET query_group TO 'ml-inference';
SELECT customer_id,
 predict_churn(feature1, feature2, feature3) AS churn_probability
FROM daily_customer_snapshot
WHERE snapshot_date = CURRENT_DATE;
RESET query_group;

インタラクティブな推論クエリ（低レイテンシ要件のBI連携）はBI/アドホックキューに振り分け、夜間の大規模バッチ推論はMLキューで実行することで、優先度とメモリ配分を適切に制御できます。

4-4. MVリフレッシュのキュー設計

MVのauto-refreshはRedshiftの内部スケジューラがトリガーするため、ユーザーが直接クエリグループを設定できません。WLMによる制御は以下の2点で行います。

パラメータグループでのキュー割当

Redshiftのパラメータグループで、MVリフレッシュの内部実行ユーザーに対応するユーザーグループをmv-refreshキューへルーティングします。これにより、auto-refreshがBIキューやETLキューのスロットを無断占有することを防げます。設定はRedshiftコンソールのパラメータグループ→WLM設定から行います。

手動REFRESHのキュー制御

手動でREFRESH MATERIALIZED VIEWを実行する場合は、実行前にクエリグループを明示的に設定します。フルリフレッシュが発生するMVは一時的にETLバッチキューへ移動することで、長時間のスキャン処理をETL時間帯に限定できます。

-- 増分リフレッシュ可能なMV（MVリフレッシュキューで実行）
SET query_group TO 'mv-refresh';
REFRESH MATERIALIZED VIEW sales_daily_summary;
RESET query_group;

-- フルリフレッシュが必要なMV（ETLバッチキューで実行）
SET query_group TO 'etl-batch';
REFRESH MATERIALIZED VIEW complex_join_aggregation;
RESET query_group;

mv-refreshキューの優先度は低〜中に設定し、業務ピーク時間帯にBIクエリと競合しないようにします。auto-refreshとConcurrency Scalingの組み合わせについては、MVリフレッシュ自体は読み取り主体の処理のためConcurrency Scaling対象となり得ますが、コスト上昇に注意が必要です。

4-5. ストリーミング取込用キュー設計

Kinesis/MSKからのストリーミング取込はRedshiftが内部で管理する継続プロセスです。外部スキーマ＋ストリーミングMVのauto-refreshとして実行されるため、MVリフレッシュと同様のキュー設計が適用されます。

ストリーミング取込の最大の設計課題は「常時スロット占有」です。以下の原則でキューを設計します。

• 固定スロット数の確保: streaming-ingestキューに専用スロットを2〜4本確保し、他キューへの侵食を防ぎます。シャード数の増加に合わせてスロット数を段階的に増やす運用を計画します。
• Concurrency Scalingは書き込みに非適用: Concurrency Scalingは読み取り（SELECT）クエリのバーストに対応する機能です。ストリーミング取込のような書き込みワークロードには適用されません。取込スループットを増やすためにはシャード数の増加またはRedshiftノードの追加で対応します。
• スループット上限の事前測定: 取込スループットの上限はシャード数・パーティション数・データ形式・Redshiftノード数の組み合わせで変わります。本番前に負荷試験でピークスループットを測定し、スロット数とメモリ割当を調整します。

-- ストリーミングMVの手動リフレッシュ（取込テスト・緊急再同期時）
SET query_group TO 'streaming-ingest';
REFRESH MATERIALIZED VIEW kinesis_raw_events;
RESET query_group;

通常のストリーミング取込はauto-refreshで自動実行されるため、手動REFRESHは例外的な用途（テスト・緊急再同期）に限定します。

4-6. Query Monitoring Rules（QMR）による暴走クエリ制御

ML推論・MVリフレッシュ・ストリーミング取込は実行時間・メモリ消費が予測しにくいため、QMR（Query Monitoring Rules）でサーキットブレーカーを設定することが重要です。

QMRはWLMキューごとに「条件＋アクション」を定義します。条件にはクエリ実行時間・メモリ使用量・スキャン行数などが使え、アクションにはログ記録・ホップ（別キューへ移動）・中断を指定できます。

ML推論キューでは実行時間上限（例: 300秒）と大規模スキャンのログ記録を設定し、意図しないフルテーブルスキャンや推論ループを早期検知します。MVリフレッシュキューでは長時間のフルリフレッシュを検知してログ記録し、ピーク時間帯への影響を把握します。

[
  {
 "query_group": "ml-inference",
 "rules": [
{
  "rule_name": "ml_timeout",
  "predicate": [
 {"metric_name": "query_execution_time", "operator": ">=", "value": 300}
  ],
  "action": "abort"
},
{
  "rule_name": "ml_large_scan_log",
  "predicate": [
 {"metric_name": "scan_row_count", "operator": ">", "value": 100000000}
  ],
  "action": "log"
}
 ]
  },
  {
 "query_group": "mv-refresh",
 "rules": [
{
  "rule_name": "mv_long_refresh_log",
  "predicate": [
 {"metric_name": "query_execution_time", "operator": ">=", "value": 600}
  ],
  "action": "log"
}
 ]
  }
]

QMRログはSTL_WLM_RULE_ACTIONシステムテーブルで確認できます。運用初期はlogアクションで傾向を把握し、閾値が安定してからabortに変更する段階的なアプローチが安全です。

4-7. WLMキュー状態の監視

5キュー構成を本番に適用した後は、各キューのスロット消費率と待機クエリ数を定期的に監視することで、スロット不足や過剰メモリ配分を早期に検知できます。

リアルタイムのキュー状態確認

-- 各WLMキューのスロット使用状況と待機数
SELECT
 service_class,
 num_executing_queriesAS running,
 num_queued_queriesAS waiting,
 num_executed_queries AS completed_total,
 max_wlm_query_duration  AS max_duration_ms
FROM STV_WLM_SERVICE_CLASS_STATE
WHERE service_class > 4  -- ユーザー定義キューのみ（5以上）
ORDER BY service_class;

num_queued_queriesが継続的に増加しているキューはスロット不足の兆候です。ML推論キューやストリーミング取込キューで頻繁に待機が発生する場合は、スロット数またはメモリ配分の増量を検討します。過去の傾向を分析するにはSTL_WLM_QUERYビューのtotal_queue_time列でキュー別待機時間を集計します。BI/アドホックキューの待機が慢性的に増加し始めたら、Concurrency Scalingのしきい値調整またはノード増設を検討します。

4-8. Serverlessとの棲み分け

本節のWLMキュー設計はRA3クラスターを対象としています。Redshift Serverlessを使う場合のワークロード管理（RPUオートスケーリング・ワークグループ設計）についてはVol1 §4を参照してください。Vol2の新ワークロード（ML/MV/ストリーミング）はServerlessでも利用可能ですが、キュー分離の代わりにワークグループ単位での分離設計が適用されます。

5. ストリーミング取込 — Kinesis Data Streams / MSK からのリアルタイム取込

5-1. ストリーミング取込 vs zero-ETL の違いと選択基準

Redshift には「ストリームからリアルタイムでデータを取り込む機能」と「データベースの変更を自動的にレプリケートする機能」の 2 種類が存在します。両者は目的も仕組みも異なるため、混同しないよう注意が必要です。

ストリーミング取込は、Amazon Kinesis Data Streams または Amazon MSK（Managed Streaming for Apache Kafka）のストリームデータを、外部スキーマとマテリアライズドビュー（Streaming MV）を経由して Redshift に直接取り込む機能です。IoT センサーデータ、クリックストリーム、アプリケーションログなど、連続して生成されるイベントデータのリアルタイム分析に適しています。

zero-ETL（本シリーズ Vol.1 §5 で解説済み）は、Amazon Aurora や Amazon DynamoDB のトランザクションデータを CDC（変更データキャプチャ）により Redshift へ自動レプリケートする機能です。ETL パイプラインを構築せずに既存データベースの内容を分析基盤に同期する用途を対象としています。

選択の基準は明確です。「Kinesis や Kafka のストリームデータをリアルタイムで分析したい」場合はストリーミング取込を、「既存の RDBMS や DynamoDB のデータをそのまま Redshift に同期したい」場合は zero-ETL を選択します。

5-2. Kinesis Data Streams → Redshift ストリーミング取込の設定

Kinesis Data Streams からのストリーミング取込は、IAM ロール設定・外部スキーマ作成・Streaming MV 作成の 3 ステップで構成されます。

ステップ 1: IAM ロールの設定

Redshift クラスター（または Serverless ワークグループ）が Kinesis Data Streams にアクセスするための IAM ポリシーを用意します。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": [
  "kinesis:GetShardIterator",
  "kinesis:GetRecords",
  "kinesis:DescribeStreamSummary",
  "kinesis:ListShards"
],
"Resource": "arn:aws:kinesis:ap-northeast-1:123456789012:stream/my-stream"
 }
  ]
}

このポリシーをアタッチした IAM ロールを Redshift クラスターの IAM ロール設定に追加します。RA3 クラスターおよび Redshift Serverless のいずれでも同一の手順で設定できます。

ステップ 2: 外部スキーマの作成

CREATE EXTERNAL SCHEMA kinesis_schema
FROM KINESIS
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftStreamingRole';

この外部スキーマは、Kinesis Data Streams のストリームを仮想テーブルとして参照するためのものです。この時点ではデータはまだ Redshift にロードされていません。

ステップ 3: Streaming マテリアライズドビューの作成

CREATE MATERIALIZED VIEW kinesis_mv
AUTO REFRESH YES
AS
SELECT
  approximate_arrival_timestamp,
  JSON_PARSE(kinesis_data)  AS payload,
  partition_key,
  shard_id,
  sequence_number
FROM kinesis_schema."my-stream";

AUTO REFRESH YES を指定することで、Redshift がストリームを継続的にポーリングし、新しいレコードを自動的にマテリアライズドビューへ取り込みます。取込間隔はおおむね数秒〜数十秒です。この動作は §3 で解説したマテリアライズドビューの AUTO REFRESH と同一の仕組みを利用しており、WLM のシステムキューで処理されます。

SUPER 型を使ったフィールド参照

Kinesis レコードのペイロードは SUPER 型として取り込まれます。JSON 形式のデータを扱う場合は JSON_PARSE() 関数で変換し、ドット記法でフィールドを参照できます。

SELECT
  payload.user_id::VARCHAR AS user_id,
  payload.event_type::VARCHAR  AS event_type,
  payload.event_time::TIMESTAMPAS event_time,
  payload.amount::DECIMAL(12, 2)  AS amount
FROM kinesis_mv
WHERE payload.event_type::VARCHAR = 'purchase'
  AND approximate_arrival_timestamp > GETDATE() - INTERVAL '5 minutes';

5-3. MSK（Amazon Managed Kafka）→ Redshift の設定と運用

Amazon MSK からのストリーミング取込も、外部スキーマ + Streaming MV のパターンで構成します。基本的な流れは Kinesis と共通ですが、MSK 固有の設定項目があります。

前提条件

MSK クラスターは Redshift と同一 VPC 内、または VPC ピアリング / AWS PrivateLink 経由でアクセス可能な状態である必要があります。また、MSK の認証方式（IAM 認証 / TLS / SASL）に対応した IAM ロール設定が求められます。

外部スキーマの作成（MSK）

CREATE EXTERNAL SCHEMA msk_schema
FROM MSK
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftStreamingRole'
URI 'b-1.mymskcluster.xxxxx.ap-northeast-1.kafka.amazonaws.com:9098'
AUTHENTICATION iam;

URI には MSK ブートストラップサーバーのエンドポイントを指定します。IAM 認証を使用する場合は AUTHENTICATION iam を設定してください。

Streaming MV の作成（MSK）

CREATE MATERIALIZED VIEW msk_mv
AUTO REFRESH YES
AS
SELECT
  kafka_timestamp,
  JSON_PARSE(kafka_value) AS payload,
  kafka_key,
  kafka_partition,
  kafka_offset
FROM msk_schema."my-topic";

MSK の場合、レコードのキーは kafka_key、値は kafka_value カラムで参照します。タイムスタンプは kafka_timestamp で取得できます。

MSK 固有の運用上の注意点

MSK ではパーティション数がスループットを決定する重要な設計要素です。Redshift のストリーミング取込は各パーティションを並列処理しますが、パーティション数が少ない場合はスループットが制限されます。本番環境では予想取込レートに応じてパーティション数を事前に設計してください。

オフセット管理は Redshift が自動的に行います。ストリーミング MV のリフレッシュを一時停止したい場合は、以下のコマンドで制御できます。

-- リフレッシュ停止
ALTER MATERIALIZED VIEW msk_mv AUTO REFRESH NO;

-- リフレッシュ再開
ALTER MATERIALIZED VIEW msk_mv AUTO REFRESH YES;

5-4. ストリーミング取込の制約と設計上の注意点

ストリーミング取込を本番環境で活用するにあたり、以下の制約と考慮点を把握しておく必要があります。

データ型の制約

Streaming MV で参照できるカラムは、Kinesis / MSK のシステムカラム（タイムスタンプ、パーティションキー、オフセットなど）と SUPER 型（ペイロード）に限定されます。取込時点では厳密なスキーマ定義が不要なため、スキーマレスなイベントデータに柔軟に対応できます。一方で、Redshift の固定スキーマ列に変換するためのキャスト処理をクエリ側で実装する必要があります。

スループットの上限

Kinesis Data Streams の場合、1 シャードあたり最大 1 MB/秒または 1,000 レコード/秒が取込レートの上限です。大量データを処理する場合はシャード数を適切にスケールアウトする設計が必要です。シャード数の増加に伴い Redshift 側の並列処理能力も向上します。

エラーハンドリング

取込中にパースエラーが発生したレコード（不正な JSON 形式など）は、該当レコードがスキップされます。エラー発生状況の把握には、システムビュー SVL_MV_REFRESH_STATUS の定期的なモニタリングが有効です。

SELECT
  name AS mv_name,
  status,
  error_count,
  start_time,
  end_time
FROM SVL_MV_REFRESH_STATUS
WHERE name = 'kinesis_mv'
ORDER BY start_time DESC
LIMIT 10;

error_count が増加している場合は、上流のデータ品質問題（不正な JSON、想定外のフィールド欠落など）を確認してください。

auto-refresh と手動 REFRESH の相互作用

AUTO REFRESH YES を設定した Streaming MV は、Redshift が継続的にリフレッシュを実行します。この状態で REFRESH MATERIALIZED VIEW を手動実行することも可能ですが、重複実行のリスクがあるため、基本的には自動リフレッシュに委ねることを推奨します。WLM の観点では、Streaming MV のリフレッシュはシステムキューで処理されるため、ユーザーキューの WLM 設定とは独立して動作します。

RA3 / Serverless 前提

現行の推奨構成は RA3 インスタンスまたは Redshift Serverless です。DC2 クラスターはストリーミング取込の一部機能が制限される場合があります。新規構築では RA3 / Serverless を前提とした設計を採用してください。

5-5. LAG 関数等を使ったリアルタイム分析クエリ設計

Streaming MV は数秒〜数十秒の遅延で最新データにアクセスできるため、リアルタイム性の高い分析クエリに活用できます。代表的なパターンを示します。

直近 5 分間のイベント集計

SELECT
  DATE_TRUNC('minute', event_time)AS minute_bucket,
  payload.event_type::VARCHARAS event_type,
  COUNT(*) AS event_count,
  SUM(payload.amount::DECIMAL(12, 2)) AS total_amount
FROM kinesis_mv
CROSS JOIN (SELECT payload.event_time::TIMESTAMP AS event_time FROM kinesis_mv) t
WHERE event_time > GETDATE() - INTERVAL '5 minutes'
GROUP BY 1, 2
ORDER BY 1 DESC;

実際のクエリでは Streaming MV から SUPER 型フィールドをキャストしてから集計します。

LAG 関数を使ったセッション境界の検出

ユーザーの行動ログから、連続するイベント間の時間差を計算してセッション境界を検出する例です。

WITH raw AS (
  SELECT
 payload.user_id::VARCHARAS user_id,
 payload.event_time::TIMESTAMP AS event_time
  FROM kinesis_mv
  WHERE approximate_arrival_timestamp > GETDATE() - INTERVAL '1 hour'
),
session_data AS (
  SELECT
 user_id,
 event_time,
 DATEDIFF(
second,
LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time),
event_time
 ) AS seconds_since_last
  FROM raw
)
SELECT
  user_id,
  event_time,
  seconds_since_last,
  CASE
 WHEN seconds_since_last > 1800 OR seconds_since_last IS NULL
 THEN 1 ELSE 0
  END AS new_session_flag
FROM session_data
ORDER BY user_id, event_time;

30 分以上のギャップをセッション境界として検出し、新規セッション開始をフラグで管理しています。LAG 関数は Streaming MV に対しても通常のテーブルと同様に使用できます。

移動平均を使ったトレンド検知

SELECT
  minute_bucket,
  event_count,
  AVG(event_count) OVER (
 ORDER BY minute_bucket
 ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
  ) AS moving_avg_5min
FROM (
  SELECT
 DATE_TRUNC('minute', approximate_arrival_timestamp) AS minute_bucket,
 COUNT(*) AS event_count
  FROM kinesis_mv
  WHERE approximate_arrival_timestamp > GETDATE() - INTERVAL '30 minutes'
  GROUP BY 1
)
ORDER BY minute_bucket;

直近 30 分のイベント数を 1 分バケットで集計し、5 分移動平均でトレンドを可視化できます。通常の変動幅を大きく超えた急増・急減を検出するダッシュボードクエリとして活用できます。

5-6. 運用監視: ストリーミング取込のメトリクスとアラート設計

本番環境での安定運用には、取込状態を継続的に監視する仕組みが不可欠です。

主要な監視ポイント

リフレッシュ状態の定期確認クエリ

SELECT
  name,
  status,
  error_count,
  DATEDIFF(second, end_time, GETDATE()) AS seconds_since_last_refresh
FROM SVL_MV_REFRESH_STATUS
WHERE name IN ('kinesis_mv', 'msk_mv')
ORDER BY end_time DESC
LIMIT 5;

seconds_since_last_refresh が期待する取込間隔（例: 60 秒）を大幅に超えている場合は、リフレッシュが停止している可能性があります。

CloudWatch アラームの推奨設定

Kinesis Data Streams の場合、以下のメトリクスにアラームを設定することを推奨します。

• GetRecords.IteratorAgeMilliseconds（最大値）: コンシューマラグを示します。値が増加し続ける場合は Redshift の取込スループットが上流の書込レートに追いついていません。目安として 30,000 ms（30 秒）超過で ALARM を設定します。
• PutRecords.ThrottledRecords: 書込スロットリングが発生していないかを監視します。スロットリングが発生すると取込データが欠損するリスクがあります。

取込停止時の復旧手順

ストリーミング MV のリフレッシュが停止した場合の確認・復旧手順を示します。

-- 1. auto refresh の設定状態を確認
SELECT name, auto_refresh
FROM SVV_MV_INFO
WHERE name = 'kinesis_mv';

-- 2. auto refresh が無効になっていた場合は再有効化
ALTER MATERIALIZED VIEW kinesis_mv AUTO REFRESH YES;

-- 3. 手動リフレッシュで即時取込を試みる
REFRESH MATERIALIZED VIEW kinesis_mv;

-- 4. 取込再開後の状態確認
SELECT name, status, end_time
FROM SVL_MV_REFRESH_STATUS
WHERE name = 'kinesis_mv'
ORDER BY end_time DESC
LIMIT 3;

上記手順でも復旧しない場合は、IAM ロールのアクセス権限・VPC のネットワーク疎通・Kinesis / MSK 側の設定変更の有無を順に確認します。必要に応じて外部スキーマを削除・再作成することで復旧できる場合があります。

6. 動的データマスキング (DDM) — 列レベルのアクセス制御と運用設計

6-1. 動的データマスキングとは — クエリ時マスクと元データ保持の仕組み

Amazon Redshiftの動的データマスキング（DDM）は、2024年5月に一般提供（GA）を開始した列レベルのアクセス制御機能です。東京リージョンを含む全主要リージョンで利用できます。

DDMの最大の特徴は、クエリ実行時に動的にマスキングを適用する点にあります。元データはRedshiftのストレージに平文で保持されており、マスキングはあくまでクエリ結果として返される値に対してだけ行われます。ETL処理やデータコピー時に物理的にマスキングするアプローチとは根本的に異なります。本番テーブルのデータを書き換えることなく、参照するユーザーのロールに応じて同一テーブルの同一列が異なる形で見えるようになります。

DDMは行レベルセキュリティ（RLS）と組み合わせて使う機能です。両者の役割は明確に異なります。RLSは「どの行を見せるか」を制御する行フィルタであり、DDMは「列の値をどのように見せるか」を制御する列値変換です。たとえばRLSで担当顧客の行のみ参照を許可し、さらにDDMでクレジットカード番号列をマスクするという多層防御が実現できます。

DDMが特に効果を発揮するユースケースとしては、個人情報（PII）を含む顧客テーブルへのアナリスト参照制御、PCI DSS対象のカード番号・CVV列の保護、問い合わせ対応チームへの部分マスク参照（下4桁のみ表示）、開発・テスト環境向けのデータマスク提供などが挙げられます。

なお、DDMはあくまでクエリ時の変換であり、ストレージ上の暗号化（保存データの暗号化）とは独立した機能です。機密データを扱う本番環境では、ストレージ暗号化とDDMを組み合わせることが標準的な構成となります。

また、DDMはRA3ノードタイプおよびRedshift Serverlessの両方で利用できます。DC2ノードタイプは2025年4月に非推奨となっており、新規の本番環境ではRA3またはServerlessを前提として設計してください。

6-2. マスキングポリシーの作成と適用 — CREATE / ATTACH の構文と優先度制御

DDMはマスキングポリシーという単位でマスキングルールを定義します。ポリシーの作成と列への適用は2ステップで行います。

ステップ1: ポリシーの作成（CREATE MASKING POLICY）

CREATE MASKING POLICY mask_phone
WITH (phone_number VARCHAR)
USING (
  CASE WHEN IS_MEMBER('admin_role')
 THEN phone_number
 ELSE 'XXX-XXXX-' || RIGHT(phone_number, 4)
  END
);

CREATE MASKING POLICYではポリシー名、入力引数（対象列のデータ型）、マスキングロジック（USING句）を定義します。USING句には通常のSQL式を記述できるため、CASE WHENによるロール判定や後述のマスキング関数を組み合わせた柔軟な変換が可能です。

ステップ2: 列への適用（ATTACH MASKING POLICY）

ATTACH MASKING POLICY mask_phone
ON customer(phone_number)
TO ROLE analyst_role
PRIORITY 10;

ATTACH MASKING POLICYで対象テーブルの列とロールの組み合わせにポリシーを関連付けます。PRIORITYは複数のポリシーが同一列・同一ユーザーに適用される場合の優先度です。数値が大きいポリシーが優先されます（デフォルトは0）。

ポリシー適用の優先度ルール

同一ユーザーが複数のロールを持ち、それぞれに異なるマスキングポリシーが設定されている場合、最も高いPRIORITYのポリシーが適用されます。同一優先度のポリシーが競合した場合はより制限の厳しいポリシーが適用されます。SUPERユーザーはDDMポリシーの制限を受けないため、SUPER権限の付与は必要最小限にとどめることが重要です。

ポリシーの定義状況はSVV_MASKING_POLICY、適用状況はSVV_ATTACHED_MASKING_POLICYシステムビューで確認できます。

SELECT table_name, column_name, policy_name, role_name, priority
FROM SVV_ATTACHED_MASKING_POLICY
WHERE table_name = 'customer'
ORDER BY column_name, priority DESC;

ポリシーを取り外す場合はDETACH MASKING POLICY、削除する場合はDROP MASKING POLICYを使用します。なお、列に適用中のポリシーをDROPしようとするとエラーになるため、まずDETACHしてからDROPする順序を守ってください。

DETACH MASKING POLICY mask_phone
ON customer(phone_number)
FROM ROLE analyst_role;

DROP MASKING POLICY mask_phone;

6-3. マスキング関数の種類 — ハッシュ化・部分マスク・固定値置換・データ型別の設計

DDMのUSING句では、目的に応じて複数のマスキング手法を使い分けます。代表的なパターンを示します。

ハッシュ化（SHA-256等）

CREATE MASKING POLICY mask_email_hash
WITH (email VARCHAR)
USING (SHA2(email, 256));

元の値を一意のハッシュ値に変換します。同一ユーザーの行を突合するアナリティクスには適しています（ハッシュの一致で同一人物を識別可能）が、実値の復元はできません。SHA2の結果は文字列型になるため、後続集計でのデータ型に注意が必要です。

部分マスク（末尾N桁のみ表示）

CREATE MASKING POLICY mask_card_partial
WITH (card_number VARCHAR)
USING ('xxxx-xxxx-xxxx-' || RIGHT(card_number, 4));

クレジットカード番号や電話番号の下4桁のみを表示するパターンです。問い合わせ対応チームが本人確認できる最低限の情報を残しつつ、フル番号の露出を防ぎます。

固定値置換（NULLまたは定数）

CREATE MASKING POLICY mask_salary_null
WITH (salary DECIMAL)
USING (NULL::DECIMAL);

CREATE MASKING POLICY mask_address_fixed
WITH (address VARCHAR)
USING ('MASKED');

NULLや固定文字列で完全に秘匿するパターンです。集計（AVG/SUM等）の際にNULLは集計対象外となる動作を設計に織り込む必要があります。

データ型別の考慮点

数値型（INTEGER/DECIMAL）をマスクする場合はNULLか固定の数値（例: -1）に変換します。日付型はNULL::DATEか固定日付（例: '1900-01-01'::DATE）を使います。USING句の返却型を入力引数と揃えることが必須であり、型の不一致はクエリ実行エラーの原因となります。ポリシー定義時にCAST式を明示することで型の不一致を防止できます。

6-4. ロールベースのマスキング設定 — 管理者と一般ユーザーの多層参照制御

DDMはRedshiftのRBAC（ロールベースアクセス制御）と組み合わせることで、ロールごとに異なるビューを同一テーブルから提供できます。

代表的な3層構成として、同一テーブルに対して管理者ロールは平文、一般アナリストは部分マスク、外部連携ロールは完全マスクを設定する例を示します。

-- 管理者: 平文参照（最高優先度でそのまま返す）
CREATE MASKING POLICY mask_ssn_admin
WITH (ssn VARCHAR)
USING (ssn);

ATTACH MASKING POLICY mask_ssn_admin
ON customer(ssn)
TO ROLE admin_role
PRIORITY 100;

-- アナリスト: 末尾4桁のみ
CREATE MASKING POLICY mask_ssn_partial
WITH (ssn VARCHAR)
USING ('***-**-' || RIGHT(ssn, 4));

ATTACH MASKING POLICY mask_ssn_partial
ON customer(ssn)
TO ROLE analyst_role
PRIORITY 10;

-- 外部連携ロール: 完全マスク
CREATE MASKING POLICY mask_ssn_full
WITH (ssn VARCHAR)
USING ('XXX-XX-XXXX');

ATTACH MASKING POLICY mask_ssn_full
ON customer(ssn)
TO ROLE external_reader
PRIORITY 5;

ユーザーが複数のロールを持つ場合は最高優先度のポリシーが適用されます。したがって、admin_roleとanalyst_roleの両方を持つユーザーは平文（PRIORITY 100）が適用されます。権限設計時にはロールの組み合わせを事前にテストして、意図しない平文参照が発生しないかを確認してください。

ロールのアサインとDDMポリシーの適用は別々に管理されるため、ロール変更時はDDMポリシーの見直しもセットで実施することを運用プロセスに組み込みます。

6-5. DDMと列レベルセキュリティ（Column-Level Security）の使い分け

Amazon RedshiftにはDDMとは別に、列レベルセキュリティ（CLS: Column-Level Security）としてGRANT/REVOKEによる列単位のアクセス制御があります。両者の使い分けを整理します。

DDMはマスクされた値を返すためクエリとしては成功します。一方、CLSでは権限のない列を含むSELECTはエラーとなります。「参照は許可するが実値は見せない」ケースはDDM、「存在すら参照させない」ケースはCLSが適切です。

実運用では両者を組み合わせるのが一般的です。列の参照可否はGRANTで制御し、参照を許可した列の値の見え方はDDMで制御するという設計パターンが多用されます。たとえばPII列への参照権限を特定ロールにのみGRANTし、そのロールに対してはDDMで部分マスクを適用するという構成が典型例です。

6-6. コンプライアンス対応 — PCI DSS・個人情報のマスキング設計パターン

DDMはPCI DSS、GDPR、個人情報保護法などのコンプライアンス要件に対応するデータ保護レイヤーとして活用できます。

PCI DSS への対応

PCI DSS v4.0では、カード会員データ（PAN/CVV/有効期限）の表示は認可された業務目的に限定することが求められます。RedshiftでPANを保持する場合、DDMで以下のロール別制御を実装します。

• 決済処理担当ロール: 下4桁のみ表示（'xxxx xxxx xxxx ' || RIGHT(pan, 4)）
• 不正検知チームロール: ハッシュ化PANで突合（SHA2(pan, 256)）
• それ以外のロール: 固定値'XXXX XXXX XXXX XXXX'

CVVはそもそもPCI DSS v4.0第3.3.2条により保存自体が禁止されています。保存カラムが存在する場合はDDMによるマスクではなくデータ削除を最優先としてください。DDMは補完策であり、保存しないことが大原則です。

個人情報（PII）の設計パターン

氏名・住所・電話番号・メールアドレス・マイナンバー等のPII列は、列ごとにマスキングポリシーを設計します。以下のステップで進めることを推奨します。

まずSVV_COLUMNS等でスキーマ全体のPII候補列を洗い出し、列ごとに用途とマスキング方式（ハッシュ/部分マスク/完全マスク）を決定します。次に用途ごとにロールを設計し、マスキングポリシーを定義・適用します。運用開始後はSVV_ATTACHED_MASKING_POLICYで適用漏れを定期的に監査し、スキーマ変更（新列追加）のたびにDDMポリシーの適用を確認するプロセスを確立します。

監査ログとの連携

DDMのポリシー変更はシステムテーブルで記録されます。CloudTrailとRedshift監査ログを組み合わせることで、誰がいつどの列にアクセスしたかを追跡できます。コンプライアンス証跡として、これらのログをS3に長期保存する構成を推奨します。

アンチパターン: ETL物理マスキングとの混同と SUPER 濫用

DDMとETL段階の物理マスキングを混同しないことが重要です。DDMはクエリ時の変換であり、ETLやINSERT ... SELECTでデータを移動する際には適用されません。マスクされたデータが別テーブルに書き込まれることを期待した設計は誤りです。物理コピーが必要な場合はETL側でマスキングを実装する必要があります。

また、デバッグ目的でSUPERユーザーを多用する運用もアンチパターンです。SUPERはDDMを完全にバイパスするため、監査の盲点となります。本番環境ではSUPERの使用を最小限にとどめ、必要な場合はアクセスログを必ず記録してください。

7. 分析高度化の統合設計 — ML + MV + WLM + ストリーミング + DDM

§2〜§6で解説した5機能は単体でも有効ですが、組み合わせることで分析プラットフォームとしての真価を発揮します。本節では機能をつなぎ合わせた統合アーキテクチャ、WLM設計、DDMを含むセキュリティ統合、運用コスト最適化、本番導入のロードマップ、そよくある問題と対処法を一気通貫で整理します。

7-1. 分析高度化5機能の統合アーキテクチャ全体像

RA3/Serverlessを基盤（DC2は2025年4月に非推奨化・詳細はVol1参照）として、5機能が連動する全体像は次のとおりです。

機能間の主要なデータフローは「ストリーミング取込 → streaming MV(auto-refresh) → ML PREDICT → DDM保護 → WLM分離」という一方向のパイプラインです。WLMとDDMは横断的に全機能のリソース管理とアクセス制御を担います。重要なのは、これら5機能が独立した機能の集合ではなく、データが1つの経路を流れながら各機能が異なるレイヤーで付加価値を加える「レイヤード設計」を前提にしている点です。

統合設計の3つの軸は次のとおりです。

• データ鮮度の軸: ストリーミング取込 → streaming MV(auto-refresh)のチェーンが鮮度を担保します。フルリフレッシュの発生を防ぐMV設計がパイプライン全体の品質を左右します。
• コンピュートリソース管理の軸: WLMが5ワークロードの競合を防ぎます。ML推論・MVリフレッシュ・ストリーミング取込の3種はWLMへの影響が大きいため、キュー設計を最優先で整備します。
• アクセス制御の軸: DDMがクエリ実行時の最終防衛ラインです。RBACと組み合わせることで個人情報や機密属性を元データを変更せずに保護できます。

7-2. ストリーミング→MV auto-refresh→ML PREDICT のパイプライン設計

リアルタイム予測分析パイプラインは最も代表的な統合パターンです。Kinesis Data StreamsまたはMSKからストリーミング取込を開始し、外部スキーマを介してRedshiftへデータが届きます。streaming MVにauto-refreshを設定することで集計データが準リアルタイムに更新され続け、Redshift MLのSQL関数がそのMVを参照して推論を実行します。推論はRedshift内でローカルに完結するためネットワーク遅延はありません。

具体的な推論クエリの例を示します。

-- streaming MVから特徴量を取得してML推論を実行
SELECT
  customer_id,
  predict_churn_risk(
 page_views_last_7d,
 purchase_count_last_30d,
 avg_session_duration
  ) AS churn_probability,
  GETDATE() AS predicted_at
FROM mv_customer_realtime_features
WHERE last_event_ts >= GETDATE() - INTERVAL '1 hour';

mv_customer_realtime_features はKinesisからのstreaming MVであり、auto-refreshで継続的に更新されています。predict_churn_risk はSageMaker Autopilotで学習済みのモデルを参照するSQL関数です。推論結果を別テーブルへINSERTして後段のDDM適用先として利用するパターンが多く採用されます。

パイプライン設計のポイント

• 鮮度と推論精度のバランス: auto-refreshの頻度が高いほどデータは新鮮に保てますが、MVリフレッシュのコンピュート負荷も増加します。特徴量の鮮度がモデル精度に与える影響と運用コストのトレードオフを設計段階で明確に定義します。
• 再学習スケジュールの設計: CREATE MODELはS3へのデータエクスポートを経由してSageMaker Autopilotを呼び出します。毎回追加のストレージ・コンピュート費用が発生するため、本番では週次や月次など定期的な再学習スケジュールをEventBridge/Lambdaで制御するのが現実的です。再学習時に前バージョンのモデルで推論を継続できるよう、新旧モデルの切り替えをスムーズに行う運用フローを設計します。
• 増分更新条件の確認: streaming MVがauto-refreshで増分更新(incremental)されるかフルリフレッシュになるかは、MV定義の集計・JOIN条件によります。フルリフレッシュが発生すると取込ラグが拡大してML推論の特徴量が古くなるため、MV定義を増分更新対象の範囲内に収める設計が重要です。
• 推論結果の永続化: ML推論の出力（例: 解約リスクスコア）を専用テーブルに記録し、BIダッシュボードや後段のアラート処理から参照できる形にします。このテーブルにDDMを適用して個人識別情報を保護する統合パターンが §7-4 で詳述する設計の核心です。

7-3. WLMでの5ワークロード(ML/MV/Stream/BI/Batch)の優先制御設計

WLMの基礎（自動WLM・手動WLM・キューの概念・Concurrency Scaling基本動作）はVol1 §4で詳解しています。本節ではVol2で登場した新ワークロードをどのキューで管理するかに絞り込みます。

RA3環境での手動WLM設定では、ユーザーグループまたはクエリグループで各キューへのルーティングを制御します。例として5キュー構成の設定方針を示します。

-- クエリグループ設定例 (WLMパラメータグループはAWSコンソールまたはCLIで管理)
-- ML推論クエリはquery_groupで識別してML推論キューへルーティング
SET query_group TO 'ml_inference';
SELECT customer_id, predict_churn_risk(...) FROM mv_customer_realtime_features;
RESET query_group;

-- MVリフレッシュはシステム内部処理のため、専用ユーザー(redshift_mv_user等)で実行
-- キュー識別: user_group='mv_refresh_group'

-- バッチETLはスケジュールジョブ用ユーザーで実行
-- キュー識別: user_group='batch_etl_group'

• Concurrency Scalingの適用境界: ML推論クエリやBIダッシュボードなどの読み取りバーストはConcurrency Scalingで追加クラスタに吸収できます。MVリフレッシュやストリーミング取込の書き込み操作はConcurrency Scalingの対象外となるため、それらのキャパシティは専用スロットで個別に確保します。
• QMR(Query Monitoring Rules)の活用: ML推論クエリが想定外のリソースを消費している場合、QMRで実行時間やメモリ上限を設けてホップまたはキャンセルさせます。MVリフレッシュが遅延してBIへ影響が波及する場合もQMRで検知し、アラートへ転送できます。
• Serverlessとの棲み分け: ServerlessではRPU(Redshift Processing Unit)の自動スケールにより5ワークロードが同一プールでリソースを共有します。ワークロード分離を細かく制御したい場合はRA3の手動WLMが有効です。判断軸はVol1 §2/§3を参照ください。

7-4. DDMとアクセス制御を組み合わせたセキュアな分析環境設計

ML推論結果やリアルタイム集計データには個人情報や機密属性が含まれることがあります。DDMとRBAC(ロールベースアクセス制御)を組み合わせることで、クエリ結果の段階で列レベルのアクセス制御を実現します。GA 2024年5月以降、東京リージョンでも利用可能です。

-- ML推論結果テーブルの個人情報列にマスキングポリシーを定義・適用
CREATE MASKING POLICY mask_email_partial
WITH (email VARCHAR)
USING (CASE
  WHEN current_setting('myapp.user_role') = 'analyst_full'
  THEN email
  ELSE CONCAT(LEFT(email, 2), '***@***.***')
END);

ATTACH MASKING POLICY mask_email_partial
ON ml_churn_predictions(customer_email)
TO ROLE analyst_restricted
PRIORITY 10;

-- 推論スコア自体は全員参照可・email列のみマスク
-- analyst_full: 平文を参照可、analyst_restricted: マスク値のみ

PRIORITYを明示することで、複数のポリシーが同一列に適用された場合の挙動が予測可能になります。数値が大きいほど優先度が高く、最もPRIORITYが高いポリシーが適用されます。

統合設計での注意点

• streaming MVへのDDM適用: マテリアライズドビューの列にもATTACH MASKING POLICYを適用できます。ストリーミング取込 → streaming MV → DDMという経路で、リアルタイム集計データの機密列をクエリ時点で動的に保護します。元データは暗号化されたまま保持され、クエリ実行時だけマスク変換が行われる点が重要です。
• ML推論結果テーブルへのDDM: 推論結果（churn_probability）と個人識別情報（customer_emailなど）を同一テーブルに保持する場合、DDMで識別情報列を権限者以外に隠蔽します。モデル精度評価担当者と個人情報参照権限者を同じクエリ環境で分離できます。
• RLSとDDMの役割分担: RLS(行レベルセキュリティ)は「誰がどの行を参照できるか」を制御し、DDMは「参照できる行の中でどの列をどの形式で見せるか」を制御します。マルチテナント分析基盤ではRLS + DDMを組み合わせてテナント行分離と列レベル保護を同時に実現します。
• SUPERユーザーの管理: SUPERユーザーはDDMの適用対象外(デフォルトで平文参照可)です。本番環境ではSUPERユーザーを最小化し、通常の分析ユーザーには適切なロールを付与してDDMが意図どおりに機能する設計を徹底します。

7-5. 運用コスト最適化: RA3/Serverlessでの使い分けとConcurrency Scaling活用

5機能を統合運用するとコストが複数レイヤーに分散します。それぞれの発生源と最適化ポイントを把握することが重要です。

RA3 vs Serverlessの使い分け(統合設計視点)

• RA3が有利なケース: 5ワークロードをWLMで個別に優先制御したい・ML推論キューとMVリフレッシュキューを明確に分離したい・コストを固定したいケースです。ストリーミング取込のような継続的ワークロードはRA3の固定費に馴染みます。
• Serverlessが有利なケース: ワークロードが間欠的でオフピーク時の無駄なノード費用を避けたい・WLM設定の管理を省略したいケースです。streaming MVのauto-refreshはServerlessでも動作しますが、最大RPU上限でのリソース競合に注意します。
• ハイブリッド構成: ストリーミング取込・MVリフレッシュ・DDM保護など継続稼働が必要な処理はRA3でWLM分離し、アドホック分析クエリはServerlessで対応するハイブリッド構成も有効な選択肢です。DataSharingを用いてRA3クラスタのデータをServerlessネームスペースから参照する構成も検討できます。

7-6. 本番導入ロードマップ: 段階的な機能採用

5機能を一度に全て本番投入するとリスクが高いため、段階的な採用ロードマップが実践的です。

Phase 2のMV導入が最もリスクが低く、既存クエリのリプレースとして開始できます。Phase 3のストリーミング取込は新規ユースケースで始めることで影響範囲を限定できます。Phase 4のML統合は再学習コストが発生するため、最初はコスト計測を目的とした小規模モデルから試行します。Phase 5のDDMは既存テーブルへの後付け適用が可能ですが、RBACを整備してからATTACH MASKING POLICYを適用する順序を守ります。

7-7. トラブルシューティング: よくある問題(MVリフレッシュ遅延/ML推論精度/ストリーミングラグ)

統合環境で発生しやすい問題とその診断・対処方法をまとめます。

問題1: MVリフレッシュ遅延

streaming MVのauto-refreshが遅延すると、ML推論の特徴量が古くなり推論精度が低下します。SVL_MV_REFRESH_STATUS ビューでリフレッシュ時間と頻度を確認し、フルリフレッシュが頻発していないかチェックします。増分更新条件を満たさないMV定義（対応外のJOINや集計）が原因の場合はMVを再設計します。また、MVリフレッシュ専用WLMキューを確保してバッチETLや取込処理とのリソース競合を排除することが有効です。

-- MVリフレッシュ履歴を確認
SELECT mv_name, refresh_type, status, duration
FROM SVL_MV_REFRESH_STATUS
ORDER BY refresh_start DESC
LIMIT 20;

問題2: ML推論精度の劣化(データドリフト)

本番データの分布がトレーニング時から乖離すると推論精度が低下します(データドリフト)。Redshiftのシステムテーブルにはモデル精度の自動監視機能がないため、推論結果をモニタリングテーブルに記録して実際の結果と突き合わせる形で外部検知します。定期再学習(EventBridge/Lambda)をパイプラインに組み込み、再学習のたびにSageMakerの学習費用が発生することを考慮して再学習頻度を決定します。

-- 推論結果の蓄積テーブル（モデル性能監視用）
CREATE TABLE ml_prediction_log (
  customer_id VARCHAR(50),
  churn_probability FLOAT,
  predicted_at TIMESTAMP,
  model_version VARCHAR(20)
) DISTKEY(customer_id) SORTKEY(predicted_at);

-- 推論結果と実績を突き合わせるクエリ（外部でモデル精度を計測）
SELECT
  l.model_version,
  COUNT(*) AS predictions,
  AVG(CASE WHEN a.churned = 1 AND l.churn_probability >= 0.5 THEN 1.0 ELSE 0.0 END) AS true_positive_rate
FROM ml_prediction_log l
JOIN customer_actuals a ON l.customer_id = a.customer_id
GROUP BY l.model_version
ORDER BY MAX(l.predicted_at) DESC;

問題3: ストリーミング取込のラグ拡大

Kinesis/MSKからRedshiftへの取込に遅延が発生するとstreaming MVの鮮度が低下します。SYS_STREAM_SCAN_STATES でスキャン状態を確認し、Kinesisのシャード数に対してRedshift側のスループットが追いついているかチェックします。ストリーミング取込専用WLMキューを割り当ててMVリフレッシュやバッチETLとのリソース競合を排除することで多くのラグ問題が改善されます。MSKの場合はコンシューマグループ設定とIAM権限の不整合もラグの原因になるため合わせて確認します。

-- ストリーミング取込のスキャン状態確認
SELECT stream_name, scan_state, last_scanned_sequence_number
FROM SYS_STREAM_SCAN_STATES
ORDER BY last_update_time DESC;

問題4: DDMポリシーの意図しない適用

複数のマスキングポリシーが同一列に適用された場合、PRIORITYの設定次第で意図しない列値が返ることがあります。SVV_MASKING_POLICY と SVV_ATTACHED_MASKING_POLICY ビューで列ごとに適用されているポリシーと優先度を確認します。テスト環境でロールを切り替えながらマスキング動作を定期検証する仕組みを設けることで、ポリシー変更の影響を本番に波及させない運用が実現できます。SUPERユーザーをDDMのテストに使わず、専用テストロールで動作確認する習慣が重要です。

8. まとめ — Redshift分析高度化のベストプラクティス

Vol2では、Vol1で築いたAmazon Redshiftの基盤の上に、データウェアハウスを分析プラットフォームへ高度化する5つの機能を整理しました。
本§では各機能の要点を振り返り、本番運用に向けたチェックリストと推奨する段階的導入ロードマップを提示します。

8-1. Vol2の5機能——学習ポイントの振り返り

§2: Redshift ML（CREATE MODEL）

Redshift MLは、DWH内のデータをSQLで直接機械学習に活用できる機能です。
CREATE MODEL文を実行すると、内部でSageMaker Autopilotがモデルを学習し、推論はSQL関数として呼び出せます。
IAMロールとS3バケットの事前準備が必須で、学習にはSageMaker側の学習費用が発生します。
モデルの定期再学習サイクルを設計することが本番運用の鍵となります。

§3: マテリアライズドビュー & auto-refresh

マテリアライズドビュー（MV）は集計/JOINの結果を事前計算して保持し、クエリの再計算コストを削減します。
auto-refreshは増分更新（incremental）が可能なクエリパターンに限られ、対象外ではフルリフレッシュが実行されます。
ストリーミング取込と組み合わせたstreaming MVでは、準リアルタイム集計を実現できます。
鮮度要件とリフレッシュコストのバランスを設計時に明確にすることが重要です。

§4: WLMによる高度ワークロード分離

ML推論・MVリフレッシュ・ストリーミング取込は負荷特性が互いに異なります。
これらを適切なWLMキューに分離し、優先度・メモリ・同時実行スロットを割り当てることが安定運用の前提です。
読み取りバーストにはConcurrency Scalingを活用し、QMR（Query Monitoring Rules）で暴走クエリを制御します。
WLMの基礎（キューの概念・Concurrency Scalingの仕組み）はVol1§4を参照してください。

§5: ストリーミング取込（Kinesis/MSK）

Kinesis Data StreamsまたはAmazon MSKからRedshiftへの直接取込は、外部スキーマとstreaming MVで構成します。
ストリーミング取込はVol1のzero-ETL（DBのCDC）とは異なる経路であることを改めて確認してください。
auto-refreshが有効なstreaming MVにより、取込から集計まで準リアルタイムで完結します。
スループット制約とKinesisシャード/MSKパーティションの設計を事前に見積もることが安定運用の鍵です。

§6: 動的データマスキング（DDM）

DDMは2024年5月にGAとなった列レベルのアクセス制御機能です。
マスキングポリシーを列＋ロールの組み合わせで定義・適用し、クエリ実行時に動的にマスクします（元データは保持されます）。
RLS（行レベルセキュリティ）とは補完関係にあり、RBACと組み合わせて多層防御を構成します。
ETL段階での物理マスキングとは別物であり、クエリ実行時のみマスクが適用される点を理解してください。

8-2. 本番運用推奨チェックリスト

8-3. 段階的導入ロードマップ

Vol2の5機能を一度に導入するのは管理コストが高くなります。
次の優先順位で段階的に導入することをお勧めします。

1. 第1段階（基盤整備後すぐ）：マテリアライズドビュー & auto-refresh
   既存の重いダッシュボードクエリの高速化から始めると効果が見えやすく、リスクも低いです。
2. 第2段階（リアルタイム要件が出たとき）：ストリーミング取込 + WLM拡張
   streaming MVと合わせてWLMキューを再設計します。
3. 第3段階（セキュリティ強化フェーズ）：動的データマスキング（DDM）
   PII管理要件が明確になったタイミングで導入します。
4. 第4段階（ML活用フェーズ）：Redshift ML（CREATE MODEL）
   データ品質とモデル更新運用フローを整えてから導入します。

各段階でVol1の基盤（Serverless/RA3/WLM基礎）が安定していることが前提です。
AWS認定データアナリティクス（DAS）やAWS認定データエンジニア（DEA）の試験においても、これらの機能の組み合わせ設計が出題範囲となっています。

▶ Amazon Redshift 本番運用 Vol1 — Serverless/RA3/zero-ETL/データ共有/Spectrum（基礎編）

▶ AWS Data Analytics本番運用 Vol2 — Kinesis/MSK/QuickSight/EMR Serverless 完全ガイド