目次 1. はじめに 検証概要 システム構成 ハードウェア ソフトウェア 検証項目 検証方法 検証実施詳細 サーバ負荷分散検証

Transcription

1 IPCOM

2 目次 1. はじめに 検証概要 システム構成 ハードウェア ソフトウェア 検証項目 検証方法 検証実施詳細 サーバ負荷分散検証 SSL アクセラレーター性能検証 保守性検証 サーバの追加 サーバ保守 セッションオーバー発生時の sorry メッセージ表示 まとめ...20

3 1. はじめに WEB コンピューティングの普及により 拡張性を見込んだ柔軟なシステムの構築が望まれ システムへのハイパフォーマンス ハイアベイラビリティの要求が増加しています また プラットフォームのオープン化に伴いシステムが複雑化したことにより ソフトウェアやハードウェアの製品個々の単独ではなく ソリューションシステムとしてシステムトータルで検証することが求められています この要求に対し アプリケーションとビジネスの統合といったニーズに対応するアプリケーション プラットフォームである BEA WebLogic Server 9.x とサーバシステムとネットワークの接点となるシステムフロントに必要な機能を統合したネットワークサーバ IPCOM との組み合わせにより 信頼性の高い WEB システムを構築することが可能です 日本 BEA システムズ株式会社 ( と富士通株式会社 ( は BEA WebLogic Server と IPCOM での アプリケーションサーバフロント統合アライアンス を実施します 今回 本アライアンスのひとつとして Windows システム上での WEB システムフロントに着目した両製品によるシステム検証を行いましたので ご報告いたします 本検証では BEA WebLogic Server と IPCOM を使った WEB システムを構築する場合に必要なシステム構成及び各種設定を 実運用に近い構成で検証し 明確にします 本文書の著作権は 日本 BEA システムズ株式会社および富士通株式会社に帰属します 日本 BEA システムズ株式会社および富士通株式会社の文書による許諾なしに 本文書の全部および一部を複製 販売 転用等することは禁じられています 本文書は 情報提供のみを目的としており 特定の製品の仕様を定義したり 特定の運用方法を推奨したりするものではなく 本文書および本文書に含まれる情報に基づく決定について 日本 BEA システムズ株式会社および富士通株式会社は いかなる責も負わないものとします 日本 BEA システムズ株式会社および富士通株式会社は 本文書に関し その内容の正確性 妥当性を含め いかなる保証も明示たると黙示たるとを問わず 一切いたしません 日本 BEA システムズ株式会社および富士通株式会社は 本文書に記載された製品の仕様ならびに動作を お客様への予告なく変更する場合があります Windows は 米国 Microsoft Corporation の米国およびその他の国における登録商標です BEA WebLogic Server WebLogic は BEA systems Inc. の登録商標もしくは商標です 本文書に記載されている会社名 製品名 名称等は すべて各社の商標または登録商標です 本資料に記載されているシステム名 製品名等には 必ずしも商標表示 ((R) (TM)) を付記していません はじめに

4 2. 検証概要 2. 1 システム構成 2. 2 ハードウェア 2. 3 ソフトウェア 以下に検証を行ったシステム構成を示します 検証システムには イントラネッ トに接続した WEB システム構成モデルとし 利用率が高い Windows 版の BEA WebLogic Server を採用し アプケーションサーバのスケラビリティを考慮し サーバのスケールアウトが容易なブレードサーバを使用します また アプリ ケーションサーバの負荷分散 SSL アクセラレーターおよびファイアーウォール としてネットワークサーバ IPCOM の最新機種である IPCOM S2400 を使用しま す 以下にシステム構成図を示します ネットワーク 図 2-1. 検証システム構成 サーバ負荷分散 (SLB) ファイアーウォール SSL アクセラレーター装置 FUJITSU IPCOM S 台 ( 二重化構成 ) セキュアスイッチ FUJITSU SR-S316C2 2 台 サーバ WEB サーバ / アプリケーションサーバ FUJITSU PRIMERGY BX600( サーバブレード 4 ) CPU:Intel Xeon CPU 3.06 GHz MEM:2.0GB オペレーティングシステム : Windows Server 2003 Standard Edition SP1 クライアント PC 4 セ アス ッ S S316 2 FUJITSU ESPRIMO K 台 CPU:Intel Celeron CPU2.66GHz MEM:1.0GB オペレーティングシステム : Windows XP Professional SP2 FUJITSU ESPRIMO K 台 CPU:Intel Celeron M processor 1.40GHz MEM:1.0GB オペレーティングシステム : Windows XP Professional SP2 WEB サーバおよびアプリケーションサーバ BEA WebLogic Server 9.1 検証用アプリケーション SL S24 セ アス ッ サーバ S S サーバ レード 4 Avitek Medical Records(WebLogic サンプルアプリケーション ) 検証概要

5 検証用アプリケーションの構成は以下のとおりです Windows Server 2003 Standard Edition BEA WebLogic Server MedrecEAR PhysianEAR StartBrowserEAR InitEAR 図 2-2. アプリケーション構成 アプリケーションの一連の動作は以下のとおりです (1)PC の WEB ブラウザから WEB サーバをアクセスします ホスト名 }:7001/index_ja.jsp DB (PointBase) JMS 以下の初期画面が表示されたら サンプルアプリケーション (Avitek Medical Records) をアクセスします ([MedRec の開始 ] をクリックします ) (2)WEB ブラウザに Avitek Medical Records のメニュー画面 ( 下左図 ) が表示 れます 医師を選択し ログインをクリックします 3 検証概要

6 (3)WEB ブラウザに認証画面 ( 上右図 ) が表示されます ユーザ名とパスワー ドを入力し [ ログイン ] をクリックします (4) 患者の検索画面 ( 下左図 ) が表示されます 姓 ( 例えば A) を入力し [ 検 索 ] をクリックします (5) 検索結果画面 ( 上右図 ) が表示されます (6) 検索した患者の姓をクリックし 患者情報 ( 下左図 ) を表示します (7) 患者情報の表示画面で [ プロファイル ] をクリックし プロファイル情報 ( 上 右図 ) を表示します (8) プロファイル表示画面で [ ログアウト ] をクリックします 検証で利用する (2)~(7) の各画面のデータサイズは以下のとおりです 画面名 画面サイズ ( バイト ) (2) メニュー画面 (3) 認証画面 (4) 検索画面 7679 (5) 検索結果画面 4513 (6) 患者情報画面 3518 (7) プロファイル画面 2996 合計 検証概要

7 2. 4 検証項目 サーバ負荷分散検証 IPCOM S2400 のサーバ負荷分散機能を使い BEA WebLogic Server システム の負荷分散を検証します 2. 5 検証方法 2. 6 検証実施詳細 SSL アクセラレーター性能検証 IPCOM S2400 の SSL アクセラレーターの性能を検証します 保守性検証 IPCOM S2400 の機能を利用したサーバシステムの保守性とサービス性を検証します 負荷ツール Microsoft Web Application Stress Tool( 以降 WAS) 検証手順 多数の仮想端末からサーバへのアクセスを発生させる検証では WAS の Script 機能を使用し あらかじめサンプルアプリケーションの一連の動作処理を登録しておき その Script を自動実行させます 自動実行では ウォーミングアップを 30 秒 測定時間を数分間として連続的に実行させます 測定回数は複数回数とします 登録する一連の動作処理は 以下のとおりです 1 メニュー画面を表示します 2 医師でログインします 3 患者の検索を実施します 4 検索結果の1 名を選択し 表示します 5 選択した患者のプロファイルを表示します 6 ログアウトします 上記の処理については 前述の 2.3 ソフトウェア を参照してください 検証期間 2006 年 7 月 13 日から 2006 年 7 月 20 日 検証場所 富士通株式会社社内 5 検証概要

8 サーバ負荷分散検証 アプリケーションとビジネスの統合といったニーズに対応するアプリケーショ ン プラットフォームを利用したシステムが普及しており IPCOM との整合 性の確認が求められています そこで IPCOM S2400 を使用して BEA WebLogic Server の WEB アプリケー ションシステムに対するサーバ負荷分散の検証を行い その結果を報告します 以下にサーバ負荷分散のシステム構成を示します 1) 検証条件 4 サーバ負荷分散 (SLB) 方式 以下の 2 通りの方式を評価します - ラウンドロビン方式 - 最小コネクション数 セッション維持 ( 一意性保証 ) 負荷分散の単位は コネクション単位で評価します セッションの維持は cookie オプションを利用する以下の 2 通りの方式 を評価します - クライアント ID 挿入方式 IPCOM 自身が cookie キー (FJNADDSPID=) にクライアント ID を 挿入する セ アス ッ S S セッション ID 参照方式 BEA WebLogic Server にて Java Servlet が Set-cookie で設定したキー (JSESSIONID=) のセッション ID を IPCOM が参照する ファイアーウォール アプリケーションサーバへ必要なアクセス (ARP http https) のみ許 可し それ以外は遮断します SSL アクセラレーター SL S24 図 3-1. サーバ負荷分散システム 本検証では SSL 通信は使用しません IPCOM の WEB アプリケーションの負荷分散機能では WEB アクセラ レーター機能を使用しない場合 TCP コネクション単位で振り分けを行 セ アス ッ サーバ S S サーバ レード 4 6

