[小ネタ] Snowflake と Fivetran を手動で接続してみた

こんにちは、データ事業本部のまっきーです。

Fivetran は SaaS や DB から DWH へのデータ同期を自動化する ETL サービスです。本記事は、Fivetran の Snowflake Destination(書き込み先)を手動でセットアップする手順と、その過程で踏みやすい設定まわりの落とし穴を整理します。

結論を先に

• Fivetran 単体サインアップから、Snowflake への接続を手動で構成できる。
• 書き込み先 DB に対する USAGE / CREATE SCHEMA 権限が既存ロールに付与されていないケースがあるので、事前確認 + 必要なら GRANT が必要。
• KEY_PAIR 認証が公式推奨だが、権限の関係で登録できない場合はパスワード認証で接続可能(廃止予告中だが現状は動く)。

やったこと

今回扱う範囲は以下の通りです。

1. Snowflake 側の接続用リソース (ロール・ウェアハウス・DB) を確認、必要なら GRANT
2. Fivetran 公式サイトから単体サインアップ
3. Fivetran 側で Snowflake への接続を構成 + 接続テスト

手順

Step 1: Snowflake 側の接続用リソースを確認

Fivetran が Snowflake に接続するために必要なリソースと情報をまとめます。今回は検証用に既に用意済みの以下を使うことにしました。

ロールの権限を確認する

まず使う予定のロール (FIVETRAN_ROLE) にどんな権限が振られているかを確認します。

SHOW GRANTS TO ROLE FIVETRAN_ROLE;

今回の環境では、ウェアハウス (FIVETRAN_WAREHOUSE の MODIFY/MONITOR/OPERATE/USAGE) と CREATE INTEGRATION ON ACCOUNT は既に付与されていました。Fivetran が Snowflake に書き込むための基本的な権限は揃っている状態です。

書き込み先 DB への権限を確認する

ただし、ここで見落としやすいのが 書き込み先 DB に対する権限 です。Snowflake の権限はアカウント / ウェアハウス / DB / スキーマ / テーブルの階層で別々に管理されるため、ロールに CREATE INTEGRATION ON ACCOUNT (アカウントレベル) があっても、特定の DB にスキーマやテーブルを作る権限 (DB レベル) は DB ごとに個別に GRANT する必要があります。

実際に書き込めるかを試すのが確実です。

USE ROLE FIVETRAN_ROLE;
USE DATABASE <DB_NAME>;
USE WAREHOUSE FIVETRAN_WAREHOUSE;
CREATE SCHEMA TEST_FIVETRAN_PERM;

今回の環境では以下のエラーが返りました。

SQL access control error:
Insufficient privileges to operate on database '<DB_NAME>'.
Your primary role FIVETRAN_ROLE must have CREATE SCHEMA granted on DATABASE <DB_NAME>.

FIVETRAN_ROLE には <DB_NAME> への権限が一切振られていない状態でした。これでは Fivetran が DB にスキーマを作れず、接続テストで失敗します。

不足権限を GRANT する

DB オーナー (今回の環境では SYSADMIN) に切り替えて、必要な権限を FIVETRAN_ROLE に振ります。

USE ROLE SYSADMIN;
GRANT USAGE ON DATABASE <DB_NAME> TO ROLE FIVETRAN_ROLE;
GRANT CREATE SCHEMA ON DATABASE <DB_NAME> TO ROLE FIVETRAN_ROLE;

USAGE は DB そのものを「見える」状態にするための権限、CREATE SCHEMA は配下にスキーマを作るための権限です。Fivetran はコネクタごとにスキーマを切ってその下にテーブルを作るので、スキーマ作成権限が必要です (スキーマ配下のテーブルは、スキーマ作成者である FIVETRAN_ROLE が自動的にオーナーになるので追加 GRANT は不要)。

GRANT 後、もう一度書き込みテストを実行して通れば準備完了です。

USE ROLE FIVETRAN_ROLE;
USE DATABASE <DB_NAME>;
CREATE SCHEMA TEST_FIVETRAN_PERM;  -- 成功
DROP SCHEMA TEST_FIVETRAN_PERM;    -- クリーンアップ

⚠️ 重要: 本記事は検証用途として自分の Snowflake ユーザーで Fivetran に接続していますが、本番運用では Fivetran 専用の Snowflake ユーザーを別途作成 するのが正しい運用です。SaaS 側に個人の認証情報を保存すると、退職・異動時の運用影響、監査ログの混乱、漏洩時の被害範囲拡大といったリスクがあります。検証用途以外では必ず専用ユーザーを切ってください。

Step 2: Fivetran 公式サイトから単体サインアップ

