Streamlitアプリのランタイム環境¶

Streamlit in Snowflake は、Streamlitアプリ用に2種類のランタイム環境を提供します。

コンテナランタイム（プレビュー）:アプリを長時間実行するサービスとして提供し、すべてのビューアーの間で共有されるアプリの専用インスタンスを作成します。
ウェアハウスランタイム:オンデマンドで実行し、ビューア―ごとにアプリの個人用インスタンスを作成します。

注釈

ROOT_LOCATION パラメーターを使用した CREATESTREAMLIT コマンドを使用すると、アプリはウェアハウスランタイムのみを使用でき、追加制限が適用されます。このページでは、 FROM パラメーターで作成されたアプリを説明します。詳細については、さまざまなタイプのStreamlitオブジェクトについて理解するをご参照ください。

次のテーブルは、 Streamlit in Snowflake アプリのウェアハウスランタイムとコンテナランタイムでサポートされる機能を比較しています。

サポートされている機能	ウェアハウスランタイム	コンテナランタイム
コンピュート	アプリコードおよび内部クエリ用の仮想ウェアハウス。	アプリコードのコンピューティングプールノード。内部クエリ用の仮想ウェアハウス。
実行の長さ	スリープタイマーで構成可能です。	ビューが3日間使用されないと停止します。
メンテナンス・ウィンドウ	該当なし。	Snowpark Container Servicesメンテナンスウィンドウの対象です。
ベースイメージ	PythonストアドプロシージャのLinux。	Snowparkコンテナ内のLinux。
Pythonバージョン	3.9、3.10、3.11	3.11
Streamlitバージョン	1.22+（制限付き選択）	1.50+ (any version, including `streamlit-nightly` versions).
依存関係	`environment.yml` 経由のSnowflake Condaチャネルからのパッケージ。	`pyproject.toml` または `requirements.txt` 経由の PyPI などの外部パッケージインデックスからのパッケージ。
	`=` 演算子でバージョンを固定します。	`==` 演算子でバージョンを固定します。
	`*` ワイルドカードでバージョン範囲を使用します。	`<`, `<=`, `>=`, `>` およびコンマ区切りリストでバージョン範囲を使用します。
エントリーポイントの場所	ソースディレクトリのルート。	ソースディレクトリ内のルートまたはサブディレクトリ。
Streamlitサーバー	各ビューアセッションに対するStreamlitサーバーの仮の個別のインスタンス。	すべてのビューアーセッション用の永続的な共有サーバーインスタンス。
	ビューアセッション間でディスク、コンピューティング、メモリリソースを共有しません。	ビューアセッション間でディスク、コンピューティング、およびメモリリソースを共有します。
	セッション間のキャッシュはサポートしていません。	Streamlitのキャッシュ機能を完全にサポートします。
起動時間	オンデマンドアプリ作成のため、ビューアーセッションあたりの速度が低下します。	ビューアーセッションごとに高速になりますが、コンテナの起動により展開が遅くなります。
アクセス	編集するには所有権が必要です。	ウェアハウスランタイムと同じです。
	クエリに所有者権限を使用します。所有者権限ストアドプロシージャと同様に制限されます。	クエリに所有者の権限を使用します。オプションで、一部またはすべてのクエリで呼び出し元の権限を使用できます。

コンテナランタイム¶

コンテナランタイムは、すべてのビューアーで共有されるStreamlitアプリの専用インスタンスを提供します。各ビューアーはアプリの同じインスタンスに接続するため、ビューアーはすでに稼働しているアプリにすばやく接続できます。コンテナは1分あたりのコストがウェアハウスよりも大幅に低く、特に頻繁に使用されるアプリでは、一般的により費用対効果の高いホスティングソリューションです。

コンテナランタイムは、ビューアセッション間でディスク、コンピューティング、およびメモリリソースを共有します。これは、Streamlitのキャッシュ機能をフルに活用して、パフォーマンスを向上させることができることを意味します。効率的なアプリ設計は、コンテナランタイムを使用して、すべてのビューアーが素晴らしい体験をできるようにすることが重要です。

外部アクセス統合を使用すると、 PyPI または `簡単なリポジトリ API<https://peps.python.org/pep-0503/>`_ をサポートするその他のパッケージインデックスからPythonパッケージをインストールできます。これにより、コンテナランタイムがより柔軟になります。streamlit-nightly バージョンを含むStreamlitの最新バージョンにいつでもアクセスできます。

ウェアハウスランタイム¶

ウェアハウスランタイムは、各ビューア―にStreamlitアプリのオンデマンドの個人用インスタンスを提供します。ビューアーがアプリを開くと、そのビューアー用にアプリの新しいインスタンスが作成されます。各ビューアーは独自の分離された環境を持っているため、ユーザーのロード時間が長くなります。どちらのランタイムも所有者の権限を使用して SQL クエリを実行しますが、ウェアハウスランタイムを使用したアプリは、所有者権限のストアドプロシージャと同様の制限が適用されます。詳細については、所有者権限ストアドプロシージャをご参照ください。

Streamlit in Snowflake でリソースを選択するためのガイドライン¶

Streamlit in Snowflake でStreamlitアプリを実行する場合、Streamlitアプリの複雑さ、ウェアハウスの可用性、レイテンシなど、複数の要因がパフォーマンスに影響する可能性があります。以下のセクションでは、Streamlit in Snowflake で仮想ウェアハウスやコンピューティングプールを使用するための一般的なガイドラインを示します。

コンピューティングプールの選択¶

When you use a container runtime, you must select a compute pool to run the Streamlit app. Each Streamlit app runs on a single compute pool node; a Streamlit app takes an entire node. The size of the compute pool node affects the performance of the app. Larger node sizes can be used if your app requires more memory. However, because Streamlit runs as a single process, your app is unlikely to benefit from multiple CPUs. For more information, see コンピューティングプールの作成.

