Oracle ホワイト・ペーパー 2010 年 9 月

Oracle WebLogic Suiteの最適化ソリューション：最適なインメモリ・データ・グリッド・アーキテクチャ

はじめに ........................................................................................................................... 1 アーキテクチャ設計の選択肢 .......................................................................................... 2 アーキテクチャの概要 ....................................................................................................................... 4 コンピューティング・ノード .......................................................................................................... 4 インターコネクト ................................................................................................................................ 6 クライアントと最初のスイッチング層 ........................................................................................ 8 WebLogic Server クラスタ層 .......................................................................................................... 9 Coherence スイッチング・レイヤー ........................................................................................ 10 Coherence 層 ..................................................................................................................................... 11 データベース層 .................................................................................................................................. 12

Coherenceのベンチマーク・テスト ............................................................................. 13 ワークロードの概要 - ホテル客室検索予約オンライン・システム ............................. 13 マイクロベンチマーク：Coherence の単純なオブジェクトのベンチマーク ............ 14 Coherence のホテル・オブジェクト ........................................................................................ 16 ベンチマーク：完全な構成のホテル・アプリケーション ................................................. 17 ホテル・アプリケーションのテスト結果 ................................................................................ 19

結論 ................................................................................................................................. 23 追加情報 ......................................................................................................................... 24 著者について ...................................................................................................................................... 26

はじめに

Oracle WebLogic Suiteは、既存のアプリケーションおよびサービス・デリバリ・インフラストラ

クチャを統合する機能を使用して、インメモリ・データ・グリッドを作成する手段を提供します。

アプリケーション・サーバーとしてのOracle WebLogic Serverとデータ・グリッドとして実行す

るOracle CoherenceとをOracle TopLinkなどの接続テクノロジーを（Java® Persistence

Architecture：JPAとして）使用して組み合わせたものを、まとめてOracle ActiveCacheと呼んで

います。このプラットフォームは、さまざまなソースから着信するデータの流れをサポートし円

滑にする役割を果たす多数のメタサービスを提供する、インメモリ・データ・グリッドを提供し

ます。ActiveCacheには、データを動的に自動分割する機能、アプリケーションとデータソースと

の間を流れる情報の特性に基づいてデータの管理を最適化する機能、データをアプリケーション

の近くに移動することで遅延を減らしてパフォーマンスを向上させる機能があり、共有データ・

リソースの容量を増加させる簡単な手段を提供します。ActiveCacheのこれらの機能は、Webを

使用するアプリケーションのパフォーマンスの最大化に効果があり、多くのワークロードで線形

に近いスケーラビリティの実現を後押しします。また、データベース・サーバーやストレージ・

システムなどのバックエンドのリソースの負荷を軽減するのにも役立ちます。

ActiveCache/Coherenceの機能に関する詳しい情報は、Oracle Technology Networkサイト

（http://www.oracle.com/technology/products/coherence/index.html）を参照してください。

ActiveCache で構築したデータ・グリッドのメリットを最大化する鍵は、モジュール化されたバ

ランスの良いアーキテクチャを作成することです。アプリケーション・サーバー数、メモリ容量

および処理ノード数をターゲット・ワークロードの特性に合わせることが、最高のパフォーマン

スを引き出すうえで重要です。

このテクニカル・ホワイト・ペーパーでは、Oracle Fusion Middleware コンポーネント、おもに

WebLogic Suite を利用するオラクルの Sun サーバー上に Coherence を実装して実行する方法に

ついて説明します。本書には、Web を使用するアーキテクチャのスケーラビリティとパフォーマ

ンスを裏付けるベンチマーク・テスト結果を掲載しています。ベンチマーク構成の実装およびテ

スト中に得られたベスト・プラクティスも掲載しています。本書に記載されている事前テスト済

みのアーキテクチャ、ベスト・プラクティス、パフォーマンス結果を活用すれば、デプロイメン

トに要する期間を短縮し、類似したワークロードまたは適応可能なワークロードのプロビジョニ

ング・コストと実装コストを削減することができます。

アーキテクチャ設計の選択肢

ActiveCache を使用する場合としない場合のアプリケーション・データの流れの違いについての理解を深めるうえで重要なのは、ActiveCache を使用する場合は基本的に、従来のWeb サービス・アーキテクチャに新しい層が追加されるという点を念頭におくことです。ActiveCache を使用しないアーキテクチャでは、ユーザーエクスペリエンスが、アプリケーション・サーバー上に存在する複雑なアプリケーション・プログラム、またはデータベース内の複雑なストアド・プロシージャによって記述されることがあります。この新しい層の中では、ActiveCache がそのようなプロシージャの標準化と分離を支援し、要求元のクライアントからデータを要求されたときは、重要なデータにすばやく確実にアクセスするための"メタ"問題に対処します。以降の各項では、モジュール化されバランスがとれた事前テスト済みの、ActiveCache のデプロイメントに最適化したアーキテクチャについて説明します。このアーキテクチャの図を図 1に示します。

図 1 最適化された Coherence のアーキテクチャ

アーキテクチャの概要

ActiveCache のデプロイメントに最適化したアーキテクチャは、オラクルのエンジニアが構築してテストしたもので、次の 4つの基本レイヤーで構成されます。

クライアント層 - オラクルのSun Fireラックマウント・サーバーとオラクルのSun Bladeサーバー・モジュールの組み合わせで構成される合計 40のシステムがクライアント層に存在し、FABANロードジェネレータを使用して相当量のワークロードを生成します。オープンソースで拡張可能なFABANロードジェネレータの詳細は、http://faban.sunsource.netを参照してください。

Oracle WebLogic Server クラスタ層 - Sun Blade T6340 サーバー・モジュール 10基を搭載したオラクルの Sun Blade 6000 モジュラー・システムと Sun Blade 6000 Ethernet Switched NEM 24p 10GbEで WebLogic Server クラスタ層をサポートします。各ノードはアプリケーション・サーバーとして機能します。各 Sun Blade T6340 サーバー・モジュールは 8コアの 1.2GHz UltraSPARC® T2 Plus プロセッサ 2基とメモリ 64GB を搭載しています。

