ServiceNow 用Snowflakeコネクタのコストガバナンス¶

このトピックでは、 ServiceNow 用Snowflakeコネクタのコストガバナンスと最適なウェアハウスサイズを見つけるためのベストプラクティスを提供します。

コネクタのコスト測定¶

コネクタにデータインジェスチョンとストレージ専用の別アカウントがあり、そのアカウントに他のアクティビティ（インジェストしたデータを使用した、ユーザーによるクエリの実行など）がない場合は、アカウントレベルで全体のコストを読み取ることができます。詳細については、総コストの調査をご参照ください。

アカウントがコネクタ専用ではない場合や、さらにコストを調査する必要がある場合は、3つのコンポーネントの課金コストを別々に分析する必要があります。

コンピューティングコスト
ストレージコスト
データ転送コスト

これら3つのコスト構成要素の紹介については、総コストについてをご参照ください。

一般的な推奨事項¶

コネクタで発生するコストを取得するために、コネクタを使用するための専用アカウントを別途作成することをお勧めします。こうすると、コネクタで発生した正確なデータ転送を追跡できます。

コネクタに別アカウントを使用できない場合は、以下をお試しください。

ストレージコストの追跡を容易にするために、インジェストデータ保存用のデータベースを別に作成します。
正確なコンピューティングコストを得るために、コネクタ専用のウェアハウスを割り当てます。
オブジェクトタグをデータベースやウェアハウスで使用し、カスタムコストレポートを構築します。
サーバーレス構成を使用する場合は、 SERVERLESS_TASK_HISTORY ビューをクエリし、コネクタ名でフィルターし、 CREDITS_USED 列をチェックして、コストを取得できます。

コンピューティングコスト¶

コネクタ専用のウェアハウスを別途作成することをお勧めします。この設定により、ウェアハウス上にリソースモニターを作成することができます。モニターを使用して、メールアラートを送信したり、ウェアハウスを一時中断したりし、設定されたクレジットクォータを超えた場合にコネクタを停止させることができます。クレジットクォータ更新後、コネクタは自動的に再開されます。大量のデータをインジェストする構成では、クレジットクォータの設定が小さすぎると、コネクタがすべてのデータをインジェストしない場合があることに注意してください。

ウェアハウスで消費されたクレジットを確認する方法については、コンピューティングコストの調査をご参照ください。また、ウェアハウスにオブジェクトタグを割り当て、タグを使用してコストレポートを作成することもできます。

コネクタが使用するウェアハウスを他のワークフローが使用する場合は、ロールごとにコストを分割することができます。ロールによって使用量を分割するには、ウェアハウスの使用量を分割するクエリを使用し、 QUERY_HISTORY ビューに以下の WHERE 句を追加します。

WAREHOUSE_NAME = '<connector warehouse name>' AND
ROLE_NAME IN ('APP_PRIMARY', ‘<role created for the connector to ingest data>’)

Copy

クエリでは、コストの概算しかわかりません。

注釈

1つのネイティブアプリのみがウェアハウスを使用できるようにします。そうしないと、ネイティブアプリは同じロール名（APP_PRIMARY）を使用するため、異なるアプリケーションのコストを分割できません。

サーバーレスタスクを使用するように構成されたコネクタの場合は、 SERVERLESS_TASK_HISTORY ビューをクエリできます。このビューは、 CREDITS_USED と DATABASE_NAME の列を表示します。後者は、コネクタの名前に関するフィルタリングに使用できます。

ストレージコスト¶

ServiceNow 用Snowflakeコネクタは、データを2か所に保存します。

公開シェアから作成され、コネクタの内部状態を保持するコネクタデータベース。
インジェストされたデータが格納されるユーザー指定のスキーマ。

データストレージは、Snowflake Fail-safe 機能によっても使用されます。Fail-safeに格納されるデータ量は、コネクタによるテーブルの更新に依存します。ServiceNow からインジェストしたテーブルの行が頻繁に更新されたり、テーブル全体が再ロードされたりすると、データ量が増加します。通常、コネクタを設定してから7～10日後には、Fail-safeのデータ量が安定します（再ロードせず、インジェストしたデータのフローが一定であることが前提です）。

Snowsightでストレージの使用状況を確認する場合は、インジェストデータを格納するためのデータベースを別途用意することをお勧めします。こうすると、オブジェクト別のストレージ使用量のグラフをフィルターし、個別のデータベースによる使用量を表示できます。これは、 DATABASE_STORAGE_USAGE_HISTORY ビューをクエリし、コネクタが使用する両方のデータベースでフィルターすることでも実行できます。

コネクタに関連しない他のスキーマがデータベースに含まれている場合は、コネクタからインジェストしたデータ専用の特定スキーマのストレージ使用量をクエリできます。データベースおよびスキーマ名でフィルタリングし、ストレージ使用量で列を集計した後、 TABLE_STORAGE_METRICS ビューから情報を取得できます。

データ転送コスト¶

コネクタは、外部関数を使用して、 ServiceNow からデータを取得します。Snowflakeは、コネクタから ServiceNow へのリクエストのサイズに基づいて、コネクタによって生成されたエグレストラフィックに対してのみ課金します。ServiceNow からの応答は、Snowflake側でコストを発生させるものではありません。

データ転送の使用量に関する情報は、アカウントレベルですべての外部関数に対して集計された形でのみ利用可能です。転送されたバイト数にアクセスするには、 DATA_TRANSFER_HISTORY ビューを使用し、 EXTERNAL_FUNCTION 転送タイプでフィルターします。

コネクタインスタンスに最適なウェアハウスサイズの決定¶

コネクタに最適なウェアハウスサイズを見つけるには、 ServiceNow インスタンスのサイズ、有効なテーブル数、各テーブルを同期するスケジュールなど、コネクタのパフォーマンスに影響する要素を考慮する必要があります。たとえば、いくつかのテーブルしか有効でない場合、コネクタは並列化の恩恵を受けられない可能性があります。

すべてのテーブルを同期させる時間間隔など、測定可能な期待値を定義し、その期待値を満たす最小のウェアハウスサイズを選択することをお勧めします。幾十もの同期テーブルを持つ大量のインジェストしたデータの場合、デフォルトの推奨はLサイズのウェアハウスです。一方、コネクタを試行し、インジェスチョン用のテーブルを1つだけ有効にする場合は、XSサイズのウェアハウスで十分でしょう。ウェアハウスを縮小できるかどうかについては、ウェアハウス負荷のモニターをご参照ください。

指定された時間枠内でのコネクタの自動起動および停止¶

コストを削減するために、 STOP_CONNECTOR および RESUME_CONNECTOR プロシージャを呼び出して、指定された時間枠内（たとえば営業時間外）にのみコネクタを実行することができます。

サーバーレスタスクでコネクタの起動と停止を自動化することができます。たとえば、 UTC の営業時間外にコネクタを実行するには、次のクエリを使用します。

CREATE TASK start_connector_after_business_hours
   SCHEDULE USING CRON 0 17 * * MON-FRI Europe/London
   AS CALL <my_connector_servicenow>.PUBLIC.RESUME_CONNECTOR();

CREATE TASK stop_connector_before_business_hours
   SCHEDULE USING CRON 0 9 * * MON-FRI Europe/London
   AS CALL <my_connector_servicenow>.PUBLIC.STOP_CONNECTOR();

Copy