IPCOM

1. はじめに 2. 検証概要 2.1 システム構成 1 2 2 2.2 検証項目 4 2.3 検証実施詳細 4 3. パフォーマンス測定結果と考察 5 3.1 パフォーマンス測定 ( S2200: 一意性保証 セキュリティ機能 SSL アクセラレータ ) 5 3.2 パフォーマンス測定 ( S2200: サーバ負荷分散機能 ) 7 3.3 パフォーマンス測定 (Oracle Application Server 10g: 負荷分散機能 ) 9 3.4 SSLパフォーマンス測定 10 3.5 考察 11 4. スケーラビリティ検証結果と考察 13 4.1 基本パフォーマンス 13 4.2 WEB サーバのスケールアウト検証 14 4.3 考察 15 5. アベイラビリティ検証結果と考察 16 5.1 切替パフォーマンスと監視タイミング 16 5.2 擬似障害検証 ( S2200) 17 5.3 擬似障害検証 (Oracle Application Server 10g) 19 5.4 考察 21 6. その他 6.1 起動 停止時間 22 22 6.2 検証システム構築時間 22 6.3 他スイッチでの検証 22 7. まとめ 23

1. はじめに WEB コンピューティングの急速な普及により システムへのハイパフォーマンス ハイアベイラビリティの要求が増大しています また プラットフォームのオープン化に伴いシステムが複雑化したことにより ソフトウェアとハードウェア単一ではなく システムトータルでそれを実現することが求められています この要求に対し アプリケーションとビジネスの統合など すべてのニーズに対応するアプリケーション プラットフォーム スイートである Oracle Application Server 10g と システムとそれらをつなぐネットワークの接点となるシステムフロントに必要な機能を統合したネットワークサーバ との組み合わせにより 信頼の高い WEB システムを構築することが可能です 日本オラクル株式会社 (http://www.oracle.co.jp/) と富士通株式会社 (http:// jp.fujitsu.com) は Oracle Application Server 10g と での WEB フロント統合アライアンス を行いました 今回 本アライアンスのひとつとして WEB システムフロントに着目した両製品によるシステム検証を行いましたので ご報告いたします 本検証では Oracle Application Server 10g と を使った WEB システムを構築する場合に必要なシステム構成および各種設定を 実運用に近い構成で検証し 明確にしました 本検証での設定を利用することにより 短期間でかつ信頼性の高いシステム構築が可能になります 検証で用いた設定の詳細な内容については 日本オラクル- 富士通 WEB フロント統合アライアンステクニカルホワイトペーパー UNIX プラットホーム詳細編 を参照下さい はじめに 本文書の著作権は 日本オラクル株式会社および富士通株式会社に帰属します 日本オラクル株式会社および富士通株式会社の文書による許諾なしに 本文書の全部および一部を複製 販売 転用等することは禁じられています 本文書は 情報提供のみを目的としており 特定の製品の仕様を定義したり 特定の運用方法を推奨したりするものではなく 本文書および本文書に含まれる情報に基づく決定について 日本オラクル株式会社および富士通株式会社は いかなる責も負わないものとします 日本オラクル株式会社および富士通株式会社は 本文書に関し その内容の正確性 妥当性を含め いかなる保証も明示たると黙示たるとを問わず 一切いたしません 日本オラクル株式会社および富士通株式会社は 本文書に記載された製品の仕様ならびに動作を お客様への予告なく変更する場合があります UNIX は 米国およびその他の国におけるオープン グループの登録商標です Sun Sun Microsystems Sun ロゴ Solaris およびすべての Solaris に関連する商標及びロゴは 米国およびその他の国における米国 Sun Microsystems, Inc. の商標または登録商標であり 同社のライセンスを受けて使用しています ORACLE は ORACLE Corporation の登録商標もしくは商標です Windows は 米国 Microsoft Corporation の米国およびその他の国における登録商標です Java およびすべての Java 関連の商標およびロゴは 米国およびその他の国における米国 Sun Microsystems, Inc. の商標または登録商標です 本文書に記載されている会社名 製品名 名称等は すべて各社の商標または登録商標です 本資料に記載されているシステム名 製品名等には 必ずしも商標表示 ((R) (TM)) を付記していません 1

2. 検証概要 2. 1 システム構成 検証システムには 本検証では Oracle Application Server 10g と により Internet 接続システムでの WEB フロント部分のアベイラビリティを強化した構 成としました DMZ や Intranet を有した 3 階層 (WEB/AP/DB) モデルとし 実際の運用をイメー ジして DNS や 装置の異常検知のための運用監視システムを含んだ構成になっ ています 検証概要 サーバ WEB サーバハードウェア :PRIMEPOWER 250 2 台オペレーティングシステム :Solaris(TM) 9 OS 9/04 アプリケーションサーバ : Oracle Application Server 10g 伝送路二重化ソフト : PRIMECLUSTER GLS AP サーバハードウェア :PRIMEPOWER 250 2 台オペレーティングシステム :Solaris(TM) 9 OS 9/04 アプリケーションサーバ :Oracle Application Server 10g 伝送路二重化ソフト :PRIMECLUSTER GLS DB サーバハードウェア :PRIMEPOWER450 1 台オペレーティングシステム :Solaris(TM) 9 OS 9/04 データベース : Oracle Database 10g ネットワーク FW サーバ負荷分散 (SLB) SSL アクセラレータ装置ハードウェア : S2200 2 台 スイッチハードウェア :Catalyst2950 2 台 Catalyst2970 1 台 センタネットワークには 100Mbps を使用しています クライアント PC ハードウェア :FMV 4 台オペレーティングシステム : WindowsXP WEB 負荷ツール :MS Web Application Stress Tool( 以降 WAS) 運用監視システム 監視サーバハードウェア : PRIMERGY TX150S2 1 台オペレーティングシステム : Windows2003 SE 運用監視ソフト : Systemwalker Centric Manager V12 検証用帯域制御装置 帯域制御装置 ハードウェア : S1000 1 台 2

検証概要 図 2-1. 検証システム構成 本検証では WEB サーバには Oracle Application Server 10g の OHS (Oracle HTTP Serve:WEB サーバとして機能 ) AP サーバには Oracle Application Server 10g の OC4J(OracleAS Containers for J2EE:J2EE コンテナとして機能 ) DB サーバでは Oracle Database 10g が稼動しています PC に搭載された WEB ブラウザから WEB サーバに対して HTTP リクエストが送られると WEB サーバから AP サーバにリクエストが振り分けられ AP サーバで検証用アプリケーションが実行されます 検証用アプリケーションは DB サーバのデータを参照 更新した後 レスポンスを WEB サーバ経由でクライアントに返します 図 2-2. 検証アプリケーション構成概要 ( アプリケーション実行時のデータの流れ ) 3

2. 2 検証項目 パフォーマンス測定 Oracle Application Server 10g と S シリーズが持つ 基本パフォーマンス を示す (11 項目 ) 検証概要 スケーラビリティ検証 WEB サーバのスケールアウトなどの手順やサービス性を示す (3 項目 ) アベイラビリティ検証 故障時のサービス性や監視システムでの異常検知に関して示す (10 項目 ) 2. 3 検証実施詳細 検証期間 2005 年 6 月 6 日から 2005 年 6 月 17 日まで 検証場所 富士通株式会社プラットフォームソリューションセンター (http://jp.fujitsu. com/facilities/psc/) 東京都港区浜松町 2-4-1 世界貿易センタービル 4

3. パフォーマンス測定結果と考察 S2200 Oracle Application Server 10g の各機能のパフォーマンス測定を実施した結果を報告します [ パフォーマンス測定対象機能 ] S2200 と Oracle Application Server 10g 両方の機能を測定 - 負荷分散方式 - SSL アクセラレータ S2200 の機能を測定 - 一意性保証 ( セッション維持機能 ) Oracle Application Server 10g の Cookie を用いた一意性保証は DB 使用のため WEB サーバで常に使用とします - ファイアーウォール (FW) 機能 3.1 パフォーマンス測定 ( S2200: 一意性保証 ファイアーウォール機能 SSL アクセラレータ ) 1) 測定条件クライアント /WEB サーバ間の S2200 のサーバの一意性保証 ファイアーウォール機能 SSL アクセラレータについて パフォーマンスを測定しました パフォーマンス測定結果と考察 2) 測定方法 WEB 負荷ツール WAS を利用し クライアント PC4 台で仮想端末 (1 台あたり 80 端末 合計 320 端末 ) を起動して WEB サーバにアクセス コンテンツ (5Kbyte 20 の gif ファイルと 750byte 1 の html 一般的な WEB ページを想定 ) を連続ダウンロードし 単位時間に処理されたリクエスト数を 3 回測定 その平均値を比較しました 3) 結果 測定結果を以下に示します なお 2 つのサーバへの負荷分散が 49 から 51% で あり 均等に行われていることも確認しました 表 3-1. パフォーマンス測定 ( S2200 の一意性保証 FW 機能 SSL アクセラレータのパフォーマンス ) 註 ) ケース 4 以外は回線トラフィックがほぼ 100Mbps すなわち LAN の帯域使用率が 100% でボトルネックとなっており ケー ス 4 は SSL アクセラレータの処理遅延により LAN の帯域使用率は低くなるが PC の CPU の使用率が 100% でボトルネックとなっている このため ケース4は単純に比較できない 負荷分散率は 49%~ 51% の間でほぼ均等に分散されている サーバの CPU 負荷は 数 % 程度で問題にはならない FWのルールと Dos 攻撃防御機能のルール数はそれぞれ 38 と 27( 一般的なルール数 ) 5

