【ITニュース解説】Introducing a Hybrid Event Sourcing Framework for Modern Applications

システム開発において、アプリケーションの状態管理は非常に重要な要素だ。近年注目を集めている「イベントソーシング」は、システムの状態が変化した結果だけを保存するのではなく、「何が起きたか」という出来事（イベント）の記録をすべて時系列に保存していくアプローチだ。例えば、ユーザーが作成された、商品が購入された、といった具体的な出来事を記録していくことで、システムの現在の状態を、これらのイベントを最初から順にたどることでいつでも再現できる。この手法は、いつ、誰が、何を、どのように変更したかという完全な履歴（監査証跡）を残せるため、後から特定の時点の状態を調べたり、過去のデータに基づいて時間的な分析を行ったりするのに非常に有効で、堅牢なシステム構築に貢献すると期待されている。

しかし、イベントソーシングを純粋な形で導入しようとすると、実際のシステム開発においてはいくつかの複雑な課題に直面することが知られている。

一つは、複数の操作が同時に行われた際に発生する「競合状態」の解決の難しさだ。例えば、二人のユーザーが同じ商品の情報を同時に更新しようとした場合、どちらの更新を優先し、どのように矛盾を解決するかという問題が起こる。純粋なイベントソーシングでは、データの更新時に他の変更が介入していないかを確認する「楽観的ロック」という仕組みを導入することが多い。これは、更新を行う前にデータのバージョンを確認し、もしその間にデータが変更されていれば更新を拒否して再試行を促す、というものだ。しかし、この競合解決のロジックを正確に実装し、さらに失敗した場合の再試行の仕組みや、ユーザーへの適切な通知まで考慮に入れると、システムは非常に複雑になり、開発チームにはかなりの工数と専門的な知識が求められる。表面的なシンプルさとは異なり、あらゆるケースに対応できる堅牢な解決策を構築するには多大な労力が必要となる。

もう一つの課題は、データ参照のための「リードモデル」のパフォーマンスと運用上の複雑性だ。イベントソーシングでは、イベントの履歴から現在の状態や、特定の用途に合わせた集計データ（リードモデル）を再構築して、ユーザーが参照できるようにする。例えば、あるユーザーのすべての注文履歴を表示するには、そのユーザーに関連する過去のすべての「注文イベント」を読み込み、それらを集計し直す必要がある。イベントの数が膨大になると、この再構築には時間がかかり、システム全体の応答速度に影響を及ぼす可能性がある。また、システムで必要となる多様なデータ表示（例えば、ユーザーの個人情報、注文履歴、現在有効なユーザーリストなど）に対応するためには、それぞれの用途に合わせた複数のリードモデルを作成し、それらを常にイベントの変更に合わせて最新の状態に保つ必要がある。イベントのデータ構造が変更された場合（スキーマの進化）、それに依存するすべてのリードモデルの再構築ロジックも修正し、データを移行しなければならない。さらに、リードモデルはイベントから遅れて更新される特性を持つため、「結果整合性」という状態になる。これは、データが更新されても、リードモデルにはすぐには反映されず、一時的に古い情報が表示される可能性があるということだ。これにより、ユーザーが「今更新したはずなのに、まだ画面に反映されていない」と感じるような、ユーザー体験上の問題を引き起こすこともある。これらの運用上の負担は、多くの開発チームが見積もりを誤りがちだ。

これらの課題は、イベントソーシングそのものに内在する欠陥というよりは、複数のシステムが連携して動作する「分散システム」全般に共通する複雑な側面であり、純粋なイベントソーシングが自動的に解決してくれるわけではない。イベントソーシングの理論的な利点は非常に魅力的だが、実際のシステム実装における複雑さが、多くの利用ケースでそのメリットを上回ってしまう場合も少なくない。

そこで、これらの課題を解決するために提案されているのが、イベントと「現在の状態データ」の保存を組み合わせた「ハイブリッドイベントソーシング」というアプローチだ。この手法は、イベントによる完全な監査証跡を保持しつつ、現在の状態データを直接利用することで競合解決を簡素化し、基本的なデータ参照をより直接的に行うことを可能にする。これにより、イベントソーシングの恩恵を享受しながらも、運用上のシンプルさを維持できる。

このハイブリッドアプローチの核となる考え方はいくつかある。まず、システム内で発生するあらゆるアクション（例：ユーザーの作成、ステータスの変更、支払いのリクエストなど）に対して、必ずイベントを生成する。これらのイベントは、イベントソーシングでいう「アグリゲート」のように、特定の「モデル」（データのかたまり）に属していると見なされる。次に重要なのは、「トランザクション整合性」の確保だ。イベントの生成と、それに対応するモデルの現在の状態データの更新は、必ず単一のトランザクションとして処理される。これにより、イベントと現在の状態データの間で矛盾が生じることを防ぎ、システムの状態が常に一貫していることを保証する。さらに、モデルの構造を、それぞれ独立して更新できる複数の「部分」に分けることができる。例えば、ある商品の「説明」と「価格」は、それぞれ独立した部分として扱われ、それぞれが独自のバージョン情報を持つ。この設計により、ある管理者が商品の説明を更新している間に、別の管理者が価格を更新しても、お互いの変更が競合しない「偽の競合」を排除し、システムの並行処理能力を高めることができる。