Oracle Coherence（Grid Edition）層 - 10 基のSun Blade X6270 サーバー・モジュールを搭載したオラクルのSun Blade 6000 モジュラー・システムとSun Blade 6000 Ethernet Switched NEM 24p 10GbEが、Coherence層にコンピューティング処理能力を提供します。各ノードは 3.2GHzのクアッドコアX6270 x86 プロセッサ 2基、48GBのメモリを搭載し、Java™ Virtual Machine1を実行して、そこでCoherenceを実行します。

データベース層 - Oracle Database 11g をホストするのは、合計 32GB のメモリと 4 基の 2.4GHz SPARC64® VII クアッドコア・プロセッサを搭載した Sun SPARC Enterprise M5000 サーバーで、このサーバーは 4つの SAS 接続を介して Sun Storage 6000 クラスのストレージ・アレイに接続されています。

個々の層についてと、それらの層に含まれるコンポーネントについては、以降の各項で説明します。テストに使用したすべてのサーバーで実行されていたのはOracle Solaris 10 オペレーティング・システムです。WebLogic Suite は Solaris またはOracle Enterprise Linux のいずれかの上で実行します。

コンピューティング・ノード

このテクニカル・ホワイト・ペーパーでは、特定の組織のニーズに合わせて拡張や変更が可能なWebLogic Suite のサンプル実装を提供することを目的に説明しています。WebLogic Server 層および ActiveCache 層の各層では、複数のサーバーを緊密に統合しやすくするために Sun Blade 6000 モジュラー・システムを使用しています。Sun Blade 6000 モジュラー・システムは複数の処理アーキテクチャに対応しているため、この方法をとれば、設計者は目前のジョブに最適な設計になるように、必要に応じて設計を柔軟に調整できます。単一のプラットフォーム・テクノロジーで両方の層を管理できるため、Sun Blade 6000 モジュラー・システムを活用することは、ソリューションの管理の単純化にもなります。

Sun Blade 6000 モジュラー・システムは 10ラック・ユニット（10U）のコンパクトなブレード・シャーシで、最大 10 基の Sun Blade 6000 サーバー・モジュール、最大 2.7Tb/秒の I/O スループット、ラック当たり最大 960 コア、ラック当たり最大 10.24TB のメモリをサポートします。シャーシの背面には、Sun Blade 6000 Network Express Module（NEM）用のスロット 2つと、PCI Express ExpressModule（EM）用のスロットが最大 20（サーバー・モジュール当たり 2つ）用意されています。個々の Sun

1 "Java Virtual Machine"および"JVM"とは、Java プラットフォーム用の仮想マシンのことです。

Blade 6000 モジュラー・システムには、さまざまな CPUアーキテクチャの Sun Blade 6000 サーバー・モジュールを任意の順序で搭載できます。搭載できる CPU アーキテクチャは、インテル® Xeon®プロセッサ、AMD Opteron™プロセッサ、チップ・マルチスレッド（CMT）テクノロジーが実装された Sun UltraSPARC T2 プロセッサまたは T2 Plus プロセッサなどです。多くのデプロイメントでは、Sun Blade 6000 モジュラー・システムのシャーシに異なるタスクを実行するサーバー・モジュールを混在させるのが一般的です。たとえば、Oracle T シリーズ・プロセッサはマルチスレッド・ワークロードの処理で性能を発揮するのに対して、x64 ベースのサーバー・モジュールはさまざまなワークロードに対応するパフォーマンスの高い汎用コンピューティング・プラットフォームです。

Sun Blade 6000 モジュラー・システムを使用するねらいは、ブレード・コンピューティング・プラットフォームがWebLogic Suite のデプロイメントに最適な選択肢の 1 つであることを示すためです。このアーキテクチャ内で Sun Blade 6000 モジュラー・システムを使用することで、本書に記載したベンチマーク結果から推測しサーバーモジュールを増減させて、ターゲットのパフォーマンス要件とワークロード要件に合わせることが可能です。ただし、既存のレガシー・サーバーを使用する必要があったり、構築済みのコンピューティング・インフラストラクチャやネットワーク・インフラストラクチャとの統合にからむ特定の問題があるなどして、従来のラックマウント・サーバーを使用することが必要になる場合もあります。Sunサーバー・プラットフォームに固有の特徴の 1つに、"ブレードとサーバーの等価関係"があります。ほとんどの場合、オラクルのラックマウント・サーバーの各モデルには、対応する Sun Blade 6000 サーバー・モジュールが存在します。複雑で頻繁に変更されるルールを使用しなければ従来のラックマウントとブレード・モジュールとを変換できない他のベンダー製品とは異なり、従来のOracle ラックマウント・サーバーはいずれも、対応するSun Bladeサーバー・モジュールとの間に機能上の相違点がほとんどありません。そのため、特定のデータセンター環境ではラックマウント・サーバーのほうが適している場合は、本書で紹介している結果を従来のラックマウント・サーバーに簡単に応用できます。しかしながら、Coherence のデプロイメントに Sun Blade 6000 モジュラー・システム・シャーシを使用することで、いくつかの大きなメリットが得られます。ラックマウント・サーバーを上回るおもなメリットは次のとおりです。

• Sun Blade モジュラー・システムを使用すると、ラックマウント・サーバーに比べて電力コストが最大 10%削減されます。

• 10 基すべてのサーバー・モジュールを 1台のシャーシで管理できるため、Sun Blade モジュラー・システムを使用すると、個別に 10台のサーバーを管理する必要がなくなります。

• さまざまな Sun Blade 6000 NEMおよび業界標準 PCIe ExpressModule（EM）を使用できるため、インターコネクト・テクノロジーのコストと接続方式の選択肢に関連する多大なメリットを得ることができます。

• タイミングや順序を気にせずに Sun Blade 6000 モジュラー・システム・シャーシ内に複数の種類のプロセッサ・テクノロジーを混在させたり組み合わせることができるため、実装の柔軟性が大幅に向上します。

