第3回WebLogicServer勉強会＠大阪補足資料

<Insert Picture Here>

「第3回WebLogic Server勉強会＠大阪」の補助資料

2009年11月19日日本オラクル株式会社

Copyright© 2009, Oracle. All rights reserved. 2


WebLogicのアーキテクチャをご存知ですか？


• ドメインについて

• スレッド管理について

• データベース接続について

WebLogicアーキテクチャ


Oracle WebLogic Server 11g アーキテクチャ

• Oracle WebLogic Server 11g の基本的なアーキテクチャは、以前までのバージョンと同様

管理対象サーバ#2


管理サーバ

WebLogicドメイン

WebLogicクラスタ

Oracle WebLogic Server 11g (10.3.1)


ノードマネージャ

ノードマネージャ

マシンA

マシンB

管理サーバ

管理ツール（Admin Console/

FMW Control//WLSTなど）

ドメインログ

コンフィグレーションリポジトリ

JMX

JMX

JMX


WebLogicドメインに含

めることで、管理コンソール（FMW Control）か

らの管理が可能

WebLogic11g以降Oracle HTTP Server／Web Cacheとの統合

• Oracle HTTP Server 11g• Apache 2.2.10ベースにUpdate• Oracle WebLogic ServerのフロントHTTPサーバとして利用可能になった

• HTTPサーバを含めたトータルな運用管理、製品サポートが提供可能

• WebLogic Serverのフロントには、従来どおりApache / IIS / Sun One Webサーバも利用可能

• Oracle Web Cache 11g•リクエスト・フィルタリング

•レスポンスヘッダによるキャッシュ無効化などの新機能が追加管理対象

サーバ

管理対象サーバ

管理サーバ

OPMN

OracleHTTP

Server 11g

mod_wl_ohsOracleWeb Cache

11g

Oracle WebLogic Server 11g (10.3.1)

WebLogicクラスタ

•Apache標準モジュール+

•mod_plsql•mod_ossl•mod_osso•mod_dms

etc

ラウンドロビンによるロードバランス

OPMNによるプロセス管理/

監視

OPMN: Oracle Process Management and Notification Server

クラスタは必須ではな

い

WebLogicドメインに含め

ることで、管理コンソール（FMW Control）からの管

理が可能

HTTP(s) HTTP(s)HTTP(s)







WebLogic 9.0以降のスレッド制御イメージ

• 単一の実行スレッドプール。スレッドプール数は自動チューニング。

• ワークマネージャー（スレッド制御ポリシーをもったキュー）により、アプリケーションの実行優先制御が可能に

実行スレッドプール

バックログ

リッスンポート

マルチプレクサキュー

リッスンスレッドにより運ばれる

ソケットリーダスレッドにより

運ばれる

ワークマネージャーサブシステム

実行スレッド

リクエスト

ワークマネージャー


アプリケーションA

アプリケーションB

何らかの理由でリクエストが処理できない場合のバッファ

アプリケーションC


[参考]WebLogic 8.1以前のスレッド制御イメージ

• 複数の実行キューと実行スレッドプール

• スレッドチューニングは手動

実行キュー実行スレッドプール

バックログ

リッスンポート

マルチプレクサキュー

Defaultキュー

実行スレッド

リクエスト

実行キュー実行スレッドプール

カスタムキュー

実行スレッド

内部管理キューにもスレッドプールが存在

リッスンスレッドにより運ばれる

ソケットリーダスレッドにより

運ばれる何らかの理由でリクエストが処理できない場合のバッファ


• サーバ単位またはアプリケーション単位で設定可能

• AdminConsoleで設定またはアプリケーションのDDに記述

• 制約：スレッド割当時の制約

• 要求クラス：スレッド割当時の優先度

• ワークマネージャーを設定しない場合、defaultのワークマネージャが適用される

ワークマネージャーで設定できること

種類要求事項概要 Defaultワークマネージャーの値

大スレッド数制約同時実行可能なスレッドの大数を指定 -1（無制限）

小スレッド数制約実行用に低限保証されるスレッド数を指定 0

制約

容量制約ワークマネージャーのキューに受け付けることができるリクエストの大数（超えた場合はHTTP 503を

返す）

-1(無制限）

応答時間要求クラス必要な応答時間(msec)の指定からスレッド使用時

間の割合（他の設定値との相対となる）を指定設定なし

フェアシェア要求クラス平均スレッド使用時間（他の設定値との相対となる）を指定

設定なし

要求クラス

コンテキスト要求クラスユーザやグループと、応答時間要求クラスやフェアシェア要求クラスとを関連付ける

設定なし


• 制約や要求クラスを個別に定義する。

• ワークマネージャーを定義し、定義した制約や要求クラスを割当てる。

• ワークマネージャーをWebLogicサーバまたはアプリケーションに割当てる。

ワークマネージャーの設定イメージ


大スレッド数制約

小スレッド数制約

容量制約

要求クラス

WebLogicサーバ

アプリケーション

それぞれ設定可能

応答時間、フェアシェア、コンテキストの

いずれかを設定


• フェアシェア要求クラス

• アプリケーションAで、フェアシェア要求クラス10を指定

• アプリケーションBで、フェアシェア要求クラス20を指定

• アプリケーションCで、フェアシェア要求クラス50を指定

• 上記の設定で、高負荷でリクエスト投入時、スレッドの割当比率が下記のようになる。

• アプリケーションAのスレッドの割当比率は12.5%　（10/80)• アプリケーションBのスレッドの割当比率は25% (20/80)• アプリケーションCのスレッドの割当比率は62.5% (50/80)

