test

Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド

処理要件の理解

Application Server にアプリケーションを配備して調整する前に、運用環境を明確に定義することが重要です。運用環境は、次のような全体レベルの制約や要件によって決定されます。

アプリケーションアーキテクチャー

J2EE アプリケーションモデルは、次の図に示すように非常に柔軟です。アプリケーションアーキテクトは、アプリケーションロジックを機能別に多数の層に分割できます。プレゼンテーション層は一般にサーブレット技術や JSP 技術を使用して実装され、Web コンテナ内で実行されます。

図 1–1 J2EE アプリケーションモデル

J2EE アプリケーションモード

ある程度までの複雑さのエンタープライズアプリケーションは、全面的にサーブレット技術と JSP 技術を使用して開発できます。より複雑なビジネスアプリケーションでは、多くの場合 Enterprise JavaBeans (EJB) コンポーネントを使用します。Application Server では、Web コンテナと EJB コンテナを単一のプロセスに統合します。サーブレットから EJB コンポーネントへのローカルアクセスは非常に効率的です。ただし、一部のアプリケーション配備では、EJB コンポーネントを独立したプロセスで実行すること、および、EJB コンポーネントにサーブレットだけでなくスタンドアロンのクライアントアプリケーションからアクセスできることが必要な場合があります。サーバー管理者はアプリケーションアーキテクチャーに基づいて、Application Server を複数層に展開するか、あるいはプレゼンテーションロジックとビジネスロジックの両方を単一層に配置するかを選択できます。

新しい Application Server 配備を設計する前、また既存のアプリケーションサーバー配備に新しいビジネスアプリケーションを配備するときは、アプリケーションアーキテクチャーについて理解することが重要です。

セキュリティー要件

ほとんどのビジネスアプリケーションにはセキュリティーが必要です。この節では、セキュリティー関連の考慮事項および決定事項について説明します。

ユーザーの認証と承認

アプリケーションのユーザーは認証を受ける必要があります。Application Server ではユーザー認証の方法として、ファイルベース、LDAP、および Solaris の 3 つの選択肢が用意されています。

デフォルトのファイルベースセキュリティーレルムは、新しいアプリケーションの開発およびテストが行われる開発者環境に適しています。サーバー管理者は配備時に、Lightweight Directory Access Protocol (LDAP) または Solaris セキュリティーレルムを選択できます。多くの大企業では、LDAP ベースのディレクトリサーバーを使用して、従業員や顧客のプロファイルを管理しています。まだディレクトリサーバーを利用していない中小企業では、Solaris セキュリティーインフラストラクチャーへの投資を活用すると有利な場合があります。

セキュリティーレルムの詳細は、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』の第 9 章「セキュリティーの設定」を参照してください。

選択した認証機構のタイプによっては、配備へのハードウェア追加が必要になる場合があります。通常、ディレクトリサーバーは独立したサーバー上で実行され、レプリケーションや高可用性のためのバックアップサーバーが必要な場合もあります。配備、サイジング、および可用性のガイドラインは、Sun Java System Directory Server のマニュアルを参照してください。

認証されたユーザーによるアプリケーション機能へのアクセスには、承認チェックも必要な場合があります。アプリケーションでロールに基づく J2EE 承認チェックを使用する場合、アプリケーションサーバーが何らかの追加チェックを実行し、これによって追加のオーバーヘッドが発生します。容量計画を実施するときは、この追加のオーバーヘッドを考慮する必要があります。

暗号化

セキュリティー上の理由から、機密性のあるユーザー入力およびアプリケーション出力を暗号化する必要があります。ほとんどのビジネス指向 Web アプリケーションでは、ブラウザと Application Server の間の通信フローの全部または一部を暗号化します。オンラインショッピングアプリケーションでは、ユーザーが購入を完了するとき、または個人データを入力するときにトラフィックを暗号化します。ニュースやメディアなどのポータルアプリケーションでは、通常は暗号化を行いません。SSL (Secure Sockets Layer) はもっとも一般的なセキュリティーフレームワークであり、多くのブラウザおよびアプリケーションサーバーでサポートされています。

Application Server は SSL 2.0 および 3.0 をサポートし、各種の暗号化方式群のソフトウェアサポートが含まれています。また、パフォーマンスをさらに高めるためにハードウェア暗号化カードの統合もサポートしています。セキュリティー上の考慮事項によって、統合ソフトウェアの暗号化を使用している場合に特に影響を受けるのは、ハードウェアのサイジングおよび容量計画です。

配備の暗号化ニーズを評価するときは、次のことを考慮します。

Web サーバーと Application Server の間で通信を暗号化する方法の詳細は、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』の第 9 章「セキュリティーの設定」を参照してください。

ハードウェアリソース

使用可能なハードウェアリソースの種類と量は、パフォーマンスチューニングおよびサイト計画に大きな影響を及ぼします。

Application Server は、卓越した垂直方向のスケーラビリティーを提供します。ただ 1 つのアプリケーションサーバープロセスを使用しながら、複数の高性能 CPU を効率的に利用するような構成への拡張が可能です。アプリケーションサーバーインスタンスの数が少ないほど、保守が容易になり管理コストが低減されます。また、関連アプリケーションを配備するアプリケーションサーバーの数が少なければデータの局所性が高まってパフォーマンスが向上し、共存アプリケーション間でのキャッシュデータの再利用も活発化します。そのようなサーバーでは、負荷の増加に対応できる十分な量のメモリー、ディスク領域、およびネットワーク容量を備える必要もあります。

Application Server は、それほど高性能でない多数のハードウェアユニットで構成される大規模「ファーム」への配備も可能です。ビジネスアプリケーションを複数のサーバーインスタンス間でパーティション分割することができます。1 つ以上の外部ロードバランサを使用して、すべてのアプリケーションサーバーインスタンス間でユーザーアクセスを効率的に分散させることができます。水平型のスケーリングアプローチでは可用性の向上やハードウェアコストの低減が可能です。このアプローチは、一部の種類のアプリケーションに適しています。ただし、このアプローチでは、より多数のアプリケーションサーバーインスタンスやハードウェアノードの管理が必要になります。

管理

1 台のサーバーへの Application Server の単一インストール内で、複数のインスタンスを動作させることができます。単一の Application Server によって管理される 1 つ以上のインスタンスのグループを「ドメイン」と呼びます。サーバーインスタンスをドメインにグループ化することにより、役割の異なる人々がそれぞれ独立した形でグループを管理できます。

単一インスタンスドメインを使用して、特定の開発者および環境向けの「サンドボックス」を作成できます。このシナリオでは、個々の開発者はほかのアプリケーションサーバードメインに干渉することなく、自分自身のアプリケーションサーバーを管理します。小規模の開発グループでは、共同作業による開発を目的として、共有管理ドメイン内に複数のインスタンスを作成することを選択できます。

配備環境では、開発者はアプリケーションやビジネスの機能に基づいてドメインを作成できます。たとえば、社内の人事管理アプリケーションを 1 つの管理ドメイン内の 1 台または複数台のサーバーで運用し、外部の顧客アプリケーションをサーバーファーム内の複数の管理ドメインで運用することができます。

Application Server は、Web アプリケーション用の仮想サーバー機能をサポートします。たとえば、効率的な管理のために、サービスプロバイダのホストである Web アプリケーションが、単一の Application Server プロセス上で複数の異なる URL ドメインをホストできます。

管理の詳細は、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』を参照してください。