❄️

Snowflake Openflow（SPCS版）を試す ― 設定手順とコストのリアル

Shuhei Miwa

2025/12/04に公開

Snowflake

openflow

tech

 はじめにSnowflake OpenflowのSPCS版がついにプレビューされました。

これまでOpenflowを利用するには、BYOC（Bring Your Own Cloud）方式でAmazon Web Services (AWS) など自前のクラウド環境に構築する必要があり、その構築のハードルから検証や導入を見送っていた方も少なくなかったはずです。
今回のSPCS版では、Openflowの設定・管理をすべてSnowflake上で完結できるようになり、こうした構築面の負担が大幅に軽減されます。
本記事では、SPCS版Openflowのセットアップ手順を紹介するとともに、BYOCとの違いやSPCSでは実際にどの程度のコストが発生するのかについてもまとめています。特に「最小構成でどのくらいクレジットが消費されるのか？」は気になる方が多いと思いますので、その点も実測結果を交えて解説します。
あわせて、以前公開したBYOC版の検証記事も参考にしてください。（PostgreSQLコネクタの設定も取り扱っています）
https://zenn.dev/nttdata_tech/articles/7b338bf9f21f67

https://zenn.dev/nttdata_tech/articles/a0884fa9b8cef6
OpenflowのSPCSに関するSnowflakeのドキュメントはこちらを参照してください。

https://docs.snowflake.com/user-guide/data-integration/openflow/about-spcs
この記事は、NTTデータ Snowflakeアドベントカレンダーの4日目です。

 1. 環境準備まず、Snowflake Openflowを動かすために必要な設定を確認します。

全体像は以下のとおりです。


タスク
説明


1. コアSnowflakeのセットアップ
デプロイメントを作成する前に、Openflow管理者ロールや権限、ネットワーク構成を準備します。

2. デプロイメントの作成
コアSnowflakeの構成後、Openflowデプロイメントを作成します。必要に応じて、ログやメトリクスを保存するイベントテーブルを設定します。

3. ランタイムロールの作成
デプロイメント作成後、ランタイム用のロールと外部アクセス統合を作成します。

4. ランタイムを作成する
作成したランタイムロールを利用してランタイムを構築します。

5. Openflowコネクタを使用してデータソースを接続する
ランタイム上でコネクタを構成し、データソースと接続します。

引用：Openflowについて - Snowflakeのデプロイメント

 Openflowの構成要素Openflowの仕組みを図で整理すると、理解しやすいです。

引用：Openflowについて
Openflowを利用するには、主に「デプロイメント」と「ランタイム」の2つを理解する必要があります。今回取り扱うSPCS版は、上記の図、右下に該当します。
デプロイメント（Deployment）

Openflowの基盤そのもので、ランタイムをどこに構築するかを定義します。

以前は「BYOC（Bring Your Own Cloud）」としてAWSなどの自前VPC上に構築する必要がありましたが、SPCS（Snowflake Provisioned Compute Service）の登場により、Snowflake上に直接デプロイできるようになりました。
ランタイム（Runtime）

コネクタを実際に動かし、データソースと連携処理を行う実行環境です。

ランタイムに紐づくランタイムロールに対して、外部アクセス統合を許可することで、ランタイムが外部リソースへ接続できるようになります。
👉 イメージとしては、デプロイメント = Openflowの箱（場所）、ランタイム = その箱の中で動く実行環境と考えると分かりやすいでしょう。
それでは、具体的な設定手順に進みます。

 1.1 コアSnowflakeのセットアップまずは、Openflowを利用するための基本設定を行います。
Openflow 管理ロールを作成

USE ROLE ACCOUNTADMIN;

CREATE ROLE IF NOT EXISTS OPENFLOW_ADMIN;
GRANT CREATE ROLE ON ACCOUNT TO ROLE OPENFLOW_ADMIN;
GRANT ROLE OPENFLOW_ADMIN TO USER <OPENFLOW_USER>;

