この記事について
Snowflake は従量課金のため、使い方を誤るとコストが急増する。この記事ではコスト構造の理解、監視方法、最適化のベストプラクティスを整理する。
1. コスト構造
1-1. 3つのコスト要素
Snowflake の月額コスト =
コンピュート(クレジット)
+ ストレージ
+ データ転送
| 要素 |
課金単位 |
割合(典型的) |
| コンピュート |
クレジット × 単価 |
60〜80% |
| ストレージ |
TB × 月額 |
15〜30% |
| データ転送 |
GB × 単価(リージョン間のみ) |
5%以下 |
コンピュートが圧倒的に大きい。コスト最適化 = コンピュート最適化。
1-2. クレジットの仕組み
| Warehouse サイズ |
クレジット/時間 |
1分あたり |
| X-Small |
1 |
0.0167 |
| Small |
2 |
0.0333 |
| Medium |
4 |
0.0667 |
| Large |
8 |
0.1333 |
| X-Large |
16 |
0.2667 |
最低課金は60秒。60秒以内に終わるクエリでも1分分のクレジットが消費される。
1-3. クレジット単価(エディション別)
| エディション |
特徴 |
単価(相対) |
| Standard |
基本機能 |
$ |
| Enterprise |
マルチクラスタ、マスキング、暗号化キー管理 |
||BusinessCritical|HIPAA、PCIDSS、PrivateLink|$ |
| Virtual Private |
専用インフラ |
$$$$ |
1-4. Serverless 機能のコスト
一部の機能は Virtual Warehouse を使わず、Snowflake 管理のコンピュートで動く。
| 機能 |
課金 |
| Snowpipe |
ファイル数 + コンピュート時間 |
| 自動クラスタリング |
再クラスタリングのコンピュート |
| Search Optimization |
インデックス構築・維持 |
| Tasks(Serverless) |
コンピュート時間 |
| Cortex LLM |
トークン数 |
2. コスト監視
2-1. Resource Monitor
Warehouse のクレジット消費を監視し、閾値でアラート・停止する。
-- Resource Monitor の作成
CREATE RESOURCE MONITOR monthly_limit
WITH CREDIT_QUOTA = 1000 -- 月1000クレジット
FREQUENCY = MONTHLY
START_TIMESTAMP = IMMEDIATELY
TRIGGERS
ON 75 PERCENT DO NOTIFY -- 75%でアラート
ON 90 PERCENT DO NOTIFY -- 90%でアラート
ON 100 PERCENT DO SUSPEND -- 100%で Warehouse を停止
ON 110 PERCENT DO SUSPEND_IMMEDIATE; -- 110%で即時停止
-- Warehouse に適用
ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_limit;
2-2. ACCOUNT_USAGE ビュー
過去のクレジット消費を分析する。
-- Warehouse 別のクレジット消費(過去30日)
SELECT warehouse_name,
SUM(credits_used) AS total_credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY total_credits DESC;
-- クエリ別のコスト(重いクエリの特定)
SELECT query_id,
warehouse_name,
execution_time / 1000 AS exec_seconds,
bytes_scanned / (1024*1024*1024) AS gb_scanned
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY execution_time DESC
LIMIT 20;
2-3. Snowflake のコストダッシュボード
Snowsight(Web UI)の「Admin > Cost Management」で視覚的に確認可能。
3. コスト最適化のベストプラクティス
3-1. Warehouse の最適化
| 対策 |
効果 |
方法 |
| 自動サスペンド |
アイドル時のコスト削減 |
AUTO_SUSPEND = 60(60秒) |
| 適切なサイズ選択 |
過剰なコンピュートを避ける |
小さいサイズから始めて調整 |
| ワークロード分離 |
不要な大きい Warehouse を避ける |
BI用(XS)、ETL用(L)を分ける |
| マルチクラスタ |
同時実行のスケーリング |
単一 Warehouse のサイズアップより効率的 |
-- 推奨設定
ALTER WAREHOUSE analytics_wh SET
AUTO_SUSPEND = 60, -- 1分でサスペンド
AUTO_RESUME = TRUE, -- クエリ到着で自動起動
MIN_CLUSTER_COUNT = 1, -- 最小1クラスタ
MAX_CLUSTER_COUNT = 3, -- 最大3クラスタ
SCALING_POLICY = 'ECONOMY'; -- コスト重視のスケーリング
3-2. クエリの最適化
| 対策 |
効果 |
| 必要なカラムだけ SELECT |
スキャンデータ量を削減 |
| WHERE 句でフィルタ |
パーティションプルーニングが効く |
| Clustering Key |
大規模テーブルのプルーニング効率向上 |
| 結果キャッシュの活用 |
同じクエリは Warehouse 不要($0) |
| LIMIT の活用 |
探索的クエリでは LIMIT をつける |
-- 悪い例
SELECT * FROM sales; -- 全カラム、全行
-- 良い例
SELECT order_id, amount, region
FROM sales
WHERE date >= '2024-04-01'
AND region = 'APAC';
-- → 必要カラムだけ、フィルタでプルーニング
3-3. ストレージの最適化
| 対策 |
効果 |
| タイムトラベル期間の短縮 |
古いデータの保持コスト削減 |
| 一時テーブル / Transient テーブル |
フェイルセーフなし(コスト削減) |
| 不要テーブルの削除 |
ストレージ解放 |
| クローンの管理 |
CLONE はメタデータだけだが、変更が蓄積するとストレージ増加 |
-- タイムトラベル期間を短縮(デフォルト1日、最大90日)
ALTER TABLE staging_data SET DATA_RETENTION_TIME_IN_DAYS = 0;
-- Transient テーブル(フェイルセーフなし)
CREATE TRANSIENT TABLE temp_results (...);
3-4. Databricks とのコスト比較
| 観点 |
Snowflake |
Databricks |
| 課金単位 |
クレジット(シンプル) |
DBU(ワークロード種別で単価が異なる) |
| 最低課金 |
60秒 |
秒単位 |
| アイドルコスト |
自動サスペンドで $0 |
自動停止で $0 |
| ストレージ |
Snowflake 管理(やや高い) |
クラウドストレージ直接(安い) |
| 予測しやすさ |
高い(クレジット × 単価) |
中程度(DBU 種別が複雑) |
4. 運用のベストプラクティス
4-1. 環境分離
-- アカウントレベルの分離(推奨)
Production Account → 本番データ、本番 Warehouse
Development Account → 開発データ、開発 Warehouse
-- または Database レベルの分離
CREATE DATABASE prod_db;
CREATE DATABASE dev_db;
CREATE DATABASE staging_db;
4-2. ロール設計
ACCOUNTADMIN(緊急時のみ使用)
│
├── SECURITYADMIN
│ └── ユーザー・ロール管理
│
└── SYSADMIN
├── ETL_ROLE → ETL Warehouse + Raw/Silver DB
├── ANALYST_ROLE → BI Warehouse + Gold DB(読み取り)
├── DS_ROLE → ML Warehouse + 全 DB(読み取り)
└── ADMIN_ROLE → 全 Warehouse + 全 DB
4-3. 監視すべきメトリクス
| メトリクス |
確認方法 |
アラート条件 |
| クレジット消費 |
Resource Monitor |
月間予算の75%超過 |
| クエリ実行時間 |
QUERY_HISTORY |
通常の3倍以上 |
| Warehouse キュー |
WAREHOUSE_LOAD_HISTORY |
キュー待ちが頻発 |
| ストレージ増加 |
STORAGE_USAGE |
想定以上の増加 |
| ログイン失敗 |
LOGIN_HISTORY |
不正アクセスの兆候 |
5. まとめ
| テーマ |
要点 |
| コスト構造 |
コンピュート(60〜80%)が支配的。Warehouse の最適化が最重要 |
| 監視 |
Resource Monitor + ACCOUNT_USAGE ビュー |
| Warehouse 最適化 |
自動サスペンド、適切なサイズ、ワークロード分離 |
| クエリ最適化 |
カラム選択、フィルタ、Clustering Key |
| ストレージ最適化 |
タイムトラベル期間、Transient テーブル |
| 運用 |
環境分離、ロール設計、メトリクス監視 |
参考文献
- Snowflake. “Understanding Compute Cost.” https://docs.snowflake.com/en/user-guide/cost-understanding-compute
- Snowflake. “Resource Monitors.” https://docs.snowflake.com/en/user-guide/resource-monitors
- Snowflake. “Cost Management Best Practices.” https://docs.snowflake.com/en/user-guide/cost-managing