Aggregation サンプルの拡張

このトピックは、提供されている単純な集約フローをさまざまな要件に合わせて変更する方法を説明しています。 この説明は、この製品のバージョン 5 およびそれ以前のバージョンから既存の集約フローを移植する場合にも役立ちます。

ファンアウトにおける集約状態制御

Aggregate Control ノードの Control ターミナルは、特定の集約操作の状況およびトラッキング情報の入った制御メッセージを伝搬するために使用します。 これは以下の 3 とおりの方法で使用できます。

  1. 切断状態のまま。
  2. Aggregate Reply ノードの Control 入力ターミナルに直接接続する。 これは、両方のノードが同じメッセージ・フローにある場合のみ該当します。
  3. MQMD を追加する Compute ノードを経由して、MQOutput ノードに接続する。 この場合、制御メッセージがユーザー定義のキューに書き出されます。 対応する Aggregate Reply ノード (たいていは別個のフローにある) の Control ターミナルには、このキューから読み取りを行う MQInput ノードが接続されています。 バージョン 5 およびそれ以前のこの製品の既存の集約フローは、この方法で正しく動作するかもしれません。

いずれかのオプションを選ぶ際に留意したい要素は以下のとおりです。

この製品の前のリリースの場合、オプション 1 を選択できたのは、Aggregate Control ノードのタイムアウト構成設定をゼロに設定した (つまり集約操作がまったくタイムアウトにならない) ときだけでした。 バージョン 6 の製品の場合、オプション 1 は、集約タイムアウトを使用するかどうかに関係なく、すべてのケースの最適な解決策です。 これなら、集約状態を保管するための CPU の使用量は最低限で済み、ファンアウト・フローは単純化されます。

本製品のバージョン 6 でも、オプション 2 および 3 を使用するフローは透過的にデフォルトでオプション 1 になります。 すなわち、Aggregate Control ノードの Control ターミナルへの接続は無視されます。 これは、前バージョンの製品からの集約フローを書き直すことなく、その集約フローの効率を最大にするためです。 この動作を逆にして、Control ターミナルが接続されている場合に、その Control ターミナルに制御メッセージが送信されるように することができます。 それには、環境変数 MQSI_AGGR_COMPAT_MODE=ON をブローカーの始動環境にエクスポートします。

オプション 2 は、タイムアウト処理の点ではオプション 1 と機能的に同等ですが、Control ターミナルからのメッセージ伝搬や Aggregate Reply ノードの後続処理に、追加の処理オーバーヘッドが伴います。 このオーバーヘッドは、オプション 1 と同様、Aggregate Control ノードの Control ターミナルを接続しないことで回避できます。

オプション 3 は選択可能な選択肢のうち最も複雑なものです。このオプションを選択するならメッセージ集約のパフォーマンスおよび動作に関係した影響があることを認識しておく必要があります。 集約メカニズムの処理が最も効率的であるためには、ファンイン・メッセージ・フローの Aggregate Reply ノードが、In ターミナルでメッセージを受け取るのに先立って、ファンアウト・メッセージ・フローの Aggregate Control ノードから情報を受け取っておく必要があります。

場合によってはこのようにならないことがあります。たとえば、ファンアウトされた要求メッセージに対する処理が非常に高速に実行される一方で、Compute ノードの処理が原因で Aggregate Control ノードの Control ターミナルからのメッセージの配信が遅れる場合などです。 これは Aggregate Reply ノードの処理の問題の原因となる可能性があります。
しかし、そうではあっても、Aggregate Reply ノードで「不明なメッセージ・タイムアウト」をゼロに設定しないでおけば、集約は正しく完了します。 この場合、不明の応答は保管されて、タイムアウト期間の後に再処理され、それらはこの時点で制御状態情報に統合されます。 不明なメッセージのタイムアウトの満了が原因で生じた遅延の後であっても、集約操作は正しく完了します。
「不明なメッセージ・タイムアウト」をゼロに設定した場合、制御メッセージより先に着信する応答は、Aggregate Reply ノードの Unknown ターミナルに直接伝搬され、集約データの残りとは統合されません。

オプション 3 は、以下の省略イメージのようになります。

制御メッセージ出力があるファンアウト・フロー (省略表示)
AddMqmd Compute ノードには以下に挙げるものに類似した ESQL が含まれ、制御メッセージをキューに書き込むことができます。

CREATE COMPUTE MODULE AggregationOut_AddMqmd
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET OutputRoot = InputRoot;
CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN 'MQMD';
SET OutputRoot.MQMD.StrucId = MQMD_STRUC_ID;
SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION;
RETURN TRUE;
END;
END MODULE;

ファンアウトにおけるトランザクション管理

制御情報が Aggregate Control ノードに保管されるより前に、応答メッセージがファンイン・フローによって受け取られる可能性を回避するには、ファンアウト・フローの MQInput ノードのトランザクション・モードを「はい」に設定する必要があります。

ファンアウト・フローがトランザクション制御下で実行されていない場合、MQOutput ノードが集約ファンアウト要求メッセージを書き出すたび、そのメッセージは呼び出されるアプリケーションによって即時に処理を受けることになります。 このアプリケーションの対応によっては、制御情報が保管されるより先に、Aggregate Reply ノードが応答を受け取ることになります。

Aggregate Control ノードの Control ターミナルが Compute ノードと MQOutput ノードに接続されている場合、つまりファンイン・フローとファンアウト・フローが別々のメッセージ・フローに置かれている場合、同じ問題が発生する可能性があります。 ファンアウトがトランザクション下で実行されるとしても、トランザクションの及ぶ範囲は MQOutput ノードによるメッセージの書き込みまでなので、ファンイン・フローの Control 分岐の処理中に、応答は同じように不明として処理される可能性があります。 これについては、上記のセクションのオプション 3 で説明しています。

