イベントソースのマイクロサービスを設計する

イベントソースのマイクロサービスはまだまだ十分に研究されていない、と Greg Young 氏は先日の µCon London 2017 で主張したが、彼はすべてのマイクロサービスがイベントソースとすべきであるとは限らない、ということも強調した。代わりに、彼は個別のサービスごとに検討し、実際に適しているサービスにイベントソーシングパターンを適用することを推奨した。

イベントソーシングの権威であり Event Store のリードアーキテクトでもある Youg 氏にとって、マイクロサービスシステムを構築する際の重要な設計上の課題は、マイル黒サービスごとにデータベースを分けるべきか、あるいは全てのマイクロサービスが同一のデータベースと会話すべきか、ということだ。例えばリレーショナルデータベースを使用している場合など静的にストアする場合、1 つか複数かのデータベースをもつということは大きな違いではないが、あベントストアを使用する場合、いくつかのサービスに 1 つのイベントストアを使用した方が、サービスごとにイベントストアを使用するよりも遥かにシンプルになる、と彼は主張する。その理由は、イベントの順序付けであり、また彼は Leslie Lamport 氏と彼の論文 Time, Clocks and the Ordering of Events in a Distributed System を引用した。

サービスごとに 1 つのイベントストアを使用すると、2 つ以上のイベントストアからイベントを読み込むサービスにとって、全てのイベントが作られた順序と同じ順序で読み込まれたか、あるいはイベントのリプレイが同じ順序で行われるかについて確証をもてない。多数のサービスがあってもイベントストアが 1 つであれば、順序は保証され、また決定的である。これは直線化と呼ばれる技術で、システムのスケーラビリティは損なわれるが動作を推測しやすくなり。 Young 氏はこの課題について、今後多くの場合で、潜在的なスケーラビリティの課題よりも重要となるだろうと考えている。

Young 氏は、直線化が秒間 10,000 イベント以上のイベントを処理するような場合でも、大半のシステムで機能すると主張する。本当に高いスループットの場合、例えば秒間 250,000 イベントまで及ぶような場合は、他の設計を検討することが良い考えかもしれない。

複数のマイクロサービスを運用する場合、 correlation （相関関係） と causation （因果関係）の同定 が大きな利益となりうる。あるサービスが、他のサービスにリッスンされるイベントをレイズし、リッスンしたサービスが自身のイベントをレイズした場合、システム内のイベントのが滝のように流れる可能性があり、そうなると順序を追うのが困難になる。しかし 3 つのアイデンティティ (uuid)、すなわち message id、correlation id、 causation id をイベントに追加すれば、この障壁は回避できる。

イベントは生成時に常にユニークな message id を取得する。あるイベントの correlation id を、その起因となったイベントの correlation id と同じ値にすれば、同一の発生元に属するイベントのフローにあるイベントを全て見つけることができるようになり、 causation id を、その起因となったイベントの message id と同じ値にすれば、イベントがレイズされた順序がわかるようになる。

メッセージフロー全体を正しい順序で把握できれば、エラー発生時にその原因を理解、発見するのに非常に役に立つ。この技術はイベントソースのシステムでなくとも利用できる。サービスからレイズされた全てのイベントをリッスンし保存するような監査サービスに追加すれば、同じことが可能だ。

Young 氏が彼のプレゼンテーションの中で、インメモリサービスやレプリケーションモデル、ジオグラフィックディストリビューションについても議論した。

来年のカンファレンスは2018年11月5日、6日に予定されている。