• NEM フォーム・ファクタにより有効化される I/O 機能は、サーバー・モジュールに搭載済みの機能を拡張したものです。低コストのファブリック拡張モジュール（FEM）をサーバー・モジュールに取り付けて、サーバー・モジュールのマザーボードに搭載されているネイティブのネットワーク機能をNEMに拡張します。

• ベアメタル・ハードウェア・プロビジョニングからパッチ管理、自動ソフトウェア・ロード、仮想化テクノロジーとの統合まで、システムの管理はOracle Enterprise Manager Ops Centerを使用して実行されます。Oracle DatabaseおよびOracle Fusion Middlewareの管理に使用するのと同じソフトウェアを、物理ディスクそのものの管理にも使用します。システム管理からデータ管理までを統合する方法についての詳細は、Enterprise Manager Ops CenterのWebページ（http://www.Oracle.com/us/products/enterprise-manager/044497. html）を参照してください。

インターコネクト

クライアント層：サンプル・アーキテクチャでは、クライアントとアプリケーション・サーバーとの間の個々のイーサネット接続に、従来の 1ギガビット・イーサネット（1GbE）を使用しています。

サーバー層：各サーバー層の間ではインターコネクト・テクノロジーが重要な役割を果たします。特に、帯域幅が広く遅延が短いインターコネクトをWebLogic Server 層と Coherence 層との間で使用することが、最高のパフォーマンスを実現するのに不可欠です。このサンプル・アプリケーションでは、フル機能の統合型スイッチング・モジュール、Sun Blade 6000 Ethernet Switched NEM 24p 10GbE を使用しています。このスイッチング・モジュールは、低遅延（最短 300ns）を実現するすばやいスイッチング機能を備えています。各Sun Blade 6000 Ethernet Switched NEM 24p 10GbEは、シャーシにインストールされている各サーバー・モジュールに 10Gb イーサネットで接続します。各サーバー・モジュールへの 10GbE 接続は、Sun Blade 6000 シャーシにNEMを 2つインストールすることで冗長化できます。ノンブロッキング・スループットを実現するために、背面パネル経由で各NEMの合計 14 の外部 10GbE 接続を使用できるようになっています。内訳は、SFP+コネクタが 2つと 4x QSFP（クアッド SFP）コネクタが 3つです（図 2）。

図 2 Switched NEM の詳細

互換性のあるラックまたはエンタープライズ・スイッチに接続する場合は、NEM によるスイッチ統合に加え、4x QSFP コネクタによっても大幅なケーブル統合が実現されます。

Oracle のモジュール型設計の原則に準拠しているため、NEMは管理が容易で、標準のインタフェースとネットワーク・プロトコルに対応しています。

• 統合シャーシ管理

• Webブラウザ・インタフェースと標準のコマンドライン・インタフェース（ILOMシェル）

• 複数のユーザー権限

• エンタープライズ・ネーミング・サービスでのシングル・サインオンのサポート

• シャーシ監視モジュールを介した ILOMのサポート

• 環境監視

• 業界標準の L2/L3 ネットワーク・スタック CLI とコマンド・セット

サーバー・モジュールからは、Sun Dual 10GbE PCIe 2.0 ファブリック拡張モジュール（FEM）を使用してNEMに接続します。FEM（図 3）がサーバー・モジュールに２つの 10GbE インタフェースを提供します。FEMのイラストを下の図に示します。

図 3 ファブリック拡張モジュール

注：InfiniBand®インターコネクトも使用できますが、この構成ではテストされていません。どのようなインターコネクト・テクノロジーでも、アプリケーション・サーバー層とデータ・グリッド層の間でより高速なネットワーク接続がサポートされます。その際、顧客のデータセンターにある他の機器に対して種類の異なるネットワーク・テクノロジーが見えることはありません。

クライアントと最初のスイッチング層

Coherence をデプロイすることで、アプリケーション・サーバー・クラスタに対して同時発生する大量のデータ要求をはじめとするすさまじいワークロードに対応できます。できる限りの精度を維持しながらこの種のワークロードをシミュレートするために、このテスト構成では大きな負荷をかける機能が必要です。この要件を満たすために、Coherence のベンチマークを FABANロードジェネレータ上で実行し、40 のラックマウントとブレード・サーバー・モジュールが混在するクライアント層（図 4）をロードジェネレータとして動作させます。

図 4 クライアント層

クライアント層に存在するサーバーの具体的な構成は重要ではありませんが、各サーバーは 1GbE の接続経由でアプリケーション・サーバー層へ、

さらに Coherence フレームワークへと接続されています。データは、クライアント層から、1GbE ネットワークと 10GbE ネットワークの間のブ

リッジとして動作するイーサネット・スイッチング・レイヤーに流れます。

WebLogic Serverクラスタ層

WebLogic Server 層では、2基の Sun Blade 6000 Ethernet Switched NEM 24p 10GbE がネットワーク接続を処理します。NEMのフォーム・ファクタは Sun Blade 6000 モジュラー・システムに固有のもので、シャーシ内のすべてのサーバー・モジュールへの I/O 接続を向上させる設計になっています。Sun Blade 6000 モジュラー・システムのシャーシには、さまざまなNEMを搭載できるスペースがあります。このシャーシは、2基のシングルハイトNEM、1基のデュアルハイトNEMのいずれかをサポートします。10GbE Ethernet Switched NEMはシングルハイトであるため、この構成にはこのNEMが 2基含まれ、10GbE のスイッチング容量を持つポートがそれぞれに 24個あり、双方向アップリンクの帯域幅は合計 280Gb/秒です。

この構成では、2基のNEMが提供する 10GbE 接続を介して各サーバー・モジュールがスイッチに接続され、負荷を生成するクライアント・システムにスイッチ経由で接続されています。ここでは、各層への接続を冗長化するために、使用可能な 2 基の NEM に接続を分散しています（図 5）。2 基目の NEM は、各サーバー・モジュールへの接続を、Coherence クラスタに接続されている 10GbEスイッチに分配します。各サーバー・モジュール上では、WebLogic Server のインスタンスが TopLink（Eclipse Link）レイヤーと通信します。TopLink は、Java Persistence Architecture（JPA）の実装で、（この例では）アプリケーション・サーバー・レイヤー間でオブジェクトの格納やアクセスをするときに使用されます。Oracle TopLink を使用すれば、万が一アプリケーション・サーバーで障害が発生しても、アプリケーション・サーバーから外部の顧客に提供されるリソースを抽象化することができます。

