この記事は カケハシ Advent Calendar 2023 の19日目の投稿になります。
東 浩稔（あずま ひろとし）と申します。 私は、カケハシでデータプロダクトのPdM(プロダクトマネージャー)を務めております。
2023年の7月に入社し、全社のデータ利活用を促進するため、データプロダクトの整備・強化に取り組んでいます。 今回は、9月にDatabricks AI World Tour Tokyo 2023で発表した「データガバナンスの視点から見たデータメッシュアーキテクチャ」を元に 当社のデータメッシュアーキテクチャの詳しく掘り下げて解説いたします。
本書を読むことで得られること
データメッシュアーキテクチャを段階的に検討するための手法やヒントが得られます。
当社はなぜデータメッシュアーキテクチャか？
当社では、患者様や薬剤師様の医療体験を向上させるため、さまざまなプロダクトを活用し、目的に応じた最適なソリューションを提供しています。これらのプロダクトはそれぞれ専門チームが担当し、今後も新たなプロダクトの追加に伴い、担当チームが増加する見込みです。
このような状況から、中央組織であるデータ基盤チームが複数のプロダクトチームのETLを担当することはスケールしきれないことが予測できました。今後のプロダクトや組織の拡大に備え、データプロダクトを再構築する必要性が生じました。
その結果、各プロダクトチーム（ドメインチーム）が、自身のデータに責任を持つデータメッシュアーキテクチャを採用し、データ利活用もスケールすることを目指しました。
※図：中央集権型（データレイク）と分散型（データメッシュ）の比較
データメッシュアーキテクチャを推進するヒント（全体像）
私が入社した時点で、すでにデータメッシュアーキテクチャが採用され、そのためのデータプラットフォームが稼働していました。（図1の原則3の箇所）
ところが、実際の運用では、中央組織がETLを担当する体制が継続していました。この状況は、人員不足によりアーキテクチャを整備するためのリソースが不足していたことや、アーキテクチャのポリシーが不透明であり、ドメインチームが適切に利用できる状態にはないことが主な要因でした。（下図1の原則1と2の箇所）
※図1:データメッシュ4つの原則
そのため、まずはデータメッシュに適合するためのデータアーキテクチャのポリシーの整備から着手することにしました。 データメッシュアーキテクチャを含むアーキテクチャ設計には、複数の論点があり、これらの整理する際には前後関係を考慮しないと矛盾が生じたり、設計の破綻や整合性の欠如が起こる可能性があります。
したがって、データアーキテクチャをレイヤー別に整理することにしました。以下に、データメッシュアーキテクチャを整備するために検討が必要なレイヤーを示します。
※図2:データアーキテクチャの検討レイヤー
データアーキテクチャでは、下記のような検討すべきポイントがあります。それぞれを各レイヤーに分けて検討をします。
- コンプライアンス
- 論理アーキテクチャ
- 接続方式
- セキュリティ
- データ品質
- 物理アーキテクチャ
レイヤー別の検討ポイント
以降に、各レイヤーでの検討の論点を整理します。これらは上から順に整理します。
1. コンプライアンス
コンプライアンスレイヤーは、法的規制や業界の標準に準拠し、データのプライバシーとセキュリティを保護する基盤を提供します。 本章では、個人情報法および医療情報システムの安全管理に関するガイドラインを解釈し、実装すべき安全管理措置などをデータプロダクトとして検討します。
下記に、検討するポイントの例を記載します。
- 情報区分の定義
- 情報区分ごとの安全管理措置
- 仮名化/匿名化の加工方針
- 暗号化方針
- 冗長化方針
- モニタリング方針
- アクセス制御方針
- ライフサイクルごと方針の定義
- 取得
- 利用
- 保存
- 削除方針
2. 論理アーキテクチャ
論理アーキテクチャは、データの流れや処理方法を体系的に組み立て、データアーキテクチャの全体像を整理する上での基盤となります。 本章では、上位のコンプライアンスの実装方針に基づき、データをどのステージに配置するか、それらのデータをどのようなフローで運用するかを検討します。
※図：論理アーキテクチャの例
下記に、検討するポイントの例を記載します。
- メダリオンアーキテクチャのステージにおけるデータの配置と、それに基づくインタフェースの検討
- Bronze、Silver、Goldへのデータ配置
- データ提供者が公開するインターフェイス
- Bronze、Silver、Goldをさらに細分化し、仮名加工情報、匿名加工情報を配置するステージの検討
3.接続方式
データ連携は、データソースとデータプロダクト間、データプロダクト内でのデータ提供者と利用者間での共有を可能にするプロセスです。 本章では、上位の論理アーキテクチャの方針に基づき、連携の方式、プロトコル、方向、起動タイミング等を検討します。
※図：連携方式の例
下記に、検討するポイントの例を記載します。
- 連携方式
- バッチ連携、ストリーム連携等
- データ連携方向
- Pull型、Push型等
- データ形式
- ファイル、メッセージ等
- 起動タイミング
- スケジューラー、イベントトリガー等
4.セキュリティ
データセキュリティは、データの保護と管理の側面から検討します。 本章では、上位の論理アーキテクチャとデータ連携の方針に基づき、アクセス制御、暗号化、監視と検知等を検討します。
下記に、検討するポイントの例を記載します。
- ロールの定義
- データプロダクトを利用するロールおよび権限モデルの定義
- アクセス制御
- 論理アーキテクチャで定義されたインターフェイス、データステージごとのアクセス制御方針等
- 暗号化
- 通信や保管時の暗号化
- 暗号化アルゴリズムの強度
- サーバ、クライアントのどちらで暗号化を行うか
- 監視と検知
- 論理アーキテクチャで定義されたインターフェイス、データステージごとの監視と検知のレベルの定義
5.データ品質
データの価値を最大限に引き出すためには、品質が重要です。 本章では、上位のレイヤーに基づき、データ品質の重要性にフォーカスし、正確性、完全性、一貫性、信頼性等のデータ品質について検討します。
下記に、検討するポイントの例を記載します。
- データ品質
- データ品質の特性の中から採用する項目
- データ品質の確認箇所
- 論理アーキテクチャで定義されたデータステージごとの品質を確認する箇所
- 役割分担
- データ品質の特性ごとに、ドメインチームとガバナンスチームのそれぞれが実施する内容を定義
- データ品質のレベル
- 確認範囲のレベル設定
- 必須項目と任意項目の定義
- エラーレベルに基づいたアクション方針
6.物理アーキテクチャ
物理アーキテクチャは、データの処理とストレージの実装方法を考慮し、システム全体の効率性と信頼性を確保します。 本章では、上位のレイヤーに基づき、具体的なコンピュートリソース、データストレージ、ネットワーク構成などの物理アーキテクチャを検討します。
当社では、DatabricksとAWSを利用しています。これらの機能を使用して実際の設計を行います。
下記に、検討するポイントの例を記載します。
- ワークスペースとアカウントの分離
- Databricksのワークスペース
- AWSアカウント管理
- ストレージ
- ストレージクラス
- データの保持期間
- 暗号化
- コンピュートリソース
- Databricksのリソース
- SQL Warehouseのクラスタサイズ
まとめ
この記事では、データメッシュアーキテクチャの段階的な検討を通じて、物理アーキテクチャの設計プロセスについて解説しました。 今回は、詳細な解説はしていないため、今後も継続してデータプロダクトについて発信していく予定です。 この記事が皆様のお役に立てれば幸いです。
最後に
当社では、日本の医療体験をアップデートするため、薬局のDXに取り組んでいます。そのために、センシティブな個人情報を安全に保護しつつ、最大限活用するためにデータメッシュアーキテクチャを採用しています。
このようなチャレンジングな環境で成長し、当社のミッションやビジョンに共感いただける方は以下からのご応募をお待ちしております。また、カジュアルな面談も随時受け付けております！
