スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

OracleRACって本当に必要?


まずお断りしておきますが、某社(某グループ?)のように不買運動的な話ではありません。また、半分はネタでタイトルをつけたので本気でいらないとは言っていません。(逆にいうと半分は本気なんですが。。。)

そもそも、OracleRACは何のために使うか考えたことはありますか?導入目的は単純明快で、DBサーバーのノードダウンがあっても処理を継続させるためです。厳密にいうとトランザクションは引き継げないのでインスタンスを守るためといったほうがいいでしょう。性能を求める要素もありますが、現在ではあまりその要件でOracleRACを選択するケースは無いと思います。

さて、システム(サービス)を継続するアプローチはいろいろあります。サーバーノードに着目した場合、RACのようにクラスタを組むのは大切な要素です。ただ、手段はそれだけではありません。サーバーノード自体の可用性をあげるのもまた大切な要素なのです。

そもそもOracleRACを導入する背景を考えてみましょう。登場したのは9iの頃ですが、当時はUNIX全盛でした。しかもサーバーの可用性は極めて低いものでした。運用した人ならわかると思いますが、サーバーの内蔵ディスクの品質は極めて悪かったと思います。リブートすると内蔵ディスクエラーで起動しないなんてことが良くありました。また、メモリエラーもありました。そんな時代だったのでサーバーノードを1つで運用するなど不安でできませんでした。

しかし時代は変わり、かなり品質が良くなりました。また、最も壊れていたディスクが外出しできるようになり、SANブートするとほとんどサーバーがダウンすることはなくなりました。

さて、こういった前提があるとして物事をニュートラルに考える必要があります。システム(サービス)の稼働はトータルの稼働率を考えなければいけません。そもそもRACの設計は大変です。一度でも構築すればわかりますが、全部設計しきるのは至難の業です。しかも設計できていないとトラブルになります。個人的に問題を感じているのは設計の難易度が全然下がらないというところです。

矛盾を感じませんか?サーバーは壊れにくくなったのにもかかわらず、可用性を高めるために入れたはずのRACは、設計ミスによる停止の確率が下がっていないため思ったほど貢献できていない可能性があるのです。むしろ機能が増えて複雑になって難易度は上がっているかもしれません。

つまり、今となっては
 サーバーの停止率<設計の考慮漏れ率
を感じるのです。

よくよく考えてみてください。シングルで組んだとしても9i当時のレベルは十分に達成できていませんか?

ちなみにOracleRACを否定する訳ではありません。何度も救われてますし。ただ、覚悟を決めて設計をやりきる価値のあるシステムはそれほど多くないと思います。逆に覚悟を決めてやるのなら、コンサルなどのサービスを利用したほうがトータルコストは安くなると思います。9i当時と比較してオラクルコンサルティングはかなり充実し、社内のナレッジが標準化しつつある印象があります。うまく彼らの能力を引き出せば障害を減らせて、トータルコストは下がるはずです。

OracleRACを本当に必要とするシステムかどうか、今一度見直す必要があると思います。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。