オンラインオークションプラットフォームを作成するためのCQRSおよびイベントソーシングの適用

同僚、こんにちは！私はミシャです。プログラマーとして働いています。



この記事では、私たちのチームがCQRSとイベントソーシングのアプローチをオンラインオークションサイトであるプロジェクトに適用することを決定した方法についてお話します。そして、これから何が得られたのか、私たちの経験からどのような結論を導き出すことができるのか、そしてどのレーキがCQRSとESを利用する人のために踏まないことが重要であるのかについてもです。

プレリュード

まず、少し歴史とビジネスの背景。顧客は、いわゆるタイムドオークションを開催するためのプラットフォームを持って私たちのところにやって来ました。このプラットフォームは、すでに生産されていて、ある程度のフィードバックが収集されました。クライアントは、ライブオークション用のプラットフォームを作成することを望んでいました。



今少し用語。オークションとは、特定のアイテムが販売されたとき-ロットであり、バイヤー（入札者）が入札します。ロットの所有者は、最も高い入札をしたバイヤーです。時限オークションは、各ロットに事前に決められた締め切り時刻がある場合です。バイヤーは賭けをします。ある時点で、ロットは閉鎖されます。 ebayに似ています。



時限プラットフォームは、CRUDを使用して古典的な方法で作成されました。ロットは、予定通りに開始され、別のアプリケーションによってクローズされました。これらすべては非常に確実に機能しませんでした：いくつかの賭けは失われました、いくつかは間違った買い手に代わって、ロットが閉じられなかったか、数回閉じられたように行われました。



ライブオークションは、インターネットを介してリモートで実際のオフラインオークションに参加する機会です。部屋（内部用語では「部屋」）があり、ハンマーと聴衆がいるオークションのホストが含まれています。ラップトップのすぐ隣にいわゆる事務員が座っています。事務員は、インターフェイスのボタンを押すと、オークションのコースをインターネットにブロードキャストし、接続されています。オークションの時点までに、バイヤーはオフラインになっている入札を確認し、入札を行うことができます。



どちらのプラットフォームも原則としてリアルタイムで機能しますが、時間制限のあるすべての買い物客が同じ立場にある場合、ライブの場合はオンラインの買い物客が室内の買い物客とうまく競争できることが非常に重要です。つまり、システムは非常に高速で信頼性の高いものでなければなりません。時限プラットフォームの悲しい経験は、古典的なCRUDは私たちに適していないことをはっきりと語っています。



私たちには、CQRSとESを使用した独自の経験がなかったため、CQRSとESを使用している同僚（私たちは大企業です）に相談し、彼らにビジネスの現実を示し、共同でCQRSとESが私たちに適しているという結論に達しました。



他にオンラインオークションの詳細は何ですか。

• — . , « », , . — , 5 . .
• , , .
• — - , , — .
• , .
• ソリューションはスケーラブルでなければなりません-複数のオークションを同時に開催できます。

CQRSとESのアプローチの概要

CQRSとESのアプローチの検討については詳しく説明しません。これについてはインターネット、特にハブレに関する資料があります（たとえば、ここ：CQRS +イベントソーシングの概要）。ただし、主なポイントについて簡単に説明します。

• イベントソーシングで最も重要なこと：システムはデータを保存しませんが、変更の履歴、つまりイベントを保存します。システムの現在の状態は、イベントの順次適用によって取得されます。
• ドメインモデルは、集合体と呼ばれるエンティティに分割されます。ユニットにはバージョンがあります。イベントは集計に適用されます。集約にイベントを適用すると、バージョンが増加します。
• write-. , .
• . . , , . «» . .
• , , - ( N- ) . «» . , .
• - , , , , write-.
• write-, read-, , . read- . Read- .
• , — Command Query Responsibility Segregation (CQRS): , , write-; , , read-.

. .

時間を節約するため、また特定の経験がないため、CQRSとESには何らかのフレームワークを使用する必要があると判断しました。



一般的に、私たちの技術スタックはMicrosoft、つまり.NETとC＃です。データベース-Microsoft SQL Server。すべてがAzureでホストされています。このスタックで時限プラットフォームが作成されました。その上にライブプラットフォームを作成することは論理的でした。



当時、私が覚えているように、技術スタックに関しては、チンチラがほとんど唯一の選択肢でした。それで私たちは彼女を連れて行きました。



なぜCQRSとESフレームワークが必要なのですか？彼は「そのまま」そのような問題を解決し、次のような実装の側面をサポートできます。

• エンティティ、コマンド、イベントの集約、バージョン管理の集約、再水和、スナップショットのメカニズム。
• さまざまなDBMSを操作するためのインターフェース。イベントとアグリゲートのスナップショットを書き込みベース（イベントストア）に保存/ロードします。
• キューを操作するためのインターフェース-コマンドとイベントを適切なキューに送信し、キューからコマンドとイベントを読み取ります。
• WebSocketを操作するためのインターフェース。

