日本の医療体験を、しなやかに。 © KAKEHASHI Inc. データ資産をシームレスに伝達するための イベント駆動型アーキテクチャ

© KAKEHASHI Inc. 株式会社カケハシ 技術戦略室 2021年、カケハシに入社。サービス・データプラッ トフォームのアーキテクトを担った後に、技術戦略 室にて、開発組織全体の技術領域の戦略を推進。 キャリアを通して、プロダクトの立ち上げの初期か ら関わることが多く、大半はアーキテクトとしての 役割を担ってきました。Data as a Serviceのよう なプロダクトを多く設計開発したこともあり、 「データ」を軸に設計することが多くあります。 カケハシ社内では、サービス間のデータ連携を含む 多くのアーキテクチャレビューに関わってきまし た。 自己紹介 @kimutyam @kimutyam 木村 彰宏 (あきひろ)

1. ドメインイベントを記録する 2. ドメインイベントを伝達する 3. 伝達におけるイベントモデル 4. 状態を転送する 5. データ基盤と統合する 6. まとめ

1. ドメインイベントを記録する

© KAKEHASHI Inc. ステート(集約) 現在の状態 状態遷移した結果 ステートとイベント イベント (ドメインイベント) 業務における出来事 再生可能

© KAKEHASHI Inc. 特徴: 最新の状態を保存する (ex. CRUD) メリット: - 読み書きに同じモデルを利用できる デメリット: - 過去の断面を追跡できない ステートソーシング

© KAKEHASHI Inc. 特徴: ドメインイベントを追記型ログとして記録する メリット: - データ利活用の拡張性が高い - イベント駆動型アーキテクチャやCQRSとの相性がいい デメリット: - アプリケーションの構成難度がやや高い イベントソーシング

© KAKEHASHI Inc. イベントソーシングのメリット - 監査 - タイムトラベル - イベント駆動型アーキテク チャへの拡張可能性 etc.. FYI: Kurrent(旧、EventStore)の 『A Beginner’s Guide to Event Sourcing』でメリットが詳しく説明 されています。 https://www.kurrent.io/event-sou rcing#Benefits-of-Event-Sourcing

© KAKEHASHI Inc. ドメインイベントがないことによる機会損失 たいていのアプリケーションはス テートソーシングで実現は可能で す。 しかし、データ分析・利活用が当た り前になった昨今で、ドメインイベ ントを記録していないことが機会損 失につながります。 イベントを記録していない場合に、 達成できない業務が存在します。 例えば、「月間の人事異動推移を把 握する」業務は、ドメインイベント データ「社員を部署異動した」がな いと達成できません。

© KAKEHASHI Inc. ドメインイベントの記録が重要課題ならば、ステートとともに保存すればよいだけです。 CQSは保守性、CQRSは信頼性・性能効率性の課題を解決するものであり、必須ではありません。 リファレンスアーキテクチャ (ドメインイベントの記録)

2. ドメインイベントを伝達する

© KAKEHASHI Inc. リファレンスアーキテクチャ(CQRS + Transaction Outbox) ドメインイベントが追記されたこと をCDC(Change Data Capture)しま す。 CDCで受け取ったイベントは、シス テム境界内外への伝達でします。 ドメインイベントがインターフェー スとして機能します。 ※ システム境界内外に同じ仕組み で伝達できることを説明の例です。 CQRSパターンを導入する必要はあり ません。

© KAKEHASHI Inc. AWSでのインフラ例 CDC(Change Data Capture)機能が備 わったDynamoDBのCommandのデータ ベースとしたリファレンスアーキテ クチャを説明します。

© KAKEHASHI Inc. AWSでのインフラ例(〜イベントストリームへレコードを伝達) - DynamoDB StreamでCDCを受け 取り、Lambdaでプライマリー キー毎に、シーケンス番号を 付与してKinesis Data Stream(以降、KDS)のシャード にPutすることで順序保証しま す(※1) - Lambdaでは、DynamoDB Stream の方言(※2)を解析し、イベン トスキーマに変換すること で、コンシューマは公表され た言語としてデータを消費で きます。 - Kinesis Data Stream(KDS)で ファンアウトします。 ※1 https://aws.amazon.com/jp/blogs/news/how-to-perform-ordered-data-replication-between-applications-by-using-amazon-dynamodb-streams/ ※2 https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/APIReference/API_streams_StreamRecord.html

