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

コンピューティングプールは、SnowflakeがSnowpark Container Servicesのサービス（ジョブサービスを含む）を実行する1つ以上の仮想マシン（VM）ノードのコレクションです。CREATE COMPUTE POOL コマンドを使用して、コンピューティングプールを作成します。その後、サービスの作成時、またはジョブサービスの実行時に、コンピューティングプールを指定します。

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

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

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

コンピュートプールノードにプロビジョニングするマシンタイプ（インスタンスファミリー）。
コンピューティングプールで起動する最小ノード数
コンピューティングプールがスケールできる最大ノード数（Snowflakeがスケーリングを管理。）

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

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

コンピュートプールを作成するには、 Snowsight、または SQL を使用します。

Snowsight:

ナビゲーションメニューで Compute » Compute Pools を選択します。
ナビゲーションバーの一番下にあるユーザ名を選択し、 ACCOUNTADMIN ロール、またはコンピュートプールの作成が許可されているロールに切り替えます。
+ Compute Pool を選択します。
New compute pool UI で、必要な情報(コンピュートプール名、インスタンスファミリー、ノード制限)を指定します。
Create Compute Pool を選択します。

SQL:

CREATE COMPUTE POOL コマンドを実行します。

例えば、以下のコマンドで1ノードのコンピュートプールを作成します。

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

Copy

インスタンスファミリーは、コンピュートプールのコンピュータノードにプロビジョニングするマシンのタイプを識別子として指定します。コンピュートプール作成時のインスタンスファミリーの指定は、ウェアハウス作成時のウェアハウスサイズの指定（XSMALL, SMALL, MEDIUM, LARGE など）と似ています。次の表は、使用可能なマシンタイプの一覧です。また、 SHOW COMPUTE POOL INSTANCE FAMILIES コマンドを使用して、利用可能なインスタンスファミリーのリストを取得することもできます。

Available instance families (machine types) for compute pool nodes¶

INSTANCE_FAMILY（Snowflakeサービス利用表を参照）

vCPU

メモリ（GiB）

ストレージ（GB）

帯域制限（Gbps）

GPU

GPU あたりの GPU メモリ（GiB）

ノード制限

説明

CPU_X64_XS

1

6

100

最大12.5

なし

なし

150

Snowpark Containersで利用可能な最小インスタンス。コストの節約と使い始めに最適です。

CPU_X64_S

3

13

100

最大12.5

なし

なし

150

コストを節約しながら複数のサービス/ジョブをホストするのに最適です。

CPU_X64_M

6

28

100

最大12.5

なし

なし

150

フルスタックのアプリケーションや複数のサービスがある場合に最適です。

CPU_X64_SL (except China)

14

54

100

最大12.5

なし

なし

150

多数の CPUs、メモリ、ストレージを必要とするアプリケーションの場合。

CPU_X64_L

28

116

100

12.5

なし

なし

150

非常に多くの数の CPUs、メモリ、ストレージを必要とするアプリケーションの場合。

HIGHMEM_X64_S

6

58

100

AWS および GCP: 最大12.5、Azure:8

なし

なし

150

メモリ負荷の高いアプリケーションの場合。

HIGHMEM_X64_M

28

AWS:240、Azureおよび GCP:244

100

AWS:12.5、Azureおよび GCP:16

なし

なし

150

1台のマシンで複数のメモリ負荷の高いアプリケーションをホストする場合。

HIGHMEM_X64_SL (Azure and GCP, except GCP Dammam region)

92

654

100

32

なし

なし

20

大規模なインメモリデータを処理するために利用可能な最大のAzureまたは GCP ハイメモリマシン。

HIGHMEM_X64_L (AWS only)

124

984

100

50

なし

なし

150

大規模なインメモリデータを処理するために利用可能な最大の AWS ハイメモリマシン。

GPU_NV_S (AWS only, except Singapore, Switzerland North, Paris, and Osaka regions)

6

27

300（NVMe）

最大10

1 NVIDIA A10G

24

150

