サービスの管理およびスケーリング¶

モデルがSnowpark Container Services（SPCS）にデプロイされると、そのライフサイクル、リソースの消費、および信頼性を管理する必要があります。このページでは、本番ワークロードの標準操作、可観測性、および高可用性の構成について説明します。

サービスの管理¶

Snowpark Container Servicesは、サービス管理のために SQL インターフェイスを提供します。DESCRIBE SERVICE および ALTER SERVICE のコマンドは、他の SPCS サービスを管理する場合と同様に、Snowflake Model Serving で作成された SPCS サービスで使用できます。たとえば、次が可能です。

サービスの MIN_INSTANCES およびその他のプロパティを変更する
サービスのドロップ（削除）
他のアカウントとサービスを共有する
サービスの所有権を変更する（新しい所有者はモデルへのREADアクセス権が必要です）

注釈

サービスのオーナーが何らかの理由で基礎となるモデルへのアクセスを失った場合、サービスは再起動後に動作しなくなります。再起動するまでは動作し続けます。

再現性とデバッグが可能である状態を確保するため、既存の推論サービスの仕様を変更することはできません。しかし、仕様をコピーしてカスタマイズし、カスタマイズした仕様を使用して、モデルをホストする独自のサービスを作成することができます。しかしこの方法では、基礎となるモデルが削除されるのを防ぐことはできません。さらに、系統を追跡することはありません。Snowflake Model Servingがサービスを作成できるようにすることを推奨します。

サービスのスケーリング¶

注釈

snowflake-ml-python 1.25.0以降では、create_serviceメソッド内でmin_instancesとmax_instancesを設定することで、推論サービスのスケーリング境界を定義できます。

自動スケーリングの仕組み¶

サービスはmin_instancesで指定されたノード数で初期化されます。また、リアルタイムのトラフィック量とハードウェアの使用率に基づいて、定義した範囲内で動的にスケーリングされます。

スケールツーゼロ（自動的に一時停止）: min_instancesが0（デフォルト）に設定されている場合、30分間トラフィックが検出されないとサービスは自動的に一時停止します。

スケーリングレイテンシ: スケーリングのトリガーは通常、必要な条件を満たしてから1分後にアクティブ化されます。スピンアップ時間の合計には、このトリガー期間に加えて、新しいサービスインスタンスをプロビジョニングして初期化するために必要な時間が含まれることに注意してください。

構成のベストプラクティス¶


パラメーター	推奨戦略
min_instances	すぐに利用できるようにし、コールドスタートの遅延を避けるため、実稼働のワークロードについては1以上に設定してください。
max_instances	リソースの消費とコストの上限を維持しながら、ピークの需要に対応するように設定します。

サービスを一時停止します。¶

デフォルトのmin_instances=0設定により、非アクティブな状態が30分間継続した後にサービスが自動的に一時停止するようにできます。受信リクエストは再開をトリガーします。遅延の合計はコンピューティングプールの可用性とモデルのロード時間（起動遅延）によって決定されます。

サービスを手動で一時停止したり再開したりするには、 ALTERSERVICE コマンドを使用してください。

ALTER SERVICE my_service [ SUSPEND | RESUME ];

モデルの削除¶

モデルやモデルのバージョンは、 SQL インターフェイスや Python API を使って通常通り管理することができますが、サービスによって（実行中であれ中断中であれ）使われているモデルやモデルのバージョンはドロップ（削除）することができません。モデルまたはモデルのバージョンを削除するには、まずサービスを削除します。

サービスのモニタリング¶

Snowpark Container Servicesでモデルを実行する場合は、コンテナのログとメトリックにアクセスすることで、サービスの健全性をモニタリングし、問題をトラブルシューティングすることができます。モデルサービングサービスは、サービスの動作を理解し、エラーを診断して、パフォーマンスを最適化するのに役立つログを生成します。

メトリックやログへのアクセスなどの SPCS サービスのモニタリングに関する包括的な情報については、サービスのモニタリングをご参照ください。

Snowsightの場合¶

Snowsightでは、モデルのサービングサービスをモニタリングできます。

ナビゲーションメニューで、モニタリング»サービスとジョブ を選択します。
サービス タブで、サービスを選択して、サービスの詳細ページを表示します。
概要タブには、コンピューティングプール、エンドポイント、インスタンス数などのサービス情報が表示されます。
ログ、メトリック、イベント の各タブには、ログ、パフォーマンスメトリック、サービスイベント（インスタンスのプロビジョニングやシャットダウンなど）が表示されます。必要に応じてインスタンス名とコンテナ名で結果をフィルタリングします。

サービスログへのアクセス¶

以下のいずれかの方法で、モデルのサービングサービスのログにアクセスできます。

サービスヘルパー関数の使用¶

モデルのサービングには、実行中または一時停止したサービスのイベントテーブルからログを取得するヘルパー関数が組み込まれています。

-- Retrieve logs using the service helper function
SELECT * FROM TABLE(mydb.myschema.my_model_service!SPCS_GET_LOGS())
WHERE
timestamp > dateadd(hour, -1, current_timestamp())
AND instance_id = 0  -- choose all instances or one particular
AND container_name = 'model-inference';

イベントテーブルを直接クエリ¶

アカウントにイベントテーブルが構成されている場合は、直接クエリしてサービスログを取得できます。

