technical white paper 日本オラクル－富士通 web …...technical white paper...

Technical White Paper

Copyright ©2005 Oracle Corporation Japan, Fujitsu Ltd. All Rights Reserved.

日本オラクル－富士通

WEB フロント統合アライアンス

テクニカルホワイトペーパー

【UNIX プラットホーム概要編】

ネットワークサーバアイピーコム

IPCOM



IPCOM

１．はじめに

２．検証概要

２．１システム構成

２．２検証項目

２．３検証実施詳細

３．パフォーマンス測定結果と考察

３．１パフォーマンス測定 (IPCOMS2200：一意性保証、セキュリティ機能、SSL アクセラレータ )

３．２パフォーマンス測定 (IPCOMS2200：サーバ負荷分散機能 )

３．３パフォーマンス測定 (OracleApplicationServer10g：負荷分散機能 )

３．４ＳＳＬパフォーマンス測定

３．５考察

４．スケーラビリティ検証結果と考察

４．１基本パフォーマンス

４．２ WEB サーバのスケールアウト検証

４．３考察

５．アベイラビリティ検証結果と考察

５．１切替パフォーマンスと監視タイミング

５．２擬似障害検証 (IPCOMS2200)

５．３擬似障害検証 (OracleApplicationServer10g)

５．４　考察

６．その他

６．１　起動・停止時間

６．２　検証システム構築時間

６．３　他スイッチでの検証

７．まとめ

1

2

2

4

4

5

5

7

9

10

11

13

13

14

15

16

16

17

19

21

22

22

22

22

23



IPCOM

１．はじめに

