イベントアーキテクチャを選択する

分散システムの設計において、おそらくはマイクロサービスに基づいたイベントアーキテクチャを検討する場合、利用可能なモデルとテクノロジはいくつかある。アーキテクチャの実装方法を選択する時、そのおもな要因は非機能要件である - さまざまなイベントアーキテクチャのスタイルを説明した先日のブログ記事で、David Dawson氏はこのように主張している。

フリーランスのシステムアーキテクトであるDawson氏は、イベントアーキテクチャとは単にイベントをベースとしたソフトウェアアーキテクチャであり、イベントがデータモデルの一部であることから、同時にデータアーキテクチャでもある、と定義する。テクノロジのセットや、あるいはサービスの対話方法に関する特定のモデルを指すものではないのだ。

シンプルで確立されたモデルのひとつがSEDA(Staged Event-Driven Architecture)である。これは基本的には、処理結果としてイベントを発生するコンポーネントによるワークプロセスであり、イベントがプロセス全体を駆動する。イベントは通常、何らかの形式のメッセージバスを使用して転送される。このモデルにおいて大きな問題は、イベントが短命であるため、転送中やコンポーネントがオフラインの場合に失われる可能性があることだ、とDawson氏は指摘する。従って結果整合性(eventual consistency)を取り入れたシステムではなく、氏の言う希望的一貫性(hopeful consistency)が実現することになるのだ。すべてが正常に動作していれば、システムには一貫性がある。しかし問題が発生した場合には、システムの一貫性は失われ、復元のために手作業による回復操作が必要になる。氏はこれをエンティティ指向マイクロサービスと呼び、このスタイルのアーキテクチャを避けるように強くアドバイスしている。

整合性を再構築可能にするためのDawson氏のベストソリューションは、イベントはデータであることを認識し、イベントストリームを永続化することだ。これにより、任意のタイミングでストリームを再生して状態を復元することが可能になり、結果として真の結果整合性を備えたシステムが実現する。その他に、同じイベントストリームに対する複数のビューが可能になる、といったメリットもある。

永続性を備えたイベントストリームは、Dawson氏の経験では、しばしばイベントソーシングと呼ばれている。しかしこれは正しくない、単一のエンティティを再作成するのではなく、無制限のエンティティセットのビューを生成するものであるからだ、と氏は考えている。そのため氏は、このスタイルをストリームプロセッシングと呼んでいる。氏によれば、これはKafkaに極めて適したアーキテクチャである。Kafkaのクライアントはストリームから順番にイベントを読み込むが、必要ならば再度先頭から、あるいは特定のイベントから読み込むことも可能だからだ。

集約(aggregate)は、一貫性を持つバウンダリ内部のエンティティセットを指すDDDの用語である。集約で発行されたすべてのイベントを永続化し、そのイベントを再生して集約の同じ状態を構築することにより、イベントをソースとする集約のルーツを得ることができる。これが本来のイベントソーシングと氏の定義するものだ。集約を再構築するには、分離されたユニークなイベントストリームを備えることが重要だ、と氏は指摘する。ビューの構築など他のニーズに対しては、別のストリームを用意する必要がある。

イベントアーキテクチャモデルに基づいたシステムを構築するために、Dawson氏は、メッセージおよびイベント指向の分散システムを構築するためのライブラリとサービスのセットであるMuon Stackを開発した。これにはイベントストリームAPIのクライアントとイベントストアのPhoton　が含まれており、現在はKafkaへの移植作業中である。