多数のスタートアップがそうであるように、Lunar Wayは、当初はモノリシックなRailsバックエンドアプリケーションであった。しかし、組織的および技術的な理由から、３年前の稼働後間もなく、マイクロサービスアーキテクチャへのマイグレーションの開始を決定した。この結果、約75のマイクロサービスで構成され、非同期メッセージパッシングを主要な通信パターンとして採用した、イベント駆動型のマイクロサービスバックエンドが実現した。
コペンハーゲンで先日開催されたMicroCPH 2019カンファレンスで、スマートフォン経由の銀行サービスを提供するフィンテック企業であるLunar WayのThomasBøghFangel氏とEmil Krog Ingerslev氏は、マイクロサービスへのマイグレーションを実施する中で、氏らがプラットフォーム固有の問題の所在を発見したことについて解説した。その結果として、氏らは昨年、これらの問題を解決し、プラットフォーム内での一貫性を保証するため、イベントソーシングに移行することを決定したのだ。プレゼンテーションでは、氏らが遭遇した4つの問題と、それらを解決する上でイベントソーシングとイベントストリームを使用した方法が説明された。
一貫性の問題
最初の問題は一貫性の問題だった。サービスがデータベースを変更する時には、イベントもメッセージキューで発行する必要がある。しかし、データベースの更新後にサービスが直接クラッシュすると、イベントは発行されない(ゼロ以上(zero-or-more)メッセージ配信)。そのため、イベントのプロデューサもコンシューマも認知しないという、一貫性の問題が発生する。これが原因で、不正なサポートケースが発生し、イベントの再送信や、コンシューマサービスのデータを手動で更新するなどの修正作業をしばしば行っていた。
これに対する解決策は、状態変更とメッセージの発行をひとつのアトミックな操作で行うことだ。このために氏らが考えたのが、イベントが状態の変化も同時に表現する、イベントソースの使用だった。ただしIngerslev氏は、これはサービス内部のイベントであるので、公開する必要がある、という点を指摘する。個々のイベントを読み取って公開し、そのイベントを指すカーソルを保存することで、すべてのイベントが外部に公開されることが保証できる。サービスがクラッシュして再起動した場合は、カーソルが指すイベントを始点として、イベント発行を続けることにより、少なくとも１回の配信が可能になる。
新しいサービスの追加
氏らの次の問題は、新しいサービスを追加することだった。サービスの開始前には、上流のサービスからのデータが必要になるが、イベントの読み取りには先程の一貫性の問題がある。ソリューションは、再配信の可能な、順序付けされたイベントストリームを使用したイベントソーシングだ。イベントストリーム上にAPIを追加することにより、コンシューマが、特定のタイプのすべてのイベントを最初から読み取ることを可能にした。内部イベントは実装の詳細である。サービスがその状態を保存する方法に関するものであって、外部に公開されるべきではない。代わりに、氏らは、内部イベントを反映した統合イベントを追加した。これらは、コンシューマが読み取るためのイベントである。
自己回復
3番目の課題は、サービスの故障に関するものだ。サービスはイベントを受信するが、何らかの理由でイベントが失われた場合、コンシューマサービスからはこれを認識できず、一貫性のない状態に陥る。これを解決するには、コンシューマがイベントの欠落を認知して、再配信できるようにする必要がある。イベントの再配信による前述のソリューションが、ここでも機能する。さらに、イベントストリームの先頭だけでなく、任意の時点からの再配信を可能にする機能も加えられた。カーソルを使用した同じ手法が、ここでも使用されている。最後に受信したイベントと、イベントの順序を認知していれば、次のイベントが異常であることを検出できる。問題は、新しいイベントが到着するまで失ったイベントを検出できないことだが、カーソルが示す最後のイベントの後に、定期的にアップストリームサービスにイベントを要求することで、この問題は軽減できる。
変更
最後のトピックは変更に関するものだ。サービスは内部的に変更される可能性があるため、その場合でも他のサービスとの通信を中断しないようにするか、複数のサービスを同時にビッグバン移行する必要がある。当初の実装では、イベントに対しては追加変更のみを行うという、開発者間のコンセンサスがあった。イベントの構造を変更しなければならない場合には、関係するすべてのサービスが、同期を取って移行する必要がある。イベントソースに基づく新しいソリューションでは、統合イベントを採用した。サービス内にはひとつのイベントストリームしか存在せず、複数のプロジェクションを持つことで、それぞれが独自の統合イベントストリームを所有することを可能にしている。データモデルの進化に伴って、新たなプロジェクションを追加することにより、新しい統合ストリームの読み取りと新しいプロジェクションを開始することが可能になる。このような方法で、サービス展開を調整することなく、マイグレーションを実行できる。
Ingerslev氏は要約として、イベントソーシングライブラリが一般的に入手できないことを指摘した。このため氏らは、独自のフレームワークを構築することになり、非常に高価なものになった。さらに氏は、すべてのチームに新しいサービス設計パラダイムを導入するのは難しく、時間を要する点を指摘する一方で、採用したイベントソーシングパターンには非常に構成力があり、改善が容易であることを強調した。Fangel氏は最後に、作業中に現れたひとつのパターンを指摘した。特定のケースを、特別に、あるいは手動で処理するという苦痛を伴う状況から、サービスの通常の動作モードに移行することができたため、開発者は、最も重要なものであるビジネスドメインに集中することが可能になった。
カンファレンスのプレゼンテーションの大部分は録画されており、今後数週間にわたって公開される予定である。