• 応答時間要求クラス

• アプリケーションAで、応答時間要求クラス2000msecを指定

• アプリケーションBで、応答時間要求クラス5000msecを指定

• ★設定した時間の相対比率をベースにするため、応答時間が必ず設定通りにはならない

• 上記の設定で、高負荷でリクエスト投入時、アプリケーション実行時間が一定の場合

　　スレッド割当比率は下記のようになる。

• アプリケーションAは、Bに対して2対5になるようにスレッドを割当

• アプリケーションBは、Aに対して5対2になるようにスレッドを割当

ワークマネージャー：要求クラス設定例


• Defaultワークマネージャー構成を独自に上書きすることができる。その場合、default という名前

のワークマネージャーを構成すればよい。

• ワークマネージャーの大スレッド数と、JDBCデータソースの接続プール数を同じにするという設定が可能。（大スレッド数指定時にデータソースのJNDI名を指定。）

• すべてのワークマネージャーの大スレッド数　＜　スレッドプールの大プール数である必要がある。

• （スレッドプールの大プール数は、「ワークマネージャーの共有容量」という項目で、ワークマネ

ージャーとは別にサーバ単位で設定可能）

• すべてのアプリケーションでワークマネージャーを個別に設定する必要はない。実行優先度を上げたいアプリケーションにのみ、ワークマネージャーを構成する。

• 有償で利用しているユーザ向けとアプリケーション（無償利用のユーザに対して優先度を上げる）

• 管理用アプリケーションなど

ワークマネージャーを使用する上での知っておきたい事







Oracle WebLogic Serverにおける

データソースアーキテクチャ

WebLogic Serverデータソース

コネクションプール

Connection

データソース2


Connection

データソース1


マルチデータソース

データソース1

データソース２

JNDI ツリー

Lookup

DataSourceRAC

外部

Java Client

Lookup

DataSource

クラスタ化されたスタブ

非RAC

Servlet

EJB


ConnectionConnection

ConnectionConnectionConnection




• マルチデータソースとは？• 複数のデータソースをクラスタ化したもの

• 負荷分散とフェイルオーバーを実現

• データソースのリストを保持、管理

• 通常のデータソースと同じ方法で利用可能（特別な設定は不要）

• DBクラスタ環境を利用する場合においても、XAトランザクションを実現

データソース2


Connection

データソース1



データソース1

データソース2

RAC


ConnectionConnectionConnection

WebLogic Server



マルチデータソースのフェイルオーバー① アプリケーションからの接続要求② 順序付けされたデータソースリストからデータソースを選択③ 接続テスト（例：dual表へのselect発行）

失敗した場合は②のデータソースリストの次のデータソースを選択失敗したデータソースを無効化し、定期的に接続テスト（フェイルバックのため）

④ 正常な接続が返却され、SQL実行注）接続取得後のRACインスタンス障害はフェイルオーバーしない

データソース１


RAC1接続マルチデータソース

データソース1


RAC2

RAC1



①接続要求

障害

③接続テスト

失敗②リストからデータソース選択

（データソース1を選択）

④データソース2で再トライ

×

WebLogic Server

RAC1接続

RAC1接続

RAC2接続

RAC2接続

RAC2接続


[参考] RACにおける「サービス」の概念

「サービス」とは論理的な接続単位。アプリケーションは「サービス」を指定してデータベースに接続し、終的に「サービス」に関連付けされたノード（インスタンス）に接続する。Javaアプリケーションの場合、Oracle JDBC Driver(Oracle Net)の機能でRACサービス接続可能

「サービス」とDBインスタンスを関連つけて

定義する。

データベース・サーバー

データベース・クライアント

サービス定義により実現できること• サービスごとの統計の把握• サービスとノードの対応の動的変更• ノード間のロードバランス• 障害時のサービスのフェイルオーバー

SERVICE_A SERVICE_B

SERVICE_ASERVICE_B

RAC

Instance#1

Instance#2

Instance#3

Instance#4

#1と#2と#3のインスタンスで

利用可能なものに接続

#3と#4のインスタンスで

利用可能なものに接続


• Javaアプリケーションの場合、Oracle JDBC Driverを使用し、JDBC URLを下記のように指定することでOracle Netの機能によるRACサービスを指定した接続が可能に

なります。

• WebLogicでは、データソース構成時にJDBCのURLを下記のように指定します。

　（下記はOracle JDBC Thinドライバでの使用例です。）

[参考] JavaアプリケーションからのRACサービス接続指定

jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP) (HOST=host1.jp.oracle.com) (PORT=1521))(ADDRESS=(PROTOCOL=TCP) (HOST=host2.jp.oracle.com) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=serviceA)))


これまでのWebLogicにおけるRAC接続

マルチデータソース利用の場合

RACのインスタンス毎にデータソースを構成

アプリケーションはRACサービスを指定した接続は行なえない。

接続要求はマルチデータソースにより、RACサービスに関係なく分散される。

RACのXAトランザクション制限の意識不要

データソース1 データソース2 データソース3

WebLogic

データソース1

WebLogic

データソース2




サービスA サービスB

Oracle Netの機能を利用の場合

RACサービス接続指定されたデータソースを構成。

アプリケーションはRACサービスに対応するデータソースを指定して接続を行なう。（RACサービス指定可能）

接続要求はRACサービス設定に基づき分散される。

RACのXAトランザクション制限に対して何かしらの措置が必要


WebLogic11gにおけるGridLink for RAC

