この記事は enechain Advent Calendar 2024 の12日目の記事です。
はじめに
こんにちは！ enechain でデータプラットフォームデスクのEMをしている26Takafujiです。
私は2023年9月にenechainへジョインし、そこからちょうど1年強の時間が経ちました。
入社時はまだ全社横断のデータ基盤は検討中の段階で本格的な提供はこれからという状態でしたが、この1年間でデータ基盤としての1st Stepである「まずはデータを集める」を進めてきて、主要なデータソースのBigQueryへの集約を一通り仕組み化できました。
今回は進めてきた仕組み化の中で、データ界隈では数年前から巷でよく取り上げられる「データメッシュ」の概念を念頭においた時、BigQueryへ集約されたデータの管理をどういった形で考えたのかを書いてみたいと思います。
これからデータ基盤を構築しようとしている人や、データ基盤を構築・運用する中でDWHにおけるデータ管理に課題感を持っている方の参考に少しでもなれば幸いです。
データメッシュについて
データメッシュとは
データメッシュは、データを大規模に管理するための基本的な方法論です。この概念は、データが高度に分散され、責任を連合型で分担するアーキテクチャを活用して、スケーラビリティが実現される世界を構想しています。人間的な側面に重点を置き、複雑化するデータアーキテクチャの管理という課題に取り組んでいます。
※出典: オライリー 大規模データ管理
データメッシュは提唱者であるZhamak Dehghani氏の How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh から広まった概念だそうです。
その後 Data Mesh Principles and Logical Architecture でデータメッシュの4つの原則が示されました。
- Domain ownership (ドメイン別オーナーシップ)
- Data as a product (製品としてデータを扱う)
- Self-serve Data Platform (セルフサービス型プラットフォーム)
- Federated Computational Governance (連邦型ガバナンス)
データ基盤の構築は一定以上の規模の会社では専門のデータエンジニアチームがデータの収集や活用の基盤づくりを行うことによって、データエンジニアリング領域の専門性を肩代わりしつつガバナンスを効かせる、というケースが多いと思います。その場合新たなデータの追加収集や活用時にはデータエンジニアチームで何かしら追加作業が必要だったり、基盤を通じて収集されたデータ自体の管理もデータエンジニアチームにより中央集権的に行われてたりすることが多いのではないでしょうか。
その時往々にして発生するのが、データの活用ニーズの増加に対して中央集権的な基盤チームが対応しきれず、活用のボトルネックになってしまうケースです。
これに対してデータメッシュは(3)セルフサービスなプラットフォームでデータエンジニアリングの専門性のハードルは下げつつ(4)ガバナンスモデルを作成し、それに準拠する形でのデータ管理/活用を通じて全体を統制しながら(1,2)分析データの管理や提供を分散的に行いデータ活用のスケーラビリティを上げる というアプローチだと理解をしています。
enechain × データメッシュ
データメッシュの概念をどこまでどういった形で採用するのが適切か？またいつ・どこまでやるのか？は会社のフェーズ・事業・サービスから生まれる「データ」の性質・会社にいる人材や組織構成など…様々な要素によって左右されると個人的には考えています。
私が入社した当時、enechainのDWHを中心としたデータを取り巻く環境は
- データ収集: 各データソースの管理者が個別の活用要件に応じてBigQueryへの連携を個別対応
- データ活用: BigQuery上でのデータ活用は一部のチームで部分的に行われており、全体的な動きではない
- ガバナンス: 取り組んでいる事業や提供しているサービスの性質上初期から情報統制要件が存在し、ガバナンスが重要
という状況でした。これを踏まえて、
- データ収集に関する共通の基盤をセルフサービス見据えつつ構築
- 収集したデータの保管場所と管理のオーナーシップの決定
- ガバナンスに関するルールやポリシーメイク
上記3点を検討してきました。 今回はデータ収集に関する基盤の全体像に触れつつ、データの保管場所やオーナーシップをどう設計したかについて書きたいと思います。 （ガバナンスに関するルールやポリシーメイクもまた別の機会に書きたいと思います。）
enechainのデータ基盤全体像
enechainのデータ基盤全体像は以下のようになっています。
enechainのシステム環境
enechainではGoogle Cloudを用いて全てのサービスが構築されています。 サービスのApplicationは全社共通のGKE Clusterが存在しており、そちらにhostされています。 データストアなどは各サービスやコンポーネント単位で専用のGoogle Cloudプロジェクトが作成され、そこにリソースが作られています。
４つのDataPipeline
現在は大きく4種類のデータソースに対してDataPipelineを開発しています。 ここでは各Pipelineの詳細には触れませんが、今後なるべくセルフサービスの形に持っていけるよう、リソース作成のTerraform module化や処理追加のConfig切り出し等で簡単に追加できるよう工夫しています。
Log Pipeline
社内に存在する各サービスのログデータを収集するPipelineです。Backend LogはApplicationがhostされているGKEからCloud Loggingに連携されるログをlog sinkでPub/Subに連携し、DataflowでRootingを行いBigQueryへStreaming insertしています。Client LogはGoogle Analyticsを利用しており標準の BigQuery Export 機能を利用しています。
DB Pipeline
社内に存在する各サービスのDBデータを収集するPipelineです。enechainではCloudSQLを利用しておりますがCloud SQL federated queriesを利用したDBデータのBigQuery連携の共通基盤を構築し、データを連携しています。 詳細はAdvent Calendarの明日公開される記事で紹介される予定ですのでぜひご欄ください。
SaaS Pipeline
会社横断で使用しているSaaS製品向けに、データのimport/export機能を提供しているPipelineです。（現在はSalesforceのみ、今後増加予定） こちらの記事でSalesforce連携の仕組みについても紹介しておりますので、ぜひご覧ください。
External Pipeline
エネルギードメインに関連するオープンデータや他社から購入している様々な外部データを収集、変換、集計するPipelineです。APIやSFTPサーバーからのデータ取得などを行っています。ApplicationはGKE上で動いており、Workflow EngineとしてはArgo Workflowsを利用しています。 以前は違うアーキテクチャだったのですが、こちらの記事でArgo Workflowsへ移行した時のことも書かれておりますので、ぜひご覧ください。
BigQueryのデータ管理検討
データを配置するプロジェクト構成の検討
前項でご紹介したPipeline群にてデータをBigQueryへ集約しておりますが、その中でもLog PipelineとDB Pipelineは取り込むデータの数がサービスやコンポーネント数と連動するので、事業の拡大と比例して特にデータ数が増加しやすいものだと思います。 今回はその2種類のPipelineに関して、それぞれのPipelineで連携するデータをBigQuery上のどのGoogle Cloudプロジェクトへ連携するかについて以下2️パターンを検討しました。
- データを1つのプロジェクトに集約する（中央集権型）
- データソース元毎にプロジェクトへ保存する（分散型）
Google Cloudプロジェクト毎にオーナーチームを決めるケースが多いと思うので、データを置くプロジェクト構成に関してはデータのオーナーシップへも大きく関係していました。
特に中央集権型は、データが単一のプロジェクトに集まることでデータ活用者から見ればそのプロジェクトを見にいけば基本的には全てのデータが揃っているため探索性に優れており横断的な利用もしやすいという特徴があります。
反面明確なオーナーシップを決めてない限りはプロジェクトの管理チームに全データ管理のオーナーシップが集中しやすくデータメッシュで語られる課題にも発展しやすいと思います。
このことを踏まえて設計してみました。
実際の設計
DB Pipelineは分散型を採用
DBデータには各サービスの根幹となる機密性の高いデータが含まれていると同時に、分析や業務にて利用のニーズが既に多くありました。そこで各サービスのDBが作成されているプロジェクトと同一のプロジェクトに対して連携用のdatasetを作成し、そこにデータを連携することで以下のような利点が得られました。
オーナーシップを分散させやすい
権限管理面を各サービス側のプロジェクトのIAM権限管理と統合できるので、各サービスのプロジェクト内の他のリソースと同じようにBigQueryデータに関してもサービス自身で管理してもらいやすい状況が作れました。その結果として中央集権チームが管理する場合と比較して各サービス毎で決められている権限ポリシーとズレが起きにくくなりました。機密性の高いデータが多いDBデータには適切な形だったと思います。
ただ、オーナーシップは分散してもそれぞれが独自に権限の申請プロセスや承認者を誰にするか？を決めていく場合コストが高く、データ毎に管理レベルのズレも発生しやすくなります。なので、新しい権限付与に関する申請プロセスや承認者などは横断のルールやワークフローを作って運用しています。
「ひとまずBigQueryまで連携しておく」がやりやすい
社内のDataAnalystチームからも特にDBデータに関してはあらゆる情報がBigQuery上で活用Readyになっていることが望まれていました。ただこのデータを中央集権的集約してしまうと、データが流れた先から集約先の全体権限を持つ人にはデータが見えてしまうというところがそもそものBigQueryへのデータ取り込み時のハードルとなってしまうリスクがありました。
今回の構成であればデータはサービス管理化のプロジェクトのBigQueryへ連携されるため、デフォルトではサービスの担当者しか権限を持っていません。なので、不用意に誰かに見えてしまうリスクがなく安全にデータをBigQueryへ連携でき、権限さえ付与されればすぐデータ利用を開始できます。
Log Pipelineは中央集権型の採用
先に紹介したDB Pipelineの例では、データソースとなるDBリソースはGoogle Cloudプロジェクトに紐づけて作成されるので必ずデータソースと1対1に紐づくプロジェクトが存在し、分散型のプロジェクト構成が取りやすい構成でした。
一方ログデータはデータソースがGKEの共通クラスターの各namespaceであることやGoogle Analyticsのアナリティクスアカウントやプロパティとなるので、分散型で管理する場合には適切なプロジェクトを新規作成するのか？もしくは既存のどのプロジェクトに置くのか？を追加のたびに検討する必要がでてきます。こうした構成に関連する事情も踏まえて、オーソドックスな単一のプロジェクトへのデータ集約することとしました。
冒頭から書いているデータメッシュの分散思想とは異なる側面もあるのですが、作成されるデータセット毎にオーナーを定義して権限の管理などを行っているので、以下に書いている利点も踏まえ実活用とガバナンスのバランスを考えてこの構成を選択しています。
横断活用がしやすい
enechainではBackendのApplicationから出力されるLogについて、フォーマットの統一化を進めておりカスタムな部分以外は共通項目を中心に同じフォーマットでログが出力される状態を目指しています。加えてログデータは全体分析やセキュリティ監査、トラブル対応時の調査など横断的に活用するケースも今後増えることが予想されます。そこで、フォーマットが統一されてかつデータが単一プロジェクトに集約されていれば、データの一覧性がありUNIONもしやすい状態を作れるので横断活用を考える上でのメリットとなります。
BigQuery上で共通機能を配りやすい
BigQueryに連携されたログデータはPayload部分がJSON型となっており、利用者にとってはJSONを都度ほどきながら利用するのが手間だったりします。そういった手間を削減するために共通のViewなどを提供しようという取り組みも検討をしていますが、こういった機能を提供する時にはプロジェクトが分散しているとリソースの作成を各所で行う難易度が高くなり、やりづらい面がでてきます。今の構成であれば、単一プロジェクト内でリソース（今回で言えばView）の作成が可能です。
現状の課題と今後の展望
ここまで現状のBigQueryにおけるデータの管理方法について書いてきましたが、現状の構成に課題も存在しています。
権限付与のリードタイムが長い
特にDBデータに対しての新規権限付与依頼が多いのですが、現在DB PipelineにてBigQueryへ連携されたデータの権限管理はTerraform上で行っております。権限付与が承認されたあとの実際の付与の作業（担当チームへ依頼 → Terraform修正/PR作成 → チーム内レビュー → PRマージ/Terraform Apply）のリードタイム長くなってしまうケースが多く存在しています。
ここをどう短縮化できるかを今後検討していく予定で、承認プロセスと紐づいてシームレスに権限が付与される仕組みを考えていきたいと思っています。
データの探索性
各データPipeline毎にデータを配置するBigQueryのプロジェクトが分散しており、分散型で配置しているDB Pipelineはさらに各サービス毎にプロジェクトが異なっています。特に新しくデータを使い始めたい人にとってはデータの探索性が高い状態とはいえず、どこに何があるのかが見つけづらい課題が存在しています。
今はドキュメントを準備し、手作業で更新しながらデータの一覧を利用者に向けて提供する形を取ってますが、中長期ではメタデータプラットフォームを検討しメタデータを充実化させて、探索性も上げていくことを検討しています。
最後に
今回はデータメッシュを意識しながら、特にBigQueryにおけるデータ管理面にフォーカスして自社の環境でどのような設計をしてみたかを紹介させていただきました。
「オーナーシップの分散」「ガバナンスを効かせる」はサービス数やデータ量が膨大かつデータ活用が盛んになりすぎた後のフェーズで進めるのは経験上非常に難易度が高く、時間もかかります。その意味で今後のデータ活用の増加を見越してデータ基盤構築の初期段階を考える中ではフレームワークとして非常に役に立ってくれたと思います。
ただ、データメッシュはその背景が「データ活用の肥大化」に対して考えられたアプローチだと思います。enechainでいえばデータ活用面はまだこれから拡大していかなければならないフェーズなので、そのタイミングで「データ活用に関する分散化」を意識しすぎてもデータ活用の活性化スピードがあまり高まらないリスクもあると思っています。
各原則で言われていることは意識しつつも、時には中央集権的にデータ活用事例を創り出していくようなことも考えながらそれを浸透させていく形で徐々に分散させるという動きも一定必要ではないでしょうか。そのバランスをどうとっていくか、という点が特に重要だと考えています（難しいテーマですが…）。
最後まで読んでいただきありがとうございました！
enechainでは一緒にこの巨大な電力マーケットを創っていく仲間を募集しています。興味を持ってくださった方はぜひ応募していただけますと幸いです！