9 うので サーバの設定で KeepAlive 機能をオフにする必要があります 本評価では WEB アクセラレーター機能を使用しないため BEA WebLogic Server の KeepAlive 設定をオフにします 2) 検証方法 WEB サーバ / アプリケーションサーバとして BEA WebLogic Server 9.1 を 4 台のサーバブレードにインストールし サンプルアプリケーション (Avitek Medical Records) を検証用アプリケーションとして稼動させて利 用します クライアント ID 挿入方式によるセッション維持でのサーバ負荷分散の 検証は クライアント PC を 4 台同時に動作させ 1 台の PC で 40 仮想 端末の WAS を起動することで合計 160 の仮想端末を使用し WAS の script 機能による自動実行を行いました 測定時間は 3 分間で連続走行を 実行し 測定を 5 回繰り返します セッション ID 参照方式によるセッション維持の検証は 4 台のクライア ント PC のブラウザからサンプルアプリケーションをアクセスして実施し ます 3) 検証結果 ラウンドロビンおよびと最小コネクション数の 2 つの負荷分散方式によ るサーバ負荷分散機能で クライアントからのアクセスがほぼ均等に割 り振られ 各サーバの負荷がほぼ均一でした これは IPCOM の負荷分 散モニタ画面で目視し 確認しました 以下に 二通りの負荷分散方式 による IPCOM のコネクション数の負荷分散モニタ画面表示例を示しま す 図 ラウンドロビン方式 負荷分散方式 セッション維持方式クライアント ID 挿入セッション ID 参照 ラウンドロビン 問題なし 問題なし 最小コネクション数 問題なし 問題なし 図 最小コネクション方式 7