WEB コンピューティングの急速な普及により、システムへのハイパフォーマンス、ハイアベイラビリティの要求が増大しています。また、プラットフォームのオープン化に伴いシステムが複雑化したことにより、ソフトウェアとハードウェア単一ではなく、システムトータルでそれを実現することが求められています。　この要求に対し、アプリケーションとビジネスの統合など、すべてのニーズに対応するアプリケーション・プラットフォーム・スイートである、OracleApplicationServer10g と、システムとそれらをつなぐネットワークの接点となるシステムフロントに必要な機能を統合したネットワークサーバ IPCOMとの組み合わせにより、信頼の高い、WEBシステムを構築することが可能です。　日本オラクル株式会社 (http://www.oracle.co.jp/) と富士通株式会社 (http://jp.fujitsu.com) は、OracleApplicationServer10g と IPCOM での、「WEB フロント統合アライアンス」を行いました。今回、本アライアンスのひとつとして、WEBシステムフロントに着目した両製品によるシステム検証を行いましたので、ご報告いたします。　本検証では、OracleApplicationServer10g と IPCOMを使ったWEBシステムを構築する場合に必要なシステム構成および各種設定を、実運用に近い構成で検証し、明確にしました。本検証での設定を利用することにより、短期間でかつ信頼性の高いシステム構築が可能になります。検証で用いた設定の詳細な内容については、「日本オラクル－富士通WEB フロント統合アライアンステクニカルホワイトペーパー【UNIXプラットホーム詳細編】」を参照下さい。

はじめに

1

本文書の著作権は、日本オラクル株式会社および富士通株式会社に帰属します。日本オラクル株式会社

および富士通株式会社の文書による許諾なしに、本文書の全部および一部を複製、販売、転用等するこ

とは禁じられています。

　本文書は、情報提供のみを目的としており、特定の製品の仕様を定義したり、特定の運用方法を推奨

したりするものではなく、本文書および本文書に含まれる情報に基づく決定について、日本オラクル株

式会社および富士通株式会社は、いかなる責も負わないものとします。日本オラクル株式会社および富

士通株式会社は、本文書に関し、その内容の正確性、妥当性を含め、いかなる保証も明示たると黙示た

るとを問わず、一切いたしません。

　日本オラクル株式会社および富士通株式会社は、本文書に記載された製品の仕様ならびに動作を、お

客様への予告なく変更する場合があります。

　UNIX は、米国およびその他の国におけるオープン・グループの登録商標です。

　Sun、Sun Microsystems、Sun ロゴ、Solaris およびすべての Solaris に関連する商標及びロゴは、米国

およびその他の国における米国 Sun Microsystems, Inc. の商標または登録商標であり、同社のライセンス

を受けて使用しています。

　ORACLE は、ORACLE Corporation の登録商標もしくは商標です。

　Windows は、米国 Microsoft Corporation の米国およびその他の国における登録商標です。

　Java およびすべての Java 関連の商標およびロゴは、米国およびその他の国における米国 Sun

Microsystems, Inc. の商標または登録商標です。

　本文書に記載されている会社名、製品名、名称等は、すべて各社の商標または登録商標です。本資料

に記載されているシステム名、製品名等には、必ずしも商標表示 ((R)、(TM)) を付記していません。



IPCOM

２．検証概要2.　1　システム構成

検証概要検証システムには、本検証ではOracleApplicationServer10g と IPCOMにより、

Internet 接続システムでのWEB フロント部分のアベイラビリティを強化した構成としました。　DMZやIntranetを有した3階層(WEB/AP/DB)モデルとし、実際の運用をイメージして DNS や、装置の異常検知のための運用監視システムを含んだ構成になっています。

【サーバ】◆WEBサーバ　ハードウェア :PRIMEPOWER250 × 2台オペレーティングシステム :Solaris(TM)9OS9/04アプリケーションサーバ :　OracleApplicationServer10g伝送路二重化ソフト :　PRIMECLUSTERGLS◆ AP サーバ　ハードウェア :PRIMEPOWER250 × 2台オペレーティングシステム :Solaris(TM)9OS9/04　アプリケーションサーバ :OracleApplicationServer10g伝送路二重化ソフト :PRIMECLUSTERGLS◆ DB サーバ　ハードウェア :PRIMEPOWER450 × 1台オペレーティングシステム :Solaris(TM)9OS9/04データベース :OracleDatabase10g

【ネットワーク】◆ＦＷ・サーバ負荷分散 (SLB)・SSL アクセラレータ装置ハードウェア :IPCOMS2200 × 2台◆スイッチハードウェア :Catalyst2950 × 2台、Catalyst2970 × 1台※センタネットワークには 100Mbps を使用しています

【クライアント】◆ PCハードウェア :FMV× 4台オペレーティングシステム :WindowsXP　WEB 負荷ツール：MSWebApplicationStressTool( 以降WAS)

【運用監視システム】◆監視サーバハードウェア :PRIMERGYTX150S2 × 1台オペレーティングシステム :Windows2003SE　運用監視ソフト :SystemwalkerCentricManagerV12

【検証用帯域制御装置】◆帯域制御装置ハードウェア :IPCOMS1000 × 1台

2



IPCOM

本検証では、WEB サーバには、OracleApplicationServer10g の OHS(OracleHTTPServe：WEB サーバとして機能 )、APサーバにはOracleApplicationServer10g の OC4J(OracleASContainersforJ2EE：J2EE コンテナとして機能 )、DBサーバではOracleDatabase10g が稼動しています。PCに搭載されたWEB ブラウザからWEB サーバに対してHTTP リクエストが送られると、WEB サーバから APサーバにリクエストが振り分けられ、APサーバで検証用アプリケーションが実行されます。検証用アプリケーションは DBサーバのデータを参照、更新した後、レスポンスをWEB サーバ経由でクライアントに返します。

DMZ

Intranet

Internet

PC

FW/SLB IPCOM S2200帯域制御　IPCOM S1000

WEB サーバ　PRIMEPOWER250DB サーバ　PRIMEPOWER450

AP サーバ　PRIMEPOWER250

OracleApplicationServer 10g


Systemwalkerクライアント

センタ

PC

OracleApplicationServer: OC4J

OracleApplicationServer: OHS

HTTP/HTTPS

WEBブラウザ

WEBサーバ APサーバ

DBサーバ

AJPNet Services

図 2-1. 検証システム構成

図 2-2. 検証アプリケーション構成概要（アプリケーション実行時のデータの流れ）

検証概要

3



IPCOM

2.　2　検証項目

◆パフォーマンス測定OracleApplicationServer10g と IPCOMS シリーズが持つ、基本パフォーマンスを示す（11項目）

◆スケーラビリティ検証　WEBサーバのスケールアウトなどの手順やサービス性を示す（3項目）　

◆アベイラビリティ検証故障時のサービス性や監視システムでの異常検知に関して示す（10項目）

2.　3　検証実施詳細

【検証期間】2005 年 6月 6日から 2005 年 6月 17日まで

【検証場所】富士通株式会社　プラットフォームソリューションセンター　(http://jp.fujitsu.com/facilities/psc/)東京都港区浜松町２－４－１　世界貿易センタービル

検証概要

4



IPCOM

3．パフォーマンス測定結果と考察

パフォーマンス測定結果と考察

IPCOMS2200、OracleApplicationServer10gの各機能のパフォーマンス測定を実施した結果を報告します。

[ パフォーマンス測定対象機能 ]

・IPCOMS2200と OracleApplicationServer10g両方の機能を測定　- 負荷分散方式　-SSLアクセラレータ・IPCOMS2200の機能を測定　- 一意性保証 ( セッション維持機能 )　※ OracleApplicationServer10gの Cookie を用いた一意性保証は、DB使用のためWEBサーバで常に使用とします　- ファイアーウォール (FW) 機能

３．１　パフォーマンス測定 (IPCOM　S2200：一意性保証、、ファイアーウォール機能、SSL アクセラレータ )

１）測定条件クライアント/WEBサーバ間のIPCOMS2200のサーバの一意性保証、ファイアーウォール機能、SSL アクセラレータについて、パフォーマンスを測定しました。

２）測定方法WEB 負荷ツールWAS を利用し、クライアント PC4 台で仮想端末（1台あたり80端末、合計 320 端末）を起動してWEBサーバにアクセス、コンテンツ (5Kbyte× 20 の gif ファイルと 750byte × 1 の html。一般的なWEB ページを想定 ) を連続ダウンロードし、単位時間に処理されたリクエスト数を 3回測定、その平均値を比較しました。

３）結果測定結果を以下に示します。なお、2つのサーバへの負荷分散が４9から 51％であり、均等に行われていることも確認しました。

表 3-1. パフォーマンス測定 (IPCOM S2200 の一意性保証、FW 機能、SSL アクセラレータのパフォーマンス )

註）ケース 4 以外は回線トラフィックがほぼ 100Mbps、すなわち LAN の帯域使用率が 100％でボトルネックとなっており、ケース 4 は SSL アクセラレータの処理遅延により LAN の帯域使用率は低くなるが、PC の CPU の使用率が 100%でボトルネックとなっている。このため、ケース４は単純に比較できない。負荷分散率は、49%～ 51%の間でほぼ均等に分散されている。サーバのCPU 負荷は、数%程度で問題にはならない。ＦＷのルールと Dos 攻撃防御機能のルール数はそれぞれ、38 と 27( 一般的なルール数 ) 5

ケースクライアント数負荷分散方式

一意性保証ファイアーウォール機能

SSL アクセラレータリクエスト数(/ 単位　時間）

想定システムIPCOM Oracle IPCOM Oracle

製品紹介のような参照のみWEB サイト（Intranet に接続）グループウェアのような書き込み、参照を行うWEB サイト（Internet に接続）

グループウェアのような書き込み、参照を行うWEB サイト（Intranet に接続）

ショッピングサイトなど、セキュリティを強化した会員向けWEB サイト（Internet に接続）

1

2

3

4

↑ ↑ ↑

↑ ↑ ↑ ↑

↑ ↑ ↑ ↑ ↑

↑ ↑ ↑

↑ ↑

↑

あり

あり

あり

なしなしなしなしなしラウンドロビン

2219320

2225

2217

876



IPCOM

2500

2000

1500

1000

500

0ケース 1 ケース 2 ケース 3 ケース 4

単純比較できない

リクエスト数／単位時間

図 3-1. パフォーマンス結果

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


6



IPCOM

３．２パフォーマンス測定 (IPCOMS2200：サーバ負荷分散機能 )

１）測定条件

クライアント /WEB サーバ間の IPCOMS2200 のサーバ負荷分散機能、ラウンドロビン、最小コネクション数（各サーバが処理しているコネクション数に基に処理）、サーバ CPU負荷（各サーバの CPU負荷率に基に処理）について、パフォーマンスを測定しました。

２）測定方法

３．１と同じく、WEB 負荷ツールWAS を利用し、クライアント PC4 台で仮想端末（1台あたり 80端末、合計 320 端末）を起動してWEBサーバにアクセスし、コンテンツ (5Kbyte × 20 の gif ファイルと 750byte × 1 の html。一般的なWEBページを想定 ) を連続ダウンロードし、単位時間に処理されたリクエスト数を 3回測定、その平均値を比較しました。

３）結果測定結果を以下に示します。

表 3-2. パフォーマンス測定 (IPCOM S2200 のサーバ負荷分散機能のパフォーマンス )

註）LAN の帯域使用率は、3 ケースとも使用率が 100％。サーバ、PC ともに CPU 使用率が十分に少なくケースごとの大きな差は見られなかった。


7

ケースクライアント数負荷分散方式

一意性保証ファイアーウォール機能


想定システムIPCOM Oracle IPCOM Oracle

グループウェアのような書き込み、参照を行うWEB サイト（Intranet に接続）グループウェアのような書き込み、参照を行うWEB サイト（Intranet に接続）

グループウェアのような書き込み、参照を行うWEB サイト（Intranet に接続）

1

2

3

↑↑

↑ ↑ ↑

↑ ↑

↑

↑ ↑

↑ ↑

ありなしなしなしなしラウンドロビン

2219320

2028

2078

最小コネクション数

サーバCPU負荷



IPCOM

2500

2000

1500

1000

500

0ケース 1 ケース 2 ケース 3


約 6.4%Down約 8.6%Down

図 3-2. パフォーマンス測定結果 ( 負荷分散機能 )

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


8



IPCOM

３．３パフォーマンス測定 (OracleApplicationServer10g：負荷分散機能 )

１）測定条件

OracleApplicationServer10g のWEB サーバであるOracleHTTPServer(OHS) がAP サーバにリクエストを割り振る負荷分散のアルゴリズムを変更して、パフォーマンスを測定しました。

２）測定方法WEB 負荷ツールWAS を利用してクライアント PC4 台で仮想端末 (1 台あたり80端末、合計 320 端末 ) を起動してWEBサーバにアクセスし、HTTP セッション・オブジェクトにデータを保持するようなWEBアプリケーションを実行して、単位時間に処理されたリクエスト数を 3回測定し、その平均値を比較しました。

３）結果測定結果は次の通りです。

表 3-3. パフォーマンス測定 (Oracle Application Server 10g の負荷分散機能 )

註 ) どのケースにおいても LAN の帯域使用率、IPCOM S2200、PC、WEB サーバの CPU 使用率は十分に少なく、AP サーバのCPU 使用率 (usr と sys の合計値 ) は継続的に 97%以上と非常に高く、AP サーバの CPU がボトルネックになっている。

20406080100120140

0ケース 1 ケース 2


図 3-3. パフォーマンス測定結果

註 ) 単位時間当たりのリクエスト処理数はほぼ等しく、また上の表には記載されていないが TTLB( クライアントでリクエストを送信してから、レスポンスが帰ってくるまでの所要時間 ) の平均値もケース 1 で 2.372 秒、ケース 2 で 2.346 秒とほぼ等しい。このように差がないのはそれぞれ数万個以上のリクエストの統計を取ったため、AP サーバへのリクエスサーバ振りがランダムの場合でも大数の法則に従って平均化されて、ラウンドロビンとほとんど同じになったためであると思われる。ただし TTLB の最大値がケース 1 では 113.00 秒であるのに対し、ケース 2 では 125.46 秒と若干悪くなっている。


9

ケースクライアント数負荷分散方式一意性

保証ファイアーウォール機能


備考（想定モデル）IPCOM Oracle IPCOM Oracle

製品紹介のような参照のみWEB サイト（Internet に接続）

製品紹介のような参照のみWEB サイト（Internet に接続）

1

2 ↑↑ ↑ ↑ ↑ ↑

なしなしなしなしラウンドロビン

ラウンドロビン

ランダム

134.6320

134.9



IPCOM

３．４ SSL パフォーマンス測定

１）測定条件SSL アクセラレータをWEB サーバである OracleHTTPServer(OHS) で行った場合と、IPCOMS2200 で行った場合の、パフォーマンスとシステムに与える負荷を比較しました。

２）測定方法３．１と同じく、WEB 負荷ツールWAS を利用し、クライアント PC4 台で仮想端末（1台あたり 80 端末、合計 320 端末）を起動してWEB サーバにアクセス、コンテンツ (5Kbyte × 20 の gif ファイルと 750byte × 1 の html。一般的なWEBページを想定 ) を連続ダウンロードし、単位時間に処理されたリクエスト数を 3回測定、その平均値を比較しました。

３）結果測定結果は次の通りです。

表 3-4. パフォーマンス測定 (SSL アクセラータ )

註 ) どのケースにおいても LAN の帯域使用率は約 50%、IPCOM 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 がボトルネックになっている

