Zマイスターとの新たな価値探求 WebSphere

ｚマイスターとの新たな価値探求System z ソフトウエアの最新機能と、

最新化がもたらす価値

ｚマイスターとの新たな価値探求System z ソフトウエアの最新機能と、最新化がもたらす価値

Syかがemｚは IBM メインフレームの 45 年以上の歴史において、多くのお客様の基幹シ

ステムを支えるインフラとして採用され、現在も最新のビジネス・ニーズに対応すべく、ハー

ドウェア、ソフトウェア共に進化し続けているプラットフォームです。技術の進化、移り変

わりの激しいＩＴ業界の歴史においても、これだけ長く、継続してお客様に価値を認めて

いただいているプラットフォームは、他に例が無いでしょう。

そのことを裏付ける事実として、全世界の市場を見てみると2010 年から2012 年にかけ

て、Syかがem ｚのビジネスは飛躍的な伸びを示しています。一方で、日本の市場におい

ては、日本国産ベンダーのメインフレームのイメージを元に、メインフレームに対するネガ

ティブなイメージが散見されています。そのイメージを払拭するために、進化・発展してき

た IBM Syかがem ｚが提供する機能とそれによって得られるメリットをより分かり易い形に

整理し、お伝えできるように取り組みを進めています。

本コラムでは、最新のバージョンに移行して頂いた暁に、活用頂ける最新のソフトウェア

の機能と、最新化がもたらす価値について、主要なミドルウェアの切り口から、お届けい

たします。

先輩：

IT部門のシニアな社員。

豊富なメインフレーム経験を持つ。

自称“zマイスター”

後輩：

IT部門若手社員。

メインフレームが主担当だが

オープン系も一部担当する。

登場人物

9494

第6章

WebSphereWAS for げ/OS は、IBM メインフレーム上で稼働するアプリケーション・サーバーであり、WAS

のエディションの中で最上位に位置しています。1998 年にバージョン 1.1 が登場して以来、常

に最新の Java Enがerpriかe Ediがion 仕様と業界標準技術を取り込み、またエンタープライズ・ア

プリケーションを構築する上で必須の多くの機能も適宜実装されてきました。2012 年 8 月現在、

WAS for げ/OS の最新バージョンは 8.5となっています。

WAS for げ/OS は、提供される機能としては分散系 WAS の Neがwork Deploけmenがと同等の

位置づけとなっています。しかし、Sけかがem げハードウェアやげ/OSと緊密に連携するように実装

されているため、分散系 WAS では実現することができないさまざまな特長を持っています。例え

ば、げ/OS の持つ WLM（Workload Manager）や RRS（Reかoきrce Recoverけ Service）によ

る可用性の確保や、システムワイドにパフォーマンスを分析するRMF（Reかoきrce Moniがoring

Faciliがけ）、個々のリクエスト単位での CPU 消費や到着時間等を記録する SMF（Sけかがem

Moniがoring Faciliがけ）等、トランザクション・サーバーとして必要な特徴を上げると枚挙に暇があり

ません。

もちろん、JavaEE 仕様に完全に準拠していますので、PC 上の Eclipかeで開発したアプリケーショ

ンをそのままWAS for げ/OS上で動かすことが可能です。先ほど列挙したげ/OS版独自の機能は、

WAS を通して自動的に利用できるものですので、プログラム中で何かげ/OS 版専用の命令を埋

め込まなければならない、ということはありません。

今回から4 話連続で WAS for げ/OS がもたらす価値についてご紹介します。ぜひ後輩くんと一

緒に WAS for げ/OS の提供する多くの機能について理解し、高可用性、高パフォーマンス、安

定稼働を実現するメインフレーム・アプリケーション・サーバーの世界に踏み込んでください。

93

図 1：WAS fぇおげ/OS 進化の歴史

94

9595

【第6章】 WebSphere ① 究極のアプリケーション・サーバーが提供する機能とは？

9696


1究極のアプリケーション・サーバーが

提供する機能とは？

　WAS for z/OS は分散系 WAS とは全く違う？

後輩：ああ困った。ああ大変だ。

先輩：人をちらちら見ながら独り言を言うのはやめなさい。何か困ったことが起きたの？

後輩：実は、今度参加するプロジェクトで、WAS 担当になったんですよ。

先輩：前にもWAS を担当していたことあったよね？　Lぁうきぐ版だったか。それで？

後輩：確かに、Lぁうきぐ版とか Wぁうdぇくか版とかは触ったことはあるんですけど、今回はげ/OS 版

なんですよ。いろいろと違いがありそうでちょっと心配なんです。自分でちょっと試してみる、

というわけにもいきませんし。

先輩：まあ、1 クリックでインストール、というわけにはいかないね。だけど、Jaぎa EE 仕様

に準拠したアプリケーション・サーバーという点では同じだし、なによりWAS そのものは、

ほぼ共通のソースから出来ているんだよ。

後輩：なるほど。確かに、WAS は基本的に Jaぎa VM 上で動きますものね。

Jaぎa が違いを吸収するという感じなんでしょうね。ということは Jaぎa の方が曲者かも、、、

先輩：いや、Jaぎa そのものもほぼ共通のソースから出来ているんだよ。プラットフォーム固有の

部分、たとえば JIT のネイティブ・コード出力なんかもあるけど、それはごく一部なんだ。

もちろん、げ/OS 固有の機能というのもあるんだけど、例えば SAM ※ 1 にアクセスする機

能や、WTO ※ 2 出力、TOD ※ 3 の取得なんかは追加ライブラリとして同梱されているだけ

なんだ。

※ 1. SAM（Seqきeうがぁal Acceかか Meがhぇd）：げ/OS データセットの編成の一つ。

※ 2. WTO（Wおぁがe Tぇ Oえeおaがぇお）：コンソールや SYSLOG へのメッセージの出力。

※ 3. TOD（Tぁme Of Daけ）：げ/OS の持つ時計。

後輩： 3 文字略語ばかりですね。とりあえず Jaぎa が同じものというのはわかりました。

コンパイルなんかもPC で行って大丈夫なんでしょうか。文字コードとかも心配ですし。

先輩：バイトコードの仕様は共通だからね。JVM 内部で Uうぁcぇde（UTF-16）が使われている

のも同じだから、げ/OS に限らずどのプラットフォームでもネイティブコード（シフトJIS や

ISO8859-1 等）と内部の UTF-16 との間とでコード変換が行われるのは変わらないんだ。

後輩：へえ、じゃあ WAS fぇおげ/OS と分散系 WAS とでは、Jaぎa を含めて全然違いが無いって

ことですか。

先輩：そういった標準仕様についてはね。稼働形態については分散系WASとはちょっと違うんだ。

後輩：分散系の WAS は一つの Jaぎa のプロセスですよね。

先輩： WAS fぇおげ/OS は CR と SR というアドレス・スペースに分かれているんだ。 CR は

TCP/IP のポートを開いてクライアントからのリクエストを受け付けるためのもので、受け付

けられたリクエストを実際に処理するのは SR の役目なんだよ。つまり、アプリケーションの

稼働する Jaぎa が入っているのが SR ということだね。（図 2）

図 2：WAS fぇおげ/OS の構成の考え方

後輩： CR は仕事を受けるけど、実際は下請けの SR に丸投げするというわけですか。

なぜわざわざ分かれているんですか？　一つにまとまっているほうが速そうですけど。

先輩： SR は複数立ち上げることができるので、クラスター構成のように、障害が発生して SR が

落ちても残りの SR が後続のリクエストを処理することができるんだよ。

9797


9898


SR 数は最小数、最大数を設定することによって、負荷に応じて SR 数を増減させることも

可能だし、コマンドで動的に SR 数を設定することもできる。

