「あれ、今月のクレジット消費、ちょっと多くない…?」となったら
Snowflakeを使っていると、ある日突然 クレジット消費が急増 していて慌てた経験はありませんか?Snowflakeは使った分だけ課金される従量課金モデルなので、放っておくと数日で月の予算を超えてしまうこともあります。
この記事では、クレジット消費が急に増えたときの 原因の調べ方 と、すぐにできる 削減テクニック を解説します。読み終えれば「とりあえずどこを見ればいいか」が分かるようになります。
クレジットはどこで消費されているの?
まず押さえておきたいのが、Snowflakeのクレジット消費は主に次の3つから発生するという点です。
- 仮想ウェアハウス: クエリを実行するためのコンピュート。稼働時間で課金。
- Serverless機能: Snowpipe、自動クラスタリング、マテビュー再構築、サーバーレスタスクなど。
- クラウドサービス層: メタデータ管理や認証。通常は全体の10%以内なら無料枠。
急増したときは「どの層が増えたのか」を切り分けるのが第一歩です。
原因を調べるSQL ― ACCOUNT_USAGEを使おう
Snowflakeには SNOWFLAKE.ACCOUNT_USAGE という監査ビューがあり、過去365日分の使用状況を確認できます。詳しくは Snowflake監査ログ入門|Account UsageとInformation Schemaの違いをやさしく解説 で紹介していますが、まずは以下のクエリを実行してみましょう。
-- 直近30日のウェアハウス別クレジット消費
SELECT WAREHOUSE_NAME,
DATE_TRUNC('day', START_TIME) AS day,
SUM(CREDITS_USED) AS credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE START_TIME >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY day DESC, credits DESC;これで「どのウェアハウスが、いつから増えたか」が見えてきます。さらに犯人クエリを特定したいときは QUERY_HISTORY を使いましょう。
-- 高コストなクエリTop20
SELECT QUERY_ID, USER_NAME, WAREHOUSE_NAME, WAREHOUSE_SIZE,
TOTAL_ELAPSED_TIME/1000 AS sec,
CREDITS_USED_CLOUD_SERVICES
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME >= DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY TOTAL_ELAPSED_TIME DESC
LIMIT 20;
よくある急増パターンと削減策
① オートサスペンドが効いていない
ウェアハウスがアイドル状態でも止まらず動き続けているケースです。デフォルトの600秒は長いので、60秒程度に短縮するのがおすすめです。
ALTER WAREHOUSE MY_WH SET AUTO_SUSPEND = 60 AUTO_RESUME = TRUE;② ウェアハウスサイズが大きすぎる
XLサイズで小さなクエリを延々と回している、というのもありがちです。クエリプロファイルでスピル(メモリ溢れ)が出ていなければ、サイズを下げて様子を見ましょう。クエリ自体が遅い場合は Snowflakeクエリが遅い原因と高速化チェックリスト完全版 もあわせてご覧ください。
③ 重いクエリが繰り返し走っている
BIツールの自動更新やETLの無限リトライが原因になることも。Memory limit exceededエラー が頻発しているなら、クエリ最適化の合図です。
④ リソースモニターで上限を設定する
「気付いたら使いすぎてた」を防ぐには リソースモニター が最強です。クレジットクォータを設定し、超えたら自動でサスペンドできます。
CREATE OR REPLACE RESOURCE MONITOR RM_MONTHLY
WITH CREDIT_QUOTA = 100
FREQUENCY = MONTHLY START_TIMESTAMP = IMMEDIATELY
TRIGGERS ON 80 PERCENT DO NOTIFY
ON 100 PERCENT DO SUSPEND
ON 110 PERCENT DO SUSPEND_IMMEDIATE;
ALTER WAREHOUSE MY_WH SET RESOURCE_MONITOR = RM_MONTHLY;上限到達時のエラー対応は Snowflakeリソースモニターのクレジット上限到達エラー解除手順 を参考にしてください。
まとめ
クレジット急増を見つけたら、まずは WAREHOUSE_METERING_HISTORY と QUERY_HISTORY で「どこ」「いつ」「誰が」を特定し、オートサスペンド・サイズ調整・リソースモニターの3点セットで対処していきましょう。日々の運用ではウェアハウスの 命名規則 を整えておくと、原因特定もぐっと楽になりますよ。
参考リンク
関連記事
- Snowflakeクエリが遅い原因と高速化チェックリスト完全版 – クエリの遅さはクレジット浪費の元凶。最適化の第一歩に。
- Snowflake「Memory limit exceeded」エラーの原因と解決方法 – スピルが発生する重いクエリの見つけ方を解説。
- Snowflakeリソースモニターのクレジット上限到達エラー解除手順 – 上限に達したときの復旧方法。
- Snowflake監査ログ入門|Account UsageとInformation Schemaの違い – 利用状況を調べるビューの使い分け。
- Snowflake命名規則ベストプラクティス – ウェアハウス名を整えるとコスト分析が楽になります。
