Snowpark Container Services: コンピューティングプールの操作¶

コンピューティングプールの作成¶

コンピューティングプールは、アカウントレベルのコンストラクトであり、Snowflakeの仮想ウェアハウスと類似しています。コンピューティングプールの命名スコープは、ご使用のアカウントです。つまり、アカウント内に同じ名前のコンピューティングプールを複数持つことはできません。

コンピューティングプールの作成に必要な最低限の情報は以下のとおりです。

• コンピューティングプールノードにプロビジョニングするマシンタイプ

• コンピューティングプールで起動する最小ノード数

• コンピューティングプールがスケールできる最大ノード数（Snowflakeがスケーリングを管理。）

コンピューティングプール内で実行予定のサービスに大きな負荷がかかったり、突然アクティビティが活発になったりすることが予想される場合は、最小ノード数を1より大きく設定することができます。このアプローチでは、自動スケーリングの開始を待つ代わりに、必要なときに追加のノードをすぐに利用できるようにします。

ノードの上限を設定すると、Snowflakeの自動スケーリングによって予期せぬ数のノードがコンピューティングプールに追加されることを防ぎます。これは、予期しない負荷の急増や、Snowflakeが当初の計画よりも多くのコンピューティングプールノードを割り当てる原因となるようなコード内の問題などのシナリオにおいて、非常に重要になる可能性があります。

次の CREATE COMPUTE POOL コマンドは、1ノードのコンピューティングプールを作成します。

CREATE COMPUTE POOL tutorial_compute_pool
  MIN_NODES = 1
  MAX_NODES = 1
  INSTANCE_FAMILY = CPU_X64_XS;

INSTANCE_FAMILY は、コンピューティングプールのコンピューターノードにプロビジョニングするマシンタイプを特定します。コンピューティングプールを作成する際に INSTANCE_FAMILY を指定することは、ウェアハウスを作成する際にウェアハウスのサイズ（XSMALL、 SMALL、 MEDIUM、 LARGE など）を指定することに類似しています。次のテーブルは、使用可能なマシンタイプのリストです。

消費テーブル マッピング	INSTANCE_FAMILY	vCPU	メモリ（GiB）	ストレージ（GiB）	GPU	GPU あたりの GPU メモリ（GiB）	最大Limit	説明
CPU | XS	CPU_X64_XS	2	8	250	なし	なし	50	Snowpark Containersで利用可能な最小インスタンス。コストの節約と使い始めに最適です。
CPU | S	CPU_X64_S	4	16	250	なし	なし	50	コストを節約しながら複数のサービス/ジョブをホストするのに最適です。
CPU | M	CPU_X64_M	8	32	250	なし	なし	20	フルスタックのアプリケーションや複数のサービスがある場合に最適です。
CPU | L	CPU_X64_L	32	128	250	なし	なし	20	非常に多くの数の CPUs、メモリ、ストレージを必要とするアプリケーションの場合。
ハイメモリ CPU | S	HIGHMEM_X64_S	8	64	250	なし	なし	20	メモリ負荷の高いアプリケーションの場合。
ハイメモリ CPU | M	HIGHMEM_X64_M	32	256	250	なし	なし	20	1台のマシンで複数のメモリ負荷の高いアプリケーションをホストする場合。
ハイメモリ CPU | L	HIGHMEM_X64_L	128	1024	250	なし	なし	20	大規模なインメモリデータを処理するために利用可能な最大のハイメモリマシン。
GPU | S	GPU_NV_S	8	32	250	1 NVIDIA A10G	24	10	Snowpark Containersを始めるのに利用できる最小の NVIDIA GPU サイズ。
GPU | M	GPU_NV_M	48	192	250	4 NVIDIA A10G	24	5	コンピュータービジョンや LLMs/VLMs などの負荷の高い GPU 使用シナリオに最適化。
GPU | L	GPU_NV_L	96	1152	250	8 NVIDIA A100	40	要リクエスト	LLMs やクラスタリングなど、特殊で高度な GPU ケースのための最大の GPU インスタンス。

利用可能なインスタンスファミリーについては、 CREATE COMPUTE POOL をご参照ください。

コンピューティングプールの管理¶

Snowpark Container Servicesは、コンピューティングプールを管理するために以下のコマンドを提供します。

• モニタリング: コンピューティングプールの情報を得るには、 SHOW COMPUTE POOLS コマンドを使用します。