マルチデータソースにおけるRACサービス指定を可能にRACサービス毎にマルチデータソースを構成

データソースは、サービス指定を行いRACノード数分用意する。

アプリケーションはRACサービスに対応したマルチデータソースを指定して接続する。

　　（RACサービス指定接続が可能）

接続要求はRACサービス設定基づき分散される。

RACのXAトランザクション制限の意識不要


WebLogic11g アプリケーション

マルチデータソース（サービスA用）


マルチデータソース（サービスB用）

サービスA サービスB

ACTIVEACTIVE ACTIVEACTIVE ACTIVEACTIVE

RACサービス数=マルチデータソース数

マルチデータソースに含まれるデータソースの数=RACインスタンス数

RACインスタンスの数だけ、データソースを設定しておく。（インスタンス「RAC3」はFINサービスが構成されていないため、データソ

ースは無効化状態）


GridLink for RAC のメリット

GridLink for RACによるメリット

RACサービスのリソース配分の変更をAPサーバー側で動的に検出し、対応

することが可能（WebLogic Server側では意識をする必要がない）

FIN用マルチデータソース

HR用

マルチデータソースデータソース

#1

データソース

#2

データソース

#3

データソース

#1

データソース

#2

データソース

#3

RACインスタンス#1

RAC インスタンス#2


FINサービス HRサービス

Oracle RAC

WebLogic Server

FIN用マルチデータソース

HR用

マルチデータソースデータソース

#1

データソース

#2

データソース

#3

データソース

#1

データソース

#2

データソース

#3

RACインスタンス#1



FINサービス HRサービス

Oracle RAC

WebLogic Server

通常時②FIN用データソース

#2がINACTIVEになり、HR用データソース#2

がACTIVEになる

③WebLogic Server側ではデータソースの設定を特に変更せず、RACのリソー

ス配分に対応可能HRの負荷が高まる

①HRサービスの負荷が高まったためRACサービスのリソース配分

を変更


GridLink for RACの構成

データソース構成にてRACサービス指定が可能Oracles's Driver (Thin) for RAC Service-Instance connectionsOracle's Driver (Thin XA) for RAC Service-Instance connections

New

管理コンソールから設定できるデータベースの種類に「Service-Instance」接続が追加

【生成される接続文字列】

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=racdb-

vip)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=SERVICE1)(INSTANCE_NAME=INST1)))



運用ツールを使いこなせ


Oracle WebLogic Serverの運用管理ツール

• Oracle WebLogicに対する各種管理操作を行うには、下表のツールを使用します。

• 下表以外に、管理APIとして様々なJMX MBeanを利用可能です。

管理タスクツール名概要

ドメイン作成 Configuration Wizard ドメインの作成で使用する。

GUIモード、コンソールモード両方サポート

管理コンソール Webベースの管理コンソールアプリケーション。管理サ

ーバが起動している場合、利用できる。

ドメインにおける各種管理操作やモニタリングを行える。

WebLogic Scripting Tool（WLST) Jythonベースで管理タスクを実行できるスクリプト・ツー

ル。プラットフォームに依存しない。

weblogic.Deployer Javaコマンドでアプリケーション・デプロイを行うユティリ

ティ

ドメイン作成後の

各種構成

Fusion Middleware Control（11gR1より）

モニタリングとアプリケーションのデプロイ/アンデプロイ。

Oracle HTTP Serverとの連携構成。

（WebLogicだけでなくSOA製品など統合管理）


JVMの監視・分析ツール

• JVMに対する監視・分析ツールには下表のようなものがあります。JVM ツール名概要

JRockit JRockit Misson Control オラクルが提供するJRockit用の診断・分析ツール。

非常に強力なプロファイリングや診断機能を提供。

Memory Leak Detectorや、JRockit Runtime AnalyzerやLatency Analyzerなど、さまざまな分析機能をGUIから利用可能

Sun JDK,JRockit,その他

HPやIBMのJVMなど

Oracle Application Diagnostics for Java(AD4J)

オラクルが提供するJVM診断・分析ツール。

Sun JDK jconsole Sun JDKに含まれるツール

JVMのヒープやスレッドや状況を監視。MBeanブラウザ

も利用可能

Sun JDK Visual VM Sun JDK1.6に含まれるツール

ヒープ利用状況分析やスレッドのロック等の分析も可能


WebLogic Scripting Tool(WLST) とは？

• 管理コンソールと同様に、 WebLogic Server の管理、運用の操作に使用できるコマンドラインスクリプト環境

• Built on Jython 2.1• 100% pure java のPython 実装

• OS/プラットフォームに依存しない

• WebLogic Server 9.x から利用可能

• WebLogicのMBeanを（比較的容易に）操作可能

• WLSTのオンラインモード

• 構成を行う場合は管理サーバ接続

• 監視を行う場合は、対象の管理対象サーバに接続

• WLSTのオフラインモード

• 管理サーバや管理対象サーバに接続していない状態

• ドメインのコンフィグレーション・ウィザードと同じ機能を提供


WLSTの操作方法

• WLSTを起動

• WL_HOME/server/bin/setWLSEnvを実行して必要な環境変数を設定後、下記を実行

• >java weblogic.WLST• WLSTのプロンプトとして下記が表示される

• wls: (offline)>

• 管理サーバに接続（オンライン）状態にする

• wls: (offline) >　connect(‘weblogic’, ‘welcome1’)

• WLSTスクリプト・ファイルを実行する

• WLST起動とともに実行：> java weblogic.WLST <filename.py>• WLST起動後に実行： wls: (offline) > execfile(‘filename.py’)


