【投票キャンペーン対象】ナレッジワークのサービス及び分析に利用するデータ基盤アーキテクチャ

アーキテクチャを選定された背景や意図

ナレッジワークのサービス基盤・データ基盤は全てGoogle Cloudで構築し、data transformにdbtを利用しています。
ナレッジワークでは社内でデータ分析をするだけでなく、顧客向けに利用状況を分析できるようにデータを提供する機能があるために、production環境だけでなくサービスの各環境向けにもdbt基盤を利用できるようにする必要がありました。

また、社内分析に利用するデータは1環境分のみ構築すればよい、という状況でもあります（例: zendeskなど）。
これを解決するために、データ基盤プロジェクトにdbt基盤を構築し、各環境向けのjobをその中で実行する体制にしました。 これにより、dbtの基盤やモデルのメンテを一元化出来るようになっています。

当初はサービス基盤のプロジェクトにdbt基盤も載せ、社内分析用の基盤はデータ基盤プロジェクトに載せていましたが、それだと以下のような問題がありました。

• dbtのモデルが一元管理されず、2重管理せざるを得ない
  
• dbt基盤のメンテナンスコストが2重にかかってしまう

1点目のdbtモデルの問題については、データメッシュ基盤を構築し、dbtモデルをdbt package化するなりして共有する方法も考えられました。
しかし、まだナレッジワークではデータ基盤を立ち上げたばかりで成熟していないため、複雑な仕組みを入れるよりは一元管理に寄せるのがよいと判断し、現在の構成を取ることにしました。
とはいえ、データメッシュ構成のようなモデルの責任範囲の分離は意識しておけるように、ディレクトリ構成やマートの分離は意識した作りになっています。

現在の課題や今後の改善予定

ナレッジワークでは個人情報データを法令・利用規約・プライバシーポリシーに従って、BigQueryのポリシータグを利用してアクセス制御しています。
目下の大きな課題として、そのポリシータグの付与を手作業で設定している点があります。

サービスのDBはDatastreamを利用してBigQueryへレプリケーションしていますが、このテーブルが自動生成されるためにコード管理が出来ず、手作業でのメンテナンスをせざるを得ないという状況になっています。
さらにDatastreamの特性として、データが追加されないとテーブルが作成されないというものがあり、そのために本番環境で実際にポリシータグの付与を行えるようになるまでのリードタイムが長いといった要素も重なって、ポリシータグの付与が遅れる可能性がある、という問題があります。

ナレッジワークはエンタープライズ企業にフォーカスしてサービスを展開しているため、セキュリティのガバナンスが非常に重要であり、この問題を早々に仕組み化して解消する必要があります。

現時点での構想として、以下のような仕組みを考えています。

• DBのdescriptionにメタ情報を書けるようにし、特定のラベル（例えば"policy": "pii" | "none" など）を付与したら、自動でBigQueryのテーブル・列にポリシータグを付与する仕組みを作る
  
• DBマイグレーションファイルの作成時にdescriptionの記載を強制し、policyラベルの記載を必須とする
  

このようにして、開発者が実装時点でアクセス制御を必ず記述することになり、より安全に運用できることを目指しています。

◆執筆：しめにゃん　@_sisisin