２年間の実運用を経て振り返るイベントソーシングの実際

私たちは、中小規模システムにおけるイベントソーシングの可能性に着目し、
2022年4月から社内でイベントソーシングフレームワークの開発と運用をしています。
現在では、社内システムや受託システムを含む5つ以上のシステムにイベントソーシングを導入しています。
本セッションでは、イベントソーシングを用いたシステム構築と運用を通じて得られた知見を振り返るとともに、
C#で開発しオープンソースとして公開した
ES CQRSフレームワーク「Sekiban」の開発経緯とその経験についても共有します。

https://cqrs-es-con.connpass.com/event/333271/

Transcript

1. ネットシェア 可 ２年間の実運⽤を経て振り返 るイベントソーシングの実際 株式会社ジェイテックジャパン ⾼丘 知央 2024年12⽉21⽇ (⼟曜⽇) 1:50PM-2:30PM CQRS+ESカンファレンス #cqrs_es_con 1
2. ネッ トシェア 可 ⾃⼰紹介 X: @tomohisa Github: @tomohisa Works at : 株式会社ジェイテックジャパン, J-Tech Creations, Inc. JTS Group - 株式会社ジャパンテクニカルソフトウェア 品川 CTO: 中⼩企業向けの受託開発を、モダンな開発スタイルで。 Microsoft MVP for Developer Technologies (Web Development, .NET) new from November 2024 - OSS: Sekiban - Event Sourcing and CQRS Framework ResultBoxes - Railway Oriented Programing Library. ⾼丘 知央 - Tomohisa Takaoka 2 / 48
3. ネッ トシェア 可 最近の活動 先⽉、Findyアーキテクチャカンファレンスで登壇しました。アーカイブも公開されて います。今⽇の話でももうちょっとシンプルな話を聞きたい⽅はどうぞ https://findy-tools.io/events/6ca88d269bb9777a8dec 3 / 48
4. ネッ トシェア 可 ２年間の実運⽤を経て振り返るイベントソーシングの実際 セッション概要 • 1. なぜ私たちはイベントソーシングを使うようになったのか？ • 2. これまでのイベントソーシング利⽤‧運⽤実績 • 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在の私たちの答え ◦ ❶ データの読み込みスピードが遅いのではないか？ ◦ ❷ ミスしたデータの調整を含めた運⽤は⼤変なのか？ ◦ ❸ 費⽤的には問題ないのか？ ◦ ❹ トランザクションとデータの⼀貫性は担保されるのか？ ◦ ❺ 分散システムへの対策はできているのか？ ◦ ❻ イベントソーシングは難しいと感じるが、⼤丈夫なのか？ • 4. イベントソーシング導⼊ガイド ◦ シンプルな実装で理解してから取り組む場合 ◦ Sekibanなどのフレームワークを採⽤する場合 • 5. まとめ 4 / 48
5. ネッ トシェア 可 1. なぜ私たちはイベントソーシングを使 うようになったのか？ 5 / 48
6. ネッ トシェア 可 1. なぜ私たちはイベントソーシングを使うようになったのか？ 6 / 48 イベントソーシング使⽤の経緯 ジェイテックジャパン: 中⼩規模の業務システムの受託開発企業 -2018: C# MVC + RDB (Fat Controller で困る) 2019-2022: C# DDD学習 → 導⼊ 意図せずして軽量DDD 2022: 振り返りで新アーキテクチャ研究開始、イベントソーシングを⾒つける 2022: 既存システムにイベントソーシングを⼀部導⼊、Sekiban開発開始 2023/12: OSSでSekiban - イベントソーシング‧CQRS フレームワークリリース
7. ネッ トシェア 可 1. なぜ私たちはイベントソーシングを使うようになったのか？ 7 / 48 これまでのターゲット: 中⼩規模の業務システム • モノリス or スケールアウト構成 • フロントエンド バックエンド RDB キューストレージ BLOBストレージ • Greg Youngによるイベントソーシングの説明のビデオを⾒た時に、『⾃分たちの作成している、 中⼩企業向けのシステム』に合っていると感じた。 • Greg Youngのイベントソーシングは基本⾃分で実装、複雑なシステムではなくシンプルなシステ ムとして説明されているので、できる気になったww • 実際には多くの現場ではマイクロサービス、ストリーミングデータベース、Kafka、イベント駆 動などと組み合わされた複雑かつ⼤規模なシステムで多く使⽤されていることは、後から知るこ とになる。
8. ネッ トシェア 可 1. なぜ私たちはイベントソーシングを使うようになったのか？ 8 / 48 Sekibanで作ったシステムのアーキテクチャ（モノリスベース） • モノリス、もしくは機能毎に分けたサー バーを使⽤している。 • スケールアップでできるだけ機能拡張 • 『ライブプロジェクション』をベースに している。メモリ内で単集約も、複数集 約もイベントからステートの計算を⾏ い、インメモリで管理 • メモリキャッシュ（インメモリ+Redisな どのKVS）を使⽤して、計算結果は実⾏ 時は継続して保存 • ⼀定期間おきにFileやDocumentDBにス ナップショットを保存 • メモリが⾜りている間は⾼速に動作する バックエンドAPIサーバー コマンド 集約 イベント データベース イベント イベント イベント フロントエンド API コマンド ハンドラー ライブ プロジェクション ① パーティション毎 ②複数パーティション クエリ API Cosmos DB etc.. Blob Storage スナップショット メモリキャッシュ ❶⾼速、実⾏時は逐次保存 ❷再⽣不要、⼀定期間おきの情報 ❸遅いが全ての事実を含む Cosmos DB+File Storage etc..
9. ネッ トシェア 可 1. なぜ私たちはイベントソーシングを使うようになったのか？ 9 / 48 モノリスベースのアーキテクチャを使ってみて • モノリスベースのイベントソーシング で、数⼗⼈、数百⼈が使うシステムでは ⼗分対応できている • まだまだサーバー拡張の余裕が⼗分あ る、DAU数千⼈でもこのアーキテクチャ で問題ないと考えている • 現時点では正式運⽤しているのが社内プ ロジェクトのみのため、慌てて⼤規模シ ステム⽤の共通機能を作るのではなく、 現在の中⼩規模向けのアーキテクチャの 中で、どれだけ効率よく書くことができ るか、コストパフォーマンスの良いシス テムにするかにフォーカスして開発して きた。 バックエンドAPIサーバー コマンド 集約 イベント データベース イベント イベント イベント フロントエンド API コマンド ハンドラー ライブ プロジェクション ① パーティション毎 ②複数パーティション クエリ API Cosmos DB etc.. Blob Storage スナップショット メモリキャッシュ ❶⾼速、実⾏時は逐次保存 ❷再⽣不要、⼀定期間おきの情報 ❸遅いが全ての事実を含む Cosmos DB+File Storage etc..
10. ネッ トシェア 可 1. なぜ私たちはイベントソーシングを使うようになったのか？ 10 / 48 第１部まとめ 今⽇の登壇では、中⼩規模のシステム向けに作られたSekibanを使⽤して約２年 半でどのように開発と運⽤をおこなってきたのか、これからも引き続き、イベン トソーシング、CQRSをどのように活⽤していきたいと考えているかを発表しま す。
11. ネッ トシェア 可 2. これまでのイベントソーシング利⽤‧ 運⽤実績 11 / 48
12. ネッ トシェア 可 2. これまでのイベントソーシング利⽤‧運⽤実績 12 / 48 2-① 最初に開発したイベントソーシングシステム • ３年間開発、２年ほど本番運⽤してきたDDDシステム • モノリス+RDBの建築業界のデータ管理システム • データのアップロード→計算処理 本番で数分で数百データアップロード • Azure Functions から同時アクセスによるトランザクションエラー • 失敗したくない処理も失敗するようになる イベントソーシングでアップロードや計算の開始終了処理を管理 • トランザクションエラーがなくなり、安定してシステム稼働 • ビルトインで開発したイベントソーシング機能を切り分けてSekiban開発開始 • 約2年たった今でも、安定して動作している
13. ネッ トシェア 可 2. これまでのイベントソーシング利⽤‧運⽤実績 13 / 48 2-② Sekibanと同時開発した、社内経費精算システム • 新しく必要な機能があったのと、Sekibanの機能確認を兼ねて旧システムの作り直しで新規開発 • Sekiban設計者の⼀⼈が担当したので学習などの問題はなし • ２年間くらい運⽤の問題も特になし • Sekibanのバージョンアップに合わせてコードスタイルなどが変化しているが、データストアは 同じものを継続して使⽤ • Cosmos DB には、Serverless モードがあり、データベース百円程度/⽉、App Service 2000円程 度 / ⽉で三⼗⼈程度のデータを運⽤できている
14. ネッ トシェア 可 2. これまでのイベントソーシング利⽤‧運⽤実績 14 / 48 2-③ 既存システムの追加機能 • 学校向けコンテンツ管理システムに、権限情報の管理をする新規機能が必要になり、Sekiban開 発者が担当したため、Sekibanが使いやすいから採⽤ • 数画⾯程度のバックエンドをSekibanで数⽇で実装、テスト、リリース • サービス終了まで約１年程度、運⽤上の問題もなし • Cosmos DB のデータをJSONLのファイルとしてエクスポートして、将来必要になった場合にイン ポート可能にして、サービス終了 • (コンソールのエクスポートツールを作成)
15. ネッ トシェア 可 2. これまでのイベントソーシング利⽤‧運⽤実績 15 / 48 2-④ 顧客向け新規開発でSekibanを採⽤ • 社内むけSekibanの安定稼働が確認できたのち、顧客向け新規プロジェクトに採⽤ • 運輸業界、部品管理など⽐較的複雑なドメイン • バックエンド開発はC#経験20年のベテランエンジニア（イベントソーシング経験はなし） • Sekiban開発者がサポートしつつイベントソーシングを導⼊ • フロントエンドからは基本的にイベントソーシングのコマンドを実⾏ • エクセルデータのインポート、エクスポート、帳票などもあり、バックエンドだけで15-20⼈⽉、 フェーズ4まで実施されている • 開発者はSekibanの採⽤により、⽤途によりコードが分かれてわかりやすく、メンテナンスも⾏いや すいとのこと。 • クラウド事業者のセールス担当にインフラ費⽤がアプリケーション規模に⽐べて安くて驚かれた。
16. ネッ トシェア 可 2. これまでのイベントソーシング利⽤‧運⽤実績 16 / 48 2-⑤ データ分析＋AI開発基盤にSekibanを採⽤ • 数万⼈が使⽤するデータの⽉次データ分析のための基盤としてイベントソーシングを採⽤ • RDBからデータを取得し、計算をしてデータ集計を集約で計算 • 集約で計算されたデータの多⾯的なデータ解析、標準偏差の計算などを計算集約で実⾏ • 計算結果をLLMに渡して要約する • 複雑な計算ドメインでもイベントソーシングが役に⽴つことを検証 • デバッグがしにくいと最初感じた（データが全体的に多くなるため） • コンソールアプリでデータ確認、デバッグが⾏うことができるようにすることにより、⼗分に複雑な プログラムの開発、確認が⾏えることを学習
17. ネッ トシェア 可 • 既存アプリケーションのコンバート (PHP) • アプリケーションのドメインはイベントソーシングがマッチしていた。 • 営業エンジニアがイベントソーシングおよびSekibanの利点をその時点で深く理解していなかったた め、最終的にSekibanではなく、PHPのバージョンアップおよびコンバート案件となった • 書き込みデータがイベントになることにより、データの共有を⾏なっている他者との連携を⼼配した という⼀⾯もあります 2. これまでのイベントソーシング利⽤‧運⽤実績 17 / 48 2-⑥ Sekiban採⽤に⾄らなかったプロジェクト
18. ネッ トシェア 可 2. これまでのイベントソーシング利⽤‧運⽤実績 18 / 48 第２部まとめ これまで２年半イベントソーシング、CQRSを使⽤してきて、中⼩規模のシステ ムに関して、シンプルなアーキテクチャで実装したSekibanを⽤いることによ り、効率的に開発することができています。これからもイベントソーシング、 CQRSを継続的に採⽤していきたいと思っています！！
19. ネッ トシェア 可 3. イベントソーシング‧CQRSでよく聞 かれる疑問と、現在のわたしたちの答え 19 / 48
20. ネッ トシェア 可 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 20 / 48 • ❶ データの読み込みスピードが遅いのではないか？ • ❷ ミスしたデータの調整を含めた運⽤は⼤変なのか？ • ❸ 費⽤的には問題ないのか？ • ❹ トランザクションとデータの⼀貫性は担保されるのか？ • ❺ 分散システムへの対策はできているのか？ • ❻ イベントソーシングは難しいと感じるのですが、⼤丈夫なのか？
21. ネッ トシェア 可 • ビジネス要件に従い、キャッシュ とスナップショットを有効に利⽤ する • プロジェクションには各観点で データを組み⽴てた全データが含 まれるので、クエリではそれをフィ ルタして返す。 • 要件によってはイベントデータベー スを読まずキャッシュを返すこと もできる 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 21 / 48 ❶ データの読み込みスピードが遅いのではないか？ ① キャッシュとスナップショットの連携により、実⾏時速度を改善 イベント データベース ライブ プロジェクション ① パーティション毎 ②複数パーティション クエリ Blob Storage スナップショット メモリキャッシュ ⾼速、実⾏時は逐次保存 再⽣不要、 ⼀定期間おきの情報 遅いが全ての事実を含む 14:10の製品在庫 リストください 起動時にはメモリ キャッシュにはない 昨⽇の17:00, Version 20000まである 今 14:10までのプロ ジェクションをす る。最新1000のイベ ントを取得してプロ ジェクション メモリキャッシュに 保存 サーバー起動時 サーバー起動後 14:13:00の製品在 庫リストください 14:10のプロジェク ションがある 14:10:00-14:13:00の プロジェクションを します。50のイベン トを取得してプロ ジェクション メモリキャッシュに 保存 14:13:02の製品在 庫リストください 14:13:00のプロ ジェクションから 返却 Version 25000に到達 した時点でスナップ ショットを⾃動更新 する
22. ネッ トシェア 可 • スナップショットのバージョンに より、変化があった時に過去のス ナップショットを利⽤しない • プロジェクターのコードを修正した ときは、プロジェクションを1から やり直す (CQRS) • プロジェクションを最新に保つこ とにより起動時のもたつきを防ぐ 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 22 / 48 ❶ データの読み込みスピードが遅いのではないか？ ② スナップショットバージョンにより古いデータに起因するバグを修正 クエリ Blob Storage スナップショット 該当バージョンのプロジェク ションがない場合は、V1から プロジェクションして、保存 する 在庫プロジェクション スナップショット V1.0 12/18 4:00 Version 20000 在庫プロジェクション スナップショット V1.0 12/20 17:00 Version 25000 時系列 12/20 12/21 12/25 プロジェクション コード修正V1.1 在庫プロジェクション スナップショット V1.1 12/24 17:00 Version 26000
23. ネッ トシェア 可 • クエリは検索パラメータ • クエリハンドラは、プロジェクションの 全データをフィルタリングして返す • プロジェクションは基本はメモリキャッ シュ＋最新データで作る • メモリキャッシュがない場合（通常は起 動時）にスナップショットを使⽤する 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 23 / 48 ❷ ミスしたデータの調整を含めた運⽤は⼤変なのか ⓪ 前提として、ライブプロジェクションのクエリの動作を解説 イベント データベース ライブ プロジェクション ① パーティション毎 ②複数パーティション クエリ Blob Storage スナップショット メモリキャッシュ ⾼速、実⾏時は逐次保存 再⽣不要、 ⼀定期間おきの情報 遅いが全ての事実を含む 広義のプロジェクション は同種の全データを含む API 必要データをリクエスト クエリハンドラー プロジェクションデータを フィルタリングして返す return projection .Where(r => r.id == q.id) .OrderBy(q.sortParam) なければ 最新だけ
24. ネッ トシェア 可 • アーキテクチャに関しての教育がよく出 来ていなかった運⽤者が、イベントを直 接変更したが、表⽰データが変わらなく て混乱した。 • 通常、古いイベントはスナップショット とメモリキャッシュに阻まれ、参照され ない • 修正イベント発⾏が基本。最悪イベント をアップデートして、スナップショット を削除して再起動することも可能 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 24 / 48 ❷ ミスしたデータの調整を含めた運⽤は⼤変なのか ① データの直修正をしてもうまく反映されない、修正イベントが必要 イベント データベース ライブ プロジェクション ① パーティション毎 ②複数パーティション クエリ Blob Storage スナップショット メモリキャッシュ ⾼速、実⾏時は逐次保存 再⽣不要、 ⼀定期間おきの情報 遅いが全ての事実を含む 広義のプロジェクション は同種の全データを含む API 必要データをリクエスト クエリハンドラー プロジェクションデータを フィルタリングして返す return projection .Where(r => r.id == q.id) .OrderBy(q.sortParam) なければ 最新だけ
25. ネッ トシェア 可 • Cosmos DBはデータのエクスポートが 簡単ではない • ConsoleアプリケーションでSekiban移 ⾏⽤のツールを作成した。データ型をコ ンバートすることも可能 • Cosmosは2MB、Dynamoは400KB、 Postgresも⼤きなデータを置くと遅くな るので注意 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 25 / 48 ❷ ミスしたデータの調整を含めた運⽤は⼤変なのか ② データベース全体の移⾏⽅法 本番データベース 検証⽤Cosmos DB Sekiban 移⾏ツール 検証/移⾏Postgres 検証/移⾏Dynamo
26. ネッ トシェア 可 • 中⼩規模システムには、サーバーレスモードが⾮常に役⽴つ • 30名で使⽤する社内経費精算システムはAzure Cosmos DB サーバーレ スモード100円以下/⽉、バックエンドサーバーが約2000円/⽉程度 • 受託開発の顧客に提供しているシステムも価格が安くてクラウド担当 者が驚いていた（キャッシュとスナップショットでイベントへのアク セスは最低限） • モバイルアプリの使⽤状況を分析しているデータがたくさん⼊るシス テムで現在数千円程度/⽉ • 要求ユニット RUで計算するため、予測しにくいが予測値より安かっ た。 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 26 / 48 ❸ 費⽤的には問題ないのか？ Azure Cosmos DB サーバーレスモード 従量課⾦ Azure Cosmos DB プロビジョニングモード Serverlessの半額だが、 最低価格が 約4000円/コンテナ
27. ネッ トシェア 可 • Sekibanは書き込みでトランザクションをかけていま せん。 • レコードの変更をしないため、同時変更が原因でのエ ラーは⽣じない • 過負荷などで失敗したときは、しばらく待ってリトラ イする。それでもエラーの時は、プロセスにエラーと して返す • 複数イベントのうちで⼀部エラーになるケース起きる 可能性があるが、現状問題になっていない 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 27 / 48 ❹ トランザクションとデータの⼀貫性は担保されるのか？ ① トランザクションなしで⼀貫したデータとなるのか？ バックエンドAPIサーバー コマンド イベント データベース イベント イベント イベント フロントエンド コマンド ハンドラー API Cosmos DB etc.. 過負荷による失敗 リトライ Resultで失敗 500エラー
28. ネッ トシェア 可 • 楽観的バージョンエラーで先に誰かがデータを書 き換えてしまった場合は、エラーとすることがで きます。 • この⽅法で500ms以上の時差で実⾏したエラーは 防ぐことが可能です。 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 28 / 48 ❹ トランザクションとデータの⼀貫性は担保されるのか？ ② 同時書き込みによる不整合は起きないのか？ バックエンドAPIサーバー コマンド 集約 Version3対象 集約 Version 4 イベント データベース フロントエンド コマンド ハンドラー ライブ プロジェクション ① パーティション毎 ②複数パーティション API 集約 Version 3 楽観的バージョン エラー
29. ネッ トシェア 可 • バックエンドサーバーにおいて は、同じ集約（パーティショ ン）に対して2つのコマンドを 同時に実⾏しない。 • これにより、同時書き込みによ る不整合や競合状態(レースコ ンディション)を防ぎ、⼀貫性の ないデータが作成されることを 防ぐ。 • Sekibanにおいては、シャー ディングは使⽤せず、同種の集 約は同じサーバーにおくことで 対処している 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 29 / 48 ❹ トランザクションとデータの⼀貫性は担保されるのか？ ② 同時書き込みによる不整合は起きないのか？ コマンド 集約 Version3対象 集約 Version 4 イベント データベース フロントエンド API 集約 Version 3 コマンド 集約 Version3対象 フロントエンド API 集約 Version 3 時系列 コマンド ハンドラー コマンドハンドラー １集約につき １スレッドのみ実⾏できる コマンド実⾏待機 楽観的バージョンエラー!! バックエンドAPIサーバー イベント
30. ネッ トシェア 可 • Sagaパターンは、分散トランザクションを扱 う際に⻑い⼀貫性のある処理を複数の⼩さな ステップ（イベント）に分割し、それぞれの ステップで状態をイベントとして⾮同期的に 通知します。また、失敗が発⽣した場合には 補償トランザクションを実⾏することで整合 性を保ち、レースコンディションや不整合状 態を防ぐことが可能になります。 • OrderRequested → PaymentProceeded → OrderConfirmed といったイベントの流れで 処理を段階的に進めるのは、まさにSagaパ ターンの典型的なアプローチです。 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 30 / 48 ❹ トランザクションとデータの⼀貫性は担保されるのか？ ③ Requested And Confirmed パターン[Sagaパターン]を⽤いて処理を進める チケット購⼊コマンド１ チケット購⼊コマンド２ 時系列 バックエンドAPIサーバー チケット予約受付 イベント１ チケット予約受付 イベント２ チケット確定 コマンド１ チケット購⼊確定 イベント１ チケット確定 コマンド２ チケット購⼊失敗 イベント２ 時系列 イベントの購読に よるコマンド実⾏ 2つの別集約 1つの確定⽤プロセス Functions, Lambdaなど
31. ネッ トシェア 可 • 不整合なデータが発⽣した場合、エラーイベン トを無視するのではなく、エラー状態の集約に 変換する形でモデリングする • エラー状態の集約になった場合、修復イベント を発⾏しないと、通常状態に戻れないようにモ デリングする • 継続処理するためには正しいデータに修正しな いといけない • 上記は⼀例ですが、モデリングにより多くの問 題が解決できる。(SQL更新クエリによる障害を なくす) • 全てのデータがあるのでデバッグは⾮常に容易 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 31 / 48 ❹ トランザクションとデータの⼀貫性は担保されるのか？ ④ ⼆重データや不整合データが起きたときはどうするのか？ 購⼊処理中集約 商品3 合計3000円 注⽂確定イベント ⽀払い処理済みイベント 3000円クレジット払い 購⼊済み 発送待ち集約 商品3 合計3000円 ⽀払い済 ⽀払い処理済みイベント 3000円クレジット払い 間違えた処理により ⼆重⽀払データが作 成されました。 ⽀払いエラー集約 商品3 合計3000円 合計⽀払い 6000円 返⾦処理済みイベント 3000円をユーザーに返⾦ 購⼊済み 発送待ち集約 商品3 合計3000円 ⽀払い済
32. ネッ トシェア 可 • 集約を跨いだ結果整合性は基本的に担保できない。 • Sagaパターンなどで対応する • ⼤規模システムでは、RDB、ステートソーシングで も、読み込みデータと書き込みデータの遅延は発⽣ するため、イベントソーシングのみの問題ではな い。 • リードモデルを構築するのに少しの時間がかかるこ とはあり、詳細ページに⾏けば最新のデータとなる ことはあるが、結果整合性をビジネス上のアーキテ クチャ特性として、設計要件に含めて対応する。 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 32 / 48 ❹ トランザクションとデータの⼀貫性は担保されるのか？ ⑤ クエリ作成に時間がかることによる結果整合性をどう扱うのか？ バックエンドAPIサーバー コマンド イベント データベース イベント イベント イベント フロントエンド API コマンド ハンドラー ライブ プロジェクション ① パーティション毎 ②複数パーティション クエリ API Cosmos DB etc.. イベントが保存されてか ら、クエリに反映される まで時間がかかるが、最 終的には追いつく 結果整合性 ???
33. ネッ トシェア 可 1. 現時点でSekibanで⼤規模な分散システムが必要な規模のアプリは扱っていないが、対応可能な技術 を使っている[Cosmos DB、Dynamo DBなど] 2. 現在はSekibanに各プロジェクトで分散技術を追加する必要がある [マテリアライズドビュー、集約 により対応サーバーを選択することにより集約毎に単サーバーを実現するシャーディング、Kafkaに よるイベント駆動プラットフォームなど] 3. Sekibanで簡単に⼩規模イベントソーシングを開始できる延⻑でプラグインを登録していくだけで分 散システムに対応できる追加機能を作っていく予定 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 33 / 48 ❺ 分散システムへの対策はできているのか？
34. ネッ トシェア 可 “イベントソーシングは、基本的に異なるモデリングパラダイムです。 2003年当時の技術（例：ORMや 単⼀のリレーショナルデータベース）はイベントソーシングの採⽤を困難にしました。近年のNoSQLや 分散システムに対応したフレームワークの進化により、この課題は緩和されています。関数型プログラ ミングの不変性や宣⾔的構造は、イベントソーシングと相性が良く、コードの明確性を⾼めます。” 2016 - Eric Evans Domain-Driven Design Europe 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 34 / 48 ❻ イベントソーシングは難しいと感じるのですが、⼤丈夫なのか？ ① Eric Evans の⾔葉 - 2016年 2008年にもGreg Youngとイベントソーシングについて話しているが その８年後でも『異なるパラダイム』と表現している。 イベントソーシングはシンプルなコンセプトだが、どのようにイベン トを扱い、組み⽴て、システムとして組み上げる⼿法は、『異なるパ ラダイム』であると理解して取り組む必要のある新しい考え⽅である と⾔える
35. ネッ トシェア 可 • コストはどうですか？→それほどはかからないはず... → これくら いのシステムでいくらでした • スピードはどうですか？→対策⽅法はあるはずです... → このシス テムでは平均XXXmsでした • 学習コストはどうですか？→なんとかなるはずです... 上記のように、不確定な点が確かに多い。ただ、理論的に正しい点が 多いので、実践し、経験することで実データとして説明可能になる が、最初⾶び込まないと、最初のデータを観測できない。Sekibanは 幾つか作って説明のための情報が揃ってきました。 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 35 / 48 ❻ イベントソーシングは難しいと感じるのですが、⼤丈夫なのか？ ② 導⼊前に不確定である点が多いです。。。
36. ネッ トシェア 可 • イベントモデリングを提唱しているAdam Dymirtukは、イベン トソーシングのプログラミングにLLM - Cursorを活⽤している。 • LLMの特性、⾔語処理⼒、ストーリーの理解⼒が⾼いという特 性と、集約のストーリーをイベントの追記によって作っていく というイベントソーシングの特性が合っていると語っている。 • 実際、イベントのリストを⾒せた上でコーディングすることに より、精度が⾼くイベントソーシングのコードを⽣成できてい る。 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 36 / 48 ❻ イベントソーシングは難しいと感じるのですが、⼤丈夫なのか？ ③ LLM時代にイベントソーシングが必要ですか？
37. ネッ トシェア 可 3. イベントソーシング‧CQRSでよく聞かれる疑問と、現在のわたしたちの答え 37 / 48 第３部まとめ いろいろ疑問があり、実装⽅法も複雑な部分があるが、イベントの追記を真実と して保存するイベントソーシングは、将来的にもデータを活⽤できるシステムを 作る上で、⾮常に役に⽴つ技術であり、ジェイテックではSekibanを使って２年 半運⽤した上で、これからの新規のプロジェクトでもイベントソーシングを使っ ていきたいと考えています。
38. ネッ トシェア 可 4. イベントソーシング導⼊ガイド 38 / 48
39. ネッ トシェア 可 4. イベントソーシング導⼊ガイド 39 / 48 • ❶ シンプルな実装で理解してから取り組む場合 • ❷ Sekibanなどのフレームワークを採⽤する場合
40. ネッ トシェア 可 4. イベントソーシング導⼊ガイド ❶ シンプルな実装で理解してから取り 組む場合 理論はシンプルなので、オープンソース実装などを参考に、⾃前でフレームワークを作っていく⽅ 法を、Greg Young は推奨している。 実際書いてみると、コアのパーツは少ない。 • イベント • 集約 • プロジェクター • リポジトリ • コマンドエクゼキューター • コマンド これらのシンプルなコードだけだったら、理解しやすいので、動かしながら試して機能追加してい けるかも。。。 40 / 48
41. ネッ トシェア 可 4. イベントソーシング導⼊ガイド ❶ シンプルな実装で理解してから取り 組む場合 C#でライブラリ400⾏、ドメイン100⾏、 実際にコンソールやWebAPIも実装した超シ ンプルなイベントソーシングを作りまし た。 データはインメモリ、スナップショットや キャッシュもないシンプルなものですが、 イベントソーシングの理解を深められま す。 これをみて⾃前実装していくのがおすす め！ 41 / 48
42. ネッ トシェア 可 4. イベントソーシング導⼊ガイド ❶ シンプルな実装で理解してから取り 組む場合 Rust版も作りました！！ メモリ処理に苦しみましたが、 traitの機能が豊富で、コンパイル が通れば実⾏ができるのを体験で きました。 42 / 48
43. ネッ トシェア 可 4. イベントソーシング導⼊ガイド ❶ シンプルな実装で理解してから取り 組む場合 Go版も作りました！！ 冗⻑なところがあるものの、ルー ルに従って書けばEasyにかけるの でサクサク作れます！ 43 / 48
44. ネッ トシェア 可 4. イベントソーシング導⼊ガイド ❶ シンプルな実装で理解してから取り 組む場合 TypeScript版も作りまし た！！ 型の合成も駆使して、構造的型付 け（Structural Typing）のパワー で、綺麗なプログラムを書くこと ができました。 44 / 48
45. ネッ トシェア 可 4. イベントソーシング導⼊ガイド ❷ Sekibanなどのフレームワークを採⽤する場合 ① 有名フレームワーク紹介 フレームワーク毎に、対応⾔語、ビジネスモデルが違うのでリサーチが必要。 フレームワークの使⽤により、書き⽅のルールが定まっていたり、クラウドサービスの利 ⽤が可能であったり、⼤規模環境へのスケールが容易に⾏えたりの利点を享受できる。 45 / 48 wolkenkit Wolverine
46. ネッ トシェア 可 4. イベントソーシング導⼊ガイド ❷ Sekibanなどのフレームワークを採⽤する場合 ② Sekibanのご紹介 • 2023年12⽉にオープンソースリリース, 中⼩規模システムに特 化したフレームワーク ◦ 全ての機能をApache 2.0 で使⽤可能！ ◦ すぐにドメイン開発を開始できる。 • C# .NET 8 & .NET 9 に対応 ◦ C#また、F#で利⽤可能 • 対応データベース ◦ Azure Cosmos DB ◦ AWS Dynamo DB ◦ Postgres • 関数型インターフェース ◦ 鉄道指向プログラミング ResultBox対応 ◦ コマンド、イベント、集約をシンプルに表現！ • 関数型に振り切った最新バージョン開発中 46 / 48 残念ながらタンブラー はないですが、Starお 願いします 󰢛
47. ネッ トシェア 可 5. まとめ 47 / 48
48. ネッ トシェア 可 まとめ 48 / 48 • イベントソーシングの概念はシンプルだが、 『新しいパラダイム』なので、理解が求めら れる • Eric Evansが認めているように新しい視点で 「何が起きているか」に焦点を当てたもの で、特定のドメインに⾮常に有効です。 • 柔軟にリードモデルを複数個作成できるとい う特性により、『関⼼の分離』が促進され、 柔軟にシステムを構築できます。 • 便利なツールの⼀つとして皆様のツールボッ クスに⼊れてみてはいかがでしょうか？ • Sekibanは中⼩規模のシステムにおいて簡単か つ効率的にイベントソーシングを導⼊するフ レームワークです。会場で声をかけてくださ い。
49. Thank You 49 株式会社ジェイテックジャパン https://www.jtechs.com/japan/ Sekiban - イベントソーシング‧CQRSフレームワーク https://github.com/j-tech-japan/sekiban Zenn - ジェイテックジャパンブログ https://zenn.dev/p/jtechjapan_pub