WLSTを使う上で知っておこう

• WLSTは、WebLogicの構成や監視をコマンドライン操作で行える強力なスクリプティング・ツール

• ただし….• PythonであれJythonであれ、ある程度の「慣れ」が必要

• OSのスクリプトに慣れきった人には逆に使いにくいかも。

• →管理コンソールでの操作をレコーディングし、WLSTを自動生成可能

　　（WLS10.0以降）

• WLSTの使いどころ• アプリケーションのデプロイであれば、weblogic.Deployerでも十分

• レコーディング機能を活用し、一から作成する手間を省く


スクリプト例WebLogic Server のスレッドプールをモニタする

# ThreadPoolRuntimeMbean の情報を取得する関数def getThreadPoolInf(threadPoolRuntime):

# 実行スレッドの総数を取得oExecuteThreadTotalCount = threadPoolRuntime.getExecuteThreadTotalCount()# アイドルスレッドの数を取得oExecuteThreadIdleCount = threadPoolRuntime.getExecuteThreadIdleCount()# STANDBY スレッドの数を取得oStandbyThreadCount = threadPoolRuntime.getStandbyThreadCount()# ACTIVE スレッドで実行中スレッドの数を取得oRunActiveThread = oExecuteThreadTotalCount-oExecuteThreadIdleCount-oStandbyThreadCount

head = "----------[" + time.strftime('%Y-%m-%d %H:%M:%S') + "]----------"sExecuteThreadTotalCount = "ExecuteThreadTotalCount : " + str(oExecuteThreadTotalCount)sExecuteThreadIdleCount = "ExecuteThreadIdleCount : " + str(oExecuteThreadIdleCount)sStandbyThreadCount = "StandbyThreadCount : " + str(oStandbyThreadCount)sRunActiveThrea = "RunActiveThread : " + str(oRunActiveThread) # 取得した情報をリストで返却return [head,sExecuteThreadTotalCount,sExecuteThreadIdleCount,sStandbyThreadCount,sRunActiveThrea]

[ThreadMonitor.py]


スクリプト例WebLogic Server のスレッドプールをモニタする

（続き）

# ファイルに情報を書き出す関数def outputFile(oList):

# 追記モードでファイルを作成f = open('c:/temp/test.txt', 'a')# リストの情報をファイルに書き出しfor i in range(0,len(oThreadRuntimeInf)):

f.write(oList[i] + "¥n")f.close()

# WebLogic Server に接続connect('weblogic','weblogic','t3://localhost:7001')# Python time モジュールをインポートimport time# Python traceback モジュールをインポートimport traceback# ServerRuntimeMbean に接続serverRuntime()# ThreadPoolRuntimeMbean を取得oThreadPoolRuntime = getMBean('ThreadPoolRuntime/ThreadPoolRuntime')


スクリプト例WebLogic Server のスレッドプールをモニタする（続き）

while(true):try:

# ThreadPoolRuntimeMbean 情報を取得oThreadRuntimeInf = getThreadPoolInf(oThreadPoolRuntime)

# ThreadPoolRuntimeMbean の情報を出力for i in range(0,len(oThreadRuntimeInf)):

print oThreadRuntimeInf[i]

# ThreadPoolRuntimeMbean の情報をファイルに書き出しoutputFile(oThreadRuntimeInf)# 5秒間待機time.sleep(5)

except:# 例外が発生した場合、例外を出力print "<<<error>>>"traceback.print_exc()break


TIPS

• prompt()• プロンプトの表示／非表示を切り替える

• find()• 現在の階層の MBean から文字列を検索する

• jndi()• JNDIツリーを表示するモード

• help()• コマンドおよび変数に関する情報を表示

• easeSyntax() コマンド（非サポート）

• 一部のコマンドを簡易入力することが可能

• java weblogic.WLST -easeSyntax



[ご参考]Oracle Application Diagnostics for Java (AD4J)のご紹介


Javaアプリケーション障害対応における課題

• 本番環境での問題調査には制約がある

• 本番環境の問題に対して、十分に深く診断できない

• 診断ツール自体が本番環境に向いていない

• 他の環境（テスト環境など）で問題の再現するのが困難

• Javaアプリ + DBの統合的・横断的な調査や分析ができない

• 性能劣化問題発生→ボトルネックの調査が必要

• DBは、DBエキスパート技術者がトレースを取得、調査

• Javaアプリは、Javaエキスパート技術者がログやJavaVM性能情報を取得、調査

• DB SessionとJavaアプリのスレッドの結びつけを意識した調査が困難

• ２名のエキスパートが時間をかけて調査してようやく問題が見つかるかどうか

問題解決の長期化

技術者育成コストの増大

問題発生時に膨大な作業が必要


AD4Jを使用することにより、管理者はJavaアプリケーションの状態をプロアクティブに監視し、問題発生時にボトルネックとなっているオブジェクトを素早く特定することができます。AD4Jを使用することにより、管理者はJavaアプリケーションの状態をプロアクティブに監視し、問題発生時にボトルネックとなっているオブジェクトを素早く特定することができます。

Javaアプリケーションの詳細な分析~ Application Diagnostics for Java（AD4J） ~

製品の特徴・負荷が軽く、本番環境で使用可。・AS層、DB層にまたがるトランザクションを追跡

・ほとんどのアプリケーション・　サーバーやJVMをサポート・インストール/セットアップが簡単。・Agentデプロイ時に再起動の必要なし。

[J2EEアプリケーションの監視]

主な用途・異常を早く検知したい。（しきい値設定とメール／　SNMPトラップの通知）

