9. キャパシティ・プランニング

9.1　必要な情報

今回は分散プラットフォームにおけるWebSphere MQ V5.3のキャパシティ・プランニング方法についてご説明します。

キャパシティ・プランニングを行う際に必要な以下の情報について順番にご説明していきます。

• 事前調査項目
• 見積もるべき項目
• 参考情報(パフォーマンスレポート)

1. 事前調査項目
キャパシティ・プランニングにあたり、最低限知っておくべき情報をまとめます。

　　
(*1)メッセージチャネルはキューマネージャー間接続、MQIチャネルはMQクライアント接続で用いられるチャネルです。

詳しくは本講座の2回「WebSphere MQの特長と主な機能（後編）」を参照ください。

2. 見積もるべき項目
以下の項目を見積もりの対象とします。

3. 参考情報(パフォーマンス・レポート)

c構成ファイル、デフォルト・オブジェクト、エラーファイル等(2で説明)

2. 製品コード、および作業データ(構成ファイル、デフォルト・オブジェクト、エラーファイル等)
製品コードの導入に必要となるディスク容量は、プラットフォーム、導入コンポーネントによって異なります。
また、プラットフォームによっては作業データも含めた形でディスク容量が記載されています。
必要となるディスク容量についてはご使用のプラットフォーム向けのスタートアップ・ガイドを参照ください。

スタートアップ・ガイドは、MQのマニュアル(オンライン・ドキュメント) に含まれています。
ご参考までにAIXプラットフォームのストレージ要件は以下のとおりです。
詳細についてはスタートアップ・ガイド(AIX) を参照ください。

• 製品コード
  • サーバー ：325MB
  • クライアント ：276MB
• 作業データ(構成ファイル、デフォルト・オブジェクト、エラーファイル等)
  • サーバー ：最低50 MB
  • クライアント ：最低15 MB

• 前提条件ソフトウェア
• オプションのソフトウェア
• アプリケーション・プログラム

なお、トレースファイルや、重大エラーやリカバリー不能なエラー等が発生した場合に生成されるFDCファイル(障害の情報が記録されたファイル)を保持するためのディスク容量も運用方式に応じて加味してください。

(参考文書) スタートアップ・ガイド(AIX)

[サーバー]
製品コード ：サーバーの章のサポートされる稼働環境の確認

作業データ ：サーバーの章の作業データ用のファイル・システムの作成

[クライアント]
製品コード ：クライアントの章のサポートされる稼働環境の確認   

作業データ ：クライアントの章の作業データ用のファイル・システムの作成

3. キューファイル

キューに必要となるディスク容量を見積もります。
メッセージ平均サイズ、メッセージ・ヘッダーのサイズ、最大メッセージ滞留数をもとに概算します。
以下はこれまでの算出の考え方を踏まえた概算のための式です。
キューごとに必要サイズを概算し、積み上げて、ディスク容量を見積もります。

<ディスク容量> = <最大メッセージ滞留数> ×<メッセージ平均サイズとメッセージ・ヘッダーのサイズ(500bytes)の合計を512bytes で切り上げたサイズ>

最大メッセージ滞留数には、例えばネットワーク障害でキューからのGET処理が進まない場合に許容値として想定する滞留件数などを当てはめます。

4. ログスペース
ここでは、キューマネージャーの再起動やオブジェクト損傷からの回復時に用いられるログファイルのサイズを見積もります。
ログサイズの見積りの考え方は、ログのタイプ(循環ロギング/リニアロギング)により異なります。
リニアログと循環ログの違いなどについては、本講座第6回「MQ運用管理と監視」を参照ください。

(参考文書) システム管理ガイド
メッセージの消失を確実に回避する(ログ)

• 循環ロギング使用時のログスペースの見積もり方法
  循環ロギングはログファイルを再利用します。
  二次ログファイル生成時を除きログサイズが増加することはありません。
  
  ログスペースは以下のようになります。
  <一次ログスペース> ＋<二次ログスペース>
  <一次ログスペース>、<二次ログスペース>の見積り方法については4.1を参照ください。