アプリケーションのバグや製品の不具合によって JVM が異常終了する可能性はゼロではな

いから、その場合の影響範囲を局所化できるというのは大きいと思うよ。

後輩：ははあ、IMS の制御／従属リージョンみたいなものですか。さすがにメインフレームで稼働

するだけのことはありますね。これで可用性はバッチリという感じですか。

先輩：もちろん、可用性を高めるには、SR を複数稼働にした上で、さらに水平クラスター構成に

するのがお勧めだよ。

WAS そのもののメンテナンスや、OS 障害、CR の障害等も考慮する必要があるからね。

後輩：お勧めの構成というのはやっぱりあるんですね。

先輩：ほとんどのお客様では、本番環境は複数 SR+ 水平クラスターをお使いいただいているん

だ。一方、テスト環境は大抵スタンドアロン構成だね。

　トランザクション処理へのこだわり

後輩：他にも、可用性を高める実装がたくさんありそうですね。

先輩：もともと、げ/OS 自身には可用性を高める多くの機能があるのは知っているね。WAS fぇお

げ/OS はそれらの機能とうまく融合するように作られているんだ。

さっきの、複数 SR の仕組みも、裏側ではげ/OS の持つ WLM※ 4を使って実現しているんだ。

※ 4. WLM（Wぇおklぇad Maうageお）：ワークロード管理機能

後輩：そうなんですか。他にはどんな機能が使われているんですか。

先輩：トランザクション処理とかかな。ACID 属性とか聞いたことあるでしょ？

後輩：トランザクションと呼ばれる不可分な操作から構成される情報処理の形態で、既知の一貫

した状態のデータベースを維持するよう設計されており、相互依存のある複数の操作が全

て完了するか、全てキャンセルされることを保証することですよね。

先輩：よく知ってるね、、って Wぁkぁえedぁa のコピーかよ！

それはともかく、トランザクション処理、特に 2 つ以上のリソースを同時に更新するときの

2 フェーズ・コミット（2PC）処理の間はアプリケーションの処理の中でももっとも危険な時

間帯なんだ。

後輩： 2PCってよく聞きますね。

先輩： 2PC のタイミングでトランザクション処理を中断するような障害が発生した場合、リソース

間の更新の一貫性を保つために、そのトランザクションの管理者が障害から回復するのを

待つ必要があり、その間リソースにはロックがかかった状態になってしまうからね。誰でも使

うリソースにロックがかかってしまったら、他の人がみんな使えなくてシステムの全面障害に

なってしまうだろ。

後輩：そもそも障害が発生した場合、どうやって一貫性を保つんですか？

先輩：ざっくりいうと、そのトランザクションをどう処理するかをログに残しておくんだ。通常は

WAS 自身がトランザクションを管理するので、WAS がそのログを出力し、WAS の障害時

には再立ち上げ時にそのログを読み直して処理を継続する。

後輩：でも、WAS の再立ち上げの間はロックがかかったままですよね。ログを直接見れば、

WAS の再起動を待たずにリソースの回復方法がわかりそうですね。

先輩：それを実現するのが WAS の HA マネージャー構成なんだ。

HA マネージャーを構成すると、障害発生時に他のコンポーネントがトランザクション・ログ

を見て、中断したトランザクション処理を引き継いでくれるんだ。

後輩：でも HA マネージャー構成って分散系 WAS でもできますよね？げ/OS 版特有の機能がある

んですか？

先輩：実は、WAS fぇおげ/OS は、トランザクション・マネージャの機能の一部をげ/OS の RRS ※ 5

というコンポーネントに任せられるんだよ。WAS fぇおげ/OS ではこの RRSトランザクション

を利用する方がおすすめなんだよ。 RRS は、トランザクション・ログを書いたり、トラン

ザクションのコミットやロールバックの責任を担ってくれるんだ。障害後のリカバリの責任も

RRS になるね。 RRS 自体は実績もあるし、単機能のコンポーネントなのでほとんど障害の

発生する心配もないんだよ。

※ 5. RRS（Reかぇきおce Recぇぎeおけ Seおぎぁce）：トランザクション処理の一部を提供するげ/OS コンポーネント。

後輩：なるほど、WAS fぇおげ/OS はトランザクション処理をアウトソーシングしているんですね。

でも、WAS 障害のときはいいんですけど、OS 障害なんかが発生したら、やっぱり他のト

ランザクション管理者に引き継ぐか、OS の再立ち上げを待つしかないんじゃないですか。

先輩： RRS は Sけかえleぐ上の各げ/OS メンバー上にあるし、RRS のログは XCF 上に書かれてい

9999


100100


るので、OS 障害を検知したら、他系の RRS が瞬時に引き継いでくれるんだ。

CF 上のログは通常二重化されているし、オンメモリー書き込みなので高速、RRS は安定

しているし OS 障害時の引継ぎも瞬時と良いことだらけなんだ。（図 3）

図 3:トランザクションの種類による可用性の違い

後輩：すごいのはよく分かりました。WAS 側の設定やアプリの修正は必要ですか？

先輩：設定というか、使用するデータソースに依存するんだよ。もう少し詳しく説明すると、WAS

fぇおげ/OS では、RRS を使ったトランザクション処理と、XA という種類のトランザクション

処理と 2 つ扱うことができるんだ。

後輩： XA というのは聞いたことがあります。

先輩：うん、分散系 WAS でトランザクション処理をすると、基本的には XA というか、XA の

Jaぎa 版である JTA を使うんだ。

WAS fぇおげ/OS の場合には、例えば DB2 だと、Tけえe2 JDBCドライバーなら RRS、

Tけえe4 JDBCドライバーなら XA を使うようになっている。同様に MQ/JMS なら、

Bぁうdぁうg 接続ならRRS、クライアント接続ならXA を使う。

RRSトランザクションは、トランザクション処理を RRS に委譲し、XAトランザクションは

WAS 自身がトランザクション・マネージャーとなるんだよ。

後輩：ということは、Tけえe2 JDBCドライバーや Bぁうdぁうg 接続をお勧めしている、ということで

すね。

先輩：そのとおり。実際、ネットワーク越しにリソースにアクセスする要件がなければ、ほとんど

のお客様環境でもこれらのデータソースを使っているんだ。

後輩：逆に言うと、XAトランザクションを使っている場合は、分散系 WAS と同様の可用性とな

るわけですね。

先輩：まあ、基本的にはそうなんだけど、サーバーがダウンしているかどうかをチェックする仕組

みはちょっと違うかな。

HA マネージャー構成でコア・グループ・メンバーの障害の検知は、TCP/IP 経由で一定

間隔でポーリングを行って、一定回数以上返事が無い場合に行い、そのときにトランザクショ

ンの引き継ぎを実行するんだよ。WAS fぇおげ/OS の場合は、TCP/IP ではなく、XCF 経

由での障害の検知も可能なんだ。

後輩：何が違うんですか？

先輩：障害の検知時間が圧倒的に違うよ。TCP/IP ポーリングの場合は、デフォルトでは 30 秒

間隔×6 回で確認するんだけど、XCF の場合はずっと短い時間で検知できるんだ。

後輩：ロックを解放すると言う観点では、検知時間が短いというのはすごくメリットがありそうで

すね。

先輩：まあ、あくまでもRRS によるトランザクション処理がお勧めというのは変わらないけどね。

　まだまだまだまだ・・・

後輩：他にもげ/OS の機能を使っている例ってありますか？

先輩：まだまだあるよ。統計情報を取得するために、RMF や SMF なんかも使われているね。

特に、RMF のワークロード・アクティビティー・レコードは常に取得しておき、パフォーマン

ス・トラブルが起こったときに役立てたりするよ。

