集約、イベントソーシング、およびCQRSを使用したトランザクションマイクロサービスの開発（パート2）

これは、マイクロサービスアーキテクチャを使用したトランザクションアプリケーションの開発に関する翻訳記事の完了です。 を開始します。



記事の最初の部分で、マイクロサービスアーキテクチャを使用する際の主な障害は、ドメインモデル、トランザクション、およびクエリが機能分離に対して驚くほど耐性があるということです。 解決策は、各サービスのビジネスロジックをDDD集合の形式で実装することであることが示されました。 各トランザクションは、単一の集約を更新または作成します。 イベントは、集合体（およびサービス）間のデータの整合性を維持するために使用されます。



記事の第2部では、イベントを使用する際の重要なタスクが、集約の状態のアトミックな変更とイベントの同時発行であることを確認します。 イベントソーシングでこの問題を解決する方法を見てみましょう。ビジネスロジックと状態保存システムの設計にイベント指向のアプローチを使用します。 その後、マイクロサービスアーキテクチャがデータベースクエリの実装を困難にし、コマンドクエリの責任分離（CQRS）と呼ばれるアプローチがスケーラブルで効率的なクエリの実装にどのように役立つかを説明します。



キーポイント：

• イベントソーシングは、状態を確実に変更し、イベントを発行するためのメカニズムであり、他のソリューションの制限を克服できます。
• イベントソーシングを使用したイベント指向のアプローチは、マイクロサービスアーキテクチャとよく一致しています。
• スナップショットは、特定の時点より前に発生したすべてのイベントを組み合わせることにより、集計状態クエリのパフォーマンスを向上させることができます。
• イベントソーシングはクエリに問題を引き起こす可能性がありますが、CQRSとマテリアライズドビューによって克服されます。
• イベントソーシングとCQRSは特別なツールやソフトウェアを必要としません。多くの既存のフレームワークは、必要な低レベル機能の一部を引き受けることができます。

信頼性の高いステータス更新とイベント発行

一見すると、イベントを介して集計間の一貫性を確保することは、非常に簡単なタスクのようです。 データベースで集計を作成または更新することにより、サービスは単にイベントを公開します。 ただし、問題があります。データベースの更新とイベントの公開はアトミックに実行する必要があります。 たとえば、データベースの更新後、イベントの発行前に何かが壊れた場合、システムは不安定な状態になります。 この場合の従来のソリューションは、データベースとメッセージブローカーを含む分散トランザクションです。 しかし、記事の前半で説明した理由により、分散トランザクションは実行可能なオプションではありません。



分散トランザクションを使用せずにこの問題を解決するには、いくつかの方法があります。 たとえば、メッセージブローカー（ Apache Kafkaなど ）を使用できます。









個別に選択されたメッセージ受信者がブローカーメッセージをサブスクライブし、それらを受信すると、データベースを更新します。 このアプローチにより、データベースが更新され、イベントが発行されます。 その短所は、アプリケーションがデータベースへの書き込みのために送信したものをすぐに読み取れない、はるかに複雑な一貫性モデルであることです。



別の解決策は、 トランザクションログの末尾パターンです。トランザクションログからレコードが取得され、イベントに変換され、メッセージブローカーに送信されます。 このアプローチの重要な利点は、アプリケーションを変更する必要がないことです。 ただし、欠点は、低レベルの変更からテーブル内の行への高レベルのビジネスイベント（データベースを更新する理由）をリバースエンジニアリングすることが困難になる可能性があることです。









3番目の解決策：データベーステーブルを一時的なメッセージキューとして使用します。 サービスが集計を更新すると、ローカルトランザクション内のEVENTSデータベースの特別なテーブルにイベントが追加されます。 別のプロセスがEVENTSテーブルを定期的にスキャンしてイベントを発行し、メッセージブローカーに送信します。



