ラリー・ヤングレン著

4月号のiSeries戦略「リモート・ジャーナル：お悩みを解決するための配管改良工事(http://www.e-bellnet.com/special/vision/vision_0604.html)」では、リモート・ジャーナルが使用される背景について説明しました。たとえば、実運用中のマシンで効率の良いトランスポート・メカニズムを利用してジャーナル･エントリを一番重要なデータベース･ファイルのレプリカやバイト･ストリーム･ファイル、データ・エリア、データ･キューなどを収容している、離れた場所（リモート）へリアルタイムに送信したい場合などです。

今回は、リモートのトランスポート･レイヤーが効率的に使用されるようあらゆるエネルギーを投資するために上記のような環境を微調整するテクニックについて考えてみましょう。いわば、筋肉をつけて脂肪を落とそうというわけです。

このようなトランスポートを間違いなく効率的なものにするためには、何段階かのカスタマイズのステップを経て脂肪を減らします。そうしないと、送信元と送信先の間の通信パイプを脂肪が流れていってしまいます。ステップごとに贅肉の取れた格好の良いジャーナルの流れにしてくれます。

ヒツジとヤギを分ける
一番効率的なアプローチの1つは一番実現しやすいアプローチでもあります。このアプローチは分岐路を作ってジャーナルが送信元マシン上の1つのディスクではなく2つのディスクへ書き込みを行えるように調整できるようにするというものです。ヒツジは右へ、ヤギは左へというわけです。このアプローチは、通常目にするジャーナル・エントリと通常は目にすることのないジャーナル･エントリがあるということに目をつけています。この原理を図1に示します。

この例を説明するために、ジャーナルの送信先側に現れる可能性の高い2つの一般的なジャーナル・エントリのインスタンスについて考えてみます。1つは新しいレコードを物理ファイルに追加する（図1のPT=PUT等）インスタンス、もう1つは通常は目にすることはありませんが図1のAPのようにアクセス･パス（たとえばキーつきの論理ファイル）の変更を行うインスタンスです。

いつも目にするジャーナル･エントリはおなじみのものです（putに対してはR/PT、deleteに対してはR/DL）。いつも目にすることのない方のジャーナル･エントリは送信元側のオペレーティング･システムがファイルの統計属性を回復させたりアクセス･パス（DSPJRNコマンドのINCHIDENTパラメータを使用しているときのみに確認できるI/IVなど）をもっとすばやく回復させたりするときに使用するという理由だけで存在しているものです。このような非表示のエントリは、道から外れて元に戻るときにだけ表示可能ですが、常に存在していて送信元の領域を消費しているという点に注意してください。

非表示のジャーナル･エントリは重要な役割を担っていますが、実運用の送信元側のマシンだけで使用するものです。つまり非表示のジャーナル･エントリはIPL時だけ関係し、送信元側マシンのIPLの完全性を保つのに寄与しているだけです。以上のことをご理解いただければ、非表示のジャーナル･エントリとはヤギのようなもので送信先のマシン（および高可用性再生ソフトなどといったような送信先側のマシンで稼動しているあらゆるソフトウェア）では一切使用しないものであるため、このエントリを送信しようなどとは夢にも思わないでしょう。分岐路で間違った方向へ行かないようにする（非表示エントリをフィルタリングする）ためには、送信元側でCHGJRNコマンドを使用し、その際RCVSIZOPT(*RMVINTENT)を指定してください。たったそれだけです。

以後は、ヒツジたち（送信先側で必要で目に見える有用なジャーナル・エントリ）だけが送信されることになります。ヤギたちは送信元側のディスク領域にある囲いの中に入れられ、送信元側のIPLに異常があったときだけ呼び出されます。この結果、通信トラフィックはほとんどの場合劇的に減少します。

この方法を採用することでおおよそどれくらいトラフィックが減少するのかお知りになりたいでしょう。それに必要なステップはたったの2つです。まず、DSPJRNコマンドでINCHIDENTを指定してジャーナル・レシーバの内容を表示させ、通常は表示されないジャーナル･エントリも表示させます。この表示結果を出力ファイルに送ります。

次に、通常は表示されないジャーナル･エントリの長さを合計するよう出力結果ファイルに対してクエリを発行します。通常は表示されないエントリはJOCODEが「I」になっているのでわかります。クエリは次のようなものになります。

Select sum(JOENTL) from
　 LIB/OUTFILE where
　 JOCODE = T

このテクニックでは、分岐路ができるとディスクへの書き込みが1回ではなく2回行われるのではと心配される方もいるかもしれません。でも心配しないでください。送信元側でのディスクへの2回の書き込みは互いにオーバーラップしており別々のディスク装置に対して一斉に行われます。ヒツジとヤギは並行して群れをなし、それぞれの囲いに向かいます。したがって、通信パイプ上に現れた通常目にするジャーナル･エントリだけが送信先側に送信されます。

その結果、送信元側での応答時間に大きな影響を与えることなく、通信パイプの脂肪も送信先へ送られるバイト数も減少します。

ベルトの穴1つ分締める
高可用性が求められる環境では、一番重要なオブジェクト（データベース･ファイル、データ領域、データ･キュー）の最初のコピーを送信先に送り、これらのオブジェクトに対する更新が送信元／実運用側で発生していないかを監視し、更新があればそれを再生するというのが一般的な目的です。マクロなレベルでみると、初期の高可用性のアプローチは元々、オブジェクトのいずれかの部分に何らかの更新があればオブジェクト全体を送るというものでした。時代の流れとともに、データベース･テーブルの更新のあった列やデータ･キューに追加された個々のメッセージだけといったオブジェクトのローカル部分のみを送信して更新するというアプローチにほとんどの製品が進化してきました。

進化の道の次の曲がり角は、列の中で更新のあったバイトやフィールドだけが転送されて再生されるようにジャーナルを構成するというものでした。これも難なく達成できました。実運用システムのローカルのジャーナルをみてCHGJRNコマンドにMINENTDTA(*FILE) オプションを指定するだけでよいのです。それ以後、データベース中の列が更新されるとその列の中の更新があったセクションだけがジャーナルに置かれ、リモート側に転送されるようになりました。つまり、配管を詰まらせる元となる脂肪を減らすことができたのです。

たとえば、フレッド・パーカーさんが携帯電話の番号を主な連絡先にしたいと変更してきたとしましょう。雇用主側としては、フレッドさんについてたくさんの情報を保管しています。ジャーナル最小化テクニックを活用すれば、フレッドさんについてのすべての情報を送信する必要はありません。フレッドさんの新しい携帯電話番号だけを送信すればよいのです。

列中の一部のフィールドだけが更新されたときの更新前後の列イメージをどのように最小化できるかを図2に示します。リモート･ジャーナル環境でこれを行うのはとても有効です。通信パイプを流れるバイト数を減少させるだけでなく、送信先側での再生ステップがより効率的になるからです。

では、このアプローチはどれくらいの効果を上げるのでしょうか。大量の列の更新はあるものの1つ1つの列中のカラムはそれほど多く更新されないようなアプリケーションの場合は非常に効果があるでしょう。一般的なサード･パーティーのERPパッケージでこのテクニックを試した例を図3に要約してあります。

まだご納得いただけませんでしょうか。ではご自分のシステムのジャーナルにどれくらい脂肪が溜まっているかご覧になってはいかがでしょう。分析用のCプログラムがwww.iseries.ibm.com/db2/journalperfutilities.htmlにあります。（「Journal Analysis Utilities」のカテゴリの「Journal Minimal Data Analysis program」というプログラムを選択してください。）

脂肪を落として引き締まった体に
通信パイプを流れるバイト数をさらに減らすための方法としてよく見逃しがちなのが、2つの論理部分で構成されているジャーナル･エントリを観察する方法です。1つは列のイメージ（エントリ固有データではESDと呼ばれることが多い）自体で、もう1つはそれに付随するメタ・データで、これは送信元側で誰がこの更新を行ったかを記述しているだけです。

図4に示したこの最初の46バイトには、更新を行った特定のプログラム、ジョブ、ユーザーを識別するための情報が保存されています。送信先側の再生用ソフトウェアがこの46バイトのすべてのデータの存在と転送に全面的に依存しているのでなければ（そのようなソフトウェアはほとんどありませんが）、上記の情報の大部分を減量して脂肪を落とすべきでしょう。（一般的なジャーナル･エントリのレイアウトについては後述の「一般的なジャーナル･エントリ」をご覧ください。）

記述メタ・データの形式とサイズはさまざまです。ほとんどのジャーナルではデフォルトで、ジョブ、ユーザー･プロファイル、プログラム名のビッグ3を獲得するように構成されています。アプリケーションがテーブル中の列を更新したりテーブルに新しい列を追加したりするたびに、このビッグ3が追加記述データの46バイト（プログラムで26バイト、ジョブで10バイト、ユーザー･プロファイルで10バイト）を消費します。

たとえば100万件の口座の残高を更新し、別の30万件に詳細レコードを追加し、さらに別の20万件に履歴列を書き出すという夜間バッチ・ジョブがあったとしましょう。このバッチ･ジョブが完了するまでにジャーナルが150万回参照されることになります。しかも1回の参照ごとに余分な46バイトを一緒に引きずります。時刻と、依然として同じユーザー･プロファイル下で依然として稼動され、同じプログラムが実行され、依然として同じバッチ･ジョブが使用されているという更新時刻を伝えるためだけに。

通信パイプ上に送信されるさらに別の数バイトのデータについてこの後すぐに説明します。送信先側のマシンは同じ情報を何度も何度も150万回送ってもらう必要が本当にあるのでしょうか。もしそうでないのであれば、送信するバイト数を減らして通信パイプ上に2度と送信されることがないようにするチャンスです。

こうした脂肪は落としたいでしょうし、もちろん落とすことができます。それには送信元側のローカル･ジャーナルに対して適切なCHGJRNコマンドを発行して、ヘッダや各ジャーナル･エントリを絞り込むようなテクニックを指定するだけで良いのです。

各ジャーナル・エントリの非ESD部分のサイズを小さくするのに使用する主なテクニックは2つあります。1つ目は、この46バイトを全て捨ててしまい、一切保持しないという方法です。この方法は最小固定長ヘッダオプションと呼ばれ、次のようにジャーナル変更コマンドで指定できます。

CHGJRN Jrn(mylib/myjrn)
　 JrnRcv(*GEN)
　 RcvSizOpt(*MINFIXLEN)

もう1つの方法は、記述非ESDヘッダ情報の一部（一番重要と思われる部分）だけを保持し、残りは捨ててしまうという選択的なアプローチです。ビッグ3のうち本当に保持しておきたいものはどれかを判断し、CHGJRNコマンドでFIXLENDTA パラメータの力を活用するだけです。

各ジャーナル・エントリのユーザー・プロファイル部分だけを記録したい場合、コマンドは次のようになります。

CHGJRN Jrn(mylib/myjrn)
　 JrnRcv(*GEN) FixLenDta(*USR)

今回ご紹介したテクニックを採用するとどれくらいバイト数を減らすことができるのかの感覚をつかみたいのであれば、方法は簡単です。まず、DSPJRNコマンドを使用してジャーナル・エントリを格納しているジャーナル・レシーバの集合を表示させて出力ファイルに出力します。出力結果のファイルに対して次のクエリを実行します。

Select count(*) * 46 as BytesReduced
　 From yourlib/yourOutfile
　 Where JOJOB != '*OMITTED'

このクエリは、まだヘッダ中のメタデータを省略していないジャーナル・エントリを分離します。（SMAPPで誘導されたジャーナル・エントリは通常は従来のジャーナル・エントリの中に混じっており、前述の46バイトがすでに削除されていてサイズの小さくなったヘッダとなっていますので、これらについては重複して数えることはしません。） 次に、全ヘッダを持っているジャーナル・エントリを数え、それに46バイトをかければ減らすことができる可能性のある最大のバイト数が算出できます。

トラフィックの渋滞を監視する
こうしたバイト・データが送信元から送信先へひっきりなしに送られるので、トラフィックが時々渋滞する可能性があります。前述のテクニックは無駄なトラフィックの量を減らすことを目的としています。ただし最終的には、通信パイプのサイズがトラフィックのピーク負荷に耐えられるようなものであることを確認する必要があります。しかしトラフィックが次の瞬間に渋滞するかどうかなどわかるのでしょうか。

IBMクライアント・テクノロジ・センターにいる仲間がそれを調べるツールを開発しました。このツールは「非同期リモート・ジャーナル滞留モニタ」と呼ばれ、適度なコンサルト・ライン契約を結べばIBMから入手可能です。あるいはあなた自身で調べることもできますが。

このツールが採用しているテクニックは、サンプリング手法を用いて滞留しているおおよそのトラフィック量を見積もります。つまり、（1）送信側に溜まっている特定のジャーナル・エントリに付けられているタイムスタンプを調べ、（2）その時刻を、送信先側にそのエントリが到着して表示可能になった時刻と比較します。この2つの時刻の違いを補正する調整をすると、おおよそどれくらいのデータが滞留しているかを示す一般的なガイドラインが得られます。滞留している量が少なければ少ないほど良いというわけです。

この滞留量が増えてきたときにリモート・ジャーナル非同期スーパー・バンドル・サポートが作動します。しかしこのオーバードライブ・モードでさえも助けを必要とする場合があります。それはどんなときでしょうか。

トラフィックの自由な流れを保つ
目に付く無駄なバイト・データをすべて取り除き、V5R3へステップ・アップし、オーバードライブ・モードも有効になっています。それでもまだ目標を超えるような送信の滞留がときどき見られるとしたら、他に何か打つ手があるでしょうか。

さらに2つの方法があります。1つは、舞台裏で動いているSLICリモート・ジャーナル送信タスクの優先度を調整するというものです。もう1つは、送信元側マシンの主記憶をステージング領域として使用することで効率を高める方法です。

優先度の調整は、SLICリモート・ジャーナル非同期送信タスクと運用マシン上の資源を取り合っている他のタスクとのバランスをとる場合に有用な手段です。このタスクの優先度はデフォルトで高くなっていますが、CHGRMTJRNコマンドにSNDT SKPTYキーワードを指定することでこの優先度を調整することができます。

さらに、送信元側マシンの主記憶をステージング領域として使用することで送信パイプの流れをスムーズに保つことができます。こうすることでリモート・ジャーナル・サポートがサービスする必要のあるリクエスト数を減らすことができるからです。おなじみの都市高速の相乗り車線（HOV: High Occupancy Vehicle）と考えれば良いでしょう。各車両に2人以上乗車させることで、同じ走行車線を走る車両の総数が減り、他のレーンが渋滞していても相乗り車線だけはスムーズに流れます。

リモート・ジャーナルのユーザーの場合、（CHGJRNコマンドにJRNCACHEキーワードをつけて有効にする）ジャーナル・キャッシングで相乗り車線を走行できるようになります。ジャーナル・キャッシングを使用することで複数のジャーナル・エントリが一斉に通信パイプ上を走り出し、目的地まで一緒に移動できるようになります。この機能を使用することでトラフィックが軽快に流れるようになります。

この仕組みを図5に示します。更新されているオブジェクト集合がたまたまおなじジャーナルに結び付けられているということ以外にまったく共通点のない（同じファイルを更新しようとしているわけでもない）3つのバッチ・ジョブが並列で実行されています。HOVオプションが有効になれば、残りはi5/OSが引き受けてくれます。i5/OSは相乗りさせる機会がないか探し、バス停で列をなして待っているジャーナル・エントリを（たとえ互いに異なるオブジェクトに関連付けられていたとしても）全て1つの束にパックし、通信パイプへ送り出します。

その結果、送信元側での性能が向上し、ディスク参照のローカル性が向上し、通信パイプの使用がより効率的になり、送信先側でのオーバーヘッドが減少します。全員が勝ち組になるわけです。（これ以上何をお望みでしょうか。）

ジャーナル・キャッシング・モード（相乗り車線）の動作を図5に示します。主記憶バッファ（ラベルA）は到着してくるジャーナル・エントリを同じジャーナルを目的地としている複数のジョブに成り代わって集めます。集められたジャーナル・エントリの列（ラベルB）はIOA書き込みキャッシュを通って最終的には一斉にディスク上に出力されます。

主記憶ジャーナルによるキャッシングの動作が行われないと、各ジャーナル・エントリはディスクに書き込まれるまで一人旅をしなければなりません。周りのジャーナル・エントリと一緒に1つにまとめられて一緒にディスクに書き込まれる束（ラベルC）も、エントリの送信先側マシン上の最終目的地にたどり着くまで通信パイプ上を流れます。ジャーナル・キャッシング（i5/OSではオプション42と呼ばれているオプションの機能）を使用しないと、各ジャーナル・エントリは通信パイプ上それぞれ別々に送信されるので効率が悪くなります。したがって、ジャーナル・ソフトウェア・キャッシングは3つのレベル（A、B、C）全てにおいて効率を向上させ、リモート・ジャーナル環境において特に有効です。

ヒツジとヤギを分別するのも、分岐路を作るのも、送信されるもののサイズを最小化するのも、トラフィックの渋滞を監視するのも、相乗り車線を活用するのも、すべてi5/OSが面倒を見てくれます。i5/OSではリモート・ジャーナル環境を強化するための選択肢が豊富に用意されているので、筋肉をつけて脂肪を落とすことができます。

ラリー・ヤングレン氏はIBMロチェスター研究所に勤務し、i5/OSのマイクロコードのデザイナとiSeriesジャーナル開発チームのリーダーを務めています。

一般的なジャーナル・エントリ

各ジャーナル・エントリは次の2つの要素で構成されています。 　 ・ ESD （エントリ固有データ）。　 　　 （たとえば更新したばかりのデータベース列のイメージなど。） 　 ・ 固定ヘッダ。オペレーティング・システムが追記する、だれが変更したかを 　　 示す記述情報。 ESDは全てのジャーナル・エントリで必要です。ESDはAPYJRNCHG、 RMVJRNCHG、HABP再生、適切なIPLの回復には不可欠です。 ただし、固定ヘッダ部分のほとんどはまったくのオプションで、回復の際に絶対必要なものではなく、場所をとって、構築するのに余計なパス長を必要とする荷物のようなものです。 このヘッダや記述情報を分析する監査人がいたり分析するソフトウェアがある場合は、仕方がないのでそのままにしておきましょう。しかしプログラム名やユーザー・プロファイルを実際に使用する人がまったくいないのであれば、こうした記述情報を収集しておくことはまったくの無駄になります。