Oracle9i Real Application Clusters(RAC)に対し,ベンダー各社が検証センターを設立してノウハウを蓄積するなど,販売に向けて力を注いできている。RACは,特にDBサーバーを追加拡張する“スケールアウト”の実現手段として期待がかかる。ベンダーの検証結果とRACのアーキテクチャから,その実現性を検証した。

図1●Oracle9i RACの検証をベンダー各社が実施
ベンダー各社は,RACにおける拡張性や可用性を検証中だ。これまでの検証結果からは,比較的良好な結果が得られている。ただし検証内容を見ると,実際の効果などを判断するのはまだこれから,の感がある
 Oracle9iの目玉である新クラスタリング機能Real Application Clusters(RAC)の活用に,ハード・ベンダーやシステム・インテグレータ各社*1が力を注いでいる。検証センターを設置して稼働検証や性能検証を実施し,ノウハウの蓄積に努め始めた(図1[拡大表示])。アシストや伊藤忠テクノサイエンス(CTC),日本ヒューレット・パッカード(HP)では検証結果を基に,導入や運用のサービスを開始した*2

スケールアウトへの期待が高い

 現状,国内でRACの稼働実績が確認できているのはインターネットイニシアティブのデジタル・コンテンツ配信サービス「CDN JAPAN」における試験利用のみ。ただ,ゼンリンデータコムの地図情報提供サービス「Zm@p on net」システムで「必要になった時点ですぐに導入できるように検証中」(構築を担当するシーズ・ラボ ITソリューション部 セクションマネージャー 玉川敏一氏)など,利用を検討中の企業は多そうだ。日本オラクルは,「約200の検討案件がある」と言う。

図2●OPSからRACへの改良点
Oracle8iで提供されていたOracle Parallel Server(OPS)においても,クラスタ構成のサーバーでフェール・オーバーをする機能や分散処理によって処理能力を高める機能を提供していた。ただし,OPSでは異なるサーバーでWRITE/WRITEの競合が発生すると,ディスクを介してデータをやり取りする必要があり,拡張性が低かった。これに対し,RACでは競合が発生した場合でもインターコネクトを通じてデータをやり取りするアーキテクチャに改良し,ディスクI/Oが拡張性のボトルネックとなることを回避した

 RACに対してユーザーは,「待機系サーバーのリソースを有効活用したい」という“拡張性”に期待を寄せている(図2[拡大表示](1))。RACの前バージョンであるOracle Parallel Server(OPS)は,可用性(同(2))はあるが拡張性が乏しかったからだ。米Oracleのデータによれば,OPS利用では「4台のサーバーで2台分」。「設計をうまくやって2台のサーバーで1.5倍,設計が悪いと1.2倍程度」と見る技術者もいる。

 OPSの拡張性が低い理由は,そのアーキテクチャにある(図2下)。あるサーバーで更新中のデータに対して別サーバーに更新要求がくる“WRITE/WRITE”の競合が発生した際,ディスクを介してデータを受け渡す。そのため拡張性を高めるには,アクセスするデータごとにサーバーを分ける実装をするなど,競合を回避するための工夫が必要だった。

 RACではこのデータの受け渡しを,ディスクを介さずに,インターコネクトと呼ぶサーバー間を直結するネットワークを介する形に変更した。これにより,ディスクによるボトルネックを解消し,拡張性にも期待が持てるようになったのである*3

 拡張性が高ければ,耐障害性を高めるためではなく,単純にシステム性能向上のために導入するケースも出てくるだろう。最上位機でも能力が不足する大規模システムだけではない。小/中規模サーバーを複数台並べて処理能力を高める“スケールアウト”でコスト・メリットが得られれば,RACの恩恵を受けられるユーザーは増える。

 ただ,これは机上での話。本記事では,ベンダー各社の検証結果とアーキテクチャを基に,RACの拡張性を分析する。また可用性の検証テストの内容も検証した。

●拡張性
CPUオーバーヘッドが問題
スケールアウトは今後に期待

 コンパックコンピュータと日本オラクルは共同で,各サーバー台数における1秒当たりのトランザクション処理数を測定した。図1左の結果はWindows 2000でのものだが,Tru64 UNIXでの検証も実施した。また,CTCではSolarisなど,アシストではLinux,日本HPではhp-ux,新日鉄ソリューションズではAIXなど,各種プラットフォームにおいて同様な実験が実施されている。

 図1左の結果では,1台で405トランザクション/秒(tps)が,2台で765,4台で1597,6台で2322tpsである。1台の処理量を1とすれば,それぞれ約1.9,約3.9,約5.7と,ほぼ台数分の処理能力が得られているように見える。ただ現状の検証結果は,各社とも「動作確認レベル」と口をそろえる。「2台あれば2台分の処理能力を出せる」とは必ずしも言えないからだ。

図3●拡張性はどの程度得られるのか
コンパックコンピュータと日本オラクルが実施した拡張性の検証テスト(図1)において,同時に測定したインターコネクトの通信量(図左)と,各サーバーのCPU使用率(図右)である。インターコネクトの通信量から,ノード数の増加に伴いノード間通信が増えていることが分かる。同時に,CPUの負荷も高まっている

 この実験では,1台では同時100セッションの負荷,2台では同時200セッションの負荷と,台数に比例して同時セッション数を設定している*4。Javaアプリケーションで,検索処理が8割,更新処理が2割の割合で実行した。アプリケーションはチューニングしておらず,サーバーへのリクエストは均等振り分けである。一般的なアプリケーションを想定したもので,競合が発生する形になっている。

 競合が発生していることは,図3[拡大表示]左で確認できる。インターコネクトの通信量が,競合発生によるデータ通信を示す。ただ,インターコネクトは転送速度100Mビット/秒であり,ボトルネックになっていない。ここで注目すべきは,CPUの使用率だ(図3右)。

 1台のときのCPU使用率は平均約42%に対し,2台は約68%,6台は約94%と上がっている。つまり,1台や2台の際には各サーバーは余裕があり,最大スループットを出している状態ではない。そして,台数に比例した負荷を掛けたにもかかわらず,各サーバーのCPU使用率が高まっているということは,クラスタリングによるCPUオーバーヘッドがあると言える。


次回(下)へ続く