❄️

Snowflakeの料金をなるべくわかりやすく説明するチャレンジ

2022/12/16に公開

この記事はSnowflake Advent Calendar 2022のPart2の16日目です。Part2の16日目はkommyさんの「Snowflake 1年目の教科書」です。

はじめに

Snowflakeの料金って、いわゆる AWS等のパブリッククラウドの課金方式をほぼ踏襲してるんですが、改めてわかりやすく説明しようとチャレンジしてみます。これから使う方向け

AWS等のパブリッククラウドの料金を理解してる方は、「(参考)いわゆるパブリッククラウドの課金」は読み飛ばして、いきなり「Snowflakeの料金」から読んでください。超急ぎの方は「Snowflakeの料金まとめ」からでもOKかも?(結局最後はスライド作ってしまった…)

(参考)いわゆるパブリッククラウドの課金

(参考)いわゆるパブリッククラウドの課金

知ってる人は読み飛ばしてください!

ざっくりいうと「必要なときに、必要なだけ、使った分だけの従量課金」ってやつです。みんな大好きクラウドのメリットそのものですね!わかりやすい!!!

AWS料金の見積り方法 -料金計算の考え方・見積り方法・お支払方法-

↑良い資料(自画自賛)

以下、AWSの例で説明(AzureやGoogle Cloudも基本的な考え方は同じなので読み替えてください)[1]

1.仮想サーバ

1-1.EC2

基本は時間単価($/h) ✕ 利用時間(h)

  • 時間単価はインスタンスタイプごとに異なる。基本的に性能が2倍になれば時間単価も2倍
  • 利用時間はEC2を起動していた時間、利用していた時間ではない
1-2.Lambda(いわゆるサーバレス)の場合

基本は時間単価($/msec) ✕ 利用時間(msec)

  • 時間単価はスペック(メモリ容量)ごとに異なる。基本的に性能が2倍になれば時間単価も2倍
  • EC2と違って利用してたときだけ動くイメージ
  • リクエスト課金とかもある

2.ストレージ(S3の場合)

利用していた容量(GB) ✕ 単価($/GB)

  • 1GBを1ヶ月利用した場合は、$0.025みたいな感じ
  • 確保ではなくて、利用した容量
  • 月内で利用容量は変動するので、月間の平均利用容量で計算

これはオブジェクトストレージであるS3のお話。プロックストレージのEBSは確保した分

3.データ転送

リージョンからインターネットに出ていった通信量(GB) ✕ 単価($/GB)

  • インターネットへ出ていったもの(アウト)が課金対象、逆(イン)は対象外
  • AZ間通信とか細かい課金もあるけど単価安いので一旦省略

4.サポート

その他サポート費用がサポートプランに合わせてかかります(必要な要件に合わせてサポートプランを顧客自身が選択できるように、標準ではバンドルされていない)

細かい課金ポイント色々あるけど…

基本的には大半(90〜95%)くらいは、仮想サーバとRDBが占めることが多い。動画配信サービスやB2Cのアプリとかは、もちろんデータ転送料が大きくなったりします。上記以外にも細かい課金ポイントはあるけど単価大きくないので今回は省略(一応、確認はしておいてくださいね。料金なので)

Snowflakeの料金

Snowflakeも「必要な時に」「必要なだけ」利用して、「使った分だけ」の従量課金という料金体系です。逆に「このクラウドのメリットそのもの」を分析基盤にも適用したのが、広く受け入れらている理由なのかなと

3つの要素

こちらも大きく分けて3つの要素で構成されます。基本的にはAWS等のクラウドと似ています。一方でサポートは標準でついています(上位のサポートプランもオプションで選べます)

1.コンピューティング
2.ストレージ
3.データ転送


円グラフはイメージ

関連ドキュメント : SNOWFLAKEでのコストについて

ここから、1つずつ説明していきます。

1.コンピューティング(3種類)

(料金の大半を占めることが多い)コンピューティングですが、さらに細かくわけると3つあります。その3つの中でも大きな割合を占めるのは、ロード、集計、BIなどなどに利用される「仮想ウェアハウス」になることが多いです。

