Cosminexus　システム設計ガイド

解説書

3020-3-M04-61

目　　次

前書き

変更内容

はじめに

1.　Cosminexusのシステム設計の目的と流れ

1.1　Cosminexusのシステム設計の目的

1.2　システム設計の流れ

1.2.1　オンライン処理を実行するアプリケーション（J2EEアプリケーション）の場合

1.2.2　バッチ処理を実行するアプリケーション（バッチアプリケーション）の場合

2.　システム設計の準備

2.1　システム設計を始める前に決めておくこと

2.2　業務の種類を明確にする

2.3　システムの目的に応じたアプリケーションの構成を決める（オンライン処理を実行する業務の場合）

2.3.1　動作させるJ2EEアプリケーションの検討

2.3.2　使用するプロセスの検討と必要なソフトウェアの準備

2.4　システムの目的に応じたアプリケーションの構成を決める（バッチ処理を実行する業務の場合）

2.4.1　動作させるバッチアプリケーションの検討

2.4.2　使用するプロセスの検討と必要なソフトウェアの準備

2.5　運用方法を検討する

2.5.1　JP1と連携したシステムの運用

2.5.2　クラスタソフトウェアと連携したシステムの運用

3.　システム構成の検討（J2EEアプリケーション実行基盤）

3.1　システム構成を検討するときに考慮すること

3.1.1　システムの目的と構成

3.1.2　システム構成の設計手順

3.1.3　システム構成の考え方

3.2　システム構成の説明について

3.3　アプリケーションの構成を検討する

3.3.1　アプリケーションの構成とアクセスポイント

3.3.2　リソースの種類とリソースアダプタ

3.4　クライアントとサーバの構成を検討する

3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）

3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（インプロセスHTTPサーバを使用する場合）

3.4.3　Session BeanとEntity Beanをアクセスポイントに使用する構成

3.4.4　CTMを使用する場合にStateless Session Beanをアクセスポイントに使用する構成

3.5　サーバ間での連携を検討する

3.5.1　Session BeanとEntity Beanを呼び出すサーバ間連携

3.5.2　CTM経由でStateless Session Beanを呼び出すサーバ間連携

3.6　トランザクションの種類を検討する

3.6.1　ローカルトランザクションを使用する場合の構成

3.6.2　グローバルトランザクションを使用する場合の構成

3.6.3　トランザクションコンテキストのプロパゲーションを使用する場合の構成

3.7　ロードバランスクラスタによる負荷分散方式を検討する

3.7.1　Webサーバ連携時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合）

3.7.2　インプロセスHTTPサーバ使用時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合）

3.7.3　CORBAネーミングサービスを利用した負荷分散（Session BeanとEntity Beanの場合）

3.7.4　CTMを利用した負荷分散（Stateless Session Beanの場合）

3.8　サーバ間で非同期通信をする場合の構成を検討する

3.8.1　Message-driven Beanをアクセスポイントに使用する場合の構成（TP1/Message Queueを使用する場合）

3.8.2　Message-driven Beanをアクセスポイントに使用する場合の構成（Cosminexus RMを使用する場合）

3.8.3　Message-driven Beanのインスタンスプールを利用した負荷分散（TP1/Message Queueを使用する場合）

3.9　運用管理プロセスの配置を検討する

3.9.1　運用管理サーバにManagement Serverを配置する構成

3.9.2　マシン単位にManagement Serverを配置する構成

3.9.3　コマンドで運用する場合の構成

3.10　SFOサーバを使用したセッション情報の引き継ぎを検討する

3.10.1　SFOサーバがシステムに複数存在する構成

3.10.2　SFOサーバがシステムに一つだけ存在する構成

3.11　クラスタソフトウェアを使用した障害時の系切り替えを検討する

3.11.1　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合）

3.11.2　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用する場合）

3.11.3　運用管理サーバの実行系と待機系を1:1にする構成

3.11.4　アプリケーションサーバの実行系と待機系を相互スタンバイにする構成

3.11.5　リカバリ専用サーバを使用する場合の構成（N:1リカバリシステム）

3.12　ファイアウォールを使用する構成を検討する

3.12.1　サーブレットとJSPに対するファイアウォールの配置

3.12.2　Session BeanとEntity Beanに対するファイアウォールの配置

3.12.3　リソースマネジャに対するファイアウォールの配置

3.13　DMZへのリバースプロキシの配置を検討する

3.13.1　Webサーバ連携時のリバースプロキシの配置

3.13.2　インプロセスHTTPサーバ使用時のリバースプロキシの配置

3.14　性能解析トレースファイルを出力するプロセスを配置する

3.15　Cosminexus以外の製品との連携を検討する

3.15.1　JP1を使用して運用する場合の構成

3.15.2　CTMゲートウェイ機能を利用してEJBクライアント以外からStateless Session Beanを呼び出す構成

3.16　任意のプロセスを運用管理の対象にする

3.17　そのほかの構成を検討する

3.17.1　Webサーバとアプリケーションサーバを異なるマシンに配置する構成

3.17.2　リダイレクタを利用して負荷分散する構成

3.17.3　CORBAネーミングサービスをアウトプロセスで起動する構成

3.18　Cosminexusのプロセスが使用するTCP/UDPのポート番号

4.　システム構成の検討（バッチアプリケーション実行基盤）

4.1　システム構成を検討するときに考慮すること

4.1.1　システムの目的と構成

4.1.2　システム構成の設計手順

4.1.3　バッチサーバが使用するTCP/UDPのポートについての注意事項

4.2　バッチサーバを使用する場合のシステム構成

4.2.1　システム構成の特徴

4.2.2　それぞれのマシンに必要なプロセスとソフトウェア

5.　セキュアなシステムの検討

5.1　セキュアなシステムの検討の概要

5.2　セキュアなシステムの構成の検討

5.3　システムの使用者の検討

5.4　システムが扱う資産の検討

5.5　セキュアなシステムの前提条件の確認

5.5.1　物理的な前提条件

5.5.2　運用上の前提条件

5.6　想定される脅威の分析

5.7　対策の検討

5.7.1　前提条件に対して実施する対策

5.7.2　想定した脅威に対して実施する対策

5.7.3　対策を実施したセキュアなシステムの動作

5.8　作業手順の検討

5.8.1　作成する作業手順書の概要

5.8.2　システムの構築手順の検討

5.8.3　システムの再構築手順の検討

5.8.4　システムの運用手順の検討

5.9　システムの監査方法の確認

5.9.1　監査ログの入手

5.9.2　監査ログの調査

5.10　外部ネットワークを使用するシステムでのセキュリティの検討

5.10.1　外部ネットワークを使用するシステムで想定されるセキュリティ上の脅威

5.10.2　ファイアウォールと侵入検知システムを配置する

5.10.3　SSLアクセラレータを使用して暗号通信を処理する

5.10.4　アプリケーションでユーザを認証する

6.　パフォーマンスチューニング（J2EEアプリケーション実行基盤）

6.1　パフォーマンスチューニングで考慮すること

6.1.1　パフォーマンスチューニングの観点

6.1.2　チューニング手順

6.1.3　アプリケーションの種類ごとにチューニングできる項目

6.2　チューニングの方法

6.3　同時実行数を最適化する

6.3.1　同時実行数制御および実行待ちキュー制御の考え方

6.3.2　最大同時実行数と実行待ちキューを求める手順

6.3.3　Webサーバでのリクエスト処理スレッド数を制御する

6.3.4　Webアプリケーションの同時実行数を制御する

6.3.5　Enterprise Beanの同時実行数を制御する

6.3.6　CTMを使用して同時実行数を制御する

6.3.7　同時実行数を最適化するためのチューニングパラメタ

6.4　Enterprise Beanの呼び出し方法を最適化する

6.4.1　ローカルインタフェースを使用する

6.4.2　リモートインタフェースのローカル呼び出し最適化機能を使用する

6.4.3　リモートインタフェースの参照渡し機能を使用する

6.4.4　Enterprise Beanの呼び出し方法を最適化するためのチューニングパラメタ

6.5　データベースへのアクセス方法を最適化する

6.5.1　コネクションプーリングを使用する

6.5.2　ステートメントプーリングを使用する

6.5.3　データベースへのアクセス方法を最適化するためのチューニングパラメタ

6.6　タイムアウトを設定する

6.6.1　タイムアウトが設定できるポイント

6.6.2　Webフロントシステムでのタイムアウトを設定する

6.6.3　バックシステムでのタイムアウトを設定する

6.6.4　トランザクションタイムアウトを設定する

6.6.5　データベースでのタイムアウトを設定する

6.6.6　J2EEアプリケーションのメソッドタイムアウトを設定する

6.6.7　タイムアウトを設定するチューニングパラメタ

6.7　Webアプリケーションの動作を最適化する

6.7.1　静的コンテンツとWebアプリケーションの配置を切り分ける

6.7.2　静的コンテンツをキャッシュする

6.7.3　リダイレクタによってリクエストを振り分ける

6.7.4　Webアプリケーションの動作を最適化するためのチューニングパラメタ

6.8　CTMの動作を最適化する

6.8.1　CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔をチューニングする

6.8.2　負荷状況監視間隔をチューニングする

6.8.3　CTMデーモンのタイムアウト閉塞を設定する

6.8.4　CTMで振り分けるリクエストの優先順位を設定する

6.8.5　CTMの動作を最適化するチューニングパラメタ

6.9　そのほかの項目のチューニング

7.　パフォーマンスチューニング（バッチアプリケーション実行基盤）

7.1　パフォーマンスチューニングで考慮すること

7.1.1　パフォーマンスチューニングの観点

7.1.2　チューニング手順

7.1.3　チューニング項目

7.2　チューニングの方法

7.2.1　バッチサーバのチューニング

7.2.2　リソースのチューニング

7.3　タイムアウトを設定する

7.3.1　タイムアウトが設定できるポイント

7.3.2　トランザクションタイムアウトを設定する

7.3.3　タイムアウトを設定するチューニングパラメタ

7.4　ガーベージコレクション制御で使用するしきい値を設定する

7.4.1　しきい値を設定する目的

7.4.2　しきい値設定の考え方

7.4.3　ガーベージコレクション制御で使用するしきい値を設定するためのチューニングパラメタ

8.　JavaVMのチューニング

8.1　ガーベージコレクションとJavaVMのメモリ管理の概要

8.1.1　ガーベージコレクションの仕組み

8.1.2　JavaVMで使用するメモリ空間の構成とJavaVMオプション

8.1.3　ガーベージコレクションの発生とメモリ空間の関係

8.2　JavaVMのチューニングの考え方と手順

8.2.1　チューニングの考え方

8.2.2　メモリサイズの見積もり手順

8.2.3　メモリサイズの設定方法

8.2.4　メモリサイズの使用状況の確認方法

8.3　Tenured領域のメモリサイズの見積もり

8.3.1　アプリケーションで必要なメモリサイズの算出

8.3.2　DefNew領域のメモリサイズを追加する理由

8.4　DefNew領域のメモリサイズの見積もり

8.4.1　DefNew::Survivor領域のメモリサイズの見積もり

8.4.2　DefNew::Eden領域のメモリサイズの見積もり

8.5　一定期間存在するオブジェクトの扱いの検討

8.5.1　DefNew領域に格納する方法

8.5.2　Tenured領域に格納する方法

8.6　Javaヒープの最大サイズ／初期サイズの決定

8.7　Permanent領域のメモリサイズの見積もり

8.8　拡張verbosegc情報を使用したフルガーベージコレクションの要因の分析方法

8.8.1　拡張verbosegc情報の出力形式の概要

8.8.2　フルガーベージコレクション発生時の拡張verbosegc情報の出力例

付録

付録A　ベーシックモードの利用（互換機能）

付録A.1　パフォーマンスチューニング

付録B　サーブレットエンジンモードの利用（互換機能）

付録B.1　システム構成の設計

付録B.2　パフォーマンスチューニング

付録C　推奨手順以外の方法でパフォーマンスチューニングをする場合のチューニングパラメタ

付録C.1　同時実行数を最適化するためのチューニングパラメタ（推奨手順以外の方法）

付録C.2　Enterprise Beanの呼び出し方法を最適化するためのチューニングパラメタ（推奨手順以外の方法）

付録C.3　データベースへのアクセス方法を最適化するためのチューニングパラメタ（推奨手順以外の方法）

付録C.4　タイムアウトを設定するチューニングパラメタ（推奨手順以外の方法）

付録C.5　Webアプリケーションの動作を最適化するためのチューニングパラメタ（推奨手順以外の場合）

付録C.6　CTMの動作を最適化するチューニングパラメタ（推奨手順以外の方法）

付録C.7　Persistent Connectionについてのチューニングパラメタ（推奨手順以外の方法）

付録C.8　バッチサーバのフルガーベージコレクションを発生させるしきい値を設定するためのチューニングパラメタ（推奨手順以外の方法）

付録D　（3020-3-M04-61）の変更内容

付録E　用語解説

索引

[他社商品名称に関する表示]

All Rights Reserved. Copyright (C) 2006, 2008, Hitachi, Ltd.

前書き

■ 対象製品

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64），Windows Server 2003 R2（x64）

P-2443-7D74　 uCosminexus Application Server Standard　 07-60
P-2443-7K74　 uCosminexus Application Server Enterprise　 07-60
P-2443-7M74　 uCosminexus Web Redirector　 07-60
P-2443-7S74　 uCosminexus Service Platform　 07-60※

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Vista，Windows XP

P-2443-7E74　 uCosminexus Developer Standard　 07-60
P-2443-7F74　 uCosminexus Developer Professional　 07-60
P-2443-7T74　 uCosminexus Service Architect　 07-60※
P-2443-7U74　 uCosminexus Operator　 07-60※

●適用OS：Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64），Windows Server 2003 R2（x64），Windows Vista，Windows XP

P-2443-7H74　 uCosminexus Client　 07-60

●適用OS：AIX 5L V5.2，AIX 5L V5.3

P-1M43-7D71　 uCosminexus Application Server Standard　 07-60※
P-1M43-7K71　 uCosminexus Application Server Enterprise　 07-60※
P-1M43-7M71　 uCosminexus Web Redirector　 07-60※
P-1M43-7S71　 uCosminexus Service Platform　 07-60※

●適用OS：HP-UX 11i V2（IPF），HP-UX 11i V3（IPF）

P-1J43-7D71　 uCosminexus Application Server Standard　 07-60※
P-1J43-7K71　 uCosminexus Application Server Enterprise　 07-60※
P-1J43-7M71　 uCosminexus Web Redirector　 07-60※

●適用OS：Red Hat Enterprise Linux AS 3（x86），Red Hat Enterprise Linux AS 4（x86），Red Hat Enterprise Linux ES 3（x86），Red Hat Enterprise Linux ES 4（x86），Red Hat Enterprise Linux AS 3（AMD64 & Intel EM64T），Red Hat Enterprise Linux AS 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux ES 3（AMD64 & Intel EM64T），Red Hat Enterprise Linux ES 4（AMD64 & Intel EM64T）

P-9S43-7D71　 uCosminexus Application Server Standard　 07-60※
P-9S43-7K71　 uCosminexus Application Server Enterprise　 07-60※
P-9S43-7M71　 uCosminexus Web Redirector　 07-60※

●適用OS：Red Hat Enterprise Linux AS 3（x86），Red Hat Enterprise Linux AS 4（x86），Red Hat Enterprise Linux 5 Advanced Platform（x86），Red Hat Enterprise Linux ES 3（x86），Red Hat Enterprise Linux ES 4（x86），Red Hat Enterprise Linux 5（x86），Red Hat Enterprise Linux AS 3（AMD64 & Intel EM64T），Red Hat Enterprise Linux AS 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux 5 Advanced Platform（AMD/Intel 64），Red Hat Enterprise Linux ES 3（AMD64 & Intel EM64T），Red Hat Enterprise Linux ES 4（AMD64 & Intel EM64T），Red Hat Enterprise Linux 5（AMD/Intel 64）

P-9S43-7S71　 uCosminexus Service Platform　 07-60※

●適用OS：Red Hat Enterprise Linux AS 3（IPF），Red Hat Enterprise Linux AS 4（IPF），Red Hat Enterprise Linux 5 Advanced Platform（Intel Itanium）

P-9V43-7D71　 uCosminexus Application Server Standard　 07-60※
P-9V43-7K71　 uCosminexus Application Server Enterprise　 07-60※
P-9V43-7M71　 uCosminexus Web Redirector　 07-60※

●適用OS：Solaris 9，Solaris 10

P-9D43-7D71　 uCosminexus Application Server Standard　 07-60※
P-9D43-7K71　 uCosminexus Application Server Enterprise　 07-60※
P-9D43-7M71　 uCosminexus Web Redirector　 07-60※
P-9D43-7S71　 uCosminexus Service Platform　 07-60※

※印の製品については，サポート時期をご確認ください。
これらのプログラムプロダクトのほかにもこのマニュアルをご利用になれる場合があります。詳細は「リリースノート」でご確認ください。
本製品では日立トレース共通ライブラリをインストールします。

■ 輸出時の注意

本製品を輸出される場合には，外国為替および外国貿易法ならびに米国の輸出管理関連法規などの規制をご確認の上，必要な手続きをお取りください。
なお，ご不明な場合は，弊社担当営業にお問い合わせください。

■ 商標類

AIXは，米国における米国International Business Machines Corp.の登録商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
Borlandのブランド名および製品名はすべて，米国Borland Software Corporationの米国およびその他の国における商標または登録商標です。
CORBAは，Object Management Groupが提唱する分散処理環境アーキテクチャの名称です。
HP-UXは，米国Hewlett-Packard Companyのオペレーティングシステムの名称です。
IIOPは，OMG仕様によるORB(Object Request Broker)間通信のネットワークプロトコルの名称です。
Intelは，Intel Corporationの会社名です。
Itaniumは，アメリカ合衆国および他の国におけるインテル コーポレーションまたはその子会社の登録商標です。
Java及びすべてのJava関連の商標及びロゴは，米国及びその他の国における米国Sun Microsystems, Inc.の商標または登録商標です。
JDKは，米国 Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
Linuxは，Linus Torvaldsの米国およびその他の国における登録商標あるいは商標です。
Microsoftは，米国およびその他の国における米国Microsoft Corp.の登録商標です。
Microsoft Internet Information Servicesは，米国Microsoft Corp.の商品名称です。
Microsoft SQL Serverは，米国Microsoft Corp.の商品名称です。
OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。
ORACLEは，米国Oracle Corporationの登録商標です。
Oracleは，米国Oracle Corporation及びその子会社，関連会社の登録商標です。
Oracle9iは，米国Oracle Corporationの商標です。
Oracle 10gは，米国Oracle Corporationの商標です。
PA-RISCは，米国Hewlett-Packard Companyの商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標若しくは商標です。
Solarisは，米国Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
SQL Serverは，米国法人Sybase，Inc.の商標です。
Sun，Sun Microsystems，Javaは，米国Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
UNIXは，X/Open Company Limited が独占的にライセンスしている米国ならびに他の国における登録商標です。
Windowsは，米国およびその他の国における米国Microsoft Corp.の登録商標です。
Windows Serverは，米国Microsoft Corporationの米国及びその他の国における登録商標です。
Windows Vistaは，米国Microsoft Corporationの米国及びその他の国における登録商標です。
X/Openは，X/Open Company Limited の英国ならびに他の国における登録商標です。
Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).
プログラムプロダクト「P-9D43-7D71，P-9D43-7K71，P-9D43-7M71，P-9D43-7S71」には，米国Sun Microsystems,Inc.が著作権を有している部分が含まれています。
プログラムプロダクト「P-9D43-7D71，P-9D43-7K71，P-9D43-7M71，P-9D43-7S71」には，UNIX System Laboratories,Inc.が著作権を有している部分が含まれています。

■ 発行

2006年4月 (第1版) 3020-3-M04
2008年1月 (第4.1版) 3020-3-M04-61

■ 著作権

All Rights Reserved. Copyright (C) 2006, 2008, Hitachi, Ltd.

変更内容

変更内容（3020-3-M04-61）

追加・変更内容 | 変更個所
記載内容を変更した。詳細は，付録Dを参照のこと。 | 付録D

変更内容（3020-3-M04-60）uCosminexus Application Server Standard 07-60，uCosminexus Developer Standard 07-60，uCosminexus Developer Professional 07-60，uCosminexus Client 07-60，uCosminexus Application Server Enterprise 07-60，uCosminexus Web Redirector 07-60，uCosminexus Service Platform 07-60，uCosminexus Service Architect 07-60，uCosminexus Operator 07-60

追加・変更内容
変更個所

Application Serverで，バッチ処理を実行するアプリケーションの実行基盤をサポートした。これに伴い，バッチアプリケーションおよびバッチサーバに関する説明を追加した。
1.2，1.2.2，2.2，2.4，2.4.1，2.4.2，2.5.2，3.2，4章，7章，8.1.2，付録D

Solarisについての説明を追加した。
2.5.2，3.1.2，3.11

次の製品の適用OSに，Red Hat Enterprise Linux 5 Advanced Platform（x86），Red Hat Enterprise Linux 5（x86），Red Hat Enterprise Linux 5 Advanced Platform（AMD/Intel 64），およびRed Hat Enterprise Linux 5（AMD/Intel 64）を追加した。

uCosminexus Service Platform

－

次の製品の適用OSにLinux（IPF）を追加した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Web Redirector

－

次の製品の適用OSにSolarisを追加した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Web Redirector

uCosminexus Service Platform

－

HP-UX（PA-RISC）のサポート中止に伴い，このOSに適応していた次の製品の記述を削除した。

uCosminexus Application Server Standard

uCosminexus Application Server Enterprise

uCosminexus Web Redirector

－

次の製品の適用OSからHP-UX（IPF）を削除した。

uCosminexus Service Platform

－

単なる誤字・脱字などはお断りなく訂正しました。

変更内容（3020-3-M04-40）uCosminexus Application Server Standard 07-50，uCosminexus Developer Standard 07-50，uCosminexus Developer Professional 07-50，uCosminexus Client 07-50，uCosminexus Application Server Enterprise 07-50，uCosminexus Web Redirector 07-50，uCosminexus Service Platform 07-50，uCosminexus Service Architect 07-50，uCosminexus Operator 07-50

追加・変更内容

システムを構築・運用する方法の推奨を，Smart Composer機能を使用する方法に変更した。運用管理ポータルおよびファイル編集による方法は，開発環境またはテスト環境で必要に応じて使用する方法とした。

XDM/RD E2にHiRDB Type4 JDBC Driverで接続できるようにした。

データベースとしてSQL Server 2005が使用できるようにした。

セキュリティフィルタおよびセキュリティアナライザについての記述を削除した。

セキュアなシステムを構築または運用するための考え方についての記述を追加した。

監査ログを出力する機能を追加した。

データベース監査証跡と連携する機能を追加した。

JP1/PAM，JP1/Cm2/NNM，およびJP1/PFM/SSOと連携する機能を削除した。

AIX 5L V5.1のサポート中止に伴い，このOSに適応していた次の製品の記述を削除した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Service Platform

uCosminexus Web Redirector

Microsoft(R) Windows(R) 2000 Advanced Server Operating System，Microsoft(R) Windows(R) 2000 Datacenter Server Operating System，およびMicrosoft(R) Windows(R) 2000 Server Operating Systemのサポート中止に伴い，これらのOSに適応していた次の製品の記述を削除した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Client

uCosminexus Developer Professional

uCosminexus Developer Standard

uCosminexus Operator

uCosminexus Service Architect

uCosminexus Service Platform

uCosminexus Web Redirector

Microsoft(R) Windows(R) 2000 Professional Operating Systemのサポート中止に伴い，このOSに適応していた次の製品の記述を削除した。

uCosminexus Client

uCosminexus Developer Professional

uCosminexus Developer Standard

uCosminexus Operator

uCosminexus Service Architect

次の製品の適用OSに，HP-UX（IPF）を追加した。

uCosminexus Service Platform

次の製品の適用OSに，HP-UX 11i V3（IPF）を追加した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Web Redirector

次の製品の適用OSに，Red Hat Enterprise Linux ES 3（AMD64 & Intel EM64T），およびRed Hat Enterprise Linux ES 4（AMD64 & Intel EM64T）を追加した。

uCosminexus Application Server Enterprise

uCosminexus Application Server Standard

uCosminexus Service Platform

uCosminexus Web Redirector

次の製品の適用OSに，Windows Vistaを追加した。

uCosminexus Client

uCosminexus Developer Professional

uCosminexus Developer Standard

uCosminexus Operator

uCosminexus Service Architect

変更内容（3020-3-M04-20）uCosminexus Application Server Standard 07-10，uCosminexus Application Server Enterprise 07-10，uCosminexus Developer Standard 07-10，uCosminexus Developer Professional 07-10，uCosminexus Client 07-10，uCosminexus Web Redirector 07-10，uCosminexus Service Platform 07-10，uCosminexus Service Architect 07-10，uCosminexus Operator 07-10

追加・変更機能

HiRDB Version 8対応に伴い，HiRDB Type4 JDBC Driverを使用できるようになった。これに伴い，HiRDB Type4 JDBC Driverに関する説明を追加した。

Smart Composer機能を使用して，CTMを使用したシステムを構築できるようになった。これに伴い，Smart Composer機能でのCTMに関する説明を追加した。

uCosminexus Application Server Standard，uCosminexus Application Server Enterprise，およびuCosminexus Web Redirectorの適用OSに，HP-UX（PA-RISC）を追加した。

uCosminexus Application Server Standard，uCosminexus Application Server Enterprise，およびuCosminexus Web Redirectorの適用OSに，Linux（IPF）を追加した。

uCosminexus Service Platformの適用OSに，AIXを追加した。

はじめに

このマニュアルは，Cosminexus（コズミネクサス）を使用して構築するアプリケーションサーバのシステム設計について説明したものです。

Cosminexusでは，次に示すプログラムプロダクトを使用してアプリケーションサーバを構築，運用します。

P-1J43-7D71　uCosminexus Application Server Standard

P-1J43-7K71　uCosminexus Application Server Enterprise

P-1J43-7M71　uCosminexus Web Redirector

P-1M43-7D71　uCosminexus Application Server Standard

P-1M43-7K71　uCosminexus Application Server Enterprise

P-1M43-7M71　uCosminexus Web Redirector

P-1M43-7S71　uCosminexus Service Platform

P-2443-7D74　uCosminexus Application Server Standard

P-2443-7E74　uCosminexus Developer Standard

P-2443-7F74　uCosminexus Developer Professional

P-2443-7H74　uCosminexus Client

P-2443-7K74　uCosminexus Application Server Enterprise

P-2443-7M74　uCosminexus Web Redirector

P-2443-7S74　uCosminexus Service Platform

P-2443-7T74　uCosminexus Service Architect

P-2443-7U74　uCosminexus Operator

P-9D43-7D71　uCosminexus Application Server Standard

P-9D43-7K71　uCosminexus Application Server Enterprise

P-9D43-7M71　uCosminexus Web Redirector

P-9D43-7S71　uCosminexus Service Platform

P-9S43-7D71　uCosminexus Application Server Standard

P-9S43-7K71　uCosminexus Application Server Enterprise

P-9S43-7M71　uCosminexus Web Redirector

P-9S43-7S71　uCosminexus Service Platform

P-9V43-7D71　uCosminexus Application Server Standard

P-9V43-7K71　uCosminexus Application Server Enterprise

P-9V43-7M71　uCosminexus Web Redirector

このマニュアルでは，これらのプログラムプロダクトの構成ソフトウェアのうち，次に示す構成ソフトウェアについて説明しています。

Cosminexus Component Container

Cosminexus Component Container - Client

Cosminexus Operator Plug-in

Cosminexus Component Container - Redirector

Cosminexus Component Transaction Monitor

Cosminexus DABroker Library

Cosminexus Developer's Kit for Java

Cosminexus Performance Tracer

Cosminexus TPBroker

なお，オペレーティングシステム（OS）の種類によって，機能が異なる場合があります。OSごとの違いがある場合の表記方法については，「適用OSの違いによる機能相違点の表記」を参照してください。

対象読者

このマニュアルは，Cosminexusを使ったシステムを設計する方を対象にしています。

次の内容を理解されていることを前提としています。

OS（WindowsまたはUNIX）のシステム構築および運用に関する知識

J2EEに関する知識

SQLおよびリレーショナルデータベースに関する基本的な知識

CORBAに関する基本的な知識

なお，JP1連携機能を使用する場合は，次の内容も理解されていることを前提とします。

JP1の統合管理，ジョブ管理，ネットワーク管理およびアベイラビリティ管理に関する基本的な知識

Microsoft Cluster Service連携機能を使用する場合は，次の内容も理解されていることを前提とします。

Microsoft Cluster Serviceを使用したクラスタ構成に関する基本的な知識

HAモニタ連携機能を使用する場合は，次の内容も理解されていることを前提とします。

HAモニタを使用したクラスタ構成に関する基本的な知識

また，このマニュアルは，マニュアル「Cosminexus　機能解説」を理解していることを前提としていますので，あらかじめお読みいただくことをお勧めします。

マニュアルの構成

このマニュアルは，次に示す章と付録から構成されています。

第1章　Cosminexusのシステム設計の目的と流れ

Cosminexusのシステムの目的と，システム設計作業の流れについて説明しています。

第2章　システム設計の準備

Cosminexusのシステム設計を始める前に決めておく必要があること，および準備しておく必要があることについて説明しています。

第3章　システム構成の検討（J2EEアプリケーション実行基盤）

J2EEアプリケーションを実行してオンライン処理をする場合のシステム構成の検討のしかたについて説明しています。

第4章　システム構成の検討（バッチアプリケーション実行基盤）

バッチアプリケーションを実行してバッチ処理をする場合のシステム構成の検討のしかたについて説明しています。

第5章　セキュアなシステムの検討

システムの監査を実行してセキュアなシステムを構築・運用するための考え方，正しい構築・運用手順，および監査の方法について説明しています。なお，この項目は，J2EEアプリケーションを実行するシステムで検討する項目です。

第6章　パフォーマンスチューニング（J2EEアプリケーション実行基盤）

J2EEアプリケーションを実行するシステムをチューニングして性能向上させるために検討する内容と，チューニングの方法について説明しています。

第7章　パフォーマンスチューニング（バッチアプリケーション実行基盤）

バッチアプリケーションを実行するシステムをチューニングして性能向上させるために検討する内容と，チューニングの方法について説明しています。

第8章　JavaVMのチューニング

JavaVMをチューニングして性能向上させるために検討する内容と，チューニングの方法について説明しています。

付録A　ベーシックモードの利用（互換機能）

互換用機能であるベーシックモードを利用する場合のシステム設計について説明しています。

付録B　サーブレットエンジンモードの利用（互換機能）

互換用機能であるサーブレットエンジンモードを利用する場合のシステム設計について説明しています。

付録C　推奨手順以外の方法でパフォーマンスチューニングをする場合のチューニングパラメタ

推奨手順以外の方法でパフォーマンスチューニングをする場合のチューニングパラメタについて説明しています。

付録D　用語解説

このマニュアルで使用している用語の意味について説明しています。

関連マニュアル

Cosminexusのマニュアル体系について，次の図に示します。

マニュアル体系図で示した関連マニュアルについて，それぞれの位置づけを次に示します。

Cosminexus　概説

Cosminexusの製品概要について説明しています。

Cosminexus　機能解説

Cosminexus Component Containerの機能を中心に，uCosminexus Application Serverの概要と提供する機能について説明しています。

Cosminexus　簡易構築・運用ガイド

セットアップウィザードおよびSmart Composer機能を使用して，システムを構築・運用する手順について説明しています。また，セットアップウィザードおよびSmart Composer機能が提供するコマンドやファイルについても説明しています。

Cosminexus　システム構築ガイド

システム構築時に必要な機能の設定方法について説明しています。

Cosminexus　システム運用ガイド

Cosminexusを使用したシステムの運用方法のうち，Smart Composer機能を使用する運用以外の方法について説明しています。

Cosminexus　アプリケーション設定操作ガイド

Cosminexus Component Containerのサーバ管理コマンド，およびServer Plug-inを使用した操作について説明しています。

Cosminexus　運用管理操作ガイド

Cosminexus Component Containerの運用管理ポータルの使用方法について説明しています。

Cosminexus　リファレンス　コマンド編

Cosminexusのシステムを構築・運用するときに使用するコマンドについて説明しています。

Cosminexus　リファレンス　定義編

Cosminexusのシステムを構築・運用するとき，またはアプリケーションを開発するときに，使用するファイルの形式について説明しています。

Cosminexus　メッセージ 1　KAWS／KDAL／KDJE編，Cosminexus　メッセージ 2　KEOS／KEUC／KFCB編，Cosminexus　メッセージ 3　KFCT／KFDB／KFDJ編

Cosminexusで出力されるメッセージについて説明しています。

Hitachi Web Server

Hitachi Web Server（Webサーバ）の構築，管理方法について説明しています。

TPBroker　ユーザーズガイド

Cosminexus TPBrokerの概要，機能，運用方法について説明しています。

Cosminexus Reliable Messaging

Cosminexus RMを使用したメッセージの非同期通信によるアプリケーションの連携方法について説明しています。

Cosminexus　アプリケーション開発ガイド

構築したCosminexusのシステムで動作させる，アプリケーションの開発方法について説明しています。

Cosminexus　リファレンス　API編

アプリケーションの開発で使用するAPIおよびタグについて説明しています。

また，マニュアル体系図に示したマニュアル以外で，このマニュアルと関連するマニュアルを次に示します。必要に応じてお読みください。

Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド（3020-3-M45）

Borland(R) Enterprise Server VisiBroker(R) プログラマーズリファレンス（3020-3-M46）

Cosminexus　サービスプラットフォーム　システム構築・運用ガイド（3020-3-M73）

JP1/Automatic Job Management System 2 設計・運用ガイド（3020-3-K22-20）

高信頼化システム監視機能　HAモニタ　AIX(R)編（3000-9-130）

高信頼化システム監視機能　HAモニタ　HP-UX編（3000-9-131）

高信頼化システム監視機能　HAモニタ　Linux(R)編（3000-9-132）

スケーラブルデータベースサーバ HiRDB Version 8 システム定義（UNIX(R)用）（3000-6-353）

スケーラブルデータベースサーバ HiRDB Version 8 システム定義（Windows(R)用）（3020-6-353）

スケーラブルデータベースサーバ HiRDB Version 7 システム定義（UNIX(R)用）（3000-6-273）

スケーラブルデータベースサーバ HiRDB Version 7 システム定義（Windows(R)用）（3020-6-273）

スケーラブルデータベースサーバ HiRDB Version 8 UAP開発ガイド（3020-6-356）

スケーラブルデータベースサーバ HiRDB Version 7 UAP開発ガイド（UNIX(R)/Windows(R)用）（3000-6-276）

スケーラブルデータベースサーバ HiRDB Version 7 UAP開発ガイド（Windows(R)用）（3020-6-276）

スケーラブルデータベースサーバ HiRDB Version 8 XDM/RD E2接続機能（3020-6-365）

スケーラブルデータベースサーバ HiRDB Version 7 XDM/RD E2接続機能（3000-6-281）

VOS3　データマネジメントシステム XDM E2系 システム定義（XDM/BASE・SD・TM2）（6190-6-625）

VOS3　Database Connection Server（6190-6-648）

なお，このマニュアルでは，次のマニュアルについて，対象OSおよびバージョン番号を省略して表記しています。マニュアルの正式名称とこのマニュアルでの表記を次の表に示します。

正式名称 | このマニュアルでの表記
スケーラブルデータベースサーバ HiRDB Version 8 UAP開発ガイド | HiRDB UAP開発ガイド
スケーラブルデータベースサーバ HiRDB Version 7 UAP開発ガイド(Windows(R)用)
スケーラブルデータベースサーバ HiRDB Version 7 UAP開発ガイド(UNIX(R)/Windows(R)用)
スケーラブルデータベースサーバ HiRDB Version 8 システム定義（Windows(R)用） | HiRDB システム定義
スケーラブルデータベースサーバ HiRDB Version 8 システム定義（UNIX(R)用）
スケーラブルデータベースサーバ HiRDB Version 7 システム定義（Windows(R)用）
スケーラブルデータベースサーバ HiRDB Version 7 システム定義（UNIX(R)用）
スケーラブルデータベースサーバ HiRDB Version 8 XDM/RD E2接続機能 | HiRDB XDM/RD E2接続機能
スケーラブルデータベースサーバ HiRDB Version 7 XDM/RD E2接続機能
高信頼化システム監視機能　HAモニタ　AIX(R)編 | 高信頼化システム監視機能　HAモニタ
高信頼化システム監視機能　HAモニタ　HP-UX編
高信頼化システム監視機能　HAモニタ　Linux(R)編

読書手順

このマニュアルは，利用目的に合わせて章を選択して読むことができます。利用目的別にお読みいただくことをお勧めします。

マニュアルを読む目的
記述個所

Cosminexusのシステム設計では何を検討する必要があるのかを知りたい。
1章

システム設計を始める前に準備しておくことについて知りたい。
2章

J2EEアプリケーションを実行するシステムの目的に応じた構成を知りたい。
3章

バッチアプリケーションを実行するシステムの目的に応じた構成を知りたい。
4章

セキュアなシステムを構築・運用する方法を知りたい。
5章

J2EEアプリケーションを実行するシステムのパフォーマンスチューニングの方法について知りたい。
6章

バッチアプリケーションを実行するシステムのパフォーマンスチューニングの方法について知りたい。
7章

JavaVMのチューニングの方法について知りたい。
8章

互換用の動作モードを使用する場合のシステム設計について知りたい。
付録A
付録B

推奨手順以外の方法でパフォーマンスチューニングをする場合のチューニングパラメタについて知りたい。
付録C

Cosminexusのマニュアルで使用している用語について知りたい。
付録D

ご利用製品ごとの用語の読み替えについて

ご利用の製品によっては，マニュアルで使用している用語を，ご利用の製品名に読み替える必要があります。

次の表に従って，マニュアルで使用している用語をご利用の製品名に読み替えてください。

ご利用の製品名 | マニュアルで使用している用語
uCosminexus Developer Professional※1 | Application ServerおよびApplication Server Enterprise
uCosminexus Developer Standard※1※2 | Application Server
uCosminexus Service Architect※1 | Application ServerおよびApplication Server Enterprise
uCosminexus Service Platform

注※1　テスト環境で使用している場合にだけ読み替えが必要です。

注※2　uCosminexus Developer StandardとApplication Serverには一部機能差があります。機能差については，マニュアル「Cosminexus　アプリケーション開発ガイド」のDeveloper Standard使用時の注意事項に関する説明を参照してください。

このマニュアルでの表記

表記 | 製品名
Application Server | Application Server Enterprise | uCosminexus Application Server Enterprise
Application Server Standard | uCosminexus Application Server Standard
Developer | Developer Professional | uCosminexus Developer Professional
Developer Standard | uCosminexus Developer Standard
HiRDBまたはHiRDBサーバ | HiRDB/Parallel Server | HiRDB/Parallel Server Version 7
HiRDB/Parallel Server Version 8
HiRDB/Single Server | HiRDB/Single Server Version 7
HiRDB/Single Server Version 8
HiRDB Run TimeまたはHiRDBクライアント | HiRDB/Run Time Version 7
HiRDB/Run Time Version 8
IPF | Itanium(R) Processor Family
JP1/AJS2 | JP1/AJS2 - Agent | JP1/Automatic Job Management System 2 - Agent
JP1/AJS2 - Light Edition | JP1/Automatic Job Management System 2 - Light Edition
JP1/AJS2 - Manager | JP1/Automatic Job Management System 2 - Manager
JP1/AJS2 - View | JP1/Automatic Job Management System 2 - View
JP1/AJS2 - SO | JP1/AJS2 - SO Manager | JP1/Automatic Job Management System 2 - Scenario Operation Manager
JP1/AJS2 - SO View | JP1/Automatic Job Management System 2 - Scenario Operation View
JP1/Cm2 | JP1/Cm2/ESA | JP1/Cm2/Extensible SNMP Agent
JP1/Cm2/ESA for Extension Mib Runtime | JP1/Cm2/Extensible SNMP Agent for Extension Mib Runtime
JP1/Cm2/NC | JP1/Cm2/NC - Manager | JP1/Cm2/Network Element Configuration - Manager
JP1/Cm2/NC - Manager for Cosminexus | JP1/Cm2/Network Element Configuration - Manager for Cosminexus
JP1/ESP | JP1/Extensible Service Probe
JP1/IM | JP1/IM - Central Console | JP1/Integrated Manager - Central Console
JP1/IM - CM | JP1/Integrated Management - Central Information Master
JP1/Integrated Manager - Central Information Master
JP1/IM - Central Scope | JP1/Integrated Manager - Central Scope
JP1/IM - Manager | JP1/Integrated Management - Manager
JP1/IM - View | JP1/Integrated Management - View
JP1/Integrated Manager - View
JP1/NETM/Audit | JP1/NETM/Audit - Manager
JP1/PFM | JP1/Performance Management
JP1/SC/DPM | JP1/ServerConductor/Deployment Manager Standard Edition
JSF | JavaServerTM Faces Reference Implementation (RI) Version: 1.1_01 FCS
Microsoft Cluster Service | Microsoft(R) Cluster Service
Microsoft IIS | Microsoft IIS 6.0 | Microsoft(R) Internet Information Services 6.0
Oracle | Oracle9i | Oracle9i
Oracle9i R2
Oracle10g | Oracle 10g
Oracle 10g R2
SQL Server | SQL Server 2000 | Microsoft(R) SQL Server(TM) 2000
SQL Server 2005 | Microsoft(R) SQL Server(TM) 2005
SQL Server のJDBCドライバ | SQL Server 2000 Driver for JDBC | Microsoft(R) SQL Server(TM) 2000 Driver for JDBC
SQL Server 2005 JDBC Driver | Microsoft(R) SQL Server(TM) 2005 JDBC Driver
UNIX | AIX | AIX 5L V5.2
AIX 5L V5.3
HP-UX | HP-UX（IPF） | HP-UX 11i V2（IPF）
HP-UX 11i V3（IPF）
Linux | Linux（IPF） | Red Hat Enterprise Linux AS 3（IPF）
Red Hat Enterprise Linux AS 4（IPF）
Red Hat Enterprise Linux 5 Advanced Platform（Intel Itanium）
Linux（x86／AMD64 & Intel EM64T） | Red Hat Enterprise Linux AS 3（x86）
Red Hat Enterprise Linux AS 4（x86）
Red Hat Enterprise Linux 5 Advanced Platform（x86）
Red Hat Enterprise Linux ES 3（x86）
Red Hat Enterprise Linux ES 4（x86）
Red Hat Enterprise Linux 5（x86）
Red Hat Enterprise Linux AS 3（AMD64 & Intel EM64T）
Red Hat Enterprise Linux AS 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux 5 Advanced Platform（AMD/Intel 64）
Red Hat Enterprise Linux ES 3（AMD64 & Intel EM64T）
Red Hat Enterprise Linux ES 4（AMD64 & Intel EM64T）
Red Hat Enterprise Linux 5（AMD/Intel 64）
Solaris | Solaris 9
Solaris 10
Web Redirector | uCosminexus Web Redirector
Windows Server 2003 | Microsoft(R) Windows Server(R) 2003，Enterprise Edition Operating System（x86）
Microsoft(R) Windows Server(R) 2003，Standard Edition Operating System（x86）
Windows Server 2003 R2 | Microsoft(R) Windows Server(R) 2003 R2，Enterprise Edition Operating System（x86）
Microsoft(R) Windows Server(R) 2003 R2，Standard Edition Operating System（x86）
Windows Server 2003（x64） | Microsoft(R) Windows Server(R) 2003，Enterprise x64 Edition Operating System
Microsoft(R) Windows Server(R) 2003，Standard x64 Edition Operating System
Windows Server 2003 R2（x64） | Microsoft(R) Windows Server(R) 2003 R2，Enterprise x64 Edition Operating System
Microsoft(R) Windows Server(R) 2003 R2，Standard x64 Edition Operating System
Windows Vista | Windows Vista Business | Microsoft(R) Windows Vista(R) Business
Windows Vista Enterprise | Microsoft(R) Windows Vista(R) Enterprise
Windows Vista Ultimate | Microsoft(R) Windows Vista(R) Ultimate
Windows XP | Microsoft(R) Windows(R) XP Professional Operating System
XDM/RD E2 | VOS3 XDM/RD E2

なお，Windows Server 2003，Windows Server 2003 R2，Windows Server 2003（x64），Windows Server 2003 R2（x64），Windows Vista，およびWindows XPを総称してWindowsと表記することがあります。

このマニュアルで使用している表記と，対応するCosminexusの機能名を次に示します。

表記 | Cosminexusの機能名
Cosminexus Developer's Kit for Java | Cosminexus Developer's Kit for JavaTM
Cosminexus RM | Cosminexus Reliable Messaging
CTM | Cosminexus Component Transaction Monitor
DB Connector for Cosminexus RM | DB Connector for Cosminexus Reliable Messaging
Management Server | Cosminexus Management Server
PRF | Cosminexus Performance Tracer
TPBroker | Cosminexus TPBroker
Server Plug-in | Cosminexus Server Plug-in
Smart Composer | Cosminexus Smart Composer

このマニュアルで使用している表記と，対応するJava関連用語を次に示します。

表記 | Java関連用語
Connector 1.0 | J2EETM Connector Architecture 1.0
Connector 1.5 | J2EETM Connector Architecture 1.5
DI | Dependency Injection
EAR | Enterprise ARchive
EJBまたはEnterprise JavaBeans | Enterprise JavaBeansTM
EJB QL | EJBTM Query Language
J2EEまたはJava 2 Platform, Enterprise Edition | JavaTM 2 Platform, Enterprise Edition
J2SE | JavaTM 2 Platform, Standard Edition
JAAS | JavaTM Authentication and Authorization Service
JAR | JavaTM Archive
Java | JavaTM
Java 2 Runtime Environment, Standard Edition | JavaTM 2 Runtime Environment, Standard Edition
Java 2 SDK, Standard Edition | JavaTM 2 Software Development Kit, Standard Edition
JavaBeans | JavaBeansTM
JavaMail | JavaMailTM
JAXP | JavaTM API for XML Processing
JCA | J2EETM Connector Architecture
JCE | JavaTM Cryptography Extension
JDBC | JDBCTM
JavaTM Database Connectivity
JDK | JavaTM Development Kit
JMS | JavaTM Message Service
JNDI | JavaTM Naming and Directory InterfaceTM
JNI | JavaTM Native Interface
JSF | JavaServerTM Faces Reference Implementation (RI) Version: 1.1_01 FCS
JSP | JavaServer PagesTM
JTA | JavaTM Transaction API
JTS | JavaTM Transaction Service
Servletまたはサーブレット | JavaTM Servlet
WAR | Web ARchive

適用OSの違いによる機能相違点の表記

このマニュアルは，適用OSがWindows，AIX，HP-UX，Linux，およびSolarisの製品に対応します。OSによって記述を書き分ける場合，次に示す表記を使用して，それぞれの説明にOS名を明記しています。

表記 | 意味
Windowsの場合 | Windowsに該当する表記です。
AIXの場合 | AIXに該当する表記です。
HP-UXの場合 | HP-UXに該当する表記です。
Linuxの場合 | Linuxに該当する表記です。
Solarisの場合 | Solarisに該当する表記です。
UNIXの場合 | UNIX（AIX，HP-UX，Linux，Solaris）に該当する表記です。

このマニュアルで使用している略語

このマニュアルで使用している英略語を次に示します。

英略語 | 英字での表記
API | Application Programming Interface
ASCII | American Standard Code for Information Interchange
BMP | Bean-Managed Persistence
BMT | Bean-Managed Transaction
CMP | Container-Managed Persistence
CMR | Container-Managed Relationship
CMT | Container-Managed Transaction
CORBA | Common Object Request Broker Architecture
CSV | Comma Separated Value
CUI | Character User Interface
DB | Database
DBMS | Database Management System
DD | Deployment Descriptor
DIT | Directory Information Tree
DMZ | Demilitarized Zone
DN | Distinguished Name
DNS | Domain Name System
DTD | Document Type Definition
EAR | Enterprise ARchive
EIS | Enterprise Information System
EL | Expression Language
EUC | Extended UNIX Code
GUI | Graphical User Interface
HA | High Availability
HTML | Hyper Text Markup Language
HTTP | Hyper Text Transfer Protocol
HTTPS | Hyper Text Transfer Protocol Security
IDE | Integrated Development Environment
IIOP | Internet Inter-Orb Protocol
JIS | Japanese Industrial Standards
LAN | Local Area Network
LDAP | Lightweight Directory Access Protocol
LDIF | LDAP Data Interchange Format
MIB | Management Information Base
OID | Object Identifier
OMG | Object Management Group
ORB | Object Request Broker
OS | Operating System
OTM | Object Transaction Monitor
OTS | Object Transaction Service
PIM | Platform Independent Model
POA | Portable Object Adapter
PSM | Platform Specific Model
RAC | Real Application Clusters
RDB | Relational Database
RMI | Remote Method Invocation
RPC | Remote Procedure Call
SFO | Session Fail Over
SHA | Secure Hash Algorithm
SOA | Service Oriented Architecture
SPI | Service Provider Interface
SPP | Service Providing Program
SSL | Secure Sockets Layer
TCS | Transaction Context Server
UDDI | Universal Description, Discovery and Integration
UML | Unified Modeling Language
URI | Uniform Resource Identifier
URL | Uniform Resource Locator
UTF | UCS Transformation Format
VM | Virtual Machine
WSDL | Web Service Description Language
XML | Extensible Markup Language

このマニュアルの図中で使用している記号

このマニュアルの図中で使用している記号を，次のように定義します。

このマニュアルで使用している記号

注意

間違いやすい点，および間違うとトラブルが発生するような項目について説明しています。

ポイント

その説明の要点について説明しています。

参考

補足的な情報を説明しています。

常用漢字以外の漢字の使用について

このマニュアルでは，常用漢字を使用することを基本としていますが，次に示す用語については，常用漢字以外の漢字を使用しています。

個所（かしょ）　脆弱（ぜいじゃく）　必須（ひっす）　閉塞（へいそく）　漏洩（ろうえい）

KB（キロバイト）などの単位表記について

1KB（キロバイト），1MB（メガバイト），1GB（ギガバイト），1TB（テラバイト）はそれぞれ1,024バイト，1,024²バイト，1,024³バイト，1,024⁴バイトです。

1.　Cosminexusのシステム設計の目的と流れ

この章では，Cosminexusのシステム設計の目的と，検討する必要がある項目について説明します。また，Cosminexusのシステム設計の流れについても説明します。

＜この章の構成＞

1.1　Cosminexusのシステム設計の目的

1.2　システム設計の流れ

1.1　Cosminexusのシステム設計の目的

Cosminexusは，JavaやCORBAなどの業界標準に準拠したアプリケーションの実行環境である，アプリケーションサーバを構築する製品です。アプリケーションサーバは，業務システムの構築基盤として位置づけられます。

業務システムには，次のような要件が求められます。

信頼性と可用性の高いシステムの実現
業務システムを止めることなく安定稼働させるために，信頼性と可用性を確保したシステムであることが必要です。

セキュリティの確保
システムを管理または運用するユーザがシステムを構築・運用していく過程や，システムが提供するサービスをエンドユーザが利用していく過程で，システムにはセキュリティ上のさまざまな脅威が想定されます。脅威からシステムを守るには，システムを物理的に安全な構成に設計したり，作業者の運用ルールを定めたりするなどの対策を実施する必要があります。

優れた処理性能の実現
Webクライアントなどの多数のクライアントからの処理要求や，EJBクライアントなどの業務のバックシステムでのミッションクリティカルな処理要求などに，迅速かつ確実に対応するレスポンスが求められます。

これらの要件を満たすシステムを構築するためには，システム構築を始める前にシステムの目的や特徴を分析して，最適なシステム構成を検討する必要があります。また，システムの運用を開始する前に，セキュリティを確保するための手順を整備したり，実際に想定される運用時の状態で動作確認およびチューニングを実施したりする必要があります。

Cosminexusのシステム設計は，これらの作業を通して，アプリケーションサーバ上で動作する業務システムを，最適な状態で運用できるようにすることを目的とします。このマニュアルでは，Cosminexusのシステムを設計する場合に検討，考慮する必要がある項目として，次の項目について説明します。

システム構成の検討方法

セキュアなシステムの検討方法

パフォーマンスチューニングの実施方法

1.2　システム設計の流れ

Cosminexusのシステム設計の流れについて説明します。

システム設計で考慮することは，そのシステムで実行するアプリケーションが，オンライン処理を実行するアプリケーション（J2EEアプリケーション）か，バッチ処理を実行するアプリケーション（バッチアプリケーション）かによって異なります。

それぞれのシステム設計の流れを示します。

＜この節の構成＞

1.2.1　オンライン処理を実行するアプリケーション（J2EEアプリケーション）の場合

1.2.2　バッチ処理を実行するアプリケーション（バッチアプリケーション）の場合

1.2.1　オンライン処理を実行するアプリケーション（J2EEアプリケーション）の場合

システム設計は，次の図に示す流れで実行します。それぞれの項目の詳細については，「参照先」に示した個所の説明を参照してください。

図1-1　システムの設計の流れ（J2EEアプリケーションを実行する場合）

1.2.2　バッチ処理を実行するアプリケーション（バッチアプリケーション）の場合

システム設計は，次の図に示す流れで実行します。それぞれの項目の詳細については，「参照先」に示した個所の説明を参照してください。

図1-2　システムの設計の流れ（バッチアプリケーションを実行する場合）

2.　システム設計の準備

この章では，システム設計の準備として，システム設計を始める前に決めておくことについて説明します。

＜この章の構成＞

2.1　システム設計を始める前に決めておくこと

2.2　業務の種類を明確にする

2.3　システムの目的に応じたアプリケーションの構成を決める（オンライン処理を実行する業務の場合）

2.4　システムの目的に応じたアプリケーションの構成を決める（バッチ処理を実行する業務の場合）

2.5　運用方法を検討する

2.1　システム設計を始める前に決めておくこと

この節では，Cosminexusのシステム設計を始める前に決めておくことについて説明します。

システム設計作業を始める前に，まず，次のことを明確にしてください。これらの検討結果を踏まえて，3章以降で説明するシステム構成の検討やパフォーマンスチューニングを実施します。

業務の種類を明確にする
システムで実現する業務の種類を明確にします。業務の種類によって，使用するアプリケーションの種類，構成，および必要なソフトウェアが決まります。

システムの目的に応じたアプリケーションの構成を決める
システムの目的に従って，使用する機能を検討した上で，動作させるアプリケーションの構成を明確にします。また，必要なソフトウェアを準備します。

運用方法を検討する
Cosminexusのシステムでは，Management Serverという運用管理プロセスを使用して，複数のサーバプロセスを一括して運用します。
運用方法の検討では，Cosminexusのシステムのほかに，Cosminexus以外のプログラムを含めたシステム全体を，どのように運用するかを検討します。

2.2　業務の種類を明確にする

システムでどのような業務を実現するのか，業務の種類を明確にします。

Cosminexusのシステムでは，次の2種類の業務を実行できます。

オンライン業務
ネットワーク経由などで送信されるクライアントからのリクエストを処理する形式の業務です。

バッチ業務
定型的または定期的な作業をまとめて処理する形式の業務です。

業務の種類によって，実行するアプリケーションの形式や，アプリケーションを実行するサーバプロセスなどが異なります。業務の種類，アプリケーションの形式，およびアプリケーションを実行するサーバプロセスの対応を次の表に示します。

表2-1　業務の種類，アプリケーションの形式，およびアプリケーションを実行するサーバプロセスの対応

業務の種類 | アプリケーションの形式 | アプリケーションを実行するサーバプロセス
オンライン業務 | J2EEアプリケーション | J2EEサーバ
バッチ業務 | バッチアプリケーション | バッチサーバ

ポイント

以降で実施するシステム設計の内容は，業務の種類によって異なります。業務の種類に応じて，必要なシステム設計を実施してください。業務の種類ごとに実行するシステム設計の内容と，このマニュアルでの参照先を次の表に示します。

表2-2　業務の種類ごとに実行するシステム設計の内容とこのマニュアルでの参照先

システム設計の内容 | 業務の種類
オンライン業務 | バッチ業務
システム設計の準備 | アプリケーションの構成の決定 | 2.3 | 2.4
運用方法の検討 | 2.5
システム構成の検討 | 3章 | 4章
セキュアなシステムの検討 | 5章 | －
パフォーマンスチューニング | 6章 | 7章
JavaVMのチューニング | 8章

（凡例）　－：該当しません。

2.3　システムの目的に応じたアプリケーションの構成を決める（オンライン処理を実行する業務の場合）

この節では，システムの目的に応じたアプリケーションの構成の検討について説明します。この節で説明するのは，J2EEアプリケーションの場合の構成です。また，必要となるソフトウェアについても説明します。

Application Serverで実現できるアプリケーションの機能の詳細については，マニュアル「Cosminexus　機能解説」を参照してください。

＜この節の構成＞

2.3.1　動作させるJ2EEアプリケーションの検討

2.3.2　使用するプロセスの検討と必要なソフトウェアの準備

2.3.1　動作させるJ2EEアプリケーションの検討

システムで動作させるJ2EEアプリケーションについて検討します。

システムの目的に応じたアプリケーションの構成を明確にすることで，システム構成の基本的な部分が決まります。例えば，クライアントにWebブラウザを使用する場合には，アプリケーションはサーブレットやJSPで構成されるWebアプリケーションにして，Webブラウザからのリクエストを受け付けるようにします。また，必要に応じて，サーブレットやJSPからEnterprise Beanを呼び出すようなアプリケーションも考えられます。この場合は，システムはWebクライアントシステムにして，Webサーバの配置や，そこからアプリケーションサーバを呼び出す場合の連携方法を検討する必要があります。

また，業務システムの基幹部分を構成するシステムを構築する場合は，クライアントにEJBクライアントアプリケーションを使用する構成が考えられます。呼び出し先のEnterprise Beanの種類によっては，CTMを利用することも検討できます。

アプリケーションに含まれるコンポーネントの種類とシステム構成との関係については，「3.3　アプリケーションの構成を検討する」で詳しく説明します。そのほか，J2EEアプリケーションを実行する場合のシステム構成の検討方法については，「3.　システム構成の検討（J2EEアプリケーション実行基盤）」を参照してください。

システムの目的に応じて使用できる機能の詳細については，マニュアル「Cosminexus　機能解説」を参照してください。また，アプリケーション開発の手順については，マニュアル「Cosminexus　アプリケーション開発ガイド」を参照してください。

参考

サーバの動作モードについて

サーバの動作モードは，J2EEサーバモード（1.4モード）で動作させることをお勧めします。アプリケーションの種類によっては，サーブレットエンジンモードやベーシックモードで動作させることもできますが，これらは互換用のモードです。

2.3.2　使用するプロセスの検討と必要なソフトウェアの準備

Cosminexusのシステムでは，使用するプロセスの種類とその配置によってシステム構成が決まります。

CosminexusのシステムはWebフロントシステムとバックシステムで構成されます。Webフロントシステムは，クライアントとしてWebブラウザを使用するシステムです。バックシステムは，クライアントとしてEJBクライアントを使用するシステムです。システムの分類については，「3.1.1　システムの目的と構成」で詳しく説明します。

ここでは，まず，システムの分類に応じて必要なプロセスとソフトウェアについて説明します。次に，使用する機能に応じて必要なプロセス，モジュールおよびソフトウェアについて説明します。なお，これらのプロセス，モジュール，ソフトウェアをどのようにシステムに配置するかについては，「3.　システム構成の検討（J2EEアプリケーション実行基盤）」で説明します。

＜この項の構成＞

(1)　システムの分類に応じて必要なプロセス

(2)　使用する機能に応じて必要なプロセスおよびモジュール

(1)　システムの分類に応じて必要なプロセス

システムの分類に応じて必要なプロセスを次に示します。これらは，使用する機能に関係なく共通して必要なプロセスです。Application Serverによって提供されます。

Webフロントシステムの場合に必要なプロセス

Webフロントシステムの場合に必要なプロセスは次のとおりです。

Webサーバ※

J2EEサーバ

PRFデーモン

なお，Application Serverに含まれるWebサーバは，Hitachi Web Serverです。クライアントには，Webブラウザを使用します。

注※

インプロセスHTTPサーバを利用する場合は，Webサーバのプロセスは不要です。

ポイント

Webサーバ選択の指針

Webクライアントシステムでは，Webクライアントからのリクエストを，次のどちらかのWebサーバを利用して処理できます。

リダイレクタと連携したWebサーバ（Webサーバ連携）
Application ServerまたはWeb Redirectorが提供するリダイレクタモジュールを組み込んだWebサーバと連携してリクエストを処理します。Webサーバが受信したリクエストは，リダイレクタモジュールを経由して，J2EEサーバに送信されます。
Hitachi Web ServerまたはMicrosoft IISが利用できます。

インプロセスHTTPサーバ
Webコンテナ機能の一部として提供される，J2EEサーバのプロセス内で機能するHTTPサーバでリクエストを処理します。WebクライアントからのリクエストをJ2EEサーバで直接受信できます。

なお，Cosminexusでは，リダイレクタと連携したWebサーバを利用することを推奨しています。また，デフォルトの設定で使用する場合は，リダイレクタと連携したWebサーバが利用されます。特に性能を重視したシステムを構築したい場合に，インプロセスHTTPサーバの利用を検討してください。

それぞれのWebサーバの特徴を次の表に示します。Webサーバを選択する場合の指針にしてください。

表2-3　Webサーバ選択の指針

比較項目
リダイレクタと連携したWebサーバ
インプロセスHTTPサーバ

Webサーバとして利用できる機能
○
Hitachi Web Server（Apacheの機能をベースにしたWebサーバ）またはMicrosoft IISが提供する多様な機能を利用できます。
△
サーブレット，JSPまたはHTMLから構成されるWebアプリケーションへのアクセスを目的にした最小限の機能だけが提供されています。※1

構築，運用の容易性
○
構築時には，Webサーバの環境設定が必要です。運用時には，Webサーバの起動，停止が必要です。ただし，Smart Composer機能のコマンドで構築・運用できるため，煩雑な操作は不要です。
○
構築時のWebサーバの環境設定，および運用時のWebサーバの起動，停止の操作が不要です。

HTML，JPEGなどの静的コンテンツに対するアクセス性能
○
静的コンテンツをWebサーバ上に配置することによって，最適な性能を確保できます。
なお，Webコンテナ上に配置する場合は，リダイレクタ経由のアクセスになるため，アクセス処理に時間が掛かります。
○
リダイレクタを経由しないでアクセスできるため，最適な性能を確保できます。

サーブレット，JSPなどの動的コンテンツに対するアクセス性能
△
リダイレクタを経由するためのアクセス処理に時間が掛かります。
○
リダイレクタを経由しないでアクセスできるため，最適な性能を確保できます。

注意事項
インターネットに接続する場合には，セキュリティ上の観点から，DMZを確保する構成にして，リバースプロキシをフロントに配置することを推奨します。
また，リバースプロキシを配置しない場合は，リダイレクタを組み込んだWebサーバをDMZに配置することで，同様の効果を得ることもできます。※2
インターネットに接続する場合には，セキュリティ上の観点からDMZを確保する構成にして，必ずリバースプロキシをフロントに配置してください。※2

（凡例）○：優れている。　△：優れていない。

注※1　インプロセスHTTPサーバで利用できる機能の詳細については，マニュアル「Cosminexus　機能解説」を参照してください。

注※2　DMZへのWebサーバの配置については，「3.13　DMZへのリバースプロキシの配置を検討する」を参照してください。

バックシステムの場合に必要なプロセス

バックシステムの場合に必要なプロセスは次のとおりです。

J2EEサーバ

PRFデーモン

バックシステムのクライアントには，EJBクライアントを使用します。EJBクライアントとは，Enterprise Beanを呼び出す，Servlet，JSP，ほかのEnterprise Bean，EJBクライアントアプリケーション，またはほかの業務システムのことです。

EJBクライアントとしてEJBクライアントアプリケーションを使用するとき，Windowsの場合はクライアントマシンをuCosminexus Clientを使用して構築することもできます。Application ServerまたはuCosminexus Clientのどちらのソフトウェアを使用した場合も，必要に応じてPRFデーモンを起動できます。

参考

CTMを使用したシステムの場合，クライアントとしてTPBrokerやTPBroker Object Transaction Monitorのクライアントなど，EJBクライアント以外のクライアントも使用できます。

(2)　使用する機能に応じて必要なプロセスおよびモジュール

使用する機能に応じて必要なプロセスおよびモジュールについて説明します。Application Serverによって提供されるものと，Application Server以外のソフトウェアによって提供されるものがあります。

使用する機能ごとに必要なプロセスのうち，Application Serverによって提供されるものを次の表に示します。これらのプロセスは，Application Serverをインストールしたマシンで起動できます。

表2-4　機能ごとに必要なプロセスまたはモジュール（Application Serverによって提供されるもの）

機能 | 必要なプロセス
サーバ間連携でCTMを利用する／CTMを利用して負荷を分散する | CTMデーモン
CTMレギュレータ
CTMドメインマネジャ
グローバルCORBAネーミングサービス
スマートエージェント
Management Serverを利用して運用管理する | Management Server
運用管理エージェント
セッションフェイルオーバ機能を使用して可用性を向上させる | SFOサーバ
CORBAネーミングサービスをアウトプロセスで起動する | CORBAネーミングサービス

使用する機能ごとに必要なプロセスおよびモジュールのうち，Application Server以外の製品が提供するプロセスおよびモジュールを，表2-5および表2-6に示します。

表2-5　機能ごとに必要なモジュール（Application Server以外によって提供されるもの）と提供するソフトウェア

機能
モジュール
提供するソフトウェア
備考

データベース（HiRDB）と接続する
HiRDB Run Time

HiRDB Run Time

JDBCドライバとしてCosminexus DABroker Libraryを使用する場合に必要になります。

HiRDB Type4 JDBC Driver

HiRDB/Parallel Server Version 8

HiRDB/Single Server Version 8

HiRDB/Run Time Version 8

HiRDB/Developer's Kit Version 8

JDBCドライバとしてHiRDB Type4 JDBC Driverを使用する場合に必要になります。

データベース（Oracle）と接続する
Oracle Client

Oracle Client

JDBCドライバとしてCosminexus DABroker Libraryを使用する場合に必要になります。

Oracle JDBC Thin Driver

Oracle JDBC Thin Driver

JDBCドライバとしてOracle JDBC Thin Driverを使用する場合に必要になります。

データベース（SQL Server）と接続する
SQL Server 2000 Driver for JDBC

SQL Server 2000 Driver for JDBC

SQL Server 2000に接続する場合に必要になります。

SQL Server 2005 JDBC Driver

SQL Server 2005 JDBC Driver

SQL Server 2005に接続する場合に必要になります。

データベース（XDM/RD E2）と接続する
HiRDB Run Time

HiRDB Run Time

JDBCドライバとしてCosminexus DABroker Libraryを使用する場合に必要になります。

HiRDB Type4 JDBC Driver

HiRDB/Parallel Server Version 8

HiRDB/Single Server Version 8

HiRDB/Run Time Version 8

HiRDB/Developer's Kit Version 8

JDBCドライバとしてHiRDB Type4 JDBC Driverを使用する場合に必要になります。

Message Queueサーバと接続する
TP1/Message Queue - Access

TP1/Message Queue - Access

－

OpenTP1のSPPと接続する
uCosminexus TP1 Connector

uCosminexus TP1 Connector

－

TP1/Client/J

TP1/Client/J

－

（凡例） －：該当しません。

注　モジュールは，J2EEサーバのプロセスに含まれて動作します。

表2-6　機能ごとに必要なプロセス（Application Server以外によって提供されるもの）と提供するソフトウェア

機能 | 必要なプロセス | 提供するソフトウェア
クラスタソフトウェアを使用して障害時に系を切り替える | Microsoft Cluster Service | Microsoft Cluster Service
HAモニタ | HAモニタ

2.4　システムの目的に応じたアプリケーションの構成を決める（バッチ処理を実行する業務の場合）

この節では，システムの目的に応じたアプリケーションの構成の検討について説明します。この節で説明するのは，バッチアプリケーションの場合の構成です。また，必要となるソフトウェアについても説明します。

Application Serverで実現できるアプリケーションの機能の詳細については，マニュアル「Cosminexus　機能解説」を参照してください。

ポイント

バッチ処理を実行するシステムには，Application Server Enterpriseが必要です。

＜この節の構成＞

2.4.1　動作させるバッチアプリケーションの検討

2.4.2　使用するプロセスの検討と必要なソフトウェアの準備

2.4.1　動作させるバッチアプリケーションの検討

システムで動作させるバッチアプリケーションについて検討します。バッチアプリケーションとは，バッチ処理として実行する，定型的・定期的な処理を実装したJavaアプリケーションのことです。

システム構成の基本的な部分は，バッチアプリケーションで実装した処理内容によって決まります。例えば，データベース上のデータを参照・更新するような処理を実装した場合は，トランザクションの管理方法や，リソースとの接続方法を検討する必要があります。また，ほかのJ2EEサーバ上の業務処理プログラム（Enterprise Bean）を呼び出す処理を実装した場合は，サーバ間の連携方法について，検討する必要があります。

バッチアプリケーションを実行する場合のシステム構成の検討方法については，「4.　システム構成の検討（バッチアプリケーション実行基盤）」を参照してください。

システムの目的に応じて使用できる機能の詳細については，マニュアル「Cosminexus　機能解説」を参照してください。

2.4.2　使用するプロセスの検討と必要なソフトウェアの準備

Cosminexusのシステムでは，使用するプロセスの種類とその配置によってシステム構成が決まります。

ここでは，まず，必要なプロセスとソフトウェアについて説明します。次に，使用する機能に応じて必要なプロセス，モジュールおよびソフトウェアについて説明します。なお，これらのプロセス，モジュール，ソフトウェアをどのようにシステムに配置するかについては，「4.　システム構成の検討（バッチアプリケーション実行基盤）」で説明します。

＜この項の構成＞

(1)　必要なプロセス

(2)　使用する機能に応じて必要なプロセスおよびモジュール

(1)　必要なプロセス

必要なプロセスを次に示します。これらは，使用する機能に関係なく共通して必要なプロセスです。Application Server Enterpriseによって提供されます。

バッチサーバ

PRFデーモン

(2)　使用する機能に応じて必要なプロセスおよびモジュール

使用する機能に応じて必要なプロセスおよびモジュールについて説明します。Application Server Enterpriseによって提供されるものと，Application Server Enterprise以外のソフトウェアによって提供されるものがあります。

使用する機能ごとに必要なプロセスのうち，Application Server Enterpriseによって提供されるものを次の表に示します。これらのプロセスは，Application Server Enterpriseをインストールしたマシンで起動できます。

表2-7　機能ごとに必要なプロセスまたはモジュール（Application Server Enterpriseによって提供されるもの）

機能 | 必要なプロセス
Management Serverを利用して運用管理する | Management Server
運用管理エージェント

使用する機能ごとに必要なプロセスおよびモジュールのうち，Application Server Enterprise以外の製品が提供するプロセスおよびモジュールを，表2-8および表2-9に示します。

表2-8　機能ごとに必要なモジュール（Application Server Enterprise以外によって提供されるもの）と提供するソフトウェア

機能
モジュール
提供するソフトウェア
備考

データベース（HiRDB）と接続する
HiRDB Run Time

HiRDB Run Time

JDBCドライバとしてCosminexus DABroker Libraryを使用する場合に必要になります。

HiRDB Type4 JDBC Driver

HiRDB/Parallel Server Version 8

HiRDB/Single Server Version 8

HiRDB/Run Time Version 8

HiRDB/Developer's Kit Version 8

JDBCドライバとしてHiRDB Type4 JDBC Driverを使用する場合に必要になります。

データベース（Oracle）と接続する
Oracle Client

Oracle Client

JDBCドライバとしてCosminexus DABroker Libraryを使用する場合に必要になります。

Oracle JDBC Thin Driver

Oracle JDBC Thin Driver

JDBCドライバとしてOracle JDBC Thin Driverを使用する場合に必要になります。

データベース（SQL Server）と接続する
SQL Server 2000 Driver for JDBC

SQL Server 2000 Driver for JDBC

SQL Server 2000に接続する場合に必要になります。

SQL Server 2005 JDBC Driver

SQL Server 2005 JDBC Driver

SQL Server 2005に接続する場合に必要になります。

データベース（XDM/RD E2）と接続する
HiRDB Run Time

HiRDB Run Time

JDBCドライバとしてCosminexus DABroker Libraryを使用する場合に必要になります。

HiRDB Type4 JDBC Driver

HiRDB/Parallel Server Version 8

HiRDB/Single Server Version 8

HiRDB/Run Time Version 8

HiRDB/Developer's Kit Version 8

JDBCドライバとしてHiRDB Type4 JDBC Driverを使用する場合に必要になります。

注　モジュールは，バッチサーバのプロセスに含まれて動作します。

表2-9　機能ごとに必要なプロセス（Application Server Enterprise以外によって提供されるもの）と提供するソフトウェア

機能 | 必要なプロセス | 提供するソフトウェア
クラスタソフトウェアを使用して障害時に系を切り替える | Microsoft Cluster Service | Microsoft Cluster Service
HAモニタ | HAモニタ

2.5　運用方法を検討する

この節では，Cosminexusのシステムの運用方法を検討するときに考慮することについて説明します。

Cosminexusのシステムの運用では，Management Serverというプロセスを利用できます。Management Serverを利用すると，Cosminexusのシステムを構成する複数のプロセスを論理サーバとして扱い，一括して運用できるようになります。

なお，業務システムは一般的に，Cosminexusだけではなくほかのプログラムで構築されるシステムと組み合わせて構築されています。運用方法の検討では，Cosminexusのシステムのほかに，これらのプログラムも合わせてシステム全体をどのように運用するかを検討する必要があります。

＜この節の構成＞

2.5.1　JP1と連携したシステムの運用

2.5.2　クラスタソフトウェアと連携したシステムの運用

2.5.1　JP1と連携したシステムの運用

Management Serverを利用して運用している場合，日立の統合システム運用管理用ミドルウェアJP1のプログラムと連携して，次のようなシステムの運用を実現できます。

JP1/IMと連携したシステム全体の集中監視

JP1/IM - CMと連携したシステムの構成定義および構成管理（Smart Composer機能を使用する場合）

JP1/AJS2と連携したシステム全体の自動運転

JP1/AJS2 - SOと連携したシナリオを使用したシステム全体の自動運転（Smart Composer機能を使用する場合）

それぞれのプログラムとの連携によって実現できる機能の詳細については，マニュアル「Cosminexus　機能解説」を参照してください。

なお，Management Serverを利用しないで運用している場合でも，JP1/AJS2を利用したシステムの自動運転は実現できます。ただし，その場合，JP1/AJS2のジョブとして，サーバ管理コマンドなどを一から定義する必要があります。

2.5.2　クラスタソフトウェアと連携したシステムの運用

クラスタソフトウェアと連携すると，障害発生時などに自動的に系切り替えができます。

また，J2EEサーバをクラスタ構成にしている場合，N個のJ2EEサーバに対して1個のリカバリ専用サーバを配置することで，障害発生時にトランザクションを解決してリソースを解放できます。ただし，この機能は，バッチサーバには該当しません。

Cosminexusのシステムでは，OSごとに，次のクラスタソフトウェアを使用できます。

Windowsの場合
Microsoft Cluster Service

AIX，HP-UXまたはLinuxの場合
HAモニタ

Solarisの場合，クラスタソフトウェアと連携したシステム運用はできません。

クラスタソフトウェアと連携するためには，システムをManagement Serverを利用して運用している必要があります。

クラスタソフトウェアと連携したシステムの運用をする場合のシステム構成については，「3.11　クラスタソフトウェアを使用した障害時の系切り替えを検討する」を参照してください。

3.　システム構成の検討（J2EEアプリケーション実行基盤）

この章では，J2EEアプリケーション実行基盤を構築する場合のシステム構成について説明します。システムを設計する流れに沿って，それぞれの設計項目でのシステム構成の標準的なパターンを示します。また，それぞれのポイントで意識する必要があるコンポーネント，プロセスおよび処理の流れについて説明します。

バッチアプリケーション実行基盤のシステム構成を検討する場合は，「4.　システム構成の検討（バッチアプリケーション実行基盤）」を参照してください。

＜この章の構成＞

3.1　システム構成を検討するときに考慮すること

3.2　システム構成の説明について

3.3　アプリケーションの構成を検討する

3.4　クライアントとサーバの構成を検討する

3.5　サーバ間での連携を検討する

3.6　トランザクションの種類を検討する

3.7　ロードバランスクラスタによる負荷分散方式を検討する

3.8　サーバ間で非同期通信をする場合の構成を検討する

3.9　運用管理プロセスの配置を検討する

3.10　SFOサーバを使用したセッション情報の引き継ぎを検討する

3.11　クラスタソフトウェアを使用した障害時の系切り替えを検討する

3.12　ファイアウォールを使用する構成を検討する

3.13　DMZへのリバースプロキシの配置を検討する

3.14　性能解析トレースファイルを出力するプロセスを配置する

3.15　Cosminexus以外の製品との連携を検討する

3.16　任意のプロセスを運用管理の対象にする

3.17　そのほかの構成を検討する

3.18　Cosminexusのプロセスが使用するTCP/UDPのポート番号

3.1　システム構成を検討するときに考慮すること

この節では，Cosminexusを使用するシステムの構成を検討するときに考慮する必要があることについて説明します。

システム構成を検討する場合，J2EEアプリケーションで使用する機能に応じて，その機能を実現するために必要なプロセスを意識し，それぞれを各マシンに適切に配置することが必要です。このとき，アプリケーションサーバの要件である，信頼性，可用性なども十分に考慮する必要があります。

＜この節の構成＞

3.1.1　システムの目的と構成

3.1.2　システム構成の設計手順

3.1.3　システム構成の考え方

3.1.1　システムの目的と構成

Cosminexusで構築するシステムは，目的とする業務および実行するJ2EEアプリケーションの要件と特徴に応じて，次の2種類のシステムに分類できます。

Webフロントシステム

バックシステム

Webフロントシステムは，Webベースのシステムの場合に，フロントエンドであるWebブラウザから送信されるリクエストを受け付けて，そのリクエストを処理するシステムです。このシステムでは，アプリケーションサーバ上のJ2EEサーバで，サーブレット，JSPおよびEnterprise Beanが動作します。

Webフロントシステムの背後で動作する，複数の業務システムに共通な業務サービスを実行するためのシステムが，バックシステムです。バックシステムにリクエストを送信するのは，次のようなコンポーネント，アプリケーションまたはシステムです。

Webフロントシステム上で動作しているサーブレット，JSPまたはEnterprise Bean

EJBクライアントマシンで動作しているEJBクライアントアプリケーション

ほかの業務システム

Cosminexusのシステムは，目的や規模に応じて，Webフロントシステムとバックシステムを一つまたは複数組み合わせて構成されます。

Webフロントシステムとバックシステムの構成例を次の図に示します。

図3-1　Webフロントシステムとバックシステムの構成例

Cosminexusのシステム構成を検討する場合，まず，システムの基本構成として，システム全体をどのようなシステムの組み合わせで構成するかを検討します。次に，構成要素であるそれぞれのシステムの目的と，クライアントからアクセスされるポイントを明確にします。それから，信頼性，性能，拡張性などアプリケーションサーバに共通して求められる要件や，EISとの接続や負荷分散の実現などそのシステム独自の要件を満たすためにはどのようにソフトウェアやプロセスを配置するのがよいのかを検討し，最適なシステム構成を設計していきます。

3.1.2　システム構成の設計手順

システム構成は，次の流れで設計します。

図3-2　システム構成を設計する流れ（J2EEアプリケーション実行基盤の場合）

＜この項の構成＞

(1)　アプリケーションの構成を検討する

(2)　クライアントとサーバの構成を検討する

(3)　サーバ間での連携方法を検討する

(4)　トランザクションの種類を検討する

(5)　ロードバランスクラスタによる負荷分散方式を検討する

(6)　サーバ間の非同期通信をするための構成を検討する

(7)　運用管理プロセスの配置を検討する

(8)　SFOサーバを使用したセッション情報の引き継ぎを検討する

(9)　クラスタソフトウェアを使用した障害時の系切り替えまたはリソース解放を実現するための構成を検討する

(10)　ファイアウォールの配置を検討する

(11)　DMZへのリバースプロキシの配置を検討する

(12)　性能解析トレースファイルを出力するプロセスを配置する

(13)　Cosminexus以外の製品との連携を検討する

(14)　任意のプロセスを運用管理の対象にする

(15)　そのほかの構成を検討する

(1)　アプリケーションの構成を検討する

各システム上で動作するアプリケーションで使用するコンポーネントの構成を明確にして，アプリケーションのどのコンポーネントをアクセスポイントにするかを決定します。

アクセスポイントとは，クライアントからリモートでアクセスされる場合に，アプリケーションのリクエスト受信窓口として動作するコンポーネントです。アクセスポイントになるコンポーネントの種類によって，実現できるシステム構成が決まります。

また，アプリケーションがデータベースなどのリソースに接続するかどうかを決めます。接続するリソースに対応して，使用するリソースアダプタが決まります。

なお，ここで検討したアクセスポイントになるコンポーネントの種類によって，それ以降のシステム構成の設計で検討が必要な項目が異なります。アクセスポイントになるコンポーネントの種類ごとに検討が必要な項目を，次の表に示します。

表3-1　アクセスポイントになるコンポーネントの種類ごとに検討が必要な項目

設計項目
アクセスポイントになるコンポーネントの種類
参照先

Webフロントシステム
バックシステム

サーブレット
／JSP
Session Bean
／Entity Bean
CTMを使用する場合のStateless Session Bean
Message-
driven Bean

クライアントとサーバの構成
◎
◎
◎
－
3.4

サーバ間での連携方法
－
△
△
－
3.5

トランザクションの種類
◎
◎
◎
◎
3.6

ロードバランスクラスタによる負荷分散方式
△
△
△
－
3.7

サーバ間での非同期通信
－
－
－
◎
3.8

運用管理プロセスの配置
◎
◎
◎
◎
3.9

SFOサーバを使用してセッション情報を引き継ぐための構成
△
△
－
－
3.10

クラスタソフトウェアを使用した系切り替えを実現するための構成
△
△
△
△
3.11

ファイアウォールの配置
△
△
△
△
3.12

DMZへのリバースプロキシの配置
　△※
－
－
－
3.13

性能解析トレースファイルを出力するプロセスの配置
◎
◎
◎
◎
3.14

Cosminexus以外の製品との連携
△
△
△
△
3.15

任意のプロセスの運用管理
△
△
△
△
3.16

（凡例）

◎：必ず検討する項目。

△：必要に応じて検討する項目。

－：検討する必要がない項目。

注※　インターネットに接続するシステムでWebサーバとしてインプロセスHTTPサーバを使用する場合は必ず検討してください。

(2)　クライアントとサーバの構成を検討する

アクセスポイントになるコンポーネントに応じて，クライアントとサーバの対応を明確にします。システムに配置したアプリケーションサーバは，その役割に応じて，クライアントとして機能したり，サーバとして機能したりします。

クライアントとサーバの構成の考え方を次の図に示します。

図3-3　クライアントとサーバの構成の考え方

この構成の場合，APサーバ1はWebクライアントに対するサーバに当たり，アクセスポイントはサーブレット／JSPになります。また，APサーバ1はAPサーバ2に対してのクライアントになります。APサーバ2はAPサーバ1に対するサーバに当たり，アクセスポイントはEnterprise Beanになります。

(3)　サーバ間での連携方法を検討する

サーバが複数ある場合に，サーバ間で連携するかどうか，連携する場合はどのように連携するかを検討します。サーバ間連携とは，クライアントから見て垂直に並んだ複数のサーバから，ほかのサーバ上にあるアクセスポイントのコンポーネントを呼び出して処理を実行する連携方法です。

サーバ間連携の考え方を次の図に示します。

図3-4　サーバ間連携の考え方

この構成の場合，APサーバ1とAPサーバ2は，APサーバ3のクライアントになり，それぞれのサーブレット，JSPまたはMessage-driven Beanから，APサーバ3のSession Beanを呼び出します。

サーバ間連携と同時に，必要に応じて，アプリケーションを分割するなど，アプリケーションの形態も見直します。また，複数のシステム間で連携する場合も，それぞれのシステムに含まれるサーバ間の連携方法を検討する必要があります。

(4)　トランザクションの種類を検討する

データベースなどのリソースを使用するシステムの場合に，トランザクション管理の対象になるリソースの数に応じて，使用するトランザクションの種類を検討します。

(5)　ロードバランスクラスタによる負荷分散方式を検討する

システムの可用性を高めるために，ロードバランスクラスタ構成によって負荷を分散するかどうか検討します。負荷を分散する場合は，アクセスポイントになるコンポーネントの種類に応じてどの方式で実現するかを検討します。

(6)　サーバ間の非同期通信をするための構成を検討する

Message-driven Beanを使用してアプリケーションサーバ間での非同期通信をする場合に，利用する製品に応じたシステムの構成を検討します。なお，Message-driven Beanによる負荷分散についても，あわせて検討します。

(7)　運用管理プロセスの配置を検討する

運用管理プロセス（Management Server）を利用する場合に，管理対象にする範囲によって，Management Serverをどのサーバマシンに配置するかを検討します。

(8)　SFOサーバを使用したセッション情報の引き継ぎを検討する

Webフロントシステムで動作するJ2EEアプリケーションまたはJ2EEサーバに障害が発生した場合に，セッション情報をほかのJ2EEサーバに引き継ぐための構成について検討します。

(9)　クラスタソフトウェアを使用した障害時の系切り替えまたはリソース解放を実現するための構成を検討する

一つのアプリケーションサーバに障害が発生した場合およびシステムを保守する場合を考慮して，クラスタソフトウェアによって系切り替えを実行して，システムの運用を続行させるための構成を検討します。このとき，実行系と待機系がそれぞれ相互に切り替え対象になる構成（相互スタンバイ構成）も検討できます。また，トランザクションサービスを使用している場合は，障害発生時にリソースを解放するためのリカバリサーバを利用するための構成も検討します。

なお，この構成は，Solarisの場合には使用できません。

(10)　ファイアウォールの配置を検討する

アプリケーションサーバおよびリソースのセキュリティを確保するための，ファイアウォールの配置について検討します。ファイアウォールは，アクセスポイントになるコンポーネントの前に配置して，アクセスポイントに対する不正なアクセスを防止します。ファイアウォールを配置するポイントは，アクセスポイントによって決まります。なお，「3.12　ファイアウォールを使用する構成を検討する」では，基本的なファイアウォールの配置についてだけを示します。侵入検知システムも含めたセキュリティ構成の詳細については，「5.10.2　ファイアウォールと侵入検知システムを配置する」を参照してください。

(11)　DMZへのリバースプロキシの配置を検討する

インターネットと接続するシステムの場合などには，アプリケーションサーバおよびリソースのセキュリティを確保するために，DMZへのリバースプロキシの配置を検討します。

(12)　性能解析トレースファイルを出力するプロセスを配置する

性能解析に使用するプロセスであるPRFデーモン（パフォーマンストレーサ）の配置について検討します。

(13)　Cosminexus以外の製品との連携を検討する

システムの集中監視，構成管理，自動運転などをしたい場合には，必要に応じてJP1などのCosminexus以外の製品との連携を検討します。

(14)　任意のプロセスを運用管理の対象にする

ユーザが定義する任意のプロセスをユーザサーバとしてManagement Serverによる運用管理の対象にしたい場合には，ユーザサーバの配置について検討します。

(15)　そのほかの構成を検討する

(14)までで検討した以外の構成について検討します。また，必要に応じて，07-00より前のApplication Serverで構築しているシステムとの互換性を持つシステム構成も検討します。

3.1.3　システム構成の考え方

ここでは，システム構成を検討するときの基本的な考え方について説明します。Application Serverで構築する実行環境は，複数のプロセスで構成されます。また，各プロセスには，提供する機能ごとに，複数のレイヤがあります。このレイヤを，機能レイヤといいます。

実行環境では，各機能レイヤをそれぞれ異なるサーバに配置できます。配置は，システムの規模や目的に応じて検討する必要があります。

機能レイヤの配置例を次の図に示します。

図3-5　機能レイヤの配置例

ここでは，次の機能レイヤを実行環境に配置する場合の構成の考え方について説明します。

Webサーバ

Webコンテナ

CTM

EJBコンテナ

JCA

EIS

ネーミングサービス

運用管理サーバ

＜この項の構成＞

(1)　WebサーバとWebコンテナ（J2EEサーバ）の配置

(2)　CTMとEJBコンテナ（J2EEサーバ）の配置

(3)　JCAとEISの配置

(4)　ネーミングサービスの配置

(5)　運用管理プロセスの配置

(1)　WebサーバとWebコンテナ（J2EEサーバ）の配置

Webサーバは，Webコンテナに対するHTTPリクエストのディスパッチ処理のほか，業務処理に含まれる静的コンテンツの処理を実行します。Webコンテナは，J2EEサーバの一部として動作して，サーブレットおよびJSPを実行するための基盤になる機能です。WebサーバとWebコンテナは同じホストまたは異なるホストに配置できます。なお，インプロセスHTTPサーバを使用する場合は，Webサーバは不要です。

WebサーバとWebコンテナを動作させるJ2EEサーバの関係は，1対1で配置することをお勧めします。なお，負荷分散をする場合は，Webサーバのフロントに負荷分散機を配置することをお勧めします。

これを踏まえた上で，次の説明を参照して，システム構成を決定してください。

「3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）」

「3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（インプロセスHTTPサーバを使用する場合）」

「3.17.1　Webサーバとアプリケーションサーバを異なるマシンに配置する構成」

(2)　CTMとEJBコンテナ（J2EEサーバ）の配置

CTMは，OLTP技術に対応して，クライアントからのリクエストのスケジューリングをする機能です。EJBコンテナは，J2EEサーバの一部として動作して，Enterprise Beanの実行および通信，トランザクション管理などのシステムレベルのサービスを提供するための基盤になる機能です。

CTMでは，EJBコンテナに対して送信されたIIOPリクエストのスケジュール処理と負荷分散処理を実行します。CTMはIIOPリクエストを処理するために特化された機能レイヤなので，EJBコンテナと別のホストに配置する必要はありません。IIOPリクエストの負荷分散は，CTM間のデータ転送で実現されます。ただし，CTMによる負荷分散の対象になるのは，Stateless Session Beanだけです。

CTMとEJBコンテナの関係は，1対多にして，それぞれロードバランスクラスタ構成にすることをお勧めします。これによって，スループットが向上します。また，拡張性と性能が高いシステムを構築できます。また，クラスタ構成にすれば障害発生時の部分縮退や部分回復ができるようになるので，信頼性と可用性も向上します。

これを踏まえた上で，次の説明を参照して，システム構成を決定してください。

「3.4.4　CTMを使用する場合にStateless Session Beanをアクセスポイントに使用する構成」

「3.7.4　CTMを利用した負荷分散（Stateless Session Beanの場合）」

(3)　JCAとEISの配置

JCAは，既存システムやデータベースなどのEISと接続するためのサポート機能を提供します。

EISに対して，JCAではコネクションプーリング処理をします。EISを一つのサーバで構築している場合，JCAとEISの関係は，多対1になります。EISを複数のサーバで構築している場合は，JCAとEISの関係は多対多になります。JCAでは，EISとの接続で障害が発生した場合に，自動回復する機能を持っているので，信頼性と可用性が確保されています。

(4)　ネーミングサービスの配置

ネーミングサービスは，名前からオブジェクトを利用できるようにするネーミング管理機能を提供します。ネーミングサービスは，Cosminexus TPBrokerによって提供されるサービスです。J2EEサーバのインプロセスで起動することをお勧めします。

インプロセスで起動することによって，アプリケーションサーバ内のプロセス数が削減できます。また，個別プロセスとしての起動処理や停止処理が不要になり，運用性が向上します。

(5)　運用管理プロセスの配置

Management Serverは，Application Server全体を運用管理するための機能を集約したサーバです。システムの運用管理，監視の対象範囲となるドメイン内に一つ配置します。

ここでは，J2EEサーバなどのほかのプロセスとは別のホストに配置した構成を使用して説明していますが，同じホストに配置した構成にすることもできます。

運用管理，監視の対象になるプロセスを配置したホストには，それぞれ運用管理エージェントを起動します。運用管理エージェントは，運用管理サーバからの指示を受けて，各ホストで操作を実行します。

運用管理者は，Smart Composer機能またはManagement Serverのコマンドを使用して，運用管理を実行します。これらのコマンドは，Management Serverを配置したホストで実行します。

参考

開発環境やテスト環境で運用管理を実行する場合には，必要に応じて次の機能も使用できます。

Server Plug-in（Eclipseのプラグイン）
EclipseからManagement Serverを配置したホストにアクセスして実行します。

運用管理ポータル
WebブラウザからManagement Serverを配置したホストにアクセスして実行します。

なお，Server Plug-inまたは運用管理ポータルを使用する場合は，必要に応じて管理クライアントマシンを用意してください。

運用管理プロセスを配置した構成については，「3.9　運用管理プロセスの配置を検討する」を参照してください。

3.2　システム構成の説明について

3章では，システム構成を検討するための，さまざまなシステム構成パターンを示して，それぞれの特徴について説明します。この節では，システム構成の説明をお読みになる前に確認していただきたい，各システム構成パターンに共通する留意点について説明します。また，この章のシステム構成図で使用する図の凡例についてもあわせて説明します。これらをご確認の上，次節以降をお読みください。

参考

ここで説明する凡例は，「4.　システム構成の検討（バッチアプリケーション実行基盤）」および「5.10.2　ファイアウォールと侵入検知システムを配置する」にも当てはまります。

＜この節の構成＞

(1)　この章のシステム構成に共通する留意点

(2)　この章で使用する図の凡例

(1)　この章のシステム構成に共通する留意点

各システム構成に共通して，次のことに留意してください。

この章では，Application Server StandardまたはApplication Server Enterpriseを使用した場合のシステム構成について説明しています。必要に応じて，この章で使用している用語を，ご利用の製品に読み替えてください。
ご利用の製品とこの章で使用している製品の対応を次の表に示します。

表3-2　ご利用の製品とこの章で使用している製品の対応

ご利用の製品 | この章で記載している製品
uCosminexus Developer Professional※1 | Application ServerおよびApplication Server Enterprise
uCosminexus Developer Standard※1※2 | Application Server
uCosminexus Service Architect※1 | Application ServerおよびApplication Server Enterprise
uCosminexus Service Platform

注※1　テスト環境で使用している場合にだけ読み替えが必要です。

注※2　uCosminexus Developer StandardとApplication Serverには一部機能差があります。機能差については，マニュアル「Cosminexus　アプリケーション開発ガイド」のDeveloper Standard使用時の注意事項に関する説明を参照してください。

システム構成の例では，主に，アプリケーションサーバを役割ごとに1台ずつ配置した例を示していますが，実際の構成では，スケーラビリティと可用性を考慮して負荷分散機などを使用したクラスタ構成にすることをお勧めします。これによって，トラブルが発生した場合やサーバのメンテナンスが必要な場合に，サービスが完全に止まることを防げます。負荷分散をする構成については，「3.7　ロードバランスクラスタによる負荷分散方式を検討する」を参照してください。

この章では，Management Serverを利用して運用することにした場合の例を示しています。Management Serverを利用しないで運用する場合，次のプロセスは不要ですので，省略してお読みください。

Management Server

運用管理エージェント

運用管理に必要なプロセスだけを起動するマシンを運用管理サーバマシンといいます。なお，Management Serverを利用しないで運用する場合，運用管理サーバマシンは不要です。

参考

Management Serverを利用しないで運用する場合に，開発環境やテスト環境でServer Plug-inや運用管理ポータルなどのクライアントから運用管理を実行するときには，管理クライアントマシンが必要です。

Server Plug-in使用する場合，管理クライアントマシンには，Eclipseが必要です。また，運用管理サーバマシンと異なるマシンを管理クライアントマシンにする場合は，uCosminexus Operatorをインストールする必要があります。

運用管理ポータルを使用する場合，管理クライアントマシンにはWebブラウザが必要です。

アクセスポイントがサーブレット／JSPのとき，この章では主に，Webサーバ連携の場合の構成例を示しています。インプロセスHTTPサーバを使用する場合は，次のプロセスは不要ですので，省略してお読みください。

Webサーバ

PRFデーモンは，性能解析トレースファイルを出力するためのプロセスです。アプリケーションサーバには必ず配置し，EJBクライアントには必要に応じて配置します。PRFデーモンの配置についての考え方については，「3.14　性能解析トレースファイルを出力するプロセスを配置する」を参照してください。

(2)　この章で使用する図の凡例

ここでは，この章のシステム構成図で使用する凡例を示します。

図3-6　3章で使用する図の凡例

また，ホストを表す色は，Management Serverによって運用管理する場合のホストの分類を表しています。

図3-7　3章で使用する図の凡例（ホストの分類）

なお，ここで示した以外の凡例については，それぞれの図で示します。

3.3　アプリケーションの構成を検討する

この節では，アプリケーションの構成の検討方法について説明します。

アプリケーションは，構成するコンポーネントの種類によって分類できます。分類ごとに，クライアント側から見たアクセスポイントがあります。ここでは，アプリケーションを構成するコンポーネントの種類と，各アプリケーションでアクセスポイントになるコンポーネントについて説明します。また，使用するリソースの種類に応じたリソースアダプタの種類についても説明します。

＜この節の構成＞

3.3.1　アプリケーションの構成とアクセスポイント

3.3.2　リソースの種類とリソースアダプタ

3.3.1　アプリケーションの構成とアクセスポイント

ここでは，アプリケーションを構成するコンポーネントの種類と，それぞれの構成の場合のアクセスポイントについて説明します。

アプリケーションを構成するコンポーネントには，次の種類があります。

サーブレットとJSP

Session BeanとEntity Bean

Message-driven Bean

＜この項の構成＞

(1)　サーブレットとJSPで構成されるアプリケーション

(2)　Session BeanとEntity Beanで構成されるアプリケーション

(3)　Message-driven Beanで構成されるアプリケーション

(1)　サーブレットとJSPで構成されるアプリケーション

サーブレットとJSPは，クライアントマシンのWebブラウザに表示するプレゼンテーションを，動的に生成するためのコンポーネントです。クライアントであるWebブラウザから，HTTPまたはHTTPSによってWebサーバ経由でアクセスされます。

サーブレットとJSPで構成されるアプリケーションの場合，クライアントから見たアクセスポイントになるコンポーネントは，フロントに配置されたサーブレットまたはJSPになります。

サーブレットとJSPで構成されるアプリケーションを次の図に示します。

図3-8　サーブレットとJSPで構成されるアプリケーション

サーブレットまたはJSPからは，JavaBeansやJavaクラスなど，ほかのコンポーネントを呼び出せます。また，Session BeanやEntity Beanを呼び出すこともできます。この場合も，クライアントから見たアクセスポイントとなるコンポーネントは，フロントに配置したサーブレットまたはJSPになります。

図3-9　サーブレットとJSPからほかのコンポーネントを呼び出す場合のアクセスポイント

このアプリケーションは，主にWebフロントシステムで動作します。

(2)　Session BeanとEntity Beanで構成されるアプリケーション

Session BeanとEntity Beanは，ビジネスロジックを実装するためのコンポーネントです。EJBクライアントから，RMI-IIOPによってアクセスされます。なお，EJBクライアントとは，Enterprise Beanを呼び出すコンポーネントの総称です。クライアントマシンで動作するEJBクライアントアプリケーション，ほかのJ2EEサーバで動作しているサーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanが該当します。

Session BeanとEntity Beanで構成されるアプリケーションの場合，アクセスポイントになるコンポーネントは，フロントに配置されたSession BeanまたはEntity Beanになります。

Session BeanとEntity Beanで構成されるアプリケーションを次の図に示します。

図3-10　Session BeanとEntity Beanで構成されるアプリケーション

Session BeanまたはEntity Beanからは，JavaBeansやJavaクラスなど，ほかのコンポーネントを呼び出せます。また，ほかのSession BeanやEntity Beanを呼び出すこともできます。ただし，この場合も，クライアントから見たアクセスポイントとなるコンポーネントは，フロントに配置したSession BeanまたはEntity Beanになります。

図3-11　Session BeanまたはEntity Beanからほかのコンポーネントを呼び出す場合のアクセスポイント

このアプリケーションは，主にバックシステムで動作します。

(3)　Message-driven Beanで構成されるアプリケーション

Message-driven Beanは，メッセージ駆動型のシステムでビジネスロジックを実装するためのコンポーネントです。次のどちらかの方法でアクセスされます。

TP1/Message QueueおよびTP1/Message Queue - Access経由でのアクセス

データベース（HiRDBまたはOracle）およびCosminexus RM経由でのアクセス

なお，Message-driven Beanをアクセスポイントとする構成の場合，リソースアダプタとして，TP1/Message Queue - AccessまたはCosminexus RMが必要です。Cosminexus RMは，DB Connector for Cosminexus RMと組み合わせて使用します。なお，Cosminexus RMおよびDB Connector for Cosminexus RMは，Application Serverが提供するリソースアダプタです。

Message-driven Beanで構成されるアプリケーションの場合，アクセスポイントになるコンポーネントは，Message-driven Beanになります。

Message-driven Beanで構成されるアプリケーションを次の図に示します。

図3-12　Message-driven Beanで構成されるアプリケーション（TP1/Message Queue - Access経由の場合）

図3-13　Message-driven Beanで構成されるアプリケーション（Cosminexus RM経由の場合）

Message-driven Beanからは，JavaBeansやJavaクラスなど，ほかのコンポーネントを呼び出せます。また，Session BeanやEntity Beanを呼び出すこともできます。ただし，この場合も，クライアントから見たアクセスポイントとなるコンポーネントは，Message-driven Beanになります。

図3-14　Message-driven Beanからほかのコンポーネントを呼び出す場合のアクセスポイント（TP1/Message Queue - Access経由の場合）

図3-15　Message-driven Beanからほかのコンポーネントを呼び出す場合のアクセスポイント（Cosminexus RM経由の場合）

このアプリケーションは，主にバックシステムで動作します。

3.3.2　リソースの種類とリソースアダプタ

Cosminexusのシステムでは，次のリソースが使用できます。

データベース（HiRDB，Oracle，SQL ServerまたはXDM/RD E2）

OpenTP1のTP1/Message Queue

OpenTP1のSPP

メールコンフィグレーション

JavaBeansリソース

なお，メールコンフィグレーションまたはJavaBeansリソースを使用する場合，リソースアダプタは不要です。

ここでは，アプリケーションが接続するリソースの種類ごとに，使用するリソースアダプタについて説明します。

ポイント

Cosminexusでは，Connector 1.0またはConnector 1.5仕様に準拠したリソースアダプタを利用できます。

ここで説明する以外のリソースアダプタについては，ご使用のリソースアダプタの説明をご確認ください。

＜この項の構成＞

(1)　データベースと接続するためのリソースアダプタ（JDBCインタフェースを使用する場合）

(2)　データベースと接続するためのリソースアダプタ（JMSインタフェースを使用する場合）

(3)　OpenTP1のTP1/Message Queueに接続するためのリソースアダプタ

(4)　OpenTP1のSPPと接続するためのリソースアダプタ

(1)　データベースと接続するためのリソースアダプタ（JDBCインタフェースを使用する場合）

JDBCインタフェースを使用してデータベースと接続する場合，リソースアダプタとしてDB Connectorを使用します。DB Connectorを使用すると，サーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanから，JDBCインタフェースを使用してデータベースにアクセスできます。

なお，Cosminexusがリソースアダプタを使用してアクセスできるデータベースは，HiRDB，Oracle，SQL ServerまたはXDM/RD E2です。リソースアダプタを使用してデータベースにアクセスする場合の構成を，データベースの種類ごとに図に示します。

HiRDBにアクセスする場合の構成
HiRDBに接続する場合，J2EEサーバと同じマシンに，HiRDB Type4 JDBC DriverまたはHiRDB Run Timeが必要となります。HiRDB Run Timeは，JDBCドライバとして，Cosminexus DABroker Libraryを使用している場合に必要です。
HiRDBにアクセスする場合の構成を，HiRDB Type4 JDBC Driverを使用するときとCosminexus DABroker Libraryを使用するときに分けて，図に示します。

図3-16　リソースアダプタを使用してHiRDBにアクセスする場合の構成（HiRDB Type4 JDBC Driverを使用するとき）

図3-17　リソースアダプタを使用してHiRDBにアクセスする場合の構成（Cosminexus DABroker Libraryを使用するとき）

Oracleにアクセスする場合の構成
Oracleに接続する場合，J2EEサーバと同じマシンに，Oracle JDBC Thin DriverまたはOracle Clientが必要となります。Oracle Clientは，JDBCドライバとして，Cosminexus DABroker Libraryを使用している場合に必要です。
Oracleにアクセスする場合の構成を，Oracle JDBC Thin Driverを使用するときとCosminexus DABroker Libraryを使用するときに分けて，図に示します。

図3-18　リソースアダプタを使用してOracleにアクセスする場合の構成（Oracle JDBC Thin Driverを使用するとき）

図3-19　リソースアダプタを使用してOracleにアクセスする場合の構成（Cosminexus DABroker Libraryを使用するとき）

SQL Serverにアクセスする場合の構成
SQL Serverに接続する場合，J2EEサーバと同じマシンに，SQL ServerのJDBCドライバが必要となります。
SQL Serverにアクセスする場合の構成を次の図に示します。

図3-20　リソースアダプタを使用してSQL Serverにアクセスする場合の構成

XDM/RD E2にアクセスする場合の構成
XDM/RD E2に接続する場合，J2EEサーバと同じマシンに，HiRDB Type4 JDBC DriverまたはHiRDB Run Timeが必要となります。HiRDB Run Timeは，JDBCドライバとして，Cosminexus DABroker Libraryを使用している場合に必要です。
XDM/RD E2にアクセスする場合の構成を，HiRDB Type4 JDBC Driverを使用するときとCosminexus DABroker Libraryを使用するときに分けて，図に示します。

図3-21　リソースアダプタを使用してXDM/RD E2にアクセスする場合の構成（HiRDB Type4 JDBC Driverを使用するとき）

図3-22　リソースアダプタを使用してXDM/RD E2にアクセスする場合の構成（Cosminexus DABroker Libraryを使用するとき）

(2)　データベースと接続するためのリソースアダプタ（JMSインタフェースを使用する場合）

JMSインタフェースを使用してデータベースと接続する場合，リソースアダプタとしてDB Connector for Cosminexus RMを使用します。DB Connector for Cosminexus RMは，Cosminexus RMと連携するためのリソースアダプタです。Cosminexus RMを使用すると，サーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanから，JMSインタフェースを使用してデータベース上に実現したキューにアクセスできます。この場合，J2EEサーバ上では，Cosminexus RMのライブラリが動作して，キューのデータはデータベースに保存されます。なお，Cosminexus RMはApplication Serverの構成ソフトウェアです。

Cosminexus RMを使用してデータベースにアクセスする場合の構成を，HiRDBにアクセスする場合と，Oracleにアクセスする場合に分けて，図に示します。

図3-23　Cosminexus RMを使用してHiRDBにアクセスする場合の構成

図3-24　Cosminexus RMを使用してOracleにアクセスする場合の構成

(3)　OpenTP1のTP1/Message Queueに接続するためのリソースアダプタ

OpenTP1のメッセージキューイング機能であるTP1/Message Queueと接続する場合，リソースアダプタとしてTP1/Message Queue - Accessを使用します。TP1/Message Queue - Accessを使用すると，サーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanから，JMSインタフェースを使用してTP1/Message Queueにアクセスできます。この場合，J2EEサーバと同じマシンに，TP1/Message Queue - Accessが必要となります。

リソースアダプタを使用してTP1/Message Queueにアクセスする場合の構成を，次の図に示します。

図3-25　リソースアダプタを使用してTP1/Message Queueにアクセスする場合の構成

(4)　OpenTP1のSPPと接続するためのリソースアダプタ

OpenTP1のSPP（サービス提供プログラム：Service Providing Program）と接続する場合，リソースアダプタとしてuCosminexus TP1 ConnectorおよびTP1/Client/Jを使用します。uCosminexus TP1 ConnectorおよびTP1/Client/Jを使用すると，サーブレット，JSP，Session Bean，Entity BeanまたはMessage-driven Beanから，OpenTP1のSPPにアクセスできます。このとき，J2EEサーバと同じマシンに，uCosminexus TP1 ConnectorおよびTP1/Client/Jが必要となります。

リソースアダプタを使用してOpenTP1のSPPにアクセスする場合の構成を，次の図に示します。

図3-26　リソースアダプタを使用してOpenTP1のSPPにアクセスする場合の構成

3.4　クライアントとサーバの構成を検討する

この節では，クライアントとサーバの構成の種類と，それぞれの場合に各マシンに配置するプロセスについて説明します。また，それぞれの構成の特徴についても説明します。

クライアントとサーバの構成を検討するためには，処理を呼び出す側であるクライアントと呼び出される側であるサーバの対応を決めて，サーバ側で動作するアプリケーションのアクセスポイントを明確にする必要があります。

ここでは，次のコンポーネントをアクセスポイントとするクライアントとサーバの構成について説明します。なお，サーブレットとJSPをアクセスポイントにする構成については，Webサーバ連携の場合とインプロセスHTTPサーバを使用する場合に分けて説明します。

サーブレットとJSP

Session BeanとEntity Bean

CTMを使用する場合のStateless Session Bean

以降，アプリケーションサーバを配置したマシンをアプリケーションサーバマシン，クライアントとして使用するマシンをクライアントマシンといいます。

＜この節の構成＞

3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）

3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（インプロセスHTTPサーバを使用する場合）

3.4.3　Session BeanとEntity Beanをアクセスポイントに使用する構成

3.4.4　CTMを使用する場合にStateless Session Beanをアクセスポイントに使用する構成

3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）

サーブレットとJSPがアクセスポイントになる，Webベースのシステム構成について説明します。この構成をWebクライアント構成といいます。Webフロントシステムで使用できる構成です。ここでは，Webサーバ連携の場合の構成について説明します。

また，この構成でインターネットに接続する場合，セキュリティの観点から，アプリケーションサーバと同じマシンに配置するWebサーバとは別に，DMZにリバースプロキシの機能を持つWebサーバを配置することをお勧めします。詳細は，「3.13　DMZへのリバースプロキシの配置を検討する」を参照してください。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なプロセスとソフトウェア

(1)　システム構成の特徴

Webフロントシステムで，Webブラウザから送信されたリクエストをアプリケーションサーバで処理する場合に適用されるシステム構成です。

最も基本的なWebクライアント構成は，クライアントマシンと1台のアプリケーションサーバマシンによって構築できます。1台のアプリケーションサーバマシンで構築するWebクライアント構成の例を次の図に示します。

図3-27　1台のアプリケーションサーバマシンで構築するWebクライアント構成の例（Webサーバ連携の場合）

特徴

クライアントで使用するソフトウェアはWebブラウザだけです。

リクエストの流れ

アクセスポイントであるサーブレットとJSPは，J2EEサーバ上で動作します。これらのコンポーネントは，WebブラウザからWebサーバ経由でアクセスされます。

(2)　それぞれのマシンに必要なプロセスとソフトウェア

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。なお，リソースと接続するために必要なプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

必要なプロセスは次のとおりです。

Webサーバ

J2EEサーバ

運用管理エージェント

PRFデーモン

なお，Application Server StandardまたはApplication Server Enterpriseには，WebサーバであるHitachi Web Serverが含まれています。Windowsの場合，WebサーバにMicrosoft IISを使用することもできます。この場合は，ソフトウェアとしてMicrosoft IISが必要です。

(b)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(c)　Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（インプロセスHTTPサーバを使用する場合）

サーブレットとJSPがアクセスポイントになる，Webベースのシステム構成について説明します。ここでは，インプロセスHTTPサーバを使用する場合の構成について説明します。

なお，この構成でインターネットに接続する場合，セキュリティの観点から，DMZにリバースプロキシの機能を持つWebサーバを配置してください。詳細は，「3.13　DMZへのリバースプロキシの配置を検討する」を参照してください。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なプロセスとソフトウェア

(1)　システム構成の特徴

Webフロントシステムで，Webブラウザから送信されたリクエストをアプリケーションサーバで処理する場合に適用されるシステム構成です。

最も基本的なWebクライアント構成は，クライアントマシンと1台のアプリケーションサーバマシンによって構築できます。インプロセスHTTPサーバを使用する場合，J2EEサーバのフロントにWebサーバを起動する必要がありません。J2EEサーバ上のHTTPサーバの機能を使用します。

インプロセスHTTPサーバを使用する場合のWebクライアント構成の例を次の図に示します。

図3-28　1台のアプリケーションサーバマシンで構築するWebクライアント構成の例（インプロセスHTTPサーバを使用する場合）

特徴

クライアントで使用するソフトウェアはWebブラウザだけです。

WebブラウザからWebサーバを経由しないで直接J2EEサーバにアクセスできるため，性能上のメリットがあります。また，Webサーバを起動する必要がないため，運用が簡易になります。

なお，インプロセスHTTPサーバを使用する場合，次の点に留意してください。

インプロセスHTTPサーバでは，Webサーバとして動作するための最小限の機能だけがサポートされています。このため，Webサーバのさまざまな機能を必要とする場合は，この構成は適していません。リダイレクタモジュールを組み込んだWebサーバと連携する構成を選択してください。インプロセスHTTPサーバで使用できる機能については，マニュアル「Cosminexus　機能解説」のインプロセスHTTPサーバで使用できる機能に関する説明を参照してください。

インプロセスHTTPサーバでは，HTTPSはサポートされていません。このため，SSLを使用する場合には，プロキシサーバをフロントに配置してプロキシモジュールを組み込んだWebサーバのSSL機能を使用するか，または，SSLアクセラレータをフロントに配置してください。

インターネットに接続するシステムでは，セキュリティ上の観点から，必ずリバースプロキシをフロントに配置してください。リバースプロキシを配置する構成については，「3.13　DMZへのリバースプロキシの配置を検討する」を参照してください。

リクエストの流れ

アクセスポイントであるサーブレットとJSPは，J2EEサーバ上で動作します。これらのコンポーネントは，Webブラウザから直接アクセスされます。

(2)　それぞれのマシンに必要なプロセスとソフトウェア

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。なお，リソースと接続するために必要なプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

必要なプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(c)　Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

3.4.3　Session BeanとEntity Beanをアクセスポイントに使用する構成

Session BeanとEntity Beanがアクセスポイントになり，クライアントでEJBクライアントアプリケーションを動作させるシステム構成について説明します。この構成を，EJBクライアント構成といいます。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

最も基本的なEJBクライアント構成は，クライアントマシンと1台のアプリケーションサーバマシンによって構築できます。

1台のアプリケーションサーバマシンで構築するEJBクライアント構成の例を次の図に示します。

図3-29　1台のアプリケーションサーバマシンで構築するEJBクライアント構成の例

特徴

Windowsの場合は，uCosminexus Clientを使用してクライアントマシンの環境を構築できます。

リクエストの流れ

アクセスポイントであるSession BeanとEntity Beanは，J2EEサーバ上で動作します。

EJBクライアントアプリケーションからのリクエストは，RMI-IIOPによってアクセスポイントに送られ，Session BeanとEntity Beanを呼び出します。このとき，EJBクライアントアプリケーションは，J2EEサーバ内で動作しているネーミングサービスから名前を検索（ルックアップ）して，Session BeanとEntity Beanにアクセスします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースに接続するためのプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(c)　EJBクライアントマシン

EJBクライアントマシンには，Application Server Standard，Application Server EnterpriseまたはuCosminexus Client（Windowsの場合）をインストールする必要があります。

起動するプロセスは，EJBクライアントアプリケーションのプロセスです。

3.4.4　CTMを使用する場合にStateless Session Beanをアクセスポイントに使用する構成

CTMを使用する場合の，Stateless Session Beanをアクセスポイントとするシステム構成について説明します。

参考

ここでは，クライアントとしてEJBクライアントアプリケーションを使用するEJBクライアント構成の例を示します。このほか，CTMゲートウェイ機能を使用すると，EJBクライアント以外のクライアントアプリケーションからJ2EEサーバ上のEJBアプリケーションを直接呼び出す構成も実現できます。これらの構成については，「3.15.2　CTMゲートウェイ機能を利用してEJBクライアント以外からStateless Session Beanを呼び出す構成」を参照してください。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

EJBクライアント構成の一つです。アクセスポイントであるStateless Session Beanに対して，CTMによってスケジューリングされたリクエストが送信されます。

CTMを使用する場合のEJBクライアント構成の例を次の図に示します。

図3-30　CTMを使用する場合のEJBクライアント構成の例

特徴

CTMによってリクエストをスケジューリングすることで，サービス閉塞を実行したり同時実行数を制御したりするシステム運用ができるようになります。

J2EEサーバを二つ以上起動することで，一つのJ2EEサーバにトラブルが発生した場合に，縮退運転をしてシステムの稼働を続けられます。

Windowsの場合は，uCosminexus Clientを使用してクライアントマシンの環境を構築できます。

リクエストの流れ

アクセスポイントであるStateless Session Beanは，J2EEサーバ上で動作します。

EJBクライアントアプリケーションからのリクエストは，CTM経由で送られ，Stateless Session Beanを呼び出します。このとき，EJBクライアントアプリケーションは，グローバルCORBAネーミングサービスから名前をルックアップして，Stateless Session Beanにアクセスします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースに接続するためのプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

グローバルCORBAネーミングサービス

CTMのプロセス群（CTMデーモンおよびCTMレギュレータ）

CTMドメインマネジャ

スマートエージェント

(b)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(c)　EJBクライアントマシン

EJBクライアントマシンには，Application Server Standard，Application Server EnterpriseまたはuCosminexus Client（Windowsの場合）をインストールする必要があります。

起動するプロセスはEJBクライアントアプリケーションのプロセスです。

3.5　サーバ間での連携を検討する

この節では，複数のアプリケーションサーバ上のJ2EEサーバで動作するアプリケーションを連携させる構成の種類と，それぞれの場合に各マシンに配置するプロセスについて説明します。また，それぞれの構成の特徴についても説明します。

なお，複数のアプリケーションサーバで構成するシステムの場合，呼び出し元になるアプリケーションが動作しているアプリケーションサーバをクライアント側のアプリケーションサーバ，呼び出されるアプリケーションが動作しているアプリケーションサーバをサーバ側のアプリケーションサーバといいます。

ここでは，次に示す2種類のサーバ間連携の構成について説明します。

Session BeanとEntity Beanを呼び出すサーバ間連携

CTM経由でStateless Session Beanを呼び出すサーバ間連携

＜この節の構成＞

3.5.1　Session BeanとEntity Beanを呼び出すサーバ間連携

3.5.2　CTM経由でStateless Session Beanを呼び出すサーバ間連携

3.5.1　Session BeanとEntity Beanを呼び出すサーバ間連携

ほかのアプリケーションサーバ上のJ2EEサーバからSession BeanまたはEntity Beanを呼び出す場合の構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

クライアント側のアプリケーションサーバから，サーバ側のアプリケーションサーバを呼び出す構成です。クライアント側のアプリケーションサーバでは，サーブレット，JSP，Entity Bean，Session BeanまたはMessage-driven Beanで構成されるアプリケーションが動作します。サーバ側のアクセスポイントになるコンポーネントは，Session BeanまたはEntity Beanです。クライアント側のアプリケーションからの呼び出しは，RMI-IIOPで実行されます。

Session BeanとEntity Beanを呼び出すサーバ間連携の構成の例を，次の図に示します。

図3-31　Session BeanとEntity Beanを呼び出すサーバ間連携の構成の例

特徴

アプリケーション間連携で使用できる構成です。複数のクライアントアプリケーションから，サーバアプリケーションを呼び出す場合などに適用できます。

システム間連携の場合にも使用できます。すでに構築されたクライアント側システムとサーバ側システムをこのシステム構成にすることで，アプリケーションをシステム間で呼び出せます。

リクエストの流れ

サーバ側のアクセスポイントであるSession BeanまたはEntity Beanへのリクエストは，クライアント側のJ2EEサーバから送られます。

このとき，クライアント側では，サーバ側のアプリケーションサーバのJ2EEサーバ内でインプロセスで起動されているCORBAネーミングサービスから名前をルックアップして，Session BeanまたはEntity Beanにアクセスします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

Session BeanまたはEntity Beanを呼び出すサーバ間連携の場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースと接続するために必要なプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　クライアント側のアプリケーションサーバマシン（サーブレット／JSPの実行環境）

サーブレットおよびJSPを動作させるクライアント側のアプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Webサーバ

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　クライアント側のアプリケーションサーバマシン（Message-driven Beanの実行環境）

Message-driven Beanを動作させるクライアント側のアプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。また，リソースアダプタとしてTP1/Message Queue - Accessを使用する場合は，TP1/Message Queue - Accessをインストールする必要があります。なお，Cosminexus RMを使用する場合は，Application Serverに含まれているため，個別にインストールする必要はありません。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(c)　サーバ側のアプリケーションサーバマシン

サーバ側のアプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(d)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.5.2　CTM経由でStateless Session Beanを呼び出すサーバ間連携

CTMを使用する場合に，ほかのアプリケーションサーバ上のJ2EEサーバからCTM経由でStateless Session Beanを呼び出すときの構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

クライアント側のアプリケーションサーバから，CTM経由でサーバ側のアプリケーションサーバを呼び出す構成です。クライアント側のアプリケーションサーバでは，サーブレット，JSP，Entity Bean，Session BeanまたはMessage-driven Beanで構成されるアプリケーションが動作します。サーバ側のアクセスポイントになるコンポーネントは，Stateless Session Beanです。クライアント側のアプリケーションからの呼び出しは，RMI-IIOPで実行されます。

CTM経由でStateless Session Beanを呼び出すサーバ間連携の構成の例を次の図に示します。

図3-32　Stateless Session Beanを呼び出すサーバ間連携の構成の例

特徴

アプリケーション間連携で使用できる構成です。複数のクライアントアプリケーションから，サーバアプリケーションを呼び出す場合などに適用できます。

システム間連携の場合にも使用できます。すでに構築されたクライアント側システムとサーバ側システムをこのシステム構成にすることで，アプリケーションをシステム間で呼び出せます。

リクエストの流れ

サーバ側のアクセスポイントであるStateless Session Beanへのリクエストは，クライアント側のJ2EEサーバからCTM経由で送られます。

このとき，クライアント側では，サーバ側のアプリケーションサーバのグローバルCORBAネーミングサービスから名前をルックアップして，CTM経由でStateless Session Beanにアクセスします。

CTMを経由したリクエストは，CTMによってJ2EEサーバ上で動作するStateless Session Beanに適切に振り分けられます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

CTM経由でStateless Session Beanを呼び出すサーバ間連携の場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースと接続するために必要なプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　クライアント側のアプリケーションサーバマシン（サーブレット／JSPの実行環境）

サーブレットおよびJSPを動作させるクライアント側のアプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Webサーバ

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　クライアント側のアプリケーションサーバマシン（Session Beanの実行環境）

Session Beanを動作させるクライアント側のアプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(c)　サーバ側のアプリケーションサーバマシン

サーバ側のアプリケーションサーバマシンには，Application Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

グローバルCORBAネーミングサービス

CTMのプロセス群（CTMデーモンおよびCTMレギュレータ）

CTMドメインマネジャ

スマートエージェント

(d)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.6　トランザクションの種類を検討する

この節では，トランザクションの種類ごとのシステム構成について説明します。

トランザクションに参加するリソースが一つの場合は，ローカルトランザクションを使用します。トランザクションに参加するリソースが複数の場合は，グローバルトランザクションを使用します。また，サーバ間で連携する構成の場合に，それぞれのJ2EEサーバが異なるリソースに接続するときには，トランザクションコンテキストのプロパゲーションも使用できます。

なお，接続するリソースとリソースアダプタの対応については，「3.3.2　リソースの種類とリソースアダプタ」を参照してください。

参考

この節では，アプリケーションサーバによって開始されるトランザクションの種類ごとの構成について説明しますが，EJBクライアントアプリケーションでもトランザクションを開始できます。なお，EJBクライアントアプリケーションでトランザクションを開始する場合は，EJBクライアントマシンにApplication Server StandardまたはApplication Server Enterpriseが必要です。

＜この節の構成＞

3.6.1　ローカルトランザクションを使用する場合の構成

3.6.2　グローバルトランザクションを使用する場合の構成

3.6.3　トランザクションコンテキストのプロパゲーションを使用する場合の構成

3.6.1　ローカルトランザクションを使用する場合の構成

トランザクションに参加するリソースが一つの場合の構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

サーブレット，JSPおよびSession Beanで構成される一つのJ2EEアプリケーションから，リソースアダプタ経由で一つのリソースマネジャにアクセスする場合の構成です。アプリケーションからリソースマネジャへのアクセスで使用するトランザクションは，リソースマネジャ側で管理されます。トランザクションの種類はXAインタフェースを使用しない，ローカルトランザクションになります。

ローカルトランザクションを使用する場合の構成の例を，次の図に示します。

図3-33　ローカルトランザクションを使用する場合の構成の例

特徴

アプリケーションから一つのリソースマネジャにアクセスします。2フェーズコミットは必要ありません。

アプリケーションからリソースアダプタ経由でリソースマネジャにアクセスする流れ

WebブラウザからWebサーバ経由でアクセスされたサーブレットおよびJSPは，同じアプリケーション内のSession Beanをローカルで呼び出します。Session Beanは，リソースアダプタを経由してリソースマネジャ（図3-33の場合はHiRDB）にアクセスします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

ローカルトランザクションを使用する場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

また，リソースマネジャと接続するために，次のソフトウェアが必要です。

接続するリソースマネジャ
必要なソフトウェア

HiRDB
HiRDB Run TimeまたはHiRDB Type4 JDBC Driver

Oracle
Oracle ClientまたはOracle JDBC Thin Driver

SQL Server
SQL ServerのJDBCドライバ

XDM/RD E2
HiRDB Run TimeまたはHiRDB Type4 JDBC Driver

TP1/Message Queue
TP1/Message Queue - Access

OpenTP1のSPP
uCosminexus TP1 Connector
TP1/Client/J

起動するプロセスは次のとおりです。

Webサーバ

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　リソースマネジャが動作するマシン

リソースマネジャが動作するマシンには，次に示すソフトウェアのどれかをインストールしてください。

HiRDB（HiRDBと接続する場合）

Oracle（Oracleと接続する場合）

SQL Server（SQL Serverと接続する場合）

XDM/RD E2（XDM/RD E2と接続する場合）

TP1/Message Queue（TP1/Message Queueと接続する場合）

TP1/Server Base（OpenTP1のSPPと接続する場合）

また，それぞれのリソースマネジャで必要なプロセスを起動してください。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

3.6.2　グローバルトランザクションを使用する場合の構成

トランザクションに参加するリソースが複数の場合の構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

Session Beanを構成要素とする一つのJ2EEアプリケーションから，リソースアダプタ経由で複数のリソースマネジャにアクセスする構成です。アプリケーションからリソースマネジャへのアクセスで使用するトランザクションは，J2EEサーバ側で管理します。トランザクションの種類は，XAインタフェースを使用するグローバルトランザクションになります。

グローバルトランザクションを使用する場合の構成の例を，次の図に示します。この例は，CTMを使用するシステムの場合の例です。

図3-34　グローバルトランザクションを使用する場合の構成の例

特徴

アプリケーションから複数のリソースマネジャにアクセスします。2フェーズコミットが必要になります。

一つのリソースマネジャにアクセスするアプリケーションと，複数のリソースマネジャにアクセスするアプリケーションを混在させるシステムの場合も，この構成にする必要があります。

アプリケーションからリソースアダプタ経由でリソースマネジャにアクセスする流れ

EJBクライアントアプリケーションからアクセスされたStateless Session Beanは，リソースアダプタを経由してリソースマネジャにアクセスします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

グローバルトランザクションを使用する場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

また，リソースマネジャと接続するために，次のソフトウェアをインストールする必要があります。

接続するリソースマネジャ
必要なソフトウェア

HiRDB
HiRDB Run TimeまたはHiRDB Type4 JDBC Driver

Oracle
Oracle ClientまたはOracle JDBC Thin Driver

TP1/Message Queue
TP1/Message Queue - Access

OpenTP1のSPP
uCosminexus TP1 Connector
TP1/Client/J

注　SQL ServerおよびXDM/RD E2はグローバルトランザクションでは使用できません。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

また，図3-34のようにCTMを使用する構成の場合は，Application Server Enterpriseをインストールして，上記のプロセスのほかに，グローバルCORBAネーミングサービス，CTMのプロセス群，CTMドメインマネジャおよびスマートエージェントも起動する必要があります。詳細は，「3.5.2　CTM経由でStateless Session Beanを呼び出すサーバ間連携」を参照してください。

(b)　リソースマネジャが動作するマシン

リソースマネジャが動作するマシンには，次に示すソフトウェアのどれかをインストールしてください。なお，SQL ServerおよびXDM/RD E2はグローバルトランザクションでは使用できません。

HiRDB（HiRDBと接続する場合）

Oracle（Oracleと接続する場合）

TP1/Message Queue（TP1/Message Queueと接続する場合）

TP1/Server Base（OpenTP1のSPPと接続する場合）

また，それぞれのリソースマネジャで必要なプロセスを起動してください。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　EJBクライアントマシン

EJBクライアントマシンには，Application Server Standard，Application Server EnterpriseまたはuCosminexus Client（Windowsの場合）をインストールする必要があります。

起動するプロセスは，EJBクライアントアプリケーションのプロセスです。

3.6.3　トランザクションコンテキストのプロパゲーションを使用する場合の構成

サーバ間で連携する構成の場合に，それぞれのJ2EEサーバが異なるリソースに接続する構成について説明します。この構成では，トランザクションコンテキストのプロパゲーションを使用します。なお，この構成の場合，CTMは使用できません。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

複数のJ2EEアプリケーションでサーバ間連携をする構成です。ここでは，サーブレット，JSP，およびSession Beanで構成されるJ2EEアプリケーションと，Session Beanだけで構成されるJ2EEアプリケーションでサーバ間連携をする例について説明します。サーブレット，JSPおよびSession Beanで構成されるアプリケーションは，クライアント側のアプリケーションサーバで動作し，Session Beanで構成されるJ2EEアプリケーションは，サーバ側のアプリケーションサーバで動作します。

それぞれのJ2EEアプリケーションは，リソースアダプタ経由で異なるリソースマネジャにアクセスします。この場合，リソースマネジャへのアクセスで使用するトランザクションは，J2EEサーバ側で管理します。このときのトランザクションの種類は，XAインタフェースを使用するグローバルトランザクションになります。

なお，CTM経由でStateless Session Beanを呼び出す構成では，トランザクションコンテキストのプロパゲーションは使用できません。

トランザクションコンテキストのプロパゲーションを使用する場合の構成の例を次の図に示します。この例では，J2EEアプリケーションは，それぞれ，データベースとOpenTP1のSPPにアクセスします。

図3-35　トランザクションコンテキストのプロパゲーションを使用する場合の構成の例

特徴

サーバ間連携をするアプリケーションから複数のリソースマネジャにアクセスする場合に適用できます。

サーバ間連携をする場合に，一つのリソースマネジャにアクセスするアプリケーションと，複数のリソースマネジャにアクセスするアプリケーションを混在させるシステムの場合は，この構成にする必要があります。

アプリケーションからリソースアダプタ経由でリソースマネジャにアクセスする流れ

WebブラウザからWebサーバ経由でアクセスされたサーブレットおよびJSPは，同じアプリケーション内のSession Beanをローカルで呼び出します。Session Beanは，トランザクションを開始して，データベースにアクセスしてから，サーバ側のアプリケーションサーバ上のJ2EEサーバで動作しているSession Beanを呼び出します。呼び出されたサーバ側のアプリケーションサーバ上のSession Beanは，OpenTP1のSPPにアクセスします。クライアント側のアプリケーションサーバ上のSession Beanは，サーバ側のSession Beanから制御が戻ると，トランザクションをコミットします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

トランザクションコンテキストのプロパゲーションを使用するときに必要なソフトウェアと起動するプロセスは，「3.6.2　グローバルトランザクションを使用する場合の構成」と同様です。ただし，コンテキストのトランザクションプロパゲーションを使用する場合，CTMは使用できません。

3.7　ロードバランスクラスタによる負荷分散方式を検討する

この節では，ロードバランスクラスタによって負荷を分散するための構成について説明します。

負荷分散は次の方法で実現します。アクセスポイントになるコンポーネントの種類によって，実現できるものが異なります。

負荷分散機を利用する（サーブレット／JSPの場合）

ネーミングサービスを利用する（Session Bean／Entity Beanの場合）

CTMを利用する（Stateless Session Beanの場合）

負荷分散機を利用する構成については，Webサーバ連携の場合とインプロセスHTTPサーバを利用する場合に分けて説明します。なお，アクセスポイントがMessage-driven Beanの場合の負荷分散については，「3.8.3　Message-driven Beanのインスタンスプールを利用した負荷分散（TP1/Message Queueを使用する場合）」を参照してください。

＜この節の構成＞

3.7.1　Webサーバ連携時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合）

3.7.2　インプロセスHTTPサーバ使用時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合）

3.7.3　CORBAネーミングサービスを利用した負荷分散（Session BeanとEntity Beanの場合）

3.7.4　CTMを利用した負荷分散（Stateless Session Beanの場合）

3.7.1　Webサーバ連携時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合）

負荷分散機（レイヤ5スイッチ）によって負荷を分散する構成について説明します。この方法は，サーブレットまたはJSPがアクセスポイントの場合に使用できます。

ここでは，Webサーバと連携する場合について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントが，サーブレットまたはJSPの場合に使用できる構成です。

負荷分散は，負荷分散機に対象となるアプリケーションサーバを登録することで実現できます。アプリケーションサーバを複数登録することで，クライアントからのアクセスによる負荷を分散できます。

負荷分散機を利用した負荷分散の構成の例を次の図に示します。

図3-36　負荷分散機を利用した負荷分散の構成の例（Webサーバと連携する場合）

特徴

サーブレットとJSPのスケーラビリティと可用性を確保できます。

特定のアプリケーションサーバでトラブルが発生した場合，またはメンテナンスが必要な場合に，負荷分散機から該当するアプリケーションサーバへのアクセスを停止することで，システムの縮退運転ができます。

リクエストの流れ

アクセスポイントであるJ2EEサーバ上のサーブレットとJSPへのリクエストは，Webブラウザから，負荷分散機およびWebサーバ経由で送られます。その際，負荷分散機では，Webブラウザからのアクセスを，それぞれのアプリケーションサーバ上で動作しているWebサーバに対して振り分けます。なお，負荷分散機では，HTTPセッションのスティッキー（Sticky）やアフィニティ（Afinity）の関連づけも制御します。

参考

HTTPSを使用する場合は，負荷分散機のフロントにSSLアクセラレータを配置する必要があります。

Smart Composer機能を使用する場合は，負荷分散機を冗長化構成で配置することもできます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

負荷分散機を使用する場合にそれぞれのマシンに必要なソフトウェアと起動するプロセスは，サーブレットとJSPをアクセスポイントにする構成と同じです。「3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）」を参照してください。

3.7.2　インプロセスHTTPサーバ使用時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合）

負荷分散機（レイヤ5スイッチ）によって負荷を分散する構成について説明します。この方法は，サーブレットまたはJSPがアクセスポイントの場合に使用できます。

ここでは，インプロセスHTTPサーバ機能を使用する場合について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントが，サーブレットまたはJSPの場合に使用できる構成です。

負荷分散は，負荷分散機に対象になるアプリケーションサーバを登録することで実現できます。アプリケーションサーバを複数登録することで，クライアントからのアクセスによる負荷を分散できます。

負荷分散機を利用した負荷分散の構成の例を次の図に示します。

図3-37　負荷分散機を利用した負荷分散の構成の例（インプロセスHTTPサーバを使用する場合）

特徴

サーブレットとJSPのスケーラビリティと可用性を確保できます。

特定のアプリケーションサーバでトラブルが発生した場合，またはメンテナンスが必要な場合に，負荷分散機から該当するアプリケーションサーバへのアクセスを停止することで，システムの縮退運転ができます。

WebブラウザからWebサーバを経由しないで直接J2EEサーバにアクセスできるため，性能上のメリットがあります。また，Webサーバを起動する必要がないため，運用が簡易になります。ただし，使用できる機能や構成について，留意する必要があります。また，インターネットに接続する場合は，必ずリバースプロキシを組み込んだWebサーバをフロントに配置してください。詳細は，「3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（インプロセスHTTPサーバを使用する場合）」を参照してください。

リクエストの流れ

アクセスポイントであるJ2EEサーバ上のサーブレットとJSPへのリクエストは，Webブラウザから，負荷分散機経由で送られます。その際，負荷分散機では，Webブラウザからのアクセスを，それぞれのアプリケーションサーバ上で動作しているJ2EEサーバに対して振り分けます。なお，負荷分散機では，HTTPセッションのスティッキー（Sticky）やアフィニティ（Afinity）の関連づけも制御します。

参考

HTTPSを使用する場合は，負荷分散機のフロントにSSLアクセラレータを配置する必要があります。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

負荷分散機を使用する場合にそれぞれのマシンに必要なソフトウェアと起動するプロセスは，サーブレットとJSPをアクセスポイントにする構成と同じです。「3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（インプロセスHTTPサーバを使用する場合）」を参照してください。

3.7.3　CORBAネーミングサービスを利用した負荷分散（Session BeanとEntity Beanの場合）

アクセスポイントになるコンポーネントがSession BeanまたはEntity Beanの場合に，J2EEサーバ内（インプロセス）のCORBAネーミングサービスのラウンドロビン検索機能を使用して負荷を分散する構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントが，Session BeanまたはEntity Beanの場合に使用できる構成です。クライアントは，EJBクライアントアプリケーションです。EJBクライアントアプリケーションは，システムプロパティに登録した論理ネーミングサービスから，オブジェクトリファレンスをラウンドロビン方式でルックアップすることで，リクエストの振り分け先を分散します。ただし，それぞれのJ2EEサーバでは同じ名前（同じ別名）でSession BeanおよびEntity Beanを開始しておく必要があります。

なお，EJBクライアントアプリケーションは，ラウンドロビン方式でJ2EEサーバ内のネーミングサービスをルックアップしたあと再度ネーミングサービスをルックアップするまでの間は，同じJ2EEサーバにアクセスします。

Session BeanとEntity Beanを対象にした負荷分散の構成の例を次の図に示します。

図3-38　Session BeanとEntity Beanを対象にした負荷分散の構成の例

特徴

Session BeanとEntity Beanのスケーラビリティと可用性を確保できます。

アプリケーションサーバを複数用意して，EJBクライアントからラウンドロビン方式でCORBAネーミングサービスを選択してアクセスすることで，負荷を分散できます。

特定のアプリケーションサーバでトラブルが発生した場合，またはメンテナンスが必要な場合，EJBクライアントアプリケーションでは，J2EEサーバの終了を検出したあと，該当するアプリケーションサーバにアクセスしません。このため，システムの縮退運転ができます。

リクエストの流れ

アクセスポイントであるJ2EEサーバ上のSession BeanとEntity Beanへのリクエストは，EJBクライアントアプリケーションから送られます。その際，EJBクライアントアプリケーションでは，J2EEサーバ内のネーミングサービスをラウンドロビン方式で選択して，オブジェクトリファレンスをルックアップします。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

CORBAネーミングサービスを使用して負荷を分散する場合にそれぞれのマシンに必要なソフトウェアと起動するプロセスは，Session BeanとEntity Beanをアクセスポイントにする構成と同じです。「3.4.3　Session BeanとEntity Beanをアクセスポイントに使用する構成」を参照してください。

3.7.4　CTMを利用した負荷分散（Stateless Session Beanの場合）

アクセスポイントになるコンポーネントがStateless Session Beanの場合に，CTMによって負荷を分散する構成です。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントがStateless Session Beanの場合に，CTMを使用して実現する構成です。ここでは，クライアントがEJBクライアントアプリケーションの場合について説明します。

EJBクライアントアプリケーションは，システムプロパティに登録したグローバルCORBAネーミングサービスからオブジェクトリファレンスをラウンドロビン方式でルックアップすることで，リクエストの振り分け先を分散します。ただし，それぞれのJ2EEサーバでは同じ名前（同じ別名）でStateless Session Beanを開始しておく必要があります。

Stateless Session Beanを対象にしたCTMによる負荷分散の構成の例を次の図に示します。

図3-39　Stateless Session Beanを対象にしたCTMによる負荷分散の構成の例

特徴

Stateless Session Beanの負荷の均衡を実現して，高い可用性を確保できます。

EJBクライアントからのラウンドロビン方式によるグローバルCORBAネーミングサービスのルックアップと，CTMによるリクエストの振り分けによって，J2EEサーバ間の負荷均衡が実現できます。

Stateless Session Beanのスケールアウトが容易に実現できるので，アプリケーションサーバの稼働率を向上できます。

特定のJ2EEサーバにトラブルが発生した場合，CTMによってほかのJ2EEサーバにリクエストをスケジューリングすることで，システムの縮退運転ができます。また，EJBクライアントアプリケーションからは，トラブルを検知したJ2EEサーバにはアクセスされません。

リクエストの流れ

アクセスポイントであるJ2EEサーバ上のStateless Session Beanへのリクエストは，EJBクライアントからCTM経由で送られます。その際，EJBクライアントは，グローバルCORBAネーミングサービスからStateless Session BeanのEJBHomeオブジェクトリファレンスの名前をルックアップします。そのあと，リクエストはCTMによって，適切なアプリケーションサーバ上のJ2EEサーバに振り分けられます。

CTMを使用して負荷を分散する場合，グローバルCORBAネーミングサービスを独立したマシンに配置することもできます。このとき，グローバルCORBAネーミングサービスを配置したマシンを，統合ネーミングスケジューラサーバといいます。

統合ネーミングスケジューラサーバを配置したシステムの構成を次の図に示します。

図3-40　Stateless Session Beanを対象にしたCTMによる負荷分散の構成の例（統合ネーミングスケジューラサーバを配置した場合）

特徴

Stateless Session Beanの負荷の均衡を実現して，高い可用性を確保できます。

統合ネーミングスケジューラサーバのレプリカを作成して複数配置することで，ネーミングサービスの可用性を確保できます。

EJBクライアントからのラウンドロビン方式によるグローバルCORBAネーミングサービスのルックアップと，CTMによるリクエストの振り分けによって，J2EEサーバ間の負荷均衡が実現できます。

Stateless Session Beanのスケールアウトが容易に実現できるので，アプリケーションサーバの稼働率を向上できます。スケールアウト時に，EJBクライアントで定義したグローバルCORBAネーミングサービスのリストを変更する必要はありません。

特定のJ2EEサーバにトラブルが発生した場合，CTMによってほかのJ2EEサーバにリクエストをスケジューリングすることで，システムの縮退運転ができます。EJBクライアントアプリケーションからは，トラブルを検知したJ2EEサーバにはアクセスされません。

EJBクライアントは，統合ネーミングスケジューラサーバ上のグローバルCORBAネーミングサービスからStateless Session BeanのEJBHomeオブジェクトリファレンスの名前をルックアップします。そのあと，アプリケーションサーバのCTMデーモンに処理が振り分けられます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

CTMを使用して負荷を分散する場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

グローバルCORBAネーミングサービス

CTMのプロセス群（CTMデーモンおよびCTMレギュレータ）

CTMドメインマネジャ

スマートエージェント

(b)　統合ネーミングスケジューラサーバマシン

統合ネーミングスケジューラサーバを配置するシステム構成の場合，統合ネーミングスケジューラサーバマシンには，Application Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。J2EEサーバを起動する必要はありません。

グローバルCORBAネーミングサービス

CTMのプロセス群（CTMデーモン）

CTMドメインマネジャ

スマートエージェント

運用管理エージェント

PRFデーモン

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　EJBクライアントマシン

EJBクライアントマシンには，Application Server Standard，Application Server Enterprise，またはuCosminexus Client（Windowsの場合）をインストールする必要があります。

起動するプロセスはEJBクライアントアプリケーションのプロセスです。

3.8　サーバ間で非同期通信をする場合の構成を検討する

この節では，サーバ間でMessage-driven Beanを使用して非同期通信をする場合のシステム構成について説明します。アクセスポイントはMessage-driven Beanになります。

Message-driven Beanを使って非同期通信をするシステム構成としては，TP1/Message Queueを使用するシステム構成と，Cosminexus RMを使用するシステム構成があります。Cosminexus RMは，Application Serverの構成ソフトウェアです。なお，Cosminexus RMを使用したシステムでは，Message-driven Beanのインスタンスプールを使用した負荷分散はできません。

＜この節の構成＞

3.8.1　Message-driven Beanをアクセスポイントに使用する場合の構成（TP1/Message Queueを使用する場合）

3.8.2　Message-driven Beanをアクセスポイントに使用する場合の構成（Cosminexus RMを使用する場合）

3.8.3　Message-driven Beanのインスタンスプールを利用した負荷分散（TP1/Message Queueを使用する場合）

3.8.1　Message-driven Beanをアクセスポイントに使用する場合の構成（TP1/Message Queueを使用する場合）

ここでは，クライアントとして，TP1/Message Queueが動作しているMessage Queueサーバを使用する場合の構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

最も基本的なメッセージ駆動型のシステムの一つです。

TP1/Message Queueを使用する場合のメッセージ駆動型のシステム構成の例を次の図に示します。

図3-41　メッセージ駆動型のシステム構成の例（TP1/Message Queueを使用する場合）

特徴

クライアントに，TP1/Message Queueにメッセージを送信するMessage QueueクライアントアプリケーションとTP1/Message Queueを使用します。なお，Message Queueクライアントアプリケーションとは，JMSインタフェースを使用するJ2EEアプリケーションです。

リクエストの流れ

アクセスポイントであるMessage-driven Beanは，サーバ側のアプリケーションサーバのJ2EEサーバ上で動作します。リソースアダプタであるTP1/Message Queue - Accessのライブラリは，サーバ側のアプリケーションサーバのJ2EEサーバ，およびクライアント側のアプリケーションサーバのJ2EEサーバ上で動作します。

クライアント側のアプリケーションサーバのJ2EEアプリケーションからのリクエスト（メッセージ）は，TP1/Message Queue経由で送られ，サーバ側のアプリケーションサーバ上のMessage-driven Beanを呼び出します。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースに接続するためのプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　アプリケーションサーバマシン（サーバ側のアプリケーションサーバマシン）

アプリケーションサーバマシン（サーバ側のアプリケーションサーバマシン）には，Application Server StandardまたはApplication Server Enterprise，およびTP1/Message Queue - Accessをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　Message Queueサーバマシン

Message Queueサーバマシンには，TP1/Message Queueをインストールする必要があります。

起動する必要があるプロセスは，TP1/Message Queueのプロセスです。

(c)　アプリケーションサーバマシン（クライアント側のアプリケーションサーバマシン）

クライアントマシン（クライアント側のアプリケーションサーバマシン）には，Application Server StandardまたはApplication Server Enterprise，およびTP1/Message Queue - Accessをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(d)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.8.2　Message-driven Beanをアクセスポイントに使用する場合の構成（Cosminexus RMを使用する場合）

ここでは，クライアントとして，Cosminexus RMと連携しているデータベース（HiRDBまたはOracle）を使用する場合の構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

最も基本的なメッセージ駆動型のシステムの一つです。

Cosminexus RMを使用する場合のメッセージ駆動型のシステム構成の例を次の図に示します。

図3-42　メッセージ駆動型のシステム構成の例（Cosminexus RMを使用する場合）

特徴

クライアントに，Cosminexus RMにメッセージを送信するCosminexus RMのクライアントアプリケーションとデータベースサーバを使用します。なお，Cosminexus RMクライアントアプリケーションとは，JMSインタフェースを使用するJ2EEアプリケーションです。

リクエストの流れ

アクセスポイントであるMessage-driven Beanは，サーバ側のアプリケーションサーバのJ2EEサーバ上で動作します。リソースアダプタであるCosminexus RMのライブラリは，サーバ側のアプリケーションサーバのJ2EEサーバ上，およびクライアント側のアプリケーションサーバのJ2EEサーバ上で動作します。

クライアント側のアプリケーションサーバのJ2EEアプリケーションからのリクエスト（メッセージ）はデータベース上に実現されたキュー経由で送られ，サーバ側のアプリケーションサーバ上のMessage-driven Beanを呼び出します。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。なお，リソースに接続するためのプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　サーバ側のアプリケーションサーバマシン

サーバ側のアプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(b)　データベースサーバマシン

データベースサーバマシンには，HiRDBまたはOracleをインストールする必要があります。

起動する必要があるプロセスは，HiRDBまたはOracleのプロセスです。

(c)　クライアントマシン（クライアント側のアプリケーションサーバマシン）

クライアントマシン（クライアント側のアプリケーションサーバマシン）には，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

J2EEサーバ

運用管理エージェント

PRFデーモン

(d)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.8.3　Message-driven Beanのインスタンスプールを利用した負荷分散（TP1/Message Queueを使用する場合）

アクセスポイントになるコンポーネントがMessage-driven Beanの場合に，J2EEサーバごとのMessage-driven Beanのインスタンスのプール数に応じて負荷を分散する構成について説明します。

なお，この構成によって負荷を分散できるのは，TP1/Message Queueを使用してMessage-driven Beanにアクセスする場合だけです。Cosminexus RMを使用してMessage-driven Beanにアクセスする場合は，Message-driven Beanのインスタンスプールを利用した負荷分散はできません。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントがMessage-driven Beanである，メッセージ駆動型のシステムで使用できる構成です。Message QueueクライアントからのメッセージがMessage Queueサーバ上のTP1/Message Queueのキューに到着すると，J2EEサーバ上でプールされているMessage-driven Beanのインスタンス数に応じて，Message-driven Beanが呼び出されます。

Message-driven Beanを対象にした負荷分散の構成の例を次の図に示します。

図3-43　Message-driven Beanを対象にした負荷分散の構成の例

特徴

Message-driven Beanの負荷分散を実現して，高い可用性を確保できます。

アプリケーションサーバを複数用意することで，アプリケーションサーバの負荷を分散できます。

サーバ側のアプリケーションサーバで障害が発生した場合やアプリケーションサーバのメンテナンスが必要な場合，TP1/Message Queueから該当するアプリケーションサーバ上のJ2EEサーバにはアクセスしません。このため，縮退運転ができます。

リクエストの流れ

アクセスポイントであるサーバ側のアプリケーションサーバのJ2EEサーバ上のMessage-driven Beanへのリクエスト（メッセージ）は，クライアント側のアプリケーションサーバのJ2EEサーバ上で動作するJ2EEアプリケーションから，TP1/Message Queue経由で送られます。TP1/Message Queueにメッセージが到着すると，サーバ側のアプリケーションサーバのJ2EEサーバ上のMessage-driven Beanが呼び出されます。その際，Message-driven Beanのインスタンスプールのプール数に応じて，リクエストが振り分けられます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

Message-driven Beanのインスタンスプールを使用して負荷を分散する場合に必要なソフトウェアと起動するプロセスは，Message-driven Beanをアクセスポイントにする構成と同じです。「3.8.1　Message-driven Beanをアクセスポイントに使用する場合の構成（TP1/Message Queueを使用する場合）」を参照してください。

3.9　運用管理プロセスの配置を検討する

この節では，運用管理に使用するプロセスである，Management Serverの配置について説明します。

ここでは，次の構成を説明します。

運用管理サーバにManagement Serverを配置する構成（運用管理サーバモデル）

マシン単位にManagement Serverを配置する構成（ホスト単位管理モデル）

コマンドを使用して運用する構成

なお，運用管理サーバモデルでManagement Serverを配置したマシンを，運用管理サーバといいます。

＜この節の構成＞

3.9.1　運用管理サーバにManagement Serverを配置する構成

3.9.2　マシン単位にManagement Serverを配置する構成

3.9.3　コマンドで運用する場合の構成

3.9.1　運用管理サーバにManagement Serverを配置する構成

Management Serverを利用して運用する場合に，ドメイン内に一つ運用管理サーバを配置する構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンで起動するプロセス

(1)　システム構成の特徴

複数のアプリケーションサーバで構成されるシステムで，ドメイン内に運用管理サーバマシンを配置する構成です。Management Serverであらかじめ定義したドメイン（運用管理ドメイン）内の運用管理および監視が実現できます。運用管理サーバマシンのManagement Serverは，それぞれのアプリケーションサーバに配置した運用管理エージェントと協調して，運用管理操作を実行します。

運用管理サーバにManagement Serverを配置する構成の例を次の図に示します。なお，この例では，接続するリソースマネジャについては省略しています。

図3-44　運用管理サーバにManagement Serverを配置する構成の例

特徴

システムの一括運用に適しています。

独立した運用管理サーバ用のマシンを用意することをお勧めします。ただし，システム内の一つのアプリケーションサーバ内にManagement Serverを配置することもできます。

(2)　それぞれのマシンで起動するプロセス

運用管理サーバにManagement Serverを配置する構成の場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

ポイント

運用管理サーバマシンを用意できないときは，ドメイン内のどれかのアプリケーションサーバが運用管理サーバを兼ねるシステム構成にもできます。

この場合は，運用管理サーバにするアプリケーションサーバマシンに，Management Serverのプロセスを配置してください。

(b)　アプリケーションサーバマシン

運用管理サーバで運用管理するために，それぞれのアプリケーションサーバマシンで起動するプロセスは次のとおりです。

運用管理エージェント

これ以外にアプリケーションサーバマシンに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

3.9.2　マシン単位にManagement Serverを配置する構成

Management Serverを利用して運用する場合に，それぞれのアプリケーションサーバマシンにManagement Serverを配置する構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

複数のアプリケーションサーバで構成されるシステムで，Management Serverをそれぞれのアプリケーションサーバマシンに配置する構成です。アプリケーションサーバ単位の運用管理および監視が実行できます。Management Serverは，運用管理エージェントと協調して，運用管理操作を実行します。

マシン単位にManagement Serverを配置する構成の例を次の図に示します。なお，この例では，接続するリソースマネジャについては省略しています。

図3-45　マシン単位にManagement Serverを配置する構成の例

特徴

アプリケーションサーバ単位の運用に適しています。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

マシン単位にManagement Serverを配置する構成の場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン

マシン単位の運用管理をするためにそれぞれのアプリケーションサーバマシンで起動するプロセスは次のとおりです。

Management Server

運用管理エージェント

これ以外にアプリケーションサーバマシンに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

3.9.3　コマンドで運用する場合の構成

Management Serverを利用しないで運用する場合の構成について説明します。

Management Serverを利用しない場合は，定義ファイルの編集や，サーバ管理コマンドの実行などによって，アプリケーションサーバを運用します。このとき，それぞれのアプリケーションサーバに，運用管理エージェントおよびManagement Serverは不要です。Cosminexus以外の運用支援ソフトウェアなどを使用してシステムを管理する場合に，この構成を検討してください。

3.10　SFOサーバを使用したセッション情報の引き継ぎを検討する

この節では，SFOサーバを使用してセッション情報の引き継ぎを実現するためのシステム構成について説明します。

この構成は，J2EEサーバが負荷分散機によって冗長化されていることが前提です。

SFOサーバは，システムに一つまたは複数配置できます。SFOサーバにトラブルが発生した場合の影響範囲を小さくするために，一つのJ2EEアプリケーションに対して一つのSFOサーバを配置することをお勧めします。

＜この節の構成＞

3.10.1　SFOサーバがシステムに複数存在する構成

3.10.2　SFOサーバがシステムに一つだけ存在する構成

3.10.1　SFOサーバがシステムに複数存在する構成

SFOサーバがシステムに複数存在する構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンで起動するプロセス

(1)　システム構成の特徴

J2EEサーバ上で動作するJ2EEアプリケーションごとに，SFOサーバを用意します。J2EEアプリケーションとSFOサーバを1:1にすることをお勧めします。これによって，SFOサーバにトラブルが発生した場合の影響を最小限に抑えられます。これに対して，複数のJ2EEアプリケーションに対して一つのSFOサーバを配置した場合，SFOサーバにトラブルが発生したときには，そのSFOサーバに対応するすべてのJ2EEアプリケーションのセッション情報が引き継げなくなります。

SFOサーバ上では，SFOサーバアプリケーションが動作しています。

システムに複数のSFOサーバが存在する場合の構成の例を次の図に示します。この例では，SFOサーバはJ2EEサーバと異なるマシン上に配置されています。この構成の場合，SFOサーバを配置したマシンを，セッションフェイルオーバサーバといいます。

図3-46　SFOサーバがシステムに複数存在する構成の例

特徴

特定のJ2EEサーバでトラブルが発生した場合に，セッション情報をほかのJ2EEサーバに引き継げます。

SFOサーバにトラブルが発生した場合も，対応するJ2EEアプリケーションだけに影響範囲を抑えられます。

リクエストの流れ

SFOサーバでは，J2EEサーバ上のグローバルセッション情報が冗長化されて管理されています。

J2EEサーバがリクエストを受け付けてセッションが確立された時点で，J2EEサーバ上のセッションフェイルオーバ用フィルタによってSFOサーバ上のグローバルセッション情報にロックが掛けられます。J2EEアプリケーションの処理が完了すると，J2EEサーバ上のグローバルセッション情報の内容に合わせてSFOサーバ上のグローバルセッション情報が更新されます。そのあとで，セッションフェイルオーバ用フィルタによってSFOサーバ上のグローバルセッション情報のロックが解除されます。

J2EEサーバにトラブルが発生した場合は，別なJ2EEサーバからSFOサーバ上のグローバルセッション情報が取得され，セッション情報が引き継がれます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン

セッションフェイルオーバ機能を使用する場合に必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(b)　セッションフェイルオーバサーバマシン

セッションフェイルオーバサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

SFOサーバ

運用管理エージェント

PRFデーモン

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

3.10.2　SFOサーバがシステムに一つだけ存在する構成

SFOサーバがシステムに一つだけ存在する構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンで起動するプロセス

(1)　システム構成の特徴

J2EEサーバ上で動作する複数のJ2EEアプリケーションに対して，一つのSFOサーバを用意します。

SFOサーバ上では，SFOサーバアプリケーションが動作しています。

システムにSFOサーバが一つだけ存在する場合の構成の例を次の図に示します。なお，この例では，SFOサーバはJ2EEサーバと異なるマシン上に配置されています。

図3-47　SFOサーバがシステムに一つだけ存在する構成の例（セッションフェイルオーバサーバを配置した場合）

特徴

特定のJ2EEサーバでトラブルが発生した場合に，セッション情報をほかのJ2EEサーバに引き継げます。

SFOサーバにトラブルが発生した場合は，システム上のすべてのJ2EEアプリケーションでセッション情報が引き継げなくなります。

リクエストの流れ

SFOサーバでは，J2EEサーバ上のグローバルセッション情報が冗長化されて管理されています。

J2EEサーバがリクエストを受け付けてセッションが確立された時点で，J2EEサーバ上のセッションフェイルオーバ用フィルタによってSFOサーバ上のグローバルセッション情報にロックが掛けられます。J2EEアプリケーションの処理が完了すると，J2EEサーバ上のグローバルセッション情報の内容に合わせてSFOサーバ上のグローバルセッション情報が更新されます。そのあとで，セッションフェイルオーバ用フィルタによってSFOサーバ上のグローバルセッション情報のロックが解除されます。

J2EEサーバにトラブルが発生した場合は，別なJ2EEサーバからSFOサーバ上のグローバルセッション情報が取得され，セッション情報が引き継がれます。

なお，SFOサーバは，J2EEサーバと同じマシンにも配置できます。

SFOサーバをJ2EEサーバと同じマシンに配置する構成の例を次の図に示します。

図3-48　SFOサーバをJ2EEサーバと同じマシンに配置する構成の例

特徴およびリクエストの流れについては，別なマシンとしてセッションフェイルオーバサーバを配置する場合と同様です。

注意

この構成の場合，J2EEサーバのプロセス障害には対応できますが，アプリケーションサーバ1でハードウェア障害が発生した場合には対応できません。アプリケーションサーバで発生するハードウェア障害に対応するためには，SFOサーバを別のマシンに配置してください。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン

セッションフェイルオーバ機能を使用する場合に必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

なお，SFOサーバをJ2EEサーバと同じマシンに配置する場合は，次のプロセスを起動してください。

SFOサーバ

(b)　セッションフェイルオーバサーバマシン

セッションフェイルオーバサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

SFOサーバ

運用管理エージェント

PRFデーモン

なお，SFOサーバをJ2EEサーバと同じマシンに配置する場合は，このマシンは不要です。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

3.11　クラスタソフトウェアを使用した障害時の系切り替えを検討する

この節では，クラスタソフトウェアを使用した障害時の系切り替えを実現するためのシステム構成について説明します。

Cosminexusのシステムでは，OSごとに，次のクラスタソフトウェアを使用できます。

Windowsの場合
Microsoft Cluster Service

AIX，HP-UXまたはLinuxの場合
HAモニタ

Solarisの場合
クラスタソフトウェアと連携したシステム運用はできません。

Cosminexusで構築するシステムでは，クラスタソフトウェアを使用して，次に示す構成を実現できます。なお，これらの構成は，Management Serverを利用して運用することが前提になります。

アプリケーションサーバの実行系と待機系を1:1にする構成
実行系のアプリケーションサーバマシン1台に対して待機系のアプリケーションサーバマシンを1台用意しておく構成です。実行系のアプリケーションサーバマシンにトラブルが発生してマシンが終了した場合，または運用管理エージェントが終了した場合に，クラスタソフトウェアによって待機系のアプリケーションサーバを起動して処理を切り替えます。トランザクションサービスを使用しない場合と使用する場合で，共有ディスク装置の要否が異なります。なお，Microsoft Cluster Serviceを使用する場合は，トランザクションサービスを使用しない場合も，共有ディスク装置が必要です。

運用管理サーバの実行系と待機系を1:1にする構成
実行系の運用管理サーバマシン1台に対して待機系の運用管理サーバマシンを1台用意しておく構成です。実行系の運用管理サーバマシンにトラブルが発生してマシンが終了した場合，またはManagement Serverのプロセスが終了した場合に，クラスタソフトウェアによって待機系の運用管理サーバを起動して処理を切り替えます。

アプリケーションサーバの実行系と待機系を相互スタンバイにする構成
アプリケーションサーバの実行系と待機系を1：1にする構成の一つです。それぞれのアプリケーションサーバに同じ種類のJ2EEサーバを配置して，異なるJ2EEサーバを起動しておくことで，それぞれのアプリケーションサーバが実行系として動作しながらお互いの待機系として機能します。どちらか一方の系に障害が発生すると，もう一方の系に切り替えられます。これによって，少ない台数のアプリケーションサーバマシンで，むだの少ない運用が可能になります。
この構成では，それぞれのアプリケーションサーバマシンでManagement Serverを起動して，それぞれに異なる運用管理ドメインを管理します。

N台の実行系に対して1台の待機系を用意する構成（リカバリ専用サーバを使用する構成）
この構成は，J2EEサーバを冗長化した構成でグローバルトランザクションを使用する場合に，特定のJ2EEサーバにトラブルが発生したときにトランザクションを決着するためのシステム構成です。
N台のJ2EEサーバを冗長化するためには，負荷分散機などを使用します。

＜この節の構成＞

3.11.1　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合）

3.11.2　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用する場合）

3.11.3　運用管理サーバの実行系と待機系を1:1にする構成

3.11.4　アプリケーションサーバの実行系と待機系を相互スタンバイにする構成

3.11.5　リカバリ専用サーバを使用する場合の構成（N:1リカバリシステム）

3.11.1　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合）

アプリケーションサーバの実行系と待機系を1:1にする構成の場合に，トランザクションサービスを使用しないときの構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンで起動するプロセス

(1)　システム構成の特徴

ローカルトランザクションを使用する場合など，トランザクションサービスを使用しない場合のシステム構成です。

なお，ここでは，アプリケーションサーバを系切り替えする場合の構成を示します。運用管理サーバを系切り替えする場合の構成については，「3.11.3　運用管理サーバの実行系と待機系を1:1にする構成」を参照してください。

トランザクションサービスを使用しない場合の構成の例を次の図に示します。

図3-49　クラスタソフトウェアを使用して実行系と待機系を1:1にする場合のシステム構成の例（トランザクションサービスを使用しない場合）

特徴

実行系と待機系は1：1で構成します。

HAモニタを使用する場合は，共有ディスク装置は不要です。Microsoft Cluster Serviceを使用する場合は，共有ディスク装置が必要です。図3-49は，HAモニタの場合の構成です。

データベースがクラスタ構成になっている場合でも，アプリケーションサーバでは仮想アドレス（論理アドレス）だけを認識していれば，接続できます。

Management Serverをアプリケーションサーバと同じマシンに配置する場合については，「3.11.3　運用管理サーバの実行系と待機系を1:1にする構成」を参照してください。

リクエストの流れ

クライアントからは，実行系，待機系のアプリケーションサーバは，合わせて1台として認識されます。リクエストは，すべて実行系のアプリケーションサーバに送信されます。

系切り替えの流れ

実行系のアプリケーションサーバマシンに障害が発生すると，系切り替えが実行されます。系切り替えは，OS，または運用管理エージェントがダウンした場合に実行されます。なお，このほか，明示的に系切り替えを実行するコマンドを実行した場合や，これ以外にクラスタソフトウェアが系切り替えの対象にしている事象が発生した場合も，系切り替えが実行されます。

系切り替えが実行されると，待機系のアプリケーションサーバの運用管理エージェント，およびそれまで停止していたプロセスが起動されます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン（実行系）

クラスタソフトウェアを使用する場合に必ず起動するプロセスは次のとおりです。

運用管理エージェント

これ以外にアプリケーションサーバに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(b)　アプリケーションサーバマシン（待機系）

待機系のアプリケーションサーバマシンにインストールするソフトウェアの構成は，実行系と一致させてください。ただし，系切り替えが発生するまで，プロセスは起動しません。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　クライアントマシン

クライアントマシンには，次のソフトウェアをインストールしてください。

Webクライアント構成の場合

Webブラウザ

EJBクライアント構成の場合

uCosminexus Client（Windowsの場合），Application Server StandardまたはApplication Server Enterprise

3.11.2　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用する場合）

アプリケーションサーバの実行系と待機系を1:1にする構成の場合に，トランザクションサービスを使用するときの構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンで起動するプロセス

(1)　システム構成の特徴

グローバルトランザクションを使用する場合など，トランザクションサービスを使用する場合のシステム構成です。この場合，共有ディスク装置が必要です。

なお，ここでは，アプリケーションサーバを系切り替えする場合の構成を示します。運用管理サーバを系切り替えする場合の構成については，「3.11.3　運用管理サーバの実行系と待機系を1：1にする構成」を参照してください。

トランザクションサービスを使用する場合の構成の例を次の図に示します。

図3-50　クラスタソフトウェアを使用してアプリケーションサーバの実行系と待機系を1:1にする場合のシステム構成の例（トランザクションサービスを使用する場合）

特徴

実行系と待機系は1：1で構成します。

共有ディスク装置が必要です。

データベースがクラスタ構成になっている場合でも，アプリケーションサーバでは仮想アドレス（論理アドレス）だけを認識していれば，接続できます。

Management Serverをアプリケーションサーバと同じマシンに配置する場合については，「3.11.3　運用管理サーバの実行系と待機系を1:1にする構成」を参照してください。

リクエストの流れ

クライアントからは，実行系，待機系のアプリケーションサーバは，合わせて1台として認識されます。リクエストは，すべて実行系のアプリケーションサーバに送信されます。

系切り替えの流れ

実行系のアプリケーションサーバマシンに障害が発生すると，系切り替えが実行されます。系切り替えは，OS，または運用管理エージェントがダウンした場合に実行されます。なお，このほか，明示的に系切り替えを実行するコマンドを実行した場合や，これ以外にクラスタソフトウェアが系切り替えの対象にしている事象が発生した場合も，系切り替えが実行されます。

系切り替えが実行されると，待機系のアプリケーションサーバの運用管理エージェント，およびそれまで停止していたプロセスが起動されます。なお，トランザクション情報については，共有ディスクに格納されていた情報が引き継がれます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスは，トランザクションサービスを利用しない場合と同じです。

3.11.3　運用管理サーバの実行系と待機系を1:1にする構成

運用管理サーバを系切り替えの対象にする場合の構成について説明します。運用管理サーバの実行系と待機系を1：1にします。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンで起動するプロセス

(1)　システム構成の特徴

運用管理サーバの実行系と待機系を1：1にする場合の構成の例を次に示します。なお，この例は，運用管理サーバをアプリケーションサーバとは別のマシンとして構築していますが，アプリケーションサーバと同じマシンにManagement Serverを配置している場合も，同じように系切り替えができます。この場合は，Management Serverと論理サーバを同じ系に含めます。

図3-51　クラスタソフトウェアを使用して運用管理サーバの実行系と待機系を1:1にする場合のシステム構成の例

特徴

実行系と待機系は1：1で構成します。それぞれのマシンにManagement Serverを配置します。

Microsoft Cluster Serviceを使用する場合は，共有ディスク装置が必要です。

系切り替えの流れ

実行系の運用管理サーバマシンに障害が発生すると，系切り替えが実行されます。系切り替えは，OS，またはManagement Serverがダウンした場合に実行されます。なお，このほか，明示的に系切り替えを実行するコマンドを実行した場合や，これ以外にクラスタソフトウェアが系切り替えの対象にしている事象が発生した場合も，系切り替えが実行されます。

系切り替えが実行されると，待機系の運用管理サーバの運用管理エージェントおよびManagement Serverのプロセスが起動されます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(b)　運用管理サーバマシン（実行系）

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(c)　運用管理サーバマシン（待機系）

待機系のアプリケーションサーバマシンにインストールするソフトウェアの構成は，実行系と一致させてください。ただし，系切り替えが発生するまで，プロセスは起動しません。

(d)　クライアントマシン

クライアントマシンには，次のソフトウェアをインストールしてください。

Webクライアント構成の場合

Webブラウザ

EJBクライアント構成の場合

uCosminexus Client（Windowsの場合），Application Server StandardまたはApplication Server Enterprise

3.11.4　アプリケーションサーバの実行系と待機系を相互スタンバイにする構成

アプリケーションサーバの実行系と待機系を1：1にする構成で，それぞれのアプリケーションサーバを実行系として稼働させながら，お互いの待機系にする構成について説明します。この構成を，相互スタンバイ構成といいます。また，この構成で構築されたシステムを，相互系切り替えシステムといいます。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンで起動するプロセス

(1)　システム構成の特徴

この構成は，実行系のアプリケーションサーバマシン1台に対して待機系のアプリケーションサーバマシンを1台用意しておく構成の一つです。ただし，待機系のアプリケーションサーバを停止させておくのではなく，実行系とは異なるJ2EEサーバを動作させておきます。これを，相互スタンバイといいます。

それぞれのアプリケーションサーバに同じ種類のJ2EEサーバを配置して，異なるJ2EEサーバを起動しておくことで，それぞれのアプリケーションサーバが現用系として動作しながらお互いの予備系として機能します。どちらかのマシンに障害が発生した場合は，系が切り替えられ，もう片方のアプリケーションサーバマシンで両方のJ2EEサーバの処理が実行されるようになります。

この構成は，次のことが前提になります。

CORBAネーミングサービスはインプロセスで起動されていること

グローバルトランザクションを使用する場合，トランザクションのステータスファイルは共有ディスクに格納されていること

Management Serverを利用して運用していること

Management Serverは，アプリケーションサーバと同じマシンに，一つずつ配置して，両方のホストで起動します。それぞれのManagement Serverは，別の運用管理ドメインを管理します。それぞれの運用管理ドメインの範囲は，Management Serverが配置されているアプリケーションサーバマシン内です。

相互系切り替えシステムの構成の例を次の図に示します。この例は，トランザクションサービスを使用する例です。共有ディスクは，トランザクションサービスを使用する場合にだけ必要です。

図3-52　相互系切り替えシステムの構成の例（トランザクションサービスを使用する場合）

特徴

実行系と待機系は1：1で構成します。それぞれのマシンにManagement Serverを配置します。

一つの運用管理ドメイン（一つのマシン）内に，二つの仮想ホストを定義します。それぞれの仮想ホストを，実行系のアプリケーションサーバのホスト，待機系のアプリケーションサーバのホストとして，システムを構築します。

運用管理ドメイン内のそれぞれの仮想ホストは，一つの運用管理エージェントで起動・停止を制御されます。ただし，それぞれの仮想ホストには実際に運用に使用されるIPアドレスとは異なるIPアドレスが割り当てられているため，見かけ上異なるホスト上で動作しているように定義されています。

各アプリケーションサーバの運用に使用するIPアドレスは，クラスタソフトウェアによって動的に割り当てられるIPアドレスを使用します。Management Serverから運用管理エージェントに対するリクエストの送信には，系切り替えによって他系へ移動しないIPアドレスを使用します。

グローバルトランザクションを使用する場合は，共有ディスク装置が必要です。共有ディスクは，仮想ホストごとに必要です。

図3-52の場合，仮想ホスト単位にLANを分けていますが，必須ではありません。

系切り替えの流れ

どちらかのアプリケーションサーバマシンに障害が発生すると，系切り替えが実行されます。系切り替えは，OS，または運用管理エージェントに障害が発生した場合に実行されます。なお，このほか，明示的に系切り替えを実行するコマンドを実行した場合や，これ以外にクラスタソフトウェアが系切り替えの対象にしている事象が発生した場合も，系切り替えが実行されます。

系切り替えが実行されると，待機系だった側のアプリケーションサーバマシンの運用管理エージェントによって，それまで停止していた論理サーバのプロセスが起動されます。

例えば，図3-52の場合に，アプリケーションサーバ1に障害が発生した場合は，クラスタソフトウェアによってアプリケーションサーバ2への系切り替えが実行され，アプリケーションサーバ2の運用管理エージェントによって，アプリケーションサーバ2上のJ2EEサーバ1およびそれ以外の論理サーバのプロセスが起動されます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン（実行系1／待機系2）

アプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

相互系切り替えシステムのアプリケーションサーバマシンで必ず起動するプロセスは次のとおりです。

運用管理エージェント

Management Server

これ以外にアプリケーションサーバに必要なソフトウェアおよびプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

なお，系切り替えの対象になるプロセスは，仮想ホスト1のプロセスだけを起動してください。

(b)　アプリケーションサーバマシン（待機系1／実行系2）

待機系のアプリケーションサーバマシンにインストールするソフトウェアおよびプロセスの構成は，実行系1／待機系2と一致させてください。

なお，系切り替えの対象になるプロセスは，仮想ホスト2のプロセスだけを起動してください。

(c)　クライアントマシン

クライアントマシンには，次のソフトウェアをインストールしてください。

Webクライアント構成の場合

Webブラウザ

EJBクライアント構成の場合

uCosminexus Client（Windowsの場合），Application Server StandardまたはApplication Server Enterprise

3.11.5　リカバリ専用サーバを使用する場合の構成（N:1リカバリシステム）

N台の実行系に対して1台の待機系（リカバリ専用サーバ）を用意する構成について説明します。この構成を，N:1リカバリシステムといいます。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンで起動するプロセス

(1)　システム構成の特徴

この構成は，J2EEサーバを冗長化した構成でグローバルトランザクションを使用する場合に，特定のJ2EEサーバにトラブルが発生したときにトランザクションを解決してリソースを解放するためのシステム構成です。N台のJ2EEサーバを冗長化するためには，負荷分散機などを使用します。

次のことが前提になります。

グローバルトランザクションを使用するシステムで利用されること

CORBAネーミングサービスはインプロセスで起動されていること

トランザクションのステータスファイルは共有ディスクに格納されていること

Management Serverを利用して運用していること

なお，N:1リカバリシステムで系切り替えの対象になるのは，アプリケーションサーバです。

また，N:1リカバリシステムを構成する場合，実行系で使用するリソースアダプタが，待機系にも必要です。ここでは，リソースアダプタの配置とシステム構成の関係について，次の3種類の構成を例として説明します。

N台の実行系マシンで，J2EEアプリケーションとリソースアダプタの構成がすべて同じ場合

N台の実行系マシンで，J2EEアプリケーションの構成は異なり，リソースアダプタはすべて同一の場合

N台の実行系マシンで，J2EEアプリケーションとリソースアダプタの構成がすべて異なる場合

次にそれぞれの構成の例を示します。

図3-53　N:1リカバリシステムのシステム構成の例（N台の実行系マシンで，J2EEアプリケーションとリソースアダプタの構成がすべて同じ場合）

図3-54　N:1リカバリシステムのシステム構成の例（N台の実行系マシンで，J2EEアプリケーションの構成は異なり，リソースアダプタはすべて同一の場合）

図3-55　N:1リカバリシステムのシステム構成の例（N台の実行系マシンで，J2EEアプリケーションとリソースアダプタの構成がすべて異なる場合）

特徴

実行系と待機系はN：1で構成します。

共有ディスク装置が必要です。共有ディスク装置には実行系の個数（N個）分のボリュームグループが必要です。

CORBAネーミングサービスはインプロセスで起動します。

待機系には，実行系と同じリソースアダプタが必要です。実行系のJ2EEサーバごとに異なるリソースアダプタがインポートされている場合，待機系のJ2EEサーバにはそれらすべてをインポートする必要があります。
なお，待機系のJ2EEサーバにJ2EEアプリケーションは不要です。

データベースがクラスタ構成になっている場合でも，アプリケーションサーバでは仮想アドレス（論理アドレス）だけを認識していれば，接続できます。

系切り替えの流れ

実行系のアプリケーションサーバで起動されているJ2EEサーバのうち，どれかのJ2EEサーバにトラブルが発生すると，クラスタソフトウェアによってリカバリ専用サーバのJ2EEサーバが起動され，トラブルが発生したJ2EEサーバが使用していたトランザクションが決着されます。そのあとで，トラブルが発生したJ2EEサーバマシンのクラスタソフトウェアと，それに対応する待機系のクラスタサービスが停止されます。

(2)　それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　アプリケーションサーバマシン（実行系）

実行系のアプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

クラスタソフトウェアを使用する場合に必ず起動するプロセスは次のとおりです。

運用管理エージェント

これ以外にアプリケーションサーバに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(b)　アプリケーションサーバマシン（待機系）

待機系のアプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

また，実行系のアプリケーションサーバマシン上のJ2EEサーバにインポートされているすべてのリソースアダプタをインポートしてください。

なお，待機系のアプリケーションサーバマシンは，コールドスタンバイの状態になります。

系切り替えが発生するまで，プロセスは起動しません。系切り替えが発生すると，J2EEサーバのプロセスが，リカバリモードで起動されます。

(c)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

(d)　クライアントマシン

クライアントマシンには，次のソフトウェアをインストールしてください。

Webクライアント構成の場合

Webブラウザ

EJBクライアント構成の場合

uCosminexus Client（Windowsの場合），Application Server StandardまたはApplication Server Enterprise

3.12　ファイアウォールを使用する構成を検討する

この節では，ファイアウォールを使用して，セキュリティを確保するための構成について説明します。

なお，ここでは，アクセスポイントになるコンポーネントの種類に応じたファイアウォールの配置位置について説明します。このほかのセキュリティの考え方については，「5.　セキュアなシステムの検討」を参照してください。

＜この節の構成＞

3.12.1　サーブレットとJSPに対するファイアウォールの配置

3.12.2　Session BeanとEntity Beanに対するファイアウォールの配置

3.12.3　リソースマネジャに対するファイアウォールの配置

3.12.1　サーブレットとJSPに対するファイアウォールの配置

サーブレットとJSPに対するアクセスをファイアウォール経由にする構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

Webクライアント側から見たサーブレットとJSPの手前に，ファイアウォールを配置します。

サーブレットとJSPに対するアクセスをファイアウォール経由にする構成の例を次の図に示します。なお，この図は，Webサーバ連携の場合の例です。

図3-56　サーブレットとJSPに対するアクセスをファイアウォール経由にする構成

特徴

サーブレットとJSPに対するアクセスをファイアウォール経由にすることで，システムへの第三者の不正侵入，アプリケーションで扱うデータの漏洩，および第三者による不正な運用を防ぎます。

クライアントからのアクセスの流れ

サーブレットとJSPに対するクライアントからのアクセスは，すべてファイアウォール経由で実行されます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

ファイアウォールを使用する場合にアプリケーションサーバマシンおよびクライアントマシンに必要なソフトウェアと起動するプロセスは，サーブレットとJSPをアクセスポイントにする構成と同じです。「3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）」または「3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（インプロセスHTTPサーバを使用する場合）」を参照してください。

3.12.2　Session BeanとEntity Beanに対するファイアウォールの配置

Session BeanとEntity Beanに対するアクセスをファイアウォール経由にする構成です。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

EJBクライアント側から見たSession BeanとEntity Beanの手前に，ファイアウォールを配置します。

Session BeanとEntity Beanに対するアクセスをファイアウォール経由にする構成の例を次の図に示します。

図3-57　Session BeanとEntity Beanに対するアクセスをファイアウォール経由にする構成

特徴

Session BeanとEntity Beanに対するアクセスをファイアウォール経由にすることで，システムへの第三者の不正侵入，アプリケーションで扱うデータの漏洩，および第三者による不正な運用を防ぎます。

クライアントからのアクセスの流れ

Session BeanとEntity Beanに対するEJBクライアントからのアクセスは，すべてファイアウォール経由で実行されます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

ファイアウォールを使用する場合にアプリケーションサーバマシンおよびクライアントマシンに必要なソフトウェアと起動するプロセスは，Session BeanとEntity Beanをアクセスポイントにする構成と同じです。「3.4.3　Session BeanとEntity Beanをアクセスポイントに使用する構成」を参照してください。

3.12.3　リソースマネジャに対するファイアウォールの配置

リソースマネジャに対するアクセスをファイアウォール経由にする構成です。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

アプリケーション側から見たリソースマネジャの手前に，ファイアウォールを配置します。

リソースマネジャに対するアクセスをファイアウォール経由にする構成の例を次の図に示します。

図3-58　リソースマネジャに対するアクセスをファイアウォール経由にする構成

特徴

リソースマネジャに対するアクセスをファイアウォール経由にすることで，システムへの第三者の不正侵入，リソースマネジャで管理するデータの漏洩，および第三者による不正な運用を防ぎます。

クライアントからのアクセスの流れ

クライアントマシン上のWebブラウザからのリクエストは，Webサーバ経由でサーブレットとJSPに送信されます。サーブレットとJSPは，ローカルでSession Beanを呼び出します。Session Beanからデータベースへのアクセスが，ファイアウォール経由になります。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

トランザクションの使用方法に応じたソフトウェアとプロセスを起動してください。詳細は，「3.6　トランザクションの種類を検討する」を参照してください。

3.13　DMZへのリバースプロキシの配置を検討する

この節では，DMZにリバースプロキシを配置してセキュリティを確保するための構成について説明します。

インターネットに接続するシステムの場合，ここで説明する構成を基に，リバースプロキシを配置する構成を検討してください。

なお，ここでは，使用するWebサーバの種類に応じた，リバースプロキシの配置について説明します。このほかのセキュリティの考え方については，「5.　セキュアなシステムの検討」を参照してください。

＜この節の構成＞

3.13.1　Webサーバ連携時のリバースプロキシの配置

3.13.2　インプロセスHTTPサーバ使用時のリバースプロキシの配置

3.13.1　Webサーバ連携時のリバースプロキシの配置

Webサーバとの連携時に，リバースプロキシを配置する構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

Webブラウザとアプリケーションサーバの間にDMZを確保して，リバースプロキシサーバを配置する構成です。

Webサーバ連携時にDMZにリバースプロキシを配置する構成の例を次の図に示します。

図3-59　Webサーバ連携時にDMZにリバースプロキシを配置する構成の例

特徴

アプリケーションサーバへのアクセスはリバースプロキシサーバからだけになり，Webブラウザからアプリケーションサーバに直接アクセスされることを抑止できます。

通常，リバースプロキシ上にはHTMLなどの静的コンテンツは配置しません。

リクエストの流れ

サーブレットとJSPに対するクライアントからのアクセスは，リバースプロキシモジュールを組み込んだWebサーバ，およびリダイレクタモジュールを組み込んだWebサーバ経由で実行されます。

また，ロードバランスクラスタを使用して負荷分散をする場合は，リバースプロキシサーバおよびアプリケーションサーバそれぞれに対して負荷分散機（レイヤ5スイッチ）を使用して負荷分散を実行できます。

ロードバランスクラスタ構成の場合に，DMZにリバースプロキシを配置する構成の例を次の図に示します。

図3-60　Webサーバ連携時にDMZにリバースプロキシを配置する構成の例（ロードバランスクラスタ構成の場合）

特徴

アプリケーションサーバへのアクセスはリバースプロキシサーバからだけになり，Webブラウザからアプリケーションサーバに直接アクセスされることを抑止できます。

通常，リバースプロキシ上にはHTMLなどの静的コンテンツは配置しません。

リバースプロキシサーバおよびアプリケーションサーバへの負荷を分散してスケーラビリティと可用性を確保できます。

リクエストの流れ

サーブレットとJSPに対するクライアントからのアクセスは，一つ目の負荷分散機，リバースプロキシモジュールを組み込んだWebサーバ，二つ目の負荷分散機およびリダイレクタモジュールを組み込んだWebサーバ経由で実行されます。

このとき，一つ目の負荷分散機は，Webブラウザからのアクセスを，複数のリバースプロキシサーバに対して振り分けて負荷を分散します。二つ目の負荷分散機は，リバースプロキシサーバからのアクセスを，複数のアプリケーションサーバに対して振り分けて負荷を分散します。二つ目の負荷分散機では，HTTPセッションのスティッキー（Sticky）やアフィニティ（Afinity）の関連づけも制御します。

なお，HTTPSを使用する場合は，一つ目の負荷分散機のフロントにSSLアクセラレータを配置する必要があります。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　リバースプロキシサーバマシン

リバースプロキシサーバマシンには，Hitachi Web Serverをインストールします。

必ず起動するプロセスは次のとおりです。

Webサーバ

このWebサーバには，リバースプロキシモジュールが組み込まれている必要があります。

(b)　アプリケーションサーバマシン，運用管理サーバマシンおよびクライアントマシン

アプリケーションサーバマシン，運用管理サーバマシンおよびクライアントマシンに必要なソフトウェアと起動するプロセスは，サーブレットとJSPをアクセスポイントにする構成と同じです。「3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）」を参照してください。

3.13.2　インプロセスHTTPサーバ使用時のリバースプロキシの配置

インプロセスHTTPサーバを使用する場合にリバースプロキシを配置する構成について説明します。

インターネットに接続するシステムでインプロセスHTTPサーバを使用する場合は，ここで示す構成を基に，必ずDMZを確保して，リバースプロキシを配置する構成にしてください。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

Webブラウザとアプリケーションサーバの間にDMZを確保して，リバースプロキシサーバを配置する構成です。

インプロセスHTTPサーバを使用する場合にDMZにリバースプロキシを配置する構成の例を次の図に示します。

図3-61　インプロセスHTTPサーバを使用する場合にDMZにリバースプロキシを配置する構成の例

特徴

アプリケーションサーバへのアクセスはリバースプロキシサーバからだけになり，Webブラウザからアプリケーションサーバに直接アクセスされることを抑止できます。

通常，リバースプロキシ上にはHTMLなどの静的コンテンツは配置しません。

リクエストの流れ

サーブレットとJSPに対するクライアントからのアクセスは，リバースプロキシモジュールを組み込んだWebサーバ経由で実行されます。

また，ロードバランスクラスタを使用して負荷分散をする場合は，リバースプロキシサーバおよびアプリケーションサーバそれぞれに対して負荷分散機（レイヤ5スイッチ）を使用して負荷分散を実行できます。

ロードバランスクラスタ構成の場合に，DMZにリバースプロキシを配置する構成の例を次の図に示します。

図3-62　インプロセスHTTPサーバを使用する場合にDMZにリバースプロキシを配置する構成の例（ロードバランスクラスタ構成の場合）

特徴

アプリケーションサーバへのアクセスはリバースプロキシサーバだけからになり，Webブラウザからアプリケーションサーバに直接アクセスされることを抑止できます。

通常，リバースプロキシ上にはHTMLなどの静的コンテンツは配置しません。

リバースプロキシサーバおよびアプリケーションサーバへの負荷を分散してスケーラビリティと可用性を確保できます。

リクエストの流れ

サーブレットとJSPに対するクライアントからのアクセスは，一つ目の負荷分散機，リバースプロキシモジュールを組み込んだWebサーバ，および二つ目の負荷分散機経由で実行されます。

このとき，一つ目の負荷分散機は，Webブラウザからのアクセスを，複数のリバースプロキシサーバに対して振り分けて負荷を分散します。二つ目の負荷分散機は，リバースプロキシサーバからのアクセスを，複数のアプリケーションサーバに対して振り分けて負荷を分散します。二つ目の負荷分散機では，HTTPセッションのスティッキー（Sticky）やアフィニティ（Afinity）の関連づけも制御します。

なお，HTTPSを使用する場合は，一つ目の負荷分散機のフロントにSSLアクセラレータを配置する必要があります。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

(a)　リバースプロキシサーバマシン

リバースプロキシサーバマシンには，Hitachi Web Serverをインストールします。

必ず起動するプロセスは次のとおりです。

Webサーバ

このWebサーバには，リバースプロキシモジュールが組み込まれている必要があります。

(b)　アプリケーションサーバマシン，運用管理サーバマシンおよびクライアントマシン

アプリケーションサーバマシン，運用管理サーバマシンおよびクライアントマシンに必要なソフトウェアと起動するプロセスは，サーブレットとJSPをアクセスポイントにする構成と同じです。「3.4.2　サーブレットとJSPをアクセスポイントに使用する構成（インプロセスHTTPサーバを使用する場合）」を参照してください。

3.14　性能解析トレースファイルを出力するプロセスを配置する

この節では，性能解析トレースファイルを出力するプログラムの配置について説明します。このプロセスは，Cosminexusのシステムには必ず配置するプロセスです。アプリケーションサーバマシンには必ず配置してください。EJBクライアントマシンへの配置は任意です。

性能解析トレースファイルは，PRFデーモン（パフォーマンストレーサ）によって出力されます。

＜この節の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

PRFデーモンは，アプリケーションサーバおよびEJBクライアントアプリケーションを実行するマシンに配置します。

PRFデーモンを配置する例を次の図に示します。

図3-63　PRFデーモンを配置する例

特徴

システム性能を解析するためのトレースファイルを出力できます。

トレースファイルは，トラブルが発生した場合のエラー個所の特定に利用できます。

性能解析トレースを出力する仕組み

クライアントとサーバ間でリクエストを処理するときに，アプリケーションサーバまたはEJBクライアントアプリケーションの各機能レイヤは，性能解析情報をバッファに出力します。PRFデーモンは，アプリケーションサーバまたはEJBクライアントアプリケーションの各機能レイヤがバッファに出力したトレース情報を，各マシン内のファイルに出力します。ファイル出力されたトレース情報は，Management Serverを利用して収集できます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

性能解析トレースファイルを出力するために起動するプロセスは次のとおりです。

PRFデーモン

これ以外にアプリケーションサーバに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

3.15　Cosminexus以外の製品との連携を検討する

この節では，Cosminexus以外の製品と連携する場合のシステム構成について説明します。

ここでは，次の構成について説明します。

JP1を使用して運用する場合の構成
運用管理プログラムとしてJP1を使用する場合の構成です。

CTMゲートウェイ機能を利用してEJBクライアント以外からStateless Session Beanを呼び出す構成
クライアントとしてTPBrokerクライアントまたはTPBroker OTMクライアントを使用する場合の構成です。

＜この節の構成＞

3.15.1　JP1を使用して運用する場合の構成

3.15.2　CTMゲートウェイ機能を利用してEJBクライアント以外からStateless Session Beanを呼び出す構成

3.15.1　JP1を使用して運用する場合の構成

JP1を使用して運用する場合の運用管理プログラムの配置について説明します。

JP1/IMと連携する場合，またはカスタムジョブの定義やシナリオなどCosminexusが提供する機能を利用してJP1/AJS2と連携する場合には，Management Serverを利用して運用していることが前提になります。「3.9.1　運用管理サーバにManagement Serverを配置する構成」または「3.9.2　マシン単位にManagement Serverを配置する構成」を参照してManagement Serverを利用するシステムの構成を決定した上で，JP1のプログラムを配置してください。JP1との連携で必要なプログラムについては，マニュアル「Cosminexus　機能解説」のJP1と連携したシステムの運用に関する説明を参照してください。

なお，JP1/AJS2またはJP1/AJS2 - SOを利用する場合に，Cosminexusの機能を使用しないでジョブまたはシナリオの定義をするときには，Management Serverを利用しなくても連携できます。この場合は，「3.9.3　コマンドで運用する場合の構成」に示すシステムの構成を検討した上で，JP1のマニュアルを参照して，システム構成を決定してください。

3.15.2　CTMゲートウェイ機能を利用してEJBクライアント以外からStateless Session Beanを呼び出す構成

CTMを使用するシステムの場合，EJBクライアントのほか，次に示すクライアントからアプリケーションサーバ上で動作するJ2EEアプリケーションを呼び出せます。

TPBrokerクライアント
TPBroker Version 5以降で開発されたクライアントアプリケーションです。

TPBroker OTMクライアント
TPBroker Object Transaction Monitorで開発されたクライアントアプリケーションです。

これらのクライアントからJ2EEサーバ上のアプリケーションを呼び出すためのクライアントアプリケーションの開発方法については，CTMのCORBA／OTMゲートウェイ機能についてのドキュメントを参照してください。

この構成では，TPBrokerクライアントまたはTPBroker OTMクライアントからJ2EEアプリケーションを呼び出すためのゲートウェイとしての機能を，CTMが提供します。

TPBrokerクライアントまたはTPBroker OTMクライアントからCTM経由でJ2EEアプリケーションを呼び出すシステム構成の例を次の図に示します。

図3-64　TPBrokerクライアントまたはTPBroker OTMクライアントからCTM経由でJ2EEアプリケーションを呼び出す構成の例

TPBrokerクライアントまたはTPBroker OTMクライアントからのリクエストは，CTMが提供するプロセス群を経由して，J2EEサーバ上のJ2EEアプリケーションに渡されます。

なお，CTMのプロセス群のうち，リクエストを受け付けるプロセスは，TPBrokerクライアントの場合とTPBroker OTMクライアントの場合で異なります。TPBrokerクライアントの場合，CTMレギュレータプロセスによってリクエストが受け付けられます。TPBroker OTMクライアントの場合，OTMゲートウェイプロセスによってリクエストが受け付けられます。なお，CTMレギュレータプロセス，およびOTMゲートウェイプロセスは，CTMデーモンを起動するときに，同時に起動されるプロセスです。

3.16　任意のプロセスを運用管理の対象にする

この節では，ユーザが定義する任意のプロセスを，Management Serverによる運用管理の対象とするためのシステム構成について説明します。

Management Serverによる運用管理の対象とする任意のプロセスを，論理サーバとして定義したユーザサーバとして配置します。論理サーバとして定義したユーザサーバを論理ユーザサーバといいます。論理ユーザサーバとして定義しておくと，Smart Composer機能のコマンドを使用して，任意のプロセスを開始したり，停止したり，任意のプロセスのステータスを監視したりできるようになります。

＜この節の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンで起動するプロセス

(1)　システム構成の特徴

このシステム構成は，Management Serverで運用管理するシステムで，論理サーバとして定義したユーザサーバを配置する構成です。運用管理に使用するManagement Serverは，運用管理サーバに配置することも，マシン単位に配置することもできます。Management Serverの配置については，「3.9　運用管理プロセスの配置を検討する」を参照してください。

ユーザサーバを配置する構成の例を次の図に示します。この構成例では，アプリケーションサーバマシンでユーザ任意のプロセスを実行します。このユーザ任意のプロセスをManagement Serverの運用管理の対象とするために，論理ユーザサーバとして定義して，配置しています。

図3-65　ユーザサーバを配置する構成の例

特徴

Management Serverを利用して任意のプロセスを運用管理できます。

(2)　それぞれのマシンで起動するプロセス

任意のプロセスをユーザサーバとして配置する構成の場合に，それぞれのマシンに必要なソフトウェアと起動するプロセスについて説明します。

(a)　アプリケーションサーバマシン

アプリケーションサーバマシンに必要なソフトウェアと起動するプロセスは，使用する機能に応じたシステム構成ごとに異なります。使用する機能に応じて必要なソフトウェアとプロセスを配置してください。

(b)　運用管理サーバマシン

運用管理サーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Management Server

3.17　そのほかの構成を検討する

この節では，前の節までに説明した以外の構成について説明します。

ポイント

この節で説明する構成は，旧バージョンとの互換性を保つための構成など，07-00以降のシステムでは推奨されていない互換用の構成です。07-00以降のApplication Serverで新規にシステムを構成する場合は，前の節までに説明した構成を使用することをお勧めします。

互換用の構成と，同等の機能を実現できる07-00以降で推奨されている構成の対応について，次の表に示します。

表3-3　互換用の構成と推奨構成の対応

互換用の構成
07-00以降で推奨されている構成
推奨されている構成についての参照先

Webサーバとアプリケーションサーバを異なるマシンに配置する構成
リダイレクタモジュールを組み込んだWebサーバとJ2EEサーバは同じマシンに配置することが推奨されています。

3.4.1　サーブレットとJSPをアクセスポイントに使用する構成（Webサーバ連携の場合）

3.13.1　Webサーバ連携時のリバースプロキシの配置

リダイレクタを利用して負荷分散する構成
サーブレット／JSPに対する負荷分散には負荷分散機を使用することが推奨されています。

3.7.1　Webサーバ連携時の負荷分散機を利用した負荷分散（サーブレット／JSPの場合）

CORBAネーミングサービスをアウトプロセスで起動する構成
CORBAネーミングサービスはインプロセスで起動することが推奨されています。
－※

（凡例）－：該当しない。

注※　3.4～3.16で説明したすべての構成で使用できます。

このほかの互換用の構成については，「付録A　ベーシックモードの利用（互換機能）」および「付録B　サーブレットエンジンモードの利用（互換機能）」を参照してください。

＜この節の構成＞

3.17.1　Webサーバとアプリケーションサーバを異なるマシンに配置する構成

3.17.2　リダイレクタを利用して負荷分散する構成

3.17.3　CORBAネーミングサービスをアウトプロセスで起動する構成

3.17.1　Webサーバとアプリケーションサーバを異なるマシンに配置する構成

サーブレットとJSPがアクセスポイントになる，Webベースのシステム構成について説明します。ここでは，リダイレクタモジュールを組み込んだWebサーバとアプリケーションサーバを異なるマシンに配置する場合について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なプロセスとソフトウェア

(1)　システム構成の特徴

Webフロントシステムで，Webブラウザから送信されたリクエストをアプリケーションサーバで処理する場合に適用されるシステム構成です。

Webクライアント構成では，Webサーバとアプリケーションサーバを異なるマシンに分けて配置できます。Webサーバとアプリケーションサーバを異なるマシンに配置したWebクライアント構成の例を次の図に示します。

図3-66　Webサーバとアプリケーションサーバを異なるマシンに配置したWebクライアント構成の例

特徴

HTMLファイルなどの静的なコンテンツを配置するマシンと，サーブレットやJSPなどのWebアプリケーションを実行するマシンを分けることで，パフォーマンスの向上が図れます。静的コンテンツとWebアプリケーションを分けて配置する場合の配置方法については，「6.7.1　静的コンテンツとWebアプリケーションの配置を切り分ける」を参照してください。

リクエストの流れ

アクセスポイントであるサーブレットとJSPは，J2EEサーバ上で動作します。Webブラウザからのリクエストは，Webサーバ経由でアクセスポイントに送られ，サーブレットとJSPを呼び出します。

(2)　それぞれのマシンに必要なプロセスとソフトウェア

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。なお，リソースと接続するために必要なプロセスについては，「3.6　トランザクションの種類を検討する」を参照してください。

(a)　Webサーバマシン

Webサーバマシンには，次のどれかをインストールする必要があります。

Application Server Standard

Application Server Enterprise

Web Redirector

必要なプロセスは次のとおりです。

Webサーバ

Management Server

運用管理エージェント

PRFデーモン

Application Server StandardまたはApplication Server Enterpriseには，WebサーバであるHitachi Web Serverが含まれています。Windowsの場合，WebサーバにMicrosoft IISを使用することもできます。この場合は，ソフトウェアとしてMicrosoft IISが必要です。

Web Redirectorには，Webサーバは含まれていません。Hitachi Web ServerまたはMicrosoft IISが必要です。

(b)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

必要なプロセスは次のとおりです。

J2EEサーバ

Management Server

運用管理エージェント

PRFデーモン

(c)　Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

3.17.2　リダイレクタを利用して負荷分散する構成

アクセスポイントになるコンポーネントがサーブレットまたはJSPの場合に，Webサーバに登録したリダイレクタによって負荷を分散する構成について説明します。

＜この項の構成＞

(1)　システム構成の特徴

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

(1)　システム構成の特徴

J2EEサーバ上で動作するアプリケーションのアクセスポイントが，サーブレットまたはJSPの場合に使用できる構成です。Webサーバに登録したリダイレクタで負荷を分散します。リダイレクタの設定ファイルに対象となるアプリケーションサーバを登録することで実現できます。

リダイレクタを利用した負荷分散の構成の例を次の図に示します。

図3-67　リダイレクタを利用した負荷分散の構成の例

特徴

サーブレットとJSPのスケーラビリティと可用性を確保できます。アプリケーションサーバを複数用意して，リダイレクタによってクライアントからのアクセスを分散することで，負荷を分散できます。

リダイレクタを登録したWebサーバは，アプリケーションサーバとは異なるマシン上に配置する必要があります。

特定のアプリケーションサーバでトラブルが発生した場合，またはメンテナンスが必要な場合に，リダイレクタから該当するアプリケーションサーバへのアクセスを停止することで，システムの縮退運転ができます。

ポイント

負荷分散機を使用する方が，Webサーバを実行するマシンへの負荷を掛けないで，性能の高い負荷分散を実現できます。

リクエストの流れ

アクセスポイントであるJ2EEサーバ上のサーブレットとJSPへのリクエストは，WebブラウザからWebサーバ経由で送られます。その際，Webサーバに登録されているリダイレクタは，ロードバランスクラスタの構成要素であるJ2EEサーバにラウンドロビン方式でリクエストを振り分けます。

(2)　それぞれのマシンに必要なソフトウェアと起動するプロセス

リダイレクタを使用した負荷を分散する場合に必要なソフトウェアと起動するプロセスは，サーブレットとJSPをアクセスポイントにする構成のうち，Webサーバとアプリケーションサーバを分離して配置する構成と同じです。「3.17.1　Webサーバとアプリケーションサーバを異なるマシンに配置する構成」を参照してください。

3.17.3　CORBAネーミングサービスをアウトプロセスで起動する構成

Application Serverでは，CORBAネーミングサービスをJ2EEサーバのインプロセスで起動できますが，アウトプロセスでも起動できます。

CORBAネーミングサービスをアウトプロセスで起動する構成の例を次の図に示します。

図3-68　CORBAネーミングサービスをアウトプロセスで起動する構成の例

ただし，07-00以降で新規にシステムを構築する場合は，CORBAネーミングサービスはインプロセスで起動することをお勧めします。インプロセスでの起動方法については，マニュアル「Cosminexus　システム運用ガイド」のJ2EEサーバの起動に関する説明を参照してください。

3.18　Cosminexusのプロセスが使用するTCP/UDPのポート番号

ここでは，Cosminexusのプロセスが使用するTCP/UDPのポート番号について説明します。

デフォルト値が「（浮動）」のポートは，ポート番号を明示的に固定しない場合にCosminexusによって自動的に番号が付けられるポートです。

Cosminexusが使用するTCP/UDPのポート番号の説明を次の表に示します。なお，ご使用のOSによっては，ネットワーク単位ではなくホスト単位でファイアウォールが設定されているものがあります。これらのファイアウォールでは，localhost（127.0.0.1）以外との通信は，同一ホスト内でもファイアウォールのフィルタリングの対象になる場合があります。この場合は，ホスト内でしか通信しないポートであっても，フィルタで通信を許可する設定にしてください。

表3-4　Cosminexusが使用するTCP/UDPのポート番号

項番
プロセス
説明
デフォルト値

(1)
J2EEサーバまたはSFOサーバ
EJBコンテナのリクエスト受付ポート。
（浮動）

(2)
管理用通信ポート。※
8080

(3)
Webサーバ（リダイレクタ）からのリクエスト受付ポート。※
8007

(4)
トランザクションサービス使用時のトランザクションリカバリ処理通信ポート。
トランザクションサービス使用時に必要です。
20302

(5)
インプロセスで起動するネーミングサービスのリクエスト受付ポート。
900

(6)
インプロセスHTTPサーバのリクエスト受付ポート。
インプロセスHTTPサーバを使用するときに必要です。
80

(7)
RMIレジストリのリクエスト受付ポート。
23152

(8)
共有キューを使用して複数システム間でのアプリケーション連携をする場合のイベント受信用ポート。
20351

(9)
稼働情報取得時のリクエスト受付ポート。
（浮動）

(10)
運用監視エージェント
運用監視エージェントの通信用ポート。
（浮動）

(11)
スマートエージェント
スマートエージェントの通信用ポート環境変数。
UDPによる双方向通信に必要です。
14000

(12)
ネーミングサービス
ネーミングサービスのリクエスト受付ポート引数（Cosminexus TPBrokerが利用）。
900

(13)
運用管理エージェント
運用管理エージェントがManagement Serverとの通信に使用するポート。
20295

(14)
Management Server
Management Serverのhttpポート。
28080

(15)
Management Serverの終了要求ポート。
ホスト内通信に必要です。
28005

(16)
Management Serverの内部通信ポート。
ホスト内通信に必要です。
28009

(17)
Hitachi Web Server
Hitachi Web Serverのhttpポート。
80

(18)
Hitachi Web Serverのhttpsポート。
443

(19)
サーバ管理コマンド
サーバ管理コマンドがJ2EEサーバと通信するポート。
（浮動）

(20)
CTMレギュレータ
CTMレギュレータがEJBクライアントからのリクエストを受け付けるポートの基底値。基底値＋プロセス数だけ使用します。
CTM使用時に必要です。
（浮動）

(21)
CTMデーモン
CTMデーモンがEJBクライアントからのリクエストを受け付けるポート。
CTM使用時に必要です。
（浮動）

(22)
CTMデーモンがほかのデーモンやJ2EEサーバなどと通信するポート。
CTM使用時に必要です。
20138

(23)
CTMドメインマネジャ
CTMドメインマネジャがほかのCTMドメインマネジャと通信するポート。
CTM使用時に，TCPおよびUDP通信（ブロードキャスト）をするために必要です。
20137

注※　SFOサーバでは使用しません。

Cosminexusのプロセスが使用するTCP/UDPのポート番号について，次の図に示します。(x)は表の項番と対応しています。

図3-69　Cosminexusが使用するTCP/UDPのポート番号

ポート番号の指定個所を次の表に示します。表の項番は図中の項番と対応しています。

表3-5　Cosminexusが使用するTCP/UDPのポート番号の指定個所

項番
定義ファイル
設定対象
パラメタ名※1

(1)
簡易構築定義ファイル
論理J2EEサーバ（j2ee-server）
論理SFOサーバ（sfo-server）
vbroker.se.iiop_tp.scm.iiop_tp.listener.port※2

(2)
簡易構築定義ファイル
論理J2EEサーバ（j2ee-server）
ejbserver.http.port

(3)
簡易構築定義ファイル
論理J2EEサーバ（j2ee-server）
webserver.connector.ajp13.port

(4)
簡易構築定義ファイル
論理J2EEサーバ（j2ee-server）
論理SFOサーバ（sfo-tier）
ejbserver.distributedtx.recovery.port

(5)
簡易構築定義ファイル
論理J2EEサーバ（j2ee-server）
論理SFOサーバ（sfo-tier）
inprocess.ns.port

(6)
簡易構築定義ファイル
論理J2EEサーバ（j2ee-server）
webserver.connector.inprocess_http.port

(7)
簡易構築定義ファイル
論理J2EEサーバ（j2ee-server）
論理SFOサーバ（sfo-server）
ejbserver.rmi.naming.port

(8)
Connector属性ファイル
Cosminexus RM
<config-property>タグに指定するRMSHPort※3

(9)
簡易構築定義ファイル
論理J2EEサーバ（j2ee-server）
論理SFOサーバ（sfo-server）
ejbserver.rmi.remote.listener.port

(10)
簡易構築定義ファイル
論理J2EEサーバ（j2ee-server）
論理SFOサーバ（sfo-server）
mngagent.connector.port

(11)
簡易構築定義ファイル
論理スマートエージェント（smart-agent）
smartagent.port

(12)
簡易構築定義ファイル
論理J2EEサーバ（j2ee-server）
論理SFOサーバ（sfo-server）
ejbserver.naming.port

(13)
adminagent.properties
運用管理エージェント
adminagent.adapter.portキー

(14)
mserver.properties
Management Server
webserver.connector.http.portキー

(15)
mserver.properties
Management Server
webserver.shutdown.portキー

(16)
mserver.properties
Management Server
webserver.connector.ajp13.portキー

(17)
簡易構築定義ファイル
論理Webサーバ
（web-server）
Listen

(18)
簡易構築定義ファイル
論理Webサーバ
（web-server）
Listen

(19)
usrconf.properties（サーバ管理コマンド用システムプロパティファイル）
サーバ管理コマンド
vbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

(20)
簡易構築定義ファイル
論理CTM（component-transaction-monitor）
ctm.RegOption

(21)
簡易構築定義ファイル
論理CTM（component-transaction-monitor）
ctm.EjbPort

(22)
簡易構築定義ファイル
論理CTM（component-transaction-monitor）
ctm.port

(23)
簡易構築定義ファイル
論理CTMドメインマネジャ（ctm-domain-manager）
cdm.port

（凡例）－：該当しない。

注※1　設定ファイルが簡易構築定義ファイルの場合は，<configuration>タグ内の<param-name>の指定値を指します。

注※2　Developer Standard以外の場合のパラメタ名です。Developer Standardを使用する場合のパラメタ名は，ejbserver.rmi.remote.listener.portになります。

注※3　RMSHPortは，リソースアダプタCosminexus RMのプロパティ定義で指定するコンフィグレーションプロパティです。RMSHPortについては，マニュアル「Cosminexus Reliable Messaging」のコンフィグレーションプロパティの詳細説明に関する説明を参照してください。

参考

運用管理ポータルまたはファイル編集によって設定する場合の設定個所を次に示します。

表3-6　TCP/UDPのポート番号を運用管理ポータルまたはファイル編集によって設定する場合の設定個所

項番
運用管理ポータルでの設定個所
ファイル編集での設定個所

(1)

J2EEサーバの場合
［EJBコンテナの設定］画面の「オプション」の「通信ポート番号」

SFOサーバの場合
［システムプロパティの設定］画面の「システムプロパティの定義」に追加

usrconf.propertiesのvbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

(2)
［J2EEサーバの基本設定］画面の「コンテナの設定」の「簡易Webサーバのポート番号」
usrconf.propertiesのejbserver.http.portキー

(3)
［Webコンテナの設定］画面の「Webサーバとの接続」の「ポート番号」
usrconf.propertiesのwebserver.connector.ajp13.portキー

(4)
［トランザクションの設定］画面の「トランザクションに関する設定」の「JTAリカバリの固定ポート番号」
usrconf.propertiesのejbserver.distributedtx.recovery.portキー

(5)

J2EEサーバの場合
［ネーミングの設定］画面の「インプロセス選択時の設定」の「ポート番号」

SFOサーバの場合
［SFOサーバの基本設定］画面の「ネーミングサービスの設定」

usrconf.propertiesのejbserver.naming.portキー

(6)
［Webコンテナの設定］画面の「インプロセスHTTPサーバ機能の使用」の「ポート番号」
usrconf.propertiesのwebserver.connector.inprocess_http.portキー

(7)

J2EEサーバの場合
［通信の設定］画面の「RMIレジストリの設定」の「ポート番号」

SFOサーバの場合
［通信の設定］画面の「RMIレジストリの設定」の「ポート番号」

usrconf.propertiesのejbserver.rmi.naming.portキー

(8)
Connector属性ファイルの<config-property>タグに指定するRMSHPort※
Connector属性ファイルの<config-property>タグに指定するRMSHPort※

(9)

J2EEサーバの場合
［通信の設定］画面の「RMIレジストリの設定」の「通信ポート番号」

SFOサーバの場合
［通信の設定］画面の「RMIレジストリの設定」の「通信ポート番号

usrconf.propertiesのejbserver.rmi.remote.listener.portキー

(10)

J2EEサーバの場合
［J2EEコンテナの設定］画面の「運用監視エージェントの設定」の「ポート番号」

SFOサーバの場合
［コンテナの設定］画面の「運用監視エージェントの設定」の「ポート番号」

mngagent.<実サーバ名>.propertiesのmngagent.connector.portキー

(11)
［スマートエージェントの設定］画面の「スマートエージェントに関する設定」の「監視ポート番号」
環境変数OSAGENT_PORT

(12)

CORBAネーミングサービスをインプロセスで起動する場合
［J2EEサーバの基本設定］画面の「利用するネーミングサービスの設定」の「インプロセス用のポート番号」

CORBAネーミングサービスをアウトプロセスで起動する場合
［ホスト内のサーバの設定］画面の「ネーミングサービスの設定」の「ネーミングサービスのポート番号」

CORBAネーミングサービスをインプロセスまたはアウトプロセスで自動起動する場合
usrconf.propertiesのejbserver.naming.portキー

CORBAネーミングサービスを手動起動する場合
nameservコマンドのコマンド引数に「-Dvbroker.se.iiop_tp.scm.iiop_tp.listener.port=<ポート番号>」を指定。

(13)
adminagent.propertiesのadminagent.adapter.portキー
adminagent.propertiesのadminagent.adapter.portキー

(14)
［ネットワークの設定］画面の「Management Server接続HTTPポート番号」
mserver.propertiesのwebserver.connector.http.portキー

(15)
［ネットワークの設定］画面の「Management Server終了要求受信ポート番号」
mserver.propertiesのwebserver.shutdown.portキー

(16)
［ネットワークの設定］画面の「Management Server内部通信用ポート番号」
mserver.propertiesのwebserver.connector.ajp13.portキー

(17)
［ホスト内のサーバの設定］画面の「J2EEサーバの設定」の「ポート番号」の「http」
httpsd.confのListenディレクティブまたはPortディレクティブ

(18)
［ホスト内のサーバの設定］画面の「J2EEサーバの設定」の「ポート番号」の「https」
httpsd.confのListenディレクティブまたはPortディレクティブ

(19)
usrconf.properties（サーバ管理コマンド用システムプロパティファイル）のvbroker.se.iiop_tp.scm.iiop_tp.listener.portキー
usrconf.properties（サーバ管理コマンド用システムプロパティファイル）のvbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

(20)
［レギュレータの設定］画面の「CTMレギュレータの設定」の「設定ファイル」
ctmregltdコマンドまたはctmstartコマンドの引数-CTMEjbPort

(21)
［スケジューリングの設定］画面の「詳細設定」の「EJBリクエスト受信ポート番号」
ctmstartコマンドの引数-CTMEjbPort

(22)
［CTMの基本設定］画面の「基本設定」の「ポート番号」
ctmstartコマンドの引数-CTMPort

(23)
［CTMドメインマネジャの基本設定］画面の「ポート番号」
ctmdmstartコマンドの引数-CTMPort

注※　RMSHPortは，リソースアダプタCosminexus RMのプロパティ定義で指定するコンフィグレーションプロパティです。RMSHPortについては，マニュアル「Cosminexus Reliable Messaging」のコンフィグレーションプロパティの詳細説明に関する説明を参照してください。

4.　システム構成の検討（バッチアプリケーション実行基盤）

この章では，バッチアプリケーション実行基盤を構築する場合のシステム構成の検討について説明します。システムを設計する流れに沿って，標準的なシステム構成のパターンを示します。また，意識する必要があるコンポーネント，プロセスおよび処理の流れについて説明します。

J2EEアプリケーション実行基盤のシステム構成を検討する場合は，「3.　システム構成の検討（J2EEアプリケーション実行基盤）」を参照してください。

＜この章の構成＞

4.1　システム構成を検討するときに考慮すること

4.2　バッチサーバを使用する場合のシステム構成

4.1　システム構成を検討するときに考慮すること

この節では，バッチアプリケーション実行基盤としてCosminexusを使用する場合に，システム構成の検討で考慮することについて説明します。

＜この節の構成＞

4.1.1　システムの目的と構成

4.1.2　システム構成の設計手順

4.1.3　バッチサーバが使用するTCP/UDPのポートについての注意事項

4.1.1　システムの目的と構成

バッチアプリケーション実行基盤は，Javaアプリケーションとして実装されたバッチアプリケーションを実行するための環境です。バッチアプリケーションは，JSP，ServletおよびEnterprise BeanなどのJ2EEアプリケーションを利用しないJavaアプリケーションとして実装します。なお，バッチアプリケーションから，J2EEサーバ上のEnterprise Beanを呼び出すことはできます。

バッチアプリケーションは，バッチサーバ上で動作します。バッチアプリケーションがリソースと接続する場合に使用するリソースアダプタも，バッチサーバ上で動作します。

バッチアプリケーションは，バッチ実行コマンドによって実行されます。バッチ実行コマンドは，ユーザが直接実行するほか，JP1/AJS2のジョブとして自動実行することができます。

バッチアプリケーションを実行するシステムの構成例を次の図に示します。この図では，アプリケーションサーバ上で，バッチアプリケーションごとに二つのバッチサーバが動作しています。また，バッチアプリケーションは，JP1/AJS2を使用して実行しています。

図4-1　バッチアプリケーションを実行するシステムの構成例

このほか，バッチアプリケーションからJ2EEサーバ上のEnterprise Beanに接続する場合は，オンライン処理を実行するバックシステムに接続することもできます。バックシステムについては，「3.1.1　システムの目的と構成」を参照してください。

4.1.2　システム構成の設計手順

システム構成は，次の流れで設計します。

図4-2　システム構成を設計する流れ（バッチアプリケーション実行基盤の場合）

＜この項の構成＞

(1)　アプリケーションの起動方式を検討する

(2)　トランザクションの使用方法を検討する

(3)　セキュリティの設定を確認する

(4)　性能解析トレースファイルを出力するプロセスを配置する

(5)　運用管理および運用監視方法を決定する

(6)　JP1との連携を検討する

(7)　そのほかの機能を使用する場合

(1)　アプリケーションの起動方式を検討する

バッチアプリケーションの起動方式を検討します。次の2種類から選択します。

バッチサーバ上で起動する
バッチサーバ上でJavaアプリケーションを起動する方式です。常駐型のJavaVMプロセスであるバッチサーバを使用することで，JavaVMの起動に掛かるオーバーヘッドを削減できます。
また，バッチサーバ上で起動する場合，リソースアダプタとしてDB Connectorが使用できます。

cjclstartapコマンドを使用して個別に起動する
javaコマンドと同じようにJavaアプリケーションを起動する方式です。この方式の場合，バッチアプリケーションを実行するたびに，JavaVMの起動が必要です。

起動方式としてバッチサーバ上で起動することを選択した場合は，次の検討項目に進みます。なお，cjclstartapコマンドを使用することを選択した場合は，以降の検討項目は該当しません。

(2)　トランザクションの使用方法を検討する

リソースと接続する場合は，トランザクションの使用方法を検討します。次の2種類から選択します。

DB Connectorを使用する
Cosminexusが提供するリソースアダプタであるDB Connectorを使用する方法です。DB Connectorの機能として，コネクションプーリングやステートメントプーリングが使用できます。また，フルガーベージコレクションの発生を制御する機能も使用できます。なお，バッチサーバで管理できるトランザクションは，ローカルトランザクションです。

JDBCドライバを直接使用する
JDBCドライバが提供するAPIを使用して，トランザクション管理に必要な処理を実装する方法です。

DB Connectorを使用する場合のリソースアダプタとリソースの構成については，「3.3.2　リソースの種類とリソースアダプタ」を参照してください。ただし，バッチサーバの場合，接続できるリソースはデータベースだけです。

(3)　セキュリティの設定を確認する

バッチサーバは，SecurityManagerによるセキュリティ保護を無効にして起動します。

(4)　性能解析トレースファイルを出力するプロセスを配置する

性能解析トレースファイルを出力するためのプロセスであるPRFデーモン（パフォーマンストレーサ）の配置を確認します。PRFデーモンは，バッチサーバごとに配置します。

(5)　運用管理および運用監視方法を決定する

運用管理および運用監視を実行するためのプロセスであるManagement Serverの配置を確認します。バッチアプリケーション実行基盤では，バッチサーバと同じマシンに配置します（ホスト単位管理モデルを使用します）。

(6)　JP1との連携を検討する

バッチアプリケーションの実行をJP1/AJS2のジョブとして自動投入する場合は，JP1との連携方法を検討します。

(7)　そのほかの機能を使用する場合

使用する機能に応じて，次の構成を検討してください。

サーバ間連携をする構成
バッチアプリケーションからJ2EEサーバ上のEnterprise Beanを呼び出す場合に検討します。「3.5　サーバ間での連携を検討する」を参照してください。

クラスタソフトウェアを使用した障害時の系切り替えをする構成
バッチサーバを系切り替えの対象にする場合に検討します。
次の説明を参照してください。

「3.11.1　アプリケーションサーバの実行系と待機系を1:1にする構成（トランザクションサービスを使用しない場合）」

「3.11.4　アプリケーションサーバの実行系と待機系を相互スタンバイにする構成」

参照先の記述のうち，「J2EEサーバ」は「バッチサーバ」に読み替えてください。

4.1.3　バッチサーバが使用するTCP/UDPのポートについての注意事項

バッチサーバは，J2EEサーバが使用するTCP/UDPのポートのうち，次の表に示すポートを使用します。

表4-1　バッチサーバが使用するTCP/UDPのポート

項番※ | 説明
(1) | EJBコンテナのリクエスト受付ポート。
(2) | 管理用通信ポート。
(3) | Webサーバ（リダイレクタ）からのリクエスト受付ポート。
(5) | インプロセスで起動するネーミングサービスのリクエスト受付ポート。
(7) | RMIレジストリのリクエスト受付ポート。
(9) | 稼働情報取得時のリクエスト受付ポート。

注

スマートエージェントを使用する指定をした場合，スマートエージェントと通信するために，この表で示した以外の複数のポートが使用されます。スマートエージェントの詳細については，マニュアル「Borland(R) Enterprise Server VisiBroker(R) プログラマーズリファレンス」を参照してください。

注※

「3.18　Cosminexusのプロセスが使用するTCP/UDPのポート番号」の「表3-4　Cosminexusが使用するTCP/UDPのポート番号」の項番と対応しています。

次の場合は，使用するポートが重複しないように設定してください。

一つのマシンでJ2EEサーバとバッチサーバを同時に使用する場合

一つのマシンで複数のバッチサーバを同時に使用する場合

J2EEサーバが使用するTCP/UDPのポートについては，「3.18　Cosminexusのプロセスが使用するTCP/UDPのポート番号」を参照してください。

4.2　バッチサーバを使用する場合のシステム構成

この節では，バッチサーバを使用する場合のシステム構成について説明します。

＜この節の構成＞

4.2.1　システム構成の特徴

4.2.2　それぞれのマシンに必要なプロセスとソフトウェア

4.2.1　システム構成の特徴

ここでは，バッチサーバを使用する場合の標準的なシステム構成について説明します。

バッチサーバは，Smart Composer機能のWebシステム（j2ee-tier）として構築，運用します。バッチアプリケーションの実行には，バッチ実行コマンドを使用します。バッチ実行コマンドは，JP1/AJS2にジョブとして定義して実行できます。

バッチサーバを使用する場合の標準的なシステム構成の例を次の図に示します。この例では，バッチアプリケーションはJP1/AJS2から実行します。また，バッチアプリケーションからリソースアダプタを使用してHiRDBにアクセスします。

図4-3　バッチサーバを使用する場合のシステム構成の例

特徴

リソースとの接続にDB Connectorが使用できます。また，uCosminexus Batch Job Execution Serverとの連携もできます。

処理の流れ

バッチアプリケーションの実行は，JP1/AJS2のジョブとして定義しておきます。JP1/AJS2のジョブとして実行されたバッチアプリケーションは，バッチサーバ上のDB Connectorを経由してHiRDBにアクセスします。

4.2.2　それぞれのマシンに必要なプロセスとソフトウェア

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

＜この項の構成＞

(1)　アプリケーションサーバマシン

(2)　管理サーバマシンおよび管理クライアントマシン

(3)　データベースサーバマシン

(1)　アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Server Enterpriseをインストールする必要があります。なお，開発環境の場合は，Developer Professionalをインストールする必要があります。

さらに，JP1/AJS2によってバッチアプリケーションを実行する場合や，uCosminexus Batch Job Execution Serverと連携したジョブの制御をする場合は，次の製品もインストールする必要があります。

JP1/AJS2と連携する場合に必要な製品

JP1/Base

JP1/AJS2 - Agent

JP1/AJS2 - Manager

JP1/AJS2 - View

uCosminexus Batch Job Execution Serverと連携する場合に必要な製品

uCosminexus Batch Job Execution Server

JP1/AJS2と連携する場合に必要な製品

起動するプロセスは次のとおりです。

バッチサーバ

PRFデーモン

Management Server

運用管理エージェント

JP1/BaseとJP1/AJS2のプロセス（JP1/AJS2と連携する場合）

uCosminexus Batch Job Execution Serverのプロセス（uCosminexus Batch Job Execution Serverと連携する場合）

また，データベースと接続する場合は，使用するデータベースと接続するためのソフトウェアが必要です。データベースに接続するために必要な製品については，「3.6.1　ローカルトランザクションを使用する場合の構成」を参照してください。ただし，バッチサーバで使用できるリソースは，次に示すデータベースだけです。

HiRDB

Oracle

SQL Server

XDM/RD E2

(2)　管理サーバマシンおよび管理クライアントマシン

管理サーバマシンおよび管理クライアントマシンは，JP1/AJS2と連携する場合に必要です。インストールする製品および起動するプロセスについては，マニュアル「JP1/Automatic Job Management System 2 設計・運用ガイド」を参照してください。

(3)　データベースサーバマシン

データベースサーバマシンに必要な製品については，「3.6.1　ローカルトランザクションを使用する場合の構成」のリソースマネジャが動作するマシンの説明を参照してください。ただし，バッチサーバで使用できるリソースは，次に示すデータベースだけです。

HiRDB

Oracle

SQL Server

XDM/RD E2

5.　セキュアなシステムの検討

業務システムを安全に稼働させ，扱うデータを確実に守るためには，システム設計の段階でセキュリティについて十分に検討しておく必要があります。この章では，セキュアなシステムを構築・運用するための考え方，正しい構築・運用手順，および監査の方法について説明します。

また，外部ネットワークを使用するシステムの場合に想定されるセキュリティ上の脅威を明確にし，それぞれに対して，ハードウェアおよびソフトウェアを使用して対策する方法についても説明します。

なお，この章は，J2EEアプリケーションを実行するシステムの場合に参照してください。バッチアプリケーションを実行するシステムの場合は該当しません。

＜この章の構成＞

5.1　セキュアなシステムの検討の概要

5.2　セキュアなシステムの構成の検討

5.3　システムの使用者の検討

5.4　システムが扱う資産の検討

5.5　セキュアなシステムの前提条件の確認

5.6　想定される脅威の分析

5.7　対策の検討

5.8　作業手順の検討

5.9　システムの監査方法の確認

5.10　外部ネットワークを使用するシステムでのセキュリティの検討

5.1　セキュアなシステムの検討の概要

システムを管理または運用するユーザがシステムを構築・運用していく過程や，システムが提供するサービスをエンドユーザが利用していく過程で，システムにはセキュリティ上のさまざまな脅威が想定されます。脅威からシステムを守るには，システムを物理的に安全な構成に設計したり，作業者の運用ルールを定めたりするなど，対策を実施する必要があります。

また，近年，組織の健全な運営の保証や，複雑化・多様化するITシステムの安全な構築・運用の観点から，組織の内部統制の重要性が高まっています。その中では，システムがセキュアに保たれていることを監査者に証明できることが求められます。そのためには，システムに対して，いつ，だれが，どんな操作を実施したのかをログに記録して，システムに対して正当な権限を持つ作業者が正当な業務を実施したことを監査できる仕組みが必要です。

このようなセキュアなシステムを実現するためには，想定される脅威をシステムの設計時に明確にして，それに応じた対策を実現できるシステムを検討していく必要があります。

この章では，システムに対して想定される脅威を明確にした上で，セキュアなシステムを構築・運用するための考え方や手順など，システム設計時に検討が必要なことについて説明します。

セキュアなシステムの検討は，次の流れで実施します。

図5-1　セキュアなシステムの検討の流れ

なお，この図では，企業内部で使用されるシステムのセキュリティを確保するための作業の流れを示しています。外部からの脅威に対する対策については，「5.10　外部ネットワークを使用するシステムでのセキュリティの検討」を参照してください。

5.2　セキュアなシステムの構成の検討

ここでは，セキュアなシステムの構成について説明します。このマニュアルではセキュアなシステムとして，次のようなシステムを想定しています。

大企業で常時稼働して，社内で利用されるシステムです。

システムを構成する要素はすべて社内LAN上に配置されます。

システムが提供するサービスは，社内のクライアント端末からWebブラウザを使用して利用されます。

クライアント端末からサービスを利用するには，ログイン処理が必要です。システムに登録されていないユーザはサービスを利用できません。

このシステムの構成を次の図に示します。

図5-2　セキュアなシステムの構成

このシステムの構成要素を次に示します。なお，説明中にある「システム管理者」，「システム運用者」，「監査者」，および「エンドユーザ」の定義については，「5.3　システムの使用者の検討」を参照してください。

サーバエリア

ハードウェアを管理するための，物理的に隔離されたスペースです。サーバエリア内のハードウェアは，システム管理者が管理します。サーバエリアに入室できるのは，システム管理者，システム運用者，および監査者だけです。

アプリケーションサーバ

Webサーバ，サービスを提供するJ2EEアプリケーション，およびJ2EEアプリケーションが稼働するために必要なサーバプログラムが稼働しているマシンです。サーバエリアに複数台設置されて，負荷分散機によって負荷分散されます。

データベース

ユーザの情報やサービスが処理した情報が格納されているマシンです。サーバエリアに設置します。

監査ログサーバ

監査ログを収集して，監査を実施するためのサーバです。監査者だけが使用します。サーバエリアに設置します。

運用管理サーバ

アプリケーションサーバを管理する，運用管理プログラムが稼働するマシンです。システム構築時にシステム管理者が，システム運用時にシステム運用者が使用します。サーバエリアに設置します。

負荷分散機

アプリケーションサーバを複数台設置する場合に，負荷分散をする装置です。サーバエリアに設置します。

ファイアウォール

サーバエリア，社内LAN，および外部インターネットの間に配置します。

クライアント端末

システムが提供するサービスを利用するための端末です。エンドユーザは，クライアント端末上のWebブラウザを使用して，社内LAN経由でアプリケーションサーバにアクセスします。

5.3　システムの使用者の検討

セキュアなシステムを検討するには，まず，システムの使用者を定義します。システムの使用者にはどのようなユーザがいるかを洗い出して，それぞれの使用者の目的や作業範囲を明確に定義します。これが，システムの監査を実施する観点の一つである，正しいユーザがそれぞれの操作を実行したかどうかを検証する根拠になります。

なお，それぞれの使用者の作業手順は，作業手順書を作成して定義する必要があります。作業手順書には，「システム構築手順書」，「システム運用手順書」，「エンドユーザ操作手順書」，「入退室手順書」などが考えられます。作業手順書の検討については，「5.8　作業手順の検討」を参照してください。

このシステムでは，次に示す使用者を定義します。

システム管理者

システム管理者は，「システム構築手順書」に従って，システムの構築，および管理を実施します。具体的には，主に次の作業を実施します。

サーバエリア内のハードウェア，ソフトウェア，ネットワークの設置・設定

ソフトウェアのアップデート

システムの起動と停止

システム管理者は，組織内の情報システム部門から選ばれたユーザが担当します。

システム運用者

システム運用者は，「システム運用手順書」に従って，サーバエリア内でエンドユーザの登録・削除などのシステムの運用作業を実施します。システム運用者は，社内の情報システム部門から委託されたユーザが担当します。

エンドユーザ

エンドユーザは，「エンドユーザ操作手順書」に従って，システムが提供するサービスを利用します。サービスの利用には，社内LANに接続されたクライアント端末上のWebブラウザを使用します。

監査者

監査者は「入退室手順書」に従ってサーバエリアに入室して，監査ログを取得します。取得した監査ログを調査して，信頼できるシステム管理者が「システム構築手順書」に従った正しい方法でシステムを構築しているかどうかを確認します。また，正しい方法で構築されたシステムが，「システム運用手順書」および「エンドユーザ操作手順書」に従った正しい方法で運用，および利用されているかどうかを監査します。監査者は，社内の内部監査を実施するコンプライアンス部門から選ばれたユーザが担当します。

5.4　システムが扱う資産の検討

セキュアなシステムを検討するには，システムが扱う資産（データ）のうち，保護する必要がある資産にはどのようなものがあるのかを明確に判断する必要があります。

このシステムでは，システムが扱う資産（データ）のうち，次の資産を保護する必要があると判断しています。

システム管理者のユーザ情報

エンドユーザのユーザ情報

システム構築時の設定ファイル

J2EEアプリケーション

サービスを利用する中でエンドユーザが送信して，J2EEアプリケーションが処理した情報

監査ログ

保護する必要があると判断した資産については，使用できる権限を制御するなどの対策が必要です。対策の詳細については，「5.7　対策の検討」を参照してください。

5.5　セキュアなシステムの前提条件の確認

ここでは，セキュアなシステムの前提条件について説明します。

セキュアなシステムでは，ハードウェアの設置方法や作業者に関する前提条件の確認が必要になります。前提条件を把握した上で，Cosminexusが提供する機能やOSの機能などを使用して，想定される脅威に対する対策を実施します。

ここでは，次の二つの前提条件を想定します。

物理的な前提条件

運用上の前提条件

＜この節の構成＞

5.5.1　物理的な前提条件

5.5.2　運用上の前提条件

5.5.1　物理的な前提条件

セキュアなシステムを構築するための，物理的な前提条件を次に示します。

システムが稼働するハードウェア，ファイアウォール，それぞれのサーバ，および内部ネットワークが，外部から物理的に隔離されたサーバエリアに設置されていること。

施錠管理などによって，認証されたユーザ以外がサーバエリアに入室できないこと。

システムが稼働するために必要のないハードウェア，およびソフトウェアは，サーバエリア内には持ち込まれないこと。

5.5.2　運用上の前提条件

セキュアなシステムを構築するための運用上の前提条件を次に示します。

運用上の前提条件には，作業手順書，システム管理，システム運用，およびシステム監査に関する前提条件があります。それぞれの前提条件を次に示します。

作業手順書に関する前提条件

システムの構築手順は「システム構築手順書」に，システムの運用手順は「システム運用手順書」に，システムの操作手順は「エンドユーザ操作手順書」に記載されていること。

システム管理に関する前提条件

システムが稼働するために必要なサーバエリア内のハードウェア，ソフトウェア，およびJ2EEアプリケーションは，「システム構築手順書」に従ってシステム管理者が構築・設定すること。また，システム管理者は，信頼できる者が担当すること。

システム運用に関する前提条件

システムが稼働するために必要な，サーバエリア内のハードウェア，ソフトウェア，およびJ2EEアプリケーションは，システム運用者が運用すること。

システム監査に関する前提条件

システム監査を実施する監査者は，信頼できる者が担当すること。

5.6　想定される脅威の分析

「5.3　システムの使用者の検討」と「5.4　システムが扱う資産の検討」で検討した内容，および「5.5　セキュアなシステムの前提条件の確認」で確認した内容から，システムにはどんな脅威が想定されるかを分析します。

このシステムでは次の脅威が想定されます。

不正なユーザによるサービスの利用
システムに登録されていないエンドユーザがサービスを利用するおそれがあります。

手順書に従わないユーザによるサービスの利用
システムに登録されているユーザIDおよびパスワードを入手しているエンドユーザが，「エンドユーザ操作手順書」に従わないで，システムの脆弱性を利用してサービスを利用するおそれがあります。
また，システムに登録しているユーザが，権限のないサービスを利用するおそれがあります。

不正なシステム管理者によるシステム構築
システム管理者ではないユーザが，「入退室手順書」に従わないで不正にサーバエリアに入室してシステムを構築するおそれがあります。

不正なシステム運用者によるシステム運用
システム運用者ではないユーザが，「入退室手順書」に従わないで不正にサーバエリアに入室してシステムを運用するおそれがあります。

手順書に従わないシステム運用者によるシステム運用
システム運用者のManagement Serverの管理ユーザアカウントを使用して，「システム運用手順書」に従わない方法でシステムを運用するおそれがあります。

「5.7　対策の検討」で説明する対策を実施すると，これらの脅威からシステムを守れます。

「入退室手順書」，「システム構築手順書」，「システム運用手順書」，および「エンドユーザ操作手順書」の詳細については，「5.8　作業手順の検討」を参照してください。

5.7　対策の検討

この節では，実施する対策の内容と，対策を実施したシステムの動作について説明します。

実施する対策には，次の二つがあります。

前提条件に対して実施する対策
「5.5　セキュアなシステムの前提条件の確認」で確認した前提条件に対する対策です。

想定した脅威に対して実施する対策
「5.6　想定される脅威の分析」で想定した脅威に対する対策です。

それぞれについて次に示します。

＜この節の構成＞

5.7.1　前提条件に対して実施する対策

5.7.2　想定した脅威に対して実施する対策

5.7.3　対策を実施したセキュアなシステムの動作

5.7.1　前提条件に対して実施する対策

ここでは，「5.5　セキュアなシステムの前提条件の確認」で確認した前提条件に対して実施する，対策の内容について説明します。

「5.5　セキュアなシステムの前提条件の確認」で確認した前提条件と，実施する対策を次の表に示します。それぞれの前提条件の詳細については，「5.5　セキュアなシステムの前提条件の確認」を参照してください。

表5-1　前提条件と実施する対策

前提条件
対策

物理的な前提条件

物理的な対策

運用上の前提条件

システム管理者に対する対策

システム運用者に対する対策

システム監査者に対する対策

それぞれの対策の概要を次に示します。

＜この項の構成＞

(1)　物理的な前提条件に対する対策

(2)　運用上の前提条件に対する対策

(1)　物理的な前提条件に対する対策

物理的な前提条件に対する対策を次に示します。

物理的な対策

システム管理者は，システムが稼働するハードウェア，ファイアウォール，それぞれのサーバ，および内部ネットワークを，外部から物理的に隔離されたサーバエリアに設置します。

システム管理者は，システムが稼働するために必要のないハードウェア，およびソフトウェアを，サーバエリア内に持ち込まないようにします。

システム管理者，システム運用者，および監査者は，「入退室手順書」に従ってサーバエリアに入退室するようにします。

「入退室手順書」については，「5.8　作業手順の検討」を参照してください。

(2)　運用上の前提条件に対する対策

運用上の前提条件に対する対策を次に示します。

システム管理者に対する対策

システム管理者には，システム全体に責任を持っていて，悪意のある行為はしない，信頼できるユーザを選定すること。

システム管理者は，システムの構築および管理に関するトレーニングなどを実施して，システムの構築，および管理方法を熟知していること。また，システムで利用するそれぞれの機器の構築，および管理方法について熟知していること。

システム管理者は，セキュリティ面での注意点を考慮しながらシステムを構築および管理すること。

システム管理者は，自分のOSのパスワード，システム管理者のManagement Serverの管理パスワード，システム運用者のOSのパスワード，およびシステム運用者のManagement Serverの管理パスワードとして，推測されにくい十分に強度のあるパスワードを設定すること。

「システム構築手順書」については，「5.8　作業手順の検討」を参照してください。

システム運用者に対する対策

システム運用者は，システムの運用に関するトレーニングなどを実施して，システムの運用方法を熟知していること。

システム運用者は，セキュリティ面での注意点を考慮しながらシステムを運用すること。

システム運用者は，エンドユーザのパスワードとして，推測されにくい十分に強度のあるパスワードを設定すること。

「システム運用手順書」については，「5.8　作業手順の検討」を参照してください。

システム監査者に対する対策

監査者には，システム全体に責任を持っていて，悪意のある行為はしない，信頼できるユーザを選定すること。

監査者には，システム管理者以外のユーザを選定すること。

監査者は，システムの構築手順が正当であるかどうかを確認すること。また，運用手順が正当であるかどうかを監査すること。

5.7.2　想定した脅威に対して実施する対策

ここでは，「5.6　想定される脅威の分析」で想定した脅威に対して実施する，対策の内容について説明します。

このシステムで想定される脅威と，それぞれの脅威に対する対策を，対策を実施する対象者ごとに次の表に示します。それぞれの脅威の詳細については，「5.6　想定される脅威の分析」を参照してください。

表5-2　想定される脅威と実施する対策

対策の対象者
脅威
対策

システム管理者
不正なシステム管理者によるシステム構築

OSのユーザ識別・認証

システム運用者
不正なシステム運用者によるシステム運用

OSのユーザ識別・認証

システム運用者のユーザ識別・認証

手順書に従わないシステム運用者によるシステム運用

システムの監査ログ出力

J2EEアプリケーションの監査ログ出力

エンドユーザ
不正なユーザによるサービスの利用

J2EEアプリケーションの監査ログ出力

J2EEアプリケーションのユーザ識別・認証

手順書に従わないユーザによるサービスの利用

J2EEアプリケーションの監査ログ出力

J2EEアプリケーションのアクセス制御

それぞれの対策の概要を次に示します。

システム管理者を対象にした対策

OSのユーザ識別・認証
システム管理者だけがシステムを管理するように，システムが動作するOSのユーザ識別・認証を設定して，コマンドの実行権限を制御します。

システム運用者を対象にした対策

OSのユーザ識別・認証
システム運用者がシステムを運用するように，システムが動作するOSのユーザ識別・認証を設定して，コマンドの実行権限を制御します。

システム運用者のユーザ識別・認証
システム運用者がシステムを運用するように，システムでユーザ識別・認証をします。

システムの監査ログ出力
手順書に従った方法でシステムを運用したかどうかを監査するために，システムで監査ログを出力するようにします。

J2EEアプリケーションの監査ログ出力
手順書に従った方法でエンドユーザを管理したかどうかを監査するために，Cosminexusが提供する監査ログ出力用のAPIを使用してJ2EEアプリケーションを実装して，J2EEアプリケーションの監査ログを出力するようにします。監査ログ出力用のAPIを使用したJ2EEアプリケーションの実装方法については，マニュアル「Cosminexus　機能解説」の，アプリケーションの監査ログを出力するための実装についての説明を参照してください。

エンドユーザを対象にした対策

J2EEアプリケーションの監査ログ出力
正当なエンドユーザが手順書に従った方法でサービスを利用したかどうかを監査するために，Cosminexusが提供する監査ログ出力用のAPIを使用してJ2EEアプリケーションを実装して，J2EEアプリケーションの監査ログを出力するようにします。監査ログ出力用のAPIを使用したJ2EEアプリケーションの実装方法については，マニュアル「Cosminexus　機能解説」の，アプリケーションの監査ログを出力するための実装についての説明を参照してください。

J2EEアプリケーションのユーザ識別・認証
正当なエンドユーザだけがサービスを利用するように，J2EEアプリケーションにユーザ識別・認証機能を実装します。

J2EEアプリケーションのアクセス制御
アクセス権限を持っているエンドユーザだけが保護するべきデータにアクセスできるように，J2EEアプリケーションにアクセス制御機能を実装します。

5.7.3　対策を実施したセキュアなシステムの動作

ここでは，対策を実施したセキュアなシステムの動作について説明します。

対策を実施したシステムの動作の概要を次の図に示します。なお，図中に示した対策は，「5.7.2　想定した脅威に対して実施する対策」で説明した対策と対応しています。

図5-3　システム管理者の操作とシステムの動作

この図で示した，対策を実施したシステムの動作の概要を，システムの使用者ごとに説明します。

＜この項の構成＞

(1)　システム管理者・システム運用者の操作とシステムの動作

(2)　エンドユーザの操作とシステムの動作

(1)　システム管理者・システム運用者の操作とシステムの動作

システム管理者・システム運用者の操作とシステムの動作の概要について説明します。

システム管理者の操作

Smart Composer機能のコマンドを使用してアプリケーションサーバを構築します。ただし，J2EEアプリケーションの設定，リソースの設定などの作業は，サーバ管理コマンドを使用して実施します。

ユーザ識別・認証機能とアクセス制御機能，および監査ログを出力する機能を実装したアプリケーションを，デプロイ・開始します。

システム運用者の操作

Smart Composer機能のコマンドを使用してシステムを運用します。ただし，障害発生時のログの収集は，snapshotlogコマンドを使用して実施します。

システムの動作

コマンドの実行によるそれぞれの操作に対して監査ログを出力します。

ポイント

一部のコマンドは監査ログを出力しないため，使用するコマンドが監査ログを出力するコマンドかどうかを確認して作業を実施してください。監査ログを出力するコマンドについては，マニュアル「Cosminexus　システム運用ガイド」の，監査ログが出力されるコマンド一覧を参照してください。

(2)　エンドユーザの操作とシステムの動作

システムが提供するサービス利用時のエンドユーザの操作とシステム（J2EEアプリケーション）の動作の概要を次に示します。

エンドユーザの操作

クライアント端末のWebブラウザからHTTPリクエストをアプリケーションサーバへ送信します。

システム（J2EEアプリケーション）の動作

HTTPリクエストに含まれているユーザ情報を識別して，ユーザ認証をします。

アクセス制御機能を使用して，認証されたユーザにアクセス権があるかどうかをチェックします。

アクセス制御機能で許可されたリクエストがJ2EEアプリケーションのサービスを実行します。

処理の実行時に，監査ログを出力します。

5.8　作業手順の検討

この節では，セキュアなシステムを構築・運用するために，システムごとに検討する必要がある作業手順について説明します。

セキュアなシステムを構築・運用するには，それぞれの作業者が実施する作業の手順を明確にする必要があります。システムの監査では，監査ログと作業手順書を照合して，それぞれに矛盾がないかを調査します。作業手順書とは，システム構築，システム運用，エンドユーザによるサービスの利用などの作業について，正しい手順，方法を明文化した文書です。作業手順書は，それぞれのシステムに応じて作成する必要があります。作業者や操作内容の記録である監査ログと作業手順書を照合することで，正しい作業者が正しい手段・手順で作業を実施したかどうかが明確になります。これによって，システムの安全性を保てます。

作業手順書の作成では，それぞれの作業手順書に記載する作業とその手順・方法を検討する必要があります。監査の観点で，正しいユーザが正しい手順・方法で実施するように規定する必要がある作業を洗い出してください。また，それぞれの作業の手順では，必ず監査ログを出力するコマンドを使用して作業を実行するように規定してください。

＜この節の構成＞

5.8.1　作成する作業手順書の概要

5.8.2　システムの構築手順の検討

5.8.3　システムの再構築手順の検討

5.8.4　システムの運用手順の検討

5.8.1　作成する作業手順書の概要

ここでは，作成する必要がある作業手順書の概要について説明します。

作成する作業手順書は，システムによって異なります。このシステムでは，次の作業手順書を作成します。

入退室手順書
施錠管理がされているサーバエリアに入退室する手順が規定された文書です。

システム構築手順書
システムを構築する手順が規定された文書です。記載する手順は，「5.8.2　システムの構築手順の検討」および「5.8.3　システムの再構築手順の検討」で説明している手順を基に作成します。
なお，「5.8.2　システムの構築手順の検討」，および「5.8.3　システムの再構築手順の検討」で説明している手順では，システム管理者はSmart Composer機能のコマンドおよびサーバ管理コマンドを使用して操作を実行しています。また，すべての操作に，監査ログが出力されるコマンドを使用しています。

システム運用手順書
システムを運用する手順が規定された文書です。記載する手順は，「5.8.4　システムの運用手順の検討」で説明している手順を基に作成します。
なお，「5.8.4　システムの運用手順の検討」で説明している手順では，システム運用者はSmart Composer機能のコマンド，およびsnapshotlogコマンドを使用して操作を実行しています。

エンドユーザ操作手順書
システムが提供するサービスを利用する手順が規定された文書です。

5.8.2　システムの構築手順の検討

ここでは，「システム構築手順書」に記載するシステムの構築手順の例について説明します。「システム構築手順書」を作成するときは，ここで説明している手順を参考にしてください。

セキュアなシステムの構築には，Smart Composer機能のコマンド，およびサーバ管理コマンドを使用します。また，すべての操作に，実行時に監査ログが出力されるコマンドを使用します。ここで説明している以外の操作を作業手順書に記載する場合も，監査ログが出力されるコマンドを使用する方法を記載してください。監査ログが出力されるコマンドについては，マニュアル「Cosminexus　システム運用ガイド」の，監査ログが出力されるコマンド一覧を参照してください。

なお，この項で説明する手順は，すべてシステム管理者が実行します。

＜この項の構成＞

(1)　ハードウェアの設置

(2)　OSのインストール

(3)　システムの管理の開始

(4)　監査ログを出力するための設定

(5)　負荷分散機およびデータベースの設定

(6)　運用管理サーバの設定

(7)　Webシステムの構成定義

(8)　Webシステムの準備

(9)　リソースアダプタの設定

(10)　J2EEアプリケーションの確認

(11)　J2EEアプリケーションの設定

(12)　Webシステムの開始

(13)　不要な機能の無効化

(14)　システム運用者の登録

(1)　ハードウェアの設置

システム管理者が，ハードウェアを設置します。ハードウェアを設置する手順を次に示します。

「入退室手順書」に従って，外部から物理的に隔離されたサーバエリアに入室します。

システムが稼働するハードウェア，およびファイアウォールをサーバエリア内に設置します。

なお，「システム構築手順書」では，ハードウェア，およびファイアウォールを設置する手順の詳細を規定してください。

(2)　OSのインストール

システム管理者が，システムで使用するOSのインストールを実施します。OSをインストールする手順を次に示します。

OSのインストール，およびIPアドレス・ホスト名の設定などの，ネットワークの接続に必要な設定をします。

システムに必要なセキュリティパッチを適用します。

システムに必要なソフトウェアをインストールして，環境変数を設定します。

システム管理者用のOSのアカウントを作成して，管理者権限を付与します。

監査者用のOSのアカウントを作成して，安全な手段で監査者へ通知します。

(3)　システムの管理の開始

システム管理者が，「(2) OSのインストール」で設定したシステム管理者用のOSのアカウントを使用してOSにログインします。

(4)　監査ログを出力するための設定

システム管理者が，運用管理サーバおよびアプリケーションサーバの端末で監査ログを出力するための設定をします。監査ログを出力するための設定をする手順を次に示します。

システム構成を基に，ログファイルのサイズを決定します。

システム管理者，およびシステム運用者に，監査ログファイルに対する読み取り権限と書き込み権限を設定します。また，監査者に監査ログファイルに対する読み取り権限を設定します。

手順1.および手順2.で決定，および設定した内容を監査ログ定義ファイル（auditlog.properties）に反映します。

監査ログ定義ファイルに指定した監査ログ出力ディレクトリを作成します。

システム管理者，およびシステム運用者に，手順4.で作成した監査ログ出力ディレクトリに対する読み取り権限と書き込み権限を設定します。また，監査者に，手順4.で作成した監査ログ出力ディレクトリに対する読み取り権限を設定します。

セットアップコマンド（auditsetupコマンド）を実行します。

(5)　負荷分散機およびデータベースの設定

システム管理者が，負荷分散機およびデータベースをサーバエリア内に設置して，負荷分散機およびデータベースを設定します。

なお，「システム構築手順書」では，負荷分散機およびデータベースの設定手順の詳細を規定してください。

(6)　運用管理サーバの設定

システム管理者が，運用管理サーバの初期設定をします。運用管理サーバを設定する手順を次に示します。

mngsvrctlコマンドで，引数「setup」を指定して，Management Serverのセットアップ，およびManagement Serverの管理ユーザアカウントの設定をします。

mngautorunコマンドで，引数「server」を指定して，Management Serverの自動起動の設定をします。

(7)　Webシステムの構成定義

システム管理者が，Webシステムの構成を定義します。Webシステムの構成を定義する手順を次に示します。

mngsvrctlコマンドで，引数「start」を指定して，Management Serverを起動します。

簡易構築定義ファイルを編集して保存します。

adminagentctlコマンドで引数「start」を指定して，それぞれのアプリケーションサーバで運用管理エージェントを起動します。

運用管理サーバでcmx_build_systemコマンドを使用して，Webシステムを構築します。

(8)　Webシステムの準備

システム管理者が，運用管理サーバの管理者端末でSmart Composer機能のコマンドを使用して，Webシステムの準備をします。Webシステムを準備する手順を次に示します。

cmx_start_targetコマンドを使用して，Webシステムを準備状態にします。

cmx_list_statusコマンドを使用して，Webシステム内のサービスユニットが準備状態であることを確認します。

(9)　リソースアダプタの設定

システム管理者が，運用管理サーバの管理者端末でサーバ管理コマンドを使用して，データベースと連携するアプリケーションに必要なリソースアダプタを設定します。リソースアダプタを設定する手順を次に示します。

次のディレクトリから，使用するリソースアダプタのConnector属性ファイルのテンプレートをコピーします。

Windowsの場合

<Cosminexusインストールディレクトリ>¥CC¥admin¥templates¥

UNIXの場合

/opt/Cosminexus/CC/admin/templates/

手順1.でコピーしてきたConnector属性ファイルのテンプレートを編集します。

cjimportresコマンドを使用して，リソースアダプタをインポートします。

cjsetrespropコマンドを使用して，Connector属性ファイルの編集内容をリソースアダプタに反映します。

cjdeployrarコマンドを使用して，リソースアダプタをデプロイします。

cjtestresコマンドを使用して，リソースアダプタの接続テストを実施します。

(10)　J2EEアプリケーションの確認

システム管理者が，「5.7.2　想定した脅威に対して実施する対策」で説明した対策がJ2EEアプリケーションに施されているかを確認します。ここでは，「5.7.2　想定した脅威に対して実施する対策」で説明した対策のうち，次の対策について確認します。

J2EEアプリケーションの監査ログ出力

J2EEアプリケーションのユーザ識別・認証

J2EEアプリケーションのアクセス制御

具体的には，J2EEアプリケーションが次の仕様を満たしているかどうかを確認してください。

システム運用者によってエンドユーザのユーザID・パスワードを登録，および削除するための機能がある。

ユーザID・パスワードの識別・認証機能がある。

提供するサービスに対するアクセス制御機能がある。

ユーザがサービスを利用するときに，監査ログを出力する機能がある。

(11)　J2EEアプリケーションの設定

システム管理者が，運用管理サーバの管理者端末でサーバ管理コマンドを使用して，J2EEアプリケーションを設定します。J2EEアプリケーションを設定する手順を次に示します。

cjimportappコマンドを使用して，J2EEアプリケーションをインポートします。

cjgetapppropコマンドを使用して，アプリケーション統合属性ファイルを取得します。

手順2.で取得したアプリケーション統合属性ファイルを編集します。

cjsetapppropコマンドを使用して，アプリケーション統合属性ファイルの編集内容をJ2EEアプリケーションに反映します。

注意

ここでは，実行時情報を持たないJ2EEアプリケーションを設定する手順について説明しています。実行時情報を持つJ2EEアプリケーションを設定する場合は，手順1.でJ2EEアプリケーションをインポートしたあとに，cjstopappコマンドを使用してJ2EEアプリケーションを停止してから，手順2.に進んでください。

(12)　Webシステムの開始

システム管理者が，運用管理サーバの管理者端末でSmart Composer機能のコマンドとサーバ管理コマンドを使用して，Webシステムを開始します。Webシステムを開始する手順を次に示します。

cjstartrarコマンドを使用して，リソースアダプタを開始します。

cjstartappコマンドを使用して，J2EEアプリケーションを開始します。

cmx_start_targetコマンドを使用して，Webシステム内のサービスユニットを稼働状態にします。

(13)　不要な機能の無効化

不正なユーザによって不要な機能を使用されないように，機能を無効化します。具体的には，システム管理者が，コマンドの実行権限を変更したり，コマンドの実行に必要なファイルを削除したりします。無効化する必要がある機能を，Windowsの場合とUNIXの場合に分けて，次の表に示します。

表5-3　無効化する必要がある機能（Windowsの場合）

機能名 | 対象ディレクトリ | 対象ファイル | 対処
Hitachi Web ServerのGUIサーバ管理機能 | <Cosminexusのインストールディレクトリ>¥httpsd | adm-httpsd.exe | システム管理者以外の実行権限を解除します。
Hitachi Web Serverのパスワードファイル編集コマンド | <Cosminexusのインストールディレクトリ>¥httpsd¥bin | htpasswd.exe | システム管理者以外の実行権限を解除します。
CTMのスケジュールキューの同時実行数の変更 | <Cosminexusのインストールディレクトリ>¥CTM¥bin | ctmchpara.exe | システム管理者以外の実行権限を解除します。
CTMのCTMドメインの情報表示と削除 | <Cosminexusのインストールディレクトリ>¥CTM¥bin | ctmdminfo.exe | システム管理者以外の実行権限を解除します。
CTMのスケジュールキューの閉塞 | <Cosminexusのインストールディレクトリ>¥CTM¥bin | ctmholdque.exe | システム管理者以外の実行権限を解除します。
CTMの実行形式ファイルおよびライブラリのバージョン情報の出力 | <Cosminexusのインストールディレクトリ>¥CTM¥bin | ctmjver.exe | システム管理者以外の実行権限を解除します。
CTMのメッセージの編集と出力 | <Cosminexusのインストールディレクトリ>¥CTM¥bin | ctmlogcat.exe | システム管理者以外の実行権限を解除します。
CTMのスケジュールキュー情報の出力 | <Cosminexusのインストールディレクトリ>¥CTM¥bin | ctmlsque.exe | システム管理者以外の実行権限を解除します。
CTMのスケジュールキューの閉塞解除 | <Cosminexusのインストールディレクトリ>¥CTM¥bin | ctmrlesque.exe | システム管理者以外の実行権限を解除します。
CTMの稼働統計情報の編集と出力 | <Cosminexusのインストールディレクトリ>¥CTM¥bin | ctmstsed.exe | システム管理者以外の実行権限を解除します。
CTMのバッファ内容の強制ファイル出力 | <Cosminexusのインストールディレクトリ>¥CTM¥bin | ctmstsflush.exe | システム管理者以外の実行権限を解除します。
CTMの実行形式ファイルおよびライブラリのバージョン情報の出力 | <Cosminexusのインストールディレクトリ>¥CTM¥bin | ctmver.exe | システム管理者以外の実行権限を解除します。
PRFの性能解析トレース情報の編集出力 | <Cosminexusのインストールディレクトリ>¥PRF¥bin | cprfed.exe | システム管理者以外の実行権限を解除します。
PRFのバッファ内容の強制ファイル出力 | <Cosminexusのインストールディレクトリ>¥PRF¥bin | cprfflush.exe | システム管理者以外の実行権限を解除します。
PRFトレース取得レベルの表示と変更 | <Cosminexusのインストールディレクトリ>¥PRF¥bin | cprflevel.exe | システム管理者以外の実行権限を解除します。
Management Serverで使用するコマンド | <Cosminexusのインストールディレクトリ>¥manager¥bin | mngsvrutil.exe | システム管理者以外の実行権限を解除します。
<Cosminexusのインストールディレクトリ>¥manager¥bin | mstrexport.exe | システム管理者以外の実行権限を解除します。
<Cosminexusのインストールディレクトリ>¥manager¥bin | mstrimport.exe | システム管理者以外の実行権限を解除します。
<Cosminexusのインストールディレクトリ>¥manager¥bin | ssoexport.exe | システム管理者以外の実行権限を解除します。
<Cosminexusのインストールディレクトリ>¥manager¥bin | ssogenkey.exe | システム管理者以外の実行権限を解除します。
<Cosminexusのインストールディレクトリ>¥manager¥bin | ssoimport.exe | システム管理者以外の実行権限を解除します。
<Cosminexusのインストールディレクトリ>¥manager¥bin | uachpw.exe | システム管理者以外の実行権限を解除します。
<Cosminexusのインストールディレクトリ>¥manager¥bin | mngsvr_adapter_setup.exe | このコマンドを実行しないようにします。
<Cosminexusのインストールディレクトリ>¥manager¥bin | Adapter_HITACHI_COSMINEXUS_MANAGER.exe | システム管理者以外の実行権限を解除します。
<Cosminexusのインストールディレクトリ>¥manager¥externals¥jp1¥mngsvrmonitor | mngsvr_monitor_setup.exe | このコマンドを実行しないようにします。
運用管理ポータル | <Cosminexusのインストールディレクトリ>¥manager¥containers¥m¥webapps¥mngsvr | index.jsp | ファイルを削除します。
<Cosminexusのインストールディレクトリ>¥manager¥containers¥m¥webapps¥mngsvr | login.jsp | ファイルを削除します。
Server Plug-in | <Cosminexusのインストールディレクトリ>¥manager¥config | mserver.properties | Server Plug-inの設定をしないようにします。

表5-4　無効化する必要がある機能（UNIXの場合）

機能名 | 対象ディレクトリ | 対象ファイル | 対処
Hitachi Web ServerのGUIサーバ管理機能 | /opt/hitachi/httpsd/sbin | adminctl | システム管理者以外の実行権限を解除します。
/opt/hitachi/httpsd/sbin | adm-httpsd | システム管理者以外の実行権限を解除します。
Hitachi Web Serverのパスワードファイル編集コマンド | /opt/hitachi/httpsd/bin | htpasswd | システム管理者以外の実行権限を解除します。
CTMのスケジュールキューの同時実行数の変更 | /opt/Cosminexus/CTM/bin | ctmchpara | システム管理者以外の実行権限を解除します。
CTMのCTMドメイン情報の表示と削除 | /opt/Cosminexus/CTM/bin | ctmdminfo | システム管理者以外の実行権限を解除します。
CTMのスケジュールキューの閉塞 | /opt/Cosminexus/CTM/bin | ctmholdque | システム管理者以外の実行権限を解除します。
CTMの実行形式ファイルおよびライブラリのバージョン情報の出力 | /opt/Cosminexus/CTM/bin | ctmjver | システム管理者以外の実行権限を解除します。
CTMのメッセージの編集と出力 | /opt/Cosminexus/CTM/bin | ctmlogcat | システム管理者以外の実行権限を解除します。
CTMのスケジュールキュー情報の出力 | /opt/Cosminexus/CTM/bin | ctmlsque | システム管理者以外の実行権限を解除します。
CTMのスケジュールキューの閉塞解除 | /opt/Cosminexus/CTM/bin | ctmrlesque | システム管理者以外の実行権限を解除します。
CTMの稼働統計情報の編集と出力 | /opt/Cosminexus/CTM/bin | ctmstsed | システム管理者以外の実行権限を解除します。
CTMのバッファ内容の強制ファイル出力 | /opt/Cosminexus/CTM/bin | ctmstsflush | システム管理者以外の実行権限を解除します。
CTMの実行形式ファイルおよびライブラリのバージョン情報の出力 | /opt/Cosminexus/CTM/bin | ctmver | システム管理者以外の実行権限を解除します。
PRFの性能解析トレース情報の編集出力 | /opt/Cosminexus/PRF/bin | cprfed | システム管理者以外の実行権限を解除します。
PRFのバッファ内容の強制ファイル出力 | /opt/Cosminexus/PRF/bin | cprfflush | システム管理者以外の実行権限を解除します。
PRFトレース取得レベルの表示と変更 | /opt/Cosminexus/PRF/bin | cprflevel | システム管理者以外の実行権限を解除します。
Management Serverで使用するコマンド | /opt/Cosminexus/manager/bin | mngsvrutil | システム管理者以外の実行権限を解除します。
/opt/Cosminexus/manager/bin | mstrexport | システム管理者以外の実行権限を解除します。
/opt/Cosminexus/manager/bin | mstrimport | システム管理者以外の実行権限を解除します。
/opt/Cosminexus/manager/bin | ssoexport | システム管理者以外の実行権限を解除します。
/opt/Cosminexus/manager/bin | ssogenkey | システム管理者以外の実行権限を解除します。
/opt/Cosminexus/manager/bin | ssoimport | システム管理者以外の実行権限を解除します。
/opt/Cosminexus/manager/bin | uachpw | システム管理者以外の実行権限を解除します。
/opt/Cosminexus/manager/bin | mngsvr_adapter_setup | システム管理者以外の実行権限を解除します。
/opt/Cosminexus/manager/bin | Adapter_HITACHI_COSMINEXUS_MANAGER | システム管理者以外の実行権限を解除します。
運用管理ポータル | /opt/Cosminexus/manager/containers/m/webapps/mngsvr | index.jsp | ファイルを削除します。
/opt/Cosminexus/manager/containers/m/webapps/mngsvr | login.jsp | ファイルを削除します。
Server Plug-in | /opt/Cosminexus/manager/config | mserver.properties | Server Plug-inの設定をしないようにします。

(14)　システム運用者の登録

システム管理者が，運用管理サーバの管理者端末でOSの機能，およびSmart Composer機能のコマンドを使用して，システム運用者のユーザIDとパスワードを設定します。また，設定したユーザIDとパスワードをシステム運用者に通知します。システム運用者を登録する手順を次に示します。

OSの機能を使用して，システム運用者のOSのユーザIDとパスワードを設定します。

OSの機能を使用して，システム運用者に管理者権限を与えないよう設定します。

cmx_admin_passwdコマンドを使用して，システム管理者のManagement Serverの管理ユーザIDと管理パスワードを，システム運用者のManagement Serverの管理ユーザIDと管理パスワードに変更します。

手順1.および手順3.で設定したユーザIDとパスワードを安全な手段でシステム運用者へ通知します。

5.8.3　システムの再構築手順の検討

ここでは，「システム構築手順書」に記載するシステムの再構築手順の例について説明します。「システム構築手順書」を作成するときは，ここで説明している手順を参考にしてください。

セキュアなシステムの再構築には，Smart Composer機能のコマンド，およびサーバ管理コマンドを使用します。また，すべての操作に，実行時に監査ログが出力されるコマンドを使用します。ここで説明している以外の操作を作業手順書に記載する場合も，監査ログが出力されるコマンドを使用する方法を記載してください。監査ログが出力されるコマンドについては，マニュアル「Cosminexus　システム運用ガイド」の，監査ログが出力されるコマンド一覧を参照してください。

なお，この項で説明する手順は，すべてシステム管理者が実行します。

＜この項の構成＞

(1)　J2EEアプリケーションの入れ替え

(2)　システムのチューニング

(3)　システム構成の変更（サービスユニットの追加）

(4)　システム構成の変更（サービスユニットの削除）

(1)　J2EEアプリケーションの入れ替え

システム管理者が，メンテナンスが必要な場合などにJ2EEアプリケーションを入れ替えます。J2EEアプリケーションを入れ替える手順を次に示します。

cmx_stop_targetコマンドを使用して，Webシステム内のサービスユニットを準備状態にします。

cjstopappコマンドを使用して，入れ替え前のJ2EEアプリケーションを停止します。

cjdeleteappコマンドを使用して，入れ替え前のJ2EEアプリケーションを削除します。

cjimportappコマンドを使用して，入れ替え後のJ2EEアプリケーションをインポートします。

cjgetapppropコマンドを使用して，入れ替え後のJ2EEアプリケーションのアプリケーション統合属性ファイルを取得します。

手順5.で取得したアプリケーション統合属性ファイルを編集して，J2EEアプリケーションに必要な情報を設定します。また，必要に応じてJ2EEアプリケーションをカスタマイズします。

cjsetapppropコマンドを使用して，手順6.で編集したアプリケーション統合属性ファイルを，入れ替え後のJ2EEアプリケーションに反映します。

cjstartappコマンドを使用して，入れ替え後のJ2EEアプリケーションを開始します。

cmx_start_targetコマンドを使用して，Webシステム内のサービスユニットを稼働状態にします。

なお，J2EEアプリケーションの入れ替えには，この手順のほかに，cjreplaceappコマンドを使用したリデプロイ機能，またはcjreloadappコマンドを使用したリロード機能を使用することもできます。

(2)　システムのチューニング

システム管理者が，必要に応じてシステムをチューニングします。システムをチューニングする手順を次に示します。

簡易構築定義ファイルを編集します。

cmx_stop_targetコマンドを使用して，Webシステム内のサービスユニットを停止します。

cmx_build_systemコマンドを使用して，Webシステムの設定を変更します。

cmx_start_targetコマンドを使用して，Webシステム内のサービスユニットを起動します。

(3)　システム構成の変更（サービスユニットの追加）

システム管理者が，必要に応じてサービスユニットを追加してシステム構成を変更します。サービスユニットを追加してシステム構成を変更する手順を次に示します。

構成変更定義ファイルを作成・編集します。

cmx_change_modelコマンドを使用して，Management ServerのWebシステムの情報モデルを変更します。

cmx_build_systemコマンドを使用して，変更したWebシステムの情報モデルを適用します。

cmx_start_targetコマンドを使用して，追加するWebシステム内のサービスユニットを準備状態にします。

cjstartrarコマンドを使用して，リソースアダプタを開始します。

cjstartappコマンドを使用して，J2EEアプリケーションを開始します。

cmx_start_targetコマンドを使用して，追加するWebシステム内のサービスユニットを稼働状態にします。

(4)　システム構成の変更（サービスユニットの削除）

システム管理者が，必要に応じてサービスユニットを削除してシステム構成を変更します。サービスユニットを削除してシステム構成を変更する手順を次に示します。

cmx_stop_targetコマンドを使用して，削除するWebシステム内のサービスユニットを停止します。

cmx_delete_systemコマンドを使用して，手順1.で指定したWebシステム内のサービスユニットを削除します。

5.8.4　システムの運用手順の検討

ここでは，「システム運用手順書」に記載するシステムの運用手順の例について説明します。「システム運用手順書」を作成するときは，ここで説明している手順を参考にしてください。

セキュアなシステムの運用には，Smart Composer機能のコマンド，およびsnapshotlogコマンドを使用します。ここで説明している以外の操作を作業手順書に記載する場合も，監査ログが出力されるコマンドを使用する方法を記載してください。監査ログが出力されるコマンドについては，マニュアル「Cosminexus　システム運用ガイド」の，監査ログが出力されるコマンド一覧を参照してください。

なお，この項で説明する手順のうち，Webシステムの起動の作業の一部，およびWebシステムのメンテナンス以外は，システム運用者が実行します。Webシステムのメンテナンスは，システム運用者に依頼されたシステム管理者が実行します。

＜この項の構成＞

(1)　Webシステムの起動

(2)　Webシステムの停止

(3)　エンドユーザの管理

(4)　エンドユーザへの通知

(5)　Webシステムのメンテナンス

(6)　システムの障害対応

(1)　Webシステムの起動

システム運用者が，運用管理サーバの管理者端末でWebシステムを起動します。ただし，リソースアダプタおよびJ2EEアプリケーションの起動は，システム管理者が，サーバ管理コマンドを使用して実行します。Webシステムを起動する手順を次に示します。

システム運用者が，cmx_start_targetコマンドを使用して，Webシステム内のサービスユニットを準備状態にします。

システム運用者が，システム管理者にサービスの起動を依頼します。

システム管理者が，cjstartrarコマンドを使用して，リソースアダプタを開始します。

システム管理者が，cjstartappコマンドを使用して，J2EEアプリケーションを開始します。

システム運用者が，cmx_start_targetコマンドを使用して，Webシステム内のサービスユニットを稼働状態にします。

(2)　Webシステムの停止

システム運用者が，運用管理サーバの管理者端末でSmart Composer機能のコマンドを使用して，Webシステムを停止します。Webシステムを停止する手順を次に示します。

cmx_stop_targetコマンドを使用して，Webシステム内のサービスユニットを停止状態にします。

(3)　エンドユーザの管理

システム運用者が，「システム運用手順書」に従って，エンドユーザのアクセス権やユーザIDなどを管理します。次の作業を実施します。

エンドユーザの登録，削除

エンドユーザの権限の変更

エンドユーザのパスワード変更

なお，「システム運用手順書」では，これらの手順の詳細を規定してください。

(4)　エンドユーザへの通知

システム運用者が，「(3) エンドユーザの管理」で登録したエンドユーザのユーザIDとパスワードをエンドユーザに通知します。ユーザIDとパスワードをエンドユーザに通知する手順を次に示します。

「システム運用手順書」に従って登録したエンドユーザのユーザIDとパスワードを使用して，サービスを利用できることを確認します。

サービス利用時に，監査ログが出力されることを確認します。

手順1.および手順2.の確認が終わったら，システム運用者がエンドユーザにユーザIDとパスワードを安全な手段で通知します。

(5)　Webシステムのメンテナンス

必要に応じてWebシステムをメンテナンスします。Webシステムのメンテナンスは，システム運用者に依頼されたシステム管理者が実施します。Webシステムをメンテナンスする手順を次に示します。

システム運用者が，cmx_stop_targetコマンドを使用して，メンテナンスするサービスユニットを閉塞，または停止します。

Cosminexusの修正パッチを適用する場合，システム運用者がCosminexus関連のプログラムを停止します。修正パッチを適用しない場合は，手順3.に進みます。

システム管理者にシステムのメンテナンスを依頼します。

システム管理者が，システム管理者用のユーザIDで，OSにログインします。

システム管理者がOSのサービスパック，セキュリティパッチ，Cosminexusの修正パッチなどを適用します。この作業をシステム管理者が実施しているとき，システム運用者はその場に立ち会う必要があります。

Cosminexusの修正パッチを適用した場合，システム運用者がCosminexus関連のプログラムを再開します。

システム運用者が，cmx_start_targetコマンドを使用して，サービスユニットを再開します。

(6)　システムの障害対応

障害発生時に，システム運用者が障害に対応します。システムの障害に対応する手順を次に示します。

snapshotlogコマンドを使用して，Cosminexusのログを収集します。

必要に応じて，snapshotlogコマンドで収集できないログを個別に収集します。

収集したログを保守員に送付して，調査を依頼します。

調査の結果に基づいてシステムをメンテナンスします。

5.9　システムの監査方法の確認

この節では，システムの監査方法について説明します。

システムの監査では，監査者がそれぞれの作業手順書と監査ログに出力されている操作の記録を照合して，正しい作業者が正しい手順で作業を実行しているかどうかを調査します。

＜この節の構成＞

5.9.1　監査ログの入手

5.9.2　監査ログの調査

5.9.1　監査ログの入手

監査ログを入手する手順について次に示します。

監査者が，「入退室手順書」に従って外部から物理的に隔離されたサーバエリアに入室します。

監査者が，監査ログサーバにログインして，各種サーバが稼働しているマシンから監査ログを入手します。

5.9.2　監査ログの調査

監査ログの調査では，次の点を確認します。

信頼できるシステム管理者が正しい方法でシステムを構築しているか
監査ログに出力された時刻，操作者，事象内容，および結果と，「システム構築手順書」の内容に相違がないことを確認します。

正しい方法で構築されたシステムが，正しく運用，および利用されているか
監査ログに出力された時刻，操作者，事象内容，および結果と，「システム運用手順書」および「エンドユーザ操作手順書」に相違がないことを確認します。

監査ログの調査方法，および監査ログに出力されるメッセージの詳細については，次のマニュアルを参照してください。

監査ログの調査方法
マニュアル「Cosminexus　システム運用ガイド」の監査ログの収集と調査についての説明を参照してください。

監査ログに出力されるメッセージの詳細
マニュアル「Cosminexus メッセージ 1 KAWS／KDAL／KDJE編」，マニュアル「Cosminexus メッセージ 2 KEOS／KEUC／KFCB編」，およびマニュアル「Cosminexus メッセージ 3 KFCT／KFDB／KFDJ編」を参照してください。

5.10　外部ネットワークを使用するシステムでのセキュリティの検討

この節では，外部ネットワークを使用するシステムで想定されるセキュリティ上の脅威とその対策について説明します。

＜この節の構成＞

5.10.1　外部ネットワークを使用するシステムで想定されるセキュリティ上の脅威

5.10.2　ファイアウォールと侵入検知システムを配置する

5.10.3　SSLアクセラレータを使用して暗号通信を処理する

5.10.4　アプリケーションでユーザを認証する

5.10.1　外部ネットワークを使用するシステムで想定されるセキュリティ上の脅威

ここでは，外部ネットワークを使用するシステムで想定されるセキュリティ上の脅威について説明します。

＜この項の構成＞

(1)　想定するセキュリティ上の脅威

(2)　考えられる対策

(1)　想定するセキュリティ上の脅威

ネットワークを使用するシステムでは，セキュリティ対策が十分でないと，アプリケーションを不正に実行されたり，通信内容やバックエンドのデータベースで管理しているデータが漏洩または改ざんされたりするおそれがあります。これらを防ぐためには，セキュリティ上の脅威を認識して，それらに十分に対策しておく必要があります。

ここでは，次のようなセキュリティ上の脅威を想定します。

システム外からシステムへの第三者の不正侵入

アプリケーションの扱うデータの第三者への漏洩

アプリケーションの通信内容の第三者への漏洩

アプリケーションの通信内容の第三者による改ざん

システム利用者の許可された権限の範囲を超えた操作や情報の入手

なお，ここでは，システム外部からの脅威を想定した対策について検討します。システム内部の脅威については，ここでは対象にしません。

(2)　考えられる対策

想定したセキュリティ上の脅威に対しては，それぞれ，次の表に示すような対策が考えられます。それぞれの具体的な対策方法については，参照先の説明を参照してください。

表5-5　セキュリティ上の脅威に対して考えられる対策

脅威 | 対策 | 参照先
システム外からシステムへの第三者の不正侵入 | ファイアウォールと侵入検知システムを配置する | 5.10.2
アプリケーションの扱うデータの第三者への漏洩
アプリケーションの通信内容の第三者への漏洩 | 通信内容を暗号化する | 5.10.3※
アプリケーションの通信内容の第三者による改ざん
システム利用者の許可された権限の範囲を超えた操作や情報の入手 | アプリケーションでユーザを認証する | 5.10.4

注※　通信内容の暗号化には，HTTPSを使用します。参照先では，HTTPSを使用する場合に，SSLアクセラレータを使用して暗号通信を処理する方法について説明します。

5.10.2　ファイアウォールと侵入検知システムを配置する

ここでは，ファイアウォールと侵入検知システムを適切に配置，設定することでシステムのセキュリティを向上させる方法について説明します。

＜この項の構成＞

(1)　ファイアウォールと侵入検知システムを配置する目的

(2)　基本的なWebクライアント構成の場合

(3)　基本的なEJBクライアント構成の場合

(4)　サーバの層ごとにファイアウォールで区切る構成（アプリケーション集中型）

(5)　サーバの層ごとにファイアウォールで区切る構成（アプリケーション分散型）

(1)　ファイアウォールと侵入検知システムを配置する目的

ファイアウォールは，外部のネットワークと内部のネットワーク間のアクセスを制御します。あらかじめアクセスを許可するクライアントや通信を特定し，決められたルールに従って通信を許可したり破棄したりすることで，外部ネットワークからの不正なアクセスを防止します。このため，ファイアウォールを使用する場合は，通信を許可するポートやIPアドレスを明確にして，設定しておく必要があります。

侵入検知システム（IDS）は，通信回線を監視して，通信パターンによって不正なアクセスを判断します。

ファイアウォールと侵入検知システムを適切な個所に配置，設定することで，次のようなセキュリティ上の脅威からシステムを守れます。

システム外からシステムへの第三者の不正侵入

アプリケーションの扱うデータの第三者への漏洩

ここでは，次の表に示すシステム構成ごとのファイアウォールと侵入検知システムの配置個所，および設定するときに留意することについて説明します。

表5-6　ファイアウォールと侵入検知システムの配置を検討するためのシステム構成の分類

システム構成 | 説明 | 参照先
基本的なWebクライアント構成 | 1台のアプリケーションサーバで構成されるシステム構成です。クライアントはWebブラウザです。 | 5.10.2(2)
基本的なEJBクライアント構成 | 1台のアプリケーションサーバで構成されるシステム構成です。クライアントはEJBクライアントアプリケーションです。 | 5.10.2(3)
サーバの層ごとにファイアウォールで区切る構成（アプリケーション集中型） | 複数のアプリケーションサーバで構成されるシステム構成で，サーバの層ごとにファイアウォールで区切る構成です。アプリケーションはすべて同じ層のアプリケーションサーバ上で動作します。 | 5.10.2(4)
サーバの層ごとにファイアウォールで区切る構成（アプリケーション分散型） | 複数のアプリケーションサーバで構成されるシステム構成で，サーバの層ごとにファイアウォールで区切る構成です。アプリケーションは異なる複数の層のアプリケーションサーバ上で動作します。 | 5.10.2(5)

なお，インターネットと接続するシステムの場合は，外部ネットワークから直接内部ネットワークのアプリケーションサーバにアクセスされないように，DMZを確保して，リバースプロキシを使用した構成を検討することをお勧めします。

(2)　基本的なWebクライアント構成の場合

ここでは，1台のアプリケーションサーバで構成される基本的なWebクライアント構成の場合のファイアウォールと侵入検知システムの配置個所について説明します。

ファイアウォールは，ネットワークから見てアプリケーションサーバの手前に配置します。この構成の場合，ネットワーク上のWebクライアントは，ファイアウォール経由でだけアプリケーションサーバにアクセスできます。

基本的なWebクライアント構成の場合のファイアウォールと侵入検知システムの配置例を次の図に示します。

図5-4　基本的なWebクライアント構成でのファイアウォールと侵入検知システムの配置例

(a)　アプリケーションサーバの設定

アプリケーションサーバでは，次の項目を設定します。

J2EEサーバの管理用通信ポートのアドレス指定
J2EEサーバの管理用通信ポートにアクセスできるアドレスを指定します。

Management Serverおよび運用管理エージェントのアドレス指定
Management Serverおよび運用管理エージェントにアクセスできるアドレスを指定します。

(b)　ファイアウォールの設定

外部ネットワークとアプリケーションサーバ内のWebサーバ（Hitachi Web Server）のアクセスについて制御するために，次の項目を設定します。

外部ネットワークからのWebサーバに対してのアクセス許可
ファイアウォールの外部のネットワークとアプリケーションサーバ間の通信では，公開ポートであるHTTP/80やHTTPS/443などだけを許可するようにします。ただし，システム構成によっては，DNSなど，そのほかの通信を必要に応じて許可してください。

アクセスを許可するWebクライアントのIPアドレスの限定（任意）
ファイアウォールの機能を使用してアクセスを許可するWebクライアントのIPアドレスを限定することで，そのシステムの利用者を特定できます。この場合は，ファイアウォールに通信を許可するIPアドレスを指定してください。

Management Serverおよび運用管理エージェントの通信ポートの指定
Management Serverおよび運用管理エージェントの通信ポートについては，ファイアウォールの外部からはアクセスできないように通信を遮断してください。これらの通信ポートにアクセスできると，運用管理者以外の外部のユーザからアプリケーションサーバに対して不正な運用操作が実行されるおそれがあります。

(c)　侵入検知システムの設定

外部ネットワークとアプリケーションサーバ内のWebサーバ（Hitachi Web Server）の公開ポートの通信内容を監視するために，次の項目を設定します。

通信内容の監視
通信内容に既知の攻撃パターンや，攻撃と疑われるようなパターンが含まれている場合は運用管理者などに警告を通知するように設定します。侵入検知システムとファイアウォールの連携機能を利用して，疑わしい通信は自動的に遮断するように設定することもできます。

SSLコネクションの確立部分への攻撃の監視
HTTPSによるアクセスは，通信内容が暗号化されているため，基本的に通信内容を監視できません。この場合は，HTTPSに関する既知の攻撃パターンとして，SSLコネクションの確立部分への攻撃などを監視対象としてください。

公開ポート以外のポートへの通信の監視
アプリケーションサーバの公開ポート以外のポートへの通信が外部ネットワークから送信されている場合は，設定ミスなどによってファイアウォールが突破されているおそれがあります。この場合，警告を通知するように設定することをお勧めします。

(3)　基本的なEJBクライアント構成の場合

ここでは，1台のアプリケーションサーバで構成される基本的なEJBクライアント構成の場合のファイアウォールと侵入検知システムの配置個所について説明します。

ファイアウォールは，ネットワークから見てアプリケーションサーバの手前に配置します。この構成の場合，ネットワーク上のEJBクライアントは，ファイアウォール経由でだけアプリケーションサーバにアクセスできます。

基本的なEJBクライアント構成の場合のファイアウォールと侵入検知システムの配置例を次の図に示します。

図5-5　基本的なEJBクライアント構成でのファイアウォールと侵入検知システムの配置

(a)　アプリケーションサーバの設定

アプリケーションサーバでは，次の項目を設定します。

J2EEサーバの管理用通信ポートのアドレス指定
J2EEサーバの管理用通信ポートにアクセスできるアドレスを指定します。

Management Serverおよび運用管理エージェントのアドレス指定
Management Serverおよび運用管理エージェントにアクセスできるアドレスを指定します。

EJBクライアントからアクセスされるポート番号の固定
EJBクライアントからアプリケーションサーバを利用するために，EJBクライアントから次のポート番号に通信できるように設定してください。

CORBAネーミングサービス
ポート番号は，通常固定されています（デフォルトのポート番号：900）。

EJBコンテナ
ポート番号が固定されていないため，EJBコンテナが利用するポート番号を明示的に指定（固定）する必要があります。指定個所については，「3.18　Cosminexusのプロセスが使用するTCP/UDPのポート番号」を参照してください。

Management Serverおよび運用管理エージェントの通信ポートの指定
Management Serverおよび運用管理エージェントの通信ポートの指定については，ファイアウォールの外部からはアクセスできないように，公開ポートを使用しないことを推奨します。これらの通信ポートにアクセスできると，運用管理者以外の外部のユーザからアプリケーションサーバに対して不正な運用操作が実行されるおそれがあります。

(b)　ファイアウォールの設定

外部ネットワークとアプリケーションサーバ間のアクセスについて制御するために，次の項目を設定します。

外部ネットワークからアプリケーションサーバに対してのアクセス許可
ファイアウォールの外部のネットワークとアプリケーションサーバ間の通信では，公開ポートであるCORBAネーミングサービスおよびEJBコンテナの固定ポートなどだけを許可するようにします。ただし，システム構成によっては，DNSなど，そのほかの通信を必要に応じて許可してください。

アクセスを許可するクライアントのIPアドレスの限定（任意）
ファイアウォールの機能を使用してアクセスを許可するクライアントのIPアドレスを限定することで，そのシステムの利用者を特定できます。この場合は，ファイアウォールに通信を許可するIPアドレスを指定してください。

Management Serverおよび運用管理エージェントの通信ポートの指定
Management Serverおよび運用管理エージェントの通信ポートについては，ファイアウォールの外部からはアクセスできないように通信を遮断してください。これらの通信ポートにアクセスできると，運用管理者以外の外部のユーザからアプリケーションサーバに対して不正な運用操作が実行されるおそれがあります。

(c)　侵入検知システムの設定

外部ネットワークとアプリケーションサーバの公開ポートの通信内容を監視するために，次の項目を設定します。

通信内容の監視
通信内容に既知の攻撃パターンや，攻撃と疑われるようなパターンが含まれている場合は運用管理者などに警告を通知するように設定します。侵入検知システムとファイアウォールの連携機能を利用して，疑わしい通信は自動的に遮断するように設定することもできます。

SSLコネクションの確立部分への攻撃の監視
HTTPSによるアクセスは，通信内容が暗号化されているため，基本的に通信内容を監視できません。この場合は，HTTPSに関する既知の攻撃パターンとして，SSLコネクションの確立部分への攻撃などを監視対象としてください。

公開ポート以外のポートへの通信の監視
アプリケーションサーバの公開ポート以外のポートへの通信が外部ネットワークから送信されている場合は，設定ミスなどによってファイアウォールが突破されているおそれがあります。この場合，警告を通知するように設定することをお勧めします。

(4)　サーバの層ごとにファイアウォールで区切る構成（アプリケーション集中型）

システムの規模によっては，一つのシステムが複数のアプリケーションサーバおよびそのほかのサーバで構成されることがあります。このような構成では，それぞれの層でセキュリティを確保する必要があります。

ここでは，Webサーバ，アプリケーションサーバおよびデータベースサーバを多層化した場合に，アプリケーションはすべて同じ層のアプリケーションサーバで動作させる構成について説明します。この構成を，アプリケーション集中型の構成といいます。

アプリケーション集中型の構成の場合のファイアウォールと侵入検知システムの配置例を次の図に示します。この構成では，サーバの層ごとに1台ずつ，合計3台のファイアウォールを配置しています。また，DMZには，リバースプロキシモジュールを組み込んだWebサーバ（リバースプロキシサーバ）を配置しています。

図5-6　アプリケーション集中型のファイアウォールと侵入検知システムの配置

また，コストなどの要因からファイアウォール数を削減したい場合は，次の図に示すような構成にできます。この例では，ファイアウォール1とファイアウォール2で実行するアクセス制御をファイアウォール1に集約して，ファイアウォール2を削減します。

図5-7　ファイアウォールを削減した構成

この構成の場合は，ファイアウォール2で設定する内容を，ファイアウォール1にまとめて設定してください。

(a)　アプリケーションサーバの設定

アプリケーションサーバでは，次の項目を設定します。

J2EEサーバの管理用通信ポートのアドレス指定
J2EEサーバの管理用通信ポートにアクセスできるアドレスを指定します。

Management Serverおよび運用管理エージェントのアドレス指定
Management Serverおよび運用管理エージェントにアクセスできるアドレスを指定します。

(b)　ファイアウォールの設定

この構成では，次に示す三つのファイアウォールを使用しています。

ファイアウォール1
外部のネットワークとDMZのWebサーバ（リバースプロキシサーバ）間のアクセスを制御します。

ファイアウォール2
DMZのWebサーバ（リバースプロキシサーバ）と内部のネットワークにあるアプリケーションサーバ間のアクセスを制御します。

ファイアウォール3
アプリケーションサーバとデータベースサーバ間のアクセスを制御します。

それぞれのファイアウォールに設定する内容について説明します。

●ファイアウォール1の設定

外部のネットワークとDMZのWebサーバ（リバースプロキシサーバ）間のアクセスを制御するためのファイアウォールです。次の項目を設定します。

外部ネットワークからWebサーバ（リバースプロキシサーバ）に対してのアクセス許可
ファイアウォール1よりも外部のネットワークからアプリケーションサーバ内のWebサーバに対する通信は，公開ポートへの通信だけを許可します。HTTP/80やHTTPS/443などが該当します。ただし，システム構成によっては，DNSなど，そのほかの通信を必要に応じて許可してください。

アクセスを許可するWebクライアントのIPアドレスの限定（任意）
ファイアウォールの機能を使用してアクセスを許可するWebクライアントのIPアドレスを限定することで，そのシステムの利用者を特定できます。この場合は，ファイアウォール1に通信を許可するIPアドレスを指定してください。

●ファイアウォール2の設定

Webサーバとアプリケーションサーバ間のアクセスを制御するためのファイアウォールです。次の項目を設定します。

DMZのWebサーバ（リバースプロキシサーバ）から内部ネットワークのアプリケーションサーバ内のWebサーバに対してのアクセス許可
ファイアウォール2よりも外部のネットワーク（DMZ）からアプリケーションサーバ内のWebサーバに対する通信は，公開ポートへの通信だけを許可します。HTTP/80やHTTPS/443などが該当します。ただし，システム構成によっては，DNSなど，そのほかの通信を必要に応じて許可してください。

アクセスを許可するWebクライアントのIPアドレスの限定（任意）
ファイアウォールの機能を使用してアクセスを許可するWebクライアントのIPアドレスを限定することで，そのシステムの利用者を特定できます。この場合は，リバースプロキシサーバのIPアドレスを指定してください。

このほかの通信の設定は，システム構成によって，必要に応じて許可してください。DNSなどの通信の許可が必要な場合があります。

参考

リダイレクタモジュールをDMZのWebサーバに組み込んだ場合など，WebサーバとJ2EEサーバが動作するアプリケーションサーバの間にファイアウォールを配置した場合には，次の設定が必要です。

Webサーバからアプリケーションサーバに対してのアクセス許可
J2EEサーバのWebサーバ通信用ポート（リダイレクタからのリクエスト受付ポート。デフォルトのポート番号：8007）への通信の許可を設定します。

●ファイアウォール3の設定

アプリケーションサーバとデータベース間のアクセスを制御するためのファイアウォールです。このファイアウォールが，システムで最も重要な情報を守るための最終防衛ラインになります。

次の項目を設定します。

アプリケーションサーバからデータベースサーバに対してのアクセス許可
アプリケーションサーバからデータベースサーバに対する通信は，データベースサーバの通信用ポートだけを許可するように設定します。データベースサーバの通信用ポートは，使用するデータベースの設定に従ってください。データベースサーバからアプリケーションサーバへのコネクション確立が必要な場合があるので注意してください。

このほかの通信の設定は，システム構成によって，必要に応じて許可してください。DNSなどの通信の許可が必要な場合があります。

(c)　侵入検知システムの設定

外部ネットワークとアプリケーションサーバ内のWebサーバの公開ポートの通信内容を監視するために，次の項目を設定します。

通信内容の監視
通信内容に既知の攻撃パターンや，攻撃と疑われるようなパターンが含まれている場合は運用管理者などに警告を通知するように設定します。侵入検知システムとファイアウォールの連携機能を利用して，疑わしい通信は自動的に遮断するように設定することもできます。

SSLコネクションの確立部分への攻撃の監視
HTTPSによるアクセスは，通信内容が暗号化されているため，基本的に通信内容を監視できません。この場合は，HTTPSに関する既知の攻撃パターンとして，SSLコネクションの確立部分への攻撃などを監視対象としてください。

公開ポート以外のポートへの通信の監視
アプリケーションサーバの公開ポート以外のポートへの通信が外部ネットワークから送信されている場合は，設定ミスなどによってファイアウォールが突破されているおそれがあります。この場合，警告を通知するように設定することをお勧めします。

(5)　サーバの層ごとにファイアウォールで区切る構成（アプリケーション分散型）

ここでは，「5.10.2(4) サーバの層ごとにファイアウォールで区切る構成（アプリケーション集中型）」と同様に，Webサーバ，アプリケーションサーバおよびデータベースサーバを多層化した場合に，アプリケーションを複数の層のアプリケーションサーバで動作させるときの構成について説明します。この構成を，アプリケーション分散型の構成といいます。

アプリケーション分散型の構成の場合のファイアウォールと侵入検知システムの配置例を次の図に示します。この例では，Webサーバに該当するマシンがアプリケーションサーバを兼ねているため，WebアプリケーションがWebサーバと同じ層で動作します。また，Enterprise Beanは，Webサーバとは別のマシン上に構築されたアプリケーションサーバ上で動作します。

なお，運用管理は，各ホストに配置したManagement Serverによって実行します。このため，管理ホストは層ごとに配置しています。

この構成では，DMZのフロントに1台，およびサーバの層ごとに1台ずつ，合計4台のファイアウォールを配置しています。また，DMZには，リバースプロキシモジュールを組み込んだWebサーバ（リバースプロキシサーバ）を配置しています。

図5-8　アプリケーション分散型のファイアウォールと侵入検知システムの配置

(a)　Web／アプリケーションサーバでの設定

Webサーバを兼ねたアプリケーションサーバマシン（Web／アプリケーションサーバ）では，次の項目を設定します。なお，このアプリケーションサーバマシンでは，Webアプリケーションが動作します。

J2EEサーバの管理用通信ポートのアドレス指定
J2EEサーバの管理用通信ポートにアクセスできるアドレスを指定します。

Management Serverおよび運用管理エージェントのアドレス指定
Management Serverおよび運用管理エージェントにアクセスできるアドレスを指定します。

(b)　アプリケーションサーバの設定

Enterprise Beanが動作するアプリケーションサーバでは，次の項目を設定します。

J2EEサーバの管理用通信ポートのアドレス指定
J2EEサーバの管理用通信ポートにアクセスできるアドレスを指定します。

Management Serverおよび運用管理エージェントのアドレス指定
Management Serverおよび運用管理エージェントにアクセスできるアドレスを指定します。

EJBコンテナが利用するポート番号の固定
EJBコンテナが利用するポート番号を明示的に指定（固定）する必要があります。
指定個所については，「3.18　Cosminexusのプロセスが使用するTCP/UDPのポート番号」を参照してください。

(c)　ファイアウォールの設定

この構成では，次の4台のファイアウォールを使用しています。

ファイアウォール1
外部のネットワークとDMZのWebサーバ（リバースプロキシサーバ）間のアクセスを制御します。

ファイアウォール2
DMZのWebサーバ（リバースプロキシサーバ）と内部のネットワーク上のWeb／アプリケーションサーバ間のアクセスを制御します。

ファイアウォール3
Web／アプリケーションサーバとアプリケーションサーバ間のアクセスを制御します。

ファイアウォール4
アプリケーションサーバとデータベースサーバ間のアクセスを制御します。

それぞれのファイアウォールに設定する内容について説明します。

●ファイアウォール1の設定

外部のネットワークとDMZのWebサーバ（リバースプロキシサーバ）間のアクセスを制御するためのファイアウォールです。次の項目を設定します。

外部ネットワークからWebサーバ（リバースプロキシサーバ）に対してのアクセス許可
ファイアウォール1よりも外部のネットワークからアプリケーションサーバ内のWebサーバに対する通信は，公開ポートへの通信だけを許可します。HTTP/80やHTTPS/443などが該当します。ただし，システム構成によっては，DNSなど，そのほかの通信を必要に応じて許可してください。

アクセスを許可するWebクライアントのIPアドレスの限定（任意）
ファイアウォールの機能を使用してアクセスを許可するWebクライアントのIPアドレスを限定することで，そのシステムの利用者を特定できます。この場合は，ファイアウォール1に通信を許可するIPアドレスを指定してください。

●ファイアウォール2の設定

外部のネットワークと内部のネットワーク上のWeb／アプリケーションサーバ間のアクセスを制御するためのファイアウォールです。次の項目を設定します。

DMZのWebサーバ（リバースプロキシサーバ）からアプリケーションサーバ内のWebサーバに対してのアクセス許可
ファイアウォール1よりも外部のネットワークから，アプリケーションサーバ内のWebサーバに対する通信は，公開ポートへの通信だけを許可します。HTTP/80やHTTPS/443などが該当します。ただし，システム構成によっては，DNSなど，そのほかの通信を必要に応じて許可してください。

アクセスを許可するWebクライアントのIPアドレスの限定（任意）
ファイアウォールの機能を使用してアクセスを許可するWebクライアントのIPアドレスを限定することで，そのシステムの利用者を特定できます。この場合は，リバースプロキシサーバのIPアドレスを指定してください。

●ファイアウォール3の設定

Web／アプリケーションサーバとアプリケーションサーバ間のアクセスを制御するためのファイアウォールです。次の項目を設定します。

Web／アプリケーションサーバからアプリケーションサーバに対してのアクセス許可
Web／アプリケーションサーバからアプリケーションサーバ上のJ2EEサーバを利用するために，次のポート番号に通信できるように設定してください。

CORBAネーミングサービス
ポート番号は，通常固定されています（デフォルトのポート番号：900）。

EJBコンテナ
ポート番号が固定されていないため，EJBコンテナが利用するポート番号を明示的に指定（固定）する必要があります。
指定個所については，「3.18　Cosminexusのプロセスが使用するTCP/UDPのポート番号」を参照してください。

トランザクション関連の双方向アクセスの許可（グローバルトランザクションでトランザクションコンテキストプロパゲーションを使用する場合）
Web／アプリケーションサーバとアプリケーションサーバの間で，グローバルトランザクションでトランザクションコンテキストプロパゲーションを使用する場合は，両方のアプリケーションサーバの次に示すポートが双方向で通信できるように設定します。

J2EEサーバのトランザクションリカバリ用通信ポート（デフォルトのポート番号：20302）

スマートエージェントの通信ポート（デフォルトのポート番号：14000）

そのほかの設定（任意）
システム構成によっては，DNSなど，そのほかの通信を必要に応じて許可してください。

●ファイアウォール4の設定

アプリケーションサーバとデータベース間のアクセスを制御するためのファイアウォールです。このファイアウォールが，システムで最も重要な情報を守るための最終防衛ラインになります。

次の項目を設定します。

アプリケーションサーバからデータベースサーバに対してのアクセス許可
アプリケーションサーバからデータベースサーバに対する通信は，データベースサーバの通信用ポートだけを許可するように設定します。データベースサーバの通信用ポートは，使用するデータベースの設定に従ってください。データベースサーバからアプリケーションサーバへのコネクション確立が必要な場合があるので注意してください。また，システム構成によっては，DNSなど，そのほかの通信を必要に応じて許可してください。

(d)　侵入検知システムの設定

外部ネットワークとアプリケーションサーバ内にあるWebサーバの公開ポートの通信内容を監視するために，次の項目を設定します。

通信内容の監視
通信内容に既知の攻撃パターンや，攻撃と疑われるようなパターンが含まれている場合は運用管理者などに警告を通知するように設定します。侵入検知システムとファイアウォールの連携機能を利用して，自動的に疑わしい通信は遮断するように設定することもできます。

SSLコネクションの確立部分への攻撃の監視
HTTPSによるアクセスは，通信内容が暗号化されているため，基本的に通信内容を監視できません。この場合は，HTTPSに関する既知の攻撃パターンとして，SSLコネクションの確立部分への攻撃などを監視対象としてください。

公開ポート以外のポートへの通信の監視
Web／アプリケーションサーバの公開ポート以外のポートへの通信が外部ネットワークから送信されている場合は，設定ミスなどによってファイアウォールが突破されているおそれがあります。この場合，警告を通知するように設定することをお勧めします。

5.10.3　SSLアクセラレータを使用して暗号通信を処理する

ここでは，SSLアクセラレータを使用して暗号通信を処理する方法について説明します。

＜この項の構成＞

(1)　SSLアクセラレータを使用する目的

(2)　SSLアクセラレータの配置

(1)　SSLアクセラレータを使用する目的

セキュリティ上の脅威のうち，アプリケーションの通信内容の第三者への漏洩または改ざんを防ぐ方法の一つに，通信内容の暗号化があります。暗号化手段としては，通信にHTTPSを使用する方法があります。ただし，HTTPSの基盤となるTLS／SSLによる通信は大変負荷が高い処理です。

SSLアクセラレータは，このような場合に，Webサーバやアプリケーションサーバに負荷を掛けないで，HTTPSによって暗号化された通信内容の処理を実現するための専用ハードウェアです。SSLアクセラレータを適切に配置することで，Webサーバやアプリケーションサーバに負荷を掛けることなく，暗号化された内容の通信を高速化できます。

(2)　SSLアクセラレータの配置

SSLアクセラレータを適用した構成の例を次の図に示します。

図5-9　SSLアクセラレータを適用した構成

WebクライアントからHTTPSによって送信された通信内容は，SSLアクセラレータによって復号化され，HTTPによってWebサーバまたはアプリケーションサーバに送信されます。また，WebサーバまたはアプリケーションサーバからHTTPによって送信された通信内容は，SSLアクセラレータによって暗号化されて，Webクライアントに送信されます。

SSLアクセラレータを配置する場合は，次の点に留意してください。

SSLアクセラレータは，ファイアウォールとの併用もできます。併用する場合は，SSLアクセラレータをWebサーバまたはアプリケーションサーバと一体として扱ってください。

Webサーバ連携をする場合は，SSLアクセラレータ使用時に，リダイレクタの追加設定が必要な場合があります。リダイレクタを設定すると，例えば，WebクライアントからのリクエストがHTTP/1.0の場合にリクエストのフォワード先指定などができます。Management Serverを利用してシステムを構築する場合は，運用管理ポータルの「論理サーバの環境設定」で設定できます。論理Webサーバの［リダイレクタの設定］画面の「ゲートウェイ指定機能の設定」で，「SSLアクセラレータの使用」に，「する」を選択してください。
Management Serverを利用しないでシステムを構築する場合は，次のファイルに設定します。

Hitachi Web Serverの場合

mod_jk.confファイルのJkGatewayHttpsSchemeキー

Microsoft IISの場合

isapi_redirect.confファイルのgateway_https_schemeキー

詳細は，マニュアル「Cosminexus　運用管理操作ガイド」およびマニュアル「Cosminexus　リファレンス　定義編」を参照してください。

インプロセスHTTPサーバを使用する場合は，SSLアクセラレータ使用時に，Webコンテナの追加設定が必要な場合があります。この設定によって，例えば，WebクライアントからのリクエストがHTTP/1.0の場合にリクエストのフォワード先指定などができます。Management Serverを利用してシステムを構築する場合は，運用管理ポータルの「論理サーバの環境設定」で設定できます。論理J2EEサーバの［その他の設定］画面で，「ゲートウェイ指定機能の設定」の「SSLアクセラレータの使用」に，「する」を選択してください。
Management Serverを利用しないでシステムを構築する場合は，usrconf.propertiesファイルのwebserver.connector.inprocess_http.gateway.https_schemeキーに設定します。
詳細は，マニュアル「Cosminexus　運用管理操作ガイド」およびマニュアル「Cosminexus　リファレンス　定義編」を参照してください。

5.10.4　アプリケーションでユーザを認証する

ここでは，Webクライアント構成の場合に，セキュリティ確保のためにアプリケーションで利用できる認証機能について説明します。

＜この項の構成＞

(1)　アプリケーションでユーザを認証する目的

(2)　アプリケーションによるユーザ認証方法の比較

(1)　アプリケーションでユーザを認証する目的

アプリケーションを実行するユーザを認証することで，セキュリティ上の脅威のうち，システム利用者によって，許可した権限の範囲を超えて操作されたり情報を入手されたりすることを防げます。

Cosminexusでは，次の3種類のプロトコルを使用してユーザ認証によるセキュリティ確保ができます。

HTTPS（クライアント認証）

HTTP（Basic認証）

HTTP（Form認証）

これらのプロトコルを目的に応じて使い分けて，セキュリティを確保してください。

(2)　アプリケーションによるユーザ認証方法の比較

通信プロトコルごとの，認証実施個所および認証に使用されるエンジンについて，次の表に示します。

表5-7　通信プロトコルごとの認証実施個所および認証に使用されるエンジン

使用するプロトコル | 認証実施個所 | 認証に使用されるエンジン
HTTPS(クライアント認証) | Hitachi Web ServerまたはMicrosoft IIS | SSL
SSLアクセラレータ | SSL
HTTP(Basic認証) | Hitachi Web Server | HWSパスワードファイル
LDAPリポジトリ
J2EEサーバ（Webコンテナ） | パスワードファイル
HTTP(Form認証) | J2EEサーバ（Webコンテナ） | パスワードファイル
J2EEサーバ（統合ユーザ管理） | 統合ユーザ管理パスワードファイル
データベース
LDAPリポジトリ

それぞれのプロトコルおよび認証に使用されるエンジンには特徴があります。それらの特徴を考慮して，システムの目的に合った認証方法を選択してください。

(a)　プロトコルの特徴

Cosminexusのシステムの認証処理に使用できるプロトコルの特徴について，次の表に示します。

表5-8　プロトコルの特徴

使用するプロトコル
認証インタフェースの自由度
クライアントでの管理の容易さ
ネットワークの安全性

HTTPS
（クライアント認証）
Webブラウザが提供する機能に制約されます。
クライアント証明書が必要です。
暗号化されているため，盗聴されても認証情報は安全です。

HTTP
（Basic認証）
Webブラウザが提供する機能に制約されます。
一般的なユーザ名称／パスワード形式を使用した認証ができます。
パスワードが平文またはそれと同等の形式で流出します。
このため，通常は，HTTPS（サーバ認証だけ）の暗号機能と併用して使用します。

HTTP
（Form認証）
アプリケーションごとにデザインできます。
一般的なユーザ名称／パスワード形式を使用した認証ができます。
パスワードが平文またはそれと同等の形式で流出します。
このため，通常は，HTTPS（サーバ認証だけ）の暗号機能と併用して使用します。

(b)　認証に使用されるエンジンの特徴

認証に使用されるエンジンの特徴について，次の表に示します。

表5-9　認証に使用されるエンジンの特徴

エンジンの種類 | はん用性 | 保守性 | システム構成への影響 | 性能影響への影響
パスワードファイル | 使用する機能ごとに形式が異なります。 | サーバまたはホストごとにユーザ情報が散在します。 | 特に認証用のプロセスは必要ありません。 | 認証時にほかのプロセスやホストとの通信が発生しないため，高速です。
データベース | 形式によっては，既存のユーザ情報データベースを利用できます。 | ユーザ情報の一括管理ができます。 | ユーザ情報を格納するデータベースサーバが必要です。 | 認証時にデータベースアクセスに必要な時間が掛かります。
LDAPリポジトリ | 形式によっては，既存のユーザ情報リポジトリを利用できます。 | ユーザ情報の一括管理，および分散したユーザ情報の集中管理ができます。 | ユーザ情報を格納するLDAP対応のディレクトリサーバが必要です。 | 認証時にLDAPディレクトリサーバへのアクセスに必要な時間が掛かります。

6.　パフォーマンスチューニング（J2EEアプリケーション実行基盤）

この章では，J2EEアプリケーションを実行するシステムのパフォーマンスをチューニングする方法について説明します。

パフォーマンスチューニングによって動作環境を最適化することで，システムの性能を最大限に生かせるようになります。

バッチアプリケーション実行基盤のパフォーマンスチューニングについて検討する場合は，「7.　パフォーマンスチューニング（バッチアプリケーション実行基盤）」を参照してください。

＜この章の構成＞

6.1　パフォーマンスチューニングで考慮すること

6.2　チューニングの方法

6.3　同時実行数を最適化する

6.4　Enterprise Beanの呼び出し方法を最適化する

6.5　データベースへのアクセス方法を最適化する

6.6　タイムアウトを設定する

6.7　Webアプリケーションの動作を最適化する

6.8　CTMの動作を最適化する

6.9　そのほかの項目のチューニング

6.1　パフォーマンスチューニングで考慮すること

この節では，J2EEアプリケーション実行基盤のパフォーマンスチューニングで考慮することについて説明します。

＜この節の構成＞

6.1.1　パフォーマンスチューニングの観点

6.1.2　チューニング手順

6.1.3　アプリケーションの種類ごとにチューニングできる項目

6.1.1　パフォーマンスチューニングの観点

J2EEアプリケーション実行基盤のパフォーマンスチューニングは，次の観点で実施します。

同時実行数の最適化

Enterprise Beanの呼び出し方法の最適化

データベースアクセス方法の最適化

タイムアウトの設定

Webアプリケーションの動作の最適化

CTMの動作の最適化

そのほかの項目のチューニング

それぞれのポイントについて説明します。

＜この項の構成＞

(1)　同時実行数の最適化

(2)　Enterprise Beanの呼び出し方法の最適化

(3)　データベースアクセス方法の最適化

(4)　タイムアウトの設定

(5)　Webアプリケーションの動作の最適化

(6)　CTMの動作の最適化

(7)　そのほかの項目のチューニング

(1)　同時実行数の最適化

同時実行数の最適化は，処理を多重化してCPUの処理能力を最大限に引き出して，システムのスループットを向上させることを目的とします。しかし，次のような場合，多重化しただけではスループットが向上しません。場合によっては，スループットが低下するおそれがあります。

入出力処理，排他処理などのボトルネックがある場合

最大スループットに到達している場合

CPUの利用率が飽和した状態で多重度以上の負荷を掛けた場合

実行待ちキューのサイズが不適切な場合

階層的な最大実行数の設定が不適切な場合

パフォーマンスチューニングでは，これらを考慮しながら適切なチューニングを実施して，同時実行数の最適化を図ります。

(2)　Enterprise Beanの呼び出し方法の最適化

Enterprise Beanの呼び出し方法の最適化は，同じJ2EEアプリケーションや同じJ2EEサーバ内のコンポーネントを呼び出すときに，ローカルインタフェースやリモートインタフェースのローカル呼び出し機能を利用することで，不要なネットワークアクセスを削減することを目的とします。

次の機能を利用することで，RMI-IIOP通信によって発生する不要なネットワークアクセスを削減できます。

ローカルインタフェースの利用

リモートインタフェースのローカル呼び出し機能の利用

また，引数や戻り値の渡し方を参照渡しにすることで，さらに処理性能を向上できる場合があります。パフォーマンスチューニングでは，アプリケーションやシステムの特徴によってこれらの機能を有効に活用して，処理性能の向上を図ります。

(3)　データベースアクセス方法の最適化

データベースアクセス方法の最適化は，処理に時間が掛かるコネクションやステートメントを事前に生成しておくことで，データベースアクセス時のオーバーヘッドを削減することを目的とします。

パフォーマンスチューニングでは，次に示す機能を有効に活用することで，データベースアクセス処理を最適化し，スループットを向上させます。

コネクションプーリング

ステートメントプーリング（PreparedStatementおよびCallableStatementのプーリング）

(4)　タイムアウトの設定

タイムアウトの設定は，システムのトラブル発生を検知して，リクエストの応答が返らなくなることを防ぎ，適宜リソースを解放することを目的とします。

設定できるタイムアウトには，次の種類があります。

Webフロントシステムのタイムアウト

バックシステムのタイムアウト

トランザクションのタイムアウト

データベースのタイムアウト

(5)　Webアプリケーションの動作の最適化

Webアプリケーションの動作の最適化は，コンテンツの配置方法の検討やキャッシュの利用によって不要なネットワークアクセスを削減して処理速度を速めたり，負荷分散によってシステムのスループットの向上を図ったりすることを目的とします。

なお，Webサーバとして，リダイレクタモジュールを組み込んだWebサーバと連携する場合と，インプロセスHTTPサーバを使用している場合で，チューニングできる項目が異なります。

Webサーバと連携する場合には，次の処理ができます。

静的コンテンツとWebアプリケーションでの処理の振り分け

静的コンテンツのキャッシュ

セッション情報に応じたリクエストの振り分け

インプロセスHTTPサーバを使用する場合は，次の処理ができます。

静的コンテンツとWebアプリケーションの配置の切り分け

静的コンテンツのキャッシュ

(6)　CTMの動作の最適化

CTMの動作の最適化は，CTMで使用するプロセス間の通信間隔を最適化して通信負荷を軽減したり，トラブル発生時に迅速に検知して対処したりすることで，システムとしての性能を向上させることを目的とします。また，CTMによってリクエストの処理に優先順位を付けることで，重要なリクエストをすばやく処理するようにもチューニングできます。

(7)　そのほかの項目のチューニング

アプリケーションサーバでは，(1)～(6)で説明した項目以外にも，チューニングできる項目があります。必要に応じてチューニングを実施してください。

6.1.2　チューニング手順

パフォーマンスチューニングは，システムのパフォーマンスを生かす最適な設定を見つける作業です。構築した環境で，実際に処理を実行したり，模擬的な負荷を掛けたりしながら，パラメタの調整やボトルネックの調査，解消によってパフォーマンスを向上させていきます。

パフォーマンスチューニングの手順の例として，ここでは，同時実行数のチューニング手順を示します。

図6-1　パフォーマンスチューニングの手順（同時実行数をチューニングする場合）

チューニング作業では，まず，目標値を決定します。ここでは，CPU利用率などが該当します。

次に，各パラメタに初期値を設定した状態でのスループットを測定し，そのあとで模擬的な負荷を掛けながら各パラメタを調整して，目標値に近い最適な値を見つけていきます。模擬的な負荷は，専用のツールを使用して発生させます。

チューニングの際，CPUの利用率の測定には，OSに付属している監視ツールなどが利用できます。スループットの測定は，負荷発生ツールなどによって測定できます。また，稼働スレッド数など，Cosminexusの稼働情報については，稼働情報収集機能などで確認できます。確認方法については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

スループットが目標値に達したところで，パフォーマンスチューニングは完了です。なお，CPU利用率が100%からかなり低い状態で飽和した場合は，システム上に入出力処理や排他処理などのボトルネックがあるおそれがあります。ボトルネックを調査し，対策してから，再度パフォーマンスチューニングを実行してください。Cosminexusのシステムのボトルネックの調査には，性能解析トレースを利用できます。性能解析トレースの機能詳細については，マニュアル「Cosminexus　機能解説」を参照してください。性能解析トレースを利用して取得したトレースファイルの利用方法については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

6.1.3　アプリケーションの種類ごとにチューニングできる項目

チューニング項目は，アプリケーションの種類によって異なります。アプリケーションに含まれるコンポーネントごとのチューニング項目について，次に示します。

表6-1　サーブレットとJSPで構成されるアプリケーション（Webアプリケーション）のチューニング項目

チューニング項目 | 利用できる機能 | 参照先
リクエスト処理スレッド数の最適化（インプロセスHTTPサーバを使用する場合） | リクエスト処理スレッド数の制御（インプロセスHTTPサーバを使用する場合）※ | 6.3.3
同時実行数の最適化 | Webアプリケーションでの同時実行スレッド数制御（Webコンテナ単位，Webアプリケーション単位，またはURLグループ単位） | 6.3.4
データベースアクセス方法の最適化 | コネクションプーリング | 6.5.1
ステートメントプーリング | 6.5.2
タイムアウトの設定 | Webフロントシステムでのタイムアウトの設定 | 6.6.2
J2EEアプリケーションのメソッド実行時間に対するタイムアウトの設定 | 6.6.6
Webアプリケーションの動作の最適化 | 静的コンテンツとWebアプリケーションの配置の切り分け | 6.7.1
静的コンテンツのキャッシュ | 6.7.2
リダイレクタによるリクエストの振り分け（Webサーバ連携の場合） | 6.7.3
そのほかの項目のチューニング | Persistent Connectionの制御（インプロセスHTTPサーバを使用する場合） | 6.9

注※　Webサーバと連携する場合は，Webサーバの機能を使用してチューニングしてください。

表6-2　Enterprise Beanで構成されるアプリケーションのチューニング項目

チューニング項目 | 利用できる機能 | 参照先
同時実行数の最適化 | Stateless Session Beanのインスタンスプーリング | 6.3.5
Stateful Session Beanのセッション制御
Message-driven Beanのインスタンスプーリング
CTMによる同時実行数制御※（CTMを使用している場合） | 6.3.6
Enterprise Beanの呼び出し方法の最適化 | ローカルインタフェースの使用 | 6.4.1
リモートインタフェースのローカル呼び出し最適化 | 6.4.2
リモートインタフェースの参照渡し | 6.4.3
データベースアクセス方法の最適化 | コネクションプーリング | 6.5.1
ステートメントプーリング | 6.5.2
タイムアウトの設定 | バックシステムでのタイムアウトの設定 | 6.6.3
トランザクションタイムアウトの設定 | 6.6.4
データベースでのタイムアウトの設定 | 6.6.5
J2EEアプリケーションのメソッド実行時間に対するタイムアウトの設定 | 6.6.6

注※　Stateless Session Beanだけが対象です。

また，CTMを使用したシステムの場合に設定できる，CTMの動作のチューニング項目を次の表に示します。CTMは，アプリケーションがStateless Session Beanで構成されている場合に使用できます。

表6-3　CTMの動作についてのチューニング項目

チューニング項目 | 利用できる機能 | 参照先
CTMの動作の最適化 | CTMドメインマネジャおよびCTMデーモンの稼働状態を監視する間隔のチューニング | 6.8.1
負荷状況監視間隔のチューニング | 6.8.2
CTMデーモンのタイムアウト閉塞の設定 | 6.8.3
CTMで振り分けるリクエストの優先順位の設定 | 6.8.4

6.2　チューニングの方法

この節では，チューニングの方法について説明します。チューニングの方法は，設定対象の種類によって異なります。

＜この節の構成＞

(1)　J2EEサーバおよびWebサーバ（リダイレクタを含む）のチューニング

(2)　アプリケーションまたはリソースのチューニング

(3)　CTMの動作のチューニング

(4)　それ以外の項目のチューニング

(1)　J2EEサーバおよびWebサーバ（リダイレクタを含む）のチューニング

J2EEサーバおよびWebサーバ（リダイレクタを含む）のチューニングには，Smart Composer機能の簡易構築定義ファイルを使用します。簡易構築定義ファイルでは，<configuration>タグ下の<logical-server-type>に設定対象とする論理サーバの種類（J2EEサーバまたはWebサーバ）を指定して，<param>タグ下でパラメタ名とその値を設定します。簡易構築定義ファイルの詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

参考

Web Redirectorを使用する場合など，Smart Composer機能を使用できない場合，Webサーバ（リダイレクタを含む）のチューニングはファイルを編集して定義します。

Smart Composer機能を使用できない場合に，Webサーバ（リダイレクタを含む）のチューニングに使用するファイルについて，次の表に示します。

表6-4　Smart Composer機能を使用できない場合にWebサーバ（リダイレクタを含む）のチューニングに使用するファイル

対象 | チューニング方法
Webサーバ | httpsd.confの編集
Webサーバ（リダイレクタ） | mod_jk.conf（Hitachi Web Serverの場合）の編集
isapi_redirect.conf（Microsoft IISの場合）の編集
worker.properties（ワーカの設定の場合）の編集

mod_jk.conf，isapi_redirect.confおよびworker.propertiesの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。httpsd.confの詳細については，マニュアル「Hitachi Web Server」を参照してください。

(2)　アプリケーションまたはリソースのチューニング

アプリケーションおよびリソースのチューニングをする場合は，次のどちらかの方法でチューニングします。

サーバ管理コマンド

Server Plug-in

なお，Server Plug-inは，Smart Composer機能で構築した，Management Serverを利用するシステムで使用できます。

サーバ管理コマンドを使用する場合は，属性ファイルを編集します。属性ファイルの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。なお，属性ファイルはServer Plug-inの画面を使用して編集することもできます。属性ファイルのタグと対応するServer Plug-inの画面については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

(3)　CTMの動作のチューニング

CTMのチューニングには，Smart Composer機能の簡易構築定義ファイルを使用します。簡易構築定義ファイルでは，<configuration>タグ下の<logical-server-type>に設定対象とする論理サーバの種類（CTMドメインマネジャまたはCTM）を指定して，<param>タグ下でパラメタ名とその値を設定します。

簡易構築定義ファイルの詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

(4)　それ以外の項目のチューニング

このほか，チューニングで使用するパラメタには，APIで設定する項目や，データベースで設定する項目などがあります。これらの設定については，それぞれの節のチューニングパラメタの説明を参照してください。

6.3　同時実行数を最適化する

この節では，アプリケーションのリクエストの同時実行数を最適化するための考え方とチューニング方法について説明します。

＜この節の構成＞

6.3.1　同時実行数制御および実行待ちキュー制御の考え方

6.3.2　最大同時実行数と実行待ちキューを求める手順

6.3.3　Webサーバでのリクエスト処理スレッド数を制御する

6.3.4　Webアプリケーションの同時実行数を制御する

6.3.5　Enterprise Beanの同時実行数を制御する

6.3.6　CTMを使用して同時実行数を制御する

6.3.7　同時実行数を最適化するためのチューニングパラメタ

6.3.1　同時実行数制御および実行待ちキュー制御の考え方

Cosminexusのシステムでアプリケーションのスループットを向上させるためには，複数のリクエストを多重処理することが有効です。複数のスレッドで多重にリクエストを処理した方が，単一スレッドで一度に1リクエストずつ処理するのに比べて，多くの場合，スループットを向上させられます。

ただし，入出力処理，排他処理などにボトルネックがあったり，すでに最大スループットに到達していたりする場合は，多重化によるスループットの向上はできません。このため，同時実行数のチューニングは，次の点を確認しながら進めます。

入出力処理，排他処理などのボトルネックの排除

スレッドを多重化してもCPU利用率が少ないままでスループットが向上しない場合は，アプリケーションのデータベースアクセスなどの入出力処理や排他処理などにボトルネックがあるおそれがあります。この場合は，ボトルネックになっている処理を特定して，排除してからチューニングする必要があります。例えば，データベースアクセス方法をチューニングしたり，排他処理方法を変更したりして，入出力処理，排他処理などのボトルネックを取り除きます。

最大スループットの確認

リクエストの多重度を大きくしてスレッド数を増やしていくと，スレッド数の増加に伴ってCPUの空き時間が減少し，さらに増やしていくと，ほとんどCPUの空き時間がない状態になります。この状態になると，スレッドを増やしてもスループットは上がりません。

これは，CPUがボトルネックになっている状態であり，マシン単体の性能として，限界に達している状態です。つまり，この時点のスループットが，マシン単体でのアプリケーションの最大スループットになります。

これ以上のスループットを確保したい場合は，CPUやマシン数を増加させるなど，ハードウェアの増強が必要になります。

同時実行数制御によるスループットの維持

CPUの利用率が飽和した状態で，さらに多重度を大きくしてスレッドを増やした場合，実行可能な状態でCPUが割り当てられないスレッドが増えます。この状態では，スレッド間のロックが競合したり，スレッドのコンテキストスイッチが多発したりするので，スループットが低下するおそれがあります。

また，スレッド数を増やすと，アプリケーションサーバ内ではスレッド数に応じてメモリ使用量が増えます。つまり，スループット低下とメモリ使用量の増加を防ぐためには，スレッド数の増加を実行可能なスレッド数までに制限する必要があります。

同時実行数制御機能を適切に使用することで，最大同時実行数をチューニングして，リクエストの多重度を大きくした場合でも，最大同時実行数分以上のリクエストの実行を待たせることができます。この結果，一時的に過負荷状態が発生したり，負荷のピークの状態になったりしても，高いスループットを維持できます。

実行待ちキューサイズの調整

アプリケーションサーバに到着したリクエストが同時実行数の上限を超えたとき，リクエストをキューに登録することで，実行中のほかのリクエストの処理が終わるまでそのリクエストを待たせることができます。しかし，ほかのリクエストの処理が終わるまでリクエストを待たせておくためのキューのサイズ（実行待ちキューサイズ）に上限を設定している場合，実行待ちキューが上限に達したあとで到着したリクエストについては，実行待ちキューには登録されないでクライアントにエラーとして返却されます。このため，実行待ちキューに上限を設定する場合は，待たせるキューに必要な数を確保しておく必要があります。

実行待ちキューへのリクエストの登録とエラーの返却の考え方を，次の図に示します。

図6-2　実行待ちキューへのリクエストの登録とエラーの返却

ポイント

リクエストを実行待ちキューで待たせるのは，一時的な過負荷状態の場合や負荷のピークの場合にエラーが発生するのを防ぐためです。エラーが返却されるのを避けるために実行待ちキューサイズをむやみに増やすのは，本質的な解決にはなりません。同時実行数を増やしたり，必要に応じてCPUやマシン数を増設したりするなどの対処をしてください。

また，クライアント側でタイムアウトを設定している場合は，リクエストが実行待ちキューに登録されてから実際に実行されるまでの時間が掛かり過ぎると，リクエストの実行前にタイムアウトが発生してエラーになるおそれがあります。

このため，実行待ちキューサイズは，最適なサイズに設定してください。

階層的なアプリケーションでの最大同時実行数のバランス

あるレイヤだけをチューニングして同時実行数を増やしても，システム全体の性能は向上しません。これは，システム全体としての性能は，性能が低いレイヤに制約されてしまうためです。

特定のレイヤだけを最適化したために無意味な設定を含んでしまった例を，次の図に示します。

図6-3　特定のレイヤだけを最適化したために無意味な設定を含んでしまった例

また，同時実行数を増やすと，実際にはリクエストを処理していないアイドル状態の場合にも，メモリなどのリソースをむだに消費するおそれがあります。

このため，同時実行数を制御する場合には，システム全体を見渡して，適切な同時実行数をそれぞれのレイヤに設定するようにしてください。

6.3.2　最大同時実行数と実行待ちキューを求める手順

最大同時実行数および実行待ちキューサイズは，次の手順に従ってチューニングできます。

負荷発生ツールなどを利用して，リクエストの多重度を増やします。
このとき，サーバ側のCPU利用率が80%～90%に達した場合は，手順2.に進みます。80%～90%に達しない，低い状態でスループットが向上しなくなった場合は，入出力処理や排他処理などにボトルネックがあることが考えられます。この場合は，ボトルネックになっている処理を特定して，性能を改善します。

サーバ側のCPU利用率が80%～90%に達した多重度を，最大同時実行数としてチューニングパラメタに設定します。
この状態でのスループットが，単体マシンの最大スループットになります。これ以上のスループットを求めたい場合は，ハードウェアの増強が必要です。

負荷発生ツールなどでさらに高い負荷を掛けて，最大スループットが維持できるかどうかを確認します。
維持できない場合は，最大スループット以上の負荷が掛からないように，チューニングパラメタを調整します。

実際のシステムでの一時的な過負荷状態，および負荷のピークの状態でのリクエスト数を見積もり，実行待ちキューサイズを決定します。

階層的な構造を持つアプリケーションでは，各レイヤでの同時実行数および実行待ちキューサイズのバランスが取れるよう，調整します。

6.3.3　Webサーバでのリクエスト処理スレッド数を制御する

Webフロントシステムの場合，Webブラウザなどのクライアントからのリクエストは，Webサーバが作成するリクエスト処理スレッドによって処理されます。リクエスト処理スレッド数を適切に制御することで，処理性能の向上が図れます。

ここでは，Webサーバでのリクエスト処理スレッド数を制御する目的と，チューニングの指針について説明します。

なお，ここでは，インプロセスHTTPサーバを使用している場合のチューニングの方法について説明します。

参考

Webサーバ連携時にHitachi Web Serverを使用している場合は，Hitachi Web Serverの設定で同様のチューニングができます。詳細は，マニュアル「Hitachi Web Server」を参照してください。

また，Smart Composer機能を使用してシステムを構築する場合，Webサーバでのリクエスト処理スレッド数の設定は，抽象パラメタの利用によって設定できます。抽象パラメタとは，互いに関連のあるパラメタを一つにまとめたパラメタです。抽象パラメタを利用することで，Webサーバのリクエスト処理スレッド数の設定を，同時実行スレッド数などの関連するパラメタと一緒に定義できます。抽象パラメタについては，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

＜この項の構成＞

(1)　リクエスト処理スレッド数を制御する目的

(2)　設定の指針

(1)　リクエスト処理スレッド数を制御する目的

リクエスト処理スレッド数をJ2EEサーバが動作しているホストの性能やクライアントからのアクセス状況に合わせてチューニングすることで，性能向上を図れます。

リクエスト処理スレッドの生成は，負荷が高い処理です。リクエスト処理スレッドをあらかじめ生成してプールしておくことで，Webブラウザなどのクライアントからのリクエスト処理要求時の負荷を軽くして，処理性能を高めることができます。

インプロセスHTTPサーバを使用する場合，J2EEサーバ起動時にリクエスト処理スレッドをまとめて生成してプールしておき，Webブラウザなどのクライアントからリクエスト処理要求があった場合にそれを利用するようにできます。これによって，リクエスト処理要求時の処理性能の向上を図れます。なお，プールしているスレッドの数を監視しておくことで，プールしているスレッド数が少なくなった場合はさらに追加生成して，プールに確保しておくこともできます。

ただし，使用しないスレッドを大量にプールしておくと，むだなリソースを消費します。このため，システムの処理内容に応じて，プールするリクエスト処理スレッド数を適切に制御し，場合によっては不要なスレッドを削除することが必要です。

リクエスト処理スレッドの制御では，これらを考慮して，パラメタに適切な値を設定してください。

(2)　設定の指針

リクエスト処理スレッド数の制御では，次のパラメタ使用してチューニングできます。

J2EEサーバ起動時に生成するリクエスト処理スレッドの数

Webクライアントとの接続数（リクエスト処理スレッド数）の上限数

接続数の上限を超えた場合のTCP/IPのListenキュー（バックログ）の最大値

予備スレッド数の最大数および最小数

J2EEサーバ起動時に生成したリクエスト処理スレッド数を維持するかどうかの選択

これらのパラメタを設定するときには，次の点に留意してください。

提供するサービスの内容によっては，J2EEサーバ起動直後から大量のリクエストを処理する必要があります。この場合は，J2EEサーバ起動時に生成するリクエスト処理スレッドの数に，大きな値を指定してください。

予備スレッド数の最大数を大きくしておくと，クライアントからのアクセスが急に増加した場合にも，処理性能を下げることなく迅速に対応できます。ただし，多くの予備スレッドをプールしておくと，多くのリソースが消費されます。このため，急な増加が予想されるアクセス数を見積もって，適切な数の予備スレッドがプールされるように，注意して設定してください。

一定数のリクエスト処理スレッドは確保した状態で，それを超えるリクエスト処理スレッドの増減を最大数と最小数を指定して制御したい場合は，J2EEサーバ起動時に生成したリクエスト処理スレッド数を維持する設定にしてください。これによって，システムとして最低確保しておきたい数のリクエスト処理スレッドを確保した状態で，クライアントからのアクセスピーク時のリクエスト処理スレッド数の増減に対応できます。未使用のリクエスト処理スレッド数が予備スレッド数の最大値を超えている場合も，J2EEサーバ起動時に生成した数のリクエスト処理スレッドは維持されます。

一度作成したスレッドを削除しないでプールし続けたい場合は，予備スレッド数の最大数を，Webクライアントとの最大接続数と同じ値にしてください。

このほか，Webアプリケーションの同時実行スレッド数との関係についても留意してください。Webアプリケーションの同時実行スレッド数については，「6.3.4　Webアプリケーションの同時実行数を制御する」を参照してください。

6.3.4　Webアプリケーションの同時実行数を制御する

Webアプリケーションの同時実行数制御では，Webフロントシステムの場合に，WebサーバがWebブラウザなどのクライアントから受け付けたリクエストの処理を，同時に幾つのスレッドで実行するかを制御します。

同時実行スレッド数は，URLグループ単位，Webアプリケーション単位，またはWebコンテナ単位で制御できます。同時実行スレッド数は，Webサーバ連携の場合，インプロセスHTTPサーバを使用する場合，どちらの場合も制御できます。

＜この項の構成＞

(1)　同時実行スレッド数制御の違い

(2)　選択の指針

(1)　同時実行スレッド数制御の違い

Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位の同時実行スレッド数制御の違いは次のとおりです。

Webコンテナ単位

Webコンテナ全体で同時にリクエストを処理するスレッド数を設定できます。

Webアプリケーション単位

Webコンテナ上で動作するWebアプリケーションごとに，同時にリクエストを処理するスレッド数を設定できます。

URLグループ単位

リクエストをWebアプリケーション内の特定の業務処理（業務ロジック）に対応するURLに振り分ける場合，振り分け先URLの処理ごとに，同時にリクエストを処理するスレッド数を設定できます。

Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位の同時実行スレッド数の関係を次の図に示します。

図6-4　Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位の同時実行スレッド数の関係

Webアプリケーションに対するリクエストの実行は，Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位に設定した同時実行スレッド数に制限されます。Webコンテナ単位，Webアプリケーション単位およびURLグループ単位に設定した同時実行スレッド数を超えるリクエストは，それぞれの実行待ちキューに入ります。

(2)　選択の指針

同時実行スレッド数制御の単位を選択するときの指針について説明します。

なお，同時実行スレッド数を制御する機能の詳細については，マニュアル「Cosminexus　機能解説」を参照してください。

●Webアプリケーション単位の選択の指針

Webアプリケーション単位の同時実行数を制御することで，J2EEサーバがTCP接続要求だけではなく，Webアプリケーションの実行待ちキューを管理できるようになります。このため，J2EEサーバ上で実行するWebアプリケーションが一つだけの場合でも，Webアプリケーション単位の同時実行スレッド数を設定することをお勧めします。

Webアプリケーション単位での同時実行スレッド数の設定は，Webコンテナ単位で設定する場合に比べて，次のような利点があります。

Webアプリケーションごとの同時実行スレッド数に上限を設けることで，特定の業務に対応するWebアプリケーションへのリクエストが増大した場合に，そのWebアプリケーションがWebコンテナ全体の処理能力を占有しないようにできます。これによって，ほかの業務も滞りなく実行できます。

CPUやI／O処理に掛かる負荷が異なる複数のWebアプリケーションがWebコンテナ上にある場合，それぞれの条件に適した同時実行スレッド数が設定できます。

Webアプリケーションごとにリクエストの実行待ちキューサイズが設定できるので，Webアプリケーションの特徴に応じた実行待ちキュー管理ができます。また，実行待ちキュー以上のリクエストが送信された場合には，クライアントにHTTPレスポンスコードで通知できます。

なお，Webアプリケーション単位の同時実行スレッド数は，稼働中のJ2EEサーバでも動的に変更できます。稼働中のJ2EEサーバで実行するWebアプリケーションの同時実行スレッド数の動的変更の手順については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

●URLグループ単位の選択の指針

Webアプリケーション単位で同時実行スレッド数を制御している場合に，さらに業務ロジック単位で同時実行スレッド数の制御をしたいときには，URLグループ単位で同時実行スレッド数を制御します。

Webアプリケーションが次のような業務ロジックを含む場合，URLグループ単位の設定を検討してください。

ほかの処理に影響を受けないで優先して実行したい業務ロジック

ほかの処理に比べて処理時間が掛かる，またはCPUやI／Oの負荷が大きい業務ロジック

URLグループ単位での同時実行スレッド数の設定は，Webアプリケーション単位だけの設定に比べて，次のような利点があります。

重要度が高い業務ロジック（URLグループ）には，確実に実行するためのスレッド数を割り当てられます。これによって，ほかの業務ロジックに対するリクエスト数が増大した場合も，Webアプリケーション全体の同時実行スレッド数をその業務ロジックに占有されないで，重要度が高い業務ロジックを実行できます。

処理時間が掛かる業務ロジック（URLグループ）の同時実行数に上限を設けることで，特定の業務ロジックによってWebアプリケーション全体の同時実行数が占有されないように制御できます。

Webアプリケーション内にCPUやI／Oの負荷が異なる複数の業務ロジック（URLグループ）がある場合は，業務ロジックに応じた同時実行数が設定できます。

Webアプリケーション内の業務ロジック（URLグループ）ごとにリクエストの待ち行列長（実行待ちキューのキューサイズ）が設定できるので，業務ロジックの特徴に応じた実行待ちキューを管理できます。また，この実行待ちキューがあふれた場合，クライアントにHTTPレスポンスコード503（Service Temporarily Unavailable）を通知できます。

6.3.5　Enterprise Beanの同時実行数を制御する

ここでは，Enterprise Beanの同時実行数を制御する方法について，Enterprise Beanの種類ごとに説明します。なお，インスタンスプーリングおよびセッション制御によるEnterprise Beanの同時実行数制御は，EJBコンテナの機能を利用して実現します。EJBコンテナの機能の詳細は，マニュアル「Cosminexus　機能解説」を参照してください。

＜この項の構成＞

(1)　Enterprise Beanの同時実行数制御で使用できる機能の種類

(2)　Stateless Session Beanの同時実行数制御

(3)　Stateful Session Beanの同時実行数制御

(4)　Entity Beanの同時実行数制御

(5)　Message-driven Beanの同時実行数制御

(1)　Enterprise Beanの同時実行数制御で使用できる機能の種類

Enterprise Beanの同時実行数を制御する場合，EJBコンテナの機能である，次の2種類の機能を利用できます。

インスタンスプーリング

Enterprise Beanのインスタンスを事前に作成しておくことで，クライアントからリクエストが送信されたときにすぐ処理を実行できるようにする機能です。プールするインスタンス数の上限値を設定することで，上限値以上のリクエストの実行を待たせることができます。これによって，同時実行数が制御できます。

参考

運用時にCTMの同時実行数を動的に変更する場合は，上限値は無制限に設定してください。

セッション制御

セッション内で，同時に生成できるセッション（インスタンス）数を制限する機能です。

なお，Enterprise Beanの種類ごとに使用できる機能が異なります。

Enterprise Beanの種類ごとに使用できる同時実行数制御の機能を次の表に示します。

表6-5　Enterprise Beanの種類ごとに使用できる同時実行数制御の機能

Enterprise Beanの種類 | 使用できる制御機能
Stateless Session Bean※ | インスタンスプーリング
Stateful Session Bean | セッション制御
Entity Bean | インスタンスプーリングとセッション制御
Message-driven Bean | インスタンスプーリング

注※　Stateless Session Beanの同時実行数を制御する場合は，CTMを利用することをお勧めします。CTMを利用して同時実行数を制御する方法については，「6.3.6　CTMを使用して同時実行数を制御する」で説明します。

なお，Enterprise Beanの同時実行数制御のうち，実行待ちリクエストをキューの概念で管理できるのは，Message-driven Beanだけです。Message-driven Beanでは，JMSのキューを使用して実行待ちリクエストを管理します。これ以外のEnterprise Beanでは，同時実行数以上のリクエストが送信された場合，設定に応じて次のどれかの処理が実行されます。

インスタンスに空きが出るまで待ち続ける

すぐに例外としてクライアントに返却する

インスタンス取得用に設定したタイムアウト時間が経過したら，例外としてクライアントに返却する（Stateless Session Beanのmethod-readyプールまたはEntity Beanのpoolプールの場合）

(2)　Stateless Session Beanの同時実行数制御

Stateless Session Beanでは，インスタンスプーリングを利用できます。通常の同時アクセス数をインスタンスプーリングの最小値として設定して，想定している最大同時アクセス数以上の値を，インスタンスプーリングの上限値に指定します。これによって，通常のアクセス時にはインスタンスを生成する時間を省略できるので，処理性能が向上します。さらに，アクセス数が増大した場合でも，想定している最大同時アクセス数までは処理でき，それ以上のリクエストの実行は待たせるように制御できます。

なお，デフォルトの設定の場合，上限値以上のリクエストがエラーで返却されることはありません。プールされているインスタンスに空きができるまで待ち続けます。エラーで返却したい場合は，必要に応じてインスタンス取得待ちのタイムアウトを設定してください。

(3)　Stateful Session Beanの同時実行数制御

Stateful Session Beanでは，クライアントごとにセッションごとの状態があるため，厳密な同時実行数制御はできません。ただし，セッション単位での流量制御（セッション制御）ができます。

想定している最大同時セッション数以上の値を，セッション制御の上限値として指定します。アクセス数が増大して，想定している最大同時セッション数以上のアクセスがあった場合には，セッションを確立しないで，クライアントに例外（java.rmi.RemoteException）を通知できます。

ポイント

リクエスト単位で同時実行制御が必要な場合は，サーブレット，JSPまたはStateless Session Beanを経由してStateful Session Beanを呼び出すことで，Webアプリケーションの同時実行数制御またはインスタンスプーリングを利用した同時実行数制御ができるようになります。

(4)　Entity Beanの同時実行数制御

Entity Beanでは，クライアントごとに管理する状態を持つセッションの上限値の設定とインスタンスプーリングによって，同時実行数の制御ができます。なお，セッション数が上限に達した場合，インスタンスプーリングに空きがあっても，新しいセッションでのリクエストは実行できません。

セッション数の上限を超えた場合は，セッションの作成に失敗した時点ですぐにクライアントに例外（java.rmi.RemoteException）が通知されます。また，デフォルトの設定の場合，インスタンスプール数の上限値以上のリクエストは，エラーで返却されることはなく，プールされているインスタンスに空きができるまで待ち続けます。エラーで返却したい場合は，必要に応じてインスタンス取得待ちのタイムアウトを設定してください。

なお，Entity Beanに対するリクエストの実行では，データベースへのアクセスが発生します。このため，同時実行できるリクエスト数は，データベースにアクセスするためのコネクション数にも制限されます。

(5)　Message-driven Beanの同時実行数制御

Message-driven Beanでは，インスタンスプーリングを利用できます。想定している最大メッセージ数以上の値を，インスタンスプーリングの上限値として指定します。これによって，メッセージ到着時にインスタンスを生成する時間を省略できるので，処理性能が向上します。さらに，メッセージ数が増大した場合でも，インスタンスプーリングの上限値以上のメッセージは，実行を待たせるように制御できます。

なお，Message-driven Beanでは，JMSのキューによって，到着メッセージを実行待ちキューで管理できます。

6.3.6　CTMを使用して同時実行数を制御する

CTMを使用している場合，Stateless Session Beanの同時実行数を制御できます。

CTMは，J2EEサーバとは独立したプロセス群です。EJBクライアントとJ2EEサーバ間のStateless Session Beanの呼び出しを中継し，Stateless Session Beanを呼び出す際に，同時実行数制御をします。なお，CTMによる同時実行数制御の単位はJ2EEアプリケーションです。

＜この項の構成＞

(1)　CTMを使用したStateless Session Beanの同時実行数制御

(2)　EJBコンテナのインスタンスプーリングとの使い分けの指針

(1)　CTMを使用したStateless Session Beanの同時実行数制御

CTMによる同時実行数制御（流量制御）によって，次に示すチューニングができます。

CPUやI／O処理に掛かる負荷が異なる，複数のJ2EEアプリケーションがJ2EEサーバ上にある場合に，それぞれの条件に適した同時実行数が設定できます。

CTMで実行待ちキュー（スケジュールキュー）を管理するので，実行待ちリクエスト数を一定数以下に保ち，それ以上のリクエストが送信された場合にはクライアントに例外を通知できます。

特定のJ2EEサーバの負荷が高い場合に，ほかのJ2EEサーバにリクエストを振り分けられます。

CTMによるStateless Session Beanの同時実行数制御の例を次の図に示します。

図6-5　CTMによるStateless Session Beanの同時実行数制御の例

ポイント

CTMは同一ホスト上のJ2EEサーバでのStateless Session Beanの呼び出しを制御して，そのホスト上での同時実行スレッド数を制御できます。アプリケーションサーバマシンのマシンスペックにも左右されますが，1台のマシン当たりCTMデーモンを1プロセス起動して，J2EEサーバを2～4プロセス起動する構成を推奨します。

なお，CTMによる同時実行スレッド数は，稼働中のCTMデーモンでも動的に変更できます。

CTMの同時実行数を制御する機能の詳細については，マニュアル「Cosminexus　機能解説」を参照してください。稼働中のCTMデーモンで実行するCTMの同時実行スレッド数動的変更の手順については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

(2)　EJBコンテナのインスタンスプーリングとの使い分けの指針

CTMを使用して同時実行数を制御することをお勧めします。なお，CTMによる同時実行数制御は，EJBコンテナでのインスタンスプーリングを利用した同時実行数制御と併用できます。

EJBコンテナの機能を使用した同時実行数制御に加えて，CTMによって同時実行数を制御するメリットは，次のとおりです。

あるEJBコンテナで同時実行数が上限に達した場合に，ほかのJ2EEサーバにリクエストを振り分けられます。

同時実行数が上限に達していなくても，特定のJ2EEサーバの負荷が高い場合，ほかのJ2EEサーバにリクエストを振り分けられます。

CTMで実行待ちキュー（スケジュールキュー）の管理をして，実行待ちリクエスト数を一定に保ち，それ以上のリクエストを受け付けた場合はクライアントにエラーを通知できます。

ポイント

CTMによる同時実行数制御とEJBコンテナでのインスタンスプーリングを併用する場合，Stateless Session Beanのインスタンスプーリング数はCTMの同時実行数以上に設定する必要があります。

また，運用時にCTMの同時実行数を動的に変更する場合は，Stateless Session Beanのインスタンスプーリング数の上限は無制限にする必要があります。なお，デフォルトでは無制限に設定されています。デフォルトから変更しないでください。

6.3.7　同時実行数を最適化するためのチューニングパラメタ

ここでは，同時実行数の最適化で使用するチューニングパラメタの設定方法についてまとめて示します。

＜この項の構成＞

(1)　リクエスト処理スレッド数（インプロセスHTTPサーバ使用時）

(2)　Webアプリケーションの同時実行数

(3)　Enterprise Beanの同時実行数

(4)　CTMで制御する同時実行数

(1)　リクエスト処理スレッド数（インプロセスHTTPサーバ使用時）

インプロセスHTTPサーバを使用している場合の，リクエスト処理スレッド数のチューニングパラメタの設定方法について説明します。

次の表に示す項目をSmart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-6　リクエスト処理スレッド数のチューニングパラメタ（インプロセスHTTPサーバ使用時）

設定項目 | 設定対象 | 設定個所（パラメタ名）
J2EEサーバ起動時に生成するリクエスト処理スレッド数 | 論理J2EEサーバ（j2ee-server） | webserver.connector.inprocess_http.init_threads
Webクライアントとの接続数の上限（リクエスト処理スレッド数の上限） | 論理J2EEサーバ（j2ee-server） | webserver.connector.inprocess_http.max_connections
Webクライアントとの接続数の上限を超えた場合に使用されるTCP/IPのListenキュー（バックログ）の最大値 | 論理J2EEサーバ（j2ee-server） | webserver.connector.inprocess_http.backlog
予備スレッド数の最大数 | 論理J2EEサーバ（j2ee-server） | webserver.connector.inprocess_http.max_spare_threads
予備スレッド数の最小数 | 論理J2EEサーバ（j2ee-server） | webserver.connector.inprocess_http.min_spare_threads

なお，Webサーバ連携でHitachi Web Serverを使用している場合のチューニングパラメタについては，マニュアル「Hitachi Web Server」を参照してください。

(2)　Webアプリケーションの同時実行数

URLグループ単位，Webアプリケーション単位，またはWebコンテナ単位に設定します。

(a)　URLグループ単位の同時実行数

URLグループ単位の同時実行数のチューニングパラメタの設定方法について説明します。設定項目ごとに設定方法と設定個所が異なります。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-7　URLグループ単位の同時実行数のチューニングパラメタ（Smart Composer機能で設定する項目）

設定項目
設定対象
設定個所（パラメタ名）

Webコンテナ単位での最大同時実行スレッド数
（Webサーバ連携時）
論理J2EEサーバ（j2ee-server）
webserver.connector.ajp13.max_threads

Webコンテナ単位での最大同時実行スレッド数
（インプロセスHTTPサーバ使用時）
論理J2EEサーバ（j2ee-server）
webserver.connector.inprocess_http.max_execute_threads

Webアプリケーション単位で同時実行数を制御するかどうか
論理J2EEサーバ（j2ee-server）
webserver.container.thread_control.enabled

デフォルトの実行待ちキューサイズ
論理J2EEサーバ（j2ee-server）
webserver.container.thread_control.queue_size

次の表に示す項目は，サーバ管理コマンド（cjsetappprop）またはServer Plug-inで設定します。パラメタは，WAR属性ファイルに定義します。

表6-8　URLグループ単位の同時実行数のチューニングパラメタ（サーバ管理コマンド（cjsetappprop）またはServer Plug-inで設定する項目）

設定項目 | 設定個所（パラメタ名）
Webアプリケーション単位での最大同時実行スレッド数 | <thread-control>タグ下の<thread-control-max-threads>
Webアプリケーションの占有スレッド数 | <thread-control>タグ下の<thread-control-exclusive-threads>
Webアプリケーション単位の実行待ちキューサイズ | <thread-control>タグ下の<thread-control-queue-size>
URLグループ単位の同時実行スレッド数制御の定義名 | <thread-control><urlgroup-thread-control>タグ下の<urlgroup-thread-control-name>
URLグループ単位での最大同時実行スレッド数 | <thread-control><urlgroup-thread-control>タグ下の<urlgroup-thread-control-max-threads>
URLグループ単位の占有スレッド数 | <thread-control><urlgroup-thread-control>タグ下の<urlgroup-thread-control-exclusive-threads>
URLグループ単位の実行待ちキューサイズ | <thread-control><urlgroup-thread-control>タグ下の<urlgroup-thread-control-queue-size>
URLグループ単位の制御対象となるURLパターン | <thread-control><urlgroup-thread-control>タグ下の<urlgroup-thread-control-mapping>

(b)　Webアプリケーション単位の同時実行数

Webアプリケーション単位の同時実行数をチューニングするパラメタの設定方法について説明します。設定項目ごとに設定方法と設定個所が異なります。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-9　Webアプリケーション単位の同時実行数のチューニングパラメタ（Smart Composer機能で設定する項目）

設定項目
設定対象
設定個所（パラメタ名）

Webコンテナ単位での最大同時実行スレッド数
（Webサーバ連携時）
論理J2EEサーバ（j2ee-server）
webserver.connector.ajp13.max_threads

Webコンテナ単位での最大同時実行スレッド数
（インプロセスHTTPサーバ使用時）
論理J2EEサーバ（j2ee-server）
webserver.connector.inprocess_http.max_execute_threads

Webアプリケーション単位で同時実行数を制御するかどうか
論理J2EEサーバ（j2ee-server）
webserver.container.thread_control.enabled

デフォルトの実行待ちキューサイズ
論理J2EEサーバ（j2ee-server）
webserver.container.thread_control.queue_size

次の表に示す項目は，サーバ管理コマンド（cjsetappprop）またはServer Plug-inで設定します。パラメタは，WAR属性ファイルに定義します。

表6-10　Webアプリケーション単位の同時実行数のチューニングパラメタ（サーバ管理コマンド（cjsetappprop）またはServer Plug-inで設定する項目）

設定項目 | 設定個所（パラメタ名）
Webアプリケーション単位での最大同時実行スレッド数 | <thread-control-max-threads>
Webアプリケーションの占有スレッド数 | <thread-control-exclusive-threads>
Webアプリケーション単位の実行待ちキューサイズ | <thread-control-queue-size>

(c)　Webコンテナ単位の同時実行数

Webコンテナ単位の同時実行数をチューニングするパラメタの設定方法について説明します。

次の表に示す項目をSmart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-11　Webコンテナ単位の同時実行数のチューニングパラメタ

設定項目
設定個所
設定個所（パラメタ名）

Webコンテナ単位での最大同時実行スレッド数
（Webサーバ連携時）
論理J2EEサーバ（j2ee-server）
webserver.connector.ajp13.max_threads

Webコンテナ単位での最大同時実行スレッド数
（インプロセスHTTPサーバ使用時）
論理J2EEサーバ（j2ee-server）
webserver.connector.inprocess_http.max_execute_threads

参考

このほか，Webコンテナでは，リダイレクタからのTCP接続要求の最大待ち行列数も指定できます（論理J2EEサーバ（j2ee-server）のwebserver.connector.ajp13.backlog）。ただし，これはソケットのListenキューの大きさを指定するキーであり，リクエストの実行待ちキューと直接の関係はありません。

(3)　Enterprise Beanの同時実行数

Enterprise Beanの同時実行数は，Enterprise Bean単位に設定します。Enterprise Beanの種類ごとに説明します。

(a)　Stateless Session Beanの同時実行数

Stateless Session Beanの同時実行数をチューニングするパラメタの設定方法について説明します。

次の表に示す項目を，サーバ管理コマンド（cjsetappprop）またはServer Plug-inで設定します。パラメタは，Session Bean属性ファイルに定義します。

表6-12　Stateless Session Beanの同時実行数のチューニングパラメタ

設定項目 | 設定個所（パラメタ名）
プールで管理するインスタンスの最大値 | <stateless><pooled-instance>タグ下の<maximum>※
プールで管理するインスタンスの最小値 | <stateless><pooled-instance>タグ下の<minimum>

注※　運用時にCTMの同時実行数を動的に変更する場合は，最大値は無制限（「0」）に設定する必要があります。

(b)　Stateful Session Beanの同時実行数

Stateful Session Beanの同時実行数をチューニングするパラメタの設定方法について説明します。

次の表に示す項目を，サーバ管理コマンド（cjsetappprop）またはServer Plug-inで設定します。パラメタは，Session Bean属性ファイルに定義します。

表6-13　Stateful Session Beanの同時実行数のチューニングパラメタ

設定項目 | 設定個所（パラメタ名）
クライアントから作成可能なセッションの上限 | <stateful>タグ下の<maximum-active-sessions>
使われていないインスタンスが削除されるまでの時間（分） | <stateful>タグ下の<removal-timeout>

(c)　Entity Beanの同時実行数

Entity Beanの同時実行数をチューニングするパラメタの設定方法について説明します。

次の表に示す項目を，サーバ管理コマンド（cjsetappprop）またはServer Plug-inで設定します。パラメタは，Entity Bean属性ファイルに定義します。

表6-14　Entity Beanの同時実行数のチューニングパラメタ

設定項目 | 設定個所（パラメタ名）
クライアントから作成可能なEntity Beanの最大値 | <maximum-instances>
使われていないEntity BeanのEJBObjectが削除されるまでの時間（分） | <entity-timeout>

(d)　Message-driven Beanの同時実行数

Message-driven Beanの同時実行数をチューニングするパラメタの設定方法について説明します。

次の表に示す項目を，サーバ管理コマンド（cjsetappprop）またはServer Plug-inで設定します。パラメタは，Message-driven Bean属性ファイルに定義します。

表6-15　Message-driven Beanの同時実行数のチューニングパラメタ

設定項目 | 設定個所（パラメタ名）
プールで管理するインスタンスの数の最大値 | <pooled-instance><maximum>
プールで管理するインスタンスの数の最小値 | <pooled-instance><minimum>

(4)　CTMで制御する同時実行数

CTMで制御する同時実行数をチューニングするパラメタの設定方法について説明します。CTMデーモン，アプリケーション，およびStateless Session Beanに設定する項目があります。

●CTMデーモンに設定する項目

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-16　CTMで制御する同時実行数のチューニングパラメタ（Smart Composer機能で設定する項目）

設定項目 | 設定対象 | 設定個所（パラメタ名）
CTMが制御するスレッドの最大値およびキューごとのリクエストの登録数 | 論理CTM（component-transaction-monitor） | ctm.DispatchParallelCount

●アプリケーションまたはStateless Session Beanに設定する項目

次の表に示す項目は，サーバ管理コマンドまたはServer Plug-inで設定します。パラメタは，アプリケーション属性ファイルまたはSession Bean属性ファイルに定義します。

表6-17　CTMで制御する同時実行数のチューニングパラメタ（サーバ管理コマンドまたはServer Plug-inで設定する項目）

設定項目 | 定義ファイル | 設定対象 | 設定個所（パラメタ名）
アプリケーションをCTMによる同時実行数制御の対象にするかどうか | アプリケーション属性ファイル | アプリケーション | <managed-by-ctm>
アプリケーションの同時実行スレッド数 | アプリケーション属性ファイル | アプリケーション | <scheduling>タグ下の<parallel-count>
Stateless Session BeanをCTMによる同時実行数制御の対象にするかどうか | Session Bean属性ファイル | Stateless Session Bean | <enable-scheduling>
Bean単位のキューについての設定※ | Session Bean属性ファイル | Stateless Session Bean | <scheduling>タグ下の<parallel-count>

注※　スケジュールキューをBean単位に配置する場合に必要です。スケジュールキューの配置方法は，アプリケーション属性ファイルの<scheduling-unit>タブに設定します。

6.4　Enterprise Beanの呼び出し方法を最適化する

この節では，Enterprise Beanの呼び出し方を最適化する方法について説明します。

通常，Enterprise Beanは，リモートインタフェースを使用してRMI-IIOP経由で呼び出されます。しかし，この方法の場合，同じJ2EEアプリケーションや同じJ2EEサーバ内で動作しているEnterprise Beanから呼び出すときにも，リモート接続と同じオーバーヘッドが掛かってしまいます。

これに対して，Enterprise Beanの呼び出し方を最適化してスループットの向上を図るために，次の呼び出し方法が使用できます。

ローカルインタフェースを使用した呼び出し

リモートインタフェースのローカル呼び出し

リモートインタフェースの参照渡し

これらの呼び出し方法には，それぞれ，次の表に示す特徴があります。この表では，標準仕様に準拠しているか（標準仕様），性能は向上するか（性能），位置透過性はあるか（位置透過），保守性に優れているか（保守性）の四つの特徴で比較しています。アプリケーションやシステムの特徴に応じて使い分けてください。

表6-18　Enterprise Beanの呼び出し方法の特徴

呼び出し方法の種類 | 標準仕様 | 性能 | 位置透過 | 保守性
ローカルインタフェース | ○ | ○ | × | ○
リモートインタフェースのローカル呼び出し | ○ | △ | ○ | ○
リモートインタフェースの参照渡し | × | ○ | △ | ×

（凡例）

○：対応している。／優れている。

△：対応しているが，一部制限がある。／やや悪い。

×：対応していない。／悪い。

なお，ローカルインタフェースの詳細については，EJBの仕様を参照してください。

リモートインタフェースのローカル呼び出しおよびリモートインタフェースの参照渡しの詳細については，マニュアル「Cosminexus　機能解説」を参照してください。

＜この節の構成＞

6.4.1　ローカルインタフェースを使用する

6.4.2　リモートインタフェースのローカル呼び出し最適化機能を使用する

6.4.3　リモートインタフェースの参照渡し機能を使用する

6.4.4　Enterprise Beanの呼び出し方法を最適化するためのチューニングパラメタ

6.4.1　ローカルインタフェースを使用する

アプリケーション開発時に，J2EE標準仕様に準拠したローカルインタフェースを使用する方法です。

ローカルインタフェースは，Enterprise Beanの呼び出しを通常の同一スレッドのメソッド呼び出しとして実行する機能です。J2EEの標準機能なので，ポータビリティがあります。ただし，クライアント側，サーバ側の両方でローカル呼び出し専用のローカルインタフェースを使用したプログラムを作成する必要があるため，位置透過性はなくなります。

なお，ローカルインタフェースは，参照渡しによる呼び出しになります。また，同一J2EEサーバ内であっても，異なるJ2EEアプリケーション間での呼び出しには適用できません。

6.4.2　リモートインタフェースのローカル呼び出し最適化機能を使用する

同一アプリケーション内または同一J2EEサーバ内でのEnterprise Beanのリモートインタフェースによる呼び出しを，同一スレッドの延長によって実行する機能（ローカル呼び出し最適化機能）を使用する方法です。クライアント側，サーバ側の両方でリモートインタフェースを使用したプログラムを作成するので，位置透過性が保てます。

なお，デフォルトの状態では，同一アプリケーション内のローカル呼び出し最適化機能を使用する設定になっています。

6.4.3　リモートインタフェースの参照渡し機能を使用する

ローカル呼び出し最適化機能を使用する場合に，引数や戻り値で使用するオブジェクト型などのサイズが大きいデータの受け渡しを参照渡しにすることで，処理の高速化を図る方法です。

次のような条件の場合に，高速化が期待できます。

表6-19　リモートインタフェースの参照渡しで高速化が期待できる条件

項目 | 処理内容
ビジネスメソッドの処理 | 仮引数経由で取得したデータに対して，直接変更をしないで参照だけする処理
ビジネスメソッドの引数と戻り値 | 配列やCollectionなどのクラスで大量のデータを受け渡す処理
呼び出すEnterprise Beanの位置 | 同一のJ2EEアプリケーション内，または同一のJ2EEサーバ内

ただし，リモートインタフェースでのデータの受け渡しは本来値渡しです。このため，値渡しを前提に作成されたプログラムは正しく動作しなくなるおそれがあるので注意してください。正しく動作しなくなるプログラムの例を次に示します。

図6-6　正しく動作しなくなるプログラムの例

また，次の場合，この機能を使用しても効果がありません。

プリミティブ型（単純型）の場合（常に値渡しになるため）

受け渡すデータのサイズが小さい場合

この機能は，J2EEサーバ単位またはEnterprise Bean単位で設定できます。

6.4.4　Enterprise Beanの呼び出し方法を最適化するためのチューニングパラメタ

ここでは，Enterprise Beanの呼び出し方法の最適化で使用するチューニングパラメタの設定方法についてまとめて示します。

＜この項の構成＞

(1)　ローカルインタフェースの使用

(2)　リモートインタフェースのローカル呼び出し機能の使用

(3)　リモートインタフェースの参照渡し機能の使用

(1)　ローカルインタフェースの使用

アプリケーション作成時に，J2EEで定義されているローカルインタフェースを使用してください。

(2)　リモートインタフェースのローカル呼び出し機能の使用

リモートインタフェースのローカル呼び出し機能のチューニングパラメタの設定方法について説明します。

次の表に示す項目をSmart Composer機能で設定します。パラメタは簡易構築定義ファイルに定義します。

表6-20　リモートインタフェースのローカル呼び出し機能のチューニングパラメタ

設定項目 | 設定対象 | 設定個所（パラメタ名）
ローカル呼び出し最適化機能の適用範囲 | 論理J2EEサーバ（j2ee-server） | ejbserver.rmi.localinvocation.scope

(3)　リモートインタフェースの参照渡し機能の使用

リモートインタフェースの参照渡し機能のチューニングパラメタの設定方法について説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは簡易構築定義ファイルに定義します。

表6-21　リモートインタフェースの参照渡し機能のチューニングパラメタ（Smart Composer機能で設定する項目）

設定項目 | 設定対象 | パラメタ名
リモートインタフェースの参照渡し機能の使用（J2EEサーバ単位） | 論理J2EEサーバ（j2ee-server） | ejbserver.rmi.passbyreference

次の表に示す項目は，サーバ管理コマンド（cjsetappprop）またはServer Plug-inで設定します。パラメタはSession Bean属性ファイルまたはEntity Bean属性ファイルに定義します。

表6-22　リモートインタフェースの参照渡し機能のチューニングパラメタ（サーバ管理コマンド（cjsetappprop）またはServer Plug-inで設定する項目）

設定項目 | パラメタ名
リモートインタフェースの参照渡し機能の使用（Enterprise Bean単位） | <pass-by-reference>

6.5　データベースへのアクセス方法を最適化する

データベースへのアクセス方法の最適化について説明します。

J2EEサーバでは，データベースアクセス方法のチューニングに次の2種類の方法を使用できます。

コネクションプーリング

ステートメントプーリング

＜この節の構成＞

6.5.1　コネクションプーリングを使用する

6.5.2　ステートメントプーリングを使用する

6.5.3　データベースへのアクセス方法を最適化するためのチューニングパラメタ

6.5.1　コネクションプーリングを使用する

ここでは，J2EEサーバでコネクションプーリングを使用する利点と，コネクションプーリングに関連して使用できる機能について説明します。

＜この項の構成＞

(1)　コネクションプーリングを使用する利点

(2)　使用できる機能

(1)　コネクションプーリングを使用する利点

データベースなどのEISとのコネクションの確立は，負荷が高くなる処理です。コネクションプーリングを使用することで，負荷を軽くできます。コネクションプーリングは，J2EEサーバによって一度取得，生成したコネクションをプールしておき，それを再利用することで処理性能の向上を図る機能です。データベースなどにアクセスするたびにコネクションを再取得する場合に比べて，性能劣化を防ぐ効果があります。

なお，EISとの接続方法によって，使用できる機能が異なります。詳細は，マニュアル「Cosminexus　機能解説」を参照してください。

なお，デフォルトの設定では，コネクションプーリングは有効になっています。

(2)　使用できる機能

コネクションプーリングで使用できる機能と設定時の指針について示します。

コネクションプーリングでは，次の機能を使用できます。

プールするコネクションの最大値と最小値を指定する

プール内のコネクションを検査して無効なコネクションを破棄する※1

コネクション取得失敗時にリトライする※2

スイーパによって使わないコネクションをプールから削除する※2

コネクションウォーミングアップによってあらかじめコネクションをプールしておく

コネクション枯渇時のコネクション取得要求を取得待ちキューに入れる

コネクションプール内の不要なコネクションを段階的に減少させる

コネクションプールをクラスタ化する※3

注※1　この機能を使用する場合，コネクションの検査にタイムアウトを設定することもできます。

注※2　これらの機能は，デフォルトの設定では無効になっています。必要に応じて使用してください。

注※3　この機能はデータベースがOracle10gの場合だけ使用できます。

(a)　プールするコネクションの最小値と最大値を指定する

コネクションプーリングを設定する場合は，プールするコネクションの最小値と最大値を設定します。無制限にした場合はコネクションが無制限に確立されます。

最小値および最大値は，定常状態で発生するデータベースなどのEISへの同時アクセス数，トランザクション数，業務の同時実行数などを参考にして決定してください。

(b)　プール内のコネクションを検査して無効なコネクションを破棄する

プール内のコネクションに障害が発生していないかどうかをコネクション取得時または定期的にチェックして，障害が発生したコネクションをプールから削除します（コネクション障害検知）。コネクション取得時に障害が発生しているコネクションを取得してしまうことを防ぎ，接続に失敗する可能性を低くできます。この機能は，DB Connectorを使用してデータベースにアクセスするためのコネクションに対して有効です。なお，SQL Serverを使用する場合，DB ConnectorのselectMethodプロパティにdirectを指定したときには，この機能は使用できません。

コネクション障害検知を実行するタイミングの使い分けの指針は次のとおりです。業務の種類に応じて使い分けてください。

表6-23　コネクション障害検知を実行するタイミングの使い分けの指針

業務の種類
タイミング

EISとの接続の失敗が許容されない業務

コネクション取得頻度が低い業務

コネクション取得時に障害検知を実行する設定をお勧めします。
コネクション取得時に掛かる処理時間は，コネクション障害検知を実行をしない場合に比べて多く掛かりますが，障害が発生しているコネクションを取得する可能性が低くなります。

コネクション取得頻度が高い業務

障害が発生したコネクションを取得してもある程度許容されるような業務

定期的に障害検知を実行する設定をお勧めします。チェック間隔をある程度長くすることで，コネクション障害検知処理のために性能が劣化することを防げます。ただし，障害が発生しているコネクションを取得してしまうおそれがあります。

また，コネクション障害検知を実行する場合，コネクション障害検知の実行にタイムアウトを設定できます。サーバ障害やネットワーク障害が発生してリソースからの応答が返らない場合，コネクション障害検知の実行に対しても応答が返らなくなることがあります。タイムアウトを設定しておくことで，リソースからの応答が返らない場合も，コネクション障害検知処理を終了して，処理を継続できます。なお，この場合は，コネクションに障害が発生していると判断されます。

ポイント

コネクション障害検知にタイムアウトを設定した場合，システム内で，コネクションプールのコネクション数に応じたコネクション管理スレッドが生成されます。このため，コネクション障害検知にタイムアウトを設定すると，設定しない場合に比べて多くのメモリを消費するので，注意が必要です。
コネクション管理スレッドは，コネクションプールのコネクション数の最大値の2倍の数が作成されます。必要なメモリ使用量を適切に見積もってください。

コネクション管理スレッドは，コネクション数調節機能のタイムアウトと共通で使用されます。このため，コネクション障害検知にタイムアウトを設定した場合，コネクション数調節機能のタイムアウトも有効になります。

コネクション障害検知を一定間隔で実施する場合，コネクションプールから取り除いた未使用コネクションは，コネクション数としてカウントされません。このため，コネクションプール内のコネクションとコネクションプールから取り除いた未使用コネクションの総数が，コネクションプールの最大値として指定した値を超える場合があります。

(c)　コネクション取得失敗時にリトライする

コネクションの取得に失敗したときに，ユーザプログラムでリトライする必要がなくなります。業務処理のレスポンスが下がっても，障害発生による業務停止を防ぎたい場合に設定してください。

リトライ回数とリトライ間隔を設定する場合の指針について次に示します。

リトライ回数を増やしたり，リトライ間隔を大きくしたりすると，コネクション取得処理が発生した場合に，待ち時間が発生するおそれがあります。

リトライ間隔×リトライ回数の時間が長過ぎると，RMI-IIOP通信のタイムアウトなどが発生しますが，タイムアウト後もリトライを続けます。このため，リトライ間隔×リトライ回数の時間は，タイムアウト値以下の値になるように設定してください。

同一リソースのコネクションを使用する業務の所要時間にも左右されますが，10秒以上を指定することを推奨します。

(d)　スイーパによって使わないコネクションをプールから自動削除する

一定時間使用しなかったコネクションをスイーパによってプールから自動削除します。コネクションを未使用のままプーリングすると問題が発生する場合に設定します。リソースアダプタ単位に設定できます。

(e)　コネクションウォーミングアップによってあらかじめコネクションをプールしておく

J2EEサーバの起動時またはリソースアダプタのスタート時にコネクションを最小値まであらかじめ取得してプールしておく機能です。コネクションプールの使用を開始した直後の，アプリケーションからのコネクション要求のレスポンスを向上できます。ただし，J2EEサーバ起動またはリソースアダプタのスタート時の処理時間が掛かります。

(f)　コネクション枯渇時のコネクション取得要求を待ち状態にする

プールしているコネクションをすべて使い切っている状態でコネクション取得要求があった場合に，コネクション取得要求を待ち状態にする機能です。

使用中のコネクションが解放されるか，コネクションが破棄されてコネクション最大数よりも少なくなった場合に，すぐにコネクション取得要求を再開できます。また，待ち時間も設定できるので，一定時間を経過してコネクションを取得できなかった場合はエラーにできます。

(g)　コネクションプール内の不要なコネクションを段階的に減少させる

コネクションプール内に不要なコネクションがある場合に，コネクション数を段階的に減らす機能です（コネクション数調節機能）。

一定間隔でコネクションプールの数をチェックします。チェック直前までの間の最大同時実行コネクション数を基準として，プール内にそれ以上の数のコネクションがある場合は，多い分のコネクションを削除します。これによって，プール内のコネクションは実際の稼働実績に適した数になるので，コネクション生成コストの削減や，リソース資源の節約ができます。

また，コネクションの削除処理にタイムアウトを設定できます。タイムアウトには，コネクション管理スレッドを使用します。なお，コネクション管理スレッドは，コネクション障害検知のタイムアウトでも使用されます。

ポイント

コネクション管理スレッドは，コネクション障害検知のタイムアウトと共通で使用されます。このため，コネクション数調節機能にタイムアウトを設定した場合，コネクション障害検知のタイムアウトも有効になります。

(h)　コネクションプールをクラスタ化する

データベースをクラスタ構成にしている場合，コネクションプールもクラスタ構成にして，クラスタ構成になっているデータベースノードごとにコネクションプールを保持できます（コネクションプールのクラスタ化機能）。データベースノードとコネクションプールは1:1で対応しています。データベースノードに障害が発生するとそれに対応するコネクションプールも一時停止し，使用できなくなります。これによって，障害が発生したコネクションを使用するおそれがなくなるため，システムの可用性が向上します。

6.5.2　ステートメントプーリングを使用する

ここでは，ステートメントプーリングを使用する利点と，設定の指針について説明します。

この機能は，DB Connectorを利用している場合に使用できる機能です。また，使用できるかどうかは，EISとの接続方法によって異なります。XDM/RD E2 11-01以前のバージョンの場合，ステートメントプーリングは使用できません。詳細は，マニュアル「Cosminexus　機能解説」を参照してください。

＜この項の構成＞

(1)　ステートメントプーリングを使用する利点

(2)　設定の指針

(1)　ステートメントプーリングを使用する利点

データベースにアクセスするときに必要なSQL文やストアドプロシジャなどのステートメントの生成は，負荷が高くなる処理です。ステートメントプーリングを使用することで，負荷を軽くできます。ステートメントプーリングは，一度生成したステートメントであるPreparedStatementとCallableStatementをプーリングしておき，それを再利用することで処理性能の向上を図る機能です。データベースなどにアクセスするたびにステートメントを再生成する場合に比べて，処理性能が向上します。

なお，PreparedStatementおよびCallableStatementとは，それぞれ，JDBCのAPIであるjava.sql.PreparedStatementとjava.sql.CallableStatementのインスタンスです。

(2)　設定の指針

ステートメントプーリングを利用するためには，アプリケーション開発時に次の点に留意する必要があります。

同じシグネチャを持つjava.sql.Connection#prepareStatementメソッドを使用します。

java.sql.Connection#prepareStatementメソッドでは同じ引数値を指定します。

これらを満たさないアプリケーションでは，ステートメントプーリングは有効に動作しません。

また，ステートメントプーリングを使用するときには，コネクションプーリングとの関連を理解した上で使用してください。アプリケーション構成および環境設定時に留意する点を次に示します。

物理コネクションのインスタンスごとにPreparedStatementおよびCallableStatementがプールされます。このため，コネクション取得時にプールされているコネクションが複数ある場合には，ステートメントがまだプールされていないコネクションが割り当てられることがあります。

それぞれのステートメントのインスタンスをプールするときには，使用しているJDBCドライバのコネクションごとの上限値を考慮してプールサイズを設定する必要があります。

コネクションプールとステートメントプールの関係を次の図に示します。

図6-7　コネクションプールとステートメントプールの関係

ステートメントプーリングのプールサイズを決めるときには，業務処理の内容に応じて，コネクションプーリングとの関係を考慮した上で決めてください。例えば，異なる業務処理で同じデータベースを使用する場合であっても，異なるテーブルにアクセスする場合や異なるSQL文を使用する場合は，一つのDB Connectorでコネクションプールとステートメントプールのサイズを大きくするよりも，業務処理ごとに別々のDB Connectorを用意して，その業務で必要な分だけの小さなコネクションプールやステートメントプールを用意する方が，効率が良い場合があります。

図6-8　業務処理に応じたコネクションプールとステートメントプールの利用

ただし，DB Connectorを複数用意してプールサイズを小さくすると，業務ごとにプールされているコネクション数の余裕がなくなり，アクセスのピーク時にコネクション不足が発生するおそれがあります。このため，業務の同時実行数などを詳細に見積もって，コネクション数不足ができるだけ発生しないようにチューニングしてください。また，プールのサイズは，業務処理ごとに，どのくらいのステートメントを利用するかによって調整してください。

一つのDB Connectorを利用する場合のステートメントプールサイズは，次の値を集計して決定します。

PreparedStatementのプールサイズを設定する指針とサイズの算出方法

コネクションごとのJDBCドライバのリソース制限を上限として，同一のDB Connectorを利用するPreparedStatementの利用数を基に算出してください。なお，JDBCドライバのリソース制限については，使用しているJDBCドライバの制限値に従ってください。

利用数は，次の数を集計して求めます。

サーブレットおよびJSPから，異なる引数を指定してjava.sql.Connection#prepareStatementメソッドを呼び出している数

Session BeanおよびEntity Bean（BMP）から，異なる引数を指定してjava.sql.Connection#prepareStatementメソッドを呼び出している数

Entity Bean（CMP）に対して，J2EEサーバが内部的にPreparedStatementで使用するSQLの数

Message-driven Beanから，異なる引数を指定してjava.sql.Connection#prepareStatementメソッドを呼び出している数

CallableStatementのプールサイズを設定する指針とサイズの算出方法

コネクションごとのJDBCドライバのリソース制限を上限として，同一のDB Connectorを利用するCallableStatementの利用数を基に算出してください。なお，JDBCドライバのリソース制限については，使用しているJDBCドライバの制限値に従ってください。

利用数は，次の数を集計して求めます。

サーブレットおよびJSPから，異なる引数を指定してjava.sql.Connection#prepareCallメソッドを呼び出している数

Session BeanおよびEntity Bean（BMP）から，異なる引数を指定してjava.sql.Connection#prepareCallメソッドを呼び出している数

Message-driven Beanから，異なる引数を指定してjava.sql.Connection#prepareCallメソッドを呼び出している数

6.5.3　データベースへのアクセス方法を最適化するためのチューニングパラメタ

ここでは，データベースへのアクセス方法の最適化で使用するチューニングパラメタの設定方法についてまとめて示します。

＜この項の構成＞

(1)　コネクションプーリング

(2)　ステートメントプーリング

(1)　コネクションプーリング

コネクションプーリングのチューニングパラメタの設定方法について説明します。

次の表に示す項目は，リソースアダプタ単位に，サーバ管理コマンド（cjsetresprop/cjsetrarprop）またはServer Plug-inで設定します。パラメタは，Connector属性ファイルに定義します。

表6-24　コネクションプーリングのチューニングパラメタ

設定項目 | 設定個所（パラメタ名）※1
コネクションプールにプールするコネクションの最小値 | <property>タグに指定するMinPoolSize
コネクションプールにプールするコネクションの最大値 | <property>タグに指定するMaxPoolSize
プール内のコネクションに障害が発生しているかどうかをチェックする方法の選択 | <property>タグに指定するValidationType
プール内のコネクションに障害が発生しているかどうかのチェックを定期的に実行する場合の間隔 | <property>タグに指定するValidationInterval
コネクション枯渇時にコネクション取得要求をキューで管理するかどうかの選択 | <property>タグに指定するRequestQueueEnable
コネクション枯渇時のコネクション取得要求をキューで管理する場合の待ち時間 | <property>タグに指定するRequestQueueTimeout
コネクションの取得に失敗した場合のリトライ回数※2 | <property>タグに指定するRetryCount
コネクションの取得に失敗した場合のリトライ間隔※2 | <property>タグに指定するRetryInterval
コネクションの最終利用時刻からコネクションを自動破棄するかを判定するまでの時間 | <property>タグに指定するConnectionTimeout
コネクションの自動破棄（コネクションスイーパ）が動作する間隔 | <property>タグに指定するSweeperInterval
コネクションのウォーミングアップを使用するかどうかの選択 | <property>タグに指定するWarmup
コネクション障害検知にタイムアウト時間を設定するかどうかの選択※3 | <property>タグに指定するNetworkFailureTimeout
コネクション数調節機能での削除処理にタイムアウト時間を設定するかどうかの選択※3
コネクション数調節機能が動作する間隔 | <property>タグに指定するConnectionPoolAdjustmentInterval

注※1　コネクションプールのクラスタ化機能を使用している場合は，メンバリソースアダプタで設定します。

注※2　コネクションプールのクラスタ化機能を使用している場合は，設定できません。

注※3　コネクション障害検知のタイムアウトとコネクション数調節機能のタイムアウトでは，共通のコネクション管理メソッドを使用します。このため，どちらかのタイムアウトを設定すると，コネクション障害検知とコネクション数調節機能の両方のタイムアウトが有効になります。

ポイント

HiRDBでコネクションプーリング機能を使用する場合，次の設定が必要です。

HiRDBクライアント環境変数のPDSWATCHTIMEに「0」を指定してください。このパラメタについては，マニュアル「HiRDB UAP開発ガイド」を参照してください。

XDM/RD E2でコネクションプーリング機能を使用する場合，次の設定が必要です。

DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文のSVINTERVALパラメタに「0」を指定してください。このパラメタについては，マニュアル「VOS3　Database Connection Server」を参照してください。

(2)　ステートメントプーリング

ステートメントプーリングのチューニングパラメタの設定方法について説明します。

次の表に示す項目は，サーバ管理コマンド（cjsetresprop/cjsetrarprop）またはServer Plug-inで設定します。パラメタは，Connector属性ファイルに定義します。

表6-25　ステートメントプーリングのチューニングパラメタ

設定項目 | パラメタ名※
物理コネクションごとにプールするPreparedStatementの数 | <config-property>タグに指定するPreparedStatementPoolSize
物理コネクションごとにプールするCallableStatementの数 | <config-property>タグに指定するCallableStatementPoolSize

注※　コネクションプールのクラスタ化機能を使用している場合は，メンバリソースアダプタで設定します。

6.6　タイムアウトを設定する

Cosminexusのシステムでは，トラブル発生時にリクエストの応答が戻ってこない状態になることを防ぐために，幾つかのポイントにタイムアウトを設定できます。

この節では，システム全体でタイムアウトが設定できるポイントと，設定する場合の指針について説明します。

＜この節の構成＞

6.6.1　タイムアウトが設定できるポイント

6.6.2　Webフロントシステムでのタイムアウトを設定する

6.6.3　バックシステムでのタイムアウトを設定する

6.6.4　トランザクションタイムアウトを設定する

6.6.5　データベースでのタイムアウトを設定する

6.6.6　J2EEアプリケーションのメソッドタイムアウトを設定する

6.6.7　タイムアウトを設定するチューニングパラメタ

6.6.1　タイムアウトが設定できるポイント

J2EEアプリケーションを実行するシステムでは，次の図に示すポイントにタイムアウトが設定できます。なお，次の図は，クライアントがWebブラウザの場合です。また，Webサーバ連携をする場合とインプロセスHTTPサーバを使用する場合で，ポイントが異なります。

図6-9　タイムアウトが設定できるポイント（Webサーバ連携の場合）

なお，クライアントがEJBクライアントの場合は，WebコンテナをEJBクライアントに置き換えてください。EJBクライアントからデータベースまでの範囲のタイムアウトが設定できます。

また，インプロセスHTTPサーバを使用する場合は，リダイレクタは該当しません。このため，タイムアウトを設定するポイントとして，ポイント2～5と12は該当しません。インプロセスHTTPサーバを使用する場合にタイムアウトが設定できるポイントについて，次の図に示します。

図6-10　タイムアウトが設定できるポイント（インプロセスHTTPサーバの場合）

それぞれのポイントに設定するタイムアウトは，次の表に示すような用途で使い分けられます。

表6-26　各ポイントに設定するタイムアウトの目的とデフォルトのタイムアウト設定

ポイント
タイムアウトの種類
主な用途

1
サーバ側で設定するクライアントからのリクエスト受信およびクライアントへのデータ送信のタイムアウト

Webサーバ連携の場合

通信路の障害，またはWebサーバの障害の検知

インプロセスHTTPサーバの場合

通信路の障害，または不正なクライアントからのアクセスの検知

2
リダイレクタ側で設定するWebコンテナへのリクエスト送信処理のうち，コネクション確立のタイムアウト
通信路の障害またはWebコンテナの障害検知

3
リダイレクタ側で設定するWebコンテナへのリクエスト送信処理のうち，リクエストヘッダおよびリクエストボディ送信のタイムアウト
通信路の障害またはWebコンテナの障害検知

4
リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト
J2EEサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

5
Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト
通信路の障害またはWebサーバの障害検知

6
Webアプリケーションで設定するメソッドの実行時間のタイムアウト
J2EEサーバの業務処理の障害（無限ループ，デッドロックなど）

7
EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIネーミングサービス呼び出しのタイムアウト
J2EEサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

8※
EJBクライアント側で設定するCTMからのEnterprise Bean呼び出しのタイムアウト
J2EEサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

9
EJBで設定するメソッドの実行時間のタイムアウト
J2EEサーバの業務処理の障害（無限ループ，デッドロックなど）

10
EJBコンテナ側で設定するデータベースのトランザクションタイムアウト
データベースサーバの障害（サーバダウンまたはデッドロックなど）の検知，またはリソースの長時間占有防止

11
データベースのタイムアウト
データベースサーバの障害（サーバダウンまたはデッドロックなど）の検知，またはリソースの長時間占有防止

12
Webコンテナ側で設定するリダイレクタへのレスポンス送信のタイムアウト
通信路の障害またはリダイレクタの障害検知

注※　CTMを使用している場合にだけ存在するポイントです。CTMを利用しない構成の場合，ポイント7の範囲はWebコンテナからEJBコンテナにEJBリモート呼び出しを実行してから，EJBコンテナからWebコンテナに実行結果が送信されるまでの間になります。

これらのタイムアウトの基本的な設定指針は次のとおりです。

タイムアウト値の設定は，呼び出し元（WebクライアントまたはEJBクライアント）に近いほど大きな値を設定するのが原則です。このため，次の関係で設定することを推奨します。

ポイント1<ポイント5

ポイント4>ポイント6>ポイント7

ポイント7=ポイント8>ポイント9>ポイント10>ポイント11

ポイント4>ポイント6

ポイント1＜ポイント12

4，7，10，11のポイントのタイムアウト値を設定する場合は，呼び出し処理に通常どの程度の時間が掛かっているかを見極めた上で，呼び出す処理（業務）ごとに算出して設定してください。

なお，1～12のポイントは，システムでの位置づけによって，次の三つに分けられます。

Webフロントシステムで意識する必要があるポイント（1～6，および12）
詳細は，「6.6.2　Webフロントシステムでのタイムアウトを設定する」を参照してください。

バックシステムで意識する必要があるポイント（7～9）
詳細は，「6.6.3　バックシステムでのタイムアウトを設定する」を参照してください。

データベース接続時に意識する必要があるポイント（10と11）
このポイントは，さらにトランザクションでのタイムアウトとデータベースでのタイムアウトに分けて意識する必要があります。
詳細は，「6.6.4　トランザクションタイムアウトを設定する」および「6.6.5　データベースでのタイムアウトを設定する」を参照してください。

それぞれのポイントでの設定については，「6.6.7　タイムアウトを設定するチューニングパラメタ」を参照してください。

参考

それぞれのポイントのデフォルト値は次のとおりです。

ポイント
デフォルト値

1
300秒

2
30秒

3
100秒

4
3,600秒

5
600秒

6
設定されていません。タイムアウトしません。

7
設定されていません。レスポンスを待ち続けます。

8
ポイント7と同じ値がEnterprise Bean呼び出し時に自動的に引き継がれて設定されます。

9
設定されていません。タイムアウトしません。

10
180秒

11
データベースの種類とタイムアウトの設定個所ごとに異なります。

HiRDBの場合

ロック解放待ちタイムアウト：180秒

レスポンスタイムアウト：0秒（HiRDBクライアントはHiRDBサーバからの応答があるまで待ち続けます）

リクエスト間隔タイムアウト：600秒

Oracleの場合（グローバルトランザクションを使用するとき）

ロック解放待ちタイムアウト：60秒

SQL Serverの場合

メモリ取得待ちタイムアウト：-1（-1を指定した場合の動作は，SQL Serverのドキュメントを参照してください）

ロック解放待ちタイムアウト：-1（ロックが解放されるまで待ち続けます）

XDM/RD E2の場合

ロック解放待ちタイムアウト：なし（タイムアウト時間を監視しません）

SQL実行CPU時間タイムアウト：10秒

SQL実行経過時間タイムアウト：0秒（タイムアウト時間を監視しません）

トランザクション経過時間タイムアウト：600秒

レスポンスタイムアウト：0秒（HiRDBクライアントはXDM/RD E2サーバからの応答があるまで待ち続けます）

12
600秒

6.6.2　Webフロントシステムでのタイムアウトを設定する

ここでは，Webフロントシステムでのタイムアウトの設定について説明します。

Webフロントシステムのタイムアウトを設定する場合は，システム全体のタイムアウトのうち，次の図に示す，1～6および12のポイントについて意識する必要があります。この番号は，図6-9または図6-10と対応しています。

ポイント

インプロセスHTTPサーバを使用する場合，設定できるのは1と6のポイントです。2～5，および12のポイントは該当しません。

図6-11　Webフロントシステムの場合に意識するタイムアウトのポイント（1～6，および12のポイント）

Webサーバでのクライアントからのリクエスト受信，およびクライアントへのデータ送信待ち時間（1のポイント）
Webブラウザからの要求が滞った場合に，タイムアウトによってリダイレクタのリソースを解放します。また，Webブラウザへの応答が滞った場合（Webブラウザが受信しない場合）に，タイムアウトによってリダイレクタおよびJ2EEサーバ内のWebコンテナのリソースを解放します。
Webサーバ連携の場合，これらの待ち時間には，同じ値が設定されます。
インプロセスHTTPサーバを使用する場合，クライアントからのリクエスト受信待ち時間と，クライアントへのデータ送信待ち時間には，それぞれ異なる値を指定できます。

Webサーバに登録したリダイレクタでのWebコンテナへのリクエスト送信待ち時間（2および3のポイント）
リダイレクタからWebコンテナへのリクエスト送信時に，Webコンテナ自体のトラブル，またはリダイレクタとWebコンテナ間の通信路でのトラブルによって制御が戻らなくなった場合に，タイムアウトによってリダイレクタのリソースを解放します。また，同時にWebブラウザにエラーを通知します。Webサーバと連携する場合にだけ設定できるポイントです。
ポイント2はWebコンテナとのコネクション確立の待ち時間，ポイント3はWebコンテナへのリクエスト送信処理の待ち時間です。

Webサーバに登録したリダイレクタでのWebコンテナからのデータ受信待ち時間（4のポイント）
J2EEアプリケーションで何かのトラブルが発生して制御が戻らなくなった場合に，タイムアウトによってリダイレクタのリソースを解放します。また，同時にWebブラウザにエラーを通知します。Webサーバと連携する場合にだけ設定できるポイントです。

ポイント

設定の単位はワーカです。このため，業務によって処理に掛かる時間が異なる場合は，業務に対応するWebアプリケーション単位でワーカを定義してタイムアウトを設定することをお勧めします。

Webコンテナでのリダイレクタからのデータ受信待ち時間（5のポイント）
ブラウザからの要求が滞ったときに，J2EEサーバ（Webコンテナ）のリソースを解放します。Webサーバと連携する場合にだけ設定できるポイントです。

Webコンテナ上でのリクエスト処理待ち時間（6のポイント）
J2EEアプリケーションの実行時間監視機能を利用します。
「6.6.6　J2EEアプリケーションのメソッドタイムアウトを設定する」を参照してください。

Webコンテナからリダイレクタへのレスポンス送信待ち時間（12のポイント）
Webコンテナからリダイレクタへのレスポンス送信時に，リダイレクタ自体のトラブル，またはリダイレクタとWebコンテナ間の通信路でのトラブルによって制御が戻らなくなった場合に，タイムアウトによってWebコンテナのリソースを解放します。また，同時にWebブラウザにエラーを通知します。Webサーバと連携する場合にだけ設定できるポイントです。

6.6.3　バックシステムでのタイムアウトを設定する

ここでは，バックシステムでのタイムアウトの設定について説明します。なお，バックシステムでのタイムアウトのうち，データベースなどのEISとのトランザクションに関連するタイムアウトについては，「6.6.4　トランザクションタイムアウトを設定する」で説明します。ここではEJBクライアントとEJBコンテナに関連するタイムアウトについて説明します。

バックシステムのタイムアウトを設定する場合は，システム全体のタイムアウトのうち，次の図に示す，7～9のポイントについて意識する必要があります。なお，この番号は，図6-9または図6-10と対応しています。

図6-12　バックシステムの場合に意識するタイムアウトのポイント

Enterprise Beanをリモート呼び出し（RMI-IIOP通信）する場合とCORBAネーミングサービスを呼び出す場合のクライアント側待ち時間（7のポイント）
CORBAネーミングサービスまたはJ2EEアプリケーションへのアクセスで何かのトラブルが発生して制御が戻らなくなった場合に，タイムアウトによってEJBクライアントにエラーを通知します。

CTMまたはEJBクライアントからEnterprise Beanを呼び出す場合のクライアント側待ち時間（8のポイント）
J2EEアプリケーションで，無限ループやデッドロックなど何らかのトラブルが発生した場合に，CTMのリソースを解放します。また，EJBクライアントにエラーを通知します。

ポイント

EJBクライアントからEnterprise Beanを呼び出す場合，タイムアウトはusrconf.propertiesまたはCosminexusが提供するAPI（com.hitachi.software.ejb.ejbclient.RequestTimeoutConfigクラスのメソッド）に指定できます。

usrconf.propertiesの定義は，プロセス全体に影響します。APIに指定したタイムアウトは，ビジネスメソッドを呼び出すスレッドまたはオブジェクトの範囲に影響します。また，APIの指定は，usrconf.propertiesの定義よりも優先されます。

このため，プロセス全体に設定したい標準的な値をusrconf.propertiesに定義して，呼び出す業務によって細かく設定したい値は適宜APIを使用して設定することをお勧めします。

Enterprise Beanの呼び出しでタイムアウトが発生した場合，EJBクライアント側には，javax.rmi.RemoteException（org.omg.CORBA.TIMEOUTなど）例外が通知されます。これによって，クライアント側のリクエストはキャンセルされます。ただし，この時点でサーバ側のEnterprise Beanの処理がすでに開始されていた場合は，そのまま処理が継続されます。このため，タイムアウトが発生した場合でも，サーバ側の処理は正常に終了することがあります。

EJBコンテナ上でのメソッド処理待ち時間（9のポイント）
J2EEアプリケーションの実行時間監視機能を利用します。
「6.6.6　J2EEアプリケーションのメソッドタイムアウトを設定する」を参照してください。

また，9のポイントで，Stateless Session Beanのmethod-readyプールおよびEntity Beanのpoolプールのインスタンスが時間内に取得できない場合も，タイムアウトが設定できます。この場合は，クライアントにjava.rmi.RemoteException（リモートクライアントの場合）またはjavax.ejb.EJBException（ローカルクライアントの場合）が送出されます。

6.6.4　トランザクションタイムアウトを設定する

ここでは，トランザクションタイムアウトの設定について説明します。トランザクションタイムアウトは，データベースシステムなどEISとのトランザクションに設定します。DB Connectorを使用してデータベースにアクセスするときのトランザクションタイムアウトについて説明します。

トランザクションタイムアウトを設定する場合は，システム全体のタイムアウトのうち，EJBコンテナとデータベースのトランザクション（図の10のポイント）について意識する必要があります。なお，この番号は，図6-9または図6-10と対応しています。

図6-13　EISとのトランザクションで意識するタイムアウトのポイント

トランザクションタイムアウトが発生すると，Application Serverによって，次の処理が実行されます。

実行中のトランザクションはロールバックされます。

トランザクションに参加しているコネクションはクローズされ，コネクションプールから削除されます。

ポイント

トランザクションのタイムアウトは，CMTの場合とBMTの場合で設定方法が異なります。

CMTの場合
CMTの場合，トランザクションのタイムアウトは，usrconf.propertiesで定義するか，またはEnterprise Bean，インタフェース，もしくはメソッドの属性として設定できます。Enterprise Bean，インタフェースまたはメソッドの属性は，サーバ管理コマンドで設定します。
usrconf.propertiesの定義は，プロセス全体に影響します。Enterprise Bean，インタフェースまたはメソッドの属性に設定したタイムアウトは，該当するEnterprise Bean，インタフェースまたはメソッドが使用するトランザクションの範囲だけに影響します。また，この指定は，usrconf.propertiesの定義よりも優先されます。
このため，プロセス全体に設定したい標準的な値をusrconf.propertiesに定義して，呼び出す業務によって細かく設定したい値はEnterprise Bean，インタフェース，またはメソッドの属性として設定することをお勧めします。

BMTの場合
BMTの場合，トランザクションのタイムアウトは，usrconf.propertiesまたはJTAのAPI（javax.transaction.UserTransaction#setTransactionTimeoutメソッド）に指定できます。
usrconf.propertiesの定義は，プロセス全体に影響します。APIに指定したタイムアウトは，APIを発行したトランザクションの範囲だけに影響します。また，APIの指定は，usrconf.propertiesの定義よりも優先されます。
このため，プロセス全体に設定したい標準的な値をusrconf.propertiesに定義して，呼び出す業務によって細かく設定したい値は適宜APIを使用して設定することをお勧めします。

トランザクションタイムアウトが発生した場合，ユーザアプリケーションに例外は通知されません。ただし，メッセージKDJE31002-WがログファイルとJ2EEサーバのコンソールに出力されます。また，トランザクションタイムアウトが発生したあとで，ユーザアプリケーションから該当するトランザクションを使用してJTAインタフェースまたはJDBCインタフェースを使用しようとすると，例外が通知されます。

6.6.5　データベースでのタイムアウトを設定する

ここでは，次に示すデータベースでのタイムアウトの設定について説明します。

HiRDB

Oracle

SQL Server

XDM/RD E2

なお，Oracleの場合は，グローバルトランザクションとローカルトランザクションのどちらを使用しているかによって，設定できる項目が異なります。

＜この項の構成＞

(1)　HiRDBのタイムアウト

(2)　Oracleのタイムアウト（ローカルトランザクションの場合）

(3)　Oracleのタイムアウト（グローバルトランザクションの場合）

(4)　SQL Serverのタイムアウト

(5)　XDM/RD E2のタイムアウト

(6)　データベースへのアクセスでタイムアウトまたはデッドロックが発生した場合のユーザアプリケーションの処理

(1)　HiRDBのタイムアウト

HiRDBでは，次の3種類のタイムアウトを設定できます。

ロック解放待ちタイムアウト
デッドロックやリソースの長時間占有を防止するために設定するタイムアウトです。HiRDBサーバのシステム共通定義のpd_lck_wait_timeoutパラメタに設定します。ここで設定するタイムアウト時間は，排他待ち時間を監視する最大時間です。排他待ち時間とは，排他要求が待ち状態になってから解除されるまでの時間です。
このタイムアウトが発生した場合にApplication ServerおよびHiRDBによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すHiRDBのメッセージKFPA11770-Iが出力されます。または，デッドロックが発生したことを示すHiRDBのメッセージKFPA11911-Eが出力されます。

実行中のトランザクションはロールバックされます。

ユーザアプリケーションのビジネスメソッド終了後に，コネクションはクローズされ，コネクションプールから削除されます。

レスポンスタイムアウト
データベースシステムのサーバ側の障害を検知するためのタイムアウトです。
HiRDBのクライアント環境変数のPDCWAITTIMEに設定します。ここで設定するタイムアウト時間は，HiRDBクライアントからHiRDBサーバに要求をしてから，応答が戻ってくるまでのHiRDBクライアントの最大待ち時間です。長時間SQLの時間を監視する場合などに指定します。
このタイムアウトが発生した場合にApplication ServerおよびHiRDBによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すHiRDBのメッセージKFPA11732-Eが出力されます。

実行中のトランザクションはロールバックされます。

コネクションはクローズされて，コネクションプールから削除されます。

リクエスト間隔タイムアウト
データベースシステムのクライアント側の障害を検知するためのタイムアウトです。
HiRDBのクライアント環境変数のPDSWAITTIMEに設定します。ここで設定するタイムアウトは，HiRDBサーバがHiRDBクライアントからの要求に対する応答を返してから，次にHiRDBクライアントから要求が送信されるまでのHiRDBサーバの最大待ち時間です。時間監視は，トランザクションの処理中（SQL実行開始からコミットまたはロールバックまでの間）が対象になります。HiRDBクライアントからの要求がHiRDBサーバに到着した段階でリセットされます。
このタイムアウトが発生した場合にApplication ServerおよびHiRDBによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すHiRDBのメッセージKFPA11723-Eが出力されます。

実行中のトランザクションはロールバックされます。

コネクションはクローズされて，コネクションプールから削除されます。

(2)　Oracleのタイムアウト（ローカルトランザクションの場合）

Oracleでローカルトランザクションを使用している場合は，次のタイムアウトを設定できます。

クエリータイムアウト
クエリータイムアウトは，JDBCドライバとしてOracle JDBC Thin Driverを使用する場合だけ設定できるタイムアウトです。java.sql.StatementクラスのsetQueryTimeoutメソッドを利用してタイムアウトを設定します。ただし，このタイムアウトが有効になるのは，MTS接続の場合だけです。専用接続では無効です。詳細はオラクルのサポートサービスにお問い合わせください。
なお，JDBCドライバにCosminexus DABroker Libraryを使用する場合は， setQueryTimeoutメソッドは使用できません。

なお，デッドロックが発生した場合は，OracleのメッセージORA-00060が出力されます。また，Application Serverによってユーザアプリケーションのビジネスメソッド終了後にコネクションがクローズされ，コネクションプールから削除されます。

(3)　Oracleのタイムアウト（グローバルトランザクションの場合）

Oracleでグローバルトランザクションを使用している場合は，次のタイムアウトを設定できます。

クエリータイムアウト
クエリータイムアウトについては，「(2) Oracleのタイムアウト（ローカルトランザクションの場合）」のクエリータイムアウトの説明を参照してください。

ロック解放待ちタイムアウト
デッドロックやリソースの長時間占有を防止するために設定するタイムアウトです。Oracleのサーバ定義のDISTRIBUTED_LOCK_TIMEOUTパラメタに設定します。このタイムアウトが発生した場合にApplication ServerおよびOracleによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すOracleのメッセージORA-02049が出力されます。または，デッドロックが発生したことを示すOracleのメッセージORA-00060が出力されます。

ユーザアプリケーションのビジネスメソッド終了後に，コネクションはクローズされ，コネクションプールから削除されます。

なお，実行中のトランザクションはロールバックされません。

(4)　SQL Serverのタイムアウト

SQL Serverでは，次の2種類のタイムアウトを設定できます。

メモリ取得待ちタイムアウト
SQL実行時のメモリ取得待ち時間を監視するために設定するタイムアウトです。SQL Serverの環境設定オプションのquery waitパラメタに設定します。ここで設定するタイムアウト時間は，SQLの実行に必要なメモリが得られなかったときのメモリ取得待ち時間です。
このタイムアウトが発生した場合にApplication ServerおよびSQL Serverによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すSQL Serverのメッセージ8645が出力されます。

実行中のトランザクションはロールバックされます。

ユーザアプリケーションプログラムのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

ロック解放待ちタイムアウト
デッドロックやリソースの長時間占有を防止するために設定するタイムアウトです。SQL ServerのSET LOCK_TIMEOUTステートメントを実行することで設定します。ここで設定するタイムアウト時間は，ロックが解除されるまでの待ち時間です。
このタイムアウトが発生した場合にApplication ServerおよびSQL Serverによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すSQL Serverのメッセージ1222が出力されます。

ユーザアプリケーションプログラムのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

また，SQL Serverでデッドロックが発生した場合にApplication ServerおよびSQL Serverによって実行される動作は次のとおりです。

ユーザアプリケーションに例外（java.sql.SQLException）が通知されます。

デッドロックが発生したことを示すSQL Serverのメッセージ1205が出力されます。

実行中のトランザクションはロールバックされます。

ユーザアプリケーションプログラムのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

(5)　XDM/RD E2のタイムアウト

XDM/RD E2では，次の5種類のタイムアウトを設定できます。

ロック解放待ちタイムアウト
デッドロックやリソースの長時間占有を防止するために設定するタイムアウトです。XDM/BASEのシステムオプション定義のTIMERパラメタに設定します。ここで設定するタイムアウト時間は，排他待ち時間を監視する最大時間です。排他待ち時間とは，排他要求が待ち状態になってから解除されるまでの時間です。
このタイムアウトが発生した場合に，Application ServerおよびXDM/RD E2によって実行される動作は次のとおりです。

J2EEアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトまたはデッドロックが発生したことを示すXDM/RD E2のメッセージJXZ1911Iが出力されます。

実行中のトランザクションはロールバックされます。

J2EEアプリケーションのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

また，XDM/RD E2でデッドロックが発生したときの動作は，ロック解放待ちタイムアウトが発生したときと同じになります。

SQL実行CPU時間タイムアウト
SQL実行時のCPU処理時間を監視するために設定するタイムアウトです。DBコネクションサーバのコントロール空間起動制御文またはサーバ空間起動制御文のSQLCTIMEパラメタに設定します。ここで設定するタイムアウト時間は，一つのSQLを実行したときのCPU処理時間を監視する最大時間です。長時間SQLの時間を監視する場合などに指定します。
このタイムアウトが発生した場合にApplication ServerおよびXDM/RD E2によって実行される動作は次のとおりです。

J2EEアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すメッセージが出力されます。メッセージは，DBコネクションサーバのコントロール空間起動制御文に指定したVPARTOPTIONパラメタの指定値によって変わります。指定を省略するかERROR NORMALを指定した場合には，HiRDBクライアントのメッセージKFPA11723-Eが出力されます。それ以外の値を指定した場合には，XDM/RD E2のメッセージJXZ1874Iが出力されます。

実行中のトランザクションはロールバックされます。

VPARTOPTIONパラメタの指定を省略するかERROR NORMALを指定した場合には，コネクションはクローズされ，コネクションプールから削除されます。それ以外の値を指定した場合には，タイムアウト発生後の初回のデータベースアクセス時，またはJ2EEアプリケーションのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

SQL実行経過時間タイムアウト
SQL実行時の経過時間を監視するために設定するタイムアウトです。DBコネクションサーバのコントロール空間起動制御文またはサーバ空間起動制御文のSQLETIMEパラメタに設定します。ここで設定するタイムアウト時間は，一つのSQLを実行したときの経過時間を監視する最大時間です。長時間SQLの時間を監視する場合などに指定します。
このタイムアウトが発生した場合にApplication ServerおよびXDM/RD E2によって実行される動作は次のとおりです。

J2EEアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すメッセージが出力されます。メッセージは，DBコネクションサーバのコントロール空間起動制御文に指定したVPARTOPTIONパラメタの指定値によって変わります。指定を省略するか，ERROR NORMALまたはERROR SQLCTIMEを指定した場合には，HiRDBクライアントのメッセージKFPA11723-Eが出力されます。それ以外の値を指定した場合には，XDM/RD E2のメッセージJXZ1874Iが出力されます。

実行中のトランザクションはロールバックされます。

VPARTOPTIONパラメタの指定を省略するか，ERROR NORMALまたはERROR SQLCTIMEを指定した場合には，コネクションはクローズされ，コネクションプールから削除されます。それ以外の値を指定した場合には，タイムアウト発生後の初回のデータベースアクセス時，またはJ2EEアプリケーションのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

トランザクション経過時間タイムアウト
トランザクションの開始時点からの経過時間を監視するために設定するタイムアウトです。DBコネクションサーバのコントロール空間起動制御文またはサーバ空間起動制御文のSVETIMEパラメタに設定します。ここで設定するタイムアウト時間は，トランザクションの経過時間を監視する最大時間です。
このタイムアウトが発生した場合にApplication ServerおよびXDM/RD E2によって実行される動作は次のとおりです。なお，タイムアウトが発生したときにSQLを実行していた場合には，その時点で実行されます。SQLを実行していなかった場合には，タイムアウト発生後のSQL実行時に実行されます。

J2EEアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すメッセージが出力されます。メッセージは，DBコネクションサーバのコントロール空間起動制御文に指定したVPARTOPTIONパラメタの指定値によって変わります。指定を省略するか，ERROR NORMALまたはERROR SQLCTIMEを指定した場合には，HiRDBクライアントのメッセージKFPA11723-Eが出力されます。それ以外の値を指定した場合には，XDM/RD E2のメッセージJXZ1874Iが出力されます。

実行中のトランザクションはロールバックされます。

VPARTOPTIONパラメタの指定を省略するか，ERROR NORMALまたはERROR SQLCTIMEを指定した場合には，コネクションはクローズされ，コネクションプールから削除されます。それ以外の値を指定した場合には，タイムアウト発生後の初回のデータベースアクセス時，またはJ2EEアプリケーションのビジネスメソッドの終了後に，コネクションはクローズされ，コネクションプールから削除されます。

レスポンスタイムアウト
データベースシステムのサーバ側の障害を検知するためのタイムアウトです。
HiRDBのクライアント環境変数のPDCWAITTIMEに設定します。ここで設定するタイムアウト時間は，HiRDBクライアントからXDM/RD E2サーバに要求をしてから，応答が戻ってくるまでのHiRDBクライアントの最大待ち時間です。長時間SQLの時間を監視する場合などに指定します。
このタイムアウトが発生した場合にApplication ServerおよびHiRDBによって実行される動作は次のとおりです。

J2EEアプリケーションに例外（java.sql.SQLException）が通知されます。

タイムアウトが発生したことを示すHiRDBクライアントのメッセージKFPA11732-Eが出力されます。

実行中のトランザクションはロールバックされます。

コネクションはクローズされて，コネクションプールから削除されます。

(6)　データベースへのアクセスでタイムアウトまたはデッドロックが発生した場合のユーザアプリケーションの処理

ユーザアプリケーションでデータベースのタイムアウトまたはデッドロックによる例外が発生した場合には，実行中のトランザクションをロールバックして，ビジネスメソッドの処理を中止してください。また，必要に応じてこの項で説明したタイムアウトパラメタを見直してください。

6.6.6　J2EEアプリケーションのメソッドタイムアウトを設定する

ここでは，J2EEアプリケーションのメソッドタイムアウトの設定について説明します。メソッドタイムアウトを設定することによって，ポイント6とポイント9で，WebコンテナまたはEJBコンテナ上の業務処理での無限ループが発生した場合などに，タイムアウトによって検知できるようになります。また，タイムアウトを検知したメソッドを強制的にキャンセル（メソッドキャンセル）することもできます。メソッドキャンセル機能の詳細については，マニュアル「Cosminexus　機能解説」を参照してください。

メソッドタイムアウトを設定する場合の考え方について説明します。

J2EEアプリケーション内でメソッドの呼び出しが入れ子になっている場合，タイムアウト値として，呼び出し元の方に大きな値を設定するように，メソッドの呼び出し順序を考慮して設定してください。

設定例を次に示します。

図6-14　メソッドのタイムアウトの設定例

この例では，呼び出し元に近いメソッドに大きな値を設定しています。これによって，メソッドのどこかでタイムアウトが発生した場合，クライアントから遠いメソッドから順番にタイムアウトが発生します。タイムアウトはメッセージで通知されます。設定によっては，このタイミングでメソッドキャンセルを自動実行できます。

リモート呼び出しを実行するメソッドに対してメソッドタイムアウトおよびメソッドキャンセルを設定した場合は，呼び出し順序に注意してください。メソッドキャンセル機能では，リモート呼び出し中のメソッドは保護区で実行中と判断されます。呼び出し元に近いメソッドで先にタイムアウトが発生した場合，メソッドはリモート呼び出し中であるため，メソッドキャンセルができません。例のように呼び出し元に近い方に大きい値を設定しておけば，タイムアウトは呼び出し元から遠い順に発生するため，タイムアウトが発生したメソッドがリモート呼び出しをしていることはありません。このため，確実にメソッドキャンセルを実行できます。

ローカル呼び出しを実行するメソッドに対してメソッドタイムアウトおよびメソッドキャンセルをする設定をした場合も，呼び出し元から遠い順にキャンセルされるようにすることで，タイムアウトが発生したメソッドとキャンセルが実行されたメソッドを一致させることができます。

タイムアウト値を設定できるメソッドについては，マニュアル「Cosminexus　機能解説」を参照してください。

ローカル呼び出しのメソッドを入れ子で呼び出している場合の注意

簡易構築定義ファイルの<param-name>タグに指定するejbserver.rmi.localinvocation.scopeにappまたはallを指定している場合，一つのメソッドから入れ子で呼び出されるローカル呼び出しのメソッドは，すべて同一スレッド上で実行されます。このとき，次の点に注意してください。

入れ子で呼び出されるメソッドのタイムアウトやメソッドキャンセルが失敗すると，そのメソッドが終了するまで同一スレッドのほかのメソッドではタイムアウトが発生しません。

タイムアウトが発生したメソッドから入れ子で呼び出されているメソッドに対してメソッドキャンセルを実行した場合，コンテナによってキャンセルされるのは，メソッドキャンセルを実行した対象のメソッドだけです。タイムアウトが発生した呼び出し元のメソッドは，キャンセルの対象にはなりません。このため，キャンセルを実行したあとも，通常入れ子のメソッドの呼び出す場合と同様に，順次呼び出されたメソッドが終了していきます。なお，それらの順次呼び出されるメソッドもタイムアウト監視の対象になります。

同一スレッド上でローカル呼び出しのメソッドを入れ子で呼び出している場合の注意を次の図に示します。

図6-15　同一スレッド上でローカル呼び出しのメソッドを入れ子で呼び出している場合の注意

6.6.7　タイムアウトを設定するチューニングパラメタ

ここでは，タイムアウトの設定で使用するチューニングパラメタの設定方法についてまとめて示します。

＜この項の構成＞

(1)　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト

(2)　リダイレクタ側で設定するWebコンテナへのデータ送信のタイムアウト

(3)　リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト

(4)　Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト

(5)　Webコンテナ側で設定するリダイレクタへのデータ受信のタイムアウト

(6)　EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト

(7)　EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト

(8)　EJBコンテナ側で設定するデータベースのトランザクションタイムアウト（DB Connectorを使用した場合）

(9)　データベースのタイムアウト

(10)　J2EEアプリケーションのメソッドタイムアウト

(1)　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト

図6-9または図6-10のポイント1のタイムアウトを設定するチューニングパラメタです。使用するWebサーバによって設定個所が異なります。

Webサーバ連携の場合は，Webサーバ単位に設定します。ファイル編集によって設定します。

表6-27　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウトのチューニングパラメタ（Webサーバ連携の場合）

設定項目 | 設定個所
クライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト | httpsd.confのTimeoutディレクティブ

注　Web Redirectorを使用する場合などで，WebサーバとしてMicrosoft IISを使用しているときには，isapi_redirect.confのreceive_client_timeoutキーを編集してください。

インプロセスHTTPサーバの場合は，J2EEサーバ単位に設定します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-28　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウトのチューニングパラメタ（インプロセスHTTPサーバの場合）

設定項目 | 設定対象 | 設定個所（パラメタ名）
クライアントからのリクエスト受信のタイムアウト | 論理J2EEサーバ（j2ee-server） | webserver.connector.inprocess_http.receive_timeout
クライアントへのデータ送信のタイムアウト | 論理J2EEサーバ（j2ee-server） | webserver.connector.inprocess_http.send_timeout

(2)　リダイレクタ側で設定するWebコンテナへのデータ送信のタイムアウト

図6-9のポイント2，およびポイント3のタイムアウトを設定するチューニングパラメタです。リダイレクタ側で設定するタイムアウトのチューニングパラメタについて説明します。なお，これらのチューニングパラメタは，Webサーバ連携の場合だけ指定できます。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-29　リダイレクタ側で設定するタイムアウトのチューニングパラメタ

ポイント | 設定項目 | 設定対象 | 設定個所（パラメタ名）※
2 | リクエスト送信時のWebコンテナに対するコネクション確立のタイムアウト | 論理Webサーバ（web-server） | JkConnectTimeout
3 | リクエスト送信のタイムアウト | 論理Webサーバ（web-server） | JkSendTimeout

注※　Web Redirectorを使用する場合などで，WebサーバとしてMicrosoft IISを使用しているときには，isapi_redirect.confのconnect_timeoutキーを編集してください。

(3)　リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト

図6-9のポイント4のタイムアウトを設定するチューニングパラメタです。

リダイレクタのワーカ定義単位で設定します。リダイレクタ側で設定するタイムアウトのチューニングパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-30　リダイレクタ側で設定するタイムアウトのチューニングパラメタ

設定項目 | 設定対象 | 設定個所（パラメタ名）
レスポンスデータ待ちの通信タイムアウト | 論理Webサーバ（web-server） | worker.<ワーカ名>.receive_timeout

Webサーバ連携の場合だけ指定できます。

(4)　Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト

図6-9のポイント5のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-31　Webコンテナ側で設定するタイムアウトのチューニングパラメタ

設定項目 | 設定対象 | 設定個所（パラメタ名）
リダイレクタからの応答待ちのタイムアウト | 論理J2EEサーバ（j2ee-server） | webserver.connector.ajp13.receive_timeout

Webサーバ連携の場合だけ指定できます。

(5)　Webコンテナ側で設定するリダイレクタへのデータ受信のタイムアウト

図6-9のポイント12のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-32　Webコンテナ側で設定するタイムアウトのチューニングパラメタ

設定項目 | 設定対象 | パラメタ名
レスポンス送信処理のタイムアウト | 論理J2EEサーバ（j2ee-server） | webserver.connector.ajp13.send_timeout

Webサーバ連携の場合だけ指定できます。

(6)　EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト

図6-9または図6-10のポイント7のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位，EJBクライアントアプリケーション単位またはAPIによる呼び出し単位に設定します。

EJBクライアント側で設定するタイムアウトのチューニングパラメタ（RMI-IIOP通信によるリモート呼び出し）を次の表に示します。

表6-33　EJBクライアント側で設定するタイムアウトのチューニングパラメタ（RMI-IIOP通信によるリモート呼び出し）

単位
設定方法
設定項目
設定個所

J2EEサーバ単位
Smart Composer機能
クライアントとサーバ間の通信タイムアウト

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.rmi.request.timeout

EJBクライアントアプリケーション単位
ファイル編集または開始時に指定するシステムプロパティの指定

定義ファイル（ファイル編集の場合）

usrconf.properties

パラメタ名

ejbserver.rmi.request.timeoutキー

API単位
API

オブジェクト単位で設定する場合

RequestTimeoutConfig#setRequestTimeout(java.rmi.Remote obj, int sec)メソッド※

スレッド単位で設定する場合

RequestTimeoutConfig#setRequestTimeout(int sec)メソッド※

注※　パッケージ名はcom.hitachi.software.ejb.ejbclientです。

EJBクライアント側で設定するタイムアウトのチューニングパラメタ（ネーミングサービス呼び出し）を次の表に示します。

表6-34　EJBクライアント側で設定するタイムアウトのチューニングパラメタ（ネーミングサービス呼び出し）

単位
設定方法
設定項目
設定個所

J2EEサーバ単位
Smart Composer機能
ネーミングサービスとの通信タイムアウト時間

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.jndi.request.timeout

EJBクライアントアプリケーション単位
ファイル編集または開始時に指定するシステムプロパティの指定

定義ファイル（ファイル編集の場合）

usrconf.properties

パラメタ名

ejbserver.jndi.request.timeoutキー

(7)　EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト

図6-9または図6-10のポイント8のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位，EJBクライアントアプリケーション単位またはAPIによる呼び出し単位に設定します。

なお，このタイムアウトの設定値には，「(6) EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト」で指定した設定値と同じ値が引き継がれます。

(8)　EJBコンテナ側で設定するデータベースのトランザクションタイムアウト（DB Connectorを使用した場合）

図6-9または図6-10のポイント10のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位，Enterprise Bean，インタフェース，メソッド単位（CMTの場合），またはAPIによる呼び出し単位（BMTの場合）に設定します。

トランザクションタイムアウトのチューニングパラメタを次の表に示します。

表6-35　トランザクションタイムアウトのチューニングパラメタ

単位
設定方法
設定項目
設定個所

J2EEサーバ単位
Smart Composer機能
トランザクションのトランザクションタイムアウト時間のデフォルト

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.jta.TransactionManager.defaultTimeOut

Enterprise Bean，インタフェース，メソッド単位（CMTの場合）
サーバ管理コマンドのcjsetapppropコマンド
トランザクションタイムアウト時間

定義ファイル

Session Bean属性ファイル，Entity Bean属性ファイル，またはMessage-driven Bean属性ファイル

パラメタ名

<ejb-transaction-timeout>

API単位（BMTの場合）
API
UserTransaction#setTransactionTimeoutメソッド※

注※　パッケージ名はjavax.transactionです。

(9)　データベースのタイムアウト

図6-9または図6-10のポイント11のタイムアウトを設定するチューニングパラメタです。

データベースのタイムアウトは，使用するデータベースの種類，およびサーバの動作モードによって異なります。なお，ここでは，DB Connectorを使用してHiRDB，Oracle，SQL ServerまたはXDM/RD E2にアクセスする場合のタイムアウトの設定方法について説明します。

参考

Oracleを使用している場合，チューニングパラメタによってタイムアウトが設定できるのは，グローバルトランザクションを使用しているときだけです。ローカルトランザクションを使用している場合，パラメタによってタイムアウトを設定することはできません。ただし，メソッドで設定するクエリータイムアウトは，ローカルトランザクション，グローバルトランザクションのどちらでも設定できます。

(a)　HiRDBのタイムアウトの設定

HiRDBサーバのシステム共通定義またはHiRDBのクライアント環境変数に設定します。詳細は，マニュアル「HiRDB システム定義」またはマニュアル「HiRDB UAP開発ガイド」を参照してください。

HiRDBのタイムアウトを設定するチューニングパラメタを次の表に示します。

表6-36　HiRDBのタイムアウトを設定するチューニングパラメタ

タイムアウトの種類 | 設定個所 | 設定方法（パラメタ名） | 設定内容
ロック解放待ちタイムアウト | HiRDBサーバのシステム共通定義 | pd_lck_wait_timeoutパラメタ | 設定値は任意です。
レスポンスタイムアウト | HiRDBのクライアント環境変数 | PDCWAITTIME | トランザクションタイムアウトの値よりも大きな値を指定します。
リクエスト間隔タイムアウト | HiRDBのクライアント環境変数 | PDSWAITTIME | トランザクションタイムアウトの値よりも大きな値を指定します。

(b)　Oracleのタイムアウトの設定（グローバルトランザクションを使用している場合）

Oracleのサーバ定義のDISTRIBUTED_LOCK_TIMEOUTパラメタに設定します。

なお，このほか，XAOpenStringのSesTmパラメタの設定がタイムアウトに影響します。このパラメタは，チューニングできません。

(c)　SQL Serverのタイムアウトの設定

SQL Serverの環境設定オプションのパラメタ，またはステートメントの実行によって設定します。

SQL Serverのタイムアウトを設定するチューニングパラメタを次の表に示します。

表6-37　SQL Serverのタイムアウトを設定するチューニングパラメタ

タイムアウトの種類 | 設定個所 | 設定方法（パラメタ名／ステートメント名） | 設定内容
メモリ取得待ちタイムアウト | SQL Serverの環境設定オプション（SQL Server 2000の場合）またはサーバー構成オプション（SQL Server 2005の場合） | query waitパラメタ | 設定値は任意です。
ロック解放待ちタイムアウト | － | SET LOCK_TIMEOUTステートメント | 設定値は任意です。

（凡例）

－：該当しない。

(d)　XDM/RD E2のタイムアウトの設定

XDM/BASEのシステムオプション定義，HiRDBのクライアント環境変数，またはDBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文に設定します。

XDM/RD E2のタイムアウトを設定するチューニングパラメタを次の表に示します。

表6-38　XDM/RD E2のタイムアウトを設定するチューニングパラメタ

タイムアウトの種類 | 設定個所 | 設定方法（パラメタ名） | 設定内容
ロック解放待ちタイムアウト | XDM/BASEのシステムオプション定義 | TIMER | 設定値は任意です。※1
SQL実行CPU時間タイムアウト | DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文 | SQLCTIME | トランザクションタイムアウトの値よりも大きな値を指定します。※2
SQL実行経過時間タイムアウト | DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文 | SQLETIME | トランザクションタイムアウトの値よりも大きな値を指定します。※2
トランザクション経過時間タイムアウト | DBコネクションサーバのコントロール空間起動制御文／サーバ空間起動制御文 | SVETIME | トランザクションタイムアウトの値よりも大きな値を指定します。※2
レスポンスタイムアウト | HiRDBクライアント環境変数 | PDCWAITTIME | トランザクションタイムアウトの値よりも大きな値を指定します。※3

注※1

詳細については，マニュアル「VOS3　データマネジメントシステム XDM E2系 システム定義（XDM/BASE・SD・TM2）」を参照してください。

注※2

詳細については，マニュアル「VOS3　Database Connection Server」を参照してください。

注※3

詳細については，マニュアル「HiRDB XDM/RD E2接続機能」を参照してください。

(10)　J2EEアプリケーションのメソッドタイムアウト

図6-9または図6-10のポイント6とポイント9のタイムアウトを設定するチューニングパラメタです。

Webアプリケーション内またはEnterprise Bean内のメソッド単位にタイムアウトを設定する場合は，アプリケーションの属性として設定します。また，タイムアウトが発生した場合の動作についても，アプリケーションの属性として設定します。これらの項目は，サーバ管理コマンド（cjsetappprop）で設定します。

メソッドの実行時間のタイムアウトを設定するチューニングパラメタを次の表に示します。なお，ポイントごとに設定個所が異なります。

表6-39　メソッド実行時間のタイムアウトを設定するチューニングパラメタ

対象になるポイント
タイムアウトの種類およびタイムアウト時の動作
設定個所

6
フィルタ，サーブレットまたはJSPのリクエスト処理メソッド

定義ファイル

サーブレット属性ファイル

パラメタ名

<method-observation-timeout>※

9
Enterprise Beanのリクエスト処理メソッド

定義ファイル

Session Bean属性ファイル，Entity Bean属性ファイルまたはMessage-driven Bean属性ファイル

パラメタ名

<ejb-method-observation-timeout>

6および9
タイムアウト発生時のアプリケーション単位の動作

定義ファイル

アプリケーション属性ファイル

パラメタ名

<method-observation-recovery-mode>

注※　メソッドキャンセルを実行する場合に「thread」を指定します。

6.7　Webアプリケーションの動作を最適化する

この節では，Webアプリケーションのパフォーマンスチューニングの方法について説明します。Webフロントシステムの場合に検討してください。

ここでは，次の3種類のチューニング方法について説明します。

静的コンテンツとWebアプリケーションの配置を切り分ける

静的コンテンツをキャッシュする

リダイレクタを使用してリクエストを振り分ける（Webサーバ連携の場合）

＜この節の構成＞

6.7.1　静的コンテンツとWebアプリケーションの配置を切り分ける

6.7.2　静的コンテンツをキャッシュする

6.7.3　リダイレクタによってリクエストを振り分ける

6.7.4　Webアプリケーションの動作を最適化するためのチューニングパラメタ

6.7.1　静的コンテンツとWebアプリケーションの配置を切り分ける

HTMLファイルや画像ファイルなど，クライアントからの要求に対する応答に使用するファイルのうち，リクエスト内容に影響されないで常に同じ内容になるコンテンツを，静的コンテンツといいます。一方，サーブレットやJSPのように，クライアントからの要求に応じて動的に生成されるコンテンツを動的コンテンツといいます。

ここでは，静的コンテンツを動的コンテンツであるWebアプリケーションと切り分けて配置することで，パフォーマンスの向上を図る方法について説明します。設定方法は，Webサーバ連携の場合とインプロセスHTTPサーバを使用する場合とで異なります。

なお，それぞれの設定例では，Webブラウザに，次の図に示すようなフレームやインラインイメージで構成されるHTMLページを表示する場合の例を基に説明します。

図6-16　静的コンテンツと動的コンテンツで構成されるHTMLページの例

この構成の場合，次のファイルは動的に生成されない静的コンテンツです。

スタイルシート（CSSファイルなど）

インラインイメージ（画像ファイル）

フレームなどを定義したHTMLファイル

＜この項の構成＞

(1)　Webサーバ連携の場合

(2)　インプロセスHTTPサーバを使用する場合

(1)　Webサーバ連携の場合

静的コンテンツをWebアプリケーションに組み込んで扱うと，Webコンテナで処理する必要がない静的コンテンツをやり取りする場合でもリダイレクタとWebコンテナ間で常にアクセスが発生します。特に画像ファイルなどの場合は，データサイズが大きいため，処理時間が掛かります。

静的コンテンツはWebアプリケーションと分離して，Webサーバ上に配置することをお勧めします。これによって，ネットワークアクセスの回数およびやり取りするデータのサイズを減らし，パフォーマンスの向上が図れます。静的コンテンツとWebアプリケーションの処理のイメージを次の図に示します。

図6-17　静的コンテンツとWebアプリケーションの処理のイメージ

Webアプリケーションと分離した静的コンテンツの配置方法について説明します。なお，ここでは，図6-16で示した構成のHTMLページを例として説明します。

図6-16の場合，次のような静的コンテンツをWebサーバに配置することで，パフォーマンスの向上が図れます。

Webサーバに配置するコンテンツ

スタイルシート（CSSファイルなど）

インラインイメージ（画像ファイル）

フレームなどを定義したHTMLファイル

配置の例を次の図に示します。

図6-18　静的コンテンツをWebサーバに配置する例（Webサーバ連携の場合）

このマッピングするためには，マッピング定義を次のように記述します。詳細は，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

WebサーバとしてHitachi Web Serverを使用している場合（mod_jk.conf）

#
JkMount /APP/* worker1
# JkMount /* worker1
# を使用するとWebサーバ上の/images/などは参照できません。

WebサーバとしてMicrosoft IISを使用している場合（uriworkermap.properties）

#
/APP/*=worker1
# /*=worker1
# を使用するとWebサーバ上の/images/などは参照できません。

(2)　インプロセスHTTPサーバを使用する場合

インプロセスHTTPサーバを使用する場合も，静的コンテンツのように常に同じ内容をクライアントに渡すときには，静的コンテンツをインプロセスHTTPサーバおよびWebコンテナとは別のWebサーバで処理した方が，パフォーマンスが向上することがあります。特に，画像ファイルなどファイルサイズが大きいデータを大量に扱う場合は，Webアプリケーションに組み込むのではなく，静的コンテンツの処理専用のWebサーバを配置して扱うことをお勧めします。

静的コンテンツをWebアプリケーションから切り出して扱うためには，フロントにリバースプロキシサーバや負荷分散機を配置する構成が考えられます。この場合，リバースプロキシサーバや負荷分散機によって，処理を次のように振り分けます。

動的コンテンツへのアクセスはインプロセスHTTPサーバおよびWebコンテナが動作するJ2EEサーバにディスパッチします。

静的コンテンツへのアクセスはWebサーバにディスパッチします。

振り分け処理のイメージを次の図に示します。次の図は，リバースプロキシサーバによって処理を振り分けている例です。

図6-19　リバースプロキシサーバによる動的コンテンツと静的コンテンツの振り分けイメージ

Webアプリケーションと分離した静的コンテンツの配置方法について説明します。なお，ここでは，図6-16で示した構成のHTMLページを例として説明します。

図6-16の場合，次のような静的コンテンツをWebサーバに配置することで，パフォーマンスの向上が図れます。

Webサーバに配置するコンテンツ

スタイルシート（CSSファイルなど）

インラインイメージ（画像ファイル）

フレームなどを定義したHTMLファイル

配置の例を次の図に示します。

図6-20　静的コンテンツをWebサーバに配置する例（インプロセスHTTPサーバの場合）

この振り分けをするためには，Hitachi Web Serverのコンフィグファイル（httpsd.conf）のProxyPassディレクティブに，次のようにリバースプロキシの定義を記述します。

詳細は，マニュアル「Hitachi Web Server」を参照してください。

リバースプロキシの定義

ProxyPass /APP/    http://inprocweb/APP/
ProxyPass /images/ http://websvr/images/
ProxyPass /css/     http://websvr/css/

6.7.2　静的コンテンツをキャッシュする

Webコンテナでは，静的コンテンツをメモリに保持（キャッシュ）できます。一度アクセスした静的コンテンツの内容をメモリに保持しておくことによって，2回目以降のアクセス時のファイルシステムへのアクセス回数を減らし，応答速度の向上を図れます。

ここでは，静的コンテンツをキャッシュする場合に必要なチューニングの方法について説明します。

チューニングできるのは，次の項目です。

静的コンテンツをキャッシュするかどうかの選択

静的コンテンツのキャッシュに使用するメモリサイズの上限値

キャッシュする静的コンテンツのファイルサイズの上限値

それぞれについて説明します。なお，これらの項目は，Webコンテナ単位およびWebアプリケーション単位で設定できます。Webアプリケーション単位の設定は，Webコンテナ単位の設定よりも優先されます。このため，J2EEサーバ全体としてデフォルトの値を指定したい場合はWebコンテナ単位の値に設定して，細かな設定をしたい場合は適宜Webアプリケーション単位に設定してください。

ポイント

メモリサイズの見積もりとの関係

静的コンテンツのキャッシュでは，メモリを使用して応答速度の向上を図ります。このため，この機能を使用する場合は，サーバで使用できるメモリ量に応じてチューニングする必要があります。

静的コンテンツのキャッシュで使用するメモリサイズは，Webアプリケーション単位に設定します。Webアプリケーション単位に設定したメモリサイズの合計値が，J2EEサーバ全体で静的コンテンツのキャッシュのために使用するメモリサイズの最大値になります。このため，この機能を使用する場合は，J2EEサーバで必要なメモリサイズを見積もる際に，Webアプリケーション単位に設定したメモリサイズの合計値を加算してください。

＜この項の構成＞

(1)　静的コンテンツをキャッシュするかどうかの選択

(2)　静的コンテンツのキャッシュに使用するメモリサイズの上限値

(3)　キャッシュする静的コンテンツのファイルサイズの上限値

(4)　静的コンテンツの稼働状況の確認

(1)　静的コンテンツをキャッシュするかどうかの選択

静的コンテンツのキャッシュは，デフォルトの設定では使用されない機能です。このため，使用する場合はパラメタを変更する必要があります。

なお，静的コンテンツのキャッシュの使用は，Webコンテナ単位およびWebアプリケーション単位で設定でき，Webアプリケーション単位の設定は，Webコンテナ単位の設定よりも優先されます。ただし，Webコンテナ単位の設定で強制的な無効を選択している場合は，Webアプリケーション単位の設定も無効になります。強制的な無効は，次のような場合に使用できます。

静的コンテンツのキャッシュを有効にしたときと無効にしたときのメモリ使用量の差を検証したい場合

Webアプリケーション単位の設定を保持した状態で静的コンテンツのキャッシュを一時的に無効にしたい場合

(2)　静的コンテンツのキャッシュに使用するメモリサイズの上限値

静的コンテンツをキャッシュするために，Webアプリケーション単位で使用するメモリサイズを設定できます。なお，それぞれのWebアプリケーションで設定した値よりもキャッシュの合計サイズが大きくなる場合は，アクセスされていない時間が最も長いキャッシュから削除されます。削除は，キャッシュの合計サイズが設定値以下になるまで繰り返されます。

メモリサイズの設定の指針を次に示します。

メモリサイズの設定の指針

Webアプリケーション内に含まれる静的コンテンツのサイズの合計値以下の値を設定します。

Webアプリケーションの内容によって最適な値は異なります。このため，値を設定してから静的コンテンツに対するリクエストの応答速度を測定して，高い効果が出る最適なキャッシュのサイズを見つける必要があります。

(3)　キャッシュする静的コンテンツのファイルサイズの上限値

静的コンテンツのキャッシュの対象とするコンテンツのファイルサイズの上限を設定できます。上限を設定した場合，上限を超えるファイルサイズのコンテンツについてはキャッシュされないで，使用するたびに毎回ファイルシステムから取得されます。

ファイルサイズの設定の指針を次に示します。

ファイルサイズの設定の指針

Webアプリケーション内に含まれる静的コンテンツ中の，ファイルサイズが最大であるコンテンツのファイルサイズ以下の値を設定します。

大きなサイズの静的コンテンツがキャッシュされることによって，アクセス頻度の高いほかの静的コンテンツのキャッシュが破棄されないように留意して，値を設定します。

(4)　静的コンテンツの稼働状況の確認

静的コンテンツの稼働状況は，Webアプリケーションを停止したときに出力されるメッセージKDJE39234-Iの出力内容で確認できます。キャッシュされている静的コンテンツの合計サイズやコンテンツの個数などが出力されるので，必要に応じて各パラメタをチューニングしてください。

6.7.3　リダイレクタによってリクエストを振り分ける

リダイレクタでは，複数のWebコンテナに処理を振り分けるためのマッピングを定義できます。これによって，負荷分散を図り，個々のWebコンテナの負荷を減らすことで，パフォーマンスの向上が図れます。なお，この機能は，Webサーバ連携の場合にだけ使用できます。インプロセスHTTPサーバを使用する場合は使用できません。

なお，リダイレクタによってリクエストを振り分ける場合，リダイレクタによってセッション情報に応じて振り分けられるため，Webアプリケーションのセッションに応じたリクエストの振り分けを考慮する必要はありません。これは，あるWebコンテナ上のWebアプリケーションでセッションが生成されると，そのあとはリダイレクタによってクライアントからのリクエストに含まれるセッション情報が調べられ，クライアントからのリクエストに対応するセッションが生成されているWebコンテナに振り分けられるためです。

リダイレクタによるリクエストの振り分けの詳細については，マニュアル「Cosminexus　機能解説」を参照してください。

6.7.4　Webアプリケーションの動作を最適化するためのチューニングパラメタ

ここでは，Webアプリケーションの動作を最適化するために使用するチューニングパラメタの設定方法についてまとめて示します。

＜この項の構成＞

(1)　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

(2)　静的コンテンツをキャッシュするためのチューニングパラメタ

(3)　リダイレクタによってリクエストを振り分けるためのチューニングパラメタ

(1)　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

静的コンテンツとWebアプリケーションの配置の切り分けは，Webサーバの動作を定義するファイルのパラメタとして指定します。設定個所，ファイルおよびパラメタは，使用するWebサーバの種類によって異なります。

Webサーバ連携でHitachi Web Serverを使用している場合は，リダイレクタモジュールを使用して切り分けます。インプロセスHTTPサーバを使用している場合は，リバースプロキシサーバ（Hitachi Web Server）に配置しているリバースプロキシモジュールを使用して切り分けます。

設定方法および設定個所を次に示します。

表6-40　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

使用するWebサーバ
設定方法
設定個所

Hitachi Web Server
（リダイレクタモジュールを使用した切り分け※1）
Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理Webサーバ（web-server)

パラメタ名

JkMount

インプロセスHTTPサーバ
（リバースプロキシモジュールを使用した切り分け）
ファイル編集

定義ファイル

httpsd.conf

設定対象

リバースプロキシサーバ

パラメタ名

ProxyPassディレクティブ※2

注※1　Web Redirectorを使用する場合などに，WebサーバとしてMicrosoft IISを使用しているときは，uriworkermap.propertiesで設定します。

注※2　httpsd.confの詳細については，マニュアル「Hitachi Web Server」を参照してください。

(2)　静的コンテンツをキャッシュするためのチューニングパラメタ

静的コンテンツをキャッシュするためのチューニングパラメタについて説明します。これらのチューニングパラメタは，Webコンテナ単位またはWebアプリケーション単位に設定します。

Webコンテナ単位に設定するチューニングパラメタの設定方法について，次の表に示します。これらの項目は，Smart Composer機能で設定します。

表6-41　静的コンテンツをキャッシュするためのチューニングパラメタ（Webコンテナ単位で設定する項目）

設定項目
設定個所

静的コンテンツのキャッシュを使用するかどうかの選択

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.static_content.cache.enabled

Webアプリケーション単位のメモリサイズの上限値の設定

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.static_content.cache.size

キャッシュする静的コンテンツのファイルサイズの上限値の設定

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.static_content.cache.filesize.threshold

Webアプリケーション単位に設定するチューニングパラメタについて示します。Webアプリケーション単位に設定する項目は，web.xmlを直接編集するか，サーバ管理コマンドまたはServer Plug-inを使用して設定します。デプロイ前のWebアプリケーションに設定する場合は，web.xmlを編集してください。デプロイ後のWebアプリケーションに設定する場合は，サーバ管理コマンド（cjsetappprop）またはServer Plug-inを使用してください。

設定内容を次の表に示します。

表6-42　静的コンテンツをキャッシュするためのチューニングパラメタ（Webアプリケーション単位で設定する項目）

設定項目
設定内容※

静的コンテンツのキャッシュを使用するかどうかの選択

<param-name>タグ

com.hitachi.software.web.static_content.cache.enabled

<param-value>タグ

（設定値）

Webアプリケーション単位のメモリサイズの上限値の設定

<param-name>タグ

com.hitachi.software.web.static_content.cache.size

<param-value>タグ

（設定値）

キャッシュする静的コンテンツのファイルサイズの上限値の設定

<param-name>タグ

com.hitachi.software.web.static_content.cache.filesize.threshold

<param-value>タグ

（設定値）

注

（設定値）に設定できる値の詳細については，マニュアル「Cosminexus　機能解説」またはマニュアル「Cosminexus　システム構築ガイド」を参照してください。

注※

web.xmlを直接編集する場合，<web-app>タグ内に<context-param>タグを追加して，<context-param>タグ内に<param-name>タグおよび<param-value>タグを追加します。

サーバ管理コマンドを使用する場合，WAR属性ファイルの<hitachi-war-property>タグ内に<context-param>タグを追加して，<context-param>タグ内に<param-name>タグおよび<param-value>タグを追加します。なお，この内容はServer Plug-inの画面で設定することもできます。

(3)　リダイレクタによってリクエストを振り分けるためのチューニングパラメタ

リダイレクタによってリクエストを振り分けるためのチューニングパラメタは，Webサーバの動作を定義するファイルのパラメタとして指定します。

なお，この定義は，Webサーバ連携の場合だけできます。インプロセスHTTPサーバを使用している場合は定義できません。

設定方法および設定個所を次に示します。

表6-43　リダイレクタによってリクエストを振り分けるためのチューニングパラメタ

設定項目
設定方法
設定個所

URLパターンのマッピング定義※
Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

JkMount

注※　Web Redirectorを使用する場合などに，WebサーバとしてMicrosoft IISを使用しているときは，uriworkermap.propertiesで設定します。

6.8　CTMの動作を最適化する

CTMを使用したシステムのパフォーマンスチューニングの方法について説明します。CTMを使用したバックシステムの場合に検討してください。

ここでは，次の4種類のチューニング方法について説明します。

CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔をチューニングする

負荷状況監視間隔をチューニングする

CTMデーモンのタイムアウト閉塞を設定する

CTMで振り分けるリクエストの優先順位を設定する

＜この節の構成＞

6.8.1　CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔をチューニングする

6.8.2　負荷状況監視間隔をチューニングする

6.8.3　CTMデーモンのタイムアウト閉塞を設定する

6.8.4　CTMで振り分けるリクエストの優先順位を設定する

6.8.5　CTMの動作を最適化するチューニングパラメタ

6.8.1　CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔をチューニングする

システムに存在する複数のCTMドメインマネジャ間，およびCTMドメイン内の複数のCTMデーモン間では，お互いの稼働状態を監視するために，定期的に通信処理が実行されています。

ここでは，それぞれの通信処理間隔をチューニングする場合の考え方について説明します。

＜この項の構成＞

(1)　CTMドメインマネジャ間で稼働状態を監視する間隔のチューニング

(2)　CTMデーモン間で稼働状態を監視する間隔のチューニング

(1)　CTMドメインマネジャ間で稼働状態を監視する間隔のチューニング

CTMドメインマネジャ間では，お互いのホストにあるCTMデーモンの情報を定期的に交換しています。この情報を基に，自ホストで受け付けたリクエストを適宜ほかのホストのCTMデーモンに振り分けています。

情報を交換するタイミングでは，お互いが稼働状態であるかどうかも同時に確認します。相手のホストのCTMドメインマネジャが停止している場合は，そのホストにはリクエストを振り分けないようにします。CTMドメインマネジャでは，情報を交換する間隔に一定の係数を掛けた時間以上応答がない場合に，相手のCTMドメインマネジャが停止していると判断します。

情報を交換する間隔の設定個所は，相手のCTMドメインマネジャが同じネットワークセグメント内にあるか，異なるネットワークセグメントにあるかによって異なります。稼働状態を判断するときに使用する係数のデフォルトは2です。例えば，同じネットワークセグメント内にあるCTMドメインマネジャの稼働情報を確認する場合，Management Serverを使用して構築したシステムでは，CTMドメイン構成情報の送信間隔に2を掛けた時間以上応答がない場合は，停止していると判断します。CTMドメイン構成情報の送信間隔が60秒の場合は，120秒間応答がない場合に，停止していると判断します。

この係数を変更することによって，通信処理の最適化が図れます。

係数に指定する値は，通信によって発生する処理の負荷を考慮して，適切な値を検討してください。基準になる送信間隔も必要に応じて検討してください。係数を小さくすると，間隔が短くなり，相手のCTMドメインマネジャが停止したことがすぐに検知できます。これによって，CTMデーモンが停止しているホストにリクエストを送信してしまうことを防げます。ただし，間隔が短過ぎると，通信処理が多く発生し，通信負荷が掛かります。

(2)　CTMデーモン間で稼働状態を監視する間隔のチューニング

CTMデーモン間では，CTMドメインマネジャ間でやり取りした情報を基に，相互にリクエストの振り分け処理をしています。

リクエストの振り分け先のCTMデーモンから一定時間応答がない場合，振り分け元のCTMデーモンでは，相手のCTMデーモンが停止していると判断して，以降のリクエストを振り分けないようにします。

デフォルトの設定では，CTMデーモンは180秒間応答を待ちます。180秒以上応答がない場合，相手のCTMデーモンが停止していると判断します。この値を変更することで，不要な処理待ち時間を短縮できます。

値は，リクエストとして送信するデータの大きさなど考慮して，適切な値を設定してください。間隔を短くすることで，相手のホストのトラブルを迅速に検知できるため，トラブルの影響が少ない状態でシステムから切り離すことができるようになります。ただし，間隔が短過ぎると，大きなサイズのデータを転送している間にタイムアウトが発生してしまうおそれがあります。

6.8.2　負荷状況監視間隔をチューニングする

CTMドメイン内の複数のCTMデーモン間では，それぞれのスケジュールキューの負荷情報を監視しています。監視結果は，CTMデーモン間のリクエスト振り分け時に利用されます。

負荷状況監視間隔は，チューニングできます。なお，デフォルトの状態では10秒です。

負荷状況監視間隔を短くすることで，その時点の状況に応じた振り分けができるようになります。ただし，短くし過ぎると，通信が多発して，負荷が高くなります。

なお，負荷状況監視間隔に0を設定した場合は，J2EEサーバ起動時の負荷状況を一度だけ収集して，その値を使用し続けます。

6.8.3　CTMデーモンのタイムアウト閉塞を設定する

CTMデーモンに対応するJ2EEサーバにトラブルが発生した場合，CTMデーモンが送信したリクエストでタイムアウトが発生します。そのままの状態で運用を続けると，CTMデーモンはトラブルが発生したJ2EEサーバに対してリクエストを送信し続けるため，そのつどリクエストでタイムアウトが発生してしまいます。

これに対処するために，CTMデーモンには，タイムアウト閉塞を設定できます。タイムアウト閉塞とは，一定時間内に規定回数以上のリクエストのタイムアウトが発生した場合に，CTMデーモンのスケジュールキューを閉塞する機能です。これによって，トラブルが発生したCTMデーモンでそれ以上リクエストを受け付けなくなり，ほかのCTMデーモンが受け付けるようになります。リクエストは正常に稼働しているJ2EEサーバに振り分けられるようになります。

6.8.4　CTMで振り分けるリクエストの優先順位を設定する

CTMで制御するリクエストには，優先順位が付けられます。すぐに実行する必要があるリクエストに高い優先順位を設定しておくことで，スケジュールキューの中で滞留することなく，迅速な処理ができるようになります。

リクエストの優先順位は，CTMにリクエストを送信する，EJBクライアントアプリケーション，J2EEサーバまたはWebコンテナサーバに対して設定できます。優先順位を高く設定したEJBクライアントアプリケーション，J2EEサーバまたはWebコンテナサーバから送信されたリクエストは，スケジュールキューに格納されているほかのクライアントからのリクエストよりも優先されて処理されます。

6.8.5　CTMの動作を最適化するチューニングパラメタ

ここでは，CTMの動作の最適化で使用するチューニングパラメタの設定方法についてまとめて示します。

＜この項の構成＞

(1)　CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔を設定するチューニングパラメタ

(2)　負荷状況監視間隔を設定するチューニングパラメタ

(3)　CTMデーモンのタイムアウト閉塞を設定するチューニングパラメタ

(4)　CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタ

(1)　CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔を設定するチューニングパラメタ

CTMドメインマネジャの稼働状態の監視間隔をチューニングするパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

なお，監視間隔は，送信間隔×係数の値になります。

表6-44　CTMドメインマネジャの稼働状態の監視間隔をチューニングするパラメタ

対象 | 設定項目 | 設定対象 | 設定個所（パラメタ名）
同じネットワークセグメント内にあるCTMドメインマネジャ | 送信間隔 | 論理CTMドメインマネジャ（ctm-domain-manager） | cdm.SendInterval
係数 | 論理CTMドメインマネジャ（ctm-domain-manager） | cdm.AliveCheckCount
異なるネットワークセグメントにあるCTMドメインマネジャ | 送信間隔 | 論理CTMドメインマネジャ（ctm-domain-manager） | cdm.SendHostInterval
係数 | 論理CTMドメインマネジャ（ctm-domain-manager） | cdm.AliveCheckCount

CTMデーモンの稼働状態の監視間隔をチューニングするパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-45　CTMデーモンの稼働状態の監視間隔をチューニングするパラメタ

設定項目 | 設定対象 | 設定個所（パラメタ名）
CTMデーモン間転送時のタイムアウト | 論理CTM | ctm.DCSendTimeOut

(2)　負荷状況監視間隔を設定するチューニングパラメタ

負荷状況監視間隔をチューニングするパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-46　負荷情報監視間隔をチューニングするパラメタ

設定項目 | 設定対象 | 設定個所（パラメタ名）
CTMデーモン間転送時のタイムアウト | 論理CTM | ctm.LoadCheckInterval

(3)　CTMデーモンのタイムアウト閉塞を設定するチューニングパラメタ

タイムアウト閉塞は，タイムアウト発生回数と監視間隔を設定しておくことによって，実行されます。

CTMデーモンのタイムアウト閉塞をチューニングするパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表6-47　CTMデーモンのタイムアウト閉塞をチューニングするパラメタ

設定項目 | 設定対象 | 設定個所（パラメタ名）
タイムアウト発生回数 | 論理CTM | ctm.RequestCount
監視時間間隔 | 論理CTM | ctm.RequestInterval

(4)　CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタ

CTMで振り分けるリクエストの優先順位の設定は，EJBクライアントアプリケーションの場合と，J2EEサーバの場合で異なります。また，J2EEサーバの場合，システムの構築方法によって設定個所が異なります。CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタを次の表に示します。

表6-48　CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタ

設定単位
設定方法
設定個所

EJBクライアントアプリケーション
ファイル編集またはEJBクライアントアプリケーション開始時に指定するシステムプロパティの指定

定義ファイル（ファイル編集の場合）

usrconf.properties

パラメタ名

ejbserver.client.ctm.RequestPriorityキー

J2EEサーバ
Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.client.ctm.RequestPriority

6.9　そのほかの項目のチューニング

ここでは，前の節までに説明した項目以外のチューニング項目について説明します。

ここで説明するのは，次の項目です。

Persistent Connectionについてのチューニング

この項目は，Webフロントシステムの場合で，インプロセスHTTPサーバを使用するときにチューニングを検討してください。

HTTP/1.1では，WebクライアントとWebサーバ間で確立したTCPコネクションを持続して，複数のHTTPリクエスト間で使用し続けるためのPersistent Connectionが定義されています。Persistent Connectionを使用することによって，WebクライアントとWebサーバ間でコネクション接続に掛かる時間を短縮し，通信トラフィックを軽減できます。

ただし，Persistent Connectionを使用すると，特定のWebクライアントがリクエスト処理スレッドを占有することになるため，サーバ全体の処理性能が低下することがあります。このため，Persistent Connectionを有効に活用し，かつサーバ処理性能を維持できるようにチューニングする必要があります。

インプロセスHTTPサーバを使用する場合，Persistent Connectionについて，次の項目がチューニングできます。

Persistent Connection数の上限値
この上限値を超えるTCPコネクションについては，リクエスト処理終了後に切断されます。これによって，新規接続を処理するスレッドが確保でき，リクエスト処理スレッドを特定のクライアントに占有されることを防げます。

Persistent Connectionのリクエスト処理回数の上限値
同じWebクライアントから連続してリクエスト要求があった場合も，この上限値を超えると，リクエスト処理終了後に一度TCPコネクションが切断されます。
これによってリクエスト処理スレッドを特定のクライアントに占有され続けることを防げます。

Persistent Connectionのタイムアウト
Persistent Connectionのリクエスト待ち時間にタイムアウトを設定できます。指定したタイムアウト時間を超えてリクエスト処理要求がない場合は，TCPコネクションが切断されます。これによって，使用されていない状態でTCPコネクションが占有され続けることを防げます。

これらの項目は，Smart Composer機能で使用する簡易構築定義ファイルのパラメタとして指定します。Persistent Connectionについて設定するチューニングパラメタについて次の表に示します。

表6-49　Persistent Connectionについて設定するチューニングパラメタ

設定項目
設定個所

Persistent Connection数の上限値

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.connector.inprocess_http.persistent_connection.max_connections

リクエスト処理回数の上限値

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.connector.inprocess_http.persistent_connection.max_requests

タイムアウト

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.connector.inprocess_http.persistent_connection.timeout

なお，各パラメタの詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

7.　パフォーマンスチューニング（バッチアプリケーション実行基盤）

この章では，バッチアプリケーションを実行するシステムのパフォーマンスをチューニングする方法について説明します。

パフォーマンスチューニングによって動作環境を最適化することで，システムの性能を最大限に生かせるようになります。

J2EEアプリケーション実行基盤のパフォーマンスチューニングについて検討する場合は，「6.　パフォーマンスチューニング（J2EEアプリケーション実行基盤）」を参照してください。

＜この章の構成＞

7.1　パフォーマンスチューニングで考慮すること

7.2　チューニングの方法

7.3　タイムアウトを設定する

7.4　ガーベージコレクション制御で使用するしきい値を設定する

7.1　パフォーマンスチューニングで考慮すること

この節では，バッチアプリケーション実行基盤のパフォーマンスチューニングで考慮することについて説明します。

＜この節の構成＞

7.1.1　パフォーマンスチューニングの観点

7.1.2　チューニング手順

7.1.3　チューニング項目

7.1.1　パフォーマンスチューニングの観点

バッチアプリケーション実行基盤のパフォーマンスチューニングは，次の観点で実施します。

データベースアクセス方法の最適化

タイムアウトの設定

フルガーベージコレクションを発生させるメモリ使用量のしきい値の設定

それぞれのポイントについて説明します。

＜この項の構成＞

(1)　データベースアクセス方法の最適化

(2)　タイムアウトの設定

(3)　フルガーベージコレクションを発生させるメモリ使用量のしきい値の設定

(1)　データベースアクセス方法の最適化

データベースアクセス方法の最適化は，生成に時間が掛かるコネクションやステートメントをプールしておくことで，データベースアクセス時のオーバーヘッドを削減することを目的とします。

パフォーマンスチューニングでは，次に示す機能を有効に活用することで，データベースアクセス処理を最適化し，スループットを向上させます。

コネクションプーリング

ステートメントプーリング（PreparedStatementおよびCallableStatementのプーリング）

データベースアクセス方法は，データベースとの接続にDB Connectorを使用している場合に最適化できます。

(2)　タイムアウトの設定

タイムアウトの設定は，システムのトラブル発生を検知して，リクエストの応答が返らなくなることを防ぎ，適宜リソースを解放することを目的とします。

設定できるタイムアウトには，次の種類があります。

Enterprise Beanを呼び出す時のタイムアウト

トランザクションのタイムアウト

データベースのタイムアウト

(3)　フルガーベージコレクションを発生させるメモリ使用量のしきい値の設定

フルガーベージコレクションの制御で使用するしきい値は，オンライン処理とバッチ処理で同じリソースを使用する場合に設定します。バッチサーバのフルガーベージコレクションによってオンライン処理を中断させないことを目的とします。

フルガーベージコレクションの実行を制御することによって，リソースを排他していないタイミングで適切にフルガーベージコレクションを実行できます。

7.1.2　チューニング手順

パフォーマンスチューニングは，システムのパフォーマンスを生かす最適な設定を見つける作業です。構築した環境で，実際に処理を実行しながら，パラメタの調整やボトルネックの調査，解消によってパフォーマンスを向上させていきます。

チューニング作業では，まず，目標値を決定します。次に，各パラメタに初期値を設定した状態でスループットを測定します。各パラメタを調整しながら，目標値に近い最適な値を見つけていきます。

チューニングの際，CPUの利用率の測定には，OSに付属している監視ツールなどが利用できます。JavaVMに関するCosminexusの稼働情報については，稼働情報収集機能などで確認できます。確認方法については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

なお，CPU利用率が100%からかなり低い状態で飽和した場合は，システム上に入出力処理や排他処理などのボトルネックがあるおそれがあります。ボトルネックを調査し，対策してから，再度パフォーマンスチューニングを実行してください。Cosminexusでは，システムのボトルネックの調査に，性能解析トレースを利用できます。性能解析トレースの機能詳細については，マニュアル「Cosminexus　機能解説」を参照してください。性能解析トレースを利用して取得したトレースファイルの利用方法については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。

7.1.3　チューニング項目

バッチアプリケーション実行基盤でのチューニング項目について，次の表に示します。

表7-1　バッチアプリケーション実行基盤でのチューニング項目

チューニング項目 | 利用できる機能 | 参照先
データベースアクセス方法の最適化 | コネクションプーリング※1 | 6.5.1※2
ステートメントプーリング※1 | 6.5.2※2
タイムアウトの設定 | Enterprise Bean呼び出しでのタイムアウトの設定 | 6.6.3※2 ※3
トランザクションタイムアウトの設定 | 7.3.2
データベースでのタイムアウトの設定 | 6.6.5※2
フルガーベージコレクションの制御※1 | しきい値の設定 | 7.4

注※1

DB Connectorを使用している場合に利用できる機能です。

注※2

J2EEアプリケーション実行基盤の説明を参照してください。その際，説明中の「J2EEサーバ」を「バッチサーバ」に読み替えてください。また，「J2EEアプリケーション」を「バッチアプリケーション」に読み替えてください。

注※3

Enterprise Bean呼び出しでは，J2EEアプリケーション実行基盤のバックシステムと同じ項目にタイムアウトを設定できます。

7.2　チューニングの方法

この節では，チューニングの方法について説明します。チューニングの方法は，設定対象の種類によって異なります。

＜この節の構成＞

7.2.1　バッチサーバのチューニング

7.2.2　リソースのチューニング

7.2.1　バッチサーバのチューニング

バッチサーバのチューニングには，Smart Composer機能の簡易構築定義ファイルを使用します。簡易構築定義ファイルでは，<configuration>タグ下の<logical-server-type>に設定対象とする論理サーバの種類（J2EEサーバ※）を指定して，<param>タグ下でパラメタ名とその値を設定します。簡易構築定義ファイルの詳細については，マニュアル「Cosminexus　簡易構築・運用ガイド」を参照してください。

注※

Smart Composer機能では，バッチサーバをJ2EEサーバとして扱います。

7.2.2　リソースのチューニング

リソースのチューニングをする場合は，次のどちらかの方法でチューニングします。

サーバ管理コマンド

Server Plug-in

なお，Server Plug-inは，Smart Composer機能で構築した，Management Serverを利用するシステムで使用できます。

サーバ管理コマンドを使用する場合は，Connector属性ファイルを編集します。Connector属性ファイルの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。なお，属性ファイルはServer Plug-inの画面を使用して編集することもできます。属性ファイルのタグと対応するServer Plug-inの画面については，マニュアル「Cosminexus　アプリケーション設定操作ガイド」を参照してください。

7.3　タイムアウトを設定する

Cosminexusのシステムでは，トラブル発生時にリクエストの応答が戻ってこない状態になることを防ぐために，幾つかのポイントにタイムアウトを設定できます。

この節では，システム全体でタイムアウトが設定できるポイントと，設定する場合の指針について説明します。

＜この節の構成＞

7.3.1　タイムアウトが設定できるポイント

7.3.2　トランザクションタイムアウトを設定する

7.3.3　タイムアウトを設定するチューニングパラメタ

7.3.1　タイムアウトが設定できるポイント

バッチアプリケーションを実行するシステムでは，次の図に示すポイントにタイムアウトが設定できます。

図7-1　タイムアウトが設定できるポイント

それぞれのポイントに設定するタイムアウトは，次の表に示すような用途で使い分けられます。

表7-2　各ポイントに設定するタイムアウトの目的とデフォルトのタイムアウト設定

ポイント | タイムアウトの種類 | 主な用途
1 | バッチサーバ側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIネーミングサービス呼び出しのタイムアウト | バッチサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知
2※ | バッチサーバ側で設定するCTMからのEnterprise Bean呼び出しのタイムアウト | バッチサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知
3 | Enterprise Bean呼び出しアクセスしたEJBで設定するメソッドの実行時間のタイムアウト | J2EEサーバの業務処理の障害（無限ループ，デッドロックなど）
4 | バッチサーバ側で設定するデータベースのトランザクションタイムアウト | データベースサーバの障害（サーバダウンまたはデッドロックなど）の検知，またはリソースの長時間占有防止
5 | データベースのタイムアウト | データベースサーバの障害（サーバダウンまたはデッドロックなど）の検知，またはリソースの長時間占有防止

注※　CTMを使用している場合にだけ存在するポイントです。CTMを利用しない構成の場合，ポイント2の範囲はバッチサーバからEJBコンテナにEJBリモート呼び出しを実行してから，EJBコンテナからバッチサーバに実行結果が送信されるまでの間になります。

これらのタイムアウトの基本的な設定指針は次のとおりです。

タイムアウト値の設定は，呼び出し元（バッチサーバ）に近いほど大きな値を設定するのが原則です。このため，次の関係で設定することを推奨します。

ポイント1=ポイント2>ポイント3>ポイント4>ポイント5

1，4，5のポイントのタイムアウト値を設定する場合は，呼び出し処理に通常どの程度の時間が掛かっているかを見極めた上で，呼び出す処理（業務）ごとに算出して設定してください。

なお，1～5のポイントは，システムでの位置づけによって，次の二つに分けられます。

Enterprise Bean呼び出しで意識する必要があるポイント（1～3）
このポイントでタイムアウトを設定する項目は，J2EEアプリケーション実行基盤のバックシステムで設定できる項目と同じです。詳細は，「6.6.3　バックシステムでのタイムアウトを設定する」を参照してください。

データベース接続時に意識する必要があるポイント（4と5）
このポイントは，さらにトランザクションでのタイムアウトとデータベースでのタイムアウトに分けて意識する必要があります。
トランザクションでのタイムアウトの詳細は，「7.3.2　トランザクションタイムアウトを設定する」を参照してください。
データベースでのタイムアウトを設定する項目は，J2EEアプリケーション実行基盤のバックシステムで設定できる項目と同じです。詳細は，「6.6.5　データベースでのタイムアウトを設定する」を参照してください。

それぞれのポイントでの設定については，バッチアプリケーション実行基盤の「7.3.3　タイムアウトを設定するチューニングパラメタ」，およびJ2EEアプリケーション実行基盤の「6.6.7　タイムアウトを設定するチューニングパラメタ」を参照してください。

参考

それぞれのポイントのデフォルト値は次のとおりです。

ポイント
デフォルト値

1
設定されていません。レスポンスを待ち続けます。

2
ポイント1と同じ値がEnterprise Bean呼び出し時に自動的に引き継がれて設定されます。

3
設定されていません。タイムアウトしません。

4
180秒

5
データベースの種類とタイムアウトの設定個所ごとに異なります。※

HiRDBの場合

ロック解放待ちタイムアウト：180秒

レスポンスタイムアウト：0秒（HiRDBクライアントはHiRDBサーバからの応答があるまで待ち続けます）

リクエスト間隔タイムアウト：600秒

SQL Serverの場合

メモリ取得待ちタイムアウト：-1（-1を指定した場合の動作は，SQL Serverのドキュメントを参照してください）

ロック解放待ちタイムアウト：-1（ロックが解放されるまで待ち続けます）

XDM/RD E2の場合

ロック解放待ちタイムアウト：なし（タイムアウト時間を監視しません）

SQL実行CPU時間タイムアウト：10秒

SQL実行経過時間タイムアウト：0秒（タイムアウト時間を監視しません）

トランザクション経過時間タイムアウト：600秒

レスポンスタイムアウト：0秒（HiRDBクライアントはXDM/RD E2サーバからの応答があるまで待ち続けます）

注※

Oracleの場合，ロック解放待ちタイムアウトのデフォルトはありません。

7.3.2　トランザクションタイムアウトを設定する

ここでは，トランザクションタイムアウトの設定について説明します。トランザクションタイムアウトは，データベースシステムなどEISとのトランザクションに設定します。DB Connectorを使用してデータベースにアクセスするときのトランザクションタイムアウトについて説明します。

トランザクションタイムアウトを設定する場合は，システム全体のタイムアウトのうち，バッチサーバとデータベースのトランザクションについて意識する必要があります。

トランザクションタイムアウトが発生すると，Application Serverによって，次の処理が実行されます。

実行中のトランザクションはロールバックされます。

トランザクションに参加しているコネクションはクローズされ，コネクションプールから削除されます。

ポイント

トランザクションの管理方法はBMTになります。トランザクションのタイムアウトは，usrconf.propertiesまたはJTAのAPI（javax.transaction.UserTransaction#setTransactionTimeoutメソッド）に指定できます。

usrconf.propertiesの定義は，プロセス全体に影響します。APIに指定したタイムアウトは，APIを発行したトランザクションの範囲だけに影響します。また，APIの指定は，usrconf.propertiesの定義よりも優先されます。

このため，プロセス全体に設定したい標準的な値をusrconf.propertiesに定義して，呼び出す業務によって細かく設定したい値は適宜APIを使用して設定することをお勧めします。

トランザクションタイムアウトが発生した場合，バッチアプリケーションに例外は通知されません。ただし，メッセージKDJE31002-Wがログファイルとバッチサーバのコンソールに出力されます。また，トランザクションタイムアウトが発生したあとで，バッチアプリケーションから該当するトランザクションを使用してJTAインタフェースまたはJDBCインタフェースを使用しようとすると，例外が通知されます。

7.3.3　タイムアウトを設定するチューニングパラメタ

ここでは，タイムアウトの設定で使用するチューニングパラメタの設定方法についてまとめて示します。

＜この項の構成＞

(1)　バッチサーバ側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト

(2)　EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト

(3)　Enterprise Bean呼び出しアクセスしたEJBで設定するメソッドの実行時間のタイムアウト

(4)　バッチサーバ側で設定するデータベースのトランザクションタイムアウト（DB Connectorを使用した場合）

(5)　データベースのタイムアウト

(1)　バッチサーバ側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト

図7-1のポイント1のタイムアウトを設定するチューニングパラメタです。

設定方法は，J2EEアプリケーション実行基盤と同じです。「6.6.7　タイムアウトを設定するチューニングパラメタ」の「(6)EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト」を参照してください。

なお，「6.6.7　タイムアウトを設定するチューニングパラメタ」の説明中の「ポイント7」が，図7-1の「ポイント1」に対応します。

(2)　EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト

図7-1のポイント2のタイムアウトを設定するチューニングパラメタです。

設定方法は，J2EEアプリケーション実行基盤と同じです。「6.6.7　タイムアウトを設定するチューニングパラメタ」の「(7)EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト」を参照してください。

なお，「6.6.7　タイムアウトを設定するチューニングパラメタ」の説明中の「ポイント8」が，図7-1の「ポイント2」に対応します。

(3)　Enterprise Bean呼び出しアクセスしたEJBで設定するメソッドの実行時間のタイムアウト

図7-1のポイント3のタイムアウトを設定するチューニングパラメタです。

設定方法は，J2EEアプリケーション実行基盤と同じです。「6.6.7　タイムアウトを設定するチューニングパラメタ」の「(10)　J2EEアプリケーションのメソッドタイムアウト」を参照してください。

なお，「6.6.7　タイムアウトを設定するチューニングパラメタ」の説明中の「ポイント9」が，図7-1の「ポイント3」に対応します。

(4)　バッチサーバ側で設定するデータベースのトランザクションタイムアウト（DB Connectorを使用した場合）

図7-1のポイント4のタイムアウトを設定するチューニングパラメタです。

バッチサーバ単位，Enterprise Bean，インタフェース，APIによる呼び出し単位（BMTの場合）に設定します。

トランザクションタイムアウトのチューニングパラメタを次の表に示します。

表7-3　トランザクションタイムアウトのチューニングパラメタ

単位
設定方法
設定項目
設定個所

バッチサーバ単位
Smart Composer機能
トランザクションのトランザクションタイムアウト時間のデフォルト

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.jta.TransactionManager.defaultTimeOut

API単位（BMT）
API
トランザクションタイムアウト時間
UserTransaction#setTransactionTimeoutメソッド※

注※　パッケージ名はjavax.transactionです。

(5)　データベースのタイムアウト

図7-1のポイント5のタイムアウトを設定するチューニングパラメタです。

設定方法は，J2EEアプリケーション実行基盤と同じです。「6.6.7　タイムアウトを設定するチューニングパラメタ」の「(9)データベースのタイムアウト」を参照してください。

なお，「6.6.7　タイムアウトを設定するチューニングパラメタ」の説明中の「ポイント11」が，図7-1の「ポイント5」に対応します。

7.4　ガーベージコレクション制御で使用するしきい値を設定する

バッチサーバのフルガーベージコレクションを実行するタイミングは，メモリ使用量にしきい値を設定することで制御できます。しきい値は，バッチ処理とオンライン処理で同じリソースにアクセスする場合に設定することをお勧めします。適切なしきい値を設定しておくことで，オンライン処理とバッチ処理の両方のスループットを確保できます。

ポイント

フルガーベージコレクションの詳細については，「8.1.3　ガーベージコレクションの発生とメモリ空間の関係」を参照してください。

＜この節の構成＞

7.4.1　しきい値を設定する目的

7.4.2　しきい値設定の考え方

7.4.3　ガーベージコレクション制御で使用するしきい値を設定するためのチューニングパラメタ

7.4.1　しきい値を設定する目的

オンライン処理とバッチ処理で同じリソースにアクセスする場合，オンライン処理のスループットに影響を与えないように考慮する必要があります。

バッチアプリケーション実行時に空きメモリが少なくなると，JavaVMによってバッチサーバのフルガーベージコレクションが実行されます。この場合，バッチサーバ上で動作するすべてのプログラムの処理が中断されます。バッチアプリケーションがリソースを排他していた場合，そのリソースはバッチサーバのフルガーベージコレクション実行中も排他された状態になります。オンライン処理の中に排他中のリソースを使用する処理があった場合は，そのオンライン処理も中断されてしまいます。

これを防ぐために，メモリ使用量のしきい値を設定して，メモリ不足が起こる前に明示的にフルガーベージコレクションを発生させるようにします。明示的なフルガーベージコレクションは，リソースを排他していないタイミングで発生するように制御できます。JavaVMによってフルガーベージコレクションが実行される前に空きメモリを増やしておくことで，リソース排他中にフルガーベージコレクションが実行されることを防ぎます。

しきい値を設定した場合，次に示す状態になるとフルガーベージコレクションが実行されます。ただし，そのときにバッチアプリケーションがリソースを排他していた場合は，排他が解除されるまで待ってから実行されます。

Tenured領域消費サイズのTenured領域合計サイズに対する割合≧しきい値

New領域合計サイズのTenured領域最大空きサイズに対する割合≧しきい値

Permanent領域消費サイズのPermanent領域合計サイズに対する割合≧しきい値

7.4.2　しきい値設定の考え方

しきい値は，次の式で算出した値を目安に算出できます。

しきい値≦100－（100×リソース排他解除を待つ間に必要な空きメモリのサイズ）／最大メモリサイズ

しきい値設定の際には，次の点を考慮してください。

フルガーベージコレクションの発生頻度

リソース排他解除を待つ間に必要な空きメモリ

ここでは，フルガーベージコレクションの発生頻度としきい値の関係と，リソース排他解除を待つ間に必要な空きメモリのサイズの見積もり方法について説明します。

＜この項の構成＞

(1)　フルガーベージコレクションの発生頻度としきい値の関係

(2)　リソース排他解除を待つ間に必要な空きメモリの見積もり

(1)　フルガーベージコレクションの発生頻度としきい値の関係

フルガーベージコレクションはプログラムの実行速度に比べて時間の掛かる処理です。このため，JavaVMのチューニングでは，フルガーベージコレクションをできるだけ発生させないようにします。JavaVMのチューニングの考え方については，「8.2.1　チューニングの考え方」を参照してください。

しきい値を設定して明示的に実行するフルガーベージコレクションも，頻度が少なくなるよう，チューニングする必要があります。

設定したしきい値ごとのメモリ使用量の例を，次の図に示します。

図7-2　設定したしきい値ごとのメモリ使用量の例

JavaVMでのメモリ使用量は，時間の経過とともに増加していき，フルガーベージコレクションが発生すると減少します。

しきい値に0を設定した場合は，JavaVMによって自動的に実行されるまでフルガーベージコレクションは実行されません。しきい値に小さな値を設定した場合は，大きな値を指定した場合に比べて，フルガーベージコレクションが実行される頻度が高くなります。図の場合は，しきい値として80を設定した場合の方が，50を設定した場合よりもフルガーベージコレクションの実行頻度を低く抑えることができています。

ただし，フルガーベージコレクションの実行頻度を少なくした場合，1回の実行に掛かる時間は，頻繁に実行する場合に比べて長くなります。

(2)　リソース排他解除を待つ間に必要な空きメモリの見積もり

メモリ使用量がしきい値以上になった場合，リソース排他が解除されるまでフルガーベージコレクションは実行されません。しかし，リソース排他の解除を待っている間にJavaVMが必要とするメモリが不足した場合は，リソース排他解除を待たないでJavaVMによってフルガーベージコレクションが実行されてしまいます。

リソース排他解除を待つ間に空きメモリが不足した場合の例を次の図に示します。

図7-3　リソース排他解除を待つ間に空きメモリが不足した場合の例

ポイント

JavaVMにフルガーベージコレクションを実行させないために必要な空きメモリについては，「8.1.3　ガーベージコレクションの発生とメモリ空間の関係」を参照してください。

フルガーベージコレクションが発生するメモリ使用量を100とする場合，リソース排他解除待ち区間に使用できるメモリサイズは，「100－しきい値（%）」です。

例えば，しきい値として「95」のように高い値を指定した場合は，リソース排他解除を待っている間に使用できる空きメモリが5%と少ないため，リソース排他が解除される前にJavaVMによって自動的にフルガーベージコレクションが実施されてしまうおそれがあります。

このため，しきい値を見積もる場合には，リソース排他待ち区間にメモリが不足しないよう，十分に余裕を持った値を設定するようにしてください。

注意

リソース排他解除待ち区間で空きメモリが不足してJavaVMによるフルガーベージコレクションが実行された場合，リソースの排他が解除されたタイミングで，フルガーベージコレクション制御によってもう一度フルガーベージコレクションが実行されます。

7.4.3　ガーベージコレクション制御で使用するしきい値を設定するためのチューニングパラメタ

ここでは，バッチサーバのフルガーベージコレクションを実行するしきい値を設定するために使用するチューニングパラメタの設定方法について示します。

表7-4　バッチサーバのフルガーベージコレクションを実行するしきい値を設定するチューニングパラメタ

設定項目
設定個所

しきい値

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

ejbserver.batch.gc.watch.threshold

8.　JavaVMのチューニング

この章では，JavaVMのチューニングについて説明します。

システムの処理性能を高めるには，基盤となるJavaVM自体のチューニングを適切に実施する必要があります。

＜この章の構成＞

8.1　ガーベージコレクションとJavaVMのメモリ管理の概要

8.2　JavaVMのチューニングの考え方と手順

8.3　Tenured領域のメモリサイズの見積もり

8.4　DefNew領域のメモリサイズの見積もり

8.5　一定期間存在するオブジェクトの扱いの検討

8.6　Javaヒープの最大サイズ／初期サイズの決定

8.7　Permanent領域のメモリサイズの見積もり

8.8　拡張verbosegc情報を使用したフルガーベージコレクションの要因の分析方法

8.1　ガーベージコレクションとJavaVMのメモリ管理の概要

JavaVMのチューニングの目的は，システムの処理性能の向上です。特に，ガーベージコレクションの仕組みを踏まえ，適切なメモリ管理ができるようにチューニングすることで，システムの処理性能が向上します。

ここでは，JavaVMのチューニングをする前提として知っておく必要がある，次の項目について説明します。

ガーベージコレクションの仕組み

JavaVMで使用するメモリ空間の構成とJavaVMオプション

ガーベージコレクションの発生とメモリ空間の関係

＜この節の構成＞

8.1.1　ガーベージコレクションの仕組み

8.1.2　JavaVMで使用するメモリ空間の構成とJavaVMオプション

8.1.3　ガーベージコレクションの発生とメモリ空間の関係

8.1.1　ガーベージコレクションの仕組み

ここでは，ガーベージコレクションの仕組みについて説明します。

＜この項の構成＞

(1)　ガーベージコレクションとは

(2)　オブジェクトの寿命と年齢の関係

(3)　コピーガーベージコレクションの仕組み

(4)　オブジェクトの退避

(1)　ガーベージコレクションとは

ガーベージコレクションは，プログラムが使用し終わったメモリ領域を自動的に回収して，ほかのプログラムが利用できるようにするための技術です。

ガーベージコレクションの実行には，処理時間が掛かります。このため，ガーベージコレクションを適切に実行できるかどうかが，システムの処理性能に大きく影響します。

プログラムの中でnewによって作成されたJavaオブジェクトは，JavaVMが管理するメモリ領域に格納されます。Javaオブジェクトが作成されてから不要になるまでの期間を，Javaオブジェクトの寿命といいます。

Javaオブジェクトには，寿命の短いオブジェクトと寿命の長いオブジェクトがあります。サーバサイドで動作するJavaアプリケーションの場合，リクエストやレスポンス，トランザクション管理などで，多くのJavaオブジェクトが作成されます。これらのJavaオブジェクトは，その処理が終わると不要になる，寿命が短いオブジェクトです。一方，アプリケーションの動作中使用され続けるJavaオブジェクトは，寿命が長いオブジェクトです。

効果的なガーベージコレクションを実行するためには，寿命の短いオブジェクトに対してガーベージコレクションを実行して，効率良くメモリ領域を回収することが必要です。また，繰り返し使用される寿命の長いオブジェクトに対する不要なガーベージコレクションを抑止することが，システムの処理性能の低下防止につながります。これを実現するのが，世代別ガーベージコレクションです。

世代別ガーベージコレクションでは，Javaオブジェクトを，寿命が短いオブジェクトが格納されるDefNew領域と，寿命が長いオブジェクトが格納されるTenured領域に分けて管理します。DefNew領域はさらに，newによって作成されたばかりのオブジェクトが格納されるEden領域と，1回以上のガーベージコレクションの対象になり，回収されなかったオブジェクトが格納されるSurvivor領域に分けられます。DefNew領域内で一定回数以上のガーベージコレクションの対象になったJavaオブジェクトは，長期間必要なJavaオブジェクトと判断され，Tenured領域に移動します。

世代別ガーベージコレクションで管理するメモリ空間とJavaオブジェクトの概要を次の図に示します。

図8-1　世代別ガーベージコレクションで管理するメモリ空間とJavaオブジェクトの概要

1回目のガーベージコレクションが実行された時点で使用されていたJavaオブジェクトは，DefNew::Eden領域からDefNew::Survivor領域に移動します。なお，このときにすでに使用されていなかったJavaオブジェクトは，移動しないで破棄されます。Tenured領域に移動するしきい値をn回とした場合，n回以上のガーベージコレクションが実行される間使用され続けていたJavaオブジェクトは，DefNew::Survivor領域からTenured領域に移動します。なお，1回以上のガーベージコレクション実行時に使用されていて，n回未満のガーベージコレクション実行時に使用されなくなっていたJavaオブジェクトは，その時点で移動しないで破棄されます。

なお，世代別ガーベージコレクションで実行されるガーベージコレクションには，次の2種類があります。

コピーガーベージコレクション
DefNew::Eden領域およびDefNew::Survivor領域だけを対象にしたガーベージコレクションです。

フルガーベージコレクション
Tenured領域も含む，JavaVM固有領域全体を対象にしたガーベージコレクションです。

一般的に，コピーガーベージコレクションの方が，フルガーベージコレクションよりも短い時間で処理できます。このため，JavaVMのチューニングでは，JavaVMオプションでそれぞれのメモリ空間のサイズや割合を適切に設定することで，フルガーベージコレクションが頻発することを防ぎ，パフォーマンス低下を防ぐようにします。

(2)　オブジェクトの寿命と年齢の関係

オブジェクトがコピーガーベージコレクションの対象になった回数をオブジェクトの年齢といいます。

オブジェクトの寿命と年齢の関係を次の図に示します。

図8-2　オブジェクトの寿命と年齢の関係

アプリケーションが開始して初期化処理が完了したあとで，何度かのコピーガーベージコレクションが実行されると，長期間必要になる寿命の長いオブジェクトはTenured領域に移動します。このため，アプリケーションの開始後しばらくすると，Javaヒープの状態は安定し，作成されるJavaオブジェクトとしては，寿命が短いオブジェクトが多くなります。特に，DefNew領域のチューニングが適切にできている場合，Javaヒープが安定したあとの大半のオブジェクトは，1回目のコピーガーベージコレクションで回収される，寿命が短いオブジェクトになります。

(3)　コピーガーベージコレクションの仕組み

JavaVMでは，コピーガーベージコレクションの対象になるDefNew領域のメモリ空間を，DefNew::Eden領域，DefNew::Survivor領域に分けて管理します。さらに，DefNew::Survivor領域は，From空間とTo空間に分けられます。From空間とTo空間は，同じメモリサイズです。

DefNew領域の構成を次の図に示します。

図8-3　DefNew領域の構成

DefNew::Eden領域は，newによって作成されたオブジェクトが最初に格納される領域です。プログラムでnewが実行されると，DefNew::Eden領域のメモリが確保されます。

DefNew::Eden領域がいっぱいになると，コピーガーベージコレクションが実行されます。コピーガーベージコレクションでは，次の処理が実行されます。

DefNew::Eden領域およびDefNew::Survivor領域のFrom空間にあるJavaオブジェクトのうち，使用中のJavaオブジェクトが，DefNew::Survivor領域のTo空間にコピーされます。使用されていないJavaオブジェクトは破棄されます。

DefNew::Survivor領域のTo空間とFrom空間が入れ替わります。

この結果，DefNew::Eden領域とTo空間は空になり，使用中のオブジェクトはFrom空間に存在することになります。

コピーガーベージコレクション実行時に発生するオブジェクトの移動を次の図に示します。

図8-4　コピーガーベージコレクション実行時に発生するオブジェクトの移動

このようにして，使用中のオブジェクトは，コピーガーベージコレクションが発生するたびに，From空間とTo空間を行ったり来たりします。ただし，寿命の長いオブジェクトを行き来させ続けると，コピー処理の負荷などが問題になります。これを防ぐために，From空間とTo空間でJavaオブジェクトを入れ替える回数にしきい値を設定して，年齢がしきい値に達したJavaオブジェクトはTenured領域に移動させるようにします。

(4)　オブジェクトの退避

年齢がしきい値に達していないJavaオブジェクトがTenured領域に移動することを，退避といいます。退避は，コピーガーベージコレクション実行時にDefNew::Eden領域およびFrom空間で使用中のオブジェクトが多くなり，移動先であるTo空間のメモリサイズが不足する場合に発生します。この場合，To空間に移動できなかったオブジェクトが，Tenured領域に移動します。

図8-5　オブジェクトの退避

オブジェクトの退避が発生した場合，Tenured領域に本来格納されないはずの寿命の短いオブジェクトが格納されます。これが繰り返されると，コピーガーベージコレクションで回収されるはずのオブジェクトがメモリ空間に残っていくため，Javaヒープのメモリ使用量が増加していき，最終的にはフルガーベージコレクションが発生します。

オブジェクトの退避が発生した場合のメモリ使用量の変化について，次の図に示します。

図8-6　オブジェクトの退避が発生した場合のメモリ使用量の変化

このような要因で発生するフルガーベージコレクションは，システムの処理性能を低下させます。

したがって，メモリ空間の構成とメモリサイズを検討するときには，オブジェクトの退避が発生しないように，DefNew::Eden領域とDefNew::Survivor領域のバランスを検討する必要があります。

8.1.2　JavaVMで使用するメモリ空間の構成とJavaVMオプション

ここでは，JavaVMで使用するメモリ空間の構成と，JavaVMオプションについて説明します。

JavaVMでは，JavaVM固有領域とOS固有領域という，2種類のメモリ空間を使用します。

JavaVMで使用するメモリ空間の構成を次の図に示します。なお，図中の番号は，表8-1の項番と対応しています。

図8-7　JavaVMで使用するメモリ空間の構成

それぞれの領域について説明します。なお，DefNew::Eden領域，DefNew::Survivor領域，およびTenured領域を合わせた領域を，Javaヒープといいます。

DefNew::Eden領域

newによって作成されたJavaオブジェクトが最初に格納される領域です。

DefNew::Survivor領域

DefNew領域に格納されていたJavaオブジェクトのうち，コピーガーベージコレクション実行時に破棄されなかったJavaオブジェクトが格納される領域です。DefNew::Survivor領域は，From空間とTo空間で構成されます。From空間とTo空間のサイズは同じです。

Tenured領域

長期間必要であると判断されたJavaオブジェクトが格納される領域です。DefNew::Survivor領域で指定回数を超えてコピーガーベージコレクションの実行対象となり，破棄されなかったJavaオブジェクトが，この領域に移動されます。

Permanent領域

ロードされたclassなどの情報が格納される領域です。

Cヒープ領域

JavaVM自身が使用する領域です。JNIで呼び出されたネイティブライブラリでも使用されます。

スタック領域

Javaスレッドのスタック領域です。

それぞれの領域のサイズや割合などを指定するJavaVMオプションを次の表に示します。なお，表の項番は，図8-7と対応しています。

表8-1　JavaVMメモリ空間のサイズや割合などを指定するJavaVMオプション

項番
オプション名
オプションの意味

1
-Xmx<size>
Javaヒープの最大サイズを設定します。

2
-Xms<size>
Javaヒープの初期サイズを設定します。

3
-XX:MaxPermSize=<size>
Permanent領域の最大サイズを設定します。

4
-XX:PermSize=<size>
Permanent領域の初期サイズを設定します。

5
-Xmn<size>
DefNew領域の初期値および最大値を設定します。

6
-Xss<size>
１スタック領域の最大サイズを設定します。

7
-XX:NewRatio=<value>
DefNew領域に対するTenured領域の割合を設定します。
<value>が2の場合は，DefNew領域とTenured領域の割合が，1:2になります。

8
-XX:SurvivorRatio=<value>
DefNew::Survivor領域のFrom空間とTo空間に対するDefNew::Eden領域の割合を設定します。
<value>に8を設定した場合は，DefNew::Eden領域，From空間，To空間の割合が，8:1:1になります。

9
-XX:TargetSurvivorRatio=<value>
ガーベージコレクション実行後のDefNew::Survivor領域内でJavaオブジェクトが占める割合の目標値を設定します。

10
-XX:MaxTenuringThreshold=<value>
コピーガーベージコレクション実行時に，From空間とTo空間でJavaオブジェクトを入れ替える回数のしきい値を設定します。
設定した回数を超えて入れ替え対象になったJavaオブジェクトは，Tenured領域に移動されます。

注　<size>の単位はバイトです。

参考

JavaVMオプションは，次の個所に設定します。

表8-2　JavaVMオプションを設定する個所

対象
設定方法
設定個所

J2EEサーバ
Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

add.jvm.arg

バッチサーバ
Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

add.jvm.arg

SFOサーバ
Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理SFOサーバ（sfo-server）

パラメタ名

add.jvm.arg

EJBクライアントアプリケーション
ファイル編集

定義ファイル

usrconf.cfg※

パラメタ名

add.jvm.argキー

Webコンテナサーバ
ファイル編集

定義ファイル

usrconf.cfg

パラメタ名

add.jvm.argキー

注※　cjclstartapコマンドを使用して開始する場合に有効になるファイルです。

ポイント

それぞれのオプションのデフォルト値は，OSによって異なります。オプションのデフォルト値については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

8.1.3　ガーベージコレクションの発生とメモリ空間の関係

ガーベージコレクションは，メモリ空間の使用状況に応じて，次のタイミングで発生します。

＜この項の構成＞

(1)　コピーガーベージコレクションが発生するタイミング

(2)　フルガーベージコレクションが発生するタイミング

(1)　コピーガーベージコレクションが発生するタイミング

コピーガーベージコレクションは，DefNew::Eden領域がいっぱいになったタイミングで発生します。

(2)　フルガーベージコレクションが発生するタイミング

フルガーベージコレクションは，次のタイミングで発生します。

DefNew領域（Eden領域とSurvivor領域の合計）で使用しているメモリサイズがTenured領域の最大値に対する未使用メモリサイズを上回っている状態の時に，DefNew領域へのアロケーションで空き領域が不足した場合

DefNew領域とTenured領域のそれぞれの未使用メモリサイズを上回るメモリサイズ（Javaオブジェクトのサイズ）のアロケーション要求があった場合

コピーガーベージコレクションの実施の結果，次のどちらかの状態になった場合

確保済みTenured領域の未使用メモリサイズが10,000バイトを下回った場合

コピーガーベージコレクション実施時のTenured領域へのオブジェクトの移動によって，確保済みTenured領域の拡張が発生した場合

java.lang.System.gc()メソッドが実行された場合

Permanent領域にアロケーションしたいメモリサイズが確保済みPermanent領域の未使用メモリサイズを上回る場合

javagcコマンドを実行した場合

jheapprofコマンドを実行した場合

JavaVMのチューニングでは，主に1.と2.の発生を抑えることを検討します。

参考

フルガーベージコレクションが発生した場合の要因は，拡張verbosegc情報を使用して確認できます。フルガーベージコレクション発生時に要因を確認する方法については，「8.8　拡張verbosegc情報を使用したフルガーベージコレクションの要因の分析方法」を参照してください。

8.2　JavaVMのチューニングの考え方と手順

この節では，JavaVMのチューニングの考え方，および手順について説明します。

＜この節の構成＞

8.2.1　チューニングの考え方

8.2.2　メモリサイズの見積もり手順

8.2.3　メモリサイズの設定方法

8.2.4　メモリサイズの使用状況の確認方法

8.2.1　チューニングの考え方

一般的に，コピーガーベージコレクションの方が，フルガーベージコレクションよりも短い時間で処理できます。

DefNew領域へのコピーガーベージコレクションの実施によって適切にメモリを回収して，Javaヒープ全体を対象とするフルガーベージコレクションの発生をできるだけ抑止することが，システムの処理性能向上につながります。これを実現するためには，JavaVMオプションでそれぞれのメモリ空間のサイズや割合を適切に設定することが必要です。

これを踏まえ，JavaVMのチューニングは，次の2点を目的として実施します。

フルガーベージコレクションをできるだけ発生させないこと

フルガーベージコレクションの頻発を抑止した上で，不要なコピーガーベージコレクションを発生させないこと

理想的なメモリ使用量と経過時間の関係を次の図に示します。

図8-8　理想的なメモリ使用量と経過時間の関係

この図の場合は，寿命の短いオブジェクトはすべてコピーガーベージコレクションによって回収できていて，オブジェクトの退避が発生しません。このため，コピーガーベージコレクション実行後のメモリサイズが一定です。これによって，フルガーベージコレクションが発生しない，安定した状態での運用を実現できます。

JavaVMのチューニングでは，この状態を理想として，JavaVMの使用するメモリ空間の各領域で使用するメモリサイズを見積もってチューニングします。

ポイント

チューニングの目安

図8-8では，フルガーベージコレクションを一度も発生させない理想的な例を示しましたが，現実的にはフルガーベージコレクションが1回発生する間にコピーガーベージコレクションが10～20回程度発生することを目安にして，チューニングを実施してください。

8.2.2　メモリサイズの見積もり手順

JavaVMのチューニングでは，JavaVM固有領域の各領域のメモリサイズを適切に見積もる必要があります。

見積もりのポイントになるメモリサイズは次のとおりです。

Javaヒープ全体のメモリサイズ

Tenured領域のメモリサイズ

DefNew::Survivor領域のメモリサイズ

DefNew::Eden領域のメモリサイズ

このほか，Permanent領域も，必要に応じて見積もります。

見積もりでは，まず，Tenured領域のメモリサイズとDefNew領域のメモリサイズを算出して，それらを基にJavaヒープ全体のメモリサイズを算出します。

メモリサイズを見積もる順序を次の図に示します。図中の番号の順番で見積もりを実施します。

図8-9　メモリサイズを見積もる順序

見積もり手順を示します。なお，番号は図中の番号と対応しています。

Tenured領域で使用するメモリサイズを見積もります。
見積もり方法については，「8.3　Tenured領域のメモリサイズの見積もり」を参照してください。

DefNew::Survivor領域で使用するメモリサイズを見積もります。
見積もり方法については，「8.4.1　DefNew::Survivor領域のメモリサイズの見積もり」を参照してください。

DefNew::Eden領域で使用するメモリサイズを見積もります。
見積もり方法については，「8.4.2　DefNew::Eden領域のメモリサイズの見積もり」を参照してください。

2.と3.の合計として，DefNew領域全体のメモリサイズを算出します。

一定期間存在するオブジェクトの扱いを検討して，必要なメモリサイズをTenured領域またはDefNew領域のメモリサイズに追加します。
検討方法については，「8.5　一定期間存在するオブジェクトの扱いの検討」を参照してください。

1.，4.および5.の合計として，Javaヒープ全体のメモリサイズを算出します。

必要に応じてPermanent領域のメモリサイズを見積もります。
見積もり方法については，「8.7　Permanent領域のメモリサイズの見積もり」を参照してください。

8.2.3　メモリサイズの設定方法

見積もったメモリサイズは，「8.1.2　JavaVMで使用するメモリ空間の構成とJavaVMオプション」で説明したオプションで指定します。それぞれの領域のメモリサイズの設定方法を次に示します。

Javaヒープ全体のメモリサイズ

-Xmx<size>オプションで最大サイズを指定して，-Xms<size>オプションで初期サイズを指定します。

Tenured領域のメモリサイズ

-XX:NewRatio=<value>オプションで，Javaヒープ全体に対する，Tenured領域とDefNew領域の分割比を指定します。例えば，「-XX:NewRatio=5」とした場合には，-Xmx<size>オプションで指定したメモリサイズが，次のように分割されます。

DefNew領域のメモリサイズ：Tenured領域のメモリサイズ = 1：5

DefNew::Survivor領域のメモリサイズとDefNew::Eden領域のメモリサイズ

-XX:SurvivorRatio=<value>オプションで，DefNew領域全体に対する，DefNew::Survivor領域とDefNew::Eden領域の分割比を指定します。なお，分割比は，DefNew::Survivor領域のFrom空間およびTo空間に対してDefNew::Eden領域を何倍確保するかの数値で指定します。例えば，「-XX:SurvivorRatio=2」とした場合には，-XX:NewRatio=<value>オプションで決まったDefNew領域のメモリサイズが，次のように分割されます。

DefNew::Eden領域のメモリサイズ：From空間のメモリサイズ：To空間のメモリサイズ = 2：1：1

Permanent領域のメモリサイズ

-XX:MaxPermSize=<size>オプションで最大サイズを指定して，-XX:PermSize=<size>オプションで初期サイズを指定します。

8.2.4　メモリサイズの使用状況の確認方法

それぞれのメモリサイズは，アプリケーションを実際に動作させて，メモリ使用量を測定しながらチューニングしていきます。Cosminexusでは，usrconf.cfgファイルに-XX:+HitachiVerboseGCオプションを指定してJ2EEサーバを起動することで，ガーベージコレクション実行時の各領域の詳細なメモリサイズを拡張verbosegc情報として出力できます。この出力内容を基にチューニングを実施してください。

拡張verbosegc情報として出力できる主な内容を次に示します。

ガーベージコレクションの発生日時

ガーベージコレクション種別

ガーベージコレクション情報※1

ガーベージコレクション経過時間

Eden情報※1

Survivor情報※1

Tenured情報※1

Perm情報※1

ガーベージコレクション要因内容※２

注※1

ガーベージコレクション前後の使用領域長および領域サイズが出力されます。

注※2

-XX:+HitachiVerboseGCPrintCauseオプションが指定されている場合に出力されます。

拡張verbosegc情報の出力例とフルガーベージコレクションの要因分析方法については，「8.8　拡張verbosegc情報を使用したフルガーベージコレクションの要因の分析方法」を参照してください。また，オプションについては，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

なお，Cosminexusでは，javagcコマンドを使用して，任意のタイミングでガーベージコレクションを発生させることもできます。この場合，-vオプションを指定することで，拡張verbosegc情報と同じ内容を出力できます。javagcコマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

8.3　Tenured領域のメモリサイズの見積もり

この節では，Tenured領域のメモリサイズの見積もりについて説明します。

Tenured領域のメモリサイズは，次のように見積もります。

Tenured領域のメモリサイズ
=アプリケーションで必要なメモリサイズ+DefNew領域のメモリサイズ

ここでは，アプリケーションで必要なメモリサイズの算出方法について説明します。

また，見積もったメモリサイズにDefNew領域のメモリサイズを追加する理由についても説明します。

＜この節の構成＞

8.3.1　アプリケーションで必要なメモリサイズの算出

8.3.2　DefNew領域のメモリサイズを追加する理由

8.3.1　アプリケーションで必要なメモリサイズの算出

Tenured領域のメモリサイズは，アプリケーションが最低限必要とするメモリサイズから見積もります。必要なメモリサイズが確保できない場合，OutOfMemoryErrorが発生してJavaVMが停止します。

アプリケーションが必要とするメモリサイズは，フルガーベージコレクション実行時の拡張verbosegc情報で，フルガーベージコレクション実行後に使用しているメモリサイズを確認することで判断できます。これは，フルガーベージコレクション実行後にJavaヒープ全体から不要なオブジェクトをすべて削除した状態のメモリサイズが，アプリケーションが必要とするメモリサイズに近いと考えられるためです。

フルガーベージコレクション実行時の拡張verbosegc情報の出力例を次に示します。

…
[VGC]<Wed May 11 23:12:05 2005>[Full GC 31780K->30780K(32704K), 0.2070500secs][DefNew::Eden: 3440K->1602K(3456K)][DefNew::Survivor:58K->0K(64K)][Tenured: 28282K->29178K(29184K)][Perm:1269K->1269K(4096K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

「Full GC」に続いて出力されている情報のうち，ガーベージコレクションの実行後の情報「->30780K」を確認します。ここでは，フルガーベージコレクション実行後に，30,780キロバイトのメモリサイズを必要としていることがわかります。

何回分かのフルガーベージコレクションの拡張verbosegc情報を集め，ガーベージコレクション実行後の領域長がいちばん大きい情報を，アプリケーションが必要とするメモリサイズであると判断してください。

8.3.2　DefNew領域のメモリサイズを追加する理由

Tenured領域のメモリサイズには，アプリケーションが最低限必要とするメモリサイズに，DefNew領域分のメモリサイズを追加することをお勧めします。これは，Tenured領域の未使用メモリサイズがDefNew領域の使用メモリサイズを下回ることによって，フルガーベージコレクションが頻発するのを防ぐためです。

通常，DefNew::Eden領域がいっぱいになると，コピーガーベージコレクションが発生します。このとき，DefNew::Eden領域とDefNew::Survivor領域のFrom空間に存在する使用中のJavaオブジェクトが，DefNew::Survivor領域のTo空間に移動しようとします。しかし，使用中のJavaオブジェクトのメモリサイズがTo空間のメモリサイズよりも大きい場合，使用中のJavaオブジェクトはTo空間ではなく，Tenured空間に退避されます。このとき，Tenured空間の未使用領域がDefNew::Eden領域とDefNew::Survivor領域で使用中のメモリサイズよりも小さいと，フルガーベージコレクションが発生してしまいます。

これを防ぐために，Tenured領域には，アプリケーションが必要とするメモリサイズに加えて，DefNew領域分のメモリサイズを追加してください。

考え方を次の図に示します。

図8-10　DefNew領域のメモリサイズを追加する理由の考え方

オブジェクトが退避できないでフルガーベージコレクションが発生する例
Tenured領域のメモリの空き領域（アプリケーションで必要なメモリ領域以外の領域）がDefNew領域のメモリサイズよりも小さいため，DefNew::Eden領域およびFrom空間からの移動オブジェクトが多い場合，オブジェクトの退避に対応できないで，メモリ不足になります。この場合，フルガーベージコレクションが発生します。

オブジェクトが確実に退避できる例
Tenured領域のメモリの空き領域（アプリケーションで必要なメモリ領域以外の領域）がDefNew領域と同じサイズ分確保してあるため，DefNew::Eden領域およびFrom空間からの移動オブジェクトが多い場合も，オブジェクトの退避に対応できます。

なお，DefNew領域のメモリサイズの見積もりについては，「8.4　DefNew領域のメモリサイズの見積もり」で説明します。

ポイント

拡張verbosegc情報などで確認したときに，コピーガーベージコレクションが発生しないでフルガーベージコレクションが頻発している場合，DefNew領域からの退避オブジェクトに対してTenured領域のメモリサイズが小さいことが考えられます。DefNew領域のサイズを増やした場合などにこの状態になることがあります。必要に応じて，Tenured領域のメモリサイズを見直してください。また，DefNew領域内のEden領域とSurvivor領域の関係もあわせて見直してください。

8.4　DefNew領域のメモリサイズの見積もり

この節では，DefNew領域のメモリサイズの見積もりについて説明します。

DefNew領域のメモリサイズは，次のように見積もります。

DefNew領域のメモリサイズ
=DefNew::Survivor領域のメモリサイズ+DefNew::Eden領域のメモリサイズ

ここでは，DefNew::Survivor領域およびDefNew::Eden領域のメモリサイズを見積もる方法について説明します。

＜この節の構成＞

8.4.1　DefNew::Survivor領域のメモリサイズの見積もり

8.4.2　DefNew::Eden領域のメモリサイズの見積もり

8.4.1　DefNew::Survivor領域のメモリサイズの見積もり

DefNew::Survivor領域のメモリサイズは，実際にアプリケーションを動作させて，DefNew::Survivor領域の使用状況を確認しながらチューニングしていきます。

チューニングの流れを次に示します。

アプリケーションでのリクエスト／レスポンス処理に使用するメモリサイズを見積もり，それをDefNew::Survivor領域のメモリサイズに指定して，アプリケーションを実行します。
このとき，チューニングで使用する情報を出力するために，-XX:+PrintTenuringDistributionオプションを指定してJ2EEサーバを起動します。

DefNew::Survivor領域に割り当てられているメモリサイズと，アプリケーション実行時に実際に使用されているメモリ使用量から，メモリ使用率を確認します。
メモリ使用率が100%に近い場合，コピーガーベージコレクション実行時にDefNew領域およびDefNew::Survivor領域のFrom空間の使用中オブジェクトがTo空間に入り切らなくなり，オブジェクトの退避が発生します。この場合は，DefNew::Survivor領域を増やすことを検討してください。

DefNew::Survivor領域のオブジェクトの年齢分布を確認し，寿命の長いオブジェクトが存在し続けていないかを確認します。
DefNew::Survivor領域のメモリサイズを増やすと，オブジェクトがTenured領域に移動するのが遅くなります。寿命の長いオブジェクトをDefNew::Survivor領域に格納し続けるのは，性能を低下させる要因になります。この場合は，DefNew::Survivor領域のメモリサイズを小さくするか，またはTenured領域に移動するためのしきい値を下げることを検討してください。

それぞれのチューニング作業について説明します。

＜この項の構成＞

(1)　リクエスト／レスポンス処理に使用するメモリサイズの見積もり

(2)　メモリ使用率の確認

(3)　オブジェクトの年齢分布の確認

(1)　リクエスト／レスポンス処理に使用するメモリサイズの見積もり

DefNew::Survivor領域は，寿命の短いオブジェクトを格納する領域です。サーバサイドで動作するアプリケーションの場合，リクエストやレスポンスの処理するために使われている，寿命の短いオブジェクトを格納する領域と考えることができます。このため，DefNew::Survivor領域のメモリサイズの見積もりでは，ある時点で存在する寿命が短いオブジェクトの最大サイズ，つまり，ある時点でのリクエストやレスポンスの処理に使用するメモリの最大サイズを考えます。例えば，ステートレスなサーブレットで構成されたアプリケーションの場合，DefNew::Survivor領域のメモリサイズを，「一つのリクエスト処理で使用する最大メモリサイズ×リクエストの同時実行数」と考えることができます。

(2)　メモリ使用率の確認

「(1) リクエスト／レスポンス処理に使用するメモリサイズの見積もり」で見積もった値をDefNew::Survivor領域のメモリサイズとして設定して，アプリケーションを実行します。実行時に使用されるメモリ使用量から，DefNew::Survivor領域に割り当てたメモリサイズに対するメモリ使用率を確認します。

参考

DefNew::Survivor領域のメモリサイズは，直接は指定できません。

DefNew::Survivor領域のメモリサイズを指定する場合は，まず，-XmxオプションでJavaヒープの最大サイズを指定して，-XX:NewRatio=<value>によってJavaヒープのメモリサイズをDefNew領域とTenured領域で分ける割合を指定した上で，-XX:SurvivorRatio=<value>オプションによって，DefNew::Eden領域との割合を指定する必要があります。

メモリ使用率は，拡張verbosegc情報で確認できます。

コピーガーベージコレクション実行時の拡張verbosegc情報の出力例を次に示します。

…
[VGC]<Wed May 11 23:12:05 2005>[GC 27340K->27340K(32704K), 0.0432900 secs][DefNew::Eden: 3440K->0K(3456K)][DefNew::Survivor: 58K->58K(64K)][Tenured: 23841K->27282K(29184K)][Perm: 1269K->1269K(4096K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

「DefNew::Survivor: 58K->58K(64K)」は，「ガーベージコレクション実行前のメモリサイズ->ガーベージコレクション実行後のメモリサイズ（割り当てられているメモリサイズ）」を意味します。この場合，64KBのDefNew::Survivor領域中58KBがすでに使用されていて，使用率は約90%になります。

ポイント

DefNew::Survivor領域のメモリ使用率には，目標値があります。デフォルトでは50%ですが，-XX:TargetSurvivorRatio=<value>で変更できます。この目標値は，DefNew::Survivor領域のオブジェクトがTenured領域に移動するときのしきい値に影響します。使用率が目標値を超えた場合はしきい値が下がり，使用率が目標値を下回った場合はしきい値が上がります。使用率が目標値よりも高い場合は，DefNew::Survivor領域のメモリサイズを増やすことを検討してください。

参考

-XX:PrintTenuringDistributionオプションの出力結果からメモリ使用率を確認することもできます。その場合は，すべての年齢のオブジェクトが使用しているメモリサイズの合計値と，「(1) リクエスト／レスポンス処理に使用するメモリサイズの見積もり」で設定した値を比べてメモリ使用率を算出してください。-XX:PrintTenuringDistributionオプションの出力結果の例については，「(3) オブジェクトの年齢分布の確認」を確認してください。

(3)　オブジェクトの年齢分布の確認

DefNew::Survivor領域のオブジェクトの年齢分布を確認し，寿命の長いオブジェクトが存在し続けていないかを確認します。オブジェクトの年齢分布は，-XX:+PrintTenuringDistributionオプションの出力結果で確認できます。

J2EEサーバ起動時にusrconf.cfgに-XX:PrintTenuringDistributionオプションを指定すると，DefNew::Survivor領域の使用状況が出力されます。出力例を次に示します。

Desired survivor size 5467547 bytes, new threshold 30 (max 31)
- age   1:    1357527 bytes,       1357527 total
- age   2:     182134 bytes,       1539661 total

「-age」に続けて出力されているのが，DefNew::Survivor領域でその年齢のオブジェクトが使用しているメモリサイズです。なお，「total」は，1歳からその年齢までのオブジェクトが使用しているメモリサイズの累計です。例の場合は，1歳のオブジェクトのメモリサイズが1,357,527バイト，2歳のオブジェクトのメモリサイズが182,134バイト，1歳と2歳のオブジェクトのメモリサイズの合計が1,539,661バイトであることを示しています。

DefNew::Survivor領域で寿命の長いオブジェクトの割合が高い場合は，DefNew::Survivor領域のメモリサイズを小さくするか，またはTenured領域に移動するためのしきい値を下げることを検討してください。

8.4.2　DefNew::Eden領域のメモリサイズの見積もり

DefNew::Eden領域のメモリサイズは，コピーガーベージコレクションを発生させる間隔に影響します。DefNew::Eden領域のメモリサイズを大きく取ると，コピーガーベージコレクションの発生間隔が長くなります。なお，コピーガーベージコレクションに掛かる時間は，使用中のオブジェクトの個数に影響され，DefNew::Eden領域のメモリサイズにはあまり影響されません。このため，コピーガーベージコレクションが頻発しないように，DefNew::Eden領域のメモリサイズを十分に確保することが，性能向上には効果的です。

ただし，DefNew::Eden領域のメモリサイズを大きくし過ぎると，キャッシュ効率が悪くなることがありますので，注意してください。

8.5　一定期間存在するオブジェクトの扱いの検討

これまでの説明は，オブジェクトの寿命に応じて，それぞれの領域に次のように格納することを前提としてきました。

アプリケーションの動作に必要な寿命の長いオブジェクトは，Tenured領域に格納する。

リクエスト処理やレスポンス処理などの寿命の短いオブジェクトは，DefNew領域に格納する。

しかし，例えばHTTPセッションに対応したオブジェクトなどの場合，セッションが開始されてからタイムアウトかログアウトによって終了するまで，一定期間使用されます。このようなオブジェクトは，寿命は長くありませんが，何回かのコピーガーベージコレクションの対象になります。

メモリサイズの見積もりでは，これらのオブジェクトを，DefNew領域，Tenured領域のどちらかに格納することを前提として，見積もりをする必要があります。

ここでは，それぞれの特徴を示します。アプリケーションの種類や目的に応じて，どちらかのメモリサイズを増加させるように見積もりをしてください。

＜この節の構成＞

8.5.1　DefNew領域に格納する方法

8.5.2　Tenured領域に格納する方法

8.5.1　DefNew領域に格納する方法

一定期間存在するオブジェクトをDefNew領域で管理する方法です。DefNew領域のメモリサイズに，これらの一定期間存在するオブジェクト分のメモリサイズを追加して見積もります。

DefNew領域サイズを大きくしてオブジェクトのTenured領域への移動を抑止することによって，フルガーベージコレクションの発生も抑止できます。ただし，コピーガーベージコレクション実行時にDefNew領域内にある使用中オブジェクトの数が増えるため，DefNew領域内でのコピー処理に時間が掛かり，1回当たりのコピーガーベージコレクション実行時間は長くなります。コピーガーベージコレクションの実行時間がフルガーベージコレクション実行時間よりも長くなるような場合は，メモリサイズの再見積もりが必要です。また，メモリ空間のサイズ設定によっては，本来コピーガーベージコレクションで回収されるはずの寿命の短いオブジェクトが使用する領域が不足して，Tenured領域への退避が発生するおそれがあります。この場合は，最終的にはフルガーベージコレクションが発生してしまいます。

なお，一定期間存在するオブジェクトをDefNew領域で管理できているかどうかは，拡張verbosegc情報で確認できます。実際にアプリケーションを動作させて，出力された拡張verbosegc情報で，コピーガーベージコレクション発生後のTenured領域のメモリサイズが大幅に増えていないことを確認してください。

DefNew領域での管理に失敗している場合，システムの処理性能が大幅に低下していることがあります。DefNew領域で管理できていないことがわかった場合は，一定期間存在するオブジェクトは，Tenured領域に格納して管理することを検討してください。Tenured領域で管理する方法については，「8.5.2　Tenured領域に格納する方法」を参照してください。

8.5.2　Tenured領域に格納する方法

一定期間存在するオブジェクトをTenured領域に移動させて管理する方法です。Tenured領域への移動のしきい値を低く設定することで実現できます。通常，しきい値は，DefNew::Survivor領域の使用率に応じて動的に変化しますが，-XX:MaxTenuringThreshold=<value>オプションを使用すると，固定できます。一定期間存在するオブジェクトをTenured領域で管理したい場合は，この値に1または2を指定することをお勧めします。例えば，「-XX:MaxTenuringThreshold=2」を指定しておけば，3回目のコピーガーベージコレクションの対象になったオブジェクトは，すべてTenured領域に移動します。

この方法を使用すると，コピーガーベージコレクションの対象になるオブジェクトが少なくなり，実行時間が短縮できます。ただし，多くのオブジェクトがTenured領域に移動するため，Tenured領域がいっぱいになった段階でフルガーベージコレクションが定期的に発生します。システムを安定して動作させるためには，システムに掛かる負荷が低いときなどに，フルガーベージコレクションを強制的に発生させてください。フルガーベージコレクションを強制的に発生させるには，次の方法があります。

プログラム内でSystem.gc()メソッドを呼び出す

javagcコマンドを実行する
javagcコマンドの詳細については，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

8.6　Javaヒープの最大サイズ／初期サイズの決定

Tenured領域およびDefNew領域の見積もりができたら，それらを基にJavaヒープの最大サイズと初期サイズを決定します。

Javaヒープの最大サイズは，次のように決定します。

Javaヒープの最大サイズ
=Tenured領域のメモリサイズ+DefNew領域のメモリサイズ

Javaヒープのメモリサイズを設定する場合，まず，-Xmxオプションに，拡張領域のサイズも含む，Javaヒープ領域の最大サイズを指定します。次に，-Xmsオプションに，Javaヒープ領域の初期サイズを指定します。なお，-Xmsオプションに指定するサイズは，-Xmxオプションに指定したサイズよりも小さくする必要があります。

JavaVMは，起動時に，-Xmsオプションで指定された分のメモリ領域をJavaヒープ領域として確保します。その後，アプリケーション実行中に-Xmsオプションで指定した以上のメモリ領域が必要になった場合に，-Xmxオプションで指定したサイズになるまで，ヒープ領域を追加して割り当てていきます。逆に，アプリケーションの中で不要なメモリ領域が発生した場合は，-Xmsオプションで指定したサイズまで，Javaヒープ領域として確保している領域を減らしていきます。

なお，システムのメモリサイズに余裕がある場合は，-Xmxオプションと-Xmsオプションには同じ値を指定することをお勧めします。

8.7　Permanent領域のメモリサイズの見積もり

この節では，Permanent領域のメモリサイズの見積もりについて説明します。Permanent領域は，ロードされたclassなどが格納される領域です。

Permanent領域のメモリサイズは，「8.1.2　JavaVMで使用するメモリ空間の構成とJavaVMオプション」で示したとおり，-Xmxオプションで指定したメモリサイズ（Javaヒープ）とは別に確保されます。

デフォルト値については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

次に，Permanent領域の使用量の見積もり方法を示します。

●Permanent領域の使用量の見積もり方法

Permanent領域でのメモリ使用量は，大体，J2EEサーバにロードされるクラスファイルの合計サイズになります。Cosminexusの場合，次に示すクラスファイルのサイズの総和から見積もることができます。

WEB-INF/classes以下のすべてのクラスファイル

WEB-INF/lib以下のJARファイルに含まれる，すべてのクラスファイル

JSPコンパイル結果として生成された，すべてのクラスファイル

EJB-JARに含まれるすべてのクラスファイル

コンテナ拡張ライブラリ，ライブラリJAR，参照ライブラリを利用している場合に追加するJARファイルに含まれる，すべてのクラスファイル

Cosminexus提供のクラスファイル（システムクラスファイル）
システムクラスファイルの総和は約80MBになります。

Permanent領域のメモリサイズは，-XX:MaxPermSize=<size>オプション，および-XX:PermSize=<size>オプションで指定します。これらのオプションのデフォルト値については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

8.8　拡張verbosegc情報を使用したフルガーベージコレクションの要因の分析方法

この節では，拡張verbosegc情報を使用したフルガーベージコレクションの要因の分析方法について説明します。拡張verbosegc情報は，日立固有のJavaVMオプションである-XX:+HitachiVerboseGCオプションを指定することによって出力できるJavaVMのログ情報です。チューニングに役立つ情報のほか，障害要因の分析にも役立つ情報が出力されます。

チューニング実行時に拡張verbosegc情報を参照することで，次の情報を確認できます。

ガーベージコレクション実行前と実行後の各領域の使用メモリサイズ

ガーベージコレクションが発生した要因

また，-XX:+HitachiVerboseGCとほかの日立固有のJavaVMオプションを組み合わせることによって，さらに詳細な情報が出力できます。-XX:+HitachiVerboseGCオプションおよびそのほかの日立固有のJavaVMオプションの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

＜この節の構成＞

8.8.1　拡張verbosegc情報の出力形式の概要

8.8.2　フルガーベージコレクション発生時の拡張verbosegc情報の出力例

8.8.1　拡張verbosegc情報の出力形式の概要

拡張verbosegc情報は，コピーガーベージコレクションが発生した場合と，フルガーベージコレクションが発生した場合に出力されます。

コピーガーベージコレクションが発生すると，ガーベージコレクションの種類として「GC」と出力されます。また，フルガーベージコレクションが発生すると，ガーベージコレクションの種類として「Full GC」と出力されます。種類に続いて，それぞれの領域の「＜ガーベージコレクション前の領域長＞->＜ガーベージコレクション後の領域長＞（＜確保済み領域サイズ＞）」が出力されます。

以降に，フルガーベージコレクションが発生した場合の拡張verbosegc情報の出力例を示します。拡張verbosegc情報には，ほかにもガーベージコレクションの発生要因やGCスレッドのCPU時間も出力されます。

拡張verbosegc情報の出力形式の詳細，およびそれぞれのオプションの詳細については，マニュアル「Cosminexus　リファレンス　定義編」を参照してください。

8.8.2　フルガーベージコレクション発生時の拡張verbosegc情報の出力例

ここでは，フルガーベージコレクションの発生時の拡張verbosegc情報の出力例を示します。

＜この項の構成＞

(1)　DefNew領域（Eden領域とSurvivor領域の合計）で使用しているメモリサイズがTenured領域の最大値に対する未使用メモリサイズを上回った場合

(2)　アロケーションしたいメモリサイズ（newで作成するJavaオブジェクトのサイズ）がTenured領域の未使用メモリサイズを上回る場合

(3)　コピーガーベージコレクション実施の結果，確保済みTenured領域の未使用メモリサイズが10,000バイトを下回った場合

(4)　コピーガーベージコレクション実施時のTenured領域へのオブジェクトの移動によって，確保済みTenured領域の拡張が発生した場合

(5)　アプリケーション内でjava.lang.System.gc()メソッドが実行された場合

(6)　Permanent領域にアロケーションしたいメモリサイズが確保済みPermanent領域の未使用メモリサイズを上回る場合

(7)　javagcコマンドを実行した場合の出力例

(8)　jheapprofコマンドを実行した場合の出力例

(1)　DefNew領域（Eden領域とSurvivor領域の合計）で使用しているメモリサイズがTenured領域の最大値に対する未使用メモリサイズを上回った場合

拡張verbosegc情報の出力例を次に示します。太字の部分がフルガーベージコレクション発生の要因を示す個所です。

…
[VGC]<Wed May 11 23:12:05 2005>[GC 27340K->27340K(32704K), 0.0432900 secs][DefNew::Eden: 3440K->0K(3456K)][DefNew::Survivor: 58K->58K(64K)][Tenured: 23841K->27282K(29184K)][Perm: 1269K->1269K(4096K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
[VGC]<Wed May 11 23:12:05 2005>[Full GC 30780K->30780K(32704K), 0.2070500 secs][DefNew::Eden: 3440K->1602K(3456K)][DefNew::Survivor: 58K->0K(64K)][Tenured: 27282K->29178K(29184K)][Perm: 1269K->1269K(4096K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

DefNew領域で使用しているメモリサイズ（3440K+58K=3498K）が，Tenured領域の最大値に対する未使用メモリサイズ（29184K-27282K=1902K）を上回りました。

フルガーベージコレクションの要因は，オブジェクトの割り付け失敗です。

(2)　アロケーションしたいメモリサイズ（newで作成するJavaオブジェクトのサイズ）がTenured領域の未使用メモリサイズを上回る場合

拡張verbosegc情報の出力例を次に示します。太字の部分がフルガーベージコレクション発生の要因を示す個所です。

…
[VGC]<Wed May 11 23:53:18 2005>[GC 28499K->28490K(32704K), 0.0540590 secs][DefNew::Eden: 808K->0K(3456K)][DefNew::Survivor: 64K->62K(64K)][Tenured: 27626K->28428K(29184K)][Perm: 1269K->1269K(4096K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
[VGC]<Wed May 11 23:53:18 2005>[Full GC 28490K->8959K(32704K), 0.1510380 secs][DefNew::Eden: 0K->0K(3456K)][DefNew::Survivor: 62K->0K(64K)][Tenured: 28428K->8959K(29184K)][Perm: 1269K->1269K(4096K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

Tenured領域の未使用メモリサイズ（29184K-28428K=756K）を上回るメモリサイズのJavaオブジェクトを，newで作成しようとしました。

フルガーベージコレクションの要因は，オブジェクトの割り付け失敗です。

(3)　コピーガーベージコレクション実施の結果，確保済みTenured領域の未使用メモリサイズが10,000バイトを下回った場合

拡張verbosegc情報の出力例を次に示します。太字の部分がフルガーベージコレクション発生の要因を示す個所です。

…
[VGC]<Fri May 25 15:21:33 2007>[GC 15436K->15416K(19840K), 0.0111825 secs][DefNew::Eden: 4413K->0K(4416K)][DefNew::Survivor: 512K->509K(512K)][Tenured: 10511K->14906K(14912K)][Perm: 1976K->1976K(8192K)][cause:ObjAllocFail][User: 0.0000000 secs][Sys: 0.0000000 secs]
[VGC]<Fri May 25 15:21:33 2007>[Full GC 15416K->8622K(19840K), 0.0284614 secs][DefNew::Eden: 0K->0K(4416K)][DefNew::Survivor: 509K->0K(512K)][Tenured: 14906K->8622K(14912K)][Perm: 1976K->1976K(8192K)][cause:ObjAllocFail][User: 0.0312500 secs][Sys: 0.0000000 secs]
…

この出力例からは，次のことがわかります。

1行目のコピーガーベージコレクションでDefNew領域からTenured領域にオブジェクトが移動したことによって，Tenured領域の使用済みメモリサイズが10511Kから14906Kに増加しました。これによって，確保済みTenured領域の未使用メモリサイズが14912K-14906K=6Kとなり，10,000バイト（約10Kバイト）を下回りました。

1行目のコピーガーベージコレクションの原因は，オブジェクトの割り付け失敗です。1行目のコピーガーベージコレクションと2行目のフルガーベージコレクションは，Javaプログラムに制御が戻る前に連続して発生します。

(4)　コピーガーベージコレクション実施時のTenured領域へのオブジェクトの移動によって，確保済みTenured領域の拡張が発生した場合

拡張verbosegc情報の出力例を次に示します。太字の部分がフルガーベージコレクション発生の要因を示す個所です。

…
[VGC]<Fri May 25 15:42:00 2007>[GC 12745K->10151K(15872K), 0.0048346 secs][DefNew::Eden: 4416K->0K(4416K)][DefNew::Survivor: 137K->512K(512K)][Tenured: 8192K->9639K(10944K)][Perm: 1976K->1976K(8192K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0000000 secs]
[VGC]<Fri May 25 15:42:00 2007>[GC 14563K->14536K(19072K), 0.0104957 secs][DefNew::Eden: 4412K->0K(4416K)][DefNew::Survivor: 512K->510K(512K)][Tenured: 9639K->14026K(14144K)][Perm: 1976K->1976K(8192K)][cause:ObjAllocFail][User: 0.0156250 secs][Sys: 0.0000000 secs]
[VGC]<Fri May 25 15:42:00 2007>[Full GC 14536K->8610K(19072K), 0.0287254 secs][DefNew::Eden: 0K->0K(4416K)][DefNew::Survivor: 510K->0K(512K)][Tenured: 14026K->8610K(14144K)][Perm: 1976K->1976K(8192K)][cause:ObjAllocFail][User: 0.0312500 secs][Sys: 0.0000000 secs]
…

この出力例からは，次のことがわかります。

2行目のコピーガーベージコレクションでDefNew領域からTenured領域へのオブジェクトが移動したことによって，Tenured領域が最低でも14026K以上必要になりました。このため，確保済みTenured領域サイズが10944Kから14144Kに拡張されました。

2行目のコピーガーベージコレクションの原因は，オブジェクトの割り付け失敗です。2行目のコピーガーベージコレクションと3行目のフルガーベージコレクションは，Javaプログラムに制御が戻る前に連続して発生します。

(5)　アプリケーション内でjava.lang.System.gc()メソッドが実行された場合

拡張verbosegc情報の出力例を次に示します。太字の部分がフルガーベージコレクション発生の要因を示す個所です。

…
[VGC]<Mon Apr 18 20:36:29 2005>[Full GC 330K->150K(3520K), 0.0387690 secs][DefNew::Eden: 330K->0K(2048K)][DefNew::Survivor: 0K->0K(64K)][Tenured: 0K->150K(1408K)][Perm: 1266K->1266K(4096K)][cause:System.gc][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

フルガーベージコレクションの要因は，J2EEアプリケーション内またはバッチアプリケーション内でのjava.lang.System.gc()メソッド呼び出しです。

(6)　Permanent領域にアロケーションしたいメモリサイズが確保済みPermanent領域の未使用メモリサイズを上回る場合

拡張verbosegc情報の出力例を次に示します。太字の部分がフルガーベージコレクション発生の要因を示す個所です。

…
[VGC]<Mon Apr 18 20:36:29 2005>[Full GC 57051K->25121K(129792K), 0.5531230 secs][DefNew::Eden: 40943K->0K(41088K)][DefNew::Survivor: 1280K->0K(1280K)][Tenured: 14827K->25121K(87424K)][Perm: 20479K->20479K(20480K)][cause:PermAllocFail][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

Permanent領域にアロケーションしようとしたメモリサイズが，確保済みPermanent領域の未使用メモリサイズ（20480K-20479K=1K）を上回りました。

フルガーベージコレクションの要因は，Permanentヒープの割り付け失敗です。

(7)　javagcコマンドを実行した場合の出力例

拡張verbosegc情報の出力例を次に示します。太字の部分がフルガーベージコレクション発生の要因を示す個所です。

…
[VGC]<Mon Apr 18 21:46:50 2005>[Full GC 369K->189K(3520K), 0.0403010 secs][DefNew::Eden: 369K->0K(2048K)][DefNew::Survivor: 0K->0K(64K)][Tenured: 0K->189K(1408K)][Perm: 1266K->1266K(4096K)][cause:JavaGC Command][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

フルガーベージコレクションの要因は，javagcコマンド実行です。

(8)　jheapprofコマンドを実行した場合の出力例

拡張verbosegc情報の出力例を次に示します。太字の部分がフルガーベージコレクション発生の要因を示す個所です。

…
[VGC]<Mon Apr 18 21:46:50 2005>[Full GC 369K->189K(3520K), 0.0403010 secs][DefNew::Eden: 369K->0K(2048K)][DefNew::Survivor: 0K->0K(64K)][Tenured: 0K->189K(1408K)][Perm: 1266K->1266K(4096K)][cause:JHeapProf Command][User: 0.0156250 secs][Sys: 0.0312500 secs]
…

この出力例からは，次のことがわかります。

フルガーベージコレクションの要因は，jheapprofコマンド実行です。

付録

＜この付録の構成＞

付録A　ベーシックモードの利用（互換機能）

付録B　サーブレットエンジンモードの利用（互換機能）

付録C　推奨手順以外の方法でパフォーマンスチューニングをする場合のチューニングパラメタ

付録D　（3020-3-M04-61）の変更内容

付録E　用語解説

付録A　ベーシックモードの利用（互換機能）

互換用のサーバの動作モードとして，ベーシックモードがあります。ベーシックモードは，J2EEサーバモードの一つです。単一のデータベースだけのリソースをトランザクションで使用するシステムに適用できます。ここでは，ベーシックモードの利用について説明します。

なお，ベーシックモードは，1.4モードに比べて，使用できる機能に制限があります。旧バージョンでJ2EEサーバモードにベーシックモードを使用していた場合には，1.4モードに移行することをお勧めします。

＜この節の構成＞

付録A.1　パフォーマンスチューニング

付録A.1　パフォーマンスチューニング

ここでは，ベーシックモードで使用できるパフォーマンスチューニングについて説明します。

ベーシックモードで使用できるパフォーマンスチューニングを次の表に示します。

表A-1　ベーシックモードで使用できるパフォーマンスチューニング

チューニング項目 | 使用可否 | 参照先
同時実行数の最適化 | リクエスト処理スレッド数（インプロセスHTTPサーバ使用時） | ○ | 6.3.3
Webアプリケーションの同時実行数 | URLグループ単位 | ○ | 6.3.4
Webアプリケーション単位 | ○
Webコンテナ単位 | ○
Enterprise Beanの同時実行数 | Stateless Session Beanの同時実行数 | ○ | 6.3.5
Stateful Session Beanの同時実行数 | ○
Entity Beanの同時実行数 | ○
Message-driven Beanの同時実行数 | ○
CTMで制御する同時実行数 | ○ | 6.3.6
Enterprise Beanの呼び出し方法の最適化 | ローカルインタフェースの使用 | ○ | 6.4.1
リモートインタフェースのローカル呼び出し機能の使用 | ○ | 6.4.2
リモートインタフェースの参照渡し機能の使用 | ○ | 6.4.3
データベースアクセス方法の最適化 | コネクションプーリング | ○ | 付録A.1(1)
ステートメントプーリング | × | －
タイムアウトの設定 | Webフロントシステムでのタイムアウト | Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト | ○ | 6.6.2
リダイレクタ側で設定するWebコンテナへのデータ送信のタイムアウト | ○
リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト | ○
Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト | ○
Webコンテナ側で設定するリダイレクタへのデータ受信のタイムアウト | ○
バックシステムでのタイムアウト | EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト | ○ | 6.6.3
EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト | ○
EJBコンテナ側で設定するデータベースのトランザクションタイムアウト（DB Connectorを使用した場合） | ○※ | 6.6.4
データベースのタイムアウト | ○ | 6.6.5
J2EEアプリケーションのメソッドタイムアウト | ○ | 6.6.6
Webアプリケーションの動作の最適化 | 静的コンテンツとWebアプリケーションの配置の切り分け | ○ | 6.7.1
静的コンテンツのキャッシュ | ○ | 6.7.2
リダイレクタによるリクエストの振り分け | ○ | 6.7.3
CTMの動作の最適化 | CTMドメインマネジャおよびCTMデーモンの稼働状態を監視する間隔の設定 | ○ | 6.8.1
負荷状況監視間隔の設定 | ○ | 6.8.2
CTMデーモンのタイムアウト閉塞の設定 | ○ | 6.8.3
CTMで振り分けるリクエストの優先順位の設定 | ○ | 6.8.4
そのほかの項目のチューニング | Persistent Connectionについてのチューニング | ○ | 6.9

（凡例）○：使用できる。　×：使用できない。　－：該当しない。

注※

ベーシックモードの場合，CMTを使用するときのトランザクションのタイムアウトは，Enterprise Bean，インタフェースまたはメソッドの属性では設定できません。ベーシックモードの場合，CMTを使用するときのトランザクションのタイムアウトは，usrconf.propertiesで定義してください。

これらのチューニング項目のうち，ベーシックモードで使用できる機能や，チューニングパラメタの異なるものについて説明します。

＜この項の構成＞

(1)　データベースへのアクセス方法を最適化するためのチューニングパラメタ

(1)　データベースへのアクセス方法を最適化するためのチューニングパラメタ

ベーシックモードの場合に，コネクションプーリングで使用できる機能を次の表に示します。なお，コネクションプーリングで使用できる各機能の設計時の指針については，「6.5.1　コネクションプーリングを使用する」を参照してください。

表A-2　コネクションプーリングで使用できる機能（ベーシックモードの場合）

機能 | 使用可否
プールするコネクションの最大値と最小値を指定する | ○
プール内のコネクションを検査して無効なコネクションを破棄する | ○
コネクション取得失敗時にリトライする | △
スイーパによって使わないコネクションをプールから削除する※ | ○
コネクションウォーミングアップによってあらかじめコネクションをプールしておく | ×
コネクション枯渇時のコネクション取得要求を取得待ちキューに入れる | ×
コネクションプール内の不要なコネクションを段階的に減少させる | ×
コネクションプールをクラスタ化する | ×
コネクションプールの未使用コネクションがしきい値以下になったとき，コネクションを追加する | ○
コネクション取得待ち時間を指定する | ○

（凡例）○：使用できる。　△：指定しても無視される。　×：使用できない。

注※

ただし，スイーパを実行する処理は負荷が高いため，性能に影響が出ます。このため，スイーパを使用する場合は，自動削除の間隔を1時間以上の値にすることをお勧めします。

次に，ベーシックモードの場合にコネクションプーリングをチューニングするパラメタについて説明します。これらのチューニングパラメタは，データソース単位に設定します。

チューニングパラメタについて，次の表に示します。これらは，サーバ管理コマンドのCUIで設定します。CUIを使用する場合は，属性ファイルを編集してください。

表A-3　ベーシックモードの場合のコネクションプーリングのチューニングパラメタ

設定項目 | 設定方法 | 設定個所
コネクションプールにプールするコネクションの最小値 | CUI（cjsetresprop） | データソース属性ファイルの<PoolConfiguration>タグ下の<MinimumSize>タグ
コネクションプールにプールするコネクションの最大値 | CUI（cjsetresprop） | データソース属性ファイルの<PoolConfiguration>タグ下の<MaximumSize>タグ
コネクションの生成時刻からコネクションを自動破棄するかを判定するまでの時間 | CUI（cjsetresprop） | データソース属性ファイルの<PoolConfiguration>タグ下の<ConnectionTimeout>タグ
コネクションの自動破棄（コネクションスイーパ）が動作する間隔 | CUI（cjsetresprop） | データソース属性ファイルの<PoolConfiguration>タグ下の<SweeperInterval>タグ
コネクションプールにコネクションを追加するためのしきい値 | CUI（cjsetresprop） | データソース属性ファイルの<PoolConfiguration>タグ下の<Threshold>タグ
コネクションプールにコネクションを追加する場合の追加数 | CUI（cjsetresprop） | データソース属性ファイルの<PoolConfiguration>タグ下の<GrowthIncrement>タグ
コネクション取得待ち時間 | CUI（cjsetresprop） | データソース属性ファイルの<PoolConfiguration>タグ下の<WaitTimeout>タグ

注　

cjsetrespropコマンドについては，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。データソース属性ファイルについては，マニュアル「Cosminexus　リファレンス　定義編」参照してください。

付録B　サーブレットエンジンモードの利用（互換機能）

互換用のアプリケーションサーバの動作モードとして，サーブレットエンジンモードがあります。サーブレットエンジンモードは，サーブレットとJSPで構成されるWebアプリケーションだけをアプリケーションサーバで動作させたい場合に利用できます。ここでは，サーブレットエンジンモードの利用について説明します。

なお，旧バージョンでサーブレットエンジンモードを使用していた場合には，Cosminexusの運用管理機能などが使用できるJ2EEサーバモードに移行することをお勧めします。

＜この節の構成＞

付録B.1　システム構成の設計

付録B.2　パフォーマンスチューニング

付録B.1　システム構成の設計

ここでは，サーブレットエンジンモードで使用できるシステム構成について説明します。

＜この項の構成＞

(1)　システム設計の準備

(2)　サーブレットエンジンモードのシステムの構成

(1)　システム設計の準備

システム設計作業を始める前に，次のことを明確にする必要があります。

アプリケーションおよびプロセスの構成

運用方法

(a)　アプリケーションおよびプロセスの構成

サーブレットエンジンモードでは，サーブレットとJSPだけで構成されるアプリケーション（Webアプリケーション）が使用できます。

また，サーブレットエンジンモードでアプリケーションサーバを動作させるシステムでは，次に示すプロセスが必要となります。

Webサーバ※

Webコンテナサーバ

PRFデーモン

注※

Application Serverに含まれるWebサーバは，Hitachi Web Serverです。

これらのプロセスは，Application Serverによって提供され，Application Serverをインストールしたマシンで起動できます。

サーブレットエンジンモードの場合，Webクライアントからのリクエストを，リダレクタと連携したWebサーバ（Webサーバ連携）を利用して処理できます。利用できるWebサーバは，Hitachi Web ServerまたはMicrosoft IISです。

(b)　運用方法

サーブレットエンジンモードでは，Management Serverを利用した運用，およびクラスタソフトウェアと連携したシステムの運用はできません。サーブレットエンジンモードで運用する場合，システムの構築には，Cosminexusが提供するコマンドと定義ファイルを使用します。

(2)　サーブレットエンジンモードのシステムの構成

サーブレットエンジンモードを使用して，Cosminexusのシステムを設計する場合，Webコンテナサーバを使用した構成になります。Webコンテナサーバは，サーブレットエンジンモードで動作しているアプリケーションサーバです。

システム構成の特徴

Webコンテナサーバの構成の例を次の図に示します。

図B-1　Webコンテナサーバの構成の例

特徴

サーブレットとJSPだけが動作します。

サーブレットとJSPを対象にした，負荷分散機またはリダイレクタを使用した負荷分散構成，およびWebサーバとアプリケーションサーバを分離した構成が実現できます。

Management Serverを利用した運用はできません。

リクエストの流れ

サーブレットとJSPに対するクライアントからのリクエストは，WebブラウザからWebサーバを経由して送られます。

それぞれのマシンで起動するプロセス

それぞれのマシンに必要なソフトウェアとプロセスについて説明します。

アプリケーションサーバマシン

アプリケーションサーバマシンには，Application Server StandardまたはApplication Server Enterpriseをインストールする必要があります。

起動するプロセスは次のとおりです。

Webサーバ

Webコンテナサーバ

PRFデーモン

Application Server StandardまたはApplication Server Enterpriseには，WebサーバであるHitachi Web Serverが含まれています。Windowsの場合，WebサーバにMicrosoft IISを使用することもできます。この場合は，ソフトウェアとしてMicrosoft IISが必要です。

Webクライアントマシン

Webクライアントマシンには，Webブラウザが必要です。

付録B.2　パフォーマンスチューニング

ここでは，サーブレットエンジンモードで使用できるアプリケーションのチューニング項目について説明します。サーブレットエンジンモードでは，アプリケーションがサーブレットとJSPだけで構成されるWebアプリケーションが使用できます。サーブレットエンジンモードで使用できるアプリケーションのチューニング項目を次の表に示します。

表B-1　サーブレットエンジンモードで使用できるアプリケーションのチューニング項目

チューニング項目
利用できる機能
参照先

同時実行数の最適化
Webアプリケーションでの同時実行スレッド数制御
（Webコンテナ単位）
6.3.4

データベースアクセス方法の最適化
Webコンテナコネクションプーリング
付録B.2(1)

タイムアウトの設定
Webフロントシステムでのタイムアウトの設定
6.6.2

Webアプリケーションの動作の最適化
静的コンテンツとWebアプリケーションの配置の切り分け
6.7.1

静的コンテンツのキャッシュ
6.7.2

リダイレクタによるリクエストの振り分け（Webサーバ連携の場合）
6.7.3

これらのチューニング項目のうち，サーブレットエンジンモードで動作する場合に異なる機能について説明します。

＜この項の構成＞

(1)　Webコンテナコネクションプーリングを使用する

(1)　Webコンテナコネクションプーリングを使用する

サーブレットエンジンモード上で動作するWebアプリケーションからデータベースへ接続する場合，Webコンテナコネクションプールを使用します。このとき，Webコンテナコネクションプーリング機能を利用してデータベースへの接続をプールできます。これによって，コネクション生成時のパフォーマンスを向上できます。

Webコンテナコネクションプーリングを使用する場合，最初のコネクション取得要求があったときに，プール数の最小値までコネクションが生成され，プールされます。クライアントからコネクション取得要求があると，プールから未使用のコネクションが選択され，クライアントに渡されます。コネクションの解放要求があると，使用中になっているコネクションの状態が未使用に設定され，コネクションがプールに返されます。なお，コネクションの状態が，再利用できない状態に設定されている場合は，データベースとの接続が切断され，コネクションが削除されます。この場合，コネクションはプールに返されません。

Webコンテナコネクションプーリングを使用する場合は，チューニングパラメタを設定する必要があります。Webコンテナコネクションプーリングのチューニングパラメタは，プール管理情報設定ファイルに設定します。設定した内容は，cjwebeditpoolコマンドで登録します。プール管理情報設定ファイルについては，マニュアル「Cosminexus　リファレンス　定義編」を，cjwebeditpoolコマンドについては，マニュアル「Cosminexus　リファレンス　コマンド編」を参照してください。

Webコンテナコネクションプーリングのチューニングパラメタを次の表に示します。

表B-2　Webコンテナコネクションプーリングのチューニングパラメタ

設定項目 | 設定個所
プールするコネクションの最小値 | <MinimumSize>タグ
プールするコネクションの最大値 | <MaximumSize>タグ
コネクションを取得できなかった場合にリトライするまでのアプリケーションの待ち時間 | <RetryInterval>タグ
コネクションを取得できなかった場合のリトライ回数 | <RetryCount>タグ

付録C　推奨手順以外の方法でパフォーマンスチューニングをする場合のチューニングパラメタ

ここでは，「6.　パフォーマンスチューニング（J2EEアプリケーション実行基盤）」および「7.　パフォーマンスチューニング（バッチアプリケーション実行基盤）」で説明した項目について，推奨手順以外の方法でチューニングを実施するためのチューニングパラメタについて説明します。推奨以外の方法とは，運用管理ポータルを使用して設定する方法，およびファイル編集によって設定する方法です。

チューニングの考え方については，「6.　パフォーマンスチューニング（J2EEアプリケーション実行基盤）」および「7.　パフォーマンスチューニング（バッチアプリケーション実行基盤）」を参照してください。

＜この節の構成＞

付録C.1　同時実行数を最適化するためのチューニングパラメタ（推奨手順以外の方法）

付録C.2　Enterprise Beanの呼び出し方法を最適化するためのチューニングパラメタ（推奨手順以外の方法）

付録C.3　データベースへのアクセス方法を最適化するためのチューニングパラメタ（推奨手順以外の方法）

付録C.4　タイムアウトを設定するチューニングパラメタ（推奨手順以外の方法）

付録C.5　Webアプリケーションの動作を最適化するためのチューニングパラメタ（推奨手順以外の場合）

付録C.6　CTMの動作を最適化するチューニングパラメタ（推奨手順以外の方法）

付録C.7　Persistent Connectionについてのチューニングパラメタ（推奨手順以外の方法）

付録C.8　バッチサーバのフルガーベージコレクションを発生させるしきい値を設定するためのチューニングパラメタ（推奨手順以外の方法）

付録C.1　同時実行数を最適化するためのチューニングパラメタ（推奨手順以外の方法）

ここでは，同時実行数の最適化で使用するチューニングパラメタの設定方法と設定個所についてまとめて示します。

＜この項の構成＞

(1)　インプロセスHTTPサーバ使用時のリクエスト処理スレッド数

(2)　Webアプリケーションの同時実行数

(3)　Enterprise Beanの同時実行数

(4)　CTMで制御する同時実行数

(1)　インプロセスHTTPサーバ使用時のリクエスト処理スレッド数

インプロセスHTTPサーバを使用している場合の，リクエスト処理スレッド数のチューニングパラメタの設定方法および設定個所について，次の表に示します。

なお，Webサーバ連携でHitachi Web Serverを使用している場合のチューニングパラメタについては，マニュアル「Hitachi Web Server」を参照してください。

表C-1　インプロセスHTTPサーバ使用時のリクエスト処理スレッド数のチューニングパラメタ（推奨手順以外の方法）

設定項目 | 設定方法 | 設定個所
J2EEサーバ起動時に生成するリクエスト処理スレッド数 | 運用管理ポータル | ［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「初期スレッド数」
ファイル編集 | usrconf.propertiesのwebserver.connector.inprocess_http.init_threadsキー
Webクライアントとの接続数の上限（リクエスト処理スレッド数の上限） | 運用管理ポータル | ［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「初期スレッド数」
ファイル編集 | usrconf.propertiesのwebserver.connector.inprocess_http.max_connectionsキー
Webクライアントとの接続数の上限を超えた場合に使用されるTCP/IPのListenキュー（バックログ）の最大値 | 運用管理ポータル | ［通信・スレッド制御に関する設定］画面の「Webクライアントとの接続設定」の「TCPリスンキューの長さ」
ファイル編集 | usrconf.propertiesのwebserver.connector.inprocess_http.backlogキー
予備スレッド数の最大数 | 運用管理ポータル | ［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「予備スレッド」の「最大数」
ファイル編集 | usrconf.propertiesのwebserver.connector.inprocess_http.max_spare_threadsキー
予備スレッド数の最小数 | 運用管理ポータル | ［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「予備スレッド」の「最小数」
ファイル編集 | usrconf.propertiesのwebserver.connector.inprocess_http.min_spare_threadsキー

(2)　Webアプリケーションの同時実行数

URLグループ単位，Webアプリケーション単位，またはWebコンテナ単位に設定します。

(a)　URLグループ単位の同時実行数

URLグループ単位の同時実行数のチューニングパラメタの設定方法および設定個所について，次の表に示します。

表C-2　URLグループ単位の同時実行数のチューニングパラメタ（推奨手順以外の方法）

設定項目
設定方法
設定個所

Webコンテナ単位での最大同時実行スレッド数
（Webサーバ連携時）
運用管理ポータル
［Webコンテナの設定］画面の「Webサーバとの接続」の「最大スレッド数」

ファイル編集
usrconf.propertiesのwebserver.connector.ajp13.max_threadsキー

Webコンテナ単位での最大同時実行スレッド数
（インプロセスHTTPサーバ使用時）
運用管理ポータル
［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「同時実行スレッド数」

ファイル編集
usrconf.propertiesのwebserver.connector.inprocess_http.max_execute_threadsキー

Webアプリケーション単位で同時実行数を制御するかどうか
運用管理ポータル
［Webコンテナの設定］画面の「Webコンテナの設定」の「同時実行スレッド数制御機能の使用」

ファイル編集
usrconf.propertiesのwebserver.container.thread_control.enabledキー

デフォルトの実行待ちキューサイズ
運用管理ポータル
［Webコンテナの設定］画面の「Webコンテナの設定」の「実行待ちキューサイズ」

ファイル編集
usrconf.propertiesのwebserver.container.thread_control.queue_sizeキー

次の設定項目については，推奨手順の場合と違いがありません。

Webアプリケーション単位での最大同時実行スレッド数

Webアプリケーションの占有スレッド数

Webアプリケーション単位の実行待ちキューサイズ

URLグループ単位の同時実行スレッド数制御の定義名

URLグループ単位での最大同時実行スレッド数

URLグループ単位の占有スレッド数

URLグループ単位の実行待ちキューサイズ

URLグループ単位の制御対象となるURLパターン

(b)　Webアプリケーション単位の同時実行数

Webアプリケーション単位の同時実行数をチューニングするパラメタの設定方法および設定個所について，次の表に示します。

表C-3　Webアプリケーション単位の同時実行数のチューニングパラメタ（推奨手順以外の方法）

設定項目
設定方法
設定個所

Webコンテナ単位での最大同時実行スレッド数
（Webサーバ連携時）
運用管理ポータル
［Webコンテナの設定］画面の「Webサーバとの接続」の「最大スレッド数」

ファイル編集
usrconf.propertiesのwebserver.connector.ajp13.max_threadsキー

Webコンテナ単位での最大同時実行スレッド数
（インプロセスHTTPサーバ使用時）
運用管理ポータル
［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「同時実行スレッド数」

ファイル編集
usrconf.propertiesのwebserver.connector.inprocess_http.max_execute_threadsキー

Webアプリケーション単位で同時実行数を制御するかどうか
運用管理ポータル
［Webコンテナの設定］画面の「Webコンテナの設定」の「同時実行スレッド数制御機能の使用」

ファイル編集
usrconf.propertiesのwebserver.container.thread_control.enabledキー

デフォルトの実行待ちキューサイズ
運用管理ポータル
［Webコンテナの設定］画面の「Webコンテナの設定」の「実行待ちキューサイズ」

ファイル編集
usrconf.propertiesのwebserver.container.thread_control.queue_sizeキー

次の設定項目については，推奨手順と違いがありません。

Webアプリケーション単位での最大同時実行スレッド数

Webアプリケーションの占有スレッド数

Webアプリケーション単位の実行待ちキューサイズ

(c)　Webコンテナ単位の同時実行数

Webコンテナ単位の同時実行数をチューニングするパラメタの設定方法および設定個所について，次の表に示します。

表C-4　Webコンテナ単位の同時実行数のチューニングパラメタ（推奨手順以外の方法）

設定項目
設定方法
設定個所

Webコンテナ単位での最大同時実行スレッド数
（Webサーバ連携時）
運用管理ポータル
［Webコンテナの設定］画面の「Webサーバとの接続」の「最大スレッド数」

ファイル編集
usrconf.propertiesのwebserver.connector.ajp13.max_threadsキー

Webコンテナ単位での最大同時実行スレッド数
（インプロセスHTTPサーバ使用時）
運用管理ポータル
［通信・スレッド制御に関する設定］画面の「スレッド制御設定」の「同時実行スレッド数」

ファイル編集
usrconf.propertiesのwebserver.connector.inprocess_http.max_execute_threadsキー

参考

このほか，Webコンテナでは，リダイレクタからのTCP接続要求の最大待ち行列数も指定できます（usrconf.propertiesのwebserver.connector.ajp13.backlogキー）。ただし，これはソケットのListenキューの大きさを指定するキーであり，リクエストの実行待ちキューと直接の関係はありません。

(3)　Enterprise Beanの同時実行数

Enterprise Beanの同時実行数は，Enterprise Bean単位に設定します。

Enterprise Beanの同時実行数のチューニングパラメタについては，推奨手順の場合と違いがありません。

(4)　CTMで制御する同時実行数

CTMで制御する同時実行数のチューニングパラメタの設定方法および設定個所について，次の表に示します。CTMデーモン，アプリケーション，およびStateless Session Beanに設定する項目があります。

CTMで制御する同時実行数のチューニングパラメタの設定方法および設定個所について，次の表に示します。

表C-5　CTMで制御する同時実行数のチューニングパラメタ（推奨手順以外の方法）

設定対象 | 設定項目 | 設定方法 | 設定個所
CTMデーモン | CTMが制御するスレッドの最大値およびキューごとのリクエストの登録数 | 運用管理ポータル | ［スケジューリングの設定］画面の「CTMキューの設定」の「スレッド最大値」
ファイル編集 | ctmstartコマンドの引数「-CTMDispatchParallelCount」

なお，アプリケーションまたはStateless Session Beanに対する設定項目については，推奨手順の場合と違いがありません。

付録C.2　Enterprise Beanの呼び出し方法を最適化するためのチューニングパラメタ（推奨手順以外の方法）

ここでは，Enterprise Beanの呼び出し方法の最適化で使用するチューニングパラメタの設定個所についてまとめて示します。

＜この項の構成＞

(1)　ローカルインタフェースの使用

(2)　リモートインタフェースのローカル呼び出し機能の使用

(3)　リモートインタフェースの参照渡し機能の使用

(1)　ローカルインタフェースの使用

アプリケーション作成時に，J2EEで定義されているローカルインタフェースを使用してください。

推奨手順の場合と違いはありません。

(2)　リモートインタフェースのローカル呼び出し機能の使用

リモートインタフェースのローカル呼び出し機能をチューニングするパラメタの設定方法および設定個所について，次の表に示します。

表C-6　リモートインタフェースのローカル呼び出し機能のチューニングパラメタ（推奨手順以外の方法）

設定項目 | 設定方法 | 設定個所
ローカル呼び出し最適化機能の適用範囲 | 運用管理ポータル | ［EJBコンテナの設定］画面の「オプション」の「J2EEアプリケーションの呼び出し方式」
ファイル編集 | usrconf.propertiesのejbserver.rmi.localinvocation.scopeキー

(3)　リモートインタフェースの参照渡し機能の使用

リモートインタフェースの参照渡し機能をチューニングするパラメタの設定方法および設定個所について，次の表に示します。

表C-7　リモートインタフェースの参照渡し機能のチューニングパラメタ（推奨手順以外の方法）

設定項目 | 設定方法 | 設定個所
リモートインタフェースの参照渡し機能の使用（J2EEサーバ単位） | 運用管理ポータル | ［EJBコンテナの設定］画面の「オプション」の「リモートインタフェースの参照渡し」
ファイル編集 | usrconf.propertiesのejbserver.rmi.passbyreferenceキー

なお，リモートインタフェースの参照渡し機能の使用（Enterprise Bean単位）については，推奨手順の場合と違いがありません。

付録C.3　データベースへのアクセス方法を最適化するためのチューニングパラメタ（推奨手順以外の方法）

データベースへのアクセス方法の最適化で使用するチューニングパラメタについては，推奨手順の場合と違いがありません。

付録C.4　タイムアウトを設定するチューニングパラメタ（推奨手順以外の方法）

ここでは，タイムアウトの設定で使用するチューニングパラメタの設定個所についてまとめて示します。

＜この項の構成＞

(1)　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト

(2)　リダイレクタ側で設定するWebコンテナへのデータ送信のタイムアウト

(3)　リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト

(4)　Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト

(5)　Webコンテナ側で設定するリダイレクタへのデータ受信のタイムアウト

(6)　EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト

(7)　EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト

(8)　EJBコンテナ側で設定するデータベースのトランザクションタイムアウト（DB Connectorを使用した場合）

(9)　データベースのタイムアウト

(1)　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト

Webサーバ連携の場合は，Webサーバ単位に設定します。インプロセスHTTPサーバの場合は，J2EEサーバ単位に設定します。

表C-8　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウトのチューニングパラメタ（推奨手順以外の方法）

使用するWebサーバ
設定方法
設定個所

Webサーバ連携
ファイル編集※

Hitachi Web Serverの場合
httpsd.confのTimeoutディレクティブ

Microsoft IISの場合
isapi_redirect.confのreceive_client_timeoutキー

インプロセスHTTPサーバ
運用管理ポータル
［通信・スレッド制御に関する設定］画面の「Webクライアントとの接続設定」の「通信タイムアウト」の「リクエスト受信」

［通信・スレッド制御に関する設定］画面の「Webクライアントとの接続設定」の［通信タイムアウト］の［リクエスト送信］

ファイル編集
usrconf.propertiesのwebserver.connector.inprocess_http.receive_timeoutキー

usrconf.propertiesのwebserver.connector.inprocess_http.send_timeoutキー

注※　Hitachi Web Serverの定義ファイルであるhttpd.confを編集して設定します。

(2)　リダイレクタ側で設定するWebコンテナへのデータ送信のタイムアウト

リダイレクタ側で設定するタイムアウトのチューニングパラメタについて，次の表に示します。なお，これらのチューニングパラメタは，Webサーバ連携の場合だけ指定できます。

表C-9　リダイレクタ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

Webサーバの種類 | 設定方法 | 設定個所
Hitachi Web Server | 運用管理ポータル | ［リダイレクタの設定］画面の「オプション」の「リクエスト送信コネクション確立タイムアウト時間」
ファイル編集 | mod_jk.confのJkConnectTimeoutパラメタ
Microsoft IIS | ファイル編集 | isapi_redirect.confのconnect_timeoutキー
Hitachi Web Server | 運用管理ポータル | ［リダイレクタの設定］画面の「オプション」の「リクエスト送信タイムアウト時間」
ファイル編集 | mod_jk.confのJkSendTimeoutパラメタ
Microsoft IIS | ファイル編集 | isapi_redirect.confのsend_timeoutキー

(3)　リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト

リダイレクタのワーカ定義単位で設定します。リダイレクタ側で設定するタイムアウトのチューニングパラメタの設定方法と設定個所を次の表に示します。

表C-10　リダイレクタ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

設定方法 | 設定個所
運用管理ポータル | ［ワーカの設定］画面の「リダイレクタで再利用するワーカとのコネクション数の定義」の「通信タイムアウト」
ファイル編集 | workers.propertiesのworker.<ワーカ名>.receive_timeoutキー

Webサーバ連携の場合だけ指定できます。

(4)　Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタを次の表に示します。

表C-11　Webコンテナ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

設定方法 | 設定個所
運用管理ポータル | ［Webコンテナの設定］画面の「Webサーバとの接続」の「タイムアウト時間」
ファイル編集 | usrconf.propertiesのwebserver.connector.ajp13.receive_timeoutキー

Webサーバ連携の場合だけ指定できます。

(5)　Webコンテナ側で設定するリダイレクタへのデータ受信のタイムアウト

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタを次の表に示します。

表C-12　Webコンテナ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

設定方法 | 設定個所
運用管理ポータル | ［Webコンテナの設定］画面の「Webサーバとの接続」の「レスポンス送信タイムアウト時間」
ファイル編集 | usrconf.propertiesのwebserver.connector.ajp13.send_timeoutキー

Webサーバ連携の場合だけ指定できます。

(6)　EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト

J2EEサーバ単位，EJBクライアントアプリケーション単位またはAPIによる呼び出し単位に設定します。

EJBクライアント側で設定するタイムアウトのチューニングパラメタ（RMI-IIOP通信によるリモート呼び出し）を次の表に示します。

表C-13　EJBクライアント側で設定するタイムアウトのチューニングパラメタ（RMI-IIOP通信によるリモート呼び出し）（推奨手順以外の方法）

単位 | 設定方法 | 設定個所
J2EEサーバ単位 | 運用管理ポータル | ［EJBコンテナの設定］画面の「サーバとの接続」の「タイムアウト時間」
ファイル編集 | usrconf.propertiesのejbserver.rmi.request.timeoutキー

EJBクライアントアプリケーション単位の設定，およびAPI単位の設定については，推奨手順の場合と違いがありません。

EJBクライアント側で設定するタイムアウトのチューニングパラメタ（ネーミングサービス呼び出し）を次の表に示します。

表C-14　EJBクライアント側で設定するタイムアウトのチューニングパラメタ（ネーミングサービス呼び出し）（推奨手順以外の方法）

単位 | 設定方法 | 設定個所
J2EEサーバ単位 | 運用管理ポータル | ［ネーミングの設定］画面の「利用するネーミングサービスの設定」の「タイムアウト時間」
ファイル編集 | usrconf.propertiesのejbserver.jndi.request.timeoutキー

EJBクライアントアプリケーション単位の設定については，推奨手順の場合と違いがありません。

(7)　EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト

J2EEサーバ単位，EJBクライアントアプリケーション単位またはAPIによる呼び出し単位に設定します。

なお，このタイムアウトの設定値には，「(6) EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト」で指定した設定値と同じ値が引き継がれます。

(8)　EJBコンテナ側で設定するデータベースのトランザクションタイムアウト（DB Connectorを使用した場合）

J2EEサーバ単位，Enterprise Bean，インタフェース，メソッド単位（CMTの場合），またはAPIによる呼び出し単位（BMTの場合）に設定します。

トランザクションタイムアウトのチューニングパラメタを次の表に示します。

表C-15　トランザクションタイムアウトのチューニングパラメタ（推奨手順以外の方法）

単位 | 設定方法 | 設定個所
J2EEサーバ単位 | 運用管理ポータル | ［トランザクションの設定］画面の「トランザクションに関する設定 」の「タイムアウト時間」
ファイル編集 | usrconf.propertiesのejbserver.jta.TransactionManager.defaultTimeOutキー

Enterprise Bean，インタフェース，メソッド単位（CMTの場合）およびAPI単位（BMTの場合）のチューニングパラメタについては，推奨手順の場合と違いがありません。

(9)　データベースのタイムアウト

データベースのタイムアウトを設定するチューニングパラメタについては，推奨手順の場合と違いがありません。

付録C.5　Webアプリケーションの動作を最適化するためのチューニングパラメタ（推奨手順以外の場合）

ここでは，Webアプリケーションの動作を最適化するために使用するチューニングパラメタの設定個所についてまとめて示します。

＜この項の構成＞

(1)　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

(2)　静的コンテンツをキャッシュするためのチューニングパラメタ

(3)　リダイレクタによってリクエストを振り分けるためのチューニングパラメタ

(1)　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

静的コンテンツとWebアプリケーションの配置の切り分けは，Webサーバの動作を定義するファイルのパラメタとして指定します。設定個所，ファイルおよびパラメタは，使用するWebサーバの種類によって異なります。

Webサーバの種類ごとの設定方法および設定個所を次に示します。

表C-16　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ（推奨手順以外の場合）

使用するWebサーバ
Webサーバの種類
設定方法
設定個所

Webサーバ連携
（リダイレクタモジュールを使用した切り分け）
Hitachi Web Server
運用管理ポータル
［論理Webサーバの定義］画面の「マッピング定義」

ファイル編集
mod_jk.confのマッピング定義（JkMountパラメタ）

Microsoft IIS
ファイル編集
uriworkermap.properties

インプロセスHTTPサーバ
（リバースプロキシモジュールを使用した切り分け）
Hitachi Web Server
ファイル編集
httpsd.confのProxyPassディレクティブ※

注※　httpsd.confの詳細については，マニュアル「Hitachi Web Server」を参照してください。

(2)　静的コンテンツをキャッシュするためのチューニングパラメタ

静的コンテンツをキャッシュするためのチューニングパラメタについて説明します。これらのチューニングパラメタは，Webコンテナ単位またはWebアプリケーション単位に設定します。

Webコンテナ単位に設定するチューニングパラメタの設定方法および設定個所について，次の表に示します。

表C-17　静的コンテンツをキャッシュするためのチューニングパラメタ（Webコンテナ単位で設定する項目）（推奨手順以外の場合）

設定項目 | 設定方法 | 設定個所
静的コンテンツのキャッシュを使用するかどうかの選択 | 運用管理ポータル | ［Webコンテナの設定］画面の「Webコンテナの設定」の「静的コンテンツキャッシュ機能」
ファイル編集 | usrconf.propertiesのwebserver.static_content.cache.enabledキー
Webアプリケーション単位のメモリサイズの上限値の設定 | 運用管理ポータル | ［Webコンテナの設定］画面の「Webコンテナの設定」の「キャッシュサイズ」
ファイル編集 | usrconf.propertiesのwebserver.static_content.cache.sizeキー
キャッシュする静的コンテンツのファイルサイズの上限値の設定 | 運用管理ポータル | ［Webコンテナの設定］画面の「Webコンテナの設定」の「ファイルサイズ」
ファイル編集 | usrconf.propertiesのwebserver.static_content.cache.filesize.thresholdキー

Webアプリケーション単位に設定するチューニングパラメタについては，推奨手順の場合と違いがありません。

(3)　リダイレクタによってリクエストを振り分けるためのチューニングパラメタ

リダイレクタによってリクエストを振り分けるためのチューニングパラメタは，Webサーバの動作を定義するファイルのパラメタとして指定します。設定個所，ファイルおよびパラメタは，使用するWebサーバごとに異なります。

なお，この定義は，Webサーバ連携の場合だけできます。インプロセスHTTPサーバを使用している場合は定義できません。

Webサーバごとの設定方法および設定個所を次に示します。

表C-18　リダイレクタによってリクエストを振り分けるためのチューニングパラメタ（推奨手順以外の場合）

Webサーバの種類 | 設定方法 | 設定個所
Hitachi Web Server | 運用管理ポータル | ［論理Webサーバの定義］画面の「マッピング定義」
ファイル編集 | mod_jk.confのマッピング定義（JkMountパラメタ）
Microsoft IIS | ファイル編集 | uriworkermap.properties

付録C.6　CTMの動作を最適化するチューニングパラメタ（推奨手順以外の方法）

ここでは，CTMの動作の最適化で使用するチューニングパラメタの設定個所についてまとめて示します。

＜この項の構成＞

(1)　CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔を設定するチューニングパラメタ

(2)　負荷状況監視間隔を設定するチューニングパラメタ

(3)　CTMデーモンのタイムアウト閉塞を設定するチューニングパラメタ

(4)　CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタ

(1)　CTMドメインマネジャおよびCTMデーモンの稼働状態の監視間隔を設定するチューニングパラメタ

CTMドメインマネジャの稼働状態の監視間隔をチューニングするパラメタを次に示します。

監視間隔は，送信間隔×係数の値になります。

表C-19　CTMドメインマネジャの稼働状態の監視間隔をチューニングするパラメタ（推奨手順以外の方法）

対象 | 設定項目 | 設定方法 | 設定個所
同じネットワークセグメント内にあるCTMドメインマネジャ | 送信間隔 | 運用管理ポータル | 論理CTMドメインマネジャの［ネットワーク設定］画面の「CTMドメイン構成情報の送信間隔」
コマンド実行 | ctmdmstartコマンドの引数「-CTMSendInterval」
係数 | 運用管理ポータル | 論理CTMドメインマネジャの［ネットワーク設定］画面の「ドメインマネジャ生存判定間隔係数」
コマンド実行 | ctmdmstartコマンドの引数「-CTMAliveCheckCount」
異なるネットワークセグメントにあるCTMドメインマネジャ | 送信間隔 | 運用管理ポータル | 論理CTMドメインマネジャの［ネットワーク設定］画面の「指定ホストへの構成情報の送信間隔」
コマンド実行 | ctmdmstartコマンドの引数「-CTMSendHostInterval」
係数 | 運用管理ポータル | 論理CTMドメインマネジャの［ネットワーク設定］画面の「ドメインマネジャ生存判定間隔係数」
コマンド実行 | ctmdmstartコマンドの引数「-CTMAliveCheckCount」

CTMデーモンの稼働状態の監視間隔をチューニングするパラメタを次に示します。

表C-20　CTMデーモンの稼働状態の監視間隔をチューニングするパラメタ（推奨手順以外の方法）

設定項目 | 設定方法 | 設定個所
CTMデーモン間転送時のタイムアウト | 運用管理ポータル | 論理CTMの［CTM間通信の設定］画面の「リクエスト転送時のタイムアウト時間」
コマンド実行 | ctmstartコマンドの引数「-CTMDCSendTimeOut」

(2)　負荷状況監視間隔を設定するチューニングパラメタ

負荷状況監視間隔のチューニングパラメタを次に示します。

表C-21　負荷情報監視間隔のチューニングパラメタ（推奨手順以外の方法）

設定項目 | 設定方法 | 設定個所
CTMデーモン間転送時のタイムアウト | 運用管理ポータル | 論理CTMの［スケジューリングの設定］画面の「負荷情報監視間隔」
コマンド実行 | ctmstartコマンドの引数「-CTMLoadCheckInterval」

(3)　CTMデーモンのタイムアウト閉塞を設定するチューニングパラメタ

タイムアウト閉塞は，タイムアウト発生回数と監視間隔を設定しておくことによって，実行されます。

CTMデーモンのタイムアウト閉塞のチューニングパラメタを次に示します。

表C-22　CTMデーモンのタイムアウト閉塞のチューニングパラメタ（推奨手順以外の方法）

設定項目 | 設定方法 | 設定個所
タイムアウト発生回数 | 運用管理ポータル | 論理CTMの［スケジューリングの設定］画面の「タイムアウト閉塞」の「自動閉塞するタイムアウト発生回数」
コマンド実行 | ctmstartコマンドの引数「-CTMWatchRequest」（一つ目のオプション引数）
監視時間間隔 | 運用管理ポータル | 論理CTMの［スケジューリングの設定］画面の「タイムアウト閉塞」の「監視時間間隔」
コマンド実行 | ctmstartコマンドの引数「-CTMWatchRequest」（二つ目のオプション引数）

(4)　CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタ

CTMで振り分けるリクエストの優先順位の設定は，EJBクライアントアプリケーションの場合と，J2EEサーバの場合で異なります。また，J2EEサーバの場合，システムの構築方法によって設定個所が異なります。CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタを次に示します。

表C-23　CTMで振り分けるリクエストの優先順位を設定するチューニングパラメタ（推奨手順以外の方法）

設定単位 | 設定方法 | 設定個所
J2EEサーバ | 運用管理ポータル | 論理J2EEサーバの［EJBコンテナの設定］画面の「CTMの設定」の「リクエストの優先順位」
ファイル編集 | usrconf.propertiesのejbserver.client.ctm.RequestPriorityキー

EJBクライアントアプリケーション単位のチューニングパラメタについては，推奨手順の場合と違いがありません。

付録C.7　Persistent Connectionについてのチューニングパラメタ（推奨手順以外の方法）

Persistent Connectionについてのチューニングパラメタについて説明します。

この項目は，Webフロントシステムの場合で，インプロセスHTTPサーバを使用するときにチューニングを検討してください。

表C-24　Persistent Connectionについて設定するチューニングパラメタ（推奨手順以外の方法）

設定項目 | 設定方法 | 設定個所
Persistent Connection数の上限値 | 運用管理ポータル | ［通信・スレッド制御に関する設定］画面の「Persistentコネクション」の「上限値」
usrconf.properties | webserver.connector.inprocess_http.persistent_connection.max_connectionsキー
リクエスト処理回数の上限値 | 運用管理ポータル | ［通信・スレッド制御に関する設定］画面の「Persistentコネクション」の「リクエスト処理回数の上限値」
usrconf.properties | webserver.connector.inprocess_http.persistent_connection.max_requestsキー
タイムアウト | 運用管理ポータル | ［通信・スレッド制御に関する設定］画面の「Persistentコネクション」の「タイムアウト」
usrconf.properties | webserver.connector.inprocess_http.persistent_connection.timeoutキー

付録C.8　バッチサーバのフルガーベージコレクションを発生させるしきい値を設定するためのチューニングパラメタ（推奨手順以外の方法）

バッチサーバのフルガーベージコレクションを実行するしきい値を設定するために使用するチューニングパラメタについて説明します。

この項目は，バッチサーバで，フルガーベージコレクションの実行を制御するときにチューニングを検討してください。

表C-25　バッチサーバのフルガーベージコレクションを実行するしきい値を設定するチューニングパラメタ

設定項目 | 設定方法 | 設定個所
しきい値 | 運用管理ポータル | ［コンテナの設定］画面の「拡張パラメタ」
usrconf.properties | ejbserver.batch.gc.watch.thresholdキー

付録D　（3020-3-M04-61）の変更内容

3020-3-M04-61の変更内容を表D-1に示します。

表D-1　（3020-3-M04-61）の変更内容

#
変更個所
追加・変更内容

1
3.18
表 3-5　Cosminexusが使用するTCP/UDPのポート番号の指定個所
［訂正前］
[図データ]
［訂正後］
[図データ]

2
3.18
表 3-6　TCP/UDPのポート番号を運用管理ポータルまたはファイル編集によって設定する場合の設定個所
［訂正前］
[図データ]
［訂正後］
[図データ]

付録E　用語解説

Application Server，uCosminexus Client，Web Redirector，およびuCosminexus Operatorで使用する用語について説明します。

（数字）

1.4モード

サーバの動作モードです。J2EE 1.4の機能を使用できます。データベースを含む複数のリソースのトランザクション管理ができます。

1:1系切り替えシステム

実行系のアプリケーションサーバと待機系のアプリケーションサーバが1:1で対応しているシステムです。実行系のアプリケーションサーバに障害が発生すると，待機系のアプリケーションサーバで処理を引き継ぎます。

（英字）

Application Server

Cosminexusの実行環境を構築する基盤製品です。Application Server Standardと，Application Server Enterpriseの総称です。

BJEX

uCosminexus Batch Job Execution Serverのことです。

BMP（Bean-Managed Persistence）

Enterprise Beanのビジネスメソッド内でデータの永続化を管理するモデルです。

BMT（Bean-Managed Transaction）

Enterprise Beanでトランザクションを管理するモデルです。Session BeanおよびMessage-driven Beanが対象になります。Entity Beanは対象外です。

CMP（Container-Managed Persistence）

EJBコンテナがデータの永続化を管理するモデルです。

CMT（Container-Managed Transaction）

EJBコンテナがトランザクションを管理するモデルです。Session Bean，Entity BeanおよびMessage-driven Beanが対象になります。

Component Container管理者

スーパーユーザ以外の，J2EEサーバやバッチサーバのセットアップ，J2EEサーバやバッチサーバの起動・停止などを実施できるユーザを指します。Component Container管理者はUNIXの場合に設定できます。

Cookieスイッチング機能

負荷分散機で提供しているサーバスイッチング機能の一つです。Cookieスイッチング機能を使用すると，クライアントからのリクエストパケット内のCookie情報に基づいて，同じサーバにセッションをリダイレクトします。

CORBAネーミングサービス

CORBAの仕様に準拠した，リモートオブジェクトの格納場所を管理するためのネーミングサービスです。Application Serverの構成ソフトウェアであるCosminexus TPBrokerによって提供される機能です。

Cosminexus

アプリケーションサーバを中核とした，性能および信頼性の高いアプリケーションを実行および開発するためのシステム構築基盤製品です。

Cosminexus Component Container

サーバ・サイドの業務処理プログラム（ビジネスロジック）をコンポーネントとして実行するための構成ソフトウェアです。また，Cosminexusシステムの運用管理をするためのManagement Server，統合ユーザ管理，snapshotログ収集などの機能も提供しています。

Cosminexus Component Transaction Monitor

クライアントからのリクエストのスケジューリングを実現するための構成ソフトウェアです。

Cosminexus Operator Plug-in

実行環境を運用管理操作するための構成ソフトウェアです。Server Plug-inとHCSC-Managerを提供しています。HCSC-Managerとは，Cosminexusサービスプラットフォームの運用環境で利用する運用管理機能です。なお，HCSC-Managerについては，マニュアル「Cosminexus　サービスプラットフォーム　システム構築・運用ガイド」を参照してください。

Cosminexus Performance Tracer

リクエストが処理されるときに，決められたポイントごとに各機能が出力する性能解析情報をファイルに出力するための構成ソフトウェアです。

Cosminexus Reliable Messaging

Cosminexus システム上のJ2EEアプリケーションがメッセージを使用して非同期に通信するためのミドルウェアです。JMSインタフェースでのメッセージ通信機能をJ2EEアプリケーションに提供します。

Cosminexusシステム

Application Serverを実行基盤として構築されているシステムのことです。

Cosminexus標準ログインモジュール

統合ユーザ管理のユーザ認証処理で使用するログインモジュールです。javax.security.auth.spiに含まれるLoginModuleインタフェースの実装クラスです。

次のログインモジュールがあります。

WebPasswordLoginModule
パスワードを使用してユーザを認証します。

WebCertificateLoginModule
クライアント証明書を使用してユーザを認証します。

WebPasswordLDAPLoginModule
LDAPディレクトリサーバの認証機能を使用してユーザを認証します。

WebPasswordJDBCLoginModule
RDBに格納された情報を使用してユーザを認証します。

DelegationLoginModule
カスタムログインモジュールを呼び出します。

WebSSOLoginModule
シングルサインオンをするときに，ほかのログインモジュールを呼び出します。

CTM

Cosminexus Component Transaction Monitorのことです。リクエストのスケジューリングをするための構成ソフトウェアです。

CTMデーモン

クライアントからのリクエストを制御するスケジュールキューを管理するプロセスです。リクエストのスケジューリングを実現する，スケジューラとして機能します。

Management Serverを利用している場合，CTMデーモンは論理サーバとして扱えます。

CTMドメイン

複数のCTMデーモンで構成される，情報共有と負荷分散の対象になる範囲です。CTMデーモンはCTMドメイン内で，それぞれに登録された業務処理プログラムの情報やスケジュールキューの負荷情報を交換してリクエストを振り分けます。

CTMドメインマネジャ

CTMドメインを管理するプロセスです。ホスト内のCTMデーモンの情報を，CTMドメイン内のほかのCTMドメインマネジャに配布します。

Management Serverを利用している場合，CTMドメインマネジャは論理サーバとして扱えます。

CTMレギュレータ

EJBクライアントからCTMデーモンに集中するリクエストを，分散集約するためのプロセスです。TPBrokerクライアント（CORBAクライアント）からJ2EEサーバ内で動作しているEJBアプリケーションを直接呼び出しできるゲートウェイ機能も提供します。

DB Connector

データベースに接続するためのリソースアダプタです。

DD

アプリケーションを運用環境に配置するときの定義情報を記述したものです。EJB用，Webアプリケーション用，Enterpriseアプリケーション用などがSun Microsystems, Inc.からの仕様で規定されています。

Dependency Injection

EJBやインターセプタクラスのフィールドやsetterメソッドに，@EJBや@Resourceアノテーションを指定することで，EJBやリソースへの参照をEJBコンテナが自動的にセットする機能です。Dependency Injectionを使用すると，EJBやリソースへの参照をJNDIを使用してルックアップする必要がなくなります。

DIターゲット

Dependency Injection機能を使用して参照を注入する対象のことです。DIターゲット名と名前が一致するフィールド，またはDIターゲット名をプロパティとして持つsetterメソッドに対して，Dependency Injectionが実行されます。

DTD

XMLで使用するタグの属性や階層構造や出現順序などを定義したものです。

EARファイル

J2EEアプリケーションを構成する複数のEJB-JARファイル，WARファイル，およびDDをEARファイル形式でパッケージ化したものです。

EIS

データベースやトランザクションサーバなど，企業内に構築されているバックエンドシステムです。

EJB（Enterprise JavaBeans）

業務ロジックをプログラムとして記述したビジネスロジック，および永続的データを格納するオブジェクトであるエンティティをJavaコンポーネント化したものです。Sun Microsystems, Inc.からEJB仕様が公開されています。

EJB-JARファイル

Enterprise Bean，DDなどをJARファイル形式に圧縮したものです。

EJBクライアント

J2EEサーバ上で開始されているEnterprise Beanを呼び出すクライアントプログラムです。次の3種類があります。

EJBクライアントアプリケーション

サーブレットまたはJSPなどのWebアプリケーション

ほかのEnterprise Bean

EJBクライアントアプリケーション

Enterprise Beanを呼び出すJavaアプリケーションです。

EJBコンテナ

Enterprise Beanを制御すると同時に，通信，トランザクション管理などのシステムレベルのサービスを提供する実行環境です。Enterprise Beanの実体は，EJBコンテナの中で実行されます。

EJBタイマ

EJBコンテナのTimer Serviceの機能を利用して，タイムアウト時間を管理するタイマです。指定された時刻または間隔で，タイムアウトメソッドをコールバックし，イベントを実行します。

Enterprise Bean

ビジネスロジックをEJBアーキテクチャに従って作成したものです。業務処理プログラムに該当します。

Entity Bean

永続化されたデータそのものを表すBeanです。Entity Beanは，さらにCMP Entity BeanとBMP Entity Beanに分類されます。

HAモニタ

クラスタソフトウェアの一つです。

システムを監視し，障害発生時などにシステムの切り替えを実行するプログラムです。HAモニタと連携することで，Cosminexusシステムの信頼性や稼働率を向上できます。AIX，HP-UXまたはLinuxを使用しているときに連携できます。

HAモニタと連携することで，1：1系切り替えシステム，相互系切り替えシステム，N：1リカバリシステムが実現できます。

Inbound

Connector 1.5仕様で定められたJ2EEサーバとリソースアダプタ間の通信モデルの一つです。リソースアダプタからJ2EEサーバにアクセスする通信モデルです。

J2EE

JavaTM 2 Platform, Enterprise Editionの略です。Sun Microsystems, Inc.からJ2EE仕様が公開されています。

J2EEアプリケーション

JSP，サーブレット，EnterpriseBeanなどで構成されるアプリケーションです。Cosminexusで扱うJ2EEアプリケーションの形式には，EARファイル形式でパッケージ化されたアーカイブ形式のアプリケーションと，アーカイブ化しない展開ディレクトリ形式のアプリケーションがあります。EARファイル形式でパッケージ化されたアプリケーションの場合，複数のEJB-JARファイル，複数のWARファイル，および一つのDDから構成されます。

J2EEアプリケーション実行時間の監視機能

EJBおよびWebアプリケーションのリクエスト実行時間を監視する機能です。実行時間監視中に障害を検知すると，メソッドタイムアウト機能およびメソッドキャンセル機能が動作します。

J2EEアプリケーションの強制停止

J2EEアプリケーションの停止での強制停止とは，J2EEアプリケーションで処理中のリクエストがある場合でも，強制的に処理を中止する方法です。

J2EEアプリケーションの通常停止

J2EEアプリケーションの停止での通常停止とは，WebアプリケーションやEJBの停止処理を順番に実施して，J2EEアプリケーションを安全に停止させる方法です。

J2EEコンテナ

J2EEアプリケーションを実行するためのサーバ基盤です。

J2EEコンポーネントへ各種APIを提供する，Webコンテナ，EJBコンテナから構成されます。

J2EEコンポーネント

サーブレット，JSP，Enterprise Beanなどのユーザアプリケーションプログラムのことです。

J2EEサーバ

J2EEコンテナを生成，実行する環境です。

J2EEサーバモード

J2EEサーバの動作モードの一つです。このモードの場合，J2EEコンテナ上で動作するアプリケーションから，J2EE関連のAPIを利用できます。なお，J2EEサーバモードには，1.4モードと，互換用の動作モードであるベーシックモードがあります。

J2EEサービス

J2EEコンテナの部品機能として利用されます。J2EEコンポーネントにJNDI，JDBC，JTA，RMI-IIOPおよびJavaMailのAPIを提供します。

J2EEリソース

サーバから利用できるリソースです。J2EEサーバの場合，データベース，OpenTP1，SMTPサーバなどを利用できます。また，バッチサーバの場合，データベースを利用できます。

J2EEリソースアダプタ

J2EEサーバに共有スタンドアロンモジュールとして配備したリソースアダプタのことです。

jaas.conf（JAASのコンフィグレーションファイル）

ユーザ認証ライブラリおよびシングルサインオンライブラリの機能を使用するために必要なJAAS認証用の設定ファイルです。

Java

1991年にSun Microsystems, Inc.内の研究グループが開発したインタプリタ言語を基に，C++をより移植性と信頼性が高くなるように改良した言語です。Webの普及によってブラウザに応用されています。

JavaロギングAPI

J2SEで提供されているコアロギング機能のクラスおよびインタフェースです。Application Serverでは，JavaロギングAPIを使用してユーザログを日立トレース共通ライブラリ形式で出力する機能を提供しています。

JCAコンテナ

J2EEサーバやバッチサーバと，EISを接続するためのシステムレベルのプラグイン機能を提供するコンテナです。

JDBC（Java Database Connectivity）

Javaのプログラムでデータベースを利用するためのAPIです。

JavaSoftが1996年前半に仕様を公開しました。Javaプログラムから，JDBC APIを経由して「JDBCドライバ」を呼び出し，ドライバがデータベース・サーバへの接続機能を提供します。

JNDI（Java Naming and Directory Interface）

Javaプラットフォーム用の標準拡張機能で，Java テクノロジに対応したアプリケーションに，企業内の複数のネーミングおよびディレクトリサービスへの統一したインタフェースを提供します。

Application Serverでは，Cosminexus TPBrokerのCORBAネーミングサービスを利用して，JNDIの機能を実現しています。

JNDI名前空間

JNDIによってアクセスする名前情報が管理されている名前空間です。Application Serverでは，J2EEアプリケーションをデプロイした時に，EJBオブジェクトリファレンスがJNDI名前空間の名前にバインドされます。

Application Serverで使用するJNDI名前空間の名前には，別名を付けることができます。これによって，Enterprise BeanやJ2EEリソースを別名でルックアップできるようになります。

JP1

日立の統合システム運用管理ソフトウェアです。

JP1/AJS2

日々の業務の中から，定型的・定期的なものを自動化して，システム運用に掛かるコストを削減し，少ない人員で確実な運用を実現するめたのプログラム群です。JP1/AJS2 - Manager，JP1/AJS2 - Agent，JP1/AJS2 - Viewの製品で構成されます。

JP1/AJS2 - SO

一つ一つの運用手順を蓄積し，ライブラリとして統合する運用管理の基盤機能を提供するプログラムです。立案したシナリオに合う運用手順をライブラリから選択し，運用環境に合わせてカスタマイズすることで，業務運用の設計を容易に，かつ高品質で実現することができます。

JP1/Cm2/NC - Manager

負荷分散機の設定をしたり，負荷分散機の制御をしたりするためのプログラムプロダクトです。

JP1/Cm2/NC - Manager for Cosminexus

Cosminexusと連携して，負荷分散機を制御するためのプログラムプロダクトです。Management Serverから負荷分散機を動的に制御できます。

JP1/IM

企業情報システム全体を統合管理する基盤になるプログラム群です。JP1 Version 8の場合は，JP1/IM - Manager，JP1/IM - View，およびJP1/IM - CMの三つの製品で構成されます。JP1 Version 7iの場合は，JP1/IM - Central ConsoleおよびJP1/IM - Central Scope，JP1/IM - View，およびJP1/IM - CMの四つの製品で構成されます。

JP1/IM - CM

業務システムを構成する各種のリソース（サーバ，ストレージなど）やシステム構成に関する情報を集約して管理するためのプログラムです。管理対象のリソースを任意にグルーピングできるため，システムの監視（性能，障害）や運用（設定配布，構成変更）の際に，グループ単位で管理したり操作したりできます。

JP1/NETM/Audit

システム内の製品が出力した監査ログを自動収集して，一括管理するためのプログラムプロダクトです。JP1/Baseと連携して，Cosminexusのアプリケーションサーバ，運用管理サーバ，連携する日立オープンミドルウェア製品などが出力した監査ログを監査ログ管理サーバで自動収集できます。また，収集した監査ログを，監査ログ管理サーバのデータベースで一元管理できます。

JP1/SC/DPM

デプロイメント操作を実行するためのソフトウェアです。ディスクイメージをバックアップしたり，OSやアプリケーションのインストールを一括して実施したりできます。

JP1イベント

システム内で何らかの事象が発生した際に，その事象に関してJP1/Baseに通知される情報です。

JP1ジョブ運用管理サーバ

JP1/AJS2と連携してシステムの自動運転をする場合に，JP1/AJS2 - Managerを配置するホストのことです。

JP1統合運用管理サーバ

JP1/IMと連携してシステムの集中監視をする場合に，JP1/IM - Manager（JP1 Version 8の場合）を配置するホストのことです。JP1 Version 7iの場合は，JP1/IM - Central ConsoleおよびJP1/IM - Central Scopeを配置するホストのことです。

JSP（JavaServer Pages）

Webページを作成するHTMLの中にJSP固有のタグを埋め込んでEnterprise Beanを呼び出すことや，サーブレットから値を受け取ることができます。また，簡単なJava言語を直接記述することもできます。

JSP EL

JSP 2.0で定義された式言語です。JSPファイルやタグファイル内に

JavaBeansの属性へのアクセスなどを記述できます。また，APIも提供されています。

JSPコンパイル結果

JSPファイルおよびタグファイルのコンパイルで生成されるJavaソースファイルやクラスファイルです。

JSP事前コンパイル

Webアプリケーションに含まれるJSPファイルおよびタグファイルをデプロイ前にコンパイルし，Javaソースファイルやクラスファイルを生成する機能です。JSP事前コンパイル機能を使用してあらかじめJavaソースファイルやクラスファイルを生成しておくと，Webアプリケーション実行時の初回リクエストでのレスポンスタイムを短縮できます。

JSPタグライブラリ

JSPタグを作成するためのもので，JSP仕様で規定されています。Cosminexusでは，統合ユーザ管理をする場合に，Cosminexus標準ログインモジュールを使用してユーザ認証をするためのJSPタグライブラリを提供しています。

Management Server

運用管理ドメインを構成するサーバプログラムです。運用管理ドメイン単位に一つ配置します。

Management Serverは運用管理ドメイン内の各ホストに配置した運用管理エージェントに指示を出して，運用管理ドメイン全体の運用管理を実行します。

Managementアクション

Managementイベント発生時に自動的に実行される処理です。Managementアクションとしてどのような処理をするかは，Management Server側であらかじめ定義しておきます。

Managementイベント

Management Serverを利用して運用している場合に，運用管理ドメイン内の論理サーバで発生した事象に応じてManagement Serverで発行するイベントです。論理サーバでメッセージが出力されたタイミングで発行できます。例えば，リソース監視中に設定したしきい値を超えた場合などに発行できます。

Managementイベントに対してManagementアクションを定義しておくと，発生した事象に応じたアクションを自動的に実行できます。

Message-driven Bean

JMSと連携するメッセージ駆動タイプのBeanです。EJBコンテナはJMSのDestinationからのJMSメッセージ受信を契機にBeanを起動します。

MIBオブジェクト

SNMPプロトコルで使用するオブジェクトです。

MIBファイル

SNMPプロトコルで使うオブジェクトの構造体を記述したテキストファイルです。すべてのオブジェクト（情報）は，オブジェクトIDで一意に決まります。

Microsoft Cluster Service

クラスタソフトウェアの一つです。

システムを監視し，障害発生時などにシステムの切り替えを実行するプログラムです。Microsoft Cluster Serviceと連携することで，Cosminexusシステムの信頼性や稼働率を向上できます。Windows Server 2003で使用できます。

Microsoft Cluster Serviceと連携したシステムでは，1：1系切り替えシステム，相互系切り替えシステム，N：1リカバリシステムが実現できます。

N:1リカバリシステム

クラスタ構成の実行系のアプリケーションサーバに対して，1台のリカバリ専用サーバを待機系として配置したシステムです。リカバリ専用サーバでは，障害が発生した実行系のアプリケーションサーバのトランザクションの決着をします。

Oracle RAC

Oracleデータベースのクラスタ機能です。Cosminexusでは，Oracle RAC機能を使用してクラスタ化されたOracleデータベースに接続できます。

ORBゲートウェイ

CORBAクライアントからJ2EEサーバ内で動作しているEJBアプリケーションを直接呼び出しできるゲートウェイ機能です。CTMレギュレータプロセスによって提供されます。

OTMゲートウェイ

TPBroker OTMのクライアントからJ2EEサーバ内で動作しているEJBアプリケーションを直接呼び出しできるゲートウェイ機能です。OTMゲートウェイプロセスによって提供されます。

OTS（Object Transaction Service）

1.4モードで，TPBroker OTSによる分散トランザクションを使用するために必要なサービスです。

Outbound

Connector 1.5仕様で定められたJ2EEサーバとリソースアダプタ間の通信モデルの一つです。J2EEサーバからリソースアダプタにアクセスする通信モデルです。

PRFデーモン

バッファに出力されたPRFトレースをPRFトレースファイルに出力するIOプロセスです。

Management Serverでは，論理サーバとして扱えます。Management Serverで扱う場合は，パフォーマンストレーサといいます。

PRFトレース

リクエストを処理する時にCosminexusシステムの各機能で出力されたトレース情報です。バッファに出力されて，一定量たまったらPRFトレースファイルに出力されます。

PRFトレース出力ライブラリ

Cosminexusシステムの各機能に組み込まれているライブラリです。機能レイヤごとのPRFトレースをバッファに出力する機能を提供しています。

PRFトレース取得レベル

PRFトレースを取得するレベルです。「標準レベル」，「詳細レベル」，「保守レベル」があります。「詳細レベル」または「保守レベル」を指定した場合，「標準レベル」に比べてトレース取得ポイントが多くなります。

PRFトレースファイル

PRFトレースを出力したバイナリ形式のファイルです。性能解析トレースファイル（CSV形式）に変換する基になるファイルです。

RMI-IIOP

JavaRMI とJavaIDLを統合したAPIです。

SecurityManager

セキュリティポリシーに基づいたWebコンテナの実行時保護をするJ2EEサーバの機能です。

Server Plug-in

Eclipseのプラグインです。Server Plug-inを使用すると次の操作ができます。

リソースアダプタのプロパティを設定したり，設定したリソースアダプタをJ2EEサーバやバッチサーバにデプロイしたりする。

J2EEアプリケーションのプロパティを設定したり，設定したJ2EEアプリケーションをJ2EEサーバにインポートしたりする。

論理サーバを起動・停止する。

Session Bean

主に業務処理を実行するためのBeanです。Session Beanは，クライアントを一つだけ持つことができます。クライアントが終了すると，対応するSession Bean も終了します。クライアントとのセッションの間だけ動作するため，一時的であり，非永続的なBeanです。Session Beanは，Stateful Session Beanと，Stateless Session Beanに分類されます。

SFOサーバ

システム内のJ2EEサーバのJ2EEアプリケーション内で生成されたグローバルセッション情報を管理するJ2EEサーバです。セッションフェイルオーバ機能を使用するときにシステム構成に含めます。

SFOサーバアプリケーション

SFOサーバ上で稼働するJ2EEアプリケーションを，SFOサーバアプリケーションといいます。SFOサーバアプリケーションはEJBで実装されています。なお，SFOサーバアプリケーションはCosminexusで提供しています。

Smart Composer機能

Cosminexusを使用してアプリケーションサーバを構築する場合に，一般的な3階層モデルのアプリケーションサーバのシステムを，簡単に構築および運用できるよう支援する機能です。システム全体に対して，システムの設定，およびJ2EEアプリケーションやリソースアダプタのデプロイを一括で実行できるので，簡単，迅速にシステム構築ができます。

構築したシステムを一括で起動したり，一括でシステムの設定を変更したりなど，運用機能についてもサポートしています。

snapshotログ

ある時点でのJ2EEサーバやバッチサーバの状態が出力されたログファイルです。

トラブルシューティングに必要な情報が自動的に出力されます。

Management Serverを利用している場合は，次のタイミングで出力されます。

論理サーバに異常が発生した時

運用管理ポータルまたは運用管理コマンドによってsnapshotログの収集を要求した時

Management Serverを利用していない場合は，コマンド（snapshotlog）を実行した時に出力されます。このコマンドで出力できるのは，そのコマンドを実行したホストの情報だけです。

SNMP連携用形式ファイル

SNMP Manager製品と連携するためのファイルです。MIBファイルに変換する基になる形式のファイルです。Management Serverの運用管理コマンド（mngsvrutil）で出力できます。

Stateful Session Bean

内部的な状態を保持できるBeanです。Stateless Session Beanとは異なり，ホームインタフェースからの生成によってインスタンス化されたあとは，メソッドの呼び出しごとに生成，消滅することはありません。セッション単位で連続した処理をする場合に適したBeanです。

Stateless Session Bean

状態を保持しないBeanです。Beanのインスタンスの生成・消滅は，すべてEJBコンテナが独自に管理しています。同じBeanのメソッドを続けて呼び出した場合にも，それらが同じインスタンスである保証はありません。そのため，Stateless Session Beanでは，内部状態を保持して，複数メソッドで連続した処理をすることはできません。1メソッドで完結するような処理を記述する場合に適しています。

Timer Service

EJBコンテナで提供される機能です。指定した時刻，経過時間，または間隔で，EJBコンテナがタイムアウトメソッドをコールバックします。

ua.conf（統合ユーザ管理のコンフィグレーションファイル）

JAAS対応ユーザ管理，およびシングルサインオンの機能を使用するための設定ファイルです。

uCosminexus Batch Job Execution Server

オープン環境で基幹系のバッチ業務を実行・運用するためのバッチジョブ実行基盤を提供する製品です。JP1/AJS2とあわせて使用します。

uCosminexus Client

EJBクライアント環境を構築するための製品です。

uCosminexus Operator

Application Serverをインストールしたマシンとは別のマシンから，GUI（Eclipseプラグイン）画面を使用して運用操作を実行するための製品です。例えば，実行環境がUNIXの場合に，別のWindowsのマシンでEclipseプラグインのGUIによる運用管理操作を実行したいときに，この製品を使用します。

usrconf.properties（ユーザプロパティファイル）

J2EEサーバ，バッチサーバ，Webコンテナサーバ，またはサーバ管理コマンドで使用するJavaVMのシステムプロパティを定義するファイルです。

WARファイル

Webアプリケーションの構成要素をJARファイル形式に圧縮したファイルです。

Webアプリケーション実行に必要なHTMLファイル，JSPページ，Javaクラスファイル，JARファイル，およびWebアプリケーション配置記述子が含まれます。

Webアプリケーション

Webブラウザを備えたクライアントを対象に作成されたアプリケーションです。具体的には，サーブレットプログラム，JSPページ，HTML/XMLドキュメントなどの集合体です。

Webコンテナ

J2EEアーキテクチャのWebコンポーネント規約を実装するコンテナです。セキュリティ，トランザクションなどの各種サービスを提供する実行環境です。Webアプリケーションは，Webコンテナ上で動作します。

Java Servlet2.4仕様，およびJavaServer Pages Specification v2.0仕様に準拠したWebアプリケーションを実行できます。

Webコンテナサーバ

サーブレットエンジンモードで動作するサーバを指します。

Webサーバ

Webブラウザからのリクエスト受信およびWebブラウザへのデータ送信に関連する処理を実行するプログラムです。Cosminexusでは，Hitachi Web Server，Microsoft IIS，またはインプロセスHTTPサーバを使用できます。インプロセスHTTPサーバは，J2EEサーバプロセス内で動作するWebサーバです。

なお，Management Serverを利用する場合，Hitachi Web Serverは論理サーバとして扱えます。

Webサーバ連携

アプリケーションサーバで使用するWebサーバとして，Hitachi Web ServerまたはMicrosoft IISを使用する方法です。

Hitachi Web ServerまたはMicrosoft IISにCosminexus Component Containerが提供するリダイレクタモジュールを組み込んで使用します。

Webシステム

1台の負荷分散機（ロードバランサ）と複数のWebサーバおよびアプリケーションサーバで構築されるWebクラスタシステムで，単一の業務サービスを提供します。

（ア行）

アーカイブ形式

EJBやサーブレットなどのアプリケーションの実体をJ2EEサーバの作業ディレクトリに持つJ2EEアプリケーションの形式です。

アウトプロセス

プロセスの起動のしかたです。アウトプロセスで起動させると，J2EEサーバのプロセス外で実行します。アウトプロセスでネーミングサービスを使用する場合，CORBAネーミングサービスはユーザが起動する必要があります。

アセンブル

単体では動作しないEJB-JARをアプリケーションの1構成要素として位置づけるための組み立て作業のことです。

アノテーション

ソースコードにクラスやメソッドの付加情報などを埋め込むための記述方式です。

アプリケーションサーバ

情報システムの中間に位置し，ユーザの要求（プレゼンテーション層）とデータベースなどの業務システム（データ層）の処理を橋渡しするためのアプリケーション層を構築するためのミドルウェアです。

日立のアプリケーションサーバCosminexusは，業務の開発から運用まで一貫した環境を提供します。

アプレット

Web経由で読み手のマシンのブラウザ上にダウンロードされるJavaプログラムです。

イベントリスナ

イベントを受け取って処理するオブジェクトです。Application Serverでは，Webアプリケーション単位でサーブレットコンテキストオブジェクトまたはセッションオブジェクトの状態変化イベントを受け取ります。

インプロセス

プロセスの起動のしかたです。インプロセスで起動させると，J2EEサーバのプロセス内で実行するように最適化されるので，パフォーマンスの高いシステムが実現できます。ネーミングサービス，トランザクションサービスおよびHTTPサーバ機能をインプロセスで起動できます。このとき，CORBAネーミングサービス，インプロセスOTSおよびインプロセスHTTPサーバは，J2EEサーバ起動時に自動で起動されます。

インプロセスHTTPサーバ

J2EEサーバのインプロセスで動作するWebサーバ機能です。Webコンテナの機能の一部として提供されます。

運用監視エージェント

ホスト上で動作する論理サーバの稼働状況を監視して，稼働情報を収集するエージェントプログラムです。

運用管理エージェント

運用管理者の代わりに，それぞれのホスト上の論理サーバを起動したり，設定ファイルを更新したりするエージェントプログラムです。

運用管理コマンド（mngsvrutil）

Management Serverを操作するためのCUIです。

運用管理サーバ

Smart Composer機能または運用管理ポータルでシステムを構築している場合に，Management Serverを配置したホストです。運用管理ドメイン内の各ホストに配置されている運用管理エージェントに対して，管理操作を指示します。

運用管理サーバモデル

Smart Composer機能または運用管理ポータルでシステムを構築している場合に，アプリケーションサーバとは別の運用管理用のホストにManagement Serverを配置するシステム構成モデルです。

運用管理ドメイン

Management Serverが管理する論理サーバの集合です。同じ運用管理ポリシーが適用されます。

運用管理ポータル

Management Serverを操作するためのGUIです。Webブラウザで表示します。

運用管理ポリシー

運用，監視，セキュリティなど，運用管理に関するポリシーです。

エラーページのカスタマイズ

Webクライアントから存在しないリソースへのアクセスなどがあった場合に，Webコンテナから返却されるエラーページをユーザが作成した任意のページに変更して表示させる機能です。

（カ行）

ガーベージコレクション制御機能

リソースの排他中にガーベージコレクションの実行を待ち状態にする機能です。リソースの排他中にフルガーベージコレクションが発生し，処理が長時間中断されるのを回避できます。ガーベージコレクション制御機能は，バッチサーバの場合に使用できます。

カスタムジョブ

JP1/AJS2以外のプログラムとJP1/AJS2が連携するジョブを定義する場合に，目的のジョブを容易に作成するために使用できるジョブのテンプレートです。Windowsの場合，Cosminexusでは，「論理サーバ制御用カスタムジョブ」と「アプリケーション制御用カスタムジョブ」の2種類を提供しています。

カスタムログインモジュール

Cosminexus標準ログインモジュール以外を使用して，各アプリケーションのユーザ認証をしたい場合に作成する実装クラスです。

仮想サーバ

負荷分散機で複数の実サーバを管理するための仮想的なサーバです。負荷分散機では，クライアントから仮想サーバにアクセスされたトラフィックを，実サーバに自動分配します。

稼働情報収集機能

J2EEサーバやバッチサーバ内の各機能の稼働情報を定期的に収集し，ファイルに出力する機能です。出力されたファイルを稼働情報ファイルといいます。

簡易Webサーバ

WebコンテナをHTTPサーバとして使用して，スタブなどのダウンロードに利用する機能です。インプロセスHTTPサーバとは異なり，実運用時にはスタブのダウンロード以外の目的では使用できません。

Management Serverを利用する場合は，「管理用サーバ」という名称で扱います。

監査証跡

データベースの機能で出力する，データベースに対する操作記録のことです。データベースに対する権限の運用が適切に行われているかどうかをチェックするために使用します。Cosminexusでは，監査証跡にCosminexusシステムの情報を出力するためのデータベース監査証跡連携機能を提供しています。

監査ログ

システム構築者やシステム運用者がCosminexusのプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴が出力されるファイルです。監査者が監査ログを調査することで，「いつ」「だれが」「何をしたか」を知ることができて，システムの運用が法規制，セキュリティ評価基準，または業界ごとの各種の基準に準拠していることを証明できます。

監視ツリー

JP1/IM連携をしている場合に，統合スコープに表示するツリーのことです。Cosminexusシステムでは，監視ツリーとして，Cosminexus業務指向ツリーとサーバ指向ツリーの2種類を作成する機能を提供しています。

管理対象オブジェクト（AdminObject）

Connector 1.5仕様で定義された，キューやトピックなどを使用したメッセージの送受信で使用するオブジェクトです。メッセージ送信や，同期または非同期でのメッセージ受信でのメッセージ変換で使用します。

管理対象オブジェクトは，メッセージプロバイダごとに特有のオブジェクトです。リソースアダプタが使用する管理対象オブジェクトは，リソースアダプタのDD（ra.xml）の<adminobject>タグで指定します。

機能レイヤ

性能解析トレース収集をする場合に，PRFトレースを出力する機能の層です。EJBクライアント，リダイレクタ，Webコンテナ，CTM，EJBコンテナ，JNDI，JTA，JCA/JDBCなどがあります。

業務指向ツリー

JP1/IMと連携している場合に統合スコープに表示する監視ツリーの一つです。Cosminexusシステム上で稼働しているJ2EEアプリケーションを主体に構成されている監視ツリーです。どの業務で問題が発生しているか，業務の視点でトラブルを監視できます。

業務処理プログラム

ビジネスロジックを実装したEnterprise Beanのことです。

共有スレッド数

Webコンテナ上にデプロイされているWebアプリケーションで共有されるスレッド数です。

クライアントアプリケーション情報

性能解析トレースに出力される情報です。次に示すEnterprise Beanを呼び出す単位で設定される情報です。

WebコンテナからEJBコンテナの呼び出し

EJBクライアントからEJBコンテナの呼び出し

EJBコンテナからEJBコンテナの呼び出し

クラスタ

ある共通の機能を提供するサーバの集合です。

Management Serverでは，J2EEサーバクラスタまたはWebサーバクラスタを論理サーバとして扱えます。

クラスタソフトウェア

システムの信頼性向上，稼働率向上を目的として，システムの切り替えを実現するプログラムです。

実行中のサーバシステムに障害が発生した場合，事前に待機しているサーバシステムに，直ちに自動で切り替えることができます。そのため，オペレータが特に意識することなく，システムの信頼性や稼働率を高められます。

Cosminexusでは，クラスタソフトウェアを使用して，1:1系切り替えシステム，N:1リカバリシステム，および相互系切り替えシステムを実現できます。

AIX，HP-UXまたはLinuxを使用している場合は，クラスタソフトウェアとしてHAモニタが使用できます。Windowsの場合は，クラスタソフトウェアとしてMicrosoft Cluster Serviceが使用できます。

グローバルCORBAネーミングサービス

CTMによってリクエストをスケジューリングする場合に，CTMドメイン内に含まれる複数のJ2EEサーバに登録されている業務処理プログラム（Stateless Session Bean）の情報を共有管理するネーミングサービスです。

グローバルセッション

セッションフェイルオーバ機能では，障害発生前のHTTPセッションと，障害発生後に引き継がれたHTTPセッションを一つのセッションとして扱います。これをグローバルセッションといいます。

グローバルセッションID

グローバルセッションを管理するIDです。システム内でグローバルセッション情報を一意に識別するために，グローバルセッションに付けられます。

グローバルセッション情報

グローバルセッションが持つ情報をグローバルセッション情報といいます。グローバルセッション情報はSFOサーバで管理されます。

グローバルトランザクション

J2EEサーバが提供するトランザクションマネジャによって管理されるトランザクションです。2フェーズコミットプロトコルを使用できるので，トランザクションに複数のリソースを参加させることができます。

系

系とは，業務処理に必要なハードウェアのほか，実行するプログラムや通信機器を含めたシステム全体の総称です。系の種類には，実行系と待機系があります。

計画系切り替え

系切り替えの方法の一つで，オペレータが系を保守する際に，計画的に系を切り替える方法です。

系切り替え

システムに障害が発生した場合やシステムの保守のために，システムを切り替えることをいいます。系切り替えが行われると，待機系は業務処理を引き継いで実行系となります。一方，実行系は，さらに障害が発生した場合に備えて待機系となります。以降，系切り替えのたびに，実行と待機を交代して，どちらかの系で常に業務処理を実行するようにします。

系障害

サーバを除いた系に発生する障害を指します。系のハードウェア障害やHAモニタの障害などがあります。なお，サーバに発生する障害はサーバ障害といいます。

ゲートウェイ指定機能

クライアントとWebサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合に，Webコンテナにゲートウェイ情報を通知し，welcomeファイルやForm認証画面に正しくリダイレクトできるようにするための機能です。

現用系

最初に実行系として動作させる系を現用系といいます。系切り替えによって，実行系が待機系になった場合でも，呼び方は変わりません。

コネクションスイーパ

一定の間隔でコネクションプール内の未使用コネクションを破棄する機能です。

コネクションプーリング

サーブレット，JSP，Enterprise BeanなどのJ2EEコンポーネントや，バッチアプリケーションからリソースへのアクセス量に応じて，リソースコネクションをメモリ上にプーリングする機能です。リソースコネクションには，JDBCコネクション，リソースアダプタのコネクションなどがあります。コネクションをプーリングしておくことで，アプリケーションからのリソース接続要求を高速に処理できます。

コミットオプション

CMPフィールドのキャッシュ方法とEntity Beanの状態遷移のキャッシュモデルを指定するオプションです。

Full cachingの場合，Entity Beanは前回のトランザクションコミット時と同じ状態で開始されます。

Cachingの場合，Entity Beanはデータベースの最新状態と同じ状態で開始されます。

No cachingの場合，Entity Beanはデータベースの最新状態と同じ状態で開始され，かつ，トランザクションコミット時にEntity Beanは非活性になります。

コンテキスト

Webアプリケーションをまとめた管理単位です。

コンテキストルート

コンテキストのルートパスです。コンテキスト内のWebアプリケーションにアクセスするときにURL上に指定します。コンテキストパスとも呼びます。

コンテナ拡張ライブラリ

ユーザ作成ライブラリのインタフェースおよび機能を，J2EEコンテナ，Webコンテナ，またはバッチサーバから利用できるように拡張したライブラリです。Enterprise Bean，サーブレットおよびJSPから共通して利用できます。

（サ行）

サーバ管理コマンド

サーバで管理しているアプリケーションおよびリソースの設定をするためのコマンド群です。

サーバ起動・停止フック機能

J2EEサーバ，バッチサーバまたはWebサーバの起動・停止時に，コンテナ拡張ライブラリを使用するための初期化処理および停止処理を自動的に呼び出す機能です。J2EEサーバまたはWebサーバが異常終了した場合には機能しません。

サーバ指向ツリー

JP1/IMと連携している場合に統合スコープに表示する監視ツリーの一つです。サーバマシン（ホスト）を主体に構成されている監視ツリーです。

サービス閉塞

J2EEアプリケーションの運用中に特定の業務処理プログラムを入れ替えたい場合などに，システム全体は稼働させたまま，該当サービスだけを安全に閉塞させる機能です。

サービスユニット

J2EEサーバやWebサーバで構成される業務サービスを提供する閉じた部分系を，サービスユニットといいます。Smart Composer機能では，サービスユニット単位でシステムを構築したり，一括起動や一括停止をしたりできます。

Smart Composer機能を利用してシステムを構築するときの概念です。

サーブレット

サーバ側でJavaを実行させる方法の一つです。

サーブレットは，Webサーバに対して，単にHTML文書や画像ファイルを送るだけではなく，Webサーバと連携して，アプリケーションを実行し，その結果をHTML文書として送り返す機能を提供します。

サーブレットエンジンモード

サーバの動作モードの一つです。Webコンテナ部分だけを使用して，サーブレットエンジンを単独で動作させます。Enterprise Beanは動作しません。

サーブレットエンジンとは，サーブレット実行機能およびJSP実行機能を持つサーバのことです。

なお，サーブレットエンジンモードは互換用の動作モードとなります。

サーブレットフィルタ

サーブレット/JSPへのリクエストや，サーブレット/JSPからのレスポンスを，フィルタリングする機能です。サーブレットフィルタによって，サーブレット/JSPの実行前のリクエスト，または実行後のレスポンスをラップして，データの変更，リソースに対するトレースの取得などができます。

Cosminexusの機能を実現するためのサーブレットフィルタとしては，セッションフェイルオーバ用フィルタ，およびHTTPレスポンス圧縮用フィルタが提供されています。

実行系

業務処理を実行させる系（実行中のサーバ）を指します。

実行待ちキュー

同時実行スレッドの最大値を設定している場合に，実行スレッド数が最大に達したときに，リクエストをためておくキューのことです。

実パラメタ

Cosminexusの定義ファイルに設定するパラメタです。Smart Composer機能では，抽象パラメタを一つ設定することで，互いに関連のある複数の実パラメタに，一括で値を設定できます。

自動系切り替え

系切り替えの方法の一つで，クラスタソフトウェアが自動的に系を切り替える方法です。

シナリオ

JP1/AJS2 - SOで扱う，シナリオジョブに実行順序を付けてネットワーク化したオブジェクトです。シナリオジョブとは，シナリオ中に定義されたコマンド，シェルスクリプト，Windows実行ファイルなどを定義したオブジェクトです。

シナリオはJP1/AJS2に登録して実行できます。

ジョブ

JP1/AJS2で扱うシステム運用の各作業のことです。

ジョブネット

JP1/AJS2で扱うジョブの実行順序を関連づけたものです。

シングルサインオン

一度のログイン処理で，ユーザIDが異なる複数のシステムをシームレスに利用できるようにする機能です。

シングルサインオン情報リポジトリ

統合ユーザ管理フレームワークのユーザマッピングを実行して，シングルサインオンでユーザ認証するための各システムの認証情報とマッピング情報を格納するリポジトリです。

シングルサインオンライブラリ

ユーザマッピング情報の格納されたシングルサインオン情報リポジトリの情報を基にユーザマッピングをして，シングルサインオンを実現するライブラリです。

スケールアウト

システム全体の処理性能を向上させることを目的として，サーバの台数を増やすことをいいます。

スケールイン

システムの規模を縮小する場合などに，サーバの台数を減らすことをいいます。

スケジュールキュー

CTMによってリクエストをスケジューリングする場合に，リクエストをためておくキューです。J2EEアプリケーション単位で作成され，CTMデーモンによって管理されます。

スケジュールポリシー

CTMによってリクエストをスケジューリングする場合に，振り分ける基準を決めるポリシーです。負荷が軽いCTMデーモンに振り分ける方法と，リクエストを受け付けたCTMデーモンに優先的に処理させる方法のどちらかを選択できます。

スマートエージェント

1.4モードでグローバルトランザクションを使用する場合，またはCTMを使用する場合に，動的な分散ディレクトリサービスを提供するプロセスです。

Management Serverを利用する場合，スマートエージェントは論理サーバとして扱えます。CTMはスマートエージェントによって管理されます。

なお，グローバルトランザクションの場合でも，インプロセストランザクションサービスを利用するときは，スマートエージェントは不要です。

静的コンテンツ

HTMLファイルや画像ファイルなど，クライアントからの要求に対する応答に使用するファイルのうち，リクエスト内容に影響されないで常に同じ内容になるコンテンツのことです。

性能解析トレース

Cosminexusシステムの性能解析をするためのトレース情報です。

性能解析トレースファイル

Cosminexusシステムの性能解析をするためのトレース情報をCSV形式で編集出力したテキストファイルです。

セキュリティアイデンティティ

J2EEサーバによるユーザ認証が成功した時にWebコンテナやEJBコンテナに伝達される認証情報です。

セッション

Webアプリケーションに対する一連の作業を示す単位です。セッションは通常，WebクライアントからWebサーバへの複数のリクエストの集合から構成されます。

セッションフェイルオーバ機能

J2EEアプリケーション実行中のHttpSessionオブジェクトに登録されたオブジェクトをセッション情報として管理し，J2EEサーバで障害が発生した場合には，管理しているセッション情報をほかのJ2EEサーバに引き渡す機能です。J2EEサーバで障害が発生し，ほかのJ2EEサーバにリクエストが転送された場合でも，障害発生前の状態で業務を続行できます。

セッションフェイルオーバサーバ

セッションフェイルオーバ機能を使用する場合に，J2EEサーバを配置しないで，SFOサーバを配置して使用するホストです。

セットアップウィザード

対話形式のウィザードプログラムを使用してシステムを構築するための機能です。必要最低限の項目を設定するだけで，J2EEアプリケーションを実行するためのシステムを構築できます。できるだけ少ない手順で実行環境を構築したい場合にお勧めの機能です。ただし，セットアップウィザードで実行できるのは，1台のマシンを対象にしたシステム構築だけです。

占有スレッド数

利用できるスレッド数のうち，同時実行スレッド数制御の対象となるリクエストを確実に実行できるスレッド数です。Webコンテナ上にデプロイされているWebアプリケーションごと，またはWebアプリケーション内の業務処理ロジックごとに指定できます。

相互系切り替えシステム

クラスタソフトウェアを使用して実現できるシステムの一つです。アプリケーションサーバの実行系と待機系を1：1にする構成で，それぞれのアプリケーションサーバを実行系として稼働させながら，お互いの待機系にするシステムです。

相互スタンバイ

クラスタソフトウェアを使用した運用をする場合に，アプリケーションサーバの実行系と待機系を1:1にする構成で，それぞれのアプリケーションサーバを実行系として稼働させながら，お互いの待機系にすることです。

（タ行）

待機系

障害に備えて待機させている系（待機中のサーバ）を指します。

抽象パラメタ

互いに関連のあるパラメタを一つのパラメタとしてまとめたものです。Smart Composer機能で使用します。Smart Composer機能のコマンドを使用してパラメタを展開すると，一度に複数の実パラメタに値が展開されます。

通常モード

J2EEアプリケーションの動作モードです。通常モードは，本番稼働するJ2EEアプリケーションを動作させるためのモードです。

データソース

JDBCを使用してデータベースに接続する機能です。

テストモード

J2EEアプリケーションの動作モードです。テストモードは，テスト用のJ2EEアプリケーションを本番環境と同じように動作させるためのモードです。

デプロイ

J2EEアプリケーションの場合，J2EEサーバ内にインポートしたJ2EEアプリケーションを，クライアントから実行可能な状態にすることです。

J2EEリソースアダプタの場合，J2EEサーバ内にインポートしたJ2EEリソースアダプタを，そのJ2EEサーバ上で動作するすべてのJ2EEアプリケーションから使用可能な状態にすることです。

展開ディレクトリ形式

EJBやサーブレットなどのアプリケーションの実体を，J2EEサーバの外部にある一定のルールに従ったファイル／ディレクトリに持つJ2EEアプリケーションの形式です。

統合コンソール

JP1/IMと連携している場合に，システムで発生した事象に関するエラーメッセージなどを表示する画面です。

統合スコープ

JP1/IMと連携している場合に，システムの監視画面として管理者の目的に合った監視ツリーを表示する画面です。

統合ネーミングスケジューラサーバ

CTMによるリクエストのスケジューリングをする場合に，J2EEサーバを配置しないで，グローバルCORBAネーミングサービスを配置して使用するホストです。統合ネーミングスケジューラサーバのレプリカを作成することで，可用性を向上できます。なお，統合ネーミングスケジューラサーバにもCTMデーモンは必要です。

統合ネーミングスケジューラサーバモデル

CTMによるリクエストのスケジューリングをする場合に，J2EEサーバを配置しないでグローバルCORBAネーミングサービスを配置するホストを作成するシステム構成モデルです。

統合ユーザ管理

Cosminexusシステムにログインするユーザを統合管理するための仕組みです。ユーザ認証を実現する統合ユーザ管理フレームワークと，リポジトリ管理およびリソース監視を実現する統合ユーザ管理GUIが使用できます。

統合ユーザ管理GUI

Management Serverの運用管理ポータルから，統合ユーザ管理の対象になるユーザ情報を格納したリポジトリを管理したり，統合ユーザ管理に関連するリソースを監視したりするためのGUIです。

統合ユーザ管理フレームワーク

統合ユーザ管理でのユーザ認証を実現するフレームワークです。Java標準仕様（JAAS）に従ったAPIが提供されています。

動作モード

サーバの動作モードです。J2EEサーバモードとサーブレットエンジンモードがあります。J2EEサーバモードには，さらに，1.4モード，ベーシックモードがあります。

ただし，ベーシックモードおよびサーブレットエンジンモードは旧バージョンとの互換用の動作モードとなります。

動的コンテンツ

サーブレットやJSPのように，クライアントからの要求に応じて動的に生成されるコンテンツのことです。

トランザクションサービス

グローバルトランザクションを使用する場合に，トランザクションを管理するサービスです。TPBroker OTSによって提供されるサービス全体を表します。トランザクションサービスは，J2EEサーバのインプロセスで起動されます。

トランザクションマネジャ

トランザクションを管理する機能です。Application Serverが提供しています。グローバルトランザクションの場合は，トランザクションマネジャのバックエンドでTPBroker OTSが使用されています。

トレース取得ポイント

Cosminexusシステムの各機能レイヤでPRFトレースを出力するポイントのことです。PRFトレース取得レベルの指定によって，トレース取得ポイントの数は異なります。

（ナ行）

ネーミング切り替え

JNDIを介してEJBホームオブジェクトの登録，削除，検索をする時に，JNDIが接続するCORBAネーミングサービスを切り替えることです。

ネーミングサービス

オブジェクトに名前を付けて格納場所を管理しておくことで，格納先を知らなくても名前からそのオブジェクトを利用できるようにするサービスです。Application ServerではCORBAネーミングサービスを利用します。

Management Serverでは，ネーミングサービスを論理サーバとして扱えます。

（ハ行）

バインド先アドレス設定機能

Webサーバ連携および簡易Webサーバで利用するIPアドレスを，Webコンテナで明示的に指定する機能をバインド先アドレス設定機能といいます。複数の物理ネットワークインタフェースを持つホストまたは一つの物理ネットワークインタフェースに対して，ホストで実行する場合に，この機能を使用することで，任意のIPアドレスを設定できます。

バッチアプリケーション

バッチ処理を実装したJavaアプリケーションです。バッチ実行コマンドを使用して，バッチサーバ上で実行します。バッチ実行コマンドをJP1/AJS2のジョブとして定義しておくと，JP1/AJS2からバッチアプリケーションを実行できます。

バッチサーバ

バッチアプリケーションを実行するためのサーバです。バッチアプリケーションの実行機能のほかに，バッチアプリケーションからデータベースに接続したり，EJBにアクセスしたりする機能も提供しています。

パフォーマンストレーサ

PRFデーモンのことです。

Management Serverでは，パフォーマンストレーサを論理サーバとして扱えます。

ハンドラ

ロガーから受け取ったアプリケーションのログをファイルやコンソールに出力する，JavaロギングAPIのHandlerオブジェクトです。J2EEアプリケーション，バッチアプリケーション，EJBクライアントアプリケーションで使用できます。

Application Serverでは，日立トレース共通ライブラリ形式のログをファイルに出力するためのファイルハンドラである，CJMessageFileHandlerを提供しています。

ビジネスインタフェース

Enterprise Beanを呼び出すためのビジネスメソッドを定義するインタフェースです。

日立トレース共通ライブラリ

日立が提供するトレース採取用のライブラリです。複数の製品で共通のライブラリを利用するので，各製品のトレース形式が統一できます。

非保護区

メソッドキャンセルができる領域を指します。ユーザプログラムのコードが非保護区に該当します。メソッドキャンセルとは，J2EEアプリケーション実行時間の監視で提供される機能の一つです。また，バッチ強制停止コマンドでも使用されます。

負荷分散機

Webブラウザなどからのリクエストを一元的に受け付けて，同等の機能を持つ複数のサーバに転送して各サーバの負荷を分散させるための装置です。

物理コネクション

接続先リソースのコネクションです。通常はJ2EEコンテナが操作します。リソースアダプタの場合は，javax.resource.spi.ManagedConnection，JDBCの場合はjavax.sql.XAConnectionに該当します。

物理ティア

同一のデプロイメント（プロセスの配置，J2EEアプリケーションやリソースアダプタのデプロイ，定義）を適用するサーバマシンの集合を物理ティアといいます。

Smart Composer機能を利用してシステムを構築するときの概念です。

フロントEJB

リクエストの受け口となるEnterprise BeanをフロントEJBといいます。

ベーシックモード

旧バージョンとの互換性を確保するためのサーバの動作モードの一つです。

単一リソースとのトランザクション管理ができます。

別名

JNDI名前空間に登録するEJBホームオブジェクトリファレンスや，J2EEリソースに付けられる任意の名前です。ユーザ指定名前空間機能を使用している場合，別名を付けられます。Optional Nameともいいます。

保護区

メソッドキャンセルができない領域を指します。J2EEサービスのソースなどが保護区に該当します。メソッドキャンセルとは，J2EEアプリケーション実行時間の監視で提供される機能の一つです。また，バッチ強制停止コマンドでも使用されます。

ホスト単位管理モデル

Smart Composer機能または運用管理ポータルでシステムを構築している場合に，Management Serverをアプリケーションサーバと同じホストに配置するシステム構成モデルです。

（マ行）

未決着トランザクション

決着していない，仕掛かり中のトランザクションです。

メソッドキャンセル機能

J2EEアプリケーション実行時間の監視機能の機能の一つです。メソッドタイムアウト機能でタイムアウトが通知されたあと，メソッドのキャンセルを実施する機能です。キャンセル時にデータベースにアクセスしている場合は，トランザクションの強制決着もします。

また，メソッドキャンセル機能は，バッチ強制停止コマンド実行時にも使用されます。

メソッドタイムアウト機能

J2EEアプリケーション実行時間の監視機能の機能の一つです。監視基盤にあるリクエストのうち，一定時間内に終了しなかったメソッド処理を，タイムアウトとしてユーザに通知します。

メッセージインフロー

メッセージプロバイダがアプリケーションサーバ上のメッセージエンドポイントにメッセージを配送する場合の規約です。Connector 1.5のInboundの通信モデルを使用する場合に使用できる機能です。

メッセージプロバイダにはEISなどが該当します。アプリケーションサーバ上のメッセージエンドポイントにはMessage-driven Beanが該当します。

面数

ログファイルを保持する数です。ログファイルは面数分作成され，循環して使用されます。

メンバリソースアダプタ

コネクションプールをクラスタ構成にしている場合に，データベースノードに接続するリソースアダプタです。メンバリソースアダプタは，必ずルートリソースアダプタを経由してアクセスされます。

（ヤ行）

ユーザ指定名前空間機能

JNDI名前空間に登録するEJBホームオブジェクトリファレンスやJ2EEリソースの名前に，ユーザが任意の別名を付けられる機能です。別名を付与することによって，CTMによってリクエストを振り分けたり，負荷分散機やロードバランサによって負荷分散したりする場合に，サーバ名やアプリケーション名に依存しない名前でルックアップできるようになります。

ユーザ情報

Cosminexusシステムにユーザがログインするための情報です。

ユーザ情報リポジトリ

統合ユーザ管理をする場合に，ログイン時のユーザ認証に使用する情報を格納するリポジトリです。LDAPディレクトリサーバまたはデータベース（RDB）が使用できます。

ユーザスレッド

ユーザがプログラムの中で明示して生成するスレッドのことです。

ユーザ認証ライブラリ

LDAPディレクトリサーバで構築されたユーザ情報リポジトリの情報を基にユーザ認証をして，認証したユーザの情報をアプリケーションに提供する，JAAS対応ユーザ管理用ライブラリです。

ユーザプロパティファイル

usrconf.propertiesのことです。J2EEサーバ，Webコンテナサーバまたはサーバ管理コマンドを実行するJavaVMのシステムプロパティを指定します。なお，J2EEサーバ，Webコンテナサーバおよびサーバ管理コマンドで使用するユーザプロパティファイルは，それぞれ格納先および指定できるキーが異なります。

ユーザマッピング

異なるユーザ情報リポジトリに格納した同じユーザについての情報を対応づけることです。

ユーザログ

J2EEアプリケーション，バッチアプリケーション，またはEJBクライアントアプリケーションが出力するログのことです。

予備系

最初に待機系として起動する系を予備系といいます。系切り替えによって，待機系が実行系になった場合でも，呼び方は変わりません。

（ラ行）

ライトトランザクション

ローカルトランザクションを最適化した状態で使用できる機能です。

ライブラリJAR

JARファイル形式でパッケージされた，共通ライブラリです。J2EEアプリケーション内のJ2EEコンポーネントから共通に使用できます。

ラウンドロビン検索

複数のCORBAネーミングサービス上にある同一名称のEJBホームオブジェクトを，ラウンドロビンポリシーに従ってルックアップする検索機能のことです。

ラウンドロビンポリシー

複数のCORBAネーミングサービス上にある同一名称のEJBホームオブジェクトをルックアップする場合に適用されるポリシーです。

EJBホームオブジェクトリファレンスをラウンドロビン検索によって取得できるので，EJBクライアントでは意識しないでJ2EEサーバに送信するリクエストの負荷分散を実現できます。

リカバリ専用サーバ

クラスタソフトウェアを使用してN:1リカバリシステムを構築している場合に待機系として機能するアプリケーションサーバです。

障害が発生した実行系のアプリケーションサーバに未決着のトランザクションがあった場合に，系が切り替えられ，該当するトランザクションを解決してリソースを解放します。

リクエスト処理スレッド

Webブラウザなどのクライアントからのリクエストを受け付けて処理するためにWebサーバで生成されるスレッドです。インプロセスHTTPサーバの場合は，Webコンテナで生成されます。

リクエストのスケジューリング

クライアントからのリクエストを実行するサーバを負荷に応じて的確に振り分けたり，サーバに送信するリクエストの数を制限したりする機能です。

リソースアダプタ

J2EE Connector Architectureによって，J2EEサーバまたはバッチサーバと，EISを接続するための接続機能です。

Cosminexusシステムでは，データベースに接続するためのリソースアダプタであるDB ConnectorおよびDB Connector for Cosminexus RMを提供しています。また，OpenTP1のSPPと接続するためのリソースアダプタであるuCosminexus TP1 Connector，TP1/Message Queueと接続するためのリソースアダプタであるTP1/Message Queue - Access，データベース上に実現したキューに接続するためのリソースアダプタであるCosminexus RMも使用できます。

リソースマネジャ

リソースを管理する機能です。DBMSなどが該当します。

リダイレクタ

Webサーバに登録しWebコンテナへの接続を可能にするプラグインコンポーネント（ライブラリ）です。Webサーバに登録したリダイレクタによって，リクエストをURLパターンまたはラウンドロビン方式で複数のWebコンテナに振り分けて処理できます。

リデプロイ機能

J2EEアプリケーションを入れ替えるときに使用する機能です。リデプロイ機能による入れ替えは，J2EEアプリケーションのテスト時などに，修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたいときに使用します。

リバースプロキシサーバ

インターネットなどの外部ネットワークとアプリケーションサーバが配置されている内部ネットワークの間のDMZに配置され，外部ネットワークからのリクエストを内部ネットワークに中継するための機能を持つWebサーバです。

Cosminexusでは，Hitachi Web Serverをリバースプロキシサーバとして使用できます。リバースプロキシサーバには，リバースプロキシモジュールが組み込まれて動作します。

リモートインタフェース

Java RMIのインタフェース規定に従い，RMI-IIOP通信によってEnterprise Beanの呼び出しをするインタフェースです。

リモートホームインタフェースとリモートビジネスインタフェースが含まれます。

リロード機能

開始状態にあるアプリケーションを停止させないで，アプリケーションを構成するクラスやJSPを，少ない手順で動的に入れ替える機能です。

ルートアプリケーション情報

性能解析トレースに出力される情報です。イベントで一連の処理の先頭になるプロセスで取得した情報です。

ルートコンテキスト

コンテキストルートが空文字（コンテキストルートに名称が指定されていない）の，WARファイル内のルートパスです。

ルートリソースアダプタ

コネクションプールをクラスタ構成にしている場合に，メンバリソースアダプタを束ね，ユーザプログラムからのリクエストを受け付けるアダプタのことです。

レルム

統合ユーザ管理をしているシステムで，同一の認証ポリシーを適用する範囲のことです。

ローカルインタフェース

Enterprise Beanの呼び出しをJavaのメソッド呼び出しで実行するインタフェースです。通信は発生しません。

ローカルホームインタフェースとローカルビジネスインタフェースが含まれます。

ローカルトランザクション

接続先のリソースマネジャによって管理されるトランザクションです。単一のリソースだけがトランザクションに参加できます。

ロードバランサ

リダイレクタを使用してリクエストを振り分ける場合に使用するワーカ定義のうち，クラスタ構成の場合に使用する特殊なワーカ定義です。振り分け先のWebコンテナのリストが定義されています。リダイレクタでは，この定義を基に，ラウンドロビン方式でリクエストの振り分け処理をします。

ロール

コンテキストに対し，アクセス制御するときに使用される単位です。ロールはグループごとに定義されます。また，アクセス制御するコンテキストについては，そのコンテキストにアクセスするのに必要なロールが定義されます。アクセスしたユーザの持つロールがコンテキストに定義されたロールと一致した場合，そのコンテキストへのアクセスは成功します。

ロガー

J2EEアプリケーション，バッチアプリケーション，またはEJBクライアントアプリケーションのログを取得する，JavaロギングAPIのLoggerオブジェクトです。

ログインモジュール

JAASに準拠した統合ユーザ管理のユーザ認証に使用する，JAAS APIのLoginModuleインタフェースの実装クラスです。

論理コネクション

サーブレットやEnterprise BeanなどのJ2EEコンポーネントが直接操作するコネクションです。

リソースアダプタの場合はjavax.resource.cci.Connection，JDBCの場合はjava.sql.Connectionに該当します。

論理サーバ

Management Serverの運用管理の対象になる，サーバまたはクラスタです。サーバには，Webサーバ，J2EEサーバなどがあります。クラスタとは，ある共通の機能を提供するサーバの集合です。

論理ネーミングサービス

JNDIがラウンドロビン検索の対象にする複数のCORBAネーミングサービスのことです。

論理ユーザサーバ

任意のサービスやプロセスをManagement Serverの管理対象として定義した論理サーバです。Management Serverで起動・停止したり，ステータス監視したりできるようになります。

（ワ行）

ワーカプロセス

Webサーバの背後で動作するWebコンテナのプロセスです。リダイレクタから見た場合のWebコンテナ実行プロセスになります。具体的には，J2EEサーバまたはWebコンテナサーバに当たります。

索引

[記号]
[数字]
[Ａ][Ｂ][Ｃ][Ｄ][Ｅ][Ｈ][Ｉ][Ｊ][Ｍ][Ｎ][Ｏ][Ｐ][Ｒ][Ｓ][Ｔ][Ｕ][Ｗ]
[ア行][カ行][サ行][タ行][ナ行][ハ行][マ行][ヤ行][ラ行][ワ行]

(記号)

-XX:+PrintTenuringDistributionオプション

(数字)

1.4モード

1:1系切り替えシステム

3章で使用する図の凡例

3章で使用する図の凡例（ホストの分類）

(英字)

(Ａ)

Application Server

(Ｂ)

Bean-Managed Persistence

Bean-Managed Transaction

BJEX

BMP

BMT

(Ｃ)

CMP

CMT

Component Container管理者

Container-Managed Persistence

Container-Managed Transaction

Cookieスイッチング機能

CORBAネーミングサービス

Cosminexus

Cosminexus

Cosminexus Component Container

Cosminexus Component Transaction Monitor

Cosminexus Operator Plug-in

Cosminexus Performance Tracer

Cosminexus Reliable Messaging

Cosminexusが使用するTCP/UDPのポート番号

Cosminexusシステム

Cosminexus標準ログインモジュール

CTM

CTMデーモン

CTMとEJBコンテナ（J2EEサーバ）の配置

CTMドメイン

CTMドメインマネジャ

CTMレギュレータ

Cヒープ領域

(Ｄ)

DB Connector

DB Connector

DB Connector for Cosminexus RM

DD

DefNew::Eden領域

DefNew::Survivor領域

Dependency Injection

DIターゲット

DTD

(Ｅ)

EARファイル

EIS

EJB

EJB-JARファイル

EJBクライアント

EJBクライアント

EJBクライアント

EJBクライアントアプリケーション

EJBクライアント構成

EJBコンテナ

EJBタイマ

Enterprise Bean

Enterprise Beanの呼び出し方法の最適化

Enterprise JavaBeans

Entity Bean

(Ｈ)

HAモニタ

(Ｉ)

IDS

Inbound

(Ｊ)

J2EE

J2EEアプリケーション

J2EEアプリケーション実行時間の監視機能

J2EEアプリケーションの強制停止

J2EEアプリケーションの通常停止

J2EEコンテナ

J2EEコンポーネント

J2EEサーバ

J2EEサーバモード

J2EEサービス

J2EEリソース

J2EEリソースアダプタ

jaas.conf

JAASのコンフィグレーションファイル

Java

Java Database Connectivity

Java Naming and Directory Interface

JavaServer Pages

JavaVMオプション

JavaVM固有領域

JavaVMで使用するメモリ空間の構成

Javaヒープ

JavaロギングAPI

JCAコンテナ

JCAとEISの配置

JDBC

JNDI

JNDI名前空間

JP1

JP1/AJS2

JP1/AJS2 - SO

JP1/Cm2/NC - Manager

JP1/Cm2/NC - Manager for Cosminexus

JP1/IM

JP1/IM - CM

JP1/NETM/Audit

JP1/SC/DPM

JP1イベント

JP1ジョブ運用管理サーバ

JP1統合運用管理サーバ

JP1と連携したシステムの運用

JSP

JSP EL

JSPコンパイル結果

JSP事前コンパイル

JSPタグライブラリ

(Ｍ)

Management Server

Management Server

Managementアクション

Managementイベント

Message-driven Bean

MIBオブジェクト

MIBファイル

Microsoft Cluster Service

mngsvrutil

(Ｎ)

N:1リカバリシステム

N:1リカバリシステム

(Ｏ)

Object Transaction Service

Oracle RAC

ORBゲートウェイ

OS固有領域

OTMゲートウェイ

OTS

Outbound

(Ｐ)

Permanent領域

PRFデーモン

PRFトレース

PRFトレース出力ライブラリ

PRFトレース取得レベル

PRFトレースファイル

(Ｒ)

RMI-IIOP

(Ｓ)

SecurityManager

Server Plug-in

Session Bean

SFOサーバ

SFOサーバアプリケーション

Smart Composer機能

snapshotログ

SNMP連携用形式ファイル

SSLアクセラレータ

Stateful Session Bean

Stateless Session Bean

(Ｔ)

Tenured領域

Timer Service

TP1/Client/J

TP1/Message Queue - Access

TPBroker OTMクライアント

TPBrokerクライアント

(Ｕ)

ua.conf

uCosminexus Batch Job Execution Server

uCosminexus Client

uCosminexus Operator

uCosminexus Operator

uCosminexus TP1 Connector

usrconf.properties

(Ｗ)

WARファイル

Webアプリケーション

Webクライアント構成

Webコンテナ

Webコンテナサーバ

Webサーバ

Webサーバ選択の指針

WebサーバとWebコンテナ（J2EEサーバ）の配置

Webサーバ連携

Webサーバ連携

Webシステム

Webフロントシステム

(ア行)

(あ)

アーカイブ形式

アウトプロセス

アクセスポイント

アクセスポイント

アクセスポイントになるコンポーネントの種類ごとに検討が必要な項目

アセンブル

アノテーション

アプリケーションサーバ

アプリケーションサーバ

アプリケーションサーバマシン

アプリケーション集中型の構成

アプリケーションで利用できる認証機能

アプリケーションの構成

アプリケーションの種類ごとにチューニングできる項目

アプリケーション分散型の構成

アプレット

(い)

イベントリスナ

インスタンスプーリング

インプロセス

インプロセスHTTPサーバ

インプロセスHTTPサーバ

(う)

運用監視エージェント

運用管理エージェント

運用管理コマンド

運用管理サーバ

運用管理サーバ

運用管理サーバ

運用管理サーバマシン

運用管理サーバモデル

運用管理サーバモデル

運用管理ドメイン

運用管理ドメイン

運用管理ポータル

運用管理ポリシー

(え)

エラーページのカスタマイズ

(お)

オブジェクトの寿命

オブジェクトの退避

(カ行)

(か)

ガーベージコレクション

ガーベージコレクション制御機能

拡張verbosegc情報

カスタムジョブ

カスタムログインモジュール

仮想サーバ

稼働情報収集機能

簡易Webサーバ

監査証跡

監査ログ

監視ツリー

管理対象オブジェクト（AdminObject）

(き)

機能ごとに必要なプロセス（Application Server以外によって提供されるもの）と提供するソフトウェア

機能ごとに必要なプロセスまたはモジュール（Application Server Enterpriseによって提供されるもの）

機能ごとに必要なプロセスまたはモジュール（Application Serverによって提供されるもの）

機能ごとに必要なモジュール（Application Server Enterprise以外によって提供されるもの）と提供するソフトウェア

機能ごとに必要なモジュール（Application Server以外によって提供されるもの）と提供するソフトウェア

機能レイヤ

機能レイヤ

業務指向ツリー

業務処理プログラム

共有スレッド数

(く)

クエリータイムアウト

クライアントアプリケーション情報

クライアント側のアプリケーションサーバ

クライアントマシン

クラスタ

クラスタソフトウェア

クラスタソフトウェアと連携したシステムの運用

グローバルCORBAネーミングサービス

グローバルセッション

グローバルセッションID

グローバルセッション情報

グローバルトランザクション

(け)

系

計画系切り替え

系切り替え

系切り替え

系障害

ゲートウェイ指定機能

現用系

(こ)

コネクション障害検知

コネクションスイーパ

コネクション数調節機能

コネクションプーリング

コネクションプーリング

コネクションプールのクラスタ化

コピーガーベージコレクション

コピーガーベージコレクションの仕組み

コミットオプション

コンテキスト

コンテキストルート

コンテナ拡張ライブラリ

(サ行)

(さ)

サーバ側のアプリケーションサーバ

サーバ管理コマンド

サーバ起動・停止フック機能

サーバ指向ツリー

サービス閉塞

サービスユニット

サーブレット

サーブレットエンジンモード

サーブレットフィルタ

作業手順書

(し)

システム構成に共通する留意点

システム構成の考え方

システム設計の流れ

システム設計の目的

システム全体の自動運転

システム全体の集中監視

システムの構成定義および構成管理

システムの分類に応じて必要なプロセス

実行系

実行待ちキュー

実行待ちキューサイズ

実パラメタ

自動系切り替え

シナリオ

ジョブ

ジョブネット

シングルサインオン

シングルサインオン情報リポジトリ

シングルサインオンライブラリ

侵入検知システム

侵入検知システム

(す)

スケールアウト

スケールイン

スケジュールキュー

スケジュールポリシー

スタック領域

ステートメントプーリング

スマートエージェント

(せ)

静的コンテンツ

静的コンテンツ

静的コンテンツのキャッシュ

性能解析トレース

性能解析トレースファイル

セキュリティアイデンティティ

世代別ガーベージコレクション

セッション

セッション制御

セッション制御

セッションフェイルオーバ機能

セッションフェイルオーバサーバ

セッションフェイルオーバサーバ

セットアップウィザード

占有スレッド数

(そ)

相互系切り替えシステム

相互系切り替えシステム

相互スタンバイ

相互スタンバイ

相互スタンバイ構成

(タ行)

(た)

待機系

(ち)

抽象パラメタ

チューニング手順

チューニング手順

チューニングの方法

チューニングの方法

(つ)

通常モード

(て)

データソース

データベースアクセス方法の最適化

データベースアクセス方法の最適化

テストモード

デプロイ

展開ディレクトリ形式

(と)

統合コンソール

統合スコープ

統合ネーミングスケジューラサーバ

統合ネーミングスケジューラサーバ

統合ネーミングスケジューラサーバモデル

統合ユーザ管理

統合ユーザ管理GUI

統合ユーザ管理のコンフィグレーションファイル

統合ユーザ管理フレームワーク

動作モード

同時実行数の最適化

動的コンテンツ

動的コンテンツ

トランザクションコンテキストのプロパゲーション

トランザクションサービス

トランザクションマネジャ

トレース取得ポイント

(ナ行)

(ね)

ネーミング切り替え

ネーミングサービス

ネーミングサービスの配置

(ハ行)

(は)

バインド先アドレス設定機能

バックシステム

バッチアプリケーション

バッチアプリケーション

バッチサーバ

パフォーマンスチューニング

パフォーマンスチューニング

パフォーマンストレーサ

ハンドラ

(ひ)

ビジネスインタフェース

日立トレース共通ライブラリ

非保護区

(ふ)

ファイアウォール

ファイアウォール

負荷分散機

物理コネクション

物理ティア

フルガーベージコレクション

フロントEJB

(へ)

ベーシックモード

別名

(ほ)

保護区

ホスト単位管理モデル

ホスト単位管理モデル

(マ行)

(み)

未決着トランザクション

(め)

メソッドキャンセル

メソッドキャンセル機能

メソッドタイムアウト機能

メッセージインフロー

面数

メンバリソースアダプタ

(ヤ行)

(ゆ)

ユーザ指定名前空間機能

ユーザ情報

ユーザ情報リポジトリ

ユーザスレッド

ユーザ認証ライブラリ

ユーザプロパティファイル

ユーザプロパティファイル

ユーザマッピング

ユーザログ

(よ)

予備系

(ラ行)

(ら)

ライトトランザクション

ライブラリJAR

ラウンドロビン検索

ラウンドロビンポリシー

(り)

リカバリ専用サーバ

リカバリ専用サーバ

リクエスト処理スレッド

リクエストのスケジューリング

リソースアダプタ

リソースマネジャ

リダイレクタ

リデプロイ機能

リバースプロキシサーバ

リモートインタフェース

リロード機能

(る)

ルートアプリケーション情報

ルートコンテキスト

ルートリソースアダプタ

(れ)

レイヤ5スイッチ

レイヤ5スイッチ

レルム

(ろ)

ローカルインタフェース

ローカルトランザクション

ローカル呼び出し最適化機能

ロードバランサ

ロール

ロガー

ログインモジュール

論理コネクション

論理サーバ

論理サーバ

論理ネーミングサービス

論理ユーザサーバ

論理ユーザサーバ

(ワ行)

(わ)

ワーカプロセス

■ 商標類

AIXは，米国における米国International Business Machines Corp.の登録商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
Borlandのブランド名および製品名はすべて，米国Borland Software Corporationの米国およびその他の国における商標または登録商標です。
CORBAは，Object Management Groupが提唱する分散処理環境アーキテクチャの名称です。
HP-UXは，米国Hewlett-Packard Companyのオペレーティングシステムの名称です。
IIOPは，OMG仕様によるORB(Object Request Broker)間通信のネットワークプロトコルの名称です。
Intelは，Intel Corporationの会社名です。
Itaniumは，アメリカ合衆国および他の国におけるインテル コーポレーションまたはその子会社の登録商標です。
Java及びすべてのJava関連の商標及びロゴは，米国及びその他の国における米国Sun Microsystems, Inc.の商標または登録商標です。
JDKは，米国 Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
Linuxは，Linus Torvaldsの米国およびその他の国における登録商標あるいは商標です。
Microsoftは，米国およびその他の国における米国Microsoft Corp.の登録商標です。
Microsoft Internet Information Servicesは，米国Microsoft Corp.の商品名称です。
Microsoft SQL Serverは，米国Microsoft Corp.の商品名称です。
OMG，CORBA，IIOP，UML，Unified Modeling Language，MDA，Model　Driven　Architectureは，Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。
ORACLEは，米国Oracle Corporationの登録商標です。
Oracleは，米国Oracle Corporation及びその子会社，関連会社の登録商標です。
Oracle9iは，米国Oracle Corporationの商標です。
Oracle 10gは，米国Oracle Corporationの商標です。
PA-RISCは，米国Hewlett-Packard Companyの商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標若しくは商標です。
Solarisは，米国Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
SQL Serverは，米国法人Sybase，Inc.の商標です。
Sun，Sun Microsystems，Javaは，米国Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
UNIXは，X/Open Company Limited が独占的にライセンスしている米国ならびに他の国における登録商標です。
Windowsは，米国およびその他の国における米国Microsoft Corp.の登録商標です。
Windows Serverは，米国Microsoft Corporationの米国及びその他の国における登録商標です。
Windows Vistaは，米国Microsoft Corporationの米国及びその他の国における登録商標です。
X/Openは，X/Open Company Limited の英国ならびに他の国における登録商標です。
Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).
プログラムプロダクト「P-9D43-7D71，P-9D43-7K71，P-9D43-7M71，P-9D43-7S71」には，米国Sun Microsystems,Inc.が著作権を有している部分が含まれています。
プログラムプロダクト「P-9D43-7D71，P-9D43-7K71，P-9D43-7M71，P-9D43-7S71」には，UNIX System Laboratories,Inc.が著作権を有している部分が含まれています。