• リニアロギング使用時のログスペースの見積もり方法
  リニアロギングはログファイルを再利用しません。
  一次ログスペース、二次ログスペースに加え、非アクティブな(=再始動リカバリに不要になった)ログファイルを保持するスペースも加味する必要があります。
  
  ログスペースは以下のようになります。
  <一次ログスペース> ＋<二次ログスペース> ＋<非アクティブなログファイルを保持するスペース>
  
  非アクティブなログファイルを保持するスペースは運用に応じて見積もり方針を検討する必要があります。
  
  以下は非アクティブなログファイルを定期的にログスペースから削除する運用の場合の見積もり方針の例です。
  
  (見積り方針)
  1.　定期的なログファイルのメンテナンス処理の間(例え日)に発生するログの書き込み量から必要となるスペースを概算し、ログファイルサイズで切り上げたサイズを算出します。
  (これを<一次ログスペース>と<非アクティブなログファイルを保持するスペース>に必要となるサイズと見込みます)
  2.　<二次ログスペース>分を加えたサイズをログスペース全体のサイズとします。
  
  パフォーマンスの観点から二次ログファイルは使用されない方が望ましいので、二次ログスペースはログ書き込み量から概算したスペースに含めず、別途そのスペースを見込むことをお勧めします。
  
  <一次ログスペース>、<二次ログスペース>の見積り方法については4.1を参照ください。
  
  ログファイルへの書き込み量の見積り方法については4.2を参照ください。

4.1.　 一次ログスペース、二次ログスペースの見積もり方法

一次ログスペース、二次ログスペースのサイズは、ログファイルサイズ、一次ログファイル数、二次ログファイル数によって決まります。これらの属性はキューマネージャー作成時に指定できます。

<一次ログスペース> ＝<ログファイルサイズ> ×<一次ログファイル数>

<二次ログスペース> ＝<ログファイルサイズ> ×<二次ログファイル数>

ログファイルサイズは、一次ログファイル、二次ログファイルで同一となります。

二次ログファイルは、一次ログスペースが足りなくなった場合に生成され、一時的に使用されます。

ログファイルサイズ、一次ログファイル数、二次ログファイル数のデフォルト値と指定可能な最大値は以下のとおりです。

(*1)一次ログファイルと二次ログファイルの合計数の最大511となります。
(*2)一次ログファイルと二次ログファイルの合計数の最大255となります。

(参考文書) システム管理ガイド

WebSphere MQ のログのデフォルト

スリープ処理やDBアクセス待ちなどによる長時間にわたるトランザクションは、ログファイルの開放タイミングに影響します。

(未完了のトランザクションのログを含むログファイルは開放されません)

メッセージのサイズや、長時間にわたるトランザクションの有無などにより一次ログスペース、二次ログスペースに必要になる容量は異なります。

以下は一次ログスペース、二次ログスペースの見積り方針についての一例です。

以下の参考文書のログファイルサイズ、ログファイル数についてのガイドに基づいた設定を検討のスタート・ポイントとする方法もお勧めです。
トランザクションレートによっては大きすぎる、または小さすぎる可能性がありますので、想定のトランザクションレートを照らし合わせの上、検討ください。

参考文書に記載の推奨のスタート・ポイント

• ログファイルサイズ：約256 MB(ログファイルの最大サイズ)
• 一次ログファイル数：10
• 二次ログファイル数：10
• 合計のログスペース：約5 GB

(参考文書) Configuring and tuning WebSphere MQ for performance on Windows and UNIX

4.2. 　ログファイルへの書き込み量の見積り方法

ログファイルへの書き込み量の見積りは、それぞれのログレコードのサイズの積み上げによって行います。
ログレコードのサイズは操作によって異なります。マニュアルに記載の表にもとづいて概算します。

(マニュアル抜粋)

ログのサイズの計算(参考文書) システム管理ガイド

ログ書き込みが発生する契機を以下つに分け、ログレコードのサイズや考慮点について説明します。

• メッセージの読み書き(MQPUT/MQGET)により発生するログレコード(4.2.1で説明)
• 運用管理オペレーションにより発生するログレコード(4.2.2で説明)
• チェックポイント生成により発生するログレコード(4.2.3で説明)

4.2.1. 　メッセージの読み書き(MQPUT/MQGET)により発生するログレコード

以下のログレコードが対象になります。

• 持続メッセージの書き込み
• メッセージの読み取り
• 同期点、コミット
• 同期点、ロールバック

◆ 持続メッセージの書き込み/メッセージの読み取り

(ローカル接続およびクライアント接続の場合)

業務アプリケーションの読み書きのログ出力量を見積もります。