どちらの場合も、Aggregate Reply ノードで「不明なメッセージ・タイムアウト」をゼロに設定しないでおけば、集約は正しく完了します。 不明の応答は保管されて、指定された秒数の後に再処理され、それらはこの時点で制御状態情報に統合されます。 不明なメッセージのタイムアウトの満了が原因で生じた遅延の後であっても、集約操作は正しく完了します。「不明なメッセージ・タイムアウト」をゼロに設定した場合、制御メッセージより先に着信する応答は、Aggregate Reply ノードの Unknown ターミナルに直接伝搬され、集約データの残りとは統合されません。

このセクションと前のセクションの両方を要約すると、Aggregation ファンアウト・フローの最も効率的な設計を行うには、以下の点を確認する必要があります。

これら 2 つの設計の推奨事項を採用すれば、前述のタイムアウト問題は起きません。 ただし、これらの推奨に従うことが何らかの理由で不可能な場合、Aggregate Reply ノード上で「不明なメッセージ・タイムアウト」パラメーターをゼロ以外の値に設定すれば、確実に集約操作を正常に完了させることができます。

ファンインにおけるトランザクションのコンテキスト

Aggregate Reply ノードには、Out、Unknown、および Timeout の 3 つの非エラー出力ターミナルがあります。 トランザクションのコンテキストに特別な注意を払いつつ、これらの異なるターミナルからメッセージが送信される時および理由を理解することは重要です。 トランザクションのコンテキストは、MQInput ノードによって所有される場合と (これは、着信メッセージによって Aggregate Reply ノードからの出力がトリガーされる場合に生じます)、Aggregate Reply ノード自身によって所有される場合とがあります。

トランザクション・コンテキストが Aggregate Reply ノードによって所有される場合、その意味体系は通常どおりですが、トランザクションの制御の中心となるのは Aggregate Reply ノードであって、MQInput ノードではありません。 これはつまり、メッセージ・フローの後の部分でエラーが生じると、MQInput ノードではなく Aggregate Reply ノードがロールバックし、このノードの Catch ターミナルにメッセージが伝搬されるということを意味します。 Aggregate Reply ノードが所有するトランザクションのコンテキストの中で Aggregate Reply ノードから伝搬されるメッセージは、MQInput ノードから直接提供されるわけではありません。Aggregate Reply ノードがそのフロー呼び出しの入力ノードとなります。

Aggregate Reply ノードのトランザクションの動作は、「トランザクション・モード」構成パラメーターによって制御されます。 この設定と MQInput ノードの設定は必ず同じものにして、Aggregate Reply ノードからの出力がすべて同じレベルのトランザクションの制御の下に置かれるようにする必要があります。

MQInput ノードのトランザクションの制御の下にあるのは、次の状態です。

Aggregate Reply ノードのトランザクションの制御の下にあるのは、次の状態です。

ファンインにおけるスレッド不足の回避

Aggregate Reply ノードには、In および Control の 2 つの入力ターミナルがあります。 Control ターミナルがオプショナルであることに留意してこれらのターミナルの両方を使用する場合、データを Aggregate Reply ノードに提供する最も効率的な方法は、ファンイン・フローのための単一の MQInput ノードを設け、その後に Filter ノードを続けることです。 Filter ノードは、必要に応じて、Aggregate Reply ノードの In または Control ターミナルに着信メッセージを経路指定するために使用します。 メッセージ・フロー内で 2 つの MQInput ノードを (1 つを In ターミナルに、1 つを Control ターミナルに) 使用する代わりに、この方法を使用してください。 ファンイン・フローは、以下のようでなければなりません。
フィルター処理のあるファンイン・フロー (省略表示)
Filter ノードは、以下に示すものと類似の ESQL モジュールを必要とします。これにより、メッセージは Aggregate Reply ノードの適切なターミナルに確実に経路指定されます。

CREATE FILTER MODULE FanIn_Filter
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
IF Root.XML.ComIbmAggregateControlNode IS NULL THEN
RETURN TRUE; -- wired to In
ELSE
RETURN FALSE; -- wired to Control
END IF;
END;
END MODULE;

単一の MQInput ノードを使用すべきなのは、2 つの MQInput ノードの間で分配する追加のスレッド (追加のインスタンスを使用することにより使用可能になる) の数を指定する手段がないからです。 Aggregate Reply ノードの In ターミナルの方がトラフィックがより大きくなる傾向があるので、そちらの入力ノードで実行させるスレッドをより多くするのが最も便利と考えられますが、そのように構成する方法がありません。 したがって、ノードがスレッド不足に陥って、応答メッセージが滞り、集約のメカニズムの速度が低下する恐れがあります。

この説明が当てはまるのは、Aggregate Control ノードの Control ターミナルがキューへの出力に接続されている場合だけです。 Control ターミナルを接続しなければ、このセクションで説明した問題は克服できます。

上記の解決方法が何らかの理由で実施できない場合、最後の手段として、制御メッセージを読み取る MQInput ノードを、単一スレッドで実行するように強制することができます。 これは、MQInput ノード構成の「拡張」パネルで「順序モード」を「キュー配列による」に設定し、「論理順序」を選択することで実現できます。 これによりすべての構成済み追加インスタンスは解放され、他の MQInput ノードにより使用されるようになります。 最初の MQInput ノードのパフォーマンスはかなり制限されるので、これはあくまでも最後の手段として実行するようにしてください。

メインページのアイコン   サンプルのホームに戻る