© KAKEHASHI Inc. AWSでのインフラ例(〜システム境界外への伝達) EventBridgeはイベントバスです。 ルールベースのフィルタリングや、 ルーティングも容易に実現可能で、 プロデューサーとコンシューマーを 疎通を疎結合にするマネージドサー ビスです。 境界づけられたコンテキスト外との 疎通でよく取っているアプローチで す。 ※ 高いスケーラビリティ要求があ る場合は、KDSをシステム境界とす る場合もあります。

© KAKEHASHI Inc. 現実解1: AWSでのインフラ例 (バッチスケジュールでイベントバスに伝達) CDCをサポートしていないデータ ベースでかつ、即時性の要求がない 場合の素朴な方法は、リードレプリ カに対してイベントをクエリするこ とです。 ただ、データベースへの負荷問題や 本体の影響がでるため、CDCツール を導入するのが一般的です。

© KAKEHASHI Inc. 現実解2: AWSでのインフラ例 (DebeziumでCDC) CDCツールを導入するのが有効で す。 ※ CDCツールはカケハシ社内で検証 中ですので、一般解として記載して います。 以下の記事は国内事例です。 FYI: Amazon MSKを用いてMySQLに対して Change Data Captureを実現する https://techblog.zozo.com/entry/ change-data-capture-for-mysql-us ing-amazon-msk

© KAKEHASHI Inc. ドメインイベントはデータ連携の銀の弾丸？ ドメインイベントを記録し、汎用的 な構成でシステム境界内外への伝達 まで行えることを説明してきまし た。 しかし、コンシューマーにとって は、ドメインイベントの粒度が細か すぎたり、イベント再生のための知 識が必要になり、結合度が高くなる 場合があります。

3. 伝達におけるイベントモデル

© KAKEHASHI Inc. イベントデータ 伝達用途でイベントデータは構造化 される。 イベントデータの構成要素。 - Header: - イベントのメタデータ - 伝達に利用するテクノロ ジに依存 - Key: - パーティショニングキー 用途 (オプション) - Value: - イベントを表す値 FYI: 「ドメインイベントを伝達するため のモデリング技法」 https://kakehashi-dev.hatenablog .com/entry/2024/05/15/090000

© KAKEHASHI Inc. デルタイベントとファクトイベント イベントモデルは伝達の文脈だと、2種類に大別されます。 以下は、イベントデータの構成要素のValueの違い。(HeaderとKeyは同様。) { "組織ID": "Organization-ID-123" , "部署": [ { "部署ID": "Department-ID-1234" , "社員IDリスト": [ "Employee-ID-1234" , "Employee-ID-5678" ] }, { "部署ID": "Department-ID-5678" , "社員IDリスト": [ "Employee-ID-2234" , "Employee-ID-6678" ] } ] } { "社員ID": "Employee-ID-1234" , "異動前部署ID": "Department-ID-1234" , "異動後部署ID": "Department-ID-5678" } デルタイベント ファクトイベント

© KAKEHASHI Inc. デルタイベント 特徴: - ドメインイベントのこと - 変更のコンテキストを有する 向いている用途: - 特定の条件に反応 - ex. 通知 / 部署異動後に権限の切り替 え - イベントに基づいたカスタムビューの構成 (例: CQRS) - 関心のあるドメインイベントだけをサブスク ライブ 不向きな用途: - 現在の状態を取得したい場合 - 異なるコンテキストでイベント再生を する用途の場合、深いドメイン知識が 必要になるため結合度が高くなる

© KAKEHASHI Inc. 特徴: - イベントのValueに(集約の)状態を持つ。 向いている用途: - Event-Carried State Transfer(ECST)パター ンで、状態を転送する。 - コンシューマーは、計算せずともイベ ントストリームのシャードの最新レ コードを取得するだけで、最新の状態 を再現できる。 向いていない用途(※1): - 特定の条件に反応する - 状態遷移した理由を辿る ファクトイベント

© KAKEHASHI Inc. メリット - コンシューマーで状態を保持しなくてもいい - 転送コストを削減できる (ただし、参照コストとの天秤) - 実現方法がシンプル デメリット - コンシューマーが増えるたびにプロバイダー側がSPoFにな る - 他のサービスを呼び出さなければ、本当の意味で機能しな い (可用性依存) - 索引方法が限定的。コンシューマーのコンテキスト独自の データの処理をしたい場合は不向きです。 
 Appendix: APIで状態を参照する

4. 状態を転送する

