ハイブリッドクラウドのイベント駆動型アーキテクチャ

イベントベースのアーキテクチャの紹介

クーポンネットワークm.cps3.cn

译自：イベント駆動型アーキテクチャの紹介

EDAアーキテクチャの長所と短所を完全に理解するために、EDAに関連するいくつかの記事が後で紹介されます。

イベントベースのアーキテクチャの紹介
- 簡単な定義
  - 決して起こらないイベント
  - チャネル送信イベント
  - 非同期性と汎用性によるデカップリング
- イベントの処理方法
  - 離散イベント処理
  - イベントストリーム処理
  - 複雑なイベント処理
- EDAを使用する場合
- EDAの利点
- EDAのデメリット
- 注意点
- 総括する

マイクロサービスの前回の紹介では、サービスの粒度と疎結合を確保する必要性について説明しました。この記事では、サービスは自律的で完全かつ独立しており、同期通信を最小限に抑える必要があると提案しています。今日は、疎結合の意味について説明し、マイクロサービスコミュニティでますます人気が高まっているイベント駆動型アーキテクチャについて説明します。

簡単な定義

イベント駆動型アーキテクチャ（EDA）は、イベントの生成と消費を促進するソフトウェアアーキテクチャ仕様です。

イベントは、関心のあるアクションを表します。一般に、イベントは、特定のエンティティの状態を作成または変更するアクションに対応します。たとえば、eコマースアプリケーションで注文することはイベントであり、注文した製品を配布することもイベントです。また、消費者が受け取った商品のレビューを提出するイベントでもあります。

決して起こらないイベント

イベントの奇妙な点は、イベントを気にする可能性のある特定のサービスに明確に伝達されていないことです。イベントは「発生するだけ」です。さらに重要なのは、これらのイベントを処理する特定のサービスがあるかどうかに関係なく、イベントは純粋にのみ発生するということです。これはよく引用される哲学的な考えのように聞こえます：「森の中の木が、誰もそれを聞いていないなら、それは音を立てますか？」。しかし、これがイベントが非常に強力である理由でもあります。イベントは、発生していることの（自己完結型の）レコードに変換され、イベントとその拡張機能は（基本的に）ハンドラーから分離されています。実際、イベントレコードの作成者は、消費者が誰であるか、または消費者がいるかどうかさえ知りません。

レコードには通常、イベントを説明する情報が含まれています。例としての前の順序では、対応するイベントのJSON記述は次のとおりです。

{
  "orderId": "760b5301-295f-4fec-95f8-6b303a3b824a",
  "customerId": 28623823,
  "productId": 31334,
  "quantity": 1,
  "timestamp": "2021-02-09T11:12:17+0000"
}

ノード：レコードとイベントの間には微妙な違いがありますが、それらはしばしば交換可能です。つまり、「イベント」という用語は通常、イベントの「レコード」を指します。説明を簡単にするために、これら2つの用語はこの中で自由に使用されます。論文。

上記は、注文を高度に簡略化したものです。注文を開始したアプリケーション（ショッピングカートサービス）は、誰が（どのようにそしてなぜ）注文を処理したかを知りません。プロデューサーは、潜在的な消費者がイベントの処理に必要なすべての情報を取得できるようにします。つまり、注文レコードには、注文を履行するために必要なすべての属性が厳密に含まれているとは限りません。たとえば、商品のサイズ、保管場所、消費者の配送先住所などの情報を直接指定する必要はありませんが、取得した注文レコードのIDを介して間接的にこの情報を取得するために解析できます。リレーショナルデータベースの外部キーの概念は、イベントにも適用されます。

チャネル送信イベント

生産者と消費者がお互いを認識していない場合、2つはどのように通信する必要がありますか？

答えは、「記録」という用語をくっつけることです。イベントは通常、ログと呼ばれるよく知られた場所に永続化されます（「元帳」という用語も使用される場合があります）。ログは最下位レベルにあり、プロデューサーによって保存されたイベントデータ構造は、後続のコンシューマーがアクセスできる場所にのみ添付できます。ブローカー（プロデューサーとコンシューマー間の永続的なミドルウェア）は、ログの操作を担当します。イベントが生成されると、誰でもそのイベントを利用できます。

