株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。
2024年12月21日に行われた、CQRS+ESカンファレンスに参加し、登壇の機会もいただき、無事登壇することができました。以下は登壇スライドです。
開催までの経緯に関して
CQRS+ESカンファレンスの経緯に関しては、ytakeさんの上記のブログにある通り、ytakeさん、nrsさん、かとじゅんさんが2024年3月のObject Oriented Conference 2024の懇親会で話して計画をしてくださり、10月に場所と日程が発表されました。
僕には会場と場所が決定した時点で、現時点で日本語でイベントソーシングに関していろいろ登壇やオープンソースを行なっていることを見てくださっていて、登壇者の一人として招待していただきました。（頑張って活動してきたとてもよかったです！）僕が米国カリフォルニア州ロサンゼルス近郊に住んでいるため、最初はなんとかオンラインからの登壇でも良いので参加させていただきたいという話にしていたのですが、なんとか東京出張にタイミングを合わせることができるようになり、２泊５日の弾丸旅行でLAから参加することができました。
カンファレンスの内容に関して
カンファレンスのConpassとTogetterで雰囲気が見てとれますが、技術に特化したイベントですごく盛り上がりました。
以下で全体の話の流れをまとめます。
ytakeさんによるカンファレンス オープニング
海外、特にヨーロッパでは普通に使われ始めている、イベントソーシングとCQRSですが、カンファレンスでもその傾向が現れています。ytakeさんの参加した、Event Sourcing Live 2021やDDD Europeでも、イベントソーシングに特化したイベントも多くありますし、通常のDDD Europeでもイベントソーシングに関する言及が多く、かなり一般的になっていることが伺い知れます。ytakeさんとして、そのようなヨーロッパの進んだ技術カンファレンスをライバルとして、そのような技術に特化したイベントを設けたいということで、今回のCQRS+ESイベントを計画してくださったとのことです。
ytakeさんによる『ドメインイベントで描く未来: CQRS/ESが変えるシステムとDXの可能性』
このセッションでは、ytakeさんが前半で、イベントソーシングの基本について扱ってくださったのがとてもよかったです。僕のセッションを含め、『イベントソーシングとは、その基本原理とは』という話が含まれていなかっため、イベントソーシングに関しての理解をリフレッシュする必要のある視聴者の皆様にはとても助かる内容でした。
イベントソーシングの基本が、イベントを Single Source of Truth にする、つまり、事実の状態を常に変更して保存するのではなく、状態を変更するために起きたイベントとして保存して、状態を取得するときもイベントストアのイベントリストを取り出して、そのイベントの羅列から状態を計算する第一のソースとするということについてわかりやすく説明してくださいました。
ytakeさんのブログを参照ください。
後半ではアクターモデルの基本と、アクターモデルがどのようにイベントソーシングと相性が良いかを説明してくださいました。
tomohisaによる『２年間の実運用を経て振り返るイベントソーシングの実際』
(NEW) 今回はオフラインイベントでしたが、当日の午前中に練習したビデオをYoutubeに公開しました。練習ですので、表現を考えてゆっくりになっているところもありますが、ご了承ください。
僕の話のポイントをいくつか挙げると以下のものになります。
-
ライブプロジェクションを使っている
ライブプロジェションは、メモリ内でプロジェクションを行い、そのデータからクエリを生成する手法で、小中規模でイベントソーシングを行う際に有用な手法です。
-
一貫性など解決すべき点があり、その解決をSekibanは、Actorシステムに頼らずに行なっている
アクターシステムで備わっているスレッドの管理などの問題管理に関しては、Sekibanではコード実行時のスレッド管理で行なっています。一貫性を担保するために、サーバー側での実行を第一の優先度としていて、データベースはデータが確定後に保存するために使用していないので、データベースは比較的に簡単に差し替えることができます。 -
Sekibanが使っているCosmos DBにはServerlessモードがあり、安い
社内の経費精算システムはCosmosDBに100円未満の費用で本番運用している。顧客向けシステムもかなり安くできている。 -
分散システムの対応はSekibanビルドインではまだだが、対応は可能
これから頑張って作っていきたいと思います。 -
イベントソーシングは『新しいパラダイム』by Eric Evans
パラダイムが変わるということは、前の常識が使えなくなるので、その新しい考え方で、新たな思考パターンを構築していかないといけない。ytakeさんやかとじゅんさんの話でも、地動説と天動説のような異なる視点で、１方の視点からは他方がわからないということが触れられていましたね。 -
全ての予測ができないため、飛び込む必要がある
ファーストペンギンが必要。でも、Sekibanは実運用２年、５プロジェクトほどあり、費用の説明ができるようになってきました。 -
LLM+イベントは相性がいい。
イベントはストーリーだから、コンテキストをLLM、ビジネスオーナー、プログラマにとって理解しやすい。
皆様からもいくつか質問が上がっているので、また返答できればしたいと思います。
-
SuperSimpleEventSourcingを作りました
イベントソーシングのコンセプトを理解するために、500行くらいでシンプルな実装を作りました。インメモリストアのものですが、これを拡張してインメモリの代わりにDBにイベントを読み書きするようにすれば、足がかりとしての実装にすることができます。
C#ではおそらくみなさん見てくれないとおもったので
- C#
- Rust
- Go
- Typescript
の４言語で作成しました。
TypeScript 人気あるんだな... 作った中ではC#、とてもいい実装だったんだけどな。。。
あと、SekibanをよかったらStarしてください！！！言語違ってもかなり参考になるコードだと思います。
nrsさんによる『いろんな機能をCQRS+ESで作ってみたので皆で所感を見てみよう』
成瀬さんの登壇は、Axonフレームワークを使用したら具体的にこんなシステムもこんなコードで簡単に実装出来ますよというコード紹介のセッションでした。
Axon フレームワークはイベントソーシングフレームワークの中でもAkkaに並び世界的には多く用いられている大きなものの一つです。
すでに多くの機能があるフレームワークを使うと、機能にフォーカスしてシンプルに作成することができることを成瀬さんがわかりやすく説明してくださりました。
マスター系や注文処理、支払い処理などのプロセス処理と色々なパターンのコードが紹介される中、質問の中に、個人情報削除を依頼されたときにどうするのかという話があり、それに関してすぐに図を手書きで書いて説明してくださっていたのが印象的でした。
GDPR対応の個人情報削除の方法で、キーバリューストアを持つ方式に関しては『ドメイン駆動設計を始めよう、７章』の中にもわかりやすく説明されていますのでご覧ください。
普通は一般的なイベントソーシング実践方法の1つ、フレームワーク依存で楽に実践するが、この話（とあとSekibanも少しそう）が一番フォーカスしていたので、難しいこと考えなくてもできるのですよということが皆様にも理解していただけてよかったのではないかと考えています。
期せずして、内容的に良い流れになっていました。
最後の部分で、イベントストーミングの画像から、『Axonで実装して』とChatGPTに尋ねることによって、ババババとどんどんChatGPTがプログラムを作成していく様子が見れて、もちろん間違えはあるので調整はしていかないといけないのですが、この方式をうまく使っていくと、開発者のアウトプットの速度が劇的に向上するのではないかと思っていますので、Sekibanでもどのようにこの体験を開発者にもたらすことができるかを考えていきたいと持っています。
ス（ズキ）さんによる『ステップバイステップではじめるES、CQRS』
ス（ズキ）さんの話は個人的にとても嬉しいもので、前職でイベントソーシングを使っておられたス（ズキ）さんが、現職に入り、イベントソーシングではないシステムのメンテナンスを行なっている際に、データの流れを追うのがとても難しい、デバッグが難しいというのに気がつき、現職に段階的にイベントソーシングを導入しているというお話でした。
この話はとても貴重と思います。なぜなら僕個人として、今まで2年半くらいイベントソーシングのシステムを作ってきて、とてもこれがいいものと考えているのですが、そこから環境を変えて、ステートソーシングのみのシステムに戻るという経験をしていないので、この経験は、僕でも、なんとかイベントソーシングを導入できないかと試行錯誤するだろうなと思うのですが、まさにその経験が語られていたからです。
これは使った人にしかわからないと思うのですが、イベントソーシングでの開発に慣れてしまうと、適応できる範囲はどんどん大きくなるのと、それによってもたらされる安心感というか、必要なデータがあることやデバッグが容易になることにより、ステートソーシングに戻って開発するのがすごく難しく感じるのではないかと現時点で思っています。その経験を聞くことは個人的にはとて無有意義な経験でした。
かとじゅんさんによる『アクターシステムに頼らずEvent Sourcingする方法について』
かとじゅんさんはAkkaの経験も多いのですが、Akkaが使えない多くの企業さんとも話してサポートをしておられるので、Akkaを使わない実装方式についても研究を重ね、コード例を作っておられます。
AWS方式についても今まで話されておられたため、LTなども含めてAWS方式を採用している実例も多いようですが、それをさらにシンプルに実現した、【KJ方式】を実現しておられます。
最近リリースされた Black Cat Carnival でも採用されている、モダンな実装方法です。
実際のところ、フレームワークではないのかもしれませんが、各言語で利用可能な参照実装が用意されているので、多くの実装を求める企業、開発者にとって、とても有用なものとなっています。CDCを利用することにより、書き込み側の負荷と読み込み側の負荷を分散することが実践されていてとても良いコンセプトと思います。
Sekibanでもこれからマテリアライズドビュー対応を追加していく予定ですので、その点ではにたコンセプトとなっていくと思います。
パネルディスカッション
パネルディスカッションでは、いくつかの質問への答えが話されました。
外部インターフェースはどうしているか？
-
Protocol Buffers や Grpcなどのスキーマ定義を用いる
https://protobuf.dev
どの範囲で定義を公開するかという話にもなっていました。 -
REST というよりコマンドとクエリを Get, Put, Postにマップする方法
OpenAPI (Swagger)でフロントに定義をシェアすることにより、TypeScriptで定義の自動生成なども行なっていることを個人的に話しました。
イベントソーシングの適応範囲は？
登壇者５人は皆ほとんどイベントソーシング脳になってしまっているため、よっぽどのことがない限りイベントソーシングを採用するよねという話になってしまいました。
ここでかとじゅんさんに振られたのは、最近の海外カンファレンスでDDDの枠を超えた取り組みもされ始めていますよねと振られたのですが、さすがかとじゅんさん、僕が海外カンファレンスの登壇ビデオを見ている系のポストも結構していることを覚えておられたのではないかなと思い、パスに答えました。
こちらもDDD EUの動画で、Aggregates Composition: A new view on Aggregates - Jérémie Chassaingというものですが、集約の考え方に関数型を加えた新しい取り組みなども考え始められており、Eric Evansの時代にははっきり定まっていなかった実装形態の色々なパターンが出てきて、イベントソーシング、CQRSは大きな影響を実装に与えていると思います。
イベントソーシングのデータベースに必要な要素は？
ある程度のサイズまでならどんなデータベースでもできるというのが現状です。
サイズが大きくなるに従って、必要な要素は主に2つです。
-
シャーディング（パーティショニング）: Cosmos DBなどのドキュメントデータベースは、データを1つのテーブルに入れていても、パーティションを作ることにより、実際には別のデータベースにデータを入れているかのように動作し、その原理でスケーリングも対応します。ですので、１テーブルにどんどんイベントを入れていくイベントソーシングでも破綻しないデータベースとすることができます。
-
CDCチェンジデータキャプチャ : イベントソーシングで大切な機能である、マテリアライズドビューの構成においてCDCに対応しているか否かは大きな違いとなります。自動的に最新データをKafkaなどのストリームにプッシュすることによって、使用側にリードモデルのデータ構築機能を接続することができるので、データベースのデータ取得を頻繁に行う必要が減り、それにより書き込みのパフォーマンスも維持することができるからです。
上記の要求を考えると、Document DB (Dynamo DB や Cosmos DB)が一番向いたデータベースといえますが、現代のデータベースのパフォーマンスが上がっていることにより、RDBでも実行できる可用性の範囲が拡大しているので、場合によりけりということができます。
LT
一つ一つのLTについては取り上げませんが、それぞれ短いながら興味深く、色々な観点で使ってみての感想や、開発は簡単だけど、現システムからの移行に悩んでいることなど、興味深い点満載でした。
kazu_kichi_67さんのブログに資料も上がっていますのでよろしければ合わせてご覧ください。
今回のカンファレンス以前の繋がりの再確認
今回、僕は個人的に日本でのオフラインのカンファレンスにほとんど参加していませんでした。2024年11月26日にFindy アーキテクチャカンファレンスでブースを持って、登壇した時に初めてオフラインでのイベント登壇、その前に幾つかのイベント、特に大きなものでは吉祥寺.pm36で登壇したのですが、今回嬉しかったのは、それらのイベントで僕のことを知ってくださった方や、オンラインのみXなどでみてくださっていた方に声をかけていただいたことです。
上記のkazu_kichi_67ともお話しすることができて嬉しかったです。
特にFindyのイベントで関心を持ってから、僕のXでのポストも関心を持ってみてくださってSuperSimpleEventSourcingも事前にZennとXで発表していたのですが、そちらもみて、社内でも展開してくださった方もおられ、とても嬉しかったです。
やはり継続的にこのようなコミュニティ活動を続けることによって、自分自身の成長にもなりますし、継続して情報を見てくださる方々と共に、全体のレベル上げにもなっていくのだというのがよくわかりましたので、また引き続きオンラインでの登壇活動なども続けていきたいと思います。
まとめ
懇親会でも少なくとも僕の周りでは、開始後30分ぐらい、食べずに実装の話をしていた中から、食べ始めても、イベントソーシング、CQRSの具体的な実装やコンセプトの話から外れず、いわゆる雑談に話がいかないくらい、がっつり技術の話をしていました。雑談もそれで楽しいのですが、皆にとって技術の話が刺激的で、関心がたくさんある分野のため、それぞれの技術の話をしていたら約２時間半の懇親会が終わってしまったという感じでした。
技術カンファレンスの中でも、さらに技術色の濃い"イベント"だったと感じました。イベントソーシングのイベントが複数のイベントの積み重ねによって深いストーリーや意味を構成していくように、これからも継続的に活動していくことにより、Sekibanやイベントソーシングに関する知見もどんどん継続してストーリーとして深めていきたいと思います。
片付けなど自然とみなさん手伝っている姿もとても良かったです。
また、個人活動では登壇やブログを書いたりを行なっていますし、弊社としてもワークショップ、技術コンサルなどのサービスも展開していますので、いろいろぜひお声がけいただけるとうれしいです！！！
Discussion