Comments
Transcript
Oracle WebLogic Suiteの最適化ソリューション：最適なインメモリ・データ
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 Machine 1 を実行して、そ こで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 倍にな りました 2 3 。 その他の高度な機能 • このベンチマーク・テストに類似したワークロードを基にすると、Sun システム上で Coherence を使用することにより、アプリケーションのスケーラビリティは 1 秒当たりの操 作が 100 万回以上になる可能性があります。 • Sun システム上に Coherence をデプロイメントすれば、顧客に確固たるサービス品質を保証 しながら、線形に近いスケーラビリティを実現できるため、ROI の最大化にも役立つ可能性 があります。 • Coherence 層を追加することにより、組織はデータベース層の CPU 使用率を最大 40%削減 し、サポートできるユーザーを最大 25%増やすことができます。 • 2 DTrace は他のどのツールよりも高度な観測機能を持ち、Solaris に無料で同梱されています。 注：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 などの分散キャッシュ・ エンジンを使用して設計された極度にスケーラブルなシステムを専門にしています。 Oracle WebLogic Suite の最適化ソリューション： 最適なインメモリ・データ・グリッド・ アーキテクチャ 2010 年 9 月 著者： Nick Kloski Nitin Ramannavar Satish Vanga Copyright © 2010, Oracle and/or its affiliates.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は、 その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証を含め、商品性ない し特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません。オラクルは本 文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとしま す。本文書はオラクルの書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 式や手段によっても再作成または送信することはできません。 Oracle および Java®は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 AMD、Opteron、AMD ロゴおよび AMD Opteron ロゴは、Advanced Micro Devices の商標または登録商標です。Intel および Intel Xeon は Intel Corporation の商標または登録商標です。 すべての SPARC 商標はライセンスに基づいて使用される SPARC International, お問い合わせ窓口 Oracle Direct 0120-155-096 oracle.com/jp/direct Inc.の商標または登録商標です。UNIX は X/Open Company, Ltd.によってライセンス提供された登録商標です。0310