業務アプリケーションによ1MQPUTに対して、1MQPUTのログレコード出力を見込みます。

業務アプリケーションによ1MQGETに対して、1MQGETのログレコード出力を見込みます。

(キューマネージャー間接続の場合)

業務アプリケーション1MQPUTに対して、送信側MCAによ1MQGET(トランスミッションキューからのMQGET)、受信側MCAによ1MQPUT(宛先キューに対するMQPUT)が発生します。
業務アプリケーションの読み書きに加え、、MCAの読み書きのログ出力量を見積もります。

業務アプリケーションによ1MQPUTに対して、1MQPUT+1MQGETのログレコード出力を見込みます。
(業務アプリケーションによるMQPUT発行後、MCAがトランスミッションキューに対しMQGETを発行している分を加味します)

業務アプリケーションによ1MQGETに対して、1MQPUT+1MQGETのログレコード出力を見込みます。
(業務アプリケーションによるMQGET発行前、MCAが宛先キューに対しMQPUTを発行している分を加味します)

なお、非持続性メッセージはログ出力の対象とはなりません。

1回の操作あたりのログレコード量は、以下のとおり見積もります。

◆同期点、コミット/同期点、ロールバック

ロールバックの場合、トランザクションに含まれるMQPUT数、MQGET数によって見込まれる出力量は異なります。

1回の操作あたりのログレコード量は、以下のとおり見積もります。

4.2.2. 運用管理オペレーションにより発生するログレコード

以下のログレコードが対象になります。

• オブジェクトの作成
• オブジェクトの削除
• 属性の変更
• メディア･イメージの記録

◆オブジェクトの作成、削除、属性の変更

一般的には、通常運用においてオブジェクトの作成、削除、変更は、発生しない、または頻繁には発生しないと考えられるので、多くの場合考慮は不要です。
発生頻度が高い場合は、見積もることを検討ください。

1回の操作あたりのログレコード量は、以下のとおり見積もります。

◆メディア･イメージの記録

メディア・イメージの記録はログのタイプがリニア・ロギングの場合にのみ実行できます。
この操作を行う場合は、ログ出力量を見積もることを検討ください。

ログ出力量の一般的な見積もりのガイドはありません。
2つの見積りの方法例を紹介します。運用などを踏まえて見積りの方法を検討ください。

なお、メディア・イメージには滞留メッセージも含まれます。メディア・イメージの記録は、できるだけキュー内のメッセージを取り除いた上で取得することをお勧めします。

(例1)キューファイルサイズからログ出力量を見積もる
多くのメッセージが滞留している状態でのメディア・イメージの記録も想定し、キューファイルサイズに安全率を加味したサイズをログ出力量として見積もる。

(例2)実際にメディア・イメージの記録を行いログ出力量を見積もる
メディア･イメージの記録によるログファイルの切り替え回数からログ出力量を概算し、安全率を加味したサイズをログ出力量として見積もる。

4.2.3. 　チェックポイントによるログサイズの増加

以下のログレコードが対象になります。

• チェックポイント

チェックポイントとは、ログに記述されているレコードとキューのレコードが一致する時点(ポイント) で、以下のような条件で発生します。

• 10,000回のログ・レコード出力ごと
• キューマネージャーの起動・停止時
• ログ・スペースが不足してきたとき

(参考文書) システム管理ガイド

チェックポイント機能を使用してリカバリーの完了を確認する

1回の発生あたりのログレコード量は、以下のとおり見積もります。

750 bytes ＋200 bytes ×<アクティブなUOWの数>

＜ログ出力量の概算見積り例＞

業務アプリケーションの稼動により日に出力されるログの出力量を見積もる例です。

(見積もり前提)

• キューマネージャーの起動/停止は日次運用項目ではない
• オブジェクトの作成・削除・属性変更は発生しない
• メディア・イメージの記録は行っていない
• キューマネージャー間接続はない

(業務アプリケーションの特性)

• すべてのMQPUT,MQGETがUOWに含まれており、持続メッセージである
• メッセージの平均サイズ(メッセージ・ヘッダー含む)：2KBytes
• 1日あたりのMQPUTのトランザクション数：7,200
• 1UOWに含まれるMQPUTの数：
• バックアウトが発生するMQPUTのトランザクションの割合：5%
• 1日あたりのMQGETのトランザクション数：7,200
• 1UOWに含まれるMQGETの数：4
• バックアウトが発生するMQGETのトランザクションの割合：5%
• アクティブなUOW数(平均)：4