Openflow 管理ロールに必要な権限を付与

Openflowでは特定のアカウントレベルの権限が必要になります。

USE ROLE ACCOUNTADMIN;

GRANT CREATE OPENFLOW DATA PLANE INTEGRATION ON ACCOUNT TO ROLE OPENFLOW_ADMIN;
GRANT CREATE OPENFLOW RUNTIME INTEGRATION ON ACCOUNT TO ROLE OPENFLOW_ADMIN;
GRANT CREATE COMPUTE POOL ON ACCOUNT TO ROLE OPENFLOW_ADMIN;

Snowflakeデプロイメントネットワークルールの作成

アカウントレベルのネットワークポリシーが有効な場合は、以下を実行します。

USE ROLE ACCOUNTADMIN;

-- 必要なデータベースとスキーマを作成    
CREATE OR REPLACE DATABASE OPENFLOW;
CREATE OR REPLACE SCHEMA OPENFLOW;
USE DATABASE OPENFLOW;

-- 必要なネットワーク ルールを作成
CREATE NETWORK RULE ALLOW_OPENFLOW_SPCS
   MODE = INGRESS
   TYPE = IPV4
   VALUE_LIST = ('10.16.0.0/12');

-- ネットワークルールをネットワーク ポリシーに追加
ALTER NETWORK POLICY <YOUR_ACCOUNT_LEVEL_NETWORK_POLICY_NAME> ADD ALLOWED_NETWORK_RULE_LIST= (ALLOW_OPENFLOW_SPCS);

BCRバンドル2025_06の有効化（無効化している場合）
-- 特定のバンドルのステータスを確認
call SYSTEM$BEHAVIOR_CHANGE_BUNDLE_STATUS('2025_06');

-- バンドルが無効になっている場合は、有効にする
call SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2025_06');


 1.2 デプロイメントの作成次に、Openflowデプロイメントを作成します。
先ほど作成したロール（OPENFLOW_ADMIN）にスイッチします

Openflowを選択し「Launch Openflow」をクリック。

先ほどOPENFLOW_ADMINロールを付与したユーザでサインイン。

Openflowの管理画面に遷移します

「Deployments」タブから「Create deployment」をクリック。

Deployment locationで「Snowflake」を選択。

Deployment access制御設定では、ロールを細かく指定できます。今回は検証のためデフォルトにしました。

「Create deployment」をクリック。私の環境では20分ほどで完了しました。

（オプション）イベントテーブルの設定

デフォルトではアカウントイベントテーブルが使用されますが、Openflow専用に設定することも可能です。
OPENFLOW_ADMIN ロールに必要な権限を付与

USE ROLE ACCOUNTADMIN;

-- <DATABASE>.<SCHEMA>は、イベント テーブルを格納するデータベースとスキーマを指定
GRANT USAGE ON DATABASE <DATABASE> TO ROLE OPENFLOW_ADMIN;
GRANT USAGE ON SCHEMA <DATABASE>.<SCHEMA> TO ROLE OPENFLOW_ADMIN;
GRANT CREATE EVENT TABLE ON SCHEMA <DATABASE>.<SCHEMA> TO ROLE OPENFLOW_ADMIN;

イベントテーブルを作成し、Openflowデータプレーン統合に関連付け

USE ROLE OPENFLOW_ADMIN;

-- イベントテーブルを作成
CREATE EVENT TABLE IF NOT EXISTS <DATABASE>.<SCHEMA>.EVENTS;
SHOW OPENFLOW DATA PLANE INTEGRATIONS;

-- <OPENFLOW_DATAPLANE_NAME>の確認
 SHOW OPENFLOW DATA PLANE INTEGRATIONS;

