イベント駆動型アーキテクチャに適したツールとパターンの使用

イベント駆動型アーキテクチャでは、システムまたはアプリケーションの状態の変更を伝えるイベントの効率的な生産と消費がサポートされます。これらのアーキテクチャにより、システム間の柔軟な接続が可能になり、システム全体で動作するプロセスとほぼリアルタイムの更新がサポートされます。イベント駆動型アーキテクチャの利点は簡単にわかりますが、実装の詳細は必ずしも明確ではありません。イベント駆動型アーキテクチャパターンで考慮する必要がある機能は?これらのパターンでは具体的にどのような問題を解決しますか?ソリューションに適用される特別な考慮事項と、その解決に最適なパターンは?

このガイドでは、Salesforce テクノロジーを使用するときに、最適なイベント駆動型アーキテクチャを構築するために使用するパターンについて説明します。また、Salesforce で使用可能なイベントツールについて説明し、選択した使用事例のツールの推奨事項を示します。Salesforce に関連するデータレベルインテグレーションについての詳細は、『Data Integration Decision Guide (データインテグレーション決定ガイド)』を参照してください。

• **要求への同期応答を必要としないプロセスには、イベント駆動型アーキテクチャを使用します。**このガイドで説明するパターンは、データの一貫性、拡張性、再利用を目的として設計されており、組織のアプリケーション環境が進化するにつれて技術的な負債を最小限に抑えるのに役立ちます。（詳細については、「適切に設計されたスループット」を参照してください）。

• **MuleSoft または別のエンタープライズサービスバス (ESB) ソリューションが既存のランドスケープの一部である場合は、可能な限りそのソリューションを使用します。**これらのソリューションは、イベント駆動型アーキテクチャパターンをサポートすることを目的として設計されており、企業全体でインテグレーションを再利用できる強力な機能を備えています。

• **今後の公開/登録パターンには、ストリーミング API などの他の API を使用して独自のイベントハンドラを作成するのではなく、Pub/Sub API を使用します。**Pub/Sub API が正式リリースされたので、新しい公開/登録パターンに使用します。ストリーミング API やカスタム Apex サービスなど、他のプラットフォーム API を使用して既存のイベント通信を Pub/Sub API に移行できる場合は移行を計画します。

• **プラットフォームイベントと変更データキャプチャ （CDC） は、他のシステムで消費する必要があるレコードおよび項目の変更を公開するための推奨メカニズムです。**新しい実装では、PushTopic および Generic イベントを使用することはお勧めしません。Salesforce は、現在の機能の範囲内で引き続き PushTopic および汎用イベントをサポートしますが、この技術にさらに投資する予定はありません。

	Salesforce Platformは、従業員、自律型AIエージェント、会社のデータ、アプリケーションを単一の信頼できるシステムに統合し、生産性とカスタマー エクスペリエンスを向上させる包括的なAI駆動型プラットフォームです。Customer 360アプリケーション、Data Cloud、Slackを接続してエンドツーエンドの自動化を実現することで、「エージェント エンタープライズ」の作成を可能にします。
	MuleSoftは、オン プレミス環境とクラウド環境でアプリケーション、データ、デバイスを接続できるSalesforceの主要な統合プラットフォームです。MuleSoft は、システム全体のデータをロック解除し、拡張性の高いインテグレーションおよび自動化フレームワークを開発し、差別化された接続された環境を迅速に作成するためのプラットフォームを IT 部門に提供するプラットフォームです。

イベント駆動型アーキテクチャ (EDA) は、ほぼリアルタイムの通知が必要なシナリオ、大量のメッセージや複雑なメッセージの処理負荷の分散、およびキューイングによる接続の復元性が必要な IoT やモバイルデバイスなどのシステムの統合にお勧めします。ただし、EDA は非同期実行を目的として設計されているため、即時の同期的な人間の応答を必要とするプロセスには実装しないでください。また、ソースデータがそれほど頻繁に変更されないため、一括処理などの単純なパターンで十分である場合にも適していません。

イベント駆動型アーキテクチャに適していることが多い一般的なシナリオを次に示します。

