TVerでデータシステムなど担当しております黒瀬です。
この記事では、弊社のサービスとして運用しているTVer ID の会員情報を保持するDB（以下、会員DB）のデータの集計にかかる時間を短縮した施策についてご紹介します。
サマリ
DatastreamとPolicy Tagを利用することで、プライバシー保護を考慮しつつBigQueryで会員DBを高速で集計できるようにしました。
背景
TVerでは、GKEでセルフホストしているRedashを利用してデータ集計や分析を行っています。
また、弊社では分析用のデータはBigQueryに集約する方針のため、基本的にはRedashでの集計はBigQueryのSQL構文でクエリを作成しています。
このRedashでクエリを実行するタスクの一つとして、弊社が提供しているTVer IDの会員の動向を集計・分析するというものがあります。
TVer IDの会員DBは、Amazon RDSで構築したMySQLでホストしており、RedashからはEC2で作成した踏み台経由でアクセスしていました。
また、Redashからは個人情報を含むフィールドをマスクするためのviewにクエリを実行することで、プライバシーも考慮した仕組みとしていました。
課題
この従来の構成では下記の課題がありました。
- Redashで作成するクエリは大部分がBigQueryのSQLであるにも関わらず、会員DBはMySQLのSQL構文でクエリを作成する必要があり、仕様の差異に留意する必要があったり突合しにくいといったことから、運用がしにくい問題がありました。
- これは会員DBのスペック上の制約でもありますが、従来の構成では会員DBに対して実行したクエリのレスポンスに数時間かかっていました。結果、集計担当者がRedashで実行したクエリの様子を見に行く必要があったりRedashのワーカーを長時間占有するなど、分析が滞る原因となっていました。
- 稀に調査などでフィールドをマスクしていないデータを見る必要がある際は、Redash経由ではなく踏み台などから直接クエリを実行しなければなりませんでした。
そこで、これまで利用していたRedashの上で、高速かつセキュアにデータを集計するための仕組みについて検討しました。
方針
上記の課題を解決するため、次のような方針で進めることにしました。
- BigQueryにデータを同期することで、MySQLでクエリを書かなくていいようにしつつ、サーバレスのクエリ実行環境であるBigQueryによるレスポンス改善を目指しました。
- フィールドをBigQuery側で隠蔽することで、分析の要件に合わせてフィールドへのアクセス権やマスキングをBigQueryで制御できることを目指しました。
ここからは、これらを実現するための詳細についてご紹介いたします。
アプローチと効果
DatastreamでMySQLからBigQueryにデータを同期する
DatastreamはGoogle Cloudで手軽にデータ変更キャプチャ(CDC; Change Data Capture)によるデータ同期ができるサービスです。今回はこのサービスを利用してMySQLのデータを都度BigQueryに同期することで、BigQueryで会員DBのデータを分析できるようにしました。
導入も非常に簡単で、今回はMySQLでbinlogを設定し、踏み台の認証情報をDatastreamで指定するだけでBigQueryにデータを同期できるようになりました。
この施策により、BigQueryのSQLで会員DBのデータを分析できるようになり、またこれまで数時間かかっていたクエリも、MySQLのクラスタのスペックによらず、十数秒で結果が返ってくるようになりました。
BigQueryに同期したテーブルのフィールドにPolicy Tagを付与する
Policy TagはBigQueryのフィールド単位で権限やマスキング方法の制御ができる機能です。
このPolicy Tagが関係するロールとしてはMasked ReaderとFine-Grained Readerの2つがあります。Policy Tagが付与されているフィールドを含むテーブルへのクエリは、クエリを実行したアカウントがどのロールが付与されているかによって次のように結果が変わります。
- Masked Readerが付与されているアカウントが実行した場合: Policy Tagが付与されているフィールドがマスキングされて結果が返ってくる
- Fine-Grained Readerが付与されているアカウントが実行した場合: Policy Tagが付与されているフィールドがマスキングされずに結果が返ってくる
- いずれのロールも付与されていないアカウントが実行した場合: クエリは権限エラーになる
今回は、氏名やメールアドレスといった会員DBに記録されている個人情報ごとに、マスク方法を適切に設定したPolicy Tagを作成し、該当するフィールドへ付与しました。
そして、Redashでクエリを実行するためのサービスアカウントとしては想定する用途によって2つを用意しました。
- 通常の分析ではマスキングされたデータを利用するため、Masked Readerが付与されているアカウントを利用
- 調査などでマスキングされていないデータを利用する場合は、Fine-Grained Readerが付与されているアカウントを利用
この施策により、BigQueryに閉じた設定でプライバシーを考慮したアクセス権限の制御ができるようになりました。
まとめ
今回、Datastreamの導入によって会員DBのデータの分析にかかる時間を効率化することができました。また、Policy Tagによってプライバシー保護もロールによる制御へ簡潔化することができました。
一方で、Datastreamによるデータ同期ではコストも相応にかかってくるため、今後はこのコストを抑える施策について検討していきたいと思います。
TVerではエンジニアを募集しています
今回ご紹介したデータシステム以外にもバックエンドやフロントエンドなど多彩なフィールドでエンジニアを募集しています！ご興味ある方はぜひ以下の採用サイトからご連絡ください！
