耐障害性とグリッド

ヒューレット・パッカードの子会社であるArjuna Tecnologies(サイト・英語)とJava Transaction ServiceとWeb Services製品(サイト・英語)に関わっているほとんど全てのチームが、最近Gridの世界と彼らの専門知識をどのように適用するか(source)ということに目を凝らしている。 最近のホワイトペーパー(source)には下記のように書かれていた。

速さと向上したリソース利用性の獲得によって、ITインフラストラクチャの複雑性が増すことになる。しかしながら結果としてデータシェアはもっと一般的でその影響を予測するのは難しい。ユーザがダイナミックに進化するITインフラの状況を明確に理解するほうが断然難しい。これは深刻な問題となり得る。特にもしデータリソースが元来閉ざされた環境の中でアクセスされるようデザインされており、また、シェアードアクセスの速さがインフラのデザイン内で見逃されている場合においてである。

そのホワイトペーパーが指摘しているように、SOAへの移行と速さの代償が存在する。ただ飯なんて実際的にあり得ないのである。データシェアは増加したが、実行環境に対する知識の管理欠如がシェアリングの性質と度合いに関する理由付けを困難にする。信頼性と耐障害性の視点からみると、これは事を複雑にするのだ。続いてそのホワイトペーパーでは同時アクセスと誤作動が存在している中でデータの一貫性と統一性をどのように保証するのかということを考慮した時に、増加したデータシェアが特にエンタープライズGridのインフラに対して、どのような問題を発生させるのかということに関して論じられている。更に彼らが指摘しているように、データのレプリケーションとキャッシング、パーティショニングはパフォーマンス性と有効性の向上に役立つものである。しかし、

パフォーマンスに関する問題を取り上げると新たな問題が浮上する。同時進行性が統一性と一貫性をもたらさなければならなく、それは分配されたパーティ間でコミュニケーションを行うプロトコルが必要となる。

Arjuna氏は人気なGridソリューションはほとんどか全くデータシェアを想定しないので、耐障害性を比較的直接的なものにすると感じている。そうでなければそのインフラは矛盾したステートがアプリケーションに影響を及ぼさないことを保証する必要があるのだ。

適切なサポートのあるシステムは以前の一貫したステートに戻す（backward recovery)か、新しいステート作りその埋め合わせをする(forward recovery)。これなしだとエンタープライズが依存しているデータを破壊させる危険があるのだ。

それはJEE、CORBA、.NET、Web Servicesにおいては当たり前と思われていることなので、何も新しいと思うことはないだろう。 しかしながらたくさんのData Gridソリューションが提供する耐障害性の競争は、アプリケーションを再起動してデータシェアをするアプリケーションにおいて（十分ではないのだが）興味深いことだ。データの一貫性用の検査メカニズムの供給なしでデータの一貫性に焦点を当てているので、それが不十分であるという概念のとおりであ る。JEEにおいて平行処理のコントロールなしでトランザクションを使用する事と同じようなものなのである。

最近はGridに耐障害性を加えるのにたくさんの努力が(PDF・英語)成され、それはインフラのアップデートが必要不可欠であるという結果をもたらした。

• 結果からアプリケーションを保護するためのデータシェア特定：障害防御
• データシェアのモニタリング:障害発見
• リカバリを補助するレコードデータ変換：障害リカバリ

疑問がいくつか残る。現在のData Gridインフラのユーザ達はこれらのコンポーネントが欠如していることで苦労しているのだろうか？もしそうでなかったらなぜだろう。これらが他のシステム内において危険な機能だからだろうか？Grid内でのデータシェアは少数派の方法なのだろうか？多分補償があるトランザクションはインフラ内よりもむしろアプリケーション内で処理されるのが一番良いのではないだろうか。

原文はこちらです：http://www.infoq.com/news/2007/09/ftgrid