第2章 アカウント管理とデータガバナンス(Account Mgmt & Governance, 20%)
🎯 この節の学習目標
リソースモニター(resource monitor)は、クレジット消費に上限と監視の仕組みを設けるオブジェクトです。想定外のクレジット消費(消し忘れた大型ウェアハウス、暴走したジョブなど)からアカウントを守る、コスト統制の中心的な機能です。
構成要素は次のとおりです。
| 要素 | 説明 |
|---|---|
| CREDIT_QUOTA | 監視間隔ごとに許容するクレジット数(上限の基準値) |
| 対象(アカウント or ウェアハウス) | アカウントレベルのモニターはアカウント内のすべてのウェアハウスの消費を合算して監視。ウェアハウスレベルは指定したWH群を監視 |
| FREQUENCY | 消費量カウンターをリセットする間隔。MONTHLY(既定)/ DAILY / WEEKLY / YEARLY / NEVER |
| トリガー(TRIGGERS) | クオータに対する割合(%)と、そこに達したときのアクションの組。複数設定できる(例:75%で通知、100%で停止)。100%を超える割合(110%など)も指定可能 |
📝 試験のポイント
割り当てのルールに注意します。1つのウェアハウスに割り当てられるリソースモニターは1つだけです(逆に、1つのモニターは複数のウェアハウスを監視できます)。また、アカウントレベルのモニターは自動的にすべてのウェアハウスに適用され、個別ウェアハウスのモニターとは独立して並行に働きます。
閾値に達したときのアクションは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段構えにしています。サスペンドされたウェアハウスは、翌月にカウンターがリセットされるか、クオータが引き上げられるまで再開できません。
クレジット消費からアクションまでの流れを図にまとめます。
図:リソースモニターの動作。消費量が閾値に達すると、通知のみ/完了待ち停止/即時停止のいずれかが発火する
リソースモニターが守るのは主にウェアハウスのクレジットですが、Snowflakeの請求全体は次の要素で構成されます。全体像を整理しておきましょう。
| コスト区分 | 課金単位 | ポイント |
|---|---|---|
| コンピュート(ウェアハウス) | クレジット(サイズと稼働時間に応じて) | 稼働中のみ課金。最低60秒、以降は秒単位 |
| サーバーレス機能 | クレジット | Snowpipe、自動クラスタリング、マテリアライズドビューの維持など、Snowflake管理のコンピュートを使う機能 |
| クラウドサービス層 | クレジット | 1日のウェアハウス消費クレジットの10%を超えた分だけ課金される(10%ルール)。超えなければ実質無料 |
| ストレージ | 圧縮後の平均使用量(TB/月)の定額 | Time Travel・Fail-safe領域も含まれる |
| データ転送 | 転送量 | 取り込み(ingress)は原則無料、外部への持ち出し(egress)に課金。別リージョン・別クラウドへの転送が対象 |
コスト統制の第一歩は「どこでいくら使っているか」の可視化です。主な手段は次のとおりです。
「ウェアハウスの暴走を止めたい=リソースモニター」「サーバーレス含む支出を見張って通知したい=バジェット」という使い分けを押さえておきましょう。
✅ この節のまとめ
問1. リソースモニターを作成できるロールはどれか。
正解:C
リソースモニターの作成はACCOUNTADMINだけができます。作成後にMONITOR/MODIFY権限を他ロールへ付与して参照・変更を委任することはできますが、作成自体はACCOUNTADMINの専権です。AのSYSADMINはオブジェクト管理の中心ロールですがリソースモニターは作成できません。Bも権限付与管理が守備範囲であり作成はできません。DのMONITORADMINというシステムロールは存在しません。
問2. リソースモニターのトリガーアクションSUSPENDとSUSPEND_IMMEDIATEの違いとして正しいものはどれか。
正解:A
SUSPENDは新規クエリの受け付けを止め、実行中のクエリが完了してからサスペンドします。SUSPEND_IMMEDIATEは実行中のクエリもキャンセルして即座にサスペンドします。Bは誤りで、どちらも対象はウェアハウスでありアカウントの停止ではありません。Cは誤りで、どちらのアクションも通知を伴います。Dは誤りで、実行中クエリの扱いという明確な違いがあります。
問3. リソースモニターの割り当てに関する説明として正しいものを2つ選べ。
正解:A、B
ウェアハウスに割り当てられるモニターは1つだけで(A)、アカウントレベルのモニターは全ウェアハウスの合算消費を監視します(B)。Cは Aと矛盾しており誤りです(多段の監視をしたい場合は1つのモニターに複数のトリガーを設定します)。Dは誤りで、リソースモニターが監視するのはクレジット消費であり、ストレージ使用量の上限を強制する機能はありません。
問4. クラウドサービス層の課金ルールとして正しいものはどれか。
正解:B
クラウドサービス層(認証・メタデータ管理・クエリ解析など)の消費は、その日のウェアハウス消費クレジットの10%までは請求されず、超過分だけが課金されます(10%ルール)。通常のワークロードでは10%以内に収まることが多く、実質無料になるケースが多い設計です。Aは10%の控除を無視しており誤り、Cは従量制である点と矛盾し、Dはエディションと課金ルールを混同しています。