高性能、高信頼なエンタープライズ・システム実行基盤としてのWebLogic Server 12cを特徴付ける機能の1つが、Oracle Databaseのクラスタ環境を実現するOracle Real Application Clusters（RAC）との緊密な連携を可能にする「Active GridLink for RAC」である。同機能について、WebLogic Server 12cの販売パートナーであるNECが、その具体的な動作ロジックや、実際の性能に関して詳細な検証を行った。作業を担当したNEC 第三ITソフトウェア事業部の牧田雄樹氏に、実施の経緯と、その結果について話を聞いた。（編集部）![]()
WebLogic Serverの最新版、WebLogic Server 12cにおいて、Oracle RAC環境との緊密な連携によってシステムの性能、可用性、管理性を高める目玉機能の1つとなっているのが、Active GridLink for RACだ。Active GridLink for RACは、RACインスタンスの状態を逐次監視することにより、ノードの利用状況に応じたインテリジェンスな負荷分散やキャッシュ・フュージョンの抑制、一部に障害が発生した場合のアクセス・ノードの動的な切り替えといった高度な連携機能を提供する。
従来、こうした要件を満たすためには、システム構築の際に多くの工数を割いて独自に開発を行う必要があった。しかし、WebLogic Server 12cとOracle RACとの組み合わせでは、アプリケーション・サーバの標準的な機能により、上述したような連携が即座に可能となるのだ。
先ごろ、このActive GridLink for RACの動作ロジックや性能について、詳細な検証が行われた。実施したのは、オラクルのパートナーとしてWebLogic Serverの導入で豊富な実績を誇るNECである。
NECは長年にわたり、WebLogic Serverを含むFusion Middleware、さらにはOracle Databaseなどを中心とするオラクル製品全般において、数々のインテグレーション、運用サポートの実績を積み重ねてきた。両社のパートナーシップの強さは、NECが2012年度にオラクルの「Partner of the Year（最優秀賞）」を3年連続で受賞したことからも伺うことができる。
Active GridLink for RACとOracle RACを用いた詳細な性能検証は、今回が国内で初の試みとなり、検証作業には約2カ月が費やされた。検証を担当したNECの牧田氏によれば、NECではWebLogic Server担当とデータベース担当の緊密な技術連携によるユーザーへのインテグレーション支援体制を確立しているが、今回はその連携を生かして検証に臨んだという。牧田氏は入社以来、一貫してWebLogic Server、Oracle Coherence、JRockitなどFusion Middleware製品の技術支援や検証活動に従事しているが、今回は検証の計画段階からデータベースの技術者と連携したことにより、Active GridLink for RACの効果を生かすためのノウハウを生み出すことができた。
Active GridLink for RACの導入を検討する企業が多い中、NECによる詳細な検証結果はユーザーやSIerにとって貴重な参考情報となるだろう。以降では、検証内容とその結果のハイライトを紹介していく。
Active GridLink for RACは、複数のデータソースを論理的に束ねて1つのデータソースとして扱う「マルチデータソース」とは異なり、複数の接続を1つのデータソース内で管理する「GridLinkデータソース」を用いるが、両者は設定や接続の管理方法が異なる。そのため、今回の検証目標の1つとして、「マルチデータソースでは不可能なことや面倒な設定が必要になることが、GridLinkデータソースでは容易に行える」ことの実証が掲げられた。
検証作業は、2ノードRAC、2ノードWebLogic Serverの環境を基本とし、さらにテスト内容に応じて4ノードRAC構成でも実施された。検証時の構成とハードウェアの詳細は次のとおりだ。
（1）ランタイム接続ロード・バランシング（RCLB）
（2）Webセッション・アフィニティ
（3）動的なRACノードの追加／削除
（4）高速接続フェールオーバー（FCF）
（5）GridLinkデータソースの使用の注意点
以降、それぞれの検証作業の概要と、その結果を順に紹介していく。
RCLBの動作に関しては、Oracle RACのサービスに対して、どのような条件（レスポンス・タイムやスループット）を重視するかを設定できる。この設定により、さまざまな統計情報のうち、どの数値を参照して動作するかが決定される。例えば、レスポンス・タイム（SERVICE_TIME）を重視する場合は「1コール当たりの経過時間」が短いRACノードに多くのリクエストを振り分け、スループット（THROUGHPUT）重視の場合は「1秒当たりのユーザー・コールの数」が大きいRACノードに多くのリクエストを振り分けるといった具合だ。
検証においては、こうしたRCLBのバランシング動作がサービスごとに独立して行われるか（あるサービスの負荷が他のサービスのバランシングに影響を与えないか）を確認するために、まず次の3つの条件でテストを実施した。
牧田氏は、「この検証により、RCLBのバランシングは当該サービスの負荷に応じて行われ、別のサービスの負荷やOracle Databaseと無関係なプロセスのCPU使用率は動作に影響しないことを確認できた。逆に言えば、CPUの実行キューが詰まっていたり、CPUを使い切っていたりといった理由から間接的にELAPSEDPERCALLやCALLSPERSECのパラメータ値に差がつく場合は、別のサービスやOracle Databaseと無関係なプロセスがバランシングに影響を与えることになる。そのため、RCLBで相互に影響を与えたくない業務処理は別サービスで動かすことが推奨される」と説明する。
RCLBについては、さらに処理内容によるバランシングの偏りや、FANイベントの情報と振り分けの割合の関係、Oracle RAC側の負荷状況の変化によるバランシング動作の状態、接続先RACノードの決定動作などを確認するための詳細な検証が行われている。牧田氏によれば、これらの検証を通じて「RCLBが高負荷なノードへの振り分けを抑え、低負荷のノードに多く振り分けようとする動作が確認できた。一方で、振り分けロジックに起因する不要な振り分けの偏りが生じるケースも確認されており、その解消が今後の課題だと考えている」という。
Webセッション・アフィニティは、HTTPセッションごとにそれぞれ別のブロックを参照／更新するアプリケーションで有効に動作する。今回は、このアフィニティの実際の効果を見るための検証も行われた。2ノードRACと4ノードRACでの検証の結果、レスポンス・タイムの短縮とインターコネクト通信量の削減において、大きな効果が認められたという。
牧田氏は、「Webセッション・アフィニティの検証では、キャッシュ・フュージョンの抑制、レスポンス・タイムの改善、インターコネクト通信量の減少といった効果が確認された。さらに、その効果はアプリケーションのデータ・アクセスの処理方法に大きく依存することもわかった」と話す。また、RCLBのバランスの偏りによってアフィニティが無効になることや、アフィニティはWebLogic Serverクラスタ間で共有されるため、アプリケーション・サーバのクラスタ内で1つのノードに障害が起きた場合でも、キャッシュ・フュージョンの抑制効果は継続することなども確認できたという。
以上、今回はNECが実施したActive GridLink for RACに対する性能検証のうち、ランタイム接続ロード・バランシング（RCLB）とWebセッション・アフィニティの検証結果を紹介した。後編では、引き続き「動的なRACノードの追加／削除」、「高速接続フェールオーバー（FCF）」、「GridLinkデータソースの使用の注意点」に関する検証結果を紹介する。
NECがActive GridLink for RACの性能を緻密に検証
NEC 第三ITソフトウェア事業部 牧田雄樹氏
従来、こうした要件を満たすためには、システム構築の際に多くの工数を割いて独自に開発を行う必要があった。しかし、WebLogic Server 12cとOracle RACとの組み合わせでは、アプリケーション・サーバの標準的な機能により、上述したような連携が即座に可能となるのだ。
先ごろ、このActive GridLink for RACの動作ロジックや性能について、詳細な検証が行われた。実施したのは、オラクルのパートナーとしてWebLogic Serverの導入で豊富な実績を誇るNECである。
NECは長年にわたり、WebLogic Serverを含むFusion Middleware、さらにはOracle Databaseなどを中心とするオラクル製品全般において、数々のインテグレーション、運用サポートの実績を積み重ねてきた。両社のパートナーシップの強さは、NECが2012年度にオラクルの「Partner of the Year（最優秀賞）」を3年連続で受賞したことからも伺うことができる。
Active GridLink for RACとOracle RACを用いた詳細な性能検証は、今回が国内で初の試みとなり、検証作業には約2カ月が費やされた。検証を担当したNECの牧田氏によれば、NECではWebLogic Server担当とデータベース担当の緊密な技術連携によるユーザーへのインテグレーション支援体制を確立しているが、今回はその連携を生かして検証に臨んだという。牧田氏は入社以来、一貫してWebLogic Server、Oracle Coherence、JRockitなどFusion Middleware製品の技術支援や検証活動に従事しているが、今回は検証の計画段階からデータベースの技術者と連携したことにより、Active GridLink for RACの効果を生かすためのノウハウを生み出すことができた。
Active GridLink for RACの導入を検討する企業が多い中、NECによる詳細な検証結果はユーザーやSIerにとって貴重な参考情報となるだろう。以降では、検証内容とその結果のハイライトを紹介していく。
Active GridLink for RACの実力を探る性能検証の概要
今回の検証で主なスコープとなった技術は、「ランタイム接続ロード・バランシング」と「FCF（高速接続フェールオーバー）」である。Active GridLink for RACは、複数のデータソースを論理的に束ねて1つのデータソースとして扱う「マルチデータソース」とは異なり、複数の接続を1つのデータソース内で管理する「GridLinkデータソース」を用いるが、両者は設定や接続の管理方法が異なる。そのため、今回の検証目標の1つとして、「マルチデータソースでは不可能なことや面倒な設定が必要になることが、GridLinkデータソースでは容易に行える」ことの実証が掲げられた。
検証作業は、2ノードRAC、2ノードWebLogic Serverの環境を基本とし、さらにテスト内容に応じて4ノードRAC構成でも実施された。検証時の構成とハードウェアの詳細は次のとおりだ。
（1）ランタイム接続ロード・バランシング（RCLB）
（2）Webセッション・アフィニティ
（3）動的なRACノードの追加／削除
（4）高速接続フェールオーバー（FCF）
（5）GridLinkデータソースの使用の注意点
以降、それぞれの検証作業の概要と、その結果を順に紹介していく。
（1）ランタイム接続ロード・バランシング（RCLB）
ランタイム接続ロード・バランシング（RCLB）とは、アプリケーション側からデータベースへの論理接続を取得する際に実行される負荷分散の仕組みだ。ロード・バランシング機能としては、ほかに物理接続の作成時に実行される接続時ロードバランシング（CLB）があるが、今回の検証ではRCLBのみを対象とし、CLBでの負荷分散は各ノードで均等に行うよう設定した。RCLBの動作に関しては、Oracle RACのサービスに対して、どのような条件（レスポンス・タイムやスループット）を重視するかを設定できる。この設定により、さまざまな統計情報のうち、どの数値を参照して動作するかが決定される。例えば、レスポンス・タイム（SERVICE_TIME）を重視する場合は「1コール当たりの経過時間」が短いRACノードに多くのリクエストを振り分け、スループット（THROUGHPUT）重視の場合は「1秒当たりのユーザー・コールの数」が大きいRACノードに多くのリクエストを振り分けるといった具合だ。
検証においては、こうしたRCLBのバランシング動作がサービスごとに独立して行われるか（あるサービスの負荷が他のサービスのバランシングに影響を与えないか）を確認するために、まず次の3つの条件でテストを実施した。
- 検証1-a：該当サービスの負荷に応じてバランシングが働くか?
- 検証1-b：別のサービス間の負荷に応じてバランシングが働くか?
- 検証1-c：マシン間の負荷に応じて振り分けを行うか?
牧田氏は、「この検証により、RCLBのバランシングは当該サービスの負荷に応じて行われ、別のサービスの負荷やOracle Databaseと無関係なプロセスのCPU使用率は動作に影響しないことを確認できた。逆に言えば、CPUの実行キューが詰まっていたり、CPUを使い切っていたりといった理由から間接的にELAPSEDPERCALLやCALLSPERSECのパラメータ値に差がつく場合は、別のサービスやOracle Databaseと無関係なプロセスがバランシングに影響を与えることになる。そのため、RCLBで相互に影響を与えたくない業務処理は別サービスで動かすことが推奨される」と説明する。
RCLBについては、さらに処理内容によるバランシングの偏りや、FANイベントの情報と振り分けの割合の関係、Oracle RAC側の負荷状況の変化によるバランシング動作の状態、接続先RACノードの決定動作などを確認するための詳細な検証が行われている。牧田氏によれば、これらの検証を通じて「RCLBが高負荷なノードへの振り分けを抑え、低負荷のノードに多く振り分けようとする動作が確認できた。一方で、振り分けロジックに起因する不要な振り分けの偏りが生じるケースも確認されており、その解消が今後の課題だと考えている」という。
（2）Webセッション・アフィニティ
Active GridLink for RACのWebセッション・アフィニティは、Oracle RAC環境において各データベース・インスタンス内のキャッシュの整合性を維持する仕組みであるキャッシュ・フュージョンの発生を極力抑え、システム全体のパフォーマンスを高めるための機能だ。Webセッション・アフィニティは、HTTPセッションごとにそれぞれ別のブロックを参照／更新するアプリケーションで有効に動作する。今回は、このアフィニティの実際の効果を見るための検証も行われた。2ノードRACと4ノードRACでの検証の結果、レスポンス・タイムの短縮とインターコネクト通信量の削減において、大きな効果が認められたという。
牧田氏は、「Webセッション・アフィニティの検証では、キャッシュ・フュージョンの抑制、レスポンス・タイムの改善、インターコネクト通信量の減少といった効果が確認された。さらに、その効果はアプリケーションのデータ・アクセスの処理方法に大きく依存することもわかった」と話す。また、RCLBのバランスの偏りによってアフィニティが無効になることや、アフィニティはWebLogic Serverクラスタ間で共有されるため、アプリケーション・サーバのクラスタ内で1つのノードに障害が起きた場合でも、キャッシュ・フュージョンの抑制効果は継続することなども確認できたという。
以上、今回はNECが実施したActive GridLink for RACに対する性能検証のうち、ランタイム接続ロード・バランシング（RCLB）とWebセッション・アフィニティの検証結果を紹介した。後編では、引き続き「動的なRACノードの追加／削除」、「高速接続フェールオーバー（FCF）」、「GridLinkデータソースの使用の注意点」に関する検証結果を紹介する。