このソリューションの優れた機能は、サービスが高レベルのビジネスイベントを発行できることです。 欠点：この方法は、イベント発行コードをビジネスロジックと同期する必要があるため、エラーが発生する可能性があります。









3つのオプションにはすべて重大な欠点があります。 延期されたデータベース更新を使用してメッセージブローカーを介してイベントを発行しても、Read-your-writes整合性モデルの条件は提供されません。 トランザクションログに基づいてイベントを公開すると、データ読み取りの一貫性が保証されますが、高レベルのビジネスイベントを常に公開できるとは限りません。 データベーステーブルをメッセージキューとして使用すると、高レベルのビジネスイベントの一貫した読み取りと発行が保証されますが、開発者は状態が変化したときにイベントを発行することを忘れないでください。



幸いなことに、別の解決策があります。 これは、イベントソーシングと呼ばれる、状態保存とビジネスロジックに対するイベント駆動型のアプローチです。

イベントソーシングによるマイクロサービス開発

イベントソーシングは、イベント駆動型のステートフルアプローチです。 これは新しいアイデアではありません。 5年以上前に最初にイベントソーシングについて学びましたが、マイクロサービスの開発を開始するまでは好奇心が残りました。 イベントソーシングは、イベント駆動型のマイクロサービスアーキテクチャを実装する優れた方法であることが実証されています。



イベントソーシングを使用するサービスは、集約の状態を一連のイベントとして保存します。 集計が作成または更新されると、サービスはデータベース内の特別なイベントストアに1つ以上のイベントを保存します。



ユニットの現在の状態を取得するために、イベントがダウンロードされて再生されます。 関数型プログラミングの観点から、サービスはイベントに対してfold / reduce機能を実行することにより、ユニットの現在の状態を再構築します。 イベントは現在状態であるため、状態の更新とイベントの公開の原子性に関する問題はもうありません。



たとえば、注文サービスを考えます。 各注文をORDERSテーブルの行として保存する代わりに、注文の各集計を、Create Order 、 Order Approved 、 Order Sentなどの一連のイベントとして保存します。 SQLデータベースを使用してオンラインストアに保存する方法を次に示します。









Entity_typeおよびentity_id列は集約識別子です。

event_id-イベント識別子。

event_type-イベントのタイプ。

event_data-JSON形式のシリアル化されたイベント属性。



一部のイベントには多くのデータが含まれています。 たとえば、 注文作成イベントには、注文の構成、請求情報、配達情報に関する情報が含まれます。 Order Sentイベントには最小限の情報が含まれており、単に状態間の遷移です。

イベントの調達とイベントの公開

厳密に言えば、イベントソーシングは単純に集約の状態をイベントとして保存します。 イベントを発行するための信頼できるメカニズムとして使用するのは非常に簡単です。 イベントの保存は本質的にアトミックな操作であり、イベントリポジトリがすべての関心のあるサービスへのイベントへのアクセスを提供することを保証します。 たとえば、イベントが上記のEVENTSテーブルに格納されている場合、サブスクライバは単に定期的にテーブルをポーリングして新しいイベントを受信できます。 より洗練されたイベントストアは、同様の保証を提供する別のアプローチを使用しますが、より生産的でスケーラブルです。 たとえば、 Eventuate Localはトランザクションログテーリングパターンを使用します。 MySQLレプリケーションスレッドからEVENTSテーブルに挿入されたイベントを読み取り、Apache Kafkaを使用して発行します。

状態スナップショットを使用してパフォーマンスを改善する

オーダーユニットは、状態遷移の数が比較的少ないことを特徴としているため、イベントの数はわずかです。 この場合、イベントストアからの要求とOrder集計の現在の状態の再構築が有効になります。 ただし、一部のユニットには多数のイベントがあります。 たとえば、 顧客集計には、多くのクレジット予約イベントが含まれる可能性があります。 時間が経つにつれて、それらのロードと処理は非効率的になります。