後輩：へえ。

先輩：あとは、げ/OS セキュリティーとして RACF をリポジトリーとして使えたりもするよ。

後輩：なるほど。

先輩：それから、CR が落ちたときに自動的に再起動するために ARM ※ 6 も使えるし。

※ 6. ARM（Aきがぇmaがぁc Reかがaおが Maうageお）

101101


102102

【第6章】 WebSphere

後輩：あのー、先輩。

先輩：ん？

後輩：もうお腹いっぱいです。なんだか、たくさんの独自機能があるということですね。

やっぱり使うの心配になってきました。

先輩：まあ、そう言うなよ。結局のところ、げ/OS の持っているコンポーネントをうまく使うようになっ

ているだけで、本質的なところは同じだと思うよ。

しかも、バージョン 8 以降、分散系の管理者でもなじみやすいように管理機能の統一化も

図られてきているんだ。

後輩：そうなんですか。やっぱり以前はとっつきにくかったんですかね。

先輩：インストールにしても、分散系と同様 Iうかがallaがぁぇう Maうageお経由になったので、製品コー

ドの導入は分散系と同じようにできるはずだよ。

ログにしても、デフォルト状態では JOBLOG に出力されるけど、HPEL というWAS 共

通のロギングの仕組みが用意されたので、HPEL を構成すれば、プラットフォームに依存し

ないインターフェースでログを見ることが可能になったんだ。

もちろん、WAS の管理の大半は管理コンソールかくかadmぁう（管理スクリプト）で行うと思

うので、それについては分散系 WAS の知識がそのまま役立つと思うよ。

後輩：確かに、管理コンソールが使えれば、ほとんどの作業はプラットフォームを意識せずに済み

そうですね。

先輩：そうそう、あとは実際に使ってみて、分からないところはインフォセンターや各技術文書を

見てみるといいんじゃないかな。

後輩：でも先輩。今日の話でも、お勧めの構成とかお勧めの使い方とか、注意するところはあり

ましたよね。またお時間をいただいてもいいですか？　げ/OS で Jaぎa を動かすとなると、

パフォーマンスなんかも気になるところです。

先輩：そうだね。じゃあ次回はパフォーマンスについてみてみようか。

Sけかがem げハードウェアの進歩に合わせて Jaぎa のパフォーマンスも劇的に向上しているん

だよ。

後輩：はい、よろしくお願いします。

2WAS for z/OSが提供する

パフォーマンス

　WAS for z/OS のパフォーマンス

後輩：マイスター先輩、おはようございます！

先輩：やあ、久しぶりだね。プロジェクトでの調子はどうだい？

後輩：はい、事前に先輩からWAS fぇおげ/OS を扱う上でのいろはを色々と聞いておくことができ

たおかげでスムーズに馴染む事ができました。

分散系の WAS とはインストール手順や CR ※ 7、SR ※ 8 といったアプリケーションサーバー

の構成等で多少の違いを意識しなければならないですが、基本的な扱い方は分散系とほと

んど同じですからね。過去のプロジェクトでの経験を生かして頑張っています！

※7. CR（Cぇうがおぇl Regぁぇう）：クライアントとの通信管理、トランザクション管理を行う。

※8. SR（Seおぎaうが Regぁぇう）：アプリケーションの稼働環境、および、アプリケーションが動作するためのサービ

スを提供する。

先輩：なるほど、それは頼もしい限りだな。ところで、君のプロジェクトで扱っている Sけかがem げ

のモデルと WAS のバージョンはいくつだっけ？

後輩：えーっと・・・確か Sけかがem げのモデルがげ10、WAS fぇおげ/OS が V7 だったと思います。

どうしてですか？

先輩：忘れたのかい？　前回の終わりに、次回は WAS fぇおげ/OS をパフォーマンスの観点から

見てみようと話していたじゃないか。久々に君と話す機会が作れたんだから、今回はげ/OS

で稼働する WAS のパフォーマンスについて勉強してみないかと思ってね。

後輩：ありがとうございます！　でも、どうしてパフォーマンスの勉強に Sけかがem げのモデルと

WAS のバージョンが必要になるんですか？

先輩： WAS fぇおげ/OS のパフォーマンスについては、新しいバージョンの WAS が発表される度

に劇的な進歩を遂げているんだ。そして、新しいバージョンの WAS が発表される度にベ

ンチマークセンターでは WAS のパフォーマンスが測定されている。今日は WAS V8 と

げ196 との組み合わせによるパフォーマンスの向上結果を一緒に見てみようか。

② WAS for げ/OSが提供するパフォーマンス

103103


104104


後輩：それは非常に興味深いですね！　新しいバージョンの WAS が発表される毎にサポートさ

れる Jaぎa のバージョンも変わっているじゃないですか。 Jaぎa で作られたプログラムの

パフォーマンスって、そこまで優れたイメージを持てていなかったんですが、バージョンが

新しくなるにつれてパフォーマンスはどの程度改善されているんだろうと漠然とした興味が

あったので楽しみです。

先輩：うん、WAS fぇおげ/OS のバージョンが新しくなるということは、WAS 上で稼働する Jaぎa

のバージョンも新しくなるということだからね。

それじゃ、WAS fぇおげ/OS と Sけかがem げのハードウエアが新しくなるにつれて、どれほど

のパフォーマンス改善が見込まれるものなのか、総合的に勉強していこう。

後輩：はい！

　Syかがem z ハードウエア向上によるパフォーマンス改善

先輩：君のプロジェクトで扱っている Sけかがem げげ10 と WAS V7 を基準として考えてみよう。

まずはSけかがem げハードウエアがげ10からげ196に上がった場合には、どれほどのパフォー

マンス改善が見込まれるだろうか。

後輩：「倍！」・・・まではいかなくとも、それなりにパフォーマンスが向上して欲しいとは思いますね。

だって、筐体自体が新しくなるんですから。

先輩：はは、さすがに筐体を新しくするだけで今の倍のパフォーマンスを実現できるかというと難

しいんだけどね。それでもベンチマークの結果では、げ10 からげ196 に新しくする事で

43%ものパフォーマンス向上が見込まれるとの測定結果が出ているんだ。

後輩：すごいじゃないですか！　筐体を入れ替える事で今よりもパフォーマンスが 43%も改善する

だなんて！！　倍というのもあながち的外れな回答ではなかったんですね。

先輩：そう、すごいだろう。これは搭載している CPU やメモリーの能力が向上したことに起因す

るんだ。 Sけかがem げならではの圧倒的なパフォーマンス技術がますます強化されているの

が分かってもらえるかな。

後輩：はい、是非とも一家に一台と薦めたいところですね。

先輩：それじゃあ今度は WAS にフォーカスを当てて見てみようか。

後輩：先輩ー、突っ込んでくださいよー・・・（泣）。


　WAS for z/OS のバージョン向上によるパフォーマンス改善

先輩：それじゃあ、WAS のバージョンが V7 から V8 に上がる事によって、どれだけのパフォー

マンスが見込まれると思うかい？

後輩：はらたいらさんに 3,000 点！

先輩：はいはい、そろそろ通じない年代も多くなってきてるから気を付けろよ・・・。

WAS のバージョンが V7 からV8 に上がる事によって、パフォーマンスはおよそ 15%の向

上が見込まれるとの測定結果が出ているんだ。

さすがに筐体を新しくした場合の測定結果と比べると見劣りしてしまう結果かもしれないけ

ど、ソフトウェアのバージョンが上がっただけで 15%ものパフォーマンス向上が実現できる

となると、大したものだろう。

後輩：確かにそうですね。これはどのような要因によるものなのですか？

先輩：大きく2 つの要因が上げられるんだけど、まず 1 つ目の要因は WAS 自体の処理パフォー