図 5 WebLogic Server クラスタ層

Coherenceスイッチング・レイヤー

アプリケーション・サーバー、または大勢のユーザーに対応する同様の永続データ・レイヤーを操作している人は、今説明したクライアント層とアプリケーション・サーバー層についてはたいてい熟知しています。このようなアーキテクチャでは、アプリケーション・サーバーからデータベース層への直接的な通信がもっとも多く発生します。Coherence を使用すると、データの流れにもう 1つの層が追加されます。Coherence アーキテクチャのこの新しい層の基本的な役割は、アプリケーションの要求しているデータがリモート・データベース上ではなくアプリケーション・サーバーのローカルな場所にあることをアプリケーションに伝えることです。この通信は JVM 内に存在する小型のコネクタ・ソフトウェアを介して行われます。要求は、この小型のコードによって、アプリケーション・サーバーの理解できる言語から Coherence の使用するシリアライズ形式に変換されます。実際は、各アプリケーション・サーバーの必要とするデータは、Coherence クラスタ・グリッドの内部で相互接続されている他のサーバー・セット上のメイン・メモリに存在します。アプリケーション・サーバーからもっとも速い速度で必要な（かつローカルに格納されていると認識させられている）データにアクセスできるようにするには、できる限り速い速度ですべてのアプリケーション・サーバーを Coherence クラスタに接続することが重要です。このような理由から、このアーキテクチャでは、すべての Coherence ノードが 10GbE ネットワーク経由で相互に接続されています。

図 1に示したアーキテクチャの全体図には、2つの独立した Sun Blade 6000 モジュラー・システムがあります。1つのシャーシでWebLogic Server インスタンスをホストし、もう 1つのシャーシですべてのCoherenceサーバーをホストしています。2基のSun Blade 6000 Ethernet Switched NEMが、両方のSun Blade 6000シャーシ上のサーバーを3本のQSFTケーブルを使用して接続しています（図6）。

図 6 Coherence スイッチング・レイヤーでは 10 ギガビット・イーサネット・スイッチを使用してアプリケーション・サーバー層から Coherence

層に接続しています。注：独立した Sun Blade 6000 シャーシが不要な場合もあり得ます（またそのような場合が多くあります）。WebLogic アプ

リケーション・サーバーは、Coherence ノードが N+1 個（N = 2 以上）あれば、Coherence ノードと共存させられます。

Coherence層

Coherence のパフォーマンスとスケーラビリティには、メモリの速度と密度、および CPUの処理速度がもっとも重要な要素です。Coherence 層のサンプル・アーキテクチャでは、インテル Xeon プロセッサ 5500 番台の CPUを搭載した Sun Blade X6270 サーバー・モジュールを 10基使用しています（図 7）。さまざまな処理アーキテクチャを比較した数多くの社内テストの結果、Enterprise 2.0およびWeb 2.0 アプリケーションを実行する Coherence ワークロードでは、このシステム構成のときにメモリ密度、CPUプロセッサ速度、パフォーマンスの高さのバランスがもっともよくなります。というのも、これらのプロセッサ上のメモリ・コントローラは、まず関連付けられている一連のメモリと直接通信してから、これより離れた（したがって速度の低い）リソースを使用するためです。このメモリ配置の自動チューニングは、応答時間を一定に保つための Coherence で実行されるメモリ操作の 1つです。

図 7 Coherence 層は、Sun Blade X6270 サーバー・モジュールを含むバランスのとれたアーキテクチャで実行するとメリットがあります。

データベース層

Enterprise 2.0 およびWeb 2.0 のワークロードの場合は、Coherence によって処理されるデータの多くがおもに Coherence のメモリ・レイヤーに存在します。頻繁にアクセスされないデータは、時間が経過してメモリを使用する高速アクセスが不要になると、バックエンドのデータベースに移動しますが、そのタイミングは、ポリシーに基づくデータ・バックアップとリテンションのスケジュールで決定されます。この例の場合は、メモリ密度とすべてのノード間のネットワーク速度が、キー・パフォーマンス・インディケータとなります。加えて、標準の Coherence のデプロイメントでは、オブジェクトを他のノードに複製することにより、すべてのインメモリ・オブジェクトに単一インスタンスの障害に対する冗長性と耐障害性を持たせることができます。その結果、メモリ内に保持されているデータはメモリ上に残しておいても安全で、ただちにデータベースに格納する必要がなくなります。

ただし、一部のデータ・オブジェクトの場合は、データの取得や格納のために、Coherence がデータベース・サーバーやネットワーク接続ストレージ（NAS）デバイスといった外部リソースにアクセスすることが必要になります。Coherence ではバックエンドのアーキテクチャに柔軟に対応させられるため、財務トランザクションや HPC ワークロードのように、データの格納をエンドユーザーに確認する前に、着信データを受信してデータベースに格納することが必要な場合もあるワークロードに対応できます。このようなユースケースでは、必要に応じてバックエンドのアーキテクチャを簡単に変更し、データベース・アクセスを高速化させることができます。実際、Coherence は次のようなさまざまなモードでの実行が可能です。

• WebLogic Server インスタンスの Level 2（L2）キャッシュとして実行する。

• アプリケーション・サーバーから要求されたデータの読取り専用キャッシュとして実行する。書込みは直接バックエンドのデータベースに対して実行されますが、書き込んだデータはCoherence ソフトウェアによって超高速の読取り専用アクセス用としてグリッドにプルされます。

• アプリケーション・サーバーから要求されたオブジェクトの読取り/書込みキャッシュとして実行する。

• ビジネス・アプリケーション全体をメイン・メモリでホストする。

本書に記載したベンチマーク・テストのシナリオでは、アプリケーション・サーバーから要求されたオブジェクトの読取り/書込みキャッシュとして Coherence を実行しました。