問題の一般的な解決策は、ユニットの状態のスナップショットを定期的に保存することです。 アプリケーションは、最後のスナップショットとその作成以降に発生したイベントのみをロードすることにより、ユニットの状態を復元します。 関数型プログラミングでは、スナップショットはfold / reduceの初期値を表します。 ユニットの構造が単純で簡単にシリアル化できる場合、スナップショットは、たとえばJSON形式にすることができます。 Mementoパターンを使用して、より複雑な集合体の写真を撮影できます。



たとえば、オンラインストアの顧客ユニットの構造は非常に単純です。顧客に関する情報、信用限度、および信用資金の予約に関するデータです。 クライアントのスナップショットは、JSON形式のステータスに関する一連のデータです。 この図は、イベント103の時点のクライアントの状態に対応するスナップショットからクライアントの状態を再作成する方法を示しています。カスタマーサービスは、スナップショットをダウンロードし、103番目以降に発生したイベントを処理するだけです。









クライアントサービスは、スナップショットのJSONを逆シリアル化し、イベント104〜106を読み込んで処理することにより、クライアントの状態を再作成します。

イベントソーシングの実装

イベントリポジトリは、データベースとメッセージブローカーのハイブリッドです。 主キーを使用して集約イベントを挿入および取得するためのAPIを備えているため、データベースですが、イベントをサブスクライブするためのAPIを備えているため、メッセージブローカーでもあります。



イベントリポジトリを実装するには、いくつかの異なる方法があります。 それらの1つは、独自のイベントソーシングフレームワークを作成することです。 たとえば、イベントをRDBMSに保存できます。 これは、イベントを投稿するための、パフォーマンスは低くても簡単な方法です。 サブスクライバは、単に定期的にEVENTSテーブルをポーリングして新しいイベントを探します。



別のオプション：特別なイベントリポジトリを使用します。これは、原則として、豊富な機能セット、より高いパフォーマンスとスケーラビリティを提供します。 イベントソーシングの先駆者であるGreg Youngは、Event Store（https://geteventstore.com）と呼ばれる.NETベースのオープンソースイベントリポジトリを作成しました。 以前Typesafeとして知られていたLightbendは 、イベントソーシングに基づいてLagomマイクロサービスフレームワークを開発しました。 クラウドサービスとして利用可能なイベントソーシングフレームワークを備えたEventuateスタートアップは、KafkaとRDBMSを使用するオープンソースプロジェクトです。

イベントソーシングの長所と短所

イベントソーシングには長所と短所があります。 このアプローチの主な利点は、集約の状態が変化するたびにイベントが発行されることが保証されることです。 これは、イベント駆動型のマイクロサービスアーキテクチャの優れた基盤です。 さらに、各イベントは変更を行ったユーザーの識別子を記録できるため、イベントソーシングは正確性が保証された監査証跡を提供します。 イベントストリームは、ユーザーへの通知の送信など、他の目的に使用できます。



イベントソーシングのもう1つの利点は、各ユニットの履歴全体を保存できることです。 集計の状態を過去に戻す一時クエリを簡単に実装できます。 特定の時点でのユニットの状態を判断するには、この瞬間の前に発生したイベントを処理するだけです。 たとえば、過去のある時点で利用可能な顧客ローンを簡単に計算できます。



集約自体ではなく、イベントを保存することにより、イベントソーシングは通常、「インピーダンスの不一致」の問題を回避します。 原則として、イベントはシンプルで簡単にシリアル化可能な構造を持っています。 シリアル化により、サービスは複雑なユニットのステータスのスナップショットを取得できます。 Mementoパターンは、集合体とそのシリアル化された表現の間に間接性のレベルを追加します。



ただし、イベントソーシングテクノロジはそれほどスムーズではなく、いくつかの欠点があります。 これは、調査する必要があるもう1つの珍しいプログラミングモデルです。 既存のアプリケーションでイベントソーシングの使用を開始するには、ビジネスロジックを書き直す必要があります。 幸いなことに、これはかなり機械的な変換であり、アプリケーションをマイクロサービス構造に転送することで実行できます。