1-1.仮想ウェアハウス(コンピューティング)
1-2.サーバーレス(コンピューティング)
1-3.クラウドサービス(コンピューティング)

1-1.仮想ウェアハウス(コンピューティング)

超ざっくりいうとEC2の料金の考え方とほぼ同じです。スキャン対象のデータ量やロードしたデータ量に関する課金は無いです

各ワークロードに割り当てる仮想ウェアハウス(いわゆるコンピューディングリソース。よく歯車のアイコンを当てています)です。AWSのEC2などと同様に起動した分の時間課金ですが、Snowflakeの仮想ウェアハウスには「自動再開(起動)」や「自動一時停止」が設定できるので、アイドル状態の仮想ウェアハウスを停止させて、起動していた時間を実際に利用していた時間に近づけることが出来ます。

稼働時間に対して「クレジット」が課金されます。これは「XSを1時間起動すると1クレジット」のように時間単価が決まっています。(AWSのEC2等では、各リージョンの各インスタンスタイプごとに「$3/h」のような単価が直接設定されていますが、)Snowflakeの仮想ウェアハウスのタイプに応じたクレジット単価はクラウドやリージョンに依らず一律に設定されています。そのかわりクラウドやリージョン、さらにはエディションごとの「クレジット単価」が設定されています。例えばAWS、Tokyoリージョン、エンタープライズエディションの場合、「1クレジット=$4.3」です(後述)

ウェアハウスタイプとサイズ

EC2のインスタンスタイプみたいな感じです。大きく分けてタイプが2種類、「標準のStandard」と、「メモリを大量に使う機械学習ワークロードなどに適したSnowpark-optimized」があります。EC2でいうところのコンピューティング最適化(C系)とメモリ最適化(R系)です。

インスタンスサイズは1段階上がると(S→Mなど)、CPUやRAMなどが倍になり処理性能が2倍になるイメージです(もちろん処理内容によりますが)。処理性能が倍になり、時間単価に相当するクレジットも倍になります(Sは2、Mは4など)

スケールアップかスケールアウトか?

サイズを1つ上げる(いわゆるスケールアップ)と処理性能が2倍になるので(もちろん処理内容によりますが)、2時間かかっていた集計処理が1時間くらいで終わったりします。時間単価は倍になりますが、コスト算出する際に掛け算する起動時間は半分になるので、同じくらいのコストで早めに結果が取得出来ます。[2]

一般的に、いわゆる"重い"処理の場合はサイズを上げるいわゆるスケールアップが有効で、同時接続数(BIで100同時接続する場合)が多い場合はSnowflakeではマルチクラスターウェアハウスと呼ぶスケールアウトが有効です。オートスケーリングも設定できます。

2つのタイプのウェアサイズごとのクレジット表
仮想ウェアハウスのタイプ Standard Snowpark-optimized
XS 1 N/A
S 2 N/A
M 4 6
L 8 12
XL 16 24
2XL 32 48
3XL 64 96
4XL 128 192
5XL 256 384
6XL 512 768

Snowpark-optimizedは、Standardの1.5倍ですね。

起動時間/時間のカウント方法

ウェアハウスごとに「自動再開」や「自動一時停止」が設定できます。普段は停止状態(課金対象外)にしておいて、実際にクエリが飛んできたときだけ稼働し(瞬時に使える状態になります)、クエリ結果返却、アイドル状態が設定した時間続くと停止します。これによりアイドル状態の時間を短くする(起動時間を実際に利用していた時間に近づける)ことが出来ます。

関連ドキュメント : ウェアハウスのクレジットはどのように請求されますか?

詳しい人向けの急に細かい話

ウェアハウス内のデータキャッシュ

各ウェアハウスは、実行中に、クエリがウェアハウスによって処理されるときにアクセスされるテーブルデータのキャッシュを保持します。これにより、クエリ内のテーブルではなくキャッシュから読み取ることができる場合は、後続のクエリのパフォーマンスが向上します。キャッシュのサイズは、ウェアハウス内のコンピューティングリソースによって決定されます(つまり、ウェアハウスが大きいほど、したがって、ウェアハウス内のコンピューティングリソースが大きいほど、キャッシュは大きくなります)。