10 4) 考察 5) 参考 IPCOM S2400 のサーバ負荷分散機能を使用し BEA WebLogic Server で 稼動するサンプルアプリケーションへのクライアントからのアクセスが 分散されることを検証しています セッション維持では クライアント ID 挿入方式およびセッション ID 参 照方式の両方でセッションが維持された状態で サーバ負荷分散が行わ れることを検証しています サーバ負荷分散では 負荷分散方式による性能差はないと考えられます なお 今回の検証結果では BEA WebLogic Server は サーバの CPU 負 荷率がほぼ 100% で動作しているため 負荷計測エージェントを使用した CPU 負荷率でのサーバ負荷分散方式は 利用しても効果が少ないと考え られます サーバ負荷分散方式による性能差の検証は BEA WebLogic Server の自 動チューニング機能により 測定を繰り返すごとに単位時間当たりの処 理件数が増加するため 性能値の確定ができませんでした 以下に例として 負荷分散をラウンドロビン方式でセッション維持をク ライアント ID 挿入方式で行う条件にて測定した単位時間当たりのリクエ スト数の推移を示します BEA WebLogic Server の自動チューニング機能とは アクセス数に したがってスレッドを増減させる機能のことです 計測回数 リクエスト数 / 単位時間 図 3-3. 単位時間当たりのリクエスト数の推移 なお 今回の検証結果では BEA WebLogic Server は サーバ CPU 負荷 率 ( タスクマネージャで目視計測 ) がほぼ 100% で動作しています しか しながら クライアント PC の CPU 負荷率 ( タスクマネージャで目視計 測 ) は 4 ~ 50% のばらつきはありますが 平均で 10% 前後であるため また ネットワークのトラッフィク (IPCOM の QoS モニタでの目視計測 ) も約 22Mbps であるため クライアント PC の処理性能やネットワーク トラフィックによる阻害はないと考えられます