イベントソーシングのもう1つの欠点は、メッセージブローカーが通常少なくとも1つの配信を保証することです。 べき等でないイベントハンドラは、繰り返しイベントを個別に検出および拒否する必要があります。 この場合、イベントソーシングフレームワークは、各イベントに自動インクリメント識別子を割り当てることで役立ちます。 その後、イベントハンドラーは、既に処理したイベントの最大識別子を追跡することにより、重複を検出できます。



イベントソーシングのもう1つの問題は、イベント（およびスナップショット！）のパターンが時間とともに変化することです。 イベントは永久に保存されるため、ユニットの状態を再構築するために、サービスはいくつかの異なるバージョンのスキームに対応するイベントを処理する必要があります。 サービスを簡素化する1つの方法は、イベントリポジトリからイベントをロードするときに、イベントソースフレームワークにすべてのイベントを最新バージョンの回路にキャストさせることです。 その結果、サービスはイベントの最新バージョンのみを処理する必要があります。



イベントソーシングのもう1つの欠点は、イベントリポジトリへのクエリ自体が困難なタスクになる可能性があることです。 低い信用限度でローンを発行する価値のある顧客を見つける必要があると想像してください。 SELECT * FROM CUSTOMER WHERE CREDIT_LIMIT <？と書くことはできません。 AND CREATION_DATE>？..与信限度を含む列は存在しません。 代わりに、ネストされたSELECTを含むより複雑で潜在的に非効率的なクエリを使用して、初期クレジット制限を設定してから変更するイベントを処理することによりクレジット制限を計算する必要があります。 さらに悪いことに、NoSQLイベントストアは通常、主キーのみで検索します。 したがって、コマンドクエリの責任分離（CQRS）アプローチを使用してクエリを実装する必要があります。

CQRSを使用したクエリの実装

イベントソースは、マイクロサービスアーキテクチャでの効率的なクエリの実装に対する主要な障害の1つです。 ただし、これが唯一の問題ではありません。 たとえば、高価な注文を出した新規顧客を見つけるSQLクエリを考えてみましょう。

SELECT * FROM CUSTOMER c, ORDER o WHERE c.id = o.ID AND o.ORDER_TOTAL > 100000 AND o.STATE = 'SHIPPED' AND c.CREATION_DATE > ?
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マイクロサービスアーキテクチャでは、単一のクエリでCUSTOMERテーブルとORDERテーブルを結合することはできません。 各テーブルは独自のサービスに属し、このサービスのAPIを介してのみアクセスできます。 異なるサービスに属するテーブルを結合する従来のクエリを作成することはできません。 イベントソーシングは状況を悪化させ、単純な直接要求を書くことを困難にします。 マイクロサービスアーキテクチャでクエリを実装する方法を見てみましょう。

CQRSを使用する

クエリを実装する良い方法は、Command Query Responsibility Segregation（ CQRS ）と呼ばれるアーキテクチャパターンを使用することです。 アプリケーションは2つの部分に分かれています。

1. コマンド部分は、コマンド（HTTP POST、PUT、DELETEなど）を処理して、集約を作成、更新、および削除します。 もちろん、これらの集約は、イベントソースを使用して実装されます。
2. アプリケーションのリクエスト部分はリクエスト（HTTP GETなど）を処理し、集計の1つ以上のマテリアライズド・ビューをリクエストします。 クエリパーツは、コマンドパーツによって発行されたイベントをサブスクライブすることにより、ビューを集計と同期させます。

要件に応じて、アプリケーションのクエリ部分は、次のデータベースの1つ以上を使用できます。