Snowpark Containersを始めるのに利用できる最小の NVIDIA GPU サイズ。

GPU_NV_M (AWS only, except gov regions, Singapore, Switzerland North, Paris, and Osaka regions)

44

178

3.4 TB （NVMe）

40

4 NVIDIA A10G

24

10

コンピュータービジョンや LLMs/VLMs などの負荷の高い GPU 使用シナリオに最適化。

GPU_NV_L (AWS only, available only in AWS US West and US East non-gov regions by request; limited availability might be possible in other regions upon request)

92

1112

6.8 TB （NVMe）

400

8 NVIDIA A100

40

要リクエスト

LLMs やクラスタリングなど、特殊で高度な GPU ケースのための最大の GPU インスタンス。

GPU_NV_XS （Azureのみ。スイス北部、UAE 北部、中部 US、UK 南部リージョンを除く）

3

26

100

8

1 NVIDIA T4

16

10

Snowpark Containersを始めるのに利用できる最小のAzure NVIDIA GPU サイズ。

GPU_NV_SM （Azureのみ。中部 US リージョンは除く）

32

424

100

40

1 NVIDIA A10

24

10

Snowpark Containersを始めるのに利用できる最小のAzure NVIDIA GPU サイズ。

GPU_NV_2M （Azureのみ。中部 US リージョンは除く）

68

858

100

80

2 NVIDIA A10

24

5

コンピュータービジョンや LLMs/VLMs などの負荷の高い GPU 使用シナリオに最適化。

GPU_NV_3M （Azureのみ。中部 US、北ヨーロッパ、UAE 北部リージョンは除く）

44

424

100

40

2 NVIDIA A100

80

要リクエスト

コンピュータービジョンや LLMs/VLMs などのメモリ負荷の高い GPU 使用シナリオに最適化。

GPU_NV_SL （Azureのみ。中部 US、北ヨーロッパ、UAE 北部リージョンは除く）

92

858

100

80

4 NVIDIA A100

80

要リクエスト

LLMs やクラスタリングなど、特殊で高度な GPU ケースのための最大の GPU インスタンス。

GPU_GCP_NV_L4_1_24G（Google Cloudのみ）

6

28

300

最大16まで

1 NVIDIA L4

24

10

Snowpark Containersを始めるのに利用できる最小の NVIDIA GPU サイズ。

GPU_GCP_NV_L4_4_24G（Google Cloudのみ）

44

178

1200

最大50

4 NVIDIA L4

24

10

コンピュータビジョンや LLMs などの GPU 使用シナリオ。

GPU_GCP_NV_A100_8_40G（Google Cloudのみ、 GCP US 中部1およびヨーロッパ西部4リージョンのみリクエストにより利用可能）

92

654

2500

最大100

8 NVIDIA A100

40

要リクエスト

コンピュータービジョンや LLMs/VLMs などのメモリ負荷の高い GPU 使用シナリオに最適化。

