第2章 アカウント管理とデータガバナンス / 想定学習時間:30〜40分 / 最終確認:2026年8月

2-6. リソースモニターとコスト管理

🎯 この節の学習目標

1. リソースモニターとは

リソースモニター(resource monitor)は、クレジット消費に上限と監視の仕組みを設けるオブジェクトです。想定外のクレジット消費(消し忘れた大型ウェアハウス、暴走したジョブなど)からアカウントを守る、コスト統制の中心的な機能です。

構成要素は次のとおりです。

要素説明
CREDIT_QUOTA監視間隔ごとに許容するクレジット数(上限の基準値)
対象(アカウント or ウェアハウス)アカウントレベルのモニターはアカウント内のすべてのウェアハウスの消費を合算して監視。ウェアハウスレベルは指定したWH群を監視
FREQUENCY消費量カウンターをリセットする間隔。MONTHLY(既定)/ DAILY / WEEKLY / YEARLY / NEVER
トリガー(TRIGGERS)クオータに対する割合(%)と、そこに達したときのアクションの組。複数設定できる(例:75%で通知、100%で停止)。100%を超える割合(110%など)も指定可能

📝 試験のポイント

割り当てのルールに注意します。1つのウェアハウスに割り当てられるリソースモニターは1つだけです(逆に、1つのモニターは複数のウェアハウスを監視できます)。また、アカウントレベルのモニターは自動的にすべてのウェアハウスに適用され、個別ウェアハウスのモニターとは独立して並行に働きます。

2. 3つのトリガーアクション

閾値に達したときのアクションは3種類あり、その違いが問われます。

アクション動作実行中のクエリ
NOTIFY通知を送るだけ。ウェアハウスは停止しない影響なし
SUSPEND(NOTIFY & SUSPEND)通知を送り、ウェアハウスをサスペンドする実行中のクエリは完了を待ってから停止する(新規クエリは受け付けない)
SUSPEND_IMMEDIATE(NOTIFY & SUSPEND IMMEDIATELY)通知を送り、ウェアハウスを即時サスペンドする実行中のクエリもキャンセルされる

💡 具体例:リソースモニターの作成と割り当て

-- ACCOUNTADMINで実行する
USE ROLE ACCOUNTADMIN;

CREATE RESOURCE MONITOR monthly_limit
  WITH CREDIT_QUOTA = 100
       FREQUENCY = MONTHLY
       START_TIMESTAMP = IMMEDIATELY
  TRIGGERS ON 75 PERCENT DO NOTIFY
           ON 100 PERCENT DO SUSPEND
           ON 110 PERCENT DO SUSPEND_IMMEDIATE;

-- 特定のウェアハウスに割り当てる
ALTER WAREHOUSE etl_wh SET RESOURCE_MONITOR = monthly_limit;

-- アカウント全体に割り当てる場合
ALTER ACCOUNT SET RESOURCE_MONITOR = monthly_limit;

この例では、月間100クレジットを基準に、75%で通知、100%で(実行中クエリの完了を待って)停止、110%で即時停止という3段構えにしています。サスペンドされたウェアハウスは、翌月にカウンターがリセットされるか、クオータが引き上げられるまで再開できません。

クレジット消費からアクションまでの流れを図にまとめます。

ウェアハウスがクレジットを消費クエリ実行・稼働時間に応じて累積
リソースモニターがFREQUENCYの期間内の消費量を集計
閾値(CREDIT_QUOTAに対する%)との比較例:75% / 100% / 110%
達した閾値のアクションを発火
NOTIFY通知のみ。稼働継続
SUSPEND実行中クエリ完了後に停止
SUSPEND_IMMEDIATE実行中クエリもキャンセルして即停止

図:リソースモニターの動作。消費量が閾値に達すると、通知のみ/完了待ち停止/即時停止のいずれかが発火する

3. コスト構成の復習

リソースモニターが守るのは主にウェアハウスのクレジットですが、Snowflakeの請求全体は次の要素で構成されます。全体像を整理しておきましょう。