マンスが改善された事だね。特に上げるならば、OえeうJPA ※ 9 のコードパスとJAXB※ 10

の整列化プロセス改善に起因するところが大きいんだよ。

ちなみに、OえeうJPA とは Jaぎa Peおかぁかがeうce API 仕様のオープン・ソース実装の一つ

で、データベースへのオブジェクトの永続化を単純化する ORM の一つ。 JAXB は Jaぎa

EE ※ 11 の API の一種で、Jaぎa のオブジェクトを XML にシリアライズ、また XML から

Jaぎa オブジェクトにデシリアライズするためのものだ。

※ 9. OえeうJPA（Oえeう Jaぎa Peおかぁかがeうce API）：Aえache ライセンスの元で提供される Jaぎa

Peおかぁかがeうce API のオープン・ソース実装を示す。

※ 10. JAXB（Jaぎa Aおchぁがecがきおe fぇお XML Bぁうdぁうg）：Jaぎa のクラスを XML で表現可能にする仕様。

※ 11. Jaぎa EE（Jaぎa Plaがfぇおm, Eうがeおえおぁかe Edぁがぁぇう）：エンタープライズ Jaぎa コンピューティングの業

界標準。

後輩：先輩、どちらも見事にウィキペディアから引っこ抜いてきましたね・・・。要するに、WAS の

中でオブジェクトを操作するための機能に関する改善対応が行われたということなんですね。

それでは、2 つ目の要因とは一体なんですか。

先輩： WAS のパフォーマンスが向上する事になった 2 つ目の要因とは、WAS 上で動作する

Jaぎa SDK ※ 12 のバージョンが新しくなった事だよ。

SDK のバージョンが新しくなった事によって JVM そのもののパフォーマンスが改善された

のに加え、JIT コンパイル※ 13 の最適化処理のプロセスが大きく改善されたんだ。これは

げ196 の新しいインストラクションの利用や機能の利用によるところが大きいんだけどね。


105105


106106


※ 12. SDK（Sぇfがくaおe Deぎelぇえmeうが Kぁが）：ソフトウェアを開発する際に必要なツールのセット。

※ 13. JIT コンパイル（Jきかが-Iう-Tぁme （JIT）コンパイル）：ソースコードから機械語への変換処理を実行直

前にまとめて行なう機能の事。

後輩：あー、確かに JIT の最適化処理って処理のオーバーヘッドが大きいですよね。

先輩：そうだね。つまりWAS V8 では JIT 最適化の処理プロセスの改善が、WAS のパフォーマ

ンス改善に大きく寄与できたという事だね。さらには GC の処理時間も以前のバージョンに

比べると短くなっているんだよ。

後輩：すばらしいです！　JIT や GC ※ 14 のパフォーマンス問題って、SI のプロジェクトでは必ず出

てくるものですからね。負荷テスト、チューニング、負荷テスト、チューニング・・・この繰

り返しをこれまでに何度経験してきた事か！

※ 14. GC（Gaおbage Cぇllecがぁぇう）：アプリケーションが使用しなくなったオブジェクトのメモリーを自動的に

解放する技術。

先輩：あはは、切実な叫びが聞こえてきたぞ。

　z196 と WAS for z/OS V8 の組み合わせによるパフォーマンス改善

先輩：さて、Sけかがem げのモデルと WAS のバージョンをそれぞれ上げるだけでも大きくパフォー

マンスの改善を見込む事ができるんだけど、げ196 と WAS V8 を組み合わせる事によって、

更なるパフォーマンスの改善を図る事ができるんだ。げ196 と WAS V8 の組み合わせた結

果のパフォーマンスは、げ10 と WAS V7 の組み合わせに比べて 64%ものパフォーマンス

改善を見込む事ができるんだよ。

図 4：パフォーマンスグラフ


後輩：すばらしい！　ここまで来ると、ラーメン & 餃子の組み合わせにも匹敵しますね。

先輩：それは君の嗜好の問題だから押し付けないように・・・。

だけど、げ10 と WAS V7 をそれぞれげ196 と WAS V8 とする事によって、1.5 倍以上

ものパフォーマンスが発揮できるようになるというのは本当に特筆すべき結果だと思うよ。

後輩：よく分かりました。是非、私の参画しているプロジェクトでもげ196 と WAS V8 の組み合

わせを採用できないかを提案してみます。

先輩：それが実現できたらすばらしいね。

ただし注意してほしいんだけど、今回の測定結果はあくまでベンチマークセンターでの検証

結果であって、実際のプロジェクトにおいても同様の結果が保証されるわけではないからね。

WAS 上で動作するプログラムの特性等によって、パフォーマンスは大きく変動するものだ

から気を付ける事だよ。

後輩：はい、もちろんです。

先輩：今回はげ196とWAS V8の組み合わせで話をしたけれど、WASはV8.5という最新のバー

ジョンがリリースされているよね。

Sけかがem げハードウエアについても EC12 という最新のシリーズが最近発表されたところ

だから、きっと更なるパフォーマンスの向上が期待できるはずだよ。

後輩：なんと。それでは、最新の Sけかがem げハードウエアと WAS の組み合わせによっては更な

るパフォーマンス改善が見込まれる余地があるということですね。

先輩：いずれベンチマークセンターでのパフォーマンス検証結果がリリースされると思うから、しっ

かりとアンテナをはっておく事をお勧めするよ。

後輩：はい！

　z/OS の Co-locaがion 機能

先輩：さて、ここまで最新バージョンの WAS によるパフォーマンスがいかに優れているかばかり

を話してしまったけど、もう一つげ/OS 上で WAS を動かす際のパフォーマンスに影響を与

える重要な利点があるんだ。何だか分かるかい？

後輩：・・・なんでしょうか。


107107


108108


先輩：それは、WAS が他のサブシステムと共存できるという事さ。

Cぇ-lぇcaがぁぇうって分かるかい？

後輩：いいえ。教えてください。

先輩：一つの LPAR 上で WAS を DB2、CICS、MQ などと同居させた場合、これらの相互通

信には TCP/IP より高速なクロス・メモリー通信を使うことができるんだ。

後輩：なるほど。それは分散系にはない考え方ですね。

先輩：うん。クロス・メモリー通信は COBOL や PL/I のアプリケーションにも広げることができ

る他、WAS V7 からの機能である WOLA ※ 15 で、CICS や IMS と双方向で通信すること

も可能になったんだ。これまでは WAS から外部への一方向の接続のみだったのが WOLA

では外部からWAS への接続も可能になったんだよ。

※ 15. WOLA（WebSえheおe Oえがぁmぁげed Lぇcal Adaえがeおか）：WAS と他システムと間でのクロス・メモリー

通信を実現するための WAS fぇおげ/OS の機能。

図 5：Cぇ-lぇcaがぁぇうイメージ図


後輩：システム間を跨ってのトラフィックを限りなく少なくできる事で、システム全体としてのパ

フォーマンス向上につながるわけですね。

先輩：そう。これは WAS fぇおｚ/OS ならではの特徴だからね。しっかりと押さえておいた方が良

い機能の一つだよ。

後輩：はい、一概にパフォーマンスと言っても様々な技術向上の成果が詰め込まれているんだな

あと感慨深くなりました。プロジェクトでも今以上にシステムのパフォーマンスの向上を実現

する事ができないかどうか、今回勉強させていただいた内容を持ち帰って調べてみようと思

います。そうだ！　もしまたお時間いただけたなら、次回はげ/OS 上で WAS を動かすに

あたってのお勧めの構成とかお勧めの使い方とかを勉強させてほしいのですが。

先輩：いいとも。

