トラブルに強いweblogic serverの設計と構築 - 第20回 weblogic server勉強会資料

Copyright (c)2011 ITOCHU Techno-Solutions Corporation

第20回 WebLogic Server勉強会＠東京

トラブルに強いWebLogic Serverの設計と構築

ソフトウェアサービス本部ミドルウェアサービス部

山田貴裕

2012/1/31


自己紹介

• 自己紹介

– 山田貴裕 (Twitter: @yamadamn)

– 伊藤忠テクノソリューションズ株式会社(CTC)

• ソフトウェアサービス本部ミドルウェアサービス部所属

– Java EE開発者やDBAを経て、ミドルウェアのサポートエンジニアに

• Oracle Fusion Middleware が主担当

– WebLogic Server, Coherence など

• 大規模案件にも従事し、設計や構築を担当

–W-1チャンピオン • 2011/12/7 「第2回W-1選手権 WebLogic Serverクイズ王決定戦」にて


おことわり

• 発表する内容は個人の見解であり、所属する組織の公式見解ではありません。

• 個人の(限られた)経験に基づくものですので、様々な環境に適したものではありません。

• 設計や構築に必要な内容を、体系的・網羅的に説明するものではありません。

– 運用時に落とし穴になりがちな設計・構築のポイントを部分的に説明するものです。

– 一般的な非機能要件(性能・可用性・拡張性など)の内容は原則として含みません。


[宣伝] WebLogic Serverを体系的に学習するには？

• Oracle WebLogic Server 11g構築・運用ガイド

– 絶賛発売中!!

– WebLogic Server勉強会でも、じゃんけん大会などで配布

11g

9.x/10 8.1


目的と対象

• 目的

– トラブルを未然に防ぐ

– トラブルに迅速に対処する

• 対象

– WLSのインフラ設計・構築担当者

– WLSの運用管理者

– (WLSの開発担当者)

• 環境

– WLS9.x以降

– Unix系OS(Solaris, Linux)中心

• Windowsでもほぼ適用可能


アジェンダ

• ログ管理

• OS環境設定

• セキュリティ

• ネットワーク

• 起動・停止スクリプト

• 監視/統計


ログ管理

種類利用目的取得有無 (デフォルト)

説明

サーバーログ運用監視

障害解析

○ 各インスタンスの詳細情報を記録する

HTTPアクセスログ稼働評価

障害解析

○ HTTPアクセスの情報を記録する

コンソールログ運用監視

障害解析

× 標準出力・エラーの情報を記録する以外に、インスタンスの重要度が高い情報を記録する

ドメインログ障害解析 ○ (管理サーバー)

ドメイン内全インスタンスの重要度が高い情報を記録する

GCログ稼働評価

障害解析

× JVMのGC情報を記録する

クラッシュログ障害解析 △ (クラッシュ時)

JVMクラッシュ時に出力される

よく利用するログファイル


ログ管理

• HTTPアクセスログ

– バッファリングされ、ある程度アクセスされないと出力されない

• 開発環境では、バッファリングを無効化しておくと便利

• 特定リリース以降であれば、バッファサイズを設定可能(詳細はサポートに…)

– 管理コンソールへのアクセスは出力されない

• 特定リリース以降であれば、出力するよう設定可能(詳細はサポートに…)

– 拡張フォーマットの利用

フィールド識別子を利用して設定する

※カスタムクラスで、ユーザ定義のフィールドを出力することも可能

• c-ip: クライアントのIPアドレス

– 「WebLogicプラグインの有効化」を設定することも検討

• date, time: レスポンスを返した日時

– 通常の共通ログフォーマットでは、リクエストを受け取った日時

• bytes: レスポンスのバイト数

• time-taken: 所要時間(ミリ秒)


ログ管理

• HTTPアクセスログの詳細設定

– [環境]→[サーバー]→<サーバー名>→ロギング→HTTP→詳細

:


ログ管理

• コンソールログ

– スレッドダンプ出力やOOME分析のためにはあった方がよい

• スレッドダンプに関しては、環境によってはjstack(HotSpot),

jrcmd(JRockit)などでも代替できる

– 後述する監視目的で取得するのも有用

– 環境変数WLS_REDIRECT_LOGで出力するログを設定可能

