Comments
Description
Transcript
システム設計 1 ISE Webシステム基盤 佐藤 なみえ（）
システム設計 ISE Webシステム基盤 佐藤 なみえ（[email protected]） 1 05. システム設計 Disclaimer この資料は日本アイ・ビー・エム株式会社ならびに 日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレビューを受けておりませ ん。 当資料は、資料内で説明されている製品の仕様を保証するものではありません。 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2010年12月現在の情 報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能性があるのでご注意 下さい。 今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。 2 WAS V7 最新動向Workshop 2 05. システム設計 Agenda §1. JVM GCポリシーの選択 §2. セキュリティ – §2.1. SSLの証明書期限切れ問題 – §2.2. SSLの2010年問題 – §2.3. SAMLサポート §3. タイマー設計 §4. MDBリスナーサービスの選択 3 よく聞かれる 最新事例 よく聞かれる 重要 V7.0.0.7 New よく聞かれる Update WAS V7 最新動向Workshop 3 セッション番号. セッション番号. セッションタイトル §1. JVM GCポリシーの選択 4 WAS V7 最新動向Workshop 4 05. システム設計 JVM設計でよくある質問 GCポリシーは何を選択すればよいですか？ genconは使われていますか？ 考慮点は何ですか？ 大容量ヒープの場合の考慮点は何ですか？ 確認 GC（ガーベッジ・コレクション）とは 9GCは、JVMが動的に確保したメモリ領域のうち、不 要になった領域を自動的に解放する機能 9GCの実行時間はアプリケーションが停止する 5 JVM WAS V7 最新動向Workshop GCとはJavaヒープ上の不要オブジェクトを自動的に開放する機能です。 GCの実行時は、アプリケーションが停止します。 IBMJDKで提供されている4つのGCポリシーの選択基準、特にgenconについてご 紹介します。 5 05. システム設計 GCのポリシー選択、ヒープサイジングのステップ ステップ1 アプリケーション特性を把握する ステップ2 要件定義 設計 アプリケーション特性を基に、適切なGCポリシーを選択する GCのメカニズムを理解する GCに適した一般的なアプリケーション特性を理解する ステップ3 ヒープサイズを見積もる ステップ4 構築 テスト ステップ5 6 パフォーマンス要件とアプリケーション特性を把握する 大容量ヒープの考慮点を把握する ヒープサイズが適切であることを確認する GCのモニタリング方法を理解する 一般的な評価基準を把握する 十分なテスト・チューニングを行う WAS V7 最新動向Workshop GCやポリシーの調整については、テストフェーズでのGCのモニタリング方法やモ ニタリング結果の評価基準についてのガイドがあります。 今回は、設計フェーズでGC/ヒープサイズの観点でやるべきことをご紹介します。 6 05. システム設計 ステップ１：アプリケーション特性の把握 アプリケーション特性とパフォーマンス要件を把握する アプリケーション特性を把握する – 例 • DBアクセスなどトランザクションが多く発生する • セッションオブジェクトが多く、セッションタイムアウトが長い レスポンス • バッチタイプのアプリケーションである タイム スルー プット パフォーマンス要件を把握する – 例 • スループット（システムが処理できるデータ量）を最大にしたいのか？ • レスポンスタイムを最小にしたいのか？ – 平均レスポンスタイムと最大レスポンスタイムのどちらが重要なのか？ – 同じGCの実行時間でも、それが問題になるかどうか？はパフォーマンスの 要件に依存する – アプリケーションのレスポンスタイムに影響するものとして、GCはそのひとつ である 7 WAS V7 最新動向Workshop まず最初にアプリケーション特性とパフォーマンス要件を把握します。 特に、JVMのパフォーマンスに問題があるかどうか？はパフォーマンスの要 件に依存します。 GCの実行時間が500ミリ秒でも、問題となるケースもあるし問題とな らないケースもあります。 数十ミリ秒のGC実行時間の改善が、有用であるケースもあるしそう でないケースもあります。 また、基本的なことですが、GCの実行時間とアプリケーションのレスポンス タイムはイコールではない点も認識しておく必要があります。 GCの実行時間はアプリケーション処理は停止しますが、停止時間 が短いからといって、レスポンスタイムが保証されるわけではありませ ん。また、レスポンスタイムが長さが、すべてGCの停止時間に起因し ているわけでもありません。 7 05. システム設計 ステップ２：GCメカニズムの理解 GCポリシー optthruput (Optimize for throughput) JDK 6(WAS 7)の デフォルト optavgpause (Optimize for pause time) スループットと停止時間 のトレードオフ gencon (Generational concurrent) optthruputとoptavgpause のハイブリッド subpool (Subpooling) アプリケーションスレッドとGCスレッドの関係 アプリ稼動 スレッドn GC 時間 スループットが 高い GCによる停止時間 が長い Global GC Scavenge GC スレッドn Concurrent mark 時間 GCによる停止時間 が低い スループットが optthruputより低い （GCとAppの 並行処理のため） Concurrent sweep スレッドn 時間 ライフサイクルの短 いObjに対しては、 短いGC処理 ライフサイクルの長いObj に対しては、GCとAppの 並行処理 POWERアーキテクチャー・プラットフォームのSMP構成マシンでのみ有効。 JDK 6ガイドでは16CPU以上、WAS 7ガイドでは8CPU以上での使用が推 奨される。 8 WAS V7 最新動向Workshop 適切なGCポリシーを選択する前に、各GCの動きを確認します。 詳細は、下記ドキュメントをご参照ください。 WebSphere Application Server V7.0によるWebシステム基盤設計ワークショップ 資料 JVM設計 http://public.dhe.ibm.com/software/dw/jp/websphere/was/was7_guide/WASV 70Design_02JVM.pdf JVM設計-参考http://public.dhe.ibm.com/software/dw/jp/websphere/was/was7_guide/WASV 70Design_reference_02JVM.pdf 8 05. システム設計 【参考】ステップ２：GCメカニズムの理解 genconの動作 確認 9 オブジェクト寿命の傾向に着目したGC方式 9 GC対象となる確率の低いオブジェクトにはGCはあまりかけずに、GC対象とな る確率の高いオブジェクトにGCが多くかかるようにオブジェクトの配置を決定 New領域(new obj 割当) Scavenge GC実行 Allocate space Survivor space ①Before Scavenge GC ②After Scavenge GC Old領域(old obj 割当) Global GC実行 Tenured space GC対象obj 使用中obj Survivorへコピー 長い期間（JVMが 自動調整）GCされ ない使用中obj Old領域へコピー Allocate spaceとSurvivor space が入れ替わる 9 WAS V7 最新動向Workshop genconポリシーの場合は、他のポリシーと異なり、オブジェクトのライフサイクルに あわせて領域がNew領域とOld領域に分割されます。New領域は、さらに AllocateSpaceとSurvivorSpaceに分割されます。 New領域にアロケートされたオブジェクトは、一定期間GC対象にならない場合は Old領域に移動されます。 9 05. システム設計 ステップ２：GCポリシーの選択 GCポリシー GC実行によ 適するアプリケーション る停止時間 optthruput 長い レスポンスタイムよりス ループットを重視するア プリケーション（バッチ 処理等） 短い 一般的に、 opttruputの 90～95% スループットよりレスポ ンスタイムを重視する アプリケーション New領域 （ライフサ イクルの 短いobj） 短い ライフサイクルの短い オブジェクトが多いアプ リケーション（トランザク ション・ベース等） Old領域 （ライフサ イクルの 長いobj） 長い 発生頻度 が低い optavgpause gencon よく聞かれる ヒープサイズ 設定箇所 初期ヒープサイズ 最大ヒープサイズ 実績 多数 WAS 7のデフォルト 値 少ない 初期ヒープサイズ 最大ヒープサイズ ＋ New領域/Old領域 のサイズ 10 多数 WebSphere Portal のデフォルト値 WESB 7のデフォル ト値 WAS 8のデフォルト 値（β版InfoCenter より） WAS V7 最新動向Workshop GCポリシーの選択について上記にまとめました。 一般的に、optthruputは、GC実行による停止時間が長いかわりにスループットがよ いので、バッチ型処理やスループット重視型のアプリケーションに向いています。 genconは、オブジェクトのライフサイクルが短いトランザクションとオブジェクトのライ フサイクルが長いフレームワークが共存するようなトランザクション型の処理に向い ているといわれています。 10 05. システム設計 ステップ３：ヒープサイズの見積もり ヒープサイズを見積もる例 – アプリケーション・サーバのメモリ・フットプリント • • 領域 OLD メモリのモニタリングツール（後述verbose:gcログやTPV）でアプリケーションサーバ起動時のメモリ使用量を把握 管理コンソールの有無、ランタイム・プロビジョニング機能の有無とOS、アプリケーションのタイプにより、メモリ使用 量が異なる – アプリケーション・フレームワークの使用領域 • サンプルシナリオを実行し、メモリのモニタリングツールで、GC実行後の使用領域等から推定 – セッション・オブジェクト • 最大セッション・サイズ＊最大セッション数 – TPVで最大セッション・サイズを把握 – 最大セッション数は、サーバ台数とAffinityの有無、セッションタイムアウトも考慮 – メモリ間セッションパーシスタンスの有無も考慮 領域 NEW – トランザクションが使用する領域 • （１トランザクション処理で使用する領域＋データ量）＊最大同時トランザクション数 – １トランザクション処理で使用する領域は、サンプルシナリオを実行して確認 – 最大同時トランザクション数はサーバ台数も考慮 – ファイル等の大きいデータを扱うシナリオも考慮 – 安全率、余裕率を掛ける • 例）1.5倍～2倍程度 – JVM環境の調整分を掛ける • • • 例） genconの場合、New領域はSurvivor spaceを考慮して2倍する 例） JVMはヒープ使用率を40～70%で自動調整するため、1.2倍する 例） 64ビット版JVMの場合、32ビット版JVMに比べて最大で60%(note参照)程度のメモリを使用するため、1.2倍す る 11 WAS V7 最新動向Workshop ヒープサイズの見積もりには、明確なガイドがありません。しかし、ヒープサイズが全 く想定できない場合や、見積もったヒープサイズと大きな隔離が無いかを確認する ために、見積もりが必要な場合があります。 見積もりの観点を例として、上記にまとめました。 genconの場合は、アプリケーション・サーバ、フレームワーク、セッション・オブジェ クトが使用する領域がOld領域となり、トランザクションが使用する領域がNew領域 となります。 安全率やJVM環境の調整分も考慮する必要があります。 64bitの場合、32bitJVMに比べて最大60%のメモリを使用しますが、WAS 7では参 照圧縮の機能があるため、10%から20%に抑えることができます。 11 05. システム設計 ステップ３：巨大ヒープ を使用する場合の考慮点 よく聞かれる 巨大ヒープの必要性を確認する ヒープサイズが大きいほど、ネイティブヒープも使用する 32ビットJVMの場合、制限値と推奨値がある プラットフォーム AIX オプション automatic Linux Hugemem Kernel Windows /3GB z/OS 設定可能最大ヒープサイズ 推奨最大ヒープサイズ 3.25GB 2.5GB 2GB 1.5GB 3GB 2.5GB 1.8GB 1.5GB 1.8GB 1.8GB 1.7GB 1.3GB 出典：http://www-01.ibm.com/support/docview.wss?uid=swg27013824 初期値としてgenconを検討する ヒープダンプの出力先に十分な空き領域を確保する – ヒープダンプは、Javaヒープ上で存続している（アプリケーションで使用中の）す べてのオブジェクトをダンプしたファイル（次ページ参照） 12 WAS V7 最新動向Workshop 当然ではありますが、ヒープサイズとGC実行時間はトレード・オフとなりますので、 まずは巨大ヒープが本当に必要かどうか？を確認する必要があります。 また、32bit版の場合、下記リンクのように最大ヒープサイズの推奨値があります。 Webcast replay: Best Practices for Tuning Java 5.0 Garbage Collection on the IBM Platforms http://www-01.ibm.com/support/docview.wss?uid=swg27013824 ヒープダンプは最大ヒープサイズの1/4のサイズで出力されるため、十分な空き領 域を確保しておく必要があります。 12 05. システム設計 設計フェーズでのGCポリシーとヒープの選択 プロジェクトや プロジェクトや アプリの アプリの 推奨値は？ 推奨値は？ ない アプリケーション特性は？ アプリケーション特性は？ トランザクション タイプ パフォーマンス要件は？ パフォーマンス要件は？ バッチタイプ ある レスポンスタイム 重視 スループット 重視 optthruput optthruput ガイド・要件に沿って設定 ガイド・要件に沿って設定 ある程度見積もる ことができる gencon gencon 最大・最小ヒープサイズは？ 最大・最小ヒープサイズは？ 検討を つけられない。。。 最大ヒープ：物理使用可能メモリの 最大ヒープ：物理使用可能メモリの 1/2より小さく 1/2より小さく 最小ヒープ：最大ヒープの1/4 最小ヒープ：最大ヒープの1/4 ある程度 見積もることができる genconの場合 genconの genconの 最大・最小New/Oldは？ 最大・最小New/Oldは？ 13 検討を つけられない。。。 デフォルトからスタート デフォルトからスタート または または New/Old最大は最大ヒープの1/2ずつ New/Old最大は最大ヒープの1/2ずつ 物理メモリに余裕があれば 物理メモリに余裕があれば 最大ヒープ 1024MB 最大ヒープ 1024MB 最大New領域 512MB 最大New領域 512MB 最大Old領域 512MB 最大Old領域 512MB 使用量をみて大きければ減らす 使用量をみて大きければ減らす WAS V7 最新動向Workshop 設計フェーズでのGCポリシーとヒープサイズ選択方法についてまとめました。 genconの場合はNew/Old領域の調整が必要なりますが、この点に関してはP.16 でご紹介いたします 13 05. システム設計 【参考】ステップ４：GCのモニタリング方法の理解 解析対象資料 説明 設定方法 verbose:gcログ Javaヒープの使用状況 やGCの稼動状況の情 報 管理コンソール（冗長ガーベッ ジ・コレクションプション）、また は、JVM引数で設定 デフォルトで、 native_stderr.logに出力 解析ツール(*) Garbage Collection and Memory Visualizer IBM Pattern Modeling and Analysis Tool for java Garbage Collector GC Collector Javaダンプ （javacore) ヒープダンプ デフォルトでJVMのクラッシュ JVMに関するダンプ情 報。OS情報、環境変数、 時や、QUIT(kill -3)シグナルを 稼動する全実行スレッド 受け取ったときに生成 のダンプ情報 JVMが使用するヒープ 上に存在する全liveオブ ジェクトのダンプ情報（メ モリを多く使用している オブジェクト等が確認可 能） デフォルトで、OutOfMemory発 生時に自動生成 (クラッシュ時にも生成するよう に環境変数で設定変更可能) IBM Thread and Monitor Dump Analyzer for Java ThreadAnalyzer HeapAnalyzer HeapRoots Java用メモリー・ダンプ診断 (MDD4J) (*)解析ツールの青字部分はIBM Support Assistance (ISA)で提供 上記のファイルを解析するツールに加えて、TPV、Health CenterなどJVMの状況をリアルタイムで把 握できるツールも提供（Health Center詳細は「システム運用」セッションを参照） 14 WAS V7 最新動向Workshop GCモニタリング方法をご紹介しています。 詳細は下記リンクをご参照ください。 IBM Support Assistant 4.1 利用ガイド http://www.ibm.com/developerworks/jp/websphere/library/was/isa41_guide/ 14 05. システム設計 【参考】ステップ４：ヒープサイズに関する一般的な指針 ヒープサイズ – JVMはヒープサイズの使用率を40%～70%で維持しようとして拡張・縮小する • • 70%以上の場合は、GCが頻発しパフォーマンスが低下する可能性がある 40%以下の場合は、GC実行時間が必要以上に長くなり、パフォーマンスが低下する可能性がある GCの稼動状況を確認する – （１）GCの実行間隔の平均は、GC1回の実行時間の平均の5～6倍 • • GCの平均実行間隔は、10秒以下だと短いとされている GCの平均実行時間は、1秒以上だと長いとされている – （２）GCの合計実行時間は、アプリケーション全体の合計実行時間の5～20% • • 一般的には13%～15%程度がよいとされている 値が低い場合、ヒープサイズが大きすぎる、またはGCポリシーが適切でない可能性がある ネイティブヒープと物理メモリを考慮して最大ヒープサイズを決定する – Javaプロセスサイズ＝Javaヒープ＋ネイティブヒープ – ネイティブヒープはJavaヒープのような制御ではないため、ネイティブヒープが枯渇した場合 の振る舞いは予測できない • アプリケーションが機能し続ける場合もあるし、OutOfMemoryErrorをスローする場合もある 15 WAS V7 最新動向Workshop 赤字部分はWAS7のマニュアル、その他はDeveloperDomain等に公開されている ガイドより抜粋しています。 GCでのモニター結果をこれらの指針に合わせてご確認ください。 そのガイドをご紹介します。 IBM の Java 仮想マシンの調整 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ib m.websphere.nd.doc/info/ae/ae/tprf_tunejvm_v61.html Webcast replay: WebSphere Application Server V6.1 Performance and Tuning http://www-01.ibm.com/support/docview.wss?uid=swg27011085 Webcast replay: Best Practices for Tuning Java 5.0 Garbage Collection on the IBM Platforms http://www-01.ibm.com/support/docview.wss?uid=swg27013824 15 05. システム設計 重要 genconのヒープサイズ調整 New領域(new obj 割当) Allocate Survivor space space Old領域(old obj 割当) Tenured space 9 初期ヒープサイズ（-Xms）：WAS 7デフォルト50MB 9 最大ヒープサイズ（-Xmx）：WAS 7デフォルト256MB New領域の デフォルト値 が小さい 9 固定エリアサイズ（-Xmn）： 9 初期エリアサイズ（-Xmns）：JDK 6デフォルト-Xmsの25% 9 最大エリアサイズ（-Xmnx）：JDK 6デフォルト-Xmxの25% JDK 5のデフォルト は-Xmsの25%と 64MBの小さいほう 9 固定エリアサイズ（-Xmo）： 9 初期エリアサイズ（-Xmos）：JDK 6デフォルト-Xmsの75% 9 最大エリアサイズ（-Xmox）：JDK 6デフォルト-Xmxと同じ New領域 –デフォルト値では小さい場合が多いため注意が必要 •WebSphere では512MBから試行することを推奨するガイドあり –リクエストのスループットを優先したい場合･･･New領域を大きくする –一回のGC時間を短くしたい場合･･･New領域を小さくする Old領域 –持続性のあるデータが格納される十分な領域が必要 •一般的なWAS上アプリは100～400MBであるというガイドあり –適切な設定の場合、Global GCの発生頻度は非常に少ない 16 WAS V7 最新動向Workshop NEW領域の初期値には注意が必要です。 JDK5（WAS 6.1）のNEW領域の初期値は、初期ヒープサイズの25%か64MBの 「小さいほう」であったため、どんなに大きなヒープサイズを指定しても64MBになっ てしまうため注意が必要です。 JDK6ではNEW領域の64MBの制限がなくなりましたが、それでもNEW領域は小さ い可能性があるため注意が必要です。 JDK5 Garbage Collector command-line options http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/topic/com.ibm.java.doc. diagnostics.50/diag/appendixes/cmdline/cmdline_gc.html JDK6 Garbage Collector command-line options http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/com.ibm.java.doc. user.lnx.60/diag/appendixes/cmdline/commands_gc.html Webcast replay: Overview of the IBM SDK for Java Version 6 http://www-01.ibm.com/support/docview.wss?uid=swg27012709&aid=1 16 05. システム設計 【参考】ヒープサイズ設定のふたつのアプローチ ダイナミック・アプローチ – 初期ヒープサイズ、最大ヒープサイズを異なる値に設定 Fixedアプローチ – Fixedアプローチの有用性、適切なヒープサイズを確認するためには、ある程 度の試行錯誤が必要 – 長時間、ヒープ中の使用メモリが一定である場合に適する – 初期ヒープサイズと最大ヒープサイズを同じ値に設定 • ヒープサイズを、アプリ使用最大メモリの1.5倍の設定から試行することが推奨さ れている – 不必要なヒープの縮小・拡張処理を削減することでパフォーマンスをアップさ せる • 初期ヒープと最大ヒープは別々に設定し、縮小処理だけ無効にする（-Xmaxf=1） 方法もあり – NewとOldの領域を固定する（-Xmn/-Xmoを指定）アプローチもあり 17 WAS V7 最新動向Workshop ヒープサイズの最もよくあるパターンは、初期ヒープサイズと最大ヒープサイズは異 なる値を設定して、最適なヒープサイズの値をJVMに任せるアプローチです。 一方、長期間、ヒープの使用メモリが一定である場合には、初期ヒープサイズと最 大ヒープサイズを同じ値に設定するFixedアプローチを選択することも可能です。 Fixedアプローチを選択する場合は、その有用性、最適なヒープサイズの確認等に、 ある程度のトライ＆エラーが必要です。 17 05. システム設計 最低限やっておくべきこと 設計フェーズ – – – – – WASのverbose:gcは常時Onにする GCポリシーはデフォルト（optthruput）で様子をみる 最大ヒープサイズは利用可能物理メモリの1/2以下とする 最小ヒープサイズは最大ヒープサイズの1/4とする DMノードの物理メモリに余裕を持たせる • DMの最大ヒープデフォルト値256MBが、アプリデプロイ等で、テスト・運用 フェーズで不足するケースがあるため – javacoreとヒープダンプの出力先を指定し、十分な空き容量を確保する • OSのコア出力容量も考慮する テストフェーズ – 以下の状況からメモリ使用状況がボトルネックでないことを確認する • OSのメモリ使用状況 • JVMのメモリ使用状況（GC平均実行時間、GC平均実行間隔、GC実行時間 の割合） 18 WAS V7 最新動向Workshop 設計フェーズで最低限必要な項目をまとめました。 GCポリシーと最大・最小ヒープサイズについては、P.13のフローを参考にしてくだ さい。 18 05. システム設計 【参考】ネイティブヒープを使用するJavaコンポーネント JITコンパイラー – Javaバイトコードからネイティブ・バイナリーコードへのコンパイルと、その出力にNative Memoryを使用する – JITでコンパイルされたメソッドが多数含まれるJavaアプリケーションは、多くのNative Memoryを使用する クラスとクラスローダー – IBM Java5以降はクラスローダーごとにNative Memoryを割りあて、そこにクラス･データを格納する（共有ク ラスとして使用される） • 業務アプリケーション、フレームワーク、アプリケーション・サーバ、サード・パーティのライブラリー等のすべてのクラス – クラスローダの数が多いほど、ロードするクラスが多いほどNative Memoryが使用される • それぞれ 1 つのクラスをロードする多数のクラスローダーを使用すると、1 つのクラスローダーで多数のクラスをロードす るよりも、ネイティブ・メモリーの使用量は増える JSPのクラス java.lang.reflect API の使用時 JNI NIO – Java 1.4 で追加された新規 I/O (NIO) クラス – データを保持するバッファーの一部がNative Memoryを使用する スレッド – Nativeスタック（ローカル変数を保持し、関数呼び出しの際に状態を維持するためのメモリー領域）、内部 データ構造用などのNative Memoryが必要 – 標準的な値は、256KB から 756KB の間で指定可能（要確認） – スレッド数が多いと多くのNative Memoryを使用することになる 19 WAS V7 最新動向Workshop JVMを稼動させる場合、ヒープサイズと同様に、ネイティブヒープが使用されている 点も重要です。 上記にネイティブヒープを使用するコンポーネントをまとめましたのでご参照くださ い。 また、WASのAIO（Asynchronous I/O）機能がネイティブ・ヒープを消費するため、 無効化することでネイティブ・ヒープの消費量を抑える方法が下記ガイドで紹介され ています。 Disabling AIO (Asynchronous Input/Output) native transport in WebSphere Application Server http://www-01.ibm.com/support/docview.wss?uid=swg21366862 19 05. システム設計 【参考】ヒープダンプとJavacoreの出力先 重要 Javacore（Javaダンプ）とヒープダンプは、WebSphereの場合、デフォルトで、 /<Profile Root>/<Profile Name>/ 直下に出力される native_std.errに出力状況が書き込まれるため確認することが可能 – 例： • • JVMDUMP010I Java ダンプは /opt/IBM/WebSphere70/AppServer/profiles/AP01/javacore.20100601.135015.3986.0001.txt に書き込まれました JVMDUMP010I Heap ダンプは /opt/IBM/WebSphere70/AppServer/profiles/AP01/heapdump.20100601.161235.13688.0002.phd に書き込まれまし た 出力先の指定 – 出力先は以下の順序で決定される • JVMコマンドライン（-Xdump）で指定したファイル名 – 例）-Xdump:java:file=/core/javacore/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt – -Xdump:heap:file=/core/heapdump/heapdump.%Y%m%d.%H%M%S.%pid.%seq.phd – -Xdump:snap:file=/core/snap/Snap.%Y%m%d.%H%M%S.%pid.%seq.trc • 以下の環境変数で指定されたディレクトリ （WAS管理コンソールの場合、[アプリケーション・サーバー]>[アプリケーションサーバー名]>[Javaおよびプロセス管 理]>[プロセス定 義]>[環境エントリー] で設定） – IBM_JAVACOREDIR ･･･javacore出力先 – IBM_HEAPDUMPDIR ･･･heapdump出力先 – IBM_COREDIR ･･･systemdump.snap出力先 • カレント作業ディレクトリ（WASの場合、 /<Profile Root>/<Profile Name>/ 直下） – 空き領域不足、権限不足など、上記のディレクトリに書き込めない場合は、以下の順序で書 き込まれる • • • • 20 Windowsの場合、C:¥WINDOWS ディレクトリ TMPDIR環境変数で指定されたディレクトリ /tmpディレクトリ Windowsの場合、C:¥Temp ディレクトリ WAS V7 最新動向Workshop ヒープダンプとJavacoreの出力先は上記のように決定されます。十分な空き容量を 確保してください。 20 05. システム設計 まとめ Q. GCポリシーは何を選択すればよいですか？ A. バッチタイプ・スループット重視であればoptthruput、トラ ンザクションタイプ・レスポンスタイム重視であれば genconを選択してください。 Q. genconは使われていますか？考慮点は何ですか？ A. genconの事例は多数存在します。 ヒープサイズのチューニング箇所が増える点に注意してく ださい。適切な値が設定されれば、GC実行時間が大幅 に短縮される可能性があります。 Q. 大容量ヒープの場合の考慮点は何ですか？ A. 32ビットの場合は制限値があります。ヒープダンプ出力の ための十分な空き容量も必要です。 21 WAS V7 最新動向Workshop GCポリシーは、バッチタイプ・スループット重視であればoptthruput、トランザクショ ンタイプ・レスポンスタイム重視であればgenconを選択してください。genconの事 例は多数存在します。 21 セッション番号. セッション番号. セッションタイトル §2. セキュリティ SSLの証明書期限切れ問題 SSLの2010年問題 SAMLサポート 22 WAS V7 最新動向Workshop 22 05. システム設計 セキュリティの最新トピック よく聞かれる 重要 V7.0.0.7 New SSLの証明書期限切れ問題 – WAS 7 で機能改善されたものの問い合わせが多い SSLの「 暗号アルゴリズムにおける2010年問題」 – 2011年も引き続き2,048bit証明書への移行検討が必要な場合がある – 証明書の移行後も注意点がある WAS 7 FixPack7 でのSAMLサポート – シングルサインオン（SSO）、ID情報伝播方法の新しい選択肢 – 2010/12現在、日本語版InfoCenterでは検索・目次表示ができないため注意、 英語版での確認が必要（note部分参照） – バグFixの観点からFP11以上の利用を推奨 証明書期限切れを発生させないためには どうしたらよいですか？ 2010年問題に対して、何をすればいいですか？ SAMLサポートって何ができるんですか？ 23 WAS V7 最新動向Workshop WAS FixPack7からSAMLがサポートされました。現在、日本語版InfoCenterでは、 検索等機能が一部使用できないため、ブラウザの言語を英語にして検索してくだ さい。 Securing Web services using Security Assertion Markup Language (SAML) http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp? topic=/com.ibm.websphere.nd.doc/info/ae/ae/cwbs_samlovervi ew.html 23 05. システム設計 WASが使用するSSL SSLは、WASを使用するサーバーとクライアント間の安全な接続のために、トランスポート層の セキュリティーを提供 – HTTP/IIOP/LDAP/SOAPの通信を保護 – – サービスのアクセスは、インバウンド・アウトバンドともSSLで通信の保護が可能 管理者のアクセスとWASセル内コンポーネント間の通信もSSLで保護 （WASの管理セキュリティ：デフォルトOn） 証明書有効 期限切れ問題 DBサーバ WASセル 管理者 デプロイ メント マネージャ 2010年問題 MQサーバ LDAPサーバ 負荷分散装置 ノード エージェント Webサーバ エンドユーザ 認証サーバ イン バウンド 24 アプリ ケーション アウト サーバ バウンド アプリ ケーション サーバ ESB WAS V7 最新動向Workshop SSLはエンドユーザからアプリケーションアクセスに対して用いられるインバウンド SSLだけでなく、アプリケーションサーバから別コンポーネントへアクセスするアウト バウンドにも用いられます。 証明書有効期限切れ問題は、WASの管理セキュリティをOnにしてWASセル内の アクセスをSSLにした場合の問題です。 2010年問題は、認証局発行の証明書を使用している場合に該当する可能性があ ります。これは証明書を配置しているコンポーネントに該当するためWebサーバに 限りません。 24 05. システム設計 【参考】SSLの仕組み SSLの仕組み 確認 クライアント Ｗｅｂサーバー Client Hello ルート 証明書 ブラウザはルート証明書 を持つ ルート証明書を用いて サーバ証明書を検証 サーバからの 公開鍵を用いて セッション鍵の 元データを暗号化 ⇒共通鍵生成 サーバ 証明書 Server Hello Server Certificate サーバは、公開鍵を付けた サーバ証明書と秘密鍵を持つ サーバ 証明書 Server Hello Done Client Key Exchange サーバは自身の 秘密鍵で復号（重い処理） ⇒共通鍵生成 ここから暗号化 Change cipher spec Finished Change cipher spec Finished Application Data exchange 25 WAS V7 最新動向Workshop SSL通信では、サーバ側には、公開鍵を付けたサーバ証明書と、秘密鍵を持つ、 ということを確認してください。 25 05. システム設計 【参考】チェーン証明書の仕組み 確認 チェーン証明書の仕組み ルート証明書は、ブラウザ開発者の定める基準に合格した認証局が発行した証明書 –ブラウザには、大手認証局のルート証明書があらかじめインストールされている 認証局が発行する証明書は、ブラウザにインストールされた「ルート証明書」のいずれかで 電子署名される あるいは、 「ルート証明書」のいずれかで電子署名された「中間証明書」で、サーバ証明書 に電子署名 される 最終的にブラウザに登録されたルート証明書に行き着けば、そのサーバ証明書は信頼で きる、と判断する 26 WAS V7 最新動向Workshop WAS7ではチェーン証明書を使用しています。チェーン証明書の仕組みを確認し てください。 26 05. システム設計 §2.1 SSLの証明書期限切れ問題 27 WAS V7 最新動向Workshop 27 05. システム設計 WASでのSSL実装 WASは、JSSEを用いてSSLを実装する – JSSE （Java Secure Socket Extension）：SSLを実装するためのJava標準API JSSEでは、サーバ証明書と鍵をキーストア・トラストストアファイルで管理する – 証明書は、X.509 証明書 を使用 – WASは、PKCS12 フォーマットを使用（JKS, JCEKS, PKCS12 の3種類のフォーマットをサポート） – IHS、プラグインはKDBフォーマットを使用しており、 PKCS12とは互換性がないため管理の際は注意 WAS管理セキュリティーでは、Javaプロセス間の双方向SSL通信を実施する – サーバー認証とクライアント認証の両方を実施 キーストア –自分の証明書、鍵などの機密情報のリスト トラストストア –機密情報を含まない –SSL通信したい相手の証明書のリスト SSL通信のためには、 相手のサーバを信頼する＝トラストストアに相手の証明書がリストされている 必要がある 28 WAS V7 最新動向Workshop WASでSSLを実装する場合はJSSEを使用します。JSSEではサーバー証明書と 鍵を、キーストア・トラストストアというファイルで管理することを定義しています。 SSL通信のためには、相手のサーバを信頼するために、トラストストアに相手の証 明書がリストされている必要があります。 28 05. システム設計 重要 WASが使用するキーストア・トラストストア WASセル root-key.p12 DmgrDefaultRootStore ルート証明書鍵ストア ルート 15年 証明書 デプロイ メント マネージャ ③SSL通信 可能になる ノード エージェント アプリ ケーション サーバ trust.p12 CellDefaultTrustStore 共通トラストストア ルート 15年 証明書 key.p12 CellDefaultKeyStore デフォルト鍵ストア 署名 チェーン 1年 証明書A ①同期で配布 ②信頼できるサーバとしてリスト trust.p12 key.p12 NodeDefaultTrustStore NodeDefaultKeyStore 共通トラストストア デフォルト鍵ストア ルート 15年 証明書 署名 チェーン 1年 証明書B 29 WAS V7 最新動向Workshop 上図は、WASが使用するキーストア・トラストストアです。 ルート証明書は署名者証明書、チェーン証明書はルート証明書で署名された個人 証明書です。 29 05. システム設計 重要 証明書の有効期限切れと自動更新 WASセル STEP 1 1 root-key.p12 ルート 15年 証明書 trust.p12 DM trust.p12 ルート 15年 ルート 15年 証明書 証明書 NA AS trust.p12 trust.p12 ルート 15年 証明書 ルート 15年 証明書 key.p12 2 key.p12 チェーン 1年 チェーン 1年 証明書A 証明書A key.p12 2 key.p12 チェーン 1年 証明書B チェーン 1年 証明書B 1 2 ルート鍵ストアの検証 STEP 2 残りの鍵ストアの検証 STEP 3 証明書の有効期限切れが 検知される STEP 4 署名者証明書ごと置き換え られる STEP 5 新規証明書が同期して各 ノードに配布される 同期が 重要 30 WAS V7 最新動向Workshop 証明書の有効期限がどのようにチェックされ、証明書が自動更新するかを示した図 です。 ND環境では、共通トラストストアを各ノードに同期して配布するため、自動更新に は同期処理が重要となります。 SSL での証明書有効期限のモニター http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ib m.websphere.nd.doc/info/welcome_nd.html 30 05. システム設計 【参考】証明書の有効期限切れ問題 事例 同期に失敗して問題となったケースと対応 – 運用方法 • • • • • • – 管理セキュリティはOn 証明書の有効期限はデフォルト 証明書自動更新はOn DMは常時停止 自動同期はOff 運用シェルでプロセスを起動停止 DMノード ルート15年 チェーン1年 ASノード（NA&AS） 停止失敗のよ 運用シェルで うに見える 停止 ルート15年 現象 チェーン1年 ① 証明書の有効期限が切れる ② アプリケーション・サーバを停止しようとすると、証明書関連のプロンプトが出力される ③ 停止運用シェルの処理が上記②で一時停止し、アプリケーション・サーバが停止した ようにみえる – 対応 ① ② ③ ④ 31 DMを起動 wsadminコマンドで証明書更新 同期実施 アプリケーション・サーバを手動で一旦停止・起動 WAS V7 最新動向Workshop 従って、WAS 7では証明書有効期限切れ問題が無くなった、といわれていますが、 同期処理が実行できない場合は、追加対応が必要となるケースがあるため、注意 が必要です。 31 05. システム設計 WASでのSSL証明書 設計のポイント プロファイル作成時に、証明書の有効期限を長く設定する 重要 – ルート証明書 15年（デフォルト）～25年 を指定可能 – チェーン証明書 1年（デフォルト）～15年 を指定可能 プロファイル作成後に、証明書置き換えも可能 – 手順は下記ガイド参照 • 【FAQ】WAS V7.0 個人証明書（チェーン証明書）の置き換え手順 • http://www-06.ibm.com/jp/domino01/mkt/websphere.nsf/doc/006170D2 証明書の有効期限をモニター機能有効化を検討する – 以下の条件であれば自動更新に問題なし • DMは常時起動している • 同期は自動同期 – DMを常時停止している場合、自動同期を無効化している場合は、更新手順を 確認 • 【考慮事項】WAS ND V7.0 証明書自動更新機能について (WAS-09-024) • http://www.ibm.com/jp/domino01/mkt/cnpages1.nsf/page/default-0007F8D1 32 WAS V7 最新動向Workshop WASのSSL証明書で有効期限切れを起さないために最もよい方法は、プロファイ ル作成時に有効期限を長く設定することです。 ただし、プロファイルを既に作成済みの場合は、証明書の置き換えや、自動更新機 能の有効化を検討してください。 32 05. システム設計 【参考】管理コンソールからのSSL証明書管理 33 WAS V7 最新動向Workshop WASで管理するSSL証明書は、上記リンクから確認することができます。 33 05. システム設計 §2.2 SSLの2010年問題 34 WAS V7 最新動向Workshop 34 05. システム設計 暗号アルゴリズムの2010年問題とは 米国立標準技術研究所（NIST）が現在の標準暗号の利用を廃止し、より安全性の高い であろう次世代暗号への2010年内に移行を強制する方針を打ち出したこと が発端 暗号技術要素 移行対象となった規格 共通鍵暗号 2-key Triple DES（2TDES） 推奨される規格 AES 公開鍵暗号 1024-bit RSA/DH/DSA 2048-bit RSA/DH/DSA以上 or 256-bitECDSA/ECMQV以上 ハッシュ関数 SHA-1 SHA-2（SHA-224以上） 但し日本では2010年から「要件」とし、2013年までに移行を「完了」 するスケジュール CA/ブラウザ・フォーラムではNISTの方針を受け，EV-SSL証明書について，2010年12 月末までに1024bit鍵長の加入者(End-Entity)証明書を失効させるよう決定 → 2010年以降は2048bit鍵長のEV-SSL証明書を使用を強制 さらに、ベリサインでは、グローバル・サーバーIDおよびセキュア・サーバーID についても2010年内に1024bitから2048bitに仕様変更する旨を公表 35 WAS V7 最新動向Workshop マシン能力の向上に伴い、現行の暗号アルゴリズムが安全と言い切れない状況に なってきました。 その背景を踏まえて、NISTでは、より強度の高い暗号化アルゴリズムへの移行を推 奨しています。 サーバ証明書に関しても、EV-SSL証明書については2048bit鍵長への移行が必 要です。 さらにそれ以外の証明書についても対応が必要な場合があります。 35 05. システム設計 2010年問題への対応 ベンダーへ置き換えの要否を確認する – 証明書には信頼性に応じて複数の証明書がある – EV-SSL証明書 • 2010年中に、暗号化強度1024ビットから2048ビットへの置き換えが必須 – その他の証明書 • 各ベンダーによって対応が異なるため、ベンダーへ置き換えの要否を確認す る • 現状ではベリサインが早くも他の規格の証明書でも2048bit化を推進を表明 IHSでサーバ証明書の置き換えが必要となった場合 – サーバーの暗号化・復号処理のためのCPU負荷が増大するため、検証 環境等で負荷を確認する – チューニング・パラメータを見直す 36 WAS V7 最新動向Workshop 証明書の置き換え要否については、各ベンダーによって対応が異なるため、確認 してください。 その結果、IHSでサーバ証明書の置き換えが必要となった場合、サーバのCPU負 荷が増大します。いくつかチューニング・パラメータを見直す必要があります。 36 05. システム設計 【参考】日本ベリサインの「暗号アルゴリズムにおける2010 年問題」対応ガイド 今年2010年末までに、鍵長2,048bit証明書対応の検証を推奨 – 2010年末で鍵長1,024bit証明書の新規発行が停止するため ハッシュ関数SHA-1の対応完了期日については、現時点では明言されていない – クライアント環境のSHA-256への対応状況が十分でないため 2011年以降は 現在利用している 1,024bit証明書の 更新の際に 2,048bitへの対応 が必要 37 WAS V7 最新動向Workshop 37 05. システム設計 【参考】SSL証明書の種類 SSL証明書には複数の種類が存在する 信頼性 高 EV-SSL証明書 企業認証SSL証明書 登記簿謄本、TDBやTSRの登録情報から 第三者認証局がその企業の実在性を認証 した上で発行される証明書 ドメイン認証SSL証明書 ドメイン名/IPアドレスの登録者等の情報が 参照できる「Whois」の情報を元に、サーバ の実在を証明した上で発行される証明書 独自の認証局で発行される証明書 OpenSSL等で認証局を独自に立てて、 その認証局で発行される証明書 ・次ページ ・取得までに時間はかかるが、厳格な認証 プロセスを通すので、信頼性は高い ・各認証局の独自の認証プロセスを持つ ・短期間かつ低コストで取得可能 ・第三者からの発行なので、最低限の 安全は確保できる ・2006年にドメイン認証でフィッシングサイトが 発見された ・第三者からの承認は不要 ・コストは発生しない ・外部公開サイトで使用する場合は信頼性が 皆無 低 38 WAS V7 最新動向Workshop 38 05. システム設計 【参考】EV SSL証明書とは 「Extended Validation SSL証明書」の略 CA/ブラウザフォーラムによって確立される検証プロセス に基づいて発行 組織の実在性だけでなく、その他に事業活動などの 実在性も審査対象となり、業界内の統一基準をクリア した企業だけが導入可能 IE7等のブラウザではアドレスバーが緑色に変化 →ネット・ユーザーからWebサイトの確かさが一目でわかる EV SSL証明書を導入するメリット フィッシング対策にかかわるサポートコストの削減 厳格な認証プロセスのもとに発行されるため、フィッシングを行う犯罪者がEV SSL証明書を取得 もしくは偽装することは困難 → フィッシング対策に関する企業側のサポートコストは、ほとんど必要ない コンバージョンレートの向上（情報入力の促進） ネットユーザーの約2割は、クレジットカードの情報をネットに流すことに不安があるという理由で、 インターネットで 物品・サービスを購入しない →EV SSL証明書はブラウザで導入が把握できるため，ネットユーザーは安心して取引できる 実際, 資料請求や物品購入までのコンバージョンレートが向上、ネット上の売り上げが向上したりする事例が 増加 39 WAS V7 最新動向Workshop 39 05. システム設計 【参考】SSLハンドシェイクの2048bit化で影響を受ける箇所 クライアントのブラウザ Ｗｅｂサーバー Client Hello Server Hello 以降の通信の元になる pre_master_secretを復号する 部分で負荷がかかる Server Certificate Server Hello Done Client Key Exchange ここから暗号化 Change cipher spec Finished Change cipher spec Finished Application Data exchange 40 WAS V7 最新動向Workshop 公開鍵の暗号化強度をあげた場合、SSLハンドシェイクでは、Client Key Exchangeの部分に負荷がかかります 40 05. システム設計 【参考】1024bitから2048bitに変更した際の負荷 検証マシン(IHS) HW: IntelliStation M Pro 621910J Pentium4 2.4GHz OS: Red Hat Enterprise Linux 4 update 6 負荷ツール: Apache JMeter 2.3.4 検証結果： ClientKeyExchangeを有するSSLハンドシェイクの場合 ClientKeyExchangeを有さないSSLハンドシェイクの場合 90 80 80 70 2048bit 1024bit （ C 60 P U 50 使 用 40 率 ） ） C P 50 U 使 40 用 率 30 30 20 20 10 10 0 0 0 500 （リクエスト数/分） 1000 約4倍の負荷 41 2048bit 1024bit 70 （ 60 1500 2000 0 5000 10000 15000 （リクエスト数/分） 負荷は大差なし 20000 25000 WAS V7 最新動向Workshop 上記はIHSV7での負荷テスト結果です。CPU使用率が約4倍になりました。 41 05. システム設計 【参考】2048bitの負荷の極小化のポイント(1/2) KeepAlive (デフォルト On) – 接続を使いまわすことができれば，余計なSSLハンドシェイクを行わずに済む KeepAliveTimeout (デフォルト15秒) – KeepAliveTimeoutで設定した期間中はスレッドが占有されてしまうので、1～2秒程度の短い値を設定 MaxKeepAliveRequests(デフォルト100) – 平均コンテンツ数程度が推奨 SSLV3Timeout (デフォルト120秒) – SSLセッションIDを有効にして，不要にClientKeyExchangeを有するSSLハンドシェイクを行わないよう にする – セキュリティー低下(なりすまし)につながる恐れもあるため，長時間の値は設定しない – 120秒を超える値を設定した場合，クライアントが使用するInternet Explorerのバージョンによっては， 120秒以内にブラウザがSSLセッションIDを破棄するため，SSLV3Timeoutで設定した値が有効になら ない場合がある GSK_V3_SIDCACHE_SIZE (OSの環境変数) – Windows系あるいはSSLCacheDisableを明示的に記述した場合、GSKitでSSLセッションIDをキャッ シュする – デフォルト512エントリーで，それを超えるリクエストがある場合，超えた分のSSLセッションIDはキャッ シュされないので、注意が必要 – １～4096まで設定可能なので、システムの同時接続数から設定値を見積もる 42 WAS V7 最新動向Workshop IHSのhttpd.confまたはOSの環境変数でポイントとなるパラメータをリストしました。 42 05. システム設計 【参考】2048bitの負荷の極小化のポイント(2/2) 分散環境の場合は以下も考慮する必要がある Affinity – SSLセッションIDはサーバー固有のものであるため，負荷分散装置により接続ごと に異なるサーバーに割り振られる場合，その都度新規のSSLハンドシェイクを実施し てしまうので、負荷が高まってしまう – Edge Components等でアフィニティーを設定できる場合はなるべく設定する ETag (デフォルトではiNodeを含む情報でキャッシュ判断) – デフォルトではサーバー依存のパラメータをEtagに含んでしまうため、別サーバーに 割り振られた場合に不要なキャッシュミスが生じてしまう – バージョン6以下のIEはキャッシュミス時にRSTパケットを返すため、後続のリクエス トは再度SSLハンドシェイクを行うことになる(IE7以上, Firefox, Google Chromeは 発生しない) 43 WAS V7 最新動向Workshop 分散環境の場合は、Affinity、ETagについても考慮してください。 43 05. システム設計 §2.3 SAMLサポート 44 WAS V7 最新動向Workshop 44 05. システム設計 SOA/クラウドを考慮したSSO/ID連携の課題 企業内・企業間のサービス連携やクラウドにおけるID連携の需要の高まり – セキュリティーの境界を越えた企業・組織とサービス連携をするケースが増加 • ドメイン間のWebシングル･サインオン（SSO) • サービス間のID連携 – SSOやID連携が、個々のサービスの技術に依存しない柔軟な実現性が必要 これらを実現する技術としてSAMLが注目される a.com b.com サービス間のID連携 Webシングルサインオン（SSO） c.com 45 WAS V7 最新動向Workshop SAMLは企業内・企業間のシングルサインオン・サービス間のID連携に使用するこ とができます。 SOA/クラウド環境でSSO/ID連携をする場合、即座に柔軟な対応が求められるた め、標準仕様であるSAMLが注目されています 45 05. システム設計 なぜSAMLが注目されるか？ SAMLとは･･･ID認証情報を伝播するためのXML仕様 9標準仕様のためベンダーや製品に依存しない 9ID認証情報だけでなく属性情報も伝播可能 9署名・暗号化によりトークンの妥当性・信頼性が確認可能 STS WS-Trustを使用してSAMLトークンの発行依頼、発行 トークンを発行するWebサービス Webサービス クライアント SAML 46 Security Token Service (STS) WAS V7 最新動向Workshop SAML（Security Assertion Markup Language）のメリットは以下になります ・Organization for the Advancement of Structured Information Standards（OASIS）によって標準化 ベンダーや製品への依存が解消される ・XMLベースのフレームワーク インターネット・アプリケーションに適用しやすい XMLパーサー、XML署名、XML暗号化技術が使用できる 拡張スキーマが使用できる ・ID認証情報、属性情報をSAMLアサーションという形式で表現 認証や認可に属性情報が伝播/使用できる ・SAMLトークンに署名鍵の添付が可能 トークン受信者は鍵の所有者を検証できる ・SAMLトークンに発行機関の署名が可能 トークン受信者はトークンの信頼性を検証できる トークン受信者はトークン発行者との信頼性に基づいて、認証情報/ 属性情報を使用できる 46 05. システム設計 V7.0.0.7 WAS 7 で出来ること（1/2） New Webサービスの認証情報伝播 – WS-SecurityのセキュリティトークンとしてSAMLが使用可能 Security Token Service (STS) ②トークン 発行依頼 SAML Webサービス クライアント (WAS) ①認証 ③トークン 発行 SAML ④SAMLトークン を添付してサ ービス要求 ドメインA ⑤トークン検証 Webサービス (WAS) ドメインB WAS V7 最新動向Workshop 47 SAMLと併せて登場する単語が、WS-TrustとSTSです。 WS-Trust（Web Services Trust Language） WS-Securityをベースとしたトークンの発行・使用するためのフレー ムワーク OASISによって定義された標準仕様 STS (Security Token Service) WS-Trustで定義されている、トークンを発行するWebサービス WS-Trust では、STS Web サービス・インターフェースを使用せず に、SOAP メッセージ・ヘッダーに直接セキュリティー・トークンを含 めることが可能 STSの機能を提供するIBM製品としてTFIMが提供されている 47 05. システム設計 【参考】Webサービスの標準化されたID情報伝播方法 WebサービスでID情報を伝播するために、WS-Securityのセキュリティ トークンのフォーマットが標準化 WS-Securityのセキュリティトークン – UserIDトークン – バイナリセキュリティ･トークン • X.509トークン • Kerberosサービス・チケット • SAML – WebSphereでは、IBM独自のセキュリティトークンであるLTPAトークンも、バ イナリセキュリティトークンとして使用可能 これらの標準的なフォーマットを用いない場合は、アプリケーション独自に 実装 48 WAS V7 最新動向Workshop WebサービスでID情報を伝播するためにはSAMLだけではなく様々なトークンを使 用することができます 48 05. システム設計 【参考】ID情報伝播方法の比較 実装方法 WS-Security Uname トークン 評価項目 実装可能なプロトコル、API WS-Security 開発容易性 前提知識 開発工数 バイナリ・セキュリティ・トークン X.509 LTPA トークン トークン パラメータの一部 として実装 Kerberos SAML サービス・チケッ トークン 制限なし WS-Security、セキュリティトークンの知識が必要 インフラの設定、テストの工数が必要 伝播可能項目ユーザID パスワード 属性項目 必要なコンポーネント （サーバ要件） ○ ○ ○ ○ ○ 必要なし 必要なし 必要なし ×：必要な場合はパラメータの一部として実装 N/A KDC アプリケーションサーバでは各仕様の準拠が必要 セキュリティトークンの 妥当性 ID+ XML パスワード検証 署名、暗号化 SOAPメッセージ の完全性・ 秘匿性 トランスポート のセキュリティ 標準化・拡張性 相互接続性 ○ 必要なし ○ STS セキュリティ を考慮した 設計が必要 アプリケーション 設計・開発・ テストが必要 自由に設定可能 実装方法に依存 秘密鍵 秘密鍵 XML トークンを個別にチケットを個別に 署名、暗号化 暗号化 暗号化 追加でXML署名 実装方法に依存 △ IBM製品のみ × 独自仕様 SSL ○ ○ 49 ○ ○ WAS V7 最新動向Workshop ID情報伝播方法を比較した表です。 49 05. システム設計 V7.0.0.7 WAS 7 で出来ること（2/2） New カスタムのWebシングル・サインオン – Webアプリケーションの認証済みトークンとしてSAMLが使用可能 – 開発が必要 – TFIM (Tivoli Federated Identity Manager)と併用するパターンが現実的 ①認証 SAML ②トークン 発行 ③SAMLトークン 添付し強制的にリ ダイレクト SAML Identity Provider ドメインA 開発した SAML TAI Web アプリケーション (WAS) ④コンテンツ表示 ドメインB 50 SAMLを使ったSSOの うち、 Brower/Bost/Pushモデ ルの例 フローを一部省略して いるため注意 WAS V7 最新動向Workshop WAS 7のSAMLサポートでWebのSSOをする場合、開発が必要となりますので、 TFIMの使用を検討頂く事が現実的です 50 05. システム設計 V7.0.0.7 【参考】WAS 7のSAMLサポート New WAS 7 Fix Pack7から以下をサポート（一部Fix Pack9からサポート） – Web Services Security: SAML Token Profile 1.1仕様のサポート • Web Services Security: SAML Token Profile 1.1仕様では、Web Services Security: SOAP Message Security 1.1仕様におけるSAML V1.1/V2.0アサーションを使用する 方法が定義 • ３つのサブジェクト確認方法 – “Bearer”、“Holder of Key” – “Sender Vouches”のみFP9でサポート – 外部セキュリティー･トークン･サービス（STS）との連携 • WS-Trust V1.2/V1.3プロトコルをサポート • STSを実現するソフトウェアとして、IBM製品ではTivoli Federated Identity Manager を提供 – SAML関連APIの提供 • SAMLアサーションの発行/使用を行うためのAPI（SAML Token Factory API） – SAMLトークンの自己発行が可能 • セキュリティー･トークン･サービスにアクセスするためのAPI（WS-Trust Client API） 51 WAS V7 最新動向Workshop WAS 7のSAMLサポートの詳細です 51 05. システム設計 【参考】ID伝播の概要図 DomainA Security Token Service (TFIM) Service Consumer (WAS) 統合アクセス 制御が可能 メッセージレベル のセキュリティ・ア クセス制御 DomainB Service Provider (WAS) Gateway (WDP/ WESBなど) Service Provider (WAS) DomainC Service Provider (WAS) User Registry 52 Service Provider (WAS) WAS V7 最新動向Workshop SAMLでWebサービスのID情報を伝播する場合、WASだけでなく、Webサービス のGatewayとなるWebSphere DataPowerやWebSphere ESBでもSAMLを処理 することも可能です 52 05. システム設計 【参考】シーケンス図 下図は、リクエストフローの例です。次ページ以降に、各リクエストのSOAPメッセージを示します。 53 WAS V7 最新動向Workshop 上記は、前頁での構成をした場合のリクエストフロー図です。 53 05. システム設計 【参考】1.1 トークンリクエストのSOAPメッセージ例 STS宛先（WSAddressing） <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"> <s:Security xmlns:s="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soapenv:mustUnderstand="1"> <u:Timestamp> <u:Created>2010-10-24T23:04:21.756Z</u:Created> </u:Timestamp> <s:UsernameToken u:Id="unt_20"> <s:Username>user01</s:Username> <s:Password Type=“http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile1.0#PasswordText">password01</s:Password> </s:UsernameToken> </s:Security> <wsa:To>https://fim:9443/TrustServerWST13/services/RequestSecurityToken</wsa:To> <wsa:MessageID>urn:uuid:8FC1B5B948CE9D89881287961462196</wsa:MessageID> <wsa:Action>http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action> トークンタイプ（SAMLV2） </soapenv:Header> の記述 <soapenv:Body> <wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"> <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType> <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType> <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</wst:KeyType> <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> トークンを使用してアクセス <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> するエンドポイント <wsa:Address>https://9.188.198.166:3099/WSSampleSei/EchoService12</wsa:Address> </wsa:EndpointReference> </wsp:AppliesTo> </wst:RequestSecurityToken> </soapenv:Body> </soapenv:Envelope> トークン発行要求 （WS-Trust） STSへのキータイプ（SAML Bearer:認証キーが添付され ない形式）の記述 54 STSへのトークン要求の記述 Issue/Validate/Renew/Cancelの 種別がある WAS V7 最新動向Workshop P.53のリクエストフロー図でのSOAPメッセージ例です。 54 05. システム設計 【参考】1.2 トークンを返すSOAPメッセージ例(1/2) <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsa="http://www.w3.org/2005/08/addressing"> <soapenv:Header> <wsa:Action soapenv:mustUnderstand="false">http://docs.oasis-open.org/ws-sx/wstrust/200512/RSTRC/IssueFinal</wsa:Action> <wsa:MessageID soapenv:mustUnderstand="false">urn:uuid:8FC1B5B948CE9D89881287961462196</wsa:MessageID> <wsa:RelatesTo soapenv:mustUnderstand="false">urn:uuid:8FC1B5B948CE9D89881287961462196</wsa:RelatesTo> <ns1:Security soapenv:mustUnderstand="false" xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd"> <ns2:Timestamp xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <ns2:Created>2010-10-24T23:06:54Z</ns2:Created> </ns2:Timestamp> </ns1:Security> トークンタイプ（SAMLV2） </soapenv:Header> の記述 <soapenv:Body> <wst:RequestSecurityTokenResponseCollection xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"> 応答トークンの情報 <wst:RequestSecurityTokenResponse wsu:Id="uuide07e96d2-012b-17b9-8553-b202718337de" （WS-Trust） xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile1.1#SAMLV2.0</wst:TokenType> <wsp:AppliesTo xmlns:wsa="http://www.w3.org/2005/08/addressing" トークンを使用してアクセス xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> するエンドポイント <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>https://9.188.198.166:3099/WSSampleSei/EchoService12</wsa:Address> </wsa:EndpointReference> </wsp:AppliesTo> <wst:Lifetime xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"> トークンの有効期限 <wsu:Created>2010-10-24T23:06:54Z</wsu:Created> <wsu:Expires>2010-10-29T03:06:54Z</wsu:Expires> </wst:Lifetime> STSからの応答 （WS-Addressing） 55 WAS V7 最新動向Workshop P.53のリクエストフロー図でのSOAPメッセージ例です。 55 05. システム設計 【参考】 1.2 トークンを返すSOAPメッセージ例(2/2) 応答トークン （WS-Trust） <wst:RequestedSecurityToken> <saml:Assertion ID="Assertion-uuide07e9730-012b-1def-aaee-b202718337de" IssueInstant="2010-1024T23:06:54Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> トークン発行者の記述 <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity">fim.makuhari.ibm.com</saml:Issuer> <saml:Subject> 認証の対象 <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid有効期限 format:emailAddress">user01</saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/> </saml:Subject> トークンを使用してアクセ <saml:Conditions NotBefore="2010-10-20T19:06:54Z" NotOnOrAfter="2010-10-29T03:06:54Z"> 条件 スするエンドポイント <saml:AudienceRestriction> <saml:Audience>https://9.188.198.166:3099/WSSampleSei/EchoService12</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2010-10-24T23:06:54Z"> 認証の状態 <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:Authn ContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </wst:RequestedSecurityToken> <wst:RequestedAttachedReference xmlns:wss="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuritysecext-1.0.xsd"> <wss:SecurityTokenReference wss11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profileトークンの参 1.1#SAMLV2.0" xmlns:wss="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 照先 xmlns:wss11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"> <wss:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:wss="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">Assertion-uuide07e9730-012b-1def-aaeeb202718337de</wss:KeyIdentifier> </wss:SecurityTokenReference> </wst:RequestedAttachedReference> </wst:RequestSecurityTokenResponse> </wst:RequestSecurityTokenResponseCollection> </soapenv:Body> </soapenv:Envelope> SAMLアサー ションによる 認証の証明 56 WAS V7 最新動向Workshop P.53のリクエストフロー図でのSOAPメッセージ例です。 56 05. システム設計 【参考】 1.3 サービスリクエストのSOAPメッセージ例 <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" セキュリティヘッダ soapenv:mustUnderstand="1"> （WS-Security） <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsu:Created>2010-10-24T23:04:18.704Z</wsu:Created> </wsu:Timestamp> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="Assertion-uuide07e9730-012b-1def-aaeeSAMLアサー b202718337de" IssueInstant="2010-10-24T23:06:54Z" Version="2.0"> ションによる トークン発行者の記述 <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid認証の証明 format:entity">fim.makuhari.ibm.com</saml:Issuer> <saml:Subject> 認証の対象 <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user01</saml:NameID> 有効期限 <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"></saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2010-10-20T19:06:54Z" NotOnOrAfter="2010-10-29T03:06:54Z"> トークンを使用してアクセ 条件 <saml:AudienceRestriction> スするエンドポイント <saml:Audience>https://9.188.198.166:3099/WSSampleSei/EchoService12</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2010-10-24T23:06:54Z"> 認証の状態 <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassR ef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </wsse:Security> <wsa:To>https://9.188.198.166:3099/WSSampleSei/EchoService12</wsa:To> エンドポイント宛先 <wsa:MessageID>urn:uuid:8FC1B5B948CE9D89881287961462109</wsa:MessageID> （WS-Addressing） <wsa:Action>echoOperation</wsa:Action> </soapenv:Header> <soapenv:Body> <ns2:echoStringInput xmlns:ns2="http://com/ibm/was/wssample/sei/echo/"> <echoInput>Message String</echoInput> </ns2:echoStringInput> </soapenv:Body> </soapenv:Envelope> 57 WAS V7 最新動向Workshop P.53のリクエストフロー図でのSOAPメッセージ例です。 57 05. システム設計 まとめ Q. 証明書の有効期限切れを発生させないためにはどうした らよいですか？ A. プロファイル作成時に有効期限を長く設定するのがお勧 めです。 プロファイル作成済みであれば、証明書置き換え、モニ ター機能有効化を実施してください。 Q. 2010年問題に対して、何をすればいいですか？ A. 各認証局ベンダーへ、証明書置き換えの必要性を確認し てください。 2048bitの証明書に置き換えると、CPU使用率が上がり ます。本番適用前のリソース状況確認とチューニングパラ メータ見直しを実施してください。 Q. SAMLサポートって何ができるんですか？ A. WebサービスでのID情報伝播、WebのSSOが可能です。 SAMLを使用したWebのSSOは開発が必要なため、要件 がある場合はTFIMとの連携も検討してください。 58 WAS V7 最新動向Workshop この章では、セキュリティの最新動向についてご紹介しました。 証明書有効期限切れのために注意すべき点、2010年問題のための要対応項目、 SAMLサポートでできることについてご紹介しました。 58 セッション番号. セッションタイトル §3. タイマー設計 59 WAS V7 最新動向Workshop 59 05. システム設計 タイマー設計のポイント タイマー種別の分類/定義 – クライアント非活動タイムアウト（セッションタイムアウト） • クライアントが指定時間以上操作をしない場合、タイムアウトとなる – 処理タイムアウト • リクエスト処理時間のタイムアウトで、クライアントがリクエストを送信し、 指定時間以上経過しても応答が返らない場合、タイムアウトとなる タイマー設計の一般的なポイント –クライアントからバックエンドへ向かって徐々に短く設定する –ユーザに表示されるタイムアウト画面とユーザの後続処理を確認する 処理タイムアウトでは以下の点も確認 –タイムアウトするタイミングと開放されるリソース –タイムアウト発生時に、その処理が中断/ロールバックされるか、処理が 継続されるか –タイムアウト発生時のエラーハンドリングと検知方法 60 WAS V7 最新動向Workshop 各コンポーネントのタイムアウト値を決める前に、タイマー設計の注意点を確認して ください。 60 05. システム設計 タイムアウトの設定箇所 処理タイマー（トランザクションタイマー） よく聞かれる 青字がパラメータ – ブラウザー – 負荷分散装置 • Edge – stickytimeout – 認証サーバ – アプリケーション・サーバ • プラグイン • WAS – ServerIOTimeout – トランザクション・タイマー » 合計存続時間タイムアウト » 最大トランザクション・タイムアウト » クライアント非活動タイムアウト – EJB関連タイマー » com.ibm.CORBA.requestTimeout – Webサービス関連タイマー » 要求タイムアウト（JAX-WSとJAX-RPCで設定箇所が異なるため注意が必要） – JDBC（DB2） • • • setQueryTimeout （メソッド） blockingReadConnectionTimeout （データソース拡張プロパティ） loginTimeout （データソース拡張プロパティ） – データベース・サーバ • DB2 – Workload ManagerのACTIVITYTOTALTIME（合計実行時間） 61 WAS V7 最新動向Workshop 各コンポーネントのタイムアウト値を抽出しました。 各環境やアプリケーションに応じて、必要なパラメータを抽出し、前頁で列挙した注 意点について確認してください。 トランザクションタイムアウトは、下記情報をご参照ください。 WebSphere Application Server V7.0によるWebシステム基盤設計ワークショップ 資料 トランザクション設計 http://public.dhe.ibm.com/software/dw/jp/websphere/was/was7_guide/WASV 70Design_03Transaction.pdf 特に、下記Technoteに記載されているとおり、トランザクション・タイムアウトが発生 してもすぐにユーザ処理 が停止しないケースがあるので注意が必要です。これは タイムアウトとユーザコードが異なるスレッドで処理されており、Javaの仕様ではス レッドが別のスレッドをキャンセ ルすることがサポートされていないためです。 JavaBean Can Not Call another Method after a Transaction Timeout Rollback http://www-01.ibm.com/support/docview.wss?uid=swg21271805 61 05. システム設計 タイムアウトの設定箇所 接続タイマー よく聞かれる 青字がパラメータ – アプリケーション・サーバ • • プラグイン：ConnectTimeout（Web サーバープラグインからWebコンテナへの接続） データソース：接続タイムアウト TCP/IP送受信タイマー – OS – Webサーバ • • IHS：Timeout WAS：HTTPトランスポートチェーン読み取り・書き込みタイムアウト その他のタイムアウト – IHS：KeepAliveTimeout • リクエスト処理時間には影響しない – WAS:接続プールのタイムアウト • データソース接続プール – 未使用タイムアウト – 経過タイムアウト • J2C接続プール – 未使用タイムアウト – 経過タイムアウト 62 WAS V7 最新動向Workshop 接続タイマー、TCP/IP送受信タイマーも処理タイムアウトに影響します。 その他、処理タイムアウトには影響しないタイムアウトもご紹介します。 62 05. システム設計 プラグインのServerIOTimeout 9 WAS 7 では、デフォルト値が60秒と短いため注意（WAS 6 では無制限） 9 IHS:WAS=1:N 構成の場合、クライアント側は ServerIOTimeout*N 秒 でタイムアウトする 9 WAS 7.0.0.3 以降で動作に変更点があるため注意（noteを参照） 9正の値、負の値の設定でサーバをダウンとみなすかどうかが異なる V7.0.0.3 Update DBサーバのテイクオーバ時に発生するタイムアウトの例 ④プラグインがWAS#1でタイムアウトし WAS#2にリクエストを転送する ③DBアク セスで Wait APサーバ#1 負荷分散 装置 ⑥プラグインがWAS#2で タイムアウト 正の値･･･サーバダウンと みなさない 負の値･･･サーバダウンと みなす 63 WAS#1 ①クライアント リクエストが 転送される IHS#2 WAS#2 APサーバ#2 サービス IP IHS#1 ②サービスIPが 無応答 ⑤DBアクセス でWait DB#1 NFS#1 DBサーバ#1 Take Over *DB *NFS *サービスIP DB#2 NFS#2 DBサーバ#2 WAS V7 最新動向Workshop WAS 7.0.0.3 以降では、SeverIOTimeoutに一部動作に変更点があるため注意してください。詳細 は、下記InfoCenterの英語版を参照してください plugin-cfg.xml ファイル http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.n d.doc/info/ae/ae/rwsv_plugincfg.html 【障害情報】POSTリクエストを再送させない設定時、プラグインがタイムアウト発生時にダウンと検知 しない問題の解決策 (WAS-09-006) http://www-06.ibm.com/jp/domino01/mkt/cnpages1.nsf/page/default-00083294 ○ServerIOTimeoutが正の値の場合 ServerIOTimeout経過後、該当サーバーをダウンと判断しません。 ○ServerIOTimeoutが0の場合 ServerIOTimeoutは無効です。 ServerIOTimeoutを明示的に設定していない場合、ServerIOTimeout=0を設定した場合と同等で す。 ○ServerIOTimeoutが負の値の場合 ServerIOTimeout経過後、該当サーバーをダウンと判断します。 プラグインは、そのほかにも重要なパラメータがあります。下記ガイドもあわせて確認してください。 Webサーバー・プラグインでのWAS障害検知方法と推奨設定について (WAS-07-037) http://www-06.ibm.com/jp/domino01/mkt/cnpages1.nsf/page/default-00099AB8 How do the properties ServerIOTimeout and PostBufferSize affect plug-in behavior? http://www-01.ibm.com/support/docview.wss?uid=swg21408884 Webserver Plugin configuration http://www-01.ibm.com/support/docview.wss?uid=swg21450051 63 05. システム設計 タイマー設計全体図（設計書の例） Client IHS (Plugin) DB JDBC 他 システム SQL タイマ ロック タイマ 30s 30s ハング スレッド 検知 40s プラグイン タイマ datasource 30s 認証 タイマ WAS Servlet 600s 600s * 2(nodes) Edge タイマ 認証 1800s 2000s 3600s クライアント タイマ Edge 接続 タイマ 64 他シス タイマ WAS V7 最新動向Workshop 設計書に、タイマー設計の章を追加して、タイマーの依存関係に問題ないかを確 認しましょう。 上記のような図を使用すると分かりやすいかもしれません。 WASでは、スレッドが指定した時間を超過してアクティブであった場合に、WASの SystemOut.logにその旨を出力させるという、スレッドハング検知機能が提供されて います。デフォルトで10分に設定されてるため、10分以上アクティブなスレッドが存 在している場合にログに出力されます。 しかしこの機能は、ログに出力されるだけであり、スレッドをキャンセルすることはで きません。従って、ログ監視を行い、想定以上に長時間処理されているスレッドの 数が多い場合はWASの再起動を行うなど、運用で対応をする必要があります。 スレッドハング検知の設定は下記情報を参照してください。 WAS V7.0 InfoCenter 「ハング検出ポリシーの構成」 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ib m.websphere.nd.multiplatform.doc/info/ae/ae/ttrb_confighangdet.html 64 セッション番号. セッションタイトル §4. MDBのリスナー機能 65 WAS V7 最新動向Workshop 65 05. システム設計 MDBのリスナー機能 MDBのリスナーとは 確認 9MDB（Message Driven Bean） Java EE標準のメッセージ駆動型処理を行うEJB ¾Web環境で非同期メカニズムを実現ために利用される ¾宛先にメッセージが到着した時にEJBコンテナによって呼び出される z他のEJBとは異なり、EJBクライアントから直接呼び出すことはできない ¾EJBコンテナが起動時に複数のMDBインスタンスを作成し、並行処理を実行 することが可能 9WASが提供するMDBのリスナー 宛先へのメッセージ到着をリッスンする機能が2種類提供されている ¾アクティベーション・スペック ¾リスナー・ポート メッセージ送信 （J2EE標準） （WAS独自機能） メッセージ到着 リスナー アプリケーション 宛先 66 WAS MDB MDB onMessage() WAS V7 最新動向Workshop WASが提供するMDBのリスナーは、標準のアクティベーション・スペックと、WAS 独自のリスナーポートがあります。 66 05. システム設計 リスナーの最新トピック Update リスナーポートの安定化 – WAS 7 リリース当初、リスナーポートは非推奨機能であったが、安定化機能へ変更された • • 非推奨機能･･･当該バージョンでサポートされるが将来削除予定の機能 安定化機能･･･次期バージョンでも削除や非推奨への変更予定のない機能 – ワークショップ資料（WASV7アナウンスメントWS、WASV7基盤設計WS）は修正済み – 2010/11現在、日本語版InfoCenterでは、依然、非推奨との記載があるため注意（note部 分参照） WAS 7 FixPack5での変更 – WMQCommonServicesスレッドプールが使用されない – リスナーポートのセッションプールモニタリング機能追加 – 2010/11現在、日本語版InfoCenterには記載がない部分があるため注意（note部分参照） リスナーポート関連のドキュメントは、英語版で最新情報を確認する必要がある リスナーポートとアクティベーションスペックは どちらを選択すればよいですか？ 67 WAS V7 最新動向Workshop リスナーポートは、WAS 7リリース当初、非推奨機能となっていましたが、安定化機能に変更となりま した。 2010/11現在、日本語版InfoCenterでは、依然、非推奨との記載があるため注意してください。 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.n d.doc/info/ae/ae/rmig_stabfeat.html 英語のみ、安定化機能としてリスナーポートの記載あり http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.n d.doc/info/ae/ae/rmig_depfeat.html 日本語のみ、非推奨機能としてリスナーポートの記載あり http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.n d.doc/info/ae/ae/cmb_aslp.html （英語）For WebSphere Application Server Version 7 and later, listener ports are stabilized. For more information, read the article on stabilized features. （日本語）WebSphere Application Server バージョン 7 以降では、リスナー・ポートは推奨 されていません。 したがって、リスナー・ポートを使用する WebSphere MQ メッセージ駆動 型 Bean のデプロイメント構成を、アクティベーション・スペックを使用する構成に移行する 準備を行う必要があります。 WASV7 FP5より、WMQCommonServicesスレッドプールが使用されない、（リスナーポートのセッ ションプールモニタリング機能追加）などの変更があった 2010/11現在、日本語版InfoCenterには記載がないため注意 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webs phere.nd.doc/info/ae/ae/tmb_adm14.html http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webs phere.nd.doc/info/ae/ae/tmb_adm14.html 67 05. システム設計 MDBでメッセージを受け取るための構成 接続の設定 リスナーの設定 WAS WebSphere MQ WMQ メッセージング・プロバイダ アプリケーションサーバ キュー接続 ファクトリー リスナー サービス アプリ キュー宛先 リスナー ポート(LP) MDB WMQ リソースアダプタ キュー宛先 アクティベーション スペック(AS) MDB サーバに搭載 された機能 SIBUS デフォルト メッセージング・プロバイダ SIB JMS リソースアダプタ キュー宛先 68 アクティベーション スペック(AS) 論理的な定義 MDB WAS V7 最新動向Workshop リスナーポートはアプリケーション・サーバの機能の一部として提供されるため、ア プリケーションの起動停止に依存せず、リスナーポートを制御することができます。 68 05. システム設計 アクティベーション・スペックとリスナー・ポート よく聞かれる アクティベーション･スペック リスナーポート 仕様 J2EE標準 JCA 1.5準拠（メッセージングに限らずEIS（DB、TPな ど）への共通の接続アーキテクチャを規定） WAS独自提供機能 JMS 1.1（ASF）準拠（JMSプロバイダーへの接続アーキ テクチャを規定） 設定 セル・ノード・クラスタ・サーバの範囲で設定可能 （アプリケーションサーバのリソースとしてJNDIネーム スペースに定義） 別途、キューのJNDI定義が必要 サーバに設定 （アプリケーションサーバのメッセージ･リスナー･サービス に定義） 別途、接続ファクトリとキューのJNDI定義が必要 起動／停止 MDBのランタイム（メッセージ・エンドポイント）に対し、 pause/resumeが可能（MDB/キューのクラスター有無 によって影響範囲が異なる） WAS起動時の初期状態（起動/停止）はアプリケーショ ンに対して設定 ListenerPortに対し、起動/停止が可能 WAS起動時の初期状態（起動/停止）をリスナーポートに 設定可能 並行稼動設定 ActivationSpecのMaxPoolDepth （MaximumServerSessions） ListenerPortの最大セッション数（セッションプールの最大 接続数） セレクター設定 アプリケーションでの設定だけでなく、WASの設定も可 能 アプリケーションで設定 ポイズンメッ セージ対応 バックアウトキューへの退避可能 エンドポイントの停止も可能 バックアウトキューへの退避可能 リスナーポートの停止も可能 コネクション･エ ラー対応 リソース･アダプターの設定で自動再接続可能 パージポリシー設定はなし リスナー・ポートの設定で自動再接続可能 障害検知時にプール内のコネクションを破棄するかどう かのパージポリシー設定が可能 順序保証 保証なし NON.ASFモードでサポート 69 WAS V7 最新動向Workshop アクティベーション・スペックとリスナー・ポートの比較表です。異なる点は、起動/停 止と順序保証です。 69 05. システム設計 起動/停止 重要 MDB処理の開始・一時停止・再開を制御したい要件がある場合 – リスナーポート･･･アプリケーションの起動状態に依存せず、起動・停止が可能 – アクティベーション・スペック･･・アプリケーション起動後に、起動･停止が可能 異なる点は、アプリケーションサーバ起動時にMDB処理を開始させたくない場合の対応 – リスナーポート･･･MDBアプリケーションを起動させたまま、リスナーポートを停止することが可能 – アクティベーション・スペック･･・サーバ起動時にMDBアプリケーションを停止しておく必要がある – ⇒アプリに複数MDBが存在する場合、MDBがオンラインアプリと同居している場合はリスナー・ポートが 有用 WMQ メッセージング・ プロバイダ アプリケーションサーバ リスナー サービス LP アプリ LP MDB MDB WMQ リソースアダプタ アプリ AS MDB AS MDB アプリ AS MDB アプリケーションサーバ起動時 リスナーポートは停止してお くことが可能 アクティベーション・スペック はアプリを停止しておく必要 がある アプリケーション起動後 個々のアクティベーション・ス ペック（メッセージング・エンド ポイント）の起動停止は可能 WAS V7 最新動向Workshop 70 MDBの処理停止、再開は、下記①～③のいずれかで可能です。どのケースでも、個々のMDBインスタンスの一時停止、再 開はできないためご注意ください。 ①MDBを含むエンタープライズアプリケーションの停止・起動 アプリケーションの自動開始の使用不可化 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/trun_a pp_targetmap.html ②アクティベーション・スペックを使用する場合はMDBのメッセージ・エンドポイントの一時停止・再開 アクティベーション・スペックはアプリケーション（MDB）に紐付く定義であるため、アプリケーションが起動してはじめて、ランタ イムのメッセージ・エンドポイントの起動・停止が可能となります。 そのため、アプリケーション・サーバ起動後に特定のメッセージ・エンドポイントのみを停止するためには、アプリケーション起 動後にメッセージ・エンドポイント停止の追加処理が必要となります。 メッセージ・エンドポイントによるメッセージの管理 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tdat_m sgendpoint.html また、アプリケーション・サーバとキューがクラスター構成になっているかどうかで、ひとつのエンドポイントを停止するしたとき の全てのエンドポイントに与える影響範囲が異なりますので、下記リンクをご参照ください。 メッセージ・エンドポイントによるメッセージの管理 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tdat_m sgendpoint.html ③リスナー・ポートの停止・起動 リスナー・ポートはアプリケーション・サーバに搭載された機能であるため、MDBを含むアプリケーションの稼動状況に依存せ ずに起動・停止が可能です。且つ、アプリケーション・サーバ起動時の初期状態を設定できるため、サーバ起動時でも特定 の業務のリスナー・ポートを停止しておくことができます。 リスナー・ポート設定 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/umb_p rolp.html 70 05. システム設計 【参照】並行稼動設定 MDBの並行稼動数に影響を与えるパラメータ 接続プールの最大接続数 セッションプールの最大接続数 ≧ 全LPのMDBインスタンス合計数･･･ リスナー・サービスの最大サイズ MDBインスタンス最 大数・・・LPの 最大セッション数 WAS WebSphere MQ Qmgr ≧ WMQ メッセージング・プロバイダ アプリケーションサーバ キュー接続 ファクトリー キュー宛先 リスナー サービス LP キュー宛先 LP WMQ リソースアダプタ キュー宛先 AS キュー宛先 AS 全ASのMDBインスタンス合計数･･･ リソース・アダプタの最大サイズ アプリ MDB MDB MDB MDB MDB MDB MDB MDB MDB MDB MDB MDB ≧ MDBインスタンス最大数・・・ ASの最大サーバーセッション数 71 WAS V7 最新動向Workshop MDBの並行稼動に影響を与えるパラメータです。 リスナーサービスのパラメータの考え方については、下記ガイドが参考になります。 How the maximum sessions property on the listener port affects WebSphere Application Server performance http://www.ibm.com/developerworks/websphere/library/techarticles/0602_kes avan/0602_kesavan.html また、スレッド数設定指針としては、下記ガイドをご参照ください。 Get the most out of high performance message-driven beans and WebSphere Application Server http://www.ibm.com/developerworks/websphere/library/techarticles/0508_par kinson/0508_parkinson.html 71 05. システム設計 【参照】ポイズンメッセージ対応 バックアウトを繰り返すメッセージ（ポイズン・メッセージ）の対応 – 指定回数のリトライ後、ポイズン・メッセージを退避させ、処理を停止したい場合 • WMQのバックアウト閾値＝WASのリトライ回数 とする（注意点はnote参照） – 指定回数のリトライ後、ポイズン・メッセージを退避させるが、他の処理は継続したい場合 • WMQのバックアウト閾値＜WASのリトライ回数 とする MQ側のキュー属性指定したバックアウト 回数分試行後、指定したキューへメッセー ジを退避 指定した回数まで試行後、LPが停止 （停止しない設定は不可） WAS WebSphere MQ Qmgr WMQ メッセージング・プロバイダ アプリケーションサーバ キュー接続 ファクトリー キュー宛先 リスナー サービス LP WMQ リソースアダプタ キュー宛先 AS アプリ MDB MDB MDB MDB MDB MDB 指定した回数まで試行後、ASが停止 （停止しない設定も可能） 72 WAS V7 最新動向Workshop サービス統合バス（SIBus）を使用した場合は、WASの管理コンソールから、ローカル宛先キューの 定義に最大デリバリー失敗数と例外宛先を指定可能ですが、 WebSphere MQプロバイダー経由 の接続の場合は、キューの実態はMQサーバにあるため、WebSphere MQ キューの定義として、 バックアウト閾値とバックアウト再キューイングのキュー名を指定します。 WebSphere MQ キューの バックアウト閾値を超えた場合、配信できないメッセージは WebSphere MQ によって、バックアウト再キューイング・キューに移動されます WMQのバックアウト閾値＞WASのリトライ回数の場合 エラーが発生し、WASのリトライ回数までリトライされた後、リスナー・ポートまたは メッセージ・エンドポイントが停止 キューのメッセージはバックアウト閾値まで達していないため、バックアップ・カウン トがアップするだけで、メッセージはキューに留まる WMQのバックアウト閾値＝WASのリトライ回数の場合 エラーが発生し、WMQのバックアウト閾値までリトライされた後、メッセージはバッ クアウト再キューイング・キューに移動される。 リスナー・ポートまたはメッセージ・エンドポイントが停止。 リスナーポートの場合は、WASのリトライ回数のカウントの仕組みがアクティベー ションスペックと異なり、WASのリトライ回数をWMQのバックアウト閾値より１小さく 設定する必要がある。（例：バックアウト閾値５、リトライ回数４でリスナーポートが停 止し、キューが再キューイング・キューに移動されます） WMQのバックアウト閾値＜WASのリトライ回数の場合 エラーが発生し、WMQのバックアウト閾値までリトライされた後、メッセージはバッ クアウト再キューイング・キューに移動される しかし、リスナー・ポートまたはメッセージ・エンドポイントは停止せず、次のメッセー ジが処理される 72 05. システム設計 【参照】コネクションエラー対応 接続先のキューマネージャー障害やN/W障害により接続エラーが発生した場合 – リスナーポートでもアクティベーションスペックでも自動的に再接続を実施 エラー検知後、コネクションのパージポリ シーを指定 自動的に再接続を実施 リトライ間隔・回数は指定可能 WAS WebSphere MQ Qmgr WMQ メッセージング・プロバイダ アプリケーションサーバ キュー接続 ファクトリー キュー宛先 リスナー サービス LP WMQ リソースアダプタ キュー宛先 73 AS アプリ MDB MDB MDB MDB MDB MDB WAS V7 最新動向Workshop 接続先のキューマネージャー障害やN/W障害により接続エラーが発生した場合は、 自動的に再接続を試みます 73 05. システム設計 まとめ Q.リスナーポートとアクティベーションスペックは どちらを選択すればよいですか？ A. 以下のケースはアクティベーション・スペックが適しています ・将来性・可搬性を考慮して標準に準拠したい場合 ・リスナーをセル・ノード・クラスターレベルで定義したい場合 ・セレクターを管理コンソールから定義したい場合 以下のケースはリスナー・ポートが適しています ・リスナーの起動停止を、MDB毎に細かく制御したい場合 ・順序制御したい場合 74 WAS V7 最新動向Workshop リスナーポートとアクティベーションスペックの選択は、標準に準拠、セル・クラス ター・ノードレベルでの定義、セレクターの管理コンソールからの指定の要件がある 場合は、アクティベーション・スペックが適しています リスナーポートの起動停止に詳細な制御が必要な場合、順序制御したい場合は、リ スナー・ポートが適しています 74