Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
データ資産をシームレスに伝達するためのイベント駆動型アーキテクチャ
Search
KAKEHASHI
PRO
February 17, 2025
Technology
2
230
データ資産をシームレスに伝達するためのイベント駆動型アーキテクチャ
イベント駆動型アーキテクチャ - イベントを主役にすることで解決できること -
https://findy-tools.connpass.com/event/343692/
での登壇資料です
KAKEHASHI
PRO
February 17, 2025
Tweet
Share
More Decks by KAKEHASHI
See All by KAKEHASHI
アジャイルチームが変化し続けるための組織文化とマネジメント・アプローチ / Agile management that enables ever-changing teams
kakehashi
PRO
3
4.1k
チームが毎日小さな変化と適応を続けたら1年間でスケール可能なアジャイルチームができた話 / Building a Scalable Agile Team
kakehashi
PRO
3
350
知らない景色を見に行こう チャンスを掴んだら道が開けたマネジメントの旅 / Into the unknown~My management journey~
kakehashi
PRO
11
1.9k
KAKEHASHI Company Deck / Company Deck
kakehashi
PRO
4
1.5k
アジャイルチームがらしさを発揮するための目標づくり / Making the goal and enabling the team
kakehashi
PRO
4
960
適材適所の技術選定 〜GraphQL・REST API・tRPC〜 / Optimal Technology Selection
kakehashi
PRO
1
940
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
PRO
2
330
スプリントゴールにチームの状態も設定する背景とその効果 / Team state in sprint goals why and impact
kakehashi
PRO
2
240
プロダクト成長に対応するプラットフォーム戦略:Authleteによる共通認証基盤の移行事例 / Building an authentication platform using Authlete and AWS
kakehashi
PRO
1
410
Other Decks in Technology
See All in Technology
第13回 Data-Centric AI勉強会, 画像認識におけるData-centric AI
ksaito_osx
0
360
Ask! NIKKEI RAG検索技術の深層
hotchpotch
13
2.8k
Classmethod AI Talks(CATs) #15 司会進行スライド(2025.02.06) / classmethod-ai-talks-aka-cats_moderator-slides_vol15_2025-02-06
shinyaa31
0
170
[2025-02-07]生成AIで変える問い合わせの未来 〜チームグローバル化の香りを添えて〜
tosite
1
290
Platform Engineeringは自由のめまい
nwiizo
4
1.9k
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code
nihonbuson
11
5.8k
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
recruitengineers
PRO
3
100
CZII - CryoET Object Identification 参加振り返り・解法共有
tattaka
0
240
転生CISOサバイバル・ガイド / CISO Career Transition Survival Guide
kanny
2
390
スタートアップ1人目QAエンジニアが QAチームを立ち上げ、“個”からチーム、 そして“組織”に成長するまで / How to set up QA team at reiwatravel
mii3king
1
1.1k
プロセス改善による品質向上事例
tomasagi
1
1.6k
『衛星データ利用の方々にとって近いようで触れる機会のなさそうな小話 ~ 衛星搭載ソフトウェアと衛星運用ソフトウェア (実物) を動かしながらわいわいする編 ~』 @日本衛星データコミニティ勉強会
meltingrabbit
0
120
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
29
4.6k
Mobile First: as difficult as doing things right
swwweet
223
9.3k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Being A Developer After 40
akosma
89
590k
RailsConf 2023
tenderlove
29
1k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.6k
Navigating Team Friction
lara
183
15k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
GraphQLとの向き合い方2022年版
quramy
44
13k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
Transcript
日本の医療体験を、しなやかに。 © 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 カケハシ技術広報