・メモリ・リーク時の原因オブジェクトを特定したい。・デッドロックのオブジェクトを検出したい。・パフォーマンス劣化の原因となっているオブジェクトを特定したい。・定常的にJavaVMの状況を監視したい

AD4J

本番環境

Agent

Agent AS

DB

EM10gR4EM10gR4


OracleDBとJavaVM間で横断的にトレース

ボトルネック原因となっているDB状況

DB処理待ちスレッドを特定

問題となっているSQL文

• JavaスレッドからDBセッションま

でトレース

– DB処理待ちの実行中のJavaスレッドを特定

– 発行SQLまでドリルダウン

• DBセッションからJava スレッドま

でトレース

– 待機状態やロック状態のDBセッションを表示

– DBセッションを保持しているJavaスレッドを特定


差分ヒープ分析

• オフライン分析用にメモリーの完全なスナップショットを作成

• 各オブジェクトからアクセス可能なメモリーを表示

• 複数スナップショットを比較して、メモリーの増加を追跡

• （ルートからの）トップダウン分析またはボトムアップ分析が可能

ロードされているクラスと使用メモリの統計

ヒープ間での使用メモリ差分


なぜAD4Jは低オーバーヘッドなのか？Javaプロファイラの実装方式

• AD4Jはサンプリング方式を実装することにより低オーバーヘ

ッドを実現している

実装方式詳細

JavaVMPI/JavaVMTI Java SDKで提供されるJavaVMの挙動を監視し、情報収集するためのインタ

ーフェース。詳細な情報を取れる反面オーバヘッドがかなり大きい。

[JDeveloperプロファイラ]

（dynamic)ByteCodeInstrumentation(BCI)又はByteCodemodification

バイトコードを操作して、プロファイリングのためのコードを埋め込む方式。

埋め込む量が多くなればオーバヘッドが大きく、少なければ得られる情報が限られてしまう。

サンプリング情報を収集したい時点のみのスナップショット(JavaVM、メモリヒープ)を取り分

析する方式。オーバヘッドは小さいが、その分得られる情報も限られる。

[AD4J]


AD4Jによって解決できる問題例

1. 連続的なDB接続によりJavaロックが発生しアプリケーショ

ンのレスポンスが遅い場合の原因究明

2. 中間層のCPU使用率が高い → もコストの高いクラス/メソッドを発見

3. ユーザのリクエストがハングしたとき、現在の状態と関連するコード中の行数を検知

4. GCが多発しリソースをほぼ使いきりアプリケーションが遅く

なってしまった場合メモリリークの原因を発見

5. レスポンスの遅いSQL文に紐づくJavaスレッドを特定



設計・開発手法、これを押さえろ


• アプリケーションの設計について

• データベースのアクセスモジュールの設計について

• WebLogicサーバの設計について

• 仮想化環境について

設計・開発手法について

Copyright© 2009, Oracle. All rights reserved.

一般的な JavaEEアプリケーションのレイアリング

ユーザインターフェース層

アプリケーション層　(コントローラ層）

サービス層

ドメイン層

パーシステント層

ユーザに対する画面の描写、ユーザからの入力の受付の制御等

ユーザ入力値の検証、画面遷移の制御等

• 下図は一般的なJavaEEアプリケーションの論理的なレイアリングとその役割を表します。

ドメイン層のロジックをアプリケーション層から利用しやすいように抽象化、ビジネスロジックのワークフロー制御

、トランザクション等

対象となる業務のドメインロジック（ビジネスロジック）等

メイン層のオブジェクトをデータストアに対して永続化するためのロジック。典型的には、リレーショナル

データベースに対してアクセスするSQLのコードを含むいわゆるDAO(Data Access Object)はこの層

42


一般的な Java Webアプリケーションと実装技術の関係

ユーザインターフェース層

アプリケーション層　(コントローラ層）

サービス層

ドメイン層

パーシステント層

JSP(Struts)/JSF

実装形態Plain Java Class

EJB

実装形態Plain Java Class

（フレームワークにより提供するクラス含む）EJB（JPA)

Hibernateや他O/Rマッピングツール利用ケースあり

Servlet/Struts/JSF

• Eclipseであれ JDeveloperであれ各レイアを実装する機能は標準的に装備

43

Copyright© 2009, Oracle. All rights reserved.Copyright© 2009, Oracle. All rights reserved. | 44

一般的な Java Webアプリケーションの実装におけ

る課題点• 各レイア間のつながりを、極力、疎結合にすることが望ましい。

• 密結合になると、修正の局所化が困難になる。

• DAOで取得したデータをBusiness Logicにいかに渡すか

• モデリングとしては、ResultSetデータでフェッチしたデータをJava Object化するのが王道。

　　　　ただし、この処理は一般的に重い。

• DAO部分を自動生成するフレームワークを使用した場合、適切なSQLが生成されるか

登録

Servlet

Business Logic

DAO DAO

Business Logic

DAO

Service

1件登録されました

登録画面

SQL

44

Copyright© 2009, Oracle. All rights reserved.Copyright© 2009, Oracle. All rights reserved. | 45

一つの解決策として….

• Oracle Coherenceのようなアプリケーションで利用するObjectのキャッシュ・サーバを設置する。

• アプリケーションは、標準のJPAでDAOを実装するが、自動的にCoherenceにアクセスさせる（TopLink Gridにより、アプリはCoherence APIを利用する必要なし)

登録

Servlet

Business Logic

DAO DAO

Business Logic

DAO

Service