• デフォルトでは上書き(>"${WLS_REDIRECT_LOG}" 2>&1)

• 別の方法で標準出力・エラー出力をリダイレクトさせておいてもよい

(startWebLogic.sh 抜粋) if [ "${WLS_REDIRECT_LOG}" = "" ] ; then : ${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ～ ${SERVER_CLASS} else echo "Redirecting output from WLS window to ${WLS_REDIRECT_LOG}" ${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ～ ${SERVER_CLASS} >"${WLS_REDIRECT_LOG}" 2>&1 fi


ログ管理

• GCログ

– GC頻度やメモリリーク傾向などを分析するためには必要

• 環境によっては、jstat などでも代替できる

– 後述する統計目的で取得するのも有用

オプション説明

-verbose:gc GC情報を出力(基本)

-Xloggc:<file> GC情報を指定されたファイルに出力

-XX:+PrintGCTimeStamps タイムスタンプ(Java起動からの経過時間)を出力

-XX:+PrintGCDetails GCの詳細情報を出力

HotSpot でよく利用するGCログ用オプション

オプション説明

-verbose:gc -Xverbose:memoryや-Xverbose:gcでも同じ

-XverboseLog:<file> GC情報を指定されたファイルに出力

-XverboseTimeStamp タイムスタンプ(日時)を出力

JRockit でよく利用するGCログ用オプション


ログ管理

• コンソールログやGCログのローテーションはどうする？

A) ローテーションしないが、上書きに配慮する • WLS_REDIRECT_LOG="servers/${SERVER_NAME}/logs/

console.log.`date +%Y%m%d%H%M%S`"

• -Xloggc:${LOG_DIR}/gc-${SERVER_NAME}-`date +%Y%m%d%H%M%S`.log

B) OS標準の機能により強制的にローテーションさせる

※ログ欠落に注意、またOS環境によっては正常にローテーションできない

• cp -p "${CURRENT_LOG}" "${BACKUP_LOG}"

cat /dev/null >"${CURRENT_LOG}"

• logrotate(Linux)やlogadm(Solaris)を利用する

C) コンソールログ独自のローテーション方法

• rotatelogsやcronologなどサードパーティ製のツールを利用する

• Windowsサービスの場合は、ログ出力設定すればローテーションされる

D) GCログ独自のローテーション方法(JRockitのみ)

• jrcmd <PID> verbosity filename=<new_file>

※現時点では、HotSpotのjinfo では変更できなかった


OS環境設定

• リソース制限に注意

– コアファイルサイズ(ulimit -c)

• 運用環境では「unlimited」に設定する

– ファイルディスクリプタ(ulimit -n)

• 厳密には難しいが「8192」程度に設定すれば問題ないことが多い

• カーネル設定は？

– 以前はマニュアルに“推奨値”とする記載があったが、

最近のマニュアルからは削除されている

• 『構築・運用ガイド』の参考値をベースラインにシステムごとにチューニング

• 言語の設定

– ログメッセージやJava APIの一部はデフォルトロケールに依存

• LANG環境変数などを起動スクリプトで明示的に設定

※Windows環境では通常いずれとも行う必要なし


OS環境設定

(参考) WLS9.1のマニュアル

– http://otndnld.oracle.co.jp/document/products/wls/docs91

/perform/HWTuning.html#1124020

http://otndnld.oracle.co.jp/document/products/wls/docs91/perform/HWTuning.html

http://otndnld.oracle.co.jp/document/products/wls/docs91/perform/HWTuning.html


セキュリティ

• アカウント利用時の注意事項

– デフォルトで作成される管理アカウントのみでの運用は危険

• 誤った(破壊的な)設定変更が行われるリスクがある

• パスワード間違えにより、アカウントロックされる

⇒運用に応じて適度にアカウントを分けておく

目的ロールグループ説明

システム管理用 Admin Administrators 構成変更を含め、すべての操作が行えるがアカウントロックやパスワード紛失に備え、複数用意しておくとよい

デプロイ用 Deployer Deployers アプリデプロイに関する操作のみ行えるため、アプリ担当が利用するとよい

モニタリング用 Monitor Monitors サーバー構成やランタイム情報の表示のみ行えるため、監視/統計に向いている

