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

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

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

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

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

  • コンピュートプールノードにプロビジョニングするマシンタイプ(インスタンスファミリー)。

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

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

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

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

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

Snowsight:
  1. Admin » Compute pools を選択します。

  2. ナビゲーションバーの一番下にあるユーザ名を選択し、 ACCOUNTADMIN ロール、またはコンピュートプールの作成が許可されているロールに切り替えます。

  3. + Compute Pool を選択します。

  4. New compute pool UI で、必要な情報(コンピュートプール名、インスタンスファミリー、ノード制限)を指定します。

  5. 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 など)と似ています。次のテーブルは、使用可能なマシンタイプのリストです。

INSTANCE_FAMILY, Snowflake Service Consumption Table Mapping

vCPU

メモリ(GiB)

ストレージ(GB)

帯域制限(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_SL、 . ハイメモリ CPU | L . (Azureのみ)

92

654

100

32

なし

なし

20

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

GPU_NV_S、 . GPU | S . (AWS のみ。パリと大阪リージョンは除く)

6

27

300(NVMe)

最大10

1 NVIDIA A10G

24

10

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

GPU_NV_M、 . GPU | M . (AWS のみ。パリと大阪リージョンは除く)

44

178

3.4 TB (NVMe)

40

4 NVIDIA A10G

24

10

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

GPU_NV_L、 . GPU | L . (AWS のみ。リクエストにより AWS US 西部および US 東部リージョンのみで利用可能。リクエストにより他のリージョンでも可用性が限定される場合あり)

92

1112

6.8 TB (NVMe)

400

8 NVIDIA A100

40

要リクエスト

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

GPU_NV_XS、 . GPU | XS . (Azureのみ。スイス北部および UAE 北部リージョンは除く)

3

26

100

8

1 NVIDIA T4

16

10

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

GPU_NV_SM、 . GPU | SM . (Azureのみ。中央 US リージョンは除く)

32

424

100

40

1 NVIDIA A10

24

10

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

GPU_NV_2M、 . GPU | 2M . (Azureのみ。中央 US リージョンは除く)

68

858

100

80

2 NVIDIA A10

24

5

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

GPU_NV_3M、 . GPU | 3M . (Azureのみ。北ヨーロッパおよび UAE 北部リージョンは除く)

44

424

100

40

2 NVIDIA A100

80

要リクエスト

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

GPU_NV_SL、 . GPU | SL . (Azureのみ。北ヨーロッパおよび UAE 北部リージョンは除く)

92

858

100

80

4 NVIDIA A100

80

要リクエスト

LLMs やクラスタリングなど、特殊で高度な GPU ケースのための最大の 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 MYPOOL SET MIN_NODES = 2  MAX_NODES = 2;
      
      Copy
  • 削除: コンピューティングプールを削除するには、 DROP COMPUTE POOL コマンドを使用します。

    例:

    DROP COMPUTE POOL <name>
    
    Copy

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

  • **コンピューティングプールのリストとプロパティの表示

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

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

  • 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はサービスインスタンスの再作成にローリングメソッドを使用します。

  • サービスにインスタンスが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はサービスインスタンスを開始するための追加ノードを確実に利用できるようになります。

Notebooksのデフォルトのコンピュートプール

リリース8.46以降、Notebooksアプリを実行するために、Snowflakeは各Snowflakeアカウント(トライアルアカウントを除く)に2つのコンピュートプールを自動的に用意します。これらのコンピュートプールはNotebooksの実行専用であり、Snowpark Container Servicesサービスの作成には使用できません。

  • コンピュートプール名(Snowsight UI): SYSTEM_COMPUTE_POOL_GPU

  • コンピュートプール名(Snowsight UI): SYSTEM_COMPUTE_POOL_CPU

    • インスタンスファミリー: CPU_X64_S

    • デフォルト構成:

      • MIN_NODES=1

      • MAX_NODES=25

      • INITIALLY_SUSPENDED=true

      • AUTO_SUSPEND_SECS=600

デフォルトの構成プロパティは以下の通りです。

  • コンピュートプール は、初期状態では一時停止状態であり、Notebooksが起動されたときに初めてコストが発生します。

  • Notebooksが実行されていない場合、これらのコンピュートプール は10分後に自動的に中断されます。次の点に注意してください。

    • デフォルトでは、Notebooks は 30 分間使用されないと自動的に中断されます。すべてのNotebooksがデフォルトのコンピュートプールで実行されなくなると、Snowflakeは10分後にプールを一時停止します。

    • デフォルトのコンピュートプールの自動停止ポリシーを変更するには、 ALTER COMPUTE POOL SET AUTO_SUSPEND_SECS コマンドを使用します。Notebooksの自動停止ポリシーも調整できます。詳細については、 アイドルタイムと再接続 をご参照ください。

デフォルトのコンピュートプール は、便宜上提供されています。SnowflakeアカウントのどのロールでもNotebooksを作成できますが、コンピュートプールを作成できるのは ACCOUNTADMIN ロールのみです。デフォルトのコンピュートプールを使用することで、ユーザーはアカウント管理者がコンピュートプール を構成しなくてもNotebooksを作成することができます。

これらのコンピュートプールは、Notebookワークロード専用であり、Notebookのコストを管理するために、 予算 をデフォルトのコンピュートプールに関連付けることができます。

デフォルトのコンピュートプール権限について、以下の点に注意してください。

  • Snowflakeアカウントでは、 ACCOUNTADMIN ロールがこれらのコンピュートプール を所有します。管理者は、コンピュートプール のプロパティの変更、運用の一時停止、消費量の監視など、コンピュートプールを完全に制御することができます。Snowflakeによって作成された既定のコンピュートプール が不要な場合、 ACCOUNTADMIN ロールはそれらを削除することができます。例:

    USE ROLE ACCOUNTADMIN;
    ALTER COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU STOP ALL;
    DROP COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU;
    
    Copy
  • 既定では、既定のコンピュートプール の USAGE パーミッションは PUBLIC ロールに与えられ、アカウント内のすべてのロールがそれらを使用できるようになっています。しかし、 ACCOUNTADMIN は、必要に応じてこれらの権限を変更し、アクセスを制限することができます。

    アカウント内の特定のロールに既定のコンピュートプールへのアクセスを制限するには、 ACCOUNTADMIN ロールを使用して、 PUBLIC ロールから USAGE アクセス許可を取り消し、 必要なロールにアクセス許可を与えます。例:

    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

ガイドラインと制約

  • CREATE COMPUTE POOL 権限: 現在のロールでコンピューティングプールを作成できない場合は、アカウント管理者に相談して権限を付与します。例:

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

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

  • コンピューティングプールノードのアカウントごとの制限。アカウントに作成できるノードの数は(コンピューティングプールの数に関係なく)120に制限されています。さらに、各インスタンス・ファミリに許可されるノード数には制限があります(インスタンス・ファミリ・テーブルNode limit 列をご参照ください)。 Requested number of nodes <#> exceeds the node limit for the account のようなエラーメッセージが表示された場合は、この制限に遭遇しています。詳細については、アカウントの担当にお問い合わせください。