Event Meshを使用して実現できるアーキテクチャパターンは、あらゆる業界の垂直分野と多種多様なユースケースに適用できます。以下のセクションでは、これらの「マクロパターン」のいくつかを探り、それらのアプリケーションが困難な問題の解決にどのような影響を与えるかを見ていきます。
イベントドリブンインテグレーションのアーキテクチャパターン
Event Meshは、以下を必要とするソリューションの設計と構築において非常に有用です。
- グローバルスケールでのイベント配信
- グローバルな信頼性と可用性
- 可変速度とボリュームの管理（バースティトラフィックへの対応）
- 多様な地理的環境（クラウドとオンプレミスの両方）にわたるデータの同期
設計段階の早期に課題に対処しないと、深刻な問題につながり、システムの稼働時間に大きな影響を与え、収益に劇的な影響を与える可能性があります。したがって、最初からスケーラブルで進化可能なアーキテクチャにつながる技術とアプローチを検討することが不可欠です。以下のセクションでは、Event Meshがリスクを軽減しながら特定のユースケースを最適化するのにどのように役立つかを見ていきます。
おさらいとして、Event Meshはイベントルーティング情報を共有する相互接続されたEvent Brokerのコレクション（複数の地域にまたがる可能性がある）です。ルーターがデータパケットを最適にルーティングするためにルーティングテーブルを互いに共有するIPネットワークと同様に、Event Meshノードはサブスクリプションテーブルを共有することで、イベントをグローバルな環境全体のすべての関係者にシームレスにルーティングできます。動的イベントルーティング機能に加えて、Event Meshは特定の低速コンシューマーを圧倒しないようにトラフィックを「バッファリング」し、データの「定常状態」のフラックスを維持することもできます。
ハイブリッド環境の同期
ほとんどの企業はクラウド環境とエンタープライズデータセンターにわたって時に何千ものアプリケーションとシステムが存在する、多様化した技術環境を持っています。ほとんどのビジネスソリューションは、これらのアプリケーションが互いに接続されることを必要とし、複数の環境にわたって、また多様なアプリケーション環境にわたってデータが自由に流れることを必要とします。例えば、クラウドアプリケーションで発生したアクティビティは、エンタープライズのオンプレミスデータセンターに存在するメインフレームデータベースの更新を促す必要があることがよくあります。これを達成する方法は多数あり、その中には他より効率的でスケーラブルなものもあります。
Event Meshがパターンとして環境間のデータ移動の改善にどのように役立つかを示す2つの例を見てみましょう。
- 地域をまたぐイベント配信
- クラウドからオンプレミスへのデータ同期
シナリオ1では、3つの異なるクラウドリージョンが別々の地域に配置されており、1つの環境で公開されたイベントを以下の図のように他の2つにリアルタイムで利用可能にしたいと想像してください。
ここでの核心的な課題は、環境間のブリッジとして機能する「転送エージェント」を各環境に配置する必要があることです。さらに、各環境が独自のイベントプロトコルを使用している可能性があるため、転送エージェントはイベントを転送する必要がある宛先（トピック/キュー）を知っているだけでなく、イベントを転送できるように2つのプロトコルを「話せる」必要があります。したがって、Event Meshを使わない方法でこのシナリオを実装するには、以下を組み込む少なくとも3つのエージェントを実装する必要があります。
- プロトコル接続/ブリッジロジック
- ルーティングロジック
さらに、各環境が独自のプロトコル固有のエラー処理と監視機能を持ちますが、カスタムソリューションを構築しない限り、3つの環境すべてを監視するグローバルな監視機能がないため、エラー処理と監視は非常に困難になる可能性があります。
ネイティブに相互接続されたEvent Meshを使用した場合、このシナリオは大幅に簡素化されます。サブスクライバーが公開されたイベントへの関心を表明すれば、Event Meshはそのイベントを暗黙的にすべての対応する宛先にルーティングします。追加のコーディングや容量は必要なく、Event Meshは実質的に1つのファブリックであるため、監視と処理はEvent Mesh全体のスコープをカバーします。
シナリオ2では、OS390システム（メインフレーム）で変更されたデータをSalesForceとAWSのデータベース（MySQLなど）と同期させる必要があると想像してください。これを行う典型的な方法は、IBM MQ経由でメインフレームに接続するインテグレーションプロセスを設定することです。レコード変更が発生すると、変更がMQに公開され、インテグレーションプロセスがそれをサブスクライブします。次にSalesForceのデータを更新するためにREST APIを呼び出し、AWS SQS経由でAWSのインテグレーションコンポーネントに接続し、そのコンポーネントがAWSデータベースに新しい変更を挿入します。
この実装では、2つのインテグレーションコンポーネント（1つはオンプレミス、1つはAWS）があり、MQをSQSにブリッジし、REST APIを呼び出さなければなりません。
要するに、構成要素が増えることでソリューションがより脆弱でエラーが発生しやすく、安定性が低くなる可能性があります。
Event Meshを使用すると、公開側でIBM MQコネクタをEvent Meshに直接ブリッジし（インテグレーション不要）、サブスクライブ側でSalesForceとデータベースコネクタをEvent Meshにブリッジして、レコードをAWSデータベースとSalesForceにそれぞれ直接アップサートできます。
したがって、環境をまたぐ同期ソリューションはEvent Meshなしでも確かに構築できますが、通常はより柔軟性が低く、追加の開発時間と容量が必要になります。Event Meshは両方のシナリオを大幅に簡素化します。
低速コンシューマーへの高速データ供給
Event Meshなしでは実現が非常に困難な、もう一つのよくあるシナリオは、高速データを前提とする環境と、より低速かつ少量のデータしか吸収できない環境を接続することです。このシナリオを可能にするのはEvent Meshのショックアブソープション機能であり、必要なときにコンシューマーがイベントを取り込めるレベルにまで速度を落とすことで、一定のトラフィックフローを保証するよう設計されています。
これが活躍できる2つの例を示します。
- IoTからエンタープライズへ（OTからITへ）
- 銀行業と資本市場
IoTの例では、IoTイベントの大量データはコアエンタープライズシステムが吸収するには過多になることが多いですが、そのデータは何らかの方法でそこに届く必要があります。エッジプロセスがIoTイベントストリームを「要約」してボリュームを削減し、コアエンタープライズシステムが取り込めるようにすることがよくあります。これにより追加のロジックが加わり、不正確なデータがエンタープライズシステムに入り込む可能性があります。IoT Event MeshをエンタープライズEvent Meshに接続することで、新しいソフトウェアを追加することなくすべてのイベントが順序どおりに配信されることが保証され、「速度を落とした」イベントストリームはどのエンタープライズシステムでもそれぞれの消費レートで取り込むことができます。
銀行業のシナリオでは、資本市場データが超高速である一方、コアバンキングシステムはリアルタイムで取り込めるデータ量に制限があるという単純な事実から、資本市場は通常コアバンキングシステムとは別の環境にあります。IoTのユースケースと同様に、資本市場のEvent Meshとコアバンキングシステムの環境をEvent Mesh経由で接続すると、コアバンキングシステムがリアルタイムデータにアクセスしてより適切な決定を下せるようになります。例えば、ウェルス・アンド・アセットマネジメント（WAM）部門は、顧客の株式投資に関するライブインサイトを取得することで大きなメリットを得られます。状況をより迅速に把握することでクライアントへのより良いアドバイスにつながり、特にWAMが適切な意思決定のコンテンツとコンテキストをリアルタイム通知としてクライアントに送信できる場合はなおさらです。
要約すると、Event Meshのショックアブソープション機能により、以前は実装が非常に困難だったユースケースを簡単に実装できるようになりました。
データ配信
非常によくあるユースケースは、データ変更のリアルタイム配信（Change Data Capture – CDCとも呼ばれる）を、グローバルに分散している可能性がある多数のアプリケーションとシステムの「オーディエンス」に行うことです。エンタープライズ全体のデータ変更の伝播は、CDCをサポートするコネクタを持つ従来のインテグレーションプラットフォームを介して、そして（ダウンストリームシステムの数に応じて）スキャッターギャザーメカニズムまたはイベントプラットフォームの活用によって比較的容易に達成できます。しかし、そのデータのダウンストリームコンシューマーが異なる地域、異なるクラウド、異なる環境にあり、かつ非常に多数（数千から数万）の場合、これは容易ではありません！
ユースケースを考えてみましょう。大手CPG企業が製品の1つの価格を変更する必要があり、その変更を複数の国、大陸、タイムゾーンにわたる2500以上のグローバル店舗に伝播させる必要があります。2500店舗それぞれが地域の価格モデルを更新し、必要な割引を適用し、通貨換算の可能性を考慮する必要があります。従来のインテグレーションモデルを使用すると、3つのオプションがあります。
- 価格変更を検出するCDCインテグレーションコンポーネントは、（地域レベルで）APIのサブセットを呼び出し、そのAPIが各店舗を表す多数のサブ地域APIを呼び出すことになります。
- あるいは、各地域が独自の価格カタログを持っている場合、CDCインテグレーションコンポーネントがそれらのリポジトリを更新し、各地域のCDCインテグレーションコンポーネントが変更を取得してローカル地域の店舗APIを呼び出すことができます。
- 追加のオプションは、前のセクションと同様に、プラットフォーム間で変更データ/イベントをルーティングする転送エージェントを持つローカルイベントプラットフォームのセットを使用することです。
これらのオプションの課題は以下のとおりです。
- スキャッターギャザーは呼び出しを並列化しますが、プロセスを終了する前にすべての並列スレッドの完了を待ちます。ダウンストリームシステムの数が非常に多い状況では、開始プロセスがタイムアウトする可能性があります。
- 地域製品カタログを更新するアプローチは、呼び出し元APIからのダウンストリーム呼び出し数を削減するため、最初のオプションよりも優れたオプションです。ただし、元のCDCプロセスに加えて複数のCDCインテグレーションプロセス（各地域製品カタログに1つ）を持つ必要があるため、複雑性が増します。
- データ変更を伝播するためにイベントプラットフォームを使用することはスケーラビリティの観点から最善のオプションですが、異なる環境や地域にまたがる複数のイベントプラットフォームを扱う場合、転送エージェントの課題や環境ごとに異なる可能性があるプロトコルの問題が発生する可能性があります。したがって、プロトコルブリッジが別のレベルの複雑性を加える可能性があります。
しかし、Event Meshベースのアプローチを取ることで問題が簡素化されます。Event Meshは、地域に関係なく関心のあるサブスクライバーがいる場所にイベントが動的にルーティングされるグローバルファブリックを作成します。Event Meshのスマートトピック、配信保証、ショックアブソープション機能により、イベントがそれぞれの宛先に支障なく届くことが保証されます。さらに、変更されたデータイベントのコンシューマーは、任意のタイプのインテグレーションプラットフォームまたはカスタムコードを使用して受信イベントを処理し、地域のルールと法律に従って価格変更を処理するために必要なロジックを適用できます。
Event Meshベースのアプローチは高い柔軟性とアジリティを提供し、任意の数のシステムをリアルタイムで更新する必要があるあらゆるシナリオに対応できます。
データ集約
Customer 360は最もよくあるユースケースの一つであり、ほぼあらゆる業界に適用できます。純粋なRESTful実装では、これを行う典型的な方法は複数のAPI呼び出しのオーケストレーションを介してレスポンスを集約することです。
このアプローチの問題は2つあります。
- オーケストレーションするポイントが多いほど、失敗とタイムアウトのリスクが高くなります
- これらのAPIが離れているほど（つまり地理的に分散しているほど）、レイテンシが増加するリスクが高くなり、タイムアウトのリスクも高くなります。
さらに、レイテンシ増加のリスクを軽減するために、企業はしばしば異なる地域でAPIインスタンスを複製しますが、これはローカルレイテンシを削減する可能性はあるものの、グローバルな容量要件を増やし、管理コストも増加させます。
APIが地理的に分散している状況では、中間にEvent Meshを使用することで多くの問題を軽減できます。すべてを網羅する顧客データのリクエストがRESTful API経由で行われるという考え方を維持する場合、そのAPIの実装は従来のオーケストレーションを行う代わりに、Event Meshへの「データリクエストイベント」の公開につながる可能性があります。すべての顧客データサブスクリプションはイベントを受信し、関連データストアを照会し、それぞれのデータのサブセットで応答します。開始元のCustomer 360 APIはすべてのレスポンスを受信し、集約して完全なペイロードをリクエストクライアントに返します。ある意味では、このアプローチはビッグデータコンテキストでのmap-reduceの実行に似ています。このアプローチには2つの大きなメリットがあります。
- 本質的にリクエストを並列化しており、より速いレスポンスタイムをもたらします
- 全体的なリクエストの構造を変更せずに追加のデータコンポーネントを追加できるため、スケーリングがはるかに容易になります。
JavaScriptフレームワーク（REACT、Angularなど）に基づく最新のUIは、イベント処理の機能を備えています。そのため、UIから直接MQTTまたはWebSockets経由でEvent Meshに顧客データリクエストイベントを送信し、RESTインターフェースの必要性をなくすことが実際に可能です。このアプローチはアーキテクチャを簡素化しパフォーマンスをさらに向上させる可能性がありますが、Experience層APIをUIに委ねることで関心の分離の原則に影響を与えるため、最善の選択ではない場合があります。しかし、最適なソリューションは、初回のロードやリクエストにはREST APIを活用し、その後の顧客データセットへのすべての変更は非同期方式でUIに直接転送されるというものです。このアプローチは「map-reduce」アプローチのスピードと、それぞれのデータ変更によって駆動されるUIのデータへの継続的なリアルタイム更新を組み合わせることで、はるかに優れた顧客体験をもたらします。
ステートフルコレオグラフィ
注文フルフィルメントは非常によくあるユースケースであり、この記事で取り上げた前のユースケースと同様に、業界を横断して適用できます。
注文処理は注文の提出から始まります。これはほとんどの場合RESTful API経由で行われ、通常2つの主要なアクティビティを含みます。
- 注文管理システム（OMS）への注文入力
- フルフィルメントプロセスの開始
フルフィルメントプロセスは多大な時間がかかる可能性があり、複数のサービスやシステムにまたがる可能性があるため、コレオグラフィ化する必要があります。このプロセスには、しばしば課題を引き起こす重要な側面があります：状態管理です。特定のプロセスの状態が中央で制御され可視化されているオーケストレーションとは異なり、コレオグラフィではそうはなりません。コレオグラフィにおける状態管理はアンサンブル内の各サービスに委任されています。これにより、各サービスが現在の状態を更新するための追加ロジックが加わり、状態を保存できるアプリケーションとオンデマンドで状態を取得するAPIが必要になります。ご覧のとおり、コレオグラフィは注文フルフィルメントプロセスを実現するための最善のアーキテクチャパターンですが、追加の容量が必要で実装の複雑性が増します。
Event Meshのネイティブ機能のいくつかは、コレオグラフィで遭遇する状態管理の課題を軽減するのに役立ちます。スマートトピックには3つの主要な差別化要素があります。
- 階層的な性質を持ち、URLのようなトピック構造を作成します（例：
/order/processed/US） - URLのどのセグメントにも挿入できる変数をサポートします（例：
/order/processed/US/{city}/{store_id}） - サブスクライバーが受信したいデータセットを識別するために使用できるワイルドカードをサポートします（例：
/order/processed/US/Chicago/*）
これらの機能を適用して、Event Mesh内で状態管理を可能にできます。例えば、変数を使用してトピックの構造自体に状態を組み込むことができます：/order/processed/{product_id}/{state}。したがって、注文を受け取ったばかりの場合、注文イベントを/order/processed/{product_id}/{create}に公開することでコレオグラフィをトリガーできます。「create」状態からイベントを消費するサービスがその作業を終えると、コレオグラフィの次のステップ/order/processed/{product_id}/{inventory}にイベントを公開します。このように、イベントの公開がコレオグラフィの状態を変化させ、イベントの消費が実質的に状態変化/遷移を処理します。
さらに、Observerサービスがすべての状態遷移を監視してレポートし、ビジネストランザクションが実行のどの段階にあるかを関係者に通知できます。
注文フルフィルメントプロセスを実装するこのアプローチは非常に有益です。
- 状態管理ロジックを記述・管理する必要をなくします
- 容量要件（状態を保持するデータベース/アプリケーションをホストするための）を削減します
- ビジネストランザクションのフローに「オブザーバビリティ」を提供します
このタイプの実装はステートフルコレオグラフィと呼ぶことができます。下の図は、Event Meshベースのアーキテクチャを示しています。
コンポジットパターン（CQRS）
コマンドクエリ責務分離（CQRS）は、コマンド（作成/更新/削除）の処理責務とデータの照会（読み取り）の責務を分離することでデータアクセスを最適化しようとする、比較的よくあるパターンです。
データの変更よりもクエリの方が頻繁に発生するため、デプロイメントアーキテクチャはデータ変更サービスよりもクエリサービスにより多くの容量を割り当てることができます。この種の関心の分離は、スケーラビリティ、パフォーマンス、セキュリティを最適化します。
Event Meshのレンズを通してCQRSを見ると、分散しているサービスを活用してインテグレーションを簡素化できるソリューションを検討できます。前述のデータ配信シナリオは、Event Meshをグローバルスケールでデータ変更機能を実装するためにどのように使用できるかを実際に示しています。同様に、データ集約ソリューションは、Event Meshをグローバルスケールでクエリを実行するためにどのように使用できるかを示しています。
したがって、Event Meshはその本質的な機能のためにCQRSパターンのスコープを大幅に拡大するために使用できます。
トポロジー
この記事で取り上げる最後のパターンは、インテグレーション自体ではなく、Event Meshトポロジーの設計パターンに焦点を当てています。最適なイベントドリブンインテグレーションアーキテクチャの基盤として、Event Meshはビジネスニーズに対応し、エンタープライズの成長パターンに関係なくデータ損失なしで一貫したパフォーマンスを保証する方法で設計されることが不可欠です。
最も関連性の高い2つのコアトポロジーパターンがあり、それぞれにバリエーションのサブセットがあります。
- 地域ベース
- ドメインベース
地域ベースのパターンはその性質上非常に直感的であり、シームレスなグローバルトラフィックに対応するために世界中の異なるデータセンターにデプロイされたEvent Meshクラスターを単純に定義します。Event MeshクラスターはグローバルなEvent Meshを実現するために完全に相互接続されています。
ドメインベースのパターンはドメイン駆動設計の原則を借用し、トポロジーへの階層化されたアプローチを推奨しています。すべてのビジネスドメインはグローバルカバレッジを提供する独自のEvent Meshを持っており、そのビジネスドメインに関連するすべてのトラフィックは明示的に定義された「イベントバウンダリー」上で行われます。ドメイン間の通信には、イベントトラフィックの交換台またはグローバルルーターのように機能する「Event Mesh Backbone」があります。これは、ピアツーピア方式（ドメイン間で直接）またはパブサブ方式（1つのドメインから複数のドメインへブロードキャスト）でトラフィックを整理します。
どのトポロジーが特定のエンタープライズに最も適しているかは、スコープと目的の問題です。しかし多くの場合、企業はハイブリッドモデルを選択します。コアトポロジーはドメインベースですが、各ドメインには地理的に分散したトポロジーがあります。
まとめ
この記事では、イベントドリブンインテグレーションの設計を最適化できるさまざまなアプローチを探りました。これらのパターンが取り上げる重要な課題はグローバルスケーリングであり、暗黙的には分散アーキテクチャの最適化です。地理的に分散した環境にわたるデータの同期、データの配信または集約、あるいは長期実行プロセスの最適化まで、これらのパターンはグローバルスケールでのデータ移動の最適化に焦点を当てています。これらのパターンの主要な特徴は、Event Meshとインテグレーションプラットフォーム間の相乗効果の最大化です。
これらのパターンは、任意の商用インテグレーションプラットフォーム（iPaaSなど）またはカスタムコードソリューションで実装できます。Event Meshはこれらの最適化を可能にする重要な要素であり、グローバルスケールを提供するだけでなく、セキュリティ、パフォーマンス、データ損失防止も提供します。分散アーキテクチャが設計プロセスの最初からどのようにスケールするかを検討することが重要です。そうすることで、より堅牢で進化可能なアーキテクチャに到達できます。