要点まとめ
- Streamlit in Snowflakeのホスティングでは、コンテナランタイムが私のデフォルトです。ダッシュボードが常にウォーム状態に保たれ、最高のユーザー体験が得られます。
- コンテナランタイムのノードは1時間あたり0.11クレジット。XSウェアハウスの1時間あたり1クレジットと比べて格安です。1クレジット$3の場合、常時稼働で月額約$238。1ノードで3つのダッシュボードをホストでき、4つ目から新しいノードが起動します。
- さらに節約するには、夜間タスクでコンピュートプールをサスペンドします。トレードオフは、翌朝、各ダッシュボードやアプリを最初に開いたユーザーが約45秒待つことです。
- サスペンド後は、実際に開かれたダッシュボードだけが課金を再開します。デプロイした分ではなく、使われた分だけ支払う形になります。
- Power BI Premium Per User 100シート分の料金(月額$2,400)で、夜間サスペンドを併用すれば、Snowflakeはアクティブに閲覧されるStreamlitアプリを約81個ホストできます。
はじめに
Streamlitは、データ中心のWebアプリやダッシュボードを作成できるオープンソースのPythonライブラリです。Pythonを書くだけで、HTMLやJavaScriptに一切触れることなく、チャート、フィルター、ボタン、モーダル、インタラクティブな操作を実現できます。Pythonだけで完結するこのアプローチにより、Streamlitはデータチームが社内ツールを素早く提供するための定番ツールになりました。
Snowflakeは2022年にStreamlitを買収し、その成果がStreamlit in Snowflakeです。アプリはSnowflakeアカウント内、つまりデータのすぐ隣で動作します。ホストするサーバーも、別のログインシステムも、データを外部にコピーする作業も不要です。アクセス権は、すでに管理しているロールにそのまま従います。
現在、SnowflakeでStreamlitアプリを実行する方法は2つあり、課金の仕組みは大きく異なります。選択を誤ったり、正しい方を一晩中稼働させたままにしたりすると、そのぶん請求に跳ね返ってきます。
本記事では、それぞれのオプションの課金の仕組み、私が実際にクレジットを無駄にした自動サスペンドの落とし穴、夜間サスペンドの方法とその効果(想像以上です)、そしてPower BIとの損益分岐点を解説します。
SnowflakeでStreamlitを実行する2つの方法
ウェアハウスランタイム
アプリは仮想ウェアハウス上で動作し、そのウェアハウスがアクティブな時間に対して課金されます。閲覧者が接続するたびに新しいStreamlitサーバープロセスが起動し、WebSocketによって、閲覧者の最後の操作から約15分後までウェアハウスは起動したままになります。このタイムアウトは設定可能なので、操作がない状態が5分続いたら停止するように簡単に変更できます。XSウェアハウスは起動中、1時間あたり1クレジットを消費します。SQLは別のクエリ用ウェアハウスで実行される可能性があるため、2つのウェアハウスがクレジットを消費することもあります。
コンテナランタイム
アプリは、Snowflakeが管理するコンピュートプールのノード上で動作します。Streamlitサーバーはそのノード上で常時稼働するため、ページの読み込みが速く、すべての閲覧者が同じサーバーを共有します。コールドスタートに遭遇するユーザーがほとんどいないため、ユーザー体験としては間違いなく最良です。
Snowflakeは両方をサポートしており、新規アプリではコンテナランタイムがデフォルトになりつつあります。
私の見解: コスト削減のためにウェアハウスランタイムを5分という厳しいタイムアウトで使うのは、ほぼすべての訪問者がコールドスタートに当たるため、ユーザー体験としては好ましくありません。私はすべてのStreamlitアプリでコンテナランタイムを使っており、最初のユーザーがページを開いた後は、ダッシュボードがウォームかつキャッシュ済みの状態になります。
同じStreamlitコードでも、請求額は大きく違います。
Streamlitプロセスには可能な限り小さいコンピュートを選ぶ
ウェアハウスランタイムでも、新しくデフォルトとなったコンテナランタイムでも、Streamlitプロセス自体に大きな処理能力は必要ありません。私がこれまで見てきたStreamlitアプリは、どれもExtra SmallのGen 1ウェアハウスで十分動きます。クエリ自体はより大きなウェアハウスを使えばよいので、Streamlitプロセスにクレジットを浪費しないでください。
ノートPCでダッシュボードを開発できるなら、Extra Small、またはCPU_X64_Sで動作するデフォルトのコンピュートプールでホストできます。
コンテナランタイムの課金の仕組み
1ノードが1つの課金単位です。 デフォルトのシステムCPUプールでは、Snowflakeは1ノードに3つのダッシュボードを詰め込みます。4つ目のダッシュボードが稼働すると2台目のノードが起動し、7つ目で3台目が起動します。プールは3つ刻みで拡大します(詳しい例は後述のコストシナリオをご覧ください)。
最小ノードのコストは1時間あたり約0.11クレジット。計算すると次のようになります。
- 1日あたり2.64クレジット
- 月あたり約79クレジット
- 自動サスペンドが一度も効かない場合、1クレジット$3で1日$7.92、月額$237.6
クレジット単価は環境によって異なるので、ご自身の単価に置き換えてください。以下の例ではすべて$3を使用します。
注目すべきポイント:
- 閲覧者が1人でも100人でも料金は同じです。 ノード側には関係ありません(後述のPower BIのユーザー単位ライセンス価格との比較をご覧ください!)。この料金モデルは新鮮です。ユーザー単価のBIライセンスにはもううんざりしています。
- ノードの時間単価はXSウェアハウスの約9分の1です。 落とし穴は、ノードは稼働し続けるのに対し、ウェアハウスは停止するという点です。コード用ウェアハウスが1日に約2.6時間以上起動しているならノードが有利、ダッシュボードが週に2回しか開かれないならウェアハウスが有利です。
- 誰も開いていないダッシュボードのコストはゼロです。 アプリのサービスは最初の閲覧時に起動します。25個のダッシュボードをデプロイしても、9ノードを借りることにはなりません。開かれたものだけが課金対象です。
- コンテナランタイムはクエリコストをなくすわけではありません。 SQLは引き続きウェアハウスで実行されます。本記事で扱うのは、アプリのホスティングコストのみです。
クエリ実行にAdaptive Warehouseを組み合わせたStreamlitのコンテナランタイムは、非常に良い体験でした。Snowflakeのドキュメントによると、Adaptive WarehouseはGen 2ウェアハウスより高速です。
Streamlitのコンピュートプールは何ノード稼働している?
Streamlitアプリはデフォルトのコンピュートプール system_compute_pool_cpu にデプロイされます。稼働中のノード数は、UIのサイドバーにある「Compute」から「compute pools」で確認できます。
その行をクリックすると詳細ページに移動し、どのアプリが実行中かを確認できます。
コードで確認したい場合は、次を実行します。
show compute pools like 'SYSTEM_COMPUTE_POOL_CPU';その後、active_nodes 列を確認してください。
自動サスペンドの落とし穴
ドキュメントにはこう書かれています。閲覧者の操作がない状態が3日間続くとStreamlitサーバープロセスが終了し、その後、コンピュートプールは自身のAUTO_SUSPEND値に従ってサスペンドする、と。
これには2つの問題があります。
第一に、この3日間は今のところ設定変更できません。 1日や1時間に短縮できないのです。アイドル状態のノード3日分は約8クレジット、つまり$24。単体では大した額ではありませんが、プール全体、そしてデプロイするすべての環境で積み重なっていきます。
第二に、プール自体のAUTO_SUSPENDは、プール上でサービスが1つも動いていない状態になって初めてカウントが始まります。 Streamlitサービスは3日間が経過するまで居座り続けるため、プールのタイマーが役に立つ機会はまったくありません。
2026年10月15日時点では、自動サスペンドは確実には作動しません。サービスとそのコンテナが3日目を過ぎても稼働し続け、4日目にもコストが発生しているのを私自身が目撃しました。Snowflakeのサポートによると、原因は開いたままのブラウザタブがWebSocketの再接続を繰り返すことだそうです(401で拒否された再接続でも、バックエンドのアイドルタイマーがリセットされます)。Snowflakeは修正に取り組んでいるので、本記事を読む頃には解決済みかもしれません。
プライベートプレビュー機能として、ウェアハウスランタイムと同様にアプリレベルで idle_auto_shutdown_time_seconds を設定できるものがあります。Streamlitアプリをdescribeしたときにこのプロパティを見かけたことがあるかもしれません。プレビューへの参加が認められれば、より短い値を設定できます。Snowflakeのアカウントチームに問い合わせてみてください。各アプリに数時間の値を設定して、できる限り無駄のない構成にできたら最高です!
それまでは、3日タイマーを当てにしないでください。節約したいなら、自分でサスペンドしましょう。詳しく見ていきます。
夜間にサスペンドして、ユーザーに起こしてもらう
最もシンプルなコスト削減策は、毎晩プールをサスペンドするスケジュールタスクです。
CREATE OR REPLACE TASK suspend_streamlit_pool SCHEDULE = 'USING CRON 30 18 * * * America/New_York'AS ALTER COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU SUSPEND;タスクを所有するロールには、プールに対するOPERATE権限が必要です。サーバーレスタスクとして実行する場合は、EXECUTE MANAGED TASKも必要です。
朝は誰も何もする必要がありません。最初にダッシュボードを開いた人がプールを起こします。私の経験では、この最初の読み込みには約45秒のコールドスタートが発生します。それ以降は、誰が開いても高速です。
見落とされがちなポイント ― 節約が積み上がる仕組み
夜間にプールをサスペンドすると、すべてのダッシュボードがシャットダウンされます。翌朝、開かれたものだけが復帰し、課金もそれらだけが再開します。
たとえばダッシュボードが25個あるとします。すべて稼働させたままなら、時間が経てば誰かが全部を開くため、9ノード分の料金を支払うことになります。夜間にサスペンドし、翌日4個しか開かれなければ、支払いは2ノード分。残りの21個は、その日コストゼロです。
つまり夜間サスペンドは、サスペンドした夜間の時間分を節約するだけの小技ではありません。誰も見ていないダッシュボードへの支払いも止まるのです。月末レポート、四半期レビュー、数か月前のプロジェクトで作られた古びたダッシュボード。これらは、誰かが実際に閲覧した日にだけコストが発生します。
請求額は、デプロイした数ではなく、1日に開かれたダッシュボードの数に連動するようになります。
メリット
- 請求が予測可能になります。最悪ケースを把握できます。
- 自動サスペンドのバグが存在する間も機能します。
- ダッシュボードが3個でも30個でも、1つのステートメントでプール内の全ノードをサスペンドできます。
- めったに使われないダッシュボードにコストがかからなくなります。
- 覚えておくことは何もありません。誰かがログインして停止する必要もありません。
デメリット
- 各ダッシュボードのその日最初の閲覧者は約45秒待ちます。私のユーザーはこれで問題ありませんでした。
- 深夜や週末に作業する人も同じコールドスタートに当たります。
- サスペンドするとプール上のすべてのノードが落ちます。セッション中の人は突然再起動ページに遭遇するため、全員が退勤した後の時間帯を選びましょう。個人的にはリスクは低く、復帰も十分速いので、やる価値はあると思います。
朝一番にダッシュボードを開く人にとって45秒が長すぎる場合は、出社の数分前にそれらのアプリのエンドポイントへ認証付きリクエストを送ることもできます。私の環境では機能しましたが、OAuthのセットアップが必要になり、複雑さが増します。ウォームアップするのは重要な数個だけに絞らないと、誰も読まないダッシュボードで節約分を帳消しにしてしまいます。私にとっては、事前ウォームアップは(OAuthフローが必要な点で)手間に見合わないと感じますが、選択肢としては存在します。
コストシナリオ
前提: 1クレジット$3、デプロイ済みダッシュボード25個、1ノードあたり3ダッシュボード。「サスペンドあり」は、ノードが平日のみ(月22日)1日12時間稼働する想定です。これは上限値です。午後2時に開かれたダッシュボードには、午前中の課金が発生しないためです。
これを、25個すべてを24時間稼働させた場合と比較してみましょう。時間が経てばすべてのダッシュボードが開かれるため、9ノード分を1か月まるごと支払うことになります。その額は$2,138。通常の1日で4個しか使われないなら、夜間サスペンドで$2,138が$174になります。
ノードは詰めて使いましょう。4個目のダッシュボードも6個目も同じコストなので、2台目のノードに料金を払うなら、埋めてしまうのが得策です。
Power BIとの損益分岐点
Power BI Proはユーザー単位課金です。定価の月額$14/ユーザーでは、レポートを閲覧する全員にシートが必要です。Streamlit in Snowflakeはノード単位課金で、プラットフォーム料金もシート料金もありません。
まずは自社の利用人数から考えましょう。月額$24/ユーザー(Premium)のPower BIのコストと、同じ金額で夜間サスペンドを使ってSnowflakeが何個のダッシュボードを動かせるかを示します。
表の読み方はこうです。4個のダッシュボードを50人が使う場合、Power BI Proは月約$700、Snowflakeは$174。25個すべてを40人が使う場合、Power BIは約$560、Snowflakeは$784(サスペンドなしなら$2,138)です。ダッシュボードあたりの利用者が多いほどSnowflakeが有利になり、1人あたりのダッシュボード数が多いほどPower BIが有利になります。
正直にお伝えすべき注意点が2つあります。
- Streamlitはコードで、Power BIはドラッグ&ドロップです。アナリストがPythonを書けない(あるいはAIを十分に使いこなせていない)場合、ホスティングの節約額は問題にならないかもしれません。
- Power BI Premium Per Userは月額$24/ユーザーで、Fabricキャパシティなら大規模導入で閲覧者のシートが不要になりますが、月額およそ$5,000からです。ビジネスケースを作る前に最新価格を確認してください。
押さえておきたいポイント
- 頻繁に開かれるダッシュボードにはコンテナランタイムを使いましょう。時間あたりコストが安く、ウェアハウスの利用と混在させたくないので、コンテナランタイムが私の新しいデフォルトです。積極的に自動サスペンドするウェアハウスと比べて、コールドスタートが少ないユーザー体験も気に入っています。
- 1ノードあたり3ダッシュボード。4つ目から新しいノードが起動します。
- 最小ノードは1時間あたり約0.11クレジット、1日2.64クレジット、1クレジット$3なら月額約$238です。この最小ノードで問題なくダッシュボードをホストできます。データサイズは関係ありません。クエリは引き続き仮想ウェアハウスで実行されます。
- 3日間の自動サスペンドに頼らないこと。スケジュールでプールをサスペンドしましょう。
- サスペンド後は、開かれたダッシュボードだけが課金を再開します。デプロイした分ではなく、使われた分だけの支払いです。
- 45秒のコールドスタートを想定し、ユーザーにも事前に伝えておきましょう。
- 閲覧者が数十人を超えたら、ノード単位課金がシート単位課金に勝ります。
Streamlit構成のサイジングや、Snowflakeクレジットの使途の把握についてサポートが必要でしたら、ぜひお気軽にご連絡ください!