3. 適用業務のパターン化

3.1 MQの適用分野

MQを使用したアプリケーションを設計していくためのポイントについて解説します。

前回まではMQの基本的な機能や特長について述べてきましたが、今回からはMQを使用したアプリケーションを設計していくためのポイントについて解説していきます。

一口にMQを使用したアプリケーションといっても適用可能な業務は多岐にわたります。例えば次のような業務処理に実際にMQは使用されています。

• • FTPで行われていたシステム間のデータ転送処理の置き換え
  • バッチ入力データの収集・蓄積
  • オンライントランザクション処理

MQを使用した具体的な事例としては次のようなものがあります。

• • オンライン受発注処理
  • ATMと勘定系システムの接続
  • インターネット チケット予約システム
  • コールセンター業務

MQは様々な業種、様々なタイプの処理に適用されています。
銀行のATMと勘定系システムとの間を接続するためにも使用されているように、MQは即応性、高スループット、高信頼性が求められる基幹業務にも数多く採用されています。

MQが提供する主な機能はデータを保持するためのキューへのアクセスをアプリケーションに提供することと、他システムに存在するキューへのデータを転送するという二点になります。
これらの機能は非常に直感的で単純な機能なのですが、ほとんど全てのタイプのアプリケーションで利用可能な機能とも言えます。
これはMQがあらゆるタイプの業務に有効な魔法のミドルウェアだと言っているわけではありません。
キューを始めとするオブジェクトのパラメーターやMQIのオプションを、処理パターンに応じて最適な値にする必要もありますし、MQだけではカバーできない機能要件はアプリケーション側で補ってやる必要も出てきます。
まず、この章では実際の業務（受注業務を例に取っています）をMQ処理パターンに分類し、その後、各MQ処理パターンについての特徴・考慮点について解説していきます。

3.2 適用業務をMQ処理パターンに分類する

この節では、下図のような業務を例に取ってMQの処理パターンにあてはめていきます。

各取引において左側はクライアントシステムであり、右側はクライアントシステムからの要求を処理するサーバーのシステムとなります。
これらクライアントのシステムとサーバーのシステムをMQで接続するという前提で話を進めていきます。ここでいうクライアントやサーバーという意味は、MQクライアント接続とは関係なく、MQIを使用しているそれぞれのサーバー上の
アプリケーションがサーバーとクライアントの関係を持っているということを意味します。

この例では「在庫照会」「受注依頼」「受注確認」「月次取引情報登録」の４つの業務について考えていきます。
それぞれの業務の特徴をまとめると下表のようになります。

	業務名	業務内容	処理内容	データ転送のタイミング	送信データ	応答	受信データ
1	在庫状況照会	画面に入力した商品の在庫状況を確認する	照会	画面入力確定毎	入力画面内容	即時要	照会結果
2	受注依頼	画面に入力した商品の受注を行う	更新	画面入力確定毎	受注データ	遅延可	受注処理結果
3	取引情報登録	顧客の取引情報をサーバーのDBに登録する	更新	顧客取引完了毎	取引データ	無	N/A
4	月次取引情報登録	クライアント側で蓄積していた日次取引情報をサーバーのDBに登録する	更新	月次バッチ処理時	月次取引データ	無	N/A

ここからMQの処理パターンに分類していく上で重要となってくるのが、「データ転送のタイミング」「処理内容」「応答」といった項目になります。
各業務毎にこれらの項目が、どのような特性を持っているかを調査することがMQ設計の第一歩とも言えます。

• データ転送のタイミング ：オンライン、ディレード、バッチ
• 処理内容 ：照会系、更新系
• 応答の必要性（例外応答は除く） ：要、不要
• 応答の即時性 ：即時（同期）、遅延可（非同期）

データ転送のタイミングというのは、クライアントシステム側からサーバーシステム側にデータを転送するタイミングです。オンラインの場合は送信データは即座に受信側システムへの転送対象になります。ディレードの場合は、受信側のシステムが稼動している場合には即座に受信側システムへの送信対象となりますが、受信側のシステムが夜間運用で停止しているような場合には一次送信側に貯めておきます。このディレード型の処理は派生処理と呼ばれることもあります。バッチ転送は文字通り、日次・月次といった具合に蓄積したデータを定期的にまとめて転送する処理を指します。

処理内容というのはサーバー側のアプリケーションがDBを更新するのか、照会するのかを指します。

応答の必要性とは、クライアント側がメッセージによって処理をサーバー側に依頼し、その結果をクライアントに戻してもらう必要性があるかどうかを指します。一般にオンライントランザクション処理では応答が必要となります。

応答の即時性とは上記項目の応答の必要性で「必要」となっている場合に、その応答がすぐに必要かどうかを指します。一般にオンライントランザクション処理では即時の応答が求められます。また、応答が戻ってくるまで端末はロックされ、１分～３分くらいで応答を返さないと端末側でタイムアウトのエラーを発生させるような設計が普通です。遅延可能なケースというのは、通常データを送信した後、端末はすぐに他の仕事に移れるようにします。処理結果は端末での処理とは非同期的にクライアントシステムに戻されており、ユーザーが任意の時間に確認をする事ができるようになっています。


この４点に着目し、各業務を表にまとめなおすと下表のようになります。各業務をMQ処理パターンに分類してあります。ここで挙げたMQ処理パターンについては次節で詳細を解説します。

応用として、照会業務で、下記のような場合は、一旦、結果（照会処理「受付」メッセージ）を返して、後で照会結果を返す場合もあります。

• サーバーシステム側の処理が重く、結果を返すまでに時間がかかる
• 端末がインターネットを介したブラウザーで、N/Wの信頼性に欠ける（この場合、照会結果の送信はMQ以外（メールなど）の方法も考えます）