1000800600

200400

0ケース 1 ケース 2

リクエスト数／単位時間約 182% up

図 3-4. パフォーマンス測定結果

註 ) ボトルネックがケース 1 では WEB サーバの CPU、ケース 2 では PC の CPU と異なるため単純な比較はできないが、ファイルのダウンロードがリクエストの大半を占めるような、WEB サーバの負荷が高く AP サーバの負荷が低いケースでは、IPCOM S2200 の SSL アクセラレータ機能を使用することで、単位時間当たりのリクエスト処理数について少なくとも 3 倍弱程度の向上を見込むことができる。


10

ケースクライアント数

負荷分散方式一意性保証

ファイアーウォール機能

SSL アクセラレータリクエスト数(/ 単位　時間）備考（想定モデル）

IPCOM Oracle IPCOM クライアントOracleショッピングサイトなどセキュリティを強化した会員向けWEBサイト（Internet に接続）

ショッピングサイトなどセキュリティを強化した会員向けWEBサイト（Internet に接続）

1

2 ↑↑ ↑↑ ↑

ありありなしなしあり

ありなし

ラウンドロビン

310 40 99

100 30

320

875

CPU 使用率WEBサーバ



IPCOM

３．５考察

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

DMZ

Intranet

Internet

PCFW/SLB IPCOM S2200

WEB サーバ　PRIMEPOWER250

DB サーバ　PRIMEPOWER450


負荷分散方式ラウンドロビン

一意性保証　なし

負荷分散方式ラウンドロビン

一意性保証　Cookie

図 3-5. 負荷分散方式と一意性保証


11



IPCOM

２）SSL アクセラレータ　　

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

表 3-5. ハードウェアを増設した場合の価格差


12

方式 WEB サーバCPU使用率

予想されるリクエスト数 /単位時間コスト［千円］

WEB サーバを4台追加（計 6台）

IPCOM SSLアクセラレータ

99%

30%

930（2 台→6台で310 の 300%）

875（検証結果）

WEB サーバを 4台増設するコスト：14000（3500×4）

IPCOM S2200 の SSL アクセラレータのコスト：1600（800×2）



IPCOM

４．スケーラビリティ検証結果と考察

サーバ全体の処理能力を向上させるために、CPUの追加などによってサーバ単体を増強する手法をスケールアップというのに対し、サーバを追加してサーバの台数を増やす手法をスケールアウトといいます。スケーラビリティ検証では、WEB サーバのスケールアウトについて、そのサービス性と、スケールアウト前後のパフォーマンス差に関して示します。

４．１基本パフォーマンス

スケーラビリティ検証では、WEB サーバを 1台から 2台へスケールアウトする場合に関して、検証を行います。以下に、まず 1台と 2台の構成の基本パフォーマンスを以下に示します。スケーラビリティ検証は、クライアント (仮想端末 )数は80台で実施しています。今回の検証では、WEB-AP間は 1：1に対応させた構成でテストしており、１つのWEB サーバへのリクエストは必ずそれに関連付けられた APサーバに振り分けられるようになっています。

表 4-1. スケールアウトの前後の基本パフォーマンス

1200001000008000060000

2000040000

01 台構成 2台構成

ヒット数

図 4-1. スケールアウト (1 台から 2 台 ) によるヒット数の変化

スケーラビリティ検証結果と考察

13

項項　　目 1台構成 2台構成

1 ヒット数 28055 111828

2 リクエスト数（/単位時間） 156 622

3 TTLB Avg 1308 283

4 WEB サーバの CPU負荷率 100% 85%



IPCOM

WEB サーバのスケールアウトする場合を想定し、以下のように 2つの手段での手順とサービス性に関して検証します。・　方式 1新規にWEB サーバを追加し、IPCOMS2200 の定義を変更し、スケールアウトを実施する。・　方式 2IPCOMのシャットダウン制御機能を使い、前もってスケールアウトするWEBサーバを IPCOMS2200 に定義し、追加するサーバを保守中にしておく。サーバ負荷などにより、スケールアウトが必要なった時点で、サーバを保守中から運用中に変更する。

１）方式 1【手順】①　システムを構築②　サービス開始③　スケールアウトが必要になる④　スケールアウト用サーバの構築⑤　LANにスケールアウト用サーバを接続⑥　IPCOMS2200 の定義変更（サービスが一時停止）【サービス性】⑥の IPCOMS2200 の定義変更時、サービスが約 4秒程度停止します。これは、クライアントからWEBサーバへ 1秒間隔で ping を発行することにより、確認しました。【WEBサーバの分散率】　サーバ追加前後のサーバの分散率を以下に示しますが、IPCOMS2200 の定義変更直後から負荷分散の必要が 50%になり、2つのサーバへの負荷分散が行われていることがわかります。

４．２ WEB サーバのスケールアウト検証

図 4-2. 方式 1 での WEB サーバ増設時のサーバ分散率の推移


14

100

80

60

40

20

0-10 0 10 20 30 40 50（秒）

（%）

WEB サーバ 1WEB サーバ 2

4 秒停止

定義変更サーバ追加



IPCOM

２）方式 2【手順】①　システムを構築（スケールアウト用のサーバをあらかじめ定義し、保守中状態にしておく）②　サービス開始③　スケールアウトが必要になる④　スケールアウト用サーバの構築⑤　LANにスケールアウト用サーバを接続⑥　IPCOMS2200 の定義変更（サービス停止が発生せず、徐々にサーバ負荷が軽減）【サービス性】⑥の IPCOMS2200 の定義変更時にもサービスの停止 0でした。これは、クライアントからWEBサーバへ 1秒間隔で ping を発行することにより、確認をしました。【WEBサーバの分散率】サーバ追加前後のサーバの分散率を以下に示しますが、保守中から運用になる場合は徐々に負荷があがる様子が分かります。

図 4-3. 方式 2 での WEB サーバ増設時のサーバ分散率推移

４．３　考察　常時、ユーザからの要求を処理するシステムにおいて、IPCOMS2200のシャットダウン制御機能を利用することでWEB サーバを安全に追加や削除することができます。この機能を利用し、予めスケールアウトを考慮したシステム構築を行うことで、スケールアウト時のサービス停止時間が発生しない運用が可能になります。　また、最近、サーバは定期的にセキュリィパッチの適用が必須となっており、適用時はサーバをシステムから切り離すことが必須です。一般的な負荷分散装置でもサーバの切り離しは可能ですが、IPCOMのシャットダウン制御機能を使い、セキュリィパッチを適用するサーバを保守状態にすることで、新規の通信は他のサーバに振り分けられ、徐々に保守状態のサーバへの通信がなくなります。保守状態のサーバへの通信がなくなった時点で、セキュリィパッチを適用することでサービス停止を０にできます。


15

100

80

60

40

20

0-10 0 10 20 30 40 50（秒）

（%）

WEB サーバ 1

WEB サーバ 2定義変更サーバ追加



IPCOM

５．アベイラビリティ検証結果と考察システムのフロント部分で二重化部分の単体切替パフォーマンスの測定し、各監視のタイミングなどを決めた上で、システムの故障箇所を想定し、それぞれの故障を擬似的に発生させ、その時のサービス性および運用監視での検知について検証しました。

５．１　切替パフォーマンスと監視タイミング

二重化した部分の単体の切替パフォーマンスに関して、クライアント・サーバ間を 1秒間隔で ping を発行させながら、強制切替コマンドなどで切り替えた時のping コマンドの不通時間を測定しました。

表 5-1. 単体切替パフォーマンス

表 5-2．監視

二重化した部分の監視方法は以下の示す通り。

【監視タイミングの考え方】　IPCOMS2200からサーバの監視はサーバのNIC切替が発生しても、そのサーバが分散対象から除外されないように、WEB サーバPRIMECLUSTERGLS からIPCOMの監視は IPCOMS2200 の切替が発生しても、NIC 切替が発生しないように、監視項目を設定する必要があり、以下の値にしました。

図 5-1. 監視の考え方

項項　　目

1

2

3

切替パフォーマンス

IPCOMの切替パフォーマンス 4秒

WEB サーバ　PRIMECLUSTER GLS NIC 切替 2秒

1秒LANの二重化（イーサチャネルまたはリングアグリケーション）の片寄せ時間

項項　　目

1

2

監視方式

IPCOM S2200 からサーバの監視 PING とポート監視

PING 監視WEB サーバ　PRIMECLUSTER GLS から IPCOMの監視

アベイラビリティ検証結果と考察

16

PCFW/SLB IPCOM S2200

帯域制御 IPCOM S1000

Systemwalker


APサーバ　PRIMEPOWER250

DBサーバ　PRIMEPOWER450

10 秒間隔で　ping を発行し、エラー検出後、２秒間隔で pingを発行し、連続８回のエラー検出でサーバの切り離し

2秒間隔で　ping を発行し、連続 5回のエラー検出でNICの切替

監視



IPCOM

表 5-3. 監視の値

５．２　擬似障害検証 (IPCOMS2200)

１）測定条件ケーブル切断やスイッチのポート無効化などで、擬似的に故障を発生させ、サービスの停止時間と監視システムでの監視の可否を確認しました。監視システムはスイッチ・IPCOMから SNMPtrap を、サーバの /var/adm/messages を確認するように設定しています。

図 5-2. 擬似障害発生箇所

図 5-3. 監視システム

項項　　目

1

2

監視方式

IPCOM S2200 からサーバの監視 10 秒間隔で PING を発行し、エラー検出後、2秒間隔でPING を発行し、連続 8回のエラー検出でサーバの切離し

2秒間隔で PING を発行し、連続 5回のエラー検出でNICの切替WEB サーバ　PRIMECLUSTER GLS から IPCOMの監視

DMZ

Intranet

Internet

PC

FW/SLB IPCOM S2200



Systemwalker

サーバは/var/adm/messagesを監視


スイッチ・IPCOMはSNMPtrap で監視


17

PC FW/SLB IPCOM S2200


Systemwalker



1

2

3 4 56 7

監視

DBサーバ　PRIMEPOWER450



IPCOM

図 5-4. 監視画面 (Systemwalker)

２）測定方法下記の表 5- ４に提示した擬似障害を発生させ、クライアントの PCからWEB 用の負荷分散アドレスに対して ping を送信し、pingの停止時間 ( 再応答時間 ) を計測しました。


18



IPCOM

３）測定結果

表 5-4．検証結果

５．３　擬似障害検証 (OracleApplicationServer10g)

１）測定条件OracleApplicationServer10g の AP サーバであるOC4J（OracleASContainersforJ2EE）インスタンスがクラスタリングを組んでいる場合に、以下の 2点についての影響を確認しました：・APサーバ層の追加および削除による既存サービスへの影響の有無

図 5-5. AP サーバの追加と削除

DMZ

Intranet

Internet

PC

FW/SLB IPCOM S2200




D A T A B A S E

Oracle ASクラスタメンバ追加D A T A B A S E


19

項故障想定箇所

1

2

3

4

5

6

7

高信頼機能サービス性監視発生方法

IPCOMのWAN

WEB サーバ側の二重化 LANの片系

WEB サーバ側の二重化 LANの両系

ケーブル抜き

ケーブル抜き

IPCOM切替

IPCOM切替

NIC 切替

IPCOM切替

スイッチの IPCOMと接続しているポートの無効化




ケーブル抜きとスイッチのWEBサーバと接続しているポートの無効化

イーサチャネルで二重化が片寄せされ一重

イーサチャネルで二重化が片寄せされ一重

IPCOMの負荷分散機能で分散対象外になる（約 20 秒後）

ping は 3秒停止するが、リトライにより利用者には影響なし

ping は 2秒停止するが、リトライにより利用者には影響なし

IPCOMからのSNMPtrap で検出

IPCOMとスイッチの SNMPtrap で検出




WEB サーバのMsg と、IPCOMとスイッチのSNMPtrap で検出

WEB サーバのMsg とスイッチのSNMPtrap で検出

停止なし

停止なし

停止なし

DMZの二重化 LANの片系

APサーバ ‒ IPCOM間の二重化 LANの片系

APサーバ ‒ IPCOM間の二重化 LANの両系

DMZの二重化 LANの両系

クライアントのWEB ブラウザ再読み込みで対応可能

クライアントのWEB ブラウザ再読み込みで対応可能



IPCOM

・WEBサーバと APサーバ間の回線をダウンさせ、短時間内に回線が復帰した際の自動復帰動作

図 5-6. 通信経路障害

DMZ

Intranet

Internet

PC

FW/SLB IPCOM S2200




通信経路の障害（WEB-AP 間）

２）測定方法本検証では、影響度を知るために APサーバ層への管理操作（OracleApplicationServer10g の ApplicationServerControl を利用）を行い、既存の OC4J インスタンスへの再起動要求やセッション情報の伝播がされることを確認しました。また、回線ダウンについては、WEBサーバと APサーバ間に存在する SW（IPCOMと APサーバの間に配置）部分の停止（10秒間）を行なうことで障害をシミュレートしました。

２）結果APサーバ層のノード追加／削除における影響確認の結果は次の通りです。

表 5-5. 　検証結果

ケース検証項目

1

2

3

結　　果内　　容

APサーバ構成変更



OC4J インスタンス追加

OC4J インスタンス削除

OC4J インスタンス追加後のリクエスト処理（セッション有）

既存 APサーバ（OC4J）は処理継続可能。追加完了後にはWEB からのリクエストの振り分けが可能になった。

APサーバが追加された際に、クラスタリング中の他のメンバーより、ステート情報の複製をコピーする。そのため、ユーザがセッション継続中の AP サーバが停止した場合には代理で処理を継続することが可能。

既存 APサーバ（OC4J）への処理を継続したまま、不要になった APサーバをクラスタリングから外すことが可能。


20



IPCOM

AP サーバへの回線ダウンにおける影響確認の結果は次の通りです。回線ダウン後の最初の新規要求が届いたタイミングより TCP 接続異常の検出を開始します。LAN アナライザでネットワーク監視をした結果、約 3.5 秒後、約7秒後、約 14秒後の 3回の異常検出動作が行なわれており、今回のケース（10秒間の回線遮断）の場合には約 25秒後に応答がWEBブラウザに戻されました。

５．４　考察

　検証システムの構成のように、ネットワークや IPCOMの二重化により、pingではエラーを検出する場合もあるものの、TCP 層のリトライで回避できるため、利用者にはシステム停止がわからない範囲になることから、非常に高信頼なシステムであるといえます。特に、深夜でもサービスをし続ける必要のあるWEB のショッピングサイトでは、このような高信頼なシステムは必須となります。　今回、センタのスイッチは L2 スイッチとし、IPCOM/ サーバ間で監視を行いましたが、より高パフォーマンスなL3スイッチを使えば、VLANごとに IPを設け、IPCOM・スイッチ、サーバ・スイッチ間の監視を行うことにより監視箇所が局所化できるため、よりよいシステムになるものと推測されます。また、OracleApplicationServer10g では、今回の検証の中で、既存クラスタメンバへの影響と回線ダウンの回復時の動作の 2点に着目して動作確認を行いました。検証の結果、どちらの場合についてもユーザにエラーが戻ることなく処理が継続できることが確認できました。OracleApplicationServer10gではクラスタ追加の場合に、以下に示す動作も行なわれてはいますが、全てにおいてサービス停止を伴うオペレーションを実施する必要はありません。

・　既存クラスタで稼動中のOC4J インスタンスを新規OracleAS へ反映する・　既存クラスタで稼動中のアプリケーションを新規OC4J へ自動デプロイする・　アプリケーション毎で保持するユーザセッションのステート情報を新規　　　　OC4J へ反映する・　新規OC4J へのリクエスト振り分けを有効化する

OC4J インスタンスへのリクエスト振り分けはOracleHTTPServer（mod_oc4j）によって行なわれ、このように新規OC4J インスタンスが稼働状態になったことは下位のOPMNプロセス間通信によって伝播されます。この伝播はイベント発行毎に即時適用されるために、新規OC4J インスタンス追加からリクエストを振り分け可能になるまでの時間差はほとんどありません。

図 5-7. Oracle Application Server 10g 通信処理

HTTP 通信

AJP 通信

AJP 通信

（処理要求　/応答）

（処理要求　/応答）（処理要求　/応答）

OC4JOHS

OC4J

mod oc4j

opmn

opmnopmn


21



IPCOM

ただし、mod_oc4j の振り分け設定については幾つか種類があるため、OracleApplicationServer10g利用者は配置を考える場合にその指定方法を考慮する必要があります。通常、OracleHTTPServer から特定のクラスタリングされたOC4J インスタンスへリクエストを振るためには「cluster:// ＜クラスタ名＞：＜OC4J インスタンス名＞」という指定するだけで比較的簡単にノード追加に対応できるので、推奨される設定と言えます。また、OracleHTTPServerとOC4J間のネットワーク障害については、現時点ではTCPレベルでの障害検出に依存しています。今回の回線ダウン時の動作確認はその中でも最もシンプルなパターンで再現確認したものですが、想定通りにTCPレベルのprobepacketが何度か再送され、回線が回復した時点でユーザへの応答も再開できることを見て取ることができました。OracleApplicationServer10g の将来バージョンでは、OC4J への AJP セッションの待ち時間に合わせたタイムアウトを指定できるようになるため、今回の TCP レベルの障害検出に依存することなくApplicationレイヤーのレベルで対応することができるようになると予想されます。

６．その他

６．１起動・停止時間PON を行い、サービスが動くまでの時間は 5分で、特に PON の順番を気にする必要はありません（ブラウザでWEB サーバが参照できるまでの時間を計測）。POFF を行い、電源断までの時間は 2分となりました。

６．３他スイッチでの検証Catalyst2950 と Catalyst2970 に代わり、Fujitsu　SR-S224TC1 でも以下の検証を行い、問題ないことを確認しています。【検証内容】◆相通確認　クライアントからシステムが使えること◆アベイラビリティ試験の擬似故障試験　切替などのアベイラビリティ機能の確認とサービス性

図 6-1.　SR-S224TC1 スイッチ検証構成

DMZ

Intranet

Internet

PC

FW/SLB IPCOM S2200







Systemwalker

SR-S224TC1

その他

22

６．２検証システム構築時間本検証システムの構築 ( 設定から導入確認まで ) にかかった時間は約 10 時間でした。これは、本検証を単機能装置 ( ルータ、ファイアーウォール、SSLアクセラレータ、負荷分散 ) を使った場合の約 1/6( 富士通概算 ) となります。



IPCOM

今回の検証では、OracleApplicationServer10g と IPCOMを使ったWEBシステムにおける、「パフォーマンス」「スケーラビリティ」「アベイラビリティ」の 3つの観点から、基礎特性や運用上の注意点などの評価を行ないました。

　パフォーマンスでは IPCOM、OracleApplicationServer のどちらも、負荷分散　についていくつかのアルゴリズムが選択可能ですが、大きな性能差は見られま　せんでした。今回検証したようなクライアントからのリクエスト、アプリケー　ションで実行される処理、サーバの性能のそれぞれが均質なケースであれば、　最もベーシックなラウンドロビン方式で対応可能であるという結果となりまし　た。

　スケーラビリティとアベイラビリティについては、システムを停止することな　くサービスを継続したまま、スケールアウトやサーバへのセキュリティパッチ　の適用が可能なことが確認されました。例えば、サーバにおいて、セキュリティ　パッチの適用が 4回 / 年、故障が 1回 / 年、IPCOMにおいて、定義変更　が　1回 /年、故障が 1回 /年、発生するシステムを想定したとします。この場合、　IPCOMの保守機能を使えば、サーバのパッチ適用時や故障時にシステム停止　が発生することはありません。IPCOMの故障の場合は、監視期間を含め約 30　秒の停止、設定変更の場合は約 8秒間の停止が発生しますが、両者を合わせて　年間約 5分以内の停止であるため、稼働率 99.999%という高い信頼性を実現　していると言えます。

本検証システムは、WEB システムのフロントで使用されるファイアーウォールや SSL アクセラレータ、負荷分散などの機器を IPCOMで集約し、シンプルな構成としました。このため、設置面積やケーブル数、設定手順が削減され、アベイラビリティ検証からも分かる通り、検証に必要な項目も少なくすることが可能となりました。本検証システムは一般的なWEB システムであるため、設定した内容をそのまま利用することができます。IPCOMを使用した本検証システムの設定を用いることにより、構築期間を単機能装置を組み合わせたシステムの場合の約 1/6に短縮することが可能と考えられます。

７．まとめ

まとめ

23

・

・

technical white paper 日本オラクル－富士通 web …...technical white paper...

Documents