カバー株式会社CTO室データ分析基盤チームのエンジニアのUです。
カバー株式会社では、公式アプリ「ホロプラス」や公式ECサイトといった自社サービスに加え、タレントの皆さんが日々活動する「YouTube」など、多岐にわたるプラットフォームから絶え間なくデータが生まれ続けています。これらの膨大なデータを一箇所に集約し、分析するための基盤として、弊社ではAIデータクラウド製品である「Snowflake」を利用しています。
また、Snowflakeの強力なデータ操作機能を全社で安全に活用するためには、過剰な権限付与や意図しないデータ操作を防ぐための設計が不可欠です。弊社では、機能をただ制限するのではなく、Snowflakeの強みを活かしながら、セキュアで自由な分析環境を両立するガバナンスを構築しています。
本記事では、カバーにおけるデータ基盤の全体像をご紹介します。あわせて、各プロジェクトが安全かつ自由にデータを活用できるよう、弊社がSnowflake上でどのように精緻なガバナンスを設定しているのか、その「アクセスコントロールの運用術」について詳しく解説します。
カバーにおけるデータアーキテクチャの全体像
多種多様なデータの収集（Extract & Load）
カバーでは、多種多様なサービスから生成されるデータを、データ基盤の中心であるSnowflakeに一元集約しています。
データを抽出・ロードするETL処理の手法は、データソースの特性に合わせて使い分けています。たとえば、一般的なSaaSやデータベースからの抽出には、マネージドなETL製品である「TROCCO」や「Airbyte」を活用しています。一方で、YouTube APIを利用した複雑なデータ取得などは、自社AWS環境に構築した独自のバッチ処理で対応しています。また、Snowflakeのネイティブなデータ連携機能を利用することもあります。
これらの多様な手法を駆使して、あらゆるデータをSnowflake上で利用できる状態にしています。
dbtを活用したデータ加工（Transform）
Snowflakeに集約された生データは、各データソースで形式が異なり、欠損や重複も含まれるため、そのままでは分析用途には適していません。そこで弊社では、データ変換ツールとして「dbt（data build tool）」を活用しています。
dbtを用いることで、生データのクレンジングから各ステークホルダーが利用しやすい形式への変換までを、すべてSQLベースでモデリングできます。モデル間の依存関係は ref() による宣言から自動でDAGとして解決されるため、数百規模のモデルになっても実行順序を人が管理する必要はありません。さらに、依存グラフをもとに変更の影響範囲を事前に可視化でき、影響のあるモデルだけを選択的に再実行することも可能なため、複雑化しがちな加工パイプラインでも安全に変更・運用できる体制を整えています。
これらのdbt処理は、AWS上のECS（Fargate）タスクとして定期バッチで自動実行するようにしております。冒頭でも触れた通り、生データには欠損や重複、想定外の値が混入することは発生するもので、また連携元のシステム障害などにより想定したタイミングでデータが届かないケースも起こり得ます。そこでdbtの機能である「dbt test」や「Source Freshness」も加工処理に合わせて実施し、データ品質と鮮度の監視を自動化しています。
たとえば「dbt test」では、主キーのユニーク性やNOT NULL制約、カラム値が想定された範囲・カテゴリに収まっているかといった検査を各モデルに対して実行し、加工後データの欠損や重複を検知しています。また「Source Freshness」では、各ソーステーブルの最終更新時刻を監視し、想定された頻度でデータが連携されていない場合にアラートを上げる仕組みを導入しています。これにより、異常なデータの混入や連携の遅延をすぐに検知でき、エンドユーザーに常に高い鮮度と品質のデータを提供できる体制を構築しています。
安全と自由を両立するアクセスコントロール
プロジェクトごとに切り出されたデータ空間
全社的なデータ利用が急速に拡大していく中で、私たちが直面した課題は「いかにして各チームのスピード感を落とさずに、データ活用をスケールさせるか」でした。
一般的に、エンジニアが最終的なデータマートの構築まで全て担う企業も多いと思います。しかし、多岐にわたる事業が日々並行して動いている弊社においては、基盤チームへの依頼がボトルネックにならないよう、各プロジェクトが自律的にデータを管理できる環境のほうが合っていました。そこで弊社では、プロジェクトやチーム、部署といった単位で専用のデータベースを随時作成し、独立した「データ空間（ワークスペース）」として払い出して運用しています。
もちろん、「どの加工データまで閲覧してよいか」という大元の制御は、引き続きデータ基盤チームで管理しています。その上で、各プロジェクトの空間内では、許可された加工層/マート層のデータを参照し、KPIモニタリングや業務オペレーション管理など、自分たちの要件に合わせたデータマートを自由に作成できる仕組みをとっています。
このようにデータベース単位で境界を明確に区切ることで、他プロジェクトへの影響を気にすることなく、各チームがスピード感と責任を持ってデータ活用を推進できるようになっています。
開発体験とガバナンスを両立するRBAC設計
プロジェクトごとの独立したデータ空間を安全に機能させるために、弊社ではSnowflakeのロールベースアクセス制御（RBAC）を精緻に設計しています。
Snowflakeのアクセス制御においては、ユーザーに直接権限を付与するのではなく、「カスタムロール」を介して必要最小限の権限のみを付与する運用が重要です。弊社でもこの考え方に基づき、アカウント全体の広範な権限を渡すことは避け、払い出したワークスペースごとに「READ」と「READWRITE」という基本のパッケージロールを作成して管理しています。
- READ（閲覧用ロール）： そのワークスペースの閲覧者向けロールです。ワークスペース内のデータはもちろん、基盤チームが許可した大元の加工データ層も参照することができます。
- READWRITE（開発・分析用ロール）： エンジニアやデータアナリスト向けの実装ロールです。READの権限に加え、そのワークスペース内に限って各種オブジェクトを自由に作成する権限を許可しています。
ここで重要なのは、Snowflakeにおける権限制御が、単なる「テーブルデータの読み書き」にとどまらない点です。
Snowflakeでは、TASKやStreamといったデータパイプライン機能、Streamlitのようなアプリケーション、さらにはML/AI機能なども、基本的には「データベース内のオブジェクト」として紐づくアーキテクチャになっています。つまり、データベースの権限制御を行うことが、そのまま機能自体の制御にも直結するのです。
弊社ではワークスペースとして作業領域を分割しているため、この仕様が最大限に活きています。アカウント全体の権限を渡すことなく、「AプロジェクトのワークスペースにはStreamlitの作成を許可する」「BプロジェクトのドメインにはTASK機能を解放する」といった、各チームの要件に合わせた安全かつ柔軟な機能制御が可能になります。なお、これらのワークスペースやロール、権限付与の設定はTerraform（snowflakedb/snowflake プロバイダ）によってIaC管理しており、構成の再現性とレビュー可能性を担保しています。
このように、権限をパッケージ化して運用負荷を抑えつつ、ワークスペース単位で機能をコントロールすることで、基盤全体のガバナンスと、現場がSnowflakeのポテンシャルを活かせる開発体験を両立させています。
まとめ
本記事では、カバー株式会社におけるSnowflakeを中心としたデータ基盤の全体像と、安全かつ自由な分析環境を支える「アクセスコントロールの運用術」をご紹介しました。
各プロジェクトのワークスペースを分割し、RBACで適切に機能制御を行うことで、現場のエンジニアやアナリストが基盤チームを介さずに自律してデータを活用できる「データ民主化」の土台が整ってきました。
一方で、データ活用がスケールし、現場の自由度が増したからこそ見えてきた課題もあります。今後はデータ基盤チームとして、主に以下の領域に取り組んでいく予定です。
自由度とコストガバナンスの両立
現状のコンピュートコスト管理は基盤チームが一括で行っており、過大なリソースを提供しないことで想定外の課金を防いでいます。しかし、各ドメインでStreamlitやTASKなどの機能活用がさらに活発になれば、より柔軟なリソースの割り当てが求められます。
今後は、Snowflakeの「リソースモニター」機能（※設定したクレジット消費量の上限に達した際、ユーザーへのアラート通知やウェアハウスの自動停止を行ってくれる仕組み）を各ワークスペースに適用していきたいと考えています。これにより、基盤チームが単に制限をかけるのではなく、現場のユーザー自身がコスト状況を可視化し、予算を意識しながら効率的にリソースを利用できる「自律的なコスト管理」の実現を目指したいと考えています。
本記事が、データ基盤の設計やガバナンスに悩む方のヒントになれば幸いです。最後までお読みいただき、ありがとうございました！
