oracle j2ee 状態レプリケーションのガイドラインとベスト ......maximum...

Oracle J2EE 状態レプリケーションのガイドラインとベスト・プラクティス

Oracle ホワイト・ペーパー 2007 年 10 月

Maximum Availability Architecture Oracle Best Practices For High Availability

Maximum Availability Architecture


概要 ...................................................................................................................... 4 はじめに .............................................................................................................. 5 参照レプリケーション・トポロジ................................................................... 5

トポロジのコンポーネントおよび用語 ..................................................... 6 ロード・バランサ ................................................................................... 6 Oracle HTTP Server（OHS） .................................................................. 6 Oracle Containers for Java（OC4J） ....................................................... 6 OPMN ベースのトポロジ....................................................................... 6

レプリケーション構成オプション................................................................... 7 マルチキャストと Peer-to-Peer の比較 ....................................................... 7 分散 JVM と同じ場所に配置されている JVM の比較 ............................. 8

応答時間 ................................................................................................... 8 可用性 ....................................................................................................... 8 システム・リソース ............................................................................... 8

レプリケーション・ターゲットまたはレプリケーション割当て制限の数......................................................................................................... 9

応答時間 ................................................................................................... 9 可用性 ....................................................................................................... 9 システム・リソース ............................................................................... 9

非同期レプリケーションと同期レプリケーション ............................... 10 応答時間 ................................................................................................. 10 可用性 ..................................................................................................... 10 システム・リソース ............................................................................. 10

レプリケートする場合............................................................................... 11 レプリケーション・テスト............................................................................. 11

マルチキャストと Peer-to-Peer の比較 ..................................................... 11 分散 JVM と同じ場所に配置されている JVM の比較 ........................... 11 レプリケーション・ターゲットの割当て制限または数 ....................... 12 非同期レプリケーションと同期レプリケーション ............................... 13

スケーラビリティの推奨事項......................................................................... 14 レプリケーション・コスト ....................................................................... 14 レプリケーション・ペアの対応 ............................................................... 15 フェイルオーバー計画............................................................................... 16

JVM 障害 ................................................................................................ 16 OC4J ノード障害 ................................................................................... 17 OHS 障害 ................................................................................................ 17

他のスケーラビリティの考慮事項 ........................................................... 17 高負荷なシナリオ ................................................................................. 17 大きいセッション・サイズ ................................................................. 18

結論 .................................................................................................................... 18 付録 A：構成の詳細......................................................................................... 20

ハードウェア構成....................................................................................... 20 HPUX 構成................................................................................................... 20


Oracle Corporation 発行「Oracle J2EE State Replication Guidelines and Best Practices」の翻訳版です。

2


付録 C：実際のテスト環境の図 ..................................................................... 23 付録 D：JVM 構成............................................................................................ 24 付録 C：クライアント、サーブレット、および JVM の構成 ................... 25



3



概要

オラクルの J2EE 状態レプリケーションは、HTTP セッションとその関連オブジェクトに対する信頼性を提供します。アプリケーションの特定のインスタンスに

よってメモリーに保存されたアプリケーション状態を構成して、アプリケーショ

ンの別のインスタンスに自動的にレプリケートできます。最初のインスタンスが

使用できなくなった場合、レプリケーション・フレームワークは、レプリケート

されたセッション状態でアプリケーションの別のインスタンスへの透過的なフェ

イルオーバーを提供します。

状態レプリケーションの利点には、アプリケーションの可用性、透過的なフェイ

ルオーバー、およびオラクルの J2EE クラスタ・フレームワークによるロード・バランシングが含まれます。Oracle Application Server 10g Release 3 は、信頼性の高いアーキテクチャを活用しようとしている組織に対して標準ベースのミッション・

クリティカルなプラットフォームを提供します。Oracle Application Server 10g Release 3 では、以前のリリースの状態レプリケーション機能を拡張して、保証されたサービス、信頼性、順序付け、断片化、およびグループ・メンバーシップを

特に強調したもっともスケーラブルでフォルト・トレラントなセッション・レプ

リケーション・フレームワークを提供します。

このホワイト・ペーパーでは、サーブレット/JSPレイヤー（HTTPセッションのレプリケーション1）でのステートフル・アプリケーションの状態レプリケーション

に関する推奨事項とベスト・プラクティスについて説明します。Oracle Application Server 10g Release 3 が提供するステートフル構成の実際のリニア・スケーラビリティと使用可能なさまざまなレプリケーション・オプションも説明します。また、

すべての主要な構成パラメータを確認し、可用性、パフォーマンス、およびシス

テム・リソースのさまざまなレプリケーション設定の影響と利点について説明し

ます。

テストと監視結果から、レプリケーションの有効化が最小限のオーバーヘッドで

実現できる完全なスケーラビリティを備えたソリューションであることがわかっ

たので、アプリケーションのセッション・データが重要な場合は常に有効にする

必要があります。

1 ステートフルSession Beanの状態レプリケーションも使用可能であり、OracleAS 10g Release 3 のHTTPセッションと同じレプリケーション・フレームワークを使用できますが、このホワイト・ペーパーでは取

り上げません



4


はじめに