ウェアハウスが一時停止されると、このキャッシュはドロップされるため、ウェアハウスの再開後、一部のクエリの初期パフォーマンスが低下する可能性があります。再開されたウェアハウスが実行され、より多くのクエリが処理されると、キャッシュが再構築され、キャッシュを利用できるクエリのパフォーマンスが向上します。

ウェアハウスを一時停止するか、実行したままにするかを決定するときは、このことに留意してください。つまり、ウェアハウスを一時停止することでクレジットを節約することと、パフォーマンスを向上させるために以前のクエリからのデータのキャッシュを維持することとのトレードオフを検討します。

関連ドキュメント : ウェアハウスのキャッシュはクエリにどのように影響しますか?

もちろん処理内容次第ですが、必ずデータキャッシュ(ウェアハウス内のSSDに読み込まれたデータ)利用すべきなのかというとそこまでこだわらなくてもいい場合も多いかなと(オブジェクトストレージにあるテーブルを読みに行っても速い)。もちろん処理内容次第なので(大事なことなので2回)、実際に試すのがおすすめ

自動停止時間TIPS

60未満の値を設定することは許可されていますが、ウェアハウスを一時停止するバックグラウンドプロセスは約60秒ごとに実行されるため、多くの場合、望ましい、または期待される動作にはなりません。したがって、ウェアハウスの一時停止を正確に制御できるようにすることを目的としていません。

関連ドキュメント : CREATE WAREHOUSE

エディションとクレジット単価

繰り返しになりますが、Snowflakeの仮想ウェアハウスのタイプごとのクレジット単価はクラウドやリージョンに依らず一律(XSなら1クレジット/時間)です。そのかわりクラウドやリージョン、エディションごとに異なる「クレジット単価」が設定されています。

エディション


ドキュメントから一部抜粋(この他にも機能差あり)

Snowflakeには主に3つのエディションがあり、利用できるオプション1クレジットあたりの単価が異なります。エディションについての詳細はドキュメントを参照いただきたいのですが、ざっくり説明すると… 開発検証用の「Standard」、本番環境用の「Enterprise」、PrivateLink利用や顧客鍵も利用した暗号化Tri-Secret Secureなど、より高いセキュリティ・コンプライアンスが求められる場合は「Business Critical」 みたいな感じです。

関連ドキュメント : Snowflake Edition

クレジット単価

各クラウド、リージョン、エディションごとに、1クレジットごとの単価が設定されていて、こちらで確認出来ます。

例としてAWS Tokyoリージョンの場合は…

エディション Standard Enterprise Business Critical
1クレジットあたりの単価 $2.85 $4.30 $5.70
主な利用用途 開発検証 本番利用 厳しいセキュリティ要件

仮想ウェアハウスの課金まとめ(計算例)

例えば今月、AWS TokyoリージョンのEnterpriseエディションで、データロード用に「M」を合計15時間、BI用に「M✕2台」をそれぞれ30時間、バッチ処理用に「XL」を合計12時間 利用した場合の仮想ウェアハウス料金は…

4クレジット(Mの時間単価) ✕ 15時間 = 60クレジット
4クレジット(Mの時間単価) ✕ 2台 ✕ 30時間 = 240クレジット
16クレジット(XLの時間単価) ✕ 12時間 = 192クレジット

で合計492クレジット。AWS TokyoのEnterpriseの1クレジットは$4.3なので、$2115.6になります。


2回目の登場

ここまで細かく説明してきましたが、この仮想ウェアハウスのコンピューティング費用がSnowflake費用の大きな割合を占めることが多いです(料金の"超概要"だけ知りたい方は、このあとのストレージだけ読めばだいたいOKです)

1-2.サーバーレス(コンピューティング)

Snowflakeはマネージドサービスなので、設定しておくとSnowflake側でよしなにやってくれる機能がいくつかあります(オプション機能)

