IBM Integration Bus 大量スレッド生成時の安定性検証

概要

当記事では、IBM Integration Bus（以下 IIB）の統合サーバー上で生成された多数のアイドルスレッドが、稼働中のメッセージフローのパフォーマンスやリソース消費に与える影響について調査した結果を記載します。

IIB の統合サーバー（プロセス）は、メッセージフロー毎に処理インスタンス（スレッド）を起動し、リクエストを処理します。 起動できる処理インスタンスの数はフロー毎に最大値を設定することができ（フローの「追加のインスタンス」設定）、統合サーバーはトランザクション量の増加に合わせて、インスタンスを追加起動し、複数のインスタンスで並行処理します。 一度起動されたインスタンスは、トランザクション量が減少した後も破棄されず、次にトランザクションが増えたときに備え、「アイドル状態」として待機します。 当記事ではこのようなアイドル状態のインスタンスを「アイドルスレッド」と表現しています。

一般的には 1 つの統合サーバーにデプロイするメッセージフローは数十本程度であり、各フローの「追加のインスタンス」設定をピーク時のトランザクション量に合わせて適切な値に設定していれば、大量のアイドルスレッドが生じることはありません。

しかし、近年のマシンスペックの高性能化やサービス数、トランザクション量の増加に伴い、1 統合サーバーに搭載するメッセージフローの数も増え、各フローがトランザクション・ピークを迎えた後には、大量のアイドルスレッドが残存する可能性があります。 その場合の懸念点として、CPU やメモリなどリソースへの影響が考えられますが、実際にどの程度影響があるのかはパフォーマンス・レポートや TechNote など公開された情報はありません。

当記事は、IIB V10 パフォーマンス・レポート（※1）のテストケースで使用された WebService フローを使って、アイドルスレッドが多数生成された状態でのパフォーマンスやリソース消費を測定し、その影響や考慮点を洗い出すことを目的としています。 測定結果の数値は、マシンスペックや構成、アプリケーション実装など検証環境・測定条件に依存するものであり、あくまでも目安の一つとして参考にしてください。 また、当検証ではアイドルスレッド増加による影響の傾向を見るため、意図的に極端にアイドルスレッド数を増やした状態で測定していますが、実環境においてこのような状態での動作や性能を保証するものではありません。

※1 IBM Integration Bus Performance and tuning

検証結果

当検証では、測定対象のフロー（検証フロー）に一定の負荷がかかるテストにおいて、アイドルスレッドが増加することで、検証フローの処理性能や統合サーバーのリソース消費がどの程度変化するかを測定しました。

ケース 1 では、アイドルスレッドがない状態で、テストドライバーから検証フローに対しておよそ 500 リクエスト／秒の負荷をかけ、検証サーバーの CPU 消費量が約 80%程度になる状況で測定しています。 以降のケースでは事前に検証フローとは別のフローに一時的に負荷をかけアイドルスレッドの数を 2000 ずつ増やした状態で、検証フローにケース 1 と同等の負荷（500 リクエスト／秒）をかけて測定しています。 ※各ケースとも、検証フローの追加インスタンス設定や各種構成／設定は同じにしています。

下表1 に検証結果を示します。 検証環境の詳細については、記事後半の「検証環境詳細」をご参照ください。

表1 検証結果

検証結果から以下の傾向が見られます。

• CPU 使用率: アイドルスレッド数の増加に応じて、検証フロー処理時の CPU 使用率の増加が見られた。（2000 スレッドごとに 2%程度の増加） 特にカーネル・モード（Sys）の使用率がアイドルスレッド数に比例して上昇していることから、アイドルスレッドの増加がカーネル処理に影響を与えていると考えられる。 ユーザー・モード（User）の使用率については、単純に増加する傾向は見られなかった。
• 消費メモリ: 統合サーバー（DataFlowEngine プロセス）の消費メモリは、アイドルスレッド数を増加したタイミングで増加し、その後アイドル状態となっても消費メモリは減少しない。 アイドルスレッドを 2000 増加するごとに 700MB 程度増加しているが、この値はアイドルスレッド生成用に使用したフローの処理内容やメッセージサイズに依存すると考えられる。 検証フローに負荷をかけているときには消費メモリの上昇はほとんど見られない。
• レスポンスタイム: 1 トランザクションのレスポンスタイムは、アイドルスレッドの増加に応じて増加した。 これはアイドルスレッドの増加によって 1 件当りの処理時間（経過時間）に占めるカーネル・モードでの処理時間の割合が増加したためと考えられる。 なお、上記レスポンスタイムは検証フローがリクエストを受信してから、レスポンスを返すまでのフロー内の経過時間を計測している。
• スループット: アイドルスレッド数が 8,000 まではスループットは劣化しなかったが、10,000 まで増やすとスループットの劣化が見られた（ケース 6）。 ケース 6 でも CPU 使用率は 100%に達していないため、CPU ネックで劣化したのではなく、レスポンスタイムの増加によって検証フローの並列度（10 スレッド）では秒 500 件のトランザクションを処理できなくなった可能性が高いと考えられる。 単純計算では 1 トランザクション当り 20 ミリ秒で処理できれば、10 スレッドで秒 500 件のトランザクションを処理できることになるが、ケース 6 ではフロー内の処理だけで 18 ミリ秒かかっており、その他の内部処理時間も加味し、1 件当りの処理時間が 20 ミリ秒を超えていたとすると秒 500 件のトランザクションは処理できなかったことになる。