ステートフル・アプリケーションのレプリケーションを有効にするには、以下の

質問を考慮する必要があります。

1) セッション状態が失われた場合にアプリケーションにどのような影響があるか。

2) 状態レプリケーションでどのように状態の損失から保護し、環境の可用性を向上させるか。

3) 状態レプリケーションを有効にした際に、アプリケーションのパフォーマンスに影響があるか。

4) 状態レプリケーションを有効にした場合にシステム・リソースに悪影響を与えるか。

上記の最初の質問の回答は、以下のとおりです。セッション情報の損失による影

響は、アプリケーションの性質によって異なります。セッションは頻繁に使用さ

れ、一連のページまたは決定を通じて特定のユーザーの進捗状況が追跡されます。

このデータの損失は、すべてのユーザーのセッション状態の再初期化を意味します。

他の質問は、このホワイト・ペーパーで説明する内容です。つまり、レプリケー

ションの全体のコストとさまざまなレプリケーション・オプションの影響に関す

る情報です。パフォーマンス、可用性、およびリソースの観点から既存のアプリ

ケーションにどれだけ影響を与えるかを説明します。

最初に、参照レプリケーション・トポロジを紹介し、基本的な用語を定義します。

次に、機能と推奨事項とともにレプリケーション・オプションを説明します。後

半では、実行された一部のテストを説明し、推奨事項を満たす独自のテスト・デー

タの図を示します。

特にトラフィックまたはレプリケーションの多い環境に関するスケーラビリティ

の推奨事項と監視結果を後に記載しています。最後の付録には、特定の環境の詳

細情報と JVM 構成の詳細が含まれます。

参照レプリケーション・トポロジ

J2EE クラスタ・レプリケーション環境の詳細に進む前に、その他の一般的なトポロジを紹介します。



5


トポロジのコンポーネントおよび用語

ロード・バランサ

ロード・バランサを使用して、OHS サーバーのいずれかにクライアント・リクエストを指示します。通常、これは HTTP ベースの状態監視とともに構成されて、サーバー・リクエストに使用できる OHS サーバーが決定されます。

Oracle HTTP Server（OHS）

OHS サーバーは、HTTP リクエストを受け入れて、OPMN トポロジの使用可能なOC4J サーバーのいずれかにサーブレット・リクエストを転送します。

Oracle Containers for Java（OC4J）

OC4J サーバーは、OHS サーバーのいずれかからリクエストを受け入れて処理し、その結果を OHS に返します。

OC4J のインストールによって、1 つ以上の OC4J インスタンスが実行されている場合があります。単一のインスタンスには、1 つ以上の JVM が含まれます。ほとんどの場合（コロケーション・テストを除く）、単一の OC4J インスタンスに 1つの JVM で実行しました。

OPMN ベースのトポロジ

すべての OHS サーバーと OC4J サーバーは、マルチキャスト OPMN トポロジで構成されます。各 OHS サーバーは、上の図の OC4J サーバーにルーティングできます。トポロジのメンバーシップは動的です。OC4J サーバーが停止すると、OHSルーティング表から削除されます。また、opmn.xml ファイルの OPMN パラメータを構成して、OC4J サーバーを追加できます。



6


レプリケーション・クラスタ

レプリケーション・クラスタは、OPMN トポロジに直交する OC4J クラスタリング・メカニズムです。J2EE アプリケーション用の Oracle Application Server 10g Release 3 の状態レプリケーションをアプリケーション・レベルとコンテナ・レベルで使用できます。これによって、レプリケーション・スコープを細分化して制

御できます。通常、OC4J セッション・レプリケーション・クラスタと OPMN トポロジは、以下の点を除いて区別されています。1.

1. レプリケーション・クラスタは、OPMN トポロジのサブセットになることができます。

2. レプリケーション・クラスタの検出メカニズムとして、OPMN トポロジをオプションで使用できます。

リクエストの動的ルーティングと動的トポロジ・メンバーシップに OPMN 構成が使用されます。セッション状態の伝播にレプリケーション・クラスタが使用され

ます。これらの 2 つのグループ（OPMN トポロジとレプリケーション・クラスタ）は、2 つの異なる通信チャネルを使用します。

レプリケーション構成オプション

セッション状態をレプリケートする最初の選択を行った後も、レプリケーション

の実行方法と実行環境に関するさまざまなオプションがあります。ここでは、基

本的なレプリケーション・トポロジと構成オプションの一部を説明します。

マルチキャストと Peer-to-Peer の比較

レプリケーションを構成する場合、3 つの異なるネットワーク構成オプション（マルチキャスト、動的 Peer-to-Peer、静的 Peer-to-Peer）があります。これらの 3 つのオプションの違いは、以下のとおりです。

マルチキャスト - レプリケーションに IP マルチキャストを使用します。レプリケートされた各ホストは、同じマルチキャスト・アドレスで構成されます。すべ

てのホストは、同じレプリケーション・クラスタの一部になります。

静的 Peer-to-Peer - 各ホストは、他方のピアの IP アドレスで構成されます。すべてのホストを接続する一連のピアが存在する限り、レプリケーション・クラスタ

が確立されます。検出とレプリケーションの両方にこのユニキャスト通信が使用

されます。

動的 Peer-to-Peer - この構成のピアは、OPMN トポロジで検出されます。この構成は検出のみに使用されます。検出段階の後、レプリケーション Peer-to-Peer クラスタは、上述の静的 Peer-to-Peer 構成と同じ方法でレプリケーションを管理します。

レプリケーション・クラスタリング・メカニズムの選択にはトレードオフがあり

ます。10.1.3 で導入された Peer-to-Peer クラスタリングによって、JVM 間の通信のUDP ベースのマルチキャストを介した信頼性が向上しました。このホワイト・ペーパーの推奨事項は、Peer-to-Peer 環境に適用されます。



7


スタンドアロンの OC4J のインストールで唯一使用できる Peer-to-Peer は、静的オプションです。また、Oracle AS インスタンスのインストールのように OPMN を使用できる場合、構成および保守が容易な動的 Peer-to-Peer クラスタのオプションが推奨されています。

静的 Peer-to-Peer だけが使用可能な場合、ノードが使用できなくても完全なクラスタを維持できるようにリング・モデルでノードを構成する必要があります。たと

えば、4 つの OC4J ノードの構成（A、B、C、D）の場合、A のピアとして B、Bのピアとして C、C のピアとして D、D のピアとして A を構成する必要があります。

分散 JVM と同じ場所に配置されている JVM の比較

レプリケーションは、同じマシンの別の JVM または別のノードのリモート JVMのいずれかで発生する可能性があります。ブール・パラメータの allow-colocationを設定して、ローカル・レプリケーションの有効化/無効化を設定できます。ローカル JVM にレプリケートする長所と短所を以下に示します。

応答時間

ローカル・レプリケーション・リクエストとネットワーク上のリクエストの作成

は、ネットワーク速度によってミリ秒単位で変わる可能性があります。ほとんど

の場合、これはアプリケーションにとって余分なオーバーヘッドになります。

デフォルトの非同期レプリケーションの場合、テストでは、レプリケート状態が

増加しても、リクエスト時間の余分な待機時間は変わらなかったことが示されて

います。つまり、非同期モデルでは、実際の状態の転送ではなくリモート・レプ

リケーション JVM との通信で余分な遅延が発生しています。

可用性

レプリケーションは、障害に対する高い可用性と保護を提供します。同じマシン

の JVM ではアプリケーションまたは JVM の障害から保護しますが、JVM がローカルでのみレプリケートされる場合は全体のノードの障害から保護されません。

システム・リソース

別の JVM へのレプリケーションを有効にすると、メモリー・リソース要件が事実上 2 倍になります。各 JVM は、レプリケートするセッション状態を送信する他のJVM のセッション状態とともに固有のセッション状態を保存します。両方の JVMが同じマシンに存在する場合、新しい JVM 用のメモリーを追加できないことがあります。

また、リモート JVM がネットワーク帯域幅の要件に追加されます。ネットワークですべての状態を転送する必要があるため、レプリケート状態が直線的に増加し

ます。パフォーマンスのレプリケーション・ネットワーク・トラフィックの影響

は、ネットワーク帯域幅が飽和しないという注意事項とともに上述の"応答時間"の項に示されています。



8


レプリケーション・ターゲットまたはレプリケーション割当て制限の数

レプリケートする他の JVM の数は、デフォルト値 1 の write-quota パラメータによって制御されます。このパラメータに最適な値を設定するには、以下の点を考

慮する必要があります。

応答時間

非同期レプリケーション・モードの状態がリモート JVM に送信されますが、確認応答を待つ必要はありません。この場合、複数のリモート JVM に状態を送信しても、レプリケーション・リクエストの応答時間が大幅に増えることはありません。

write-quota の設定 1 と 2 を比較しても、応答時間に明らかな違いは検出されませんでした。セッション状態が非同期に送信されるので、外部 JVM に迅速にセッション状態を送信できます。

同期レプリケーションの場合、アプリケーションは、レプリケート状態を受信す

るすべてのノードではなく、少なくとも 1 つのノードからの確認応答を待機します。このため、多くのレプリケーション・ターゲットを追加しても、全体の応答

時間は増加しません。

これは、十分なシステム・リソースを前提としています。このケースの詳細は、

後述の'システム・リソース'の項に記載されています。

可用性

レプリケーション・ターゲットが増加すると、システムの可用性が向上します。

元の JVM で障害が発生しても、セッション状態を保持している他の複数の JVMがあります。一方、これは収穫逓減を発生させる可能性もあります。write-quotaを 1 に設定し、別のノードの JVM でレプリケーションが発生している場合、すべてのセッション状態が失われると 2 つの個別のノード障害が発生します。

これは珍しい事例で、write-quota を 1 に設定し、ターゲットとしてリモート・ノードを設定すれば（allow_colocation=false）、ほとんどのケースに対応できます。


レプリケーション・リクエストは、ローカル JVM の状態がリモート・ノードに送信されるアウトバウンド・ネットワーク・トラフィックとリモート状態をローカ

ルで受信するインバウンド・トラフィックの両方を生成します。全体のトラフィッ

クの量は、レプリケーションに含まれるノードの数とレプリケートされる状態の

量に比例します。

たとえば、特定の期間のインバウンド・トラフィックの量は、次のように計算で

きます。

I=Reqs*Wq*St

Ｉは全体のトラフィック、Reqs は特定の期間のアプリケーション・インスタンスごとのレプリケーション・リクエストの数、Wq は write-quota、St はレプリケートされたセッション状態の平均サイズです。つまり、多くのレプリケート状態を含

むビジー状態のシステムの場合、write-quota の値を 1 から 2 に増やすとトラフィックが 2 倍になり、許容範囲が変更される可能性があります。



9


同様に、2 倍のセッション状態を管理する JVM は、ガベージ・コレクション・アクティビティの増加などによって、メモリー要件とメモリー管理オーバーヘッド

が増加する可能性があります。

リソースが制約されない限り、このような考慮事項をシステムに適用しないでく

ださい。

非同期レプリケーションと同期レプリケーション

デフォルトのレプリケーション・モードは非同期です。非同期と同期の違いは、

データの送信後にアプリケーションが少なくとも 1 つのレプリケーション・ターゲットからの確認応答を待機するかどうかです。非同期の場合、アプリケーショ

ンは、データの送信とともにアプリケーション処理を継続します。

再度、この余分な確認応答の影響を要約します。

応答時間

確認応答の待機によって、全体の応答時間が増加します。この余分な時間は、少

量の状態が高速なネットワークを移動する場合には大きな影響はありません。小

規模で高速なサーブレットを使用したアプリケーションの場合、同期レプリケー

ションの余分なオーバーヘッドの影響（ミリ秒単位）によって、全体の応答時間

が 2 倍になることがあります。大規模で複雑なアプリケーションの場合は、確認応答を待つ余分な時間（ミリ秒）は無視できます。

可用性

同期レプリケーションの利点は、セッション状態が別のノードにレプリケートさ

れる前に障害が発生した場合のセッションの非一貫性から保護することです。

したがって、同期レプリケーションを有効にすると信頼性が向上しますが、わず

かな期間だけです。非同期レプリケーションおよび同期レプリケーションは、デー

タを受信できるリモート・ホストからの最初の確認応答まで待機します。このた

め、データの転送中で完全に受信していなくてもリモート・ホストが最初の確認

応答を作成した後、リモート・ホストを削除する必要があります。


同期レプリケーションの使用を選択する場合、システム・リソースに大きな影響

はありません。余分な待機時間がわずかにアプリケーションに追加されるだけな

ので、同期レプリケーションの CPU 時間が若干少なくなります。

ほとんどの場合、デフォルトの非同期レプリケーションを使用すれば十分な可用

性が実現します。同期レプリケーションを有効にすると、少しの可用性の期間が

発生しますがアプリケーションのパフォーマンスが低下します。トレードオフを

行うかどうかは、アプリケーション固有の決定になります。



10


レプリケートする場合

レプリケーション頻度に使用するデフォルト・パラメータは OnRequestEnd です。このパラメータは、リクエストの最後にレプリケーションが発生することを示し

ます。他のオプションは OnAttributeModify と OnShutdown です。OnShutdown オプションは、アプリケーションが停止している場合にのみレプリケートします。こ

のため、ほとんどの障害からは保護されません。

すべてのテストで OnRequestEnd オプションを使用しました。アプリケーションの観点からのセッション・レプリケーションの利点は、複数の独立したリクエスト

の状態を保持して保存できることです。頻繁にレプリケートするとパフォーマン

スに影響しますが、さらに重要な点は一貫性のあるデータまたは使用できるデー

タを作成できない場合があることです。これは、リクエスト中にデータが作成さ

れる一方でリクエストの開始時にデータを有効にする必要があるためです。

レプリケーション・テスト

次の項では、実行された実際のテスト、取得した結果、および推奨事項の根拠の

詳細について説明します。これらの項は、前の項と並行しています。

マルチキャストと Peer-to-Peer の比較

最初のテストでは、テスト用の Peer-to-Peer よりも信頼性が劣るマルチキャスト通信のばらつきが示されました。つまり、一連のレプリケーション・リクエストの

待機時間の分散が調査対象の他の変数に影響を与えました。このため、最初のい

くつかのテスト以外では、Peer-to-Peer レプリケーションを使用した追加のテストを実行しました。

分散 JVM と同じ場所に配置されている JVM の比較

同じ場所に配置されている JVM を使用したテストには、相互にレプリケートするように構成された全体で 2 つの JVM を使用しました。これには、次の構成を使用しました。

1) 各インスタンスに 1 つの JVM を使用した、同じマシン上の 2 つのインスタンス

2) 同一の 2 つの JVM で構成された単一のインスタンス

3) それぞれ固有のマシンで 1 つの JVM を使用した 2 つのインスタンス

2 つの JVM が同じマシンを共有する直接的な影響は、この特定のマシンのリソースが飽和する可能性が高くなることです。これは、各 JVM に割り当てられたメモリーが同じであることを前提とします。

