AWS入門ブログリレー2024〜AWS Clean Rooms編〜
2024.06.06当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』の61日目のエントリです。
このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。
では、さっそくいってみましょう。今回のテーマは『AWS Clean Rooms』です。
AWS Clean Roomsとは
企業間などで、データセットを完全に開示できないものの、互いにその個人情報を特定されない粒度の特徴を組み合わせることで有用なインサイトを得られるデータ活用のユースケースで使われるサービスです。
海外では個人が特定できる情報の取り扱いが非常に厳しくなっており、今後日本も含めてより多くの地域でその取り扱いの重要性が増してくると想像されます。
例えばウェブの広告施策だと、GDPRやCCPAなどの法規制を受け、ブラウザ側でサードパーティクッキーの廃止や制限が進んでいます。これにより、サードパーティクッキーを使用した広告施策が実施できなくなりつつあります。この代替手段として、データクリーンルームを使い企業や組織間で個人情報を侵害しない粒度に集計したデータセットを共有することで、ユーザーのプライバシーを守りつつ、最適化した広告を提供することにつながります。
システム上この仕組みを構築することはかなり難度が高いです。例えば両組織間で共通のインターフェースを持つ仕組みをしっかり擦り合わせて構築する必要があります。頑張って作ったとしても集計ロジックに不備がありデータから個人が特定されてしまえば、地域によっては非常に厳しい罰則が課される可能性があります。集計ロジックが完璧であったとしても、データ数が非常に少ない場合に個人を特定されてしまう場合もあります。
AWS Clean Roomsはこういったデータクリーンルーム構築に伴う非常に大きな悩みを解決するためのサービスです。例えばマネジメントコンソールから数クリックするだけで速やかにクリーンルームを構築でき、差分プライバシーなどデータ保護の仕組みも搭載されています。
AWS Clean Roomsの全体像
理解のため、2アカウント間でのクリーンルームのデータ連携方法を簡単な図で表すと以下のようになります。
アカウントは同一のコラボレーションに参加します。データコンシューマー側のアカウントは、コラボレーションを使い、データプロデューサーが公開しているテーブルに対して、設定された分析ルールの範囲でデータに対する検索を実行することができます。具体的には、コンソールからだとAmazon Athenaに似たUIの画面で、自分でSQLを記述するか、Analysis Builderによって分析を作成し、テーブルに対して実行できるのですが、こちらについては後ほどご紹介します。
より詳細にはAWS Black Belt Online Seminarで紹介されている以下の図が参考になります。
（引用元：AWS Clean Rooms AWS Black Belt Online Seminar）
コラボレーションには複数のアカウントが参加可能です。データソースのデータの場所はS3バケットで、Glueテーブルを介してデータが検索できることが前提とされています。AWS Clean Roomsにもテーブルという概念が登場しますが、どのような分析を許可するかという分析ルールをアタッチすることができるものになっています。分析結果の出力もS3バケットになります。コラボレーションは同一リージョンである必要がある点もポイントです。
基本的な使い方
以下のブログで、2アカウント間の設定例をご紹介しました。
概要としては、以下の流れになります。
- プロデューサーのアカウントで、AWS Clean Rooms用のサービスロールを作成する。
- プロデューサーのアカウントで、コラボレーションを作成する。
- プロデューサーのアカウントで、クエリするデータテーブルを準備する。
- プロデューサーのアカウントで、設定したテーブルへの分析ルールを設定する。
- プロデューサーのアカウントで、設定したテーブルをコラボレーションに関連付ける。
- コンシューマーのアカウントで、メンバーシップを作成し、コラボレーションに参加する。
- コンシューマーのアカウントで、クエリを発行し、データを取得する。
ユーザーガイドにも基本のセットアップ方法の記載があります。
コンシューマーのアカウントでは、以下のような画面からクエリを実行できます。
料金
料金はコンピューティングリソースあたりの課金になります。
UIがAmazon Athenaに似ているのでスキャン量課金かな？と一瞬思ってしまうかもしれませんが、課金形態が異なるので注意しましょう。
ほかのトピック
分析結果の活用
分析結果はS3バケットに保存されます。データの保存先のキープレフィクスが指定できるため、アドホックな分析のフェーズが終わってシステム化する場合はPython SDKからなどからその日のプレフィクスを指定して配置するなどするとよいかもしれません。
AWS Clean Rooms MLについて
re:Invent2023のキーノートで発表された新機能で、トレーニングした機械学習モデルをコラボレーションで公開し、パートナーが利用することができる機能です。
MLモデルはサービス内でネイティブに構築されるため、パートナーにMLモデルの構築のためにデータを共有する必要がありません。
今年4月に一般提供開始となっています。
AWS Clean Rooms Differential Privacyについて
re:Invent2023のキーノートで発表された新機能で、データベソースから統計的な出力を取得する際の差分プライバシーというプライバシー基準を満たすようにクエリにノイズを付与することにより、意味のある洞察を行うために十分な正確性を維持しつつ、個人の寄与を隠蔽したクエリ結果を出力する機能です。
AWS Clean Rooms Differential Privacyを使うことで、差分プライバシーを実装するための深い理解をしていなくても、AWS Clean Roomsのフルマネージド機能として利用することができます。
今年4月に一般提供開始となっています。
ほかのサービスとの使い分け
データを共有するという点では、同じように見えるサービスや機能がいくつかあるため、使い分けについても考察しておきます。
観点としては、公開範囲と共有するデータの粒度を考えると分かりやすいかと思います。
AWS Data Exchangeは、データセットを別のアカウントに一般公開することができるサービスです。このサービスの場合、利用できるユーザーであればサブスクリプション契約を結ぶことでだれでもデータセットにアクセスすることができます。一方でAWS Clean Roomsは、お互いにコラボレーションに参加したアカウントのユーザーだけが、許可された分析ルールの範囲内での分析結果のみにアクセスすることができます。
Redshiftのデータ共有は、あるRedshiftのインスタンス内のデータを別のRedshiftのインスタンスから参照できるようにする機能です。同一アカウントでも、クロスアカウントでも設定さえすれば互いにデータを参照することが可能です。安全なデータのみを共有に用途を制限するものではないため、加工済みの安全なデータのみ共有するようにするためには非常に厳しい管理が必要になります。例えばAmazon Redshiftデータ共有のアクセスと権限をAWS Lake Formationで一元管理することも可能ですが、組織のデータレイク内に別の組織のRedshiftが入ってくるのは個人的には違和感があるので、そのような場合はAWS Clean Roomsをインターフェースとして分離する方が良いと思います。
最後に
以上、『AWS 入門ブログリレー 2024』の61日目のエントリ『AWS Clean Rooms』編でした。 次回、6/7(月)は弊社平木佳介による『AWS Backup』編の予定です。
