LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Snowflakeのコスト構造：クレジット課金の仕組み

Snowflakeのコスト最適化とは、クレジット課金の仕組みと費用構成要素を正確に把握し、ウェアハウスの稼働状況・サイズ・設計を見直すことで、データ基盤の運用コストを適正化する取り組みです。Snowflake公式ドキュメント（コストの管理）^*1によると、費用は主にコンピュート・ストレージ・データ転送の3つの要素で構成されています。

費用の大部分を占めることが多いのはコンピュート（仮想ウェアハウスの稼働に消費するクレジット）です。ウェアハウスが稼働している間はクレジットが消費されるため、クエリが終わった後もウェアハウスが停止していない「アイドル稼働」が費用増の主な原因になります。

ストレージは、保存されたデータ量（圧縮後）に応じた月次課金です。データ転送は、異なるクラウドリージョンや外部サービスへのデータ移動に発生します。この3要素の中で、ウェアハウス稼働のコンピュート費用は変動幅が最も大きく、日々の運用改善で削減できる余地があります。

クレジット課金の単位とウェアハウスサイズの関係

Snowflakeでは、ウェアハウスのサイズ（XS・S・M・L・XLなど）によって1時間あたりのクレジット消費数が変わります。XSが1クレジット/時間を基準として、Sは2クレジット、Mは4クレジット、Lは8クレジットと、サイズが1段階上がるごとに消費量が倍になる設計です（Snowflake公式ドキュメント「ウェアハウスのクレジット使用量」^*2に基づく）。クレジットの単価はSnowflakeの契約プランや利用クラウドによって異なり、公式サイトで確認できます。実際の円・ドル換算での費用は、クレジット単価×消費クレジット数で算出されます。

必要以上に大きなサイズのウェアハウスを常時稼働させていると、クエリが1本しか動いていない時間帯でも多くのクレジットを消費します。サイズの適正化は費用削減の基本的な手段です。

ウェアハウス運用の最適化：AUTO_SUSPEND・サイズ適正化・クエリ検証

ウェアハウスの運用最適化では、アイドル停止の自動化・サイズの見直し・クエリ履歴による実態把握の3つが主な取り組みになります。Snowflake公式ドキュメント（ウェアハウスのコスト管理）^*3で推奨されているアプローチに沿って整理します。

AUTO_SUSPEND：アイドル停止でクレジット浪費を防ぐ

AUTO_SUSPEND（自動停止）は、ウェアハウスがアイドル状態になってから一定時間後に自動停止させる設定です。この設定がない、または値が大きすぎると、クエリが終わってもウェアハウスが長時間稼働し続け、クレジットを消費します。

Snowflake公式によると、AUTO_SUSPENDは短め（60秒前後）から始め、ワークロードの実態に合わせて調整することが推奨されています。最適値はクエリの実行頻度・間隔によって異なるため、設定を変えた後にACCOUNT_USAGE.QUERY_HISTORY（クエリ履歴ビュー）を用いてアイドル時間とクレジット消費の変化を確認することが大切です。

注意点として、AUTO_SUSPENDを短くすると次のクエリ実行時にウェアハウルの再起動が発生し、コールドスタートによるレイテンシが生じる場合があります。BIツールのように即時応答が求められるウェアハウスでは、レイテンシ要件とのバランスを取りながら設定値を決めることが重要です。

ウェアハウスサイズとマルチクラスターの適正化

ウェアハウスサイズは、実際に実行されるクエリのデータ量・複雑さに対して適切か定期的に確認することが大切です。大きすぎるサイズは余剰クレジットの消費を招き、小さすぎるサイズはクエリのスピルオーバー（一時データがストレージに溢れる状態）を引き起こしてかえって実行時間が延びるケースがあります。

マルチクラスターウェアハウス（Multi-Cluster Warehouse）は、同時クエリ数が多くキューイングが発生するケースで有効な機能です。Snowflake公式によると、クエリ1本の処理速度を上げたい場合はウェアハウスサイズを上げ、同時実行数を増やしたい場合はクラスタ数を増やす設計が基本です。ただし稼働クラスタ数に応じてクレジット消費が増えるため、最小・上限クラスタ数の設定と実際のコンカレンシー状況を定期的に確認する必要があります。