運用で利用する可能性の高いロール・グループ


セキュリティ

• WebサーバーでBASIC認証を行う際の注意点

– 第19回WLS勉強会のLT資料を参照

http://www.slideshare.net/OracleMiddleJP/webbasic

• X-Powered-Byヘッダーの無効化

– デフォルトでは「X-Powered-By: Servlet/3.0 JSP/2.2」のようにレスポンスヘッダに出力されるが、実装バージョンを含めないよう無効化してもよい

– <ドメイン>→[構成]→[Webアプリケーション]から設定

http://www.slideshare.net/OracleMiddleJP/webbasic


セキュリティ

• 一般的な推奨事項は以下ドキュメントを参照

Oracle Fusion Middleware ドキュメント・ライブラリ

> WebLogic Server

> SECURITY

> 本番環境の保護

参考リンク

– 12c Release 1(12.1.1) - 英語

• http://docs.oracle.com/cd/E24329_01/web.1211/e24418/toc.htm

– 11g Release 1(10.3.5) - 日本語

• http://docs.oracle.com/cd/E24001_01/web.1111/b61616/toc.htm

http://docs.oracle.com/cd/E24329_01/web.1211/e24418/toc.htm

http://docs.oracle.com/cd/E24001_01/web.1111/b61616/toc.htm


ネットワーク

• リスニングアドレス

– デフォルトでは指定されておらず、OSにバインドされている

すべてのIPアドレスやホスト名でアクセス可能

– 複数NICがあるマルチホーム環境では、リスニングアドレスを明示しないと、管理サーバー・管理対象サーバー間の通信が不安定になるため設定を推奨


ネットワーク

• ネットワークチャネル

– 目的(プロトコル)別に、リスニングするアドレスとポートを指定して追加し、性能・セキュリティ面の向上を図る

– 場合によっては管理ポートを有効化してもよい

[環境]→[サーバー]→<サーバー名>→[プロトコル]→[チャネル]から設定


管理

サーバー

ネットワーク

管理用セグメント

サービス用セグメント

管理系通信

サービス用通信

ネットワークの構成とリスニングアドレス・チャネルの設定例

A

サービス用の通信(http)はチャネルを明示的に定義 S

A 管理系の通信(t3, iiop, httpなど)はリスニングアドレスの設定

により作成されるデフォルトチャネルを利用

管理対象

サーバー

S

A

管理対象

サーバー

A

S


起動・停止スクリプト

起動スクリプトの構造

• <DOMAIN_HOME>/bin/startManagedWebLogic.sh

└ <DOMAIN_HOME>/bin/startWebLogic.sh

└<DOMAIN_HOME>/bin/setDomainEnv.sh

└<WL_HOME>/common/bin/commEnv.sh

停止スクリプトの構造

• <DOMAIN_HOME>/bin/stopManagedWebLogic.sh

└ <DOMAIN_HOMEbin/stopWebLogic.sh

└<DOMAIN_HOME>/bin/setDomainEnv.sh

└<WL_HOME>/common/bin/commEnv.sh



• デフォルトで作成される起動・停止スクリプトを最大限活用

– インスタンス単位のカスタムスクリプトを用意し、そこから

start(Managed)WebLogic.sh, stop(Managed)WebLogic.sh

を呼び出す形式にする

– ドメイン共通の設定は、setDomainEnv.sh に設定する

環境変数説明

JAVA_HOME WLSを起動するJDKのホームディレクトリ

JAVA_VENDOR JDKのベンダー(ex. Oracle, Sun, HP, IBM)

USER_MEM_ARGS デフォルトで設定されるメモリ用起動オプション(MEM_ARGS)を上書き

JAVA_OPTIONS システムプロパティ(-D<key>=<value>)やGCログ用オプションなど、

通常のJava起動オプションを設定

CLASSPATH クラスパスを設定するが、付加する位置を制御するために、PRE_CLASSPATHやPOST_CLASSPATHも利用可能

SERVER_NAME WLSを識別するサーバー(インスタンス)名

ADMIN_URL 接続先となるサーバー(通常、管理サーバー)のURL

利用する可能性の高い環境変数