この場合は、a.方式で一旦メッセージを返し、後でb.方式で転送されてきたデータを参照することとなります。

また、パッケージ・ソフト同士のデータ通信では、データ転送のタイミングがバッチの場合が多く、その場合はd.方式でお互いにデータを送信し合う設計を取ります。

3.3 MQ処理パターンの解説

この節では次のような４つのMQの代表的な処理パターンについて解説します。

• オンライン処理：一方向型
• オンライン処理：双方向型（要求/応答型）
• バッチ転送処理
• ディレード処理

前節で実業務をMQの処理パターンに分類しましたが、対応は以下のようになっています。

「在庫状況照会」「受注依頼」　 →　オンライン：双方向型
「取引情報登録」　 →　ディレード処理
「月次取引情報登録」　 →　バッチ処理

では、順番に各パターンについて解説していきます。

オンライン処理：一方向型

オンライン処理：双方向型（要求/応答型）

この処理の流れは以下のようになります。

①送信側アプリケーションは送信したいデータを要求メッセージとしてMQPUTします。また、応答メッセージを受信するためにMQGETを実行します。この間送信側アプリケーションは待ち状態になり、他の処理を行なう事はできません。
②MQPUTされた要求メッセージはチャネルによって受信側システムへと転送されます。
③受信側アプリケーションは要求メッセージをMQGETし、DBアクセス等の処理を行い、実行結果データを応答メッセージとしてMQPUTします。
④応答メッセージはチャネルによって送信側システムへと転送されます。
⑤送信側アプリケーションは応答メッセージをMQGETし、自分が要求した処理結果を得ます。

なお、応答メッセージが遅延可能な場合には①で送信側アプリケーションが実行しているMQGETは必ずしもこの時点で行なう必要はありません。

「オンライン処理：双方向型」はオンライントランザクション業務として、よく使用される処理形態ですが、最も設計時に注意を要します。
主に以下のような設計ポイントがあります。

・要求メッセージと応答メッセージを関連付ける方法
・パーシステントメッセージを使用するかどうか（一般に照会業務はノンパーシステントメッセージを使用しますが、更新業務はパーシステントメッセージを使用するケースもあります）
・DBとの２フェーズコミット処理が必要かどうか
・送信側アプリケーションのタイムアウト値を何秒に設定するか
・受信側のアプリケーションは常駐型にするか、トリガーにて起動するか。

バッチ転送処理

この処理の流れは以下のようになります。

①端末から入力されたデータや、ファイル転送等で受信したデータをMQメッセージとしてMQPUTします。このデータは受信側システムで稼動するバッチプログラムの入力データになります。バッチ転送に備えて通常チャネルは停止状態にあり、MQPUTされたメッセージは転送キューに蓄積された状態になっています。
②バッチ転送の時間になると、チャネルを開始します。この事により転送キューに溜まっていたメッセージが受信側システムに送られます。
③トリガー機能等により、バッチプログラムが起動し、キューに届いたメッセージをMQGETし、バッチ処理を開始します。

バッチ転送処理の特徴は転送するデータ量が多い事と、送信側に応答を返す必要が無い事が挙げられます。ただし、例外として、エラー情報や転送完了の通知を送信側に返すこともあります。バッチ転送では通常転送キュー等にメッセージを貯めることになるため、キューの容量が十分か注意する必要があります。また、他の業務の応答時間に影響を与えないように、オンライン業務が停止している夜間・休日等にバッチ転送を行う事が望ましいでしょう。

また、送信側に再送可能となる元のデータが保持されていない限り、一度送信側でMQPUTされたメッセージは消失する事が許されません。したがって、バッチ処理用のメッセージは通常パーシステントメッセージを使用します。ノンパーシステントメッセージを使用する場合、メッセージが間違い無くバッチプログラムに処理されたことを確認する仕組みや、システム障害等によりメッセージが消失してしまった場合にメッセージを再送する機能等をアプリケーションロジックとして開発する必要があります。

また、バッチ転送時に必要となる可能性がある機能のうち、MQが標準で備えているのは以下の機能になります。

・グループ化・セグメント化
・文字コード変換（データが全て文字データである場合）
・暗号化
・データ圧縮機能

考慮点としては以下の項目が挙げられます。

・ユーザーデータ以外にMQMDが付加されるため、データ量が１メッセージあたり324バイト（又は364バイト）増加します。このため、転送キューに蓄積するデータ量やネットワーク転送するデータ量にオーバーヘッドがかかります。
・送信側にMQクライアントを使用している場合、キューにメッセージを貯めておいてバッチ転送を行うという処理形態は採る事ができません。

ディレード処理

この処理の流れは以下のようになります。

①オンライン業務はフロントエンドのシステム内で完結させます。つまり、バックエンドシステムに対する照会・更新の完了とは関係無く、端末に応答を返します。
②フロントエンドのシステム内のDB更新処理と同じ作業単位でMQPUTを実行し、MQメッセージをバックエンドシステムに向けて送信します。これらのメッセージはオンラインでバックエンドシステムに送信されるケースもあれば、チャネルを停止することによって転送キューに蓄積しておき、後からバッチ処理的に送信するケースもあります。後者はバックエンドシステムがメンテナンス作業等で停止しているときに採られる方法です。
③バックエンドシステムは転送されてきたデータをMQGETし、DBの更新処理等を行います。

このディレード処理は派生処理とも呼ばれ、即応性が要求される処理から派生して、ベストエフォートで行わせたい処理がある場合に使用されます。日常のオンライントランザクション処理のデータを元にデータウェアハウスを構築するような例が典型的です。また、バックエンドシステムが停止している間の擬似24時間オンライン処理を実現するためにも使用されます。

この処理の場合、メッセージの消失が許されない事がほとんどであり、通常、パーシステントメッセージを使用します。