ほとんどの大規模組織では、さまざまな機能を備えた複数のシステムが混在した複雑な IT 環境があります。イベント駆動型インテグレーションをサポートしていないレガシーシステムが組織に存在している可能性があります。また、システムでサポートされる場合でも、イベント駆動型インテグレーションが役に立たない使用事例もあります (サードパーティからの SFTP ファイル転送など)。一歩下がって組織の IT ランドスケープ全体を見ると、他のアーキテクチャソリューションと同様に、さまざまなシナリオをサポートするためにさまざまなパターンを採用する可能性があります。イベント駆動型をインテグレーションの推奨アプローチにする場合は、ツールボックスの別のツールと考えてください。適切なシナリオで使用できますが、すべてのシステムに適用されるアプローチではありません。包括的なインテグレーション戦略を作成すると、このガイドで説明されているパターンが適切な場合と適さない場合を判断するのに役立ちます。

多くのシナリオではイベント駆動型アーキテクチャが必要です。一部のシナリオでは、イベント駆動型アーキテクチャが最適でなくても機能します。ただし、一部のシナリオでは、イベント駆動型アーキテクチャは使用すべきではありません。次のシナリオを特定するのに役立つ判断基準の質問をいくつか紹介します。

イベント駆動型アーキテクチャにはさまざまなパターンがあります。イベント駆動型以外の特別な要件がない使用事例に適用できる汎用パターンもあります。たとえば、「適切に設計された相互運用性」を参照してください。他のパターンは、大量のデータが含まれるインテグレーションや、より長期間のメッセージ保持を必要とするシナリオなど、ここで説明する特定の使用事例に適用されます。

次の表は、このドキュメントで説明されているパターンの属性を比較したものです。特定の使用事例の潜在的なパターンを特定する必要がある場合のクイックリファレンスとして使用します。

Salesforce には、イベント駆動の使用事例に対処するのに役立つ複数のツールが用意されています。次の表に、使用可能なツールの概要を示します。

コアアプリケーション内で重要なレコードの状態が変更された場合 (注文の状況が「処理中」から「出荷済み」に変更された場合など)、他の複数のシステムでそれぞれのタスクを実行するためにほぼリアルタイムの通知が必要になる可能性があります。このような変更の量が多く、メッセージが複雑な場合、特定のビジネスニーズが発生します。従来の 2 地点間インテグレーションは負担が大きく、メンテナンスが困難です。すべての連動アプリケーションに対して脆弱なカスタム接続を確立すると、技術的な負債が発生し、組織の迅速な拡張が妨げられます。これらの頻繁なデータ同期を管理するには、ソースシステムをすべての消費システムに直接結合せずに堅牢なインテグレーションアプローチが必要です。

次の図は、複数のパブリッシャーと登録者がイベントバスを介してデータを共有する一般的な公開/登録パターンを示しています。この基本パターンは、このガイドの残りの部分にあるより具体的なパターンの基礎となります。このパターンの主な特徴を次に示します。

• パブリッシャーと登録者の間に直接のつながりはありません。パブリッシャーは、イベントバスにメッセージを送信するだけで、イベントバスはメッセージをリッスンする他のシステムにブロードキャストします。

• 同じシステムが公開者と登録者の両方になる可能性があります。

• システムは、複数の種別のイベントを公開または登録できます。

• このガイドのすべてのパターンと同様に、公開/登録パターンは、リモートプロシージャ呼び出し (RPI) または単に「起動後すぐに使用」と呼ばれる一般的なインテグレーションパターンカテゴリに分類されます

プッシュ通知やモバイルデバイスへの SMS メッセージなど、多数のクライアントアプリケーションに瞬時に更新を送信する必要がある場合、受信者ごとに一意の送信を作成する従来のプロセスは、すぐに拡張性のボトルネックになります。この場合のコアビジネスニーズは、1 つの情報 (取引先アラートや重要なサービス変更通知など) を多数のエンドポイントアプリケーションに同時に迅速かつハイパフォーマンスに配信することです。この要件を満たすための合理化されたアプローチでは、すべてのメッセージを 1 つのキューでルーティングします。このキューは、すべての消費システムのイベント情報の中心として機能します。この方法では、多数の個別のメッセージコピーを管理する必要がなくなるため、パフォーマンスが向上します。

fanout パターンでは、メッセージは 1 つのメッセージキューを介して 1 つ以上の宛先 (リスン中のクライアントまたは登録者) に配信されます。登録者は、自分の一意のコピーではなく、キューから同じメッセージを取得します。(これによりパフォーマンスが向上しますが、特定のユーザがメッセージを受信したかどうかの確認がより困難になる可能性があります)。

一部のイベントシナリオは、同期および変換プロセスの容量を圧迫する恐れのある大量のメッセージや、イベントデータの処理と変換に必要な複雑な複数ステップのロジックによって特徴付けられます。