必要なら	次に使用する	例えば
主キーによるJSONオブジェクトの検索	MongoGBなどのドキュメント指向データベース、またはRedisなどのキーバリューデータウェアハウス。	MongoDBを使用して、すべての注文を含む顧客ドキュメントを使用して注文履歴を実装します。
基本的なJSON検索	MongoGBなどのドキュメント指向データベース。	MongoDBを使用してクライアント向けにプレゼンテーションを実装します。
全文検索	全文検索エンジン（ Elasticsearchなど） 。	注文ごとにElasticsearchドキュメントを使用して、注文で全文検索を実装します。
グラフリクエスト	Neo4jなどのグラフデータベース管理システム。	顧客、注文、その他のデータのグラフを使用した不正検出システムの実装。
従来のSQLクエリ	RDBMS	標準的なビジネスレポートと分析。

多くの点で、CQRSは、RDBMSをデータウェアハウスおよび全文検索（Elasticsearchなど）の検索エンジンとして使用する、広く使用されているアプローチのより一般的なイベント指向バージョンです。 CQRSは、全文検索エンジンではなく、より広範なデータベースタイプを使用します。 さらに、イベントにサブスクライブすることにより、アプリケーションの要求部分のプレゼンテーションをほぼリアルタイムで更新します。



次の図は、オンラインストアのCQRS図を示しています。

カスタマーサービスと注文サービスは、アプリケーションのコマンド部分に含まれています。 これらは、顧客と注文を作成および更新するためのAPIを提供します。 Customer View Serviceはクエリパーツに含まれています。 顧客データを照会するためのAPIを提供します。









Customer View Serviceは、アプリケーションのコマンド部分によって発行されたイベントをサブスクライブし、MongoDBに実装されているビューリポジトリを更新します。 MongoDBコレクションには、クライアントごとに1つのドキュメントが含まれています。 各ドキュメントには、特定の顧客を説明する属性と、最新の顧客注文の属性があります。 このコレクションは、上記のクエリを含むさまざまなクエリをサポートしています。

CQRSの長所と短所

CQRSの主な利点は、CQRSのおかげで、特にイベントソースを使用するマイクロサービスアーキテクチャでクエリを実装できるようになることです。 これにより、アプリケーションはさまざまなクエリセットを効果的にサポートできます。 別の利点は、責任の分離により、アプリケーションのコマンドとクエリの部分が単純化されることが多いことです。



欠点の1つは、CQRSがシステムの開発と運用に追加の労力を必要とすることです。 ビューを更新し、ビューをリクエストできるリクエスト側のサービスを作成してデプロイする必要があります。 さらに、ビューのリポジトリを展開する必要があります。



CQRSのもう1つの欠点は、コマンドとクエリ間のタイムラグに関連しています。 予想されるように、コマンドパーツが集約を更新する瞬間と、リクエストパーツの表現がこれらの変更を反映する準備ができる時の間に遅延があります。 集約を更新し、ビューを使用してすぐに要求を行うクライアントアプリケーションは、集約の以前のバージョンを見ることができます。 したがって、アプリケーションは、ユーザーがこの潜在的な不一致を受け取らないように作成する必要があります。

まとめ

イベントを使用してサービス間のデータの整合性を維持する際の主な問題の1つは、アトミックデータベースの更新とイベントの同時発行です。 従来のソリューションは、データベースとメッセージブローカーを使用して、分散トランザクションを使用することです。 ただし、このアプローチは最新のアプリケーションでは実行できません。 最適なソリューションは、イベントソーシングを使用することです。イベントソーシングは、ビジネスロジックおよび状態保存システムの設計に対するイベント駆動型のアプローチです。



マイクロサービスアーキテクチャの別の問題はクエリです。 多くの場合、複数のサービスに属するデータを結合する必要があります。 ただし、データはサービスごとにプライベートであるため、結合だけを使用することはできなくなりました。 現在の状態はそれ自体では保存されないため、イベントソースを使用すると、クエリを効率的に実装することがさらに難しくなります。 解決策は、CQRSを使用して、簡単にクエリできる1つ以上のマテリアライズドビューを最新の状態に保つことです。