コストの制御

このトピックでは、 仮想ウェアハウス の使用量を制限するために使用できる 制御 について説明します。これらの制御により、仮想ウェアハウスを使用する実際のコストが予想コストを超えないようにすることができます。

これらの制御は、 クラウドサービスサーバーレス機能 には適用されません。

このトピックの内容:

ウェアハウスへのアクセスを制御する

費用対効果の高い構成を持つ既知のウェアハウスに制限して、ウェアハウスで作業できるユーザーと、それらのウェアハウスで何ができるかを慎重に定義すると、コンピューティングリソースのコストを管理できます。Snowflakeの詳細な アクセス制御 により、ウェアハウスに対して次の権限を付与できます。

  • CREATE WAREHOUSE --- 新しいウェアハウスを作成できるロールを制限するグローバル権限(つまり、アカウントに付与)。コスト管理が実施されている既存のウェアハウスを個人に強制的に使用させることができます。

  • MODIFY --- ウェアハウスのサイズ変更や 自動中断 の設定の無効化など、コストに影響する設定を変更できる特定のウェアハウスに対する権限。一般に、ユーザーは特定のワークロード用にウェアハウスのサイズを増やした後、それを元のサイズに戻すのを忘れてしまい、コストに大きな影響を与える可能性があります。

  • USAGE --- 特定のウェアハウスに対する権限。ウェアハウスをアクティブ化して、クエリやその他の SQL アクションにコンピューティングリソースを提供できるようにします。この権限を慎重に割り当てることで、ユーザーはワークロードに適したサイズと構成のウェアハウスのみを使用できるようになります。

ウェアハウスの作成とスケーリングの責任をチームの数人のメンバーに集中させることは、ベストプラクティスと見なされます。すべてのウェアハウスを作成および変更する権限を持つ専用のロールを作成し、そのロールを限られた数のユーザーに付与できます。これにより、ウェアハウスポリシーを管理し、ウェアハウスが予期せず作成または拡大されることによる偶発的なコスト超過を防ぐことができるようになります。

Tip

より要求の厳しいワークロードを処理するためにウェアハウスをスケールする機能が必要であるものの、ユーザーが後でサイズ変更を忘れる可能性があるため、ウェアハウスのサイズを増やす機能をユーザーに提供しない場合は、 マルチクラスターウェアハウス の使用を検討してください。マルチクラスターウェアハウスは、ワークロードの変動に応じて自動的にスケーリングされます。

ウェアハウスに設定できるすべての権限のリストについては、 仮想ウェアハウス権限 をご参照ください。

最適なウェアハウスのサイズを選択する

ウェアハウスのサイズによって、1時間に使用できるクレジットの最大数が決まります。たとえば、Sサイズのウェアハウスは、1時間あたり2クレジットを超える消費はできません。ウェアハウスサイズの完全なリストとそれらが消費するクレジットの最大数については、 ウェアハウスの概要 をご参照ください。

コスト管理のベストプラクティスの1つは、ワークロードごとに異なるウェアハウスを使用することです。これにより、ワークロードごとに適切なサイズを選択できます。ウェアハウスの最適なサイズがわからない場合は、小さいサイズから始めて、ワークロードのパフォーマンスとその SLA に基づいて徐々にサイズを大きくします。

ワークロードに適したウェアハウスの選択に関する詳細については、 Snowflakeコンピューティングリソースの管理 (Snowflakeブログ投稿)をご参照ください。

クエリ時間を制限する

ハングしたクエリは、予想よりも長く実行されるため、過剰なクレジットを消費します。暴走クエリに関連する余分なコストを回避するために、 STATEMENT_TIMEOUT_IN_SECONDS パラメーターを設定して、 SQL ステートメントがキャンセルされるまでに実行できる最大時間を定義できます。

STATEMENT_TIMEOUT_IN_SECONDS パラメーターは、アカウント全体、ユーザー、セッション、または特定のウェアハウスに対して設定できるため、さまざまなワークロードの予想される実行時間に一致する時間制限を慎重に設定できます。このパラメーターは、デフォルトによりアカウントレベルで設定されます。セッションに加えてウェアハウスに対してパラメーター設定されている場合、0以外の最小値が適用されます。

次のコマンドを使用して、現在のクエリの時間制限を表示します。

SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN ACCOUNT;
SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN USER <username>;
SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN SESSION;
SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN WAREHOUSE <warehouse_name>;
Copy

時間制限を調整する必要がある場合は、次のコマンドのいずれかを使用します。

ALTER ACCOUNT SET STATEMENT_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER USER <username> SET STATEMENT_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER WAREHOUSE <warehouse_name> SET STATEMENT_TIMEOUT_IN_SECONDS = <number_of_seconds>;
Copy

ステートメントのキュー時間を制限する

SQL ウェアハウスを使用するためにキューに入っているステートメントは、クレジットを消費しません。ただし、クエリがキューに長時間留まると、クエリが実行されるまでに関連性がなくなる可能性があります。関連性がなくなったクエリを実行するとクレジットが浪費されるため、 SQL ステートメントがキャンセルされる前にキューに入れることができる最大時間を設定することで、コスト管理を実装できます。