たとえば、次のようなものがあります。

• **季節的な量の急増：**オンライン小売業者は、商品の選択が「旬」になると、量が急増する可能性があります。多数の顧客が同時に購入する場合、生成されるイベント数が同期および変換プロセスの容量を一時的に超える可能性があります。詳細は、「適切に設計されたデータ処理」を参照してください。

• **ケースまたは請求管理：**サービスベースの会社は、停止中にケース数や請求数が急増する可能性があります。

• **複雑なデータ変換：**メッセージを変換するために複雑なロジックを必要とする組織は、多くの場合、変換よりも早くイベントが生成されることを懸念します。

このパターンは、変換よりも早くメッセージが生成されるという問題に対処します。ストリーミングメッセージプラットフォームとセグメント化されたメッセージ処理ロジックを専用コンポーネントに組み込むことで、大量のメッセージと必要なデータ操作を確実に処理できます。

「合格メッセージ」パターンは、メッセージ処理ロジックを複数のコンポーネントに分割することで機能します。

• 1 つのコンポーネントでメッセージのルーティングを処理し、必要な変換と最終的な送信先を決定します。

• 個別のコンポーネントセットは、メッセージ変換の異なるレイヤー (項目の対応付け、オブジェクトリレーションなど) を処理します。

• 最後のコンポーネントは、最後に変更されたメッセージを書き込みます。

一部のプロデューサーは、イベントの連続ストリームを生成します。一般的な例として、メディアストリーミングがあります。メディアストリーミングには、個別のイベントとして自然に発生するユーザー操作が含まれます。コアストリーミング環境をブロックすることなく、複数のシステムで同じユーザー行動に同時に反応する必要があります。

音楽ストリーミングプラットフォームのイベントについて考えます。これには次のものが含まれます。

• 開始/一時停止/スキップされたイベントを追跡する

• タイムスタンプ付きのリスニングセッションイベント

• プレイリストの作成/変更イベント

• ソーシャル共有イベント

• オフラインリスニング用にダウンロード

ストリーミングパターンでは、登録者は各イベントストリームにアクセスし、イベントを受信した正確な順序で処理します。各メッセージストリームの一意のコピーが各登録者に送信されるため、登録者固有のコンテンツを配信し、どの登録者がどのストリームを受信するかを識別できます。

ストリームが理にかなっているためには、そのすべてのイベントと関連するメッセージが正しい順序になっている必要があります。異なるシステムからストリームでデータを取得する場合、設計プロセスの一環として追加の注文ロジックを組み込む必要があります。

キューイングの使用事例は随所に存在します。例として、次のようなものがあります。

• **低品質のインターネット接続:**モバイルデバイスを使用するチームが品質が低く、インターネットアクセスが断続的な地域で作業する必要がある Field Service 組織やその他の組織では、接続が回復すると、これらのデバイスのアプリケーションがキューに接続して関連メッセージを取得できるため、キューが役立ちます。

• **メッセージバッファリング:**メッセージの量が登録者の処理能力を超えることがあり、遅延の増加によって追加の問題が発生しない場合、キューは過剰なメッセージを保存し、データの損失を防ぐためのバッファになります。

• **輸送管理:**法人車両を監視する必要がある物流組織は、このパターンを使用して、各車両が経由するルートをほぼリアルタイムで表示し、運転者の効率を最大限に高めることができます。

• **IoT デバイス:**メーカーは多くの場合、高速データストリームを生成するシステムを使用しており、これらのストリームが追加のシステムに下流の影響を及ぼす可能性があります。このパターンは、複数のシステムにまたがる重大な障害が発生する前に、人間の介入が必要な一連のイベントを識別するために使用できます。

Queuing パターンでは、プロデューサーがキューにメッセージを送信し、登録者が取得するまでキューにメッセージが保持されます。ほとんどのメッセージキューは先入れ先出し (FIFO) 順序に従っており、取得後にすべてのメッセージが削除されます。各登録者には一意のキューがあり、追加の設定手順が必要ですが、配信を保証し、どの登録者がどのメッセージを受信したかを識別できます。

Queuing パターンの非同期の性質上、メッセージがキューに追加されてから取得されるまでに長い遅延が発生する可能性があります。キューにはメッセージを保持するためのメモリまたはストレージ容量が必要なため、無制限に拡張することはできません。つまり、無制限にオフラインになっている登録者は、キューに十分なメッセージが蓄積されると、障害が発生する可能性があります。メッセージのバッファリングは、登録者の処理時間が長くなりすぎて大量のメッセージがキューに蓄積された場合にも同じ影響を及ぼす可能性があります。これらのリスクを軽減するには、すべてのメッセージキューのストレージ要件を徹底的に分析し、必要に応じて、メッセージが設定された時間内に取得されなかった場合や、メッセージが事前に定義された量に達した場合にキューを消去および無効にするプロセスを設計します。