(A)メッセージの読み書き(MQPUT/MQGET)により発生するログ出力量

ログ出力量

＝<持続メッセージの書き込みによるログ出力量> ＋<メッセージの読み取りによるログ出力量>

＋<コミットによるログ出力量> ＋<ロールバックによるログ出力量>

＝( 750 + メッセージの平均サイズ) ×<MQPUT回数/日> ＋260 ×<MQGET回数/日>

＋750 ×<コミット回数/日> ＋( 1000 ＋12 ×<1UOWあたりのMQPUT数/MQGET数> ) ×<ロールバック回数/日>

＝( 750 ＋2,048 ) ×28,800 ＋260 ×28,800 ＋750 ×13,680 ＋( 1,000 ＋12 ×4 ) ×720

＝80,582,400 ＋7,488,000 ＋10,260,000 ＋754,560

＝99,084,960

(B)チェックポイントにより発生するログ出力量

ログ出力量

＝( 750 bytes ＋200 bytes ×<アクティブなUOWの数> ) ×<チェックポイント発生回数(*1)>

＝( 750 + 200 ×4 ) ×8

＝12,400 

(*1)チェックポイント発生回数

＝<1日に出力されるログ・レコード数> ÷10,000

＝( <MQGET数> ＋<MQPUT数> ＋<トランザクション数(コミット、およびバックアウトの数)> ) ÷10,000

＝( ( 7,200 ×4 ) ＋( 7,200 ×4 ) ＋( 7,200 ＋7,200 ) ) ÷10,000

＝7.2

≒8

1日のログ出力量

ログ出力量

＝(A)メッセージの読み書き(MQPUT/MQGET)により発生するログ出力量 ＋(B)チェックポイントにより発生するログ出力量

＝99,084,960 ＋12,400 

＝約95MB

9.3　メモリー容量

MQが使用するメモリー容量の見積もりを行います。

1. 対象項目

以下の項目についてメモリーの使用量を見積もります。

• キューマネージャーのシステム・プロセス
• チャネル・プロセス
• キュー
• ログ・バッファー
• ユーザー・アプリケーション

設定値や接続アプリケーション数、メッセージ・サイズなどによりメモリーの使用量は変動するものであり、正式なメモリーの使用量の見積もり方法、算出式はありません。
机上での見積もりはあくまで参考値として捉え、精度の高い見積もりが必要な場合には、検証環境でのテストの結果等を踏まえた検討が必要です。

以下の文書の情報を引用していますので、詳細な情報につきましては、こちらを参照ください。

(参考文書)

WebSphere MQ for AIX V7.0 - Performance Evaluations(MP6N)

Configuring and tuning WebSphere MQ for performance on Windows and UNIX

2. 　キューマネージャーのシステム・プロセス

プラットフォームによっても異なりますが、起動直後の状態で数十MB程度使用します。
パフォーマンス・レポートによれば、AIXではデフォルト設定の場合に起動時に90 MB 程度のメモリーの使用が見込まれます。

3. 　チャネル・プロセス

チャネル・プロセス(MCA)によるメモリー使用量は以下のような条件で変動します。

• チャネルの種類：MQIチャネル/メッセージチャネル
• 受信方法：runmqlsr/inetd
• メッセージ・サイズ

全チャネル・プロセスのメモリー使用量を積み上げて概算値を求めます。

MQIチャネル
パフォーマンス・レポートによれば、AIXでは100 KB 以下のメッセージにおいてチャネルあたり1 MB 以下のメモリーの使用が見込まれます。

メッセージチャネル
1つのキューマネージャーとの接続に対し対のメッセージ・チャネルとトランスミッションキューのメモリーの使用を見込みます。
トランスミッションキューのキュー・バッファーのサイズにもよりますが、MQIチャネル2倍+トランスミッションキュー分と考え、1つのキューマネージャーとの接続に対してMQIチャネルの2~3倍程度のメモリーの使用を見込む見積もり方法が考えられます。

フォーマンス・レポートのテストにおいて、AIXでは2 KB の非永続メッセージを処理する際のメモリー使用量は690 KB でした。

4. 　キュー

キューは、オープンされるとメモリーを使用します(オープンしているアプリケーションの数には依存しません)。
よって、同時にオープンされるキューの数から使用量を積み上げて概算値を求めます。