ACCOUNT_USAGE.QUERY_HISTORYによるクエリ検証

コスト増加の原因をウェアハウスの設定だけに帰着させず、クエリそのものの設計を見直すことも重要です。ACCOUNT_USAGE.QUERY_HISTORY（Snowflake公式ドキュメント「QUERY_HISTORY ビュー」^*4）では、実行されたクエリの実行時間・消費クレジット・スキャンバイト数・スピルオーバーの有無などを確認できます。

特に消費クレジットが大きいクエリや、フルスキャンを繰り返しているクエリを特定することが優先度の高い改善につながります。テーブルのクラスタリングキー設定やパーティションプルーニング（不要なデータブロックをスキャンしない最適化）を活用することで、同じ処理でもクレジット消費を抑えられる場合があります。

ガードレールの設定：リソースモニターとBudgetsで費用急増を防ぐ

ウェアハウスの設定最適化と並行して、費用が想定を超えないようにするガードレールを設けることが大切です。Snowflakeには、ウェアハウス単位とアカウント全体の2つの粒度でクレジット消費を監視・制限できる機能が用意されています。

リソースモニター（Resource Monitor）：ウェアハウス単位の制御

リソースモニター（Resource Monitor）は、月次やカスタム期間でクレジットの上限（spend limit）を設定し、閾値到達時に自動アクションを実行できるSnowflakeの機能です。Snowflake公式ドキュメント（リソースモニターの操作）^*5によると、設定できるアクションには通知メールの送信、ウェアハウスのSUSPEND（現在実行中のクエリ完了後に停止）、SUSPEND_IMMEDIATE（即時停止）があります。

閾値は複数設定できます。たとえば50%で通知のみ、75%で通知＋警告、上限到達でSUSPENDというように段階的なアクションを組み合わせることで、費用超過のリスクを段階的に制御できます。特定のウェアハウスだけに個別上限を設けることも、アカウント全体に共通の上限を設けることも可能です。

リソースモニターはSUSPENDを実行した場合、管理者が手動でウェアハウスを再開させるか、翌期間のリセットを待つ必要があります。業務上クリティカルなクエリが止まるリスクを考慮して、閾値と対応アクションを設計することが重要です。

Budgets（バジェット）：アカウント全体のクレジット監視

BudgetsはSnowflakeのサーバーレス機能を含むアカウント全体のクレジット消費を監視し、閾値で通知できる機能です。Snowflake公式ドキュメント（Budgetsを使ったコストのモニタリング）^*6によると、ウェアハウスだけでなくSnowpipe（自動データ取り込み機能）やAutomatic Clustering（自動クラスタリング）など、サーバーレス機能で消費されるクレジットも含めた全体監視ができます。

Budgetsの通知閾値は50%・90%・上限到達などを設定でき、閾値に到達するとメールや設定したアラートチャネルに通知が届きます。リソースモニターがウェアハウス単位の「実行制御」を担うのに対して、BudgetsはアカウントレベルでSnowflake全体の費用動向を把握する「監視役」として補完的に機能します。2つを組み合わせることで、見落としのないガードレールを構築できます。

最適化を進める流れ：可視化→主因特定→設定見直し→モニタリング継続

Snowflakeのコスト最適化を体系的に進めるには、現状の費用構造を把握することから始めることが大切です。感覚的な設定変更ではなく、データに基づいた優先順位付けが効果的な取り組みにつながります。

ステップ1：ACCOUNT_USAGEとBudgetsで費用を可視化する

Snowflakeには、アカウント全体のリソース使用状況を記録するACCOUNT_USAGEスキーマが用意されています。WAREHOUSE_METERING_HISTORYビューではウェアハウス別のクレジット消費履歴を、QUERY_HISTORYビューではクエリごとの実行詳細を確認できます。これらのビューを組み合わせて、どのウェアハウスが費用の大部分を占めているかを特定することが出発点です。

