Messaging 1 WASV6.1による基幹システム設計Workshop

WASV6.1による基幹システム設計Workshop
Messaging
1
Agenda
„
„
„
Messaging（メッセージング）とは
WASV6.1におけるメッセージング環境
メッセージング基盤設計
‹
‹
‹
‹
„
„
メッセージング基盤の計画
接続方式,キュー配置,ネットワーク･リンクの検討
メッセージ信頼性の検討
負荷分散/可用性向上の実装
WASV6.1でのJMSプロバイダー選択のポイント
補足
‹
‹
ESB(Enterprise Service Bus)
Hints&Tips
Messaging
MQ
ME
ESB
2
はじめに、メッセージングとはどういうものなのか、その特徴・使用方法についてご説明します。その次に、
メッセージングを実装する製品であるMEとMQについて、トポロジー・信頼性・負荷分散/可用性を中心に
ご説明します。纏めとして、WASV6.1でのMQ/MEの選択指針についてご説明します。
2
Messaging（メッセージング）とは
‡ Messaging(メッセージング)とは
‡ メッセージングの利用形態
‡ メッセージ・キューイングとUOW
3
3
Messaging（メッセージング）とは (1/3)
„
メッセージングとは
‹
„
プログラム間のコミュニケーション手段の一つ
以下の2つの側面がある
‹
メッセージ・インタフェース
¾
‹
プログラム間インタフェースをメッセージ形式で規定する方法
メッセージ・キューイング⇒当資料の主題
¾
メッセージ転送に一時保管場所としてキューを利用する方法
メッセージ・インタフェース
送信者
メッセージング
・プロバイダー
送信
受信者
受信
メッセージ・
キューイング
4
このページでは、システムにおけるメッセージングの特徴について説明します。以下の文章は、一般的
なMessaging（メッセージング）の考え方、特徴についての解説です。
メッセージングとは、人同士のコミュニケーションで例えれば電子メール（郵便）に似ています。電子メー
ルでは、用件を書いて、宛先を設定し、送信ボタンをクリックすれば、送信者は次の仕事に取り掛かれま
す。一度預かったメールは、電子メールのプロバイダーが責任を持って、宛先の受信者のメール・ボックス
に配信します。受信者は自分の都合の良いときに受信メールをチェックし、内容に応じたアクションをとる
ことができます。または、新着メールが届いたタイミングでメール・ソフトがポップ･アップ画面や音で通知し
てくれます。
これが、電話のような相手と直接接続する必要がある方法(密結合)では、相手の都合に大きく左右され
ることになります。(相手が電話の前にいなかったり、多忙であったりすれば、何コールも待たされ、ついに
はあきらめることになり、何も相手に伝えられないまま処理が進みません。)
電子メールの良いところは、このように相手の都合に左右されないということ(非同期)、相手と直接接続
する必要がないこと(疎結合)にあります。反面、急ぎの用件の時には相手がすぐにメールを見るとは限ら
ないので、誰しもメールではなく直接電話するでしょう。
このように、仕事を進める上で必要なコミュニケーション手段は、目的に応じて使い分けることが重要で、
仕事の効率を上げる一つのコツであることはご理解いただけると思います。システム間、プログラム間の連
携の場合も要件に応じ連携方法を使い分けることが、処理の効率を上げ、トラブルを最小化することにつ
ながります。
(※)メッセージングという言葉を広義で解釈すると、フォーマットをメッセージ形式で規定したデータ連携手
法全般(つまり直接コネクションを張る形式も含まれる)を指しますが、当資料ではキューを介したメッセー
ジング(メッセージ・キューイング)を主題とします。
4
Messaging（メッセージング）とは (2/3)
„
メッセージングの特徴
‹
メッセージ・インタフェース
メリット
‹
デメリット
・一度決めたメッセージ・インタフェースさえ
守れば、処理内部のロジックを変更しても、
他の処理に影響を及ぼさない
・人が目で見て、理解出来る形式である
・メッセージ形式不正の場合、受信側の
フォーマット解析の際にエラーが発生する
(※) WebServiceではJAXRPC等の規定に
基づき、提供されたWSDLを公開し、使用
するので開発時に予めエラーを除去できる
‹
メッセージ・キューイング
メリット
デメリット
・転送途中でのデータ編集、型変換などの
加工がしやすいため、アプリケーション間
のインタフェース/プロトコル差を吸収する
処理を組み込みやすい
・高負荷時にキューが一時的なバッファー
となる
・相手と直接接続しないので、相手の稼動
状況が分からない
・システム的な作業単位（UOW）が
キューを境に分かれる
5
メッセージングの特徴をキーワードで示すと「非同期」、「疎結合」と表現できると思います。通常のWeb
（HTTP)が「同期」的で「密結合」であることを考えると、言わばそれぞれが対極に位置し、適用すべき範囲
が異なります。そのためシステム構築にあたって通信プロトコルを決定する際はどちらの方式がお客様要
件によりマッチするかについて、初期段階で検討することが必要です。
5
Messaging（メッセージング）とは (3/3)
„
メッセージ・キューイング製品利用価値
‹
分散環境での接続性
¾
¾
¾
‹
メッセージ加工機能
¾
‹
マルチ・プラットフォーム環境の接続、ネットワーク障害ハンドリング機能
アプリケーションは宛先、メッセージ識別のみを意識し、システム構成(マシン、ネッ
トワーク)を意識しないで済む
ネットワーク・リンクによる信頼性のあるメッセージの転送が利用できる
データが全て文字型であればコード変換もしてくれる
可用性向上/負荷分散/拡張機能
¾
¾
メッセージ信頼性レベルの選択により、適切なコストで必要なサービス・レベルを
得ることができる
負荷分散、可用性向上機能により連続稼動性、拡張性を備えた基盤を整備できる
6
メッセージング製品の利用価値について纏めました。システム要件にメッセージングが入っている場合、
どのような効果を製品レベルで実現できるか、整理する際にご参照下さい。
6
メッセージングの利用形態
„
メッセージングを利用した処理
‹
一方向型
¾
¾
‹
送信者から受信者にメッセージを送信する
ディレード処理や、センターカット処理に活用できる
要求応答型
¾
¾
送信者から受信者にメッセージを送信し、受信者から送信者にメッセージ処理結
果を送信する
オンライン処理に活用できる
一方向型
要求応答型
送信者
受信者
送信者
受信
送信
宛先
受信者
要求送信
長時間を要するような
処理を起動しておき、
後から別プロセスで
結果を取得するような、
ディレード方式やセン
ターカット方式に適用
可能
要求受信
要求宛先
応答受信
応答送信
応答宛先
短時間で結果を戻
すオンライン方式
に適用可能
7
メッセージングの利用形態は様々ですが、つきつめると、一方向型のメッセージングと、要求応答型のメッセージン
グに分類することができます。
一方向型は、サービスを呼び出しておき、後から結果を取得するようなディレード(遅延)処理や、大量件数を処理す
るセンターカット(一括)処理に活用できます。
要求応答型は、受信者(サービス)が送信者(リクエスター)に処理結果を戻すような、オンライン処理に活用できます。
ただし、メッセージ伝達の負荷を考えると、EJBやWebサービスと比較して、パフォーマンスは劣るかもしれません。パ
フォーマンスの観点からメッセージングを利用して要求応答を行うメリットを生かせるのは、送信側と受信側が並行し
て処理を行うような場合です。ただし、送信者側と受信者側のトランザクションが分離してしまうので、障害ケースのイ
ンダウト処理について、入念に検討する必要があります。
7
メッセージ・キューイングとUOW
„
メッセージ・キューイング方式ではリソース更新のUOWが分かれる
‹
メリット
‹
デメリット
リソース更新がローカルで完了するため、ロック保持時間を分割/最小化できる
¾
システムを跨ったリソース更新においてUOWを一つにはできない
⇒実現には他の分散同期処理方式を選択する必要がある
¾
要求/応答型
一方向型
分散同期処理方式
送信タスク
リソース
更新
送信
同期点取得
要求タスク
更新
要求送信
応答受信
更新
同期点取得
メッセージング・キューイング方式
受信タスク
送信タスク
受信
リソース
更新
同期点取得
リソース
......
同期点取得
メッセージング
・プロバイダー
更新
送信
同期点取得
要求タスク
更新
要求送信
同期点取得
応答タスク
要求受信
更新
応答送信
リソース
UOW
リソース
リソース
応答受信
更新
同期点取得
送信
メッセージング
・プロバイダー
受信タスク
受信
更新 リソース
同期点取得
受信
メッセージング
・プロバイダー
応答タスク
要求受信
更新
リソース
応答送信
同期点取得
......
8
メッセージング・キューイング方式を採用した業務処理では非同期処理を前提にしていますので、メッ
セージがキューに入った後いつ相手がそのメッセージを処理するかについての保証はありません。その
ため、その業務が分散トランザクション処理を含んでいる場合は、トランザクションの作業単位をメッセー
ジ・キューを跨って定義することはあまり現実的ではありません。
8
WASV6.1におけるメッセージング環境
‡
‡
‡
‡
JMS（Java Messaging Service）とは･･･
WASV6.1におけるメッセージング環境
メッセージング・プロバイダー
SIBusとメッセージング・エンジンの関係
9
9
＜参考＞JMS(Java Messaging Service)とは・・・
‹
J2EE標準のメッセージング・インターフェイス
¾
‹
JMSで実装すると、メッセージング・サービスに依存しないアプリケー
ションを構築可能
¾
¾
‹
サン・マイクロシステムズ㈱が中心になって標準化
JMSクライアント環境を提供するメッセージング・サービス＝JMSプロバイダー
JMSインターフェイスによりメッセージング・サービスを利用するアプリケーション＝
JMSクライアント
メッセージング機能はメッセージング・サービスが独自に実装
JMSプロバイダー
SIBus
JMS
Client
JMS
WMQ
他社メッセージ
ング製品
メッセージング・サービス
JMS
JMS
Client
10
JMSはJ2EE標準のメッセージング・インターフェイスです。標準のインターフェイスでコーディングすることにより、
メッセージング・サービスに依存しないアプリケーションを開発できます。JMSを利用できる環境を提供するメッセージ
ング・サービスを、JMSプロバイダーと呼びます。また、JMSインターフェイスを利用してメッセージング・サービスを利
用するアプリケーションを、JMSクライアントと呼びます。
JMSはインターフェイス定義が中心で、メッセージングの機能については触れていません。その為、メッセージング機
能の実装は、各ベンダーに任されています。
10
WASV6.1におけるメッセージング環境
WebSphere Application Server V6.1利用可能なJMSプロバイダー
„
‹
サービス統合デフォルト・メッセージング・プロバイダー(SIBus)
¾
‹
WebSphere MQ JMS プロバイダー
¾
‹
別途MQのライセンスが必要。
バージョン 5 デフォルト・プロバイダー(組み込みメッセージング)
¾
‹
WASと同一プロセス内で稼動するメッセージング・エンジンを使用。
前のリリースとの後方互換性維持のためのサポート。
汎用 JMS プロバイダー
¾
サード・パーティーのメッセージング・システムを使用するために提供。
WebSphere Cell環境
MQ
JMS
(ローカル接続/
クライアント接続)
Application
Server V6.x
Application
Application
Server V6.x
Application
JMS
JMS
MQリンク
ME
組み込みMQ
WebSphere Cell環境
ME
Application
Server V5.x
Application
JMS
JMS(ローカル接続/
クライアント接続)
3rd. party MQ
SIBusリンク
11
・サービス統合デフォルト・プロバイダー
WebSphere Application Server のサービス統合テクノロジーは、デフォルトのメッセージング・プロバイダー
を介してアクセスされるサービス統合バスを構成した際に、メッセージング・システムとして機能することが
できます。このサポートは、 WebSphere Application Server の一部としてインストールされ、管理コンソー
ルを介して管理され、 WebSphere Application Server ランタイムに完全に統合されます。
・WebSphere MQ JMS プロバイダー
WebSphere Application Server には、WebSphere MQ JMS プロバイダーのサポートも含まれます。サポー
トされている WebSphere MQ のバージョンで使用するために提供されます。
・バージョン 5 デフォルト・プロバイダー
前のリリースとの後方互換性のため、WebSphere Application Server では バージョン 5 のデフォルト・メッ
セージング・プロバイダーもサポートしています。これによって、WebSphere Application Server バージョン
5 の組み込みメッセージング・システムとともに使用するリソースを構成できます。バージョン 5 のデフォル
ト・メッセージング・プロバイダーは、サービス統合バスでも使用できます。バージョン 5 のデフォルト・メッ
セージング・プロバイダーは、バージョン 5 の組み込み WebSphere MQ プロバイダーです。バージョン 5
のリソースを引き続き使用して、組み込みメッセージングを使用する混合バージョン・セル内で、バージョン
5 のノードと通信するアプリケーションで使用できるように、設計されています。
・汎用 JMS プロバイダー
WebSphere Application Server には、汎用 JMS プロバイダーのサポートも含まれます。サード・パー
ティーのメッセージング・システムで使用するために提供されます。メッセージ駆動型 Bean を使用する場
合、メッセージング・システムは ASF ( Application Server Facilities )をサポートする必要があります。
11
メッセージング・プロバイダー
„
ME
メッセージング・エンジン：
WASに組み込まれているメッセージング・プロバイダー
‹
プログラムから通信処理を隠蔽
¾
¾
¾
¾
¾
‹
一般的にキューを介して通信を実施。アプリケーションは、キューを宛先として指
定して、メッセージング・プロバイダーにメッセージを渡す。
宛先までメッセージを届けるのは、メッセージ･プロバイダーの役割。
アプリケーションはメッセージング・プロバイダーが提供するプログラミング・イン
ターフェイス(API)を利用してメッセージを送受信。
通信ロジックを意識せず、業務ロジックだけをコーディングすることで動作。
メッセージ・フォーマットだけを守れば通信可能。
WebSphere MQのような非同期処理を実現
¾
¾
通信相手が稼動していなくても処理を継続可能。
並行処理を実現。
Messaging Engine
[Messaging Provider]
Message Producer
[JMS Client]
API
[JMS]
Destination
API
[JMS]
Message Consumer
[JMS Client]
12
一言で言うと、MEは、メッセージング・プロバイダーです。アプリケーションでメッセージングを行う為のイ
ンフラを実装しており、それを利用する為のAPIを提供しています。
一般的にメッセージングでは、FIFO（First-In First-Out）に基づいて実装されたキューを介して、メッ
セージをやりとりします。このキューのことを、宛先（Destination）と呼びます。これにより、アプリケーション
には通信ロジックを記述する必要がありません。また、送信側アプリケーションと受信側アプリケーションは、
同期を取らずに実行できるので、お互いがそれぞれの処理を継続できます。つまり、非同期処理が可能
になります。
送信アプリケーションと受信アプリケーションでは、やりとりを行う宛先と、メッセージのフォーマットさえ分
かれば、通信が可能です。
12
SIBusとメッセージング・エンジンの関係（1/3）
„
ESB概要（参考）
‹
‹
ESBは、分散システムを構築するためのアプローチであるSOAの通信基盤
IBMのBusiness Integration Reference Architectureでは、各種サービスを
緩やかに連携するための仲介及び通信を行うレイヤーに位置づけられてい
る
¾
サービス間の連携に必要な作業を代わりに行うことで疎結合を実現する
13
SIBusとメッセージング・エンジンの関係を説明する前に、SIBusとSIBusが目指すESBという概念を紹介致します。
ESBは各種サービスを疎結合するための仲介及び通信を行うレイヤーに位置づけられています。同期・非同期通信、
複数のプロトコルをサポートする通信経路です。
各種サービスが抽象的なインターフェースを持つことで、そのサービスの実装や稼動するプラットフォームを意識せず
利用することができます。これはSOAがめざす組み合わせによるシステムの構築への大きな前進と言えます。しかしこ
のままでサービスを連携するにはいくつか考慮点があります。
•まずサービス連携に当たって、連携相手のネットワーク上のロケーションなどの情報が必要です。例えばWebサービ
スの場合、サービス・リクエスターの中でサービス・プロバイダを表すWSDLのロケーションを記述する必要があります。
•またサービス・リクエスターがサービス・プロバイダを呼び出すには、双方が同じトランスポート・プロトコルを使用する
必要があります。
•さらにリクエスターの要求によって、別のサービスへルーティングしたい場合、サービス・リクエスターの中でそのルー
ティングの制御ロジックを記述する必要があります。
上記のように個々のサービスが明確に定義されているインターフェースを持っていても、連携する際、通信レベルで
お互いに依存することになります。ESBの役割は、上記のようなサービス間の連携に必要な作業を個々のサービスの
代わりに行なうことで、サービス間の通信レベルでの依存をできるだけ取り除き、疎結合を実現することです。
13
SIBusとメッセージング・エンジンの関係（2/3）
„
SIBus機能一覧（参考）
‹
‹
‹
‹
‹
メッセージング機能
JMSプロバイダー機能
高可用性機能
負荷分散機能
外部バスとの接続機能
¾
¾
‹
メディエーション機能
¾
¾
‹
SIBusリンク
MQリンク
メッセージ・フォーマット変換
ルーティング
SIBWS機能
¾
セキュリティー機能
14
SIBusは、ESBを実装したもので、以下のような機能を提供します。
・メッセージング機能
SIBusでは、メッセージング・サービスを実装することで、疎結合を実現しています。
・JMSプロバイダー機能
SIBusをJMSプロバイダーとして利用する機能できます。
・高可用性
HAマネージャーと連携して、SIBusのメッセージング・サービスの実体として扱われるメッセージング・エンジ
ン(以下ME)の可用性を高めることができます。
・負荷分散機能
メッセージを送信する際に、複数のキューに振り分けることで、負荷を分散することができます。
・外部バスとの接続機能
前のリリースの組み込みメッセージングでは、MQとチャネル接続できない、といった制約がありました。
SIBusではMQとのチャネル接続が可能です。
・メディエーション機能(Mediation)
メッセージのフォーマット変換や、ルーティングを行うことができます。メディエーションを利用すると、サービ
スの変更を最小限にとどめたり、サービスの繋ぎ替えが可能になります。
・SIBWS機能
WASに標準で付属のSIBus Web Service enablementを導入することで、WebサービスもSIBusに統合で
きます。この機能をSIBWSと呼びます。
14
SIBusとメッセージング・エンジンの関係（3/3）
„
ME
SIBusにおけるメッセージング機能はMEが提供
‹
MEをメッセージング・プロバイダーとして利用する為には、以下の手順でSIBusを構成
2.
バス（Bus）を定義します。
バス・メンバー（Bus Member）としてアプリケーション・サーバー（AS）もしくはクラスターを登録。
3.
バス・メンバーを指定して、宛先（Destination）を作成。
1.
ASをバス・メンバーとして登録すると、サーバー内に1つのMEが作成される。
クラスターをバス・メンバーとして登録すると、高可用性機能やワークロード共用を利用可能な、MEクラスターが作成可能。
-
バス・メンバーとして指定されたASのME内に、メッセージ・ポイント（キュー or トピック）が作成。
-
‹
アプリケーションは次のようにメッセージング機能を利用する
1.
バス名を指定して接続。
2.
宛先に対してメッセージを送信/受信。
バスによって抽象化されているが、実際にはメッセージング・エンジン（ME：Messaging Engine）に対して接続します。
-
宛先によって抽象化してメッセージを送信/受信するが、実際にはメッセージ・ポイント（MP：Message Point）にメッセージ
が届く。
-
Bus Member
Destination
Destination
Application Server
Messaging Engine
Message Point
Bus
Bus Member
Destination
Destination
Application Server Cluster
Clustered Messaging Engine
Message Point
Message Point
Message Point
15
正確には、SIBusがメッセージング・プロバイダーです。SIBusとMEは密接なかかわりがあります。SIBusは
仮想的なメッセージング・プロバイダーで、実際にメッセージング機能をつかさどっているのがMEです。ア
プリケーションは、SIBusのインスタンスであるバスに接続し、宛先を介してメッセージのやり取りを行います。
ただし実際には、アプリケーションはMEに接続して、メッセージ・ポイントを介してメッセージのやり取りを
行っています。
メッセージング・プロバイダーを利用するために、WAS管理者はバスを作成し、バス・メンバーを登録して、
そのバス・メンバー上に宛先を作成します。これにより、バス・メンバーとして登録したサーバー/クラスター
にはMEが生成され、宛先に関連付けられたバス・メンバーのMEにはメッセージ・ポイントが生成されます。
サーバーとMEは、同一プロセス内で動作します。
WAS管理者は抽象化されたバスや宛先だけでなく、実体であるMEやメッセージ・ポイントを意識しなくて
はなりませんが、アプリケーションを開発する上では、バスに接続し宛先にメッセージを送信する、という考
え方に基づいてコーディングできます。
15
＜参考＞宛先の種類
„
ME
メッセージング・エンジンでは2種類のメッセージ・ポイントが
利用可能です
‹
キュー・ポイント（QP：Queue Point）
¾
¾
¾
‹
バスにキュー宛先を作成すると、MEにキュー・ポイントが生成されます。
1つのメッセージを、1つの受信者が受信します。（PTP：Point To Point）
First In First Out（FIFO）の概念に基づいて、通信を仲介します。
トピック・スペース（Topic：Topic Space）
¾
¾
バスにトピック宛先を作成すると、MEにトピック・スペースが生成されます。
1つのメッセージを、複数の受信者が受信します。（Pub/Sub：Publish/Subscribe）
Producer
Queue Point
Sender
Consumer
Receiver
Subscriber
Topic Space
Publisher
Subscriber
Subscriber
16
バスの宛先には、PTPでやり取りを行う為のキュー宛先と、Pub/Subを行う為のトピック宛先が利用でき
ます。
キュー宛先を作成すると、宛先に関連付けられたバス・メンバーのMEにキュー・ポイントが生成されます。
PTPの場合、メッセージを送る側を送信者（Sender）、メッセージを受け取る側を受信者（Receiver）と呼
びます。
トピック宛先を作成すると、宛先に関連付けられたバス・メンバーのMEにトピック・スペースが生成されま
す。
Pub/Subの場合、メッセージを送る側をパブリッシャー（Publisher）、メッセージを受け取る側をサブスクラ
イバー（Subscriber）と呼びます。
キュー・ポイントやトピック・スペースなど、宛先の実体にあたるオブジェクトを、MEではメッセージ・ポイント
と呼びます。
16
＜参考＞メディエーション
„
ME
メディエーションとは
‹
宛先に関連付けて、メッセージのルーティング・パスの変更や、データ・フォー
マットの変換を行う機能
¾
¾
1.
2.
3.
4.
メディエーション開発のためのAPIを使用してコーディングする
ビジネスロジックから制御ロジックを分離することが可能になる
アプリケーションが送信したメッセージをMEが受け取ると、メッセージをメディエーション・ポ
イントに格納。
メディエーション・ポイントにメッセージが格納されると、そのメッセージはメディエーションとし
て登録した、メディエーション・ハンドラー・リストに受け渡される。
メディエーション・ハンドラー・リストに指定されている全てのメディエーション・ハンドラーが処
理を完了すると、メッセージはメッセージ・ポイントに格納される。
アプリケーションがメッセージを受信する時は、メッセージ・ポイントからメッセージを取得。
メディエーション・
ハンドラー
メディエーション・
ハンドラー・リスト
メディエーション内のロジックは
ユーザーが開発
メディエーション
3
送信アプリケーション
6
5
4
メディエーション・
ポイント
受信アプリケーション
2
キュー・
ポイント
1
メッセージ・
ポイント
17
メディエーションは、宛先に関連付けることで、その宛先に届いたメッセージのルーティング・パスを変更
したり、メッセージの中身を操作する機能です。
メディエーションが関連付けられた宛先にメッセージを送信すると、メディエーション・ポイントにメッセー
ジが格納されます。通常の受信アプリケーションは、メディエーション・ポイントにあるメッセージは取得でき
ません。メディエーションのみが取得できます。メディエーションに関連付けられたメディエーション・ハンド
ラー・リストが呼び出され、メディエーション・ハンドラーが一つずつ呼び出されます。全ての処理が成功す
ると、メッセージはメッセージ・ポイントに格納されます。ここではじめて、受信アプリケーションがメッセージ
を取得できます。
InfoCenter - 「メッセージ・ヘッダーの使用」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.nd.do
c/tasks/tjy1502.html
InfoCenter - 「メッセージ・ペイロードの使用」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.nd.do
c/tasks/tjy1501.html
17
メッセージング基盤設計
メッセージング基盤の計画
‡
‡
‡
‡
‡
‡
‡
メッセージング基盤の計画
適用業務の分類基準
適用業務パターン
一方向型適用業務の設計/実装のポイント
メッセージ処理順序のFIFO保証に必要な構成/運用
エラー退避キューの検討
要求/応答適用業務の設計/実装のポイント
18
18
メッセージング基盤の計画 (1/4)
„
業務要件の定義
‹
アプリケーション・プロファイルの把握
¾
‹
メッセージ・フローのパターン
¾
¾
¾
¾
‹
‹
‹
既存/新規、種類、数、稼動環境
一方向
要求/応答
Publish/Subscribe
ルーティング(1:1/1:N/N:M/アグリゲーション)
データ変換機能の要否
メッセージ処理順序の保証が必要な単位
メッセージのリカバリー機能、手順
¾
リソース更新との整合性
z
z
¾
¾
‹
UOW範囲/2フェーズ・コミット要否
リスタート・ポイントの保持要否
不正メッセージの検知/修正方法
システム障害発生時に必要なリカバリー機能
19
問題判別に必要な資料取得機能
このページではメッセージング方式によるシステム構築を行う際に、定義すべき業務要件について解説
します。
メッセージ・フローは、対象とする業務により様々で、通常、外部設計局面（または内部設計局面）になら
ないとメッセージ・フローの詳細は確定しません。基盤として整備する必要がありそうなメッセージ・フロー
をパターンとして定義することが、要件定義の第一歩となります。
大方のケースでは、突き詰めると一方向、または要求/応答のいずれかにパターン化することができます。
19
メッセージング基盤の計画 (2/4)
„
システム要件の定義
‹
‹
‹
開発言語、ツール
基盤共通APIの仕様
メッセージ属性
¾
‹
‹
‹
‹
‹
‹
信頼性、ヘッダー設定値、コード変換
稼動サーバー構成
接続ネットワーク構成
冗長構成(可用性向上/負荷分散)の要否
メッセージング・プロバイダー⇔アプリケーション間の接続構成
キュー配置、ネットワーク・リンク構成（→後述）
メディアの容量、配置、冗長構成（→後述）
¾
¾
MQ=キュー・ファイル、ログ・ファイル
ME=データ・ストア、ファイル・ストア
20
このページではメッセージング方式によるシステム構築を行う際に、定義すべきシステム要件について
解説します。
20
メッセージング基盤の計画 (3/4)
„
性能要件の定義
‹
‹
‹
‹
レスポンス・タイム
スループット
1UOWあたりのメッセージ処理数
性能評価のために取得する統計値
¾
„
製品側統計/各処理タイム・スタンプ
可用性要件の定義
‹
‹
計画停止頻度/サービス停止許容時間
最大障害回復時間
21
このページではメッセージング方式によるシステム構築を行う際に、定義すべき性能要件と可用性要件
について解説します。
21
メッセージング基盤の計画 (4/4)
„
運用要件の定義
‹
‹
‹
起動⇒業務開局手順
想定障害項目/障害検知/回復手順
監視項目
¾
¾
¾
‹
ハウス・キーピング
¾
¾
‹
‹
‹
‹
‹
„
キュー滞留状況
チャネル稼動状況
製品のエラー・メッセージ
滞留メッセージのクリア
バックアップ取得→不要ログの削除
業務閉局⇒停止手順
縮退/切戻し手順
システム拡張手順
PTF適用手順
バッチ化/自動化項目
その他：セキュリティ
¾
¾
¾
¾
ユーザー/グループ認証
各種権限設定必要資源/認可の単位
キュー上のメッセージ暗号化要否
ネットワーク上のデータ暗号化要否
22
このページではメッセージング方式によるシステム構築を行う際に、定義すべき運用要件について解説
します。
22
適用業務の分類基準
„
応答の必要性
‹
‹
„
要求側への応答送信を必要とするかどうか
応答データの待ち受けの間、要求側の操作/リソースをロックするかどうか
データ・フロー
‹
‹
応答不要⇒一方向型
応答要⇒要求/応答型
¾
¾
„
処理の即時性
‹
単位処理あたりの開始から完了までに許容される時間
¾
„
複数データ間の処理順序を遵守する必要があるかどうか
¾
遵守不要、FIFO(First In First Out)
受信業務
受信
処理
受信
処理
….
リソース
データ入力元のリソース
¾
DB/ファイル/エンド・ユーザー/プログラム
要求業務
処理
要求送信
リソース更新有無
‹
„
リソース
送信業務
処理
送信
処理
送信
….
データの入力元
‹
„
即時=数秒～数十秒/ディレード(遅延)=数分～数時間/バッチ：半日以上
処理順序
‹
„
同期待：応答データを同期的に待受ける
非同期取得：要求側の都合の良いときに、非同期に取得する
‹
要求受信
処理
応答送信
リソース(DB/ファイルなど)の更新があるかどうか
同期点取得範囲
作業単位(UOW)を合わせる必要がある範囲
応答業務
リソース
応答受信
処理
......
......
リソース
23
システムの設計・実装・保守を行なう上でシステムを通信基盤の観点から業務を見たときのポイントを
チャートに示します。ここに示した分類基準に基づいてシステムを考えていくことで、該当業務が使用する
通信基盤部分に求められる各種要件を押さえることができます。
23
＜参考＞適用業務パターン
„
前述の分類基準による適用業務パターン
分類基準
パターン名
データ・フロー
応答
即時性
処理順序
入力リソース
リソース更新有無
/同期点取得範囲
一方向型
不要
数分
遵守不要
エンド・ユーザー
リソース更新なし
ブロード･キャスト
不要
数秒～数時 要件に依存 エンド・ユーザー
間
/プログラム
要件に依存
パブリッシュ・
サブスクライブ
不要
数時間
DB/ファイル
ローカル・リソース更新
⇔データ送受信
バッチ転送
不要
数分～数時 DBレコード
間
順
DB
DB更新⇔データ送受信
DBレプリケーション
不要
数分
DB/ファイル
ローカル・リソース更新
⇔データ送受信
オンライン転送
不要
数～数十秒 入力受付順 プログラム
更新なし
イベント連動
同期待
数～数十秒 DB更新完
了順
ローカル・リソース更新
⇔
リモート・リソース更新
オンライン取引
同期待
数～数十秒 入力受付順 エンド・ユーザー
リソース更新なし
オンライン照会
業務処理⇔データ送受
信
非同期応答
要求/応答型
リソースの
レコード順
リソースの
レコード順
エンド・ユーザー
非同期取 数十秒～数 入力受付順 DB/ファイル
得
分
24
前ページでご紹介した観点で業務の特長を見ていくと、業務で使用する通信形態を様々なパターンとし
て分類することができます。それを纏めたのがこのページのチャートです。
データの流れが一方向型か双方向（要求と応答が一対になっているか）で大別できます。それを踏まえ、
応答に対する時間スパンや同期点の調整などが主な分類ポイントになります。
次のページから、一方向/双方向の区分けで見た場合の設計時、および実装時のポイントを示して行き
ます。
24
一方向型適用型業務の設計/実装のポイント
‹
送信者→受信者間にデータを一時保管する場所を確保する
‹
処理順序の遵守が必要である単位を業務要件として決定する
‹
送信者→受信者への確実なデータ転送基盤を整備する
¾
¾
¾
メッセージ・キューイング方式を利用
リソース単位(テーブル/ファイル単位など)/タイミング（静止点間など）
転送経路でのデータ・ロスト/逆転/重複を防ぐための構成/運用が必要
z
z
z
‹
受信者がデータ到着を待つ受身の状態にあるときの動作
¾
¾
受信待受け常駐タスクが必ず必要になる
受信業務への連動方法の選択
z
z
z
‹
運用により受信業務を起動(開局から常駐/タイマー起動/ジョブ・ネット起動)
MQの場合：トリガリング/MDB(WAS ListenerPort機能で実装⇒最大起動リトライ回数設定可能)
MEの場合：MDB(WAS J2C Activation Specificationの実装⇒最大起動リトライ回数設定不可)
処理開始～処理終了までのタイマー
¾
‹
構成：処理順序を遵守したい単位でコンポーネントを単一とする
9 送信キュー⇒ネットワーク・リンク⇒受信キュー(排他使用属性=YES)
メッセージング・プロバイダーのエラー退避キューは設けない
運用：送受信処理を逐次化(一時点で稼動する送信タスク、受信タスクを単一化)する
9 ME/MQ共通：単純リトライでは未確定メッセージの抜けが生じる可能性がある
⇒実装/運用の工夫で逐次化を行う
9 MQ/zキュー共用の場合：ConnTagオプション+単純起動リトライにより逐次化保証が可能
通常タイマーを業務として持たないため、処理状況/時限監視、障害検知/再処理は運用で
行う必要がある
処理結果の確認と業務の役割
¾
¾
25
業務的な静止点の取得（送信側で取得し、受信側へ通知/取得）
送受信者双方のリソースの精査/検算を行う(データ送受信数、データ項目の積算値など)
メッセージングという観点に限定した上で、一方向型メッセージを実現する際のポイントを纏めてみまし
た。
一方向型を採用した場合、業務はデータの伝達を通信基盤に委譲することになりますので、通信基盤
側で相手に確実にデータを送付するための仕組みを実現することになります。この要件はWebSphere
MQやWASのMessaging Engineに代表されるメッセージングの通信基盤ソリューションが得意としている部
分です。
業務によりますが、メッセージの伝達順序をどの程度まで基盤で保証すべきかを検討します。すべての
段階において順序を保証する必要は必ずしもなく、何らかの単位で分割が可能な場合が多いです。この
検討項目は障害時のリカバリーを考える上でリトライのポイントを決定する意味でも重要です。
一般に順序の保証を高めていこうとすると、ひとつのコンポーネント、単一伝達経路で実装する部分の
度合いが高くなりますので実行の並列度は下がります。
25
＜参考＞メッセージ処理順序のFIFO保証に必要な構成/運用
業務実装
・プライオリティ/メッセージ信頼性レベルを同一にする
・ConnTagの組み込み(MQ/zキュー共用環境)
・送受信双方のリソース整合性検査
・ポイズン・メッセージ発生通知/修正/再入力
・多重障害発生時のリカバリー方法
送信タスク
リソース
メッセージング
・プロバイダー
更新
送信
送信
リンク
ログ/キュー/リソース
送信タスク
リソース
更新
送信
メッセージング
・プロバイダー
送信
リンク
基盤の構成
・単一経路(キュー/ネットワーク・リンク構成)
・エラー退避キュー=なし
・受信キュー排他使用オプション=YES
・TPモニターで同期点処理が終わるまでは再始動を許可しない設定とする
・代替系の構成(ネットワーク/筐体/OS/ミドルウェア)
・メディアの冗長化
メッセージング
・プロバイダー
受信タスク
稼動系
受信
リンク
受信
更新
リソース
ログ/キュー/リソース
メッセージング
・プロバイダー
受信タスク
受信
リンク
代替系
受信
更新
リソース
運用項目
・送受信タスク稼動の逐次化
・コンポーネント稼動状況の監視/障害検知
- 各キューの滞留状況の監視
- リンク稼動状況の監視
・代替系への切り替え/再始動
・処理状況進捗/時限の管理
・ポイズン・メッセージ発生の検知
26
このチャートでは前のページでご紹介したポイントを図として表現しました。
26
エラー退避キュー採否の検討
„
エラー退避キューとは
‹
メッセージ不正でエラーが発生した場合、該当メッセージを退避するためのキュー
‹
機能/動作はメッセージング・プロバイダーの実装に依存
¾
„
エラー退避キューのメッセージ退避原因
‹
メッセージング・プロバイダーのコンポーネントが送信宛先のキューに送信できない
¾
¾
¾
‹
キューの定義不正/FULL/送信抑制
コード変換失敗
ヘッダーのフォーマット/内容不正
メッセージ内容不正により受信アプリケーション処理でエラーが繰り返し発生
¾
¾
¾
¾
„
後続のメッセージ処理を継続するため
データ・フォーマット不正
データ型不正
データ値不正
更新先リソースの永続的なエラー
考慮点
‹
‹
エラー退避キューを設けると、メッセージの抜けが発生する
処理順序の遵守が必須である業務では設定禁止
¾
以下の運用手順でリカバリーする
z 不正なメッセージ発生の検知
z 送信抑制/受信タスク停止
z 滞留メッセージを取得、ファイルへ書出し
z 問題判別
z 修正 （製品ヘッダー不正⇒基盤により修正、データ不正⇒業務により修正）
27
z ファイルからキューへ再入力
不正なメッセージにより後続のメッセージ処理が継続できなくなった場合、該当するメッセージを別の
キューに退避させます。この方法をとった場合、退避させた（抜けてしまった）メッセージをどのようにリカバ
リーしていくか、その対策を運用で実施する必要があります。
基本パターンは不正となったメッセージを何らかの形で通知して、誰かが修正し、再度送信し直すことに
なりますので、この三つの作業をどのように行なうかデザインします。
27
＜参考＞エラー退避キューの実装
„
ME
MEでの実装
‹
例外宛先
¾
¾
‹
„
MQ
ME単位にデフォルトで自動作成される
z
SIBusリンク、MQリンクなどのMEシステム・タスクが退避先として使用する
キュー宛先ごとの例外宛先も作成可能
z
JMSX.DeliveryCount値が最大デリバリー失敗数を超えた場合、自動で例外宛先に退避
エラー理由などの情報は付加されない
MQでの実装
‹
デッド･レター･キュー
¾
‹
キュー・マネージャー単位にユーザーが作成/指定
z
DEFINE QLOCAL(dlqname)
z
ALTER QMGR DEADQ(dlqname)
バックアウト・キュー
¾
¾
ローカル・キュー単位にユーザーが作成/指定
z
DEFINE QLOCAL(boqname)
z
ALTER QLOCAL(qname) BOQNAME(boqname) BOTHRESH(integer)
ユーザーのエラー処理として、MQMD.BackoutCounがキュー属性BOTHRESH値を超えた場合に、
BOQNAMEで指定したキューにメッセージを退避
‹
MQDLHにエラー理由などの情報が付加される
‹
デッド･レター・ハンドラーによるデッド･レター･メッセージの監視と対応(送信リトライ、フォワード、クリ
アなど)が可能
28
¾
デッド･レター・ハンドラーはMQに付属
¾
¾
エラー・メッセージのMQMDも保存される
MQ運用管理製品でも同様の機能が提供されている
MEとMQでエラー退避キューの実装にどのような相違点があるかを纏めてみました。
MEの場合はメッセージがエラー退避キューに送信された場合になぜそのメッセージが退避キューに流
れてきたのかについての情報が付加されません。それに対してMQで実装する場合はデッド・レター・
キューに渡ったタイミングでそれらの情報が付加され、それらを解析するツールも用意されています。この
点は適用業務に対してどちらの基盤(MQ/ME)を選択するかを考える上でのポイントになります。
28
＜参考＞デッド･レター･ヘッダー(MQDLH)
MQ
29
このページは、デッド･レター・ヘッダーとして付加される情報になります。
29
＜考慮点＞ポイズン・メッセージのバックアウト
„
ME上のキュー宛先をリッスンするMDBで、処理をロールバックした際の動き
‹
‹
„
ME
「最大デリバリー失敗数」に達するまで、メッセージの受信 → ロールバックを繰り返す
「最大デリバリー失敗数」に達すると、「例外宛先」にメッセージを退避
メッセージ退避ができない場合の考慮点
‹
‹
‹
メッセージ処理順序のFIFOを守りたい場合 ⇒例外宛先は「なし」に設定
例外宛先がFULLになった場合
⇒例外宛先は「なし」と同じ動作
ポイズン・メッセージが発生した場合
⇒MDB起動⇔Rollback処理のループに陥る(CPUオーバー・ヘッドも大きい)
理由：MEはJCA(Java Connector Architecture)の仕様実装、JCAは起動試行最大数の規定が
ない
¾ 対策：アプリケーション・ハンドリングや運用による回避が必要
※MQをJMSプロバイダーとして選択した場合は、リスナー・ポートの最大試行回数の指定により
MDB起動回数を制限させること可能(エラー・メッセージも出力されるので監視可能)
¾
①
MDBアプリケーション
receive
public void onMessage( ){
例外発生!
繰り返し
ejbctx.setRollbackOnly();
}
②
rollback
30
例外宛先
③
例外宛先へ退避
メッセージの内容やフォーマットが不正などの理由で、何度処理を繰り返してもエラーになってしまい、
バックアウト処理がループしてしまう場合があります。このようなメッセージをポイズン・メッセージと呼びま
す。バックアウト処理のループにより後続メッセージの処理が止まることを避けるために、MDBはポイズン・
メッセージを別のキュー（例外宛先）に退避させる仕組みを提供します。
メッセージの退避を行うには、宛先の「最大デリバリー失敗数」と「例外宛先」プロパティーを指定します。
・MDB内でメッセージのロールバックが行われると、メッセージの「再デリバリー回数」が１つインクリメントさ
れます。
・ロールバックの回数が宛先の「最大デリバリー失敗数」に達すると、メッセージを「例外宛先」に指定した
キューに退避します。
例外宛先は、SIBus全体で同じ宛先を例外宛先として使用することも可能ですし（「システム」 を指定）、
宛先ごとに固有の例外宛先を指定する(「指定」)ことも可能です。
例外宛先に何らかの理由でメッセージの送信が失敗した場合、あるいはメッセージの順序性を保つ等
の理由で例外宛先を指定しない（「なし」に指定）場合には、MDBはループに陥ります。この場合、CPUな
どのリソースを大量に消費するほか、WASのスレッド・ハング検知機能でも検知することができません。
現状ではアプリケーション・ロジックと運用で回避する必要があります。
30
＜参考＞一方向型業務の設計/実装のポイント (1/2)
パターン名
処理概要/適用業務例
ブロード･
キャスト
z参考情報を予め登録された zリソース更新は伴わない．
関係者に送信する
z業務例
・業務連絡一般
・広告/宣伝
特徴
z宛先へのメッセージ配信保証の
要否は要件に依存．
9権限を持った管理者により、配布リストを管理す
る．
9メッセージ配信保証要件により、メッセージ信頼
性レベルを設定する．
9ブローカー機能はメッセージング製品提供機能を
り送信宛先を選別する制御が必 利用可能．(ME,MQ,WMBで標準提供)
要．
9Pub/Sub方式が適切であるかどうかの見極めが
(ブローカー機能)
重要．
zバブリッシュされた情報は配信
・Pub/Sub向きの業務
ソースとなるので、データ・ロストは
⇒送信宛先が受信者の都合により
許されない．
動的に変わる業務
zサブスクライバーへの配信メッ
(受信者が主体的にサブスクライブ
セージの蓄積/配信保証の要否は
を登録/削除することが基本)
要件に依存．
・Pub/Subに向かない業務
⇒送信宛先の変更がほとんどない業務
9メッセージの抜け/逆転は送信側が振るタイム・
スタンプをもとに受信側で制御する．
パブリッ
シュ・
サブスクラ
イブ
z情報発信者(パブリッシャー) zカテゴリ/キーワード/基準値によ
バッチ転送
z静的なリソース(DB/ファイ
は発信する情報にカテゴリ/
キーワード/基準値を設定し、
送信する．予め登録を行って
いる情報要求者(サブスクラ
イバー)に配信する．
z業務例
・メルマガ配信
・製品/技術情報配信
・特定業務情報配信
・異常値通報
設計/実装のポイント
z単位あたりのデータ量が大量に 9単位あたりのデータ量により、メッセージの分割
ル)のデータを転送する処理． なる場合がある．
を検討する．
z入力リソースのレコード順を遵守 9メッセージ処理順序の保証が必要．
する必要がある．
z業務例
z入力元データがあるので最悪の
・ファイル転送
場合、再送も可能．
・リモート定期帳票印刷
31
前述のパターン分類から一方向型の業務パターンを抽出して、それらの特徴と設計時、および実装時
のポイントを2ページに渡って纏めてみました。
一方向型のパターンでも考慮すべき点は少なくないことがわかると思います。
31
＜参考＞一方向型業務の設計/実装のポイント (2/2)
パターン名
適用業務例
特徴
設計/実装のポイント
DBレプリケー zマスターDBから利用者/グ z各拠点にDBを分散させる 9マスターDBから抽出/加工したデータはキューにメッ
ション
ループ別に必要な情報を抽 ことにより、マスターDBへの セージとして蓄積する．
出/加工して送信し、受信側 アクセス集中回避、照会レ 9メッセージ信頼性はパーシステントが基本．
でレプリカDBを作成する処 スポンスの向上を図る．
(障害時のリカバリー手順を簡易化するため)
理．
9各拠点サーバーの定時起動タスクにより、センターへ
z入力リソースがあるので再 の接続、メッセージを受信し、レプリカを更新する
送は可能．
z業務例
9データ量を削減するため、差分情報を送信とする
・顧客マスター配信
9受信側の多重障害による回復不能時に備え、全件コ
・製品情報配信
ピー機能も用意する
オンライン転
送
z基幹系取引情報を他シス
イベント連動
zイベント・ドリブンで次工程
テムに転送する処理．業務
の迅速化、経営戦略への反
映を図る．
z業務例
・即時DBレプリケーション
・データ・ウェア・ハウス
z可用性/連続稼動/レスポ
ンス・タイム(情報鮮度)の要
件が厳しい．
z取引量にピーク性がある．
z送受信双方のリソース更
新の整合性を保証する必要
がある．
9可用性向上のため全てのコンポーネントを代替系に
切り替えられる構成とすることが理想．
9メッセージ処理順序の保証が必要．
9リソースの整合性確認のために、業務により静止点
を取得し、検算を行う必要がある．
9障害回復までの時間と処理の追いつきに必要な時
間の関係を負荷テストで把握しておく．
9ログ・ファイル/バック･アップが配置されているメディ
アの多重障害に備え、業務/運用によるリカバリー方法
を準備しておく．
z宛先へのメッセージ配信保 9次工程に渡すデータが大量の場合は、別メディアに
の処理を起動/連動する処 証の要否は要件に依存．
保管し参照情報のみを送る.
理．
z工程終了の時限がある.
9運用によるタイマーの保持、進捗監視が必要．
z業務例
・運用イベントの通知
32
・他業務へのプロセス連動
32
要求/応答型適用業務の設計/実装のポイント
‹
要求データ/応答データの紐付け/宛先管理が必要となる
¾
¾
‹
要求側の応答データ待ち受け時の動作
¾
¾
‹
¾
照会のみ(リソース更新なし)場合⇒単純リトライ
リソース更新を伴う場合
z 接続再開後、要求側から処理状況を問い合わせ、結果によって必要なリカバリーを行う
9 処理済の場合⇒次の取引を開始する
9 処理未済の場合⇒同一取引の処理要求を再送
可用性向上/負荷分散のためのシステム基盤の構成
¾
‹
タイム・アウト時間内に応答データが要求側に届かなれば取引が完了しない
⇒レスポンス・タイム重視の設計
リソース更新を伴う場合
z 要求側は応答を受信するまで処理状況不明(In-doubt)の状態
要求側の応答データ待ち受けがタイム・アウトした場合のリカバリー
¾
‹
データ識別ID、応答識別IDの利用/持ち回り
応答返信宛先の持ち回り
コンポーネントを全て冗長化し、コンポーネント障害が発生した場合は迂回できる構成にする
z ただし、データの滞留/ロスト/重複/逆転が発生する可能性がある
⇒取引を識別するIDの採番、送受信データの通番管理をEnd-To-Endで行う必要がある
アフィニティ
¾
複数回のデータ送受信で取引が成立する場合
z 並列化された応答タスクの中で特定の相手と取引する必要がある
⇒2回目以降の要求データ送信先を指定して送る/取引情報を共有資源に保持する
33
要求/応答型、つまり通信が双方向に渡る場合は一方向型の時よりも更に複雑になります。
要求側では、要求に対する応答データをいつとりに行くか、待っている間にリソースをロックしておくかど
うかという二つの部分で設計が大きく分かれます。
33
＜参考＞更新/アフィニティ有の要求/応答型の実装例
要求業務
応答業務A
＜商品検索＞
商品検索キーワード送信
検索結果待受け
待受け
商品検索キーワード受信
検索処理
検索結果送信
待受け
レスポンス･タイム
検索結果受信
＜在庫引当＞
発注処理開始要求送信
レスポンス･タイム
取引IDn/引当結果受信
取引IDn登録
＜発注処理＞
発注情報送信
発注結果待受け
取引
マスター
11
12
1
10
2
3
9
8
4
7
6
5
タイマー
アフィニティ
＜リカバリー処理＞
接続リトライ
応答データ有無確認 → 無し
取引IDn状況照会要求データ送信
照会結果データ待受け
レスポンス･タイム
照会結果データ受信
If (処理済?)
then 取引IDn確定処理
else 取引IDn処理要求再送
......
在庫
マスター
取引
マスター
発注情報受信
発送処理要求送信
取引IDn/
発注者/
決済情報など
発注結果受信タイムアウト
発注処理開始要求受信
在庫引当
取引ID採番=n
取引IDn/引当結果送信
待受け
在庫引当/発注/発送処理確定
発注結果送信
Indoubt
応答業務B
データ待受け
取引状況照会要求データ受信
取引IDn状況照会
照会結果データ送信
......
34
ひとつの業務が複数のアクティビティから構成されている場合、実行されたアクティビティがどのリクエス
トの実行結果の一部なのかを紐付けておくことが必要になります。これを実現するためにはメッセージや
通信基盤の中で紐付け情報を保持しておく必要があります。仮に通信コンポーネントの冗長化を行なっ
ていた場合でも、紐付けデータをコンポーネント間で共有する仕組みがないのであれば、業務を継続する
ためには必ず該当データを持っているコンポーネントと通信を行なう必要があります。この仕組みを実現
する仕組みをアフィニティと呼びます。
34
＜参考＞要求/応答型業務の設計/実装のポイント
パター
ン
適用業務例
オンライ z要求/応答双方のリ
ン
ソース更新があり、整
合性の一致が必須であ
取引
る処理．
z業務例
･ATM預金入出金/記帳
･各種オンライン商取引
オンライ zリソースの更新は伴
ン
わず、リソースを検索/
照会する業務
照会
z業務例
･口座残高参照
･在庫照会
非同期
応答取
得
z大量応答データ/長時
間処理となり応答の同
期待受けが非現実的で
ある処理．
z業務例
･随時帳票印刷
･人手を介した
プロセス･フロー
特徴
メッセージ・キュー 設計/実装のポイント
イング可否/適否/
実績/理由
z高可用性/連続稼動/レス
ポンス・タイムの要件が厳し
い．
z取引量にピーク性がある．
z実装可能
z実績多数
z考慮点あり
z経路/受信タスク
障害時にキューに
メッセージが滞留
する．
zサービス・レベル/レスポン z冗長化構成では
ス・タイムの要件が厳しい． メッセージ転送途
中で入力順序の
z照会量にピーク性がある．
逆転が発生する可
z検索のキーによっては長 能性がある．
時間処理、または照会結果
が大量になることがある．
z高可用性/連続稼動/レス z適している
ポンス・タイムの要件は限定 z実績多数
的．
9要求側タイムアウトにより滞留したままの
メッセージを削除/退避する仕組み/運用が
必要．
9レスポンス・タイム短縮/スルー･プット向上
/余計な重複処理回避のため、メッセージ属
性はノン･パーシスタントとし、コンポーネント
は全て必要なレベルで冗長化する.
9（経路障害発生時には要求側はタイムアウ
トとなるため、障害回復後メッセージが復活し
ても仕方ない）
9メッセージのロスト/重複/逆転は、両端の
プログラムで取引ID管理/通番カウントアップ
を行うことで防止する．
9要求側は、リソース/操作ロック時間を最小
化するため、要求メッセージ送信のみ行い応
答は待受けない．
9転送経路でのメッセージ・ロストを防ぐため、
zキューに大量
z取引量にピーク性がある． データを一時保管 メッセージはパーシスタント属性とする．
可能であり、転送 9転送途中でのメッセージ逆転を防ぐため、
の整合性を確保で 処理順序を遵守したい単位でコンポーネント
/処理を逐次化する．
きるため
9非同期応答取得機能(要求送信タスク⇒応
答受信タスクへのメッセージ識別情報通知/
35
自動取得タイマー/取得操作機能)を開発/利
用する必要がある．
要求/応答型の実装のポイントと処理の流れについて纏めてみました。
要求/応答型とひとくくりに表現しても、それがデータ更新を伴う取引なのか、照会だけで終わるのか、応
答はすぐもらう必要があるのか、それともバッチ処理などで後でもらえばよいのかなど、やはり様々な検討
ポイントが存在します。
35
メッセージング基盤設計
接続方式,キュー配置,ネットワーク･リンクの検討
‡
‡
‡
‡
接続方式,キュー配置,ネットワーク･リンクの検討
MEの接続,ネットワーク・リンク方式
MQの接続,ネットワーク・リンク方式
サービス統合バス・リンクの考慮点
36
36
接続方式,キュー配置,ネットワーク･リンクの検討 (1/2)
„
アプリケーションと宛先(キュー)の配置を以下の観点で検討
‹
リモート・システム/アプリケーションと非同期で処理をしたい場合
¾
アプリケーションと同一サーバー上にキューを持つ構成にする
＜一方向型＞
メッセージング・プロバイダー
Producer
メッセージング・プロバイダー
Consumer
ネットワーク・リンク
宛先定義
転送キュー
受信キュー
＜要求/応答型＞
メッセージング・プロバイダー
メッセージング・プロバイダー
Responder
Requester
要求送信
要求受信
ネットワーク・リンク
宛先定義
転送キュー
要求キュー
応答送信
応答受信
ネットワーク・リンク
応答キュー
転送キュー
37
これまで説明したような考慮点や設計ポイントを踏まえた上で、以降ではメッセージング基盤を利用して
実装していく上でのポイントについて説明します。
（検討の結果、業務に通信基盤を使用することになったということを前提とします）
まず、抽出した要件からアプリケーションとキューの関係を決定します。非同期的なやり取りをしたいとい
う場合は基本的にローカルにキューを配置する構成にします。送ったらおしまいというスタンスで考え、要
求/応答型の場合は一方向通信を二つ構成するイメージになります。
37
接続方式,キュー配置,ネットワーク･リンクの検討 (2/2)
„
アプリケーションと宛先(キュー)の配置を以下の観点で検討
‹
リモート・システム/アプリケーションと同期で処理をしたい場合
¾ アプリケーションは宛先を保持するサーバーに直接接続する
z
アプリケーション⇔メッセージング・プロバイダー間はリモート・クライアント接続にする
メッセージング・プロバイダー
Requester
Responder
要求送信
要求受信
応答受信
リモート・
クライアント接続
要求キュー
応答送信
応答キュー
38
相手と話をしないと処理が進まない、つまりアクティビティーを同期的にやりとりして業務を進めていくよう
な場合は、上記チャートのように一方にのみキューを配置し、キューを持たない方から持つ方に対してリ
モート接続を行なうのが基本となります。
38
MEの接続,ネットワーク･リンク方式 (1/2)
„
ME
ローカル接続
AS
ME
Producer
Consumer
キュー宛先
„
リモート接続
アプリケーション
･クライアント
Producer
AS
ME
Consumer
39
前ページでご紹介した方針を、WASのME（Messaging Engine)で実装した場合の例を示します。
39
MEの接続,ネットワーク･リンク方式 (2/2)
„
ME
ME間転送
‹
同一バス内⇒リモート宛先経由(自動定義)
BUS
AS
AS
Producer
Consumer
(ネットワーク・リンク)
(ネットワーク・リンク)
(リモート宛先)
‹
AS
ME
ME
ME
キュー宛先
(リモート宛先)
別バス間⇒サービス統合バス・リンク(明示定義)
BUS
AS
BUS
AS
ME
Producer
ME
Consumer
サービス統合バス・リンク
外部宛先
(転送キュー)
キュー宛先
40
MEの実装上の特徴として、どのような転送経路やどのようなキューを通って通信が行なわれて最終的に
メッセージが宛先に伝達されるかというのはBusを構成しているME間で自動的に行なわれるという点があ
ります。
バスをまたぐようなケースは、サービス統合バスリンクを明示的定義することで実現できます。
40
MQの接続,ネットワーク･リンク方式 (1/2)
„
MQ
ローカル接続
キュー・マネージャー
Producer
Consumer
ローカル・キュー
„
リモート接続
MQIクライアント
Producer
キュー・マネージャー
エージェント・
タスク
Consumer
ローカル・キュー
41
同様の形態をMQで実現した場合の例を示します。基本的にコンポーネントが違うだけでMEと変わりは
ありません。
41
MQの接続,ネットワーク･リンク方式 (2/2)
„
MQ
キュー・マネージャー間転送
キュー・マネージャー
キュー・マネージャー
送信
MCA
Producer
リモート・キュー定義
転送キュー
チャネル
受信
MCA
Consumer
ローカル・キュー
42
MEと違う点は、複数のキュー・マネージャーを連携させる場合、キューと送受信のためのネットワーク･リ
ンクはユーザーが意識して事前に定義する、もしくはMQの機能を使用して自動的に定義されるものを
使ってユーザーが運用をしていく必要があるところです。
42
サービス統合バス・リンクの考慮点
„
„
サービス統合バス・リンク： バス間を接続しメッセージ転送を行うネットワーク・リンク
サービス統合バス・リンクはメッセージング・エンジン単位に定義し、稼動する
‹
„
„
ME
接続先メッセージング・エンジン名、ホスト名、ポート番号、プロトコルを直接指定
外部宛先を定義 （外部バス (接続先のバス)にある宛先への紐付けのため）
考慮点
‹
‹
‹
サービス統合バス・リンクの定義反映にはWASの再起動が必要
リトライ間隔/回数、バッチ・サイズ等、細かい指定ができない（必要ない）
MQのトランス・ミッション・キューに相当する定義/インタフェースはない
¾
¾
‹
メッセージ転送の仕組みが公開されていない
¾
¾
‹
非同期転送は可能
z
内部的に送信キューを自動定義/保持している
z
リンクで接続障害が発生しても、アプリケーションは送信処理を完了できる
接続先メッセージング・エンジン/ネットワーク障害発生時にメッセージが何件残っているか、
未コミットのメッセージが残っているかなどの確認方法は公開されていない
z
wsadminコマンドで滞留数を照会することは可能ではある
9 送信キューを特定する方法が公開されておらず、Fix適用で実装が変化している
転送のバッチ化、障害検知、再接続、同期情報の保持、In-doubt解決の仕組みなど
パフォーマンス・テスト、負荷をかけた状態でのネットワーク障害テスト必須
リンクの稼動状況は管理コンソールから確認可能
¾
MQのDISPLAY CHSTATUSコマンドで照会できるような詳細項目は公開されていない
43
サービス統合バスリンクを使用する上での考慮点について纏めました。
MQと比較すると、登場し使用されるようになってから日が浅いということもあり、機能や使いやすさの点
ではMQにやや劣るように見える部分があります。このチャートはMQとMEのどちらを利用するかを検討さ
れる際に参考にして下さい。
43
メッセージング基盤設計
メッセージ信頼性の検討
44
44
メッセージ信頼性の検討
„
メッセージ信頼性の考え方
‹
基本
¾
以下の方針/バランスを考慮し選択
アプリケーション/運用によるメッセージ回復/整合性維持
メッセージング・プロバイダーへのシステム・リソース/冗長化
製品ログ/バックアップの人為/多重/SW障害によるロストのリス
クまで想定し、アプリケーション/運用によるリカバリーを実装する
かどうか
信頼性を上げれば、その分必要なシステム・リソースが増大
する
‹
メッセージ・フロー別の考え方
¾
¾
‹
一方向型フロー
z 保証パーシスタント＋ログ/キューの冗長化
9 送信後の障害検知は基本的に不可能なので、メッセージ回復/整合性維持を保証し
て欲しい
要求/応答型
z 高信頼性ノン・パーシスタント
9 応答タイム・アウトにより障害検知/再入力は可能
9 通信障害でのメッセージ・ロストは避けたい
9 余計な重複を避けるためプロセス障害後の再始動時には、
タイムアウトとなった取引のメッセージは消して欲しい
z ベストエフォート・ノン・パーシスタント
9 照会業務のみなのでパフォーマンスを重視する (※メッセージExpiryも併用）
その他
¾
監査目的でメッセージの送受信記録をログに残す⇒保証パーシステント
45
メッセージの信頼性とは、つまり通信基盤内におけるメッセージの永続化とほぼ同義です。
メッセージ信頼性も業務内容と要件に併せて検討する必要があります。永続化をしなければ運用面でも
性能面でも楽になりますが、何らかの障害時にメッセージそのものが消失する可能性がでてきますので、
回復手段を運用でカバーする必要が出てきます。それに対してメッセージを永続化するとメッセージ消失
の可能性が減ります。ただし多重障害などのケースがありますので、必ずしも万全とはいえません。永続
化を行なっていてもある程度運用でカバーしないといけない部分もあります。また、永続化によってコスト
の増大やパフォーマンス低下などの影響も発生します。
そのため、トレードオフの要素を踏まえた上でどの程度の永続化強度にするかを検討します。
45
＜参考＞メッセージ信頼性(詳細)
メッセージの
信頼性
MQ
ME
メッセージ属性
メッセージ処理
JMS
Delivery
Mode
相当する
MQパー
システン
シー
トランザク
ションの
アトミック
性
データ・ス
トア書出
有無
正常稼動
時の破棄
可能性
重複発生
の可能性
計画停止
メッセージ残存
クライアン
ト通信障
害
メッセージ
ング・エン
ジン間通
信障害
メッセージ
ング・エン
ジン/サー
バー障害
ベスト・
エフォート・
ノン・
パーシスタント
ノン・
パーシ
スタント
FAST
メッセー
ジ※1
なし
なし
ある
なし
残存し
ない
残存し
ない
残存し
ない
残存し
ない
高速
ノン・
パーシスタント
ノン・
パーシ
スタント
該当な
し
あり
リソース
不足時
のみ
なし
あり
残存し
ない
残存し
ない
残存す
る
残存し
ない
高信頼性
ノン・
パーシスタント
(デフォルト)
ノン・
パーシ
スタント
ノン・
パーシ
ステント
あり
リソース
不足時
のみ
なし
あり
残存し
ない
残存す
る
残存す
る
残存し
ない
高信頼性
パーシスタント
パーシ
スタント
該当な
し
あり
非同期
書出
なし
あり
残存す
る※2
※3
残存す
る
残存す
る
残存の
可能性
あり※2
保証
パーシスタント
(デフォルト)
パーシ
スタント
パーシ
ステント
あり
同期書
出
なし
なし
残存す
る
残存す
る
残存す
る
残存す
る
MQリンク受信デフォルト
MQリンク受信デフォルト
※1：チャネル属性のNPMSPEED(FAST)指定下のノン･パーシステント・メッセージ
※2：データ・ストアに書出されたメッセージについては回復
※3：メッセージング・エンジン停止処理時にキャッシュ上のメッセージはデータ・ストアに強制書出される
46
チャートの表は、WASV6.1 Information Centerの下記文章を元にメッセージの信頼性について、永続化
のレベルに応じてシステムの挙動にどのような違いがあるかを纏めたものです。
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.nd.do
c/concepts/cjj9000_.html
46
＜参考＞データ・ストア (ME)
„
データ・ストアとは
‹
MEが以下の情報を保持するためのRDBのスキーマ( cf. ファイル・ストア )
¾
¾
¾
„
ME
ME作成時に以下の表を自動作成
ME始動時に排他ロックが確保される
スキーマを分けることにより1つのDBMSに複数のデータ・ストアを保持可能
※ノン・パーシスタント・メッセージのみの場合でも、データ・ストアの作成/運用必須
テーブル名
内容
SIBOWNER
排他使用権があるメッセージング・エンジンのUUID
SIBCLASSMAP
データ・ストア内オブジェクトのカタログ
SIBLISTING
SIBnnnテーブルのカタログ
SIBXACTS
アクティブな2フェーズ・コミットのステータス
SIBKEYS
ME内のオブジェクトの識別子
SIB000
SIB001,SIB002の構成情報
SIB001
高信頼性/保証パーシスタント・メッセージ
SIB002
ME稼動プロセスのヒープに収まりきれないノン・パーシスタント・メッセージ
JDBCプロバイダーの選択
‹
組み込みderby(デフォルト)
‹
その他のJDBC接続をサポートするRDB製品
¾
WASクラスター構成での使用はサポートされない
47
永続化機能によって預かったメッセージを蓄えておくところの実装形態は、MEとMQで変わってきます。
MQは独自のファイル・システムを利用します。MEではファイル・ベースとDBへの格納の二つの形態から
選択します。WASがサポートしているDBはデータ・ストアとして使用が可能です（ただしライセンスや製品
は各自で用意して頂く必要があります）。
47
＜参考＞データ・ストア・トポロジーの検討 (1/2)
„
ME
データ・ストアの配置(ローカル構成)
¾
メッセージング・エンジンと同一ノード上で稼動
AS
ME
DS
¾
トレード・オフ
メリット
デメリット
・ローカル接続なのでネットワーク・トラフィック
/障害の影響を受けない
・組み込みderbyを利用すれば追加ライセンス
は不要
・ノード障害時、データ・ストアも同時に
障害となるので、MEが他ノードに
フェール・オーバーできない
⇒ フェール・オーバー不要の場合に適する
48
データ・ストアを配備する（トポロジー）上の考慮点について纏めてあります。
WASには組み込みDBとしてderbyがデフォルトで同梱されており、データ･ストア用のDBとしても利用が
可能です。ただし、WASクラスター構成でMEを利用したい場合はderbyは使用できません。
48
＜参考＞データ・ストア・トポロジーの検討 (2/2)
„
ME
データ・ストアの配置(リモート構成)
¾
メッセージング・エンジン稼動ノードからリモートのDBサーバーに接続
AS
DBサーバー
ME
DS
¾
メリット
トレード・オフ
デメリット
・ノード障害時、MEフェール・オーバーにより ・ネットワーク・トラフィック/障害の影響を
メッセージの回復ができる
受ける
※同一データ・ソースにアクセス必要
※DBMS側のスレッド開放のためDBサー
バー側TCPIP KeepAliveを設定する
⇒ パーシスタント・メッセージ有 & フェール・オーバー要件有の場合は必須
49
ローカル配置されているderbyではDBの信頼性が満たされないというケースでしたら、信頼の置けるDB
で構築するという選択肢をとります。さらにノード障害時の信頼性を高める必要があればこのチャートでご
紹介しているようにDBをリモートに配置することを検討します。
49
メッセージング基盤設計
負荷分散/可用性向上の実装
‡
‡
‡
‡
‡
‡
‡
‡
‡
‡
‡
MEの高可用性（HA：High Availability）機能
MEパーティショニングによる負荷分散/可用性向上
要求/応答型のMEパーティショニングによる負荷分散
ME⇔Responderプロセス分割時の考慮点
MEフェール・オーバーによる可用性向上
サービス統合バス・リンクの可用性
MQクラスターによる負荷分散/可用性向上
MQクラスターとMEパーティショニングの比較
MQクラスターによるアフィニティへの対応方法
ME⇔MQ連携の負荷分散
ME⇔MQ連携の可用性向上
50
50
MEの高可用性（HA：High Availability）機能
„
MEが障害で停止した時に、同一クラスター内の別サーバーにMEを引き継ぐことが可能
‹
‹
„
ME
データ・ストアは、引継ぎ先のサーバーからアクセス可能である必要がある。
パーシスタント・メッセージのみを引き継ぎ可能。
MEクラスターは、HA Managerによって、監視・制御される
‹
HAポリシーとして、メッセージング・エンジンの振る舞いを指定
¾
静的ポリシー
¾
One of N
z
z
¾
‹
‹
‹
1つのクラスタ・メンバーがMEを稼動します。他のクラスター・メンバーは待機。
ノーオペレーション
z
‹
MEを特定のサーバーでのみ稼動。
障害が発生しても、何もしない設定。
HAポリシーの適用範囲は、一致基準（Match criteria）で指定。
ポリシーに該当するコンポーネントをHAグループと呼ぶ。
優先サーバーを設定することで、ME障害時のフェイル・オーバーの優先順位を指定可能。
フェイル・バックを有効にすることで、優先度の高いサーバーが復旧した際に、MEを引き継ぐことが
可能。
Bus
Cluster
AS1
ME1
Data Store
for ME1
ME2
Data Store
for ME2
AS2
ME1
ME2
HA Group 1
HA Group 2
51
ここから負荷分散と可用性向上の話に入っていきます。
MEの高可用性機能を利用する場合、データ・ストアを引き継ぐことで業務の継続性を高めます。
データ・ストアが複数ノードにまたがって引き継ぎ可能である必要があるため、デフォルトのデータ・ストア
であり、同一サーバーからしかアクセスできないderbyは利用できません。
引継ぎ方法は、コア・グループのポリシーに設定します。このポリシーには、メッセージング・エンジンの
振る舞いを指定する他、HAポリシーをどのコンポーネントに適用するかを指定する一致基準、そのコン
ポーネントを稼動させるサーバーの優先順位を指定する優先サーバー、フェイル・バックの有効/無効な
どを設定します。
【メッセージング・エンジン用のポリシーの構成】
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.nd.do
c/tasks/tjt0028_.html
51
MEパーティショニングによる負荷分散
„
MEのワークロード共用(パーティショニング)とは
‹
キュー宛先に送信されたメッセージを複数のMEにより保持される各キュー・ポイントに
振分け/転送する機能
¾
„
WAS NDエディション、WASクラスター構成
振分けロジック：ラウンドロビン
‹
„
Information Centerの記述 ⇒「全体にわたりバランスよく分割されます」
振分け動作の原則
‹
送信⇒パーティショニングされる
‹
受信⇒パーティショニングされない
¾
„
WASプロセス/データ・ストアが複数になる ⇒ CPU/メモリー/I/O分散を図ることができる
前提構成
‹
„
ME
宛先/キュー・ポイントごとにパーティショニング有無を指定することはできない
考慮が必要なアプリケーション要件
‹
‹
複数メッセージの送受信処理において、順序性保証が必要な場合はパーティショニン
グ不可
要求/応答型の複数取引においてアフィニティーが存在する場合の考慮点
¾
接続時に宛先ME名を直接指定することはできない
z メッセージ/共有メモリ/DB上にセッション情報を保持する必要がある
52
MEにおける負荷分散のパーティショニングの概要についてご紹介します。パーティショニングを行なうこ
とによってキュー・ポイントが受信側のプロセス毎に生成されます。キュー・ポイントまでメッセージが来た
後にプロセス障害が発生した場合、MQと異なり正常に稼動しているキューに対してメッセージの再送信
は行なわれません。そのため、そのメッセージは障害発生したプロセス自身によって障害回復後に転送
が再開されるという仕組みになっています。
52
＜参考＞リモート・キュー・ポイントの操作
„
管理コンソール操作
‹
„
サービス統合 > バス > busname > メッセージング・エンジン > mename > リモート・
キュー・ポイント
照会できる項目
‹
‹
‹
„
ME
メッセージ入出力数
滞留メッセージ数
処理状況の照会
滞留メッセージに対する操作
‹
‹
削除
例外宛先への移動
53
リモート・キュー・ポイントの情報の参照と滞留メッセージに対する操作は、WASの管理コンソールから行
なうことができます。
53
ME⇔Responderプロセス分割時の考慮点 (1/3) ME
„
MEとResponderが同一プロセス上で稼動している場合
⇒ 応答メッセージは問題なく受信できる
‹
MQリンク、SIBusリンクがResponderである場合もこの動作
Cell
BUS01
Member00
ME00
Requester
要求送信
Responder
Node
要求受信
Agent
宛先=DestReq01
応答送信
応答受信
宛先=DestRep01
Requester
要求送信
キュー宛先
DestReq01
Member01
ME01
Responder
要求受信
宛先=DestReq01
応答受信
応答送信
宛先=DestRep01
54
要求/応答型の環境でMEのパーティショニングを行う時の考慮点があります。
応答側の業務のJVMプロセスを分割したい場合にMEだけ分割しないということはできません。分割され
てしまいます。
54
ME⇔Responderプロセス分割時の考慮点 (2/3) ME
„
Requesterの応答受信に関する考慮点
Requesterの応答受信は接続先MEの応答宛先を待受ける
Responderの応答送信は接続先ME上の応答宛先となる
‹ メッセージ送信時にME名を直接指定することはできない(接続先MEにより自動振分け
される)
⇒応答メッセージがRequester接続先ME以外のキュー・ポイントに返るケースがある
‹
‹
„
回避案
案1)応答宛先として一時宛先を動的作成し、JMS.ReplyToに利用する
¾ 一時宛先はバス内でユニークなので、応答メッセージはRequester接続先MEに必ず返る
¾ 考慮点
z JMSアプリケーションでの一時宛先の実装方法
9 TemporaryQueueオブジェクトの作成(createTemporaryQueue())/削除(delete())
を記述する必要がある
9 既存JMSアプリケーションでMQをJMSプロバイダーとしている場合⇒修正が必要．
z アプリケーションが必要に応じ動的に作成するため、パフォーマンス上のオーバー・
ヘッドがある
z アプリケーションの終了処理ができなかった場合、ゴミとして残る
案2)接続先のMEを意識したJMSリソース構成、アプリケーション・ロジックとする.
55
55
ME⇔Responderプロセス分割時の考慮点 (3/3) ME
„
応答宛先を事前定義のキュー宛先とした場合の動作
BUS01MEMember00
ME00
APMember01
Responder
Node
要求受信
Agent
宛先=DestReq01
応答送信
宛先=DestRep01
Requester
要求送信
MEMember01
ME01
応答受信
宛先=DestReq01
受信待受け
タイムアウトとなる
メッセージ滞留
„
※
宛先=DestRep01
キュー宛先
DestReq01
応答宛先も
パーティショニ
ングされる
・アプリケーションから直
接キュー・ポイント名
/ME名を指定して送信で
きない
応答宛先を動的作成の一時宛先とした場合の動作
BUS01
MEMember00
ME00
Requester
要求送信
宛先=DestReq01
応答受信
一時宛先=_QDestRepｘｘｘ01
Requester
要求送信
応答宛先は
バス内でユニーク
な宛先となる
応答宛先として
一時宛先を
動的に作成する
キュー宛先
DestReqxxx01
宛先=DestReq01
Responder
Node
要求受信
Agent
応答送信
APMember01
MEMember01
ME01
応答受信
APMember00
キュー宛先
DestReqxxx02
Responder
Node
要求受信
Agent
応答送信
56
一時宛先=_QDestRepｘｘｘ02
56
MEフェール・オーバーによる可用性向上
„
ME
可用性向上
‹
HAマネージャーによるプロセス障害検知は以下のいずれかのタイミング
¾
¾
¾
‹
設定箇所（管理コンソール）
¾
¾
‹
プロセスダウンにより、ソケットがクローズされた場合
HAマネージャー間のHeartBeatが断絶した場合
OSのTCP/IP KeepAliveのタイムアウトにより、ソケットがクローズされた場合
IBM_CS_FD_CONSECUTIVE_MISSED
IBM_CS_FD_PERIOD_SECS
秒)
ハートビートの失敗数(デフォルト：6回)
ハートビートの送信間隔(デフォルト：30
障害メンバー上で稼動するMEを他メンバーで自動再始動することが可能
¾
¾
データ・ストアを引き継ぐ
z 障害MEのDBMS側エージェント・タスクをリセットするため、DBサーバーに
TCP/IP KeepAliveの設定必要
以下のリソースを回復する
z キュー・ポイント
z 障害前に保持されていたパーシスタント・メッセージ
57
WASのND版では、HAマネージャーによるメッセージング・エンジンのFailover機能が利用できます。
57
MEフェール・オーバーによる可用性向上(図)
ME
Cell
BUS01
Deployment Manager
HAマネージャー
Node
Node Agent
HAマネージャー
Member00
ME=Cluster01.000-BUS01
キュー・ポイント[email protected]
JMSアプリケーション
JMSアプリケーション
JMSアプリケーション
送信
送信
送信
キュー宛先
Dest01
WAS HAフェール・オーバー
Node
JMSアプリケーション
受信
DS
Node Agent
HAマネージャー
Member01
ME=Cluster01.000-BUS01
キュー・ポイント[email protected]
JMSアプリケーション
受信
58
MEのFailoverを実現する場合は、障害発生時に永続化メッセージのためのDBのロックを適切に開放し
て、引き継ぎ先のME(WASプロセス）がDBを使用可能な状態にすることが必要です。適切に開放するた
めにはDBクライアント（もしくはJDBCドライバー）とDBサーバー間の通信にタイムアウトを指定します。
58
サービス統合バス・リンクの可用性
„
サービス統合バス・リンク構成手順概要
‹
外部バスを定義
‹
サービス統合バス・リンクを定義する
‹
接続先バスの情報を設定
¾
¾
¾
¾
¾
„
ME
接続先のバス名
双方のバスで名前を一致させる
外部バス名
リモート・メッセージング・エンジン名
ブート・ストラップ・エンドポイント
z
接続先ME稼動サーバーの
ネットワーク・アドレス
z
ポート番号
z
プロトコル
可用性向上の設定
‹
ブート・ストラップ・エンドポイントの設定
¾
¾
ブート・ストラップ・サーバーなしの場合
z
ME稼動サーバーの
SIB_ENDPOINT_ADDRESSを複数指定
9 設定順に接続を試みる
ブート・ストラップ・サーバーありの
z
ブート・ストラップ・サーバーの
SIB_ENDPOINT_ADDRESSを指定
9 MEのフェール・オーバー先
サーバーへの接続情報が通知
され、再接続される
59
サービス統合バス・リンクの可用性確保の方法としては、MEを複数参加させることで経路を複数もたせ
たり、ブート･ストラップ・サーバーを指定する方法があります。
59
サービス統合バス・リンクの可用性(図)
ME
BUS02
Cluster
BSMember
BSMember
ブート・ストラップ・エンドポイント設定
bootstrap1;7278;BootstrapBasicMessaging,
bootstrap2;7278;BootstrapBasicMessaging,
SIB_ENDPOINT_ADDRESS
(bootstrap1,port=7281)
Bootstrap
AS
Member00
BUS01
ME01
ME00
Producer
別名/外部宛先=Dest01
バス=BUS02
(転送キュー)
サービス統合
バスリンク
BUS01=BUS02
宛先=Dest01
外部バス=BUS01
ルーティング定義タイプ
= 直接-サービス統合バスリンク
外部バス=BUS02
ルーティング定義タイプ= 直接-サービス統合バスリンク
SIB_ENDPOINT_ADDRESS
(yujioatp1,port=7281)
SIB_ENDPOINT_ADDRESS
(mqtp1,port=7276)
ブート・ストラップ・エンドポイント設定
yujioatp1;7278;BootstrapBasicMessaging,
yujioatp2;7278;BootstrapBasicMessaging,
Consumer
WAS HAフェール・オーバー
再
接
続
AS
ME00’
Consumer
宛先=Dest01
SIB_ENDPOINT_ADDRESS
(yujioatp2,port=7281)
60
60
MQクラスターによる負荷分散/可用性向上
„
MQ
MQクラスターとは
‹
複数のキュー・マネージャーをクラスター化し、負荷分散、可用性向上を実現す
る機能
MQCLUS
MQGET(wait)
CorrelId=QMA指定
QM1
QMA
振分け処理
MQXQH.CorrelIdに送
信先チャネル名指定
CLUSSDR
CLUS(MQCLUS)
MQPUT
MQCONN(QM1)
MQOPEN(CLQ)
MQPUT
レポジトリ・
マネージャー
QLC01
CLUSRCVR
レポジトリ・
マネージャー
クラスター
送信キュー
構成/制御情報の交換
レポジトリ・キュー
QMB
レポジトリ・キュー
MQGET(wait)
レポジトリ・
マネージャー
CorrelId=QMB指定
CLUSSDR
レポジトリ・キュー
CLUSRCVR
QLC01
CLUS(MQCLUS)
61
次にMQを利用した場合の可用性機能についてご紹介します。
MQのクラスター機能では、基本的に送信側のキューはひとつです。キューに入れられたメッセージは
キュー･マネージャー毎に配備されているレポジトリー・マネージャーと呼ばれる転送の制御を行なってい
るサブシステムによってクラスター送信キューにPUTされます。各振り分け先に対してクラスター・センダー
とよばれる仕組みがあり、CorrelIdを元に自分の担当する宛先に対するメッセージかどうかを識別していま
す。
クラスターの構成情報や制御情報は、レポジトリー・マネージャーがレポジトリー･キューという専用の
キューを利用してキュー・マネージャー間を交換しています。
61
MQクラスターとMEパーティショニングの比較
MQ
ME
項目
ME
MQ
振分けロジック
記述なし.(ラウンド・ロビンのみ)
ラウンド・ロビン、重み付け、優先付け、ランク付け
振分け処理
タイミング/場所
接続先MEによリモート・キュー・ポイントが宛先キュー・ポイント毎
に動的に作成され、振り分け/宛先キュー・ポイントへの転送が行
われる
リポジトリ・マネージャーにより振分けが行われ、振分先キュー・マ
ネージャーと接続している送信チャネル名をMQXQH.CorrelIdに指
定し、クラスター送信キューにMQPUTする.
送信チャネルはCorrelId指定で自分宛のメッセージをMQGET(wait)
しており即座に送信する.
受信側/ネットワー
ク障害時の動作
振分け処理後のメッセージはリモート・キュー・ポイントに滞留
他キュー・マネージャーに自動リルートされる
送信In-doutの解決
再接続後に自動解決される(手動操作により強制解決も可能)
区分化指定の単位
ME単位(宛先単位には指定不可)
キュー単位にクラスター属性の指定が可能
応答の受信
プロセス分割時、応答メッセージが取得できないことがある.
(応答宛先として一時宛先を作成する、または
JMSコネクション・ファクトリーをME単位に定義し、JNDI名を使い
分けるロジックの実装が必要)
要求メッセージのMQMD.ReplyToQ,ReplyToQMgr名宛に応答メッ
セージを送信すれば、Requesterの待つ応答キューに応答メッセー
ジが届く.
アフィニティ制御
送信先ME名をアプリケーションは直接指定できない
(JMSコネクション・ファクトリーをME単位に定義し、JNDI名を使い
分けるロジックの実装が必要)
要件に応じた送信先キュー・マネージャーの指定が可能
「MQクラスターによるアフィニティへの対応方法」参照
構成/制御情報の
管理/保管場所
記述なし．
各キュー・マネージャーのレポジトリー・キューに保管.
フル・レポジトリーのキュー・マネージャー×2つをマスターを保持.
クラスター・チャネルを通じたリポジトリ・マネージャー間のPub/Sub
で構成情報/制御情報の交換を行っている.
他のキュー・マネージャーは必要とする情報のみを部分レポジト
リーに保持.(90日経過後に未使用情報を削除).
ネットワーク・
リンクの運用
不要(不可)
START/STOP CHLによる制御が可能
(トリガリングによる自動接続も可能)
保守/拡張性
キュー・ポイントの追加情報反映のため送信側サーバーのリス
タートが必要
クラスター・キュー作成時に動的に反映される
SUSPEND/RESUME/RESETコマンドによるキュー・マネージャーの
62
休止/復帰/強制離脱操作が可能.
REFRESHコマンドによる構成情報の再取得が可能.
このチャートではMEのパーティショニングとMQクラスターの違いについて纏めています。
大きな相違点は送信元の振り分け処理の場所と振り分けされた結果です。
振り分けの結果、MEの場合は複数のリモート･キュー・ポイントにメッセージが分かれて入るのに対して、
MQが入る先はひとつということです。MQの場合は宛先のキュー・マネージャーの障害を検知すると、そ
のCorrelIdの付け替えを行なって別の割り振り先にリルートすることができます。また、MQの場合はコマン
ドを発行することで動的に拡張が可能ですが、WASの場合は拡張の際に関連するプロセスの再起動が必
要になります。
62
＜参考＞MQクラスター負荷分散アルゴリズム
„
MQ
単純なラウンドロビンだけでなく、高度なワークロード・バランスが可能
‹
重み付けラウンドロビン
¾
¾
チャネルのCLWLWGHT属性に設定可能（1から99）
処理能力の高いマシンに多くのメッセージを割り振ることができる
Weight=99
QMA
QLC1
QM1
MQクラスター
QMB
Weight=50
‹
QLC1
プライオリティ制御
¾
¾
チャネル、キューのCLWLPRTY属性に設定可能（0から9）
正常時は一方のキューにメッセージを片寄せして送信、障害時に代替キューに送信先を切り替え
Priority=9
QLC1
QMA
MQクラスター
QM
Priority=9
本番機
QLC1
QMA
Priority=0
QM2
QLC1
MQクラスター
代替機
QM1
Priority=0
QM2
63
QLC1
63
MQクラスターによるアフィニティへの対応方法
„
MQ
要件により、以下の3種類の動作を選択できる
アフィニティの要件
MQOPEN時の指定
送信メッセージ振分け動作
MQOD.ObjectQMgrName指定
MQOO_BINDオプション指定※
アフィニティ無し
どのQMGRも問題ない場合
ブランク
MQOO_BIND_NOT_FIXED
各メッセージ(MQPUT)毎に
振分けされる
アフィニティ有り．
どのQMGRでも良いが、
最初に解決されたキュー・マネージャー
を使い続けたい場合
ブランク
MQOO_BIND_ON_OPEN
宛先QMGRは自動選択され、
以降のメッセージは同一
キュー・マネージャーに送信さ
れる
アフィニティ有り．
特定のQMGRにしか送信
したくない場合
送信したいQMGR名
N/A
ObjectQMgrNameで指定した
キュー･マネージャーに送信さ
れる
１
MQOPEN
MQOO_BIND_NOT_FIXED
MQOD.ObjectName=Q1
MQPUT(1)
MQPUT(2)
※JMSの場合アプリケーションによるオプション指定は不可
(キュー属性DEFBIND(OPEN/NOTFIXED)で制御可能)
WLMによる
振り分け
①
QM1
Q1
②
２
３
MQOPEN
MQOO_BIND_ON_OPEN
MQOD.ObjectName=Q1
MQPUT(1)
MQPUT(2)
宛先決定
= QM2
MQOPEN
MQOD.ObjectQMgrName=QM2 宛先明示指定
MQOD.ObjectName=Q1
MQPUT(1)
MQPUT(2)
QM2
Q1
64
MEと比較するとMQの方がアフィニティの設定ができます。チャートにはアフィニティを有効にしている場
合としていない場合でどのように動作を制御できるかについてご紹介しています。
アフィニティを有効にすると、送信先のキュー･マネージャーの指定ができます。最初に送信した先の
キュー･マネージャーに対してのみメッセージを送信します。
64
＜参考＞
要求(ME)/応答(MQ)型実装詳細
MQXQH
RemoteQName
=QREQ
RemoteQMgrName=Q
Reauester(JMS)
M01
//初期化、接続
cf.start();//jms/CF
//入力データ受付
//業務処理
//要求メッセージ送信
setJMSReplyTo(jms/DestRep);
send(msg); //to jms/DestReq
//応答メッセージ受信
JMSCorrelationID
=JMSMessageID
//応答識別ID設定
Receive(timeout);
//to jms/DestRep
JMSキュー
名前=Q01
JNDI名=jms/DestRep
バス名=Bus01
キュー名=QREP
JMSキュー
名前=DestReq
JNDI名=jms/DestReq
バス名=Bus01
キュー名=QREQ
JMS接続ファクトリー
名前=CF
JNDI名=jms/CF
バス名=BUS01
(MQRFH2) UserData
リスナー
runmqlsr –m QM01 –t TCP –p 1414
バス
名前=Bus01
メッセージ・エンジン
名前=was01Node01.server1-Bus01
バス名=BUS01
別名宛先
ID=QREQ
バス=BUS01
ターゲットID=QREP@QM01
ターゲット・バス=QM01
Receiverチャネル
DEFINE
CHANNEL(BUS01.QM01)
TRPTYPE(TCP)
Responder(MQ)
MQCONN(QM01)
MQOPEN(QREQ)
MQOPEN(QREP)
MQGET(QREQ)
MQリンク
名前=MQL01
外部バス名=QM01
キュー・マネージャー名=QM01
送信側チャネル
チャネル名=BUS01.QM01
ホスト名=mqserv1
ポート=1414
トランスポート・チェーン
=OutboundBasicMQLink
外部バス
名前=QM01
ルーティング定義タイプ
=直接WebSphere MQリンク
(wait)
MQCC_OK
受信キュー
DEFINE QLOCAL(QREQ)
業務処理
応答メッセージ作成
MsgId=CorId
ObjName=RepToQ
ObjQMName=RepToQMGR
MQPUT(QREP,BUS01)
転送キュー
DEFINE QLOCAL(BUS01)
USAGE(XMITQ)
受信者チャネル
チャネル名=QM01.BUS01
トランスポート・チェーン
=InboundBasicMQLink
キュー宛先
ID=QREP
バス=BUS01
MQXQH
RemoteQName =QREP
RemoteQMgrName=BUS01
WAS(hostname=was01, SIB_MQ_ENDPOINT_ADDRESS=5558)
ME
MQ
MQMD
MsgID=xxx
CorrelId=000
ReplyToQ=QREP
ReplyToQMgr=BUS01
MQMD
MsgID=yyy
CorrelId=xxx
Senderチャネル
DEFINE
CHANNEL(QM01.BUS01)
CHLTYPE(RCVR)
TRPTYPE(TCP)
CONNAME(was01(5558))
XMIQ(BUS01)
(MQRFH2)
UserData
65
QM01(hostname=mqserv01)
メッセージング基盤を利用したアプリケーションを実際に動かしてテストを行なおうとしたときに、チャート
にあるような定義情報が必要になってきます。
65
ME⇔MQ連携の負荷分散
„
„
MQ
ME
外部宛先/別名宛先はパーティショニングできない
MQリンクはMQクラスターには参加できない
⇒現状では、ME⇔キュー・マネージャー間での負荷分散はできない
„
WAS上のJMSアプリケーション⇔MQ間の負荷分散
‹
MQをJMSプロバイダー とし、MQクラスターを利用.
(注：SIBWSが使用する宛先はMQをプロバイダーとすることはできない)
JMSアプリケーション
SIBWS
receive
QM01
ME01
send
QL01
MQリンク
送信
受信
MCA
MQリンク
受信
送信
MCA
内部転送
キュー
受信宛先
MQ
アプリケーション
QL01
MQGET
MQPUT
送信キュー
MQクラスター
MQクラスター
QM02
ME02
MQリンク
送信
受信
MCA
MQリンク
受信
送信
MCA
QL01
MQ
アプリケーション
QL01
受信宛先
MQGET
MQPUT
送信キュー
66
66
ME⇔MQ連携の可用性向上 (1/2)
„
‹
パーシスタント・メッセージの回復
制御情報の引継ぎ
¾
¾
構成情報(宛先定義、WAS/MQクラスター構成、リンク定義など)
リンク転送状況/トランザクション処理状況
引継ぎが必要なシステム・リソース
‹
ネットワーク・アドレス
¾
¾
‹
‹
„
ME
可用性向上のためME/MQ障害が発生した場合、稼動系⇒代替系へのテイク･オー
バーを行う
‹
„
MQ
MQ送信チャネルは接続先アドレスを複数指定できない
ネットワーク障害はネットワーク構成の冗長化で吸収
MQ： キュー・ファイル、ログ・ファイル
ME： データ・ストア、ファイルストア
MQテイク・オーバーの方法
1)サーバー・プラットフォームのHA機能を利用する
¾
Windows MSCS、AIX HACMP、z./OS ARM + VIPA
2)自動化の開発
3)手動で対応
„
MEフェール・オーバーとの関係
‹
MEはWAS HAマネージャーによるフェール・オーバーが可能
¾
ただし、以下の手順の自動化を行う必要がある
z
MEフェール・オーバーの検知⇒フェール・オーバー先サーバーの特定⇒ネットワーク・アドレスの引継ぎ
67
・WASv6.1 SIBusとWebSphereMQを繋ぐMQリンクの高可用性について
http://www-06.ibm.com/jp/domino01/mkt/cnpages1.nsf/page/default-0041D082
67
ME⇔MQ連携の可用性向上 (2/2)
JMS
アプリケーション
ME01
receive
TCPIP
TCPIP
外部/別名
宛先
内部転送
キュー
受信宛先
NIC
NIC
MQリンク
受信
NW
構成
IPyyy
IPxxx
receive
TCPIP
TCPIP
内部転送
キュー
受信宛先
MQGET
MQPUT
送信キュー
NIC
NIC
MQリンク
受信
QM01
受信
MCA
MQリンク
送信
外部/別名
宛先
送信
MCA
ログ/キュー・ファイル
ログ/キュー・ファイル
ME01
send
稼動系
MQ
アプリケーション
受信キュー
NIC
NIC
MEデータ・ストア
JMS
アプリケーション
QM01
受信
MCA
MQリンク
送信
send
ME
MQ
IPyyy
NW
構成
NIC
NIC
IPxxx
代替系
MQ
アプリケーション
受信キュー
送信
MCA
MQGET
MQPUT
送信キュー
68
68
WAS V6.1でのJMSプロバイダー選択のポイント
‡ メッセージング・プロバイダーの選択基準項目
‡ JMSプロバイダー選択のポイント
69
69
メッセージング・プロバイダーの
選択基準項目
„
WAS V6.1では以下のJMSプロバイダーが選択可能
‹
‹
‹
‹
„
ME
MQ
サービス統合デフォルト・メッセージング・プロバイダー(SIBus)
WebSphere MQ JMS プロバイダー
バージョン 5 デフォルト・プロバイダー(組み込みメッセージング)
汎用 JMS プロバイダー
選択基準項目
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
サポート・プラットフォーム
サポート言語
既存アプリケーションへのインタフェース
サポート・トランスポート
他環境/製品へのブリッジ/アダプター機能
負荷分散機能
V6.x Application Server
可用性向上機能
運用監視機能/インタフェース
ME
ME
¾ 運用管理製品
パフォーマンス
実績
アプリケーション
JMS
必要スキル
MQ
宛先
価格
etc…
バッファー
derby
/DB2 etc.
DBMS
バッファー
ログ
データ
ストア
ログ
キュー
ファイル
70
WAS V6ではJMSプロバイダーとして以下の４つの選択肢があります。
・デフォルト・メッセージング・プロバイダー
サービス統合バスのメッセージング・エンジンにより実装されます。
・WebSphere MQ
WAS V5と同様にJMSプロバイダーとしてMQのキュー・マネージャーを直接利用可能です。
・一般JMSプロバイダー
サード・パーティーのメッセージング・プロバイダー製品を利用する場合に使用します。
・V5 デフォルト・メッセージング
WAS V5 組み込みメッセージングの互換性のための選択肢です。
V5 デフォルト・メッセージング・プロバイダーは、WebSphere MQクライアント・リンクを経由して、サービ
ス統合バスとともに使用することもできます。
メッセージ・ドリブン Bean を使用するには、 JMS プロバイダーは、JMS Application Server Facility
(ASF) 機能をサポートしているか、JCA V1.5 に定義されているインバウンド・リソース・アダプターをサポー
トしている必要があります。
一般にJMSプロバイダーを選択する際に検討すべき項目は以下の観点があります。（サポート・プラット
フォーム、サポート言語、サポート・トランスポート、他環境/製品へのアダプター機能、負荷分散機能、可
用性向上機能、運用監視機能、インタフェース、パフォーマンス、実績、必要スキル、価格、etc…）
WAS V6 JMS 1.1サポートの概要については「WebSphere Application Server V6 Announcement
Workshop」、”WASV6プログラミングモデル Java2 Enterprise Edition 1.4”セッション資料をご参照下さい。
70
JMSプロバイダー選択のポイント
„
‹
MEはWASに同梱されており、ライセンス料は発生しない
WASでの運用管理の統一、HAマネージャーによる可用性向上を図ることができる
WAS内でパーシスタント・メッセージを使う場合の考慮点
‹
„
データ・ストアの冗長化/チューニング/運用/保守必須
既存MQシステムとの連携が多い場合
‹
ME/JMSの制約を考慮
¾
¾
¾
¾
MEはMQクラスターに参加できない
MEはCCSID=5026,5035のキュー・マネージャーとは接続できない
MEはJMSしか利用できないため、機能の制約がある（メッセージIDの設定不可など)
⇒既存MQアプリケーションがメッセージIDの設定を求めている場合問題となる
MEでは、WASコンソール(wsadmin)/JMXによる運用管理の仕組み、手順を新たに作成する必要がある
⇒MQ用の運用管理ツールは利用できない
WAS + ME
API
運用管理
可用性
コスト
実績
ME
WAS内でノン・パーシスタント・メッセージのみを行う場合
‹
„
MQ
JMSのみ
WASコンソールですべて管理可能
データ・ストアの運用管理が必要
HAマネージャーによる切替
（MQリンク再接続にはネットワーク・アドレスの引継ぎ
必要）
MQクラスターには参加できない
MEはWASに同梱
クラスター構成ではDS用RDBライセンスが別途必要
本番使用している例がある
WAS + MQ
JMSとMQ Base Javaを利用可能
WASコンソールでJMSオブジェクトの管理
MQの運用管理が必要
OSのHA機能を利用
MQクラスターの利用
MQのライセンスが別途必要
多数の稼動実績あり
大規模、高パフォーマンスの基幹系システムにも採用
71
WAS内でノン・パーシスタント・メッセージのみを行う場合は、MEで十分に実現する事が出来ます。
WAS内でパーシスタント・メッセージを使う場合は、データ・ストアの冗長化/チューニング/運用/保守必
須であり、SIBusリンクでは送受信のメッセージ転送状況を把握するインタフェースは未公開である点を考
慮する必要があります。
また、既存MQシステムとの連携する場合、ME/JMSの制約がありますので、十分に考慮して下さい。
71
このセッションで学習したこと
„
Messaging（メッセージング）とは
‹
„
WASV6.1におけるメッセージング環境
‹
„
WASV6.1でサポートされるJMSメッセージングについて確認しました。
メッセージング基盤設計
‹
‹
‹
„
メッセージングとはどういうものなのか、その特徴・使用方法について確認し
ました。
メッセージング基盤の計画について確認しました。
接続方式、キュー配置、ネットワーク・リンクについて確認しました。
負荷分散/可用性の向上について確認しました。
WAS V6.1でのJMSプロバイダー選択のポイント
‹
WASV6.1でのMQ/MEの選択指針について確認しました。
Messaging
ME
MQ
ESB
72
72
参考資料
‡ ESB(Enterprise Service Bus)を実装する製品群と役割分担
‡ Hints&Tips
73
73
ESBを実装する製品群と役割分担 (1/2)
„
ESB(Enterprise Service Bus)とは
‹
複数の製品が協調して実装、構成される汎用的なデータ転送/変換基盤
¾
„
要件に応じた最適な製品の組合せ/設計/実装/運用/保守により実現
ESBを実装する各製品の特徴と役割
‹
WebSphere Application Server(WAS)
¾
Web/Java/J2EE/Webサービス環境のアプリケーション実行基盤
z
z
¾
Network Deployment環境による一元管理機能/拡張性の提供
WASクラスタリング構成による高度な負荷分散/可用性機能の提供
Service Integration Bus(SIBus)=WAS内のESB実行基盤
z
Service Integration Bus Web Service enablement(SIBWS)=WASでのWeb Service仲介機能
z
Messaging Engine(ME)=WAS内のメッセージング基盤
Mediation
9
z
9
SOAP/HTTP,SOAP/JMS,EJB/IIOP,JAX/RPC,WSSecurity,WSTransaction,etc
XMLメッセージの変換を行うBeanの呼び出しインタフェース,Mediation用クラスの提供
74
74
ESBを実装する製品群と役割分担 (2/2)
„
ESBを実装する各製品の特徴と役割
‹
WebSphere MQ
¾
負荷分散/高可用性/高信頼性メッセージング基盤
z
z
z
¾
各種環境との接続性
z
z
z
z
z
‹
JMSよりも歴史が長く、機能は豊富
MQクラスターによる高度な負荷分散/可用性/拡張性の提供
MQ/zにおけるログSW二重化,キュー/チャネル共用
MQ API(アセンブラ,C,C++,COBL,PL/I,RPG,NET,VB,JMS,etc)
アプリケーション稼動環境へのブリッジ環境(IMS,CICS,JMS,Notes,Siebel,etc)
ネットワーク・プロトコル変換(TCPIP V4/V6,SNA,etc)
ベンダー提供のMQFAP/MQIによるメッセージング機能(HULFT,日立/富士通ホスト)
WBI Adapterとの連携
WebSphere Message Broker(WMB) MQ基盤⇔標準技術間のデータ・フォー
マット/トランス・ポート変換機能の開発/実行基盤
z
z
SOAP1.1/1.2,WSDL1.1,XML1.0/1.1,XPath1.0,JMS1.1,J2SE1.4,HTTP/HTTPS,etcをサポート
複雑なメディエーション機能の提供
9
‹
タグ/デリミッター区切り⇔固定長/可変長/繰返し⇔XML間の変換
WebSphere Business Integration Adapter(WBI Adapter)
¾
各種パッケージ製品との連携(SAP,People,etc)
75
75
ESB実装イメージ
エンタープライズ・システム
パッケージ・ソフト
SAP,People etc.
既存システム
既存基盤
ベンダー独自仕様
JMS/MQI
既存
資産
MQチャネル
MQブリッジ
WBI Adapter
MQ基盤
業界標準仕様
(SWIFT、EDI関連、
etc)
XML/タグ&デリミッタ/ユーザー独自仕様
取引先
Web
ｻｰﾋﾞｽ
フォーマット変換、コンテンツ・ベース・ルーティング
SOAP
HTTP/JMS
MQI
WMB/WMQ
SOAP HTTP/JMS
ESB
MQチャネル(MQリンク)
XML形式
SI-Bus
ME
本社/支社
Mediation
ME
ME
SOAP HTTP/JMS
XML形式
SI-Bus
ME
支店/営業所
Mediation
ME
ME
SOAP HTTP/JMS
Web
CGI
JMS/MQI
Bean
HTTP
76
76
アプリケーション構造と接続パターン
„
アプリケーションの再利用性を高め、迅速かつ柔軟に連携させる
‹
‹
コネクティビティやメディエーション（ルーティング、フォーマット変換）ロジック
を分離
アプリケーションのサービス化
Direct Connectivity
Message Queuing Message Brokering
通信ロジック
通信ロジック
コードの構造
メディエーション
通信ロジック
通信ロジック
メデイエーション
制御ロジック
メディエーション
制御ロジック
Service Brokering
メディエーション
制御ロジック
アプリケーション
アプリケーション
アプリケーションに
すべてのロジックが
入る
アプリケーションから
通信ロジックを切り離す
制御ロジック
アプリケーション
アプリケーションから
通信ロジックとルーティング、
フォーマット変換ロジックを
切り離す
アプリケーションは
サービスの集まり
アプリケーションから
ビジネスロジックを減らし、
サービス化する
77
柔軟性と再利用性
77
トランスポート層の検討
„
Webサービスのトランスポートをメッセージ・キューイングで実現
‹
‹
Webサービスは、SOAP形式（XML）のメッセージを使用して通信を行なう
Webサービスの標準では、SOAPを伝送するトランスポートは規定されていない
データ・フォーマット
トランスポート
‹
SOAP
HTTP
JMS
SOAP/HTTP
SOAP/JMS
etc...
トランスポートにJMS（MQ/ME）を使用することで、得られるメリット
¾
¾
メッセージのパーシスタント化による、障害時のメッセージのリカバリー
製品による、Webサービスの負荷分散/可用性向上
z
z
¾
¾
MEパーティショニング
MQクラスター
既存のMQネットワーク（キューやチャネル定義など）との連携
既存のMQアプリケーション/ブリッジとの連携
z
SOAP⇔既存MQアプリケーション変換が必要
9
WMB(WebSphere Message Broker)などを利用
SOAP
Webサービス・
クライアント
Webサービス・
プロバイダー
78
SOAP/MQ
78
＜参考＞SOAP/MQ
„
„
MQ V6で提供されるSOAP/JMS機能を、「SOAP/MQ」と呼ぶ
Webサービス・フレームワークに対応したSOAP/JMS用ライブラリの提
供
‹
Apache Axisと .Net のWebサービス・フレームワークに対応
¾
¾
‹
各フレームワークの通信部分を置き換える形で実現
Axisと.Net のWebサービス・クライアント/ プロバイダー間の通信も可能
V5.3までSupportPac（MA0R）で提供されていた、MQ独自の機能
¾
WAS の SOAP/JMS とは別機能
Webサービス・クライアント
Webサービス・プロバイダー
SOAP/MQ
SOAP/MQ
リスナー
SOAP/MQ
センダー
Webサービス
クライアント フレームワーク
アプリケーション （Axis/.Net)
Webサービス
サービス
フレームワーク アプリケーション
（Axis/.Net)
参考：SOAP/HTTPとの比較
HTTP
Transport
SOAP/HTTP
HTTP
Transport
79
今回提供される機能
79
WESBとWMB
„
ESBの主要製品
‹
‹
„
WebSphere ESB
WebSphere Message Broker
→新製品
→新バージョン
製品のポジショニング
WebSphere ESB
・Web サービス間の接続とデータ変換の
機能を提供
（J2EE環境内での接続）
SOAP/HTTP, SOAP/JMS,
WebSphere MQ, WebSphere Adapters
WebSphere Message Broker
・Webサービス以外も含むユニバーサル
な接続とデータ変換を提供
（J2EE環境と非J2EE環境の接続）
SOAP/HTTP, SOAP/JMS,
WebSphere MQ, WebSphere Adapters
＋more・・・
・XMLフォーマットのみサポート
・XML以外にもユーザー定義フォーマット、
業界標準フォーマットをサポート
・WebSphere ASをベースとして、実行エ
ンジンはJavaで実装されたミドルウェア
・WebSphere MQをベースとして、実行
エンジンはC++で実装されたミドルウェア
Core ESB
Advanced ESB
80
80
WebSphere ESB
„ WebSphere
ESB
‹サポート・プロトコル
¾SOAP/HTTP,
SOAP/JMS, WebSphere MQ (※), WebSphere Adapters
※MQリンクを使用してMQネットワークに接続可能
‹サポート・フォーマット
¾XML
‹標準提供変換機能
¾
¾
¾
¾
¾
¾
¾
Stop Mediation
Fail Mediation
MessageFilter Mediation
XSLT Mediation
DatabaseLookup Mediation
MessageLogger Mediation
CustomSCA Mediation
‹開発環境
¾WebSphere
Integration Developer
81
81
WebSphere Message Broker
„ WebSphere
Message Broker
‹サポート・プロトコル
¾SOAP/HTTP,
SOAP/JMS, WebSphere MQ, WebSphere Adapters, Files,
Telemetry(SCADA), Mobile(MQe), Real Time, Multicast, Tibco RV
‹サポート・フォーマット
¾XML
¾固定長メッセージ：
C structures, COBOL copybook,
業界標準のSWIFT, EDIFact, EDI-X.12, ACORD/AL3, HL7, HIPAA, FIX, TLOG,
¾アダプター系：CICS, VSAM など
¾その他：MIME , Base64(DSTX), GZIP/ZLIB(DSTX),TAR(DSTX)
¾TDS：
‹実装可能な機能（標準提供機能）
¾多くの標準提供ノードを提供(「WMB標準提供ノード一覧」参照)
‹開発環境
¾WebSphere
Message Broker Toolkit
(WebSphere MBに同梱）
82
82
WESBとWMBの比較表
項目
WebSphere ESB
WebSphere Message Broker
特徴
J2EE環境でのWeb Service接続をサポート
J2EE環境とと非J2EE環境を接続.
Webサービスと既存システムの接続.
Webサービスのサポート
●
●
メッセージ変換＆プロトコル変換
●
●
高度なルーティング＆メッセージ
ロギング
●
●
XMLデータ・フォーマットの変換
●
●
Real-Time Event Processing
●
●
Complex Event Processing
－
●
XMLデータ・フォーマット以外の
変換
－
●
センサーとデバイスのインテグ
レーション
－
●
CICSやVSAMとのネイティブなイ
ンテグレーション
－
●
Real-Time Database Interaction
－
（１テーブルの参照のみ可能.JDBCアダプ
ターを併用すれば、更新などの作業も可能
になる）
●
83
83
＜参考＞WMB標準提供ノード一覧
役割
外部インターフェース
メッセージ変換
データベース・アクセス
フロー制御
エラー処理
その他
ノード名
説明
MQInput/MQOutput/MQGet
MQとの入出力、N in M outフローが可能。
MQReply
MQOutputのサブセット．MQMD.ReplyToQにメッセージ送信
JMSInput/JMSOutput
JMS1.1プロバイダーとの接続/入出力(MEへのJMSクライアント接続)
MQeInput/MQeOutput
MQEveryPlaceとの入出力
SCADAInput/SCADAOutput
SCADA端末との入出力
HTTPInput/HTTPReply/HTTPRequest
WebServiceとの入出力
MQOptimizedFlow/RealtimeInput/RealTimeOptimizedFlo
w
JMS/JMS(IP)との入出力（Pub/Sub通信のみサポート）
Publication
PubSub通信．MQ、MQEveryPlace、SCADA端末にメッセージ送信
Compute
ESQLによる変換、データベース・アクセス（汎用）
Java Compute
Javaによる変換ロジックの開発が可能
Mapping
GUIマッピングによる変換、データベース・アクセス（読み込みのみ）
Extract
Mappingのサブセット．データベース・アクセスなし
JMSMQTransform/MQJMSTransform
JMSメッセージとMQメッセージの変換
XMLTransform
XSLTによる変換
Database
ESQLによるデータベース・アクセス（汎用）
DataDelete/DataInsert/DataUpdate
GUIマッピングによるデータベース・アクセス（削除専用/挿入専用/更新専用）
Warehouse
メッセージ全体をBLOBフォーマットでデータベースに挿入
Filter
ESQLによる条件判断で処理を分岐
RouteToLabel/Label
Labelノードに処理を移動/処理の移動先
AggregateControl/AggregateRequest/AggregateReply
Aggregator機能（複数宛先への要求送信、応答メッセージを待ち受けて合体）
TimeoutControl/TimeoutNotification
メッセージフローの時刻起動
FlowOrder
分岐フローの実行順序制御
Throw
例外の生成
TryCatch
例外の補足
Trace
メッセージのダンプ
ResetContentDescriptor
メッセージ・パーサーの変更（メッセージの再パース）
Input/Output
サブ・フロー機能（サブフローへの開始点/サブフローの出口点）
Passthrough
サブ・フローの識別
妥当性検査（Validate)
入力メッセージとメッセージ定義の妥当性検査
Check
メッセージ・パーサーのチェック
84
※下線はv6での新規追加ノード
84
＜参考＞外部宛先と別名宛先の違い
„
共通
‹
定義のみの宛先
¾
¾
„
実体のある宛先をポイントするため
メッセージが格納される実体のある宛先ではない
関係
‹
外部宛先⊆別名宛先
¾
¾
„
ME
別名宛先で上書き可能な属性(※別名宛先でのみ設定可能な属性)
宛先名(※) / サービスの品質 / デフォルト優先順位 / 送信許可 / 受信許可(※) / 応答
宛先(※)
※外部宛先名はキュー宛先名と同一となる
応答宛先バス(※) / デフォルトの転送ルーティングパス(※) / 送信検査をターゲット宛先
に委任(※)
外部宛先で上書き可能な属性
z サービスの品質 / デフォルト優先順位 / 送信許可
使い分け
‹
別名宛先を採用する場合
¾
¾
‹
上記の属性を詳細に設定したい場合
ターゲットの宛先がMQ上のキューを指し示す場合、外部宛先でも可能Information Center
に明記なし)
外部宛先
¾
¾
¾
別名宛先のみで設定できる
上記属性を設定する必要がない場合
同一名称の別SIBus上の宛先を単に示したい場合
85
85
＜参考＞外部宛先と別名宛先の違い
＜別名宛先設定項目＞
ME
＜外部宛先設定項目＞
86
86
＜参考＞ブートストラップ・サーバー
„
ME
リモート接続先に複数のサーバー/メッセージング・エンジンが稼動している場合
‹
ブートストラップ・サーバーによるメッセージング・エンジンの自動選択が可能
¾
ブートストラップ・サーバーとは
z
ブートストラップのみ担当し、メッセージング・エンジンを稼動させないサーバー
⇒コネクション数分散が可能
＜ブートストラップなし＞
＜ブートストラップあり＞
Cell
Cell
BUS01
BUS01
AS
AS
ME
ME
SIB_ENDPINT
_ADDRESS
SIB_ENDPINT
_ADDRESS
AS
SIB_ENDPINT
_ADDRESS
AS
AS
ME
ME
SIB_ENDPINT
_ADDRESS
SIB_ENDPINT
_ADDRESS
１．Bootstrap
1.Bootstrap
↓
2.Connect
1.Bootstrap
↓
2.Connect
2.Connect
2.Connect
AS or
クライアント・
コンテナー
AS or
クライアント・
コンテナー
AS or
クライアント・
コンテナー
AS or
クライアント・
コンテナー
AS or
クライアント・
コンテナー
JMSクライアント
JMSクライアント
JMSクライアント
JMSクライアント
JMSクライアント
87
リモート接続先に複数のサーバーまたはメッセージング・エンジンが稼動している場合、ブートストラッ
プ・サーバーによるメッセージング・エンジンの自動選択が可能です。
ブートストラップ・サーバーとは、ブートストラップのみ担当し、メッセージング・エンジンを稼動させない
サーバーです。ブートストラップ・サーバーなしの構成では、最初に接続したサーバー上のメッセージン
グ・エンジンにそのまま接続されます。ブートストラップ・サーバーありの構成では、ブートストラップ・サー
バーによりコネクション数の負荷分散が行われます。
87
＜参考＞MQグループ・メッセージによる順序保証
„
‹
‹
„
複数のメッセージにGroupIDを付加し、グループ化して送受信する機能
グループ化の単位は業務要件に依存する
活用方法
‹
„
転送経路を冗長化しても送受信順序の保証が可能
グループ・メッセージの実装
‹
グループ・メッセージのフォーマット
¾
¾
¾
GroupId グループを識別するための一意のID
MsgSeqNumber グループ内でのメッセージの順序番号（論理順序）
MsgFlags MQMF_LAST_MSG_IN_GROUPで最終メッセージを識別(最終メッセージ以外はMQMF_MSG_IN_GROUP）
PMO.Options =
MQPMO_LOGICAL_ORDER
| MQPMO_SYNCPOINT
MQPUT MD.MsgFlags =
MQMF_MSG_IN_GROUP
MQPUT MD.MsgFlags =
MQMF_MSG_IN_GROUP
:
MQPUT MD.MsgFlags =
MQMF_LAST_MSG_IN_GROUP
MQCMIT
„
MQ
グループ・メッセージ機能とは
G=1|N=1
G=1|N=1
G=1|N=2
G=1|N=3
MQクラスター
MQクラスター
GMO.Options = MQGMO_LOGICAL_ORDER
| MQGMO_ALL_MSGS_AVAILABLE
|MQGMO_SYNCPOINT
| MQGMO_WAIT
G=1|N=3
G=1|N=2
while(GroupStatus == MQGS_MSG_IN_GROUP )
MQGET
MQCMIT
考慮点
‹
‹
‹
JMSでは未サポート
最終メッセージが到着してから、グループの受信処理を始める
グループの単位を大きくしすぎるとパフォーマンス・オーバーヘッドとなる
88
88
＜参考＞MQ接続タグ・オプションによる逐次化
MQ
MQ/zキュー共用環境でのPeer Recovery,Serialized Apllication
„
Group
Attach
CECA
CECB
CF
QMGR
障害
MQCONNX MQG1
MQCNO_SERIALIZE_CONN_TAG_QSG
CEC1
ConnTag = x'aaaaaaaaaaaa'
MQGET
入力キュー
SQL UPDATE
Application
DB
MQPUT
MQCONNX MQG1
MQCNO_SERIALIZE_CONN_TAG_QSG
ConnTag = x'aaaaaaaaaaaa'
MQGET
SQL UPDATE
MQPUT
QMGR
QMGR
出力キュー
CHIN
CHIN
QMGR
MQPUT
MQGET
QMGR
89
89
＜参考＞MQ接続タグ・オプションによる逐次化
„
Peer Recovery
‹
‹
キュー･マネージャー障害時に，同一キュー共用グループに属する他のキューマネージャーが障害
の検知，UOWの解決を行い，処理を引き継ぐ
MQによりUOWの解決ができない場合
¾
„
MQ
'RESOLVE INDOUBT'コマンドでの強制コミット/バックアウトが可能
z
CICS,IMS,RRSとの間でInboubtとなっている場合
Serialized Application(メッセージ処理順序の逐次化)
‹
キュー単位でFIFOの遵守が必須である場合 ⇒ 入力キュー:アプリケーション = 1:1
MQOO_INPUT_EXCLUSIVEにより共用キューを占有可能
‹
キュー･マネージャー障害時の考慮点
‹
¾
¾
¾
既存のアプリケーションをそのまま移行可能
Peer Recoveryが行われ、他キュー･マネージャー上で起動されるタスクにより処理が継続される．
メッセージがバック･アウトされる間でのWindowでメッセージ･シーケンスの逆転が生じる可能性がある
‹
MQによる逐次化
‹
同一のconnecting tagを指定して､複数のサーバーアプリケーションが稼働している場合
¾
¾
¾
MQCONNX発行時connection tagを指定してキューマネージャーにコネクトする
MQが該当のconnecting tagのUOWを監視しFIFOを守る．
9 Primary アプリケーションがMQCONNX serialize option､connection tagを指定しコネクトする
9 SecondaryアプリケーションにTake Overされた時､Primary アプリケーションの
全てのUOWがバックアウトされないとコネクトは失敗する．
z
MQRC_CONN_TAG_IN_USE (2271, X'8DF')
z
MQRC_CONN_TAG_NOT_USABLE (2350, X'92E')
90
z
MQRC_CONN_TAG_NOT_RELEASED(2344, X'0928') など
90
参考リンク
„
WebSphere AS V6.1 Information Center
‹
„
WebSphere Developer Domain
‹
„
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
http://www-6.ibm.com/jp/software/websphere/developer/
MQ設計★虎の巻
‹
http://www.ibm.com/jp/software/websphere/developer/mq/toranomaki/index.html
91
91