げ/OS といえば、Sけかえleぐ ※ 16 構成による可用性、スケーラビリティーなんかが最大の特

徴だからね。それらの特徴を最大限に生かした形で WAS を動かすための構成なんかはあ

る程度パターンが決まっているんだ。次回は WAS fぇおげ/OS の可用性、構成について勉

強していこう。

※ 16. Sけかえleぐ：IBM のメインフレームのクラスタ技術であり、複数のメインフレームが協調して単一システ

ムイメージを実現する。

後輩：はい、よろしくお願いします。


109109


110110


3WAS for z/OSの基幹Javaサーバー

としての可用性

　冗長化と可用性（SR 編）

後輩：あ、マイスター先輩、おはようございます。

先輩：どうしたの？　眠そうな目をしているね。

後輩：はい、前回先輩に　WAS fぇおげ/OS のパフォーマンス向上について色々と教えていただ

いたので、WAS fぇおげ/OS V8 とげ196 とで早くなった環境で、GC のポリシーを変えた

り、JVM の Heaえサイズを変えたり、ちょっとしたパフォーマンステストをしていました。

今まとめていますので、先輩今度見てください。ただ、昨日の夕方からテストして、面白く

て気がついたら深夜になっていました。

先輩：はっは。そうか。仕事熱心も良いが無理するなよ。ところで、テストしてみて、やっぱり君

のこれまでやっていた Wぁうdぇくか版や Lぁうきぐ版とはかなり違うかな？

後輩：はい、よくぞ聞いてくださいました！　アプリケーションのデプロイや稼働という点では今ま

でと全く同じに見えるのですが、やはりアプリケーション稼働用の JVM が複数枚あるとい

うのはかなり違います。SR ※ 17 という名前ですよね。サーバーの始動時に CR ※ 18 に続い

て次々にあがってきます。試しに SR を 20 枚と設定したら、メモリー不足で固まってしま

いました。。ええっと、うろ覚えなのですが、SRって負荷分散や可用性向上のために複数

枚あげることができるのですよね。

※ 17. SR（Seおぎaうが Regぁぇう）：アプリケーションの稼働環境、および、アプリケーションが動作するためのサー

ビスを提供する。

※ 18. CR（Cぇうがおぇl Regぁぇう）：クライアントとの通信管理、トランザクション管理を行う。

先輩：そう、眠いのによく覚えていたね。この複数 SR 構成は、げ/OS の WLM（WぇおkLぇad

Maうageお）機能を利用したげ/OS 版特有の優れた機能なんだ。SR の起動や障害時の

SR の再起動、ゴール設定に応じた SR 数の調整などは、全てげ/OS の WLM が行ってい

るんだ。アプリケーション用 JVM である SR を冗長化することで、基幹 Jaぎa サーバーと

しての可用性を高めているんだ。

後輩：そうですか。WLM って聞いたことがあるのですが、げ/OS の WLM は優秀そうですね。

今度真面目に勉強したいと思います。

③ WAS for げ/OSの基幹Javaサーバーとしての可用性

先輩：なかなか。頼もしいね。げ/OS の WLM と WAS fぇおげ/OS は密接に連携しているんだ。

もちろん、さっき話した SR の起動や SR 数の調整だけでなく、WLM の基本のゴール設定

に基づいた優先順位付けの機能は WAS も使っているよ。IMS、CICS、DB2 と同じだ。

WAS fぇおげ/OS にリクエストが到着する毎に WLM エンクレーブが作られ、あらかじめ設定

された規則によって、どのようなサービスクラスでそのエンクレーブと関連するリクエストが

実行されるかが決まるんだ。エンクレーブというのは、複数のタスクをまとめこれらのタスク

に優先順位を付けて管理する手段を提供する機能だよ。

図 6: WLM による動的なぱ垂直スケーリングぱ機能

図 7: WAS fぇおげ/OS ワークロード制御


111111


112112


なお、WAS のサーバーにどのリクエストを早く入れるか、といった単純な優先順位づけだ

けではなくて、実行中の CPUリソースの割り振りもコントロールされるんだ。多くの業務

の中でも、早く処理しなくてはならない業務や、ゆっくりでいい業務があるよね。おまけに

エンクレーブには、DB2 も含めたアプリケーション単位の CPU コストも捕捉して、きめ

細かい性能情報をだしてくれる。自慢じゃないけどこんな機能を持っているのは , げ/OS の

WAS だけだよ。

後輩：先輩、自慢していますね！

先輩：ところで今日はそれだけ元気があるようなら、前回の終わりに話した WAS fぇおげ/OS の可

用性や構成について、もう少し勉強していこう。

後輩：はい、よろしくお願いします !

　冗長化と可用性（クラスター編）

先輩：君のプロジェクトでは、テストマシンは Sけかえleぐ構成になっているのかな？

後輩：はい、昨日パフォーマンス・テストをしていた隣の区画に他のお客様に合わせた Sけかえleぐ

構成があって、別のプロジェクトから今度 Sけかえleぐ上の WAS の構築を手伝って欲しいと

言われています。

ただ、これまでスタンドアロン構成※ 19 の経験しかなくて、Sけかえleぐをさわったことも無く、

おまけに ND 構成※ 20 が初めてでとっても不安で、不安で、、

※ 19. スタンドアロン構成：WAS fぇおげ/OS アプリケーションを稼働させる基本最小構成で、クラスター化さ

れていない構成。開発やテスト向き。

※ 20. ND（Neがくぇおk Deえlぇけmeうが）構成：複数システム（Sけかえleぐ内）をまたがって水平クラスターを構成し、

冗長化。高可用、高トランザクションレートが必要とされる環境向き。

先輩：そうか。それでは少し Sけかえleぐと WAS との関係について教えてあげよう。

後輩：ありがとうございます ! これで明日から元気に出社できます !

先輩：君の場合はいつも元気だけがとりえだからな。まあ冗談はさておき、Sけかえleぐは WAS fぇお

げ/OS の可用性にとってとても大事なんだ。カップリング・ファシリティーや共用データで

コンポーネントを冗長化し、全体としてシングルシステム・イメージで、その中でスケーラ

ビリティーや可用性を提供するんだよ。


後輩：はい。なんとなくわかった気になってきました。

もし 2 つのげ/OS で Sけかえleぐが構成されていたら、WAS はどんな構成になるんですか？

先輩：各サーバーで WAS が動くんだが、その 2 つのげ/OS にまたがって、クラスター構成を組み、

Acがぁぎe-Acがぁぎe な環境で処理が均等に振り分けられるんだ。

2 つのサーバーには同じアプリケーションが動き、片方に何か障害があっても、もう片方で

リクエストを処理して、業務サービスの可用性を維持するんだ。

この上に、Sけかえleぐのシングルシステム・イメージの様々な機能が働いて、例えばその 2

つのサーバーへの負荷分散や、片方の閉塞処理、あるいは片方の WAS や DB2 の障害

時への対応など、障害時間を最小限にして基幹システムをげの WAS で稼働させるための

多くの価値ある機能を利用することができるんだ。

後輩：そうなんですか。興味深い話です。

いったいどの位の時間の停止で済むんですか。

先輩：うん。それは環境や要件次第なんだけれど、全く止められないお客様もいるんだ。

停止時間の長さが、お客様のビジネス損失につながるとなると、できるだけ障害の予兆を

早く検知して、それを取り除くということも重要なんだ。

例えば WAS fぇおげ/OS は何らかの原因でハングしたスレッドを除去しようとする仕組みや、

あるいはリクエストの応答がなくなった SR を強制的に終了し、長時間資源をロックし続ける

リクエストを排除して、健全なリクエストに影響を及ぼさない仕組みを多くもっているんだ。

