Gartner Japan

主流の採用段階に入ったOracle RAC

Oracle Real Application Clusters(RAC)は、テクノロジ、管理容易性、実装の成熟と改善を8年以上にわたって重ね、既に主流の採用段階に入っており、顧客に大きな利点をもたらしている。本リサーチノートでは、Oracle RACがいつ、どのような側面で最も効果を発揮するかについて解説する。

要約

　Oracleは、RACテクノロジを過去8年にわたって大幅に改善し、同製品の管理容易性を高めてきた。その結果、Oracle RACは既に主流の採用段階に入っており、実際に製品を運用している顧客数は1万5,000社以上に達している。

主要な所見

Oracleは、Oracle Database 10gおよび同11gにおいてRACの管理容易性を大幅に高めている。
RACを既に導入している企業は1万5,000社以上に上っている。
RACの主な利点には、可用性、低コストのハードウェアによる水平スケーラビリティや、グリッド内の複数のデータベース管理システム (DBMS) インスタンス間のキャパシティ共有などがある。
Oracleは、同社DBMSの主要プラットフォームとしてLinuxの利用を推進することに成功している。RACの導入基盤の少なくとも30%は、Linux上にインストールされている。

推奨事項

ビジネス・ニーズに応じたデータベースのキャパシティ共有や水平スケーリング機能を必要とする企業は、Oracle RACを検討する。
クラスタリングはシングル・インスタンスのDBMSよりも複雑であるため、RACのトレーニングや研修を受講する。
サーバ障害の発生時にトランザクションを透過的にフェールオーバーする機能を必要とする企業は、利用可能な代替RACノードにおけるトランザクションの自動処理を実現するために、Oracleアプリケーション・プログラミング・インタフェース (API) を利用してアプリケーション・ロジックを記述する。
分散型のシェアード・ナッシング環境を必要とする場合は、RACを使用しない。
小規模企業でRACの導入を検討する場合や、クラスタリングに関するスキルが十分に確保されていない場合には注意を要する。

分析

　Oracle RAC は、ディスクへの並行アクセスの共有化により、複数のサーバ・ノードにわたってDBMSインスタンスを共有するデータベース共有環境である。ガートナーでは、2003年11月に、Oracle Database 9i (9i) RACの早期採用企業における利用や実装に関する分析を行った。RACはその時点でも信頼性の高いシステムであり、スケーラビリティや可用性の向上も実現していた。しかしその一方、RACは複雑であり、十分な効果を得るには、熟練したデータベース管理者 (DBA) の確保が不可欠であった。この複雑さが、当時におけるRACの採用拡大を妨げる要因の1つであったといえる。

　RACは何度かのリリースを繰り返し、5年間で急速な発展を遂げた。Oracleは、RACの運用管理の容易性を大幅に向上させ、実装や管理に必要となるスキル・レベルを引き下げている。ガートナーは、RAC の導入によるビジネス価値や、その長所と短所を把握するために、十数社のRACユーザー (ほとんどはOracle Database 10gR2 RACを導入) にインタビューを行った。その結果、全体として、RACの導入に要する追加のソフトウェア・コストを十分に正当化できる大きな効果が得られていることが明らかになった。

　ただし、RACはあらゆるアプリケーションに適しているわけではない。そこで、本リサーチノートでは、RACを利用すべき場合とそうでない場合についてのガイダンスに加えて、RACの利点や、強みと課題に関する分析を提示する。

　2003 年末の時点で、RACを本稼働させているOracle の顧客は約1,000 社であった。現在、その数は1 万5,000社以上に達しており、RACは主流の採用段階に入っている。Oracle では、主にDellとの代理店契約を通じて、中間市場への浸透も果たしている。こうした点から、Oracle がOracleDatabase 10g (10g) の管理容易性の向上に注力したことで、複雑さという阻害要因は軽減されたといえる。RACは、Oracle がサポートしているすべてのプラットフォーム上で稼働するが、特によく利用されているのはLinux プラットフォームである。RACの実装の約30%は、Linux 上に導入されている (そして、その割合は現在も高まりつつある)。