イベント駆動型システムを扱う場合、1つ以上のログインターフェイスを表すために「ストリーム」という用語を使用することがよくあります。ログは物理的な概念（ファイルを使用して実装）であり、ストリームは論理的な概念であり、イベントを構成する無制限のレコードのセットを表しますが、レコードは特定の順序に従う必要があります。異なるストリーミングプラットフォームは、独自の名前を使用してストリームを参照する場合があります。Apache Kafkaは、トピックとパーティションを使用してフローを記述します。

プロデューサー、コンシューマー、ストリームの関係は次のとおりです。

イベント駆動型アーキテクチャの参照モデル

関連する概念を思い出してください。

イベントは、個別の時点で発生する関心のあるアクションです。イベントは、外部から観察および説明される場合があります。
レコードとしてのイベントの永続性：イベントとレコードは関連していますが、技術的に異なります。イベントは、何か（状態の変化など）の発生を表し、それ自体は無形です。そして、記録はイベントの正確な説明です。通常、「イベント」という用語は、対応するレコードを指すために使用します。
プロデューサーは、対応するレコードをストリームに公開することによってイベントを検出するレシーバーです。（レコードの投稿は、イベントが発生したことを意味します）
ストリームは、永続性の順序付けられたレコードです。これらは通常、1つ以上のディスクベースのログによって永続化されます。もちろん、データベーステーブル、分散コンセンサスプロトコル、またはブロックチェーンスタイルの分散型台帳を使用して永続化をサポートすることもできます。
ブローカーは、ストリームへのアクセス、読み取りおよび書き込み操作の促進、コンシューマーステータスの処理、およびストリームでのさまざまな「ハウスキーピング」の実行を担当します。たとえば、ブローカーは、レコードがオーバーフローしたときにストリームのコンテンツを傍受する場合があります。
コンシューマーはストリームを読み取り、受信したレコードに応答します。イベントに対する消費者の反応には、いくつかの追加操作が伴う場合があります。たとえば、コンシューマーはローカルデータベースのエントリを永続化する（「更新」イベントを発行してリモートエンティティの状態を再構築する）（つまり、リモートエンティティの説明を更新する）ことができます。
消費者と生産者は重複する可能性があります。たとえば、イベントへのレスポンダーは、1つ以上の派生イベントを生成することもできます。

非同期性と汎用性によるデカップリング

なぜEDAは結合度を大幅に減らすことができるのですか？

結合のより実用的な定義は次のとおりです。コンポーネントが他のコンポーネントによって影響を受ける程度。結合は、空間（コンポーネントは構造的に関連しています）と時間（時間はコンポーネント間の関係の程度に影響します）に存在します。後者の場合、より良い例は、1つのサービスが他のサービスのRESTAPIを同期的に呼び出すことです。呼び出されたサービスがダウンしている場合、サービスは処理を続行できません（応答がブロックされます）。2つのサービスを同時に実行する必要がある場合、2つの間にある程度の時間的結合があります。2つのサービスの依存度が高い場合は、強結合と呼ばれ、そうでない場合は、疎結合と呼ばれます。

カップリングの概念モデル

EDAは、結合を抑制するために2つの方法を使用します。

要約すると、イベントは通信することができない、彼らは起こります。（リリースレコードを介して）イベントを開始したコンポーネントは、他のコンポーネントが存在するかどうかを認識していません。したがって、コンシューマーが使用できない場合でも、プロデューサーは動作を停止しません。ブローカーは、プロデューサーにバックプレッシャーをかけることなく、イベントを一時的にキャッシュします。
ブローカーのイベントレコードの永続性は、時間の概念を大幅に排除します。プロデューサーはT1でイベントを公開し、コンシューマーはT2でイベントインシデントを読み取り、T1とT2の間隔はミリ秒（通常のすべてのコンポーネント）または時間レベル（一部のコンシューマーがダウンしているか他のことに忙しい場合）です。