イベント駆動型アーキテクチャが組織に適していると完全に確信していても、すでに多数のポイントツーポイントインテグレーションがある状況から開始している場合があります。すべてのインテグレーションを一度に置き換えるプロジェクトの資金を得ることは困難な場合があります。また、一部のレガシーシステムでイベント駆動型アーキテクチャを直接使用することさえできない場合もあります。これらのシナリオでは、最もビジネスクリティカルなアプリケーションを最初に変換してから、将来のプロジェクトで更新または置き換えられたときに他のシステムを変換することで、より疎結合なアーキテクチャに段階的に移行できます。このアプローチにより、イベントバスに新しいアプリケーションを簡単に追加でき、時間の経過と共にシステムが追加されても IT ランドスケープ全体の拡張性と耐障害性を維持できます。

アーキテクトは、すべてのアーキテクチャにはトレードオフがあることを認識しています。イベント駆動型アーキテクチャも例外ではありません。疎結合のシステムでいっぱいのランドスケープは、拡張性と耐障害性に優れていますが、次のようなトレードオフも考慮する必要があります。

• **全体的な統合戦略:**使用するツールやパターンに関係なく、まず、組織内のさまざまなシステムでデータを共有する方法に関する戦略を作成することが重要です。この戦略には、データの目標、データの共有方法と使用パターン、データソース、対象、構造、所有権とアクセスの要件を含める必要があります。

• **レガシーシステムのサポート:**組織にイベント駆動型アーキテクチャパターンをサポートしていないレガシーシステムがある場合があります。回避策 (イベントに登録し、別のデータ転送手段を使用して出力をターゲットシステムに送信するパススルーとして機能するプロセスなど) を構築することは可能ですが、この場合は他のインテグレーション方法を検討することをお勧めします。

• **メッセージの構造の変更：**最初のメッセージ構造が定義され、公開者と登録者の間で合意されると、特に登録者が外部の場合、変更が困難になる可能性があります。この問題に対処する方法はいくつかあります。バージョン管理されたエンドポイントを使用できますが、開発者が同時に多くのバージョンを管理する必要がないように、各バージョンの明確なライフサイクルを定義して伝えてください。Heroku の Apache Kafka がランドスケープの一部である場合は、スキーマレジストリや同様のツールを検討することもできますが、ランドスケープ内の他のシステムでもサポートされている (および使用されている) ことを確認してください。

• **パブリッシャーと登録者間の可視性の欠如:**ほとんどのイベント駆動型アーキテクチャパターンでは、パブリッシャーは登録者の状況を認識しません。そのため、すべての登録者がオフライン中にパブリッシャーが重要なメッセージを送信すると、メッセージが配信されない場合があります。リプレイ機能を使用するか、すべての重要なメッセージに対して別々のサーバで実行される冗長なユーザを追加することで、この問題に対処できます。

• **パフォーマンスのボトルネック：**イベント駆動型アーキテクチャの拡張に伴い、イベントバスが大量の登録者に同時にメッセージを送信しようとするパブリッシャーに圧倒されると、メッセージ配信のボトルネックになる可能性があります。これに対処するには、イベントバスに割り当てられるメモリと処理リソースを増やすか、複数のイベントバスを使用して異なる種別のメッセージを並列処理します。

イベント駆動型アーキテクチャを実装する前に、そもそも本当に使用する必要があるかどうかを検討します。前のセクションでは、各イベント駆動型アーキテクチャパターンに適した一般的なビジネスシナリオについて説明します。詳細は、「適切に構築された相互運用性」も参照してください。「イベント駆動型アーキテクチャを実装するときに考慮すべき課題」を確認して、想定しているパターンが特定の使用事例に最も適しているかどうかを判断します。

このガイドで扱うシナリオの大部分はインテグレーションに関連しますが、イベント駆動型アーキテクチャでは、プラットフォームイベントなどを使用して 1 つの Salesforce 組織内でメッセージを送信することもできます。プラットフォームイベントを内部メッセージングシステムとして使用するプロセスを設計するときは、該当するイベント割り当て制限に留意してください。