図 3-1. パフォーマンス結果 パフォーマンス測定結果と考察 註 ) 一意性保証の有無による性能差は見られなかった これは 一意性保証が無い場合 ( ケース 1) は 毎回コネクション接続を行うため 4 台のクライアント PC でそれぞればらつきが大きくなったが 一意性保証が有る場合 ( ケース 2) は 最初の 1 回目でコネクション接続を行い その後同一のサーバに接続に行くためばらつきが小さくなっていたことにより 処理性能差が埋もれてしまったものと推測される ファイアーウォール機能の有無 ( ケース 3) による性能差も 1% 以下でほとんどないが 今回の評価環境では ネットワーク上には固定された評価データしか通信されていなかったためと推測される ファイアーウォールのアクセス制御ルールでも http https( 評価データ ) を最優先としていることも性能差を出さない要因と考えられる なお 実際の環境のように 様々なデータや DoS/DDoS 攻撃などが発生すると 処理性能は変わってくることが考えられるが データ通信に関してはアクセス制御ルールで主な通信のアクセス優先度を上位に設定することで 性能ダウンを軽減することができると思われる SSL アクセラレータは 使用しなかった場合に比べかなり性能が落ちるため SSL 暗号化処理にはかなり処理時間がかかることが推測できる しかし クライアントの CPU 負荷が 100% などクライアントでの処理性能がボトルネックになっているため クライアント数を増加させることでリクエスト数 / 単位時間も増加すると推測できる 6

