フィオラノ ソフトウェア ジャパン ブログ
    Twitter
  • Facebook
  • Google+

メッセージング再入門 (後編) — イベント駆動と非同期メッセージング —

messaging

1.3 イベント駆動によるアプリケーション

1.3.1 イベント駆動と非同期メッセージング

現実世界の業務処理では、”何らかの事象 (イベント) が発生するとそれに応じた業務処理が実行される” というケースが数多くあります。例えば、イベントには次のようなものがあります。

  • 倉庫に部品が入庫した
  • 製造ラインで不良品を検出した
  • 株価が変化した
  • 新規顧客がデータベースに登録された
  • 在庫数が閾値を超えた
  • POS 端末で特定商品の売上げを検出した

今回は、イベント駆動によるアプリケーション実行とメッセージングとの関係について考察します。

イベント駆動とは、イベントに発生によって特定の業務処理が駆動される方式を指しています。

これとは異なり、リクエスト-リプライ方式は未だ為されていない処理の実行を他者に依頼 (委譲) するもので、実行結果を依頼者 (リクエスター) が自身の元に持ってくる (プルする) 方式です。

イベント駆動では、既に発生した事象 (イベント) を検知したプログラムがイベント発生をイベントに対応した処理プログラムに通知します。イベント通知によって対応する次の処理を促す (プッシュする) 方式です。

この観点から、リクエスト-リプライをプル型、イベント ドリブンをプッシュ型の業務処理方法と呼びます。

 

また、リクエスト-リプライ方式では、処理の依頼者 (リクエスター) と依頼リクエストを処理するプログラム/アプリケーションは、密接に連携し同期 (シンクロナイズ) しながら動作します。これは、リクエスタ自身が実行してもよい処理を他のプログラムに委譲するいわゆる “サブルーチン コール (RPC)” や “リモート プロシージャ コール (RMI)” と同じコンセプトであり、リソースや処理状態ステートを共有する必要があるためです。

一方、イベント駆動方式では、イベント発生を検知しイベント通知を行うプログラムと発生しイベントに応じた処理を行うプログラムは、リソースや処理ステートを共有する必要はほとんどなく、それぞれ相手の状態に関知する必要がありません。

 

イベント駆動によるアプリケーション間の連携には、イベント通知や関連データを非同期メッセージングによって配信する方法が適してします。

イベントの発生は一般に不定期であるため、イベントを検出するアプリケーションとイベントに応じた処理を実行するアプリケーションが同期しながら稼働することは、ほぼ不可能に近いものです。無理に同期方式で行うとたいへん非効率なシステムとなってしまいます。イベント駆動方式では、イベントを検出するアプリケーションとイベントに応じた処理を実行するアプリケーションを、相手側の状態に関知しない独立したものとして稼働させたほうが効率的かつ効果的なシステムとなります。アプリケーション間の連絡には、非同期なメッセージングを用います。

ストア&フォワード メカニズムによる疎結合と非同期メッセージングの機能を持つ JMS メッセージングは、イベント駆動とたいへん親和性の高い方式です。

 

1.3.2 イベント駆動の長所

関係する他のシステムが関知できないタイミングである処理が実行されるケースや予期できないタイミングである事象が発生するケースには、イベント駆動が適しています。

リクエスト リプライ方式では、リクエスターがこのような事象の発生を検知することが非常に難しく、イベントの発生に対して即座に対応することができません。

イベント駆動では、イベントの発生時に発生場所 (アプリケーション) で即座に検知し、それを関連するアプリケーションに通知することができます。これによって、イベントの関連アプリケーションが直ちに処理を行えるようになり、リアルタイム性に優れたシステムとなります。

 

イベント駆動について、例題を基に考えてみましましょう。次の図は、在庫管理のアプリケーション連携を示しています。

イベント駆動の例
イベント駆動の例

処理ステップは、次のようになります。

  1. 倉庫に完成した製品が不定期に運送されてきます。不特定数の製品が箱の中に梱包されており、この箱の数もまた搬入ごとに異なります。
  2. 搬入された箱は直ちにベルトコンベヤーに載せられ、箱に貼り付けられている RFID (IC タグ) をスキャンすることで製品の種類とその数を判別します。スキャン データは、倉庫管理システムに送られます。
  3. 倉庫管理システムでは、製品毎の在庫数を管理しています。決められた在庫数の閾値を超えるような搬入があると、本社の ERP システムに通知します。
  4. ERP には、2 ヶ所の倉庫から在庫数オーバーの通知が届きます。ERP は、通知を受け取ると、当該製品の生産計画を変更するよう生産管理システムに通知します。
  5. 同時に、ERP はサプライ チェーン システムに対しても当該製品の部品供給量を調整するよう通知します。

 

さて、この例題における “RFID スキャナー” と “倉庫管理システム” との間をリクエスト リプライ方式で連携することを考えてみます。

リクエスト リプライで構築する場合、どちらがリクエスターになるかが問題となります。

倉庫管理システムがリクエスターになる場合

この場合、倉庫管理システムは RFID スキャナーに対して “ベルトコンベヤー上の梱包内容をスキャンしろ” というリクエストを送信します。RFID スキャナーはリクエストに応じてスキャンを試みようとしますが、ベルトコンベヤー上に箱が載っていないケースがほとんどでしょう。

製品の搬入が不定期であるため、製品の搬入タイミングと倉庫管理システムがリクエストを出すタイミングをシンクロさせることは不可能です。このため、倉庫管理システムからのリクエストが空振りに終わるケースが非常に多くなることが予想されます。

不定期に配送されてくる製品に対して倉庫管理システムの側からスキャン リクエストを出すことは、非常に非効率なものとなってしまいます。

 

RFDI スキャナーがリクエスターになる場合

このケースでは、製品が到着した時点で RFID スキャナーが梱包内容をスキャンすることができます。スキャンした後に倉庫管理システムに在庫数チェックなどの処理をリクエストします。こうすることで、倉庫管理システムがリクエスターになる場合の、不定期に届く製品のスキャン タイミングの問題は解消されます。

しかしながら、倉庫管理システムからのリプライを待っている間にもベルトコンベヤー上には次々と製品が載せられ流れてきます。倉庫管理システムからのリプライに時間がかかり過ぎたり、あるいは倉庫管理システムに障害が発生したりした場合には、ベルトコンベヤーを停止させる事態に発展してしまうかもしれません。障害復旧が長時間に及ぶ場合には、倉庫の搬入受け入れ業務が機能しなくなってしまう恐れもあります。

また、在庫数オーバーのリプライが返ってきた場合には ERP に通知する必要がありますが、この通知を RFID スキャナーが行うことはスキャナーの処理負荷としては大きすぎますし、業務処理のロジック的にもあまり良いものはありません。

このようにリクエスト リプライ方式ではうまく処理できないケースというのは、案外に多いものです。無理にリクエスト リプライ方式で処理すると、処理効率が悪く、データ発生時に即座に処理できない事態になることもあります。

多くのアナリストが、リアルタイム性を求められるアプリケーション連携ではイベント駆動が最適な方法であると表明しています。

前編の 『1.1 JMS を使用することの意味』および『1.2 ストア&フォワード メカニズムによる疎結合』 で説明した JMS の特徴は、 イベント駆動処理の基礎を提供してくれます。

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>