--　関連付け
ALTER OPENFLOW DATA PLANE INTEGRATION
  <OPENFLOW_DATAPLANE_NAME>
  SET EVENT_TABLE = '<DATABASE>.<SCHEMA>.EVENTS';


 1.3 ランタイムロールの作成続いて、ランタイムを動かすためのロールを作成します。
ランタイムロールの作成
USE ROLE OPENFLOW_ADMIN;
CREATE ROLE IF NOT EXISTS OPENFLOW_RUNTIME_ROLE_<RUNTIMENAME>;
GRANT ROLE OPENFLOW_RUNTIME_ROLE_<RUNTIMENAME> TO ROLE OPENFLOW_ADMIN;

ランタイムロールに権限付与
-- データ取り込みに使用する予定の既存のウェアハウスを使用するための権限
GRANT USAGE, OPERATE ON WAREHOUSE <OPENFLOW_INGEST_WAREHOUSE> TO ROLE OPENFLOW_RUNTIME_ROLE_<RUNTIMENAME>;

--  Snowflakeオブジェクトを使用、作成、またはアクセスするための権限
GRANT USAGE ON DATABASE <OPENFLOW_SPCS_DATABASE> TO ROLE OPENFLOW_RUNTIME_ROLE_<RUNTIMENAME>;
GRANT USAGE ON SCHEMA <OPENFLOW_SPCS_SCHEMA> TO ROLE OPENFLOW_RUNTIME_ROLE_<RUNTIMENAME>;

ネットワークルール、外部アクセス統合の作成

ネットワークルールと外部アクセス統合を用いて、ランタイムの外部リソースへのアクセスを管理します。
USE DATABASE <OPENFLOW_DATABASE>;
-- NWルールの作成
CREATE OR REPLACE NETWORK RULE OPENFLOW_<RUNTIME_NAME>_NETWORK_RULE
    MODE = EGRESS
    TYPE = HOST_PORT
    VALUE_LIST = ('comma separated list of host:port pairs');

-- 外部アクセス統合を作成
CREATE OR REPLACE EXTERNAL ACCESS INTEGRATION OPENFLOW_<RUNTIME>_EAI
   ALLOWED_NETWORK_RULES = (OPENFLOW_<RUNTIME_NAME>_NETWORK_RULE)
   ENABLED = TRUE;

-- ランタイムロールに外部アクセス統合へのアクセス権を付与
GRANT USAGE ON INTEGRATION OPENFLOW_<RUNTIME_NAME>_EAI TO ROLE OPENFLOW_RUNTIME_ROLE_<RUNTIME_NAME>;


 1.4 ランタイムを作成する最後に、ランタイムを作成します。
「Create Runtime」を選択。


パラメータを入力


設定項目の例：

引用：Openflow のセットアップ - Snowflake デプロイメント: ランタイムの作成


パラメータ
説明


ランタイム名
ランタイムの名前を入力します。

デプロイメント名
1.2で作成したデプロイメントを指定します。

ノードタイプ
ノードサイズを指定します。

最小/最大ノード
スケール範囲を指定します。

ランタイムロール
1.3で作成したロールを指定します。

使用ロール
必要に応じて追加で付与します。

外部アクセス統合
必要に応じて、1.3ランタイムロールの作成の外部アクセス統合を選択して、外部リソースへのアクセスを許可します。

作成が完了すると（私の環境では5分程度）、以下のように表示されます。

Runtimesタブから作成済みランタイムを選択すると、認証後に設定画面へ遷移できます。


 2. BYOC版とSPCS版の比較・所感
 2.1 セットアップ面の違いBYOCとSPCSのセットアップ作業を改めて整理してみました

この図からもわかるように、SPCS版は利用者の技術的ハードルを大きく下げ、誰でもセットアップしやすくなった という印象を受けました。このシンプルさは、セットアップだけでなく、運用面にも共通していると考えます。

 2.2 コストの違いBYOC版