11 3. 2 SSL アクセラレーター性能検証 データの盗聴や改ざん 成りすましを防止するため SSL による暗号化通信の 利用が増加しており イントラネット内のシステムにおいても高度のセキュリ ティが求められています しかし SSL による暗号化通信を利用する場合 暗 号化 / 復号化の処理を行う必要があり この処理を WEB サーバで行うとサー バのパフォーマンスが低下します そこで IPCOM の SSL アクセラレーター機能を利用することにより 暗号化 / 復号化処理を WEB サーバから IPCOM へオフロードすることにより WEB サーバのパフォーマンスを向上させることができます SSL 通信を行うにあたり IPCOM S2400 の SSL アクセラレーター機能を利用 する場合と BEA WebLogic Server の SSL 機能 ( サーバで実行 ) を利用する場 合との性能を検証し その結果を報告します なお IPCOM S2400 の SSL アクセラレーター機能と BEA WebLogic Server で の SSL 機能の条件を一致させるため アプリケーションサーバは 1 台で検証を 行います 以下に IPCOM の SSL アクセラレーター機能を使用した通信と BEA WebLogic Server の SSL 機能を使用した通信の例を示します 4 s セ アス ッ S S316 2 SSL アクセラレーター SL S24 セ アス ッ サーバ S S サーバ レード 4 図 IPCOM S2400 の SSL アクセラレーター機能使用例 4 セ アス ッ S S316 2 s SL S24 セ アス ッ サーバ S S サーバ レード 4 図 BEA WebLogic Server の SSL 機能使用例 SSL 能 9

12 1) 検証条件 サーバ負荷分散(SLB) 方式ラウンドロビン方式 セッション維持( 一意性保証 ) 分散の単位は ノード単位で評価します ファイアーウォールアプリケーションサーバへ必要なアクセス (ARP http https) のみ許可し それ以外は遮断します SSL アクセラレーター以下の 2 通りの方式を評価します - IPCOM の SSL アクセラレーター機能使用時 - BEA WebLogic Server の SSL 機能使用時 2) 検証方法 WEB サーバ / アプリケーションサーバとして BEA WebLogic Server 9.1 を 1 台のサーバブレードにインストールし サンプルアプリケーション (Avitek Medical Records) を検証用アプリケーションとして稼動させて利用します このとき 他の 3 台のサーバブレードは IPCOM のシャットダウン制御機能を利用して停止状態にします クライアント PC を 4 台同時に動作させ 1 台の PC で 10 仮想端末の WAS を起動することで合計 40 の仮想端末を使用し WAS の script 機能による自動実行を行います 測定時間は 3 分間で連続走行を実行し 測定を 5 回繰り返します 3) 検証結果 IPCOM の SSL アクセレータ機能を使用する場合は BEA WebLogic Server の SSL 機能を使用する場合に比べ 約 1.7 倍高速でした 以下に SSL 機能処理装置ごとの単位時間当たりのリクエスト数 ( 測定 4 回の平均値 ) を示します SSL 機能処理装置 IPCOM WebLogic Server 性能比率 リクエスト数 / 単位時間 図 3-5. SSL 機能の性能 10