起動・停止スクリプト共通の考慮点

• OSアカウントによる制限

– rootで起動されてしまい、作成されるファイルのオーナーが変更されるトラブルを防ぐ

• その後、通常アカウントで起動する際に、ファイルの書き込みに失敗し、起動できなくなる危険がある

• umaskによるパーミッションの設定

– WLS11g以降の起動スクリプトでは、umaskが「037」

– WLS11g以降の停止スクリプトでは、umaskが「026」

⇒ログファイルの読み取りなどに注意が必要



起動スクリプトの考慮点

• 管理対象サーバー起動時の管理サーバーへの接続

– 明示的に管理サーバーのURLを指定する

startManagedWebLogic.sh <server> t3(s)://<admin_host>:<port>

SERVER_NAME(必須) ADMIN_URL(省略可)

※URLを指定しないと、デフォルトで「http://<admin_host>:<port>」になる

⇒若干、管理サーバーとの通信の安定性に懸念がある

– OS起動時に自動起動する場合は、管理サーバーとの起動順序やリトライを考慮する

• Windowsサービス(beasvc[≦11g],wlsvc[12c])で起動する場合は、管理サーバーのサービス起動後に管理対象サーバーを起動するよう設定することも可能



停止スクリプトの考慮点

• 管理対象サーバーを停止する際は、明示的に各サーバー自身のURLを指定する

stopManagedWebLogic.sh <server> t3(s)://<managed_host>:<port>

SERVER_NAME(必須) ADMIN_URL(省略可)

※URLを指定しないと、管理サーバー経由で停止することになる

⇒管理サーバーが正常に稼働していないと停止できない

(stopWebLogic.sh 抜粋) echo "connect(${userID} ${password} url='${ADMIN_URL}', adminServerName='${SERVER_NAME}')" >>"shutdown.py" echo "shutdown('${SERVER_NAME}','Server', ignoreSessions='true')" >>"shutdown.py" echo "exit()" >>"shutdown.py" echo "Stopping Weblogic Server..." ${JAVA_HOME}/bin/java -classpath ${FMWCONFIG_CLASSPATH} ${MEM_ARGS} ${JVM_D64} ${JAVA_OPTIONS} weblogic.WLST shutdown.py 2>&1



停止スクリプトの考慮点(続き)

• shutdown時のオプションに注意

– デフォルトでは処理中の実行スレッドがあると停止しない

⇒force='true'やtimeOut=n(秒)オプションの指定を考慮する

– OSコマンドでの停止も検討する

kill -SIGTERM (SIGINT[Ctrl+C]でも基本的に同様)

• force='true'と同様だがJVMの停止フックを利用

kill -SIGKILL (Windowsではtaskkill /F /PID)

• 最終手段であり、ロックファイルが残るなどの弊害が生じる可能性がある

• 同一マシン内での同時実行

– shutdown.py が同時に書き込まれ、失敗する可能性がある

⇒shutdown-${SERVER_NAME}.py などに変更


監視/統計

監視

• プロセス監視

java ～ -Dweblogic.Name=<server> ～ weblogic.Server

• ヘルスチェック

– WLS8.1までは weblogic.Admin PINGを利用することがあったが、weblogic.AdminユーティリティはWLS9.0以降で非推奨になった

• WLSTのconnectが直接の代替だが、ヘルスチェックとしては重い

– HTTPリクエストを実際に投げて応答をチェックするのが現実的

• アクセスログに記録されることは避けられない

• フルGCを考慮してタイムアウトやリトライを実装

プロセス名サーバー(インスタンス)名の識別 WLSのメインクラス


監視/統計

監視

• ログファイル

– サーバーログよりもコンソールログを監視対象とする

• 基本的に重大度の高いログのみが出力され、目視でも確認しやすい ※サポートへはサーバーログも併せて要送付

• OOMEなどの問題も検出しやすい

• 監視のテストも行いやすい

– ドメインログは監視には向いていない

• リアルタイムに出力されない

• 管理サーバーが停止しているとドメインログは出力されない

重大度監視有無

Emergency, Alert, Critical 基本的に監視対象とすべき

Error, Warning 場合によって監視対象とする

Notice, Info, Debug, Trace 基本的に監視対象とすることはない