3.2 パフォーマンス測定 ( S2200: サーバ負荷分散機能 ) 1) 測定条件クライアント /WEB サーバ間の S2200 のサーバ負荷分散機能 ラウンドロビン 最小コネクション数 ( 各サーバが処理しているコネクション数に基に処理 ) サーバ CPU 負荷 ( 各サーバの CPU 負荷率に基に処理 ) について パフォーマンスを測定しました 2) 測定方法 3.1 と同じく WEB 負荷ツール WAS を利用し クライアント PC4 台で仮想端末 (1 台あたり 80 端末 合計 320 端末 ) を起動して WEB サーバにアクセスし コンテンツ (5Kbyte 20 の gif ファイルと 750byte 1 の html 一般的な WEB ページを想定 ) を連続ダウンロードし 単位時間に処理されたリクエスト数を 3 回測定 その平均値を比較しました 3) 結果測定結果を以下に示します パフォーマンス測定結果と考察 表 3-2. パフォーマンス測定 ( S2200 のサーバ負荷分散機能のパフォーマンス ) 註 )LAN の帯域使用率は 3 ケースとも使用率が 100% サーバ PC ともに CPU 使用率が十分に少なくケースごとの大きな差 は見られなかった 7

パフォーマンス測定結果と考察 図 3-2. パフォーマンス測定結果 ( 負荷分散機能 ) 註 ) サーバ CPU 負荷と最小コネクション数の場合は 両者とも LAN の帯域使用率が 90 ~ 100% であるため サーバ CPU 負荷による負荷分散を使用する方が性能が良いと推測される ラウンドロビンの場合は LAN の帯域使用率がほぼ 100% でボトルネックになっているため 回線トラフィックの改善により 他の負荷分散方式よりも性能向上が見込める また 2 台の WEB サーバに対してクライアントの振分け率を見ると ラウンドロビンとサーバ CPU 負荷では 50% 均一で振分けており 最小コネクション数では 49%~ 51% と少し偏りが見られた 以上より 本測定条件のもとでの負荷分散方式の評価は ラウンドロビン サーバ CPU 負荷 最小コネクション数の順番で負荷分散の効率が良いと推測できる 8

