そのデータ連携、ホントにそれでいいの？ 〜データモデル分析の重要性を説く〜 / How to analyse data integration

【Assured×カケハシ】DXを牽引する先進プロダクト開発に携わるエンジニア達が語るドメインモデリング
https://techplay.jp/event/952464
の登壇資料です

Transcript

1. 日本の医療体験を、しなやかに。 © KAKEHASHI Inc. 〜データモデル分析の重要性を説く〜 そのデータ連携、ホントにそれでいいの？
2. © KAKEHASHI Inc. 株式会社カケハシ 技術戦略室 2021年、カケハシに入社。サービス・データプラッ トフォームのアーキテクトを担った後に、技術戦略 室にて、開発組織全体の技術領域の戦略を推進。 キャリアを通して、プロダクトの立ち上げの初期か ら関わることが多く、大半はアーキテクトとしての 役割を担ってきました。Data as a Serviceのよう なプロダクトを多く設計開発したこともあり、 「データ」を軸に設計することが多くあります。 カケハシ社内ではデータ連携を含む多くのアーキテ クチャレビューに関わってきました。 自己紹介 @kimutyam @kimutyam 木村 彰宏 (あきひろ)
3. Introduction
4. © KAKEHASHI Inc. カケハシが提供する薬局DXプロダクト
5. © KAKEHASHI Inc. カケハシが目指す未来
6. © KAKEHASHI Inc. カケハシのデータ連携事情 カケハシでは、医療に関する様々なバリューチェーンに対して複数のプロダクトを提供しています。 既存のプロダクトのデータ資産を活用して新たなプロダクトを立ち上げるスキームが多く、データ連携数は 年々増加しています。 • システム数: 30 • システム間データ連携数: 135 (2024月6月時点) システムは、境界づけられたコンテキスト内で独立して実行・デプロイされる、凝集した機能のまとまりの ことを指します。 システム間データ連携数は、データ供給のためにコンテキストをまたぐパス数です。
7. © KAKEHASHI Inc. 次の論理プロセスの設計相談・設計レビューを受けることが多くあります。 1. 機能を実現するには、異なるサービス(コンテキスト)のデータが必要である 2. データを供給してもらうためには、〇〇のデータ連携方法が必要である 3. データ連携を実現するには、〇〇のインフラ構成で考えている 簡易な構成であれば、この論理プロセスでうまくいく場合もありますが、システムの依存関係が絡み合った 状況では局所最適な設計になることがあります。 これを解決するためには、具体的な連携方法やインフラ構成に入る前に、対象のデータをモデリングするこ とが重要です。 課題: よく見受けられるデータ連携の設計内容
8. © KAKEHASHI Inc. Micro Service Architecture(MSA)やEvent Driven Architecture(EDA)の文脈で、ドメイン駆動設計 (DDD)における境界づけられたコンテキストが再 フィーチャーされました。 この方法論は、モデルベースでドメインを分析し、 論理的な解決領域の境界を見出していきます。 コンテキスト間で連携を取るには、コンテキストを 中継する共有モデルを定義し、関係性を示していき ます。 コンテキストがマイクロサービスの単位とは限りま せん。モデルの関係性を示すだけであり、実現方法 は言及しません。 巷でよく見かける方法論: 境界づけられたコンテキスト 引用: martinFowler.com | 「Bounded Context」| https://martinfowler.com/bliki/BoundedContext.html
9. © KAKEHASHI Inc. 実践に際して・・・ どうドメイン分析を行いますか？ 既存サービスが、戦術的DDDのドメインモデルベースで組み立てられていない場合は、どうしますか？ ドメインエキスパートや運用しているエンジニアを集めて、概念モデリングから始めますか？ どう解決領域の定義をしますか？ ドメインエキスパートやアーキテクトの経験と勘でしょうか？ データモデルやデータ品質特性などの知識を踏まえずに、適した論理的な境界を設計できるでしょうか？ 境界づけられたコンテキストは、少し噛み砕く必要がある
10. © KAKEHASHI Inc. データ連携は4つに分解して考える データの品質特性を踏まえて、データフ ロー図を組み立てる。最終的にデータフ ローを俯瞰して実現方法や依存関係の整 合性を分析する。 Ⅲ. データフロー分析 機能的凝集度を踏まえてどこで所有する べきか。 対象データの利用用途と制約は何か？ Ⅱ. 所有分析 対象データにはどのような変更理由があ るか。業務を達成する上で過不足ない状 態になっているか。 Ⅰ. イベント分析 Ⅰ〜Ⅲの分析結果と、ビジネス観点・ チーム体制等を踏まえて、アーキテク チャ構成との整合性をとる。 Ⅳ. システムコンテキスト分析
11. Ⅰ.イベント分析
12. © KAKEHASHI Inc. データ連携のほとんどは、データコンシューマーの「〜〜のデータが欲しい」という要望が起点になります が、データへの理解が得られていないことが多く見受けられます。 実際には、データがどのように生成され、どう変更されるのかを理解して活用する必要があります。 以下は、データプロバイダー内の振る舞いによって、コンシューマーの業務を達成できなくなる事例です。 (例) • プロバイダー:「注文」の「キャンセル」に際して、対象の「注文」データの削除をしている • コンシューマー: 「キャンセル」を含めた過去の「注文」の動向をレポーティングしたい したがって、データに関連するイベント(起こった事実)を明らかにし、業務知識を共有することが重要で す。 データに関連する業務知識を共有するためのイベント分析
13. © KAKEHASHI Inc. ケーススタディ: イベント分析 対象データの状態が変わるイベントを列挙します。 プロバイダーのサービスがイベントを記録している 場合は、それを採用します。 イベントを記録していない場合は、対象データに関 連するイベントを関係者間で議論して、共通言語を 定義します。 注文 <<対象デー タ>> 注文依頼 <<event>> 注文キャン セル <<event>> 配達開始 <<event>> 配達完了 <<event>>
14. © KAKEHASHI Inc. ケーススタディ: イベント分析 コンシューマーは、「キャンセル」を含めた過去の 「注文」の動向をレポーティングする業務を実行す る必要があるとします。 しかし、イベント分析の結果、プロバイダー:「注 文」の「キャンセル」に際して、対象の「注文」 データの削除をしていることが発覚しました。 これでは、対象データをデータ連携しても業務が達 成できません。 コンシューマーの業務を達成するには、対象データ モデルを見直すか、イベントデータを連携する必要 があります。 注文 <<対象デー タ>> 注文依頼 <<event>> 注文キャン セル <<event>> 配達開始 <<event>> 配達完了 <<event>>
15. © KAKEHASHI Inc. ケーススタディ: イベント分析 イベント分析の結果、「配達開始」と「配達完了」 の業務で、「注文」のステータス変更を実行されて いる発覚しました。 コンシューマーは、配達には関心がないようです。 コンシューマーに提供するデータインターフェース には、配達ステータスは不要になります。 関心がないイベントを明らかにすることで交換する データを薄くできます。 注文 <<対象デー タ>> 注文依頼 <<event>> 注文キャン セル <<event>> 配達開始 <<event>> 配達完了 <<event>>
16. © KAKEHASHI Inc. ケーススタディ: イベント分析 イベントはデータの変更理由そのものであり、それ と紐づくデータは集約です。 (集約はデータの一貫性を担保するためのまとまり のことです。) 集約の変更理由が多くなるに、トランザクションが 衝突する可能性が高くなりがちです。 イベントを明らかにすることは、データモデル自体 を見直すきっかけにもなります。 ※ 右の例では、「配達状況」という集約を新たにしましたが、 この是非については取り上げません。 注文 <<対象デー タ>> 注文依頼 <<event>> 注文キャン セル <<event>> 配達開始 <<event>> 配達完了 <<event>> 配達状況
17. © KAKEHASHI Inc. ケーススタディ: イベント分析 「注文」はデータプロバイダーのアプリケーション の都合で変更されるデータ構造です。供給するには 間接化したインターフェースを用意する必要があり ます。 対象のデータプロバイダーで、イベントデータを記 録している場合は、イベントデータをインター フェースとしたイベントデータ連携が有効な場合が あります。 ※「ドメインイベントを伝達するためのモデリング技法」 でイ ベントの伝達方法を紹介していますので、参考にしてみてくださ い。 https://kakehashi-dev.hatenablog.com/entry/2024/05/15/0900 00 注文 <<対象デー タ>> 注文依頼 <<event>> 注文キャン セル <<event>>
18. © KAKEHASHI Inc. イベントストーミングは、より深いビジネスドメインへの探求 し、最終的にシステムの設計に落とし込むためのワークショッ プです。 このワークショップでは、まずイベントを明らかにして業務理 解を深め、集約を決定します。プロダクトの初期設計や、大幅 なリアーキテクティング等のシナリオで実施することをおすす めします。 一方、今まで取り上げてきたイベント分析は、対象データの変 更理由を把握するために、AS ISの集約からイベントを定義・解 析しています。 機能を実現するためのデータ連携などカジュアルに分析する時 に有効だと考えます。 (補足) イベントストーミング 引用: Introducing EventStorming | https://www.eventstorming.com/book/
19. Ⅱ. 所有分析
20. © KAKEHASHI Inc. 所有とは データへの書き込み操作を行うサービスが、そのデータを所有することになります。 イベント分析で登場したイベントが書き込み操作の全てです。
21. © KAKEHASHI Inc. 単独所有 サービスに対して1つのデータ(テーブル)を割り当 てる単一所有が基本になります。 サービス テーブル
22. © KAKEHASHI Inc. 共同所有 複数のサービスが1つのデータ(テーブル)を共同所 有している場合があります。 複数のサービスが同じデータに書き込みを行うた め、それぞれのサービスで、スキーマやデータの一 貫性の担保をするための調整を行う必要がありま す。 これを積極的に採用する理由はありません。 サービスA テーブル サービスB
23. © KAKEHASHI Inc. データベース (補足) サービスベースアーキテクチャにおける所有 サービスベースアーキテクチャは、境界づけられた コンテキストに基づいてサービスを分割する一方、 データベースはモノリシックにするハイブリットな アーキテクチャスタイルです。 既存のデータベーススキーマや結合点を変更せずに サービス分割できるメリットがあります。 この場合でも、データの所有は限定できます。 片方のサービスからは読み込みしか行わないように すれば、単一所有になります。 右の例では、サービスAがデータを単一所有してい ることになります。 サービスA サービスB テーブル Read/Write Readonly
24. © KAKEHASHI Inc. 所有分析: データの利用用途と制約の整理 所有する(=書き込みを行う)サービスを決定しま す。 データの利用用途と制約を整理することで、関連す るデータと整合性が明らかになります。 データ 利用用途 制約
25. © KAKEHASHI Inc. HTTP API ケーススタディ: データ連携の検討内容 既に存在する管理画面サービス(モノリス)にて、SMSの「通数上限」を記録し、SMS送信サービスで通数 制御するために、ストリーミングでデータ連携が検討されていました。 この場合、管理画面サービスで「通数上限」を所有していることになります。 SMS送信サー ビス 管理画面 サービス (モノリス) (ストリーミング) 通数上限 管理画面フロントエンド
26. © KAKEHASHI Inc. ケーススタディ: データの利用用途と制約の分析 前提 • 「送信依頼」と「送信完了」はSMS送信サービ スが所有している 解釈 • 送信において、「送信依頼」と「送信完了」 のデータは、「通数上限」関連が強く、機能 的凝集度を高めた方が良さそうである。 • 「通数上限」を上回る送信は結果整合が許容 できない。 通数上限 (利用用途1) 送信を実施する際に、 「送信依頼」リクエスト のリスト数と比較し、月 間で通数上限を上回らな いように制御したい。 送信は従量課金であり予 算に関係するため、強い 整合性を維持したい (制約1) 通数上限は、「送信依頼」 数と「送信完了」数を足し た数よりも小さい値を設定 できない
27. © KAKEHASHI Inc. ケーススタディ: 所有の見直し SMS送信サービスが「通数上限」を所有すること で、管理画面サービスとSMS送信サービスのデータ 連携パスはなくなりました。 簡易な例で当たり前と思うかもしれませんが、各 サービスを運用するチームが異なっている場合は、 サービスを横断した議論に発展しない場合もありま す。 データ連携以前に、チーム及びサービスを横断して 所有分析することは重要です。 通数上限 SMS送信サー ビス 管理画面 サービス (モノリス) 管理画面フロントエンド HTTP API
28. Ⅲ. データフロー分析
29. © KAKEHASHI Inc. データフロー分析 データをどう流通させるかを明らかにします。 以下のステップで分析を進めます。 1. データフロー図の作成 (1データあたり、1データフロー図) 2. データフロー俯瞰図の作成 (データフロー図を統合)
30. © KAKEHASHI Inc. データ連携方式 Provider Data Consumer イベント ストリーミ ング群 API群 RDS群 Data Provider Data Provider Data Consumer 出典: 大規模データ管理 第2版 | 書籍案内: O'Reilly Japan https://www.oreilly.co.jp/books/9784814400713/ データ連携方式は、3つのパターンに抽象化できま す。 API 同期型のリクエストレスポンス通信。 RDS Readonly-Data Store。読み出し専用(不変)のデー タのまとまりにアクセスさせる。 規模の大きいデータである場合や、複雑な変換を ETLプロセス等を経て供給する場合に有効。 イベントストリーミング 非同期通信。 即時性のあるイベント及びメッセージのストリーミ ング。キューイングやPub/Subもこのパターンに属 する。
31. © KAKEHASHI Inc. (補足)データを所有しているサービスとプロバイダーの違い データを所有する(=書き込みを行う)サービスがプ ロバイダーになることが多いですが、例外もありま す。 例えば、特定のデータの所有が外部サービスやレガ シーシステムであった場合に、業務で利用可能な状 態にするための仲介サービスを設けることがありま す。 真正性のあるデータをマネジメントするサービスの ことゴールデンソースと呼びます。 ゴールデンソースがデータプロバイダーの役目を果 たします。 データプロ バイダー (ゴールデン ソース) 外部サービ ス(所有ソー ス) Normalize
32. © KAKEHASHI Inc. ケーススタディ： 1. データフロー図の作成 (送信依頼 / イベントストリーミング) データ: 送信依頼 顧客サービスにて、顧客の電話番号を特定し、SMS 送信をしたい。 SMS送信のロジックはSMS送信サービスに任せたい。 SMS送信サービスでは、API Rate Limitや通数上限 を考慮する関係で、キューイングをして流量コント ロールをしたい。 イベントストリーミングでデータ連携することとす る。
33. © KAKEHASHI Inc. ケーススタディ: 1. データフロー図の作成 (配信依頼リスト / RDS) データ: 配信依頼リスト 特定のセグメントに対してマーケティングコンテン ツをSMSで配信したい。 SMS送信のロジックはSMS送信サービスに任せたい。 配信依頼リストはバッチサイズが大きく1つの配信 トランザクションの追跡可能性を維持し、ETL処理 に開かれてまとまったデータを参照させたい。 RDS(Readonly-Data Store)で連携することとする。 配信依頼リストの作成が完了したら、完了通知を Event Busを経由して伝達する(Claim Checkパター ン)
34. © KAKEHASHI Inc. ケーススタディ: 1. データフロー図の作成 (配信依頼リスト / API) データ: オプトアウト 顧客サービスが所有するオプトアウトデータを参照 し、マーケティングメッセージを配信していいのか を判断したい。 オプトアウトデータは、SSoTを担保した正確性を維 持し、常に最新性のあるデータを参照したい。例え ば、レプリケーションによるデータ解釈揺れや結果 整合は避けたい。 マーケティングサービスからAPIで参照することと する。
35. © KAKEHASHI Inc. ケーススタディ: 2. データフロー俯瞰図の作成 1つ1つのデータに着目してデータ連携方式を整理し てきましたが、それらを1つにまとめます。 ここまで整理ができると、コンテキスト境界を定め る準備が整います。 データフロー全体を俯瞰し、全体的な依存関係や連 携方式を確認し、必要に応じて、改善点を議論しま す。
36. Ⅳ. システムコンテキスト分析
37. © KAKEHASHI Inc. システムコンテキスト分析 データフロー俯瞰図をインプットに、システムコンテキスト分析をします。主に次の観点を追加してシステ ムアーキテクチャとの整合性を取っていきます。 • ビジネス観点での関心事 • チーム体制 これらに答えはありません。 組織や事業、技術戦略の価値基準によって分析は異なってきます。 次のステップで分析を進めます。 1. データフロー俯瞰図の精査 (データフロー分析で作成したデータフロー俯瞰図を元に観点の整理をし ます) 2. システムコンテキスト図に抽象化
38. © KAKEHASHI Inc. ケーススタディ: 1. データフロー俯瞰図の精査 (精査例) • 顧客サービスとマーケティングサービスは、顧客接点をと るための手段の違いでしかなく、両面でやっていることを 理解し調整しながらカスタマージャーニーを組み立てた い。ゆえ、1チームで扱う解決領域(コンテキスト)とした い。 • 今後のチャネル追加に伴う横断的関心時を扱う解決領域 (コンテキスト)としたい。 • SMS送信サービスで対応する連携方式が多いため、チーム の運用性を考慮して、イベントストリーミング1本に統一 したい。配信トランザクションの追跡可能性はトランザク ションIDを付与することで代替可能である。 • コンテキスト内でAPI連携する開発コストに見合うリター ンが少ないため、オプトアウトは共有DBで運用したい。 データフロー俯瞰図を精査することでデータフロー 自体を見直す場合は、データフロー分析に立ち返っ てください。
39. © KAKEHASHI Inc. ケーススタディ: 2. システムコンテキスト図に抽象化 精査されたデータフロー俯瞰図をインプットに、 ビジネ ス的に解決したい粒度、チーム体制を踏まえて、コン テキストの単位を決定します。 データフロー俯瞰図の精査 のケーススタディで先んじ てコンテキストについても言及していましたが、データ フローが明らかになることでコンテキストへの解像度を 高くなります。 コンテキスト間の関係性、コンテキストとアクターの関 係性を明らかにします。 ※ ここで<<system>>と表記されているのは境界づけ られたコンテキストです。
40. © KAKEHASHI Inc. 補足: C4 model ケーススタディでは、C4 modelのシステムコンテキ スト図とコンテナ図を使って作図しました。 C4モデルは、アーキテクチャをシステムコンテキスト (Context)、コンテナ(Container)、コンポーネント (Component)、コード(Code)の4レイヤーで抽象化 したアプローチです。 引用: https://c4model.com/
41. © KAKEHASHI Inc. システムコンテキスト図 アクターとシステムの関係性、システムとシステム の関係性。解決領域。 コンテナ図 アプリケーションやデータストア、それらの連携方 式 (補足) C4 model 引用: https://c4model.com/
42. © KAKEHASHI Inc. コンポーネント図 インターフェースの背後にカプセル化された関連機 能のグループ。レイヤーやモジュール。 コード図 実際にコードに対応する、データ構造や振る舞いの モデル図。UML等。 補足: C4 model 引用: https://c4model.com/
43. カケハシでの設計活動
44. © KAKEHASHI Inc. 今までのSDLC Software Development Life Cycle (SDLC) 1.計画 2.設計 3.実装 4.テスト 5.デプロ イ 6.メンテ ナンス アーキテチャ レビュー 設計相談 ストリームアラインドチームのSDLCの過程の中で、 主にプラットフォームチームが相談に乗ったり、レ ビューをする運用でした。 また、コンテキスト間データ連携は横断的観点が必 要なため、アーキテクチャレビューは必須としていま す。 プロダクショ ンレディネス チェック (定期) リスクマネジメントレビュー
45. © KAKEHASHI Inc. 課題 • アーキテクチャ設計に関するガイドラインやベストプラクティスが十分でない • 十分なドメイン知識をもってレビューを行えていない • 設計の終盤でレビューしても、プロジェクトの兼ね合いで改善につながりづらい • ストリームアラインドチーム内の設計活動に閉じると、全体最適解につながりづらい
46. © KAKEHASHI Inc. 今後のSDLC Software Development Life Cycle (SDLC) 1.計画 2.設計 3.実装 4.テスト 5.デプロ イ 6.メンテ ナンス アーキテチャ レビュー 設計相談 技術戦略を中長期の視点で組織的に考えていく技術 戦略室が設立されました。(2024年6月〜) チームを横断する複合的課題に焦点を置き、アーキ テクチャの方向性と技術指針を示すミッションがあ ります。 技術戦略室としては、計画・設計段階からイネーブリン グチームとして関わり、 ストリームアラインドチームと伴 奏することで、全体整合性を図ることにしました。 今後は以下の推進を予定しています。 • ビジネス・技術的観点で、TO BEのシステムコ ンテキストの方針策定 • リアーキテクチャによる品質改善の推進 • アーキテクチャガイドラインの策定 プロダクショ ンレディネス レビュー (定期) リスクマネジメントレビュー
47. @kakehashi_dev
 カケハシ技術広報