13 4) 考察 IPCOM の SSL アクセラレーター機能を使用する場合 BEA WebLogic Server の SSL 機能を使用するよりも 専用ハードウェアであるため処理が高速であることは当然です しかし 今回の検証結果では 利用したサンプルアプリケーションの一連の処理で使用するコンテンツのサイズが合計で約 70 キロバイトしかなく 暗号化 / 複合化処理以外の DB 処理などのアプリケーションの動作処理に時間が多くとられ 暗号化 / 復号化処理にはあまり時間が取られていないと考えられます このため 両者の性能差が小さかったと推測します 大容量のコンテンツが多い WEB サイトでは 暗号化 / 複合化処理に多くの時間がとられるために IPCOM の SSL アクセラレーター機能による暗号化 / 複合化処理のオフロードの効果は大きいと考えられます 11

14 3. 3 保守性検証 IPCOM が提供する以下の機能についてサーバシステムの保守性とサービス性の検証を行い 結果を報告します サーバの追加 サーバ保守 セッションオーバー発生時の Sorry メッセージ表示 サーバの追加システムの初期投資を最小限におさえ ビジネスの拡大にあわせシステムを増強することが望まれていますが システムの増強にはサービス停止が必要です しかし IPCOM を導入することで サービス無停止でシステムの増強が可能です システムの利用者増加などにより システムの負荷が増加しサーバのスケールアウトが必要になった時の手順とサービス性に関して検証を行い 結果を報告します 以下にサーバ追加の概念図を示します 4 セ アス ッ S S316 2 SL S24 セ アス ッ サーバ S S サーバ レード 4 クライアントの増加に伴い サーバブレードを 1 台追加 セ アス ッ S S316 2 SL S24 セ アス ッ サーバ S S サーバ レード 4 サーバ レード 図 3-6. サーバのスケールアウト サーバ レード o 1) 検証条件 サーバ負荷分散(SLB) 方式ラウンドロビン方式 セッション維持( 一意性保証 ) コネクション単位の分散によるクライアント ID 挿入方式 12

15 ファイアーウォールアプリケーションサーバへ必要なアクセス (ARP http https) のみ許可し それ以外は遮断します SSL アクセラレーター本検証では SSL 通信は使用しません 2) 検証方法 WEB サーバ / アプリケーションサーバとして BEA WebLogic Server 9.1 をサーバブレードにインストールし サンプルアプリケーション (Avitek Medical Records) を検証用アプリケーションとして稼動させて利用します 最初は 2 台のサーバブレードを稼動し その後 1 台のサーバブレードのスケールアウトを実施し 稼動させます スケールアウト前は クライアント PC を 2 台同時に動作させ 1 台の PC で 20 仮想端末の WAS を起動することで合計 40 の仮想端末を使用し WAS の Script 機能による自動実行で連続走行を行います さらに スケールアウト後 PC を 2 台追加し 4 台のクライアント PC を同時に動作させ 合計 80 の仮想端末を使用し WAS の Script 機能による自動実行で連続走行を行います IPCOM の操作は あらかじめ追加するサーバを定義しておき 以下のモニタ画面の操作により 1 台のサーバのスケールアウトを実施します 図 3-7.IPCOM の負荷分散ルール画面と保守状態の解除操作画面 3) 検証結果前もって IPCOM でスケールアウト時に追加するサーバを保守状態にしておき 途中でスケールアウトを実行してもクライアントのセッションが切断されることなく 追加したサーバにもアクセスが分散されることを IPCOM の負荷分散モニタ画面で目視し 確認しました 以下に サーバを 1 台スケールアウトした場合のサーバ負荷分散状態を IPCOM のコネクション数の負荷分散モニタ画面表示例で示します 13

16 図 3-8. スケールアウト実施時の負荷分散状況 4) 考察将来 WEB サーバのスケールアウトを意識したシステム構築を行い あらかじめ IPCOM のポリシーに WEB サーバを設定しておくことで 無停止のスケールアウトが実現可能となります 負荷が継続的に増加するシステムを構築する場合は IPCOM を導入し 構築時からスケールアウトを考慮したシステムの構築を行うことで 運用中のサービスを無停止にすることが可能となります 本検証のように ブレードサーバ PRIMERGY BX600 を使用していると スケールアウトによるサーバ増設などが容易に行えます 14