3.3 パフォーマンス測定 (Oracle Application Server 10g: 負荷分散機能 ) 1) 測定条件 Oracle Application Server10g の WEB サーバである Oracle HTTP Server(OHS) が AP サーバにリクエストを割り振る負荷分散のアルゴリズムを変更して パフォー マンスを測定しました 2) 測定方法 WEB 負荷ツール WAS を利用してクライアント PC4 台で仮想端末 (1 台あたり 80 端末 合計 320 端末 ) を起動して WEB サーバにアクセスし HTTP セッショ ン オブジェクトにデータを保持するような WEB アプリケーションを実行して 単位時間に処理されたリクエスト数を 3 回測定し その平均値を比較しました 3) 結果 測定結果は次の通りです 表 3-3. パフォーマンス測定 (Oracle Application Server 10g の負荷分散機能 ) パフォーマンス測定結果と考察 註 ) どのケースにおいても LAN の帯域使用率 S2200 PC WEB サーバの CPU 使用率は十分に少なく AP サーバの CPU 使用率 (usr と sys の合計値 ) は継続的に 97% 以上と非常に高く AP サーバの CPU がボトルネックになっている ク スト 時間 図 3-3. パフォーマンス測定結果 註 ) 単位時間当たりのリクエスト処理数はほぼ等しく また上の表には記載されていないが TTLB( クライアントでリクエストを送信してから レスポンスが帰ってくるまでの所要時間 ) の平均値もケース 1 で 2.372 秒 ケース 2 で 2.346 秒とほぼ等しい このように差がないのはそれぞれ数万個以上のリクエストの統計を取ったため AP サーバへのリクエスサーバ振りがランダムの場合でも大数の法則に従って平均化されて ラウンドロビンとほとんど同じになったためであると思われる ただし TTLB の最大値がケース 1 では 113.00 秒であるのに対し ケース 2 では 125.46 秒と若干悪くなっている 9

3.4 SSL パフォーマンス測定 1) 測定条件 SSL アクセラレータを WEB サーバである Oracle HTTP Server(OHS) で行った場 合と S2200 で行った場合の パフォーマンスとシステムに与える負荷 を比較しました 2) 測定方法 3.1 と同じく WEB 負荷ツール WAS を利用し クライアント PC4 台で仮想 端末 (1 台あたり 80 端末 合計 320 端末 ) を起動して WEB サーバにアクセ ス コンテンツ (5Kbyte 20 の gif ファイルと 750byte 1 の html 一般的な WEB ページを想定 ) を連続ダウンロードし 単位時間に処理されたリクエスト数 を 3 回測定 その平均値を比較しました 3) 結果 表 3-4. パフォーマンス測定 (SSL アクセラータ ) 測定結果は次の通りです パフォーマンス測定結果と考察 註 ) どのケースにおいても LAN の帯域使用率は約 50% S2200 の CPU 使用率は約 50% で また AP サーバの CPU 使用率 (usr と sys の合計値 ) は数 % と低い ケース 1 では PC の CPU 使用率は十分低いが WEB サーバの CPU 使用率が継続的に 99% 以上であり ケース 2 では WEB サーバの CPU 使用率は最大で約 30% であるが PC の CPU 使用率が継続的にほぼ 100% となっている よってケース 1 では OHS の稼動している WEB サーバの CPU ケース 2 では WAS の稼動しているクライアント PC の CPU がボトルネックになっている ク スト 時間 12 p 図 3-4. パフォーマンス測定結果 註 ) ボトルネックがケース 1 では WEB サーバの CPU ケース 2 では PC の CPU と異なるため単純な比較はできないが ファイルのダウンロードがリクエストの大半を占めるような WEB サーバの負荷が高く AP サーバの負荷が低いケースでは S2200 の SSL アクセラレータ機能を使用することで 単位時間当たりのリクエスト処理数について少なくとも 3 倍弱程度の向上を見込むことができる 10