Snowpipeやサーバレスタスクを含むこれらの機能を利用する際に、前述の仮想ウェアハウスをユーザ側用意する必要はありませんが、Snowflake側で準備してるコンピューティングリソースを使用します。これがサーバーレス料金になります。

サーバレスか?仮想ウェアハウスか?(Snowpipeやタスク)

「Snowpipe(サーバレスを利用)か、仮想ウェアハウスを利用した通常のCOPYか?」や「サーバレスタスクか、仮想ウェアハウスを利用したタスクか?」など選択できるものもあります。これらはサーバレスを選択した場合は、1秒単位の課金なります(60秒への切り上げなし)、ただし1秒あたりの単価は機能ごとに異なる(マネージドサービスの係数がかかる)ので、実際に試して費用や便利さを比較して確認いただくことが確実です。


「Snowflakeサービス利用テーブル」から一部抜粋

関連ドキュメント : サーバーレスのクレジット使用状況
関連ドキュメント : コンピューティングコストの調査

1-3.クラウドサービス(コンピューティング)

ユーザーの認証、セキュリティの強化、クエリのコンパイルと最適化の実行、リクエストクエリのキャッシュの処理などなど、仮想ウェアハウスを使わない処理でも、Snowflakeとしてはパブリッククラウドのリソースを利用して機能を提供しています(SnowflakeがAWS等にお金を払っています)。それらの費用をユーザさんにフェアに負担いただくための課金です。

一方で「クラウドサービスの使用量は、クラウドサービスの日次消費量が仮想ウェアハウスの日次使用量の10%を超えた場合にのみ請求されます」なので、仮想ウェアハウスを使った分析をするといったような一般的なご利用であれば請求対象外になることが多いです(もしクラウドサービス使用量が大きいようなら、後述のクエリで原因にあたりをつけることが必要)

関連ドキュメント : クラウドサービスのクレジット使用状況
関連ドキュメント : コンピューティングコストの調査

クラウドサービス消費を調べる例
どのクエリタイプがクラウドサービス消費してるか調べる例(以前ドキュメントに載っていた)
select
    query_type, 
    sum(credits_used_cloud_services) cs_credits, 
    count(1) num_queries
from query_history
where true and start_time >= timestampadd(day, -30, current_timestamp)
group by 1
order by 2 desc
limit 10;
クラウドサービスの使用率が高いウェアハウス(ドキュメントから流用)
select
    warehouse_name
    ,sum(credits_used) as credits_used
    ,sum(credits_used_cloud_services) as credits_used_cloud_services
    ,sum(credits_used_cloud_services)/sum(credits_used) as percent_cloud_services
from "SNOWFLAKE"."ACCOUNT_USAGE"."WAREHOUSE_METERING_HISTORY"
where to_date(start_time) >= dateadd(month,-1,current_timestamp())
    and credits_used_cloud_services > 0
group by 1
order by 4 desc
;

2.ストレージ

基本的にはデータベースのテーブルとステージの保存容量です。1ヶ月の平均ストレージ容量(TB)✕ストレージ単価($/TB)です。ここでのストレージ容量は(Snowflakeが透過的に実施している)圧縮後の容量で計算されます。

こちらはクレジットを挟まずに、1ヶ月1TB保存したらの単価が直接$で設定されています。クラウドの各リージョンと料金支払い方法(後述)に応じた単価が設定されていますが、前払いであるキャパシティプランの場合はS3等オブジェクトストレージの利用料とほとんど同じです。

比較的安価

ストレージ料金は1TBを1ヶ月保存しても$25(AWS Tokyoで、キャパシティプランの場合)と非常に安価なので、(しつこいですが)一般的には仮想ウェアハウスのコンピューティング費用が、Snowflake費用の大きな割合を占めることが多いです

関連ドキュメント : ストレージコストについて

各種テーブルの使い分け

その他、TimeTravelやFail-safeでもストレージを消費します。変換処理に使うテーブルなどについてTimeTravelやFail-safeのストレージ費用を抑えたい場合は、これらの保持期間期間が短かったりする、仮テーブルと一時テーブルを選択することもできます。