1件登録されました

登録画面

TopLink GridによりCoherenceアクセス

Oracle Coherence Oracle Coherence

45


TopLinkGridとは

• TopLinkのL2キャッシュもしくはデータストアそのものとしてCoherenceをシームレスに利用することが可能（＝TopLink Grid）

• メリット• DBの負荷軽減

• Java SE環境でも利用可能

• Coherence分散キャッシュの機能を活用可能（拡張性、クエリ機能など）

• 動作パターン• Coherence Read

• JPAの読取り（find,Query）をCoherenceにリダイレクト

• 書込みはJPAで実行• Coherence Read/Write

• JPAの読取り、書込みをCoherenceにリダイレクト

• Coherence L2 Cache• CoherenceによるL2キャッシュの実装

• キャッシュヒットは主キーアクセスのみ

TopLink と組み合わせた場合の動作

Application

EntityManager API(find, query, persist, merge)

Cache API(get, put, filter)

TopLink JPA

CacheLoader/Store

SQL

SQL

Coherenceによる

分散キャッシュ

CacheLoader/StoreによりDBから読取り、書込み


• アプリケーションの設計について

• データベースのアクセスモジュールの設計について

• WebLogicサーバの設計について

• 仮想化環境について

設計・開発手法について


仮想化サーバの市場動向:3年後の2011年にはサーバーの4割が仮想化を採用

• x86サーバーにおける仮想化の普及が市場を牽引

• 仮想化技術の成熟

• OS標準や無償提供による敷居の低下

• 逆に言えば、3年後であっても6割は非仮想化環境サーバー

• ユーザの要件により仮想化か非仮想化かを選択できる時代

国内仮想化サーバー市場出荷台数予測、2004年～2011年

IDC Japan: 2008年国内サーバー市場仮想化技術の導入動向調査


仮想化におけるコスト・メリットと注意点

• 仮想化で減るコスト• サーバー代（保守料含む）

• 電気代、設置スペース代

• 運用管理コスト etc

• 仮想化で増えるコスト• 仮想化ソフトウェアライセンス（保守料含む）

• 外部ストレージ代（保守料含む）

注意点は、サーバー代の削減幅を上回る程のコストが仮想化の導入で掛かってしまう可能性があること


仮想化の適用範囲について

• システム構成の中では Web APサーバの層がもサーバ数が多くなる傾向にある。

• 仮想化の適用を検討した場合、Web APサーバ層がも効果が出る可能性が高い。

LoadBalancer/Fire Wall

Rich Client（C/C++)

Webシステム

モバイルシステム

RSS（Excel)Rich Client（C/C++)

Webサーバ層

アプリケーションサーバ層HTTP

HTTP

クライアント層クライアント層 APAPサーバ層サーバ層データベース層データベース層

永続的にデータを保持する永続的にデータは保持しない

Disk中のデータは原則一元管理で

分散しない

（Oracle RAC）データを処理する

DBインスタンスのサーバ

は増加可能。ただし、データ整合性維持のためサーバ数増加はAPサーバほど容易

ではない

負荷や可用性要件に応じて、サーバを増加させる

ことが比較的容易

Disk

DB Instance

Oracle RAC

拡張拡張拡張


仮想化事例: オラクル

• Oracle VM の Oracle Corporation 社内導入効果• Oracle On Demand - ホスティング, SaaSサービス

• サーバー数を1/3に削減

• CPU使用率が9%から55%に改善

• Oracle University - 研修

• サーバー数を1/6に削減

• 設置スペースを50%削減

• データセンターの電力使用量を40%削減

• Oracle Development - 開発/検証

• 容易な環境構築が可能に

• サーバー利用の大幅な効率化


仮想化とAPサーバについて

• ユーザの要件により、仮想化環境か非仮想化か選択可能な時代になっています。

• 仮想化の適用判断について

• 下記のケースでは仮想化環境を検討する余地があるといえます。

• 現在、物理サーバが多いことによりコストや運用負荷が高いケース

• 将来、物理サーバ増加が見込まれ、コストや運用負荷が増加する可能性があるケース

• 仮想化の適用先について

• Webシステムの構成においては、その構造上、Web APサーバのサーバ台数がも増加する傾向にあるため、Web APサーバを統合・仮想化することでも効

果を出す可能性が高いといえます。


[ご参考]Oracle WebLogicが対応している仮想化環境

• 下表は2009年11月13日時点での情報で、下記URLからの抜粋です。

仮想化/分割化技術プラットフォームオペレーティングシステム

Oracle VM IA32IA64

RedHat LinuxOracle Enterprise LinuxWindows

IBM LPAR (IBM WPARは不可)

IBM AIX Power AIX 5.3AIX 6.1

nPar (static nPar のみ) Itanium-2 HP-UX 11.23HP-UX 11.31

Sun Containers Sun Solaris SPARC Solaris10 SPARC

詳細は下記をご参照ください。http://www.oracle.com/technology/products/ias/hi_av/oracleas_supported_virtualization.html


JRockitを極める – パラレル/コンカレント＆世代別/シングルスペース


パラレルGCとコンカレントGC

•※ 4CPU環境におけるスレッドとＧＣの関係

GC実行

GC終

了

パラレルＧＣ（主流）

GC実

行

GC終

了

GC実

行

コンカレントＧＣ

STOP-THE-World!!

デフォルトＧＣ

STOP-THE-World!!


シングルスペースGCと世代別GC

Heap領域Single

Young(Nursery)

Two-Generational GC

Single-Space GC

・全体をGC

Old

