|
| Sun ONE Application Server 7 パフォーマンスチューニングガイド |
Sun ONE Application Server のパフォーマンスについてこの章では、次の項目について説明します。
アプリケーションサーバーをチューニングする目的
配備記述子の設定をいくつか調整したり、サーバー設定ファイルに変更を加えるだけでパフォーマンスは大きく向上します。しかし、環境とパフォーマンスの最終的な目標を把握することが重要です。本稼働環境で最適な設定が必ずしも開発環境に適しているとは限りません。このマニュアルでは、Sun ONE Application Server のパフォーマンスを最大限に引き出せるように、用意されている調節オプションとサイズ設定のオプションについて説明します。
次の図は、Sun ONE Application Server のプロセスアーキテクチャを示しています。
図: シングルドメインの Sun ONE Application Server プロセスアーキテクチャ
動作要件について
Sun ONE Application Server にアプリケーションを配備し、チューニングを始める前に、動作環境を明確にしておくことが重要です。動作環境は、次のような高レベルの制約と要件から決定されます。
アプリケーションアーキテクチャ
次の図に示すように、J2EE アプリケーションモデルはとても柔軟性があり、アプリケーション開発者はロジックを機能別に複数の層に分割できます。プレゼンテーション層は、通常はサーブレットと JSP を使って実装され、Web コンテナ内で実行されます。
図: J2EE アプリケーションモデル
ある程度の複雑さが必要となるエンタープライズアプリケーション全体をサーブレットと JSP だけで開発することは一般的ではありません。より複雑なビジネスアプリケーションの多くは、EJB を使って実装されます。Sun ONE Application Server は、Web コンテナと EJB コンテナを 1 つのプロセスに統合します。サーブレットから EJB へのローカルアクセスはとても効率的です。しかし、アプリケーションの配備によっては、EJB を別のプロセスで実行したり、スタンドアロンのアプリケーションやサーブレットから EJB にアクセスすることが必要です。アプリケーションアーキテクチャに基づけば、サーバー管理者は Sun ONE Application Server を複数の層に分割したり、プレゼンテーションとビジネスロジックを 1 つの層にまとめることができます。
新しいアプリケーションサーバーの配備を設計したり、既存のアプリケーションサーバーの配備に新しいビジネスアプリケーションを配備するときは、サーバー管理者は事前にアプリケーションアーキテクチャを理解することが重要です。
セキュリティ要件
ビジネスアプリケーションのほとんどはセキュリティを必要とします。ここでは、セキュリティに関するさまざまな考慮事項や、利用できる選択肢について説明します。
ユーザーの認証と承認
アプリケーションのユーザーを認証する必要があります。Sun ONE Application Server には、3 種類のユーザー認証方法が用意されています。
新しいアプリケーションを開発、テストする開発環境には、デフォルトのファイルベースのセキュリティレルムが適しています。開発時に、サーバー管理者は LDAP レルムと UNIX レルムのいずれかを選択できます。
LDAP は、Lightweight Directory Access Protocol の略です。大企業の多くは、従業員プロフィールや顧客プロフィールの管理に LDAP ベースのディレクトリサーバーを使っています。
ディレクトリサーバーを使っていない中小企業にとっても、Solaris のセキュリティインフラストラクチャの活用は魅力的です。
さまざまなセキュリティレルムを統合する方法については、『Sun ONE Application Server セキュリティ管理者ガイド』を参照してください。
選択した認証メカニズムによっては、配備に追加ハードウェアが必要となります。一般に、ディレクトリサーバーは別のサーバーで実行され、レプリケーションや可用性の確保に備える場合はバックアップも必要になります。配備、サイズ設定、可用性のガイドラインについては、Sun ONE Directory Server のマニュアルを参照してください。
認証されたユーザーによる、アプリケーションのさまざまな機能へのアクセスには、さらに承認チェックが必要です。アプリケーションがロールベースの J2EE 承認チェックを採用した場合は、アプリケーションサーバーによって追加チェックも行われます。これによってオーバーヘッドも増えるため、処理能力を計画するときには注意が必要です。
暗号化
セキュリティ上の理由から、機密性のあるユーザー入力やアプリケーション出力の転送は、暗号化した上で行う必要があります。ビジネスに関連する Web アプリケーションのほとんどは、ブラウザとアプリケーションサーバーの間の通信内容の一部またはすべてを必要に応じて暗号化しています。オンラインショッピングのアプリケーションでは、通常のトラフィックは暗号化されていませんが、ユーザーが購入を完了する場合や、個人データを入力する場合は暗号化されます。ニュースなどのポータルアプリケーションでは、通常は暗号化は行われません。インターネットで最も一般的なセキュリティフレームワークは SSL で、多くのブラウザとアプリケーションサーバーがこれに対応しています。
Sun ONE Application Server は SSL 2.0 と 3.0 に対応し、さまざまな暗号方式をサポートするソフトウェアも用意されています。また、より高性能なハードウェア暗号化カードの統合にも対応しています。セキュリティに関する考慮事項、特に暗号化ソフトウェアの統合は、ハードウェアのサイズ設定と処理能力の計画に影響します。配備するアプリケーションの暗号化について検討する場合、管理者は次の点に注意する必要があります。
- セキュリティを考慮した場合、アプリケーションの性質はどのようなものか。アプリケーションの入出力のすべてを暗号化するか、一部だけを暗号化するか。セキュアな転送が必要な情報は、全体の何パーセント程度か。
- インターネットに直接接続されたアプリケーションサーバーにアプリケーションを配備するのか。アプリケーションサーバー層とバックエンドエンタープライズシステムとは別に、DMZ (非武装ゾーン) に Web サーバーは置かれているか。高度なセキュリティが必要な配備では、DMZ を使った配備をお勧めします。また、アプリケーションに静的なテキストや画像が大量に含まれ (ほとんどの場合は暗号化の必要がなく、DMZ に配備した Web サーバーからの配信が可能)、比較的小規模なビジネスロジックを強力なファイアウォールの奥のアプリケーションサーバーで実行する場合にも便利です。一般的な Web サーバー が Sun ONE Application Server を統合できるように、Sun ONE Application Server にはセキュアなリバースプロキシプラグインが用意されています。Sun ONE Application Server は本格的な Web サーバーでもあるので、DMZ 内で Web サーバーとして利用することもできます。
- DMZ 内の Web サーバーと次の層で稼働するアプリケーションサーバーの間で暗号化は必要か。Sun ONE Application Server のリバースプロキシプラグインは、Web サーバー層とアプリケーションサーバー層の間の SSL 暗号化をサポートしています。これを有効にする場合、管理者は暗号化のポリシーとメカニズムを考慮してハードウェアの処理能力を計画する必要があります。
- ソフトウェアによる暗号化を利用する場合、システムの各層で予想されるセキュリティ要件関連のパフォーマンスオーバーヘッドは何か。
- ハードウェアによる暗号化を利用する場合、各製品のパフォーマンスとスループットの関係はどのようなものか。
注 Web サーバーと Sun ONE Application Server の間の通信を暗号化する方法については、『Sun ONE Application Server 管理者ガイド』を参照してください。
アプリケーションの用途
アプリケーションのユーザーは、誰もがアプリケーションのパフォーマンスについて何らかの期待を持っています。これは、通常は数値化が可能です。サーバー管理者はこの期待を明確に把握し、完成したアプリケーションが顧客のニーズを満たせるように処理能力を計画する必要があります。
パフォーマンスについては、次の点に注意する必要があります。
- アプリケーションとの間でさまざまなやりとりを行うエンドユーザーが必要とする平均的な応答時間はどの程度か。最も頻繁に行われるやりとりは何か。応答時間の重要性が極端に高いやりとりがあるか。思考時間も含め、各トランザクションの長さはどの程度か。多くの場合、役に立つ予測を立てるには、ユーザーによる実際の操作テストを行う必要があります。
- 安定時とピーク時のユーザー負荷はどの程度か。負荷がピークとなる特定の時間帯、曜日、月はあるか。オンラインビジネスでは数百万人の登録顧客も考えられますが、ある一定の時間にログインし、ビジネストランザクションを行うのは、通常はそのごく一部に限られます。処理能力の計画で起きやすい間違いは、並行してアクセスする顧客の平均人数とピーク時の人数を基準とせずに、顧客の総数を基準とすることです。並行アクセスするユーザーの数は、時間帯によっても異なることがあります。
- 1 つの要求で転送されるデータの平均量と最大量はどの程度か。これもアプリケーションによって大きく異なります。コンテンツのサイズを正しく見積もることは、その他の用途パターンと合わせて、管理者によるネットワーク容量の計画に役立ちます。
- 今後 12 か月に予想されるユーザー負荷の成長はどの程度か。将来に備えた計画により、危機的な状況や、アップグレードのためのダウン時間を回避できます。
ハードウェアリソース
管理者が自由に使えるハードウェアリソースの種類と数は、パフォーマンスのチューニングとサイトの計画に大きく影響します。
Sun ONE Application Server は、優れた垂直スケーラビリティを提供します。1 つのアプリケーションサーバープロセスで、最大で 12 の高性能 CPU を利用できます。アプリケーションサーバーインスタンスの数は、少ないほど管理の手間とコストが少なくなります。また、少数のアプリケーションサーバーに複数の関連アプリケーションを配備することで、データのローカリティの向上や、アプリケーション間でのキャッシュデータの再利用が見込めるため、パフォーマンスの向上を期待できます。このようなサーバーでは負荷も増大するため、大容量のメモリ、ディスクスペース、ネットワーク容量も必要となります。
Sun ONE Application Server は、小規模なハードウェア製品のグループに配備することもできます。ビジネスアプリケーションは、さまざまなサーバーインスタンスに区切ることができます。1 台または複数の外部ロードバランサーを導入することで、ユーザーからのアクセスは、効率的にすべてのアプリケーションサーバーインスタンスに分散されます。水平スケーリングのアプローチは、ハードウェアコストを抑えると同時に、可用性も向上させることができるため、このアプローチが適するアプリケーションもあります。ただし、管理が必要なアプリケーションサーバーインスタンスとハードウェアノードの数も多くなります。
管理
サーバーにインストールした 1 つの Sun ONE Application Server を使って、複数のインスタンスを作成できます。1 つの管理サーバーは 1 つまたは複数のインスタンスを管理でき、この管理サーバーと管理対象インスタンスのグループを「ドメイン」と呼びます。複数の管理ドメインを作成することで、アプリケーションサーバーインスタンスの複数グループを異なる担当者が個別に管理できます。
開発環境の開発者用に、1 つのインスタンスだけのドメインを作成し、これを独立した作業領域として使うこともできます。この場合、各開発者はその他のアプリケーションサーバードメインに影響することなく、専用のアプリケーションサーバーを管理できます。小規模な開発チームであれば、共同開発用に複数のインスタンスを持つ共用の管理ドメインも作成できます。
開発環境では、サーバー管理者はアプリケーションとビジネス機能に基づいて管理ドメインを作成できます。たとえば、社内用の人材アプリケーションを 1 つの管理ドメインの 1 つまたは複数のサーバーでホストし、外部の顧客用アプリケーションを複数のハードウェアにまたがる複数の管理ドメインでホストすることができます。
Sun ONE Application Server は、Web アプリケーションの仮想サーバー機能をサポートしています。Web アプリケーションをホストするサービスプロバイダでは、管理を容易にするために、1 つの Sun ONE Application Server で複数の URL ドメインをホストしたいと考えるかもしれません。サーバー管理者は、この機能の必要性を検討する必要があります。
この時点でサーバー管理者は、すべてのアプリケーション、パフォーマンス特性の概要、セキュリティ要件を把握し、かなり具体的な配備環境のイメージを持っているはずです。次に、パフォーマンスを見積もり、処理能力を計画する方法について説明します。
処理能力の計画
これまでに、理想的な配備アーキテクチャについて説明してきました。しかし、実際の配備サイズは、処理能力の計画によって決定されます。
しかし、特定のハードウェアの処理能力、または特定のアプリケーション負荷や顧客基準に見合ったハードウェアリソースをどのように見積もればよいのでしょう。これは、実際のアプリケーション、および現実的なデータと作業負荷のシミュレーションを使った慎重なパフォーマンスベンチマークプロセスによって行われます。次に、基本的な手順について簡単に説明します。
- 1 つの CPU のパフォーマンスを求める
まず、わかっている処理能力から得られる最大の負荷耐性を求めます。この値を求めるには、1 つのプロセッサだけを搭載したマシンでアプリケーションのパフォーマンスを測定します。テスト環境で、同じような処理特性を必要とする既存のアプリケーションを組み合わせるか、理想的には実際のアプリケーションと作業負荷を使って測定します。アプリケーションとデータリソースは、実際の配備と同じ層構造に設定しておく必要があります。
- 垂直スケーラビリティを求める
プロセッサを追加したときに、パフォーマンスがどれだけ向上するかを求める必要があります。これは、特定の作業負荷の下で生じる共有リソースの競合を間接的に測定するということです。これは、マルチプロセッサシステムでアプリケーションの追加負荷を測定して求めるか、すでにテストが終わっている同様のアプリケーションに関する既存の情報から求められます。CPU の数を 1 から 8 まで順に増やしてテストすることで、システムの垂直スケーラビリティの概要を把握することができます。正しい調査結果を得るには、アプリケーション、アプリケーションサーバーとバックエンドデータベースのリソース、オペレーティングシステムなどを適切に調節しておく必要があります。
- 水平スケーラビリティを求める
十分に強力なハードウェアリソースを利用できる場合は、単独のハードウェアノードだけでもパフォーマンス要件を満たすことができます。しかし、サービスの可用性を向上するために、複数のシステムによるクラスタ化が必要になることもあります。外部のロードバランサーを導入した場合の作業負荷をシミュレートし、手順 2 で求めた 1 つのチューニング済みアプリケーションサーバーノードのパフォーマンスと比較して、どれだけの向上を見込めるかを調べます。
次の表は、処理能力の計画手順をまとめたものです。
パフォーマンスチューニングの流れ
配備環境のチューニングは、次の順序で行います。
- アプリケーションのチューニング
- Sun ONE Application Server のチューニング
- Java 実行システムのチューニング
- オペレーティングシステムのチューニング
設定ファイル
Sun ONE Application Server の設定ファイル init.conf、obj.conf、server.xml には、変更することでパフォーマンスを向上できる数多くの属性が設定されています。このマニュアルでも随所でとりあげられるこれらのファイルは、次のディレクトリに保存されています。
<APPSERVER_HOME>/appserv/domains/<DOMAIN_NAME>/<SERVER_NAME>/config/
APPSERVER_HOME は、Sun ONE Application Server のインストールディレクトリです。DOMAIN_NAME と SERVER_NAME は、設定するサーバーインスタンスのドメイン名とサーバー名です。
次の図は、あるインスタンスの設定ファイルの内容を示しています。
図: Sun ONE Application Server の設定ファイル
config/backup ディレクトリには、サーバー設定ファイルのコピーが保存されています。これらのファイルは、管理サーバーインスタンスによって自動的に作成されます。一般に、ユーザーがファイルを手動で変更することはお勧めできません。config ファイルを手動で変更した場合は、backup ディレクトリに保存されているファイルのコピーも置き換えてください。また、サーバーインスタンスの再起動も必要となります。
ログの記録とパフォーマンスへの影響
Sun ONE Application Server が生成するログメッセージと例外のスタックトレース出力は、ログファイルに書き込まれます。ログメッセージと例外スタックは、各インスタンスの logs ディレクトリに保存されます。ログの記録はサーバーのパフォーマンスに影響するので、特にベンチマーク測定時には注意を払う必要があります。
デフォルトでは、ログレベルは INFO に設定されています。log_service 要素の属性レベルを変更することで、サーバーのすべてのサブシステムのログレベルを変更できます。特定のサブシステムに設定したログレベルは、これに優先して適用されます。たとえば、mdb_container 要素の log_level 属性を変更することで、mdb_container はサーバーのデフォルトとは異なるレベルでログメッセージを生成するようになります。ログレベルを FINE、FINER、または FINEST に設定することで、より多くのデバッグメッセージを記録できます。ベンチマーク測定時のログレベルは、SEVERE が適当でしょう。