【要約】Streamlit in Snowflake でアプリを 1 本作る — どこで課金されるのか [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がSnowflake上でStreamlitアプリを構築する際、ランタイムの特性を誤解すると予期せぬコスト増大を招く。特に、アプリの停止条件と課金対象の範囲を把握していないことが問題となる。
- ・ランタイムによって課金対象となるリソースが異なる。
- ・コンテナランタイムはIDLE状態でも課金が継続される。
- ・コンテナの停止には、無操作期間とAUTO_SUSPEND設定による長いタイムラグが存在する。
// Approach
開発者がコストを最適化できるよう、2種類のランタイムの挙動とコスト構造を比較・検証する。具体的には、TPC-Hのサンプルデータを用いた可視化アプリの実装を通じて、以下の差異を整理した。
- ・コンテナランタイム：コンピュートプール（Python用）とクエリウェアハウス（SQL用）の分離構成。
- ・ウェアハウスランタイム：単一のウェアハウスでPythonとSQLの両方を処理する構成。
- ・停止制御：sleep timer（ウェアハウス）とAUTO_SUSPEND（コンテナ）による停止条件の比較。
// Result
ランタイムの選択によって、コスト効率と運用管理の難易度が明確に分かれることが判明した。
- ・コンテナランタイム：単価は安いが、停止までに最大3日以上のラグが生じる可能性がある。
- ・ウェアハウスランタイム：単価は高いが、sleep timerにより数分単位での停止が可能である。
- ・結論：毎日利用されるアプリにはコンテナ、低頻度な利用にはウェアハウスが適している。
Senior Engineer Insight
> 開発体験（DX）は極めて高いが、運用コスト（FinOps）の視点が不可欠だ。コンテナランタイムは単価が低い反面、停止までのラグが非常に長い。3日間の無操作期間とAUTO_SUSPEND設定の組み合わせは、小規模な検証用途ではコスト爆発を招く恐れがある。頻繁に利用される基幹ダッシュボードにはコンテナ、たまにしか使わないツールにはウェアハウスという、利用頻度に基づいた厳格な使い分けを推奨する。