クラスタ・ソフトを使ったActive/Standby型の冗長化構成以外にも，ダウンタイムを同等以上に抑えられる仕組みがいくつかある。これらを利用すれば，クラスタの落とし穴をいくつか回避できる。
一つは，米Oracleの「RAC（Real Application Clusters）」である。RACは，複数サーバーでOracle DBを実行し，全サーバーをActiveとして利用するActive/Active型のクラスタ・システムだ。複数サーバーでDBのテーブルを共有した状態で運用するため，「共有ディスクが見えないといった従来のクラスタ・システムでの問題を解消できる」（伊藤忠テクノサイエンス 東氏）。
RACでもActive/Standby型と同様にクラスタ・ソフトを利用するが，ハートビートによる障害監視の対象はハードに限られる。Oracle DBの死活監視は，クラスタ・ソフトではなく，Oracle DB自身が受け持つ。「クラスタ・ソフトを使った場合と比べて死活監視が正確になる。従来のように，過負荷状態を障害とみなしてしまうようなトラブルは極めて少ない」（同氏）。
導入企業は徐々に増えており，「ダウンタイムをActive/Standbyより短縮できたほか，5台のサーバーで4.8台分のスケーラビリティを得られた」（楽天トラベル 金住氏）と導入企業の評価は上々である。その一方で，ライセンス料がActive/Standbyより割高になるなどの理由から「導入に二の足を踏むユーザーが少なくない」（日立情報システムズ 治田氏）のが実情だ。
ディスク障害に備える
もう一つ，クラスタの代替技術として最近注目されているのがデータベース・レプリケーション機能を応用した耐障害技術である。ディスクを共有しないレプリケーション（複製）を使うことで，従来のクラスタ・システムで起こりやすい共有ディスク関連のトラブルを減らせる。
 図6●ディスク障害に備え，Data Guardを利用する楽天トラベル ディスク障害や災害に備えて，Oracle9i DatabaseのData Guard機能を使って，データを同期させている。万一現用ディスクに障害が発生したら，ディスクを手動でマウントし直したり，クライアントが接続するサーバーを切り替えたりして業務を継続する [画像のクリックで拡大表示] |
 表2●レプリケーションを応用したRDBMSの高可用性機能 [画像のクリックで拡大表示] |
 図7●RDBMSが提供するレプリケーションによる耐障害性向上機能の概要 通常運用時，ActiveからStandbyに更新データを送信。Standbyはその情報をデータベースに書き込む。監視サーバーがActiveとStandbyの稼働状況を確認し，Activeに障害が発生したらStandbyをActiveに昇格させる。クライアントはStandbyに自動的に接続する。図はSQL Server 2005の例 [画像のクリックで拡大表示] |
楽天トラベルは，Oracle9i Database Enterprise Edition（EE）が備えるデータベースのレプリケーション機能「Data Guard」を利用して，サーバーの耐障害性を高めている（図6[拡大表示]）。この仕組みにより，現用ディスクに障害が発生しても，常に同じデータを保持する予備ディスク（データベース）に切り替えれば処理を続行できる。「切り替え時間は最大でも5分」（金住氏）という。
このようにデータベースのレプリケーションはディスク障害時の対策として有効な手段だが，RDBMSがサーバーの監視機能や自動切り替え機能を備えていないことが課題だった。「障害が夜間などに発生したときのことを考えると，切り替え処理は自動化したい」（イー・マーキュリー 開発部 バタラ ケスマ氏）という声が多かった。同社も耐障害性向上のためにMySQLのレプリケーション機能を利用しているが，障害発生時は手作業でサーバーを切り替えている。
商用RDBMSが相次ぎ自動化に対応
こうしたニーズにこたえて，サーバーの切り替えを自動化できるレプリケーション機能を商用RDBMSが備え始めた（表2[拡大表示]）。
2004年9月にリリースされたDB2 UDB V8.2と来年前半に出荷予定のSQL Server 2005では，死活監視機能や自動切り替え機能＊5が追加された。Data Guardも「今後，サーバーの自動切り替えに対応する方向」（日本オラクル マーケティング本部 担当マネジャー 山本哲也氏）としている。
データ同期の基本的な仕組みはどの製品もほぼ同じである。更新データや更新ログをStandbyに送信し，その情報を基にStandbyのデータを更新する（図7[拡大表示]）。両サーバーのデータベースが更新された段階で，クライアントに通知するため，1台のDBサーバーで運用するよりも応答性が若干落ちる＊6。例えばDB2の場合，2分程度のバッチ処理をテストした結果，レプリケーション機能を使わない場合と比べ，「応答速度が約10％落ちる」（日本IBM ソフトウェア事業部 ソフトウェア テクニカル・セールス＆サービス IMテクニカル・セールス＆サービス ICP・コンサルティング ITスペシャリスト 出羽奏太郎（いずはそうたろう）氏）。
これらの機能を使う場合の注意点は，RDBMSのライセンス料がActive/Standby型のクラスタ・システムと比べて割高になる場合があること。OracleとSQL Server 2005の場合，ActiveとStandby側にそれぞれCPUやユーザー数に応じたライセンス料が必要になる＊7。DB2 UDBはクラスタ・ソフトを使った通常のActive/Standby構成と同じく，Standby側のライセンス料は1CPU分である。