3.5 考察 1) 負荷分散方式と一意性保証サーバの負荷分散方式や一意性保証に関してはシステムやアプリケーション種別に依存します 一意性保証はシステム構成に左右されます ステートレスな WEB アプリケーションではセッション情報を保持するために 通常リクエストを送るクライアントと リクエストを処理する AP サーバが一対一対応の関係にある ( 一意性が保証される ) 必要があります 本構成の3 階層モデルにおいては DB のトランザクションを保証するために AP サーバとクライント間で一意性保証を行う必要がありますが WEB サーバの Oracle HTTP Server は AP サーバがクライアントに設定した Cookie の値を元に クライアントからのリクエストを AP サーバに一意性保って割り振ります そのためクライントのリクエストがどの WEB サーバに割り振られても問題がなく WEB サーバとクライアント間の S2200 では一意性保証を行う必要がありません 次に 負荷分散方式ですが WEB サーバとクライアント間は一意性保証を行うこともなく WEB サーバ構成が均一な検証構成においては S2200 の WEB サーバに対する負荷分散として 単純で高速なラウンドロビン方式がよいといえます Oracle Application Server 10g の WEB サーバである Oracle HTTP Server が AP サーバにリクエストを割り振る負荷分散の方式としても同様に 各 AP サーバのハードウェアや実行されるアプリケーションが均一で WEB クライアントからのリクエストが偏りなくコンスタントに発生するような条件であれば リクエストの処理時間のばらつきの少ないラウンドロビン方式がよいといえます サーバのパフォーマンス差やパケットの大きさ ばらつきにより 負荷分散の方式を選ぶ必要がありますが もし よい方法が導きだせない場合は まず ラウンドロビン方式で導入を行い 運用前の検証または運用中に監視を行いながら サーバ負荷や処理時間にばらつきが多いようなら 最小コネクション方式などの別の方式に変更したほうがよいといえるでしょう パフォーマンス測定結果と考察 負荷分散 ラウンン一意性保証 負荷分散 ラウン ン 一意性保証 Cooie 図 3-5. 負荷分散方式と一意性保証 11

2)SSL アクセラレータパフォーマンス測定を行ったところ ソフトウェアである Oracle HTTP Server(OHS) で SSL を処理した場合には単位時間に 310 のリクエストが処理されましたが ハードウェアである S2200 の SSL アクセラレータを使用した場合には単位時間に 875 のリクエストが処理されるという結果になりました OHS で SSL を処理した場合には WEB サーバの CPU がボトルネックになりましたが S2200 の SSL アクセラレータを使用した場合にはクライアント PC の CPU がボトルネックになりました PC の台数を追加したりすることで PC の CPU ボトルネックを解消できれば S2200 の SSL アクセラレータを使用した場合にはさらに単位時間当たりのリクエスト処理数は増加すると予想されます このことからファイルのダウンロードがリクエストの大半を占めるような WEB サーバの負荷が高く AP サーバの負荷が低いケースでは S2200 の SSL アクセラレータ機能を使用することで 単位時間当たりのリクエスト処理数について少なくとも 3 倍弱程度の向上を見込むことができます 次に価格的な観点からの比較ですが S2200 の SSL アクセラレータ搭載の有無での価格差は 800 千円 二重化する場合には 1,600 千円となります これに対し 例えば単位時間当たり約 900 リクエスト程度の処理を WEB サーバの増設で実現しようとすると 2 台で単位時間辺り 310 リクエストを処理していたことから計算上 WEB サーバを 4 台追加すれば単位時間当たり 930 リクエストを処理できることになります そのためにはハードウェア ( 本体 メモリ ) OS LAN 二重化ソフトなど約 14,000 千円が必要となり 価格面でも S2200 の SSL アクセラータを利用する方がコスト的に優れていることになります パフォーマンス測定結果と考察 表 3-5. ハードウェアを増設した場合の価格差 12

4. スケーラビリティ検証結果と考察 4.1 基本パフォーマンス サーバ全体の処理能力を向上させるために CPU の追加などによってサーバ単体を増強する手法をスケールアップというのに対し サーバを追加してサーバの台数を増やす手法をスケールアウトといいます スケーラビリティ検証では WEB サーバのスケールアウトについて そのサービス性と スケールアウト前後のパフォーマンス差に関して示します スケーラビリティ検証では WEB サーバを 1 台から 2 台へスケールアウトする場合に関して 検証を行います 以下に まず 1 台と 2 台の構成の基本パフォーマンスを以下に示します スケーラビリティ検証は クライアント ( 仮想端末 ) 数は 80 台で実施しています 今回の検証では WEB-AP 間は 1:1 に対応させた構成でテストしており 1つの WEB サーバへのリクエストは必ずそれに関連付けられた AP サーバに振り分けられるようになっています 表 4-1. スケールアウトの前後の基本パフォーマンス スケーラビリティ検証結果と考察 図 4-1. スケールアウト (1 台から 2 台 ) によるヒット数の変化 13