17 3.3.2 サーバ保守サーバを運用していく上で 定期的にセキュリティパッチを適用していくのは運用上 必須になっていますが セキュリティパッチ適用時にはサーバの再起動などサービス停止を伴うケースが多いです しかし 複数台設置した BEA WebLogic Server の前段に IPCOM を設置し サーバ負荷分散を行うことにより 保守時には IPCOM のシャットダウン制御機能を利用して サーバの保守を順次実行していくことで サービスを停止させずにサーバ保守を行うことが可能となり サービス性がアップします サーバ保守を実施するには 一部のサーバを保守状態にする必要があるため サーバを保守状態にする手順とサービス性に関しての検証を行い 結果を報告します 以下にサーバ保守の概念図を示します 4 セ アス ッ S S316 2 SL S24 セ アス ッ サーバ S S サーバ レード 4 サーバ保守のため サーバブレードを 2 台を保守状態に移行 4 セ アス ッ S S316 2 SL S24 セ アス ッ サーバ S S サーバ レード 4 図 3-9. サーバの保守 サーバ レード サーバ レード o 1) 検証条件 サーバ負荷分散(SLB) 方式ラウンドロビン方式 一意性保証( セッション維持 ) コネクション単位の分散によるクライアント ID 挿入方式 ファイアーウォールアプリケーションサーバへ必要なアクセス (ARP http https) のみ許可し それ以外は遮断します SSL アクセラレーター本検証では SSL 通信は使用しません 15

18 2) 検証方法 WEB サーバ / アプリケーションサーバとして BEA WebLogic Server 9.1 をサーバブレードにインストールし サンプルアプリケーション (Avitek Medical Records) を検証用アプリケーションとして 稼動させて利用します 最初は 4 台のサーバブレードを稼動させ その後 サーバ保守の実施にあたり 2 台のサーバブレードを保守状態にしてシステムから分離させます クライアント PC は 4 台を同時に動作させ 1 台の PC で 20 仮想端末の WAS を起動することで合計 80 の仮想端末を使用し WAS の Script 機能による自動実行で連続走行を行います IPCOM の操作は 以下のモニタ画面の操作により稼動中の 4 台のサーバから 2 台を順次保守状態にします 図 IPCOM の負荷分散ルール画面と保守状態の設定操作画面 3) 検証結果 IPCOM のサーバ負荷分散モニタの画面操作により 2 台のサーバを保守状態にすると クライアント PC からの新規アクセスが保守状態にしたサーバには振り分けられないことを IPCOM の負荷分散モニタ画面で目視し 確認しました 以下に サーバの保守を実施した場合 (4 台 2 台 ) のサーバ負荷分散の状態を IPCOM のコネクョン数の負荷分散モニタ画面表示例で示します 16

19 図 サーバ保守実施時 (2 台 4 台 ) の負荷分散状況 4) 考察 BEA WebLogic Server が稼動しているサーバシステムのサーバ保守を実行する場合でも IPCOM のシャットダウン機能を利用し サーバを切り離して保守を実施することで サービスを停止させることなくサーバの保守が実現可能になります また 保守が完了したサーバをシステムに復旧させる場合も IPCOM の操作によりサービスを停止させることなく サーバをシステムに組み込むことが可能です 組み込まれたサーバには IPCOM のスロースタート制御機能により クライアント PC の新規アクセスから徐々に振り分けられ安定した負荷分散が行われます なお サーバ保守中の場合は 保守をしていないサーバのコネクション数が増加するため あらかじめシステム設計時に保守時の最大コネクション数を考慮する必要があります 本検証のように ブレードサーバ PRIMERGY BX600 を使用していると サーバの保守が容易に行えます 17

