Snowflake Cloud Services：料金と監視のポイント

計算はUTCタイムゾーンで毎日行われます。Snowflakeはその日のウェアハウスコンピュートクレジットとCloud Servicesクレジットを合計し、（ウェアハウスクレジットの10％）または（使用されたCloud Servicesクレジット）のいずれか小さい方を調整額とします。請求対象となるのは、Cloud Servicesクレジットから調整額を差し引いた値です。

例1：しきい値未満（課金なし）

• ウェアハウスコンピュート：100クレジット
• Cloud Services：8クレジット
• 調整額：8クレジット（Cloud Servicesが10％のしきい値を下回るため）
• Cloud Services請求額：0クレジット
• 合計請求額：100クレジット

例2：しきい値超過（一部課金）

• ウェアハウスコンピュート：100クレジット
• Cloud Services：20クレジット
• 調整額：10クレジット（10％のしきい値分）
• Cloud Services請求額：10クレジット
• 合計請求額：110クレジット

重要な例外：Snowpipe、Automatic Clustering、Materialized Viewsといったサーバーレス機能は、10％調整の対象外です。これらは個別の項目として課金されます。

Cloud Servicesクレジットは、Snowflakeのサービス層における次のような処理で消費されます。

• クエリのコンパイルと最適化 - すべてのクエリは実行前にコンパイルされます
• メタデータ操作 - DDLコマンド（CREATE、ALTER、DROP）、ゼロコピークローン、SHOWコマンド、INFORMATION_SCHEMAクエリ
• 認証とアクセス制御 - ユーザーログイン、ロール切り替え、権限チェック
• クエリ結果のキャッシュ - キャッシュ結果の管理と提供
• ファイルリスト処理 - COPYコマンドはロード前にオブジェクトストレージのファイル一覧を取得します

SnowflakeのACCOUNT_USAGEスキーマには、Cloud Servicesを追跡するためのビューが用意されています。データには約2時間の遅延があり、保持期間は365日です。

日次のCloud Services請求

実際に課金が発生した日を確認します。

SELECT
    usage_date,
    credits_used_cloud_services,
    credits_adjustment_cloud_services,
    credits_used_cloud_services + credits_adjustment_cloud_services AS billed_cloud_services,
    credits_used_compute,
    ROUND(credits_used_cloud_services / NULLIF(credits_used_compute, 0) * 100, 2) AS cs_pct_of_compute
FROM snowflake.account_usage.metering_daily_history
WHERE usage_date >= DATEADD(month, -1, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0
ORDER BY billed_cloud_services DESC;

billed_cloud_servicesが正の値であれば、その日に課金が発生したことを意味します。

クエリタイプ別のCloud Services

Snowflakeのquery_historyビューにはcredits_used_cloud_services列があり、どのクエリタイプがCloud Servicesを多く消費しているかを特定するのに役立ちます。

SELECT
    query_type,
    SUM(credits_used_cloud_services) AS total_cs_credits,
    COUNT(1) AS num_queries,
    AVG(credits_used_cloud_services) AS avg_cs_per_query
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0
GROUP BY query_type
ORDER BY total_cs_credits DESC;

Cloud Services消費の多いクエリ

同じ考え方で、Cloud Services消費が大きい個別のクエリを抽出できます。

SELECT
    query_id,
    user_name,
    warehouse_name,
    query_type,
    credits_used_cloud_services,
    SUBSTRING(query_text, 1, 100) AS query_snippet
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0.001
ORDER BY credits_used_cloud_services DESC
LIMIT 100;

Snowflakeのお客様と取り組む中で、Cloud Servicesのコストを押し上げる要因として繰り返し見られるパターンがあります。

1. 高頻度のメタデータクエリ

SELECT 1、SELECT CURRENT_SESSION()、showクエリといった単純なクエリでも、1日に何万回も実行されれば積み上がります。また、INFORMATION_SCHEMAに対するクエリはウェアハウスコンピュートを使わず、Cloud Servicesのみを消費します。

対処法：クエリ履歴を見て、こうしたヘルスチェック系クエリが請求額を押し上げているなら、実行頻度を下げましょう。遅延が許容できるならinformation_schemaの代わりにaccount_usageスキーマを使う手もありますが、判断は慎重に。多くの場合、ウェアハウスを起動しない方が合理的です。

2. 過剰なDDLとクローン

DDL操作はすべてメタデータ操作です。大規模なスキーマを頻繁に作成・削除したり、バックアップ目的でデータベース全体をクローンしたりすると、Cloud Services消費が膨らみます。

対処法：必要最小限の粒度でクローンしましょう。スキーマ単位ではなくテーブル単位、データベース単位ではなくスキーマ単位といった具合です。クローンの頻度を可能な範囲で減らし、アカウント内で実行されるDDLが本当に必要なものに絞られているかも確認してください。

3. 単一行INSERTとスキーマの細分化

SnowflakeはOLTPシステムではありません。単一行のINSERTは、マイクロパーティション全体を置き換えることが多く、Cloud Servicesリソースを大きく消費します。さらに、顧客ごとにスキーマを分けるマルチテナント構成は過剰なメタデータを生み出します。

対処法：バッチまたはバルクロードを利用してください。マルチテナントアプリでは、可能な限りcustomer_idでクラスタリングしたテーブルを持つ共有スキーマと、分離のためのセキュアビューを使う構成がSnowflakeから推奨されています。

4. ファイル選択性の低いCOPYコマンド

COPYコマンドはオブジェクトストレージからファイル一覧を取得するため、Cloud Servicesのコンピュートを消費します。数件をコピーするために数千ファイルを一覧化していれば、消費量は大きくなります。

対処法：オブジェクトストレージは日付プレフィックスで整理し、COPYコマンドでは具体的なファイルパターンを指定しましょう。

-- すべてを一覧表示する代わりに
COPY INTO target FROM @stage/raw_data/;

-- 特定のパスだけを一覧表示：年/月/日
COPY INTO target FROM @stage/raw_data/2025/10/24/;

5. 複雑なクエリのコンパイル

JOINが過剰なクエリ、大規模な集合演算（IN、NOT IN、EXISTS）、デカルト積を含むクエリは、コンパイル時にCloud Servicesを大量に消費します。

対処法：クエリ構造をシンプルにしましょう。大きなINリストは一時テーブルとJOINに置き換え、複雑なクエリはCTEで分割します。

定期的に監視する。Cloud Services消費量を週次でレビューする運用を整えましょう。ベースラインを把握しておけば、異常を素早く検知できます。

処理をバッチ化する。DDLでもDMLでもデータロードでも、まとめて処理する方が個別実行よりほぼ確実に効率的です。

サードパーティツールのクエリを見直す。BIツール、ETLプラットフォーム、オーケストレーションシステムは、ユーザーが直接コントロールしにくいメタデータクエリのパターンを生成しがちです。設定を見直すだけで、不要なクエリを大幅に減らせる場合があります。

アラートを設定する。監視クエリをスケジュールタスクに組み込み、通知連携を加えましょう。さらに手早く始めたい場合は、すぐに使えるSELECT monitorsのアラート機能の活用がおすすめです。