Snowflakeの月額請求が想定の2倍に膨れ上がった、という相談を受けることが少なくありません。クラウドDWHは「使った分だけ」の従量課金ですが、裏を返せば使い方次第でコストは青天井に伸びます。本記事では、実プロジェクトで月額請求を半額まで落とした5つの施策を、具体的なSQL設定例付きで解説します。ウェアハウスの自動サスペンドから、クエリチューニング、Resource Monitorによるガードまで、今日から手をつけられるアクションを整理しました。

Snowflakeのコスト構造を理解する

Snowflakeのコストは主に「コンピュート(ウェアハウス)」「ストレージ」「クラウドサービス(メタデータ管理等)」の3要素で構成されますが、多くの場合、請求の80%以上をコンピュートが占めます。つまり、コスト削減はコンピュート最適化とほぼ同義です。

【Snowflakeコスト構造】

総請求額
  |
  +--> コンピュート(約80%)
  |       |
  |       +--> ウェアハウス稼働時間(秒単位課金)
  |       +--> サーバーレス機能(自動クラスタリング等)
  |
  +--> ストレージ(約10〜15%)
  |       |
  |       +--> アクティブストレージ
  |       +--> タイムトラベル(履歴)
  |       +--> フェイルセーフ(7日固定)
  |
  +--> クラウドサービス(約5〜10%)
          |
          +--> メタデータ管理、認証、最適化

※ コンピュートから手をつけるのが費用対効果の面で最優先

コスト削減を進める前に、ACCOUNT_USAGEスキーマのWAREHOUSE_METERING_HISTORYビューで、どのウェアハウスが何クレジット消費しているかを必ず可視化してください。現状把握なしに最適化を始めても、効果測定ができず無駄打ちに終わります。Snowflake入門記事も合わせてご参照ください。

施策1――ウェアハウスの自動サスペンドと適正サイジング

現場で最も効果が大きいのが、ウェアハウスの自動サスペンド時間の見直しです。Snowflakeは秒単位課金(60秒の最小課金)ですので、アイドル時間の放置は純粋に無駄になります。デフォルトの10分を1〜5分に短縮するだけで、ETL処理の隙間時間の課金をカットできます。

-- 自動サスペンド1分、サイズXS、最小1ノード
ALTER WAREHOUSE etl_wh SET
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 1
  INITIALLY_SUSPENDED = TRUE;

サイジングも重要です。Snowflakeのウェアハウスはサイズを1段階上げるごとにクレジット消費が倍になりますが、処理時間は必ずしも半分にはなりません。小さいウェアハウスで時間がかかっても、トータルコストではそちらが安いケースが多々あります。クエリ履歴から実際の処理時間を測定し、適正サイズを見極めましょう。

施策2――クエリ最適化(クラスタリングキー、マテリアライズドビュー)

ウェアハウスを小さくするだけでは限界があります。クエリそのものが効率的でなければ、スキャンするマイクロパーティションが増え、結果として処理時間とコストが増えます。ここで効くのがクラスタリングキーです。大規模テーブル(数TB以上)で頻出するフィルタ列にクラスタリングキーを設定することで、プルーニング効率が大幅に向上します。

-- 日付とテナントでクラスタリング
ALTER TABLE fact_events
  CLUSTER BY (event_date, tenant_id);

マテリアライズドビューも選択肢に入りますが、自動メンテナンスにクレジットを消費するため、「高頻度で実行される定型集計クエリ」に限って使うのが鉄則です。リアルタイム性が不要な集計は、dbtのインクリメンタルモデルで十分なケースが多いことも覚えておきましょう。dbt入門を併用すると、さらにコスト効率が上がります。

施策3――ストレージ最適化(タイムトラベル期間、ゼロコピークローン活用)

ストレージコストは全体の10〜15%と比較的小さいですが、大規模テーブルではタイムトラベル期間の設定が効きます。デフォルトでは1日ですが、Enterpriseエディション以上では最大90日まで設定できます。機密性の高いマスタテーブルを除き、必要以上の長期保持は避けましょう。