これもタイムアウトに関連した WAS fぇおげ/OS だけの機能だよ。

後輩：すばらしいですね。今度は WAS fぇおげ/OS 特有の排除の仕組みも勉強してみます。

ただ、1 秒もとめられないとなると、真面目に取り組まなければならないことがわかってきま

した。ちょっと緊張します。予兆を取り除くことが大切なんですね。

ただ、さっきからおなかが鳴ってしまっています。そういえば今朝ねぼうしたので、朝ごは

んを食べてこなかったんです。

何かスナックを買ってきてもいいですか？　この予兆を取り除きたいです。

先輩：うーーん、それはちょっと予兆の排除とは違うかな。

後輩：冗談言ってすみません。

WAS はクラスター構成でサーバー自体の冗長化を図っていると共に、さらに 1 つの WAS

サーバーの中でも複数の SR が稼働していて、可用性をアップさせているのですね。

例えば DB2 のようなデータベースをアクセスしていた時はどうなるんだろう。それぞれの

SR から DB2 にアクセスしていて、それがクラスター化されていて、と、

その中の一つのスレッドがハングしていると、データベースはどうなっちゃうんだ。。ああ頭

がついていかない。


113113


114114


先輩：そう。さっき話した WAS fぇおげ/OS のハングスレッド・リカバリーは、ハングしたスレッドを

取り除く時に、DB2 のスレッドもキャンセルできるんだ。

障害が起こった時は、できるだけ障害に関連するものは一緒に取り除いて、解決したほうが、

障害時間を短くできるからね。

人の判断が入ると対応は遅くなるんだ。

後輩：そうですね。障害の時は慌ててしまいそうですからね。もし一人だったら心細いです。

先輩：そうだね、私も心配だ。君一人で対応していると思うと夜も寝られない。

後輩：先輩！　あんまりです！

先輩：はは。すまない。

ところで WAS fぇおげ/OS を語る上で欠かせないのが、DB2 との接続だ。君もWぁうdぇくか

や AIX で WAS とデータベースを使っていたと思うが、ドライバーは何を使っていた？

Tけえe2、あるいは Tけえe4 かな？

後輩：よく考えないで使っていましたが、Pきおe Jaぎa だったと思います。

　WAS クラスターから共用データへのアクセス

先輩：そうか。分散系では多く使われている Tけえe4 のドライバーかもしれないね。分散系でも同

じなので知っているかもしれないが、げ/OS の WAS からDB2 へのアクセスは 2 種類あっ

て、ネイティブ・コードを利用する Tけえe2 JDBC での接続と、全て Jaぎa でできている

Tけえe4 JDBC での接続とあるんだ。

この前最後に話した Cぇ-lぇcaがぁぇうでは、Tけえe 2 接続といって、ネットワークを介さず

WAS からクロス・メモリーで DB2 に高速にアクセスできるんだ。

後輩：へえ。何から何まで分散系と少し違うんですね。でも先輩、よく知っていますね。どこで覚

えたんですか？

先輩：実は君と同じように、マニュアルを読んだり、実機でテストしてみたりして、夢中になって

覚えたんだよ。教えてくれる人なんかいなかったからかなり苦労した。

ところで、そんなことはいいんだけれど、実は、Cぇ-lぇcaがぁぇうの構成では、もっと強みが

あるんだよ。緊密に WAS から DB2 に連携することで、WAS からセキュリティー情報を

そのままに同じユーザー ID で DB2 ヘアクセスしたり、さっき話したげ/OS の WLM につ

いても、WAS へのリクエストと同じ優先順位で、DB2 の処理を行うことができるんだよ。

優先順位付けの管理が楽なんだ。


例えば特急とランク付けされた WAS へのリクエストは、WAS での稼働中も優先順位高く

処理され、そのまま DB2 の処理も同じ優先順位で処理されるんだよ。

後輩：確かに、特急で入ってきた WAS のリクエストが DB2 に入ってから、突然ゆっくり処理され

ても、処理待ちのリクエストが溜まってしまいますね。

リクエストとして一気通貫の管理が必要ですね。

先輩：そうだね。

また、運用の点でも、この WAS と DB2 とが緊密連携している、というこの構成はメリッ

トがあるんだよ。

後輩：はあ。いろいろなメリットがあるんですね。

いったいいくつメリットがあるんだろう。。覚えきれない。。今度の試験にでますか？

先輩：君、学生じゃないんだから、そんな試験は無いよ、仕事だから。とはいえ、深く理解して、

また実機で体感しておくと、良いよ。

早いうちに、楽しく学んでおくことは、後で自分の財産になるから。

後輩：ご指導ありがとうございます！いつも先輩に教えていただいてばかりですみません。

先輩：いやいや、そのうち、こっちもいろいろ教えてもらうよ。

ところで、運用の話だけど、例えば 2 つの WAS が 2くaけ Sけかえleぐの上でクラスター構

成になっていて、後ろのデータ共用のデータにアクセスするとするよね。入り口に負荷分散

装置か何かがあって、一方の WAS に入ってきて、アプリケーションの処理をしてから、同

じ OS 上の DB2 に接続するとすれば、WAS の入り口を止めるだけで、後ろの DB2 へリ

クエストはいかなくなるよね。運用がわかりやすくて楽なんだ。

WAS と DB2 の接続形態や配置は、その後の運用も考えて決める必要があるよ。

ただ、Tけえe4 のリモートアクセスの場合は、通常 WAS からアクセスできる DB2 が後ろ

に 2 つあったとしたら、負荷分散して DB2 にアクセスしたりする。

その場合は、片方の入り口を塞いでも、後ろの DB2 へのアクセスは止めることができない。

別の WAS からもリクエストがくる可能性があるからだ。

今はひとつの例だけれど、WAS fぇおげ/OS の配置は、Tけえe2 接続を使って、片系ずつ

シンプルに接続しておくことが、運用を楽にして、お勧めなんだ。


115115


116116


図 8：DB2 のタイプ 2 とタイプ 4 接続

後輩：そうなんですか。シンプル・イズ・ベストですね。

先輩の仕事の邪魔をして申し訳ないのですが、これだけ Sけかえleぐ環境での WAS fぇおげ/

OS のことがわかってきたので、後もう少しだけ WAS fぇおげ/OS の可用性と運用の関係に

ついて教えてください。

それだけ聞いたら、自信を持って、別プロジェクトの Sけかえleぐ WAS について入っていけ

そうです。

先輩：よし。がんばっているな。眠らないようについてこいよ！

後輩：はい！

　WAS for z/OS が止まる時

先輩：立ち上げた WAS サーバーを止めなければいけない場面は思い浮かぶかな。

後輩：はい、ええっと、アプリケーションを入れ替える時や、それから外に出かけていて使ってい

ない時や帰宅する時は必ず止めて帰ります。節電です。


先輩：そうか。会社ではそれでよくても、本番稼働している業務ではそんなに止められないんだ。

24 時間 365 日 WAS を稼働させなくてはならないところでは、ローリング・メンテナンス

といって、1 区画ずつ順番に止めてアプリ入れ替えや Fぁぐ適用を行っていき、ユーザーか

らは常時サーバーが稼働しているように見えるようにするんだ。その間は縮退稼働になるん

だよ。また、そのためには、前にある負荷分散装置で、メンテナンス中の区画に振り分け

ないようにしたり、あるいは WAS fぇおげ/OS ではコマンド※ 21 でリスナー用のポートを閉じ

て負荷分散対象から確実にはずすこともできるんだ。

※ 21. PAUSELISTENERS コマンドを指す。モディファイコマンド　/F < サーバー >,PAUSELISTENERS

によりコマンド実行される。

後輩：そうか。前の入り口を止めておけば、ゆっくり作業できますね。作業が終わったら、