考慮点

上記結果からアイドルスレッドが増加する場合の考慮点として以下が挙げられます。

• アイドルスレッド数の増加に合わせて CPU 使用率が増加し、CPU ネックが発生する可能性がある。 CPU 使用率が逼迫している環境ではアイドルスレッドの影響でカーネル・モード処理（Sys）の使用率が上昇すると、その分ユーザー（User）の使用率が減り、フローの処理性能が劣化する可能性がある。
• スレッド数が増加すると統合サーバーのメモリ使用量も増加する。 メモリが逼迫している環境ではメモリ使用量が増え、ページングが頻発するようになるとパフォーマンスダウンにつながる可能性がある。
• レスポンスが遅くなることでフローおよびリクエスターの処理能力が低下する。 1件当りのレスポンスが遅くなると、アイドルスレッドがないときに処理できていたトランザクション量を同じ並列度では処理できなくなる可能性がある。 またリクエスター側も同期処理型の実装をしている場合、IIB からのレスポンスが遅くなることで待ち時間が長くなり、処理量が減少する可能性がある。

アイドルスレッドがフローの性能にどの程度影響を与えるかは環境、構成、フローの実装等に依存するため、大量のアイドルスレッドが発生する可能性のある環境では実際にアイドルスレッドを生成された状況でもフローの性能テストを実施されることを推奨します。

検証環境詳細

製品バージョン:

• IBM Integration Bus V10.0.0.7
• AIX V7.1

検証構成:

• 検証構成の全体図（赤枠内が測定対象）

検証用アプリケーション:

IIB V10 パフォーマンス・レポート提供の WebService 連携アプリケーションを利用

• SOAPConsumer：検証フローとして検証サーバーに配置
• SOAPProvider：スタブフローとしてスタブ・サーバーに配置

IBM Integration Bus V10 Performance Testing Samples

アイドルスレッド生成用フロー:

上記 WebService 連携フローをカスタマイズし、アイドルスレッドを生成するために検証サーバーに配置 Consumer と Provider のセットを 50 組（100 フロー）用意し、各フローは 100 インスタンスで稼働するよう追加インスタンスを設定 各ケースにおいて検証実施前にこれらのフローに一時的に負荷をかけ、アイドルスレッドを生成

テスト・ドライバー:

WebService の負荷ツールとして Apache JMeter V3.1 を利用 http://jmeter.apache.org/

統合サーバーのパラメータ設定:

デフォルトから変更したパラメータ

• HTTPConnector
• acceptCount：180
• maxThreads：360
• ComIbmJVMManager
• jvmMaxHeapSize：1073741824(1GB)

測定方法:

検証実施時の測定対象と測定方法

表2 測定対象と測定手段

検証サーバー・マシンスペック:

• Processor Type: PowerPC_POWER6
• Number Of Processors: 2
• Processor Clock Speed: 4204 MHz
• Memory Size: 7712 MB

ご注意

メッセージフローの動作や消費する CPU やメモリなどのマシンリソースは、メッセージフロー実装、マシンリソース、サーバー構成に依存するため、必ずしも結果の数値が保証されるものではありません。 当記事の記載は、あくまでも目安の一つとして参考にしていただき、実際のパフォーマンスは実環境で測定してください。

当記事は日本アイ・ビー・エム株式会社の正式なレビューを受けておりません。 資料の内容には正確を期するよう注意しておりますが、内容は 2017年4月現在の情報であり、製品の新しいリリース、修正などによって動作／仕様が変わる可能性があります。 この情報の利⽤またはこれらの技法の実施はひとえに使⽤者の責任において為されるものであり、資料の内容によって受けたいかなる被害に関しても⼀切の補償をするものではありません。