CQRSとイベントソーシングでシステムを構築する

CQRSとイベントソースシステムに関する議論の末にMichiel Overeem氏が達した結論は、イベントソースシステムの持つ問題点について、従事する人々の多くが知識と理解を持たず、問題へのアプローチ方法も分かっていない、というものだ。これが氏にとってこの種のシステムを構築する方法を探求的に研究するきっかけになったと、氏は、先日アムステルダムで開催されたDDD Europe 2018カンファレンスで説明した。

Overseem氏がソフトウェアアーキテクトのリーダを務めるAFASは、ERPシステムの開発を20年以上続けているソフトウェア企業である。Overssem氏がCRQSベースのシステムのアップグレード方法について調査を始めたのは、同社が現行システムの完全な再構築プロセスにあったためだ。新たなシステムはCQRSとイベントソーシングに基づくものになる予定だが、それよりも重要なのは、同社がすべての知見をひとつのモデルに集積して、そのモデルからERPシステムを生成することを決定した点だ。この方法には、ビジネスロジックとテクノロジの分離が可能になるというメリットがあるが、ひとつ問題なのは、システムが一定期間運用されて大量のイベントが生成された後のモデル変更やアップグレードをどのように扱うのか、という点だ。

他のチームがCQRSやイベントソースシステムのアップグレードをどう扱っているかを知るために、Overeem氏と氏のチームは、さまざまなビジネス領域で50,000から数百万までの量のイベントを処理している人々を対象に、24件のインタビューを実施した。インタビューではイベントスキーマの改善過程に的を絞り、結果的に５つの領域を見出した。すなわち、“防止”、“テクニック”、“ルール設定”、“プライバシ”、そして“読み取りモデル”である。

基本的な視点を作り上げるため、まず最初に氏は、イベントソースシステムには暗黙のスキーマが常に存在することを強調した。スキーマに関する知識はシステムに組み込まれているが、リレーショナルデータベースとは対象的に、イベントストアはこのスキーマを強制していない。与えられたデータは喜んで格納するのだ。

変更の必要を“防止”する、あるいは最小限にするひとつの方法は、ドメイン駆動アプローチを採用することである。ドメインの実世界でのイベントを模倣すれば、ドメインが頻繁に変化するものでない以上、変更の必要性も少なくなるはずだ。もうひとつのアプローチは、企業として、イベントの変更とその影響をすべて検討し、場合によっては影響の少ない代替策を提案するような委員会を用意することである。

最も一般的に言及される“テクニック”は、イベントやスキーマは変更せず、変更毎に新たなイベントを導入する方法である。このプラクティスは多くの人たちが取り上げているが、Overeem氏の見る限り、実際に使われることはほとんどない。極めて簡単なテクニックである一方で、ドメインがより脆弱になるというリスクがあるのだ。ドメイン特有の変更はうまくいく場合が多いが、イベントバージョンの導入はドメインを棄損する可能性がある。

“テクニック”として一般的に利用されるのは弱いスキーマ(Weak Schema)だ。オブジェクトの逆シリアライズに弱いスキーマを使用すれば、使用するプロパティやアトリビュートのみが意味を持つようになる。データが利用可能であるか、あるいはデフォルト値が存在すれば、そのスキーマは満足される。

アップデートは、リレーショナルデータベースのアップデートと同じようなテクニックだ。このテクニックでは、スキーマ情報を備えた新たなツールを導入して、イベントストアを帯域外で更新する。これは怖いテクニックだ、とOvereem氏は言う。ミスをすればイベントストアを破壊する可能性があるからだ。ただし、破壊的ではない書き換え方法もある。例えば、新しいストレージテクニックでイベントを上書きしたり、XMLからJSONに変更することも可能だ。

コピートランスフォーム(Copy-transform)は、最もよく使われてきたテクニックだ。この場合、ひとつのイベントストアから読み出して別のイベントストアに書き込むと同時に、イベントを新たなスキーマに変換(transform)する。少し違う方法として、古いストリームから新たなストリームを生成するが、新しいストリームも同じストアに保存するものもある。マイクロサービスを使用する場合は、新しいスキーマ用にマイクロサービスを新たに作成して、旧マイクロサービスのすべてのイベントをコピーする方法もある。

EUの一般データ保護規則(GDPR)のようなデータ保護ルールによって、“プライバシ”はますます重要なものになってきている。個人情報の削除には３つの戦略がある、とOvereem氏は言う。

• トランスフォームのテクニックを使って、イベントストアからデータを削除する。
• メインのイベントと、分離保存される個人情報を持ったイベントとに分割する。これにより、個々の個人データが削除可能になる。
• 暗号化アプローチを使用して、個人のイベント毎に異なる暗号化キーを用意する。個人のイベント用のキーを削除することで、それらの読み取りを防止することが可能になる。

“読み取りモデル”の典型的な方法は再構築である。デメリットは長時間を必要とすることだ。この問題を克服するには複数のプロジェクタを並列動作させればよい、とOvereem氏は指摘する。古いイベントをスキップしたり、他のプロパティをフィルタリングするようなことも考えられる。可能であれば、第２のストアに対してプロジェクタを実行し、新たなものが用意できるまではオリジナルのストアを使うようにするとよい、と氏は述べている。

Overeem氏は要約として、CQRSとイベントソースシステムの構築にはさまざまな選択肢があり、インタビューした人たちのほとんどが複数のテクニックを使っていた点を指摘している。自分が何をしているのかを知り、自分の状況を理解することが必要だ、と氏は強調する。状況を考慮していない、安易な答が数多く存在するのだ。

Greg Young氏はイベントソースのバージョニングに関する本を執筆中で、現在は70パーセントが完成している。

DDD Europe 2019の計画は開始されたが、詳細な情報はまだ決定していない。