・Young GC・Promotionフェーズ　(Oldへのオブジェクトの移動)

・Old GC

シングルスペースGCは、オ

ブジェクトの移動を小化することでGCコストの総量

を抑えます。

世代別GCは、オブジェクト

の生存期間に適した処理を行うことで、効率的なGC制

御を行います。


Sun JVM vs JRockit 世代別GC の違い

• Sun JVM の New GC(ScavengeGC)は、オブジェクトがプロモーションされるまでに大32回New領域内を移動しつつ留まり続けます。JRockit の NurseryGCは、オブジェクトがNursery領域内を移動することが無く1回のGCでプロモーションされます。

Heap領域New 領域To

Heap領域

Old 領域

Nursery Old 領域

From

大32回で

プロモーション

Eden

0 1 32

0 1

Sun JVM

JRockit1回でプロ

モーション

Perm領域

中寿命オブジェクト数とコンパクションの効率に対する両社の考え方の違いが反映されています。


JRockitを極める – 奨励パラメータ


静的GCと動的GC

• 静的GC( Static GC )• -Xgc オプションで、使用する GC 戦略を設定

• Single-Spaced Parallel （-Xgc:parallel）• Single-Spaced Concurrent （-Xgc:singlecon）

• Generational Parallel ( -Xgc:genpar)• Generational Concurret （-Xgc:gencon）

• 動的GC( Dynamic GC )• -XgcPrio オプションで、使用する GCモードを設定

• スループット重視（ -XgcPrio: throughput ）• 停止期間の均等化重視（-XgcPrio: pausetime ）• 停止期間とGC間隔の固定化重視 ( -XgcPrio: deterministic )

deterministicは別ライセンスが必要です。


GCアルゴリズムの選択

• 静的GCの世代別パラレルGCが簡単でお勧め

• 動作が固定でチューニングが簡単

• 静的アルゴリズムなので、動的判定のコストがかからない（動的GCだとGCログが煩雑となる）

• Appサーバのような24時間動き続ける環境では、生存期間の長いオブジェクトが存在するため有利

Nursery GC Nursery GCOld GC


Heapサイズの指定

• 小と大ヒープサイズの設定

• ヒープサイズを指定する際には、小サイズと大サイズを同じ値にすることをお勧めします。

# java -Xmx:1500m -Xms:1500m

• ヒープサイズを拡張する際のコストを抑えることができます。


• 32-bit OSのプロセスサイズの制限• 32-bit OSではOSの仮想プロセスサイズ以上にヒープサイズを確

保することはできません。例えば、32-bit ReaHat Linuxでは仮想プロセスサイズは2Gとなっています。

• 上記の場合、-Xmx 1500mを設定した場合、ネイティブ領域は500mとなります。ネイティブ領域を利用するアプリケーションが多

い環境では、ヒープ領域を減らしてネイティブ領域を増やす必要があります。

Heapサイズの指定（つづき）

　　　　　Javaヒープネイティブメモリ

プロセスサイズ

-Xmx


• JVMは32bit版の方がパフォーマンス的に有利• 32bitメモリ空間

• GCについて

• 32bit Native APIとJVMの内部実装

• JVMのHeapが足りない場合は64bit化よりもAPの分散化を検討

63

32bit版 JVMの勧め


コード適化オプション

• JRockitは効率的な機械語を生成するために、自JVM内

でのプログラムの性能を絶えず解析し、適化を実施しています。

• 数値計算を行うような複雑で長時間動き続けるプログラムなどでは、非常に高いパフォーマンスを発揮します。

• ただし、WebLogic Serverのようなアプリケーションサーバではネットワークの通信レイヤがボトルネックとなり、JRockitのコード適化の恩恵を受けにくい。

• 稀に安定しないケースも発生

• -XnooptオプションにてOFFでも可


lazyUnlockingオプション

• R27.5： -XXlazyUnlocking:enable=<true|false>• R27.4： -XXlazyUnlocking

• JDK6.0ではデフォルトで有効

• JDK5.0と1.4.2ではデフォルトで無効

• lazyUnlockingオプションを有効化すると、スレッドのロックの解放がその時点では有効にならず、次に同じスレッドからのロックが発生した際のコストを下げることができます。全ての局面において、有効化した方がパフォーマンスが良くなります。


jrcmdによる運用監視について

• jrcmdのprint_object_summaryやheap_diagnosticsコマンドを定期的に発行して、本番機のメモリ情報を取っている場合、FullGCが多発します。

• jrcmdで「Heap情報を取得する」コマンドを実行した場合、FullGCさせることでメモリ情報を取得しています。ただし、これはパフォーマンス的には問題。

• jcmdの利用は低限にして、定常的なメモリ情報などはJMXを使ったMbeanの監視を行うようにしてください。


JRockitのGC関連オプション

-XclearType-Xgc-XgcPause-XgcPrio-XgcReport-XnoClassGC-XpauseTarget

-X-XXaggressive-XXallocClearChunks-XXallocClearChunkSize-XXallocPrefetch-XXallocRedoPrefetch-XXcompactRatio-XXcompactSetLimit-XXcompactSetLimitPerObject-XXdisableGCHeuristics-XXexternalCompactRatio-XXfullCompaction-XXfullSystemGC-XXgcThreads-XXgcTrigger-XXheapParts-XXinitialPointerVectorSize-XXinternalCompactRatio-XXkeepAreaRatio-XXlargeObjectLimit-XXmaxPooledPointerVectorSize-XXminBlockSize-XXnoCompaction-XXnoSystemGC

