Snowflake クラウドサービス利用料の仕組みと最適化

はじめに

Snowflake の利用明細を見ると、ウェアハウスのコンピュートとは別に「クラウドサービス（Cloud Services）」というクレジット消費が記録されている。これが何者で、どういう条件で課金され、どう追跡・削減するかを整理する。

公式ドキュメント: Understanding compute cost / Optimizing cloud services for cost

クラウドサービスレイヤーとは

Snowflake のアーキテクチャは大きく3層に分かれる。

┌────────────────────────────────────────────┐
│        Cloud Services Layer                │  ← 今回の対象
│  認証 / メタデータ管理 / クエリコンパイル      │
│  アクセス制御 / トランザクション管理           │
├────────────────────────────────────────────┤
│        Compute Layer（仮想ウェアハウス）      │  ← クエリ・DML実行
├────────────────────────────────────────────┤
│        Storage Layer                       │  ← データ永続化
└────────────────────────────────────────────┘

クラウドサービスレイヤーは、ユーザーが明示的にウェアハウスを起動しなくても、Snowflake が内部的に常時稼働させているコンポーネントになる。主な役割は以下のとおり。

10%ルール（Cloud Services Adjustment）

課金の仕組み

クラウドサービスのクレジット消費は常に発生するが、課金（請求）されるのは一定の条件を超えた場合のみとなる。

1日（UTC）のクラウドサービス消費量が、同日の仮想ウェアハウス消費量の10%を超えた場合のみ、超過分が課金される。

超過分のみが課金される仕組みを「Cloud Services Adjustment（調整）」と呼ぶ。METERING_DAILY_HISTORY ビューの CREDITS_ADJUSTMENT_CLOUD_SERVICES 列が負の値で記録され、その分だけ差し引かれる。

計算例

公式ドキュメントの具体例を以下に示す。

• Nov 1: CS=20 > VW×10%=10 → 超過10クレジット分が課金。調整額は −10
• Nov 2: CS=10 < VW×10%=12 → CS が10%未満 → 調整額は −10（CS全額控除）
• Nov 3: CS=5 < VW×10%=8 → 全額調整。調整額は −5（CS全額控除）
• Nov 4: CS=13 > VW×10%=10 → 超過3クレジット分が課金。調整額は −10

クラウドサービス費用が発生するユースケース

以下のいずれも、仮想ウェアハウスを使わずにクラウドサービスのみでリソースを消費するパターンになる。

操作別クラウドサービス消費量の実測

実際に各種操作を実行し、INFORMATION_SCHEMA.QUERY_HISTORY でCS消費量を計測した。以下はその結果だ。

CS のみで完結する操作（ウェアハウス不使用）

bytes_scanned = 0 となり、仮想ウェアハウスを起動せずにCS単独で処理される操作の一覧。

結果キャッシュの挙動

同一クエリを2回実行した際の比較。

結果キャッシュヒット時もCS消費はゼロにはならない。これはCSがキャッシュを管理・提供する処理自体にCSリソースを使うためだ。消費量は初回の約78%程度で、完全に消えるわけではない点に留意する。キャッシュヒットの特徴は bytes_scanned = 0 かつ rows_produced > 0 の組み合わせで判別できる。

-- 結果キャッシュヒットかどうかを判別するクエリ
SELECT
    query_type,
    LEFT(query_text, 80)                  AS query_snippet,
    ROUND(credits_used_cloud_services, 8) AS cs_credits,
    bytes_scanned,
    rows_produced,
    CASE
        WHEN bytes_scanned = 0 AND rows_produced > 0 THEN 'RESULT_CACHE_HIT'
        WHEN bytes_scanned > 0 AND rows_produced > 0 THEN 'WAREHOUSE_COMPUTE'
        ELSE 'CS_ONLY_METADATA'
    END AS access_type
FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY(
    DATEADD('minute', -30, CURRENT_TIMESTAMP),
    NULL, 200
))
WHERE query_type = 'SELECT'
ORDER BY start_time DESC;

クラウドサービス費用の追跡方法

1. 日次課金サマリー（METERING_DAILY_HISTORY）

SNOWFLAKE.ACCOUNT_USAGE.METERING_DAILY_HISTORY ビューで、日ごとのCS使用量と調整後の実課金量を確認できる。

-- 過去1ヶ月のCS課金サマリー（課金量が多い日順）
SELECT
    usage_date,
    credits_used_cloud_services,
    credits_adjustment_cloud_services,
    credits_used_cloud_services + credits_adjustment_cloud_services AS billed_cloud_services
