Snowflake Database Replication DR設計

Database Replicationは、Snowflakeのデータベースを 別のリージョンまたは別のクラウドプロバイダーのアカウントに複製する機能です。Failover Groupと組み合わせることで、 災害復旧（DR）やビジネス継続性（BCP）を実現する堅牢なアーキテクチャを構築できます。 データベースのレプリケーション自体は全エディションで使えますが、フェイルオーバー（セカンダリの昇格）・Failover Group・Client Redirectには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権限を持つロールでFailover GroupをPrimaryに昇格させます。 これは手動の操作で、Snowflakeが障害を検知して自動で切り替えることはありません。 昇格後、元のソースアカウント側のFailover Groupは読み取り専用のSecondaryに降格します。

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

-- 元のソースアカウント（Secondaryになった側）でスケジュール更新を再開
-- （フェイルオーバーするとSecondaryのスケジュール更新は停止する）
ALTER FAILOVER GROUP prod_dr_group RESUME;

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

RPO / RTO 設計

RPOはREPLICATION_SCHEDULEの間隔で決まりますが、セカンダリはプライマリより最大で間隔の2倍遅れることがあります。 10分間隔で設定した場合、最悪ケースで直近20分のデータが失われる可能性があります。 RPO Assurance（2026年9月GA）を有効にすると、スケジュールの代わりにSnowflakeが継続的にリフレッシュを管理し、RPO目標30分を目指します（フェイルオーバーは引き続き手動です）。 RTOは、障害を判断してフェイルオーバー（と接続の切り替え）を自分で実行するまでの時間で決まります。Snowflakeが自動で切り替えることはありません。 また、リフレッシュの実行中はフェイルオーバーできないため、その完了待ちや中断の時間もRTOに含まれます。

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

フェイルオーバー後にアプリケーションの接続先を手動で変更するのは運用負荷が高いため、 SnowflakeはClient Redirect（Connection Failover）機能を提供しています（Business Critical以上）。 アプリケーションが接続オブジェクトの接続URLで接続するようにしておけば、 ターゲットアカウントで ALTER CONNECTION ... PRIMARY を実行したときに接続先が新しいPrimaryアカウントに切り替わります。 Failover Groupを昇格しても接続は自動では切り替わらないため、両方を実行します。

-- 接続URLの形式（Client Redirect）
-- https://<org_name>-<connection_name>.snowflakecomputing.com

-- ソースアカウント：プライマリ接続を作成し、ターゲットへのフェイルオーバーを許可
CREATE CONNECTION prod_connection;
ALTER CONNECTION prod_connection ENABLE FAILOVER TO ACCOUNTS myorg.target_account;

-- ターゲットアカウント：セカンダリ接続を作成
CREATE CONNECTION prod_connection
  AS REPLICA OF myorg.source_account.prod_connection;

-- フェイルオーバー時（ターゲットアカウントで手動実行）：Primary接続の切り替え
ALTER CONNECTION prod_connection PRIMARY;

レプリケーション監視

-- レプリケーション遅延の推移の確認（Secondaryアカウントで実行）
SELECT timestamp, lag_seconds, primary_snapshot_timestamp
FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_LAG_HISTORY(
  REPLICATION_GROUP_NAME => 'prod_dr_group'));

-- リフレッシュ履歴と所要時間の確認
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,
  replication_group_name,
  SUM(credits_used) AS total_credits,
  SUM(bytes_transferred) / POWER(1024, 3) AS gb_transferred
FROM SNOWFLAKE.ACCOUNT_USAGE.REPLICATION_GROUP_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要件に合わせる：セカンダリの遅れは最大で間隔の2倍になるため、RPO = 10分なら REPLICATION_SCHEDULE = '5 MINUTE' 以下を設定し、遅延監視アラートを構成する
• Client Redirectを導入してアプリ側の変更を不要にする：アプリは接続URLで接続し、フェイルオーバー時は ALTER CONNECTION ... PRIMARY の実行だけで済むようにして、アプリケーションの再設定を排除する
• クロスリージョン転送コストを見積もる：異なるクラウドリージョン間の転送にはGB単位で課金されるため、初回フルスナップショットのコストを事前に試算する

問題で確認

よくある質問