SQL ステートメントがキューに留まる時間を制御するパラメーターは STATEMENT_QUEUED_TIMEOUT_IN_SECONDS です。このパラメーターは、アカウント全体、ユーザー、セッション、または特定のウェアハウスに対して設定できます。このパラメーターは、デフォルトによりアカウントレベルで設定されます。セッションに加えてウェアハウスに対してパラメーター設定されている場合、0以外の最小値が適用されます。

次のコマンドを使用して、現在のキューの時間制限を表示します。

SHOW PARAMETERS LIKE 'STATEMENT_QUEUED_TIMEOUT_IN_SECONDS' IN ACCOUNT;
SHOW PARAMETERS LIKE 'STATEMENT_QUEUED_TIMEOUT_IN_SECONDS' IN USER <username>;
SHOW PARAMETERS LIKE 'STATEMENT_QUEUED_TIMEOUT_IN_SECONDS' IN SESSION;
SHOW PARAMETERS LIKE 'STATEMENT_QUEUED_TIMEOUT_IN_SECONDS' IN WAREHOUSE <warehouse_name>;
Copy

時間制限を調整する必要がある場合は、次のコマンドのいずれかを使用します。

ALTER ACCOUNT SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER USER <username> SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER SESSION SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER WAREHOUSE <warehouse_name> SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;
Copy

自動中断を使用する

デフォルトでは、すべてのウェアハウスで自動中断の設定が有効になっています。つまり、ウェアハウスは、定義された期間非アクティブになると自動的にシャットダウンされます。中断されたウェアハウスはクレジットを消費しないため、ウェアハウスはワークロードを処理しているときにのみコストが発生します。

ユーザーが自動中断の設定を無効にできないように制限すると、未使用のウェアハウスがクレジットを浪費するのを防ぐのに役立ちます。 アクセス制御 を使用して、誰かがウェアハウスを使用できるようにするだけでなく、自動中断の設定を変更できないようにすることもできます。

クエリ: 自動中断のないウェアハウスを検索する

次のクエリを使用して、自動中断の設定が無効になっているウェアハウスがあるかどうかを定期的に確認します。

SHOW WAREHOUSES
;

SELECT "name" AS WAREHOUSE_NAME
    ,"size" AS WAREHOUSE_SIZE
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE IFNULL("auto_suspend",0) = 0;
Copy

オフになっているウェアハウスの自動中断を有効にするには、 Snowsight を開き、 Admin » Warehouses に移動します。 ALTER WAREHOUSE コマンドの AUTO_SUSPEND パラメーターを使用することもできます。

自動中断での自動再開の使用

一般に、自動中断が有効になっているすべてのウェアハウスでは、自動再開も有効にする必要があります。これら2つの設定の組み合わせにより、ウェアハウスの作業負荷が変動すると、ウェアハウスが自動的に停止および開始されます。

クエリ: 自動再開のないウェアハウスを検索する

次のクエリは、自動再開が有効になって いない ウェアハウスをリストし、変更が必要なウェアハウスを示します。

SHOW WAREHOUSES
;

SELECT "name" AS WAREHOUSE_NAME
    ,"size" AS WAREHOUSE_SIZE
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE "auto_resume" = 'false';
Copy

オフになっているウェアハウスの自動再開を有効にするには、 Snowsight を開き、 Admin » Warehouses に移動します。 ALTER WAREHOUSE コマンドの AUTO_RESUME パラメーターを使用することもできます。

支出制限を強制する

リソースモニター は、特定の時間間隔または日付範囲内でウェアハウスによって消費されるクレジットに制限を設定する機能を提供します。これにより、ウェアハウスが通常予想されるよりも多くのクレジットを意図せずに消費することを防止できます。

リソースモニターは、クレジットの限度に達したときに管理者に通知するだけの場合もありますが、限度に達するとすぐにウェアハウスを中断するようにリソースモニターを構成することで、限度を 強制 することもできます。制限を強制する場合は、保留中のステートメントが実行された後にウェアハウスを中断するか、ステートメントの完了を待たずにすぐに中断するかの2つのオプションがあります。

複数のウェアハウスまたはアカウント全体に対して1つのリソースモニターを設定できるため、全体的な支出制限に達したときに、複数のウェアハウスを効果的に中断できます。ウェアハウスは、それ自体のリソースモニターとアカウント固有のリソースモニターに同時に割り当てることができます。いずれかのクレジットの限度に達すると、ウェアハウスは中断されます。

使用制限に達した場合のウェアハウスの中断に関する詳細については、 リソースモニターの操作 をご参照ください。

クエリ: リソースモニターのないウェアハウスを検索する

次のクエリは、ウェアハウス固有のリソースモニターに割り当てられていない、コストの暴走に対して脆弱なウェアハウスをリストします。クエリは、アカウントレベルのリソースモニターをチェックしないことに注意してください。アカウントレベルのリソースモニターがあるアカウントに属するリスト内のウェアハウスは、引き続きクレジット限度の対象となります。

SELECT "name" AS WAREHOUSE_NAME
      ,"size" AS WAREHOUSE_SIZE
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE "resource_monitor" = 'null'
;
Copy

注釈

リソースモニターによって中断されたウェアハウスに対してクエリが実行された場合、Snowflakeアーキテクチャのクラウドサービスレイヤーには、依然として少額のコストが発生する可能性があります。