| エンタープライズ：コラム | 2003/05/28 15:29:00 更新 |
Gartner Column：第94回 オラクルのRACは「本物」のクラスタ
コンピュータのデザインとは、音速で飛ぶジェット機とはいはいをする赤ん坊の同期を取るのに似ているという。つまり、キャッシュ技術が重要ということだ。クラスタでサーバが複数台になるとキャッシュの管理もさらに複雑になる。Oracle9i RACは、その問題の解決に真面目に取り組んだ製品のひとつだ。
今回は、前回のコラムで説明し切れなかったオラクルのOracle9i RAC（Real Application Clusters）について説明しよう。RACは、トランザクション処理に向いたクラスタを真面目に実装した数少ない製品のひとつであり、その真価は今後、時間を経るにしたがってさらに明らかになっていくだろう。
だいぶ昔になるがコンピュータシステムの設計とは、「ジェット機と、はいはいをする赤ん坊の同期をどうやって取るか」を考えているようなものだというコラムを読んだことがある。つまり、CPUの計算速度とI/O速度の極めて大きな相違をどう吸収するかが、システム作りの最大の課題であるということだ。
ここで極めて重要となるテクノロジーがキャッシュである。必要とするデータをできるだけ高速な記憶域にコピーして保持して置くことである。DBMSにおいてもキャッシュを活用して、できるかぎりメモリ上で処理を完結し、ディスクI/Oを最小化することが性能向上の最大のキーである。キャッシュのヒット率が1％違うだけでもシステムの性能は大きく変わる。
ここで、複数のサーバで並列的にデータベース処理を行っている場合には、キャッシュの管理はさらに複雑になる。複数の独立したサーバ機上でキャッシュされている共用データの複数コピーのひとつに変更が加えられたときに、ほかのコピーとの整合性を取る手段が必要となるからである。
RACのテクノロジーとしてのポイントは、このコピー整合性の確保の方式にある。いわゆるリソース共用型クラスタと呼ばれる方式である。その優位性を示すために、ほかのアプローチについても簡単に説明していこう。
シェアードナッシング
共用データの問題を解決するためには、何も共用させなければいいではないかというアプローチである。つまり、各サーバが独立したDBMSインスタンス、キャッシュ、データベースを稼動する構成である。
データベースを各サーバごとにきれいに分割できるタイプのアプリケーションであれば、シェアードナッシングのシステムはうまく稼動する。しかし、現実のトランザクション処理では制御テーブルなどの共用データが必要となることが多いし、各サーバに均等に負荷がかかるようなデータベースの分割を行う作業は負担が大きい。
シェアードナッシング型の並列データベースは、データウェアハウスなどの読み取り中心型アプリケーションであれば十分対応可能だ。しかし、現実の複雑なトランザクション処理で高いスケーラビリティを達成するとなると、不可能ではないにせよ結構手間がかかるのである。
従来型クラスタ
クラスタ構成、つまり、共用ディスク型の構成ではキャッシュ中のコピーの整合性を取る必要がある。Oracle9i RACの一世代前にあたるOPS（Oracle Parallel Server）のような従来型クラスタでは、あるシステムでキャッシュが更新されると、どのブロックが更新されたかの情報がほかのシステムにネットワーク経由で伝えられるようになっている。ほかのシステムは、自分が抱えているキャッシュ内のそのブロックはもう古くて使えないことが分かるので、それを無効にする。そのデータが後に必要になったときにはディスクから読み込み直さなければならない（その前に、キャッシュを更新した側のシステムがキャッシュ内の更新されたブロックの内容をディスクに書き戻しておくことも必要である）。
つまり、せっかくキャッシュしていたデータもどれかひとつのシステムが更新を行っただけで無駄になってしまい、ディスクI/Oをせざるを得ないいうことである。
共用データへの更新が頻繁に行われるアプリケーション、要するに一般的な大規模トランザクション処理やERPなどのアプリケーションパッケージではこのオーバヘッドはかなり大きい。性能を上げようと思ってクラスタにサーバ機を追加しても、かえって性能が低下してしまうこともあるくらいである。
従来型クラスタは高可用性向けソリューションとしては十分かもしれないが、スケーラビリティソリューションとしてはちょっと無理があったのである。
リソース共用クラスタ
従来型クラスタではキャッシュが更新されたという情報だけがシステム間でやり取りされていた。ここで、更新されたという情報だけではなく、更新されたデータそのものもディスクに書き戻すことなく、直接ネットワーク経由でやり取りしてしまえばいいではないかというアイデアが生まれても当然だろう。Infinibandなどの高速なサーバ間接続テクノロジーが出現している現在、特にこれは言える。
これがリソース共用クラスタである。リソース共有型クラスタでは、更新される共用データもディスクを介すことなく整合性を確保でき、複数のサーバが自分のキャッシュ上のデータを直接アクセスできるので、現実のトランザクション処理におけるスケーラビリティは大きく向上する。結果的に、複数のサーバを組み合わせて、あたかも巨大なサーバ上で1つのDBMSを稼動しているかのようなイメージで使えるようになる。つまり、シングル・システム・イメージが提供されるわけである。
リソース共用クラスタに該当する製品にはRACのほかにメインフレーム環境の並列シスプレックスがある。両者の大きな違いは、RACではキャッシュが各サーバに分散されているの対して、並列シスプレックスでは結合機構と呼ばれる専用ハードウェア上でグローバルなキャッシュを管理している点である。
リソース共用型クラスタの考え方は口で言う分にはシンプルであるが、実装はそう簡単ではない。特に、ロッキングの問題やエラー時のリカバリーの問題が結構厳しい。しかし、RACの本番稼動事例もかなり増えてきており、そろそろ先進的ユーザーでなくとも安心して使える段階にきているようだ。
また、共用データのキャッシュ整合性確保のオーバーヘッドがゼロというわけではないので、特に、特定の共用データ（いわゆるホットスポット）が頻繁にアクセスされるようなタイプのアプリケーションではスケーラビリティが限定的になる点にも注意すべきだ。100台のサーバを使えば100倍の性能が達成できるかというとそういうわけではない。
RACは、クラスタのあるべき姿をそのまま実装したテクノロジーであると言えるだろう。現段階ではどちらかというと高可用性を目的とした事例が多いようだが、ガートナーは2006年までにRACユーザーの90％が高スケーラビリティを目標とした展開を行うようになると予測している。特に、ERPなどのエンタープライズ・アプリケーション・パッケージを利用する大規模環境ではRACは魅力的である。このようなアプリケーションは、前述のように共用テーブルへの更新が頻繁に行われる（つまり、シェアードナッシングや従来型クラスタでは対応しにくい）設計が行われているのが通常だからである。
関連記事
Gartner Column：第91回 いいとこどりアーキテクチャのNUMAとRACGartner Column：第88回 大型サーバは死せず
[栗原 潔，ガートナージャパン]
