Snowflakeの課金はコンピュート(クレジット)とストレージ(TB/月)の2軸で構成されます。 コンピュートはウェアハウスの稼働時間とサーバーレスサービスの使用量に応じてクレジットが消費され、 ストレージはアクティブデータ・Time Travel・Fail-safeの合計容量に対して課金されます。 この記事ではクレジット課金モデルの構造、監視SQL、Resource Monitorの設定、 そして実務で即使えるコスト最適化5策を整理します。
| 課金カテゴリ | 対象 | 課金単位 | 課金タイミング |
|---|---|---|---|
| ウェアハウスクレジット | Virtual Warehouseの稼働 | サイズ × 稼働時間(秒単位、最低60秒) | ウェアハウス稼働中 |
| Cloud Services | メタデータ操作・認証・最適化 | コンピュートクレジットの10%超過分 | 常時(10%免除枠あり) |
| Serverless Credit | Snowpipe / Clustering / MV / Replication等 | サービス固有のクレジットレート | サービス利用時 |
| ストレージ | テーブル / ステージ / Time Travel / Fail-safe | TB/月(圧縮後のデータ量) | 日次で計測、月次精算 |
| データ転送 | リージョン間/クラウド間データ移動 | GB単位 | 転送発生時 |
| ウェアハウスサイズ | 1時間あたりのクレジット | ノード数 |
|---|---|---|
| X-Small | 1 | 1 |
| Small | 2 | 2 |
| Medium | 4 | 4 |
| Large | 8 | 8 |
| X-Large | 16 | 16 |
| 2X-Large | 32 | 32 |
| 3X-Large | 64 | 64 |
| 4X-Large | 128 | 128 |
Multi-cluster Warehouseの場合、上記クレジットにクラスタ数を掛けた値が消費されます。 たとえばMediumサイズで3クラスタ稼働中は 4 × 3 = 12クレジット/時です。
-- ウェアハウス別の日次クレジット消費
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())
GROUP BY 1, 2
ORDER BY total_credits DESC;
-- 時間帯別のクレジット消費パターン分析
SELECT
EXTRACT(HOUR FROM start_time) AS hour_of_day,
warehouse_name,
AVG(credits_used) AS avg_hourly_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD(DAY, -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY warehouse_name, hour_of_day;-- 全サービスのクレジット消費を一覧化
SELECT
start_time::DATE AS usage_date,
service_type,
SUM(credits_used) AS total_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY
WHERE start_time >= DATEADD(MONTH, -1, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY usage_date, total_credits DESC;
-- service_type の値:
-- WAREHOUSE_METERING : ウェアハウス
-- AUTO_CLUSTERING : Automatic Clustering
-- MATERIALIZED_VIEW : MV メンテナンス
-- PIPE : Snowpipe
-- REPLICATION : レプリケーション
-- SEARCH_OPTIMIZATION : Search Optimization Service
-- SERVERLESS_TASK : Serverless TaskResource Monitorは、ウェアハウスのクレジット消費に上限を設定し、 閾値到達時に通知・サスペンドを行うガバナンス機能です。 ACCOUNTADMINロールで作成・管理します。
-- Resource Monitorの作成
CREATE RESOURCE MONITOR bi_monitor
WITH CREDIT_QUOTA = 500
FREQUENCY = MONTHLY
START_TIMESTAMP = IMMEDIATELY
TRIGGERS
ON 80 PERCENT DO NOTIFY
ON 95 PERCENT DO SUSPEND
ON 100 PERCENT DO SUSPEND_IMMEDIATE;
-- ウェアハウスにResource Monitorを割り当て
ALTER WAREHOUSE bi_dashboard_wh SET RESOURCE_MONITOR = bi_monitor;
-- アカウントレベルのResource Monitor(全ウェアハウスに適用)
ALTER ACCOUNT SET RESOURCE_MONITOR = account_monitor;
-- Resource Monitorの確認
SHOW RESOURCE MONITORS;| アクション | 動作 | 推奨用途 |
|---|---|---|
| NOTIFY | 管理者に通知のみ(ウェアハウスは継続稼働) | 最初の閾値(70〜80%) |
| SUSPEND | 実行中クエリの完了を待ってからウェアハウスを停止 | 中間の閾値(90〜95%) |
| SUSPEND_IMMEDIATE | 実行中クエリを即座にキャンセルしてウェアハウスを停止 | 最終閾値(100%) |
-- 対話型: 5分(300秒)で自動サスペンド
ALTER WAREHOUSE bi_wh SET AUTO_SUSPEND = 300;
-- バッチ: 1分(60秒)で自動サスペンド
ALTER WAREHOUSE etl_wh SET AUTO_SUSPEND = 60;
-- AUTO_RESUME を有効にしてクエリ受信時に自動再開
ALTER WAREHOUSE bi_wh SET AUTO_RESUME = TRUE;BI・ETL・データサイエンスなど異なるワークロードを同一ウェアハウスで実行すると、 リソース競合によりすべてのクエリが遅くなり、結果的にコスト増大につながります。 ワークロードごとに専用ウェアハウスを作成し、適切なサイズとAUTO_SUSPEND設定を個別に行います。
-- パーティションプルーニング効率が低いクエリの特定
SELECT
query_id,
query_text,
partitions_scanned,
partitions_total,
ROUND(partitions_scanned / NULLIF(partitions_total, 0) * 100, 1) AS scan_pct,
bytes_scanned / POWER(1024, 3) AS gb_scanned
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD(DAY, -7, CURRENT_TIMESTAMP())
AND partitions_total > 100
AND partitions_scanned / NULLIF(partitions_total, 0) > 0.8
ORDER BY bytes_scanned DESC
LIMIT 20;-- Time TravelとFail-safeのストレージ使用量を確認
SELECT
table_catalog AS database_name,
table_schema AS schema_name,
table_name,
ROUND(active_bytes / POWER(1024, 3), 2) AS active_gb,
ROUND(time_travel_bytes / POWER(1024, 3), 2) AS time_travel_gb,
ROUND(failsafe_bytes / POWER(1024, 3), 2) AS failsafe_gb,
ROUND(retained_for_clone_bytes / POWER(1024, 3), 2) AS clone_gb
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS
WHERE active_bytes > 0
ORDER BY (active_bytes + time_travel_bytes + failsafe_bytes) DESC
LIMIT 30;
-- 不要なTransientテーブルの検出(Fail-safeが不要な中間データ)
-- Transientテーブルに切り替えることでFail-safeストレージコストを削減-- Serverlessサービス別のクレジット消費トレンド
SELECT
start_time::DATE AS usage_date,
service_type,
SUM(credits_used) AS credits
FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY
WHERE start_time >= DATEADD(MONTH, -1, CURRENT_TIMESTAMP())
AND service_type != 'WAREHOUSE_METERING'
GROUP BY 1, 2
ORDER BY usage_date, credits DESC;-- ウェアハウス別の月次コストレポート(チャージバック用)
SELECT
warehouse_name,
DATE_TRUNC('MONTH', start_time) AS billing_month,
SUM(credits_used) AS total_credits,
SUM(credits_used) * 3.00 AS estimated_cost_usd -- 単価は契約による
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD(MONTH, -3, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY billing_month DESC, total_credits DESC;Cost Management
問題 1
ある企業のデータチームがMediumサイズのウェアハウスを月次のバッチETLに使用しているが、ETLジョブは1日1回30分しか実行されない。にもかかわらず月間のクレジット消費が想定の5倍になっている。最も可能性の高い原因と対策の組み合わせはどれか。
正解: B
Mediumサイズ(4クレジット/時)のウェアハウスが24時間×30日稼働すると4×24×30 = 2,880クレジットを消費しますが、1日30分のETLのみなら4×0.5×30 = 60クレジットで済むはずです。5倍の差はAUTO_SUSPENDが無効でウェアハウスが常時稼働していることが最も可能性の高い原因です。AUTO_SUSPENDを60〜300秒に設定することでアイドル時に自動停止し、コストを大幅に削減できます。
Snowflakeのクレジットとは何ですか?実際の金額はどう計算しますか?
クレジットはSnowflakeのコンピュートリソース消費を測る単位です。1クレジットの金額はEdition・クラウドプロバイダー・リージョンの組み合わせで異なり、契約形態(On-Demand vs Capacity)によっても変わります。たとえばAWS US-EAST-1のEnterprise Editionでは1クレジットが約$3(On-Demand)です。WAREHOUSE_METERING_HISTORYで消費クレジット数を取得し、契約単価を掛けることで実コストを算出できます。ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILYビューでは金額ベースで日次消費を確認できます。
Resource Monitorのアクションで「Suspend & Immediately」はどう動作しますか?
SUSPEND_IMMEDIATEアクションは、クレジット消費が閾値に達した時点で実行中のクエリを即座にキャンセルしてウェアハウスを停止します。一方、SUSPENDアクションは現在実行中のクエリの完了を待ってからウェアハウスを停止します。SUSPEND_IMMEDIATEはコスト上限を厳格に守る必要がある場合に使いますが、ユーザーのクエリが中断されるため本番BIウェアハウスには通常SUSPENDを推奨します。NOTIFYアクションはウェアハウスを停止せず管理者に通知のみ行うため、最初の閾値(例: 80%)にNOTIFY、最終閾値(100%)にSUSPENDを設定する多段構成が一般的です。
Serverless Creditはウェアハウスクレジットと何が違いますか?
ウェアハウスクレジットはユーザーが明示的に作成したVirtual Warehouseの稼働時間に対して課金されます。Serverless Creditは、Snowflakeが自動管理するバックグラウンド処理(Automatic Clustering、Materialized View Maintenance、Snowpipe、Replication、Search Optimization Service等)に対して課金されます。Serverless Creditの単価はウェアハウスクレジットとは異なり、通常やや高めに設定されています。SERVERLESS_TASK_HISTORYやAUTOMATIC_CLUSTERING_HISTORYなどのビューでサービス別のServerless Credit消費を追跡できます。
NicheeLab編集部
データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。
Snowflake資格一覧|全11試験(SnowPro)の難易度・費用
Snowflake認定資格(SnowPro)全11試験の一覧・難易度・費用・出題範囲を徹底解説。...
Snowflake試験の難易度ランキング|全11資格を徹底比較
Snowflake(SnowPro)認定全11試験の難易度をランキング形式で比較。学習時間・合格に必要なスキルから分析。...
Snowflake資格の勉強方法|効率的な学習ルートと合格のコツ
Snowflake認定資格(SnowPro)に最短で合格するための勉強方法。公式リソース・学習スケジュールを徹底ガイド。...
SnowPro Core試験完全解説|出題範囲・問題例・合格戦略
SnowPro Core Certification(COF-C03)を徹底解説。出題範囲・100問の試験形式・合格ライ...
SnowPro Platform Associate完全解説|入門試験の攻略
SnowPro Associate: Platform Certification(SOL-C01)を徹底解説。最も簡単...