EDAは特効薬ではなく、結合の概念を排除するものではありません（そうしないと、システム内のコンポーネントが連携しなくなります）。ここで、焦点をブローカーに移します。プロデューサーとコンシューマーが意味のある分離を行うためには、ブローカーに依存する必要があります。このアプローチは、システムアーキテクチャの複雑さを増し、他の障害点をもたらします。これが、ブローカーが高性能でフォールトトレラントでなければならない理由です。そうでない場合は、問題のセットを別のセットに置き換えるだけです。

イベントの処理方法

時間処理は通常、3つの一般的な方法に分けられます。これらのメソッドは相互に排他的ではなく、大規模なイベント駆動型システムで共存することがよくあります。

離散イベント処理

ソーシャルメディアプラットフォームでの投稿の公開など、個別のイベントを処理するために使用されます。離散イベント処理は、表示されるイベントが通常は関連しておらず、独立して処理できるという特徴があります。

イベントストリーム処理

これは、一連の関連する無制限のイベントストリームを処理するために使用されます。イベントのレコードは特定の順序で表示され、発生したイベントに関連するいくつかの情報を伝達します。たとえば、事業体が共同で変更を行う場合、消費者は生産者が指定した順序で変更を加え、その事業体のコピーをローカルデータベースに保存できます。イベント処理のシーケンスに注意を払う必要があるため、このようなイベントを個別に処理することはできません。コンシューマーは、条件付きの競合を回避する必要があります。つまり、複数のコンシューマーインスタンスがデータベース内のレコードを同時に変更する可能性があり、更新の順序が正しくないためにデータの不整合が発生する可能性があります。

Kafkaなどのよりよく知られているストリーミングイベントプラットフォームは、更新順序を維持するために記録されたキーとパーティションに依存しています。Kafkaはまた、エンティティへのすべての変更が特定のコンシューマーによって処理されることを保証し、複数のコンシューマーがイベントを並行して処理し、同時に競合を引き起こすことを回避します。

複雑なイベント処理

複合イベント処理（CEP）は、一連の単純なイベントから複雑なイベントを導出または識別するためのモデルです。たとえば、建物内の温度センサーと遅延センサーを監視し、火災が発生したかどうかを推測し、それらを追跡し続けます。温度変化だけでは、アラームをトリガーするのに十分ではありません。さらに重要なのは、温度ピークと変化率の収束によって形成されるクラスターイベントであり、これは人命を救う可能性があります。

このタイプの処理は通常、より複雑であり、イベントハンドラーが以前のイベントを追跡し、要求および集約するための効果的な方法を提供する必要があります。

EDAを使用する場合

イベント駆動型アーキテクチャの利点は、いくつかのシナリオで使用できます。

不透明な消費者エコシステム。この場合、プロデューサーはコンシューマーを理解していません。後者は短いプロセスである可能性があり、短時間で行き来する可能性があります。
高いファンアウト。イベントが複数の異なるコンシューマーによって処理される可能性があるシナリオ。
複雑なパターンマッチング。イベントをつなぎ合わせて、より複雑なイベントを推測することができます。（このようなシナリオでは、集約、つまり上記の複雑なイベント処理が必要になる場合があります）
コマンドクエリの責任の分離。CQRSは、データストレージ領域の読み取り操作と更新操作を分離するモードです。CQRSを実装すると、アプリケーションのスケーラビリティと柔軟性を向上させることができます（データの一貫性にはトレードオフがあります）。このモードは通常、EDAに関連付けられています。

EDAの利点

キャッシングとフォールトトレランス。イベントの消費率はプロデューサーと同期されていない可能性があり、プロデューサーはコンシューマーとの一貫性を保つために速度を落とすことはできません。
不器用なポイントツーポイント統合を回避するために、プロデューサーとコンシューマーは分離されています。EDAの下では、新しいプロデューサーとコンシューマーを追加するのは簡単です。また、プロデューサーとコンシューマーの実装を変更するのも簡単です（イベントレコードを制約するコントラクト/スキームが遵守されている場合）。
大規模な拡張。通常、イベントストリームの一部は、いくつかの無関係なセルフストリームに分割され、並行して処理されます。イベントのバックログにより、負荷需要を満たすためにコンシューマーの数を増やすこともできます。Kafkaのようなプラットフォームは、イベントを厳密に順番に処理し、ストリーム間で大規模な並列処理を可能にします。

EDAのデメリット

