イベントアーキテクチャとイベントストリーミング

モノリシック・システムから分散あるいはマイクロサービス・システムに移行すると、たいてい、1つのデータベースにある信頼できる唯一の情報源から、複数のデータベース、すなわち信頼できる複数の情報源へと移行することになる。イベントアーキテクチャを使って、全てのイベントをストリームとして永続化することで、信頼できる唯一の情報源へと戻ることができる。イベントとKafkaの使用に関する一連のブログ記事の中で、Ben Stopford氏はそう主張する。

ConfluentのエンジニアであるStopford氏は、従来のメッセージングシステムでは、イベントは一時的なものであり、すでに消費されたイベントの履歴は存在しない、と指摘する。全てのイベントを永続化することは、信頼できる唯一の情報源を生み出すだけでなく、データを別にしたバージョン管理システムのように、イベントを巻き戻して再生することを可能にする。また、壊れたシステムを復元して、バグ修正後にイベントを再生することも可能になる。

典型的なイベントベースのシステムは、イベントを待ち受け、データベースにある状態を更新・保持し、新しいイベントを送出する。Stopford氏にとって、これには2つの課題があるという。1つは、データベースとイベントログの両方に書き込む際の一貫性を保つことだ。もう1つは、データベースにあるデータとイベントが、、例えば異なるコードパスのために、ずれ始めるおそれがあることだ。これはシステムの不整合という問題を引き起こす。それを解決する最善策は、イベントソーシングシステムのように、イベントを第１級エンティティにして、イベントだけを使うことだ。

イベントストリームを始める1つの方法は、Change Data Capture (CDC) を使うことだ。このテクニックは多くのデータベースで使えるようになってきている。CDCを使ってデータベースに書き込むと、書き込みはバックグラウンドでイベントストリームに変換される。Stopford氏が言及した利点の1つは、整合ポイントを与えてくれることだ。データベースに対して読み書きできるにもかかわらず、イベントストリームが手に入る。データベースとストリームを同期し続けるための分散トランザクションの必要はない。

Stopford氏にとって、CDCのもっとも重要なユースケースの一つは、古いアーキテクチャからの移行だ。CDCを使ってレガシーシステムのデータベースに接続することで、イベントストリームを取り出して、レガシーシステムの使用からイベントストリームの使用へと徐々に移行することができる。

イベントソーシングとイベントストリームを使うときに役立つパターンは、イベントを2度保持することだ。一度は、時間順でなされた全ての変更を保持するリテンションベースのトピックで、これはイベントソースのビューで使われる。もう一度は、圧縮されたトピックで、これはエンティティの最新ビューのみを提供し、より小さく高速になる。

Stopford氏は、ストリームベースのイベントアーキテクチャの一番の機能は、進化できることである、と締めくくった。新たな要件が発生すると、新しいサービスを構築して、簡単にデプロイし、最初から全てのイベントを再生することで最新の状態にすることができる。Kafkaにはそのための機能が備わっており、このスタイルのアーキテクチャを構成するのにぴったりだ、と彼は考えている。