• Like
第3回WebLogicServer勉強会@大阪 補足資料
Upcoming SlideShare
Loading in...5
×

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

  • 9,578 views
Uploaded on

2009年11月19日に開催された第3回WebLogic Server勉強会@大阪の補足資料です。

2009年11月19日に開催された第3回WebLogic Server勉強会@大阪の補足資料です。

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
9,578
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
221
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. <Insert Picture Here> 「第3回WebLogic Server勉強会@大阪」の補助資料 2009年11月19日 日本オラクル株式会社
  • 2. <Insert Picture Here> WebLogicのアーキテクチャをご存知ですか? Copyright© 2009, Oracle. All rights reserved. 2
  • 3. WebLogicアーキテクチャ • ドメインについて • スレッド管理について • データベース接続について Copyright© 2009, Oracle. All rights reserved. 3
  • 4. Oracle WebLogic Server 11g アーキテクチャ • Oracle WebLogic Server 11g の基本的なアーキテクチャは、以前までのバージョンと同様 WebLogicドメイン マシンA WebLogicクラスタ 管理サーバ ドメイン ログ JMX 管理対象 管理 コンフィグ サーバ#1 レーション JMX サーバ リポジトリ JMX ノード マネージャ 管理対象 サーバ#2 マシンB 管理対象 管理ツール サーバ#3 (Admin Console/ ノード FMW Control/ マネージャ /WLSTなど) Oracle WebLogic Server 11g (10.3.1) Copyright© 2009, Oracle. All rights reserved. 4
  • 5. 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 • リクエスト・フィルタリング WebLogicクラスタ WebLogicドメインに含め WebLogicドメインに含 • レスポンスヘッダによるキャッシュ ることで、管理コンソール めることで、管理コンソ ラウンドロビ 無効化 (FMW Control)からの管 ール(FMW Control)か ンによるロー 理が可能 ドバランス などの新機能が追加 らの管理が可能 管理対象 サーバ Oracle Oracle mod_wl_ohs HTTP(s) クラスタは HTTP(s) HTTP(s) Web Cache HTTP 必須ではな い 11g Server 11g •Apache標準モジュール 管理対象 OPMNによる + サーバ プロセス管理/ •mod_plsql •mod_ossl 監視 OPMN •mod_osso •mod_dms etc Oracle WebLogic Server 11g (10.3.1) OPMN: Oracle Process Management and Notification Server Copyright© 2009, Oracle. All rights reserved. 5
  • 6. WebLogicアーキテクチャ • ドメインについて • スレッド管理について • データベース接続について Copyright© 2009, Oracle. All rights reserved. 6
  • 7. WebLogic 9.0以降のスレッド制御イメージ • 単一の実行スレッドプール。スレッドプール数は自動チューニング。 • ワークマネージャー(スレッド制御ポリシーをもったキュー)により、アプリケーションの実行優先 制御が可能に リクエスト リッスンポート ワークマネージャーサブシステム 実行スレッドプール マルチ プレクサ 実行スレッド キュー ワークマネージャー アプリケーションA バックログ リッスンスレッドにより ワークマネージャー アプリケーションB 運ばれる 何らかの理由でリクエストが ソケットリーダ アプリケーションC 処理できない場合のバッファ スレッドにより 運ばれる Copyright© 2009, Oracle. All rights reserved. 7
  • 8. [参考]WebLogic 8.1以前のスレッド制御イメージ • 複数の実行キューと実行スレッドプール • スレッドチューニングは手動 リクエスト リッスンポート Defaultキュー 実行キュー 実行スレッドプール マルチ 実行スレッド プレクサ キュー カスタムキュー 実行キュー 実行スレッドプール バックログ リッスンスレッドにより 実行スレッド ソケットリーダ 運ばれる スレッドにより 何らかの理由でリクエストが 運ばれる 処理できない場合のバッファ 内部管理キューにもスレッドプールが存在 Copyright© 2009, Oracle. All rights reserved. 8
  • 9. ワークマネージャーで設定できること • サーバ単位またはアプリケーション単位で設定可能 • AdminConsoleで設定またはアプリケーションのDDに記述 • 制約:スレッド割当時の制約 • 要求クラス:スレッド割当時の優先度 • ワークマネージャーを設定しない場合、defaultのワークマネージャが適用される 種類 要求事項 概要 Defaultワークマネージャー の値 制約 最大スレッド数制約 同時実行可能なスレッドの最大数を指定 -1(無制限) 最小スレッド数制約 実行用に最低限保証されるスレッド数を指定 0 容量制約 ワークマネージャーのキューに受け付けることがで -1(無制限) きるリクエストの最大数(超えた場合はHTTP 503を 返す) 要求クラス 応答時間要求クラス 必要な応答時間(msec)の指定からスレッド使用時 設定なし 間の割合(他の設定値との相対となる)を指定 フェアシェア要求クラス 平均スレッド使用時間(他の設定値との相対となる) 設定なし を指定 コンテキスト要求クラス ユーザやグループと、応答時間要求クラスやフェア 設定なし シェア要求クラスとを関連付ける Copyright© 2009, Oracle. All rights reserved. 9
  • 10. ワークマネージャーの設定イメージ • 制約や要求クラスを個別に定義する。 • ワークマネージャーを定義し、定義した制約や要求クラスを割当てる。 • ワークマネージャーをWebLogicサーバまたはアプリケーションに割当てる。 ワークマネージャー WebLogic サーバ 最大スレッド数制約 それぞれ 最小スレッド数制約 設定可能 容量制約 アプリケーション 応答時間、 フェアシェア、 要求クラス コンテキストの いずれかを設定 Copyright© 2009, Oracle. All rights reserved. 10
  • 11. ワークマネージャー:要求クラス設定例 • フェアシェア要求クラス • アプリケーション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になるようにスレッドを割当 Copyright© 2009, Oracle. All rights reserved. 11
  • 12. ワークマネージャーを使用する上での知っておきたい事 • Defaultワークマネージャー構成を独自に上書きすることができる。その場合、default という名前 のワークマネージャーを構成すればよい。 • ワークマネージャーの最大スレッド数と、JDBCデータソースの接続プール数を同じにするという設 定が可能。(最大スレッド数指定時にデータソースのJNDI名を指定。) • すべてのワークマネージャーの最大スレッド数 < スレッドプールの最大プール数である必要が ある。 • (スレッドプールの最大プール数は、 「ワークマネージャーの共有容量」という項目で、ワークマネ ージャーとは別にサーバ単位で設定可能) • すべてのアプリケーションでワークマネージャーを個別に設定する必要はない。実行優先度を上 げたいアプリケーションにのみ、ワークマネージャーを構成する。 • 有償で利用しているユーザ向けとアプリケーション(無償利用のユーザに対して優先度を上げる) • 管理用アプリケーションなど Copyright© 2009, Oracle. All rights reserved. 12
  • 13. WebLogicアーキテクチャ • ドメインについて • スレッド管理について • データベース接続について Copyright© 2009, Oracle. All rights reserved. 13
  • 14. Oracle WebLogic Serverにおける データソースアーキテクチャ WebLogic Server JNDI ツリー データソース コネクションプール 非RAC Connection アプリケーション Connection Connection Servlet Lookup EJB DataSource マルチデータソース データソース1 RAC データソース1 コネクションプール データソース2 Connection Connection Connection 外部 Lookup データソース2 Java Client DataSource コネクションプール Connection クラスタ化されたスタブ Connection Connection Copyright© 2009, Oracle. All rights reserved. 14
  • 15. マルチデータソース • マルチデータソースとは? • 複数のデータソースをクラスタ化したもの • 負荷分散とフェイルオーバーを実現 • データソースのリストを保持、管理 • 通常のデータソースと同じ方法で利用可能(特別な設定は不要) • DBクラスタ環境を利用する場合においても、XAトランザクションを実現 WebLogic Server データソース1 RAC コネクションプール Connection マルチデータソース Connection Connection データソース1 データソース2 データソース2 コネクションプール Connection Connection Connection Copyright© 2009, Oracle. All rights reserved. 15
  • 16. マルチデータソース マルチデータソースのフェイルオーバー ① アプリケーションからの接続要求 ② 順序付けされたデータソースリストからデータソースを選択 ③ 接続テスト(例:dual表へのselect発行) 失敗した場合は②のデータソースリストの次のデータソースを選択 失敗したデータソースを無効化し、定期的に接続テスト(フェイルバックのため) ④ 正常な接続が返却され、SQL実行 注) 接続取得後のRACインスタンス障害はフェイルオーバーしない WebLogic Server データソース1 ③接続テスト コネクションプール 失敗 RAC1 ②リストからデータソース選択 (データソース1を選択) RAC1接続 × RAC1接続 障害 マルチデータソース RAC1接続 ①接続要求 データソース1 データソース2 データソース2 コネクションプール RAC2 ④データソース2で再トライ RAC2接続 RAC2接続 RAC2接続 Copyright© 2009, Oracle. All rights reserved. 16
  • 17. [参考] RACにおける「サービス」の概念 「サービス」とは論理的な接続単位。 アプリケーションは「サービス」を指定して データベースに接続し、最終的に 「サービス」に関連付けされたノード(インスタンス)に 接続する。 Javaアプリケーションの場合、Oracle JDBC SERVICE_A SERVICE_B Driver(Oracle Net)の機能でRACサービス接続可能 データベース・クライアント データベース・サーバー #1と#2と#3のインスタンスで #3と#4のインスタンスで 利用可能なものに接続 利用可能なものに接続 「サービス」とDBインスタンスを関連つけて Instance Instance Instance Instance 定義する。 #1 #2 #3 #4 SERVICE_A SERVICE_B サービス定義により実現できること • サービスごとの統計の把握 • サービスとノードの対応の動的変更 RAC • ノード間のロードバランス • 障害時のサービスのフェイルオーバー Copyright© 2009, Oracle. All rights reserved. 17
  • 18. [参考] Javaアプリケーションからの RACサービス接続指定 • Javaアプリケーションの場合、Oracle JDBC Driverを使用し、JDBC URLを下記のよ うに指定することでOracle Netの機能によるRACサービスを指定した接続が可能に なります。 • WebLogicでは、データソース構成時にJDBCのURLを下記のように指定します。  (下記はOracle JDBC Thinドライバでの使用例です。) 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))) Copyright© 2009, Oracle. All rights reserved. 18
  • 19. これまでのWebLogicにおけるRAC接続 マルチデータソース利用の場合 Oracle Netの機能を利用の場合 RACのインスタンス毎にデータソースを構成 RACサービス接続指定されたデータソースを構成。 アプリケーションはRACサービスを指定した接続は行 アプリケーションはRACサービスに対応するデータソー なえない。 スを指定して接続を行なう。(RACサービス指定可能) 接続要求はマルチデータソースにより、RACサービス 接続要求はRACサービス設定に基づき分散される。 に関係なく分散される。 RACのXAトランザクション制限に対して何かしらの措 RACのXAトランザクション制限の意識不要 置が必要 WebLogic アプリケーション WebLogic アプリケーション マルチデータソース データソース1 データソース2 データソース3 データソース1 データソース2 サービスA サービスB Copyright© 2009, Oracle. All rights reserved. 19
  • 20. WebLogic11gにおけるGridLink for RAC マルチデータソースにおけるRACサービス指定を可能に RACサービス毎にマルチデータソースを構成 データソースは、サービス指定を行いRACノード数分用意する。 アプリケーションはRACサービスに対応したマルチデータソースを指定して接続する。   (RACサービス指定接続が可能) RACサービス数=マルチデータソース数 接続要求はRACサービス設定基づき分散される。 マルチデータソースに含まれるデータソースの数 =RACインスタンス数 RACのXAトランザクション制限の意識不要 WebLogic11g アプリケーション マルチデータソース(サービスA用) マルチデータソース(サービスB用) ACTIVE ACTIVE ACTIVE データソース1 データソース2 データソース3 データソース1 データソース2 データソース3 RACインスタンスの数だけ、データソースを 設定しておく。(インスタンス「RAC3」はFIN サービスが構成されていないため、データソ サービスA サービスB ースは無効化状態) Copyright© 2009, Oracle. All rights reserved. 20
  • 21. GridLink for RAC のメリット GridLink for RACによるメリット RACサービスのリソース配分の変更をAPサーバー側で動的に検出し、対応 することが可能 (WebLogic Server側では意識をする必要がない) ③WebLogic Server側で はデータソースの設定を特 に変更せず、RACのリソー 通常時 ②FIN用データソース HRの負荷が高まる ス配分に対応可能 #2がINACTIVEになり、 WebLogic Server HR用データソース#2 WebLogic Server がACTIVEになる FIN用 HR用 FIN用 HR用 マルチデータソース マルチデータソース マルチデータソース マルチデータソース データ データ データ データ データ データ データ データ データ データ データ データ ソース ソース ソース ソース ソース ソース ソース ソース ソース ソース ソース ソース #1 #2 #3 #1 #2 #3 #1 #2 #3 #1 #2 #3 FINサービス HRサービス FINサービス HRサービス RAC RAC RAC RAC RAC RAC インスタンス#1 インスタンス#2 インスタンス#3 インスタンス#1 インスタンス#2 インスタンス#3 ①HRサービスの負荷 が高まったためRACサ Oracle RAC ービスのリソース配分 Oracle RAC を変更 Copyright© 2009, Oracle. All rights reserved. 21
  • 22. GridLink for RACの構成 データソース構成にてRACサービス指定が可能 New Oracles's Driver (Thin) for RAC Service-Instance connections Oracle's Driver (Thin XA) for RAC Service-Instance connections 管理コンソールから設定できるデータベースの種類に 「Service-Instance」接続が追加 【生成される接続文字列】 jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=( ADDRESS=(PROTOCOL=TCP)(HOST=racdb- vip)(PORT=1521)))(CONNECT_DATA=(SERVICE_NA ME=SERVICE1)(INSTANCE_NAME=INST1))) Copyright© 2009, Oracle. All rights reserved. 22
  • 23. <Insert Picture Here> 運用ツールを使いこなせ Copyright© 2009, Oracle. All rights reserved. 23
  • 24. 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製品など統合管理) Copyright© 2009, Oracle. All rights reserved. 24
  • 25. JVMの監視・分析ツール • JVMに対する監視・分析ツールには下表のようなものがあります。 JVM ツール名 概要 JRockit JRockit Misson Control オラクルが提供するJRockit用の診断・分析ツール。 非常に強力なプロファイリングや診断機能を提供。 Memory Leak Detectorや、JRockit Runtime Analyzer やLatency Analyzerなど、さまざまな分析機能をGUIか ら利用可能 Sun JDK, Oracle Application オラクルが提供するJVM診断・分析ツール。 JRockit, Diagnostics for Java その他 (AD4J) HPやIBMのJVMなど Sun JDK jconsole Sun JDKに含まれるツール JVMのヒープやスレッドや状況を監視。MBeanブラウザ も利用可能 Sun JDK Visual VM Sun JDK1.6に含まれるツール ヒープ利用状況分析やスレッドのロック等の分析も可能 Copyright© 2009, Oracle. All rights reserved. 25
  • 26. WebLogic Scripting Tool(WLST) とは? • 管理コンソールと同様に、 WebLogic Server の管理、運用の操作に使用できる コマンドライン スクリプト環境 • Built on Jython 2.1 • 100% pure java のPython 実装 • OS/プラットフォームに依存しない • WebLogic Server 9.x から利用可能 • WebLogicのMBeanを(比較的容易に)操作可能 • WLSTのオンラインモード • 構成を行う場合は管理サーバ接続 • 監視を行う場合は、対象の管理対象サーバに接続 • WLSTのオフラインモード • 管理サーバや管理対象サーバに接続していない状態 • ドメインのコンフィグレーション・ウィザードと同じ機能を提供 Copyright© 2009, Oracle. All rights reserved. 26
  • 27. 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’) Copyright© 2009, Oracle. All rights reserved. 27
  • 28. WLSTを使う上で知っておこう • WLSTは、WebLogicの構成や監視をコマンドライン操作で行える 強力なスクリプティング・ツール • ただし…. • PythonであれJythonであれ、ある程度の「慣れ」が必要 • OSのスクリプトに慣れきった人には逆に使いにくいかも。 • →管理コンソールでの操作をレコーディングし、WLSTを自動生成可能   (WLS10.0以降) • WLSTの使いどころ • アプリケーションのデプロイであれば、weblogic.Deployerでも十分 • レコーディング機能を活用し、一から作成する手間を省く Copyright© 2009, Oracle. All rights reserved. 28
  • 29. スクリプト例 WebLogic Server のスレッドプールをモニタする [ThreadMonitor.py] # 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] Copyright© 2009, Oracle. All rights reserved. 29
  • 30. スクリプト例 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') Copyright© 2009, Oracle. All rights reserved. 30
  • 31. スクリプト例 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 Copyright© 2009, Oracle. All rights reserved. 31
  • 32. TIPS • prompt() • プロンプトの表示/非表示を切り替える • find() • 現在の階層の MBean から文字列を検索する • jndi() • JNDIツリーを表示するモード • help() • コマンドおよび変数に関する情報を表示 • easeSyntax() コマンド (非サポート) • 一部のコマンドを簡易入力することが可能 • java weblogic.WLST -easeSyntax Copyright© 2009, Oracle. All rights reserved. 32
  • 33. <Insert Picture Here> [ご参考] Oracle Application Diagnostics for Java (AD4J)のご紹介 Copyright© 2009, Oracle. All rights reserved. 33
  • 34. Javaアプリケーション障害対応における課題 • 本番環境での問題調査には制約がある • 本番環境の問題に対して、十分に深く診断できない • 診断ツール自体が本番環境に向いていない • 他の環境(テスト環境など)で問題の再現するのが困難 • Javaアプリ + DBの統合的・横断的な調査や分析ができない • 性能劣化問題発生→ボトルネックの調査が必要 • DBは、DBエキスパート技術者がトレースを取得、調査 • Javaアプリは、Javaエキスパート技術者がログやJavaVM性能情報を取得、調査 • DB SessionとJavaアプリのスレッドの結びつけを意識した調査が困難 • 2名のエキスパートが時間をかけて調査してようやく問題が見つかるかどうか 問題発生時に膨大な作業が必要 問題解決の長期化 技術者育成コストの増大 Copyright© 2009, Oracle. All rights reserved. 34
  • 35. Javaアプリケーションの詳細な分析 EM10gR4 EM10gR4 ~ Application Diagnostics for Java(AD4J) ~ AD4Jを使用することにより、管理者はJavaアプリケーションの状態をプロアクティブに監視し、 AD4Jを使用することにより、管理者はJavaアプリケーションの状態をプロアクティブに監視し、 問題発生時にボトルネックとなっているオブジェクトを素早く特定することができます。 問題発生時にボトルネックとなっているオブジェクトを素早く特定することができます。 [J2EEアプリケーションの監視] 本番環境 Agent AS AD4J Agent DB 製品の特徴 ・負荷が軽く、本番環境で使用可。 ・AS層、DB層にまたがるトラン 主な用途 ザクションを追跡 ・異常を早く検知したい。(しきい値設定とメール/ ・ほとんどのアプリケーション・  SNMPトラップの通知)  サーバーやJVMをサポート ・メモリ・リーク時の原因オブジェクトを特定したい。 ・インストール/セットアップが簡単。 ・デッドロックのオブジェクトを検出したい。 ・Agentデプロイ時に再起動の ・パフォーマンス劣化の原因となっているオブジェクトを特定したい。 必要なし。 ・定常的にJavaVMの状況を監視したい Copyright© 2009, Oracle. All rights reserved. 35
  • 36. OracleDBとJavaVM間で横断的にトレース • JavaスレッドからDBセッションま でトレース DB処理待ち スレッドを特定 – DB処理待ちの実行中の Javaスレッドを特定 – 発行SQLまでドリルダウン • DBセッションからJava スレッドま ボトルネック原因と なっているDB状況 でトレース – 待機状態やロック状態のDB 問題となっている セッションを表示 SQL文 – DBセッションを保持している Javaスレッドを特定 Copyright© 2009, Oracle. All rights reserved. 36
  • 37. 差分ヒープ分析 • オフライン分析用に メモリーの完全な ロードされているクラスと スナップショットを 使用メモリの統計 作成 • 各オブジェクトから アクセス可能な メモリーを表示 ヒープ間での 使用メモリ差分 • 複数スナップショット を 比較して、メモリーの 増加を追跡 • (ルートからの) トップダウン分析 またはボトムアップ 分析が可能 Copyright© 2009, Oracle. All rights reserved. 37
  • 38. なぜAD4Jは低オーバーヘッドなのか?Javaプロ ファイラの実装方式 実装方式 詳細 JavaVMPI/JavaVMTI Java SDKで提供されるJavaVMの挙動を監視し、情報収集するためのインタ ーフェース。詳細な情報を取れる反面オーバヘッドがかなり大きい。 [JDeveloperプロファイラ] (dynamic)ByteCode バイトコードを操作して、プロファイリングのためのコードを埋め込む方式。 Instrumentation(BCI) 埋め込む量が多くなればオーバヘッドが大きく、少なければ得られる情報が限 又はByteCode られてしまう。 modification サンプリング 情報を収集したい時点のみのスナップショット(JavaVM、メモリヒープ)を取り分 析する方式。オーバヘッドは小さいが、その分得られる情報も限られる。 [AD4J] • AD4Jはサンプリング方式を実装することにより低オーバーヘ ッドを実現している Copyright© 2009, Oracle. All rights reserved. 38
  • 39. AD4Jによって解決できる問題例 1. 連続的なDB接続によりJavaロックが発生しアプリケーショ ンのレスポンスが遅い場合の原因究明 2. 中間層のCPU使用率が高い → 最もコストの高いクラス/メ ソッドを発見 3. ユーザのリクエストがハングしたとき、現在の状態と関連す るコード中の行数を検知 4. GCが多発しリソースをほぼ使いきりアプリケーションが遅く なってしまった場合メモリリークの原因を発見 5. レスポンスの遅いSQL文に紐づくJavaスレッドを特定 Copyright© 2009, Oracle. All rights reserved. 39
  • 40. <Insert Picture Here> 設計・開発手法、これを押さえろ Copyright© 2009, Oracle. All rights reserved. 40
  • 41. 設計・開発手法について • アプリケーションの設計について • データベースのアクセスモジュールの設計について • WebLogicサーバの設計について • 仮想化環境について Copyright© 2009, Oracle. All rights reserved. 41
  • 42. 一般的な JavaEEアプリケーションのレイアリング • 下図は一般的なJavaEEアプリケーションの論理的なレイアリングとその役割を 表します。 ユーザに対する画面の描写、ユーザからの入力の ユーザインターフェース層 受付の制御 等 アプリケーション層 (コントローラ層) ユーザ入力値の検証、画面遷移の制御 等 ドメイン層のロジックをアプリケーション層から利用しや サービス層 すいように抽象化、ビジネスロジックのワークフロー制御 、トランザクション 等 ドメイン層 対象となる業務のドメインロジック(ビジネスロジック) 等 パーシステント層 メイン層のオブジェクトをデータストアに対して永続化 するためのロジック。典型的には、リレーショナル データベースに対してアクセスするSQLのコードを含む いわゆるDAO(Data Access Object)はこの層 Copyright© 2009, Oracle. All rights reserved. 42
  • 43. 一般的な Java Webアプリケーションと 実装技術の関係 • Eclipseであれ JDeveloperであれ各レイアを実装する機能は標準的に装備 ユーザインターフェース層 JSP(Struts)/JSF アプリケーション層 (コントローラ層) Servlet/Struts/JSF サービス層 実装形態 Plain Java Class ドメイン層 EJB パーシステント層 実装形態 Plain Java Class (フレームワークにより提供するクラス含む) EJB(JPA) Hibernateや他O/Rマッピングツール利用ケースあり Copyright© 2009, Oracle. All rights reserved. 43
  • 44. 一般的な Java Webアプリケーションの実装におけ る課題点 • 各レイア間のつながりを、極力、疎結合にすることが望ましい。 • 密結合になると、修正の局所化が困難になる。 • DAOで取得したデータをBusiness Logicにいかに渡すか • モデリングとしては、ResultSetデータでフェッチしたデータをJava Object化するのが王道。     ただし、この処理は一般的に重い。 • DAO部分を自動生成するフレームワークを使用した場合、適切なSQLが生成されるか Servlet 登録画面 Service Business Logic Business Logic 1件登録されました 登録 DAO DAO DAO SQL Copyright© 2009, Oracle. All rights reserved. 44 Copyright© 2009, Oracle. All rights reserved. | 44
  • 45. 一つの解決策として…. • Oracle Coherenceのようなアプリケーションで利用するObjectのキャッシュ・サー バを設置する。 • アプリケーションは、標準のJPAでDAOを実装するが、自動的にCoherenceにアク セスさせる(TopLink Gridにより、アプリはCoherence APIを利用する必要なし) Servlet 登録画面 Service Business Logic Business Logic 1件登録されました 登録 DAO DAO DAO TopLink Gridにより Coherenceアクセス Oracle Coherence Copyright© 2009, Oracle. All rights reserved. 45 Copyright© 2009, Oracle. All rights reserved. | 45
  • 46. TopLinkGridとは • TopLinkのL2キャッシュもしくはデータストア そのものとしてCoherenceをシームレスに利用 TopLink と組み合わせた場合の動作 することが可能(=TopLink Grid) • メリット Application • DBの負荷軽減 EntityManager API • Java SE環境でも利用可能 (find, query, persist, merge) • Coherence分散キャッシュの機能を活用可能 (拡張性、クエリ機能など) TopLink JPA Cache API Coherenceによる • 動作パターン (get, put, filter) 分散キャッシュ • Coherence Read • JPAの読取り(find,Query)をCoherence にリダイレクト SQL • 書込みはJPAで実行 CacheLoader/Store • Coherence Read/Write • JPAの読取り、書込みをCoherenceに CacheLoader/Storeにより リダイレクト SQL DBから読取り、書込み • Coherence L2 Cache • CoherenceによるL2キャッシュの実装 • キャッシュヒットは主キーアクセスのみ Copyright© 2009, Oracle. All rights reserved. 46
  • 47. 設計・開発手法について • アプリケーションの設計について • データベースのアクセスモジュールの設計について • WebLogicサーバの設計について • 仮想化環境について Copyright© 2009, Oracle. All rights reserved. 47
  • 48. 仮想化サーバの市場動向: 3年後の2011年にはサーバーの4割が仮想化を採用 • x86サーバーにおける仮想化の普及が市場を牽引 • 仮想化技術の成熟 • OS標準や無償提供による敷居の低下 • 逆に言えば、3年後であっても6割は非仮想化環境サーバー • ユーザの要件により仮想化か非仮想化かを選択できる時代 国内仮想化サーバー市場出荷台数予測、2004年~2011年 IDC Japan: 2008年 国内サーバー市場 仮想化技術の導入動向調査 Copyright© 2009, Oracle. All rights reserved. 48
  • 49. 仮想化におけるコスト・メリットと注意点 • 仮想化で減るコスト • サーバー代(保守料含む) • 電気代、設置スペース代 • 運用管理コスト etc • 仮想化で増えるコスト • 仮想化ソフトウェアライセンス(保守料含む) • 外部ストレージ代(保守料含む) 注意点は、サーバー代の削減幅を上回る程のコストが 仮想化の導入で掛かってしまう可能性があること Copyright© 2009, Oracle. All rights reserved. 49
  • 50. 仮想化の適用範囲について • システム構成の中では Web APサーバの層が最もサーバ数が多くなる傾向にある。 • 仮想化の適用を検討した場合、Web APサーバ層が最も効果が出る可能性が高い。 クライアント層 APサーバ層 APサーバ層 データベース層 永続的にデータは保持しない 永続的にデータを保持する Web アプリケーション Oracle RAC HTTP サーバ層 サーバ層 DB Instance Disk中のデータは Rich Client(C/C++) 原則一元管理で 分散しない Disk Load RSS(Excel) Balancer/ Rich Client(C/C++) Fire Wall 拡張 拡張 拡張 (Oracle RAC) Webシステム HTTP データを処理する DBインスタンスのサーバ は増加可能。 ただし、データ整合性維 モバイルシステム 負荷や可用性要件に 持のためサーバ数増加 応じて、サーバを増加させる はAPサーバほど容易 ことが比較的容易 ではない Copyright© 2009, Oracle. All rights reserved. 50
  • 51. 仮想化事例: オラクル • Oracle VM の Oracle Corporation 社内導入効果 • Oracle On Demand - ホスティング, SaaSサービス • サーバー数を1/3に削減 • CPU使用率が9%から55%に改善 • Oracle University - 研修 • サーバー数を1/6に削減 • 設置スペースを50%削減 • データセンターの電力使用量を40%削減 • Oracle Development - 開発/検証 • 容易な環境構築が可能に • サーバー利用の大幅な効率化 Copyright© 2009, Oracle. All rights reserved. 51
  • 52. 仮想化とAPサーバについて • ユーザの要件により、仮想化環境か非仮想化か選択可能な時代になっています。 • 仮想化の適用判断について • 下記のケースでは仮想化環境を検討する余地があるといえます。 • 現在、物理サーバが多いことによりコストや運用負荷が高いケース • 将来、物理サーバ増加が見込まれ、コストや運用負荷が増加する可能 性があるケース • 仮想化の適用先について • Webシステムの構成においては、その構造上、Web APサーバのサーバ台数が 最も増加する傾向にあるため、Web APサーバを統合・仮想化することで最も効 果を出す可能性が高いといえます。 Copyright© 2009, Oracle. All rights reserved. 52
  • 53. [ご参考]Oracle WebLogicが対応している仮想化環境 • 下表は2009年11月13日時点での情報で、下記URLからの抜粋です。 仮想化/分割化技術 プラットフォーム オペレーティングシステム Oracle VM IA32 RedHat Linux IA64 Oracle Enterprise Linux Windows IBM LPAR IBM AIX Power AIX 5.3 (IBM WPARは不可) AIX 6.1 nPar (static nPar のみ) Itanium-2 HP-UX 11.23 HP-UX 11.31 Sun Containers Sun Solaris SPARC Solaris10 SPARC 詳細は下記をご参照ください。 http://www.oracle.com/technology/products/ias/hi_av/oracleas_supported_virtualization.html Copyright© 2009, Oracle. All rights reserved. 53
  • 54. JRockitを極める – パラレル/コンカレント & 世代別/シングルスペース Copyright© 2009, Oracle. All rights reserved. 54
  • 55. パラレルGCとコンカレントGC •※ 4CPU環境におけるスレッドとGCの関係 デフォルトGC パラレルGC(主流) コンカレントGC GC実 GC実行 行 STOP-THE-World!! GC実 行 STOP-THE-World!! GC終 了 GC終 了 Copyright© 2009, Oracle. All rights reserved. 55
  • 56. シングルスペースGCと世代別GC Single-Space GC Heap領域 Single シングルスペースGCは、オ ブジェクトの移動を最小化 することでGCコストの総量 ・全体をGC を抑えます。 Two-Generational GC Young(Nursery) Old 世代別GCは、オブジェクト の生存期間に適した処理を ・Young GC ・Old GC 行うことで、効率的なGC制 ・Promotionフェーズ 御を行います。  (Oldへのオブジェクトの移動) Copyright© 2009, Oracle. All rights reserved. 56
  • 57. Sun JVM vs JRockit 世代別GC の違い • Sun JVM の New GC(ScavengeGC)は、オブジェクトがプロモーショ ンされるまでに最大32回New領域内を移動しつつ留まり続けます。 JRockit の NurseryGCは、オブジェクトがNursery領域内を移動する ことが無く1回のGCでプロモーションされます。 最大32回で Sun JVM プロモーショ ン Eden From To Perm New 領域Heap領域 領域 Old 領域 0 1 32 1回でプロ 中寿命オブジェクト数 モーショ とコンパクションの効 JRockit ン 率に対する両社の考 え方の違いが反映さ れています。 Nursery Old 領域 Heap領域 0 1 Copyright© 2009, Oracle. All rights reserved. 57
  • 58. JRockitを極める – 奨励パラメータ Copyright© 2009, Oracle. All rights reserved. 58
  • 59. 静的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は別ライセンスが必要です。 Copyright© 2009, Oracle. All rights reserved. 59
  • 60. GCアルゴリズムの選択 • 静的GCの世代別パラレルGCが簡単でお勧め • 動作が固定でチューニングが簡単 • 静的アルゴリズムなので、動的判定のコストがかからない (動的GCだとGCログが煩雑となる) • Appサーバのような24時間動き続ける環境では、生存期間の 長いオブジェクトが存在するため有利 Nursery GC Nursery GCOld GC Copyright© 2009, Oracle. All rights reserved. 60
  • 61. Heapサイズの指定 • 最小と最大ヒープ サイズの設定 • ヒープサイズを指定する際には、最小サイズと最大サイズを同じ 値にすることをお勧めします。 # java -Xmx:1500m -Xms:1500m • ヒープサイズを拡張する際のコストを抑えることができます。 Copyright© 2009, Oracle. All rights reserved. 61
  • 62. Heapサイズの指定(つづき) • 32-bit OSのプロセスサイズの制限 • 32-bit OSではOSの仮想プロセスサイズ以上にヒープサイズを確 保することはできません。例えば、32-bit ReaHat Linuxでは仮想 プロセスサイズは2Gとなっています。 • 上記の場合、-Xmx 1500mを設定した場合、ネイティブ領域は 500mとなります。ネイティブ領域を利用するアプリケーションが多 い環境では、ヒープ領域を減らしてネイティブ領域を増やす必要 があります。 プロセスサイ ズ ネイティブメモ      Javaヒープ リ - Xmx Copyright© 2009, Oracle. All rights reserved. 62
  • 63. 32bit版 JVMの勧め • JVMは32bit版の方がパフォーマンス的に有利 • 32bitメモリ空間 • GCについて • 32bit Native APIとJVMの内部実装 • JVMのHeapが足りない場合は 64bit化よりもAPの分散化を検討 Copyright© 2009, Oracle. All rights reserved. 63
  • 64. コード最適化オプション • JRockitは効率的な機械語を生成するために、自JVM内 でのプログラムの性能を絶えず解析し、最適化を実施し ています。 • 数値計算を行うような複雑で長時間動き続けるプログラ ムなどでは、非常に高いパフォーマンスを発揮します。 • ただし、WebLogic Serverのようなアプリケーションサー バではネットワークの通信レイヤがボトルネックとなり、 JRockitのコード最適化の恩恵を受けにくい。 • 稀に安定しないケースも発生 • -XnooptオプションにてOFFでも可 Copyright© 2009, Oracle. All rights reserved. 64
  • 65. lazyUnlockingオプション • R27.5: -XXlazyUnlocking:enable=<true|false> • R27.4: -XXlazyUnlocking • JDK6.0ではデフォルトで有効 • JDK5.0と1.4.2ではデフォルトで無効 • lazyUnlockingオプションを有効化すると、スレッドのロッ クの解放がその時点では有効にならず、次に同じスレッド からのロックが発生した際のコストを下げることができま す。全ての局面において、有効化した方がパフォーマンス が良くなります。 Copyright© 2009, Oracle. All rights reserved. 65
  • 66. jrcmdによる運用監視について • jrcmdのprint_object_summaryやheap_diagnosticsコマ ンドを定期的に発行して、本番機のメモリ情報を取ってい る場合、FullGCが多発します。 • jrcmdで「Heap情報を取得する」コマンドを実行した場合、 FullGCさせることでメモリ情報を取得しています。ただし、 これはパフォーマンス的には問題。 • jcmdの利用は最低限にして、定常的なメモリ情報などは JMXを使ったMbeanの監視を行うようにしてください。 Copyright© 2009, Oracle. All rights reserved. 66
  • 67. JRockitのGC関連オプション -X -XX -XXaggressive - -XclearType -XXallocClearChunks XXpointerMatrixLinearSeekDistan -Xgc -XXallocClearChunkSize ce -XgcPause -XXallocPrefetch -XXprintSystemGC -XgcPrio -XXallocRedoPrefetch -XXsetGC -XgcReport -XXcompactRatio -XXstaticCompaction -XnoClassGC -XXcompactSetLimit -XXthroughputCompaction -XpauseTarget -XXcompactSetLimitPerObject -XXtlaSize -XXdisableGCHeuristics -XXusePointerMatrix -XXexternalCompactRatio -XX:MaximumNurseryPercentage -XXfullCompaction -XXfullSystemGC -XXgcThreads -XXgcTrigger -XXheapParts -XXinitialPointerVectorSize -XXinternalCompactRatio -XXkeepAreaRatio -XXlargeObjectLimit -XXmaxPooledPointerVectorSize -XXminBlockSize -XXnoCompaction -XXnoSystemGC Copyright© 2009, Oracle. All rights reserved. 67
  • 68. 障害分析テクニック – スレッドダンプがとっても大事 Copyright© 2009, Oracle. All rights reserved. 68
  • 69. WebLogic Serverでの障害のパターン化 • WebLogic Serverのハング/無応答 • Javaヒープメモリの使用量が徐々に増え続けていく • JDBC接続でデータベースからの応答が悪くなる • プロセスがCPU100%となり応答が返らなくなる これらの障害解析においてスレッドダンプ情報の取得は必須! Copyright© 2009, Oracle. All rights reserved. 69
  • 70. Javaスレッドダンプとは • Javaスレッドダンプは、JVM(サーバ)プロセスの全スレッ ドのスナップショットです。 • テキスト形式で標準出力もしくは標準エラーに出力されま す。 • 数秒~数十秒間隔で複数回取得することでサーバの動 きを確認することができます。 • 標準出力と標準エラーはファイルにリダイレクトしておくこ とをお勧めします。WLSではWLS_REDIRECT_LOG環 境変数で制御できます。 -- startWebLogic.cmd -- set WLS_REDIRECT_LOG=stdout.out Copyright© 2009, Oracle. All rights reserved. 70
  • 71. Javaスレッドダンプの取得方法 1 UNIXプラットフォームの場合 • # kill -3 <PID> 2 Windowsプラットフォームの場合 • コマンドプロンプト上でCtrl-Breakキー 3 WebLogic Scripting Tool • % threadDump(“hogehoge/dump.out”) Copyright© 2009, Oracle. All rights reserved. 71
  • 72. 復習:WLSのアーキテクチャ ワークマネージャ WebApp A 7001 Muxer WebApp B Port キュー EJB A バックログ スレッドプール リクエスト 実行スレッド ソケットリーダスレッド Listenスレッド BEA WebLogic Copyright© 2009, Oracle. All rights reserved. 72
  • 73. WLSスレッドとスレッド名の対応表 WLSのスレッド スレッドダンプで取得した際の スレッド名 実行スレッド weblogic.kernel.Default (self-tuning) ソケットリーダースレッド weblogic.socket.Muxer Listenスレッド DynamicListenThread[Default] Copyright© 2009, Oracle. All rights reserved. 73
  • 74. 典型的なハングの例) 全ての実行スレッドが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) … Copyright© 2009, Oracle. All rights reserved. 74
  • 75. <Insert Picture Here Oracle Advanced Customer Servicesのご紹介 Copyright© 2009, Oracle. All rights reserved. 75
  • 76. Oracle Advanced Customer Services • ACSはお客様のミッションクリティカルな情報システムを24 時間365日体制で対応するための、ハイエンドなサポート サービスです。 • 日本オラクルのエキスパートで編成される専用のサポート アカウントチームを作り、お客様システムの運用保守を支 援します。 Copyright© 2009, Oracle. All rights reserved. 76
  • 77. ACS BEA product offierings • BEA Troubleshooting Methodologies Workshop • WebLogic Serverの典型的な障害(サーバハング、サーバcore、 CPU100%、メモリリークなど)をパターン化し、問題解決のノウハ ウをワークショップ形式で提供します。 • BEA Migration Support Service • 旧バージョンのWebLogic Serverから最新バージョンへの Upgradeを、Oracleの(元BEAの)経験豊富なエンジニアが支援 • ドメインアップグレード手順書の作成 • 新旧WLSバージョンにおける非互換情報の提供 Copyright© 2009, Oracle. All rights reserved. 77
  • 78. サポート期間(抜粋) リリース GA Date Premier Extended Sustainin Support Ends Support Ends Support 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 9.0 2005年6月 2011年6月 2013年6月 無期限 Tuxedo 9.1 2006年6月 2012年6月 2014年6月 無期限 Tuxedo 10.x 2007年9月 2013年9月 2015年9月 無期限 Tuxedo 10.3 2009年1月 2015年1月 2017年1月 無期限 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月 無期限 Copyright© 2009, Oracle. All rights reserved. 78
  • 79. Copyright© 2009, Oracle. All rights reserved. 79