4.2 WEB サーバのスケールアウト検証 WEB サーバのスケールアウトする場合を想定し 以下のように 2 つの手段での手順とサービス性に関して検証します 方式 1 新規に WEB サーバを追加し S2200 の定義を変更し スケールアウトを実施する 方式 2 のシャットダウン制御機能を使い 前もってスケールアウトする WEB サーバを S2200 に定義し 追加するサーバを保守中にしておく サーバ負荷などにより スケールアウトが必要なった時点で サーバを保守中から運用中に変更する 1) 方式 1 手順 1 システムを構築 2 サービス開始 3 スケールアウトが必要になる 4 スケールアウト用サーバの構築 5 LAN にスケールアウト用サーバを接続 6 S2200 の定義変更 ( サービスが一時停止 ) サービス性 6の S2200 の定義変更時 サービスが約 4 秒程度停止します これは クライアントから WEB サーバへ 1 秒間隔で ping を発行することにより 確認しました WEB サーバの分散率 サーバ追加前後のサーバの分散率を以下に示しますが S2200 の定義変更直後から負荷分散の必要が 50% になり 2 つのサーバへの負荷分散が行われていることがわかります スケーラビリティ検証結果と考察 停止 定 サーバ WEB サーバ 1 WEB サーバ 2 図 4-2. 方式 1 での WEB サーバ増設時のサーバ分散率の推移 14

2) 方式 2 手順 1 システムを構築 ( スケールアウト用のサーバをあらかじめ定義し 保守中状態にしておく ) 2 サービス開始 3 スケールアウトが必要になる 4 スケールアウト用サーバの構築 5 LAN にスケールアウト用サーバを接続 6 S2200 の定義変更 ( サービス停止が発生せず 徐々にサーバ負荷が軽減 ) サービス性 6の S2200 の定義変更時にもサービスの停止 0 でした これは クライアントから WEB サーバへ 1 秒間隔で ping を発行することにより 確認をしました WEB サーバの分散率 サーバ追加前後のサーバの分散率を以下に示しますが 保守中から運用になる場合は徐々に負荷があがる様子が分かります スケーラビリティ検証結果と考察 定 サーバ WEB サーバ 1 WEB サーバ 2 図 4-3. 方式 2 での WEB サーバ増設時のサーバ分散率推移 4.3 考察 常時 ユーザからの要求を処理するシステムにおいて S2200 のシャットダウン制御機能を利用することで WEB サーバを安全に追加や削除することができます この機能を利用し 予めスケールアウトを考慮したシステム構築を行うことで スケールアウト時のサービス停止時間が発生しない運用が可能になります また 最近 サーバは定期的にセキュリィパッチの適用が必須となっており 適用時はサーバをシステムから切り離すことが必須です 一般的な負荷分散装置でもサーバの切り離しは可能ですが のシャットダウン制御機能を使い セキュリィパッチを適用するサーバを保守状態にすることで 新規の通信は他のサーバに振り分けられ 徐々に保守状態のサーバへの通信がなくなります 保守状態のサーバへの通信がなくなった時点で セキュリィパッチを適用することでサービス停止を0にできます 15

5. アベイラビリティ検証結果と考察 システムのフロント部分で二重化部分の単体切替パフォーマンスの測定し 各監視のタイミングなどを決めた上で システムの故障箇所を想定し それぞれの故障を擬似的に発生させ その時のサービス性および運用監視での検知について検証しました 5.1 切替パフォーマンスと監視タイミング 二重化した部分の単体の切替パフォーマンスに関して クライアント サーバ間 を 1 秒間隔で ping を発行させながら 強制切替コマンドなどで切り替えた時の ping コマンドの不通時間を測定しました 表 5-1. 単体切替パフォーマンス アベイラビリティ検証結果と考察 二重化した部分の監視方法は以下の示す通り 表 5-2. 監視 監視タイミングの考え方 S2200 からサーバの監視はサーバの NIC 切替が発生しても そのサーバが分散対象から除外されないように WEB サーバ PRIMECLUSTER GLS から の監視は S2200 の切替が発生しても NIC 切替が発生しないように 監視項目を設定する必要があり 以下の値にしました 図 5-1. 監視の考え方 16