可用性について、構成 2)は JVM レベルでの保護を提供しますが、OracleAS インスタンスおよびノードの障害からは保護しません。一方、OracleAS によって、この構成の管理が非常に簡単になります（自動ポート割当てがインスタンスによっ

て異なる JVM に実行されます）。また、この構成によって、ノード内の非常に動的な垂直スケーラビリティが提供されます。構成 1)はインスタンスの障害から保護しますが、マシン/ネットワークの障害からは保護しません。



11


同じマシンで 2 つの JVM を使用している場合に CPU 要件が予想通り 2 倍になることが確認されました。個別のインスタンスに JVM を配置するには、追加のリソースがわずかに必要になります。制約のあるシステムでは、これによってパ

フォーマンスに大きな悪影響を与えることが予想されます。

制約のないシステムの場合はどうでしょうか。その場合、ローカル・レプリケー

ションとネットワーク上のレプリケーションの違いを考慮します。

以下の図は、2 つの異なる構成のミリ秒単位の応答時間を示しています。両方とも、対象のすべてのマシンに十分なメモリーと CPU が装備されています。一方は2 つの JVM がローカルで相互にレプリケートします。もう一方は JVM が高速のネットワークでレプリケートします。

図の水平軸は、レプリケート状態の量の増加による影響を示しています。両方の構

成は、応答時間の増加を示しています。これは、テスト・サーブレットで多くの状

態を処理するために必要な作業量が多いことも一因となっています。レプリケート

状態の量が多くなっても、サーブレットで必要な余分な時間は増加しません。

重要な点として、これらのテストは十分なネットワーク帯域幅のシステムで実行

されました。使用される帯域幅の量は、レプリケート状態の量とともに直線的に

増加します（レプリケーション・ターゲットの概算については、前の項を参照）。

このため、ネットワークが飽和した場合に確実にパフォーマンスに影響します。

セッションのサイズと数が約 5 倍の構成の応答時間がわずかに 2 倍にしかならないことに注意してください。これは、このようなトポロジのレプリケーション・

フレームワークに対応した適切なワークロードを示しています。

レプリケーション・ターゲットの割当て制限または数

テストでは、ネットワーク帯域幅への潜在的な影響以外に複数のターゲットにレ

プリケートする場合の明らかに余分なオーバーヘッドは検出されませんでした。

十分なリソースのシステムでテストが行われましたが、以下の図のように明白な

違いは確認されませんでした。



12


上の図のテストは、すべてレプリケーションで構成された 4 つの異なる JVM の環境で実行されました。一方は、それぞれ write-quota が 1 の構成で、状態を他の 1つの JVM にレプリケートします。もう一方は、write-quota が 2 の設定で、各 JVMが他の 2 つの JVM にレプリケートされます。

全体のレプリケート状態サイズの範囲で応答時間も測定されました。上の図に示

されているように、応答時間は通常のばらつきの範囲内で、2 つの構成はテスト・サーブレットの全体の応答時間に影響を与えませんでした。これはレプリケー

ションが異なるメンバーと並行して発生するためです。したがって、パフォーマ

ンスに大きな影響を与えることなく、割当て制限を増やしてレプリケーション・

クラスタの信頼性を向上できます。

非同期レプリケーションと同期レプリケーション

非同期レプリケーションと同期レプリケーションの違いは、処理前に少なくとも

他の 1 つの JVM がすべてのデータを受信したことの確認応答のために元の JVMが待機するかどうかです。これは write-quota を増やしても問題ない理由の説明になります。この場合、同期レプリケーションだけがデータを受信する最初の JVMから確認応答を待機します。

ただし、余分な確認応答の待機時間によって、アプリケーションの応答時間が増

加します。余分な待機時間は、アプリケーションによって異なります。以下の図

で、全体のレプリケート状態に対応した応答時間を示します。



13


同期レプリケーションを有効にすると、上の図のように全体の応答時間が増加し

ます。ただし、これはリクエストごとにミリ秒程度です。レプリケーション以外

の処理はほとんど行わないこのテスト・サーブレットの場合、応答時間が事実上

2 倍になります。

レプリケートされるセッション状態のサイズが増加すると、余分な時間が増えま

す。通常、システムのパフォーマンスの同期モードの影響の主な要因は、レプリ

ケーション・トリガーです（つまり、アプリケーションでセッションがレプリケー

トされる回数およびこの情報をアプリケーションが処理する時間に依存します）。

確認応答が頻繁に発生して待機時間が増加すると、影響が大きくなる可能性があ

ります。

スケーラビリティの推奨事項

適切なレプリケーション・トポロジの作成に関するベスト・プラクティスは、あ

る程度までアプリケーションに依存します。上述の参照トポロジを使用すると、

レプリケーションの有効化の影響、レプリケーション・トポロジをスケール・ア

ウトする推奨事項、および可用性のメモに関する監視結果を取得できます。

レプリケーション・コスト

以下の図は、レプリケーションを有効/無効にした小規模なテスト・アプリケーションの応答時間を比較しています。



14


上の図は、小規模なサーブレットで測定された応答時間を示しています。ここで

は、write-quota が 1 でピア・ベースのレプリケーションのデフォルトの非同期レプリケーションを使用しました。