非同期処理のみ。EDAは効果的なシステムデカップリングモードですが、アプリケーションを非同期イベント処理に制限します。EDAは、要求や応答などの対話を適切に処理しません（イニシエーターは、応答が処理を続行するのを待つ必要があります）。
追加の複雑さを導入します。従来のクライアントサーバーと要求/応答には2つのパーティしか含まれていませんでしたが、EDAを採用した後、プロデューサーとコンシューマーの間の仲介者としてサードパーティのブローカーが導入されました。
欠点は隠されています。これは、デカップリングシステムの性質に反しているように見えるため、独特です。システムが高度に結合されている場合、システムのエラーはすぐに受け継がれ、私たちの注意を引き付けます。ほとんどのシナリオでは、この状況を回避する必要があります。コンポーネントに障害が発生した場合、他のコンポーネントへの影響を最小限に抑えるようにしてください。障害隠蔽の悪影響は、私たちの注意を引くべき問題を不注意に隠してしまうことです。これは、各イベント駆動型コンポーネントにリアルタイムの監視とログ記録を追加することで解決できますが、そうすることで新たな複雑さももたらされます。

注意点

EDAは万能薬ではありません。多くの強力なツールと同様に、誤って使用される可能性があります。以下にリストされている内容は、EDAの欠点としてではなく、開発者やアーキテクトがイベント駆動型システムを設計および実装する際に注意を払う必要のある一連の落とし穴と見なす必要があります。

複雑な振り付け。疎結合コンポーネントを使用すると、ユーザーが混乱する可能性があります。アーキテクチャ全体がルーブゴールドバーグマシンのように見え（下の図を使用するとルーブゴールドバーグを理解できます）、ビジネスロジック全体も一連のイベントとして実装されます（副作用）：あるコンポーネントによって開始されたイベントは、別のコンポーネントをトリガーして別のイベントを開始し、次に別のコンポーネントをトリガーしてイベントを開始するなどの可能性があります。コンポーネント間のこの種の相互作用は、すぐに理解できなくなる可能性があります。
コマンドとイベントの混乱。イベントは、何が起こったかを簡単に説明するために使用されます。イベントの処理方法は指定されていません。コマンドは、特定のコンポーネントに対する直接コマンドです。コマンドとイベントはどちらも特定の種類のメッセージであるため、コマンドを混乱させてイベントと間違えるのは非常に簡単です。

コマンドはEDAの下に配置することもできますが、イベントと区別する必要があります。コマンドはシステムの状態を変更する可能性があり、通常はロールバック計画が必要です。
消費者は不可知論者です。イベントは何らかの方法で関連するプロパティをキャプチャする必要がありますが、これらのイベントの処理方法を制限するものではありません。言うのは簡単、するのは難しい。イベントレコードに追加されるコンテンツを制限するのに十分な情報を取得できない場合があります（レコードに追加された情報が最終的に役立つかどうかを判断することは不可能です）。

最も重要なことは、コマンドとイベントを区別するための上記の2番目のポイントだと思います。

総括する

マイクロサービスアーキテクチャのパターンは、より保守しやすく、スケーラブルで、堅牢なソフトウェアシステムの構築に伴う難しい問題の1つです。問題分解の観点からは、マイクロサービスは優れていますが、多くの厄介な問題ももたらします。その1つが結合です。システムを少数のマイクロサービスにランダムに分割すると、最初よりも悪い状況になる可能性があります。それを「オールインワンで配布」と表現する用語があります。

混乱を解決し、結合の問題を特定するために、イベント駆動型アーキテクチャを導入しました。

EDAは、システムコンポーネント間の結合を減らすのに役立つ効果的なツールであり、プロデューサー、コンシューマー、イベント、およびストリームを使用して相互作用するモデルです。イベントは対象のアクションを表し、どのコンポーネントも、他のコンポーネントの存在を認識する必要なしに、イベントを非同期に公開および消費できます。EDAを使用すると、コンポーネントを独立して操作および進化させることができます。しかし、すべての問題を解決するのは特効薬ではありません。EDAは良い選択であり、その利点はそれを採用するコストを大幅に上回ります。EDAは、マイクロサービスの展開を成功させるために必要な要素であると言えます。