第8回DataMeshLT#2 とあるエンプラ企業への DataMesh適用シミュレーション

SnowflakeUserGroupデタマネコミュニティ第8回活動で利用したLT資料の5本中2本目を公開します！

Transcript

1. とあるエンプラ企業への DataMesh適用シミュレーション 2024/05/10 Snowflake デタマネコミュニティメンバ 佐川
2. 自己紹介 Profile Snowflakeデタマネコミュニティ運営メンバ 佐川 未紗 ❏ 某SIerにて、通信事業者様などの顧客を担当 ❏ データ基盤構築・運用歴 約4年, 基幹システム開発歴 約2年 ❏ 2020年よりSnowflakeを利用 Today’s Session エンタープライズ規模のデータ基盤を運用するなかで 「多岐にわたる業務データやメタデータ」を「利用者の要求する品質」で「スピーディー」に提 供・運用するためには、プロセス/エンジニアリング面・体制面いずれも障壁となる課題が多い。 ”Data Mesh”がこの課題を解決できるのかが分からずもやもやしていたため、実際DataMeshの考え を適用したらどんな課題が解決できてどんな難しさがあるのか、シミュレーションしてみる。 ※事例をマージしているので、特定企業に関する内容ではありません。
3. rawデータ とある大企業の設定 ・大規模エンタープライズ企業（PB規模データで多岐にわたる業務ドメインをもつ） ・データ活用推進に向けて全社のデータ基盤を整備 ・グループ会社も複数あり、今後データや業務を連携していきたい オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム NEW システム カスタマー 情報 決済情報 メディア 情報 広告効果 情報 キャン ペーン情報 BIレポーティング DWH マート マート マート マート 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループ会社 Snowflake Ａ社内で未統合の データ基盤 デ ー タ カ タ ロ グ 収集 蓄積 加工 分析 NEW
4. rawデータ とある大企業の基盤構成例 ・クラウドベース：Snowflakeを中心とし、周辺ツールも基本SaaSで構成 ・一元管理：中心に据えたSnowflakeに全社の業務データを集約 ・上流システム：クラウド系の新規システムやレガシーオンプレシステム等、多岐にわたる数十の上流システム ・ユースケース追加：新サービスやシステムが追加される度にSnowflakeへデータセットや接続先を追加する オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム NEW システム カスタマー 情報 決済情報 メディア 情報 広告効果 情報 キャン ペーン情報 BIレポーティング DWH マート マート マート マート 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループ会社 Snowflake Ａ社内で未統合の データ基盤 デ ー タ カ タ ロ グ 収集 蓄積 加工 分析 NEW
5. rawデータ とある大企業の組織体制例 各部門の役割 • システム部門A ：上流のオンプレ/クラウド 基幹システム開発運用 • システム部門B：データ基盤の運用管理 （新データセット追加、メタデータのカタログ登録、共通パイプライン運用、遅延やエラーの復旧、アクセス制御、SSO、ログ管理 等） • データ活用・DX推進部門：データガバナンスルールの統括、データ活用推進、データ分析・機械学習等 • 事業部門A：上流のクラウド系システムの開発運用 • 事業部門B：マート作成やダッシュボード作成利用 オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム NEW システム カスタマー 情報 決済 情報 メディア 情報 スポーツ 情報 キャン ペーン情報 BIレポーティング DWH マート マート マート マート 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループ会社 Snowflake Ａ社内で未統合の データ基盤 デ ー タ カ タ ロ グ システム部門 データ 活用推 進部門 事業部門 事業部門 事業部門 事業部門 事業部門 データ 活用 推進部門 収集 蓄積 加工 分析 NEW システム部門
6. rawデータ 前述構成・体制の基盤運用課題 前述の構成・体制はクラウドベースのデータ基盤で典型的な構成。大企業でよくある体制。 オンプレミスよりもパフォーマンス面含めてよくなっているはずだが、以下のような課題が各所で残る。 自動化したり、プロセス改善したり、人を増やしても解決しきれない課題が点在。 ※特に組織間のコミュニケーションや意識づけが難しい オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム NEW システム カスタマー 情報 決済 情報 メディア 情報 スポーツ 情報 キャン ペーン情報 BIレポーティング DWH マート マート マート マート 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループ会社 Snowflake Ａ社内で未統合の データ基盤 デ ー タ カ タ ロ グ 収集 蓄積 加工 分析 NEW 新データセット追加 全業務を取り扱うと範囲が広すぎて 各ドメイン業務を把握しきれていない。 業務モデル理解が不十分なデータ設計 メタデータのカタログ登録 メタデータ情報誤り等の品質課題。 上流システムに聞かないと分からない ＆データ利用者から質問がくる板挟み。 新データセット追加 利用者は早くデータがほしい。 開発チームのプロダクトバックログの順番待ち 上流システム運用 データ活用って・・？ 24/365で開発・運用 することがミッション。 データ使いたいなら 連携はしますよ データ分析・利用 データオーナーを設定していても、所有意識の欠如 や上流システムはデータ利用を意識していないため に、データに関する問合せがたらいまわしに。 新データセット追加 スピード感を持って分析したいデータ利用者。 対象業務が多くて運用が大変な基盤運用者。 組織間の摩擦が発生
7. DataMeshで解決できる課題 DataMeshは従来の中央集権的な構成から、業務ドメインごとの分散管理を推奨する考え方。 以下の4つの原則に準拠することが重要。（おそらく1つでも欠けるとうまくいかない） DataMeshで前述の課題解決の糸口はみえてくるのか・・？ １ ドメイン指向の 分散アーキテクチャ ２ データの 製品思考 ３ フェデレーテッド ガバナンス ４ セルフサービス プラットフォーム 参考 ・Data Mesh Principles and Logical Architecture ・How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
8. 新サービスドメインチーム 決済ドメインチーム カスタマー情報ドメインチーム データオーナー（所有責任）を上流システムにできるだけ近づける！＆業務ドメインカットに分ける スポーツドメインチーム １．ドメイン指向の分散アーキテクチャ オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム BIレポーティング 決済系 ＤＷＨ 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループドメ イン 新ドメイン データセット デ ー タ カ タ ロ グ カスタマー 情報 決済 情報(raw） メディア 情報 スポーツ 情報 カスタマー系 ＤＷＨ スポーツ系 ＤＷＨ メディア系 DWH メディアドメインチーム グループ会 社事業 NEW システム
9. 新サービスドメインチーム 決済ドメインチーム カスタマー情報ドメインチーム 社内であってもデータの利用者を実際のお客様と捉え、良いデータ製品を提供するという考えでデータセ ットを提供する。 スポーツドメインチーム ２．データの製品思考 オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム BIレポーティング 決済系 ＤＷＨ 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループドメ イン 新ドメイン データセット デ ー タ カ タ ロ グ カスタマー 情報 決済 情報(raw） メディア 情報 スポーツ 情報 カスタマー系 ＤＷＨ スポーツ系 ＤＷＨ メディア系 DWH メディアドメインチーム グループ会 社事業 NEW システム 使いやすいデータの 評価 KPIはデータの使われ 具合・連携され具合
10. 新サービスドメインチーム 決済ドメインチーム カスタマー情報ドメインチーム 旧来の構成で点在していた課題は解決の糸口が見えてくる。 スポーツドメインチーム １．ドメイン指向の分散アーキテクチャ ２．データの製品思考 オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム BIレポーティング 決済系 ＤＷＨ 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループドメ イン 新ドメイン データセット デ ー タ カ タ ロ グ カスタマー 情報 決済 情報(raw） メディア 情報 スポーツ 情報 カスタマー系 ＤＷＨ スポーツ系 ＤＷＨ メディア系 DWH メディアドメインチーム グループ会 社事業 NEW システム 新データセット追加 全業務を取り扱うと範囲が広すぎて 各ドメイン業務を把握しきれていない。 業務モデル理解が不十分なデータ設計 ⇒自分のドメインを把握すればOK メタデータのカタログ登録 メタデータ情報誤り等の品質課題。 上流システムに聞かないと分からない ＆データ利用者から質問がくる板挟み。 ⇒各ドメインで品質を担保する 上流システム運用 データ活用って・・？ 24/365で開発・運用 することがミッション。 データ使いたいなら 連携はしますよ ⇒データを目的にあわせて提供 する データ分析・利用 データオーナーを設定していても、所有意識の欠如や上 流システムはデータ利用を意識していないために、デー タに関する問合せがたらいまわしに。 ⇒所有権は各ドメインのデータチーム。KPI含め明確 ✓ ✓ ✓ ✓ 新データセット追加 利用者は早くデータがほしい。 開発チームのプロダクトバックログの順番待ち ⇒他のドメインとの競合が減る ✓ 新データセット追加 スピード感を持って分析したいデータ利用者。 対象業務が多くて運用が大変な基盤運用者。 組織間の摩擦が発生 ⇒ソース側の役割が明確になり、利用者の要求 を満たすことも優先できるようになる ✓
11. 新サービスドメインチーム 決済ドメインチーム カスタマー情報ドメインチーム しかし、もともと集約していたのは理由があって、ガバナンス利かせるのは現実的でないのでは？ スポーツドメインチーム オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム BIレポーティング 決済系 ＤＷＨ 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループドメ イン 新ドメイン データセット デ ー タ カ タ ロ グ カスタマー 情報 決済 情報(raw） メディア 情報 スポーツ 情報 カスタマー系 ＤＷＨ スポーツ系 ＤＷＨ メディア系 DWH メディアドメインチーム グループ会 社事業 NEW システム 品質基準がドメインチー ムの文化次第で ばらばらにならないか？ 全ドメインが効率的にデ ータパイプラインつくれ ないのでは？ Snowflakeの使い方分 かるのか？ セキュリティや規約準拠 方法など統一できていな いと危ない １．ドメイン指向の分散アーキテクチャ ２．データの製品思考 ドメイン間のデータを結 合するときに型がズレて いたら困る。連携できる のか？
12. ガバナンスチーム ※各ドメインの代表者の連 合チーム 新サービスドメインチーム 決済ドメインチーム カスタマー情報ドメインチーム 連合のガバナンスチームで共通で守るべきポリシーと展開ルールを整備する。 スポーツドメインチーム ３．フェデレ―テッドガバナンス オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム BIレポーティング 決済系 ＤＷＨ 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループドメ イン 新ドメイン データセット デ ー タ カ タ ロ グ カスタマー 情報 決済 情報(raw） メディア 情報 スポーツ 情報 カスタマー系 ＤＷＨ スポーツ系 ＤＷＨ メディア系 DWH メディアドメインチーム グループ会 社事業 NEW システム ◆展開ルール ・ドメインの境界の特定、データ製品とドメインの関 連づけ ・アクセス制御ポリシーや規制遵守ポリシールール ・データの論理名標準や構文モデル標準 ・データの品質チェック基準観点 ・横断の結合キー(ＩＤ等)の定義 ・エンコーディング基準ルール ・データセットの命名規約 ・S3バケットやスキーマの命名規約 ・多義語の識別方法・名寄せ辞書 ・メタデータの項目リストとフォーマット標準 ポリシー（例） ✓ 意思決定はできるだけドメインに近づける ✓相互運用性を考慮したグローバルな意思決定 ✓セキュリティ・規制・コンプライアンスといった横断的 な点はグローバル化
13. ガバナンスチーム ※各ドメインの代表者の連 合チーム 新サービスドメインチーム 決済ドメインチーム カスタマー情報ドメインチーム ガバナンスチームのポリシーに沿って共通インフラチームが各ドメインで必要な技術を展開する。 スポーツドメインチーム ４．セルフサービスプラットフォーム オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム BIレポーティング 決済系 ＤＷＨ 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループドメ イン 新ドメイン データセット デ ー タ カ タ ロ グ カスタマー 情報 決済 情報(raw） メディア 情報 スポーツ 情報 カスタマー系 ＤＷＨ スポーツ系 ＤＷＨ メディア系 DWH メディアドメインチーム グループ会 社事業 NEW システム 共通インフラ提供チーム ＜提供機能例＞ ・データパイプライン実装コンポーネント ・クレンジング処理共通コンポーネント ・データ暗号化処理 ・マスキングポリシー/行アクセスポリシー ・データカタログへのメタ登録API ・バージョン・ブランチ管理方法 ・リネージュツール ・データ品質チェック関数 ・SSO ・コスト管理ダッシュボードテンプレ ★ドメイン固有概念はもたない ★ビジネスロジックはもたない ★とにかくコンポーネント化 ★とにかく自動化・セルフサービス化
14. ガバナンスチーム ※各ドメインの代表者の連 合チーム 新サービスドメインチーム 決済ドメインチーム カスタマー情報ドメインチーム ガバナンスチームのポリシーに沿って共通インフラチームが各ドメインで必要な技術を展開する。 スポーツドメインチーム ４．セルフサービスプラットフォーム オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム BIレポーティング 決済系 ＤＷＨ 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループドメ イン 新ドメイン データセット デ ー タ カ タ ロ グ カスタマー 情報 決済 情報(raw） メディア 情報 スポーツ 情報 カスタマー系 ＤＷＨ スポーツ系 ＤＷＨ メディア系 DWH メディアドメインチーム グループ会 社事業 NEW システム 共通インフラ提供チーム 品質基準がドメインチームの 文化次第で ばらばらにならないか？ ⇒ガバナンス標準と共通イン フラチームの手段提供 全ドメインが効率的にデータパ イプラインつくれないのでは？ Snowflakeの使い方分かるの か？ ⇒共通インフラチームがつくる セキュリティや規約準拠方法 など統一できていないと危な い ⇒ガバナンス標準と共通イン フラチームの手段提供 ドメイン間のデータを結合すると きに型がズレていたら困る。連携 できるのか？ ⇒ガバナンス標準で定義
15. DataMeshの４原則 ・おそらくこの4つの原則すべてが実現できないと成り立たない ・これが実現できれば、もともとの基盤課題は解決できそうな点も多い １ ドメイン指向の 分散アーキテクチャ ２ データの 製品思考 ３ フェデレーテッド ガバナンス ４ セルフサービス プラットフォーム 参考 ・Data Mesh Principles and Logical Architecture ・How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
16. rawデータ 前述構成・体制の基盤運用課題＜再掲＞ 前述の構成・体制はクラウドベースのデータ基盤で典型的な構成。大企業でよくある体制。 オンプレミスよりもパフォーマンス面含めてよくなっているはずだが、以下のような課題が各所で残る。 自動化したり、プロセス改善したり、人を増やしても解決しきれない課題が点在。 ※特に組織間のコミュニケーションや意識づけが難しい オンプレ基幹 システム オンプレ基幹 システム クラウド系 システム クラウド系 システム NEW システム カスタマー 情報 決済 情報 メディア 情報 スポーツ 情報 キャン ペーン情報 BIレポーティング DWH マート マート マート マート 経営ダッシュボード 機械学習 アドホック分析 Ａ社の全社基盤 Ａ社グループ会社 Snowflake Ａ社内で未統合の データ基盤 デ ー タ カ タ ロ グ 収集 蓄積 加工 分析 NEW 新データセット追加 全業務を取り扱うと範囲が広すぎて 各ドメイン業務を把握しきれていない。 業務モデル理解が不十分なデータ設計 メタデータのカタログ登録 メタデータ情報誤り等の品質課題。 上流システムに聞かないと分からない ＆データ利用者から質問がくる板挟み。 新データセット追加 利用者は早くデータがほしい。 開発チームのプロダクトバックログの順番待ち 上流システム運用 データ活用って・・？ 24/365で開発・運用 することがミッション。 データ使いたいなら 連携はしますよ データ分析・利用 データオーナーを設定していても、所有意識の欠如 や上流システムはデータ利用を意識していないため に、データに関する問合せがたらいまわしに。 新データセット追加 スピード感を持って分析したいデータ利用者。 対象業務が多くて運用が大変な基盤運用者。 組織間の摩擦が発生
17. 大企業でどこまで実現できる・・？ ◆ハードルに感じる点 ・ドメインチームへの体制移動はトップダウンの意思決定が必要では・・？ ・多数のステークホルダーを束ねる「３」「４」の役割がちゃんと作り切れるか ・「３」「４」のルールや手段が各ドメインのちゃんと浸透させられるか ・ドメインチーム内の規模が大きくなると、また人が増えることによる摩擦が発生しそう ◆うまくいきそうな点 ・グループ間とのデータ共有等を進める場合、いずれにせよ「３」「４」の整備は不可欠では。 ・なんだかんだ「３」にあたるものは中央集権のデータチームも作っているので展開できる部品はそこそ こある。 １ ドメイン指向の 分散アーキテクチャ ２ データの 製品思考 ３ フェデレーテッド ガバナンス ４ セルフサービス プラットフォーム 参考 ・Data Mesh Principles and Logical Architecture ・How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh