test

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

第 1 章 Application Server パフォーマンスチューニングの概要

Sun Java System Application Server およびこの製品に配備されたアプリケーションのパフォーマンスは、いくつかの配備設定およびサーバー設定を調整することによって大きく改善することができます。ただし、環境およびパフォーマンスに関しての目標を理解することが重要です。本稼働環境で最適な設定と、開発環境で最適な設定は必ずしも一致しません。この章では、パフォーマンスチューニングのプロセスを紹介し、次のトピックについて説明します。

プロセスの概要

次の表は、管理プロセスの全体の概略と、一連の作業の中でパフォーマンスチューニングがどこに位置するかを示したものです。

表 1–1 パフォーマンスチューニングのロードマップ

ステップ 

タスクの説明 

参照マニュアル 

1 

設計: 高可用性トポロジを決定し、Application Server および高可用性データベース (HADB) システムを設定します。 

『配備計画ガイド』

2 

容量計画: 高いパフォーマンスを発揮するための十分なリソースがシステムに搭載されていることを確認します。 

『配備計画ガイド』

3 

インストール: Application Server ソフトウェアとともに、または単体で HADB ソフトウェアをインストールします。 

『インストールガイド』

4 

配備: アプリケーションをインストールして実行します。Application Server のサブシステムおよびコンポーネントの設定および管理方法について理解します。 

『管理ガイド』 

5 

チューニング: アプリケーション、Java 実行時システム、オペレーティングシステム、HADB、および Application Server を調整します。 

『パフォーマンスチューニングガイド』

Procedureパフォーマンスチューニングの流れ

アプリケーション開発者は、本稼働環境での運用を開始する前にアプリケーションを調整する必要があります。アプリケーションのチューニングにより、パフォーマンスが劇的に改善されることがよくあります。システム管理者は、アプリケーションを調整したあと、またはアプリケーションチューニングを待機する必要があるがその間にもできるだけパフォーマンスを改善したい場合に、次のリストに示した残りのステップを実行します。

この一連のステップは、パフォーマンスチューニングを行なっているときに実行するのが理想的です。

  1. 第 2 章「アプリケーションのチューニング」の説明に従ってアプリケーションを調整します。

  2. 第 2 章「アプリケーションのチューニング」の説明に従ってサーバーを調整します。

  3. 第 6 章「高可用性のチューニング」の説明に従って、高可用性データベースを調整します。

  4. 第 2 章「アプリケーションのチューニング」の説明に従って、Java 実行時システムを調整します。

  5. 第 5 章「オペレーティングシステムのチューニング」の説明に従って、オペレーティングシステムを調整します。

処理要件の理解

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 管理ガイド』を参照してください。

一般的なチューニングの概念

パフォーマンスチューニングに影響する重要な概念には、次のものがあります。

次の表で、これらの概念と実際の測定方法を説明します。左端の列では一般的な概念を示し、2 番目の列にはその概念を実行した場合の結果を示します。3 番目の列では測定値、右端の列では値のソースを説明します。

表 1–2 パフォーマンスに影響する要因

概念 

実行した場合の結果 

測定値 

値のソース 

ユーザー負荷

ピーク負荷時の同時セッション数 

毎分トランザクション数 (TPM) 

毎秒 Web インタラクション数 (WIPS) 

(最大同時ユーザー数) * (予測応答時間) / (クリック間隔) 

例: 

(100 ユーザー * 2 秒) / 10 秒 = 20 

アプリケーションのスケーラビリティー

1 個の CPU 上で測定されるトランザクション率 

TPM または WIPS 

負荷ベンチマークから測定されます。各層で実行します。 

垂直方向のスケーラビリティー 

CPU の追加によるパフォーマンス上昇 

追加 CPU あたりの上昇率 

ベンチマークからの曲線の当てはめに基づくCPU 数を段階的に増やしながらテストを実行します。曲線の「転換点」を識別します。これは、CPU の追加によるパフォーマンス上昇効果がコストに見合わなくなるポイントです。このガイドの説明に従ったチューニングが必要です。各層で実行し、必要であれば反復します。この測定値がパフォーマンス要件を満たしていればここで中止します。 

水平方向のスケーラビリティー 

サーバー の追加によるパフォーマンス上昇 

サーバープロセスやハードウェアノードの追加あたりの上昇率 

前のステップと同様に、十分に調整された単一のアプリケーションサーバーインスタンスを使用します。サーバーインスタンスおよびハードウェアノードを 1 つ追加するたびにパフォーマンスがどれだけ改善されるかを測定します。 

安全性マージン

高可用性要件 

システムが障害に対処する必要がある場合、1 つ以上のアプリケーションサーバーインスタンスの機能停止を想定したパフォーマンス要件を満たすようにシステムのサイズを決定する 

高可用性が必要な場合は、使用する等式が異なります。 
 

想定を超えたピーク時の超過容量 

ある程度の安全マージンを確保するために、ベンチマークで測定されたピークよりも低い負荷でサーバーを運用することが望ましい 

ピーク負荷の 80% のシステム容量利用は、ほとんどのインストールで適切です。現実のピーク負荷およびシミュレートされたピーク負荷の各条件下で配備を測定します。 

容量計画

これまでの説明では、配備アーキテクチャーの定義に向けた指針を示しました。ただし、配備の実際のサイズは、「容量計画」と呼ばれるプロセスによって決定します。容量計画では、次のことを予測します。

これらの値を予測するには、現実的なデータセットおよび作業負荷を用意したアプリケーションを使用して、入念なパフォーマンスベンチマーク測定を行います。

Procedure容量を決定する

  1. 1 個の CPU 上でのパフォーマンスを特定する。

    まず、1 個のプロセッサで持続できる最大の負荷を特定します。この数値は、シングルプロセッサマシン上でアプリケーションのパフォーマンスを測定することによって入手できます。類似の処理特性を持つ既存のアプリケーションのパフォーマンス数値を利用するか、より理想的な方法として、テスト環境で実際のアプリケーションおよび作業負荷を使用します。この測定で使用するアプリケーション層およびデータソース層の構成は、最終的な配備と完全に一致するようにしてください。

  2. 垂直方向のスケーラビリティーを特定する。

    プロセッサを追加したときにパフォーマンスがどの程度上昇するかを特定します。これは、特定の作業負荷がかかったときにサーバー上で発生する共有リソース競合の量を間接的に測定することになります。この情報は、マルチプロセッサシステム上でのアプリケーションの追加負荷テストに基づいて入手するか、あるいは、すでに負荷テストが完了している類似のアプリケーションから入手した既存の情報を利用します。

    一般的には、1〜8 個の CPU 構成で一連のパフォーマンステストを段階的に実行することにより、システムの垂直方向スケーラビリティー特性の感覚が得られます。結果を歪曲することがないように、必ず、アプリケーション、Application Server、バックエンドのデータベースリソース、およびオペレーティングシステムを適切に調整してください。

  3. 水平方向のスケーラビリティーを特定する。

    十分に強力なハードウェアリソースを利用できる場合、単一のハードウェアノードでパフォーマンス要件を満たせる場合があります。それでも、2 台以上のシステムをクラスタ化することで、さらなる可用性の向上を実現できます。外部のロードバランサおよび作業負荷シミュレーションを利用して、ステップ (2) で特定したように、十分に調整された 1 つのアプリケーションサーバーノードをレプリケートすることによって得られるパフォーマンス向上を特定します。

ユーザーの期待

アプリケーションのエンドユーザーは一般に、パフォーマンスに関して何らかの期待を抱いています。多くの場合、そのような期待は数値的に定量化できます。顧客のニーズが満たされることを保証するために、これらの期待を明確に理解し、容量計画に反映する必要があります。

パフォーマンスに関する期待について、次の事項を検討します。

詳細情報