　RACに関するOracleの主な販売方針は、OS (Red Hat LinuxのOracleによるディストリビューションであるOracle Enterprise Linux) を含めて、完全に統合されたソフトウェア・スタックを販売することである。RACのライセンス価格はシングル・インスタンスのDBMSよりも50%高額であるが( http://www.oracle.com/corporate/pricing/technology-price-list.pdf )、RACの利点に加えてハードウェア・コストの削減を考慮すれば、十分妥当な価格設定であるといえる。

2003年以降のRACの改善項目

■ グリッドの発展

　9iでは「独立した」RACインスタンスが使用可能であったが、10gでは、そうした個別のRACインスタンスを互いに結び付けた1つのグリッドが形成されるようになった。Oracleでは、「サービス」と呼ばれる概念により、すべてのノードを任意のサービスに割り当て可能にするとともに、予備を含むキャパシティをデータベース間で共有できるようにしている。Oracle は現在、サービスをRACデータベースとして定義しているが、同社には、データベース層だけでなく、アプリケーション・アーキテクチャのあらゆる階層をサービスという概念に取り込もうという構想がある。

■ すべてのプラットフォームでOracle Clusterwareをサポート

　9i では、Oracle Clusterware を利用できるプラットフォームがWindows とLinux に限られていた。10gでは、このテクノロジのサポートを他のプラットフォームにも拡大している。Oracleは、2003年にTruCluster のソフトウェア資産を買収し、それを基盤としてOracle Clusterware を実装している。このため、RACではなく、フェールオーバー機能を備えたシングル・インスタンスのデータベースを必要とする顧客も、サードパーティ製のクラスタリング・ソフトウェアを使用する必要はなくなっている。ただし、Unixプラットフォームでは、現在も必要に応じてサードパーティ製クラスタリング・ソフトウェアの実装が可能である。一方、RACをWindows やLinux で使用する場合、Oracleがサポートするクラスタリング・ソフトウェアは自社製品のみである。

■ Automatic Storage Management

　10gでは、シングル・インスタンスのデータベースとRACのクラスタ化データベースに対応するグリッド・ボリューム・マネージャを提供する無償オプションとしてAutomatic Storage Management(ASM) が追加された (RAC では、自身のアーキテクチャに基づいてASMを利用し、クラスタ・ボリュームを管理する)。ストレージ管理者がASMに対して論理ユニット番号 (LUN)、つまり論理ストレージの割り当てを指定すると、データベース・ストレージ用の共有ストレージ・プールが作成される。ASMには、ストライピング機能やミラーリング (2重化および3重化) 機能がある。また、DBAの指定に応じて、ダウンタイムなしでプールからデータベースにストレージを追加することも可能である。

　ASM を利用すると、ストレージ・スペースの割り当てやパフォーマンス・チューニング ( パフォーマンスを最適化するためにデータをどこに配置すべきかの決定) がソフトウェアによって自動的に行われるため、DBAがストレージ管理に費やす時間が短縮される。また、サードパーティ製のファイル・システムやボリューム・マネージャの必要性が低下するため、ASMを導入しているユーザーは、ソフトウェアや保守に伴うコスト全体を削減できる。ASMは、ストレージ・エリア・ネットワーク (SAN) やネットワーク接続ストレージ (NAS) にも対応している。Oracleは、これまでサーバへのハードウェア投資を軽減することでRAC導入の合理性を高めてきたのと同様に、RACとASMを正当化する要素として、低コストな共有ストレージの利用を提唱している。

■ 管理容易性

　Oracleは、10gの管理容易性を高めることでDBAの労働時間を短縮している。ただし、10gでは、DBAの労働時間が9i RACよりも25～50%短縮されたものの、シングル・インスタンスのシステムと同様にクラスタを管理できる水準には達していなかった。そのため、Oracle は、複数のデータベースを単一ビューから管理する機能を10gに追加している。これにより、1つのクラスタ全体、1つのデータベース、特定のインスタンスに対して、単一のコンソールからコマンドを実行できる。

　Oracleは、10gにタスクの自動化機能を組み込み、ワークフロー・エンジンによるタスクの実行とロールバックを可能にしている。同社が「グリッド・コントロール」と呼ぶこの機能は、Oracle Enterprise Manager によって実現されている。そのほかにも、インストール時間の短縮やセルフチューニング機能の拡充 (ストレージ・パフォーマンスや共有メモリの自動チューニングなど)、根本原因分析に役立つプロアクティブな診断機能の追加といった改良が行われている。Oracle Database 11g (11g) では、Automatic Database Diagnostic Monitor (ADDM) がRACクラスタに対して実行されるようになり、複雑さや、RACの管理に求められるスキル要件が緩和されている。

■ 計画ダウンタイム

　10g RAC では、アプリケーションを停止することなく、グリッドに対してローリング方式によるパッチやOS／ハードウェアのアップグレードを実行できるが、ローリング・アップグレードはサポートされていない。11g では、ASM のローリング・アップグレードおよびパッチのサポートが追加された。Oracle では、DBMSのローリング・パッチをサポートしているとはいえ、パッチの性質によっては、適用するためにダウンタイムを設けなければならない可能性が常に付きまとう。

　RACでは、クラスタ・ノードで障害が発生したときに更新トランザクションを透過的にフェールオーバーする機能がサポートされていない。データベースのクラッシュを切り抜けるように作成されていないアプリケーションでは、再起動と再ログオンが必要になる可能性がある。データベース・サーバの障害をアプリケーション側で認識して対処するには、稼働中の他のノードに接続し直し、失われたトランザクションを再実行するというロジックを開発者が記述しなければならない。そのため、独立系ソフトウェア・ベンダー (ISV) のアプリケーションでは、RACがサポートされていない場合もある。

RAC導入の目的と利点

　RACを利用すると、クラスタ内のサーバやデータベース・インスタンスで障害が発生したときに60秒未満でフェールオーバーを実行できることから、2003年当時の早期採用企業は、主に可用性の向上のためにRACを導入していた。可用性の向上が期待できる点は現在も変わりないが、現在のほとんどのユーザーは、スケーラビリティと柔軟性の向上を目的としてRACを導入している。RACでは、スケールアウト・アーキテクチャによってスケーラビリティを向上させており、(対称型マルチプロセシング [SMP] システムによる垂直スケーリングに対して) 低コストなハードウェアによる水平スケーリングが可能であり、(将来のニーズを見越してハードウェアを購入しなければならないシステムとは対照的に)ビジネス・ニーズの高まりに応じた柔軟な投資を行うことができる。

　10g のグリッドには多数のクラスタ・ノードを取り込めるため、任意のデータベース・インスタンスを任意のノード上で実行することで柔軟性の向上を実現できる。例えば、計画ダウンタイムのために特定のノードを停止させる必要がある場合は、データベースへの要求をクラスタ内の他のノードに分散させて処理できる。あるノードで実行されているインスタンスを別のインスタンスに切り換えることも可能である。また、特定のアプリケーションによる負荷が増大し、キャパシティを増やす必要がある場合には、DBAがグリッド内の新たなノードでデータベースを起動することによってキャパシティを追加することも可能である。

　Oracleの顧客は、具体的な利点として以下を挙げている。

インフラストラクチャやストレージの共有：ASMによって柔軟性と管理容易性が向上するため、複数のサーバ・ノードで構成される単一クラスタ内で、さまざまなデータベースを管理できる。各ノードで任意のデータベース・インスタンスを実行することが可能である。RACでは、水平的なスケールアップ／スケールダウンが可能であるため、DBAがキャパシティの増減をスケジュールしたり、手作業で開始したりすることによって、キャパシティをデータベースごとに最適化することができる。この結果、データベース・インフラストラクチャの孤立によって発生する過剰なプロビジョニングが削減される。また、9iでOracle Cluster File System (CFS) を利用した顧客は、ASMによる管理作業が容易であり、各インスタンスへのストレージ割り当てに伴う煩雑さが軽減されることを指摘している。
アクティブ／アクティブ・モードによる処理：：RACでは、アクティブ／パッシブ・モードではなくアクティブ／アクティブ・モードにより、確保されているキャパシティを最大限に活用できる。
水平スケーラビリティと低コストなx86サーバ：RACを使用している顧客の多くは、Unix の高価なSMPシステムよりも、低コストなx86サーバを利用した方が合理的であるという点で、グリッドの概念に賛同している。Oracleの多くの顧客は、RACの採用を決定した主な動機として、ビジネスの成長に沿った水平スケーリングが可能である点を挙げている。グリッドに新たなノードを追加し、合計10ノード～18ノードの構成にすることで、80%以上のスケールアップが可能であるという指摘もあった。
計画ダウンタイム：インスタンスを別のノードに移行し、ユーザーに影響を与えずにハードウェアやOSの保守を実施できる。
計画外のダウンタイム：フェールオーバーに要する時間は通常、1分未満である。ただし、アプリケーションのタイプによっては、フェールオーバー時間の測定結果が数十秒になった組織もある。フェールオーバー発生時にも、クエリ・トランザクションはクラスタ全体で保護されるため、ユーザーが再入力する必要はない (更新トランザクションは再入力が必要)。
9i RACの管理と比べてDBAの作業時間を最大50%短縮する効率性：DBAがノードのプロビジョニングをより迅速に実行できる上に、従来よりも少人数でストレージの管理や実行環境のチューニングを実施できる。
統合された単一ソフトウェア・スタック(RAC DBMS、ASM、Grid Control)のワンストップ・サポート：ガートナーが話を聞いた顧客は、RAC環境に対するOracleのサポートが優れている点を例外なく指摘している。こうした顧客は、OSのサポートについては依然としてOS提供元のサービスを利用しているが、Linuxを使用している顧客は、OSの面でもOracleにかなり豊富な知識があり、それがサポート対応に生かされている点を指摘していた。そのような点を踏まえて、一部の顧客は、OracleのLinuxディストリビューションの採用を検討していた。統合されたソフトウェア・スタックには、クラスタリング、ファイル・システム、診断などのツールに必要なサードパーティ製ソフトウェアを削減する効果もある。

課題

OracleはRACの複雑さを軽減しているものの、クラスタリングには依然として複雑さが伴い、専門的なDBAと、システム管理に関するスキルやトレーニングが必要である。
RACに関する顧客のフィードバックは、おおむね好意的であったが、モニタリングおよび管理機能のグラフィカル・ユーザー・インタフェース (GUI) が不完全であるという根強い不満も見られた。そのような意見の多くでは、プラットフォーム間の一貫性が欠けていること、タスクや最適化の可能性について十分にきめ細かい情報が提供されていないことが指摘されていた。11gではGUIが大幅に改善されている。
RACでは、単一の共有データベースを使用するため、そのデータベース部分が単一障害点となる。データ破損、クラスタ障害、サイト障害などのリスク・シナリオに対処したり、ダウンタイムなしでバージョンのアップグレードを行ったりするには、リカバリ戦略が不可欠である。Oracleは (10gおよび11gで) これらの問題を解決するために各種のソリューションを提供しているが、特に中堅・中小企業やRACを初めて利用した顧客では、それらのオプションを十分理解していないケースが見受けられた。
現時点で、グリッドの規模をどこまで拡大できるかは不明である。ガートナーがインタビューで確認した最大のグリッドは、18ノードの一次サイト (8つのデータベースが稼働) と18ノードの災害復旧サイトという構成である。Oracleは、1クラスタ当たりの最大ノード数が現時点で32個であることを明らかにしている。グリッドの拡大に従って、どのような管理上の影響が現れるかは不明確である。
ASMは、ストレージに関する見通しを立てる役割をストレージ管理者から奪い、それをDBAに譲り渡してASMによって管理するという点において、ストレージ管理者に意識改革を迫ることになる。ASMの最初のバージョンである10gR1には多数のバグが見られたが、10gR2ではレポートが大幅に改善されている。ASMに関するトレーニングを実施しているのはOracleのみであるが、DBA自身がストレージを管理するためにはトレーニングへの参加が欠かせない。
ASMとCFSには機能の混乱が見られる。9i RACでは、ロー・パーティションあるいはCFS (WindowsあるいはLinux版のみ) が提供されていたが、いずれも管理容易性の観点から見ると欠点があった。CFSは、10gでも引き続きサポートされているが、Oracleデータベースに関する同社の戦略的方針に沿った製品はASMである。しかしながら、これらの製品は、どのような場合にどちらを使用すべきなのか、また、どのような場合に両者を併用すべきなのかという点で顧客に混乱を与えている。つまり、ASMはバイナリ・ファイルの共有をサポートしていないのにCFSではサポートしている点や、ASMがロー・ディスクにアクセス可能でパフォーマンスに優れているのに対し、CFSは管理が容易できめ細かい処理の実行に強みがあるといった点が、混乱の原因となっている。
RACは、クラスタ・ノードの障害発生時に更新トランザクションを透過的にフェールオーバーする機能を備えていない。多くの場合は、中間層のアプリケーションを再起動して、クライアントを別のノードに割り振る必要がある。このようなフェールオーバーを実現するには、アプリケーション開発者がクラスタとクライアントのAPIを記述しなければならない。そのため、ISVの一部のアプリケーションではRACがサポートされていない場合がある。
Oracleは、改良された構成管理機能 (プロビジョニング、クローン作成、パッチ適用) を追加している。これらの機能を利用するには、プロセッサ・ライセンス当たり3,500ドルの追加費用を負担して、2種類のOracle Management Packを購入する必要がある。この点については、これらの機能がもたらす利点から見ると、あまりにも高額であることが顧客から指摘されている。RACでは、DBMSを別のノードで継続的に稼働させることができるが、パッチを適用するには、依然としてノードのダウンタイムを設けなければならない。
RACには、キャパシティを動的に増減させる機能がなく、キャパシティの変更はDBAがスケジュールするか、手動によって開始する。

教訓

バイナリをCFS 内に配置すると、クラスタ内の任意のノード上で任意のデータベースを稼働させることが可能になるが、SANの障害発生時にクラスタ全体のダウンタイムが生じる危険性もある。
ASMでディスクのロード・バランシングを効果的に行うには、LUNのサイズを標準化する必要がある。
例えば、クラスタ機能のテスト、フェールオーバー、パッチのテストを行う場合には、(品質保証後の) 認定環境が必須となる。
ノード障害を中間層に通知し、ユーザーに障害の発生を意識させないようにするには、Oracle APIを使用する。これにより、中間層で何分間もかけて再起動を行う必要がなくなる。
ASMでマルチパス化機能をテストするとともに、ストレージ・ベンダーがASMをサポートしていることを確認する。
サードパーティ製ソフトウェアについては、RAC認定の有無を確認する。
低遅延が求められるアプリケーションの場合は、Oracleのログを高速なディスク上に配置する。
RACを利用して高可用性、連続稼働、災害復旧ソリューションを完全な形で実現するには、データベースの冗長性をアーキテクチャに組み込む。
RACは、あらゆる環境に適しているというわけではない。小規模な組織でクラスタリングのスキルを確保できない場合、RACの採用は慎重に検討すべきである。

ガートナーの結論

Oracleが10g RACの管理容易性を大幅に向上させた結果、同製品は既に主流の採用段階に入っている。IT部門が、データベースの水平スケーラビリティに加えて、以下のような目標を実現しようとする場合には、RACの評価を行うべきである。

インフラストラクチャを共有する機能により、1つのクラスタ内でさまざまなデータベースを稼働させる柔軟性を確保する。
遊休状態／パッシブ状態のリソースを削減する。
ノード障害発生時のフェールオーバー時間を短縮する。

ただし、IT部門では、クラスタリングによって運用環境の複雑さが高まることを理解するとともに、RACを安易に導入することは避けるべきである。Oracle 10g および11gで管理容易性が大幅に向上しているとはいえ、RACで成果を挙げるためには、ユーザーを本格的なトレーニングや研修に参加させる必要がある。

推奨リサーチ

「データウェアハウス向けデータベース管理システムのマジック・クアドラント：2008年」
(APP-09-23、2009年3月19日付)
「Choosing the Appropriate Database Management System Platform for SAP」
「What Oracle's U.S. Price Increases Mean to Your Organization」

(監訳：堀内秀明)

このページのトップに戻る

本レポートの内容は、一般に入手可能な情報、および当該各社、各機関の責任者によって公開された情報をガートナーの解釈・分析に基づいて表現したものですが、その正確度・完璧性に関しては免責とさせていただきます。
本レポートの中には、ガートナーがその顧客から非公開資料として入手したものは含まれません。また、本レポートに記載されている会社名および製品名は、各社の商標もしくは登録商標です。