コスト区分課金単位ポイント
コンピュート(ウェアハウス)クレジット(サイズと稼働時間に応じて)稼働中のみ課金。最低60秒、以降は秒単位
サーバーレス機能クレジットSnowpipe、自動クラスタリング、マテリアライズドビューの維持など、Snowflake管理のコンピュートを使う機能
クラウドサービス層クレジット1日のウェアハウス消費クレジットの10%を超えた分だけ課金される(10%ルール)。超えなければ実質無料
ストレージ圧縮後の平均使用量(TB/月)の定額Time Travel・Fail-safe領域も含まれる
データ転送転送量取り込み(ingress)は原則無料、外部への持ち出し(egress)に課金。別リージョン・別クラウドへの転送が対象

4. コストの可視化とバジェット

コスト統制の第一歩は「どこでいくら使っているか」の可視化です。主な手段は次のとおりです。

「ウェアハウスの暴走を止めたい=リソースモニター」「サーバーレス含む支出を見張って通知したい=バジェット」という使い分けを押さえておきましょう。

✅ この節のまとめ

練習問題

問1. リソースモニターを作成できるロールはどれか。

  1. SYSADMIN
  2. SECURITYADMIN
  3. ACCOUNTADMIN
  4. MONITORADMIN(専用のシステムロール)
解答と解説を見る

正解:C

リソースモニターの作成はACCOUNTADMINだけができます。作成後にMONITOR/MODIFY権限を他ロールへ付与して参照・変更を委任することはできますが、作成自体はACCOUNTADMINの専権です。AのSYSADMINはオブジェクト管理の中心ロールですがリソースモニターは作成できません。Bも権限付与管理が守備範囲であり作成はできません。DのMONITORADMINというシステムロールは存在しません。

問2. リソースモニターのトリガーアクションSUSPENDとSUSPEND_IMMEDIATEの違いとして正しいものはどれか。

  1. SUSPENDは実行中のクエリの完了を待ってから停止し、SUSPEND_IMMEDIATEは実行中のクエリをキャンセルして即時停止する
  2. SUSPENDはウェアハウスを停止し、SUSPEND_IMMEDIATEはアカウント自体を停止する
  3. SUSPENDは通知を送らないが、SUSPEND_IMMEDIATEは通知を送る
  4. 両者に機能的な違いはなく、名前が異なるだけである
解答と解説を見る

正解:A

SUSPENDは新規クエリの受け付けを止め、実行中のクエリが完了してからサスペンドします。SUSPEND_IMMEDIATEは実行中のクエリもキャンセルして即座にサスペンドします。Bは誤りで、どちらも対象はウェアハウスでありアカウントの停止ではありません。Cは誤りで、どちらのアクションも通知を伴います。Dは誤りで、実行中クエリの扱いという明確な違いがあります。

問3. リソースモニターの割り当てに関する説明として正しいものを2つ選べ。

  1. 1つのウェアハウスには1つのリソースモニターしか割り当てられない
  2. アカウントレベルのリソースモニターは、アカウント内のすべてのウェアハウスのクレジット消費を監視する
  3. 1つのウェアハウスに複数のリソースモニターを割り当てて多段の監視ができる
  4. リソースモニターはストレージ使用量の上限も強制できる
解答と解説を見る

正解:A、B

ウェアハウスに割り当てられるモニターは1つだけで(A)、アカウントレベルのモニターは全ウェアハウスの合算消費を監視します(B)。Cは Aと矛盾しており誤りです(多段の監視をしたい場合は1つのモニターに複数のトリガーを設定します)。Dは誤りで、リソースモニターが監視するのはクレジット消費であり、ストレージ使用量の上限を強制する機能はありません。

問4. クラウドサービス層の課金ルールとして正しいものはどれか。

  1. クラウドサービス層の使用量は常に全額課金される
  2. 1日のウェアハウス消費クレジットの10%を超えた分のクラウドサービス使用だけが課金される
  3. クラウドサービス層は月額固定料金である
  4. クラウドサービス層はEnterpriseエディション以上でのみ課金される
解答と解説を見る

正解:B

クラウドサービス層(認証・メタデータ管理・クエリ解析など)の消費は、その日のウェアハウス消費クレジットの10%までは請求されず、超過分だけが課金されます(10%ルール)。通常のワークロードでは10%以内に収まることが多く、実質無料になるケースが多い設計です。Aは10%の控除を無視しており誤り、Cは従量制である点と矛盾し、Dはエディションと課金ルールを混同しています。