可用性まとめ
可用性の概要をまとめました。
今後はもう少し技術的に突っ込んだ領域に踏み込んでいきたいところですね。
続編も追々、書いていきます。
■可用性まとめ
可用性とは
DBシステムで可用性が低い理由
可用性と予算の関係性
DBシステムの高可用性構成概要（Active/Standby） その1
DBシステムの高可用性構成概要（Active/Standby） その2
DBシステムの高可用性構成概要（Active/Active） その1
DBシステムの高可用性構成概要（Active/Active） その2
GRID(2)
複数のマシンで1つのデータベースを構成する際に致命傷となる点があります。
マシンは複数なのに対し（厳密に言えばインスタンスが複数）、データベースは1つであるということは、必ずデータの競合が発生し得るという点です(データは1箇所しかないため)。
これは至極当たり前な意見ですが、果たしてこの点を意識してRACシステムを構築している人が、世の中にどれだけいるのでしょうか。
私が知る限り、ほとんどそういう方と出会った事がありません。
もちろん複数マシンから同一データへアクセスする際に競合がおきにくいようなアーキテクチャも用意されています。例えばASSM(AutoSegmentSpaceManagement)という機能は、同一データへの同時INSERT処理があっても競合を回避できるような機能です。
しかしASSMを採用するとINSERT/DELETEの競合で処理が遅くなるということを知っている人はどれだけいるでしょうか。
また同一データを複数マシンで共有しなければならないため、どうしてもマシン間の連携が必要となります。
結局、この辺りはいくら技術が進化しても100%解消することはできない部分であるわけです。
これに対して、例えばDB2が採用してきた形は複数マシンで複数のデータベース(これも厳密には違います)を保持し、データを分割することによってデータの競合を排除するアーキテクチャです。
これによりデータの競合は解消します。
しかし、アプリケーションを開発する側としてはデータが均等に各マシンに割り振られ、ある程度均等に負荷が分散するように設計を意識する必要があります。これをサボってしまうと負荷か偏ってしまい、パフォーマンスの劣化を招いてしまいます。
つまり、いくら技術が進化しても解消しない問題というのは必ず存在するものなのです。
各ベンダーは都合の良いことばかりいいますが、もし都合の良い提案ばかりをされた場合は、上記の部分について突っ込みを入れてみてはいかがでしょうか。
GRID(1)
2年ぐらい前になるでしょうか、ORACLE社がしきりに
「これからはグリッド・コンピューティングの時代だ」
と訴えていた事がありました。基本的に今もそれは変わっていないんじゃないかと思います。
グリッドはそのまま和訳すると、格子。イメージとしては、縦と横の線を何本が引いたようなもの。この交わるところがコンピュータだと想像してみてください。ここからグリッド・コンピューティングとは、
ネットワークを介して複数のコンピュータを結ぶことで仮想的に高性能コンピュータをつくり、利用者はそこから必要なだけ処理能力や記憶容量を取り出して使うシステム
という意味になります。
もっと簡単にいうと、
複数のコンピュータで巨大な1台のコンピュータを構成すること
と言い換えてもいいかもしれません。
実際、ORACLE社が提供する高可用性システム用のオプションとして、Real Application Clusters(RAC)というものがあります。これは複数のコンピュータで1つのデータベースシステムを構成するためのオプションです。
私が知る限り、2台から4台程度で1つのデータベースシステムを構成することが多いようです。
（コマーシャル的には12台云々とかという話もあるようですが、そんな台数あったら管理できるわけありませんよ。いくらGUIツールが用意されたからといっても）
この構成が本当に高可用性なのかどうか、これは一旦片隅においておくとして、複数台のコンピュータで1つのデータベースシステムを構成することが出来るのは紛れもない事実です。
例えば2CPUのマシン4台でRAC構成を組むとすると、論理上は1つのデータベースに対して8CPUで処理していることと同じです。
ブレードサーバの台頭と相まって、この構成が世に出され、実際に多くの企業でRAC構成のシステムが構築されるようになってきました。恐らくORACLE社がいうグリッドの時代というのは、それほど間違ってはいないようです。