[イベント駆動型アーキテクチャ] Salesforce の提供するイベント機能
前回から間があいてしまいましたが続きです。今回は、イベント駆動の実際の構成や、Salesforce で提供するイベント機能について説明します。
前回の内容はこちら。
Heroku で実現する同期と非同期のアーキテクチャ
弊社 PaaS である "Heroku" を使った、同期・非同期の構成サンプルを紹介します。
こちらの構成は、大量のアクセスを捌くための考え方としての一つの Heroku で実現するサンプル構成です。この形式が全てではなく、他の構成パターンもあります。
同期処理と非同期処理の実装方法
同期型アーキテクチャでは高速ストレージを活用して、一つ一つの処理を高速化して対処します。非同期型アーキテクチャでは、イベントバスとなる "Apache Kafka" を中心に据え「イベント」を単位として各処理へ伝達する仕組みになっています。
非同期処理のサンプルでは、フロント側がイベントの発生器となっています。Webシステムとして、例えば「カートへ入れる」「注文する」などのボタンなどが押されたコトを「イベント」として扱います。フロントのWebシステムは、エンドユーザの行動を受け付けて、後続の仕組みに対して「イベント」を発行するという代替わりをしています。処理のきっかけを「イベント」から始める非同期型アーキテクチャを「イベント駆動型アーキテクチャ」と呼びます。
イベント駆動型アーキテクチャとは
イベントとは
ここで一度「イベント」についておさらいです。
"イベント" とは…
システムまたはその環境の状態における重大な変化のこと
(a significant change in the state of a system or its environment.)
と定義されています。日本語にすると分かりにくいですね。何か操作を行うことが状態の変化だと理解してもらって問題ないです。「ボタンを押した」などは、まさにその「変化」した「状態」です。
また、イベントは次のような情報を含みます。
状況 (context)
そのイベントが生成された状況資源 (resource)
そのイベントによって、どのリソースが対象となるのか操作 (operation)
どのような操作によって、イベントが発生したのか
例えば「"しょっさん" が "2023-02-10 12:59:38(JST)" に "ECサイト" で」(context)、「"¥3,800" の "Perfume の CD" "型番 prfm-092012230215" を」(resource) 「"カートへ入れた"」(operation) というものが「イベント」です。
イベント駆動型のキモは「非同期」と「Pub/Sub」
イベント駆動型アーキテクチャでは、「非同期」こそが重要な処理アプローチとなります。中心にあるイベントバスがイベントを受け付けると、それを後続の各処理へと依頼し、各々のプロセスで非同期に処理します。
このように、フロント側が後続の処理を指定して、特定のメッセージキューへメッセージを登録して実行を依頼する仕組みを、メッセージキューイング方式と呼びます。フロント側が、実行してもらいたい処理を指定して、特定のキューへメッセージを入れる仕組みとなります。従って、実体としてはフロントがハブとなって、後続の処理を決める方法となり、フロントがビジネスプロセスを確定づけています。連携方法としては疎結合ですが、プロセスは密結合とも言えます。
ここで、"Apache Kafka" をはじめとする、多くのイベントバスでとられている方法は、より特徴的なPub/Subという方式を実装しています。Pub/Sub とはイベントを登録する側を "Publisher(出版者)" 、後続で処理を待ち受けているプロセスを "Subscriber(購読者)" と呼ぶ方式にちなんでいます(呼び方自体はメッセージキューイングでも同じだったりはするけど)。日本の一部界隈では"出版購読型"とも呼んでいます。
"Publisher" は、イベントバスへイベントを登録します。後続で処理を待ち受けている "Subscriber" たちは、イベントバスに登録されたイベントが、自分が実行すべきかどうかを判断して処理を行います。"Subscriber" は全てのイベントを購読するわけにもいかないので、"Apache Kafka" では「トピック」などでイベントの役割を分類して取捨選択します。
このようにして、"Subscriber" 側が処理を行うためのイベントを選別できる方式のため、"1対多" のようなイベントのやりとりや、データの伝送、それから新しい処理を本番稼働中でも、すぐに接続して利用可能です。
このように "Apache Kafka" は、Pub/Sub モデルを実装していることにより、連携だけではなく、ビジネスプロセスの疎結合化も実現できます。また、"Apache Kafka" は一般的なDBのような Active-Standby 型の HA(High-Availability[高可用性])構成ではなく、クラスター型でスケールアウト可能な構成を組むことが可能です。ですから、イベントバスへ負荷が集中するようなケースでも、それを見越してスケールアウトの構成を準備できます。そのため、大量のアクセス下においても負荷分散を実現して、負荷に強い、ハイパフォーマンスな構成を実現できます。
このように、非同期型というか "Apache Kafka" で構成された、イベント駆動型アーキテクチャにおいては、分散させることで処理上限を突破させられるという特徴があります。
ただ、みなさまの想像に難くない通り、非同期処理は実装が難しい構成です。非同期といえども、ほとんどの処理がリアルタイムに近い形で処理されます。とは言え、なんらかの要因で遅延することもあります。複数の処理が完結しないといけないのに、そのうちの一つの処理だけがエラーや障害で停止してしまった場合など、複雑なプロセスで実装が困難なケースも考えられます。すべてを非同期で実現することは難しく、エンドユーザ側への影響も含めて、障害時の運用なども綿密に計画が必要かもしれません。結果整合性をどの程度の期間で担保するかが、この構成のポイントです。
Salesforce の提供する二つのイベント機能
今回の最後は Salesforce プラットフォームの提供する二つのイベントバスについて紹介します。
Apache Kafka on Heroku
1つは既に紹介済みの "Apache Kafka on Heroku" です。こちらは "Heroku" のアドオンとして提供される機能です。
Heroku のアプリケーション開発における、イベント駆動アーキテクチャの中心となるシステムです。これはマネージドサービスとして提供されているので、"Apache Kafka" 自身の運用は不要です。すべて Salesforce がサービスの運用を行っています。また、クリック一つでインストール可能で、すぐに利用できると言うことがこういったマネージドサービスのメリットです。
"Apache Kafka" は、通常の Web API (REST/SOAPなど) ではなく専用のインタフェイスなので、従来の Web プログラミングとは異なります。"Apache Kafka" のための学習コストもかかるため、実装を難しくさせている要因の一つかもしれません。
プラットフォームイベント
もう一つは、Salesforce Platform 上に搭載されている "プラットフォームイベント" です。
こちらも "Apache Kafka" 同様、Pub/Sub 方式をとっている Salesforce Platform に特化したイベントバスです。Salesforce 外部からは REST API で Publish 可能で、Subscribe は CometD および gRPC が利用可能です。こちらは、よりモダンな Web API が利用できます。
また、Salesforce に特化した機能のとして、Salesforce のフローやトリガなどで利用可能なことが特徴です。
Salesforce 機能でのイベントの Publish
Salesforce 機能でのイベントの Subscribe
今回はここまでです。次回は、一つ、サンプルアーキテクチャを紹介します。
貴方がサポートしてくれると、私が幸せ。 私が幸せになると、貴方も幸せ。 新しいガジェット・ソフトウェアのレビューに、貴方の力が必要です。