Snowflake Database Replication DR設計

Database Replicationは、Snowflakeのデータベースを 別のリージョンまたは別のクラウドプロバイダーのアカウントに複製する機能です。Failover Groupと組み合わせることで、 災害復旧（DR）やビジネス継続性（BCP）を実現する堅牢なアーキテクチャを構築できます。Business Critical Edition以上で利用可能です。

Primary / Secondary アーキテクチャ

SnowflakeのレプリケーションはPrimary-Secondaryモデルで動作します。 Primaryデータベース（またはFailover Group）が書き込み可能な正系で、 Secondaryは読み取り専用の複製です。 Secondaryは定期的にPrimaryから増分スナップショットを受信して同期します。

┌──────────────────────────────┐     レプリケーション     ┌──────────────────────────────┐
│  Source Account (US-EAST-1)  │ ──────────────────────→ │  Target Account (EU-WEST-1)  │
│                              │    増分スナップショット     │                              │
│  [Primary]                   │                         │  [Secondary / 読み取り専用]     │
│   ├─ DB: analytics           │                         │   ├─ DB: analytics (replica)   │
│   ├─ DB: raw_data            │                         │   ├─ DB: raw_data (replica)    │
│   ├─ Roles / Users           │                         │   ├─ Roles / Users (replica)   │
│   └─ Network Policies        │                         │   └─ Network Policies (replica)│
└──────────────────────────────┘                         └──────────────────────────────┘
        ↑ 通常運用は Primary で実行                          ↑ DR発動時に Primary に昇格

レプリケーションの種類

Failover Group の作成

-- ソースアカウントでFailover Groupを作成
CREATE FAILOVER GROUP prod_dr_group
  OBJECT_TYPES = DATABASES, ROLES, USERS, WAREHOUSES, NETWORK POLICIES, INTEGRATIONS
  ALLOWED_DATABASES = analytics, raw_data
  ALLOWED_INTEGRATION_TYPES = SECURITY INTEGRATIONS
  ALLOWED_ACCOUNTS = myorg.target_account
  REPLICATION_SCHEDULE = '10 MINUTE';

-- ターゲットアカウントでSecondary Failover Groupを作成
CREATE FAILOVER GROUP prod_dr_group
  AS REPLICA OF myorg.source_account.prod_dr_group;

-- 手動でレプリケーションを実行（テスト用）
ALTER FAILOVER GROUP prod_dr_group REFRESH;

フェイルオーバー手順

DR発動時は、ターゲットアカウント側でFailover GroupをPrimaryに昇格させます。 昇格後、元のソースアカウント側のFailover GroupはSecondaryに降格します。

-- ターゲットアカウントでPrimaryに昇格（DR発動）
ALTER FAILOVER GROUP prod_dr_group PRIMARY;

-- フェイルバック：元のソースアカウントで再びPrimaryに戻す
-- （ターゲットアカウントで変更されたデータが逆方向にレプリケートされた後に実行）
ALTER FAILOVER GROUP prod_dr_group PRIMARY;

RPO / RTO 設計

RPOはREPLICATION_SCHEDULEの間隔で決まります。 10分間隔で設定した場合、最悪ケースで直近10分のデータが失われる可能性があります。 RTOはフェイルオーバーコマンドの実行時間に依存し、 データベースのサイズよりもメタデータの量（テーブル数・ビュー数等）に影響されます。

Client Redirect（接続リダイレクト）

フェイルオーバー後にアプリケーションの接続先を手動で変更するのは運用負荷が高いため、 SnowflakeはClient Redirect（Connection Failover）機能を提供しています。 Connection URLにOrganizationレベルのURLを使用することで、 フェイルオーバー時に自動的に新しいPrimaryアカウントにリダイレクトされます。

-- Organization URL形式（Client Redirect対応）
-- https://<org_name>-<connection_name>.snowflakecomputing.com

-- Connection（接続オブジェクト）の作成
CREATE CONNECTION prod_connection
  AS REPLICA OF myorg.source_account.prod_connection;

-- Primary接続の切り替え
ALTER CONNECTION prod_connection PRIMARY;

レプリケーション監視

-- レプリケーション遅延の確認（Secondaryアカウントで実行）
SELECT SYSTEM$REPLICATION_LAG('analytics');

-- リフレッシュ履歴と所要時間の確認
SELECT
  replication_group_name,
  phase_name,
  start_time,
  end_time,
  DATEDIFF('SECOND', start_time, end_time) AS duration_sec,
  primary_snapshot_timestamp
FROM SNOWFLAKE.ACCOUNT_USAGE.REPLICATION_GROUP_REFRESH_HISTORY
WHERE start_time >= DATEADD(DAY, -7, CURRENT_TIMESTAMP())
ORDER BY start_time DESC;

-- レプリケーションのクレジット消費監視
SELECT
  start_time::DATE AS usage_date,
  database_name,
  SUM(credits_used) AS total_credits,
  SUM(bytes_transferred) / POWER(1024, 3) AS gb_transferred
FROM SNOWFLAKE.ACCOUNT_USAGE.REPLICATION_USAGE_HISTORY
WHERE start_time >= DATEADD(MONTH, -1, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY usage_date DESC;

Edition要件まとめ

DR設計ベストプラクティス

• Failover Groupにロール・ネットワークポリシーを含める：データベースだけ複製してもRBAC設定が欠落するとアクセスできないため、OBJECT_TYPESにROLES/USERS/NETWORK POLICIESを含める
• 定期的なDRドリル（訓練）を実施：四半期ごとにフェイルオーバー→フェイルバックの手順を実行し、RTOの実測値を記録する
• REPLICATION_SCHEDULE をRPO要件に合わせる：RPO = 10分なら REPLICATION_SCHEDULE = '10 MINUTE' を設定し、遅延監視アラートを構成する
• Client Redirectを導入してアプリ側の変更を不要にする：Organization URLを使用し、フェイルオーバー時のアプリケーション再設定を排除する
• クロスリージョン転送コストを見積もる：異なるクラウドリージョン間の転送にはGB単位で課金されるため、初回フルスナップショットのコストを事前に試算する

問題で確認

よくある質問