Snowflakeのアラート・通知機能（2024年最新版）

最初に取り上げる機能はメール通知です。Snowflakeでは、SYSTEM$SEND_EMAILというストアドプロシージャを使い、検証済みのメールアドレス宛にメールを送信できます。検証済みとは、Snowflakeユーザーに紐付いたアドレスで、本人がメール内のアクティベーションリンクを経て認証を完了している状態を指します（手順はこちら）。共有メールボックスや通知専用のアドレスを使いたい場合は、まずSnowflake上に専用ユーザーを作成し、そのアドレスを割り当てる必要があります。

SYSTEM$SEND_EMAILを利用するには、notification integration（通知統合）の作成が必要です。

Snowflakeのnotification integrationとは

notification integrationは、Snowflakeから通知を送信するために必要な情報とセキュリティ権限をひとまとめにした「ラッパーオブジェクト」と捉えるとわかりやすいでしょう。作成するには、CREATE INTEGRATION権限を持つロールが必要で、デフォルトではこの権限はACCOUNTADMINロールにのみ付与されています。これにより、Snowflake管理者は「職務分離（segregation of duties）」の原則を保てます。管理者がnotification integrationを作成して受信者リストを管理し、開発者にはオブジェクトの利用権限のみを付与する。開発者は利用はできるが変更はできない、という運用が実現します。

notification integrationの作成方法

notification integrationは次のコマンドで作成できます。

CREATE NOTIFICATION INTEGRATION my_email_int
    TYPE=EMAIL
    ENABLED=TRUE
  ALLOWED_RECIPIENTS=('joe.doe@my_domain.com','another.joe@my_domain.com');

CREATE NOTIFICATIONコマンドのパラメータは3つです。

• TYPE: notification integrationの種別（EMAIL、QUEUE）
• ENABLED: TRUEまたはFALSE
• ALLOWED_RECIPIENTS: メッセージの送信先となる検証済みメールアドレス（最大10件）

notification integrationを用意したら、他のロールにも利用権限を付与し、メール送信に使えるようにしておくとよいでしょう。

1GRANT USAGE ON INTEGRATION my_email_int TO ROLE my_developer_role;

少なくとも1件の検証済みメールアドレスを設定したnotification integrationオブジェクトができれば、メール送信の準備は完了です。

Snowflakeから手動でメールを送信する

SYSTEM$SEND_EMAILプロシージャは、他のストアドプロシージャと同じくCALLキーワードで呼び出します。コマンド例は次のとおりです。