20 3.3.3 セッションオーバー発生時の sorry メッセージ表示システムの能力以上の要求をクライントから受けると現在のほとんどの IT システムはスローダウンまたはシステム停止になってしまいます しかし IPCOM を導入することで クライントの要求を制限し 制限したクライントにはメッセージを出すことができます セッションオーバーが発生した場合の動作とサービス性を検証し 結果を報告します セ アス ッ S S316 2 SL S24 セ アス ッ サーバ S S サーバ レード 4 図 セッションオーバーの発生 1) 検証条件 サーバ負荷分散(SLB) 方式ラウンドロビン方式 一意性保証( セッション維持 ) コネクション単位の分散によるクライアント ID 挿入方式 ファイアーウォールアプリケーションサーバへ必要なアクセス (ARP http https) のみ許可し それ以外は遮断します SSL アクセラレーター本検証では SSL 通信は使用しません 2) 検証方法 WEB サーバ / アプリケーションサーバとして BEA WebLogic Server 9.1 をサーバブレード 4 台にインストールし サンプルアプリケーション (Avitek Medical Records) を検証用アプリケーションとして稼動させて利用します クライアント PC は 2 台を同時に動作させ 1 台の PC で 40 仮想端末の WAS を起動することで合計 80 の仮想端末を使用し WAS の Script 機能による自動実行で連続走行を行います IPCOM の操作は クライアントからのアクセス数を制限するアクセス制限機能でコネクション数を 1200 と設定し コネクション数がオーバーした場合は sorry メッセージを表示するように設定します 3) 検証結果 クライアントからの連続的なアクセスによりアクセス制限数を超え セッ 18

21 ションオーバーの状態が発生した場合に 新規アクセスを行ったクライ アントに以下の sorry メッセージ画面が表示され アクセスが受けつけら れないことを IPCOM の負荷分散モニタ画面で目視し 確認しました 図 IPCOM からの sorry メッセージ表示画面 4) 考察 IPCOM のアクセス制限機能とセッションオーバーエラー発生時に sorry メッセージを表示する設定を行うことにより sorry サーバを別途設置しなくても クライアントに対し システムの接続制限を通知することが可能となります これにより システムダウンなどの発生を未然に防ぐことが可能となります 19

22 4. まとめ 今回の検証では BEA WebLogic Server と IPCOM を使った WEB アプリケーショ ンシステムにおける サーバ負荷分散 SSL アクセラレーター性能 保守性 の 3 つの観点から特性と運用上の注意点などの検証を行いました まとめ サーバ負荷分散では BEA WebLogic Server のサンプルアプリケーションのサーバ負荷分散が IPCOM で可能であり セッション維持も問題なく行えました サーバ負荷分散の方式では ラウンドロビン方式でも最小コネクション数でも性能的には差はないと考えられます また BEA WebLogic Server はサーバのサンプルアプリケーションを稼動した場合に 今回の検証結果ではサーバの CPU 負荷率は 100% となるため 負荷計測エージェントを使用する負荷分散方式では効果が現れないと考えられます SSL アクセラレーター性能では IPCOM の SSL アクセラレーター機能を利用する方が BEA WebLogic Server の SSL 機能を利用するより 約 1.7 倍の性能が良いという検証結果から IPCOM の SSL アクセラレーター機能を利用することにより WEB サーバ / アプリケーションサーバのパフォーマンスを向上させることができます 今回の検証結果では 検証で使用したサンプルアプリケーションの一連の処理で使用するコンテンツのデータ量が少ない ( コンテンツの合計で約 70 Kbyte) ため 暗号化 / 複合化処理以外の DB 処理などのアプリケーションの動作処理の方に時間が多くとられ 暗号化 / 復号化処理にはあまり時間が取られていないと考えられます このため 大容量のコンテンツが多い WEB サイトなどでは IPCOM の SSL アクセラレーター機能による暗号化 / 複合化処理のオフロードの効果はさらに大きくなると考えられます 保守性では サーバの追加やサーバの保守において IPCOM の保守機能を利用することで サービス性が向上することがわかりました モニタの画面操作により サーバを保守状態へ移行し 作業完了後保守状態を解除することで アプリケーションシステムのサービスを停止させないようにすることができます また ブレードサーバ PRIMERGY BX600 を使用してシステムを構築することにより IPCOM の機能を利用したサーバ保守やサーバのスケールアウトが容易に行えます 20

23 日本 BEA システムズ- 富士通アプリケーションサーバフロント統合アライアンステクニカルホワイトペーパー Windows プラットフォーム編 2006 年 9 月初版 Copyright 2006 BEA Systems Japan, Ltd. Fujitsu Ltd. All Rights Reserved.