関連ドキュメント : ストレージコストについて
関連ドキュメント : ストレージコストの調査

支払い方法

コンピューティング料金では関係なかったのですが、ストレージは支払い方法(オンデマンドまたはキャパシティ)によって単価が変わります。

事前に支払う「キャパシティプラン」だとストレージ費用は大幅に割引になります(キャパシティは事前に入金して、毎月利用した分をそこから消費していくイメージ)

3.データ転送

基本的にAWS等と同様に、Snowflakeから外にデータ転送(OUT、Egress)する際に料金が発生します…が、こちらもAWS等のデータ転送料金とほぼ同価格なので、一般的には大きな金額にはならないことが多いです(ストレージよりもさらに小さいことが多い)

主に「Snowflakeを使っているクラウドリージョンとは異なるリージョンの外部ステージへのデータのアンロード」や「Snowflakeを使っているクラウドリージョンとは異なるリージョンへのテーブルのレプリケーション(プライマリとセカンダリが別リージョン)」などがあります。詳細はドキュメントでご確認ください

関連ドキュメント : データ転送のコストについて
関連ドキュメント : データ転送コストの調査

Snowflakeの料金まとめ

ざっくりいうと…

大きく分けて3つの要素(コンピューティング・ストレージ・データ転送)で構成されていて、AWS等のクラウドと考え方はほぼ同じ。サポートは標準で含まれている(上位のサポートプランもオプションである)

3つのうちコンピューティングの割合が大半を占めることが多い(ストレージとデータ転送はあまり大きくない)


満を持して3回目の登場

仮想ウェアハウスは、タイプとサイズごとに設定されている時間単価(クレジット)✕起動していた時間で、1クレジットの単価は、クラウド、リージョン、エディションで決まる


実はこのスライド作るだけで良かったのかもしれない…

[試算例]コンピューティングは仮想WHのLを1クラスタを合計20時間利用し、ストレージは月間平均2TB使用していた場合

試算ツール(例)

あくまで非公式ですが、The unofficial Snowflake Pricing Calculatorはわりと有名です…がメンテされるか怪しい気もする… メンテされなくなってた。基本的にはワークロード毎にサイズ×稼働時間で計算するだけです。


時間帯ごとに利用者数が異なるイメージも入れられる

スペック決定は実際にクエリ流して見るのが一番確実ですね…


手入力でAWS Tokyoのクレジット単価にしてみた例

デフォルトではAWS US-EASTの単価が入っているので設定変更必要です。

そして、利用開始後のお話へ

本エントリではSnowflakeの料金ついて説明してきました。運用開始後、特に慣れてない最初のうちはこまめに利用状況を確認するのがいいかなと思います。ここからはほぼキーワードだけ

リソースモニタ


関連ドキュメント : リソースモニタ

アカウントレベルのリソースモニターは、サーバーレス機能(例: Snowpipe、自動再クラスタリング、マテリアライズドビュー)のためにSnowflakeが提供するコンピューティングリソースによるクレジット使用状況を制御しません。機能の完全なリストについては、 サーバーレス機能 をご参照ください。

皆さんのブログに感謝!
Snowflakeでクレジットの使用状況を確認してみた 〜SQL編〜 | DevelopersIO
Snowflakeのリソースモニターを設定してみた - ACCOUNTADMIN以外のユーザに通知したい!
Snowflakeでのクレジット監視Tips

日々の料金確認


関連ドキュメント : 総コストの調査

皆さんのブログに感謝!
Snowflakeでクレジットの使用状況を確認してみた 〜ウェブインターフェイス編〜
Snowflakeでクレジットの使用状況を確認してみた 〜SQL編〜


この記事はSnowflake Advent Calendar 2022のPart2の16日目でした。Part2の16日目はkommyさんの「Snowflake 1年目の教科書」です。

脚注
  1. AWSについて、ざっくり書けるよろこびを感じる ↩︎

  2. では"軽い"処理でも、常にハイスペックにしておけばいいのかというと、このあと出てくる時間のカウントの仕方があります ↩︎

Discussion