表 5-3. 監視の値 5.2 擬似障害検証 ( S2200) 1) 測定条件 ケーブル切断やスイッチのポート無効化などで 擬似的に故障を発生させ サー ビスの停止時間と監視システムでの監視の可否を確認しました 監視システムは スイッチ から SNMPtrap を サーバの /var/adm/messages を確認する ように設定しています アベイラビリティ検証結果と考察 図 5-2. 擬似障害発生箇所 図 5-3. 監視システム 17

アベイラビリティ検証結果と考察 図 5-4. 監視画面 (Systemwalker) 2) 測定方法下記の表 5-4に提示した擬似障害を発生させ クライアントの PC から WEB 用の負荷分散アドレスに対して ping を送信し ping の停止時間 ( 再応答時間 ) を計測しました 18

表 5-4. 検証結果 3) 測定結果 アベイラビリティ検証結果と考察 5.3 擬似障害検証 (Oracle Application Server 10g) 1) 測定条件 Oracle Application Server 10g の AP サーバである OC4J(OracleAS Containers for J2EE) インスタンスがクラスタリングを組んでいる場合に 以下の 2 点についての影響を確認しました : AP サーバ層の追加および削除による既存サービスへの影響の有無 Oracle AS クラスタ ンバ 図 5-5. AP サーバの追加と削除 19

WEB サーバと AP サーバ間の回線をダウンさせ 短時間内に回線が復帰した際の自動復帰動作 図 5-6. 通信経路障害 2) 測定方法本検証では 影響度を知るために AP サーバ層への管理操作 (Oracle Application Server 10g の Application Server Control を利用 ) を行い 既存の OC4J インスタンスへの再起動要求やセッション情報の伝播がされることを確認しました また 回線ダウンについては WEB サーバと AP サーバ間に存在する SW( と AP サーバの間に配置 ) 部分の停止 (10 秒間 ) を行なうことで障害をシミュレートしました アベイラビリティ検証結果と考察 2) 結果 AP サーバ層のノード追加 / 削除における影響確認の結果は次の通りです 表 5-5. 検証結果 20

5.4 考察 AP サーバへの回線ダウンにおける影響確認の結果は次の通りです 回線ダウン後の最初の新規要求が届いたタイミングより TCP 接続異常の検出を開始します LAN アナライザでネットワーク監視をした結果 約 3.5 秒後 約 7 秒後 約 14 秒後の 3 回の異常検出動作が行なわれており 今回のケース (10 秒間の回線遮断 ) の場合には約 25 秒後に応答が WEB ブラウザに戻されました 検証システムの構成のように ネットワークや の二重化により ping ではエラーを検出する場合もあるものの TCP 層のリトライで回避できるため 利用者にはシステム停止がわからない範囲になることから 非常に高信頼なシステムであるといえます 特に 深夜でもサービスをし続ける必要のある WEB のショッピングサイトでは このような高信頼なシステムは必須となります 今回 センタのスイッチは L2 スイッチとし / サーバ間で監視を行いましたが より高パフォーマンスな L3 スイッチを使えば VLAN ごとに IP を設け スイッチ サーバ スイッチ間の監視を行うことにより監視箇所が局所化できるため よりよいシステムになるものと推測されます また Oracle Application Server 10g では 今回の検証の中で 既存クラスタメンバへの影響と回線ダウンの回復時の動作の 2 点に着目して動作確認を行いました 検証の結果 どちらの場合についてもユーザにエラーが戻ることなく処理が継続できることが確認できました Oracle Application Server 10g ではクラスタ追加の場合に 以下に示す動作も行なわれてはいますが 全てにおいてサービス停止を伴うオペレーションを実施する必要はありません アベイラビリティ検証結果と考察 既存クラスタで稼動中の OC4J インスタンスを新規 OracleAS へ反映する 既存クラスタで稼動中のアプリケーションを新規 OC4J へ自動デプロイする アプリケーション毎で保持するユーザセッションのステート情報を新規 OC4J へ反映する 新規 OC4J へのリクエスト振り分けを有効化する OC4J インスタンスへのリクエスト振り分けは Oracle HTTP Server(mod_oc4j) によって行なわれ このように新規 OC4J インスタンスが稼働状態になったことは下位の OPMN プロセス間通信によって伝播されます この伝播はイベント発行毎に即時適用されるために 新規 OC4J インスタンス追加からリクエストを振り分け可能になるまでの時間差はほとんどありません 図 5-7. Oracle Application Server 10g 通信処理 21

