社内の Streamlit in Snowflake アプリでウェアハウスランタイムとコンテナランタイムのコストを比較してみた
はじめに
社内で運用している Streamlit in Snowflake アプリ（ダッシュボード）を、ウェアハウスランタイムからコンテナランタイムへ移行しました。短期間ではありますが、移行前後の消費量を算出比較してみましたので、その内容をまとめてみます。
アプリの概要
社内の所属チームで定期的に発生するタスクがありました。これまでは、Snowflake のダッシュボード機能を使用し各種確認作業を行っていたのですが、ダッシュボード機能廃止に伴い、Streamlit in Snowflake（以降、SiS とします）上のダッシュボードに移行しました。
当初は構成の容易なウェアハウスランタイムから試してみましたが、現在 SiS はコンピュートプールでホストすることができます。これにより、アプリ実行とクエリ実行の分離、共有インスタンスであることによるキャッシュの恩恵を受けることもできます。
ランタイムの違による特徴は以下に記載があります。
また、以下の記事でも詳しく紹介されています。
Streamlit in Snowflake のランタイムとコスト
上記のように SiS には、ウェアハウス上でアプリを実行するウェアハウスランタイムと、Snowpark Container Services のコンピュートプール上でアプリを実行するコンテナランタイムの2種類があります。
コストを考える上での前提として、SiS には「アプリホスト用のコンピュート（Streamlit サーバー本体を動かす分）」と「クエリ用のコンピュート（アプリ内で発行される SQL を実行する分）」という2種類の概念があります。ウェアハウスランタイムではデフォルトで両者は同一のウェアハウスが使われます。一方コンテナランタイムでは、アプリホスト側は常にコンピュートプールが使われ、クエリ側はQUERY_WAREHOUSEで指定したウェアハウスが使われるという構成が前提になります。
コンテナランタイムについては、例えばCPU_X64_XSなど小さいインスタンスであれば、時間当たりのクレジット単価が 0.06 など通常のウェアハウスを使用するよりも安価です。
一方でコンテナランタイムのアイドルタイムアウトについては、以下の記事でも触れているように、アプリのビューへのアクセスが3日間ないと初めてサービスが自動停止し、その後さらにコンピュートプールのAUTO_SUSPEND_SECSが経過して初めて課金が止まるなどの仕組みがあり、ウェアハウスのAUTO_SUSPEND（多くの場合数十秒〜数分）と比べると、かなり長時間アイドル状態のまま稼働し続けることになります。
ノード単価自体はウェアハウスに比べて安価ではあるものの、実際の使用頻度とあわせたときに、この単価やアイドル時間の長さが実際のコストにどう効いてくるのかを、社内の一ユースケースで実測してみました。
前提条件
検証環境
今回対象としたアプリのユースケースは以下の規模感・使用頻度です。
- 利用者数：関連するメンバー15名程度。15名は最大。同時アクセスは数名が基本。
- 使用頻度：常時アクセスがあるわけではなく、月初に前月分の確認作業でまとまってアクセスが発生し、それ以外の期間はアクセスが少ない（日によってはゼロの）断続的な利用パターン
- 集計期間：
- 移行前（ウェアハウスランタイム）は2026/8/2の移行日を基準に、その前月にあたる2026/7/1〜7/31（31日間）、移行後（コンテナランタイム）は移行日翌日の2026/8/2〜8/31（30日間）をそれぞれ1ヶ月分として比較
- 母数が異なるのは、移行日翌日の8/2から集計を開始しているためです。なお、対象外となる8/1は休日かつ対象ウェアハウスのクレジット消費も実績上ゼロだったため、比較への影響はないと考えています
移行前後で、アプリのホストにはそれぞれ以下のオブジェクトを使用しています。
| 種別 | サイズ / インスタンスファミリー | ノード/クラスタ数 | AUTO_SUSPEND | 単価（Credits/時間） |
|---|---|---|---|---|
| ウェアハウスランタイム | X-Small |
min/max = 1 | 60秒 | 1.00 |
| コンテナランタイム | CPU_X64_XS |
min/max = 1 | 300秒 | 0.06 |
単価はいずれもSnowflake Service Consumption Tableに記載の値です。
特徴として、アプリ内で実行される SQL クエリ自体は、ランタイム移行の前後を通じて同じ仮想ウェアハウスを使い続けています。つまりコンテナランタイム移行後は、アプリ実行（Streamlit サーバー本体）はコンピュートプール、アプリ内のクエリ実行、は従来のウェアハウスのまま継続利用となります。
コンテナランタイム移 行後のコストはコンピュートプール分とウェアハウス分の合計で見ていきます。
事前準備：コンピュートプールの強制停止タスク
前述の通り、コンテナランタイムのアイドルタイムアウトは既定で3日間と長く、コスト影響が大きいと判断したため、移行と合わせて毎日22時（JST）にコンピュートプールを強制停止するタスクを用意しています。
このタスクを導入した状態でのコスト比較である点にご注意ください。
実際にクレジット消費量を比較する
ACCOUNT_USAGE 配下のビューから、ウェアハウスランタイム期間（移行前）とコンテナランタイム期間（移行後）それぞれのクレジット消費量を取得しました。
ウェアハウスランタイム期間（移行前・1ヶ月分）
まず、ウェアハウスの日別クレジット消費量を取得します。
※以降のウェアハウス名、コンピュートプール名はブログ公開用の名称に置き換えています。
SELECT
DATE_TRUNC('day', start_time)::date AS usage_date,
warehouse_name,
SUM(credits_used) AS credits_used
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'APP_WH'
AND start_time >= '2026-07-01'
AND start_time < '2026-08-01'
GROUP BY 1, 2
ORDER BY 1;
実行結果
+------------+----------------+--------------+
| USAGE_DATE | WAREHOUSE_NAME | CREDITS_USED |
|------------+----------------+--------------|
| 2026-07-03 | APP_WH | 4.993201658 |
| 2026-07-06 | APP_WH | 1.121474721 |
| 2026-07-07 | APP_WH | 1.750394170 |
| 2026-07-08 | APP_WH | 2.970813059 |
| 2026-07-09 | APP_WH | 0.163338610 |
| 2026-07-10 | APP_WH | 0.371989166 |
| 2026-07-17 | APP_WH | 0.750935279 |
| 2026-07-29 | APP_WH | 0.319601668 |
+------------+----------------+--------------+
月内でアクセスが発生した日はまばらで、特に月初クレジット消費が多い想定通りの結果でした。
こちらを集計すると、以下のような結果になりました。
SELECT
warehouse_name,
SUM(credits_used) AS total_credits,
COUNT(DISTINCT DATE_TRUNC('day', start_time)) AS active_days,
ROUND(SUM(credits_used) / COUNT(DISTINCT DATE_TRUNC('day', start_time)), 3) AS avg_credits_per_active_day
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'APP_WH'
AND start_time >= '2026-07-01'
AND start_time < '2026-08-01'
GROUP BY warehouse_name;
実行結果
+----------------+---------------+-------------+----------------------------+
| WAREHOUSE_NAME | TOTAL_CREDITS | ACTIVE_DAYS | AVG_CREDITS_PER_ACTIVE_DAY |
|----------------+---------------+-------------+----------------------------|
| APP_WH | 12.441748331 | 8 | 1.555 |
+----------------+---------------+-------------+----------------------------+
- 消費のあった日数：8日 / 31日（それ以外の日はアクセスなしでコストゼロ）
- 月合計：約 12.441 クレジット
- 稼働日あたり平均：約 1.555 credits/日
コンテナランタイム期間（移行後・1ヶ月分）
移行後はコンピュートプール側とウェアハウス側の両方を集計します。まずコンピュートプール側（アプリ実行分）の日別クレジット消費量です。
-- コンピュートプール側（アプリ実行）
SELECT
DATE_TRUNC('day', start_time)::date AS usage_date,
compute_pool_name,
SUM(credits_used) AS credits_used
FROM SNOWFLAKE.ACCOUNT_USAGE.SNOWPARK_CONTAINER_SERVICES_HISTORY
WHERE compute_pool_name = 'APP_CP'
AND start_time >= '2026-08-02'
AND start_time < '2026-09-01'
GROUP BY 1, 2
ORDER BY 1;
+------------+-------------------+--------------+
| USAGE_DATE | COMPUTE_POOL_NAME | CREDITS_USED |
|------------+-------------------+--------------|
| 2026-08-02 | APP_CP | 0.036166666 |
| 2026-08-04 | APP_CP | 0.472166656 |
| 2026-08-05 | APP_CP | 0.667583318 |
| 2026-08-06 | APP_CP | 0.402583325 |
| 2026-08-07 | APP_CP | 0.771583316 |
| 2026-08-13 | APP_CP | 0.766516651 |
| 2026-08-14 | APP_CP | 0.763716650 |
| 2026-08-18 | APP_CP | 0.666066657 |
| 2026-08-20 | APP_CP | 0.397033326 |
| 2026-08-21 | APP_CP | 1.297699973 |
| 2026-08-24 | APP_CP | 0.333016659 |
| 2026-08-25 | APP_CP | 1.298433305 |
| 2026-08-26 | APP_CP | 0.393566658 |
| 2026-08-28 | APP_CP | 0.626866652 |
+------------+-------------------+--------------+
8月は、月を通して断続的にアクセスがあり、特定の日だけに極端に偏ってはいない結果でした。
集計クエリと結果
SELECT
compute_pool_name,
SUM(credits_used) AS total_credits,
COUNT(DISTINCT DATE_TRUNC('day', start_time)) AS active_days,
ROUND(SUM(credits_used) / COUNT(DISTINCT DATE_TRUNC('day', start_time)), 3) AS avg_credits_per_active_day
FROM SNOWFLAKE.ACCOUNT_USAGE.SNOWPARK_CONTAINER_SERVICES_HISTORY
WHERE compute_pool_name = 'APP_CP'
AND start_time >= '2026-08-02'
AND start_time < '2026-09-01'
GROUP BY compute_pool_name;
結果
+-------------------+---------------+-------------+----------------------------+
| COMPUTE_POOL_NAME | TOTAL_CREDITS | ACTIVE_DAYS | AVG_CREDITS_PER_ACTIVE_DAY |
|-------------------+---------------+-------------+----------------------------|
| APP_CP | 8.892999812 | 14 | 0.635 |
+-------------------+---------------+-------------+----------------------------+
30日のうち14日で消費があり、期間合計は約8.893クレジット、稼働日あたり平均は約0.635クレジットでした。
続いて、クエリ実行に使われるウェアハウス側のクレジット消費も同様に確認します。
-- ウェアハウス側（クエリ実行、移行後も継続利用）
SELECT
DATE_TRUNC('day', start_time)::date AS usage_date,
warehouse_name,
SUM(credits_used) AS credits_used
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'APP_WH'
AND start_time >= '2026-08-02'
AND start_time < '2026-09-01'
GROUP BY 1, 2
ORDER BY 1;
結果
+------------+----------------+--------------+
| USAGE_DATE | WAREHOUSE_NAME | CREDITS_USED |
|------------+----------------+--------------|
| 2026-08-02 | APP_WH | 0.116200277 |
| 2026-08-04 | APP_WH | 0.231462219 |
| 2026-08-05 | APP_WH | 0.395752227 |
| 2026-08-06 | APP_WH | 0.354242217 |
| 2026-08-07 | APP_WH | 0.558275832 |
| 2026-08-13 | APP_WH | 0.041256947 |
| 2026-08-14 | APP_WH | 0.114310834 |
| 2026-08-18 | APP_WH | 0.081126391 |
| 2026-08-20 | APP_WH | 0.129711666 |
| 2026-08-21 | APP_WH | 0.057730555 |
| 2026-08-24 | APP_WH | 0.254319720 |
| 2026-08-25 | APP_WH | 0.061893332 |
| 2026-08-28 | APP_WH | 0.290873890 |
+------------+----------------+--------------+
コンピュートプール側とほぼ同じ日にクエリが実行されており、アプリへのアクセスとクエリ実行のタイミングが連動していることがわかります。
集計クエリと結果
SELECT
warehouse_name,
SUM(credits_used) AS total_credits,
COUNT(DISTINCT DATE_TRUNC('day', start_time)) AS active_days,
ROUND(SUM(credits_used) / COUNT(DISTINCT DATE_TRUNC('day', start_time)), 3) AS avg_credits_per_active_day
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'APP_WH'
AND start_time >= '2026-08-02'
AND start_time < '2026-09-01'
GROUP BY warehouse_name;
+----------------+---------------+-------------+----------------------------+
| WAREHOUSE_NAME | TOTAL_CREDITS | ACTIVE_DAYS | AVG_CREDITS_PER_ACTIVE_DAY |
|----------------+---------------+-------------+----------------------------|
| APP_WH | 2.687156107 | 13 | 0.207 |
+----------------+---------------+-------------+----------------------------+
30日のうち13日で消費があり、期間合計は約2.687クレジット、稼働日あたり平均は約0.207クレジットでした。
移行後の結果を集計すると以下のようになりました。
| 項目 | コンピュートプール | ウェアハウス | 合計 |
|---|---|---|---|
| 消費のあった日数 | 14日 / 30日 | 13日 / 30日 | - |
| 期間合計 | 約 8.893 credits | 約 2.687 credits | 約 11.580 credits |
| 稼働日あたり平均 | 約 0.635 credits/日 | 約 0.207 credits/日 | - |
移行前後の比較
結果の比較は以下の通りです。
| 項目 | 移行前（ウェアハウスランタイム） | 移行後（コンテナランタイム、CP+WH合計） |
|---|---|---|
| 期間合計 | 約 12.441 credits | 約 11.580 credits |
| アクセスのあった日数 | 8日 / 31日 | 14日 / 30日 |
| 稼働日あたり平均 | 約 1.555 credits/日 | 約 0.827 credits/日 |
月合計だけを見ると、移行後は約 -0.861 credits やや減少しています。ただし移行後はアクセスのあった日数が7日から14日に増えており、それでも月合計がほぼ横ばいという結果でした。稼働日あたりの平均で見ると、1.555 → 0.827 credits/日と約47%の減少で、アクセス1回あたりのコスト効率という観点ではコンテナランタイムの方が良い結果になりました。
また、今回のような小規模アプリでは、コンピュートプールの停止タスクをさらに高頻度で実施する、なども検討できます。
まとめ
今回の検証結果をまとめると以下の通りです。
| 項目 | ウェアハウスランタイム | コンテナランタイム |
|---|---|---|
| ノード/ウェアハウス単価 | 高い | 安い（約1/17） |
| アイドル時の挙動 | 秒単位で自動停止 | サービス自体は最大3日間稼働し続ける |
| 実際の稼働時間 | 短い（アクセスがある時間のみ） | 長い（アプリを開いている間ずっと） |
| 月間コスト（今回の実測） | 移行前とほぼ同水準 | 移行前とほぼ同水準（やや減） |
コンテナランタイムはノード単価こそ安いものの、アイドルタイムアウトが長いために結果的に稼働時間が伸びる点はやはり注意が必要です。アプリの使用頻度によりますが、今回試したような強制停止タスクの導入なども合わせて検討するのがよいと思います。
結論として、今回のケースではコストは悪化しておらず、コンテナランタイムならではのメリット（アプリ実行とクエリ実行の分離、共有インスタンスのキャッシュ等）もあるため、引き続きコンテナランタイムで運用していく予定です。
さいごに
Streamlit in Snowflake のウェアハウスランタイムとコンテナランタイムについて、実際のクレジット消費量をもとにコストを比較してみました。
こちらの内容がどなたかの参考になれば幸いです。