応答時間は、システムが安定した後に十分な期間を確保して 5 つの同時クライアントの平均を測定したものです。水平軸は、レプリケート状態の量を示していま

す。パフォーマンスへの影響が大きくなりデータ損失量が常に増加するので、

100kbs を超えるセッション・サイズを使用しないことを推奨します。

また、これは、メモリー、CPU、および帯域幅の観点から十分なリソースのシステムを示しています。非同期レプリケーションで追加された余分な時間は、処理

時間です。

セッション状態が増えるとレプリケーションの余分なコストが増加しますが、特

に状態の量が少ない場合の処理時間の平均的な増加は、リクエストごとにミリ秒

程度です。

レプリケーション・ペアの対応

アプリケーションのスケール・アップには、繰り返し実行可能で直接的な制限が

ない方法で負荷を処理するリソースの追加が含まれます。

write-quota が 1 の場合、各 JVM が他の 1 つの JVM にレプリケートするのみです。つまり、レプリケーション・ペア（相互にレプリケートする JVM のペア）の概念を示しています。

このホワイト・ペーパーの参照トポロジでは、相互にレプリケートする OC4J1 とOC4J2 を使用しています。継続してペアで JVM を追加できます。たとえば、OC4J3と OC4J4 を追加すると、相互にレプリケートする新しいペアが作成されます。



15


以下の図は、レプリケートする 2 つの JVM のトポロジと 4 つの JVM のトポロジのシステムの応答時間を示しています。

制約のないシステムでは、リソースを追加してもアプリケーションの応答時間が

同じになります。応答時間が減少する場合は、システムが制約されています。応

答時間が増加する場合は、リソースの追加によってオーバーヘッドが発生してい

る可能性があります。

フェイルオーバー計画

セッション・レプリケーションの最大の利点は、停止に対する保護です。停止は、

プロセス障害、ハードウェア障害、またはネットワーク障害という形で発生します。

ここでは、発生する可能性のある停止とそれぞれのケースの状態でレプリケー

ションが失敗する理由について説明します。

JVM 障害

JVM がクラッシュした場合または JVM を使用できない場合、OPMN トポロジから削除され、レプリケーション・クラスタからも削除されます。存続する JVM は、新しいレプリケーションを検出するために再構成されます。

新しいレプリケーション・パートナの検出はベスト・エフォートです。つまり、

write-quota が 2 に設定されていて他の 1 つの JVM だけが存続している場合、レプリケーションは 1 つの宛先にのみ発生します。同様に、最後の JVM だけが存在している場合、レプリケーションの宛先がなくても継続して動作してデータを処理

します。つまり、システムは継続して動作し、指定された数のレプリケーション・

パートナを処理するために停止または待機しません。

以前使用できなかった JVM をクラスタに再接続する場合、クラスタを再構成して、可能であれば要求された数のレプリケーションの宛先を有効にします。このモデ

ル（1 つのノードに 1 つの JVM）は、他のメンバーを使用できなくなった場合に割当て制限を満たすためにレプリケーションを発生させるレプリケーション・マ

スターとして機能します。レプリケーションの割当て制限を満たすには、ユー

ザー・リクエストでセッションのレプリカをアクティブにする（つまり、このノー

ドで少なくとも 1 回はアクセスする）必要があります。



16


OC4J ノード障害

OC4J プロセスではなく全体のマシンの障害は、JVM プロセスの障害に似ています。どちらも、上述のように存続するノードが再構成されます。

ただし、ノード障害の場合、レプリケーション・クラスタからノードを除外する

前に長い待機時間があります。この場合、除外されたノードと存続するノードの

オープンな接続の TCP タイムアウトの待機時間です。

OHS 障害

OHS はシステムのエントリ・ポイントなので、クライアントはプロセスまたはノードの障害を直接検出します。このホワイト・ペーパーの参照アーキテクチャでは、

2 つの OHS ノードを使用しています。一方が使用できる場合、存続している OHSノードは使用できないノードと同じルーティングを実行できます。

他のスケーラビリティの考慮事項

高負荷なシナリオ

以下の図は、システムの負荷を増やした場合の応答時間を示しています。レプリ

ケーションを有効にした場合と無効にした場合を比較しています。

水平軸は、同時ユーザーの数を表しています。それぞれ小規模（1k）なセッション・リクエストを作成しています。垂直軸は、ミリ秒単位の応答時間です。



17


同時ユーザーが 200 を超えるとシステムの過負荷によってシステムが不規則になるように見えますが、レプリケーションは関係なくアプリケーションの応答時間

に大きな違いはありません。同様に、高負荷の状態におけるレプリケーションを

有効にしたシステムの応答は、スケーラビリティの問題を示していません。これ

は、OracleAS 10g Release 3 レプリケーション・フレームワークの高いスケーラビリティを実証しています。

大きいセッション・サイズ

大きなサイズのセッション状態でレプリケーションを測定するとどうなるでしょ

うか。

上の図は、セッション・サイズに対応した応答時間を示しています。状態のサイ

ズが約 100k を超えると、オーバーヘッドが固定されずに状態のサイズに比例して応答時間が増加します。この時点でネットワーク帯域幅が頻繁に使用されていま