Tip

将来、アプリをさらに追加する際の混乱を減らすには、将来のStreamlitアプリを考慮して MAX_NODES を設定します。
アプリの作成を迅速に行うには、テストや実験を含め、同時に実行する予定のアプリの数と同じ MIN_NODES でコンピューティングプールを作成します。
コストを削減するには、より小さなノードサイズを使用します。
ノードの数量とノードサイズの両方がコストに影響します。詳細については、コンピューティングプールコストをご参照ください。

たとえば、以下のコマンドは、2つから5つのStreamlitアプリを同時に実行するコンピューティングプールを作成します。

CREATE COMPUTE POOL streamlit_compute_pool
 MIN_NODES = 2
 MAX_NODES = 5
 INSTANCE_FAMILY = CPU_X64_XS;

Copy

仮想ウェアハウスの選択¶

コスト、パフォーマンス、モニターを最適化するには、アプリの実行とアプリ内でクエリの実行に別々のコンピューティングリソースを使用します。コンテナランタイムを使用すると、アプリコードがコンピューティングプールノード上で実行され、そのクエリが仮想ウェアハウスで実行されるため、コンピューティングリソースは自動的に分離されます。ウェアハウスランタイムを使用する場合、アプリコード内で別のクエリウェアハウスをアクティブ化しない限り、アプリは同じウェアハウスを使用してアプリコードを実行し、クエリを実行します。

例えば、ウェアハウスランタイムを使って、X-Smallウェアハウスを使用してPythonコードを実行し、アプリでLクエリウェアハウスをアクティブ化して複雑なクエリを実行することができます。

注釈

CREATESTREAMLIT および ALTERSTREAMLIT コマンド内で、 QUERY_WAREHOUSE パラメーターは、ランタイムタイプに応じて異なる方法で使用する必要があります。

コンテナランタイムの場合、 QUERY_WAREHOUSE はアプリ内でクエリを実行するためのクエリウェアハウスを設定します。
ウェアハウスランタイムの場合、 QUERY_WAREHOUSE はアプリコードを実行するためのコードウェアハウスを設定します。アプリコード内で別のウェアハウスを有効にしない場合は、クエリの実行に同じウェアハウスが使用されます。

クエリウェアハウスのベストプラクティス¶

Streamlitアプリでクエリウェアハウスを選択するには、他のSnowflakeワークロードの場合と同じ一般的なガイドラインに従ってください。クエリの複雑さ、クエリされるデータのサイズ、およびウェアハウスのサイズを選択するときに予想される同時実行性を考慮します。

アプリがコンテナランタイムを使用している場合は、 QUERY_WAREHOUSE パラメーターを使用して Streamlitアプリを作成または変更するときにクエリウェアハウスを設定します。ただし、アプリがウェアハウスランタイムを使用する場合は、 QUERY_WAREHOUSE パラメーターを使用してコードウェアハウスを設定します。通常、アプリコードの実行にはより小さな専用ウェアハウスを使用し、アプリコード内で別のクエリウェアハウスに手動で切り替える必要があります。

例：コンテナランタイム

コンテナランタイムを使用する場合は、アプリの内部クエリを実行するのに十分な大きさのクエリウェアハウスを設定します。

CREATE STREAMLIT my_app
FROM '@my_stage/app_folder'
MAIN_FILE = 'streamlit_app.py'
RUNTIME_NAME = 'SYSTEM$ST_CONTAINER_RUNTIME_PY3_11'
COMPUTE_POOL = streamlit_compute_pool
QUERY_WAREHOUSE = my_large_warehouse
;

Copy

例：ウェアハウスランタイム

ウェアハウスランタイムを使用する場合は、Streamlitアプリ実行用の小さな専用コードウェアハウスを設定します。

CREATE STREAMLIT my_app
FROM '@my_stage/app_folder'
MAIN_FILE = 'streamlit_app.py'
QUERY_WAREHOUSE = my_small_warehouse;

Copy

アプリコード内で、クエリのために別のウェアハウスに切り替えます。

import streamlit as st

conn = st.connection("snowflake")
session = conn.session()
session.use_warehouse("my_large_warehouse")

Copy

コードウェアハウスのベストプラクティス¶

Streamlit in Snowflake でウェアハウスランタイムを使用する場合、アプリコードを実行するために可能な最小のウェアハウスを選択します。

ウェアハウスは、Streamlitアプリで使用されるPythonパッケージをキャッシュし、後続のアプリの読み込みのパフォーマンスを向上させます。キャッシュはウェアハウスが中断されると削除されるため、ウェアハウス再開後のアプリの初期読み込みが遅くなる可能性があります。再開されたウェアハウスでより多くのアプリが実行されると、パッケージキャッシュが再構築され、ロードパフォーマンスが向上します。

秒単位の請求と自動一時停止により、小規模なウェアハウスから始めて、必要に応じてサイズを調整する柔軟性が得られます。ウェアハウスのサイズはいつでも拡大できます。詳細については、 Streamlitアプリのウェアハウスを変更するをご参照ください。

Snowflakeでは、コストを分離し、他のワークロードを回避することで読み込み時間を改善するために、Streamlitアプリ専用のウェアハウスを使用することを推奨しています。アプリのコード内で、必要に応じてクエリ用に別のウェアハウスをアクティブ化します。

詳細については、ウェアハウスに関する考慮事項をご参照ください。

Tip

初期化中にウェアハウスの中断を避けるため、自動中断を少なくとも30秒に設定します。
Streamlitアプリのスリープ時間と WebSocket タイムアウトを構成してコストを削減します。詳細については、 Streamlitアプリのカスタムスリープタイマーをご参照ください。