MQ設計虎の巻: 第3回「適用業務のパターン化」

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 初級

山根 雅彦, WebSphereテクニカル・セールス, IBM

2007年 09月 04日
更新 2009年 04月 09日

ご好評の記事、「MQ虎の巻」の久々の改訂版(V7対応）です。今回は第3回「適用業務のパターン化」を改訂いたしました。

1 MQの適用分野

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

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

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

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

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

これらの事例の詳細については下記URLを参照して下さい。

http://www.ibm.com/jp/solutions/casestudies/search.wss?keyword=mq

海外の事例は、下記のサイト(英語)で検索することができます。

http://www-01.ibm.com/software/success/cssdb.nsf/softwareL2VW?OpenView&Count=30&RestrictToCategory=software_WebSphereMQ&cty=en_us

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

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

まず、この章では実際の業務（受注業務を例に取っています）をMQ処理パターンに分類し、その後、各MQ処理パターンについての特徴・考慮点について解説していきます。

上に戻る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上に戻る

3 MQ処理パターンの解説

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

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

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

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

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

1 オンライン処理：一方向型
この処理の流れは以下のようになります。

1. 送信側アプリケーションは送信したいデータをMQPUTします。
2. MQPUTされたメッセージは順次チャネルによって受信側システムへと転送されます。
3. 受信側アプリケーションはメッセージをMQGETし、処理します。

「オンライン処理：一方向型」は全てのMQ処理パターンの中でも最も単純な形態です。MQPUTされたメッセージは即時に受信側システムに転送されます。つまり、キューマネージャー間のチャネルは常に稼働状態になければなりません。

業務要件によってパーシステントメッセージ（持続メッセージ）を使用するか、ノンパーシステントメッセージ（非持続メッセージ）を使用するかを選択する事になります。

また、MQのレポート機能により、転送が正常に行われたかどうかを確認する事もできます。この場合、処理形態は次の「オンライン処理：双方向型」と同じになります。

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

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

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

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

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

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

3 バッチ転送処理

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

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

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

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

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

• グループ化・セグメント化
• 文字コード変換（データが全て文字データである場合）
• 暗号化（WebSphere MQ V5.3以降）
• データ圧縮機能（WebSphere MQ V6.0以降）

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

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

4 ディレード処理

拡大図

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

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

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

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

参考文献

• developerWorks Japan: WebSphere: WebSphereの日本の技術情報サイトです
  
  
• developerWorks: WebSphere(US) : WebSphereの英語の技術情報サイトです

著者について

		山根 雅彦,日本アイ・ビー・エム株式会社

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る