アカウント使用状況によるCortex AI関数のコスト管理¶
Snowflake Cortex AI関数(AI_COMPLETE、AI_SUMMARIZE、AI_TRANSLATE、AI_SENTIMENTなど)は、トークンまたはページの使用状況に基づいてクレジットを消費します。モニタリングや制御を行わない場合、これらの関数を使用するためのコストは、次の理由によりすぐに上昇する可能性があります。
過剰なトークンを生成する最適化されていないプロンプト
長時間実行または暴走クエリ
ユーザーごとの支出制限がないこと
使用パターンの可視性が不十分であること
このトピックでは、Snowflake Cortex AI関数に関連するコストをモニタリング、管理、制御するための戦略を提案します。CORTEX_AI_FUNCTIONS_USAGE_HISTORYビューを使用すると、使用パターンを追跡し、自動コスト管理を実装できます。これらのテクニックは、使用状況をモニタリングし、支出制限を超えた場合にアラートを発出し、月間の上限に基づいて関数へのアクセスを制御し、暴走クエリを停止するのに役立ちます。
使用履歴ビュー¶
SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORYビューは、SQL経由で呼び出されるすべてのCortex AI関数について詳細なテレメトリーを提供します。ビューの最大レイテンシは60分ですが、データは関数実行開始からわずか10分で利用可能になる場合があります。このビューについて詳しくは、:doc:`/sql-reference/account-usage/cortex_ai_functions_usage_history`を参照してください。
基本的な使用状況のモニタリング¶
次のクエリは、AI関数の使用パターンを理解するのに役立ちます。これらを定期的に自分で実行するか、ダッシュボードに統合して継続的な可視化を行います。
関数やモデルごとの毎日のクレジット消費¶
毎日の支出傾向を追跡して、使用量の急増を特定し、最も多くのクレジットを消費している関数やモデルを把握します。
SELECT
DATE_TRUNC('day', START_TIME) AS usage_date,
FUNCTION_NAME,
MODEL_NAME,
SUM(CREDITS) AS total_credits,
COUNT(DISTINCT QUERY_ID) AS query_count
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE START_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3
ORDER BY usage_date DESC, total_credits DESC;
ユーザーごとの月間クレジット消費¶
上位のコンシューマーを特定し、ユーザーごとの支出を経時的に追跡します。このクエリは、USERSビューとの結合により、メールや既定のロールなどのユーザーの詳細を提供します。これにより、識別とフォローアップが容易になります。
SELECT
DATE_TRUNC('month', h.START_TIME) AS usage_month,
u.NAME AS user_name,
u.EMAIL,
u.DEFAULT_ROLE,
SUM(h.CREDITS) AS total_credits,
COUNT(DISTINCT h.QUERY_ID) AS query_count
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY h
JOIN SNOWFLAKE.ACCOUNT_USAGE.USERS u
ON h.USER_ID = u.USER_ID
WHERE h.START_TIME >= DATEADD('month', -3, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3, 4
ORDER BY usage_month DESC, total_credits DESC;
コスト管理¶
過剰な支出を検出し、是正措置を講じる自動メカニズムを定義します。これらのクエリは、互いに独立して使用することも、包括的なコストガバナンスのために組み合わせて使用することもできます。
アカウントレベルでの月間支出アラート¶
アカウント全体におけるAI関数クレジットの月間の合計消費をモニタリングする自動アラートを設定します。支出が定義されたしきい値を超えると、アラートは指定された管理者にメール通知を送信します。アラートを設定するには、次の前提条件が必要です。
ACCOUNTADMINロール、または:ref:`通知統合<label-create_email_notification_integration>`および:ref:`アラート<label-alerts_privileges_granting>`を作成するための適切な権限
アラート条件チェックを実行するウェアハウス
アラート受信者の検証済みメールアドレス
まず、通知統合がまだ存在しない場合は作成します。この例では、``ai_cost_alerts``という名前の既存の統合を置き換えます。
CREATE OR REPLACE NOTIFICATION INTEGRATION ai_cost_alerts
TYPE = EMAIL
ENABLED = TRUE
ALLOWED_RECIPIENTS = ('admin@company.com', 'finops@company.com')
次に、各月のアラートがいつ送信されたかを追跡するテーブルを作成します。これは、1か月以内の重複アラートを防ぐために使用されます。
CREATE TABLE IF NOT EXISTS AI_FUNCTIONS_ALERT_STATE (
ALERT_NAME VARCHAR NOT NULL,
ALERT_MONTH DATE NOT NULL,
SENT_AT TIMESTAMP_LTZ DEFAULT CURRENT_TIMESTAMP(),
CREDITS_AT_ALERT NUMBER(38,6),
PRIMARY KEY (ALERT_NAME, ALERT_MONTH)
);
次に、アラートが今月すでに送信されたかどうかを確認し、アラートの状態を記録してメール通知を送信するストアドプロシージャを作成します。
CREATE OR REPLACE PROCEDURE SEND_MONTHLY_SPEND_ALERT(P_THRESHOLD FLOAT)
RETURNS VARCHAR
LANGUAGE JAVASCRIPT
EXECUTE AS CALLER
AS
$$
// Check if alert already sent this month
var check_sent = snowflake.execute({
sqlText: `SELECT COUNT(*) AS cnt FROM AI_FUNCTIONS_ALERT_STATE
WHERE ALERT_NAME = 'monthly_spend'
AND ALERT_MONTH = DATE_TRUNC('month', CURRENT_DATE())`
});
check_sent.next();
var already_sent = check_sent.getColumnValue(1);
if (already_sent > 0) {
return 'Alert already sent for this month';
}
// Get current spend
var spend_result = snowflake.execute({
sqlText: `SELECT COALESCE(SUM(CREDITS), 0) AS total
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE START_TIME >= DATE_TRUNC('month', CURRENT_TIMESTAMP())`
});
spend_result.next();
var v_credits = spend_result.getColumnValue(1);
// Check threshold
if (v_credits <= P_THRESHOLD) {
return 'Threshold not exceeded. Current: ' + v_credits + ' / ' + P_THRESHOLD;
}
// Record alert
snowflake.execute({
sqlText: `INSERT INTO AI_FUNCTIONS_ALERT_STATE (ALERT_NAME, ALERT_MONTH, CREDITS_AT_ALERT)
VALUES ('monthly_spend', DATE_TRUNC('month', CURRENT_DATE()), ?)`,
binds: [v_credits]
});
// Send email - update the recipient email address
snowflake.execute({
sqlText: `CALL SYSTEM$SEND_EMAIL(
'ai_cost_alerts',
'admin@company.com',
'AI Functions Monthly Spend Alert',
'Monthly AI Function credit consumption has exceeded the threshold.\\n\\n' ||
'Current spend: ' || ${v_credits}::VARCHAR || ' credits\\n' ||
'Threshold: ' || ${P_THRESHOLD}::VARCHAR || ' credits\\n\\n' ||
'Please review usage accordingly.'
)`
});
return 'Alert sent. Credits: ' + v_credits;
$$;
最後に、支出しきい値に対して使用状況を1時間ごとにチェックし、必要に応じてプロシージャを呼び出して通知を送信するアラートを作成します。以下の例の2か所に表示されている1000クレジットの制限を、目的のしきい値に調整する必要があります。
CREATE OR REPLACE ALERT ai_functions_monthly_spend_alert
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 * * * * UTC' -- Runs every hour
IF (EXISTS (
SELECT 1
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE START_TIME >= DATE_TRUNC('month', CURRENT_TIMESTAMP())
HAVING SUM(CREDITS) > 1000 -- adjust the limit accordingly
))
THEN
CALL SEND_MONTHLY_SPEND_ALERT(1000); -- please adjust the limit accordingly
-- enable the alert
ALTER ALERT ai_functions_monthly_spend_alert RESUME;
Tip
テストの目的で、まず制限を0に設定して、アラートをすぐにトリガーします。アラートが期待どおりに機能することを確認した後、目的のしきい値でアラートを再作成します。
しきい値を0に設定したテストの後、次のSQLを実行して、今月アラートが再度トリガーされるようにします。
DELETE FROM AI_FUNCTIONS_ALERT_STATE
WHERE ALERT_NAME = 'monthly_spend'
AND ALERT_MONTH = DATE_TRUNC('month', CURRENT_DATE());
次のようにアラート履歴とアラート状態テーブルをクエリすると、アラートが動作していることを確認できます。
-- Make sure alert exists
SHOW ALERTS LIKE 'ai_functions_monthly_spend_alert';
-- Check alert history
SELECT *
FROM TABLE(INFORMATION_SCHEMA.ALERT_HISTORY(
SCHEDULED_TIME_RANGE_START => DATEADD('day', -1, CURRENT_TIMESTAMP()),
ALERT_NAME => 'ai_functions_monthly_spend_alert'
))
ORDER BY SCHEDULED_TIME DESC;
-- Check which months have had alerts sent
SELECT * FROM AI_FUNCTIONS_ALERT_STATE ORDER BY ALERT_MONTH DESC;
ユーザーごとの月間支出制限¶
この例では、ユーザーごとの月間の支出制限を実装します。ユーザーには、Cortex AI関数へのアクセスを提供するカスタムの専用AI_FUNCTIONS_USER_ROLEが付与されます。テーブルには、個々のユーザーの月間トークン予算が格納されます。ユーザーがその月の予算を超えると、1時間ごとのタスクによってAI_FUNCTIONS_USER_ROLEが削除され、AI関数へのアクセスが取り消されます。月ごとのタスクによって、ロールは翌月の初めに復元されます。
重要
デフォルトでは、SNOWFLAKE.CORTEX_USERデータベースロールがPUBLICロールに付与されているため、すべてのユーザーがAI関数(およびSnowflake Cortexの他の機能)にアクセスできます。ユーザーごとの制限を適用するには、PUBLICからSNOWFLAKE.CORTEX_USERを取り消し、AI_FUNCTIONS_USER_ROLEを通じてのみ付与する必要があります。次のSQLを使用して、PUBLICからロールを取り消します。
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_USER FROM ROLE PUBLIC;
Cortexの機能へのアクセスが必要なすべてのユーザーに対して、AI_FUNCTIONS_USER_ROLEのみが付与されていることを確認してください。SNOWFLAKE.CORTEX_USERを含むその他のロールを使用すると、ユーザーはこの例で実装された支出制限の制御を回避できるようになります。場合によっては、より具体的なロールを使用できます。例えば、Cortex Analystへのアクセスのみが必要なユーザーには、SNOWFLAKE.CORTEX_USERの代わりにSNOWFLAKE.CORTEX_ANALYST_USERロールを付与できます。
ユーザーごとの支出制限を設定するには、まずAI関数へのアクセスを制御するロールを作成し、このアクセスを他の権限とは別に管理できるようにします。
-- Create a role specifically for AI Function access
CREATE ROLE IF NOT EXISTS AI_FUNCTIONS_USER_ROLE;
-- Grant necessary privileges to the role
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE AI_FUNCTIONS_USER_ROLE;
-- Grant usage on warehouse
GRANT USAGE ON WAREHOUSE AI_FUNCTIONS_WAREHOUSE TO ROLE AI_FUNCTIONS_USER_ROLE;
次に、アクセス制御テーブルを設定します。これは、AI関数へのアクセス権を持っているユーザー、個々の支出制限、個々の取り消し履歴を追跡するものです。これは自動モニタリングとアクセス復元のプロセスにおける信頼できる情報源となります。
CREATE TABLE IF NOT EXISTS AI_FUNCTIONS_ACCESS_CONTROL (
USER_NAME VARCHAR NOT NULL,
USER_ID NUMBER,
GRANTED_AT TIMESTAMP_LTZ DEFAULT CURRENT_TIMESTAMP(),
MONTHLY_CREDIT_LIMIT NUMBER(38,6) DEFAULT 100, -- adjust the limit accordingly
IS_ACTIVE BOOLEAN DEFAULT TRUE,
REVOKED_AT TIMESTAMP_LTZ,
REVOCATION_REASON VARCHAR,
PRIMARY KEY (USER_NAME)
);
次に、ユーザーにAI関数へのアクセスを付与し、個々の支出制限とともにアクセス制御テーブルに登録するストアドプロシージャを作成します。このコードは、モニタリングクエリでの効率的な結合を可能にするために、アカウント使用状況ビューからユーザーのIDを検索します。
CREATE OR REPLACE PROCEDURE GRANT_AI_FUNCTIONS_ACCESS(
P_USER_NAME VARCHAR,
P_MONTHLY_LIMIT NUMBER(38,6) DEFAULT 100 -- adjust the limit accordingly
)
RETURNS VARCHAR
LANGUAGE SQL
AS
$$
DECLARE
v_user_id NUMBER;
BEGIN
-- Look up USER_ID from account usage
SELECT USER_ID INTO :v_user_id
FROM SNOWFLAKE.ACCOUNT_USAGE.USERS
WHERE NAME = :P_USER_NAME
LIMIT 1;
-- Grant the AI Functions role to the user
EXECUTE IMMEDIATE 'GRANT ROLE AI_FUNCTIONS_USER_ROLE TO USER ' || P_USER_NAME;
-- Register or update the user in the access control table
MERGE INTO AI_FUNCTIONS_ACCESS_CONTROL tgt
USING (SELECT :P_USER_NAME AS USER_NAME) src
ON tgt.USER_NAME = src.USER_NAME
WHEN MATCHED THEN
UPDATE SET
USER_ID = :v_user_id,
IS_ACTIVE = TRUE,
MONTHLY_CREDIT_LIMIT = :P_MONTHLY_LIMIT,
GRANTED_AT = CURRENT_TIMESTAMP(),
REVOKED_AT = NULL,
REVOCATION_REASON = NULL
WHEN NOT MATCHED THEN
INSERT (USER_NAME, USER_ID, MONTHLY_CREDIT_LIMIT, IS_ACTIVE)
VALUES (:P_USER_NAME, :v_user_id, :P_MONTHLY_LIMIT, TRUE);
RETURN 'Access granted to ' || P_USER_NAME || ' with monthly limit of ' || P_MONTHLY_LIMIT || ' credits';
END;
$$;
このストアドプロシージャを使用して、ユーザーとそのクレジットクォータをアクセス制御テーブルに追加します。
CALL GRANT_AI_FUNCTIONS_ACCESS('ALICE', 1000); -- grants access to user ALICE with a monthly limit of 100 credits
CALL GRANT_AI_FUNCTIONS_ACCESS('BOB', 2000); -- grants access to user BOB with a monthly limit of 200 credits
次に、月ごとのアクセス更新タスクを作成します。このタスクは毎月1日に実行され、資格のあるすべてのユーザーに対してAI関数へのアクセスを復元します。前の月に制限を超えたためにユーザーのアクセスが取り消された場合、このタスクは、そのユーザーに新しい月の新たな予算を付与します。
-- Create a procedure to re-grant access to all entitled users
CREATE OR REPLACE PROCEDURE GRANT_ALL_ENTITLED_USERS()
RETURNS TABLE (USER_NAME VARCHAR, CREDIT_LIMIT NUMBER, ACTION VARCHAR)
LANGUAGE SQL
AS
$$
DECLARE
result RESULTSET;
BEGIN
result := (
SELECT
USER_NAME,
MONTHLY_CREDIT_LIMIT AS CREDIT_LIMIT,
'GRANTED' AS ACTION
FROM AI_FUNCTIONS_ACCESS_CONTROL
);
-- Re-grant access for each entitled user
FOR rec IN result DO
CALL GRANT_AI_FUNCTIONS_ACCESS(rec.USER_NAME, rec.CREDIT_LIMIT);
END FOR;
RETURN TABLE(result);
END;
$$;
-- Create a task to run on the 1st of each month at midnight UTC
CREATE OR REPLACE TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 0 1 * * UTC' -- 1st day of each month at 00:00 UTC
AS
CALL GRANT_ALL_ENTITLED_USERS();
-- Enable the task
ALTER TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH RESUME;
-- Run once initially to populate grantees
CALL GRANT_ALL_ENTITLED_USERS();
-- Verify task status
SHOW TASKS LIKE 'MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH';
最後に、ユーザーの支出をモニターし、月間の制限を超えたユーザーのアクセスを取り消す1時間ごとのタスクを作成します。
-- Create a procedure to re-grant access to all entitled users
CREATE OR REPLACE PROCEDURE GRANT_ALL_ENTITLED_USERS()
RETURNS TABLE (USER_NAME VARCHAR, CREDIT_LIMIT NUMBER, ACTION VARCHAR)
LANGUAGE SQL
AS
$$
DECLARE
result RESULTSET;
BEGIN
result := (
SELECT
USER_NAME,
MONTHLY_CREDIT_LIMIT AS CREDIT_LIMIT,
'GRANTED' AS ACTION
FROM AI_FUNCTIONS_ACCESS_CONTROL
);
-- Re-grant access for each entitled user
FOR rec IN result DO
CALL GRANT_AI_FUNCTIONS_ACCESS(rec.USER_NAME, rec.CREDIT_LIMIT);
END FOR;
RETURN TABLE(result);
END;
$$;
-- Create a task to run on the 1st of each month at midnight UTC
CREATE OR REPLACE TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 0 1 * * UTC' -- 1st day of each month at 00:00 UTC
AS
CALL GRANT_ALL_ENTITLED_USERS();
-- Enable the task
ALTER TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH RESUME;
-- Run once initially to populate grantees
CALL GRANT_ALL_ENTITLED_USERS();
-- Verify task status
SHOW TASKS LIKE 'MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH';
暴走クエリの検出とキャンセル¶
長時間実行されるAI関数クエリは、かなりのコストを蓄積する可能性があります。この例では、クレジットのしきい値を超えるクエリを検出し、さらにリソースを消費する前にキャンセルする自動システムを実装します。クエリの完全な詳細が記載されたメールアラートが送信されます。
注釈
クエリがキャンセルされた場合でも、クライアントはキャンセルの瞬間までに消費されたすべてのリソースに関して課金されます。暴走クエリをキャンセルすると、コストがさらに蓄積されることはありませんが、すでに使用されたクレジットは払い戻しされません。
このプロシージャは、過去48時間以内のAI関数クエリのうち、クレジットのしきい値を超えたもの、かつ実行中のものを検索してキャンセルし、管理者にレポートします。
-- Create a procedure to detect and cancel expensive runaway queries
CREATE OR REPLACE PROCEDURE MONITOR_AND_CANCEL_RUNAWAY_QUERIES(
P_CREDIT_THRESHOLD NUMBER DEFAULT 50 -- adjust the limit accordingly
)
RETURNS TABLE (
QUERY_ID VARCHAR,
USER_NAME VARCHAR,
FUNCTION_NAME VARCHAR,
MODEL_NAME VARCHAR,
CREDITS NUMBER,
START_TIME TIMESTAMP_LTZ,
ACTION VARCHAR
)
LANGUAGE SQL
AS
$$
DECLARE
result RESULTSET;
BEGIN
-- Find queries from the last 48 hours that exceed the threshold and are still running
result := (
SELECT
h.QUERY_ID,
u.NAME AS USER_NAME,
h.FUNCTION_NAME,
h.MODEL_NAME,
h.CREDITS,
h.START_TIME,
h.ROLE_NAMES,
h.QUERY_TAG,
h.WAREHOUSE_ID,
'CANCELLED' AS ACTION
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY h
LEFT JOIN SNOWFLAKE.ACCOUNT_USAGE.USERS u
ON h.USER_ID = u.USER_ID
WHERE h.START_TIME >= DATEADD('hour', -48, CURRENT_TIMESTAMP())
AND h.CREDITS > :P_CREDIT_THRESHOLD
AND h.IS_COMPLETED = FALSE
);
-- Cancel each runaway query and send alert
FOR rec IN result DO
-- Attempt to cancel the query
BEGIN
EXECUTE IMMEDIATE 'SELECT SYSTEM$CANCEL_QUERY(''' || rec.QUERY_ID || ''')';
EXCEPTION
WHEN OTHER THEN
NULL; -- Query may have already completed
END;
-- Send alert with query details
CALL SYSTEM$SEND_EMAIL(
'ai_cost_alerts',
'admin@company.com',
'Runaway AI Query Cancelled - ' || rec.QUERY_ID,
'A runaway AI Function query has been cancelled due to excessive cost.\n\n' ||
'Query Details:\n' ||
'- Query ID: ' || rec.QUERY_ID || '\n' ||
'- User: ' || COALESCE(rec.USER_NAME, 'Unknown') || '\n' ||
'- Function: ' || rec.FUNCTION_NAME || '\n' ||
'- Model: ' || rec.MODEL_NAME || '\n' ||
'- Credits Used: ' || rec.CREDITS::VARCHAR || '\n' ||
'- Threshold: ' || :P_CREDIT_THRESHOLD::VARCHAR || '\n' ||
'- Start Time: ' || rec.START_TIME::VARCHAR || '\n' ||
'- Roles: ' || COALESCE(rec.ROLE_NAMES::VARCHAR, 'N/A') || '\n' ||
'- Query Tag: ' || COALESCE(rec.QUERY_TAG, 'N/A') || '\n' ||
'- Warehouse ID: ' || COALESCE(rec.WAREHOUSE_ID::VARCHAR, 'N/A') || '\n\n' ||
'Please investigate this query and take appropriate action.'
);
END FOR;
RETURN TABLE(result);
END;
$$;
-- Create a task to monitor and cancel runaway queries every hour
CREATE OR REPLACE TASK MONITOR_RUNAWAY_AI_QUERIES
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 * * * * UTC' -- Every hour
AS
CALL MONITOR_AND_CANCEL_RUNAWAY_QUERIES(50); -- adjust the limit accordingly
-- Enable the task
ALTER TASK MONITOR_RUNAWAY_AI_QUERIES RESUME;
-- Verify task status
SHOW TASKS LIKE 'MONITOR_RUNAWAY_AI_QUERIES';
-- Check task execution history
SELECT *
FROM TABLE(INFORMATION_SCHEMA.TASK_HISTORY(
SCHEDULED_TIME_RANGE_START => DATEADD('day', -1, CURRENT_TIMESTAMP()),
TASK_NAME => 'MONITOR_RUNAWAY_AI_QUERIES'
))
ORDER BY SCHEDULED_TIME DESC;
Tip
一部のクエリは長時間実行されることがすでにわかっている場合があります。これらのクエリに特別なロールを定義し、プロシージャのキャンセルロジックからそのロールを除外することができます。例えば、ロールを作成するには次のようにします。
CREATE ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE;
GRANT ROLE AI_FUNCTIONS_USER_ROLE TO ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE;
GRANT ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE TO USER LONG_RUNNING_USER;
このロールを持つユーザーが実行したクエリをキャンセルから除外するには、プロシージャのWHERE句に次の条件を追加します。
,, code-block:: sqlexample
AND NOT ARRAY_CONTAINS(h.ROLE_NAMES, 'AI_FUNCTIONS_USER_LONG_RUNNING_ROLE')
これで、ユーザーはロールを引き受けて、キャンセルされることなく長時間実行されるクエリを実行できます。
USE ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE;
-- then start the long-running query
ベストプラクティス¶
AI関数の使用状況に関するコスト管理戦略を開発する際は、次のベストプラクティスに留意してください。
**モニタリング開始:**自動制御を実装する前に、:ref:`label-ai_functions_basic_usage_queries`のクエリを使用してベースラインの使用パターンを確立します。
**クエリタグの使用:**プロジェクトやチームごとのコスト配分を可能にするために、QUERY_TAGセッションパラメーターを使用するようチームに推奨します。
**アラートのテスト:**重要なアラートの通知手段として運用を開始する前に、メール通知が正しく機能することを確認します。
**レイテンシの考慮:**ACCOUNT_USAGEビューには最大60分のレイテンシがあります。これをモニタリング戦略に組み込みます。