5
1

Snowflakeのレプリケーション(複製)に関するメモ (Architect)

Last updated at Posted at 2024-03-20

これは何?

Snowflakeのレプリケーションに関してまとめてみたメモ。
レプリケーション(replication)は日本語マニュアルでは「複製」と表現される。
あとはプレビュー中の機能が多い印象。

公式情報

  • レプリケーション(複製)
    • レプリカを作成する機能
      • 元データ(ソース)を「プライマリオブジェクト」という
      • 元データ(ソース)を持つアカウントを指して「ソースアカウント」という
      • レプリケーション先を「セカンダリオブジェクト」という
      • レプリケーション先のアカウントを指して「ターゲットアカウント」という
    • AWS、GCP、Azureのリージョン全般でサポートされる
    • グループ
      • 複製グループ
        • 1つ以上のターゲットアカウントにユニットとして複製される、ソースアカウント内のオブジェクトの定義済みコレクション
        • 複製されたオブジェクトへの「読み取り専用」アクセスを提供する
      • フェールオーバーグループ
        • フェールオーバーも可能な複製グループ
        • セカンダリフェールオーバーグループが、プライマリフェールオーバーグループに昇格すると、「読み取り/書き込み」アクセスが利用可能になる
    • グループを使わない複製/フェールオーバーもある
      • ALTER DATABASE設定できる
        • ALTER DATABASE <name> ENABLE REPLICATION TO ACCOUNTS <account_identifier>
        • ALTER DATABASE <name> ENABLE FAILOVER TO ACCOUNTS <account_identifier>
      • グループを使った複製に移行したい場合は、先に無効にする必要がある
    • エディション差分
      • 複製自体は全エディションで使用できる
      • 一部機能はBusiness Critical以上で利用できる
        • アカウントオブジェクト(データベースおよび共有以外)複製
        • フェールオーバーグループ
        • Tri-Secret Secureで保護されたデータ
  • 複製できるオブジェクト
  • 複製スケジュール
    • スケジュールによる自動更新が推奨されている
      • REPLICATION_SCHEDULEパラメーターで設定する
    • 一度に1回の更新のみが実行される
    • 次回の更新がスケジュールされているときに更新がまだ実行中の場合、現在実行中の更新が完了後に次回の更新が遅れて開始される
    • 更新の実行中は、セカンダリフェールオーバーグループをプライマリグループに昇格できない
    • ターゲットアカウントでスケジュールされた複製を一時停止してから昇格する
    • スケジュールされた複製を一時停止しても、現在進行中の更新操作は停止されない
      • 複製処理が完了後、以降のスケジュールが停止される
  • 下位エディションのアカウントへの複製
    • デフォルトではエラーになりうる
      • デフォルトではBusiness Critical(またはそれ以上)のアカウントから、機密データを下位エディションのアカウントに誤って複製することを防ぐ動きになる点に注意する
      • その手のデータ(HIPAA HITRUST規制、PHI データ)が含まれているときに複製しようとするとエラーになる
    • エラー回避
      • CREATE <オブジェクト>ALTER <オブジェクト> のSQLの実行時にIGNORE EDITION CHECK句を含めることで、エラーの回避は可能(デフォルトの動作を上書きする)
  • 複製に関する考慮事項 (いっぱいある...)
    • オブジェクトは、1つのフェールオーバーグループにのみ存在できる
    • 複製先が異なる場合は、1つのオブジェクトは複数の複製グループに所属できる
    • オブジェクトは、フェールオーバーグループと複製グループの両方に含めることはできない
    • セカンダリ(レプリカ)オブジェクトを、プライマリ複製グループまたはフェールオーバーグループに追加することはできない
    • 複製の権限
      • デフォルトではACCOUNTADMINで各種処理を実行できる
      • カスタムロールで実行したい場合は以下の権限を考慮
        • 複製グループのOWNERSHIP
        • フェールオーバーグループのOWNERSHIP
        • CREATE REPLICATION GROUP (複製グループを作成する権限)
        • CREATE FAILOVER GROUP (フェールオーバーグループを作成する権限)
        • FAILOVER (セカンダリフェールオーバーグループを昇格する権限)
        • REPLICATE (セカンダリグループを更新する権限)
        • MODIFY (オブジェクトの設定やプロパティを変更する機能)
        • MONITOR (オブジェクト内の詳細を表示する権限)
    • 複製グループ間での複製と参照
      • ダングリングリファレンス/dangling referencesに注意する
        • 要はオブジェクト間の依存関係に関するの話
          • BY_NAME (CTASを実行するとき、AS以降に指定するテーブル名とか)
          • BY_ID (ストレージ統合、外部ステージとか)
          • BY_NAME_AND_ID (マテリアライズドビューとか)
        • 依存関係を持っているオブジェクトが複製時に存在しなかった等の理由でエラーになる可能性がある
        • OBJECT_DEPENDENCIES
          • オブジェクトの依存関係を確認する際に参照
        • ストリームの考慮点
          • こんなエラーが出る
            • Primary database: the source object ''<object_name>'' for this stream ''<stream_name>'' is not included in the replication group. Stream replication does not support replication across databases in different replication groups.
          • 回避策
            • プライマリデータベースに、ストリームとそのベースオブジェクトの両方を含めておく
            • ストリームを含むデータベースと、ストリームが参照するベースオブジェクトを含むデータベースが、同じ複製グループかフェールオーバーグループに含まれていること
        • ネットワークポリシーの考慮点
        • シークレットの考慮点
          • 以下を単一の複製グループまたはフェイルオーバーグループで指定する
            • シークレットを含むデータベース
            • シークレットを参照するUDFsやプロシージャを含むデータベース
            • シークレットを参照する統合を
        • 複製およびTime Travel
          • セカンダリデータベース用に新たにTime Travel(タイムトラベル)、Fail-safe(フェールセーフ)が作成される
          • プライマリデータベースとは独立している
        • 複製と外部テーブル
          • 複製しようとするとエラーが発生する
            • 003906 (55000): SQL execution error: Primary database contains an external table '<database_name>'. Replication of a database with external table is not supported
          • 回避策
            • 複製されていない別のデータベースに外部テーブルを移動する
            • プライマリデータベースのクローンを作成し、クローンから外部テーブルを削除してから、クローンデータベースを複製する
            • ターゲットアカウントでセカンダリデータベースを昇格した後、データベースに外部テーブルを再作成する
          • プライマリに外部テーブルが存在する状態でセカンダリに降格(セカンダリ側の操作でセカンダリがプライマリに昇格)した場合、エラーが発生する
            • 003958 (55000): SQL execution error: Secondary database contains an external table '<table_name>'. Replication of a database with external table is not supported.
          • 回避策
            • セカンダリになるデータベース内に外部テーブルが含まれないようにしておく
        • 複製とストリーム
          • 以下のストリームはサポートされない
            • 外部テーブル
            • 共有から作成したデータベースのテーブル/ビュー
            • 異なる複製グループ/フェールオーバーグループに、ストリームとソースオブジェクトが存在する(分離されている)場合
              • ストリームとそのストリームが参照するオブジェクトは同じグループに入れておく必要があるということ
            • データ重複の回避
              • ここに書いてある事例は見ておくとよさそう
            • ストリーム複製およびTime Travel
              • ここに書いてある事例(図)は見ておくとよさそう
        • 複製とタスク
    • 複製経由以外の方法でターゲットアカウントにオブジェクトを作成した場合
      • ターゲットアカウントがソースアカウントからリフレッシュされると、グローバル識別子を持たないターゲットアカウント内にある OBJECT_TYPES リストのすべてのアカウントオブジェクト型が削除される
  • 複数のアカウント間にわたるデータベースとアカウントオブジェクトの複製
    • アカウントとデータベースオブジェクトの複製を有効にし、オブジェクトを更新する手順が書いてある
      • こちら参照
      • ソースアカウントでフェールオーバーグループを作成
      • ターゲットアカウントでフェールオーバーグループをレプリカとして作成
      • その後、初回複製はスケジュールが設定されていれば自動で実施される
    • アカウントオブジェクトとデータベースの複製
      • ORGADMIN権限で以下の実行が必要
        • SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');
    • ターゲットアカウントのスクリプトによって作成されたオブジェクトにグローバル IDs を適用する
      • 複製経由「以外」の方法でターゲットアカウントにアカウントオブジェクトを作成すると、リフレッシュ時に削除される
      • これを回避する時の方法が書かれてある
        • 初期複製の前に、ターゲットアカウントにのみ存在するユーザーまたはロールを手動でソースアカウントに再作成する
        • SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME関数を使用して、両方のアカウントで同じ名前を持つオブジェクトをターゲットアカウントでリンクする
        • ユーザーおよびロールの初期複製を行う
  • API 統合のリモートサービスの更新
    • Snowflakeアカウント毎に統合のID/アクセス管理(IAM)エンティティが必要になる
    • ソースアカウントで設定した時と同じ要領でターゲットアカウント用の設定が必要
    • 各クラウドベンダー毎の設定方法に従って対応する
  • 複数のアカウントにわたるセキュリティ統合の複製
  • ステージ、パイプ、ロード履歴の複製
    • こちらは全般的にプレビュー機能とのこと
  • 複製コストについて
    • ターゲットアカウントで費用が発生する
    • データ転送
      • リージョン間でデータを転送するのでそのコストがかかる
      • こちら参照
    • コンピューティングリソース
      • データをコピーする際にSnowflakeが提供するコンピュートリソースを使用するのでそのコストがかかる
      • こちら参照
        • Table 5: Serverless Feature Credit Table
    • ストレージコスト
    • 実際にかかったコスト
    • 複製に失敗した時
      • 失敗までに消費したリソースのコストはもちろんかかる
      • 最初の複製またはリフレッシュ操作が失敗する前にコピーされたデータは、その後のリフレッシュ操作(14日以内に実行された場合)で再利用できる
  • アカウントオブジェクトのフェールオーバー
    • セカンダリフェールオーバーグループをプライマリフェールオーバーグループに昇格
      • ALTER FAILOVER GROUP...PRIMARYを実行
    • ターゲットアカウントでスケジュールされた複製を再開
      • ALTER FAILOVER GROUP...RESUMEを実行
  • ALTER FAILOVER GROUPについて
    • フェールオーバーグループのプロパティ変更のために使用する
      • ソースアカウントから実行する場合
        • セカンダリフェールオーバーグループの自動更新の複製スケジュールを設定または更新する
        • 複製とフェールオーバーが有効になっているターゲットアカウントを追加または削除する
        • 共有またはデータベースを別のフェールオーバーグループに移動する
        • 他、名前変更など
      • ターゲットアカウントから実行する場合
        • セカンダリフェールオーバーグループをプライマリに昇格する
          • オブジェクトのフェールオーバーグループをフェールオーバーする
        • ソースアカウントからターゲットアカウントのオブジェクトを手動更新する
        • スケジュールされた複製を停止/再開する
    • 必要な権限
      • REFRESH
        • フェールオーバーグループのOWNERSHIPREPLICATE
      • PRIMARY
        • フェールオーバーグループのOWNERSHIPFAILOVER
      • データベースをフェールオーバーグループに追加する
        • データベースのMONITOR
      • フェールオーバーグループに共有を追加する
        • 共有のOWNERSHIP

ざっくりポイント

  • セカンダリデータベースは、プライマリとは異なるクラウドベンダーおよびリージョンに配置することができる
  • セカンダリは読み取り専用
    • 昇格してプライマリになると書き込みができる
  • レプリケーション時のデータ転送とコンピュートリソースのコストがかかるのはターゲットアカウント(セカンダリ)側
  • 外部テーブルに注意
  • スケジュールによる自動更新が基本
  • 下位エディションへの複製に注意

所感

ん〜なんか難しい。
あんま使わないからイメージも湧きづらい...かといって試すのも結構重いか。

プレビュー機能も多いから、実践的に使われているものなのかどうかよくわからん。
リージョンまたぎやクラウドベンダーまたぎのシェアのためには必須の機能なので、どちらかというとその目的のために使われているのかな(というか使わざるを得ない)

5
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
1