障害を故意に起こさせるツールで耐障害性を高める

Amazonクラウド上でわざとシステム障害を起こすためのツールChaos Monkeyの記事があったのでメモ。
故意に障害を起こして、サービス障害発生時の運用を想定するためのテストにも使えるだろう。
でも、開発者にとって障害がたとえ想定されるテストであったとしても、マゾっぽい気もする(笑)

【元ネタ】
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 － Publickey

about DevOps… ≪ すでにそこにある雲

Twitter / akipii: 故意に障害を起こして障害のフォローを想定したテストも可能になる。設計手法がどんどん変わりつつある。　サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 http://goo.gl/163yj

最近、Webサービスの開発と運用を一体化したDevOpsの概念が提唱されているが、実際の運用では、障害発生時の対応が非常に重要だ。
下手をすれば社会的信用を落とす。
だから、ITILなどの技法を取り入れて障害発生時のエスカレーション手順を厳格に定めたり、その手順をシステムテストなどで障害フォローの手順をテストしたりして、対処したりしているだろう。

最近の技術傾向を振り返ると、二つの特徴があるように思う。
一つは、監視ツールなどインフラをサポートするツールが普及してきたこと。
特にWebサービスはずっと稼働し続けるのが普通なので、障害を検知したり、ログをリアルタイムに解析したりするツールを導入して、インフラ管理をサポートするのが大切。

about DevOps… ≪ すでにそこにある雲というBlogでは、ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)
と言う本が紹介されている。
まだ読んでないので、機会があれば読みたい。

もう一つは、障害を起こさないようなアーキテクチャ作りも大切だが、むしろ、フェールセーフないしフールプループのような障害が起きたとしても安全なシステムになるようなアーキテクチャを重視するようにあらかじめ設計すること。
あるいは、メインのシステムがダウンしても、待機系のシステムがすぐに稼働して、通常の業務に支障が出ないようにシステムを冗長化(フォールトトレランス)すること。

つまり、障害が起きた時に重大な事故を起こさないように安全な運用に倒すフェールセーフ、初心者がシステムを誤動作させても安全に保つフールプルーフ、システムの冗長化というフォールトトレランスな設計が重要になっている。
これは、セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)でもよく言われていたことだ。

セーフウェアが必要な理由～ソフトウェアが凶器になる時: プログラマの思索

フォールト・アボイダンスからフェイルセーフ、フォールト・トレランスへ: プログラマの思索

障害が起きないような高信頼性のシステム作りよりも、障害がたとえ発生したとしてもすぐに修復できれば、稼働率を変えることなくWebサービスを運用することができる。
クラウドサービスが、HDDを使い捨てのように扱うことで、ハードディスクが定期的に壊れる前提で運用するように、このような発想のシステム作りが最近よく研究されているように思う。

アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性: プログラマの思索