EventSourcingの理想と現実

JJUG CCC 2024 Fall用のスライドです！

1. Event Sourcingの 理想と現実 2024 JJUG CCC Fall
2. • 名前：なかやまひろ@せち • 都内のシステム開発会社に勤務 ◦ フリーランスと会社員を行ったりきたり • 最近のお仕事は社内の何でも屋！ ◦ AWSからFEまでやってます ◦ Javaやりたい・・・ • 趣味は自転車乗ったりゲームしたり ◦ スライド作りとかで乗れてないのがつらい • JJUGはオフラインでは初めて • 猫可愛いので覚えて帰って 自己紹介 JJUG Tシャツを バリバリした直後の犯 猫
3. QRコードをスマホ等で読み込むか、気合いで解読してください。入り切らな かったネタとかも書いてあります。 スライドこちら
4. EventSourcingについて・・・ • 知らない！聞いたこともない！今日初めて知った！ • ネットで記事を見たことあるし、概要は知ってるけど使ったことない • めっちゃ使ってますし、何でしたら代わりに20分話しますよ？ 質問です！
5. EventSourcingについて・・・ • 知らない！聞いたこともない！今日初めて知った！ • ネットで記事を見たことあるし、概要は知ってるけど使ったことない • めっちゃ使ってますし、何でしたら代わりに20分話しますよ？ 質問です！
6. このセッションで得られる（といいなぁ・・・）もの • 知らない人 ◦ EventSourcingっていうものがあること • 知ってるけどやったことない人 ◦ 経験しなければわからないところを知っていただければ • 既に導入してる人 ◦ こういうアプローチもある 知らなくても大丈夫です
7. • Event Sourcingとは？ • Event Sourcingを実践してみた話 • まとめ（良かったところとか） EventSoucingのアプリケーションに携わった経験も交えつつ、お話ししていく 予定です。 今日話すこと
8. • EventSoucingについての詳しい解説 ◦ これだけで20分飛んでしまう・・・ • 実装は簡単に紹介しますが、具体的な細かいところまでは踏み込まない です ◦ SpringModulithとEventSoucingで検索すると良さげなサンプルが あります 今日話さないこと
9. Event Sourcingとは？
10. 一言で言うならば「アプリケーションの状態管理とデータ保存のためのアーキ テクチャパターン」で、以下の2つが特徴です。 • システムで発生するEventを記録（状態は記録しない） ◦ 一般的なシステムは状態を記録・更新していく • 保存したイベントを発生順に再生することで「現在の状態」を表現する 実際に設計する際はCQRSと組み合わせることが多いです。（CQRSの説明は 割愛） Event Sourcingとは？
11. 銀行の例で説明してみます。口座開設からの入出金のEventを記録します。 残高（現在の状態）が必要な場合、Eventを最初から再生することで算出でき ます。 Event?再生？どゆこと？
12. どうやってEventの登録と再生を行うのでしょうか。ざっくり書くとこのような形 になります。（各要素の呼び名は色々あります） どう実現するのか？
13. 一般的にこういうところがメリットと言われています。 • 関心ごとが別れているため、ソースコードの複雑さが軽減する ◦ アーキテクチャの複雑さでなんとかする • 発生したEventを全て記録することで、データロス発生を防ぐ • Eventが監査にも利用できるログやデータ更新の履歴管理として利用で きる（副次的な効果） もちろん欠点もありますが、それは後ほど。 で、Event Sourcingは何を解決したいの？
14. Event Sourcingを構成する要素を、以下の５つに定義します。 • Command：Eventを登録する更新用API • Query：現在のデータを参照するAPI • EventListner：Eventを再生して現在のデータを作り出す処理。キューを 用いて非同期で実行することもある。 • EventStore：Eventを登録するデータベース • ViewModel：Eventを再生して作成した参照用データベース ※色々呼び名はあります 本資料における用語の定義（参考）
15. Event Sourcingを実践してみた話
16. 一番最初にEvent Sourcingと出会ったのは2018年くらい。レガシーの金融シ ステムをクラウドにリプレイスするにあたり、全体的なアーキテクチャや設計方 針を検討中の時でした。 その当時流行っていたマイクロサービスでの構築を検討していたものの、デー タの整合性をどうやって担保するかで悩んでいました。 そんなときにEvent Sourcingと出会い、一縷の希望を感じたものPoCの実践 までで断念しました。 Event Sourcingとの出会い（自分語り）
17. 昔のことなのでうろ覚えですが、こんなことを感じました。 • 上手く作ればハマりそうな気がする • でも難易度が高すぎるのでは？ ◦ そこそこ大きなプロジェクトなのでメンバーが多く、全員にEvent Sourcingを習得させるのは困難 ◦ 設計失敗したら取り返しがつかないのでは？ • イレギュラーなケース出てきたとき対応し切れるのか・・・ ◦ 将来発生するであろう未知の要件への不安 Event Sourcingを諦めた理由
18. 現在の会社に入社し、担当になったのがEvent Sourcingで構築されたサー ビス。 個人的な感想としては「マジか！あの難しそうなもので作り切ったのか！スゴ イ！」 今回はこのサービスをベースにお話しします。 Event Sourcingとの再会
19. アプリケーションは売り手と買い手の間を取り次ぐ業務システム。 1. 買い手は欲しい商品を検索 2. 商品が見つかったら売り手が見積（条件のすり合わせ） 3. 条件に合意したら発注 条件のすり合わせ中に発生する差分、過去に販売した金額確認で履歴が重 要という声がユーザーから上がっていた。 履歴が重要・・・Event Sourcingやってみよう！ サービスの簡単な説明
20. アーキテクチャは前に紹介した構図とほぼ同じ。ただ、Event Listnerは Commandから起動し、同一トランザクションで処理を実施する。（１トランザク ションでEventとViewModelの両方を作成） アーキテクチャ
21. EventListenerはCommandから実行しています。とは言え、直接呼ぶわけ ではなく、Eventの型に応じたクラスのListnerが動く仕組みになっています。 今だとSpring Modulith使うとフレームワークで解決できますね。 Eventの再生はQueueを用いて非同期で行うこともありますが、同期で実行し ています。 ではEventとは一体なんなのでしょうか？ アーキテクチャ補足
22. Eventはシステムで発生した出来事で、Javaの場合はRecordで実装するの がおすすめです。ドメインに関する属性とEventとして取り扱うための属性から 構成されます。 Eventはデータクラス 例えばユーザー作成Eventであれば、メールア ドレスやユーザー名といった属性が含まれます。 1つのユースケースに対して1個のEventができ る。簡単ですね。
23. 特別な処理をしているわけではなく、普通のビジネスロジックを実行していま す。 個人的には同じイベントを複数回再生されても大丈夫なように作るのを推奨し ます。 Event再生ってなにするの？
24. 大きいイベントは分割して持つ場合があります。例として、注文は複数明細を 持つため、各明細は別Eventとして扱います。テーブル設計に近いと思いま す。Listenerの設計も大変・・・。 Eventが複雑になると・・・
25. 設計の進め方は色々あると思いますが、モデリングやデータの設計をした後、 何をイベントにするのかを決めるのが良いと思います。 ん？設計する量が増えてるように見える？ キノセイデスヨ、タブン・・・。 では、EventSourcingで何を得られるのか？ どの時点でここらへんを設計するの？
26. Event Sourcingの恩恵は受けれたと思います。 • CommandとQueryの構成による関心ごとの分離 • 参照データに変更が必要な場合、EventListenerとViewmodelを追加 するというアプローチが取れる ◦ REST APIにおけるV2が作りやすい ◦ 変更しやすいことで、Query周りの設計のコスト削減ができる ▪ テーブル含めたリファクタリングがやりやすい この構成で解決できたこと
27. Eventを再生する処理とその先の参照テーブルを新しく作成して切り替えま す。EventSourcingではなくても可能ですが、比較的楽にできるのが強みだと 思います。 テーブルのリファクタリングについて補足
28. もちろん、いいことだらけではないです。 • Event Sourcingの課題である設計の難しさ ◦ 普通にCRUD作るより難しい ◦ 開発のコストがかかる • システム全体の正しさの担保が難しい ◦ 特に1つのユースケースでイベントが複数発生する場合 ◦ よくわからないけど動いてる、コワイ！なところはたまにある • オーバーエンジニアリング感 一方で課題も・・・
29. 悩みを • Command実行時に現在の状態を参照したいときどうするか ◦ EventStore参照はコストが辛い ◦ ViewModel見るのは依存関係的に辛い • Listenerでエラーが発生したらどうするか？ ◦ 今回は全部ロールバックできるが、非同期とかにしていた場合は・・・ 設計時にも悩み・・・
30. EventSourcingの理想は素晴らしいと思う反面、現実的にはある程度の抜け 道が欲しいケースはしばしばあります。 「ちょっとデータ登録失敗したから裏でSQL流して直してくれない？」みたいな ケースは対応し辛いです。 EventSourcingのルールに従うのであれば、補正Eventを登録するというア プローチになります。 理想はわかるけど・・・！ システムは改ざんしたい
31. あくまで母数1の感想です！ 今の課題というよりは将来への投資という印象。重すぎるアプローチで、開発 生産性は犠牲になってる気がする。もちろん、EventSourcingを軽量で上手く 回しているところもあると思うが・・・。 難易度は高いためコードを理解するのに時間がかかる。多分、プロジェクトに 参加してからパフォーマンスを発揮できるまでは厳しい。 でも助けられたところも多くある。 EventSoucingを実際にやってみた感想
32. まとめ
33. EventSourcingが出た当時に比べれば資料もライブラリも増えてきました。 Javaで実装する場合も、Spring Modulithを利用すればいい感じに実装でき ると思います。 AIに尋ねれば色々教えてくれます。スライド作成時、Claudeさんに色々質問し ましたがいい感じに答えてくれます。 情報は十分にあるため、始めるにあたって情報不足で詰まることはないと思い ます。 Event Sourcingは難しい、けど楽しい
34. プロジェクトの技術選定する立場でEventSoucingを採用するかを問われた ら、この辺りを考慮したらいいと思います。 • 自分たちが作ろうとするアプリケーションとマッチするか • チームに技術力と学習する時間は確保できているか • 工数はちゃんと合意できてるか • 運用面で発生する課題に立ち向かう覚悟はあるか 技術選定するにあたって多角的な視点を身につけられたのはプラス。（昔だっ たら飛びついてたかも・・・！） とは言え、気軽に始められない
35. エンジニア人生の中で、Event Sourcingに携わることは少ないかもしれない です。 ただ、エンジニアとして使える武器として持っておくことは損はないです。Event Sourcingを導入せずとも、思想やアプローチが問題解決の役にたつケースは あるはず。 １エンジニアとしてはとても楽しかったですし、大きな学びを得られたと思いま す。 最後に
36. ご清聴ありがとうございました！
37. • Eventを再生する処理がViewModelにある未来のデータを参照してしま い、再構築ができなくなったケース • Event自体を変更・無かったことにしたい場合 ◦ 金融で検討したときあったケース • 今のアプリケーションでは発生しないが、大量のデータを処理するバッチ 系の処理 ◦ これも金融系 ◦ 例えば給料日の反映処理 入り切らなかったネタ
38. • 監査ログとか履歴は副次的な効果なので、それ目的に導入するのは ちょっと違うと思う ◦ 別にEventSourcingじゃなくてもできるよねー • 途中から入れるのは辛いけど、スモールスタートに向かないのが厳しいと ころ • 全部イベントにするのが理想だけど、多分現実的には厳しいよねー。 入り切らなかったネタ