本書で説明しているこのベンチマーク・テストの場合、Coherence 層で処理したトランザクションには、ただちにコミットしてコミットの通知をバックエンドのデータベースに書き込む必要がありませんでした。そのためこの構成では、パフォーマンスを発揮するうえでデータベースへのインターコネクトの速度は重要ではありませんでした。図 8に示すように、Sun SPARC Enterprise M5000 サーバー上で実行しているOracle Database 11gインスタンスは、1枚の10GbEアドインPCI Expressカード経由で Coherence 層の Sun Blade 6000 Ethernet Switched NEMの SFP+ポートに接続されています。データベースへの負荷は大きくなく、Coherence には冗長性があるため、データベースに格納する必要のあるトランザクションをただちにコミットする必要はありません（このテスト・ケースに含まれるデータ片すべてのマスター・コピーとバックアップ・コピーが、Coherence を実行する物理的に独立したもう 1つのサーバー・モジュール上に 1つずつ存在しました）。

図 8 データベース層に必要な最小限のネットワーク帯域幅を処理するのは、1つの 10GbE接続です。

Coherenceのベンチマーク・テスト

Coherence をデプロイメントする際に選択するハードウェアの影響がもっともよく分かるようにするために、オラクルのエンジニアは理解と文書化が容易なワークロードを選択しました。そのため、このベンチマーク・テストでは、オンライン・トランザクションとオンライン検索のユースケース（オンライン・トランザクション処理：OLTP）をシミュレートします。このプロジェクトのテスト・エンジニアは、顧客がホテルの客室を検索して予約するときに使用するオンライン・システムを模倣するワークロードの作成を目指しました。テスト結果を検討する際は、このアーキテクチャがあらゆるターゲット・デプロイメントと正確に適合しない場合もあることを念頭においてください。ただし、コンポーネントの多くは、代わりのワークロードとの適合性が高まるように交換することができます。

ワークロードの概要 - ホテル客室検索予約オンライン・システム

ホテル客室検索予約オンライン・システムは、オンラインでホテルの客室を検索して予約するシステムです。利用者はWebブラウザ・インタフェースからこの架空のWebサイトにログオンし、客室の検索と選択、予約を実行してログアウトします。このワークロードはオープンソース化されており、Project Kenaiのサイトからダウンロードできるようになっています（http://kenai.com/projects/ coherencebench）。

ユーザーの要求は、Sun Blade 6000 サーバー・モジュールでホストされている特定のアプリケーション・サーバーに送信され、アプリケーション・サーバーが Coherence 層と通信し、必要に応じてバックエンドのデータベースとも通信が行われます。その後、結果がアプリケーション・サーバーに返送され、最終的にクライアント・システムに返送され、ユーザーが操作するための結果が作成されます。このワークロードは、オンラインWeb アプリケーションとエンタープライズ・アプリケーションを対象とした Coherence の"典型的な"ターゲット実装です。副次的なメリットとして、このワークロードは、最適なハードウェアを選択することがスケーラビリティにどのように影響するかを示す分かりやすく柔軟性のあるデプロイメントとしても使用できます。2つのワークロードを作成して、この参照アーキテクチャのスケーラビリティとパフォーマンスをテストしました。

• Coherence の単純なオブジェクトのマイクロベンチマーク - できるだけ小さいオブジェクトを使用した場合の Coherence の生のパフォーマンスを表示するように設計した GET およびPUT 操作で 1KB のオブジェクト・サイズを使用します。また、ハードウェア上で実行されている標準的なユーザー・ワークロードがない状態のプラットフォームとソフトウェアの生のパフォーマンスをテストできるように設計されています。

• ホテル予約オンライン・システムのワークロード - 標準的な 10KB のパケット・サイズで、クライアント・システム、WebLogic Server 層、Coherence 層、およびバックエンドのデータベースを使用するホテル客室検索予約システム全体をシミュレートします。

マイクロベンチマーク：Coherenceの単純なオブジェクトのベンチマーク

Coherence のマイクロベンチマークでは、キャッシュのGET と PUT を実行して 1KB の小型オブジェクトを Coherence 層から出し入れし、Coherence のスケーラビリティを簡単にテストします。図 8に示すように、アプリケーション・サーバー層を使用しない場合の 1KB オブジェクトの Sunサーバーと Coherence のスケーラビリティはほぼ線形です。図 9の結果のグラフでも、これらのシステムがこのテストを通じて安定した即応性を発揮していることが分かります。このマイクロベンチマーク・テストで負荷が最大になったときの CPU使用率は 95%に達しますが、スケーラビリティは一定しており、ボトルネックは発生しませんでした。図 10 のグラフでは、ネットワークでもスケーラブルなスループットが見られ、テストを実施している間、応答時間は一定でした。これらのマイクロベンチマーク結果は、Coherence フレームワークを使用しても RAWハードウェアの遅延が目に見えて増加したりはしないことが示されています。これらのテストはマイクロベンチマークであり、アプリケーション・サーバー層をまったく使用せずに Coherence サーバーそのものから実行されました。このテストでの負荷は、1KB のオブジェクトを使用した読取りが約 80%で書込みが約 20%でした。

図 9 マイクロベンチマーク・テストの結果は、1 台の Coherence ノード上で実行される 1 秒当たりの操作を単位とした場合、このテスト構成で

の応答時間は一定で、スケーラビリティは線形に近いことを示しています。

図 10 ネットワークのスループットには線形に近いスケーラビリティがあり、ネットワーク応答時間は、マイクロベンチマーク・テストを実行し

ている間一定でした。

このマイクロベンチマーク・テストは、一般の10ギガビット・イーサネット・カードとSun Blade 6000 Ethernet Switched 24p 10GbE NEMのパフォーマンスを比較する目的で実行します。テスト結果は、NEM ネットワーク・インタフェースと一般の 10 ギガビット・イーサネット・カードの応答時間とスループット・レベルが同じであることを示しました。このテストには、繰り返し実施するテストで使用する基準値を求めること以外に、Sun NEM製品には他のサード・パーティのネットワーク・ソリューションと同等の性能がありながら、管理性と性能の面では業界標準のアドイン・オプションよりメリットがあることを示す目的がありました。

