クロスクラウドにおけるSnowflakeデータシェアリングの実装手法（23年版）
クロスクラウドでのデータシェアリング実装
はじめに
2024年9月に開催されたSnowflake World Tour Tokyoで、CCCMKホールディングスはクロスクラウドでのデータ共有に関する取り組みを発表させていただきました。本記事では、その実装アーキテクチャと実践から得られた知見を共有します。
クロスクラウドにおけるデータ共有の課題
今やクラウドサービスの選択肢は豊富で、多くの企業が複数のクラウドを目的に応じて使い分けています。例えば、機械学習基盤はGCP、基幹システムはAWSといった具合です。また企業間ではその企業が採用するクラウドプロバイダーが提供するストレージや独自のデータ転送手法、サードパーティ製品を活用したETLパイプラインの構築が必要とされてきました。
しかし、これらのアプローチは地味にエンジニアリソースを消費する要因となっています。パイプラインの構築と保守、セキュリティ要件への対応、さらには各クラウド固有の認証基盤や監視の仕組みへの対応など、多くの工数が必要です。
こうした課題に対し、Snowflakeはデータシェアリング機能という解決策を提供しています。ただし、異なるクラウド間での直接的なデータシェアには制限があります。本記事では、この制限を解決した効率的な実装例をご紹介します。
実装の全体像
本実装は以下の3つのフェーズで構成されています：
実装フェーズの全体像
| フェーズ | 主な作業項目 | 実装のポイント |
|---|---|---|
| 準備フェーズ | ・ミニDBの設計 ・必要最小限のデータセット定義 ・レプリケーション戦略の策定 |
・コスト最適化を考慮したデータ選定 ・権限管理の設計 ・更新頻度の検討 |
| 実装フェーズ | ・ミニDBへのデータコピーの実装 ・レプリケーション設定 ・データシェア設定 |
・最適な実装方式の選択 ・セキュリティ設定 ・エラーハンドリングの実装 |
| 運用フェーズ | ・監視体制の確立 ・定期的なメンテナンス ・パフォーマンスとコストの最適化 |
・モニタリング指標の設定 ・アラート基準の設定 ・定期的な効率化レビュー |
データコピー実装方式の比較
上記のプロセスにおいて、どの方式でレプリケーション用のデータコピーを実装するのか、以下の実装案をまとめました。
| 評価観点 | CTAS + Task | Dynamic Table(PV) | Materialized View(GA) |
|---|---|---|---|
| 設計アプローチ | △ ・命令的（手続き型） ・手動でのタスク管理 ・スケジュール化必要 |
◎ ・宣言的アプローチ ・結果のみを定義 ・複雑なクエリ可能 |
○ ・単一テーブルのみ ・複雑なクエリ不可 ・透過的な最適化 |
| 更新の仕組み | △ ・手動スケジュール ・明示的な更新処理 ・非決定的処理可能 |
◎ ・TARGET_LAGベース ・自動増分更新 ・決定的処理のみ |
◎ ・即時更新 ・ベーステーブルと同期 ・完全な整合性維持 |
| ユースケース | ○ ・シンプルな更新 ・カスタム処理必要時 ・完全制御の必要性 |
◎ ・パイプライン構築 ・複数テーブル結合 ・段階的データ変換 |
◎ ・クエリパフォーマンス重視 ・即時性が必要 ・透過的な最適化必要 |
| 制限事項 | △ ・すべて手動制御 ・運用負荷大 ・監視の仕組み必要 |
○ ・非決定的関数制限 ・Enterprise Edition必須 ・コスト考慮必要 |
△ ・単一テーブルのみ ・複雑なクエリ不可 ・柔軟性に制限 |
採用判断のまとめ
上記の表を見るとほぼ一択の選択肢なのですが、Dynamic Tableがプレビュー機能であることやMaterialized Viewが設計的に重めであることから、今回は、CTAS + Task で実装しました。
snowflakeでデータ連携しようということは早い段階で決まったのですが、
何を連携するかなかなか決まらず、最終的に一気に作らざるを得なくなったこともあり、一番シンプルな方式で実装する事となりました。
じっくり取り組める案件であれば、一般提供後という前提ではありますが、Dynamic Table で実装するのがベストと思います。
（ベストプラクティスに直したいけど、別段困ってる訳ではないので一番見直ししづらい・・）
運用管理の主要指標
| 監視カテゴリ | 監視項目 | アラート基準 | 対応方針 |
|---|---|---|---|
| データ同期 | ・レプリケーション遅延 ・同期成功率 ・エラー発生状況 |
・遅延60分以上：ALERT ・同期失敗：ALERT ・エラー検知：即時通知 |
・自動リトライ設定 ・手動同期手順確立 ・エラーパターン分析 |
| リソース使用 | ・ストレージ使用量 ・ウェアハウス効率 ・レプリケーションコスト |
・閾値超過：WARNING ・異常使用検知：ALERT ・コスト超過：通知 |
・自動クリーン ・リソース最適化 ・コスト分析 |
| タスク実行 | ・実行状態 ・完了時間 ・エラーメッセージ |
・実行失敗：ALERT ・遅延120分以上：WARNING ・エラー発生：即時通知 |
・タスク再実行 ・root cause分析 ・実行時間最適化 |
従来のストレージやファイル連携に比べた実装のメリット
| 施策 | メリット | 効果 |
|---|---|---|
| ミニDB構築 | ・レプリケーションコスト削減 ・転送データ量最小化 ・権限管理の簡素化 |
・コスト効率の向上 ・運用負荷の軽減 ・セキュリティ強化 |
| CTAS + Task採用 | ・シンプルな実装 ・明確な処理フロー ・柔軟な制御 |
・開発効率の向上 ・保守性の確保 ・トラブルシュート容易化 |
| 監視体制確立 | ・早期異常検知 ・自動アラート ・傾向分析可能 |
・安定運用の実現 ・問題の早期解決 ・継続的な改善 |
DBより1回も出さずに連携出来るのは控えめに言って便利過ぎる。
最適化されたアーキテクチャ設計
さて、そんな実装の話を踏まえつつ、全体の設計について説明していきます。
ミニDB戦略によるコスト最適化
データベース全体をレプリケーションするとデータ転送コストなど大きく発生するため、必要最小限のデータのみを含む「ミニDB」 を先ほどの手順に従い作成し、それをレプリケーション対象とする方式を採用しました。これにより以下の課題を解決しています：
- レプリケーションコストの最小化
- 不要なデータ転送の削減
- 権限管理の簡素化
-- 共有用ミニDBの作成
CREATE DATABASE share_minimized_db
COMMENT = 'Minimized DB for cross-cloud sharing';
-- 必要データのみを抽出したテーブル作成（CTAS）
CREATE OR REPLACE TABLE shared_minimal_data AS
SELECT
t.transaction_id,
t.transaction_date,
t.amount,
t.product_category,
t.region_code
FROM source_transaction_table t
WHERE t.transaction_date >= DATEADD(month, -3, CURRENT_DATE())
AND t.status = 'COMPLETED';
-- 定期更新タスクの設定
CREATE OR REPLACE TASK refresh_shared_data
WAREHOUSE = compute_wh
SCHEDULE = 'USING CRON 0 1 * * * Asia/Tokyo'
AS
CREATE OR REPLACE TABLE shared_minimal_data AS
SELECT /* 上記と同じSELECT文 */;
データフローの実装
-- レプリケーション設定
ALTER DATABASE share_minimized_db
ENABLE REPLICATION TO AWS_ACCOUNT = 'aws-account-id'
REGION = 'ap-northeast-1';
-- データシェア設定
CREATE SHARE partner_share;
GRANT USAGE ON DATABASE share_minimized_db TO SHARE partner_share;
GRANT SELECT ON TABLE share_minimized_db.public.shared_minimal_data
TO SHARE partner_share;
運用管理とモニタリング
データ量がよほど多くならない限り、ほとんど監視する必要性はないと考えていますが、
以下のような観点は確認するのが良いと思います。
重要な監視指標
-
データ同期の健全性
- レプリケーション遅延時間
- データ同期の成功率
- エラーの発生状況
-
リソース使用状況
- ストレージ使用量の推移
- コンピュートリソースの使用効率
- レプリケーションコストの変動
-- 統合モニタリングタスクの作成
CREATE OR REPLACE TASK monitor_replication_health
WAREHOUSE = monitor_wh
SCHEDULE = 'USING CRON */30 * * * * Asia/Tokyo'
AS
SELECT
'Replication Status' as metric_type,
database_name,
replication_status,
last_refresh_time,
DATEDIFF('minute', last_refresh_time, CURRENT_TIMESTAMP()) as delay_minutes,
CASE
WHEN DATEDIFF('minute', last_refresh_time, CURRENT_TIMESTAMP()) > 60 THEN 'ALERT'
ELSE 'OK'
END as status
FROM account_usage.replication_usage
UNION ALL
SELECT
'Resource Usage' as metric_type,
database_name,
'STORAGE_USAGE' as status,
CURRENT_TIMESTAMP() as check_time,
storage_bytes / (1024 * 1024 * 1024) as storage_gb,
CASE
WHEN storage_bytes > threshold_bytes THEN 'ALERT'
ELSE 'OK'
END as status
FROM database_storage_usage;
-- タスク実行状況の監視
SELECT
task_name,
state,
completed_time,
error_message,
CASE
WHEN state = 'FAILED' THEN 'ALERT'
WHEN DATEDIFF('minute', completed_time, CURRENT_TIMESTAMP()) > 120 THEN 'WARNING'
ELSE 'OK'
END as status
FROM table(information_schema.task_history())
WHERE task_name = 'refresh_shared_data';
今後の展望
Snowflakeのクロスクラウド機能は継続的に進化しています。今後は以下のような改善が期待されます：
- より直接的なクロスクラウドデータシェア（DCRで実装してるのに！）
- パフォーマンスの向上
- コスト効率の改善
また、弊社での実装もさらに連携対象が増えて運用負荷が増大した場合は、Dynamic Tableへの移行を検討することが有効な対応方法と考えています。（はよGAして！）
まとめと追記
本記事では、Snowflake World Tour Tokyo 2024での発表内容をベースに、クロスクラウドでのデータ共有の実装について解説しました。シンプルながら効果的なCTAS + Task方式の採用と、ミニDB戦略によるコスト最適化により、効率的なクロスクラウドデータ共有を実現しています。
実装方式の選択においては、チームの技術スタックや運用体制を考慮し、最もシンプルで保守性の高い方式を選択しました。必要に応じて段階的に最適化していく方針も、実践的なアプローチとして有効です。
追記
というようなことを書いてたら、23年9月にListing機能がGAされており、これによりクロスクラウド問題は大きく解消することが分かりました。と言う訳でこの実装は23年時点の情報として修正させていただきました！
弊社として当時取りうる選択肢として上記のアーキテクチャで実装しましたが、やはりsnowflakeの進化は早く、しっかり陳腐化しました笑
ちなみに最新構成案の記事はこちらです！
Discussion