INSTANCE_FAMILY（Snowflakeサービス利用表を参照）	vCPU	メモリ（GiB）	ストレージ（GB）	帯域制限（Gbps）	GPU	GPU あたりの GPU メモリ（GiB）	ノード制限	説明
CPU_X64_XS	1	6	100	最大12.5	なし	なし	150	Snowpark Containersで利用可能な最小インスタンス。コストの節約と使い始めに最適です。
CPU_X64_S	3	13	100	最大12.5	なし	なし	150	コストを節約しながら複数のサービス/ジョブをホストするのに最適です。
CPU_X64_M	6	28	100	最大12.5	なし	なし	150	フルスタックのアプリケーションや複数のサービスがある場合に最適です。
CPU_X64_SL (except China)	14	54	100	最大12.5	なし	なし	150	多数の CPUs、メモリ、ストレージを必要とするアプリケーションの場合。
CPU_X64_L	28	116	100	12.5	なし	なし	150	非常に多くの数の CPUs、メモリ、ストレージを必要とするアプリケーションの場合。
HIGHMEM_X64_S	6	58	100	AWS および GCP: 最大12.5、Azure:8	なし	なし	150	メモリ負荷の高いアプリケーションの場合。
HIGHMEM_X64_M	28	AWS:240、Azureおよび GCP:244	100	AWS:12.5、Azureおよび GCP:16	なし	なし	150	1台のマシンで複数のメモリ負荷の高いアプリケーションをホストする場合。
HIGHMEM_X64_SL (Azure and GCP, except GCP Dammam region)	92	654	100	32	なし	なし	20	大規模なインメモリデータを処理するために利用可能な最大のAzureまたは GCP ハイメモリマシン。
HIGHMEM_X64_L (AWS only)	124	984	100	50	なし	なし	150	大規模なインメモリデータを処理するために利用可能な最大の AWS ハイメモリマシン。
GPU_NV_S (AWS only, except Singapore, Switzerland North, Paris, and Osaka regions)	6	27	300（NVMe）	最大10	1 NVIDIA A10G	24	150	Snowpark Containersを始めるのに利用できる最小の NVIDIA GPU サイズ。
GPU_NV_M (AWS only, except gov regions, Singapore, Switzerland North, Paris, and Osaka regions)	44	178	3.4 TB （NVMe）	40	4 NVIDIA A10G	24	10	コンピュータービジョンや LLMs/VLMs などの負荷の高い GPU 使用シナリオに最適化。
GPU_NV_L (AWS only, available only in AWS US West and US East non-gov regions by request; limited availability might be possible in other regions upon request)	92	1112	6.8 TB （NVMe）	400	8 NVIDIA A100	40	要リクエスト	LLMs やクラスタリングなど、特殊で高度な GPU ケースのための最大の GPU インスタンス。
GPU_NV_XS （Azureのみ。スイス北部、UAE 北部、中部 US、UK 南部リージョンを除く）	3	26	100	8	1 NVIDIA T4	16	10	Snowpark Containersを始めるのに利用できる最小のAzure NVIDIA GPU サイズ。
GPU_NV_SM （Azureのみ。中部 US リージョンは除く）	32	424	100	40	1 NVIDIA A10	24	10	Snowpark Containersを始めるのに利用できる最小のAzure NVIDIA GPU サイズ。
GPU_NV_2M （Azureのみ。中部 US リージョンは除く）	68	858	100	80	2 NVIDIA A10	24	5	コンピュータービジョンや LLMs/VLMs などの負荷の高い GPU 使用シナリオに最適化。
GPU_NV_3M （Azureのみ。中部 US、北ヨーロッパ、UAE 北部リージョンは除く）	44	424	100	40	2 NVIDIA A100	80	要リクエスト	コンピュータービジョンや LLMs/VLMs などのメモリ負荷の高い GPU 使用シナリオに最適化。
GPU_NV_SL （Azureのみ。中部 US、北ヨーロッパ、UAE 北部リージョンは除く）	92	858	100	80	4 NVIDIA A100	80	要リクエスト	LLMs やクラスタリングなど、特殊で高度な GPU ケースのための最大の GPU インスタンス。
GPU_GCP_NV_L4_1_24G（Google Cloudのみ）	6	28	300	最大16まで	1 NVIDIA L4	24	10	Snowpark Containersを始めるのに利用できる最小の NVIDIA GPU サイズ。
GPU_GCP_NV_L4_4_24G（Google Cloudのみ）	44	178	1200	最大50	4 NVIDIA L4	24	10	コンピュータビジョンや LLMs などの GPU 使用シナリオ。
GPU_GCP_NV_A100_8_40G（Google Cloudのみ、 GCP US 中部1およびヨーロッパ西部4リージョンのみリクエストにより利用可能）	92	654	2500	最大100	8 NVIDIA A100	40	要リクエスト	コンピュータービジョンや LLMs/VLMs などのメモリ負荷の高い GPU 使用シナリオに最適化。

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

コンピューティングプールノードの自動スケーリング¶