グラフから読み取れるように、1GbE インターコネクトから 10GbE インターコネクトに移行することでパフォーマンスが大幅に向上します。また、Sun Blade 6000 モジュラー・システムでは、サーバー・モジュールを追加しても遅延の大幅な増加はありません。さまざまなテストからも、Sun Blade X6270 サーバー・モジュール当たりの最適な JVMの数は、JVMが 8の場合（インテル Xeon プロセッサ・コア当たりの JVMがほぼ 1のとき）にスループットが最大に達すると結論づけられています。このテスト結果の詳細は、本書の「ベスト・プラクティス」の項を参照してください。

Coherenceのホテル・オブジェクト

大半の Coherence のデプロイメントでは、オブジェクトの平均サイズは 1KB～10KB の間で、ほとんどが約 8KB です。この"ホテル・オブジェクト"は 10KB で、通常の Coherence オブジェクトよりわずかに大きめです。このホテル・オブジェクトには、ユーザーがホテルを検索したときに一般的なホテルが公表する情報に対応したテキストと数字が含まれます。この 10KB のオブジェクトに含まれるコンテンツは次のとおりです。

• ホテル名

• 住所

• 電話番号とファックス番号

• ホテルの評判の例

これらのフィールドを合計すると約 10KB 相当のデータになり、オンライン検索を使用するアプリケーションの標準的なサイズをほぼ表すことになります。図 11は、ホテル・オブジェクトが生成されて Coherence アーキテクチャの中を流れる様子を示しています。

図 11 ホテル・オブジェクトを生成する手順を示すフロー・チャート

ベンチマーク：完全な構成のホテル・アプリケーション

このホテル・アプリケーションのベンチマークでは、クライアント・マシンからアプリケーション・サーバー経由で Coherence 層、データベース層へと非同期に通信し、またクライアントまで戻る構成全体のスケーラビリティをテストします。Coherence 層にテストを応用する方法を理解するには、Coherence の動作の仕方を理解することが重要です。このホテル・アプリケーションではSpringSourceフレームワークと Fusion Middleware スタックを使用して、ホテル検索予約オンライン・システムをエミュレートします（図 12）。シミュレートされるユーザーは、TopLink JPA が実行されているWebLogic Server インスタンスと通信します。各インスタンスは TopLink JPA で Coherence フレームワークと透過的に統合されています。このユースケースは、このモデルのようなオンライン/エンタープライズ・アプリケーションで最高のスケーラビリティとパフォーマンスが発揮されるようにCoherence を読取り/書込みキャッシュとして実行するオンライン OLTP ワークロードの場合にもっとも意味があります。

図 12 Coherence のスケーラブルなアプリケーション・アーキテクチャ

すでに説明したように、Coherence のテストには、1GbE ネットワークでWebLogic Server と通信するさまざまなマシンが混在するクライアント層が必要です。WebLogic Server に UltraSPARC T2 Plusプロセッサを使用した場合のスケーラビリティは、テストしたすべてのアーキテクチャの中で一番だったため、WebLogic 層ではチップ・マルチスレッド（CMT）テクノロジーを搭載したプロセッサを使用しています。最大 8個の UltraSPARC コアと、コア当たり 8スレッド（アドレス可能なハードウェア・スレッド数はプロセッサ当たり最大 64）を使用できるため、このプロセッサを使用すると、WebLogic Server のようなマルチスレッド Java アプリケーションのパフォーマンスは格段に向上します。WebLogic Server 層では、TopLink を JPA プロバイダとして使用すると同時に、すべてのオブジェクトのためのデータ・リポジトリであるバックエンドの Coherence との通信にも TopLink 使用します。Coherence で見つからないデータ片がある場合は、Oracle Database 11g が実行されているバックエンドの Sun SPARC Enterprise M5000 サーバーに問い合わせてデータを取得します。

Coherence キャッシュ・クラスタは、Sun SPARC Enterprise M5000 サーバー上で実行されているOracle Database 11g から Coherence フレームワークにデータをバッチ・ロードしてキャッシュを暖め、クライアントから初めてアクセスされるたびにデータベースに直接問い合わせる必要をなくしています。キャッシュ・ミスがある場合のみ、データベース・サーバーからデータがプルされ、要求元のクライアントに返送されますが、それ以外の場合は、よくアクセスされるデータがデータベースからバッチで読み取られます。テストの場合は、Coherence グリッド内に存在するほとんどすべてのデータが Coherence 層にキャッシュされているため、キャッシュ・ミスは頻繁には発生しま

せんでした。また、データベースが特定のデータ片の送信元サーバーとして動作することが必要になるのは極めてまれです。すべてのインスタンスについて、Coherence のデータを冗長化するために、もう 1つの Coherence ノード上の別の 1箇所にデータがレプリケートされました。この事実 1つだけでも、Coherence キャッシュ・クラスタを追加してデータベースの負荷を削減することにより、データベースのスケーラビリティが大幅に向上する可能性があることが分かります。

ホテル・アプリケーションのテスト結果

このテスト構成では、ホテル・オブジェクトのベンチマーク・テストの間、線形に近いスケーラビリティと一定の応答性が得られました（図 13）。特に、このテスト構成では、1 秒当たりの操作回数が最大 100 万に達するパフォーマンス・スケーラビリティがありました。

図 13 ホテル・オブジェクトのベンチマークのパフォーマンス・メトリックと応答時間メトリック

ベンチマークの実行時に収集されたその他のメトリックを見ると、Coherence を使用することで、このテスト構成で対応可能なユーザー数が増加し（図 14）、データベース・サーバーの CPU使用率が劇的に削減される（図 15）ことが分かります。

図 14 ホテル・オブジェクトのベンチマークに Coherence を使用することで、このテスト構成で対応可能なユーザー数が増加しました。"タイル"

は、WebLogic Server ノードの 1 つのペアと 1 つの Oracle Coherence ノード、およびこれらをまとめるための関連するネットワークを指します。

図 15 ホテル・オブジェクトのベンチマークに Coherence を使用することで、データベース・サーバーのワークロードが削減されました。"タイ