Budgetsダッシュボードでは、アカウント全体のクレジット消費トレンドをグラフで確認できます。月次の消費推移と予算に対する進捗を定期的に確認することで、費用増加の予兆を早期に捉えることができます。

ステップ2：ウェアハウス別に主因を特定する

可視化で費用の多いウェアハウスを特定したら、そのウェアハウスのアイドル時間・クエリ頻度・平均実行時間を確認します。アイドル時間が長い場合はAUTO_SUSPENDの見直し、クエリが遅い場合はウェアハウスサイズやクエリ設計の最適化が主な改善策になります。

複数のチーム・用途が1つのウェアハウスを共有している環境では、ウェアハウスを分割して用途別に管理することで、費用の帰属を明確にしながらサイズとAUTO_SUSPENDを個別に最適化しやすくなります。

ステップ3：設定を変更し変化を確認する

AUTO_SUSPENDの変更・ウェアハウスサイズの変更・リソースモニターの追加は、本番環境に直接適用する前にテスト環境や低負荷の時間帯に確認することが基本です。ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORYで変更前後のクレジット消費を比較し、意図した変化が得られているかを検証します。

クエリ設計の見直し（クラスタリングキーの追加やクエリの書き換え）は、既存の処理に影響を与えるリスクがあります。変更の影響範囲を把握した上で段階的に適用することが、リスクを抑えた進め方です。

ステップ4：モニタリングを継続し改善サイクルを回す

Snowflake環境はデータ量・ユーザー数・クエリパターンが変化するにつれてコスト構造も変わります。一度最適化を行っても、新しいウェアハウスの追加や大量データの取り込みが始まると費用が増加します。定期的にACCOUNT_USAGEとBudgetsを確認し、設定とガードレールを見直すサイクルを継続することが重要です。

リソースモニターとBudgetsのアラートを適切な担当者に通知設定することで、費用の急増を早期に検知できる体制を作ることが、継続的なコスト管理の土台になります。

外注の使いどころ：診断・設計・構築を委託する判断軸

Snowflakeのコスト最適化を内製で進めることは技術的には可能ですが、ACCOUNT_USAGEの分析・ウェアハウス設計・ガードレール構築には相応の知識と工数が必要です。外注を検討する際の判断軸と委託先選定のポイントを整理します。

外注が有効な3つの場面

1つ目はコスト診断フェーズです。Snowflakeの費用が増えている原因が分からない、どのウェアハウスから手をつければよいか判断できないという場合、外部専門家によるACCOUNT_USAGE分析と診断レポートから始めることが有効です。現状の問題点と優先順位を明確にするだけでも、内製対応の効率が上がります。

2つ目はウェアハウス設計・ガードレール構築フェーズです。AUTO_SUSPENDの最適値はワークロードの特性によって異なり、リソースモニターのSUSPENDアクションは業務への影響を考慮した設定が必要です。Snowflakeの挙動を理解した設計を誤ると、業務停止や費用増加につながるリスクがあります。Snowflake環境の設計経験を持つパートナーに委ねることでリスクを抑えられます。

3つ目は継続モニタリングフェーズです。社内にSnowflakeのコスト管理を専任で担うリソースがない場合、月次の消費状況確認・アラート対応・改善提案を外注することで、費用の増加傾向を早期に検知できる体制を作れます。

内製でSnowflakeコスト最適化を進める場合に必要なスキルと工数の目安

内製対応に必要な知識の範囲は広くなります。ACCOUNT_USAGEスキーマの各ビュー（WAREHOUSE_METERING_HISTORY・QUERY_HISTORYなど）の理解と分析、ウェアハウスサイズ・AUTO_SUSPEND・AUTO_RESUMEの設定、リソースモニターとBudgetsの設計、クラスタリングキーやクエリ最適化の知識、マルチクラスターウェアハウスの設計が求められます。