コンピューティングプールを作成すると、Snowflakeは最小数のノードを起動し、許可された最大数まで追加のノードを自動的に作成します。これは 自動スケーリング と呼ばれます。新しいノードは、稼働中のノードがさらなる作業負荷に耐えられない場合に割り当てられます。たとえば、2つのサービスインスタンスがコンピューティングプール内の2つのノードで実行されているとします。同じコンピューティングプール内で別のサービスを実行する場合には、追加のリソース要件によってSnowflakeが追加のノードを起動する可能性があります。

しかし、特定の期間、ノード上でサービスが実行されない場合、Snowflakeは自動的にノードを削除し、削除後もコンピューティングプールが必要最小限のノードを維持するようにします。

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

コンピュートプールの管理には、 Snowsight、または SQL を使用します。

Snowsight では、コンピュートプール名の隣にあるmoreオプション(...)を選択し、メニューから必要な演算子を選択します。このセクションでは、コンピュートプールを管理するために使用できる SQL コマンドについて説明します。

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 = <value>
propertiesToAlter := { MIN_NODES | MAX_NODES | AUTO_RESUME | AUTO_SUSPEND_SECS | COMMENT }
```
Copy
MAX_NODES を減らす場合は、以下の潜在的な影響に注意してください。
- Snowflakeでは、1つまたは複数のサービスインスタンスを終了し、コンピューティングプール内の他の利用可能なノード上でそれらを再起動することが必要になる場合があります。MAX_NODES の設定が小さすぎると、Snowflakeは特定のサービスインスタンスをスケジュールできない場合があります。
- 終了したノードがジョブサービスの実行中だった場合、ジョブの実行は失敗します。Snowflakeでジョブサービスは再開されません。
  
  例:
  ALTER COMPUTE POOL my_pool 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カ月間アクティブになります。

メンテナンス・ウィンドウ¶

通常、定期メンテナンスは毎週土曜日の PM8時から日曜日 AM8時まで、および毎週日曜日 PM8時から月曜日AM8時まで行われます。:ref:`早期アクセスアカウント <label-releases_early_access_to_full_releases>`の場合、メンテナンスは毎日PM11時から行われ、最大6時間継続する可能性があります。

サービスの中断¶

メンテナンス中、Snowflakeは古いコンピュートプールノードで稼働しているサービスインスタンスを新しいノード上に自動的に再作成します。Snowflakeはサービスインスタンスの再作成にローリングメソッドを使用します。

サービスにインスタンスが1つしかない場合、Snowflakeがインスタンスを再作成している間にサービスの中断が発生します。
複数のインスタンスを持つサービスの場合、Snowflakeはアップグレードされたノード上でサービスインスタンスをインクリメンタルに再作成します。一度に交換されるサービス・インスタンスは50%以下です。この場合、リクエストされた MIN_INSTANCES よりも可用性が低くなる可能性があることに注意してください。可用性インスタンスが MIN_READY_INSTANCES より少なくなると、 READY の状態から PENDING の状態に移行し、サービスが中断します。したがって、サービスの中断を避けるために、 MIN_READY_INSTANCES を MIN_INSTANCES の50%未満にセットすることを検討してください。

継続中のジョブサービスは中断されるため、メンテナンス終了後にお客様ご自身で再開していただく必要があります。

注意

メンテナンスウィンドウまたは重要なアップデート中のサービス中断は、 Snowflakeのサポートポリシーおよびサービスレベル契約に規定されるサービスレベルの対象外です。

ダウンタイムを最小限に抑えるベストプラクティス¶

複数のサービス・インスタンスを実行します： 複数のインスタンスを持つことで、メンテナンス時のサービスの中断を最小限に抑え、高い可用性を確保します。
アプリケーションの状態を永続ストレージに格納します： ブロックストレージ、Snowflakeステージ、Snowflakeテーブルなどの永続ストレージにデータとステートフルオブジェクトを格納します。
SIGTERM シグナルをキャッチします： サービスインスタンスを終了する際、Snowflakeはまず各サービスコンテナーに SIGTERM シグナルを送信します（サービスの終了を参照）。シグナル処理の一環として、コンテナーコードは、サービスインスタンスがシャットダウンまたは再起動される前に、サービスの状態を保存することができます。
メンテナンス中にデグレード状態で実行する高可用性サービスを設計します： メンテナンス中も可用性を維持するには、50%のインスタンスしかない状態でもサービスを実行できる耐性が必要です。
準備完了プローブを提供します： 準備完了プローブを提供しない場合、Snowflakeはコードの実行開始と同時にサービスインスタンスの準備が完了したとみなします。通常、コンテナーが初期化を完了し、リクエストを処理できるようになるまでには時間がかかります。サービスインスタンスがリクエストを処理する準備ができたことを明示的にSnowflakeに伝えるために、サービス構成で準備プローブを提供する必要があります。
メンテナンススケジュールを監視します： メンテナンスウィンドウの間に重要なタスクをスケジュールしないようにします。
メンテナンスウィンドウ中にジョブサービスを実行するスケジュールは避けてください： Snowflakeは、メンテナンスウィンドウ中に実行中のジョブをキャンセルする可能性があります。
定期的なバックアップまたはチェックポイントの実行： 永続ストレージ（ブロックストレージ、Snowflakeステージ、またはSnowflakeテーブルを含む）上のアプリケーションの状態を定期的にバックアップまたはチェックポイントします。

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

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

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

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

注釈

Snowflakeは、アプリケーションコンテナーが使用するステージマウントをサポートしています。Snowflake内部ステージは、サポートされるストレージ・ボリューム・タイプの1つです。

最適なパフォーマンスを実現するため、Snowflakeでは、同じサービスインスタンス、同じサービス、または異なるサービスに属するボリュームに関係なく、コンピューティングプールノードごとにステージボリュームマウントの合計数を8つに制限するようになりました。

ノードの上限に達すると、Snowflakeはそのノードを使用して、ステージボリュームを使用する新しいサービスインスタンスを開始しません。コンピューティングプール内のすべてのノードで上限に達した場合、Snowflakeはサービスインスタンスを起動できなくなります。このシナリオでは、 SHOW SERVICE CONTAINERS IN SERVICE コマンドを実行すると、Snowflake は「Unschedulable due to insufficient resources」というメッセージとともに PENDING ステータスを返します。

ノードのこのステージマウント割り当て制限に対応するために、場合によっては、コンピューティングプールにリクエストするノードの最大数を増やすことができます。そうすると、Snowflakeはサービスインスタンスを開始するための追加ノードを確実に利用できるようになります。

System compute pools¶

Snowflake automatically provisions two compute pools in each Snowflake account. These compute pools are provided exclusively for the following Snowflake workloads.

Notebooks
Model serving
ML jobs

By using system compute pools, users can run these workload without needing an account administrator to configure a compute pool first.

The system compute pools have the following default configuration:

Compute pool name: SYSTEM_COMPUTE_POOL_GPU
- インスタンスファミリー: Snowflakeアカウントが AWS またはMicrosoft Azureリージョンのどちらにあるかによって、Snowflakeはこのコンピューティングプールに次の GPU インスタンスファミリーを使用します。
  - Azureでは、 GPU_NV_SM です。
  - AWS では、 GPU_NV_S です。
  なお、以下のリージョンは SYSTEM_COMPUTE_POOL_GPU をサポートしていません。
  - AWS: シンガポール、スイス北部、パリ、大阪。
  - Azure: US 中部。
  - Google Cloud: GPU コンピューティングプールは利用できません。
- デフォルト構成：
  - MIN_NODES=1
  - MAX_NODES=50
  - INITIALLY_SUSPENDED=true
  - AUTO_SUSPEND_SECS=600
Compute pool name: SYSTEM_COMPUTE_POOL_CPU
- インスタンスファミリー: CPU_X64_S
- デフォルト構成：
  - MIN_NODES=1
  - MAX_NODES=150
  - INITIALLY_SUSPENDED=true
  - AUTO_SUSPEND_SECS=600

Note that,

Compute pools are initially in a suspended state and only begin incurring costs when a supported Snowflake workload starts using them.
If no workloads are running, these compute pools are automatically suspended after 10 minutes. To modify the auto-suspension policy for default compute pools, use the ALTER COMPUTE POOL SET AUTO_SUSPEND_SECS command.

Managing the system compute pools¶

In a Snowflake account, the ACCOUNTADMIN role owns these system compute pools. Administrators have full control over the compute pools, including modifying their properties, suspending operations, and monitoring consumption. The ACCOUNTADMIN role can delete the compute pool. For example:

USE ROLE ACCOUNTADMIN;
ALTER COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU STOP ALL;
DROP COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU;

Copy

By default, the USAGE permission on system compute pools is granted to the PUBLIC role, allowing all roles in the account to use them. However, the ACCOUNTADMIN can modify these privileges to restrict access if necessary.

To restrict access to system compute pools to specific roles in your account, use the ACCOUNTADMIN role to revoke the USAGE permission from the PUBLIC role and grant it to the desired role(s). For example:

USE ROLE ACCOUNTADMIN;
REVOKE USAGE ON COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU FROM ROLE PUBLIC;
GRANT USAGE ON COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU TO ROLE <role-name>;

Copy

System compute pools can be associated with budgets. for cost management.

Notebooks用の好みのコンピューティングプールの構成¶

By default, Notebook services run in system compute pools. If you don't want to use the Snowflake-provisioned compute pools, you have the option to choose other compute pools in your account for Notebooks. To override the Snowflake-provisioned compute pools you can set these parameters (DEFAULT_NOTEBOOK_COMPUTE_POOL_CPU and DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU). Note that, this will change your Snowsight experience. When creating a Notebook in Snowsight, the compute pool you configure using these parameters appears as the first preference in the UI. The following example commands set these parameters:

GPU ランタイムを使用するNotebooksで優先されるアカウントレベルのコンピューティングプールとして my_pool を構成します。
```
ALTER ACCOUNT SET DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU='my_pool';
```
Copy
my_pool を、データベース my_db で作成されたNotebooksで優先されるコンピューティングプールとして構成します。
```
ALTER DATABASE my_db SET DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU='my_pool';
```
Copy
my_pool を、スキーマ my_db.my_schema で作成されたNotebooksで優先されるコンピューティングプールとして構成します。
ALTER SCHEMA my_db.my_schema SET DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU='my_pool';
Copy

Notebooksを実行するためにアカウントに構成されている現在の GPU コンピューティングプールの優先順位を確認するには、以下のコマンドを使用します。

SHOW PARAMETERS LIKE 'DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU' IN ACCOUNT;

SHOW PARAMETERS LIKE 'DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU' IN DATABASE my_db;

SHOW PARAMETERS LIKE 'DEFAULT_NOTEBOOK_COMPUTE_POOL_GPU' IN SCHEMA my_db.my_schema;

Copy

詳細については、 SHOW PARAMETERS をご参照ください。

ガイドラインと制約¶

CREATE COMPUTE POOL 権限: 現在のロールでコンピューティングプールを作成できない場合は、アカウント管理者に相談して権限を付与します。例:
```
GRANT CREATE COMPUTE POOL ON ACCOUNT TO ROLE <role_name> [WITH GRANT OPTION];
```
Copy
詳細については、 GRANT <権限> ... TO ROLE をご参照ください。
コンピューティングプールノードのアカウントごとの制限。
- アカウントに作成できる最大ノード数は（コンピューティングプールの数に関係なく）500です。
- コンピューティングプールあたりの最大ノード数は50です。
さらに、各インスタンスファミリーで許可されるノード数には制限があります（インスタンスファミリーテーブルの ノード制限 列を参照してください）。Requested number of nodes <#> exceeds the node limit for the account のようなエラーメッセージが表示された場合は、この制限に遭遇しています。詳細情報については、アカウント担当者にご連絡ください。