ル"は、WebLogic Server ノードの 1 つのペアと 1 つの Coherence ノード、およびこれらをまとめるための関連するネットワークを指します。

ベンチマーク・テストの結果から、Coherence を使用することにより応答時間がより安定する可能性があること、また組織は品質保証契約(SLA)を守りやすくなる可能性があることも分かりました（図16）。

Coherence のパフォーマンスは、オンラインのノード数が増えるにつれて実際に向上しましたが、このテスト中の応答時間は、オンラインのノードの数を増やしても変化しなかったか短縮されました。オンラインのリソースを増やすとパフォーマンスは目に見えて向上しますが、ハードウェア・リソースを追加することで、成長曲線とパフォーマンス曲線に具体的にどのような影響があるのか判断できることが、データセンターの計画やアプリケーションのプロビジョニングを理解するうえで重要です。

図 16 ホテル・オブジェクトのベンチマークに Coherence を使用することで、さらに応答時間が一定しました。"タイル"は、WebLogic Server ノー

ドの 1 つのペアと 1 つの Coherence ノード、およびこれらをまとめるための関連するネットワークを指します。

この構成のテストの一環として、オラクルのエンジニアはさまざまなJVMパラメータをチューニングし、パフォーマンスとスケーラビリティに関連する問題を解決しました。オラクルのエンジニアはOracle Solarisを採用することで、Solarisダイナミック・トレース（DTrace）という、強力な観測機能を備えたチューニング・ツールを手に入れました。DTraceの詳細は、http://www.sun.com/ bigadmin/content/dtrace/index.jspを参照してください。

DTrace を使用するとオペレーティング・システムのカーネルまで調査できるため、テスト・エンジニアは対処する必要のあるパフォーマンス領域をすばやく特定できました。DTrace を使用するときに、オラクルのエンジニアは次のベスト・プラクティスを使用して、パフォーマンスを改善する領域の検出に役立てました。

• JVMを-XExtendedProbes で開始する

• Garbage Collection Probe で GCの間隔とポーズを確認する

• ロック・アクティビティを監視する

• 頻度とコストが高いコールのMethod entry/exitprobe を検査する

テスト・エンジニアはこれらのDTrace プローブを使用して、このワークロードに最適なパフォーマンスに合わせて JVMをチューニングできました。DTrace はアプリケーション実行のさまざまな側面に消費される処理時間に関する貴重な情報を提供してくれるため、このツールを使用すると、テスト・エンジニアがチューニング作業に集中できるという効果もあります。最終的に得られたパフォーマンスの詳細は次のとおりです。

• シリアライズ：33%

• ネットワーク読取り/書込み：31%

• ガベージ・コレクション：26%

• Put の LockWait：5%～20%

• InvocableMap の参照：5%

オラクルのエンジニアは、DTrace で得られた詳細情報を使用して、どのようなパフォーマンスの問題でも徹底的に調査して解決することができました。類似したワークロードの結果を改善するのに役立つチューニング領域は、他に次のような領域があります。

シリアライズ - オブジェクト・データのシリアライズに Portable Object Format（POF）を使用することを検討してください。シリアライズ/デシリアライズとは、元のオブジェクトは基本的に"フラット化"し、Coherence フレームワークに格納するオブジェクトは"フラット化を解除"するプロセスのことです。完全なオブジェクトを格納する処理はあまりに複雑でパフォーマンスに著しく影響するため、オブジェクト全体を 1つの単位として Coherence フレームワークに格納することはできません。したがって、格納する際にはオブジェクト自体をシリアライズする必要があり、後でクライアントやアプリケーション・サーバーからデータを要求されたらオブジェクトを組み立て直します。POF を利用するメリットはおもに次の 2つです。

• Java のシリアライズより CPU使用率を約 20%削減

• Java のシリアライズよりキャッシュ・エントリ・サイズが縮小

ネットワーク・パフォーマンス - アプリケーション・サーバー層から着信する要求のサイズに合わせてネットワークをチューニングする方法は、Coherence のオンライン・ドキュメントで説明されています。ネットワーク・パフォーマンスと、アプリケーション・サーバーと Coherence 層の両側で期待されるパフォーマンスとをぴったり一致させるには、UDP バッファ・サイズを平均のオブジェクト・ペイロードにチューニングすることがとても重要です。また、オラクルのエンジニアは、10GbE を使用するときにネットワーク・スタックのジャンボ・フレーム機能を使用することで、CPU使用率を約 22%削減しました。

JVM のチューニング - JVMの一部をチューニングすることでも、パフォーマンスが向上します。JVMバージョン 1.6 をラージ・ページ・サポートと併用すると、旧バージョンの JVM よりもパフォーマンスが大幅に向上し、パラレル・ガベージ・コレクションやアグレッシブ・ガベージ・コレクションを使用しても向上します。

ネットワーク・インターコネクトの選択 - テスト中、エンジニアはネットワークと処理サブシステムを 100%近く（95%前後）の能力で使用することができました。InfiniBand®は CPU ワークロードの削減に効果があるため、10GbE ネットワークをQuad Data Rate（QDR）の InfiniBand®に交換することで、スループットのレベルが一段と向上する可能性があります。

結論

垂直方向のスケーラビリティを持つデータベース層から水平方向のスケーラビリティを持つデータ・グリッドにスケーラビリティの負担を変換するアーキテクチャを構築すれば、アプリケーションのスケーラビリティを新たなレベルに引き上げることができます。本書で紹介したベンチマーク結果を踏まえると、Coherence と Sun サーバー・ソリューションを活用することで、組織は次のようなメリットが得られます。

より高いパフォーマンス

• テストしたソリューションでは、Coherenceを追加することで、1秒当たりのE-Commerce問合せとトランザクションが、Coherenceなしで実行した同じテストと比べて最大 2.5 倍になりました23。

その他の高度な機能

• このベンチマーク・テストに類似したワークロードを基にすると、Sun システム上でCoherence を使用することにより、アプリケーションのスケーラビリティは 1 秒当たりの操作が 100 万回以上になる可能性があります。

• Sun システム上に Coherence をデプロイメントすれば、顧客に確固たるサービス品質を保証しながら、線形に近いスケーラビリティを実現できるため、ROI の最大化にも役立つ可能性があります。

