Snowpark Container Services: コンピューティングプールの操作¶
コンピューティングプールは、SnowflakeがSnowpark Container Servicesのサービス(ジョブサービスを含む)を実行する1つ以上の仮想マシン(VM)ノードのコレクションです。 CREATE COMPUTE POOL コマンドを使用して、コンピューティングプールを作成します。その後、 サービスの作成 時、または ジョブサービスの実行 時に、コンピューティングプールを指定します。
コンピューティングプールの作成¶
コンピューティングプールは、アカウントレベルのコンストラクトであり、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, Snowflake Service Consumption Table Mapping
vCPU
メモリ(GiB)
ストレージ(GiB)
帯域制限(Gbps)
GPU
GPU あたりの GPU メモリ(GiB)
ノード制限
説明
CPU_X64_XS 、 . CPU | XS
1
6
100
最大12.5
なし
なし
50
Snowpark Containersで利用可能な最小インスタンス。コストの節約と使い始めに最適です。
CPU_X64_S、 . CPU | S
3
13
100
最大12.5
なし
なし
50
コストを節約しながら複数のサービス/ジョブをホストするのに最適です。
CPU_X64_M, . CPU | M
6
28
100
最大12.5
なし
なし
50
フルスタックのアプリケーションや複数のサービスがある場合に最適です。
CPU_X64_L、 . CPU | L
28
116
100
12.5
なし
なし
50
非常に多くの数の CPUs、メモリ、ストレージを必要とするアプリケーションの場合。
HIGHMEM_X64_S, . High-Memory CPU | S
6
58
100
AWS: 最大12.5, Azure: 8
なし
なし
50
メモリ負荷の高いアプリケーションの場合。
HIGHMEM_X64_M、 . ハイメモリ CPU | M . (AWS のみ)
28
240
100
12.5
なし
なし
50
1台のマシンで複数のメモリ負荷の高いアプリケーションをホストする場合。
HIGHMEM_X64_M、 . ハイメモリ CPU | M . (Azureのみ)
28
244
100
16
なし
なし
50
1台のマシンで複数のメモリ負荷の高いアプリケーションをホストする場合。
HIGHMEM_X64_L, . High-Memory CPU | L . (AWS のみ)
124
984
100
50
なし
なし
20
大規模なインメモリデータを処理するために利用可能な最大の AWS ハイメモリマシン。
HIGHMEM_X64_L, . High-Memory CPU | L . (Azureのみ)
92
654
100
32
なし
なし
20
大規模なインメモリデータを処理するために利用可能な最大のAzureハイメモリマシン。
GPU_NV_S, . GPU | S . (AWS のみ)
6
27
100
最大10
1 NVIDIA A10G
24
10
Snowpark Containersを始めるのに利用できる最小の NVIDIA GPU サイズ。
GPU_NV_M, . GPU | M . (AWS のみ)
44
178
100
40
4 NVIDIA A10G
24
10
コンピュータービジョンや LLMs/VLMs などの負荷の高い GPU 使用シナリオに最適化。
GPU_NV_L, . GPU | L . (AWS のみ)
92
1112
100
400
8 NVIDIA A100
40
要リクエスト
LLMs やクラスタリングなど、特殊で高度な GPU ケースのための最大の GPU インスタンス。
GPU_NV_XS, . GPU | XS . (Azureのみ)
3
26
100
8
1 NVIDIA T4
16
10
Snowpark Containersを始めるのに利用できる最小のAzure NVIDIA GPU サイズ。
GPU_NV_SM, . GPU | SM . (Azureのみ)
32
424
100
40
1 NVIDIA A10
24
10
Snowpark Containersを始めるのに利用できる最小のAzure NVIDIA GPU サイズ。
GPU_NV_2M, . GPU | 2M . (Azureのみ)
68
858
100
80
2 NVIDIA A10
24
5
コンピュータービジョンや LLMs/VLMs などの負荷の高い GPU 使用シナリオに最適化。
GPU_NV_3M, . GPU | 3M . (Azureのみ)
44
424
100
40
2 NVIDIA A100
80
要リクエスト
コンピュータービジョンや LLMs/VLMs などのメモリ負荷の高い GPU 使用シナリオに最適化。
GPU_NV_SL, . GPU | SL . (Azureのみ)
92
858
100
80
4 NVIDIA A100
80
要リクエスト
LLMs やクラスタリングなど、特殊で高度な GPU ケースのための最大の GPU インスタンス。
利用可能なインスタンスファミリーについては、 CREATE COMPUTE POOL をご参照ください。
コンピューティングプールノードの自動スケーリング¶
コンピューティングプールを作成すると、Snowflakeは最小数のノードを起動し、許可された最大数まで追加のノードを自動的に作成します。これは 自動スケーリング と呼ばれます。新しいノードは、稼働中のノードがさらなる作業負荷に耐えられない場合に割り当てられます。たとえば、2つのサービスインスタンスがコンピューティングプール内の2つのノードで実行されているとします。同じコンピューティングプール内で別のサービスを実行する場合には、追加のリソース要件によってSnowflakeが追加のノードを起動する可能性があります。
しかし、特定の期間、ノード上でサービスが実行されない場合、Snowflakeは自動的にノードを削除し、削除後もコンピューティングプールが必要最小限のノードを維持するようにします。
コンピューティングプールの管理¶
Snowpark Container Servicesは、コンピューティングプールを管理するために以下のコマンドを提供します。
モニタリング: コンピューティングプールの情報を得るには、 SHOW COMPUTE POOLS コマンドを使用します。
操作: コンピューティングプールの状態を変更するには、 ALTER COMPUTE POOL コマンドを使用します。
ALTER COMPUTE POOL <name> { SUSPEND | RESUME | STOP ALL }
コンピューティングプールを一時停止すると、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 }
MAX_NODES を減らす場合は、以下の潜在的な影響に注意してください。
Snowflakeでは、1つまたは複数のサービスインスタンスを終了し、コンピューティングプール内の他の利用可能なノード上でそれらを再起動することが必要になる場合があります。MAX_NODES の設定が小さすぎると、Snowflakeは特定のサービスインスタンスをスケジュールできない場合があります。
終了したノードがジョブサービスの実行中だった場合、ジョブの実行は失敗します。Snowflakeでジョブサービスは再開されません。
例:
ALTER COMPUTE POOL MYPOOL SET MIN_NODES = 2 MAX_NODES = 2;
削除: コンピューティングプールを削除するには、 DROP COMPUTE POOL コマンドを使用します。
例:
DROP COMPUTE POOL <name>
コンピューティングプールをドロップする前に、実行中のサービスをすべて停止する必要があります。
**コンピューティングプールのリストとプロパティの表示
コンピューティングプールのライフサイクル¶
コンピューティングプールは、以下のいずれの状態にもなり得ます。
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カ月間アクティブになります。
メンテナンス・ウィンドウ¶
定期メンテナンスは、毎週月曜日から木曜日、11 PM から 5 AM (展開地域の現地時間)まで、予想されるウィンドウは6時間です。
サービスの中断¶
メンテナンス中、影響を受けるコンピューティングプール内のすべてのサービスインスタンスは、新しいノード上に自動的に再作成されます。継続中のジョブ・サービスは中断されるため、メンテナンスが完了次第、お客様ご自身で再開していただく必要があります。
注意
メンテナンスウィンドウまたは重要なアップデート中のサービス中断は、 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はサービスインスタンスを開始するための追加ノードを確実に利用できるようになります。
ガイドラインと制約¶
CREATE COMPUTE POOL 権限: 現在のロールでコンピューティングプールを作成できない場合は、アカウント管理者に相談して権限を付与します。例:
GRANT CREATE COMPUTE POOL ON ACCOUNT TO ROLE <role_name> [WITH GRANT OPTION];
詳細については、 GRANT <権限> をご参照ください。
コンピューティングプールノードのアカウントごとの制限。アカウントに作成できるノードの数は(コンピューティングプールの数に関係なく)120に制限されています。さらに、各インスタンス・ファミリに許可されるノード数には制限があります(インスタンス・ファミリ・テーブル の Node limit 列をご参照ください)。
Requested number of nodes <#> exceeds the node limit for the account
のようなエラーメッセージが表示された場合は、この制限に遭遇しています。詳細については、アカウントの担当にお問い合わせください。