第5章 データコラボレーション(Data Collaboration, 10%)
🎯 この節の学習目標
ここまで学んだTime Travel・Fail-safeは「同じ場所での時間軸の保護」でした。しかし、リージョン全体の障害に備えたり、別リージョンのユーザーにデータを届けたりするには、物理的に別の場所にデータのコピーを維持する仕組みが必要です。それがレプリケーション(replication)です。
レプリケーションの単位は大きく2つあります。
| 単位 | 内容 |
|---|---|
| データベースレプリケーション | 個別のデータベースをレプリケーションする |
| アカウントレプリケーション(レプリケーショングループ/フェイルオーバーグループ) | 複数のデータベースに加え、ユーザー・ロール・ウェアハウス・シェアなどアカウントレベルのオブジェクトもまとめてレプリケーションする。グループ単位でリフレッシュ間隔をスケジュールできる |
💡 具体例:データベースレプリケーションの基本操作
-- プライマリ側:データベースをレプリケーション可能として有効化する
ALTER DATABASE sales ENABLE REPLICATION TO ACCOUNTS myorg.dr_account;
-- セカンダリ側:プライマリのレプリカとしてデータベースを作成する
CREATE DATABASE sales AS REPLICA OF myorg.prod_account.sales;
-- セカンダリ側:リフレッシュを実行してプライマリの変更を取り込む
ALTER DATABASE sales REFRESH;リフレッシュは差分ベースで行われ、タスクなどでスケジュール実行するのが一般的です(フェイルオーバーグループでは REPLICATION_SCHEDULE で自動化できます)。セカンダリはリフレッシュ時点までのデータを持つため、リフレッシュ間隔が目標復旧時点(RPO)の目安になります。
災害復旧(DR)の要となるのがフェイルオーバー(failover)です。プライマリ側のリージョンで障害が起きたとき、セカンダリをプライマリに昇格させ、書き込み可能なデータベースとして業務を継続します。障害復旧後に元のリージョンへ役割を戻す操作がフェイルバック(failback)で、実体は「元プライマリを再びプライマリに昇格し直す」操作です。
📝 試験のポイント
レプリケーション自体は多くのエディションで利用できますが、フェイルオーバー/フェイルバック(およびフェイルオーバーグループ)を使えるのはBusiness Criticalエディション以上です。「DR構成(フェイルオーバー)に必要なエディションはどれか」と問われたらBusiness Criticalと答えられるようにしておきましょう。セカンダリが昇格するまで読み取り専用である点もあわせて押さえます。
図:レプリケーションとフェイルオーバー。復旧後はフェイルバックで元のリージョンに役割を戻せる
| 用途 | 説明 |
|---|---|
| 災害復旧(DR) | リージョン規模の障害に備え、別リージョンにセカンダリを維持。フェイルオーバーで業務継続(Business Critical) |
| リージョン間のデータ共有の実現手段 | 5-3で学んだとおり、ダイレクトシェアは同一リージョン・同一クラウド内が前提。別リージョンのコンシューマに共有するには、コンシューマ側リージョンへデータベースをレプリケーションし、そこからシェアを作成する(リスティングの自動フルフィルメントは、これをSnowflakeが自動で行う仕組み) |
| アカウント移行 | 別リージョン・別クラウドへアカウントを引っ越す際の移送手段として使う |
すべてのオブジェクトがレプリケーションされるわけではありません。代表的な整理は次のとおりです。
| レプリケーションされる | レプリケーションされない |
|---|---|
| permanentテーブル・transientテーブル、ビュー、シーケンス、ファイルフォーマット、ストアドプロシージャ/UDFなどデータベース内のオブジェクト。アカウントレプリケーションではユーザー・ロール・ウェアハウス等も対象にできる。内部名前付きステージも、グループベースのレプリケーション(レプリケーション/フェイルオーバーグループ)で対象化でき、ディレクトリテーブルが有効ならステージに登録されたファイルもレプリケートされる | temporaryテーブル(セッション限りのため)、外部テーブル、ユーザーステージ・テーブルステージ上のファイルなど。イベントテーブルなど一部のオブジェクトにも制限がある |
課金は次の3要素で構成されます。
フェイルオーバーでセカンダリを昇格させても、BIツールやアプリケーションの接続文字列が旧プライマリを向いたままでは業務を再開できません。クライアントリダイレクト(Client Redirect)は、この接続の切り替えを担う機能です。
✅ この節のまとめ
問1. レプリケーションにおけるセカンダリデータベースの説明として正しいものはどれか。
正解:B
セカンダリは読み取り専用のレプリカで、リフレッシュ(手動またはスケジュール)を実行した時点までのプライマリの変更を保持します。Aの双方向同期という仕組みはなく、書き込めるのは常にプライマリだけです。Cは逆で、別リージョン・別クラウドのアカウントへのレプリケーションこそが主目的です。Dはリフレッシュという明示的な同期の仕組みと矛盾し、リフレッシュ間隔分の遅延(RPO)が存在します。
問2. リージョン障害時にセカンダリをプライマリに昇格させて業務を継続する「フェイルオーバー」を利用するために必要なエディションはどれか。
正解:C
フェイルオーバー/フェイルバック(およびフェイルオーバーグループ、クライアントリダイレクト)はBusiness Criticalエディション以上の機能です。AのStandardとBのEnterpriseではフェイルオーバーは利用できません(レプリケーション自体はより広いエディションで利用可能ですが、昇格による業務継続はできません)。Dはエディション要件を無視しており誤りです。エディションと機能の対応(例:Time Travel 90日=Enterprise以上、フェイルオーバー=Business Critical以上)は整理して覚えましょう。
問3. レプリケーションの課金・特性に関する説明として正しいものを2つ選べ。
正解:BとC
レプリケーションの課金は「データ転送+リフレッシュのコンピュート+セカンダリのストレージ」の3要素です(B・C)。Aは誤りで、レプリケーションは別リージョンへの物理コピーであり、同一アカウント内でメタデータだけを作るゼロコピークローンとは根本的に異なります。Dも誤りで、temporaryテーブルや外部テーブル、ユーザーステージ・テーブルステージ上のファイルなどレプリケーションされないオブジェクトがあります(内部名前付きステージはグループベースのレプリケーションで対象化でき、ディレクトリテーブルが有効ならファイルもレプリケートできます)。
問4. フェイルオーバー時に、BIツールやアプリケーションの接続文字列を変更することなく新しいプライマリアカウントへ接続を切り替えたい。使用すべき機能はどれか。
正解:A
クライアントリダイレクトは、アカウント固有URLの代わりに接続オブジェクトが提供する組織レベルのURLを使わせることで、フェイルオーバー時に接続オブジェクトの向き先を切り替えるだけでクライアントを新プライマリへ誘導する機能です。Bのリーダーアカウントは、Snowflakeアカウントを持たない相手とのデータ共有の仕組みです。Cのゼロコピークローンは同一アカウント内の複製であり、接続の切り替えとは無関係です。DのData Exchangeは招待制のデータ交換ハブであり、DRの機能ではありません。