• Coherence 層を追加することにより、組織はデータベース層の CPU 使用率を最大 40%削減し、サポートできるユーザーを最大 25%増やすことができます。

• DTraceは他のどのツールよりも高度な観測機能を持ち、Solarisに無料で同梱されています。

2注：E-Commerce のワークロードは、標準的な 10Kのオブジェクト・サイズに対する Coherence の操作のうち読取りが 80%で

書込みが 20%と見なします。 3本書のテストは、Sun Blade X6270 サーバー・モジュールで実行されました。本書を発表した後に、Sun Blade X6270 M2 バージョ

ンのサーバー・モジュールが発表されましたが、全体的なパフォーマンスの増加は、本書で説明したシステムの約 2倍になりま

す。ワークロードの数はアプリケーションによってばらつきがあります。

オープン・ネットワーク・システム

• オラクルの Sun Blade 6000 サーバー・モジュールは、ラックマウント・サーバーより 10%少ない消費電力で動作します。また、ラックマウント・サーバーと等価関係にあるサーバー・モジュールが用意されており、業界標準の PCI Express ExpressModule を使用して柔軟にネットワークを構築できます。Network Express Module はさまざまなネットワーク・オプションの中から選択できます。

• オラクルはスタンドアロンの Coherence を提供しており、Coherence のインストールとWebLogic Server のインストールですべての層を表現することも、既存の環境に Coherence層だけをインストールすることもできます。また、オラクルはWebを使用するオンラインのCoherence ワークロード用として使用できる、小規模、中規模、大規模の各構成定義を作成しました。

• Enterprise Manager と統合することで、Ops Center はアプリケーションからディスクまでを管理できる統合プラットフォームになります。Ops Center で、ベアメタル・プロビジョニングからオペレーティング・システム・プロビジョニングや Linux および Solaris の両方の環境へのパッチ適用までを実行できます。

Sun Tシリーズ・システムは、Standard Performance Evaluation Corporation（SPEC®）という組織の次に示すWebサイト4に報告されているとおり、WebLogic Serverの実行で高いパフォーマンス値を保持しています。

• http://www.spec.org/osg/jAppServer2004/results/res2009q3/jAppServer2004-200907

01-00135.html

• http://www.spec.org/osg/jAppServer2004/results/res2009q1/jAppServer2004-200901

13-00127.html

オラクルのエンジニアは、Sunのハードウェア上で高いパフォーマンス・レベルでCoherenceを実行するためにこのシステムを構築しました。詳細は、このアーキテクチャのメインWebサイト（http:// www.Oracle.com/us/products/middleware/coherence/index.html）を参照してください。オラクルがこのような作業を実施したのは、類似した構成の構築にかかる時間を利用者に節約してもらうためです。これらの結果は、オラクルの適切なSunサーバーを使用してCoherenceソフトウェア・スタックのバランスを取るCoherenceのデプロイメントの作成に使用できます。

追加情報

Coherence のメリットおよび Sun サーバーのメリットについての詳細は、次の関連リソースを参照してください。

Sun Blade システム

http://www.Oracle.com/us/products/servers-storage/servers/blades

Sun ネットワーク・テクノロジー

http://www.Oracle.com/us/products/servers-storage/networking

4 SPECおよびSPECjAppServerは、Standard Performance Evaluation Corporation（SPEC）の登録商標です。最新の結果

はwww.spec.comを参照してください。

Sun JVMチューニング・ガイド

http://java.sun.com/performance/reference/whitepapers/tuning.html

Oracle Coherence

http://www.Oracle.com/goto/coherence

Oracle Technology Network に掲載されているOracle Coherence の技術情報

http://www.Oracle.com/technology/products/coherence

著者について

Nick Kloski はオラクルの Principal Infrastructure Solutions Manager です。Nick は 13 年間 Sunに勤めていたため、システム管理作業、6年を超える現場での技術サービス、社内での品質検査、Technical Marketing Department の一員としての経験など、Sunのシステムと競合システムの両方の幅広い経験を持っています。Senior Infrastructure Solution Manager という役職に就くNick の職務は、Oracle Fusion Middleware ソフトウェア製品群の知識と、これらの製品をオラクルの世界レベルのハードウェア製品と組み合わせる方法を顧客に教えることです。

Nitin Ramannavar はオラクルの Performance Engineering チームの中心メンバーの 1人で、システムとアプリケーションのエンド・ツー・エンドのパフォーマンスを向上させることなどを職務としています。Nitin は Web テクノロジーが専門で、特に分散コンピューティング、仮想化を使用したスケールアウト・アプリケーション・アーキテクチャ、Webおよびアプリケーション・キャッシュ、サービス品質が保証されるクラウド・サービスの提供に精通しています。

Satish Vanga はオラクルの ISV Engineering グループ内で WebLogic Server、Coherence、およびOracle TimesTen In-Memory Database を担当する技術リーダーです。Satish はこれまでに複数のSPECjAppServer ベンチマークを発表しており、SugarCRMと Coherence のベンチマークを開発しました。Satish は、Coherence、Terracotta、TimesTen In-Memory Database などの分散キャッシュ・エンジンを使用して設計された極度にスケーラブルなシステムを専門にしています。

Copyright © 2010, Oracle and/or its affiliates.All rights reserved.

本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は、

その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証を含め、商品性ない

し特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません。オラクルは本

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

す。本文書はオラクルの書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形

式や手段によっても再作成または送信することはできません。

Oracle および Java®は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

AMD、Opteron、AMDロゴおよび AMD Opteron ロゴは、Advanced Micro Devices の商標または登録商標です。Intel および Intel

XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International,

Inc.の商標または登録商標です。UNIX は X/Open Company, Ltd.によってライセンス提供された登録商標です。0310

Oracle WebLogic Suite の最適化ソリューション： 最適なインメモリ・データ・グリッド・ アーキテクチャ 2010 年 9 月 著者： Nick Kloski Nitin Ramannavar Satish Vanga Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A.

お問い合わせ窓口 Oracle Direct

0120-155-096 oracle.com/jp/direct