-XX-XXpointerMatrixLinearSeekDistance-XXprintSystemGC-XXsetGC-XXstaticCompaction-XXthroughputCompaction-XXtlaSize-XXusePointerMatrix-XX:MaximumNurseryPercentage


障害分析テクニック – スレッドダンプがとっても大事


WebLogic Serverでの障害のパターン化

• WebLogic Serverのハング/無応答

• Javaヒープメモリの使用量が徐々に増え続けていく

• JDBC接続でデータベースからの応答が悪くなる

• プロセスがCPU100%となり応答が返らなくなる

これらの障害解析においてスレッドダンプ情報の取得は必須！


Javaスレッドダンプとは

• Javaスレッドダンプは、JVM(サーバ)プロセスの全スレッ

ドのスナップショットです。

• テキスト形式で標準出力もしくは標準エラーに出力されます。

• 数秒～数十秒間隔で複数回取得することでサーバの動きを確認することができます。

• 標準出力と標準エラーはファイルにリダイレクトしておくことをお勧めします。WLSではWLS_REDIRECT_LOG環

境変数で制御できます。

-- startWebLogic.cmd --set WLS_REDIRECT_LOG=stdout.out


Javaスレッドダンプの取得方法

UNIXプラットフォームの場合• # kill -3 <PID>

Windowsプラットフォームの場合• コマンドプロンプト上でCtrl-Breakキー

WebLogic Scripting Tool• ％ threadDump(“hogehoge/dump.out”)

11

22

33


復習：WLSのアーキテクチャ

BEA WebLogic

リクエスト実行スレッドソケットリーダスレッドListenスレッド

7001Port

バックログ

Muxerキュー

WebApp A

ワークマネージャ

WebApp B

EJB A

スレッドプール


WLSスレッドとスレッド名の対応表

WLSのスレッドスレッドダンプで取得した際の

スレッド名

実行スレッド weblogic.kernel.Default (self-tuning)

ソケットリーダースレッド weblogic.socket.Muxer

Listenスレッド DynamicListenThread[Default]


典型的なハングの例）全ての実行スレッドがDBからの応答待ちでハング

Oracle からの応答待ちでハングしているスレッドダンプの例"[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x004706f8 nid=0xb runnable[0xf2c7e000..0xf2c7fc48]

at java.net.SocketInputStream.socketRead0(Native Method)at java.net.SocketInputStream.read(SocketInputStream.java:129)at oracle.net.ns.Packet.receive(Unknown Source)at oracle.net.ns.DataPacket.receive(Unknown Source)at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)at oracle.net.ns.NetInputStream.read(Unknown Source)at oracle.net.ns.NetInputStream.read(Unknown Source)at oracle.net.ns.NetInputStream.read(Unknown Source)at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:979)at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:951)at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:435)at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:185)at oracle.jdbc.driver.T4CPreparedStatement.execute_for_describe(T4CPreparedStatement.java:503)at oracle.jdbc.driver.OracleStatement.execute_maybe_describe(OracleStatement.java:951)at oracle.jdbc.driver.T4CPreparedStatement.execute_maybe_describe(T4CPreparedStatement.java:535)at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1046)at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:2905)at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:2946)- locked <0xac8d7510> (a oracle.jdbc.driver.T4CPreparedStatement)- locked <0xb606b0d0> (a oracle.jdbc.driver.T4CConnection)at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:100)at jsp_servlet._jdbc.__jdbc._jspService(__jdbc.java:121)at weblogic.servlet.jsp.JspBase.service(JspBase.java:34)…


<Insert Picture Here

Oracle Advanced Customer Servicesのご紹介


Oracle Advanced Customer Services

• ACSはお客様のミッションクリティカルな情報システムを24時間365日体制で対応するための、ハイエンドなサポート

サービスです。

• 日本オラクルのエキスパートで編成される専用のサポートアカウントチームを作り、お客様システムの運用保守を支援します。


ACS BEA product offierings

• BEA Troubleshooting Methodologies Workshop• WebLogic Serverの典型的な障害（サーバハング、サーバcore、

CPU100%、メモリリークなど）をパターン化し、問題解決のノウハ

ウをワークショップ形式で提供します。

• BEA Migration Support Service• 旧バージョンのWebLogic Serverから新バージョンへの

Upgradeを、Oracleの（元BEAの）経験豊富なエンジニアが支援

• ドメインアップグレード手順書の作成

• 新旧WLSバージョンにおける非互換情報の提供


サポート期間（抜粋）

リリース GA Date Premier Support Ends

Extended Support Ends

SustaininSupport Ends

WebLogic Server/Express 8.1 2003年3月 2009年9月 2011年9月無期限

WebLogic Server/Express 9.x 2005年6月 2011年11月 2013年11月無期限

WebLogic Server/Express 10.x 2007年3月 2013年5月 2016年5月無期限

WebLogic Server/Express 10.3 2008年8月 2014年1月 2017年1月無期限

Tuxedo 8.1 2003年2月 2010年2月 2011年2月無期限



Tuxedo 10.x 2007年9月 2013年9月 2015年9月無期限


WebLogic Integration 8.1 2003年7月 2009年9月 2011年9月無期限

WebLogic Integration 9.x 2006年11月 2011年11月 2013年11月無期限

WebLogic Integration 10.x 2008年5月 2013年5月 2016年5月無期限

WebLogic Integration 10.3 2008年12月 2014年1月 2017年1月無期限


Technology

第3回WebLogicServer勉強会＠大阪 補足資料

第3回WebLogicServer勉強会＠大阪補足資料