こんにちは。藤です。
truestar では Prepper Open Data Bank という名前で収集・加工済みのオープンデータを無料で公開しています。
先日（2023年5月17日）にナウキャストさん主催のイベントで
『データプロバイダ側から見た Snowflake Marketplace』（登壇資料は SpeakerDeck で公開中）
というタイトルで登壇し、その時にも軽く触れていたのですが、Prepper Open Data Bank がデータ共有基盤として活用している Snowflake Marketplace でのデータ共有の仕組みを少し詳しく説明してみます。
Secure Data Sharing
Marketplace でデータ共有を行う場合、Secure Data Sharing という仕組みを使います。
公式ドキュメントには以下のように書かれています。
Secure Data Sharingにより、アカウント間で実際のデータのコピー、または転送は されません 。
簡単に絵にしてみると下のようなイメージです。
Secure Share をされた場合、データコンシューマ側からは、自身の環境内にあたかもそのデータベースがあるかのように見えます。
しかし、実際にはデータプロバイダのデータベースに対して、データコンシューマにクエリする権限を与えているだけであり、コンシューマ側の環境にはデータベースはありません。
結果として、プロバイダは権限のコントロールを行い、直ちに共有を停止することができます。契約終了後にコンシューマのデータを回収したり、削除を依頼する必要もありません。
Secure Data Sharing とリージョン
少し細かく見てみます。
結論を先に言うと、Secure Data Sharing は同一クラウドかつ同一リージョン内でしか行えません。
Prepper Open Data Bank の場合、メインの環境は Snowflake の AWS Tokyo リージョンにあります。
データコンシューマの Snowflake アカウントが AWS Tokyo リージョンにあれば簡単です。
しかし・・・
データコンシューマが AWS Osaka リージョンだったり、Azure Tokyo リージョンだったりすると、そのままでは共有できません。
異なるリージョンのコンシューマにデータ共有を行う場合、そのリージョンにアカウントを作り、そこにレプリケーションを作ることになります。
こんな感じです。
複製のためのアカウント作成作業は若干手間ですね・・・
しかし、Marketplace にはその手間を軽減するため、Region Availability という設定があり、そこで Global Avialability や Data Product Fulfillment to Available Regions のAutomatic というオプション選択で複製の自動化が可能になっています。これらはデータ共有方法による利用制限があります。少し複雑なのでここでは説明を省きます。Global Avialability については前回のブログでも触れていますが、その他詳細は公式ドキュメントで・・・
Secure Data Sharing での課金の仕組み
大前提として、Marketplace でのデータ代の話ではありません。データ代はデータプロバイダが共有するデータごとに有償無償様々ありますのでご注意ください。※PODB は全データ無償です！！！
ここでは Snowflake Marketplace に関連するインフラでの課金について説明します。
シンプルに同一リージョンのケースから見てみます。
先述した通り、データコンシューマ側にはデータベースは存在していません。
従って、ストレージ費用が発生するのは、データプロバイダのみになります。例えば、行動ログや IoT センサーログなどのビッグデータを Marketplace 経由で入手したとしても、使わない限りはストレージ費の課金は発生しません。
一方、コンシューマのA社やB社が共有されたデータにクエリする場合、そのコンピュート費用はA社、B社それぞれにかかります。プロバイダには発生しません。
もちろん Snowflake なので、同じデータベースに対して A 社と B 社の処理が同時に発生したとしても、競合して遅くなる、なんてことは起こりえません。
プロバイダにとってもコンシューマにとっても非常に合理的な課金体系になっています。素晴らしい！
次に別のリージョンの場合を見てみましょう。
プロバイダ側では、各リージョンのアカウントに複製を作る必要がありました。そのためのコストが追加で発生します。
上の図の右側では新たに三つの費用が発生しています。
- 複製
- データ転送
- ストレージ
異なるリージョンからのリクエストに応えるには、データプロバイダ側にこれらの追加コストが発生することになります。
しかし、高頻度（ニアリアルタイムや日次など）でのデータ更新が必要ではないならば、複製とデータ転送のコストは限定的です。また、ストレージはコンピュートコストに比べると安価であり、例えば PODB だと23年4月時点での総容量が 34GB でしたが、これは AWS Tokyo リージョンで月額1ドル弱でした。テラバイトを大きく超えるようなデータを扱わない限りストレージ費用は微々たるものだとは思います。
結局のところ、最もコストがかかるのはデータ利用時のクエリであり、そのコストはコンシューマが負担するものなのでプロバイダに費用には影響がありません。
※PODB の実際のコストについては先述のスライドの中でも公開していますので参考にしてみてください。『データプロバイダ側から見た Snowflake Marketplace』（P15-18）
また、コンシューマにとっては、プロバイダの元データが別のリージョンにあるかどうかは関係なく、同じリージョン内に複製されたデータを見ているので、コストも同じリージョンで計算される形になっており非常にシンプルです。
プロバイダの視点に戻ると、コスト抑制のためにデータを展開するリージョンを絞ることも可能ですし、何をもってコスパ良しとするかはケースバイケースなのでどちらが良いとは言えませんが、非常に簡単に世界中のリージョンからのリクエストに応えることができることもあり、PODB ではどのリージョンからの申請にも応えるようにしています。
なお、非常に細かい話ですが、複製とデータ転送にかかる費用はレプリケーション先にある環境（セカンダリアカウント）側で請求されます。さらに細かく言うと
- レプリケーションにかかるコストはデータ転送・コンピューティングリソースのいずれもターゲットアカウント (セカンダリアカウント) 側で課金される
- データ転送の金額はソースアカウント (プライマリアカウント) 側のリージョンの金額で、ソースアカウントからの Egress (外向き) のトラフィックについて課金される
ということだそうです。課金されるのはセカンダリですが、データ転送費用はプライマリ側の金額で決まります。
まとめ
ホント、Snowflake のサポートの神対応は半端ないです。まだの方は是非一度使ってみてください。Snowflake がさらに好きになると思います。
（つらつら書きながら、実は『共有の仕組み』よりも『サポートの神対応』のほうを伝えたかったのかも、と思ったり。まあそれでもいいか。）
それではまた！