キューのメモリーの使用量はキュー・バッファーのサイズをもとに見積もります。
キューはそれぞれ非永続メッセージ用のキュー･バッファーと永続メッセージ用のキュー・バッファーを持ちます。
キュー･バッファーのデフォルトサイズは以下のとおりです。

キュー・バッファーのサイズはパフォーマンスに影響を与える場合があります。
キュー･バッファーのサイズに応じて見積もってください。

なお、キューはキュー･バッファーとは別に、滞留しているメッセージ数に応じたサイズのメモリーを使用します。
経験上1メッセージあたり数百バイトと考えられますが、そのサイズについての正式な記述はありません。
多くのメッセージ滞留が想定される場合は、この点も考慮して、大きめのサイズを見積もってください。

5. 　ログ･バッファー
ログ・バッファーのデフォルトのサイズは2 MB で、最大サイズは16 MB です。
ログ・バッファーのサイズはパフォーマンスに影響を与える場合があります。
可能な限り大きな領域を割り当てることを推奨します。

6. 　ユーザー・アプリケーション

ユーザー・アプリケーションがMQと通信することで発生するメモリー使用量についての正式な算定式はありません。
チャネルはトランスミッションキューからMQGETしたり、宛先キューにMQPUTする「MQアプリケーション」の一つと考え、
チャネル・プロセスのメモリー使用量と同等と仮定して計算する方法1つの方法と考えられます。

例えば、チャネル・プロセスのメモリー使用量MBと見積もっている場合、
同時接続アプリケーション数ꥄの場合、ユーザー・アプリケーションのメモリー使用量を100 ×1 MB ＝100 MB と見積もります。

9.4　その他のリソース

CPUなどその他のリソースに対し検討します。
スループット、レスポンスタイムといった性能要求を満たすためには十分なリソースを用意する必要があります。

1. 見積もり方法

パフォーマンス・レポートや検証環境でのテスト結果をもとに、実際の環境に一番近いテストケースを選び、マシンスペックの比率から処理性能を見積もります。
CPU数が倍になったからといって、システム全体としての処理性能が倍になるとは限りませんので、余裕を持った見積もりが必要となります。

以下、レスポンスタイムやスループット向上のために必要なリソースを考える上で、注意すべきポイントを挙げます。

2. リソース見積もりに関する注意点

2.1. CPU

システムの処理性能がCPUの処理能力に依存するのは、特に以下のようなケースです。

• 非永続メッセージを扱う

ディスクアクセスをせず、メモリー上で処理を行うためです。

• キューへのメッセージ滞留がない

非永続メッセージでも、キュー・バッファーを超えた分についてはディスクI/Oが発生し、この影響を受けます。

テストケースを元にして必要な処理性能を概算するには、CPUのOLTP値やSPEC INTなどのベンチマーク実績値を使用します。

例えば12CPUのOLTP値120でCPUのときの値が40だった場合、
12CPUのとき60件/秒の処理性能があれば、4CPUでは60 ×( 40 ÷120 ) ＝20件/秒の処理性能を想定します。

一般的にCPU数の追加は、並行処理能力を高め、スループットの向上が期待できます。
一方、より処理能力の高い(動作周波数が大きい、内部アーキテクチャが優れている)CPUの使用は、レスポンスタイムの向上が期待できます。
必要に応じてCPUリソースを増強できるようなモデル選択が重要となります。
なお、スリープ、DBMSのロックによるアクセス待ちなどが発生している場合は、CPUを増強してもトータルとしての処理性能の向上は見込めません。

2.2. 　ディスクI/O

ディスクI/Oが処理性能に大きな影響を与える場合があります。

• 特に永続メッセージを扱う際には必ずログ書き込みが発生するため、高速なディスク装置の使用を検討してください。
• I/Oを並列化して速度向上を図るため、ログを配置するディスクとキューなどのデータを配置するディスクは極力分けてください。
• ディスクI/Oをl極力抑えるため、各種バッファーについて適正なサイズの検討を行ってください。

2.3. 　ネットワーク
ネットワーク帯域がレスポンスタイムに大きな影響を与える場合があります。

• メッセージのサイズ、ピーク時のレート(件/秒)からピーク時のトラフィック量を算出し、必要となるネットワークの帯域(実効帯域)を検討してください。