したがって、チンチラの使用を考慮して、スタックに追加しました。

• コマンドおよびイベントバスとしてのAzure Service BusであるChinchillaは、そのままでサポートします。
• 書き込みおよび読み取りデータベースはMicrosoft SQL Serverです。つまり、どちらもSQLデータベースです。これは意識的な選択の結果ではなく、歴史的な理由によるとは言いません。

はい、フロントエンドはAngularで作成されています。



すでに述べたように、システムの要件の1つは、ユーザーが自分のアクションの結果と他のユーザーのアクションについてできるだけ早く学習することです。これは、顧客と店員の両方に当てはまります。したがって、SignalRとwebsocketを使用して、フロントエンドのデータをすばやく更新します。ChinchillaはSignalR統合をサポートしています。

ユニットの選択

CQRSとESのアプローチを実装するときに最初に行うことの1つは、ドメインモデルを集約に分割する方法を決定することです。



私たちの場合、ドメインモデルは次のようないくつかの主要なエンティティで構成されています。

public class Auction
{
     public AuctionState State { get; private set; }
     public Guid? CurrentLotId { get; private set; }
     public List<Guid> Lots { get; }
}

public class Lot
{
     public Guid? AuctionId { get; private set; }
     public LotState State { get; private set; }
     public decimal NextBid { get; private set; }
     public Stack<Bid> Bids { get; }
}
 
public class Bid
{
     public decimal Amount { get; set; }
     public Guid? BidderId { get; set; }
}

2つの集計、オークションとロット（入札あり）がありました。一般的に、それは論理的ですが、1つのことは考慮していませんでした。このような分割により、システムの状態は2つのユニットに分散され、場合によっては、一貫性を維持するために、1つではなく両方のユニットに変更を加える必要があります。たとえば、オークションを一時停止できます。オークションが一時停止されている場合は、入札できません。ロット自体を一時停止することは可能ですが、一時停止されたオークションは「一時停止解除」以外のコマンドを処理できません。



あるいは、1つの集合体、オークション、すべてのロットと入札を作成することもできます。しかし、オークションには最大数千のロットがあり、1つのロットに数十の入札があるため、そのようなオブジェクトは非常に困難になります。オークションの存続期間中、このようなアグリゲートには多くのバージョンがあり、アグリゲートのスナップショットが作成されていない場合、そのようなアグリゲートの再水和（すべてのイベントのアグリゲートへの順次適用）には、かなり長い時間がかかります。これは私たちの状況には受け入れられません。スナップショットを使用する場合（私たちはスナップショットを使用します）、スナップショット自体が非常に重くなります。



一方、単一のユーザーアクションの処理内で2つのアグリゲートに変更が確実に適用されるようにするには、トランザクションを使用して同じコマンド内で両方のアグリゲートを変更するか、同じトランザクション内で2つのコマンドを実行する必要があります。どちらも概して、アーキテクチャ違反です。



ドメインモデルを集合体に分解するときは、このような状況を考慮する必要があります。



プロジェクトの進化のこの段階では、AuctionとLotという2つのユニットがあり、いくつかのコマンド内で両方のユニットを変更することでアーキテクチャを壊しています。

ユニットの特定のバージョンにコマンドを適用する

複数のバイヤーが同時に同じロットに入札した場合、つまり、「入札」コマンドをシステムに送信した場合、1つの入札のみが成功します。多くは集合体であり、バージョンがあります。コマンドの処理中に、イベントが生成され、それぞれが集約のバージョンを増分します。2つの方法があります。

• 適用するアグリゲートのバージョンを指定するコマンドを送信します。その後、コマンドハンドラは、コマンドのバージョンをユニットの現在のバージョンとすぐに比較し、一致しない場合は続行できません。
• コマンドでユニットのバージョンを指定しないでください。次に、集計がいくつかのバージョンで再水和され、対応するビジネスロジックが実行され、イベントが生成されます。そして、それらが保存されたときのみ、そのようなバージョンのユニットがすでに存在するという実行ポップアップが表示されます。他の誰かが以前にやったからです。

2番目のオプションを使用します。これにより、チームは実行される可能性が高くなります。コマンドを送信するアプリケーションの部分（この場合、これはフロントエンドです）のため、ある確率で、アグリゲートの現在のバージョンは、バックエンドの実際のバージョンよりも遅れます。特に大量のコマンドが送信され、ユニットのバージョンが頻繁に変更される状況では。

キューを使用してコマンドを実行するときのエラー

