ステートソーシング型 イベント駆動 の視点で捉える CQRS + ES

Introduction 名前 廣田新之典 (@shin_developer) ECサイト開発のバックエンド開発 業務 経験 Java / Spring Boot: ５年 Kotlin / Spring Boot : 3ヶ月

Archtecture 現在開発を行っているシステムの概要図。 それぞれ基幹マイクロサービスのProduceする Eventを外部連携用のマイクロービスが Consumeし、外部サービスへの連携をしたりし ている。 また逆に外部から受けたリクエスを基幹サービス へ連携する場合もある。 基本的にはステートソーシングでデータは永続化 されている 本日はそのようなシステムの開発に携わっている 視点からCQRS＋ESをみていく

Eventのreplayが大変 1. 2. 過去状態を辿るのが大変 Problems StateSourcingのため最新の状態にデータが書き換わってしまう。 履歴が重要の情報だけデータモデルとして履歴にすることもできるが、 まったく意図しない挙動をしてしまった時はログから調査が必要になるが 運用方針次第ではProd環境で完全に遡ることが困難である場合もある 基本的にはEventは処理されると消えてしまうので、何か不具合が発生し た場合にイベントを再作成に苦労する。また本番環境ではドメインイベン トをログとして出力しない運用になっている場合、その時何が起きたのか も失われてしまう可能性がある。

Eventのreplayが大変 1. 2. 過去状態を辿るのが大変 Problems StateSourcingのため最新の状態にデータが書き換わってしまう。 履歴が重要の情報だけデータモデルとして履歴にすることもできるが、 まったく意図しない挙動をしてしまった時はログから調査が必要になるが 運用方針次第ではProd環境で完全に遡ることが困難である場合もある 基本的にはEventは処理されると消えてしまうので、何か不具合が発生し た場合にイベントを再作成に苦労する。また本番環境ではドメインイベン トをログとして出力しない運用になっている場合、その時何が起きたのか も失われてしまう可能性がある。 運用でカバーできなくはないがEventStoreがほしい

EventStoreを導入するなら もはやCQRS ＋ESにしたほうがいいのでは？

What is Event Store ドメインイベントを時系列順に記 録するデータストアとしての特性 を持つ。一度記録されたデータは 基本的に更新されることがなく、 データの更新の際には新たなイベ ントが記録される。 イベント履歴 ドメインイベントの種別にデータ 構造が異なる可能性が高い。その ようなデータを蓄積する必要があ るため、柔軟なスキーマを併せ持 つNoSQL系DBがイベントストア として採用されるケースが多い。 Kurrent(旧EventStore)のような 専用データストアを用いるケース もある。 柔軟なスキーマ バージョン管理 による拡張 ドメインイベントのを履歴として 管理する必要があり、各イベント 履歴はImmutableである必要が ある。よってバージョンを用いた デシリアライズが一般的である。

CQRS＋ES によって どう変わるか 01 イベント履歴の永続化 イベントが履歴として永続化されることで、障害 時の原因調査や、イベントの再構築が容易にな る。また監査ログとしても利用できる。 Read/Writeのデータモデル衝突の回避 ソフトウェアは性質上記録したい情報と、見せたい情 報で形式が異なりこれを一つのデータモデルで再現し ようとしてバッティングが生じてきた。書き込み側は ビジネスロジックや整合性を重視するのに対し、読み 取り側は迅速なデータ取得や集計を優先したデータ構 造を使用したい。これらを分離することで、システム の保守性の向上が期待できる。 スケーラブルなWriterアプリケーションの構築 柔軟なスキーマ設計を行える点からWrite側のアプリケーシ ョンのデータストアとしてMongoDBのようなNoSQLを用 いるケースが多い。そのためRDBのように複数のインスタ ンスに対して書き込み処理を行えるため、書き込みがスケー ルしない問題を解消することが期待できる。 02 03

とはいえ移行は相当大変なので そこまでしたいほどのモチベはない （その権限もない） 個人的にはトレンドを 趣味で追う程度で現状満足....

Thank you