イベント ソーシングを備えた CQRS は、私たちのシステムの 1 つのアーキテクチャとして完璧に適合しているように見えますが、現在心配していることは 1 つだけです。それは、大量のイベントを処理し、結果として巨大なイベント ストアを処理することです。
私たちの現在のシステムは、1 日に約 100 万のイベントを受け取ります (ただし、現在はイベント ソーシングとは何の関係もありません)。それらを長期間保存すると、イベント ストアはかなり大きくなる可能性がありますが、ダンプ/パージすると、ローリング スナップショットに頻繁にアクセスすると、イベント ソーシングの大きな利点の 1 つ、つまりシステムの履歴とリプレイに関する情報が失われる可能性があります。
CQRS アーキテクチャでこの問題に対処する一般的な方法は何ですか? それはまったく問題ですか？イベント ストアに追加のハードウェアを投入するだけですか、それともアーキテクチャ設計レベルで何かできることはありますか?
最も一般的なアプローチは、スナップショットと永続的な読み取りモデルを使用することだと思います。つまり、新しい読み取りモデルを構築する必要がある場合や、既存の読み取りモデルの動作を変更する必要がある場合を除いて、実際にイベントを頻繁に再生することはありません。ドメイン オブジェクトのスナップショットを保存することで、イベントの長いストリームを再生する必要がなくなります。
スナップショットと永続的な読み取りモデルを保存することは、イベント ソーシングなしで CQRS を実行することと大差ないと主張する人もいるかもしれません。しかし、古いイベントは、読み取りモデルで間違いを犯した場合、新しい情報を導き出す必要がある場合、またはその他の厳格な監査要件がある場合に備えて存在します。
ビジネス価値の低いイベントが多数あるこのアプリケーションでは、イベント ログが小さくなるように、実行中にイベントを大幅にスクラブする予定です。しかし、一部のオブジェクトについては、スナップショットと永続モデルにフォールバックすると思います。
「アクティブなストリームセット」を見てください。生成され、比較的短期間で変異し、最終状態に達すると消滅するライフサイクルを持つストリームはありますか? その場合、これらのストリームを安価なストレージ (バックアップ) に移動できます。それらが必要になる唯一の理由は再生の目的であるため、(応答速度は遅くなりますが) アクセスできるようにするか、再生のために圧縮コピーを保持することをお勧めします。いずれにせよ、イベント ストアから、または少なくともアクティブなストリームセットから移動できるストリームがあるかどうかを確認してください。
もう 1 つのオプションは、ストリームを複数の物理イベント ストアに分割することです。使用できる地理的境界があるかもしれませんし、それらを自然に分割する何かがあるかもしれません (通常、あなたがいるドメインがヒントを提供します)。長所と短所について考える必要があるようなものです。
この手法は、イベント ソーシングに限定されません。状態ベースのモデルにも同様に適用できます (結局は単なるデータです)。