Snowflake Warehouseのサイズ設計：同時実行とコスト最適化の実務指針

本稿では、SnowflakeのWarehouse（仮想ウェアハウス）のサイズ選定、同時実行のさばき方、コスト最適化の基本パターンを、試験で問われやすい観点と実務手順の両方から整理します。

サイズを大きくするのか、マルチクラスタで横に広げるのか、AUTO_SUSPEND/RESUMEやスケーリングポリシー、Resource Monitorの設定値をどう決めるか、迷いどころを具体的に解消します。

この記事のゴールと前提

SnowflakeのWarehouseは、クエリ実行に必要な計算リソースを提供します。サイズは単一クエリの処理速度に主に効き、マルチクラスタは同時実行の平準化に効きます。課金は基本的に「サイズ×稼働時間（秒課金・最小1分）」で、サスペンド中は課金されません。

試験（SnowPro Core）では、サイズ拡大とマルチクラスタの目的の違い、AUTO_SUSPEND/RESUMEの有効性、スケーリングポリシー（STANDARD/Economy）の違い、Resource Monitorの役割が頻出です。実務でも同じ観点で設計・検証するのが近道です。

本稿は公式ドキュメントの安定機能を前提にします。エディションや契約により使える機能や上限が異なる場合があるため、最終判断は組織の契約情報と公式ドキュメントを確認してください。

• サイズを上げる＝単一クエリ性能の改善が主目的
• マルチクラスタ＝同時実行の待ち時間（キュー）削減が主目的
• 課金は秒単位（最小1分）。AUTO_SUSPEND/RESUMEで無駄を削減
• スケーリングポリシー：STANDARDは俊敏、ECONOMYはコスト重視
• Resource Monitorでクレジット消費の警告/停止を自動化
• キャッシュ（結果/データ/メタデータ）で計算を減らせることも忘れない

まず現在の倉庫を把握する

SHOW WAREHOUSES;
DESCRIBE WAREHOUSE IF EXISTS BI_WH;

サイズと課金の基本

Warehouseサイズは、X-Smallから6X-Largeまで段階的に提供され、一般に1段階上げるごとに消費クレジットは約2倍になります。単一クエリの重い集計や結合がボトルネックなら、まずはサイズ拡大で改善を試みます。

SnowflakeのWarehouseは秒課金（最小1分）で、サスペンド中は課金されません。AUTO_SUSPENDとAUTO_RESUMEを有効化して、アイドル時間の課金を抑えます。サイズ変更は新規にキューイングされるクエリから反映され、実行中クエリは継続されます。

コストは「クレジット消費×単価」で決まります。Warehouse以外にもクラウドサービス側のクレジット消費が別途計上される可能性があるため、月次で両方のメータリングを確認しましょう。

• 秒課金（最小1分）。短時間で頻繁に使うワークロードほどAUTO_SUSPENDが効く
• サイズは倍々。数分のバッチ短縮と費用増のトレードオフを試算して決定
• サイズ変更は安全。実行中クエリはそのまま、新規クエリから新サイズ適用
• メータリング履歴で「どの倉庫が、いつ、どれだけ」使ったかを定期点検

サイズ変更の基本（安全に拡大・縮小）

ALTER WAREHOUSE ETL_WH SET WAREHOUSE_SIZE = 'LARGE';
-- 実行中クエリは継続。新規クエリからLARGE適用
ALTER WAREHOUSE ETL_WH SET AUTO_SUSPEND = 120;
ALTER WAREHOUSE ETL_WH SET AUTO_RESUME = TRUE;

同時実行とマルチクラスタの戦略

同時実行で待ち行列（キュー）が発生しているなら、サイズ拡大より先にマルチクラスタを検討します。サイズは単一クエリの速度を主に改善しますが、マルチクラスタは「並列に実行できるクエリの数」を増やし、待ち時間を減らします。

スケーリングポリシーはSTANDARDとECONOMYの2種類。前者は新クラスタの起動が積極的で、待ち時間をより抑えやすい一方、費用が増えやすい。後者は保守的でコスト優先です。どちらも閾値や起動/停止タイミングの詳細はSnowflake側で管理されます。

BIの短時間クエリや、多数ユーザーの集中アクセスがある時間帯に最も効果を発揮します。ETLのように「重いが少数」のワークロードでは、まずサイズ拡大で単一クエリ時間を短縮する方が適切なことが多いです。

• キューが多い→マルチクラスタ、単一クエリが遅い→サイズ拡大
• STANDARDはレイテンシ重視、ECONOMYは費用重視
• 最小/最大クラスタ数で上限コントロール。夜間は1、昼間は最大3など

キューとマルチクラスタの関係（概念図）

マルチクラスタ倉庫の作成例（コスト重視のECONOMY）

CREATE WAREHOUSE BI_WH
  WAREHOUSE_SIZE = 'MEDIUM'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 3
  SCALING_POLICY = 'ECONOMY'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