イベントは、モデルID、アクションの種類、バージョン番号を組み合わせた「複合識別子」によって一意に管理される。例えば、MongoDBのようなデータベースには、イベントの種類を示す「topic」、ビジネスロジックに関する実際のデータである「body」、そしてイベントの一意のID、対象モデルのID、バージョン、作成日時といった「メタデータ」を含む形で記録される。

イベントの保存と処理のアーキテクチャとしては、まず、それぞれの「ドメイン」（特定の業務領域）や「サービス」が、自身に関連するイベントを専用のデータベースに保持する。すべてのイベントタイプは一つの共通のコレクションやテーブルに保存され、現在の状態データも別に保存される。生成されたイベントは、他のシステムが利用できるよう、「メッセージブローカー」と呼ばれる仕組みを通じて非同期に配信される。これにより、イベントを生成したサービスとイベントを利用するサービスが直接依存することなく、緩やかに連携できる。また、イベントのデータ構造が変更された場合でも柔軟に対応できるよう、複数のイベントバージョンを扱える機能も提供される。システム内部では、バックグラウンドで動作する専用のプロセスが常に未処理のイベントを監視し、適切なメッセージブローカーへ送信したり、エラーが発生した際には再試行を管理したりする役割を担う。

具体的な例として、「ユーザーサービス」と「ペイアウトサービス」の連携が挙げられる。ユーザーサービスは、ユーザーの作成、更新などの操作を担い、そのたびにイベントを生成する。このイベント生成のプロセスは、まず入力された「コマンド」（命令）を検証し、次に必要なデータを含んだイベントを作成する。そして、「イベントオーケストレーター」と呼ばれる仕組みを利用して、イベントの永続化と、それに対応するモデルの作成または更新を単一のトランザクションで実行する。開発者は、適切なイベントを構築し、モデルへのマッピングを定義するだけで、イベントの保存、処理、他のサービスへの通知といった複雑なインフラストラクチャの詳細はフレームワークが自動的に処理してくれるため、ビジネスロジックの記述に集中できる。イベントには、「モデルの種類.サブジェクト.アクション.データ転送オブジェクト（DTO）バージョン」という形式の「トピック」が割り当てられ、例えば「user.model.created.v1」（ユーザーモデルが作成された、バージョン1）のように、イベントの内容とバージョンが明確に示される。また、「イベントマッピング」の仕組みにより、システム内部で使用するイベントのデータ構造と、外部に公開するイベントのデータ構造を分離できる。これにより、内部の変更が直接外部に影響せず、他のサービスが新しいイベントバージョンに段階的に移行することも可能になる。

更新処理に関しては、データが重要で競合検出が必要な場合（例えば、ユーザーの個人情報更新）には「バージョン管理あり」で更新を行う。この場合、クライアントは更新対象データの現在のバージョン番号をリクエストに含める必要があり、システムに保存されているバージョンと一致しない場合は競合として処理が拒否される。一方、独立した更新（例えば、ユーザーのステータス変更）のように、競合が許容される場合は「バージョン管理なし」で更新を行うことも可能だ。この柔軟なアプローチにより、ビジネス要件に合わせた適切な競合解決戦略を選択できる。

イベントを消費する側のサービス（例えばペイアウトサービス）は、ユーザーサービスが提供するイベントクライアントのライブラリをプロジェクトに追加し、受け取りたいイベントのタイプに対応するメソッドを専用のアノテーションを付けて定義するだけでよい。これにより、イベントが発生すると、定義されたメソッドが自動的に呼び出され、ビジネスロジックを実行できる。この際、イベントを転送する具体的な技術（Kafka、RabbitMQ、SQSなど）はフレームワークが抽象化するため、イベントを消費するサービス側はこれらの詳細を意識することなく、ビジネスロジックの実装に集中できる。

このハイブリッドイベントソーシングのアプローチは、筆者が携わった実際の運用システムで高い有効性が実証されている。純粋なイベントソーシングが抱える運用上の複雑さを軽減しつつ、完全な監査証跡やイベント駆動によるシステム連携という重要なメリットを享受できる。ビジネスの要求に合致した柔軟な競合解決や、開発者がインフラの複雑さに煩わされることなくビジネスロジックに集中できる環境を提供することで、開発生産性の向上にも貢献する。イベントソーシングの導入を検討している開発チームにとって、運用管理の負担を抑えながらそのメリットを最大限に引き出すための、非常に魅力的な選択肢となるだろう。