Fivetran 公式サイト (https://www.fivetran.com/) の Start free trial から、メールアドレスでサインアップします。trial は 14 日間で、ダッシュボード上には「Your 14-day account trial begins once the initial sync is complete」と表示されており、初回同期完了時点からカウントが開始 される仕様のようです。設定段階ではカウントは進みません。

Fivetran の料金プランの公式案内によると、Free Plan では月間 MAR (Monthly Active Rows) が 50 万行までは無料で利用できるとあり、trial 期間後も検証用途であれば継続利用の余地がありそうです。

サインアップ直後にオンボーディングアンケート (用途や使用予定の software 等) が数問続きます。これは Fivetran 側のレコメンドのためのものなので、実際に使う Source/Destination を素直に選んでおくとセットアップ画面でショートカットされて楽です。

Step 3: Fivetran 側で Snowflake 接続を構成

Fivetran のセットアップウィザードは 「Source (どこから取る) → Destination (どこに置く)」 の 2 段で進みます。Snowflake は Destination 側です。

接続情報の入力

Snowflake Destination 設定画面で以下を入力します。

Data processing location を Japan に変更すると AWS Region で ap-northeast-1 が選択可能になります。Snowflake と Fivetran の処理リージョンを揃えると、データ転送が同一リージョン内で完結します。

認証方式の選び方

Snowflake 公式は KEY_PAIR 認証 を推奨しており、Fivetran の Snowflake Destination 設定画面でも KEY_PAIR がデフォルトになっています。Snowflake は シングルファクター パスワード サインインを段階的に廃止する方針を示しているためです。

KEY_PAIR を使う場合、手元で秘密鍵 / 公開鍵を生成し、Snowflake のユーザーに公開鍵を登録します。ただし、共用 Snowflake アカウントでは公開鍵登録の権限が不足して詰まるケースがあります。 順を追って見ていきます。

# 秘密鍵生成 (パスフレーズなし、検証用)
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -nocrypt

# 公開鍵抽出
openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

抽出した公開鍵を Snowflake に登録します。

ALTER USER <自分のユーザー名> SET RSA_PUBLIC_KEY='<公開鍵の中身>';

今回の環境では以下のエラーが返りました。

SQL access control error:
Insufficient privileges to operate on user '<USER_NAME>'.
Your primary role <YOUR_ROLE> or one of your secondary roles
must have MODIFY PROGRAMMATIC AUTHENTICATION METHODS granted on USER <USER_NAME>.

これは 自分のユーザー設定 (パスワード / 公開鍵 / etc) の変更は管理者ロール (USERADMIN / SECURITYADMIN / ACCOUNTADMIN 等) でないとできない という Snowflake の権限設計によるものです。共用 Snowflake アカウントで自分が管理者ロールを持っていない場合、KEY_PAIR を自分で登録する手段がないケースがあります。

このため今回の検証では、パスワード認証で接続 することにしました。

注意: パスワード認証は廃止予告中ですが、現時点では使用可能です。ただし Fivetran 設定画面でも「Snowflake is blocking single-factor password authentication. We will be deprecating password authentication soon. Please use key_pair authentication.」と警告が表示されます。本番運用では必ず KEY_PAIR 認証 (および専用ユーザー) を使ってください。

接続テスト

設定が揃ったら、Load Virtual Warehouses ボタンで使用するウェアハウスを取得・選択します。これを押した時点で Fivetran が裏で Snowflake に接続を試みるので、ここで接続情報の正しさが最初に検証されます。

ウェアハウスを選択したら Save & Test ボタンを押下します。Fivetran が以下のテストを順次実行します。

• Host Connection
• Default Warehouse Test
• Database Connection
• Validate Internal Stage Access Test
• Permission Test

全てが緑になれば、Snowflake 側の接続は完了です。Step 1 で FIVETRAN_ROLE に GRANT した USAGE + CREATE SCHEMA が効いて Permission Test が通る形になります。

ハマりどころのまとめ

本文中で詳述したものを、事前回避のチェックリストとして整理します。

書き込み先 DB の権限は、ロールのアカウントレベル権限とは別

• ロールに CREATE INTEGRATION ON ACCOUNT や WAREHOUSE 権限があっても、特定 DB への USAGE / CREATE SCHEMA は DB ごとに個別 GRANT が必要。
• ロール側の権限確認 (SHOW GRANTS TO ROLE ...) と、書き込み先 DB への実機テスト (CREATE SCHEMA ...) の 両方 をやっておくと安全。

KEY_PAIR 認証の公開鍵登録は自分でできるとは限らない

• ALTER USER ... SET RSA_PUBLIC_KEY = '...' には MODIFY PROGRAMMATIC AUTHENTICATION METHODS 権限が必要。
• USERADMIN / SECURITYADMIN / ACCOUNTADMIN 等の管理者ロールが持つ権限で、通常のユーザーには付与されていないケースがある。
• 詰まったら「管理者依頼で GRANT してもらう」or「当面はパスワード認証で進める」の二択。

まとめ

Fivetran 単体サインアップから Snowflake への接続を手動で構成するルートをまとめました。Snowflake 側は権限 GRANT さえ整えれば接続テストは全パスする状態まで持っていけます。

その後の連載では、Fivetran 経由で Snowflake に取り込んだデータに対して AI_PARSE_DOCUMENT で本文抽出 → Cortex Search で検索 という流れを試していく予定です。

参考リンク

• Fivetran Snowflake Destination Setup - Fivetran 公式ドキュメント
• Snowflake Key-pair authentication and key-pair rotation - Snowflake 公式ドキュメント
• 前回までの記事:
  • Snowflake Cortex Search で PDF チャットボットを作ってみた
  • Snowflake Intelligence で統合 AI エージェントを組んでみた
  • Snowflake AI_EXTRACT で複数の文書種を構造化抽出してみた
  • Snowflake AI_EXTRACT を Stream + Task で自動化してみた
  • Snowflake Cortex Analyst の Semantic Model を 1 から自作してみた