シェアードディスク型について

Question

「達人に学ぶDB設計徹底指南書」という本を読んでいます。
その本の中に次のような記述がありました。

データーベースのクラスタリング設計に関しての記述で、Active-Standby方式とActirve-Active方式の二つの方式を説明しています。
Active-Standby方式では、通常、動いているのは現用系だけで、もう一方の待機系は全く処理をしません。ただ、現用系に障害が発生した場合には待機系に置き換わり、少ない停止時間でシステムが復旧できるという利点があります。
いまいちわからないのは次のActive-Active系におけるシェアードディスク方式についてです。

「いずれにせよ、Active-Standby方式というのは、基本的にサーバ2台で構成し、しかも動いているのは１だいだけなので、性能はスタンドアロンと変わりません。これにプラスして性能の向上も目指した方式が、Active-Active方式です。名前の示すとおり、この構成では待機系というサーバーは存在せず、すべてのサーバーが現用系です。したがって、処理を各サーバーに分散することができ、かつ台数も（理論的には）特に限定せず増やしていくことができるので、信頼性のみならず性能的にも有利な方式と言えます。
まず一つ目がシェアードディスク方式です。これはディスクだけをサーバー間で共有して、CPU、メモリ、ネットワークと言った資源は分離する構成です。この方式の利点は、どのサーバからも共通のデータを参照・更新することができるため、どのサーバに障害が発生しても、残りのサーバで処理を継続することができるという柔軟性にあります。一方で、共有資源となるディスクがボトルネックポイントになりやすく、それが原因でサーバー台数を増やしても性能向上が頭打ちになってしまう、という欠点があります。
また、このシェアードディスク方式をサポートしているDBMSは、本書の執筆時点ではOracleとDB2だけです。「え、二つだけなの？」と思うでしょう。このActive-Active方式は、Web/APサーバーのクラスタリングとしては非常にポピュラーなのですが、DBサーバでは難しいのです（この難しいというのはベンダーとシステム開発者の両方にとってです）。それは、基本的にWeb/APサーバが次にいられるシェアードナッシング方式で十分要件を満たせるのに対し、DBサーバはどうしてもシェアードディスク方式でないと要件を満たせないことが多いからです。」

最後の文章についてなのですが、DBサーバはどうしてもシェアードディスク方式でないと要件を満たせないのであれば、シェアードディスク方式でないといけないということではないのでしょうか？
お分かりの方、解説お願いします。

Answer 1

DBサーバはデータの一貫性を保つため一カ所にデータを集める必要があります。
一方、WEBサーバ・APサーバは、保存すべきデータはソースファイルだけで、ソースファイルをエンドユーザが変更することがないためリリース時にコピーするだけですみ、ディスク（ストレージ）を共有する必要はありません。
つまり、ディスク（ストレージ）を共有しない（シェアードナッシング）でも可能なので、簡単にActirve-Active方式構成にできるわけです。

Comments

[退会済みユーザー]

シェアードディスク方式でないと要件を満たせないことが多いのに、2012年時点ではその方式を実現するDBMSが二つしかないのは、その実現が難しいからなのでしょうか？

[kantomi]

シェアードディスク方式を採用するところは、ミッションクリティカルな業務システムに多いです。
保証問題が絡みますのでオープンソースでは難しく、商用RDBMSになります。
ちなみに、SQLServerはWindowsオンリーだったので、あまり巨大なシステムでは使われません。

オープンソースのRDBMSは、WEB系で多く使われ一貫性を求めず、スケールアウトして規模を拡大することが多いです。Twitterも1億ユーザぐらいまではMySQLで動いていましたが、全てのツイートが同じDBサーバで見える必要はありませんから、「シェアードディスクにしなければならない」という要望は出ないからでしょう。

[退会済みユーザー]

お返事ありがとうございます。
>全てのツイートが同じDBサーバで見える必要はありませんから
Web系といえども、データには一貫性が求められるのではないでしょうか？
例えば、Twitterでの話だと、私がフォローしている人（Aとします）を別の人がフォローしているとして（Bとします）、私のBのタイムラインはAのツイートに関しては一貫性が求められると思うのですが、どうなのでしょうか？

[kantomi]

Twitterは一貫性を犠牲にして、ディレイ更新（リアルタイムではない）にしています。
ですから、このような障害が起きます。
http://twinavi.jp/topics/it/54ab5228-c2a0-4759-ab30-35abac133a21

RDBMSなら、オールオアナッシングになりますから、障害時は全く書き込みできず、数がズレるというようなタイプの異常は発生しません。

[退会済みユーザー]

何度もすいません。
TwitterはRDBMSを使ってないのでしょうか？
新たなツイートを一つのDBに格納するスタイルだったが、ハッシュ値により分散するシステムに変更したというのは知っていますが、この変更とは別の話をされているのでしょうか？

[kantomi]

前に書いた通りです。
いずれにしても、完全な一貫性は持っていません。
完全な一貫性を持たせようとするシステムは、シェアードディスクのタイプを求めるだけの話です。
棲み分けができているのに、わざわざ作る必要はないでしょう。
あなたは一体何を知りたいの？

[退会済みユーザー]

最初は「なぜシェアードディスク型でないといけないのか」といったことを疑問に思い、質問していましたが、途中Twitterの話が出てきて、それについてあなたが書いたことがよく理解できなかったので、質問しております。
「ディレイ更新」について検索してみましたが、データベースに関連するような記事というのは見つけることができませんでしたので、教えていただけると、助かります。

[kantomi]

おそらく、今はもっとスマートになっていると思いますが、

http://www.atmarkit.co.jp/news/201004/19/twitter.html

"　1つは「fan out」と呼ぶメール配送に似たアーキテクチャを使うこと（fan outは漢字で書くと“扇出”か。風で一気にまき散らすようなイメージ）。各ユーザーのタイムラインをメールの受信箱のように見立てて、そこにメッセージを配信する。つぶやきはいったんmemcachedに保存され、それが各受信箱（タイムライン）に送られるが、その配送処理は非同期のオフライン処理だという。ただ、オフラインといっても夜間バッチのような半日単位というものではなく、秒単位の遅延を上限としたものであるという。"

秒単位の遅延処理なんです。

[退会済みユーザー]

回答ありがとうございました。