第8回DataMeshLT#1 DataMeshって？

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

Transcript

1. © 2023 HR Force Inc. Data Meshって？ 1 2024年5月10日 すずき（@suzupappa）
2. © 2023 HR Force Inc. 2 鈴木 凌（すずき） 株式会社HR Force DS統括部 DXグループ Dataチーム リーダー Salesforce / Tableauシステム管理者 データエンジニア / アナリティクスエンジニア @suzupappa @suzupappa Ryo Suzuki
3. © 2023 HR Force Inc. はじめに 3
4. © 2023 HR Force Inc. データメッシュ（Data Mesh) 4
5. © 2023 HR Force Inc. あんまりわからないですよね？ （私はわかりませんでした、、） 5
6. © 2023 HR Force Inc. ということで、今回調べてきました 6
7. © 2023 HR Force Inc. 7
8. © 2023 HR Force Inc. 8
9. © 2023 HR Force Inc. 2章 Scaled Architectureの紹介：大規模なデータ管理 9
10. © 2023 HR Force Inc. なぜ必要？ 10
11. © 2023 HR Force Inc. 「中央集権的なデータアーキテクチャ」 には限界があるから・・・ 11
12. © 2023 HR Force Inc. 12 Data meshはなぜ必要なのか？ 「中央集権的なアーキテクチャ」の限界 • そもそも、データ駆動（データドリブン）を進めるためには、 アジリティ・コントロール・インサイト・セキュリティが必須 • また、各ユースケース、ビジネス課題に対応するデータを作成・変更するためには、 生データやユースケース、ドメインの把握が必須 • だが、中央集権的なアーキテクチャでは、中央が管理しているDWHなどの基盤に統合する 必要があり、その統合には多大な課題や労力がかかる • また、中央に統合する過程で、ドメイン情報が排除されてしまうことも多い
13. © 2023 HR Force Inc. 「分散型のアーキテクチャ」の登場 → Data mesh 13
14. © 2023 HR Force Inc. どこでわける？ 14
15. © 2023 HR Force Inc. 「ドメイン駆動設計（DDD）」 15
16. © 2023 HR Force Inc. 16 「ドメイン駆動設計（DDD）」 「ドメイン駆動設計（DDD、domain-driven Design ）」 Eric Evans氏が発表した大規模な組織の複雑なシステムを対象としたソフトウェア開発の手法 ドメインの専門家からの情報に従って、それに一致するようにソフトウェアをモデル化すること で、効率的な開発につながる データ基盤開発にDDDの要素を導入するメリット データ管理 / 活用におけるドメインの範囲を決定することで、ドメイン内に詳しい人が責任をも って進めることができるようになり（単一責任）、効率的な管理が可能になる
17. © 2023 HR Force Inc. 17 「ドメイン駆動設計（DDD）」 そもそもドメインってなに？ ドメイン： 取り組もうとしている問題空間 知識、行動、法律、アクティビティが適用される領域。基本的には、サブドメインに分割される サブドメイン： 主に、下記の3つに分類される。 ・コアサブドメイン（最も重要。ビジネスを一意にする秘伝のソースみたいなもの） ・汎用サブドメイン（ビジネスに特化したものではなく、既製品で対応可能） ・支援サブドメイン（競争上の優位はないが、組織の維持には必須の部分。複雑ではない）
18. © 2023 HR Force Inc. 18 「ドメイン駆動設計（DDD）」 どのようにドメイン境界を設定するか？ ・ビジネスアーキテクチャの論理的な境界にマッピングして設定する ・組織の境界やビジネスプロセス、ドメインの専門性、に注目して境界を設定する ・ソフトウェアアーキテクチャの詳細な青写真を作成し、どの要素を疎結合にするか、密結合に するかを検討して、境界を設定する 原則 各コンテキスト境界につき、独自のユビキタス言語（共通言語）をもち、 一つのチーム（DevOpsチームなど）が管理する
19. © 2023 HR Force Inc. もっと知りたい！という方は下記が良いとのこと ・Domain Storytelling ・Modelling Bounded Contexts with the Bounded Context Canvas: A Workshop Recipe 19
20. © 2023 HR Force Inc. 「ドメイン」にわける方法はわかっ た じゃあ、どうやって実践する？ 20
21. © 2023 HR Force Inc. 「Scaled Architecture」 ≒Data meshによるアーキテクチャ 21
22. © 2023 HR Force Inc. 22 Scaled Architecture ＞企業が必要なのは、データプロバイダーとデータコンシューマを簡単に接続 し、柔軟性、コントロール、インサイトを提供できる、スケーラブルで高度な 分散型アーキテクチャである。 大規模データ管理―エンタープライズアーキテクチャのベストプラクティス P38より引用
23. © 2023 HR Force Inc. 23 Data meshはなぜ必要なのか？ 「中央集権的なアーキテクチャ」の限界 • そもそも、データ駆動（データドリブン）を進めるためには、 アジリティ・コントロール・インサイト・セキュリティが必須 • また、各ユースケース、ビジネス課題に対応するデータを作成・変更するためには、 生データやユースケース、ドメインの把握が必須 • だが、中央集権的なアーキテクチャでは、中央が管理しているDWHなどの基盤に統合する 必要があり、その統合には多大な課題や労力がかかる • また、中央に統合する過程で、ドメイン情報が排除されてしまうことも多い 再掲
24. © 2023 HR Force Inc. 24 Data meshはなぜ必要なのか？ 「中央集権的なアーキテクチャ」の限界 • そもそも、データ駆動（データドリブン）を進めるためには、 アジリティ・コントロール・インサイト・セキュリティが必須 • また、各ユースケース、ビジネス課題に対応するデータを作成・変更するためには、 生データやユースケース、ドメインの把握が必須 • だが、中央集権的なアーキテクチャでは、中央が管理しているDWHなどの基盤に統合する 必要があり、その統合には多大な課題や労力がかかる • また、中央に統合する過程で、ドメイン情報が排除されてしまうことも多い 再掲
25. © 2023 HR Force Inc. どのように把握していくのか？ 25
26. © 2023 HR Force Inc. 26 把握方法 サービスレベル契約やコントロール、データ品質ルール、データの利用方法を組 織に対して明らかにするため、データ配信契約とデータ共有合意が必要 データ配信契約 サービス契約のようなもの データ提供のSLAやサービス条件を含むインターフェースの互換性を保証などを対象とする データ共有合意 データ利用の目的を示すもの 使用方法やプライバシー、目的（制限を含む）などを対象とする
27. © 2023 HR Force Inc. 契約内容は、中央で保管される必要がある 27
28. © 2023 HR Force Inc. 28 Scaled Architecture 中央で保管されることで、新しいアーキテクチャにおける構成要素となる そして、データプロバイダーとコンシューマは中央のサポートを受けずに、データ配信とデータ 消費の問題を自分たちで解決できるようになる → 中央集権的なデータプラットフォームから脱却し、自律的なチームづくりに
29. © 2023 HR Force Inc. エンタープライズ規模でのドメイン駆動設計（DDD） データプロバイダー データプロバイダー データコンシューマ データコンシューマ データレイヤー API群 RDS群 イベント ストリーミング データプロバイダーとコンシューマの間にデータレイヤーを介し、それらのメタデータを中央の 管理機能と連携する 中央の管理機能
30. © 2023 HR Force Inc. まとめ 30
31. © 2023 HR Force Inc. まとめ 「中央集権的なデータアーキテクチャ」には限界があることがわかってきたため、 Data meshが生まれた それを実現するためには、ドメインを分割し、その中でそれぞれのデータ管理を 実施するための組織戦略を立てつつ、アーキテクチャを検討していくことが必要
32. © 2023 HR Force Inc. 詳しい実装方法や、生々しい内容に関しては、 後のパネリストの皆様の発表に期待！！ 32
33. © 2023 HR Force Inc. 下記については時間の都合上お話していないので、 是非、本をお読みください • ビジネスアーキテクチャ ◦ ビジネスケイパビリティ • 通信と統合のパターン ◦ ポイントツーポイント ◦ サイロ型 ◦ ハブスポークモデル 33