• 操作: コンピューティングプールの状態を変更するには、 ALTER COMPUTE POOL コマンドを使用します。

  ALTER COMPUTE POOL <name> { SUSPEND | RESUME | STOP ALL }
  

  Copy

  コンピューティングプールを中断すると、Snowflakeはすべてのサービスを中断しますが、ジョブは終了状態（DONE または FAILED）になるまで実行され続け、その後コンピューティングプールノードは解放されます。

  中断されたコンピューティングプールは、新しいサービスやジョブを開始する前に再開する必要があります。コンピューティングプールが自動再開するように設定されている場合（AUTO_RESUME プロパティが TRUE に設定されている場合）、Snowflakeは、サービスまたはジョブがプールに提出されると、自動的にプールを再開します。それ以外の場合は、 ALTER COMPUTE POOL コマンドを実行して、コンピューティングプールを手動で再開する必要があります。

• 変更: コンピューティングプールのプロパティを変更するには、 ALTER COMPUTE POOL コマンドを使用します。

  ALTER COMPUTE POOL <name> SET propertiesToAlter
  propertiesToAlter := { MIN_NODES | MAX_NODES | AUTO_RESUME | AUTO_SUSPEND_SECS | COMMENT }
  

  Copy

  MAX_NODES を減らす場合は、以下の潜在的な影響に注意してください。

  • Snowflakeでは、1つまたは複数のサービスインスタンスを終了し、コンピューティングプール内の他の利用可能なノード上でそれらを再鼓動することが必要になる場合があります。MAX_NODES の設定が小さすぎると、Snowflakeは特定のサービスインスタンスをスケジュールできない場合があります。

  • 終了したノードがジョブの実行中だった場合、ジョブの実行は失敗します。Snowflakeはジョブを再開しません。

    例：

    ALTER COMPUTE POOL MYPOOL SET MIN_NODES = 2  MAX_NODES = 2;
    

    Copy

• 削除: コンピューティングプールを削除するには、 DROP COMPUTE POOL コマンドを使用します。

  例：

  DROP COMPUTE POOL <name>
  

  Copy

  コンピューティングプールをドロップする前に、実行中のサービスをすべて停止する必要があります。

• コンピューティングプールのリストとプロパティの表示: SHOW COMPUTE POOLS と DESCRIBE COMPUTE POOL コマンドを使用します。例については、 コンピューティングプールを表示する をご参照ください。

コンピューティングプールのライフサイクル¶

コンピューティングプールは、以下のいずれの状態にもなり得ます。

• IDLE: コンピューティングプールには必要な数の仮想マシン（VM）ノードがありますが、サービスやジョブはスケジュールされていません。この状態では、アクティビティがないため、自動スケーリングによってコンピューティングプールを最小サイズまで縮小することができます。

• ACTIVE: コンピューティングプールでは、少なくとも1つのサービスが実行中か、実行するようにスケジュールされています。プールは、負荷やユーザーの操作に応じて（最大ノードまで）拡大したり（最小ノードまで）縮小したりすることができます。

• SUSPENDED: プールには現在実行中の仮想マシンノードが含まれていません。しかし、 AUTO_RESUME コンピューティングプールプロパティが TRUE に設定されている場合は、サービスまたはジョブがスケジュールされると、プールは自動的に再開します。

以下の状態は一時的です。

• STARTING: コンピューティングプールを作成または再開すると、少なくとも1つのノードがプロビジョニングされるまで、コンピューティングプールは STARTING 状態になります。

• STOPPING: コンピューティングプールを中断する（ALTER COMPUTE POOLを使用）と、Snowflakeがコンピューティングプール内のすべてのノードを解放するまで、コンピューティングプールは STOPPING 状態になります。コンピューティングプールを中断すると、Snowflakeはすべてのサービスを中断しますが、ジョブは終了状態（DONE または FAILED）になるまで実行され続け、その後コンピューティングプールノードは解放されます。

• RESIZING: コンピューティングプールを作成すると、最初は STARTING の状態になります。ノードが1つプロビジョニングされると、最小数のノード（CREATE COMPUTE POOL で指定）がプロビジョニングされるまで、 RESIZING 状態になります。コンピューティングプール（ALTER COMPUTE POOL）を変更し、ノードの最小値と最大値を更新すると、最小ノードがプロビジョニングされるまで、プールは RESIZING 状態になります。コンピューティングプールの自動スケーリングにより、コンピューティングプールも RESIZING 状態になることに注意してください。

コンピューティングプール権限¶

コンピューティングプールを使用する場合、以下の権限モデルが適用されます。

• アカウントにコンピューティングプールを作成するには、アカウントに対する CREATE COMPUTE POOL権限が現在のロールに必要です。プールを作成すると、所有者として OWNERSHIP 権限が付与され、そのコンピューティングプールを包括的に制御できるようになります。あるコンピューティングプールの OWNERSHIP があっても、他のコンピューティングプールの権限があるとは限りません。

• コンピューティングプール管理のために、以下の権限（機能）がサポートされています。

  権限	使用状況
  MODIFY	サイズの変更を含む、コンピューティングプールのプロパティを変更できるようにします。
  MONITOR	コンピューティングプールのプロパティの説明を含む、コンピューティングプールの使用状況を表示できるようにします。
  OPERATE	コンピューティングプールの状態（中断、再開）を変更できるようにします。さらに、スケジュールされたサービスやジョブを停止できるようにします。
  USAGE	コンピューティングプールにサービスとジョブを作成できるようにします。コンピューティングプールが中断状態にあり、 AUTO_RESUME プロパティがtrueに設定されている場合、コンピューティングプールの USAGE 権限を持つロールは、 OPERATE 権限がなくても、サービスを開始したり再開したりする際に、暗黙的にコンピューティングプールの再開をトリガーすることができます。
  OWNERSHIP	コンピューティングプールに対する包括的な制御を付与します。特定のオブジェクトに対して一度にこの権限を保持できるのは、1つのロールのみです。
  ALL [ PRIVILEGES ]	OWNERSHIP を除く、コンピューティングプールに対するすべての権限を付与します。

コンピューティングプールのメンテナンス¶

定期的な内部インフラストラクチャメンテナンスの一環として、Snowflakeは古いコンピューティングプールの更新を実施します。このプロセスには、オペレーティングシステムのアップグレード、ドライブの強化、コンピューティングプールノードに存在するセキュリティ脆弱性の解決などの重要なタスクが含まれます。

これらのメンテナンス手順の間、コンピューティングプールのノードはオフラインになり、定期的（数週間ごと）に更新されたノードと置き換えられます。コンピューティングプールノードは最大1か月間アクティブであり、その後Snowflakeはノードを引退させ、新しく更新されたノードと置き換えます。このような場合、

• これらのコンピューティングプールで現在実行しているすべてのサービスインスタンスは、新しいノード上に自動で再作成されます。

• 進行中のジョブはすべて中断され、コンピューティングプールが再稼働した後、お客様により再開される必要があります。

予想されるメンテナンスウィンドウはおよそ30分間です。

これらの内部インフラストラクチャの更新は、毎週火曜日、水曜日、木曜日、金曜日の午前8時から午後1時（現地時間）の間に行われる。

コンピューティングプールでのサービスのスケジューリング方法¶

サービスの作成 時に、受信する負荷を管理するために複数のインスタンスを実行することを選択することもできます。Snowflakeは、コンピューティングプールノードでサービスインスタンスをスケジューリングする際に、以下の一般的なガイドラインを使用します。

• サービスインスタンス内のすべてのコンテナーは、常に単一のコンピューティングプールノード上で実行されます。つまり、サービスインスタンスが複数のノードにまたがることはありません。

• 複数のサービスインスタンスを実行する場合、Snowflakeは、これらのサービスインスタンスを同じノードまたはコンピューティングプール内の異なるノードで実行する可能性があります。この決定をする場合、Snowflakeは、サービス仕様ファイル（containers.resources フィールド を参照）に概説されているように、指定されたハードリソース要件（メモリや GPU など）を考慮します。

  たとえば、コンピューティングプールの各ノードが8 GB のメモリを提供しているとします。サービス仕様に6 GB のメモリ要件が含まれており、サービスの作成時に2つのインスタンスを実行することを選択した場合、Snowflakeは同じノード上で両方のインスタンスを実行することはできません。この場合、Snowflakeは各インスタンスをコンピューティングプール内の別のノードにスケジューリングし、メモリ要件を満たします。

ガイドラインと制約¶

• CREATE COMPUTE POOL 権限: 現在のロールでコンピューティングプールを作成できない場合は、 ACCOUNTADMIN ロールを使用して権限を付与します。例:

  GRANT CREATE COMPUTE POOL ON ACCOUNT TO ROLE <role_name> [WITH GRANT OPTION];
  

  Copy

  詳細については、 GRANT <権限> をご参照ください。

• コンピューティングプールノードのアカウントごとの制限。任意のインスタンスファミリー（CREATE COMPUTE POOL を参照）では、アカウントごとに、いつでもアクティブにできるノードの総数に制限があります。 Requested number of nodes <#> exceeds the node limit for the account のようなエラーメッセージが表示された場合は、この制限に遭遇しています。詳細については、アカウントの担当にお問い合わせください。