© KAKEHASHI Inc. 状態を転送する用途であれば、ステートソーシングでも対応が可能です。 CDCを通じてファクトイベントを転送するだけです。 ただし、テーブル構造をそのままイベントバスに含めると結合度が高くなるため、イベントスキーマ に変換することをお勧めします。 リファレンスアーキテクチャ

© KAKEHASHI Inc. システムの内部テーブル構造にCDCする対象が複数の場合(ex. 正規化)に、イベントを受け取るコン シューマーでデータを統合する複雑性が生じます。統合はプロデューサーの内部構造に依存するの で、結合度が高くなります。 解決方法は一般的に2つあります。 1. イベントストリーム再構築パターン 2. Transactional Outbox パターン 状態転送における課題

© KAKEHASHI Inc. 集約単位でイベントストリームを再構築します。 イベントストリームの運用難易度は高いですが、Producer側のデータベースに変更を加えられない場 合は有効な手段になります。 解法1: イベントストリーム再構築パターン

© KAKEHASHI Inc. Transaction Outbox パターンは、内部で管理するデータ構造(Internal Table)と、外部に伝達する データ構造(Outbox Table)を分割するデザインパターンです。 Producer側のデータベースに変更を加えられる場合は、運用がシンプルであるため有効な手段です。 解法2: Transaction Outbox パターン

5. データ基盤と統合する

© KAKEHASHI Inc. 昨今の業務ユースケースは、データ分析結果に依存することが増えています。 例: ECサイトの注文履歴データを、データ基盤でリアルタイム分析し、分析結果とユーザーのセッ ションに基づいて商品のレコメンドする。 イベントストリーミングは、アプリケーションとデータ基盤をシームレスに連携させる役目を果たし ます。 ※ 慣習的に、即応性のあるアプリケーションとデータ基盤をそれぞれOperational(運用)、 Analytical(分析)と表現することが多いです。 運用と分析の垣根をなくす 出典: INFINITE LAMBDA, "Event-Driven Data Mesh: Understanding the Fundamentals", https://infinitelambda.com/event-driven-data-mesh-fundamentals/

© KAKEHASHI Inc. イベントストリームを通じてマルチモーダルに展開できます。 データ基盤用に別のデータパイプラインを用意する必要はありません。 ※ カケハシでは、ドメイン毎にデータ基盤を運用するアーキテクチャポリシーを敷いています。 (関連: データメッシュ) リファレンスアーキテクチャ

© KAKEHASHI Inc. カケハシでは、データ基盤(レイクハウス)としてDatabricksを採用しています。 DatabricksのCDF(Change Data Feed)機能を使って、Databricks内のストレージ(Deltaテーブル)への 変更を捕捉できます。 捕捉したのち、後続のデータパイプラインでイベントストリームに送信できます。 データ基盤からイベントデータストリームへ 出典: Databricks,"How to Simplify CDC With Delta Lake's Change Data Feed", https://www.databricks.com/blog/2021/06/09/how-to-simplify-cdc-with-delta-lakes-change-data-feed .html

© KAKEHASHI Inc. AWSでのインフラ例(Databricksからイベントストリームへ) - Kinesis Data Streamを経由してDatabricksに入力 - DatabricksのCDF(Change Data Feed)を使って、Kinesis Data Streamへ出力

© KAKEHASHI Inc. 現実解1: Databricksへの同期インジェスション 分析用途に閉じた利用の場合は、イベントストリームでデータ連携する必要はありません。 スケジュールバッチで、データベースのスナップショットからデータを同期します。 CDF(Change Data Feed)を使えば、出力をイベントストリームにすることは可能。

© KAKEHASHI Inc. 現実解2: Databricks to EventBridge (Claim Check) Claim Checkとは: - ペイロードをデータストアに外部化し、イベントにはペイロードを含めずに、アクセスするため のパスやトークンを含めるデザインパターン 用途: - 分析結果のデータサイズが大きい場合 - ストリーミング処理をする必要がない場合 デメリット: - イベントバスとストレージの両方の通信の口を用意する必要がある

6. まとめ

© KAKEHASHI Inc. - ドメインイベントは記録する価値がある - CDCを使ってイベントストリームに展開できる - イベントストリーム・イベントバスを通じてサービス間連携を行う - ドメインイベント(デルタイベント)は、通知やカスタムビューの構成に向いている - ファクトイベントは、状態の転送に向いている - イベントストリームを通じてアプリケーションとデータ基盤はシームレスに連携できる まとめ

© KAKEHASHI Inc. リファレンスアーキテクチャ

@kakehashi_dev
 カケハシ技術広報