多くの場合、イベント駆動型アーキテクチャのアンチパターンは、Salesforce 組織の内部コミュニケーションの回避策としてイベントを使用することに起因します。一般的なアンチパターンは次のとおりです。

• **同じイベント オブジェクトに関連付けられた Apex トリガーからのイベントのパブリッシュ：**これにより、無限トリガーループが発生します。

• **DML トランザクションが完了する前に Apex からイベントを公開する：**トランザクションが失敗してロールバックされた場合、[すぐに公開] 公開動作を持つ公開済みイベントはロールバック動作に含まれません。

• **後続の自動化を調整するためのフローでの公開イベント：**複数の自動化間でロジックを調整する最適な方法は、サブフローまたはフローオーケストレーターを使用することです。

• **実行時連動関係の作成:**実行時の連動関係を排除する適切な手順を実行せずに、パッケージ間の通信を促進するイベントを公開しないでください。

• **不必要に大きいペイロード:**要求を実行するときは、ペイロードでできるだけ少ない量のデータを送受信することをお勧めします。ユーザーのすべてのアクションで複数の要求が発生する可能性があるため、これらを効率的に処理することが重要です。必要以上に多くのデータを送信すると、転送が遅くなり、処理時間が長くなる可能性があります。

• **アプリケーションイベントの選択解除処理：**アプリケーションイベントをリスンするコンポーネントが複数ある場合、開発者はイベントハンドラーが実際に必要で役に立つ場合にのみ実行されることを確認する必要があります。たとえば、Lightning コンソールでは、フォーカスされていないタブに含まれるコンポーネントは、表示されていなくても聞くことができます。開発者は、バックグラウンドユーティリティ項目を唯一のリスナーとして使用したり、getEnclosingTabId() をコールしてコンポーネントのこのインスタンスがフォーカスされたタブ内に含まれるかどうかを判断したりして、各イベントが意図した場合にのみ処理されるようにします。

• プラットフォームイベントの公開動作を正しく使用しないプラットフォームイベントには、[すぐに公開] と [コミット後に公開] の 2 つの公開動作があります。リアルタイムプラットフォームイベントは、トランザクションが成功して確定したかどうかに関係なくログイベントを公開する必要があるログ記録などの使用事例で使用できます。ただし、リアルタイムプラットフォームイベントでは、[Publish Immediately (すぐに公開)] を慎重に使用してください。イベントは、登録者が同じトランザクション内で消費し、行ロックやその他の競合状態を引き起こす可能性があります。

イベント駆動型アーキテクチャを実装する場合、成功への鍵の 1 つはイベント自体の設計方法の標準を設定することです。詳細は組織の使用事例によって異なりますが、一般的なガイドラインを次に示します。

• **イベントペイロードの最適な構造を決定します。**メッセージサイズを小さくすると処理時間が短縮されますが、大量のメッセージを登録者に送信しようとすると、パフォーマンスのボトルネックが発生する可能性があります。適切なバランスを見つけるために、ペイロードのサイズと構造に対して反復処理が必要な場合があります。MuleSoft および同様の ESB ツールでは、イベントに関連付けられたメッセージでカスタムペイロードを設計できるため、登録者側のパフォーマンスを向上させるためにデータ構造を視覚化できます。(詳細については、「適切な設計 - API 管理」を参照してください)。

• **プロセスをエンドツーエンドで検討します。**インテグレーションがロールアウトされると追跡が困難になる可能性がある「無限ループ」シナリオを作成していないことを確認します。たとえば、レコードが更新されたときにイベントを公開し、同時に相互のイベントをリスンする 2 つのシステムで、処理時に追加の公開イベントがトリガーされます。

  この種別のアンチパターンを修正するには、消費されたイベントの結果として行われた変更によって新しいイベントが公開されないようにするロジックを両方のシステムに追加します。また、すべてのイベント、関連付けられたトリガー、および影響を受ける可能性のあるダウンストリームシステムを文書化する必要があります。このドキュメントは、無限ループや類似するシナリオをできるだけ早くキャッチするための設計セッション中の参照資料として使用します。(詳細については、「適切な設計 - プロセス設計」を参照してください)。

• **システム全体で共通の命名規則を使用します。**イベント駆動型アーキテクチャを含め、すべてのソフトウェア開発で一貫した命名規則を使用することをお勧めします。イベント名、構造、関連付けられたオブジェクト、エラー処理プロセスに関する一連の標準を文書化して、システム全体で一貫性を確保します。(詳細については、「適切に設計された設計基準」を参照してください)。