開発・検証環境のデータ複製には、ゼロコピークローンが圧倒的に有効です。物理的にデータをコピーせず、メタデータだけで新しいテーブルを作成できるため、ストレージコストが発生しません。毎週本番のスナップショットをクローンして検証環境に配置する、といった運用が当たり前に使えるのは他のDWHにない強みです。ETLの本番適用前のリハーサルもクローン環境で実施することで、万一のロールバックも安全に行えます。

施策4――Resource Monitorによるコスト監視

最適化後も油断はできません。新しいクエリや想定外のワークロード急増で、コストが静かに膨らむリスクは常にあります。Resource Monitorを使えば、クレジット消費が閾値を超えた時点でアラートを出したり、ウェアハウスを自動停止することが可能です。

CREATE OR REPLACE RESOURCE MONITOR etl_monitor
  WITH CREDIT_QUOTA = 500
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 75 PERCENT DO NOTIFY
    ON 90 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE etl_wh SET RESOURCE_MONITOR = etl_monitor;

Resource Monitorは「事故防止」として機能します。想定の倍の請求が来る前に、75%で通知、100%で強制停止という設計にしておけば、月末に驚くこともなくなります。経営層への説明責任の観点でも、ガードレールがあること自体が大きな安心材料です。

施策5――ワークロード分離(ETL用/BI用/アドホック用のウェアハウス分離)

最後の施策が、ワークロード別のウェアハウス分離です。ETL・BI・アドホックを1つのウェアハウスで運用すると、BI側の突発的な重いクエリがETL処理を遅延させたり、逆にETLがBIレスポンスを劣化させたりします。ワークロードごとに専用ウェアハウスを用意し、それぞれ適切なサイズとサスペンド設定にするのが最終形です。

ワークロード推奨サイズ自動サスペンドマルチクラスタ注意点
ETL(バッチ)S〜L60秒無効処理時間優先でサイズ調整
BI(定型レポート)M〜L300秒有効(同時実行分)レスポンス速度優先
アドホック分析XS〜S60秒無効暴走クエリ対策のためガード推奨
開発・検証XS60秒無効クローン活用

以上5つの施策を実施した結果、実プロジェクトでは月額請求が初期の約50%まで削減されました。効果の内訳は以下の通りです。

施策削減寄与度実装難易度即効性
1. 自動サスペンドとサイジング20〜25%低即日
2. クエリ最適化10〜15%中1〜2週間
3. ストレージ最適化3〜5%低即日
4. Resource Monitor事故防止効果大低即日
5. ワークロード分離10〜15%中1〜2週間

なお、BigQueryのコスト管理とも設計思想を比較しながら進めると、自社にとって最適なDWHが見えてきます。Terraform IaCで構成を管理することで、最適化設定を再現性高くデプロイできるのもおすすめです。

まとめ

Snowflakeのコスト最適化は、ウェアハウスの自動サスペンド・適正サイジング・クエリ最適化・ストレージ最適化・Resource Monitor・ワークロード分離の5つを組み合わせることで、実プロジェクト実績で約50%の削減が可能です。特に自動サスペンドとResource Monitorは、即日実施できて効果も大きい「最初の一歩」としておすすめします。継続的なTCO算出と定点観測で、コストを「見える化」された状態に保ちましょう。

よくある質問(FAQ)

Q. Snowflakeのコストが高くなる最大の原因は?

ウェアハウスの自動サスペンド未設定が最多です。デフォルトは10分ですが、利用パターンに応じて1〜5分に短縮するだけで大幅に削減できます。アイドル時間の課金が積み重なることを意識しましょう。

Q. Snowflakeのコストを可視化するにはどうすればよいですか?

ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORYビューでクレジット消費を分析できます。ウェアハウス別・日別の消費量を可視化し、Resource Monitorでアラートを設定するのも効果的です。BIツールでダッシュボード化する運用も併用しましょう。

Q. Snowflakeのコスト削減でまず取り組むべきことは?

ウェアハウスの利用状況分析(稼働率・クエリ量)から始め、サスペンド設定とサイジングの見直しを行うのが最も即効性があります。次にResource Monitorで事故防止のガードレールを設置し、その上でクエリ最適化に進むのが効果的な順序です。