すが、直線的な増加のように示されています。数百キロバイトのセッションの増

加によって瞬時に応答時間が増加します。セッション・レプリケーションを有効

にしたシステムとレプリケーションを使用しないシステムには、数秒の違いがあ

ります。

結論

J2EE 状態レプリケーションを有効にした場合のコストをここで説明します。テストと監視結果によって、パフォーマンスへの影響と必要なシステム・リソースの

観点から非同期レプリケーションを有効にした場合の追加コストは最小限に抑え

られることがわかります。このため、レプリケーション・システム全体の非常に

高いスケーラビリティが実現します。アプリケーションの高い可用性によって、

関連するアプリケーションの余分なオーバーヘッドが正当化されます。

ほとんどの場合に推奨されるパラメータは、以下のとおりです。

非同期レプリケーション - 同期レプリケーションは非同期よりも高い一貫性を保証しますが、収穫逓減につながる可能性があります。



18


分散 JVM - 異なる物理マシンの JVM だけをネットワークまたはマシンの障害から保護できます。システムに必要なスケーラビリティ・モデル（水平および垂直）

によって、本書に記載されているトレードオフでいずれかが許容される場合があ

ります。

単一のレプリケーション・ターゲット - 複数のレプリケーション・ターゲットによって大きなオーバーヘッドを発生させずに優れた保護を実現できます。ほとん

どの場合、単一のレプリケーション・ターゲットで十分です。

ピア・レプリケーション - ピア・レプリケーションによって、レプリケーション・トポロジを設定するための優れた制御を実現できます。動的な OPMN ベースの検出とともに、これも管理可能なソリューションです。



19


付録 A：構成の詳細

ハードウェア構成

[注：特に記載がない限り、ドライバとアプリケーション・サーバーは同一です]

• HP Integrity rx2620 サーバー

o 2x1.6GHz のシングル・コア・プロセッサ

o 12GB の RAM

• 2x146GB の内部ディスク・ドライブ

• HP-UX 11iV2 オペレーティング・システム・ソフトウェア

o パッチ・バンドル：2006 年 3 月版の Quality Pack、2006 年 6 月版の HW Enablement

o Java 1.5.0.03

• ネットワーク

o MP（Maintenance Port）100TX

o パブリック 1GB

o プライベート 1GB（レプリケーション以外のすべての通信用の専用アプリケーション層ロード・バランサ・ネットワーク）

o プライベート 1GB（アプリケーション層の専用レプリケーション・ネットワーク）

HPUX 構成

ほとんどのテストのすべてのサーバーに HPUX 11v2 が使用されました。この調査の後半で、アプリケーション・サーバーの 1つをHPUX 11v3にアップグレードし、いくつかのベースライン・テストを再実行しました。結果として、11iV2 と 11iV3のパフォーマンスに違いがないことが示されました。11iV2 のパッチ要件は、以下のとおりです。11iV3 用の追加パッチは必要ありませんでした。11iV2 と 11iV3で同一のカーネル・パラメータも記載されています。

HPUX 11iV2 パッチ PHCO_34944 pthread ライブラリ累積パッチ PHKL_34032 ksleep 累積パッチ PHSS_34444 アセンブラ・パッチ PHSS_34445 milli 累積パッチ PHSS_34853 数学ライブラリ累積パッチ PHSS_34858 リンカーおよび fdp 累積パッチ PHSS_34859 Integrity アンワインド・ライブラリ PHSS_35045 Aries 累積パッチ │ PHSS_35055 aC++ランタイム（IA：A.06.10、PA：A.03.71）



20


HPUX カーネル・パラメータ

パラメータ名値

cmc_plat_poll 15

create_fastlinks 1

dbc_max_pct 8

dbc_min_pct 8

default_disk_ir 1

fs_async 1

hfs_max_ra_blocks 20

hfs_max_revra_blocks 20

hfs_revra_per_disk 256

max_async_ports 768

max_thread_proc 2048

maxdsiz 4294963200

maxfiles 32768

maxfiles_lim 32768

maxssiz 401604608

maxtsiz 1073741824

maxuprc 3277

maxvgs 80

msgmap 5122

msgmax 32768

msgmnb 65536

msgseg 20480

msgssz 128

msgtql 5120

nfile 65536

ninode 8192

nkthread 16384

nproc 8192

npty 200

nstrpty 200

nswapdev 25

o_sync_is_o_dsync 1

scsi_max_qdepth 8

semmni 4096

semmns 8192

semmnu 4092

semume 512

shmmax 2000000000

shmmni 520

shmseg 512

STRMSGSZ 65535

swapmem_on 1



21


swchunk 8192

tcphashsz 32768

vps_ceiling 64



22


付録 C：実際のテスト環境の図



23


付録 D：JVM 構成

すべてのテストに HP Java 1.5 が使用されました。ただし、2 つの異なるパッチ・リリースが使用されました。Oracle AS 10.1.3.x とともに出荷されたバージョン（Java バージョン"1.5.0.03"）を使用して、ほとんどのテストが実行されました。

ただし、HP Java の最新のバージョン（Java バージョン"1.5.0.08"）を使用して、一連のベースライン・テストが実行されました。新しいバージョンを使用したテス