FROM snowflake.account_usage.metering_daily_history
WHERE usage_date >= DATEADD(month, -1, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0
ORDER BY 4 DESC;

実行結果：

すべての行で billed_cloud_services = 0 になっている。CS消費量と調整額が完全に一致しており、VWの10%以内に収まっているため追加課金が発生していない状態だ。調整の仕組みが正常に機能している例として読み取れる。

主要列の意味：

2. ウェアハウス別の分析（WAREHOUSE_METERING_HISTORY）

CSの割合が高いウェアハウスを特定することで、問題のある処理を絞り込める。

-- CS割合が高いウェアハウスを特定
SELECT
    warehouse_name,
    SUM(credits_used)                AS credits_used,
    SUM(credits_used_cloud_services) AS credits_used_cloud_services,
    ROUND(
        SUM(credits_used_cloud_services) / NULLIF(SUM(credits_used), 0) * 100,
        2
    )                                AS pct_cloud_services
FROM snowflake.account_usage.warehouse_metering_history
WHERE TO_DATE(start_time) >= DATEADD(month, -1, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0
GROUP BY 1
ORDER BY 4 DESC;

実行結果：

CLOUD_SERVICES_ONLY は Snowflake が仮想ウェアハウスを介さずに実行する処理（DDL、メタデータ操作等）を計上する擬似ウェアハウスで、CS割合が必ず100%になる。COMPUTE_WH は 4.14%、RETAIL_WH は 2.81% とともに10%未満に収まっており、追加課金は発生していない。

PCT_CLOUD_SERVICES が 10% を大きく超えているウェアハウスが出た場合、前節のパターンに該当する処理が動いている可能性が高い。

3. クエリタイプ別の分析（QUERY_HISTORY）

どの種類の操作がCSを多く消費しているか確認する。

-- 過去7日間のクエリタイプ別CS消費量
SELECT
    query_type,
    ROUND(SUM(credits_used_cloud_services), 6) AS cs_credits,
    COUNT(1)                                   AS num_queries
FROM snowflake.account_usage.query_history
WHERE start_time >= TIMESTAMPADD(day, -7, CURRENT_TIMESTAMP)
GROUP BY 1
ORDER BY 2 DESC
LIMIT 10;

実行結果：

SELECT が CS消費の大半を占めており、DROP（テーブル削除等のDDL）と SHOW がそれに続く。281件の SHOW に対してクレジット消費は 0.000596 と軽微だが、アプリが頻繁にメタデータを取得する構成では件数がこの数十倍規模になることもある。

4. Snowsight での確認

Snowsight の Admin > Cost Management からグラフィカルに確認できる。サービスタイプや期間でフィルタリングでき、クエリを書かずに傾向を把握するのに適している。

補足

INFORMATION_SCHEMA と ACCOUNT_USAGE の違い

追跡クエリを書く際、スキーマ選択で挙動が変わる点に注意が必要となる。

モニタリング用途では ACCOUNT_USAGE を使うのがコスト面で有利なケースが多い。

METERING_DAILY_HISTORY の注意点

• ビューのレイテンシは最大180分（3時間）
• CREDITS_USED_CLOUD_SERVICES 列のレイテンシは最大6時間（WAREHOUSE_METERING_HISTORY 側）
• 月次請求と照合する際は、セッションのタイムゾーンを UTC に設定してから参照する

ALTER SESSION SET TIMEZONE = UTC;

コスト削減の優先順位

実際の対策として効果が出やすい順に並べると以下のようになる。

1. INFORMATION_SCHEMA → ACCOUNT_USAGE への切り替え — コード変更だけで対応可能
2. 高頻度 SHOW コマンドの削減 — ツール設定の見直しで対応
3. 単一行 INSERT のバルク化 — アーキテクチャ変更が必要だが効果大
4. COPY コマンドの S3 バケット構造見直し — 段階的に対応可能

まとめ

• クラウドサービスレイヤーは認証・メタデータ管理・クエリコンパイルを担い、常時クレジットを消費する
• 課金は「1日のCS消費がVWの10%を超えた場合の超過分のみ」という仕組みで、多くの場合は調整が効く
• METERING_DAILY_HISTORY・WAREHOUSE_METERING_HISTORY・QUERY_HISTORY の3つのビューで段階的に原因を特定できる
• CS費用が高い場合はまず「高頻度のSHOW/INFORMATION_SCHEMAクエリ」と「単一行INSERT」を疑う

参考資料

Understanding compute cost | Snowflake Documentation

docs.snowflake.com

Optimizing cloud services for cost | Snowflake Documentation

docs.snowflake.com

Exploring compute cost | Snowflake Documentation

docs.snowflake.com

METERING_DAILY_HISTORY view | Snowflake Documentation

docs.snowflake.com