OPENLISTENERS コマンド投入！ですね。

先輩：惜しい！　OPENLISTERNERS ではなくて、RESUMELISTENERS だからね。ただ、

作業の終了でサーバーのポートをすぐに開けるよりは、前の負荷分散装置でも振り分け対

象からはずしておいて、作業の終了を確実に確認したら、サーバーを再立ち上げして、負

荷分散装置に準備ができたことを知らせてリクエストを再受付する、という運用が多いかな。

もう運用デザインの話だけれど。

後輩：あてずっぽうで言ったのがばれてしまいました。

先輩：まあ、そうがっかりせず、君もいつか運用のデザインをする時がくるよ。WAS fぇおげ/OS は、

これまで話したように、Sけかえleぐやげ/OS の機能を十分に活用して、可用性を提供してい

るんだ。それまでに、WAS だけでなく、Sけかえleぐやげ/OS も一緒に勉強すると、最強の

WAS fぇおげ/OS 担当者になれるよ。

後輩：先輩、あまり聞きたくないんですが、WAS サーバーを止めなければならない、というより

止まってしまう場面としては、障害のケースもありますよね。

先輩：そうだね。あまり考えたくないが、このケースをあらかじめ考えておくことは重要だよ。可

用性への要件がある場合は、まず冗長化を考えたほうが良いよ。

後輩： SR を複数枚ですね！

先輩：そう。それはサーバーの可用性を高めるのだけれど、例えば CRに障害が発生してしまうと、

リクエストは受け付けられなくなってしまう。そのために、クラスター構成で、CR の障害に

も備えたほうがいいんだ。


117117


118118


後輩：なるほど。Sけかえleぐとクラスター構成ですね。

先輩：そうそう。君もかなりわかってきたね。昨日の夜遅かった割には。

後輩：先輩、あまりそれを言わないでください。ちょっと夢中になりすぎてしまいました。

先輩：ごめんごめん。それでは今日はこれくらいにしておこう。今度会った時には、ログとかダン

プとか、問題判別の話をしようか。Wぁうdぇくかとか AIX の WAS を動かしていた君には馴

染みのある話もあるけれど、げ/OS 環境特有の話もあって面白いぞ。

後輩：ありがとうございます！　どうもげ/OS の仕組みは難しくてわかりにくいのですが、どんな問

題判別ができるのか、これもちょっと密かに身につけておきたいです。

先輩：了解。それと昨日のパフォーマンス・テストの結果と考察も今度教えてくれ。今度は君が

先生だよ。

後輩：了解いたしました！


4 信頼を支えるきめ細かな問題判別機能

　アプリケーション、動いているかな？

後輩：先輩、助けてください。

先輩：今日は、どうしたんだい。何が起きたの？

後輩：実は、アプリケーション開発チームから、テストで実行したリクエストがアプリケーション・サー

バーに届いているか、確認して欲しいって連絡があったんです。でも、何をしたらいいかわ

からなくて。

先輩：そんなことぐらいで、オロオロしてちゃ、基盤担当は務まらないね。急ぎでないのなら、良

い機会だから、問題判別の心得から勉強してみるかい？

後輩：是非お願いしたいです、と、言いたいところなんですが、『リクエストがアプリケーション・サー

バーに届いているか』を確認する方法を、先に教えてくれませんか？

先輩：ああ、判ったよ。WAS fぇおげ/OS では、アプリケーション・サーバーに対する様々なコマ

ンドが提供されていて、DISPLAY,WORK コマンドがその確認にピッタリのコマンドだよ。

このコマンドは OS コンソールに直接入力するんだ。ちょっとコンソールまで行こう。

サーバーに対するコマンドは、げ/OS のモディファイ・コマンドを使うんだよ。

モディファイ・コマンドは、MODIFY でもいいけど、F の一文字に省略もできるんだ。

F <かeおぎeお_うame>,ぐぐぐぐ　という感じだね。

だから、DISPLAY,WORK コマンドの実行はこういうふうに実行するんだよ。

F WAS8A,DISPLAY,WORK

WAS8A は、君が構築した WAS fぇおげ/OS のアプリケーション・サーバー名だね。

後輩：何か数字がでてきましたね。出力の意味がよく判らないんですが。

F WAS8A,DISPLAY,WORK

BBOO0255I TIME OF LAST WORK DISPLAY 2012/10/01 13:15:23.125623

BBOO0261I TOTAL REQUESTS TO SERVER 14 (DELTA 14)

BBOO0262I TOTAL CURRENT REQUESTS 2

④ 信頼を支えるきめ細かな問題判別機能

119119


120120


BBOO0263I TOTAL REQUESTS IN DISPATCH 2

BBOO0268I TOTAL TIMED OUT REQUESTS 0 (DELTA 0)

BBOO0188I END OF OUTPUT FOR COMMAND DISPLAY,WORK

先輩：このコマンドの出力の意味は以下だよ。

TOTAL REQUESTS TO SERVER　：　このサーバーで処理された総リクエスト数

TOTAL CURRENT REQUESTS　：　現在このサーバーが受け付けているリクエスト数

TOTAL REQUESTS IN DISPATCH　：　現在処理中のリクエスト数

TOTAL TIMED OUT REQUESTS　：　タイムアウトしたリクエスト数

DELTA　：　前回コマンドを実行してからのリクエスト数の差分

後輩：ありがとうございます。じゃあ、コマンド実行時、まさに 2 つのリクエストが処理されてたっ

てことなんですね。アプリケーション開発チームに連絡してきます！

---< 後輩、走っていく>

　問題判別は大切だよ！

後輩：先輩、大丈夫でした。アプリケーション開発チームさん、確認したかっただけだそうです。

コマンド出力説明したら、安心してくれました。

先輩：良かったね、まずは一安心。では、モディファイ・コマンドの続きを説明しようか？他にも、

活動中のタスクのスタック・トレースを表示したり、トレースや DUMP を取得したり、Jaぎa

ヒープのサイズを表示したりもできるんだ。とても豊富なコマンドが揃っていて、役立つよ。

後輩：先輩！　僕だってマニュアルぐらい見ますよ。細かなことは、自分で勉強しますから、さっき

の、問題判別の心得を教えてください。

先輩：では、問題判別の基本から考えよう。図 9 を見てごらん。

問題判別では、問題の兆候（Sけmえがぇm）を見つけ、典型的な問題かどうかの事前チェッ

クを行い、問題の情報収集を行って、収集した情報の分析を行う。これが問題判別の基本

的な流れだよ。

後輩：慌てず、落ち着いて、問題の情報収集を行うことが、大事みたいですね。

先輩：そうだね。問題判別が迅速に正しく行われるかどうかは、問題の情報を如何に確実に取得

出来るかどうかにかかっているんだ。


いま、君が担当しているのは、メインフレームだよね。そして、お客様のアプリケーションは、

基幹業務だ。基幹業務システムは、企業がビジネスを遂行するために不可欠だ。だから君

が問題判別に手間取ると企業や社会に影響を及ぼしてしまうんだよ。

後輩：はい、心得てます。でも、Sけかがem げなら、ハードウェアやソフトウェアそれ自体が信頼性

が高いので、安心してます。

先輩：メインフレームの安定性というのは、ハードウェアやソフトウェアそれ自体の安定性だけの話

ではないんだよ。基盤だってきちんと設計して構築しなきゃいけないし、アプリケーションだっ

てそうだ。全部が揃って、やっと信頼性の高いシステムが出来上がるんだよ。

後輩：はい、判りました。では、僕の役割も大事だってことですね。

先輩：そうだよ。基盤チームの役割も大事なんだ。では、問題判別という観点で、Sけかがem げ