Deployment/RuntimeをAWS上のEC2で稼働させるため、Snowflake クレジットに加えて AWS の EC2・EKS・VPC の利用料が発生
運用環境がSnowflakeとAWSに分離するため、コスト管理が煩雑

SPCS版
実行基盤をすべて Snowflakeが提供するため、課金はSnowflakeクレジットに完全一本化


 2.3 実際に1日動かしてみたコスト試しに、SPCS版Openflowを約1日稼働させたときのクレジット消費を調べてみました。

今回は ランタイムは作成済みですが、コネクタを設定せず、実際の処理は一切実行していません。つまり、これは純粋に Control Pool + Small Runtime（最小ノード=1）の維持コストです。
対象: Control Pool + Small Runtime (最小ノード=1)

SELECT 
    *
FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY
WHERE SERVICE_TYPE = 'OPENFLOW_COMPUTE_SNOWFLAKE';



日付
種別
消費クレジット


2025-10-01
Control Plane
2.64 (CPU_X64_S:0.11/H)

2025-10-01
Runtime（最小サイズ）
2.64(CPU_X64_S:0.11

合計

5.28

このように、最小構成でも1日あたり約5クレジットほどかかることが分かります。

Runtime は管理画面から停止できるので、使わないときは止めておくのがおすすめです。

一方、Control Plane は現時点ではユーザ側で明示的に止められないようなので、このあたりは今後のアップデートに期待ですね。

 まとめ本記事では、SPCS版 Openflow のセットアップ手順を紹介しました。
BYOC と SPCS の両方を検証した結果、やはり 「Snowflake だけで完結できるシンプルさ」 は大きな魅力だと感じます。これまでの BYOC 方式では、VPC 設計や EKS 構築などクラウド基盤の知識が不可欠で、PoC の段階でつまずくケースも少なくありませんでした。
一方、SPCS 版ではこれらの前提作業が不要になり、Snowflakeの画面から数クリックでOpenflow が動き出すという体験が得られます。その結果、以下のような変化が期待できます。
SPCSベースのフロー構築が当たり前になることで、より多くのユースケースがOpenflowベースにシフトしていく
Snowflake Cortex AIで扱うデータの前処理や取り込みをOpenflowが担うことで、AIワークロード全体がSnowflake内で完結する
Openflowを触ってみたいけれど、BYOCはハードルが高かったという方にとって、SPCS版は非常に強力な選択肢になるはずです。

タスク	説明
1. コアSnowflakeのセットアップ	デプロイメントを作成する前に、Openflow管理者ロールや権限、ネットワーク構成を準備します。
2. デプロイメントの作成	コアSnowflakeの構成後、Openflowデプロイメントを作成します。必要に応じて、ログやメトリクスを保存するイベントテーブルを設定します。
3. ランタイムロールの作成	デプロイメント作成後、ランタイム用のロールと外部アクセス統合を作成します。
4. ランタイムを作成する	作成したランタイムロールを利用してランタイムを構築します。
5. Openflowコネクタを使用してデータソースを接続する	ランタイム上でコネクタを構成し、データソースと接続します。

パラメータ	説明
ランタイム名	ランタイムの名前を入力します。
デプロイメント名	1.2で作成したデプロイメントを指定します。
ノードタイプ	ノードサイズを指定します。
最小/最大ノード	スケール範囲を指定します。
ランタイムロール	1.3で作成したロールを指定します。
使用ロール	必要に応じて追加で付与します。
外部アクセス統合	必要に応じて、1.3ランタイムロールの作成の外部アクセス統合を選択して、外部リソースへのアクセスを許可します。

日付	種別	消費クレジット
2025-10-01	Control Plane	2.64 (CPU_X64_S:0.11/H)
2025-10-01	Runtime（最小サイズ）	2.64(CPU_X64_S:0.11
合計		5.28

NTT DATA TECH

NTT DATA公式アカウントです。技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。当社のサービスなどについてのお問い合わせは、お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。

設定によりコメント欄が無効化されています