-- Find the event table for your account
SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;

-- Query the event table for model service logs
SELECT TIMESTAMP, RESOURCE_ATTRIBUTES, RECORD_ATTRIBUTES, VALUE
FROM <current_event_table_for_your_account>
WHERE timestamp > dateadd(hour, -1, current_timestamp())
    AND RESOURCE_ATTRIBUTES:"snow.service.name" = '<model_service_name>'
    AND RECORD_TYPE = 'LOG'
    AND RESOURCE_ATTRIBUTES:"snow.service.container.instance" = '0'  -- choose all instances or one particular
    AND RESOURCE_ATTRIBUTES:"snow.service.container.name" = 'model-inference'
ORDER BY timestamp DESC
LIMIT 10;

システム関数の使用（インスタンスの実行のみ）¶

アクティブなコンテナのリアルタイムデバッグには、SYSTEM$GET_SERVICE_LOGS 関数を使用できます。

-- Retrieve logs from a specific service instance
SELECT SYSTEM$GET_SERVICE_LOGS('model_service_name', '0', 'model-inference', 10);

注釈

モデル推論サービスのコンテナ名は、model-inferenceです。イメージビルドの問題のトラブルシューティングには、コンテナ名としてmodel-buildを使用します。

サービスメトリックへのアクセス¶

モデルサービングサービスは、リソースの使用率、リクエストレート、レイテンシ、その他の運用特性をモニタリングするのに役立つパフォーマンスと健全性のメトリックを出力します。これらのメトリックはイベントテーブルに取り込まれ、クエリしてサービスのパフォーマンスを経時的に分析することができます。

SPCS サービスメトリックの詳細については、イベントテーブルサービスのメトリックへのアクセスをご参照ください。

サービスヘルパー関数の使用¶

モデルサービングサービスには、実行中または一時停止されたサービスのイベントテーブルからメトリックを取得するヘルパー関数が組み込まれています。

-- Retrieve metrics using the service helper function
SELECT *
FROM TABLE(mydb.myschema.my_model_service!SPCS_GET_METRICS())
WHERE
timestamp > dateadd(hour, -1, current_timestamp())
AND instance_id = 0  -- choose all instances or one particular
AND container_name = 'model-inference';

イベントテーブルを直接クエリ¶

イベントテーブルを直接クエリして、特定のメトリックを取得し、フィルタリングすることができます。

-- Find the event table for your account
SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;

-- Query the event table for model service metrics
SELECT
    timestamp,
    RESOURCE_ATTRIBUTES:"snow.service.container.instance" as instance,
    RESOURCE_ATTRIBUTES:"snow.service.container.name" as container,
    RECORD:metric:"name" as metric,
    value
FROM my_event_table_db.my_event_table_schema.my_event_table
WHERE timestamp > DATEADD(hour, -1, CURRENT_TIMESTAMP())
    AND RESOURCE_ATTRIBUTES:"snow.service.name" = '<model_service_name>'
    AND RECORD_TYPE = 'METRIC'
    AND RESOURCE_ATTRIBUTES:"snow.service.container.instance" = '0'  -- choose all instances or one particular
    AND RESOURCE_ATTRIBUTES:"snow.service.container.name" = 'model-inference'
ORDER BY timestamp DESC
LIMIT 100;

フォールトトレランス¶

分散システムでは障害が発生します。ミッションクリティカルなワークロードの場合は、ノードとゾーンの障害に対して耐久性があるサービスをユーザーが構成する必要があります。

ノードの障害復旧¶

標準のノード障害を許容するために、Snowflakeは50%のオーバープロビジョニングまたは少なくとも3つのインスタンスの維持（いずれか高い方）をお勧めします。

例: ピークトラフィックをサポートするために4つのインスタンスが必要な場合は、6つのインスタンスをプロビジョニングする必要があります

ゾーンの障害復旧¶

ゾーン全体にわたる障害に対する復元力を必要とするミッションクリティカルなワークロードの場合は、:doc:`サービス</sql-reference/sql/create-service>`作成時に分散型:doc:`コンピューティングプール</sql-reference/sql/create-compute-pool>`を使用できます。分散型コンピューティングプールは、PLACEMENT_GROUPパラメーターをDISTRIBUTEDに設定することで作成されます。分散型コンピューティングプールの詳細については、:ref:`label-SPCS_working_with_compute_pool_placement_group`をご参照ください。

構成ガイド¶

既存のプールを変換する¶

警告

アクティブなプールではこの設定を変更できません。最初に一時停止する必要があります。

ALTER COMPUTE POOL my_pool SUSPEND;

ALTER COMPUTE POOL my_pool
  SET PLACEMENT_GROUP = 'DISTRIBUTED';

ALTER COMPUTE POOL my_pool RESUME;

既存のプールを元に戻す¶

警告

アクティブなプールではこの設定を変更できません。最初に一時停止する必要があります。

ALTER COMPUTE POOL my_pool SUSPEND;

ALTER COMPUTE POOL my_pool
  UNSET PLACEMENT_GROUP;

ALTER COMPUTE POOL my_pool RESUME;

検証¶

HA に対してプールが正しく構成されていることを確認するには、placement_group列を確認してください。

DESCRIBE COMPUTE POOL my_service_pool;