ウェアハウスが数十以上ある環境で体系的に取り組む場合、担当者1〜2名が数週間程度を集中させる工数が目安になります（実際の工数はウェアハウス数・データ量・業務要件によって異なります）。設定ミスによって業務クエリが止まった場合のリカバリコストも考慮すると、外注の費用対効果が見合うケースは多くなります。

委託先の選び方：Snowflake実績・設計力・説明責任で判断する

Snowflakeコスト最適化の外注先を選ぶ際に確認すべきポイントを整理します。まず、Snowflake環境のウェアハウス設計・ACCOUNT_USAGE分析・リソースモニター設計の具体的な実績があるかどうかを確認します。提案段階でワークロード別のウェアハウス分割設計やAUTO_SUSPEND最適化の方針を説明できるかどうかが見極めのポイントです。

次に、成果を定量的に示せる体制があるかどうかです。最適化前後のクレジット消費量をACCOUNT_USAGEで比較したレポートを提供できるか、KPIの定義と測定方法を契約前に合意できるかを確認します。費用削減を断言する提案には根拠を求め、具体的なデータに基づく説明を求めることが大切です。

長期的な関係を想定する場合は、ナレッジ移転の意向も確認します。設定変更の方針・運用手順のドキュメント化や、社内担当者への勉強会提供など、内製化への道筋を示せるパートナーが信頼性の高い委託先です。

外注費用の目安と費用対効果の考え方

外注費用はスコープ・ウェアハウス数・契約形態によって異なります。以下は市場参考値であり、一次資料に基づく数値ではありません。実際の費用は複数社への見積もりで確認してください。

費用対効果の評価には、最適化前後のクレジット消費量をACCOUNT_USAGE.WAREHOUSE_METERING_HISTORYで比較することが基本になります。外注費用と削減されたクレジット費用のバランスを確認し、継続契約の判断材料にすることが大切です。

まとめ：Snowflakeコスト最適化を進める3つの軸

本稿では、Snowflakeのクレジット課金の構造とウェアハウス稼働がコスト増の主因になりやすい理由から始まり、AUTO_SUSPEND・サイズ適正化・ACCOUNT_USAGEによるクエリ検証、リソースモニターとBudgetsによるガードレール設定、最適化を進める4ステップのフロー、外注の使いどころと委託先の選び方を整理しました。要点を3つに集約します。

第一に、Snowflakeのコスト最適化はウェアハウスの可視化から始めることが大切です。ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORYとQUERY_HISTORYで費用の主因となるウェアハウスとクエリを特定してから、優先順位をつけて取り組むことが効率的です。

第二に、AUTO_SUSPENDとリソースモニター・Budgetsの組み合わせがコスト管理の実効手段です。アイドル停止の自動化でクレジット浪費を防ぎ、ガードレールで費用急増を未然に抑える設計が継続的なコスト管理につながります。設定には各機能の挙動を正確に理解した上での設計が必要です。

第三に、外注の有効性はウェアハウス数・担当リソースの有無・設計リスクによって変わります。外注先はSnowflake設計実績・定量的な成果説明力・ナレッジ移転の姿勢を軸に選ぶことが長期的な費用対効果につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Snowflake Inc.「Understanding overall cost」 — https://docs.snowflake.com/en/user-guide/cost-understanding-overall（2024年）
2. *2　出典：Snowflake Inc.「Virtual warehouse credit usage」 — https://docs.snowflake.com/en/user-guide/warehouses-overview#virtual-warehouse-credit-usage（2024年）
3. *3　出典：Snowflake Inc.「Warehouse considerations」 — https://docs.snowflake.com/en/user-guide/cost-controlling#warehouse-considerations（2024年）
4. *4　出典：Snowflake Inc.「QUERY_HISTORY View」 — https://docs.snowflake.com/en/sql-reference/account-usage/query_history（2024年）
5. *5　出典：Snowflake Inc.「Working with resource monitors」 — https://docs.snowflake.com/en/user-guide/resource-monitors（2024年）
6. *6　出典：Snowflake Inc.「Monitoring cost with Budgets」 — https://docs.snowflake.com/en/user-guide/budgets（2024年）

Tweet