DBシステムの高可用性構成概要（Active/Active） その2
この Active / Active構成について特徴を考えてみましょう。
1.可用性レベル
全てのマシンがActiveであるため、可用性としては2007年3月時点では最高レベル（※）にあるといえます。
（※）ORACLE社とIBM社でこの最高レベルの可用性構成が異なります。
この点は機会があればお話しします
どちらかのマシンがダウンしても、残りのマシンが稼動しています。
ここがHA構成との決定的な差で、つまり「切替」を基本的には意識する必要がないわけです。
ここでいう切替とは、生き死にを確認し、切替を行うべきかどうか判断し、実際に切替を行う処理。
これが基本的には意識しなくても良いという意味です。
（アプリケーションレベルの切替は意識する必要がありますが、これはまた今度書くことにしましょう）
アメーバブログさんがこのActive / Active構成なのかどうかは知りませんが、多くの止めることが許されないシステムにおいて可用性が最高レベルであるこの構成が採用されています。
ただし、あらゆる階層において”多重化”している事が前提です。
この詳細も機会があれば今度まとめてみることにしましょう。
2.拡張性
この構成のもう1つの技術的特長は、拡張性が高いという事です。スケーラビリティが高いとかという場合もあります。
例えば2台のマシンがあったとします。各マシン共に 4CPU/4GB Memory だとしましょう。
この場合各構成により使用可能なリソース（今回はCPUとメモリ）は以下のようになります。
・Active / Active構成
使用可能なCPU
4 + 4CPU
使用可能なメモリ
4 + 4GBMemory
・Active / Standby構成
使用可能なCPU
4CPU
使用可能なメモリ
4GBMemory
当たり前ですが、Active / Active構成の方が使用可能なリソースが多い事が確認できます。
（厳密に言えば、何％分かはRAC構成を組む事により劣化します）
より多くのリソースが使用可能なわけであり、更にマシンを追加すれば、その分使用可能なリソースが増加します。
そういった意味で拡張性が高い、といえるわけです。
3.費用
想像するまでもないかもしれませんが、用意するマシン分の費用が必要となります。
しかもHA構成と異なり、ソフトウェアのライセンスもマシン分きっちり徴収されますので、非常に費用が高くなってしまいます。
これは最高レベルの可用性を維持するために必要なコスト、と考えるしかないでしょう。
更に、少しだけ前段でも述べましたが、基本的に全ての階層を多重化する必要があるため、ハード機器面でコスト上昇が発生しますし、ソフトウェア面でも本当に1箇所で障害が起きても問題ないことを確認するテストが必要となります。
これで更にコストが上昇します。
現行ではこのコスト上昇はやむを得ない、と言わざるを得ないでしょう。
4.その他
細かいアーキテクチャは後日お話しするとして、Active / Active構成の場合は、複数のマシンが1つの同じDISK領域にアクセスする形になります。
実はこれは単純には出来ません。
複数のマシンが同じ領域を見る、ということは簡単に言えば会社共有のファイルサーバへのアクセスを想像してもらえれるとわかりやすいかもしれませが、要は”排他制御”が必要となるわけです。
単純に誰かが書いていればファイルロックをかけて・・・・、というわけにもいきません。
そんなことしたらデータベースソフトウェアとして十分なパフォーマンスを生み出すことは不可能でしょう。
一般的にこの制御は、クラスタウェアと呼ばれるものを用いて行います。
そして通常はファイルシステムではなく、RAWデバイスが用いられます。
この辺は別の機会にお話ししたほうが良いでしょう。
そういうことで最高レベルの可用性は、費用も技術も共に高い必要があるわけです。
■可用性まとめ
可用性とは
DBシステムで可用性が低い理由
可用性と予算の関係性
DBシステムの高可用性構成概要（Active/Standby） その1
DBシステムの高可用性構成概要（Active/Standby） その2
DBシステムの高可用性構成概要（Active/Active） その1
DBシステムの高可用性構成概要（Active/Active） その2
DBシステムの高可用性構成概要（Active/Active） その1
前回 は Active / Standby構成について説明しました。
この構成の特徴は、メインのマシンが死んだら、サブのマシンが動き出す事で可用性を担保するものの、メインからサブへの切替に時間がかかってしまう点がデメリットであると説明しました。
そこで考えられたのが、Active / Active構成です。
最初からActive / Active構成にしておけば、どちらかが倒れても、ブッ潰れても問題ないじゃないか、という至極真っ当な発想からこの構成が考えられました。
確かにその通りで、両方のマシン共に稼動している状況ですから Active / Standby構成よりも障害が発生した際の切替は素早く出来そうですよね。
ここまでは事実です。
しかし前に簡単に説明したDBシステムのアーキテクチャ、が上記構成をより複雑化せざるを得ないという事態を引き起こしました。
例えばAさんとBさんにまた例えてみましょう。
Active / Active構成の場合、AさんもBさんも起動した状態です。そしてAさんもBさんも同じ情報を持っている必要があります。
ここがポイントです。
AさんもBさんも”同じデータ”を保持、もしくは即座に認識可能な状況である必要があるわけです。
Aさんに「ポテトチップス 10個」という注文が入ったら、Bさんもその情報を知っておく、もしくは即座に知り得る状況である必要があります。
そうしないとAさんにポテトチップス10個という情報が入った直後に、Bさんに「ポテトチップス何個必要？」と聞いた際に、Bさんは適切な回答が出来ないからです。
簡単にいえば、AさんとBさんは常に同期を取り、且つ、同じデータが参照可能な状況である必要があるわけです。
このアーキテクチャを具体化し、高可用性構成のトップに君臨するのは、ORACLE社のReal Application Clusters(RAC)という構成です。
上記がRAC構成例です。
ざっくり見た雰囲気は、Active / Standby構成とさほど変わらないように見えるんじゃないでしょうか。
確かにそんなに大きな違いは構成としてはありません。
しかし、RAC構成と Active / Standby構成の決定的な違いは、
・各マシン同士がインターコネクト回線で常に通信をしている
・共有DISK領域を各マシンが同時にマウントしている
・クラスタウェアが必須
といったところが挙げられます。
詳細は次回に！
■可用性まとめ
可用性とは
DBシステムで可用性が低い理由
可用性と予算の関係性
DBシステムの高可用性構成概要（Active/Standby） その1
DBシステムの高可用性構成概要（Active/Standby） その2
DBシステムの高可用性構成概要（Active/Active） その1
DBシステムの高可用性構成概要（Active/Active） その2
本ブログの目標
本当は一番最初にお話しておくべきことだったのかもしれませんが、僕がこのブログを書いている理由、といいますか、最終的にどうしたいのかを書いておきます。
理由は単純で以下の3つのためです。
1. 自分の知識の整理、浄化、更なる知識習得
2. 書籍化
3. 転職のオファー
1つ目は純粋な気持ちとして、これまで経験してきた事象や思ったこと、こうだったらもっと良かったのにといった後悔等、これらをまとめておきたかったという事です。
これはいざやってみて初めて気づきましたが、書いていくと頭の中も整理されますし、更に周辺の知識を得ようという欲求も出てきます。
これは僕の成長にとって非常に大きなものだと思っています。
2つ目。
完全に不純な動機ですね(笑)
別に偉そうに上から目線で書籍を出したいがために書いてるわけでは決してありません。
単にDBエンジニアの仕事や思い、考えがまとめられた書籍ってあんまりないなぁ（たぶん需要がないから）と思っただけです。
ニッチな世界で受け入れられれば、僕としては最高に嬉しいんですけどね。
3つ目。
これも完全に不純な動機です(笑)
今の仕事内容や待遇に不満はありません。
これって結構珍しい？ことなのかもしれませが、今は恵まれた環境にいるなぁとつくづく思います。
しかし、今に満足していてはいけません。
満足していては、時代の波に取り残され、いつか化石のようになった知識とクビを宣告する紙だけが残る結果になってしまうのではないかと思うわけです。
ですからこうやって広く自分の考えを公開し、まとめることで、どこかの企業さんが僕を必要としてくれたらなぁと。
ということで、どうですか？サイバーエージェントさん(笑)
僕を雇ってみません？
まぁこれが目標です。
目標の設定は、ひとまず2年後をターゲットにしたいと思います。
2008年時点でまた次の目標を考えることにします。
現在までのブログ内容は基本的に初級向けになっていますが、状況によってはもう少しミクロ的でマニアックな話も踏まえていこうかと思っています。
ということで今後ともよろしくお願いいたします。