CALL SYSTEM$SEND_EMAIL(
'my_email_int',
'joe.doe@my_domain.com,
'Hello from Snowflake Alerting',
'My first email sent from Snowflake via SYSTEM$SEND_EMAIL stored procedure'

関数呼び出しの中でメールアドレスを改めて指定している点に注目してください。notification integrationのALLOWED_RECIPIENTSに含まれていないアドレスを指定した場合、メールは送信されません。

上記コマンドで届くメールは次のような見た目になります。

ストアドプロシージャが正常終了すると、**TRUE**が返ります。

Snowflakeから自動でメールを送信する

多くのSnowflakeユーザーは、アラートの自動化を実現したいと考えるはずです。どうすればよいでしょうか。

定番の実装パターンは、SYSTEM$SEND_EMAILを別のストアドプロシージャの中に組み込む方法です。外側のプロシージャでまず特定の条件を満たすかを確認し、満たしている場合にSYSTEM$SEND_EMAILを呼び出してメールを送ります。

チェック対象となる条件には、たとえば次のようなものがあります。

• Snowflakeタスクが一時停止（suspended）状態になっていないかを監視する
• Snowflakeストリームが想定より早く陳腐化（stale）した場合に通知を受け取る
• 特定のビジネスルールを検証する（例：機能Xを利用するには有料顧客である必要がある）

ここではSnowflakeタスクの監視を例に挙げてみましょう。一定のスケジュールで動くはずのタスク、あるいはタスクツリーがあるとします。タスクが一時停止状態となり実行が止まっていないかを把握したい、というケースです。タスクを変更する際には事前に一時停止し、変更後に再開する必要があるため、こうした状況は変更のたびに起こり得ます。

一時停止状態のタスクを検出するため、task_state_monitoringというストアドプロシージャを作成します。これは指定したタスクの状態を監視し、suspendedになっていればメールを送信するものです。show tasksコマンドで全タスクを取得し、ループで1件ずつ処理して、現在のstate変数が'suspended'かどうかを判定します。該当する各タスクごとにメールが送信されます。

プロシージャのコードは次のような形になります。

create or replace procedure task_state_monitor(task_name string)
returns varchar not null
language SQL
AS
$$
DECLARE
    task_state string;
    c CURSOR FOR SELECT "state" from table(result_scan(last_query_id())) where "name" = ?;
BEGIN
    show tasks;
    open c USING (task_name);
    fetch c into task_state;
    IF(task_state = 'suspended') THEN
        CALL SYSTEM$SEND_EMAIL(
            'my_email_int',

コードを展開

このストアドプロシージャを運用に乗せるには、Snowflakeタスクを作成し、任意のスケジュール（例：5分ごと、1日2回など）でtask_state_monitoringを呼び出すよう設定します。

もう1つの強力な通知機能がSnowflake Alertsです。スキーマレベルのオブジェクトで、データの内容やSnowflakeアカウント全般のさまざまな状況に応じてアクションを発火させられます。

代表的な使い道はコストアラートです。たとえば、特定の仮想ウェアハウスやSnowflakeサービスでアカウントのクレジット消費が急増したことを検知するアラートを作成できます。別の例として、ビジネスルールを検証し、検証が失敗したら通知を受け取るといった使い方もあります。アラートのアクションはメール送信に限らず、ルール検証に失敗した際にタイムスタンプ・検証種別・失敗内容を記録したレコードをログテーブルに挿入する、といったことも可能です

Snowflake Alertsは次の3つの要素で構成されます。

• アラートを発火させるcondition（条件）（例：クエリが0件を返す）
• 条件が満たされたときに実行するaction（アクション）（例：メール送信、テーブルへのレコード挿入）
• 条件を評価する頻度を定めるfrequency（実行間隔）の設定（例：24時間ごと）

Snowflake Alertの作成方法

ここでは、1日あたりのSnowflakeクレジット消費が100クレジットを超えたときにメールで通知するSnowflake Alertを作成します。

1時間ごとに評価されるアラートのコードは次のとおりです。

CREATE OR REPLACE ALERT credits_consumption
  WAREHOUSE = COMPUTE_WH
  SCHEDULE = 'USING CRON 0 1 * * * UTC'
  IF( EXISTS (
    select
        1
    from
        snowflake.account_usage.metering_history
    where
        start_time >= SNOWFLAKE.ALERT.LAST_SUCCESSFUL_SCHEDULED_TIME()
        AND SNOWFLAKE.ALERT.SCHEDULED_TIME()
    group by service_type
    having sum(credits_used) > 100

))

コードを展開

内容を順に見ていきましょう。

• アラートの実行に使う仮想ウェアハウスとしてCOMPUTE_WHを指定しています。
• CRON構文でスケジュールを定義し、毎日UTC午前1時に実行されるようにしています。
• 条件として、直近24時間のクレジット消費が100を超えた場合に「1」を含む1行を返すSQLクエリを指定しています。
• アクションとしてSYSTEM$SEND_EMAILプロシージャを呼び出しています。

アラートを作成しただけでは動かないため、再開（resume）操作が必要です。

alter alert credits_consumption resume;

これでアラートが稼働状態になります。

アラートのモニタリング

SnowflakeはACCOUNT_USAGEにALERT_HISTORYビューを用意しており、アラートの実行状況の監視に利用できます。

SELECT *
FROM snowflake.account_usage.alert_history
ORDER BY SCHEDULED_TIME DESC
;

このビューには各アラート実行の概要に加え、条件評価に使われたクエリのquery_id（CONDITION_QUERY_ID）と、対応するアクション側のクエリのquery_id（ACTION_QUERY_ID、すなわちSYSTEM$SEND_EMAILを呼び出すクエリ）が含まれます。

なお、アクションクエリと条件クエリはQUERY_HISTORYには現れません。中身を確認したい場合はRESULT_SCAN関数を使います。

1select * from table(result_scan('<action_query_id>'));

Snowflake Alertsの課金

メール送信やSnowflake Alerts自体に追加料金は発生しません。指定した仮想ウェアハウス上で条件評価クエリとアクションクエリを実行するのに要したコンピュート時間に対してのみ課金されます。

Snowflake Alertsのメリット

Snowflake Alertsを使うと、ビジネスロジックの検証と、その結果に応じたアクションの実行を一気にシンプルにできます。SYSTEM$SEND_EMAILでメール通知を発火させようとすると、SQLを明示的に実行し、結果を処理し、検証を行ったうえでメールを送る別のストアドプロシージャを作成する必要がありました。さらに、そのプロシージャをスケジュール実行するためのタスクも別途用意しなければなりません。

Snowflake Alertsなら、これらの工程がすべて1つのアラートオブジェクトの作成に集約されます。

メールではなく、チームのSlackチャンネルで通知を受け取りたいというユーザーも少なくありません。その方が、コラボレーションや対応が一気に速くなるからです。Slackには専用メールアドレス宛のメールをチャンネルに投稿する機能があるため、そのアドレスを使ってSnowflakeのnotification integrationを構成できます。

ステップ1：Slackチャンネル用のメールアドレスを発行する

まず、Slackチャンネルで使うメールアドレスを取得するために、新しいインテグレーションを追加します。チャンネル設定から「インテグレーション」をクリックし、「このチャンネルにメールを送信」を選択します。

ステップ2：Slackからの確認メッセージを受け取る

設定が完了すると、Slackからチャンネル内に自動でメッセージが投稿されます。

ステップ3：Slackのメールアドレスを使ってSnowflakeユーザーを作成する

Snowflakeは検証済みのSnowflakeユーザー宛にしかメールを送れないため、Snowflake上で新しいユーザーを作成し、Slackで取得したアドレスを割り当てます。そのうえでアドレスの検証を行います。

ステップ4：Slack側でSnowflakeのメールアドレスを検証する

検証メールはSnowflakeから直接Slackチャンネルに届きます。届いたメッセージのリンクをクリックすればアドレスの検証が完了し、以降はSYSTEM$SEND_EMAIL()ストアドプロシージャで利用できるようになります。Snowflakeの検証メールはSlack上で次のように表示されます。

先ほどnotification integrationを作成した際は、TYPEパラメータにEMAILを指定しました。実はこのパラメータにはQUEUEも指定できます。QUEUEを選ぶと、SnowflakeからAmazon SNS、Google Pub/Sub、Microsoft Azure Event Gridといった他のクラウドメッセージングサービスへ通知を送信できます。

この仕組みは、SnowflakeタスクやSnowpipeのERROR_INTEGRATIONパラメータと相性がよく、ERROR_INTEGRATIONはQUEUEタイプのnotification integrationを受け付けます。詳細はSnowflakeタスクのエラー通知に関するブログ記事をご覧ください。

Tomáš Sobotík・Senior Data Engineer & Snowflake SME at Norlys

Tomasは長年にわたるSnowflake Data SuperHeroであり、Snowflake全般に精通したエキスパートです。データ領域で10年以上のキャリアを持ち、その間にさまざまな業界・技術領域のプロジェクトで、Snowflakeのデータエンジニア、アーキテクト、管理者として活躍してきました。コミュニティのコアメンバーとして自らの知見を積極的に共有し、多くの人にインスピレーションを与えています。O'Reillyのインストラクターとしてライブ形式のオンライントレーニングも担当しています。