ただし mod_oc4j の振り分け設定については幾つか種類があるため Oracle Application Server 10g 利用者は配置を考える場合にその指定方法を考慮する必要があります 通常 Oracle HTTP Server から特定のクラスタリングされた OC4J インスタンスへリクエストを振るためには cluster:// <クラスタ名 >: < OC4J インスタンス名 > という指定するだけで比較的簡単にノード追加に対応できるので 推奨される設定と言えます また Oracle HTTP Server と OC4J 間のネットワーク障害については 現時点では TCP レベルでの障害検出に依存しています 今回の回線ダウン時の動作確認はその中でも最もシンプルなパターンで再現確認したものですが 想定通りに TCP レベルの probe packet が何度か再送され 回線が回復した時点でユーザへの応答も再開できることを見て取ることができました Oracle Application Server 10g の将来バージョンでは OC4J への AJP セッションの待ち時間に合わせたタイムアウトを指定できるようになるため 今回の TCP レベルの障害検出に依存することなく Application レイヤーのレベルで対応することができるようになると予想されます その他 6. その他 6.1 起動 停止時間 PON を行い サービスが動くまでの時間は 5 分で 特に PON の順番を気にする必要はありません ( ブラウザで WEB サーバが参照できるまでの時間を計測 ) POFF を行い 電源断までの時間は 2 分となりました 6.2 検証システム構築時間 6.3 他スイッチでの検証 本検証システムの構築 ( 設定から導入確認まで ) にかかった時間は約 10 時間でした これは 本検証を単機能装置 ( ルータ ファイアーウォール SSL アクセラレータ 負荷分散 ) を使った場合の約 1/6( 富士通概算 ) となります Catalyst2950 と Catalyst2970 に代わり Fujitsu SR-S224TC1 でも以下の検証を行い 問題ないことを確認しています 検証内容 相通確認クライアントからシステムが使えること アベイラビリティ試験の擬似故障試験切替などのアベイラビリティ機能の確認とサービス性 WEB サーバ PIMEPOWE20 Stealer S1000 B サーバ PIMEPOWE0 WSLB S2200 図 6-1. SR-S224TC1 スイッチ検証構成 AP サーバ PIMEPOWE20 22

7. まとめ 今回の検証では Oracle Application Server 10g と を使った WEB システ ムにおける パフォーマンス スケーラビリティ アベイラビリティ の 3 つの観点から 基礎特性や運用上の注意点などの評価を行ないました まとめ パフォーマンスでは Oracle Application Server のどちらも 負荷分散についていくつかのアルゴリズムが選択可能ですが 大きな性能差は見られませんでした 今回検証したようなクライアントからのリクエスト アプリケーションで実行される処理 サーバの性能のそれぞれが均質なケースであれば 最もベーシックなラウンドロビン方式で対応可能であるという結果となりました スケーラビリティとアベイラビリティについては システムを停止することなくサービスを継続したまま スケールアウトやサーバへのセキュリティパッチの適用が可能なことが確認されました 例えば サーバにおいて セキュリティパッチの適用が 4 回 / 年 故障が 1 回 / 年 において 定義変更が 1 回 / 年 故障が 1 回 / 年 発生するシステムを想定したとします この場合 の保守機能を使えば サーバのパッチ適用時や故障時にシステム停止が発生することはありません の故障の場合は 監視期間を含め約 30 秒の停止 設定変更の場合は約 8 秒間の停止が発生しますが 両者を合わせて年間約 5 分以内の停止であるため 稼働率 99.999% という高い信頼性を実現していると言えます 本検証システムは WEB システムのフロントで使用されるファイアーウォールや SSL アクセラレータ 負荷分散などの機器を で集約し シンプルな構成としました このため 設置面積やケーブル数 設定手順が削減され アベイラビリティ検証からも分かる通り 検証に必要な項目も少なくすることが可能となりました 本検証システムは一般的な WEB システムであるため 設定した内容をそのまま利用することができます を使用した本検証システムの設定を用いることにより 構築期間を単機能装置を組み合わせたシステムの場合の約 1/6 に短縮することが可能と考えられます 23

日本オラクル- 富士通 WEB フロント統合アライアンステクニカルホワイトペーパー UNIX プラットホーム概要編 日本オラクル株式会社富士通株式会社 2005 年 10 月第二版 OF05-10001 Copyright 2005 Oracle Corporation Japan, Fujitsu Ltd. All Rights Reserved.