私たちの実装では、チンチラによって大きく駆動され、コマンドハンドラーがキュー（Microsoft Azure Service Bus）からコマンドを読み取ります。チームが技術的な理由（タイムアウト、キュー/ベースへの接続エラー）で失敗した場合と、ビジネス上の理由（すでに受け入れられているのと同じ金額で多くの入札を試みた場合など）を明確に区別します。最初のケースでは、コマンドはキュー設定で指定された繰り返し回数に達するまでコマンドの実行が繰り返され、その後コマンドはデッドレターキュー（Azure Service Busでの未処理メッセージの別のトピック）に送信されます。業務執行の場合、チームは即座にデッドレターキューに送られます。

キューを使用してイベントを処理するときのエラー

コマンドの実行の結果として生成されたイベントは、実装に応じて、イベントハンドラーによってキューに送信され、キューから取得されます。また、イベントを処理するときにエラーも発生します。



ただし、コマンドが実行されない状況とは対照的に、ここではすべてが悪化しています。コマンドが実行され、イベントが書き込みベースに書き込まれたが、ハンドラーによる処理が失敗した可能性があります。また、これらのハンドラーの1つが読み取りベースを更新しても、読み取りベースは更新されません。つまり、不整合な状態になります。読み取りイベントを再試行するメカニズムのため、ほとんどの場合、データベースは最後に更新されますが、すべての試行後にデータベースが壊れたままになる可能性はまだ残っています。







私たちはこの問題を家で経験しました。しかし、その理由は、イベント処理にいくつかのビジネスロジックがあり、激しい賭けで時々失敗する可能性が高いためです。残念ながら、これは遅すぎることに気づき、ビジネス実装を迅速かつ簡単にやり直すことは不可能でした。



その結果、一時的な対策として、アプリケーションの書き込み部分から読み取り部分にイベントを転送するためのAzure Service Busの使用を停止しました。代わりに、いわゆるインメモリバスが使用されます。これにより、コマンドとイベントを1つのトランザクションで処理し、障害が発生した場合はすべてをロールバックできます。







このようなソリューションはスケーラビリティには貢献しませんが、一方で、読み取りベースが壊れてフロントエンドが故障し、すべてのイベントを再生して読み取りベースを再作成しないとオークションを続行できなくなる状況は除外します。

イベントに応答してコマンドを送信する

これは原則として適切ですが、この2番目のコマンドの実行に失敗してもシステムの状態が壊れない場合に限られます。

1つのコマンドの複数のイベントを処理する

一般に、1つのコマンドを実行すると、いくつかのイベントが発生します。イベントごとに、読み取りデータベースに変更を加える必要があります。また、イベントのシーケンスも重要であり、間違ったシーケンスでは、イベント処理が正常に機能しません。これはすべて、たとえば、キュ​​ーからメッセージを読み取るコードの異なるインスタンスを使用して、キューから読み取り、1つのコマンドのイベントを個別に処理することができないことを意味します。さらに、キューからのイベントがそこに送信されたのと同じ順序で読み取られることが保証されている必要があります。または、最初の試行ですべてのコマンドイベントが正常に処理されるわけではないという事実に備える必要があります。

複数のハンドラーで1つのイベントを処理する

システムが1つのイベントに応答して複数の異なるアクションを実行する必要がある場合、通常、このイベントの複数のハンドラーが作成されます。それらは、並行してまたは順次に動作できます。順次起動の場合、ハンドラーの1つが失敗すると、シーケンス全体が再開されます（これはチンチラの場合です）。このような実装では、一度正常に実行されたハンドラーの2回目の実行が失敗しないように、ハンドラーがべき等であることが重要です。そうしないと、2番目のハンドラーがチェーンから落ちたときに、最初のハンドラーが2回目（およびそれ以降）の試行で落ちるため、チェーン（チェーン）は完全に機能しません。



たとえば、読み取りベースのイベントハンドラーは、5ルーブルの多くに入札を追加します。これを行う最初の試みは成功し、2回目はデータベースで制約を実行できません。

結論/結論

現在、私たちのプロジェクトは、私たちに思われるように、私たちのビジネスの詳細に関連する既存のレーキのほとんどにすでに踏み込んだ段階にあります。一般的に、私たちの経験はかなり成功していると考えています。CQRSとESは、この分野に適しています。チンチラの放棄により、プロジェクトのさらなる発展が見られ、より柔軟な別のフレームワークが支持されました。ただし、フレームワークの使用をまったく拒否することもできます。また、一方では信頼性と、他方ではソリューションの速度とスケーラビリティとの間のバランスを見つける方向にいくつかの変更が生じる可能性があります。



ビジネスコンポーネントに関しては、ここでもいくつかの質問が未解決のままです。たとえば、ドメインモデルを集計に分割します。



私たちの経験が誰かのために役立ち、時間を節約し、熊手を避けるのに役立つことを願っています。ご清聴ありがとうございました。