Multi-cluster Warehouse実践

Multi-cluster Warehouseは、Snowflakeのウェアハウスが複数のコンピュートクラスタを動的に起動・停止して 同時実行性（コンカレンシー）をスケールアウトする機能です。 個々のクエリの速度はウェアハウスサイズ（スケールアップ）で制御し、 同時に処理できるクエリの数はMulti-cluster（スケールアウト）で制御するという使い分けが重要です。Enterprise Edition以上で利用可能です。

動作原理

通常のウェアハウスは1つのクラスタで構成されます。 Multi-cluster WarehouseではMIN_CLUSTER_COUNTとMAX_CLUSTER_COUNTを設定し、 同時実行クエリがクラスタの処理能力を超えるとSnowflakeが自動的に追加クラスタを起動します。 負荷が減少すると不要なクラスタは自動停止されます。

同時実行クエリが増加した場合の動作：

[クラスタ1] ■■■■ 4クエリ実行中
                    ↓ キューイング検知
[クラスタ1] ■■■■   [クラスタ2] ■■ 追加起動
                    ↓ さらに増加
[クラスタ1] ■■■■   [クラスタ2] ■■■■   [クラスタ3] ■■ 追加起動

負荷が減少した場合：
[クラスタ1] ■■     [クラスタ2] 停止     [クラスタ3] 停止

CREATE WAREHOUSE構文

-- BIダッシュボード向け：レスポンス重視
CREATE WAREHOUSE bi_dashboard_wh
  WAREHOUSE_SIZE = 'MEDIUM'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 6
  SCALING_POLICY = 'STANDARD'
  AUTO_SUSPEND = 300
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE;

-- バッチETL向け：コスト重視
CREATE WAREHOUSE batch_etl_wh
  WAREHOUSE_SIZE = 'LARGE'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 3
  SCALING_POLICY = 'ECONOMY'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

-- 常時稼働（MIN = MAX で固定クラスタ数）
CREATE WAREHOUSE always_on_wh
  WAREHOUSE_SIZE = 'SMALL'
  MIN_CLUSTER_COUNT = 3
  MAX_CLUSTER_COUNT = 3
  AUTO_SUSPEND = 0
  AUTO_RESUME = TRUE;

Standard vs Economy 比較表

キューイングの原因と対策

キューイングは、ウェアハウスの全クラスタがビジー状態のときに新しいクエリが待機キューに入る現象です。 ユーザーのレスポンスタイム悪化に直結するため、以下の手順で原因を特定し対処します。

-- キューイングが発生しているクエリの確認
SELECT
  query_id,
  warehouse_name,
  user_name,
  queued_overload_time,
  total_elapsed_time,
  execution_time,
  query_text
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE queued_overload_time > 0
  AND start_time >= DATEADD(HOUR, -24, CURRENT_TIMESTAMP())
ORDER BY queued_overload_time DESC
LIMIT 20;

-- ウェアハウスの負荷パターンを時間帯別に分析
SELECT
  DATE_TRUNC('HOUR', start_time) AS hour_slot,
  warehouse_name,
  COUNT(*) AS query_count,
  AVG(queued_overload_time) / 1000 AS avg_queue_sec,
  MAX(queued_overload_time) / 1000 AS max_queue_sec
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD(DAY, -7, CURRENT_TIMESTAMP())
  AND warehouse_name = 'BI_DASHBOARD_WH'
GROUP BY 1, 2
ORDER BY hour_slot;

キューイング対策チェックリスト

運用時のパラメータ変更

-- クラスタ数の変更（即時反映）
ALTER WAREHOUSE bi_dashboard_wh SET
  MIN_CLUSTER_COUNT = 2
  MAX_CLUSTER_COUNT = 10;

-- スケーリングポリシーの変更
ALTER WAREHOUSE bi_dashboard_wh SET
  SCALING_POLICY = 'ECONOMY';

-- ウェアハウスサイズの変更（次のクエリ実行時に反映）
ALTER WAREHOUSE bi_dashboard_wh SET
  WAREHOUSE_SIZE = 'LARGE';

モニタリング

-- ウェアハウスの負荷履歴（クラスタ稼働状況）
SELECT
  start_time,
  end_time,
  warehouse_name,
  avg_running,
  avg_queued_load,
  avg_queued_provisioning,
  avg_blocked
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_LOAD_HISTORY
WHERE start_time >= DATEADD(DAY, -7, CURRENT_TIMESTAMP())
  AND warehouse_name = 'BI_DASHBOARD_WH'
ORDER BY start_time DESC;

-- クレジット消費の推移
SELECT
  start_time::DATE AS usage_date,
  warehouse_name,
  SUM(credits_used) AS total_credits,
  SUM(credits_used_compute) AS compute_credits,
  SUM(credits_used_cloud_services) AS cloud_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD(MONTH, -1, CURRENT_TIMESTAMP())
  AND warehouse_name = 'BI_DASHBOARD_WH'
GROUP BY 1, 2
ORDER BY usage_date DESC;

設計パターン

• BI層とETL層のウェアハウス分離：インタラクティブクエリ（Standard / 高MAX_CLUSTER_COUNT）とバッチETL（Economy / 大サイズ）を別ウェアハウスにすることで相互干渉を排除する
• MIN_CLUSTER_COUNT = 1 でコスト最適化：アイドル時に1クラスタだけ稼働させ、AUTO_SUSPENDで完全停止も可能にする
• 固定クラスタ数（MIN = MAX）で予測可能なコスト：ピーク時のクレジット消費を予測したい場合に有効。ただし負荷変動への柔軟性は失われる
• Resource Monitorとの併用：MAX_CLUSTER_COUNTを大きく設定しつつ、Resource Monitorでクレジット上限を設定して予算超過を防ぐ

問題で確認

よくある質問