トでも、同様のパフォーマンスの特性を示しました。

JVM バージョンを変更する以外に、JVM パラメータも変更しました。ほとんどの場合に次のパラメータを使用して実行しました。

-server -Xmx3000m -Xms3000m -Xmn2000m -XX:PermSize=48m -Xverbosegc:file=/tmp/gcfile -Djava.security.policy=$ORACLE_HOME/j2ee/project/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false

また、SpecJAppServer2004 ベンチマーク（以下の URL を参照）で使用されたすべてのパフォーマンス関連パラメータによるテストも実行しました。

http://www.spec.org/osg/jAppServer2004/results/res2007q1/jAppServer2004-20070130-00054.html

すべての実行に対して十分なシステム・リソースが提供されていたため、このよ

うな追加パラメータがパフォーマンスの向上につながりませんでした。

JVM ガベージ・コレクションなどのメモリー管理の問題が発生しないように、十分なメモリーが用意されました。リソースが制約されている環境のチューニング

は、今回のテストの目的ではありません。



24

http://www.spec.org/osg/jAppServer2004/results/res2007q1/jAppServer2004-20070130-00054.htmlhttp://www.spec.org/osg/jAppServer2004/results/res2007q1/jAppServer2004-20070130-00054.html


付録 C：クライアント、サーブレット、および JVM の構成

テスト環境に使用されるサーブレットには、3 つの機能が用意されました。

1) 作成状態

2) プロセス状態

3) 破棄状態

サーブレットの通常の呼び出しは、以下の形式です。

http://host:port/Session/Session?mode=initialize&number=2&size=5

この例では、それぞれサイズが 5k の 2 つのセッション・オブジェクトが作成されます。プロセス機能がすべてのセッション・オブジェクトをループして、それぞ

れの値を変更します。最後の機能は、すべてのセッション・オブジェクトを解放

します。

コーリング・クライアントは、Apacheの Jmeterによってエミュレートされました。通常は、状態を破棄する前に 4 回処理する、上述の機能をそれぞれ実装している5 個のスレッドが実行されました。思考時間はありませんでした。スレッドごとに 10k から 20k で実行されている間に Jmeter .jtl ファイルから報告された出力値を平均して、このホワイト・ペーパーに記載されている測定された応答時間を収集

しました。平均の結果は、初期化の問題を訂正して安定した状態値を取得するた

めに、実行の最初の 20%の破棄後に計算した平均値です。

これらの実行で使用された JVM パラメータは、以下のとおりです。

-server -Xmx3000m -Xms3000m -Xmn2000m -XX:PermSize=48m -Xverbosegc:file=/tmp/gcfile -Djava.security.policy=$ORACLE_HOME/j2ee/project/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false

このテストの目的ではないので JVM ガベージ・コレクションなどのメモリー管理の問題が発生しないように、十分なメモリーが用意されました。gc 出力ファイルを使用して、これを検証しました。



25

http://host:port/Session/Session?mode=initialize&number=2&size=5


2007 年10月

著者：Richard Delval 共著者：Pradeep Bhat、Fermin Castro、Bill Cortright

Oracle Corporation World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065 U.S.A.

海外からのお問合せ窓口：電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

www.oracle.com

Copyright © 2005, Oracle. All rights reserved. 本文書は情報提供のみを目的として作成されたものであり、その内容は予告なく変更されること

があります。

本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や

法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保証および条件など

のいかなる保証および条件も提供するものではありません。オラクル社は本文書に関するいかな

る法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないも

のとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のた

めにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはでき

ません。

Oracle、JD Edwards、およびPeopleSoftは、米国Oracle Corporation およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

はじめに参照レプリケーション・トポロジトポロジのコンポーネントおよび用語ロード・バランサOracle HTTP Server（OHS）Oracle Containers for Java（OC4J）OPMNベースのトポロジレプリケーション・クラスタ

レプリケーション構成オプションマルチキャストとPeer-to-Peerの比較分散JVMと同じ場所に配置されているJVMの比較応答時間可用性システム・リソース

レプリケーション・ターゲットまたはレプリケーション割当て制限の数応答時間可用性システム・リソース

非同期レプリケーションと同期レプリケーション応答時間可用性システム・リソース

レプリケートする場合

レプリケーション・テストマルチキャストとPeer-to-Peerの比較分散JVMと同じ場所に配置されているJVMの比較レプリケーション・ターゲットの割当て制限または数非同期レプリケーションと同期レプリケーション

スケーラビリティの推奨事項レプリケーション・コストレプリケーション・ペアの対応フェイルオーバー計画JVM障害OC4Jノード障害OHS障害

他のスケーラビリティの考慮事項高負荷なシナリオ大きいセッション・サイズ

結論付録A：構成の詳細ハードウェア構成HPUX構成

付録C：実際のテスト環境の図付録D：JVM構成付録C：クライアント、サーブレット、およびJVMの構成

oracle j2ee 状態レプリケーションの ガイドラインとベスト ......maximum...

Documents

oracle j2ee 状態レプリケーションのガイドラインとベスト ......maximum...