※重大度をベースとし、特定のメッセージID(BEA-xxxxxx)を包含・除外する


監視/統計

監視

• メトリック値による閾値判定・アラート

– MBeanによるモニタリング

• WLST, WLDFなど組み込みのツール

• その他のJMX対応モニタリングツール

MBeanの種類説明

JVMRuntime ヒープサイズや空き容量を取得する

ThreadPoolRuntime スレッドの使用状況を取得する

WebAppComponentRuntime HTTPセッションの使用状況を取得する

JDBCDatasourceRuntime JDBCデータソースの使用状況を取得する

監視に利用する代表的な実行時MBean


監視/統計

統計

• ログファイルの集計

– HTTPアクセスログ

• 平均所要時間、最大所要時間など

• ステータスコードごとの件数など

一般的なアクセスログ解析はWebサーバー側で行った方がよい

– GCログ

• GCの回数、平均所要時間など

• フルGC後のヒープサイズの推移など

• メトリック値の収集・蓄積

– MBeanによるモニタリング

• 監視の項を参照


監視/統計

ThreadPoolRuntime

0

10

20

30

40

50

60

70

2009

/2/1

3 10

:41:

27

2009

/2/1

3 10

:43:

27

2009

/2/1

3 10

:45:

27

2009

/2/1

3 10

:47:

28

2009

/2/1

3 10

:51:

24

2009

/2/1

3 10

:53:

25

2009

/2/1

3 10

:55:

25

2009

/2/1

3 10

:57:

52

2009

/2/1

3 10

:59:

52

2009

/2/1

3 11

:01:

53

2009

/2/1

3 11

:03:

53

2009

/2/1

3 11

:05:

54

2009

/2/1

3 11

:08:

18

2009

/2/1

3 11

:10:

37

2009

/2/1

3 11

:12:

38

2009

/2/1

3 11

:14:

38

2009

/2/1

3 11

:17:

04

2009

/2/1

3 11

:19:

05

2009

/2/1

3 14

:29:

59

2009

/2/1

3 14

:32:

12

2009

/2/1

3 14

:34:

24

2009

/2/1

3 14

:48:

50

2009

/2/1

3 14

:50:

50

2009

/2/1

3 14

:53:

01

2009

/2/1

3 14

:55:

29

2009

/2/1

3 14

:57:

30

2009

/2/1

3 14

:59:

32

2009

/2/1

3 15

:01:

34

2009

/2/1

3 15

:03:

36

2009

/2/1

3 15

:05:

38

2009

/2/1

3 15

:07:

56

2009

/2/1

3 15

:10:

18

（単位

： -

）

ExecuteThreadIdleCount

ExecuteThreadTotalCount

StandbyThreadCount

HoggingThreadCount

PendingUserRequestCount

Throughput

スレッドの利用状況例 (by WebLoDOCK-Monitor/Viewer)


[宣伝] WebLogic診断/監視サービス(WebLoDOCK)


[宣伝] WebLogic診断/監視サービス(WebLoDOCK)

WebLogic診断/監視サービス(WebLoDOCK) の提供内容

運用支援ツール（WebLoDOCK-Monitor）診断レポートに必要な情報を取得するための監視モニターツールです。

WebLogic Serverから必要な情報を一度に取得することが可能です。

また、閾値の設定により、メールによるアラート通知やスレッドダンプの取得も行えます。

⇒障害およびサービスダウンを未然に防ぐ

⇒サポートによる問題解決時間の短縮

情報閲覧ビューワ（WebLoDOCK-Viewer） WebLoDOCK-Monitorで取得した情報を閲覧する専用ビューワです。

グラフ化することで、WebLogic Serverの稼働状況を把握することが可能になります。

作成されたグラフは、エンドユーザ様への報告資料にもご活用いただけます。

⇒可視性の向上

診断レポート WebLoDOCK-Monitor、および各種ログ情報などから障害が発生していないか、

障害が発生しそうな兆候はないかについて、弊社エンジニアが診断致します。

また、簡易的なチューニングのご提案も含みます。

⇒運用管理者の心強い味方


Q&A

トラブルに強いweblogic serverの設計と構築 - 第20回 weblogic server勉強会資料

Technology