-- 混雑時のみ2〜3クラスタに自動拡張、アイドルで自動停止

コスト最適化の実践（AUTO_SUSPEND/RESUME・スケジューリング・モニタ）

秒課金とAUTO_SUSPENDの組み合わせは、細切れ利用のワークロードで最も効きます。BI用途なら60〜300秒程度のサスペンドが実務でよく使われます。短すぎると再起動が頻発しレイテンシがぶれるため、利用パターンを見て微調整します。

営業日/営業時間のパターンが明確なら、スケジューラで事前にRESUME/ SUSPENDするのも有効です。大量バッチの前に一時的にサイズ拡大、終了後に元へ戻す、といった運用でピーク性能と費用のバランスを取れます。

Resource Monitorでクレジット消費に閾値を設け、超過時に通知やSUSPENDを自動化します。費用の上振れを未然に抑制できます。

• AUTO_SUSPENDは使う。短すぎる設定は避け、実測で最適化
• 営業時間に合わせてRESUME/SUSPENDや一時的なサイズ変更を自動化
• Resource Monitorで70%通知、100%停止などの二段構え
• マルチクラスタの最大数は明示設定。無制限拡張は避ける

Resource Monitorの設定例（倉庫に紐づけ）

CREATE RESOURCE MONITOR rm_monthly_budget
  WITH CREDIT_QUOTA = 500
  TRIGGERS ON 80 PERCENT DO NOTIFY
           ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE BI_WH SET RESOURCE_MONITOR = rm_monthly_budget;

設計・検証の進め方とメトリクス

設計は「仮説→計測→調整」の反復が基本です。まず、QUERY_HISTORYのQUEUED系指標（QUEUED_PROVISIONING_TIME、QUEUED_OVERLOAD_TIME）で待ち時間を確認します。待ちが多ければマルチクラスタ/最大数の見直し、単一クエリが遅ければサイズを見直します。

WAREHOUSE_LOAD_HISTORYやWAREHOUSE_METERING_HISTORYで、負荷やクレジット消費の時系列を見ます。ピーク帯とアイドル帯を切り分け、設定（サイズ、サスペンド閾値、最大クラスタ数）が実態に合っているかを検証します。

設定変更は一度に1点に絞り、変更前後で同条件の期間を比較します。BIは曜日/時間帯の季節性が強いので、少なくとも1〜2週間は観測するのが安全です。

• 待ち時間が多い＝並列度不足、サイズでなくマルチクラスタを優先
• 単一クエリが重い＝サイズ拡大で短縮、SQL改善と併用
• 費用はメータリング履歴で日/週次の傾向を把握、予算に合わせて上限設定

混雑と費用を可視化するクエリ例

-- 待ち時間（キュー）の可視化
SELECT
  DATE_TRUNC('hour', START_TIME) AS hr,
  WAREHOUSE_NAME,
  COUNT(*) AS q_cnt,
  AVG(QUEUED_PROVISIONING_TIME + QUEUED_OVERLOAD_TIME) AS avg_queue_ms,
  AVG(TOTAL_ELAPSED_TIME) AS avg_elapsed_ms
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
  AND WAREHOUSE_NAME = 'BI_WH'
GROUP BY 1,2
ORDER BY 1,2;

-- クレジット消費の時系列
SELECT
  DATE_TRUNC('day', START_TIME) AS d,
  WAREHOUSE_NAME,
  SUM(CREDITS_USED) AS credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE START_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())
  AND WAREHOUSE_NAME = 'BI_WH'
GROUP BY 1,2
ORDER BY 1,2;

アンチパターンと試験の落とし穴

よくある誤りは、同時実行の問題をサイズ拡大だけで解決しようとすることです。キューの原因は並列度不足なので、マルチクラスタで横方向に広げるのが筋です。また、AUTO_SUSPEND未設定や、最大クラスタ数の無制限設定も費用リスクにつながります。

SQL最適化を無視してサイズに頼るのも非効率です。不要なワイドSELECTや重複スキャンを抑え、クエリプロファイルを見てボトルネックを特定しましょう。ワークロード分離（ETLとBIを別倉庫に切り分け）も待ち行列の抑制に有効です。

• 同時実行の待ち行列にサイズ拡大だけで対処しない
• AUTO_SUSPEND/RESUMEを必ず有効化し、値は実測で最適化
• 最大クラスタ数を明示し、予算に合わせて上限を設定
• ETLとBIを同一倉庫で混在させない（分離する）
• 設定変更は1点ずつ、変更前後を同条件で比較

ワークロード分離（倉庫を役割ごとに分ける）

CREATE WAREHOUSE ETL_WH
  WAREHOUSE_SIZE = 'LARGE'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 1
  AUTO_SUSPEND = 300
  AUTO_RESUME = TRUE;

CREATE WAREHOUSE BI_WH
  WAREHOUSE_SIZE = 'MEDIUM'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 3
  SCALING_POLICY = 'ECONOMY'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

問題で確認

よくある質問