やげ/OS 、WAS fぇおげ/OS が、どれほどしっかりしているか、見ていこう。きちんとログ

をはき出せて、状況を出力出来て、それを追えるようになっている。発生した問題を曖昧

にしない。ひとつひとつ、確実に問題を解決し、品質を上げていく。これが、WAS fぇお

げ/OS の信頼性を支えているんだ。

図 9: 問題判別フロー


121121


122122


後輩：はい、前に WAS fぇおげ/OS のぱ独自機能ぱの話をしてくださった時に、『WAS fぇおげ/OS

は分散系 WAS とは全く違う？』という内容で教えていただきましたね。WAS fぇおげ/OS

は他のプラットフォームの WAS とは、同じだけど、違うんですよね。

先輩：そうだよ、判っているかどうか、曖昧な表現だけど、WAS fぇおげ/OS の問題判別に関係

するところを、勉強していこう。

　WAS for z/OS 関連の問題発生時の資料収集は沢山ある！

先輩：まず、どのプラットフォームの WAS でも出力される問題判別に利用される資料はどんなも

のがあるか、知っているかい？

後輩：はい。まず、アプリケーション・サーバーのログがありますよね。あと、エラーが発生した

時には、FFDC ※ 22 や Heaえdきmえや Jaぎacぇおe が出力されたと思います。FFDC は、

実行時に発生したエラーやイベントが出力されています。Heaえdきmえは、Jaぎa ヒー

プ内のオブジェクトのサイズ、タイプ、参照情報が出力されています。Jaぎacぇおe は、

Jaぎadきmえとも呼ばれ、JVM 実行状況のスナップショットで、JVM 内のすべてのスレッ

ド状況が出力されているんですよね。正しいですか？

※ 22. FFDC（Fぁおかが Faぁlきおe Daがa Caえがきおe）：初期障害データ・キャプチャー機能

先輩：よく勉強しているね。そう、君が今言ったものは、他のプラットフォームでも共通で、WAS

fぇおげ/OS でも同じだね。でもWAS fぇおげ/OS には他にもあるんだよ。

後輩：えっ、まだあるんですか？

先輩：表 1 を見てごらん。WAS fぇおげ/OS 関連ログの一覧だよ。いっぱいあるだろう。WAS

fぇおげ/OS では、これだけ多くの情報が得られるということなんだよ。

後輩：すごいですね。他には無いログがあるということは、他のプラットフォームでは判らないこと

が判るということですか？

先輩：良いことに気づいたね。そうだよ、げ/OS ならではのログが沢山あって、それを解析できる

解析担当者が居て、障害発生時の状況を確実に追うことができるんだ。

後輩：では、僕はこれらの問題判別のための情報を確実に確保して、分析したり、必要に応じて、

解析部門に連携したりしなきゃいけないということなんですね。どういうときに、どういう資

料を確保しなきゃいけないか、判らなくなりそうだなぁ。


表 1：WAS fぇおげ/OS 関連ログ

先輩：『IBM MきかがGaがheお WAS げ/OS』で Web 検索してごらん。トラブルの種類毎に必要な

情報と取得方法を詳細に解説している MきかがGaがheおというサイトが見つかると思うよ。

MきかがGaがheお: Read でおかが fぇお WebSえheおe Aええlぁcaがぁぇう Seおぎeお fぇおげ/OS　だと

URLは、hががえ://くくく.ぁbm.cぇm/かきええぇおが/dぇcぎぁeく.くかか?きぁd=かくg21176043 （US）だね。

後輩：ありがとうございます。問題が発生したとき困らないように、読んでおきます。

先輩：そうだね。障害発生時の一次対応は、手順化して手元に置いておくと良いね。頑張れよ！

　SVCDUMP って素晴らしい！

後輩：ログが沢山あるのは良いんですが、この中の、SVCDUMPって何ですか？

先輩： Heaえdきmえや Jaぎacぇおe は、Jaぎa ヒープ領域内部だけの情報だったよね。また、

Heaえdきmえから取得できるのは、オブジェクトの型、サイズおよびアドレスのみで、内容

の確認はできないんだ。

それに対して、SVCDUMP は、げ/OS で共通に取得できるもので、仮想記憶域そのもの

のダンプなんだ。だから、データそのものの、分析ができるんだよ。ただ、SVCDUMP

の解析には、IPCS ※ 23 というツールを利用するんだけど、いろいろな前提知識が必要だか


123123


124124


ら熟練が必要だよね。君が使いこなすようになるにはハードルが高いだろうねぇ。通常は、

専門の解析担当部門にお願いして、解析してもらうんだよ。

SVC ダンプを WAS で取ると、その中身には Jaぎacぇおe や Heaえdきmえが含まれている

んだよ。

Heaえdきmえ、Jaぎacぇおe、SVCDUMP の関係を表したものが、図 10 だよ。

SVCDUMP では、Jaぎa ヒープ領域だけでなく、Naがぁぎe メモリー領域の様子も分析でき

ることが判るね。

※ 23. IPCS：対話式問題管理システム（Iうがeおacがぁぎe Pおぇblem Cぇうがおぇl Sけかがem）

図 10：各 DUMP 間の関係

後輩： SVCDUMPって凄いですね。

先輩：そうだろ。繰り返しになるが、きちんとログをはき出せて、状況を出力出来て、それを追え

るようになっている。発生した問題を曖昧にしない。Sけかがem げソフトウェアはそういう製

品なんだよ。


　高い信頼性を実現するアプリケーション・サーバー基盤

後輩：先輩、長々とありがとうございました。WAS が Sけかがem げ上で稼働するということのメリッ

トは、WAS fぇおげ/OS そのものが、げ/OS や Sけかえleぐの機能を取り入れ、堅牢性に優れ

た作りになっているということだけでなく、げ/OS 上で稼働する基幹ミドルウエアとして、と

ても優れた問題判別機能を備えているということが判りました。

先輩：よく判ってくれたね。今日のぱ問題判別ぱの話だけでなく、今までの WAS fぇおげ/OS のぱ

独自機能ぱ、ぱパフォーマンス改善ぱ、ぱ高可用性ぱの話でも判ったように、WAS fぇおげ/

OS には、げ/OS で稼働するこだわりがあることが判ったね。WAS fぇおげ/OS は、ミッショ

ン・クリティカルな業務や、安定性、信頼性を求めるお客様にご利用いただいているんだよ。

WAS fぇおげ/OS は、げプラットフォームの堅牢性を最大限に活用できる、高い信頼性を実

現するアプリケーション・サーバー基盤である、ということだね。

今のプロジェクトは始まったばかりだ。良い製品で、良い設計をして、良い運用をしよう。

お客様のシステムの安定稼働のために、すべきことは沢山あるぞ。

後輩：はい、マイスター先輩、どうもありがとうございます。引き続き、よろしくお願いいたします。

頑張ります！


185

IBM、IBM ロゴ、ibm.com、AIX、CICS、CICSPlex、DB2、IMS、InfoSphere、NetVeiw、pureScale、RAA、

RACF、Rational、Rational Team Concert、SPSS、System z、Tivoli、WebSphere、z/OS およびｚSecure は、

世界の多くの国で登録された International Business Machines Corporation の商標です。他の製品名および

サービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、

www.ibm.com/legal/copytrade.shtml をご覧ください。

● 掲載された情報は 2013 年 3 月現在のものです。事前の予告なく変更する場合があります。

● 製品、サービスなどの詳細については、弊社もしくは IBM ビジネスパートナーの営業担当員にご相談ください。

● 本事例中に記載の肩書や数値、固有名詞は掲載当時のものであり、変更されている可能性があることをご了承ください。

Zマイスターとの新たな価値探求 WebSphere

Software