
「Snowflake Openflow Connector利用の勘所」というタイトルで、DevelopersIO 2026 Tokyoにて登壇しました。 #devio2026
Snowflake Openflow Connectorを導入する際にハマりやすいポイントと対処法をまとめました。ネットワーク構成やソースDB側の準備、運用時の落とし穴まで、実装の勘所を紹介します。
2026.10.27
データ事業本部の笠原です。
2026/10/24 (土) に開催された「DevelopersIO 2026 Tokyo」にて、「Snowflake Openflow Connector 利用の勘所」というタイトルで登壇しましたので、資料を共有します。
スライド資料
概要
Snowflake Openflow Connectorを利用した際に、ハマったところと対処法をまとめてみました。
Snowflake Openflow Connectorを導入する際に以下の内容をチェックして進めていきましょう。
始める前
ORGADMINで規約承諾- 利用ユーザの
DEFAULT_ROLEはACCOUNTADMIN以外にして Runtime にアクセス - コネクタの利用条件等の制約を確認
ネットワーク構成
- SPCSから外部接続するためには「Network Rule と EAIの作成」「RuntimeロールにEAI権限付与」「RuntimeにEAIを関連付け」の3点を設定
- Business Criticalエディション利用なら、PrivateLinkを使って閉域接続 / そうでないなら、パブリックNW経由になるのでNLBを利用してIP制限等対策を
ソースDB側の準備
- ライセンス・ログ設定・ユーザはDB管理者と事前に合意した上で設定
- PostgreSQLはLogical Replication設定 / Publication設定
- OracleDBはGoldenGate / XStream 利用可否の確認の上、ARCHIVELOGモード / supplimental logging / STREAM_POOL_SIZE 等設定
- 連携対象となるテーブルは、ソースDB側でも指定する必要あり
動作した後
- スナップショットが来るのにCDCが来ない
- アーカイブログの保持期間等を確認
- アーカイブログが出力されないとそもそもSnowflakeへ反映されない
- 取込対象テーブルの追加順は「ソースDB側の設定」→「Snowflake側の設定」
- 順番を間違えると、エラーがないままデータ欠損が起きる
- ステータスが「Running」のままでも連携が止まっている場合は、Oracle側の問題かSnowflake側の問題か、切り分けが必要
- Oracleの場合は、「capture (Oracle)」→「outbound (Oracle)」→「Connector (Snowflake)」で確認
- それでもよくわからない場合は、Snowflake側のプロセスを深掘りして確認してみよう
- 監視と運用のルールを設定
- 基本的にConnectorは止めない
- 停止、再開でデータ欠落なく連携が追いつけるかどうかを本番運用前に試験して手順を確認しておくこと
後片付け
- 消したつもりになっていて、実は残っているリソースがないか注意
- destroy.sh (BYOCでのエージェント) / compute pool / スロット / エンドポイント
これからOpenflowを使うなら
- gen2で、構築手順をSQLで










